UART/USART setting the logic to start at LOW instead of HIGH

Hi,

does anyone know how to set the logic to start at LOW instead of HIGH. I am sending my data with serial.write but the problem is my start bit is a ('0') and my stop bit is ('1') because the logic is a HIGH. I want the logic to be low so my start bit will be ('1') and my stop bit will be ('0'). I would like to know a way in software and if there is none how about hardware?

Thanks

Where are you looking at the signals?
The UART TX output at D1 will sit low, going High to start and then low to finish.
If you are going thru an RS232 converter, it will look inverted.
If you just want to invert the signal, a simple transister can do that.
Drive the base of the transistor high, the collector will go low.
(circuit is shown as something else driving the base while the arduino reads the collector level)

Where are you looking at the signals?
The UART TX output at D1 will sit low, going High to start and then low to finish.

CR: I'm sure you have that backwards. Serial TTL a High = Mark = data bits high = stop bit = idle condition. A LOW = start bit = data bits low.

If OP required inverted TTL serial then he has two choices, add TTL inverters to pins 0 and 1 (74xx04, or two npn transistors wired as inverters) or use software NewSoft Serial library, as I believe it has an optional inverter parameter.

Lefty

I'll have to get a scope out & look - maybe the last device I comm'd with put out TTL levels, and I had to invert to/from it to make things work eventually.
The USART0 section of the datasheet would seem to say I have it backwards too. I know it took me a while figure out why the data that was coming had so many high bits when I was expecting mostly 0s, but it wasn't just inverted because the start bits were off too.

I started out working with asynchronous serial data with the old electro-mechanical Teletype machines in the 60s for the Air Force. One thing has always been consistent for asynchronous serial communications, The 'stop' condition and the data bit true condition are always of the same level. That applies to the old 60ma and 20ma current loops, (true) serial TTL, even RS-232 where a data bit true is a negative voltage and so is the 'stop' (or idle) condition.

Lefty

roadrobber:
does anyone know how to set the logic to start at LOW instead of HIGH. I am sending my data with serial.write but the problem is my start bit is a ('0') and my stop bit is ('1') because the logic is a HIGH. I want the logic to be low so my start bit will be ('1') and my stop bit will be ('0'). I would like to know a way in software and if there is none how about hardware?

I agree with Lefty, serial is always high (1) for idle state (eg. stop bits) and low (0) for a start bit. I doubt you can change that behaviour of the hardware in software (of course, modifying SoftwareSerial would do it).

So either do your "inverted" version of SoftwareSerial or use a logic-inverting gate/op-amp.

Look at page 181 of the Atmega328 spec:

Start bit, always low.
Data bits (0 to 8).
Parity bit. Can be odd or even.
Stop bit, always high.
IDLE No transfers on the communication line (RxDn or TxDn). An IDLE line must be high.

The start bit is the space state and the idle or other part is the Mark state. The Mark is always the undriven state of the line and the space is the driven state. When logic came in the undriven logic state of an input is a logic one.
A fault is said to occur when the line is in the space state for longer than a character time. This is known as being "spaced out". Perhaps it is the origin of the phrase that has such a diffrent meaning today.

This sounds like current-loop or some such. On the Arduino, you could say both states are "driven". The line is driven high or driven low. To say undriven implies high-impedance state, which I doubt the UART is switching to.

But I agree, if the line is in the 0 state for too long that would be a framing error. More particularly, there would be no stop bit where one is expected.

if the line is in the 0 state for too long that would be a framing error

AKA a "break" condition.


Rob

Grumpy_Mike:
The start bit is the space state and the idle or other part is the Mark state. The Mark is always the undriven state of the line and the space is the driven state. When logic came in the undriven logic state of an input is a logic one.
A fault is said to occur when the line is in the space state for longer than a character time. This is known as being "spaced out". Perhaps it is the origin of the phrase that has such a diffrent meaning today.

Well before RS-232 sprung onto the world the old teletype world used simple on/off current loops for the signaling levels using 20ma or 60ma level. The idle (stop) condition was current flowing and start/space/data bit false state was current off. If a line break caused the line to stay at current off, it was also called 'running open' as the teletype would just continuously cycle thinking blank characters were being sent and would never enter the latched up idle state, making a very distinct sound.

Graynomad:

if the line is in the 0 state for too long that would be a framing error

AKA a "break" condition.


Rob

And some UART controllers to this day can detect a 'break' condition, some comm links use that for special signaling applications. Break = any continuous space/start/data bit off level lasting longer then one complete character time at the baudrate defined for the link. A framing error may also be from parity error is parity checking is enabled (but that may very from uart to uart, not sure), or a space condition seen after the proper number of data/parity bits have been received (expecting the stop bit, but it reads as a space bit).

Start bit, always low.
Data bits (0 to 8 ).
Parity bit. Can be odd or even.
Stop bit, always high.
IDLE No transfers on the communication line (RxDn or TxDn). An IDLE line must be high.

I wonder how a comm link set up to use 0 data bits would work out for the users? :wink:
Lefty

0 data bits

0n1, an easy way to generate a square wave at the baud rate /2 :slight_smile:


Rob

retrolefty:
I wonder how a comm link set up to use 0 data bits would work out for the users?

I guess you could still use word timing and breaks to get useful data across it. Does seem silly.

retrolefty:
I wonder how a comm link set up to use 0 data bits would work out for the users? :wink:

Oh yes good point. I just copied and pasted that without paying close attention. :stuck_out_tongue:

According to further on (page 198), you can actually have 5 to 9 data bits.

I suppose the only use for 0 data bits would be to either to successfully transmit no data, or have errors.