Hello everyone,

We're running on an or1k-based BSP off of 4.11 (with the patches I've forwarded 
in February last year) and have seen some strange sluggishness in the system. 
When measuring using a standalone peripheral clock, I can see that we spend 
between 0.8 - 1.4 ms just handling the tick. This sounds a bit absurd to me and 
I just wanted to send out a couple of questions to see if anyone has an inkling 
of what is going on. I haven't been able to test with the or1k-simulator (and 
the generic_or1k BSP) as it won't easily compile with a newer gcc, but I'm 
running on real hardware. The patches I made don't sound like big hold-ups to 
me either, but a second pair of eyes is of course always welcome.

To the questions:
1. On the or1k-cpu RTEMS bsp, timer ticks are using the cpu-internal timer, 
which when timing out results in a timer exception. Clock_isr is installed as 
the exception handler for this and thus have complete control of the cpu for 
it's duration. Is this as the Clock_isr is intended to run, i.e. no other tasks 
or interrupts are allowed during tick handling? Just want to make sure there is 
no mismatch between the or1k setup in RTEMS and how Clock_isr is intended to 

2. Running a very simple test application with three tasks, I delved into the 
_Timecounter_Tick part of the Clock_isr and I have seen the tc_windup() is 
using ~340 us quite consistently and _Watchdog_Tick() is using ~630 when all 
tasks are started. What numbers can be seen at other systems, i.e. what should 
I expect as normal here? Any ideas on what can be wrong? I'll keep digging and 
try to discern any individual culprits as well. 

Oh, and we use 10000 as base for the tick quantum.

(If anyone is interested in looking at our code, bsps and toolchains can be 
downloaded at repo.aacmicrotec.com.)

Best regards,


Jakob Viketoft
Senior Engineer in RTL and embedded software

ÅAC Microtec AB
Dag Hammarskjölds väg 48
SE-751 83 Uppsala, Sweden

T: +46 702 80 95 97
devel mailing list

Reply via email to