Page 1 of 1

SUART stopped after update

Posted: Mon Mar 16, 2020 4:34 pm
by skartalov
Just updated the SF and compiled a project, the SUART doesn't work anymore.

What changes it has?

How can I obtain the previous version of SUART?

Re: SUART stopped after update

Posted: Mon Mar 16, 2020 11:41 pm
by Jerry Messina
A few questions...
Can you give any details about what doesn't work?
What device are you using it with?
Any example code I can test?

I've attached a copy of the previous version (v1.3) in the meantime.

Re: SUART stopped after update

Posted: Tue Mar 17, 2020 6:33 am
by skartalov
I compiled with the old SUART, and now it works again!

I sent you my code on PM, check.

Re: SUART stopped after update

Posted: Tue Mar 17, 2020 11:38 am
by Jerry Messina
Thanks. I'll take a look and see what I find...

Re: SUART stopped after update

Posted: Tue Mar 17, 2020 4:23 pm
by Jerry Messina
So, here's the scoop...

The SUART module (v14) from the 2230 update works as intended.
The major difference between v14 and the old v13 is that v14 initializes the state of the TX output pin when you call SetTX()
(that and it now works with a wider range of devices/ports).

v13 does not initialize the TX pin state until the first WriteByte() occurs, so the first byte may be invalid depending on the
state of the pin and mode setting. If it works, it's a fluke since the LAT register is not initialized @ pon or reset.

There are a few things that influence this, and most of them have to do with the order of statements.
I can rearrange the initialization code and get the same failures out of both versions, but v14 is more reliable.

First off, you should remove any 'input' and 'output' statements from your main module for the SUART... they only tend to make things worse.
Then, it's important to change the order of calls so that 'SetMode()' is done BEFORE calling 'SetTX()'. That can help.
Finally, once the TX pin is initialized you may need to insert a short delay (say 1-10ms) before you send the first byte
so that the receiving device has time to see a valid idle level.

You can't fix this in v13, but with v14 I would do something like:

Code: Select all

include "SUART.bas"

SetAllDigital()        

UART.SetMode(umTrue)
UART.SetTX(PORTB.4)
UART.SetRX(PORTB.5)
UART.SetBaudrate(sbr57600)
// this delay allows time for the device you're connect up to
// to see a proper idle level on its RX input (our TX output 
// may have been "invalid" at startup causing the receiver to see
// garbage for the first character or a serial BREAK) 
delayms(10)

UART.WriteByte("1")
UART.WriteByte("2") 
UART.WriteByte("3") 
UART.WriteByte("4")
I've made some changes to the module for v15 that make some of this easier by adding '#options' that you can set to control this stuff...
#option SUART_MODE // default = 2 (umInverted)
#option SUART_INIT_TX // default = true

Example:

Code: Select all

#option SUART_MODE = 1     // set default to idle high (like a hw uart)
#option SUART_INIT_TX = true	// defaults to true, so not really required 
include "SUART.bas"

SetAllDigital()        

UART.SetTX(PORTB.4)
UART.SetRX(PORTB.5)
UART.SetBaudrate(sbr57600)
// this delay allows time for the device you're connect up to
// to see a proper idle level on its RX input (our TX output 
// may have been "invalid" at startup causing the receiver to see
// garbage for the first character or a serial BREAK) 
delayms(10)

UART.WriteByte("1")
UART.WriteByte("2") 
UART.WriteByte("3") 
UART.WriteByte("4")
If you use '#option SUART_MODE' you don't even have to call SetMode anymore... it'll be set for you.
If you don't want SetTX() to init the TX pin state, then set '#option SUART_INIT_TX = false' (but I wouldn't recommend that).
Setting '#option SUART_MODE=2' and '#option SUART_INIT_TX = false' will get you the same operation as v13.
v15 will be included as part of the next update.

I have half a mind to change the default mode option to '1 (umTrue)' since that makes it work like a regular hw uart out of the box.
Any feelings on this?