RS-485 or I2C?

I'm trying to decide the architecture for my mobile robot, and I'm open for suggestions. Here's what I need to do:
Fact: Brain of the robot will reside on a PC. This PC has standard ports
(serial, parallel, USB, etc). My original thought: Have the PC interface via RS-232 with what I call "the main message manager", which is a PIC mcu that is responsible to inquiry several "sensor slave modules" (as described below) if a message is ready to send. If yes, then the message manager reads that data, packages into a given software protocol and transmits to the host computer (the brain).
The sensor slave module is another PIC that interfaces with one or many sensors. The PIC "knows" the language of the sensor. It may be configured to sample sensors at a given time interval, and then once the sensor was read, it stores the data in memory and flags "I'm ready" to the message manager.
Now, until today I was set on implementing the messaging system using I2C, but someone also suggested RS-485 (CAN would be more difficult to implement as there are no direct libraries in my development platform and I'd have to do it in assembler).
So what do you think?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Padu wrote:

My personal experience with I2C is that it is ok. Nothing great, kinda slow. Also, the PC that uses a parallel port to speak I2C has to generate the protocol. It is not handled by a UART.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Padu wrote:

IMO I2C is a bit overrated as a general purpose communications bus, especially as the needs of the system scale upward. Serial tends to be one of the easiest architectures to implement. You're more likely to be able to access serial ports than parallel ports, given different versions of Windows. (You didn't mention if your PC is running Windows, Linux, DOS, or something else.) Helpful for down the road...
With serial you are free to create whatever communications protocol you wish, though there are some "standards" already out there. You can see how other people have done these, but -- as an example -- you might start with a unit ID number (1 to 254), then send one or more bytes for the actual data. Data length can be arbitrary.
For examples of how some people have implemented good ol' serial as a two-way communications bus for robot components you might try here:
http://www.gramlich.net/projects/robobricks/index.html
Wayne Gramlich, one of the creators of this system, is a regular contributor here. The site makes the specs, board designs, and software for many core modules freely available. The concept has been written up recently in SERVO magazine, if you have a subscription to that.
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Gordon McComb wrote:

