How to learn serial Communication - hand-On approach 2

[tektips2006]

I have an ME degree, and I am working in the automation inudstry. Often I find myself trying to solve networking problems, mostly serial communications (RS232, RS485). This is where I realize that I lack the in-depth understanding of the subject.
Although it is not the primary focus of my job, I am at the point where I want to get better at understanding the subject. This will help me advance my career. I took many COE courese at college to bridge the gap, including Digital design, Digital electronics, microprocessor deisgn. And I did very well, getting all A's, but there was no lab work.

I envision myself working at home with some sort of a kit (or simulator?)that I can manipulate, that would teach me the concepts of serial comm (reading a book by itself is almost fruitless). I looked at a kit from parallax.com, but I am not sure if this is the way to go.
I wasn't sure if this is the right Site/forum to post this, but I appreciate any advice. Thanks

 

[edfair]

I would suggest getting two older computers that have ATIO cards (486 or below), IDEIO cards with the IDE crippled, or if you are in luck, serial I/O cards. You get access to the control registers and can manipulate how things are told to work. MSDOS and GWBASIC will allow you prod around in the chip and having another machine to communicate with will give you feedback to your correct communications settings.

Get the 232 working first, then worry about the rest.

B&B Electronics or BlackBox have some white pages that may be of assistance.

Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[gbaughma]

Serial communications is pretty simple. I have written applications (albeit years ago) which worked with an automated motor testing system. The computer would communicate serially with a Himmelstein test rig; the test rig would read information like torque, RPM, temperature, and so forth, and give a constant stream of information.

If you're wanting to just communicate with an automation system, you may want to learn some basics by using a comm program such as NetTerm or Telix, just so you can "talk" with the system.

If you're wanting to write your own comm program, you need to start with the above step first, so you can understand how the other unit is communicating, what to look for, what commands it will accept, and so forth.

I remember doing just that with the Himmelstein unit... I used a modem communications program and captured the output from the unit itself, then decoded what was happening, to incorporate into my automation program.

Now, if you're wanting to understand serial communications in general, let me know and I'll give you the quick 5-minute rundown. I can explain stuff like 7- or 8-bit, parity, and flow control. Pretty straight-forward stuff.



Just my 2¢
-Cole's Law: Shredded cabbage

--Greg

http://parallel.tzo.com

 

[lespaul]

I'd be interested in your 5-minute rundown, even if the OP isn't.....

Leslie

In an open world there's no need for windows and gates

http://www.ubuntu.com

 

[gbaughma]

Well, if you think of parallel communications like a multi-lane highway, with multiple cars arriving at the same time, then serial communication is like a one-lane road.

The bits, represented by the power either being ON or OFF, come in at a preset rate (the baud rate). The higher the baud rate, the faster the power is flipped on and off.

So, if you take one byte of information, represented by 8 bits, say 11011100, they would arrive one bit at a time. Sounds pretty simple, however there's no "marker" in case something goes wrong; the computer doesn't know where the information starts and stops. And there's no error checking.

