I've never seen them. Can you name a couple?
No argument from me. For me, I will either do RS232 right
or not at all.
Parallax Stamps can bit-bang serial data in both inverted and
non-inverted mode. The Parallax Javelin can do the same. The
OOPIC can also do both inverted and non-inverted. The OOPIC
also allow you to hook up to the on-board hardware UART, and
that is non-inverted (of course!) I suspect that the BSX24
and ATOM can do both as well.
One of my close friends has used the Parallax Basic Stamp in
bunch of robots and he has talked with many modules using
serial protocol and never had to use Stamp's the ability
to invert the data.
The serial communication protocols evolved over time and they
can be quite confusing. For example, why did the RS232 folks choose
-12V for "1" and not +12V? They did and we've had to live with
the confusion ever since.
At least Bob asked for feedback and he has been willing to *listen*
to the feedback. No complaints from me on that aspect. Hopefully,
some other people are reading this thread and it is helping them
understand serial communication protocols a little better.
Agreed. Added though, RS232A limited maximum excursions to +25 and -25
as well.RS232C limited maximum excursions to +15 and -15 as well.
But yes, I agree, fr RS-232, a -3V (to something depending on spec of
choice) is a logical "1".
I disagree. It is not a buffer, per sa. And I will even say it is not an
inverting buffer or a non-inverting buffer, both of which terms are
used. For proof I offer the 74HC240, which you will find is classified
as an octal Buffer / line driver; 3-state inverting.
as opposed to say at 74HC244, which you will find is classified as an
octal buffer / line driver; 3-state (non-inverting).
A MAX232 is a level shifter. And I would also argue it is an inverting
level shifter. I do so based on manufacturer's data sheets.
While I can see your point, something with a logical 1 where it should
be might not be inverted, I think you are focusing on final
interpretation of the signal, and ignoring the view point of the driver
which has no preset knowlege of what is a 0 or a 1 and only does the
level shifting. Well, we could get into relativity theory, because
something cannot be inverted by itself, but must be inverted relative to
something else. Therefore RS-232 is not inverted compared to RS-232. It
is however inverted compared to TTL synchronous serial, and vice versa.
I think the bubble is correct, and possibly this argument might change
your position and "hypocracy" back to orthodoxy.
Here's looking into the link to the MAX drivers of the last post.
The typical driver output voltage swing is ±8V whenloaded with a nominal
5k? RS-232 receiver and VCC = +5V. Output swing is guaranteed to meet
the EIA/TIA-232E and V.28 specification, which calls for ±5V minimum
driver output levels under worst-case conditions. These include a
minimum 3k? load, VCC = +4.5V, and maximum operating temperature.
Unloaded driver output voltage ranges from (V+ -1.3V) to (V- +0.5V).
Input thresholds are both TTL and CMOS compatible. The inputs of unused
drivers can be left unconnected since 400k? input pull-up resistors to
VCC are built in (except for the MAX220). The pull-up resistors force
the outputs of unused drivers low because all drivers invert.
Now what about the receivers.
EIA/TIA-232E and V.28 specifications define a voltage level greater than
3V as a logic 0, so all receivers invert.
I think it is important to remember it would be possible to make a
non-inverting chip that shifted to the same (if opposite) levels. I
don't know of any, but it would be possible. So the one made for RS-232
conversion is the inverting one (electrically, not logically), and
should remain being called one, just as the manufacturer does, and the
schematics show (bubble on output).
There are inverting buffers and non-inverting buffers.
When the term "buffer" is used without the preceeding
word "inverting" or "non-inverting", it means "non-inverting".
My sentence would have been clearer if I had written
"... it is technically a non-inverting buffer, not an
Nope. I'm not buying into your argument.
Is RS-485 inverted? How about current-loop? How about CAN?
FSK (Frequency Shift Keying)? What matters is that I shove a
"1" (5V) or "0" (0V) into the driver and the corresponding
receiver returns the same "1" or "0". I should be able to make
an entire matrix of drivers and receivers that convert between
0-5V, RS232, RS245, CAN, current loop, etc. I can chain them all
together in whatever sequence I want (e.g. 0-5V => RS2323 =>
current_loop => RS285 => CAN => 0-5V) and when I shove a "1"
in front of the chain, a "1" comes out the back. If I shove
a "1" in one end and a "0" comes out the other end, somebody
has inverted the data.
[snip lots of text]
In the end, I'm still a hypocrite, since I shove a "1" (5V) into
the MAX232 and it spits out a valid RS-232 "1" (-12V). No
inversion of the data has occured. I still have bubbles on
my MAX232, primarily because the spec. sheets have bubbles.
They really do not belong there.
Well, a series at least. The DSP56xxx in our 'Pod's line of micros have
a POL polarity bit. From the DSP56F801-7UM.pdf manual:
188.8.131.52 Polarity (POL)-Bit 10
This bit determines whether to invert the data as it goes from the
transmitter to the TXD pin and
from the RXD pin to the receiver. All bits, START, DATA, and STOP, are
inverted as they leave
the Transmit Shift register and before they enter the Receive Shift
. 0 = Doesn't invert transmit and receive data bits (Normal mode)
. 1 = Invert transmit and receive data bits (Inverted mode)
Note: It is recommended the POL bit be toggled only when both TE and RE
Think MCORE might have had this feature too, but not sure. Just have the
sense this isn't the only micro I've seen it on. Again, not sure.
Wayne, you can add AVRs using the Bascom compiler to the list that support
inverted and non-inverted. The problem comes with the hardware UART - the
MCUs I've used don't have the option of changing the polarity of the serial
Agreed, Bob is reaching out to a large audience to get feedback. Let's not
hammer him too hard in the process :-)
I've ordered a pair (they haven't arrived yet) - I'm intending to
connect them directly to my PIC's USART pin(s), since the +/-5V
obviously works perfectly for this.
Question: Will the 'R' be decoded as decimal 82 (= 0x52 = 0b01010010) or
the inverse 173 (=0xAD = 0b10101101)?
I don't really care which it is - experimentation will tell me, and it's
easy to invert the byte received before using it, but it's always nice
to get the code right first time :)
My 2c on the datasheet thing - Personally, I think that a statement that
"0=0V, 1=5V" (or vice versa - which ever is correct, obviously) would be
much simpler for everybody. It's unambiguous, and that means that
nobody can get upset.
To propose an alternative for the ds:
"TX - Delivers asynchronous serial with 0 bit = 0V, 1 bit = 5V. The
output is an ASCII capital "R", followed by three ASCII character digits
representing the range in inches up to a maximum of 255, followed by a
carriage return (ASCII 13).
Note: Although the voltage of 0-5 V is outside the RS232 standard, most
RS232 devices have sufficient margin to read 0-5V serial data. If
standard voltage level RS232 is desired, invert, and connect an RS232
converter such as a MAX232."
This separates what the MaxSonar produces from the way to make it into a
"real" RS232-compatible signal, and I think avoids all the confusion...
Or at least not any I can remember.
I think I've got a pretty good idea why RS-232 is "inverted" (by my
understanding of it being inverted at least). The normal amplification
mode of a transistor in common emitter inverts the signal. Almost always
with single sided drivers, in order to use the least transistors
possible, you would use an inverter. It takes less transistors to make
an inverter than a non-inverting buffer. Back in the day, transistors
cost like processors do today. And another reason to use an inverter
instead of a buffer, with less stages, its faster. So to make the most
economical, fastest, line driver then, you used one stage of inversion
in the driver, and another stage of inversion in the receiver.
This is also the reason 7400 NANDs, 7402's NOR's and 7404's inverters
were the low number (first) 7400 series gates made. Simpler and faster
than AND's OR's or Buffers.
Same here. If you want to be able to hook up to a microcontroller
UART, the safe choice is always to use non-inverted signalling.
'nuf said on that topic.
You walk into your final exam for digital 101 and it provides the
Value CMOS RS232C
"1" 5V -12V
"0" 0V +12V
Now design a circuit that converts a CMOS signal into an RS232C
signal and another circuit that converts an RS232 signal into
a CMOS signal.
My solution to this problem would be to use a MAX232 chip.
If you want to call it an inverter, I guess I really do not
care, but given that a "1" on one side produces a "1" on the
other side, I do not call it an inverter. We may have to
agree to disagree on this one.
It is way past my bed time. I'm going to give the topic a rest.
Micro hardware to Micro hardware - logic unchanged.
Micro hardware to PC via a level shifter - logic unchanged.
Micro hardware to PC via current limiting resistors - logic inverted.
With a basic stamp you need to use 'inverted' mode if you don't
use a level shifter.
They only reference that I am aware that uses 'inverted' is the ISO
7816 smart card standard which uses 'regular convention' and 'inverse
convention' reflecting the above.
Note that many people have *very* different ideas about what Bob
has been saying.
I will note that while he has the choice of what he wants to sell,
we have the choice of what to buy.
If I find that I can't access this via standard TTL-level asynchronous
serial, I may not buy a second one. If I want to access a component
like this from my PC, I will use a level-shifter.
If this can be changed by a firmware upgrade, I would go for it.
D. Jay Newman
Here's an excerpt from a post I made a couple of weeks ago, right after
receiving and playing with a couple of these units:
My experience with the device is that it works very well, is stable, low
power, and inexpensive. The *only* niggle I have with it is the serial
output. For most of my applications, I'll just bit-bang the serial
reception anyway, so it's not a big deal - most of the time...
"I prefer heaven for climate, hell for company."
Actually, it almost certainly won't work perfectly, precisely because of the
reasons pounded into the ground in the preceeding discussions.
Your PIC's USART, just like my 8051's UART, expects the idle signal to be a
+5V TTL level (I would say "1", but I don't want to reawaken Wayne's ire),
with "true" data bits at 0V TTL level ("0" to me...) and "false" data bits
at 5V TTL also. The MaxSonar-EZ1's output is exactly the inverse of this.
Since the USART depends upon the logically "true" start bit to begin its
asynchronous reception, it will always be seeing what's known as a break
condition, and won't be able to synchronize on the beginning of each
character frame. Were the output inverted, as many posters have requested,
then it would work fine. However, "out-of-spec" pseudo-RS232 direct
connection to a standard PC serial port would then not work, for the same
Of course, if you're bit-banging the reception with code, then it really
"I prefer heaven for climate, hell for company."
I do bit bang with the PIC. It may seem trivial for a hobbyist to
change the serial output but this is not a hobby operation. One thing
to remember is that I live in AZ and the product is built in MN. Labor
costs are low in MN. The production test fixtures are in MN.
Distributors are already selling this product and it is doing very
well. Right now changing this product would be costly for me and for
this operation. To think other wise is to not understand business.
Currently I do not believe that this product will get changed. There
have been 2100 started. All of the 1st 1000 have been programmed and
100s shipped in less than one month! The product has been very well
received indeed, because the actual press release has not been done
yet! Another 1000 are being planned for RoSH compliance. Product
success means a great deal. These are the real votes. Changing the
product right now really does not make good sense. People have been
using this product and they like it.
There are three interfaces to this product right now. Choose the one
you like best.
I am working to get a datasheet that is technically accurate.
Your inputs (and everyone else the participated) will really help us
when we do the next datasheet update (the next datasheet update is
scheduled for mid February).
We at Maxbotix would like to thank everyone that contributed to this
discussion. We would like to do so in a tangible way (by sending you a
gift). I have emailed everyone that contributed, but when I tried to
email you, the email bounced. Please email me at bob@max ....
remove this area (spam)... botix.com and I will let you know the