Hi, Good Day.
I am working on ARM7TDMI core processor from Analog Devices family (ADuC703x). I developed a preemptive scheduler on the same in ARM environment. The functionality of the same is fine and its working well. For the purpose of optimization, i migrated into thumb mode using Keil RV compiler option (by changing the code generation option to THUMB mode and the optimization level option to 3 in C/C++ tab of the target settings option).
After changing the settings my code size is reduced by 2 KB. But, the complete functionality of the software got changed.
Can anybody help me out to get out of this problem? Also, I would like to know why this kind of behavior is occurring... Please let me know your valuable suggesions.
Thanking you in anticipation, Ravi Kumar Desaraju.
Hi Michel,
I may require few peripheral interrupts in my application. I dont want to use those interrupts in FIQ since, FIQ holds the higher priority than IRQ. Therfore, I am using the FIQ handler for scheduler. In future, if I require any peripheral interrupts in my application, I can configure the same in IRQ handler.
think of this: what is more important to you - switching a task in a timely manner or servicing a peripheral at a timely manner? I don't know about you, but unless what you are writing is truly time critical and has clear deadlines (per task), servicing a peripheral sounds more important to me (so: keep the FIQ for a peripheral). You are aware that the difference between FIQ/IRQ servicing is one branch instruction at most, as the FIQ is the last entry in the vector table hence the servicing code can be placed in the table itself. is your application that time critical? and don't be stubborn - do as you are told :-)
Mine is safety critical system. For this kind of application, we feel its better to use FIQ service handler (since it has the high priority).
The tasks in this system must run over a specific periodicity. No latencies are allowed and the scheduler must be built with hard realtime concept. These are the key requirements which are forced me to go for FIQ. Yes, I do agree your opinion about the peripheral interrupts. In our case, the priority is task switching over the specific periodicity.
Apart from this, I would like to know few points about the ISRs in ARM7TDMI core processors.
My FIQ handler was developed in ARM code and the CPU mode is switch from THUMB to ARM in case of FIQ interrupt. After leaving the handler, CPU mode is switching from ARM to THUMB. There is no problem in executing the interrupt service. My question is, is it suggestible to implement the context switching with in the ISR....?
if you are writing a safety critical system you are probably much better off with a real RTOS rather than writing you own scheduler. Your expectations of having no interrupt latency are not realistic, I am afraid, as there is usually a trade-off between interrupt latency, throughput, and processor utilization. One way of the other, high system load will cause some delays and there is no way around it. As to your final question - have you seen this link? http://www.keil.com/forum/docs/thread12635.asp
Hmm... I'm afraid the system in question cannot qualify as 'safety critical': it appears some basic problems have not been sorted out yet. I agree with Tamir, why not look around for a 'tried and true' third-party RTOS? After all, you are not trying to develop your own compiler, shouldn't the same apply to an RTOS?
Hi Mike and Tamir,
I do agree with you ppl about using the IRQ handler instead of FIQ. As I explained earlier, my system is a safety critical thats the only point which forced me to work with FIQ. Moreover, my scheduler is working fine with all the timing considerations in ARM mode. I am facing the problem with THUMB mode only.
The reason why we did not prefer to go with already available RTOS is memory consideration... This particular chip is having 30KB of FLASH and 4 KB of SRAM. So.. we are developing our own scheduler with minimum functionality (viz., we don't have resource sharing concept in this project, so no need to develop mutex and seam phore etc... In a broad way we are implementing the RM algorithm in our scheduler).
In ARM mode the size of my code is 3 KB. When I convert and build the code in THUMB mode, I observed that the scheduler code is occupying just 1.8KB. So, I thought its better to go for THUMB mode to reduce the code size further (worst case, it would become 2 KB. which saves 1 KB of FLASH memory....).
Tamir,
I referred the link which you have provided. Its really useful... thanks a lot.
Keil's RTL has all the features you want, plus more that you do not need AND meets your tight space requirements. (That if 2K or less of ROM space for the kernel is a requirement) It also works in ARM or Thumb Mode. You can also buy the source code so that you can modify it if you need too (I believe it is still under $5k US to buy). One of the ways they keep the code size small is that if you do not use a feature, it will not link in that feature (i.e. Semaphores, Mailboxes, Mutexes...). You can just use the Real Time Task Scheduler... that works. If nothing else by buying the source that works, you might be able to figure out what you are doing wrong. It never hurts to understand more.
Make that $5k for each user who need to be able to work with the project.
(30k of Flash + 4k of RAM) == ($5k * 1)
Sorry, I can parse - but not understand - that equation. $5k * 1 for the RTXC source if only a single user needs to compile the project.
It was a Joke.
It meant to fill up 30K of Flash and 4k of RAM would only require 1 developer, especially if that developer did not have to develop the RTOS from scratch.
I agree. 30k ROM implies a quite small application.
Buying - or settling for the pre-compiled version - of RTXC saves a lot of time.
Not just time to write the code, but also to verify that the scheduler really works. Better to spend that time on debugging the final application.
The saved time could possibly be used to write tighter code for the actual application. That would probably affect the total flash and RAM requirements way more than the size difference between the two scheduler implementations.
Hi All,
I found the solution for my problem and able to fix the same. My scheduler is functioning as expected and meeting all our timing requirements. Currently the code size for the scheduler is 2 KB.
Please tell us - what was the problem?
The context switching code was developed in ARM mode and the same is performing out side the FIQ handler. The context switching code will be invoked from the FIQ handler. While entering into the FIQ handler the processor mode was stored in the SPSR register as THUMB mode and the same was restored while leaving the FIQ handler.
At this point of time, the code was in ARM mode and the processor mode was in THUMB which is the major problem caused to enter into PABORT exception. Also, my earlier code (in ARM mode)contains the context switching code within the FIQ handler. I am retrieving and storing the context of a particular task within the FIQ service handler (which requires to change the processor Stack pointer). The processor will remember the current SP value while exiting from the FIQ handler. Therefore, after performing the context switching, FIQ handler is using the SP which was restored last time. This was the reason why I moved my contextswitching code out side the FIQ handler.
I have gone through the link u provided last time. In your code u defined an element in the TCB for each register. In my code, TCB doesn't contain any info abt the registers. It just contain the SP, LR, TAsk ID and the next element/previous elemnt. I am taking the SP value from the TCB and retrieving the context using a POP instruction. I think this was the difference between your code and mine.
View all questions in Keil forum