Padu:
If you are using a PC for your main brain, it is prudent to architect your system so that you can advantage of the newer and newer processors that come out on a regular basis. USB and 10/100/1000 Ethernet look like they are going to be on the motherboard for quite a while. The serial port, parallel port, game port, ps/2 port, etc. are already starting to disappear from motherboards. Even the PCI bus, which has been around for a long time looks like it is going to fragment in the not too distant future (PCI Express, etc.) Unfortunately, neither USB nor Ethernet are particularly easy to interface a microcontroller to. My recommendation is to use some flavor USB to serial converter. The output of the serial converter can be either RS-232 or TTL compatable voltage levels. If the output is RS-232, a simple MAX232 chip can convert to the TTL compatible levels or you can use the same circuit that the Parallax Basic Stamp people use to level convert (a few transistors and a few resistors.) There is no reason not to crank the frequency up on your CPU to root microcontroller link. For some reason 115.2kbps is the typical baud rate used on PC CPU's although the UART on the root microcontrollers can go faster. Finally, when you get around to doing a vision system, give it it a private bus to pump the bits over (115.2kbps is not enough.)
Once you have serial data from the main CPU sitting in your root microcontroller you have lots of options. There is no reason to confine yourself to just one bus. There is no reason why the root microcontroller can not talk to more than one bus -- I2C, SPI, CAN, USB, or whatever. An example root processor that you can look at is:
<http://gramlich.net/projects/robobricks/picbrain11/index.html
This board has the Parallax RS-232 level converter, and the ability to talk to I2C (and SPI) buses, and bit-bang out serial protocol to multiple serial pins to a star topology.
When it comes to inter-module communication, differential signalling has a higher noise immunity than non-differential signalling. Examples of differential signalling are RS-422, RS-485, Ethernet, CAN bus, USB and probably a few more that I can't think of. Non-differential signalling is represented by RS-232, I2C, SPI, and plain old TTL level signalling. The longer the run and the higher the frequency, the more likely you want to pick up the noise immunity feature of a differential bus. Unfortunately, the motors we stuff into our robots typically kick out a lot of noise. If you carefully read the I2C specification you will find that Philips recommends using shielded cables for longer I2C runs. I don't know whether Philips is just playing it safe or whether the bus really starts to loose it as it gets longer. I suspect the bus looses it, since it does not take a very long piece of wire sitting next your next door neighbor's HAM tower to kick up a lot of noise. (I have very little experience with I2C, so other people who have used I2C may offer additional insight based on their experiences.) RS-422/485 is quite cheap to interface to and only requires three pins (RX, TX, and a direction control pin); the remaining microcontroller pins are yours.
If you want to try a star topology with a UART, a couple of inexpensive 74*151 and 74*138 chip allow for the easy stearing of the signal. The advantage a star topology has is that you don't have to figure out how to address your modules. If your module receives a message, it is knows the message is for itself. Whereas, on a multi-drop RS-485 bus, you have to somehow provide an address for each module and each module has to receive every message and ignore the messages that not addressed to it. An example design for such a star topology circuit is at:
<http://gramlich.net/projects/robobricks/multiplex8/index.html
This particular module is sitting on my shelf waiting for some spare time to dust it off and get it working. Sigh.
It is tempting to try to turn a multi-drop RS-485 bus into a mini-ethernet with full peer to peer communication. It can be done, but it makes things more compilicated since you have to provide code for detecting collisions, backing off, trying again etc. It has been done, but it now adds some uncertainty into whether or not a message you send actually got through or not. I do not recommend doing a peer to peer network; stick with a strict master/slave network instead.
The RoboBricks architecture uses asynchronous serial communication with TTL voltage level signalling in a star topology. Our inter module cables are 6 inches long to keep try and keep noise issues under control. At the time I started the project, PIC microcontrollers with UART's on them tended to be both expensive and had way too many pins on them. To reduce costs, I wound up using microcontrollers without UART's and bit-banged the serial protocol. I am currently in the process of upgrading the modules to use the PIC16F688 which has both an on-board UART, 8 channels of A/D, and reasonable number of pins (not too many and not too few.) I'm hoping to crank the baud rate of each module up to 115.2kpbs, but the jury is still out as two whether I can pull it off for every module.
Hopefully the text above is informative without being too technical. Please let us know what you decide upon.
-Wayne
P.S. I'll be off line for about a week starting tomorrow morning.
P.P.S. If you wish to contact me directly via E-mail, my E-mail address is Wayne .at. Gramlich @dot@ Net.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Wayne C. Gramlich wrote:

At NAB?
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Wayne C. Gramlich"

I hadn't think about that, the idea of using a usb2serial is a very good one and I think I'm gonna use it, thanks. I'll even take a look at the newest PICs that support USB.... I've heard that they made it very easy to interface with.
<snip>

Here's what I'm very inclined to do:
Have the PC (running windows XP) communicate with the "microcontroller's box" via USB, either a direct USB path or a usb2rs232 cable. Supposing I decide for the later, when the signal gets to the "box", a MAX232 converts it to TTL levels and send the signal to an LTC485 for example, that is connected to the RS485 bus. In this case, the master will be the PC. Each sensor will have a dedicated microcontroller responsible for sensor data acquisition and packaging that data into a protocol known both by the slave and the master. This way, the master must only know the address of that sensor, since the "language" is standard for all sensors. I believe this architecture still promotes decoupling between the cpu and sensors, but eliminating the box's root processor eliminates one layer of communication.
One advantage that I can think of: for example, if at some point the "brain" decides that it doesn't need information from a particular sensor, instead of sending a message to the root processor of the type "hey root, I don't need info on sensor X for now, stop sending it to me until I request it back", it only doesn't request data from that sensor anymore.
For example, one of the sensors my robot has is a battery meter. The discharge rate of the batteries I'm using is known, so I could implement a variable sampling rate. When the batteries are full charged, I don't need to know their voltage every second.
The way I was thinking with I2C was very similar to this, except I'd have a root microcontroller in the "box" responsible for packaging information and communicating with the PC through serial port. Somehow, the idea of not having a root microcontroller in the box is growing in my mind.

