1. Home
  2. General Robotics Forum
  3. RS-485 or I2C?
  4. Page 2

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 send data get response ...

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

Padu wrote: : "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

Reply to
Dennis Clark
Loading thread data ...

"Wayne C. Gramlich"

What about simulating the second serial via software (bit banging?).

Thanks for the app notes list. I'll read through.

Padu

Reply to
Padu

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

Reply to
Wayne C. Gramlich

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.

Reply to
the Artist Formerly Known as K

The Silabs cp chips are very easy to use easily available from Silabs , Sparkfun.com or mouser. Need less components than the ftdi chips

formatting link
The drivers can be found (oem ones) on the net (don't need the kit)

formatting link
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

pic can appnotes

Reply to
Alex Gibson

Padu wrote: : "Wayne C. Gramlich" : : > 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

Reply to
Dennis Clark

Wayne C. Gramlich wrote: : Padu wrote: : > "Wayne C. Gramlich" : > : >>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

Reply to
Dennis Clark

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.