adecar wrote on Thursday, September 24, 2009:
Hi,
I have a bit of a request for FreeRTOS. I’m currently working on a project which requires the use of 3 UARTS, the SAM7 has 3 uarts on board, 2 normal and 1 debug uart which has reduced functionality, but for our particular application we do not require anything other than the standard 8-N-1 settings on the port.
I have my own UART abstraction layer which we have used on the SAM7 before which just requires me to add a low level driver for the uart, however, there’s a bit of an issue with the sam7 port out of the box.
The system interrupt vector which you install assumes that the only time it will ever be called is because the system tick has "gone off", however, the DBGU on the SAM7 shares the system interrupt with the PIT timer.
Now, modifying the port code is obviously trivial, but what I like to do when you release a new version of FreeRTOS is to just drop it into my project and replace the existing freertos distribution, rebuild and bobs you uncle. However, if I make changes to the port file then they will obviously be lost.
So, what I’m asking (proposing) is would it be possible to provide a define which allows a user routine (or macro) to be called if the PIT was not the source of the interrupt, so for example, the freertos system tick could become:
void vPreemptiveTick( void )
{
/* Save the context of the current task. */
portSAVE_CONTEXT();
#if defined( configUSE_SAM7_SYSTEM_DISPATCHER )
if (AT91C_BASE_PITC->PITC_PISR & AT91C_PITC_PITS)
{
#endif
/* Increment the tick count - this may wake a task. */
vTaskIncrementTick();
/* Find the highest priority task that is ready to run. */
vTaskSwitchContext();
/* End the interrupt in the AIC. */
AT91C_BASE_AIC->AIC_EOICR = AT91C_BASE_PITC->PITC_PIVR;
#if defined( configUSE_SAM7_SYSTEM_DISPATCHER )
}
else
sam7_system_irq_dispatcher();
#endif
portRESTORE_CONTEXT();
}
If you don’t use the option, then the code will compile as is, but if you do use the option, you have to supply the sam7_system_irq_dispacher routine which the user supplies to locate the source and then handle the interrupt.
One other thing which has been like this for a while, the sam7x256 header file which you use is out of date, and the function which installs the system interrupt has an incorrect syntax when used against the current atmel library functions, it’s missing a first parameter which should be a pointer the AIC base address. This isn’t a problem unless you change the header to a newer one (i.e if you think, oh I’m not using a SAM7X so I’ll change the include to SAM7S) and then wonder why you keep ending up in data abort.
Thanks.
Adrian