FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [September 2009 Threads] SAM7 System InterruptPosted by Adrian Carpenter on 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
RE: SAM7 System InterruptPosted by Richard on September 25, 2009 I would be grateful if you would add this to the feature request tracker (under SourceForge).
Also, how did you get the code to be displayed as formatted code? I tried it the other day but it just added tags into the text.
Regards
RE: SAM7 System InterruptPosted by Mike on September 29, 2009 Could I also remind you of this thread [https://sourceforge.net/forum/message.php?msg_id=7095131][1] which seems to cover the same area
Regards [1]: https://sourceforge.net/forum/message.php?msg_id=7095131
RE: SAM7 System InterruptPosted by Adrian Carpenter on September 29, 2009 The method in that thread is a bit "hacky". you'd either have to cut and paste code from vTaskStartScheduler to get it to install your own vector, or you'd have to let it install it's own vector and then in one of the tasks that start, disable interrupts and then install your own vector and then let yourself take over that interrupt, which isn't a very clean thing to do in my eyes.
Providing a compile time solution into the port is a much nicer way of dealing with this.
Thanks
RE: SAM7 System InterruptPosted by Adrian Carpenter on September 29, 2009 Oh, and I'm not sure what I did with the tags, I clicked the "101010" button and then just pasted my code from textmate directly into the block it created and it pretty much came out how I expected.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|