#114 INT0 problem - INTEDG0 ignored on 18F core

open
None
5
2014-02-12
2010-11-27
No

When the correction for bug #3071596 was implemented, two issues were overlooked. Firstly, only INT1 and INT2 were added; some supported devices have INT3 as well. Secondly, the behaviour of INT0 was explicitly left alone. This is wrong, because the existing behaviour matches the 14-bit core; on the 18F core INT0 is like INT1..3 and should be implemented as such.

Discussion

  • Robert Pearce

    Robert Pearce - 2010-11-28
    • assigned_to: nobody --> bdt-rob
     
  • Robert Pearce

    Robert Pearce - 2010-11-28

    Now working on a fix. Noticed that the regression test attempts to verify both edges but makes no effort to check which edge is actually sensitive (or indeed whether they both are).

     
  • Robert Pearce

    Robert Pearce - 2011-01-29

    This was nominally fixed at r2147, but there is no regression test for the INT3 input (available on 18F6520 but not the 2321 that the regression test uses)

     
  • Anonymous - 2014-02-10

    Hi Robert,

    I found the same problem when using gpsim with pic16F877.
    When INTEDG bit is cleared in OPTION_REG, the datasheet says the interrupt should trigger on falling edge of RB0/INT pin. But it still triggers on the rising edge when simulating with gpsim.

    Brilliant tool otherwise!

    Stan

     
  • Anonymous - 2014-02-12

    Hi Robert,

    I tested v0.27 and confirm that pic16F877 INT0 triggers correctly on falling edge when INTEDG bit is cleared in OPTION_REG, The previous message was wrong, sorry for the confusion.

    Stan

     


Anonymous

Cancel  Add attachments