topic Re: Changing channel function TIM08 in 8-bit Microcontrollers

Changing channel function TIM08

JimB — Mon, 26 Dec 2011 11:54:07 GMT

I wish to bit-bang a SCI receiver on a TIM08 channel in a similar way to that demonstrated in AN2502 so that I can use the other channel independently for other things. AN2502 says:

"It is possible to implement full-duplex operation because two independent

channels of the TIM are used for each of the operations with independent data

registers."

...and...

"In the interrupt service routine (ISR) for the input capture, the time for the first

received bit is set. At this point, the reception channel is configured as output

compare and used as a time base for data bit receptions."

The TIM08 reference manual and the MCU datasheet seem to rule this out:

"NOTE: Stop and reset the TIM before changing a channel function.

Before writing to the mode select bits (MSxB and MSxA), set the timer

stop and timer reset bits (TSTOP and TRST) in the TSC register."

I'd really like to reconcile these two sources before I proceed. Please let me know if you have any suggestions, ideally a datasheet or other reference that expands on the TIM08 directive.

Incidentally, I realise that bit-banging a SCI and coding for an HC08 are both a bit old-fashioned now!

Thanks,

Jim

Re: Changing channel function TIM08

rocco — Tue, 27 Dec 2011 06:56:59 GMT

Hi Jim,

Here is another attempt to reply, not as thorough as the previous attempt (I'm out of time).

I can't help with your question directly, as I have always used HC08 and S08 that contained an SCI. However, I did implement a uart in a DSP once, using just two standard I/O pins and a periodic timer.

I set one I/O pin as output for TX and one as input for RX. I set the timer to interrupt at 16x the baud rate.

I would sample the RX pin on every timer interrupt, and update the TX pin on every 16th timer interrupt. The TX part was way too easy. The RX, not so.

For RX, I implemented a state-machine algorithm, as spelled-out in the SCI chapter of the HC08 databook: Syncing a mod-16 counter on the leading edge of the start-bit, and then sampling the data in every 7th, 9th and 11th interrupt.

But the DSP was a lot faster than an HC08. If the baud rate is high, you could reduce the timer to 8x the baud-rate and sample the 3rd, 4th and 5th interrupt. I can even see it working at 2x baud-rate.

Re: Changing channel function TIM08

bigmac — Tue, 27 Dec 2011 11:41:04 GMT

Hello Jim,

You will observe that the paragraph that you quote is provided as a "note", and is not a "warning". No mention is made of any consequences if this is not followed.

Since you need to continue counting, following the input capture event for the start bit, you certainly do not want to clear the TIM counter. While you could conceivably halt the counter for a short interval while the registers are altered, I don't think that this is really necessary.

For PWM mode, certain precautions are necessary to prevent spurious pin output. However, your requirement commences with input capture mode, and then changes to a software compare mode, and finally reverts back to input capture mode. Just ensure that the channel interrupt flag is explicitly cleared after each mode change.

With a reasonable choice of bus frequency and baud rate, none of the channel timing would seem critical. I cannot see why the AN2502 code should not work as intended. The only potential timing issue would concern any other interrupts than may occur, and give additional latency in reading the pin state.

Regards,

Mac

Re: Changing channel function TIM08

JimB — Tue, 27 Dec 2011 18:56:48 GMT

Thank you both (Rocco & Mac) for taking the time to help - I know it took me a long time just to get the question right :smileyalert:, so I really appreciate it.

Rocco: your suggestion, as you say, could be a bit tight in my situation. In fact I have only 333 cycles per bit, and perhaps the clincher is that I wish to use the MCU's internal clock source rather than a xtal which I figure means I probably can't afford the added uncertainty of the phase difference between the periodic interrupt and the transmitter's bit clock with an achievable interrupt rate. I must confess I would also be worried about how the rest of my struggled-for code would perform with such a change, so perhaps I am just a bit chicken.

Mac: that gives me the confidence to proceed as intended, I hoped someone would say something like that! I suppose also that the author of AN2502 would have quickly discovered anything too severe. Your final point about interrupt latency and the clock-uncertainty consideration Rocco inspired has got me re-examining the rest of my design: It looks like my worst case is about 50 cycles, which I had thought would be OK, but I'll put it on my list to consider whether I can unmask interrupts within that ISR.

Thanks again,

Jim