The tricky part is of coruse that you can't (or shouldn't) block inside the ISR, so you may find that the right thing to do is either to ENSURE that you never update stuff that ReadData() uses [e.g. readPtr] inside the ISR, or have some sort of "make this ISR happen at a later stage" type mechanism.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
That makes sense, its the same as mutual exclusive. I don't have an OS on this processor - its an STM32 ARM core, so just using standard C with the inbuilt libraries to do peripheral control.Originally Posted by Salem
Off to do some more research on semaphores in C then...
--dave
matsp has a good point, making sure the ISR doesn't block is essential.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Yes. I know this from experience - blocking in interrupts is a good way to stop the entire system from working (at least until the interrupt unblocks, and if it's waiting for a lower priority task, then we could be waiting a good while, like until the next power-cut or some such).
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Thanks for all your help chaps, the solution suggested by salem worked and made sense to me
--dave
