I am trying to use the timing withing uCOS-II as my real time source.
I only need to service a routine 1x/sec, and this routine takes 100uS to complete.
I seem to be getting innacurate timing. My service routine (which is the higherst priority task) only runs every 1.000- 1.03 seconds.
I have disabled all external interrupts, I run no other interrupts on timers etc. I use OS_ENTER_CRITICAL, but only for some floating point assignments to global variables (infrequent).
I am using an RCM4200
My RTC seems to accurately reflect the true time, so it seems that some periodic interrupts are not being seen by uCOS-II?
Can anyone make any suggestions?
Some quick testing seems to reveal that both ethe ADC driver, as well as the SPI driver are the cause of the dropped periodic interrupt servicing.
When I disable both tasks that perform the above, the timing is exact to 5 decimal places. Enabling either task results in timing errors of up to 3% (slower - ie missed interupts).
Is there anything that can be done about this - not very Real Time as it now stands
I may be off base but I think OS time is dependent on the number number of ticks per second which defaults to 64. Altering the number of ticks per second may be an avenue to explore.
OS Time is by default 64 ticks per second. I was using 256, but decreased it to the default 64 as part of my testing, this had no effect. I do not want to decrease the time slice period further as then response time may be affected by some of the other tasks (Modbus, as well as TCP I/O).
Note that allowing TCP / Modbus does not cause accuracy problems, just the SPI routines (? are interrupts being disabled for a short period, and are they being missed)
I had a few debugging printf (to stdio) in the program to look at runtime A/D and thermocouple outputs.
When eliminating the stdio output, the accuracy is back to 6 decimal places.
The SPI was not the problem.
Do me a favor and look at my posting a few down in the thread. I was no help to you but maybe can shed some light on my problem.