SW UART on FLITE2 - AN1753, Output Compare and TRANCR

[jkn_stforum]

Posted on April 20, 2007 at 13:13

SW UART on FLITE2 - AN1753, Output Compare and TRANCR

[jkn_stforum]

Posted on December 21, 2006 at 17:04

Hello all

I've been trying to get the SW UART code detailed in AN1753 running on an ST7FLITE29. I've been having some problems and since I'm relatively new to the ST7 family thought I'd ask here.

At first I thought there would be no trouble using the code in the AN, which is designed for the ST7FLITE0. However there seem to be some subtle difference between the implementation of the autoreload timer.

On the FLITE0 the loading of the DCR into the shadow register depends on the state of the OE0 flag. On the FLITE2 this seems to use the TRANCR flag instead. So I ended up adding a

ld a, #01

ld TRANCR, a

every time I store into the DCRH & DCRL registers. Does this make sense in Output Compare mode?

Without this I wasn't getting any output at all on the FLITE29. The code in the application note clears the OE bit of the PWMCR each time before it re-enables the OUTPUT COMPARE interrupt Enable. Surely this is only necessary once, when the SW Uart is initialised?

I have some other questions but this will do to begin with. Has anyone else ported this Application note to the FLITE2, or can help me with the fine details of this?

Thanks

Jon N

[brian4]

Posted on April 17, 2007 at 08:30

Do you want to TX or RX on a pin?

[pjr]

Posted on April 19, 2007 at 13:11

Jonn,

Some ramblimg thoughts/alternate methods...

All this comes from thinking about your postings ( this one and previous )and reading the f29 datasheet. I have only worked with the 2264 and not the flite series...

For RX of data:

At program init load the ATR with a large value ( 4091 ). This will be loaded into the CNTR every CNTR overflow which in this case will happen every 5 CNTR clocks. Keep the number close to the ATR maximum to reduce timing offset error.

When the start bit transition is received load the ATR with a value equal to one-half of the bit time you want to receive ( This value is determined by the clock source applied to CNTR and the baud rate you are trying to receive. The one-half value will place the next OVF interrupt at the middle of the start bit for sampling it for correctness. ) and enable the CNTR OVF interrupt. The CNTR is somewhere in a cycle between 4091 and overflow. When CNTR overflows ( within 5 CNTR clocks ) it will be reloaded with the one-half bit time and the OVF interrupt will be asserted ( here is where keeping the initial ATR value large reduces the timing error as the next OVF interrupt will happen a number of CNTR clocks later whose value is the sum of the remainder of the CNTR cycle of (4091 to overflow cycle) + the one half bit time value. ). Service the interrupt by setting the ATR to a full bit time value and re-enable the OVF interrupt. Also sample the input bit ( start bit ) to check it is still low and thus a valid start bit.

The next OVF interrupt will occur midway of the first data bit. Service the interrupt by re-enabling the OVF interrupt. Sample the input bit for its value. Also the CNTR will reload with a full bit time count value.

The next OVF interrupt will occur midway in the second data bit. etc....

Repeat this until the stop bit is received. At that time set the ATR back to 4091 to begin the short CNTR to overflow cycling awaiting the next byte. Leave the OVF interrupt off during this idling period.

Transmitting data could use a similar scheme just use the full bit time count value and set the output pin to the desired bit state each OVF interrupt.

The above method limits you to TX only or RX only at any given time ( half-duplex ). I don't think you do full-duplex comms with this scheme.

Another possibility....

Maybe you could use a PWM channel to make a full-duplex capability. Set the pwm frequency to the full bit time you want to use and set the DCRxH/DCRxL to the half bit time. Connect the pwm output pin to another pin configured as input/interrupt. On CNTR overflow/pwm cycle restart/pwm output pin transition do the transmit function so there is a full bit time between bit transitions and use the DCRx count point to do the receive so that would put that transition in the middle of the receive bit time. Haven't thought about this one much.

pjr

[jkn_stforum]

Posted on April 19, 2007 at 15:27

Hi there

Thanks for the thoughts on this. not quite sure how this thread came back from the dead, but hey...

Quote:

For RX of data:

At program init load the ATR with a large value ( 4091 ). This will be loaded into the CNTR every CNTR overflow which in this case will happen every 5 CNTR clocks. Keep the number close to the ATR maximum to reduce timing offset error.

This is pretty much what I ended up doing. I actually used 4095 since there was little enough else to do and I was running at a slow baud rate.

It's a bit of a game getting the re-load count value in sync, and switching between TX and Rx, but I got it working in the end.

Interestingly I see that ST have got a 'B' mask version out of the (I think) '15 and '29, where you can force the reload to occur immediately. Which at least seems to acknowledge this as a bug.

Thanks for your thoughts.

jon N

[laurent239955_stm1]

Posted on April 20, 2007 at 13:13

Hi,

First of all : Thank you all for your contibutions to the ST7 forum.

I want to come back to Jon's last point. From a semantic point of view, a bug is a behaviour which does not respect the specifications. Which is not the case concerning the point which you highlight.

The ST7LITE1B (10B, 15B and 19B) products were introduced on customer's requests. The Lite1B Auto-Reload Timer is an advanced Timer which provides some new features among the force update and the one pulse mode.

I let you refer to the datasheet for more information.

Best regards

Laurent