RIOT-OS
enc28j60: irq handling
I think the function https://github.com/RIOT-OS/RIOT/blob/361d41db0514d2c000a61a47c0a3822c09b9cd34/drivers/enc28j60/enc28j60.c#L250 is executed inside a irq context, thus https://github.com/RIOT-OS/RIOT/blob/361d41db0514d2c000a61a47c0a3822c09b9cd34/drivers/enc28j60/enc28j60.c#L254 will try to lock the mutex, and this is maybe locked by any other spi transfering function, thus it may hang for a while... -> maybe better to not do any spi transface inside a irq function?
I agree that this looks quite suboptimal; from my understanding of interrupt lines in general (it's been too long since I've actually programmed ENC28J60 drivers) it should suffice if the event handler cleared the interrupt register, then worked off everything that might be pending.
I've skimmed the handbook again, and given that we sit on an edge interrupt, I think the proper sequence would be:
- disable the interrupt at the start of nd_isr (clear INTIE)
- read EIR the first time
- enable interrupts again (set INTIE; the interrupt should be clear now, but if something is just coming along, it can go up any time again, making nd_isr pending in the event thread again)
- loop until EIR is clear, without touching INTIE again
This may create one more trip through nd_isr in the rare case that an interrupt fires while events are being handled, but ensures that we're on the safe side w/rt mutexes and interrupts. But I don't have the whole picture here, so pinging @gschorcht for details.
