Learning to crawl - Newbie question about serial communications

Greetings,

I am contemplating building an idea I have had for some time, and in the
process learn more than just basic electronics. Without going into great
detail at this phase, I would like to implement a serial bus in order to
communicate with multiple receivers each with it's own binary address. I
have been looking at max232, a RS-4XX equivalents, and PIC controllers. I am
overwhelmed and at this point, as each stop just short of what I "think" I
need.

I would like to have a PC send instructions and read responses/status back
from these modules. I can think of many ways to accomplish my goal, but the
serial bus is something I seem to have under-estimated.....as usual.

Any public references, websites, or schematics would be helpful in
understanding how I can implement this concept and possible incorporate it
into my design.

Regards

Doorman352

 

Take a look at the RS-485 protocol instead of RS-232. Other options
might be Microwire (trademark of National Semi, IIRC) or SPI or "three
wire interface"; I2C (trademark Philips) or "two wire interface", or
more specialized protocols like CAN. All of these support multiple drops
better than "regular" RS-232.

Microwire is pretty easy to bit-bang for parts without built-in SPI
ports. You'll need a separate enable line for each remote component.

What kind of data rate are you looking at?

A microcontroller board as "glue" between the PC's standard RS-232 and
whatever multi-drop protocol you implement between the other components.

 

Subject: Learning to crawl - Newbie question about serial communications

A good place to strart is Jan Axelson's Lakeview Research Serial Links web
page...

http://www.lvr.com/serport.htm

The book "Serial Port Complete" by Axelson is a great resource. It starts from
square 1, and it's available from her website, as well as amazon and most of
the hobbyist sources like Jameco, &c. Well worth the price.

Good luck
Chris

 

Rich,
Thank you for your prompt response.

RS-485 does seem to offer the most bang for me. I haven't run accross
any schematics showing a bus scheme, and so I don't know what is
involved..... Any sources?

As for data rates, they aren't critical since the communication won't be
continuos. The thought was to provide RS-232 to X conversion on my board
with X being the "data bus". I keep running into various techniques that use
serial "ports" embedded in chips, but I can't figure out how I would manage
the data stream. One thought was to use a shift register to create a
parallel bus that I could check bit values, as I am using a binary coding
for staus registers..... (K.I.S.S. - Keep it simple stupid).

Do you have any experience working with this interface in embedded
applications?

Doorman352

 

Have a look at the Maxim web site, they have application notes to help
you use their ICs and I'm sure there is information there on RS232,
RS422 and RS485. See:

www.maxim-ic.com

You said in your original post that you want multiple devices, but I
would suggest that you start with a PC and a single device and get that
going first. You can then move on once you are confident that you have
the basics working.

A PC to single PIC is quite easy to do. The PIC has a serial port on it
which outputs logic levels. The shift registers are inside the PIC so
you don't need to add any, but RS232 has some strange voltages so you
need a MAX232 (or something similar) to convert the voltage levels to
something a PC will recognise. If you then get the right baud rate and
data format the PC and PIC should be able to communicate.

For multiple devices the tricky bit is probably ensuring that only one
device is transmitting at any one time and that the devices which are
not transmitting have their outputs set to high impedance. To do this
RS485 drivers will have an Disable pin which you can control from the
PIC. Only one transmitter on the bus must be enabled at any one time.

One way to arrange your bus would be to have the PC as the bus
controller and have the PICs transmit only when the PC asks them to,
That way you can be sure that you wont end up with two devices trying to
talk at once.

The Transmit on the PC would go to the Receive on all the PICs, and
another connection from the Transmit on all the PICs would go to the
Receive on the PC. The PC would transmit a data packet which would
contain an address and instruction. All the PICs would receive this
data packet, but if the address was not theirs they would just ignore
it. If the PIC is to respond to the PC it would Enable its RS485
transmitter, send the data then disable the transmitter as soon as it
had sent the data. The PC would then know that the bus is be clear once
it had received the PIC's response. There should be a time out as well
so that the PC doesn't wait for ever for a response that, for some
reason, doesn't get through.

The RS485 bus will simply be two twisted pairs of wire - one pair for
the PC to transmit to the PICs and one pair for the PICs to respond to
the PC. To convert from RS485 to RS232 to get the data from your bus
into the PC you could just use the RS485 receiver to get to logic levels
then use an RS232 driver to go from logic levels to RS232, and obviously
vice versa to get data from the PC to your bus.

Hope that helps,

Gareth.

--

 

As Gareth mentioned, Maxim has some good app notes. Search their site
with "485" and you'll find lots of info. Also, a Google search for
"introduction 485" has many good hits.

The serial-parallel conversion is in the UART/USART "peripheral" inside
the microcontroller chip. Typically you'd throw a byte at a transmit
register and go away to do other work. When the transmit register is
ready for another byte it asserts an interrupt and/or sets a flag.
Either service the interrupt and send the next byte or periodically poll
the ready bit and respond to it.

My preference is to offload as much of the low level grunt work from the
PC as possible (not least so that things continue to operate if/when
Windows crashes). In this case I'd probably look at running everything
from either an ATmega162 or ATmega64 master. Both have two UARTs and so
could easily be made to speak to a PC out one port and the other
controllers out the other (adding appropriate line drivers/receivers, of
course). Throw on an LCD character display and a small keypad and you
have an autonomous device that can work without a PC but that can send
status & accept commands if the PC is awake.

Long, long ago. All of the multiple-devices-on-a-bus stuff recently has
been SPI/Microwire. SPI is single-ended and runs at logic levels, so it
can be used simply port-to-port for neighboring chips or run (for short
distances) off-board with ordinary (cheap) buffers.

 

A friend of mine just implemented a PC-to-PIC interface with RS232. It
works great. He wrote the PIC code using the CCS C compliler. If you
plan to use the CCS C compiler for your PIC, I'm sure he would be glad
to share the code with you. Let me know.

BRW

 

Hi everybody,

I am wondering which port; serial or parallel will be a good startup
for a beginner like me.

I saw lot of PC interfacing work done by parallel port, so should I
move forward with this one?

Thanks

Regards,
Animesh Maurya

 

Hi Steve,

Thanks for the direction.

What does it means, is parallel port so vulnerable to blow-up your PC !

 

I think it depends what you are doing. For example if you are using a
microcontroller with a serial port on it the serial port would be easy
to use. If you just want to switch a few things on and off from your PC
the parallel port will probably be easier.

One thing to watch out for though with the parallel port is that most
modern PCs seem to output ~3.3 Volts for a logic high rather than the 5V
you might expect.

Gareth.

--