We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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,
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.