I’m working on a project which uses FreeRTOS.  It is working, but we want to service devices (in addition to the PIT, which is used for the timer tick) which are part of the SYSC, and, therefore all share the AT91C_ID_SYS IRQ. In the GCC/ARM7_AT91SAM7S port, vPreemptiveTick (or vNonPreemptiveTick, as the case may be) is registered directly to the SYS interupt.  That’s fine, since that’s the only SYSC device that raises them.  I need to also handle the RSTC interrupt, which requires me to change that.  I pretty much know how I can do that, but am concerned that if I do, we’ll lose the ability to directly update those files when a new version of FreeRTOS comes out. If there is a plan to allow other SYSC devices to have interrupts serviced, I’d rather go with that than to hack it locally and try to keep everything in sync when the GCC/ARM7_AT91SAM7S port of FreeRTOS changes. It is easily conceivable that the ability to do this sort of thing may be of broad interest (on the SAM7 platform).  It would allow one to use the DBGU UART, for instance.

A loooooong time ago there were a couple of solutions posted here to allow all the sys interrupts to be serviced. You might be able to find then by searching the forum but the search facility is not too good. One way of getting around your upgrade worries is to setup the timer interrupt from your application code rather than from the FreeRTOS code.

I don’t even know what search terms I’d use for that.  And I see what you mean about the search facility.  Nice to see it’s been considered.  Sad to see it didn’t make its way into the distribution. Yeah, I could set up the timer code, myself, but that would pretty much force me to abandon most if not all of the other port code that comes with FreeRTOS, wouldn’t it? Maybe I can use some creative linking to supply my own functions to do some of the things in the port, but use the others in the port that I do not define.  A problem with that, though, would be that the functions I override will still be present in the executable, taking up FLASH needlessly.  It’s not the end of the world (the functions are small); but still.