Ok, so bear with me here a little bit, I'm working on a custom designed device for a particular need, and needed to inexpensively add multiple devices to the same chain. Yes, there's i2c and SPI, I know, but it's really hard to beat RS-485 on ease and cost and cable length...
So, here I am with my nice RS-485 adapter cable, my multiple arduino's hooked up with SN65LBC176 IC's, a nice fail-safe resistor chain on each (no need to figure out which devices terminate the chain), and of course - I'd like to use the same wiring + cable combo to upload software (presume I've already burned the bootloader on the chip on the device via ICSP).
But that's a real head-scratcher. It seems easy enough to flip the RE/DE state whenever TX should go high - but the list of problems that could occur start piling up: most notably, it just didn't work when I tried the simple, hack-ish way - just link TX to RE/DE.
Has anyone else tried programming over an RS485 link? Have they had any success? Even an adapter pcb would be fine, as it would work better than adding additional ports (and cables) in this design.
That is definitely not going to drive the driver/receiver enable properly. You will need to use another pin and some logic to drive the RE/DE.
programming over an RS485 link
I don't know if the Arduino software upload protocol requires full-duplex to operate properly -- it might. But even if it could, as a protocol, operate over a half-duplex link, neither the bootloader nor the Arduino IDE have the logic or hardware to control the RE/DE for duplex turn-around.
And on top of that, the software upload protocol doesn't have a means for addressing a particular station on a multi-drop bus.
No, having "master nodes" polling "slave nodes" is not a solution in any reasonable sense to this problem. I obviously was not clear in my question, so I will be more clear.
I have an RS-485 bus which is converted to TTL USART before going on to the atmega chip and I want to use the RS-485 bus for hex uploads.
^ With the above, and for simplicity's sake, presume there are only two devices on the bus (pc + arduino), and addressing is not required (as RS485 is not natively "addressed")
Has anyone else successfully interacted with the arduino bootloader from an RS-485 bus to upload sketches? How did you do it?
An obvious solution: create/modify a bootloader to drive the driver select pin on the transceiver. Considering it, but hate to add another software variable to an already complex project - so would like to avoid, but won't be heart-broken if its the best solution.
Perhaps there is some buffer out there with a lot of hysteresis that could be used to monitor the TX line and drive the transceiver state from that? If such a thing did exist, that would tickle me in numerous ways =)
Gardner:
Yes, I already have a separate pin driving RE/DE state (required to implement the software on the bus), but I'm hoping to find a way to also tie the state to the TX UART state so that I can interact with the arduino bootloader.
From the avrdude end, it shouldn't look different than anything else - which is why timing issues concern me, if it does anything async. The PC end is handled by an FTDI cable that uses the same FTDI chip to talk to its transceiver (and manage state) as the arduino does, and uses the same VCP driver - so appears exactly the same to avrdude, afaict.
To get all these devices working together you must already have a protocol in place that addresses them, handles master/slave polling etc.
If so then it's a small step to add a "program" command that downloads the data to your boot loader. I would think the way to do it would be for the master to accept a HEX file from the PC and ship it (either directly or converted back to binary format) to the slave being programmed.
OK, cross posted there, I see you don't want master/slave.
No worries - you've actually got an interesting, if not slightly dangerous idea. To take raw data in from serial and simply write it into the correct memory locations, byte-by-byte...
Obviously, I understand that's what the bootloader effectively does, but I'm wishing to avoid such voodoo in my normal application space - one bug somewhere else and you're bricked until you hit up the ICSP =)
I was mostly choking at the pedantry in that first response. Made it hard to swallow.
I think you've said you have a multi-drop bus topology, with more than one Arduino on it. If you could get the electronics to all work, how do you expect to point the boot-loader to the proper arduino on the bus? Would you start the download, then manually go to a specific node and reset it, so that would be the one to interact with the programmer? Or would you expect all of the nodes to be simultaneously programmed?
AFAIK, the software download and verify protocol is a duplex handshake protocol, and simultaneous programming would be a problem since the receiving arduino expects to talk back to the programmer, and has no logic for bus arbitration or station addressing.
Are you planning to invent your own bootloader for this application? If so, then you should be able to incorporate logic to handle the multidrop topology.
monitor the TX line and drive the transceiver state from that?
I think it's normal to start the bus transmitter at least a bit time before sending the first bit, but that is probably not super-critical. Suppose you had the start bit trigger a timer that was set for just over the length of a byte. Then the start bit would trigger it, and it would assert the transmitter control for at least that long. Subsequent space bits would retrigger the timer to keep the bus transmitter running. When the TxD goes idle, eventually, around a byte time after the last space bit, the timer pops and the bus transmitter is switched off.
If the timing in the programming handshake protocol is right, this might work. But the programming protocol was designed and tested on full-duplex, so it would be lucky if it did.
I think you've said you have a multi-drop bus topology, with more than one Arduino on it. If you could get the electronics to all work, how do you expect to point the boot-loader to the proper arduino on the bus? Would you start the download, then manually go to a specific node and reset it, so that would be the one to interact with the programmer? Or would you expect all of the nodes to be simultaneously programmed?
Yes, it's RS-485 multi-drop bus, but I also said:
^ With the above, and for simplicity's sake, presume there are only two devices on the bus (pc + arduino), and addressing is not required (as RS485 is not natively "addressed")
There's is no issue with programming one unit at a time (I can't stress enough how much a simple instruction of "disconnect the out cable before programming the device" solves a plethora of design problems), the only issue is the half-duplex RS-485.
Either way, it's looking like modifying the stock bootloader is the right way to go. Thanks for your input.