I need to measure small portions of time (at least 500us) while using Keil's RTX51 with a System Slice of 20ms. I'm assuming that RTX51 already has a realtime counter that tracks clock ticks (or at least Timer0 overflows) since initialization. Does anyone know the variables/registers it uses for this. I cannot find any reference to tracking time that's less than one System Slice in the RTX manual Normally I would set up another timer to do this tracking but Timer1 and Timer2 are already being used for UART and I2C functions. I have a fall back plan to use Timer1 (even while in use as a baud rate generator) but using system variables would be much cleaner
Unless you grab one of the other timers, this will typically mean you have to *) Stop RTX's multitasking, to free Timer0 *) (Save its configuration) *) Set it up the way you need it *) do your timed thing *) (restore the saved configuration) *) Re-enable multitasking Or you could just look at the values of the Timer0 registers, and try to make sense out of them. But that will cause its own kinds of problems as soon as you come close to the time slice boundaries.
unfortunately hijacking timer0 from the RTOS is not an option. This would create timing errors that would seriously hurt my application. As it turns out RTX51 does not actually track (or expose) a running time slice count. Fortunately my fall back plan of leaving timer1 interrupts enabled while it is a baud rate generator will work for my situation. My goal is to track byte size gaps in a serial bit stream for a Modbus RTU driver. Although that solves my current problem, I would still like to have access to a system tick counter for other purposes. Perhaps a counter in a task set to a 1 tick interval will be my only option
Have you considered using a derivative with a PCA or CCA, either gives you 4 or 5 "timers" more. Erik
Hi First of all before using a timers. Select the smalles segment in your case 500uS then set one of your timer to 500uS then use tick_count varibel (It can be a Byte or 2 Byte)data, Do your I2C or UART onec tick count reach the actual value
You may be better off ignoring the interbyte timeout with Modbus RTU. I've looked at a number of implementations and found that none of them conformed to the specification during transmit. This means that your receive implementation may erroneously detect end of transmission. Stefan
Funny you should mention about ignoring the byte gap of the RTU mode. For lack of simpler solutions. I've also decided to ignore the byte gap and solely rely on checking the incoming stream to make sure it conforms to my supported commands. This gives me 6 points of reference to check, plus that LRC checksum nighmare. This adds to my serial interrupts overhead, but in the end it is extremely unlikely my system will falsely activate on someone else's command. I'm glad to see that other designer's have also followed this route