Multitasking I/O pins & batch programming

Forum 2005-2010 (read only) Hardware Interfacing
1

I'm totally new to Arduino though I've done a fair bit of embedded work before on PIC platforms. In my current project, I am using the Bare-bones Arduino to control 12 mosfet drivers and read from 3 analog sensors. There will be 40 of these guys daisychained on a full-duplex RS485 bus (using MAX3466 1/4UL drivers).

I have a couple of things I'd like to confirm about my hardware design, and possibly a couple of neat little tricks to share if these will work.

The bus is full-duplex, meaning one master receiver is connected to all other transmitters, and the master transmitter talks to all other receivers. Messages go through the master and have to contain an address in the packet header.

  1. batch programming along the 485 bus

I am hoping to do batch programming of the 40 devices by connecting the PC USB to the serial programming port on the master BB Arduino board. Since the TX/RX pins are connected to the RS485 drivers, anything that comes across to program that board, should be sent along the bus as well. I will need a DPDT switch to connect Master RX<->Slave RX and same with TX. Once programming is done I will switch back to Master TX<->Slave RX and Master RX<->Slave TX for normal bus operation. Questions:

a) Does the board talk back to the PC during programming? if not, then I will boot the boards with the 485 TX drivers disabled to avoid bus conflicts; if so, then I will connect only the Master TX to the programming cable and hope that bus delays don't cause a problem.

b) Can anyone see any reason why this won't work, or has anyone done this before?

  1. multitasking I/O pins

This hack came about because initially I forgot in my design about 2 things: address configuration and the RS485 TX driver enable signal, required in order to prevent conflicts on the bus. The solution I came up with is to use the digital pins as inputs during setup, with internal pull-ups on, and then switch them to outputs once addressing/config data has been read. By putting a switch to ground in series with a 4.7k resistor then into the pin, the pin will read 1 when the switch is open because of the pullup and have at worst 4.7/24.7*Vcc=0.2Vcc when the switch is closed. This is below the 0.3Vcc required to register as low on the 168 input. Once the pin switches to output, it drives the gate of a mosfet. If the config switch on that pin is closed, there will be a 4.7k resistor between gate and ground, so the only real side-effect is to draw an extra about 4.2/4.7 mA of current if the associated config switch is closed.

Does anyone see any problems with this? If people like, I can post code and schematics which show how this works (it has been successfully tested on my breadboarded version).

Thanks for the collective input/wisdom!

Rob.

2

So I found some MAX489 RS485 drivers in my stash and hooked up a test between two Barebones Arduino boards. The "master" is connected to the PC via the USB/Serial programming cable. Its RX pin is also connected to the outgoing driver on the RS485 chip and that drives the inputs on another RS485 chip which in turn is connected to RX on the "slave" Arduino.

The test is to reset both devices and upload the code, to see if both are programmed. The result is that it worked, and in fact seems quite robust to order and (small) delays in sequence of reset_slave, reset_master, and upload.

This is an inconclusive test since the length of the "bus" right now is only a few inches, but it's promising. Note that the TX pin of the "slave" are not connected at all. If there is in fact handshaking during programming, then lengthening the bus might mess things up.

Rob.

3

Hi Rob...

thx for this. btw: you don´t know by chance where i can find an rs485 to ttl circuit using the max489 (i´m having an sensor working with rs485 and want to connect it to the arduino)? somehow i can only find some for rs232 to ttl...

timm

4

thx for this. btw: you don´t know by chance where i can find an rs485 to ttl circuit using the max489 (i´m having an sensor working with rs485 and want to connect it to the arduino)? somehow i can only find some for rs232 to ttl...

I'm not sure I understand your question. The RO and DI pins of the MAX489 are TTL-level pins as far as I can tell from the MAX489 datasheet. The connection between your MAX489 and the sensor depends on whether its full-duplex, half-duplex, multi-drop, etc.

Rob.

5

...that was actually what i was looking for. the connection is half-duplex and probably won´t be multi-drop...and i´d have a question, if i don´t bother: when using the max489 for a single connection, does it make sense to connect A&Y and B&Z? i found a circuit in the net doing this, and now i wonder if it is some safty thing or stuff...
timm

6

...that was actually what i was looking for. the connection is half-duplex and probably won´t be multi-drop...and i´d have a question, if i don´t bother: when using the max489 for a single connection, does it make sense to connect A&Y and B&Z? i found a circuit in the net doing this, and now i wonder if it is some safty thing or stuff...

If your communication is bi-directional and half-duplex, then you need to connect A/Y & B/Z. It is not a safety thing: it is the definition of a half-duplex connection. Half-duplex requires only two wires, but only allows communication in one direction at a time. The A/Y & B/Z connections are so that the transciever can both write and read the bus.

Note that something else needs to ensure that the two sides are not trying to write to the bus at the same time. That can be either a set of additional wires used for bus arbitration signaling between your sensor and your Arduino, or it could just be a set of agreed-upon conventions. E.g., Arduino asks for data, then turns the bus over within X ms so that the sensor can write the data back, including some implicit or explicit indication that the data packet is complete. Whether you have the Arduino set to idle as bus master or the sensor depends on synchronization between the Arduino and the sensor, and whether the data is read in a request-response model as above, or just streamed by the sensor.

It will also be easier if you can commit to either multi-drop or not right now, rather than saying "probably not multi-drop." It is more complicated to do bus arbitration and avoid multiple bus-writers in the half-duplex multi-drop case.

There is a lot one needs to know about your particular sensor and the data protocol in order to answer your real question, which is "how do I hook this up and make it work."

Rob.

7

i think multi-drop doesn´t make sense in my case, so i won´t use it. just said "probably" cause it´s a work in progress and things allways can change. the sensor is messuring ozone and waiting for a string having 6 chars(kind of setup) before giving back a string out of 20chars carrying the data.
Other things: RS485 Asynchronism, Semiduplex, 19200bps, 8 byte , Odd 1 Stop-bit...