SUSART module with Timers

octal · Post by **octal** » Sat Apr 21, 2007 9:08 am

Hi,
I'm using the timer class from "ISRTimer.bas". I created an OnTimer event that updates status leds from my board (ON/OFF/BLINK). All works fine.
I tried to use the SUSART module to send some data (for Debug purpose). The SUSART module is unable to send data correctly, I receive garbage chars on SF - Serial Communicator software. I tried only to send simple string "debug msg".
When I disable the Timer all works fine and I receive my strings from USART. I thinked that it was due to the fact that the SUSART is on the same port that controls LEDs updated by the timer, so I changed ALL leds to be on portA and SUSART sends/receives chars on PortB ;... nothing ... I disabled the Pullups on PortB and nothing !!!

What happens ?

Best regards

Used Chip : 18F1320 on EasyPic-4 board

David Barker · Post by **David Barker** » Sat Apr 21, 2007 9:37 am

With software serial communication, timing is critical. Just look at the source to see what I mean. A bit has to be sampled (or sent) at a very specific bit rate.

If an interrupt fires when sending or receiving data, the critical timing required is corrupted and the routine will fail. It's the same for other asynchronous software based bit-banged routines. You should therefore:

(a) Consider using hardware based 232 with interrupts
(b) Disable your ISR before sending or receiving data using asynchronous software based comminication routines, such as those found in modules like SUART, One Wire (OW) etc...

Doj · Post by **Doj** » Sat Apr 21, 2007 9:58 am

Octal, I have a PCB that uses 9 software serial ports to communicate on board(written in PDS as it happens) and the answer David gives holds true for PDS also, I just disable the interrupt before sending/receiving and enable it when finished, works perfectly for me.
In order not to loose characters I have a "handshake pin" from each slave to make the main routine know that data is available and that it needs to stop the interrupt and look at the serial ports.
I find this totally reliable and you can run at high speed without losing data.

octal · Post by **octal** » Sat Apr 21, 2007 10:21 am

Ok. Thank you for your answer.
This is what I have done :

T1CON = 0
UART.Write(value,b,13)
T1CON = 1

It's not problematic for me to stop the timer because it's just for debug purpose and the Timer is used only for updating Status Leds. Updating leds is not mandatory for me when debugging since I send the state information with the USART. But i'm managing to change a bit the pcb (and design) to free up the RB1/RB4 pins to use hardware USART. It will be better for final release.

I personnaly think that this kind of problems can be avoided if we add/had a info section in the header of each module (or in WIKI

) that gives explicitely the harware resources used by the module.

Best regards
Octal

David Barker · Post by **David Barker** » Sat Apr 21, 2007 11:07 am

> I personnaly think that this kind of problems can be avoided if
> we add/had a info section in the header of each module (or in
> WIKI Wink ) that gives explicitely the harware resources used
> by the module.

I'm not sure what you mean - the SUART module does not use any peripheral hardware resources.

octal · Post by **octal** » Sat Apr 21, 2007 11:32 am

David Barker wrote:>
I'm not sure what you mean - the SUART module does not use any peripheral hardware resources.

Hi David,
Do not be hurted, it's just a proposition. I was not meaning the SUSART module, but the Timer Module. Instead of having to analyse the timer module source code (and other modules that we may use) it could be nice to have a little doc saying :
Timer module:
USES : Timer1, Interrupt .....

SPI module :
USES : SPI, TIMERnnn, ...

KEyboard Module:
USES : xxxx hardware, xxxx SoftResource .....

From a doc like this, even before choosing to use any module we can directly see for example that KeybModule relays on Timer1, that SPI uses Timer3 (for example) ....
this can be very helpful to let us choose witch modules have to be reworked to avoid conflict and will be very time-saving help.

Best regards
Octal

TimB · Post by **TimB** » Sat Apr 21, 2007 11:47 am

You would find a pretty empty wiki section

I can think of only 3 modules that use interrupts and they all have interrupt in there title.

Usart = Usart

SPI = MSSP

err any more?

xor · Post by **xor** » Sat Apr 21, 2007 12:34 pm

I wrote a simple SUSART for a P12 that implemented the edge-interrupt pin for RX. It's an excellent method for doing software UART and could be implemented easily enough with the PORTB interrupts.