Jump to content

wolahr

Members
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

0 Neutral

About wolahr

  • Rank
    Newbrie
  1. Why not? Especially when there may be a higher priority interrupt which can interrupt the interrupt if something more pressing occurs? I can see that keeping interrupts short is a good idea in general, but is there some special or non-obvious reason why putting a delay in is dangerous? <{POST_SNAPBACK}> Never delay in an interrupt!.....unless you have to. <{POST_SNAPBACK}> So, if I do have to delay in an interrupt, could you arrange the linker to allow delay calls to be called (inlined) from more than one thread, and perhaps create a warning saying:
  2. Why not? Especially when there may be a higher priority interrupt which can interrupt the interrupt if something more pressing occurs? I can see that keeping interrupts short is a good idea in general, but is there some special or non-obvious reason why putting a delay in is dangerous?
  3. Hi dave, Thanks for fixing this so quickly Regards Will
  4. Bug description: I just compiled, linked and ran some code on a PIC18F4455, and noticed some unexpected behaviour in my program. On investigation I found that some of my data (a char[] array) had been stored in the 0x060-0x0ff range. On the PIC18F4455 this range contains SFRS (note details given below) Steps to reproduce: declare an array of over 80 bytes: char *SomeArray= " Any of this text stored between 0x80 and 0xFF may be corrupted" compile, link, run debugger and see where your data is. Expected behaviour: I expect data not to change unless it is modified by my
×
×
  • Create New...