Hey guys!
At the moment I am working on a hobby project where I emulate a Graupner HoTT telemetry sensor to transmit own sensor-signals. There is a UART byte stream from my micro to the 2.4GHz transceiver and there has to be a gap of 2ms between the single bytes.
To realize that I'm working with a timer and the RX-interrupt from the USCI. I'm sending a byte which causes the RX-interrupt to trigger when the byte has finished. In the ISR I start a timer with the required clock-ticks added and enable the interrupts for it - when the timer interrupt fires, I disabled the timer interrupts and send the next byte on so on.
My timer runs in continuous-mode at 8MHz which comes from the SMCLK. MCLK is 8MHz, too. I have a macro to advance the timer:
#define HOTT_MCU_TIMER_ADD_TICKS( ticks ) ( TA0CCR1 = (( ticks ) + TA0R) )
Then I pass another macro in there:
#define HOTT_MCU_TIMER_2MS_TICK_VALUE 16000
Which should result into:
( TA0CCR1 = (( 16000 ) + TA0R) )
Take the actual TAR-value and add the desired delay to it and write it to the CCR-register. But I found out, that sometimes the gaps between the packets aren't as long as they should be (I saw this on the oscilloscope). That's why I took a look into the registers of the timer and sometimes, not always, the addition of the current TAR and the extra ticks won't result in the correct value.
The user's guide says, that reading TAR, when sourced from an asynchronous clock, can fail. But this clock is SMCLK or do I misunderstand this part in the guide? It is very hard to get this "calculation error" if you want to see it - it is very rare. I tried for about twenty times now and it worked well.
Or is it a race-condition caused by the same frequency of MCLK and timer?
Anyway - I think this is a part of the timer that I still can learn something about. Any suggestion what/how to do it? I could stop the timer using TACLR, but then the other CCR-registers which are used for other things are disturbed, too.
Thanks a lot!
Dennis
