RS-485 or I2C?

Padu,
RS485 is strictly a physical spec, any message formatting that needs to be done will have to be done by you. The RS485 bus just spits serial
as a half-duplex differential signal. IOW, anything that you can send via RS232, can be sent unchanged in RS485.
That said, there is something that is different. You need to provide an address preamble if you want to address multiple slaves on the bus. This means that what I wrote above is not strictly true IF you want multiply addressed slaves on the bus. Now you need this kind of protocol: send address <set the "9th bit" to denote this> send data get response <if one required> ...
I really recommend that you use the "9th bit" to denote an address, it simplifies how the slaves operate. In this way you can set the slave micro to fire an interrupt when it receives a '1' in the 9th bit so that you can look to see if the next bytes coming need to be dealt with. Otherwise your slave can discard the serial data since it knows that it isn't for him.
have fun, DLC
: "Dennis Clark" : > : > 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 : >
: 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
--
============================================================================
* 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 wrote:

While I've never used a one-shot, I suspect that using a one will work. The issue is how fast the RS-485 chip can go from receive mode to transmit mode. At 115.2kpbs, a single bit is 8.68uS long. If the one-shot can trigger and get the transceiver turned around in .1uS (worst case), only 1.15% of the start bit is lost in turn-around time. That should not introduce too much additional error into the USART receivers that are sitting on the receiving end of the RS-485 bus.
Both the transmitting USART in the CPU and the receiving USART on the RS-485 bus, are probablly running a little off frequency and have some additional timing error. For example, a PIC16F688 running off its internal 8MHz oscillator, has ~1% oscillator error and 2.12% frequency counter error at 115.2kbps. USART frequency error on a PC is rarely documented. All of these errors can add up and eventually cause an increase intransmission errors.
> I think a more reliable means is to put a micro

I concur with your opinion. If you want to change bus speeds with the one-shot, you need to change the RC constant of the one-shot. If you use a microcontroller, not only can the speed be changed via software. it can do all sorts of other useful things like poll sensors, error checking, etc.

[snip]
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

The Silabs cp chips are very easy to use easily available from Silabs , Sparkfun.com or mouser. Need less components than the ftdi chips http://www.silabs.com/tgwWebApp/appmanager/tgw/tgwHome?_nfpb=true&_pageLabel=GenericContentPage&contentObjectId=/public/web_content/products/Microcontrollers/Interface/en/interface.htm
The drivers can be found (oem ones) on the net (don't need the kit)
www.ftdichip.com another usb to serial chips. easy to use
pic 18f4550 or similar pic with usb that runs at 48MHz. Fairly easy to use. I got it working easly enough and if I can use then so can anyone else who can write c. Get the free student version of the microchip 18f c compiler.
Also keep an eye on the Philips lpc2xxx arm chips and other arm7 chips as a lot of the manufacturers are promising usb for second half of 2005.
Why not Can bus ?
Some of the pics have Can hardware onboard.
Pic app notes here on can , i2c , spi etc <http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId 69&filter1=function>
pic can appnotes <http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId 90&filterID97>
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Padu wrote:

I use I2C in general, since there tends to be good hardware support for it in many micros (especially PICS and ATMEL devices) as well as a number of commercially available robotic peripherals or generally useful components. In particular, the hardware support is nice for slave and multi-master mode, since a given node will only be interrupted when it is addressed. It's generally fast enough for most mobile robotic use -- with the right termination it can be run at speeds up to 3.4mbs. I generally just use resistors for termination and fairly sloppy wiring and run the clock around 810khz to 1.2mhz -- which is more than adequate for my needs. I've never felt the urge to go to active termination.
If the PC motherboard doesn't support i2c (smbus -- see below), you can just use the RS-232 port to talk to the PIC directly at speeds as high as the PIC can support (which can be pretty high). The PIC simply acts as a dispatcher (as you describe) in addition to its other duties -- I've had great success with this approach. One of my robots has 4 PIC boards managing various sensors and other devices, as well as a number of devantech devices, all using I2C -- works like a charm. My robot "bus" is basically just Vcc, GND, SCL and SDA.
Note that smbus isn't identical to i2c -- the former is officially limited to 100khz, and has a much lower maximum current sink spec (around 350 ua), which means you have to use higher resistances for termination. There are other differences, but these are minor for most applications. I don't know if smbus supports some kind of active termination to raise the max clock rate -- it may.
You can also bit-bang i2c off of the parallel port -- but I haven't tried it personally.
Hope that helps -- tAfkaks
--
(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
On Thu, Apr 14, 2005 at 02:19:40PM -0700, Padu wrote:

Take a look at ROBIN for this purpose:
http://www.bdmicro.com/code/robin
Basically just a simple packet protocol to use on RS485. I've implemented this on several systems and it works very well.
Alternatively, I'm currently working on a purely ASCII protocol that works well also. I'm not quite ready to publish that but it's slightly easier to implement that ROBIN, not that ROBIN is too difficult. I'm currently experimenting with this ASCII version on a smart h-bridge that I'm working on.
But your idea is sound. RS485 is reliable, has good noise immunity, is easy to use, and bus lengths are not really an issue since RS485 is good for something like a kilometer or so. Also, you can turn any RS232 serial port into an RS485 port using a converter like found here:
http://www.bb-elec.com/product_family.asp?FamilyId 
I like RS485 so much that I include an RS485 transceiver on my MAVRIC-IIB board:
http://www.bdmicro.com/mavric-iib
I find that it works superbly.
-Brian
--
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Brian Dean wrote:

and have a look at: http://www.dontronics.com/usb_485.html for a USB to rs-485 converter.
Don...
--
Don McKenzie
E-Mail Contact Page: http://www.e-dotcom.com/ecp.php?un=Dontronics
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Brian Dean" wrote

Because this project is potentially attractive to the military, I'm investigating the possibility of implementing this type of "soft" messaging protocol:
http://www.jauswg.org /
In the future, all (automomous vehicle) robotic projects that pledge government funds must comply with their framework. Their goal is to make a software control unit of vendor A to be able to control the robotic vendor of supplied by vendor B that is carrying payloads (sensors, guns, actuators, manipulators) of vendor C. They have recently field tested this concept and the framework specification is very detailed.
This doesn't invalidate at all the discussion RS485 x I2C, as they decouple the framework from the physical communication layer, hardware and OS.
Padu
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.