What I like about the USART is how easy it is to work with. I constantly use it do debug my applications (I send breakpoint info through USART instead of showing it on an LCD for example). But one thing I liked about the RS485 is that because it uses differential signaling, the devices can be implemented with uncommon grounds. Somehow this gives me the idea that more modularity and isolation between modules is provided. Another benefit is that I'll have two 14V DC motors running my car (the platform is an RC car... or better, an RC monster truck) at more or less 18A with spikes up to 50A, so noise may be a problem.

Very. Thank you for such detailed explanation.
As far as what I'll decide on using, I'm very biased on RS485. This is my Master's thesis, and although I wish I had more time to play around with the electronic side of it, I don't. RS485 libraries are provided with the development platform I'm utilizing (mikropascal), therefore reducing time spent on this part of the project.

I'll CC this post to your email.
Cheers
Padu
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Padu wrote:

I would say that RS-232 will be around for a while, don't panic. If and when the time comes that it is no longer available, the modules to convert USB to serial will probably work with the future version of USB that will be the standard.
In short, don't plan too far ahead with computers. There seems to be no risk as that what you want to do currently works, and the technology that will eventually replace what you have probably isn't out yet.

Windows? That's so sad. A potentially great robot incapacitated with a BSOD.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"mlw" wrote

risk
You're probably right, but I'll investigate the USB way either way. If it's proven to be as easy or just a little bit more complex to implement than RS232, then I'll go for it. I don't know.
<snip>

BSOD.
Hehe, I knew you'd say something like that. I have nothing against linux, and it would be probably more efficient than windows. I don't need the graphic environment in the robot, but I think it won't hurt it too bad. The thing is that I'm not familiar with linux, and although this could be an excellent opportunity to learn a new OS, I have a very limited time to learn lots of other things. I have to focus on my research which is coming up with a robust navigation system for my rover, instead of dealing with OS problems. I know that if I go with linux I'll surely have problems with something related to the OS, either by OS inadequacy or my lack of experience with linux. I'm a seasoned windows developer, that's what I've been doing for the past 13 years, and if I go with Windows, I'm sure I won't have to deal with OS problems, and if I do, I'm pretty confident that I can "patch" it much faster than I'd do in linux.
Furthermore, by implementing the cpu completely decoupled from the sensor system, replacing the CPU and the OS is a much easier task.
Cheers
Padu
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Padu wrote:

:-)
Probably?

That is but one advantage.

I have a liberal policy about learning and obtaining new tools. It has been my experience that learning to use something inherently more aligned to your task is often faster in the long run.

How will you get the "robust" in Windows?

ok.
I'm a seasoned Windows *and* Linux developer and I am dubious that this is true.
I have a number of problems with Windows, 1st, it is unpredictable, no matter how good you are at your craft, you can not make a reliable solution. 2nd, unless you are using an old version, say 2K or 98, every time you materially change your system you'll have to call Microsoft and ask permission to use your computer again. Lastly, the granularity of control over the system is discouraging.

Perhaps.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Padu wrote:

I think that the exact method of serial "playout" from the PC is of less overall concern than the fact that you're using byte-oriented serial communications. Your current serial port can work now; RS-232 and RS-485 level-shifting is fairly easy with off-the-shelf parts; and serial USB-RS232 adapters can always be added.
Do consider a "middleware" controller that can be used as a master for slave controllers. Yes, at first it might appear that it's simpler to communicate directly with each subcontroller, but in the long run, I think a master controller is the easier and more flexible approach. You still have the ability to turn sensors on and off, but an advantage of a master controller is that the subcontrollers can be of any type, on any bus. You might use I2C for some, serial for others, SPI for yet some more, or simple pin signalling for still others.
Changes you make from the host can be more readily adapted by updating code in just one master, rather than updating all the subcontrollers. It also allows you to use some ready-made sensors that come with own bus, like I2C. You don't have to make anything special to use the sensor.
One other potential benefit of a master controller is that you can design a kind of message queue in it, similar to the one you have in Windows. The controller dispatches messages bidirectionally. This allows you to send and receive messages to/from sensors without regard to timing restrictions. You don't have to set the message speed to the slowest sensor.
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Two things I want to interject here for you padu:
1) Linux may be "scary" because it's new. The concepts and organization, however, are much more forward than M$. The only reason Windows seems simpler to use to most people is that it's what they know, and what you know is simple. In 30 days or less of working with linux, you WILL know the ins and outs of how it works. You wont be a guru, but once you grasp the basic concepts, it's very simplistic in nature and beautiful in form.
As far as patching goes...there are hundreds if not thousands of patches written daily for everything from the linux kernel to the calculator. Does this mean you NEED these patches? No...but history dictates that if a vulnerability is found that could actually be exploited, it's amatter of minutes to hours before a patch is available, as compared to windows where it has to make it's way around the internet, then the magazines, then the rpess releases, THEN microsoft will act.
2) A number of years ago there was an Aegis Cruiser (US Navy top of the line missile cruiser), and this ship had been running windows flawlessly for quite a while. Everything ran on microsoft products, even though 99.9% of the software was custom written by Naval programmers...but a seemingly innocuous system BSOD'd. This cause a catastrophic cascade of BSOD's to the point where they couldn't even reboot the ship. Literally. It had to be towed from it's Sea Trial several hundred miles back to port. As of my last update, they were running unix on those ships now. Something to think about. No matter how many times you patch, no matter how stable you THINK it is, it's unix that keeps the world running, and windows that lets the masses of farm animals in the workplace access those unix boxes.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Padu wrote:

[snip]
I think you've missed a very important point with RS-485. Each RS-485 chip (like the LTC486) has send, receive, *and* direction pins. When the PC is transmitting, it needs to be able to assert the send direction pin *before* it starts transmitting. After transmission, it needs to deassert the transmit direrection pin.
It is tempting to just grab and extra RS-232 pin, like DTR, and use it to control direction. Unfortunately, the protocols for each USB to RS-232 convertes tend not to be published. It may not be possible for the operating system to guarantee that the USB message that changes the DTR pin value occurs within the minimum amount of time required for your sensors to send a response message.
I recommend that you use a root microcontroller to do the RS-232 to RS-485 conversion. It lets you carefully control the timing of the direction line.

Yup. Dedicating a mircocontroller to each sensor is a reasonable architecture.

It can be done, but you need to think through *all* of the timing issues.
[snip]

