value of RS232_ERRORS with SW UART

[mgasperi]

When using a software RS232 port, according to the manual, the value of RS232_ERROR will be a 0 if there is a timeout on a getc(). It appears to have the value 0x40 for a normal character, but I can't find any explanation for this value. That bit in the RCSTA register doesn't have anything to do with normal reception. Does anyone know the values RS232_ERROR takes for various conditions with a SW UART?

[Ttelmah]

It doesn't.
The software UART, doesn't really 'have' any error checking.
There is no parity testing.
It can't overrun, since there is no buffering.
RS232_ERRORS only applies to hardware UARTs.

Best Wishes

[Ttelmah]

As a comment, re-read the manual on this. It tells you there, that for the software UART, it's only functions, are to hold/get bit 9 for 9bit modes, and to indicate the 'float_high' succeeded, or for a timeout, if this is enabled. No 'error' handling as such.
Their implementation is poor, since you would have to set RS232_ERRORS yourself to a non zero value, otherwise zero is a perfectly legitimate response when data _has_ arrived...
In fact, if I wanted a timeout, I'd actually base it on the timed_getc function, rather than using CCS's code.

Best Wishes

[Guest]

Is the implementation of the CCS SW UART available? Experimentally it appears that the "normal" received character value of RS232_ERRORS is 0x40 if you have a TIMEOUT sepecified in the USE RS232. You only get 0x00 if there actually was a timeout. This would be nice if you could depend on it and it wasn't just an undocumented feature or side effect.

[RayJones]

I once examined the listing for the code used for SW UART operation.
You should be able to do the same if you examine the code generated for putc and getc.
Yes, it will not be immediately obvious.

I do recall that there were bits used within a control variable, and they probably did end up as you suggest.

Having said that, using the CCS SW UART really is a desparation move.
It is highly simplistic, and spends 100% of the time sitting and waiting for a serial word to come in once started. Likewise upon tx.

If you need to interface with a real serial interface, you will eventually have problems keeping up.

I needed a FULL DUPLEX passthrough operation, forwarding characters rx'd on the SW UART onto the HW UART, likewise rx HW UART -> SW UART tx.

I ended up designing a timer ISR driven SW UART which still allows useful operations to be performed during the typical 1ms of a 9600 serial word.

This is impossible with the standard SW UART as it would take 2 character intervals to receive 1 character and send 1 character over the SW UART.

Ray