Very long time for context switch on SH2

[James Yates]

The frequency of the CPU clock is 44.2368Mhz. I have managed to configure the tick timer to give 20uS ticks 
using an on-chip timer. Anything less than this and for some reason it refuses to run.

   I am running the code with GDB over a 115k serial link. Running on the board is a ported version of the 
gdbSTubs project from sourceforge which I have used successfully for lots of non RTOS work, so I am 
confident it works ok and it uses no interrupts. 

   The test i wrote consists of 2 task plus the main init task. Once the init task spawns tasks1 & 2 it then
 terminates. Each of the 2 tasks are identical sitting in endless loops taking a semaphore using a blocking 
call, inverting an on board LEDs state, giving the semaphore and then calling 
rtems_task_wake_after(RTEMS_YIELD_PROCESSOR);    Both tasks use the same semaphore.

  To measure what I did was first to measure, using a scope, the time difference between both LEDs changing 
state. I then repeated the test but with only 1 task running to measure the time taken to go obtain and 
release the semaphore. The difference between these 2 times being the approx context switch time.

In this case, the only memory being used is the on-chip flash of the SH2, where the gdbstub program resides
and runs from and some external SRAM.

My concern which led me to measuring the context switch time is that setting very small count values for 
the timer providing the clock ticks led to the code refusing to run. I am going to try to create a version
which will run as firmware rather than through the debugger so as to remove any possible gdb stub interraction
and then re perform the tests. I do however think that something more fundamental is wrong in what I have done
to get this running on the SH7145 or my BSP.

	Many thanks Ralf

-----Original Message-----
From: Ralf Corsepius [mailto:ralf_corsepius at rtems.org]
Sent: 22 March 2004 12:38
To: James Yates
Cc: RTEMS Users
Subject: Re: Very long time for context switch on SH2


On Mon, 2004-03-22 at 11:25, James Yates wrote:
> I am working on a custom BSP which has an SH2 7145f. I have performed
> a basic port for this SH7145 
> cpu based on the SH7045 already in the tree. The 2 chips are very
> similar. However, after some 
> analysis, the shortest time I seem to be able to measure for a context
> switch is 192us, which I think is pretty slow.

The code for the context switch can be found in __CPU_Context_switch in
c/src/lib/libcpu/sh/sh7040/score/cpu_asm.c

Counting the asm instructions in there gives you a rough estimate of
cpu-cycles being required (ca. 50 cpu-cycles) for a context switch.

>  Am I wrong?
Yes, 192e-6 would be pretty slow, but to be able to further comment on
this requires more knowledge about your actual setup and how you
measured this figure.

> I have been muckng around with the system clock to see if by increasing the ticks per second, the 
> context switch time could be reduced but I can't get any better than 192us.
How did you measure this timings? Normally, the context switching time
should be inversely proportional to the CPU clock rate.

The time between task switches is application and setup dependent.

> Does anyone have any ideas?
One crucial point on SH1s and SH2s is their memory. 

Unlike many other CPUs they can be equipped with non-consecutive memory
(Our AMOS boards the gensh1 and gensh2 are derived from, had such
non-consecutive memory), which can apply different wait-states/memory
timings etc., which can have unexpected influences on task-switching
times.

Another factor to consider is IRQs, IO and debugging stubs. 
Esp. the latter 2 can distort measurements because they often apply
"busy waiting"/"polling on IO-registers".

Also, debugging stubs often are implemented as ISRs being attached to a
very high priority interrupt, which could disturb RTEMS. 

>  Is there an Idle task that always runs?
IIRC, yes. 

>  Could this be causing any problems?
Theoretically yes, but not to the extend you seem to be experiencing.

Ralf