SO... in comes parity and stop bits. Parity can be none, even or odd. It's simple, really. If you have 10111100 that has 5 1's and 3 0's. So, even parity would be a 1 (making it an even number of 1's), and odd parity would be a 0 (making it an odd number of 1's). Then, stop bits. Either 1 or 2, usually 1 if you have 8-bit communication.

So.... the byte 10111100 with even parity, 1 stop bit would come across as 1011110011 (a total of 10 bits). This is why you can pretty much take your modem connect speed, and divide by 10 to figure out the number of bytes per second.

So, on to flow control.

There are two types of flow control, software and hardware. Software flow control sends back an XON/XOFF (Transmit on, Transmit off) back from the receiving computer to say "Woah... I have enough to chew on... let me catch up). The upside to software flow control is that you only need a total of 3 wires (transmit, receive, and ground) to make it work.

Hardware flow control uses a CST/RTS (Clear to send, request to send) to control the data flow. This is another pair of wires, that when the signal goes "high", it's OK to send more information. When the signal goes "low" (power off), then information is paused.

All of this information is handled by a special chip called the UART (Universal Asynchronous Receiver/Transmitter) which takes the individual bits coming in one at a time, and sorts them one at a time. Imagine cars coming into a parking lot one at a time, each of them taking a parking space from left to right, then all leaving at once. That's what the UART does. (Of course, it also does it in reverse, directing the traffic from the parking spots back out the single-lane exit).

Hope this was informative.



Just my 2¢
-Cole's Law: Shredded cabbage

--Greg

http://parallel.tzo.com

 

[lespaul]

it was very informative, thanks for the run down!

Leslie

 

[tektips2006]

Thank you for the info. Very nice explaination of the thoery. I appreciate that.I need to get a better handle of the hands-on, however.

My immediate goal is to start "playing" with serial comm.
My ultimate goal is to be able to write communication drivers (maybe a long shot!).

Ok. Lets say I am handed an automation system (some sort of a microcontroller connected to external sensors). Now I was told that it's using RS232 (physical layer), but nothing else.

How can interogate the micro-controller to find out first about the baud rate, parity,etc. And once I have that, how can I find out what protocol is it using(modbus, ASCII, ..). And last how do I write drivers to talk to the controller using my PC (on the serial port)? Maybe using C as programming language, or some higher level language like VB?

Thanks

 

[gbaughma]

The baud rate should be in the documentation... however, you can try and figure it out. Connect a computer using a serial port to the unit, open up some comm software, and try different baud rates until you're not getting "gibberish".

I've written comm and automation control programs in QuickBasic (LONG time ago) and also in VisualBasic. It's as simple as opening the com port like you would a file, then either reading from it or printing to it.



Just my 2¢
-Cole's Law: Shredded cabbage

--Greg

http://parallel.tzo.com

 

[tektips2006]

What comm software do you recommend to do the sniffing?. Something like "hyperterminal" maybe?

Also given the fact that you don't know the comm protocol yet, how do you pull data from the controller (if it's only set to respond to requests).
It's like walking toward a stranger, where you don't know what language he is speaking. But you want to get him to say something, hoping that you can desipher the language.

Thanks

 

[edfair]

A scope is useful. You can watch the bit cells change and figure out cell timing. With that you get the baud rate.

When you get to the UART usage you also get to check the data registers to make sure that the tx is empty before giving it another or when receiving you make sure that you really have something there to get. This is at the low level of machine language.

Using hyperterm is one way of communicating with your connected device but the low level stuff is there handling the nitty-gritty handing the data off to your operating system which gives it to hyperterm.

Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[MasterRacker]

To get a handle on what to do from the application side, you could start with a serial comm library like this:

http://tinyurl.com/397v9e

Personally I don't see the need to write a low-level library since it has been done a hundred times. Using a pre-written library allows you to focus on the command structure and protcol of the device you want to communicate with.

_____
Jeff
[small][purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day
"The software I buy sucks, The software I write sucks. It's time to give up and have a beer..." - Me[/small]

 

[gbaughma]

The place to start is really with the documentation. You won't be able to figure out what the automation system is telling you without it.

I have seen all kinds of funky things with automation systems. It could be something like this:

Communications: 2400,N,8,1

(2400 baud, no parity, 8 bits, one stop bit)

... and then have information like:

FORMAT OF INFORMATION:

1 byte SOT CHR(27) ' Escape
3 bytes Temp1 Temperature in degrees F
3 bytes Temp2 Temperature in degrees F
3 bytes RPM RPMs
1 byte EOT CHR(23) ' Ctrl-x

.... so you would read the information from the serial port, then split it apart to get your information.

I know, this is VERY over-simplified.... but sometimes that's how it works.

Others may give you a MSB/LSB output, others give you plain text... the bottom line is, start by reading the manual, set up a comm program (like hyperterminal even) to talk to the box, and start watching the data stream coming from the unit. Then you can best decide how to get that information and process it in your control program.

One automation system that I wrote had to control a couple of power supplies as well. That was fun; one of the power supplies would put out up to 48 volts, with a 5v input voltage. So... 5v output 48 volts, 0v output 0v, and 2.5v output 24v, etc.

I used a D to A converter card in the PC, which gave me I think 4 5v outputs. It was controlled by POKE-ing a memory address... so, poking a 127 into a memory address gave me 2.5 volts out, which in turn went to the power supply, which gave me 24v output from that (at something like 100 amps... it was a *BIG* unit).

So, the program that I wrote had to not only read the input from the test gear through a serial port, it also had to control power supplies to do the experiments and tests. Oh, and for safety issues, there had to be big red "emergency stop" buttons as well.

Hitting one of the buttons would immediatly force an error in the program; the error handler in the program would shut down the power supplies and abort the tests.

(I did it with an error handler because then I knew no matter WHAT a person was doing in the program, no matter what part of the experiment, hitting that button would shut everything down right now).

Fun project. I learned a lot.



Just my 2¢
-Cole's Law: Shredded cabbage

--Greg

http://parallel.tzo.com