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.
: Padu wrote:
: > "Wayne C. Gramlich"
: > 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.
: > 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.)
* Dennis Clark email@example.com www.techtoystoday.com *
Click to see the full signature.