RS-485 requires *some* level of electrical connectivity between the modules. Be sure to read up on several of excellent application notes on RS-422/485 that have been published (National has a bunch.)
[snip]
-Wayne
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
You can "spoof" the direction line by putting a retriggerable one-shot on the line that responds to the transmit data. I've seen reference designs that do this. I think a more reliable means is to put a micro out there that relays the serial data after it properly sets up the data direction line for the RS485 driver, but that's just my opinion.
DLC
: Padu wrote: : > "Wayne C. Gramlich" : > : >>Padu:
: [snip]
: > Here's what I'm very inclined to do: : > : > Have the PC (running windows XP) communicate with the "microcontroller's : > box" via USB, either a direct USB path or a usb2rs232 cable. Supposing I : > decide for the later, when the signal gets to the "box", a MAX232 converts : > it to TTL levels and send the signal to an LTC485 for example, that is : > connected to the RS485 bus.
: I think you've missed a very important point with RS-485. Each RS-485 : chip (like the LTC486) has send, receive, *and* direction pins. When : the PC is transmitting, it needs to be able to assert the send direction : pin *before* it starts transmitting. After transmission, it needs to : deassert the transmit direrection pin.
: It is tempting to just grab and extra RS-232 pin, like DTR, and use it : to control direction. Unfortunately, the protocols for each USB to RS-232 : convertes tend not to be published. It may not be possible for the : operating system to guarantee that the USB message that changes the DTR : pin value occurs within the minimum amount of time required for your : sensors to send a response message.
: I recommend that you use a root microcontroller to do the RS-232 : to RS-485 conversion. It lets you carefully control the timing of : the direction line.
: > In this case, the master will be the PC. Each sensor will have a dedicated : > microcontroller responsible for sensor data acquisition and packaging that : > data into a protocol known both by the slave and the master. This way, the : > master must only know the address of that sensor, since the "language" is : > standard for all sensors. I believe this architecture still promotes : > decoupling between the cpu and sensors, but eliminating the box's root : > processor eliminates one layer of communication.
: Yup. Dedicating a mircocontroller to each sensor is a reasonable architecture.
: > One advantage that I can think of: for example, if at some point the "brain" : > decides that it doesn't need information from a particular sensor, instead : > of sending a message to the root processor of the type "hey root, I don't : > need info on sensor X for now, stop sending it to me until I request it : > back", it only doesn't request data from that sensor anymore. : > : > For example, one of the sensors my robot has is a battery meter. The : > discharge rate of the batteries I'm using is known, so I could implement a : > variable sampling rate. When the batteries are full charged, I don't need to : > know their voltage every second. : > : > The way I was thinking with I2C was very similar to this, except I'd have a : > root microcontroller in the "box" responsible for packaging information and : > communicating with the PC through serial port. Somehow, the idea of not : > having a root microcontroller in the box is growing in my mind.
: It can be done, but you need to think through *all* of the timing issues.
: [snip]
: > What I like about the USART is how easy it is to work with. I constantly use : > it do debug my applications (I send breakpoint info through USART instead of : > showing it on an LCD for example). But one thing I liked about the RS485 is : > that because it uses differential signaling, the devices can be implemented : > with uncommon grounds.
: RS-485 requires *some* level of electrical connectivity between the : modules. Be sure to read up on several of excellent application : notes on RS-422/485 that have been published (National has a bunch.)
: [snip]
: -Wayne
--
============================================================================
* Dennis Clark snipped-for-privacy@frii.com www.techtoystoday.com *
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Dennis Clark"

I see, from these feedbacks it sounds like it's easier to just put a PIC there to make the bridge between the max232 and the rs485 transceiver right? If this is easier, then I'll just to this way (lazyness is the mother of all [efficient] inventions).
Now, if the PC sends messages packed in a software protocol, does the root mcu need to have any intelligence? Does it need to bufferize that message prior to sending it down the rs485 bus?
Here's what I envision: PC needs to send a message to the steering servo to turn +20 degrees. It first packs that command into a packet (I will decide later which messaging framework I'm gonna use, but it will probably be JAUS), for example:
"@0001-TURN-+20#"
where @0001 is the address of the mcu that controls the steering servo, TURN is the command and +20 is 20 degrees to the right and # marks the end of the message. I just came up with this "protocol" as an example, don't pay attention to it.
Then the CPU streams this message to the serial port, connected to the root mcu. I guess there's no other way right? The mcu must parse that message, at least to get the device address. Once it has the device address, then it starts a message on the RS485 bus by activating device "0001", once it gets the ACK from it, it sends the message "TURN+20". I don't know if I really need to wait for a final ACK from the device, but let's suppose that yes. When the root mcu receives the final ACK, then it sends a message to the host cpu, something like "@0001-ACK"
Does it seem reasonable?
I'm going to order Jan Axelson's Serial Port Complete just to grab a few more concepts on RS-485, as I'll be spending a lot of time creating this bus in the next upcoming weeks. Any other good pointers on RS-485?
Thanks!!
Padu
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Padu wrote:

There are many ways to accomplish this. The three broad ways of doing this are:
Unbuffered: The microcontrolelr listens to the message traffic and figures out when to change the RS-485 direction line.
Buffered: 2 USARTS available:     Hook one USART to the RS-232 line and the other RS-485 bus. 1 USART available: Add some steering circutry to allow the PIC to select whether it is listening to the RS-232 line or the RS-232 bus and another line to steer USART output to either the RS-232 line or the RS-485 bus.
I think the 2 USART method is best if your microcontroller has 2 USARTS. Since most Microchip PIC's only have 1 USART, a PIC based solution usually involves adding a little steering circuitry. The Unbuffered solution tends to be fragile in the sense that an error can cause loss and message synchronization and result in complete chaos. Adding one or two simple gates for steering is really a cost effective way of improving overall reliability.

Actually, the root processor is more concerned with the length of the send message. Since all devices are hanging off of the RS-485 bus, the device address is not really very interesting to it.
> Once it has the device address, then it

Yes.
Jan's book is pretty reasonable; she spends approximately 100 pages talking about an RS-485 bus.
You should also avail yourself of some the excellent application notes that are available for RS-422/RS-485. Heres a list of application notes from my National Semiconductor directory:
an_1031_tia_eia_422_b_overview.pdf an_1057_ten_ways_to_bulletproof_rs_485_interfaces.pdf an_214_transmission_line_drivers_and_receivers_for_tia_eia_standards_rs_422_and_rs_r223.pdf an_216_summary_of_well_known_interface_standards.pdf an_256_circuitry_for_inexpensive_relative_huminity_measurement.pdf an_299_audio_applications_of_linear_integrated_circuits.pdf an_409_transceivers_and_repeaters_meeting_the_eia_rs_485_interface_standard.pdf an_457_high_speed_low_skew_rs_422_drivers_and_receivers_solve_critical_system_timing_problems.pdf an_694_a_dmos_3a_55v_h_bridge_the_lmd18200.pdf an_74_lm139_lm239_lm339_a_quad_of_independently_functioning_comparators.pdf an_759_comparing_eia_485_and_eia_422_a_line_drivers_and_receivers_in_multipoint_applications.pdf an_805_calculating_power_dissipation_for_differential_line_drivers.pdf an_806_data_transmission_lines_and_their_characteristics.pdf an_807_reflections_computations_and_waveforms.pdf an_808_long_transmission_lines_and_data_signal_quality.pdf an_828_increasing_the_speed_torque_of_bipolar_stepper_motors.pdf an_847_failsafe_biasing_of_differential_buses.pdf an_903_a_comparison_of_differential_termination_techniques.pdf an_916_a_practical_guide_to_cable_selection.pdf an_972_inter_operation_of_interface_standards.pdf an_979_the_practical_limits_of_rs_485.pdf
Most of these application notes are about RS-422/RS-485.
Frankly, if you read the above application notes, I doubt you will gain much additional insight from Jan's book.
-Wayne
P.S. To contact me directly, use Wayne .at. Gramlich @dot@ Net.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Wayne C. Gramlich" <snipped>

What about simulating the second serial via software (bit banging?).
Thanks for the app notes list. I'll read through.
Padu
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Padu wrote:

Padu:
Bit banging will work, but I do not recommend it unless you are really into tight real time programming. Bit-banging is quite easy at slow speeds, but gets quite challenging as the speeds get higher. At 115.2kps (a somewhat arbitrary speed), you have 8.68 uS per bit. For a PIC running at 8MHz, that is about 17 cycles. Realistically, you need to sample about every third of bit on receive (yeah, I know about the Nyquist sampling theorem, but I talking about stuff that is actually implementable via bit-banging techniques) so you only have 6 cycles. That is really tight timing. If you want to crank the clock speed PIC up to 20MHz or higher, you are now spending more money on the resonator/crystal/oscillator than the steering circuitry costs.
The steering circuity for input selection can be done with a single 74*02 (Quad 2-input NOR gate) and the output steering can be done with a single 74*32 (Quad 2-input OR gate.) These are still cheaper than microcontrollers. If you are using a microcontroller with a single USART, do yourself a favor and use the two extra glue chips. Your microcontroller software will be much, much simpler.
-Wayne
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: Padu wrote: : > "Wayne C. Gramlich" : > <snipped> : >>I think the 2 USART method is best if your microcontroller has 2 : >>USARTS. Since most Microchip PIC's only have 1 USART, a PIC based : >>solution usually involves adding a little steering circuitry. The : >>Unbuffered solution tends to be fragile in the sense that an error : >>can cause loss and message synchronization and result in complete : >>chaos. Adding one or two simple gates for steering is really a : >>cost effective way of improving overall reliability. : > : > What about simulating the second serial via software (bit banging?).
: Padu:
: Bit banging will work, but I do not recommend it unless you are : really into tight real time programming. Bit-banging is quite : easy at slow speeds, but gets quite challenging as the speeds : get higher. At 115.2kps (a somewhat arbitrary speed), you have : 8.68 uS per bit. For a PIC running at 8MHz, that is about 17 cycles. : Realistically, you need to sample about every third of bit : on receive (yeah, I know about the Nyquist sampling theorem, : but I talking about stuff that is actually implementable : via bit-banging techniques) so you only have 6 cycles. That is : really tight timing. If you want to crank the clock speed : PIC up to 20MHz or higher, you are now spending more money : on the resonator/crystal/oscillator than the steering circuitry : costs.
: The steering circuity for input selection can be done with : a single 74*02 (Quad 2-input NOR gate) and the output steering : can be done with a single 74*32 (Quad 2-input OR gate.) These : are still cheaper than microcontrollers. If you are using a : microcontroller with a single USART, do yourself a favor and : use the two extra glue chips. Your microcontroller software : will be much, much simpler.
: -Wayne
Remember that this network is likely to be half-duplex, which makes the idea of a bit banged UART more workable. There are SPI UARTs that can be added to a micro, but, they cost more than the micro does, so that isn't a great solution. If you are going to switch the micro's UART from one port to the next, that might be an ineresting idea, again, made more possible by the half-duplex nature of the master/ slave nature of the common RS485 network. Hmm.
DLC
--
============================================================================
* Dennis Clark snipped-for-privacy@frii.com www.techtoystoday.com *
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Padu wrote:

There's one advantage that using I2C will have here (when using a PIC). PICS that have SSPs (which you'll usually use for I2C), will also have a second UART, which you can use for your serial interface to your main controller.
--
(Replies: cleanse my address of the Mark of the Beast!)

Teleoperate a roving mobile robot from the web:
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: "Wayne C. Gramlich" : <snipped> : > I think the 2 USART method is best if your microcontroller has 2 : > USARTS. Since most Microchip PIC's only have 1 USART, a PIC based : > solution usually involves adding a little steering circuitry. The : > Unbuffered solution tends to be fragile in the sense that an error : > can cause loss and message synchronization and result in complete : > chaos. Adding one or two simple gates for steering is really a : > cost effective way of improving overall reliability. : >
: What about simulating the second serial via software (bit banging?). : Thanks for the app notes list. I'll read through.
Bit banging a UART works just fine. I do this all the time with a 4MHz PIC, so it can be done. The problem with steering is that you can't effectively deal with "9th bit" addressing, nor with error correction and detection if there is a "collision" on the bus. As Wayne says, buffering is also a very good idea, obviously needed if the baud rates between the two "sides" is different.
DLC
--
============================================================================
* Dennis Clark snipped-for-privacy@frii.com www.techtoystoday.com *
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.