Problem in converting the ARM code into THUMB

It makes sense to use Thumb "as much as you can" to optimize for size.

on an ARM7TDMI you CANNOT run with thumb code exclusively, you must have SOME ARM code. It really cannot be done so don't try to.

That being said, I would assume that having working code is more important than the size. Because it is much easier to get a scheduler to work in ARM code than Thumb code, you should write you scheduler in ARM code. I would also write it to be run though the SWI execption handler. This will put you into a priviledge mode AND into ARM mode. When you return from this you can have the USER registers all set up/restored and return to either thumb or ARM mode directly, without using a BX instruction.

It makes sense to use Thumb "as much as you can" to optimize for size.

on an ARM7TDMI you CANNOT run with thumb code exclusively, you must have SOME ARM code. It really cannot be done so don't try to.

That being said, I would assume that having working code is more important than the size. Because it is much easier to get a scheduler to work in ARM code than Thumb code, you should write you scheduler in ARM code. I would also write it to be run though the SWI execption handler. This will put you into a priviledge mode AND into ARM mode. When you return from this you can have the USER registers all set up/restored and return to either thumb or ARM mode directly, without using a BX instruction.

Robert,

you wrote

I would also write it to be run though the SWI execption handler. This will put you into a priviledge mode AND into ARM mode.

I thought that all exception code is executed in ARM, even if the non-exception code runs in thumb? it is possible to switch to thumb in the handler, of course.

Yes, all exception/interrupt code has to start in ARM mode, since the processor does not know anything about the code when entering the exception handler.

I think he is trying to say that an SWI handler is an easy way to get into priviledged mode and into ARM mode. No need to consume the FIQ handler.

Yes, All the exceptions must be written in ARM mode. While you exit from the exception, the statement (return) itself switches the control back to THUMB mode. No need to execute a branch exchange instruction again to switch back to THUMB mode. This I experimented in FIQ handler and IRQ handler. I think it is same for all exceptions.

Well, coming to running the scheduler with SWI, how sure you are maintaining the performance of your scheduler with in the tolerance range. My application is to execute few tasks on a specific timing interval/periodicity. That's why I opted for a FIQ (using timer interrupt).

why then not use a periodic timer that uses an IRQ? IRQ has a higher interrupt priority than SWI:

Exceptions      Priority        I bit   F bit
Reset                      1              1       1
Data Abort                 2              1       -
Fast Interrupt Request     3              1       1
Interrupt Request          4              1       -
Prefetch Abort             5              1       -
Software Interrupt         6              1       -
Undefined Instruction      6              1       -

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 :-)

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.