TLL & Serial Coms...
teganburns
Posts: 134
I have a Wifi module and i want to understand what exactly I'm dealing with. The module is Uart to wifi. (link--> http://www.thaieasyelec.net/index.php/Wireless/Wifi/TTL-UART-to-WiFi-Linksprite/p_184.html)
and i have this (link-->http://www.4dsystems.com.au/downloads//micro-USB/uUSB-MB5/Docs/Pdf/uUSB-MB5_DataSheet_rev1.pdf)
usb to Rs-232 module.
I have done research on the internet and think i understand some things, like UART, but i continue to read and get the concepts mixed up.
Is there any one who can give a quick summary on TLL, Rs-232, Serial, and UART please?
Thanks!
and i have this (link-->http://www.4dsystems.com.au/downloads//micro-USB/uUSB-MB5/Docs/Pdf/uUSB-MB5_DataSheet_rev1.pdf)
usb to Rs-232 module.
I have done research on the internet and think i understand some things, like UART, but i continue to read and get the concepts mixed up.
Is there any one who can give a quick summary on TLL, Rs-232, Serial, and UART please?
Thanks!
Comments
Serial may refer to a variety of communication protocols where bits are sent out one at a time. Parallel refers to the "opposite" where several bits are sent out simultaneously, usually with a clock for synchronization. A serial protocol may be clocked or self-clocking or what is known as asynchronous. Usually when people say serial, they refer to asynchronous serial. Read the Wikipedia article for details. A UART (Universal Asynchronous Receiver Transmitter) is just a device that takes data, usually in the form of 8-bit bytes, and transmits or receives those bytes (or portions of them) in asynchronous serial format. Again, consult the Wikipedia for details.
On the other hand, the true RS232 has a specification that voltages can swing +12/-12.
AND, True RS232 inverts the TTL through a level shifting device (either a chip or a few transistors).
~~~~~~~~~~~~
So there are two issues when using a USB to RS232 converter with a Propeller.
[a] The logic is inverted
Depending on what that USB to RS232 delivers, you can actually drive a Propeller pin negative and damage the i/o
~~~~~~~~~~~~
To make things more weird, Parallax and others do provide USB to TTL converters that only go as high as 3.3v so as to protect the Propeller i/o. Some USB to TTL may actually drive a true +5 volts and be too high for the Propeller i/o in a direct connection.
~~~~~~~~~~~~~
What to do?
[a] For inverted logic, the Propeller code can actually be inverted -- but TTL to TTL doesn't require this.
Check your USB to RS232 or your USB to TTL device to confirm that it does not exceed the range from 3.3V to 0V or buy one from Parallax with documents that say it is safe.
[c] Buy a Parallax board that specifically offers a lifetime guarantee and forget about all the technical stuff.
~~~~~~~~~~
In general, 5V to 0V TTL from your Wifi can interface with the Propeller with one 3.3K resistor.
The +5V from the Wifi unit would require a 3.3k resistor to protect the Propeller which is receiving. The 3.3V from the Propeller can be wired direct as it won't hurt anything.
Since both are inverted from true RS232, the two inversions cancel each other. Don't worry about the inversions.
~~~~
You can go from TTL to RS232, then from RS232 back to TTL, but if the project fits on one bench with short wires... that is rather silly... a lot of extra wiring and hardware.
~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~
BTW, the wireless module you provided a link to appears to be powered by 3.3v. So I suspect that you just have to connect it directly to the Propeller without any resistors.
As you can see, people, and especially in Asian languages, tend to use specs and terms that they don't fully understand. TTL should only be +5 to 0, but we have a lot of people translating without a rigorous background.
I had connected a TLL Cam that i had and it worked...
Because the Wi-fi module came with some computer test software
"RS232" and "TTL" are the same signal. Just different voltages. RS232 is good for long cables like hundreds of metres, or if the cable might get shorted or connected the wrong way. For things close to each other, ie in a box or on your bench, TTL works just fine.
Are you going to be using a Propeller chip or some other chip?
If you use the propeller chip, the voltage inversion problem Loopy mentions is not a problem because you can correct that in software. You can also set the baud rate in software. So the Propeller makes it all very easy to interface to these sorts of modules.
BTW nice module. These wifi to serial modules are the key to the "internet of things". But they are going to have to come down a long way in price from $49. Hopefully in the next few years we will see these for one or two dollars.
Well ......... -3V is NOT safe for the Propeller i/o. Don't go below 0 volts.
The real problem is that a lot of vendors are not really aware of what they are advertising. Maybe the device outputs +3.3v to 0 with a UART that conforms to RS232 timing. That will work with a lot of RS232 interfaces that expect something from +12/-12.
The problem is that a lot of vendors are not really aware of what they are advertising. Maybe the device outputs +3.3v to 0 with a UART that conforms to RS232 timing.
Manufacturers save quite a bit of money by NOT providing the -3.3v or -12v or whatever -V. That negative voltage requires a dual supply setup.
But without testing the actual, you are not going to know for sure.
"RS232" and "TTL" are NOT the same... they are inverted!
[a] TTL levels never have a negative voltage and IC i/o is generally damaged when you go below 0. Where as true RS232 hardware is supposed to provide a negative voltage.
UARTs and USARTs are silicon devices that provide RS232 timing and buffers, but you don't have to have a UART or USART to send or receive RS232 serial.
[c] To fully meet the RS232 communications, devices normally have two devices - a UART or a uP that emulates a UART and outputs a logic level between 0 and whatever, and a Driver chip (called a level shifter) that inverts the signal and adds a negative voltage.
~~~~~~~~~
Everything has gotten very sloppy in how we communicated what RS232 really is. And in the hobby market, people often use the wrong terms or often repeat the wrong advice. In the global internet, users in Asian languages often never understand what abbreviations are truly indicating. And industry documents are now migrating from TTL to Low Voltage TTL.
There are just too many players to ever get this cleared up through declaring a new standard of terminology. IT will just have to be told and retold as a support issue.
++++++++++++++++++
Historically, RS232 has been around since the use of teletype machines that were placed in banks and hotels around the world. It eventually migrated to dumb terminals and serial printers.
Where as TTL originated as a standard of 5volt logic chips that used transistors. The newer logic is using CMOS and lower voltages. So misnomers keep arising as newcomers don't know much about the history of electronics.
Connectors is a whole separate issue as the fundamental communications is Rx, Tx, and Ground (3 wires) with two flow control wires added in cases where older equipment had to ask for the faster device to wait or needed to tell the other device that it was ready.
Without understanding the history, one doesn't properly understand the muddle. The problems are all about attaching older legacy devices to the most modern new devices.
~~~~~~~~~~~~~~~~~~
Furthermore, TTL hardware drivers, RS232 hardware drivers, RS422 hardware drivers, and hardware RS485 drivers all can use the same forms of serial as provided by a UART or USART or uP.
You can easily and safely
TTL to TTL
3.3 logic to 3.3 logic
RS232 to RS232
RS422 to RS422
RS485 to RS485.
Not quite accurate. Early teletypes used 20mA current loop (20mA current or no current) for ones and zeroes. They did use the asynchronous data protocol (one start bit, 5 to 8 data bits, odd/even or no parity bit, and one or two stop bits. Early data rates were very low (110baud and I think there was a slower rate of 60baud) because the positioning of the print drum was done mechanically from a solenoid driven by the 20mA current loop. The model 23 and 33 teletypes were amazing works of mechanical precision and ingenuity.
RS232 came later and used the same asynchronous data protocol. IIRC the initial version for RS232 allowed for voltages as high as +- 24V. The RS232-C spec was +-12V.
RS232 resting volts are usually something like minus 12V, and an active pulse is plus 12V. So there is inversion plus voltage translation. Or you can cheat and just go to ebay and buy a RS232 to TTL converter for $3.70 including shipping http://www.ebay.com.au/itm/MAX232-RS232-To-TTL-Converter-Adapt-er-Module-Board-/260781677532?pt=AU_B_I_Electrical_Test_Equipment&hash=item3cb7cc9bdc which I think is cheaper than a board plus D9 socket plus max232.
and erco will probably get that even cheaper
It is true that TTL has fewer (or no) standards, however the situation is much simpler than it was in the early days of RS232. Between the variety of connectors being used and the variation in signal pinouts it was a bit of a nightmare. Add to that the various control signals (DTR, DCD, DSR, RI, RTS, CTS, TxD, RxD), the secondary signals, STD, SRD, SRTS, SCTS, SDCD), and the data variations (baud rate, number of data bits, parity, stop bits) getting two pieces of equipment to talk to each other could be a major undertaking.
To make life simpler I made adapters that went from whatever connector and pinout was on the equipment to a DB9 with a fixed pinout. Pins 1 to 4 were always inputs, Pin 5 was ground, and pins 6 to 9 were outputs. Pin 4 was always Rx and pin 6 was always Tx. The other pins were used for whatever signals were necessary for the equipment to operate.
Trust me, whatever problems we have with serial connections now is nowhere near what there was with early RS232 connections.
Now i am working on writing a program so the propeller can be networked. (This will open up a world of amazing tech fun!!)
but i was wondering if there any simple way to add in hex from 80 to 8f? The prop chip needs to be able to address each packet differently each time it is sent .
The thing is you need to somehow indicate this is numeric data and not ASCII. So what ever is on the receiving end needs to either know how to trap a header with this data, or have a filter in software that will toggle one of the more obscure unused ASCII characters or a sequence of ASCII characters to be interpreted as your choice of hex or decimal number.
Something like a ESC h for hex and ESC d for decimal and ESC a for ASCII would do well.