software uart on 115200 baud

[overmindx]

hi,
I am using an pic18f67k22 mcu on 16 MHz clock speed. I have a sensor that operates on 115200 baud. When i connect to it using hardware uart, i can communicate to it perfectly. However when i connect to it using the software uart pins, it doesn't reply. Now, my question is, is this a limitation of the software uart capability or there is a way to tweak it on the firmware code. Thanks..

[temtronic]

timing is 'everything' and SW UARTS are 'slow' and need to poll/time every bit that comes in.That's one reason why HW UARTS are far superior.Also they provide an interrupt for even faster performance.
IF you are fixed with that PIC, use the HW UART for the sensor.Assuming the PIC needs to talk to a PC or other serial device you might use the SW UART for that,esp. if 9600 baud or less.
These days I use the 18F46K22 for the 2 HW UARTS in it but other possible options include..
1) adding an I2C UART.....more pins and code....
2) tie serial to INT pin...works but need the I/O pin and code
3) replace PIC with one with 2 HW UARTS...layout/cost issues?

hth
jay

[Ttelmah]

Agree wholeheartedly. Timing is _everything_.

The software UART should be able to 'handle' 115200bps (I have used 50000bps at 4MHz),, but you have to understand that the software UART is half duplex only, and that the receive code needs to actually be sitting 'waiting' to receive. This latter is almost certainly where the problem lies. There is no margin. The hardware UART will start receiving automatically when the falling edge is seen. The software UART has to be in the getc, waiting for this edge to arrive. With low baud rates relative to the CPU clock rate there is just enough time for something like an interrupt to be used to trigger the getc, but at 115200bps, at 4mips there are only 34.7 instructions per bit. The receive code needs to be actually starting to sample _before_ the middle of the bit, so the time needed to get into an ISR, rules this out, and rules out doing anything much in the code, except sitting waiting for the character to arrive.

You need to think of changing to a chip with a second hardware UART, or operating at a lower baud rate, or designing the code so you know exactly when the reply is to start.

[asmallri]

[Ttelmah]

I have done timer based software full duplex UART's. 115200bps, I'd say is 'pushing' this even at 64MHz, but it does depend on what else the chip is doing. It might just about be possible, but requires careful programming. Into the 'you need to actually fully understand the chip' area, rather than basic programming.....

[asmallri]

[Ttelmah]

Absolutely.

I suspect you used tricks like 'byte syncing', so that the transmitted channels were all transmitting at the same time. This makes it not that much harder to transmit multiple channels than one. However 'pushing to limit' begins to apply...