Sending value 0 with RS232

[Frizie]

To send some error messages between 2 PIC's I have a RS232 connection.
I am sending 16 bits between the PICs and each bit represents an error.
For example, if bit ErrorMess.0 is HIGH, then the fan is not running.
The PIC sends WORD 'ErrorMess' to the other PIC if it has undergone a value change (ie. a bit has changed level).

The problem is, if there is no error at all, then all the bits are LOW, so the value 0 is sent.
However, the PIC on the receiving side does not see that value 0 has been sent.
Is it correct that this means that there must always be at least 1 bit HIGH?

I've never noticed this before.
This would mean that (in case of BYTE transmission) only 1...255 can be send and not 0...255.

By the way, I use the software variant SEROUT, if this makes any difference at all.

Frizie.

[trastikata]

With TTL levels a single 0 byte will be a problem. Because it is asynchronous transmission, a single null byte would appear as idle line unless you make some synchronization before that.

- if timing allows it, you can use a preamble byte to sync the PICs - effectively adding a byte
- or another simple solution is software Manchester encoding to allow for bit transitions, thus doubling the data to 4 bytes.
- or third option is to use line transition and predetermined delay to sync the transmission

There are probably other options but at the moment that comes to mind.

[Frizie]

Thanks trastikata.

No problem for me for the moment, I can make one bit continue HIGH, I have some spare bits.
I was just curious, as I wrote: I've never noticed this before.

Regards,
Frizie.

[Giuseppe MPO]

It is not true, even using TTL levels, in addition to the 8 bits transmitted
there is the start bit and the stop bit, any value 0-255 can be transmitted

[charliecoutas]

I agree, I send zero bytes over USART's all the time, no problem.

[Giuseppe MPO]

This is 0x00


This is 0xFF

[top204]

As has been correctly stated, a zero can be transmitted and received because each transmission of an 8-bit value actually sends 10-bits: Start, Data, Stop. So the data between the start and stop bits does not matter because it is based upon timing, not actual pulses, so no pulse at a certain time in the data mean a zero bit.

However, make sure you have a pull-up or pull-down resistor on the receiving line, otherwise, not all highs and lows will be detected, especially the start pulse. I've found a resistor of approx 100K to 180K is sufficinet to keep the RX line from floating and allow much better coms between async serial devices, and does not put too much of a load on the lines.

It is always recommended to send a sync value, of some kind, before the data, so that the receiver can adjust any circuitry it has. i.e. Data slicer etc... Recommended sync values are $55 or $AA, because $55 is binary %01010101 and $AA is binary %10101010, and each value has the same ampunt of bits spaced equally.

[trastikata]

Ouf, completely forgot about start and stop bits    , my apologies and thank you for reminding me.

[Frizie]

Besides that also I (stupid Flanders ehh Frizie ) had completely forgotten the start and stop bits, I still couldn't send the value 0 from one PIC to another.

BUT: I have found the cause in my specific case.
I only have 2 UARTs on my PIC (1 for a Nextion HMI and 1 for a Siemens PLC), but I actually need 3 (for connection to a 2nd PIC), so the 3rd connection is a normal port (PORTB.1).

If the 2nd PIC has an error message, it passes it on to the 1st PIC via 16 bits (WORD 'ErrorMess'), where each bit representing an error.
If there is no error, a 0 will be sent, but sending a 0 does not work.

Because there is no UART input here, I use interrupt INT1 on this port.
But if a 0 is sent, the interrupt is not triggered (yes, maybe on the stop bit, but then it's too late).
If I leave bit 15 of WORD 'ErrorMess' constantly HIGH, it always goes well.
(not tried (yet), but maybe making bit 0 of the WORD constantly HIGH is even better?).

What I'm curious about:
Is there a start bit here?
The Positron manual does not mention about a start bit at HRSOUT / HSEROUT / SEROUT, only about a stop bit is mentioned.
Otherwise, shouldn't the interrupt be triggered on the start bit?   

Frizie 

[top204]

Hello Frizie, and many thanks my friend.

The interrupt is fired when a byte is received and the interrupt flag is set, so it will not fire with the start bit alone.

For that type of mechanism, you will need to set the pin as an IOC (Interrupt On Change), then that alone triggers the interrupt for the rest of the byte to be received. However, you will miss the start bit because it was used to fire the interrupt, so the first byte of the data will be missed.

That is why there should always be pre-sync values sent before the data itself. This gives the receiver time to sort itself out and receive the actual data once the sync values have been sent.

It's the same when waking a device from sleep using a USART. The first byte received will wake the device, but the data will not be received, so I always send a sync byte to wake a device up, then send the data.

For reliable coms, either create an AT+ type interface, or a packet type interface, so there is a sync or identifier at the beginning, and the data itself can be verified. That is the reason ethernet and other serial data coms are actually quite bulky and slow, because of the testing they have to do, and if possible, error correcting etc...

Never send a single byte on its own, because it will not always get there, unless the receiver is constantly waiting for data with very litle between the waits.

[Frizie]

Thanks Les, I'll try this weekend.

Love Positron , the best Basic compiler for PIC microcontrollers.