rs485 support for optiboot_x (attiny1614)

[jonspieg]

is it possible to add rs485 support in the optiboot_x bootloader (I don't mind the increase in size of the bootloader)? I noticed the original optiboot bootloader has this feature added recently, is there a reason why it could not work in optiboot_x as well?

I have a raspberry pi as rs485 master connected to multiple 1614 slaves and I really wish to be able to flash them directly from the pi.

[WestfW]

Yeah, probably. Especially if you only need it the same way it's implemented on the older AVRs. If you're willing to be an active participant in testing, I've had some ideas about improvement, too.

Um; I'm not sure that the current implementation supports multidrop; all it does is switch the transmitter on and off. Do you have info on the rs485 setup on the Pi side? (and I guess HW-wise on the xtiny side as well.) I've got some Pis; perhaps I could actually try it out!

[jonspieg]

I guess as a first stage it'll be great to have it implemented the same way as the old boards. I must say I haven't seen much documentation of this feature. How whould I go about actually initiating a flashing procedure from the arduino ide connected with an rs485 adapter to a single slave (as a first stage). I'm definitely up to being an active tester for this feature. As for the multidrop architecture, I'm not sure it needs to be addressed on the bootloader level. Correct me if I'm wrong, but if only one slave is being programmed at a time only initiating the flashing procedure should account for the multidrop nature of the protocol. The hardware is based on the Max33072 both on the pi and the attiny. This project is still under development and as a first goal I want to proove that this can actually work.

Thank you!

[jonspieg]

Hi @WestfW I see you're working on adding rs485 to optiboot_x, thank you!

I've noticed on the last commit (645a92f) you mentioned it's implemented using programmed IO and not the old USART way, could you please explain what this actually means?

Do you have rs485 hardware to test this with? As I said before I'm willing to test this feature and make sure it's working reliably.

Thanks again!

[WestfW]

The xTiny and mega0 chips have "RS485 support" built into the hardware, that will assert and de-assert a pin at the appropriate times when transmitting. See section 24.3.2.6 of the tiny1614 datasheet, for instance.

However, this only supports a particular pin, whereas the "programed IO" scheme can use any pin for the tx-enable, and doesn't take very much code.

No, I don't have any rs485 support - please test for me. The logic is slightly different than the regular optiboot - I don't disable the transmitter until I'm in getch(), so it stays "true" for multi-byte transmission. (Which is the way I think it should be, but not the way the support in optiboot.c does it.) Let me know if you need a particular binary built; I notice that my makefile targets are different than SpenceKonde's ...

[jonspieg]

I'm trying to build optiboot for the attiny1614 without much luck. Could you please share the command you use for this option. I'm on a windows machine and I'm able to build it for atmega1284 as described in the wiki. I'm not sure what should be the arguments for the attiny1614 build.

a precompiled HEX file could also be nice. I'm using pin 0 (PA4) for the 485 transmit enable. Also attached are the options I'm currently using with SpenceKonde's optiboot

Thanks!

[WestfW]

make -f Makefile.mega0 optiboot_attiny1614.hex UARTTX=B2 TIMEOUT=8 LED=A7 RS485=A4 (that's for an 8s bootloader timeout, appropriate if you don't have HW reset, and LED as per the "DrAzzy" boards.)

Here's the resulting .hex optiboot_attiny1614.hex.zip

[jonspieg]

I've tested the binary you've sent and can't seem to make it work. I'm trying to program it from the arduino IDE on my windows PC via a generic usb to rs485 converter with auto direction turnaround, so it should work out of the box with no modifications to avrdude, right? Unfortunately there's no responce from the chip. I've probed the tx line and nothing. Also, the direction control pin (PA4) is remaining low the entire time.

I also tried flashing it directly with uart (skipping the rs485 all together) to no avail.

I'm currently unable to build the bootloader myself, this is the output I get: >make -f Makefile.mega0 optiboot_attiny1614.hex UARTTX=B2 TIMEOUT=8 LED=A7 RS485=A4 Using Compiler at: C:/Jonathan/Hamezave/hamezave-omega/optiboot/optiboot/bootloaders/optiboot/avr-gcc avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax -DWDTTIME=8 -DLED_START_FLASHES=3 -DLED=A7 -DUARTTX=B2 -DBAUD_RATE=115200 -DRS485=A4 -Wl,-section-start=.text=0 -Wl,--section-start=.application=0x200 -Wl,--section-start=.version=0x1fe -Wl,--relax -nostartfiles -nostdlib -mmcu=attiny1614 -o optiboot_attiny1614.elf optiboot_x.c avr-gcc: error: cannot access device-specs for 'attiny1614' expected at 'c:/program files (x86)/arduino/hardware/tools/avr/bin/../lib/gcc/avr/4.9.2/device-specs/specs-attiny1614' avr-gcc: note: devices natively supported: ata5272 ata5505 ata5702m322 ata5782 ata5790 ata5790n ata5791 ata5795 ata5831 ata6285 ata6286 ata6289 ata6612c ata6613c ata6614q ata6616c ata6617c ata664251 ata8210 ata8510 atmega103 atmega128 atmega128a atmega128rfa1 atmega128rfr2 atmega1280 atmega1281 atmega1284 atmega1284p atmega1284rfr2 atmega16 atmega16a atmega16hva atmega16hva2 atmega16hvb atmega16hvbrevb atmega16m1 atmega16u2 atmega16u4 atmega161 atmega162 atmega163 atmega164a atmega164p atmega164pa atmega165 atmega165a atmega165p atmega165pa atmega168 atmega168a atmega168p atmega168pa atmega168pb atmega169 atmega169a atmega169p atmega169pa atmega256rfr2 atmega2560 atmega2561 atmega2564rfr2 atmega32 atmega32a atmega32c1 atmega32hvb atmega32hvbrevb atmega32m1 atmega32u2 atmega32u4 atmega32u6 atmega323 atmega324a atmega324p atmega324pa atmega325 atmega325a atmega325p atmega325pa atmega3250 atmega3250a atmega3250p atmega3250pa atmega328 atmega328p atmega328pb atmega329 atmega329a atmega329p atmega329pa atmega3290 atmega3290a atmega3290p atmega3290pa atmega406 atmega48 atmega48a atmega48p atmega48pa atmega48pb atmega64 atmega64a atmega64c1 atmega64hve atmega64hve2 atmega64m1 atmega64rfr2 atmega640 atmega644 atmega644a atmega644p atmega644pa atmega644rfr2 atmega645 atmega645a atmega645p atmega6450 atmega6450a atmega6450p atmega649 atmega649a atmega649p atmega6490 atmega6490a atmega6490p atmega8 atmega8a atmega8hva atmega8u2 atmega8515 atmega8535 atmega88 atmega88a atmega88p atmega88pa atmega88pb attiny10 attiny11 attiny12 attiny13 attiny13a attiny15 attiny1634 attiny167 attiny20 attiny22 attiny2313 attiny2313a attiny24 attiny24a attiny25 attiny26 attiny261 attiny261a attiny28 attiny4 attiny40 attiny43u attiny4313 attiny44 attiny44a attiny441 attiny45 attiny461 attiny461a attiny48 attiny5 attiny828 attiny84 attiny84a attiny841 attiny85 attiny861 attiny861a attiny87 attiny88 attiny9 atxmega128a1 atxmega128a1u atxmega128a3 atxmega128a3u atxmega128a4u atxmega128b1 atxmega128b3 atxmega128c3 atxmega128d3 atxmega128d4 atxmega16a4 atxmega16a4u atxmega16c4 atxmega16d4 atxmega16e5 atxmega192a3 atxmega192a3u atxmega192c3 atxmega192d3 atxmega256a3 atxmega256a3b atxmega256a3bu atxmega256a3u atxmega256c3 atxmega256d3 atxmega32a4 atxmega32a4u atxmega32c3 atxmega32c4 atxmega32d3 atxmega32d4 atxmega32e5 atxmega384c3 atxmega384d3 atxmega64a1 atxmega64a1u atxmega64a3 atxmega64a3u atxmega64a4u atxmega64b1 atxmega64b3 atxmega64c3 atxmega64d3 atxmega64d4 atxmega8e5 at43usb320 at43usb355 at76c711 at86rf401 at90can128 at90can32 at90can64 at90c8534 at90pwm1 at90pwm161 at90pwm2 at90pwm2b at90pwm216 at90pwm3 at90pwm3b at90pwm316 at90pwm81 at90scr100 at90s1200 at90s2313 at90s2323 at90s2333 at90s2343 at90s4414 at90s4433 at90s4434 at90s8515 at90s8535 at90usb1286 at90usb1287 at90usb162 at90usb646 at90usb647 at90usb82 at94k m3000 avr-gcc: note: supported core architectures: avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega2 avrxmega4 avrxmega5 avrxmega6 avrxmega7 avrtiny avr1 avr-gcc: note: you can provide your own specs files, see <http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html> for details make: *** [Makefile.mega0:124: optiboot_attiny1614.elf] Error 1

Could you please help solve this issue?

Thanks!

[WestfW]

I'm currently unable to build the bootloader myself You'll need to point it at a PACKS directory, or set it in your environment. (I have it set in my environment, so I didn't notice.)

make -f Makefile.mega0 optiboot_attiny1614.hex UARTTX=B2 TIMEOUT=8 LED=A7 RS485=A4 PACKS=/Downloads/Atmel.ATtiny_DFP.1.8.332 They're the "new" official way of adding new HW support to avr-gcc without changing the whole toolchain, and they're downloadable from https://packs.download.microchip.com/

I'll check to see if I can gets some signs of life here, even without "real" rs485... Are you using some well-known hardware (say, one of the boards DrAzzy sells), or your own board?

[jonspieg]

I'll try building it with PACKS once I'm next to my computer.

Let me know if you are able to program via uart. Also probing the direction pin during this procedure could help I guess.

I'm using my own board which works well with rs485, except for the flashing part :)

[YO6PVH]

Tested current version on ATmega328p. It works, but is picky about the RS485 adapter used on the PC side. With one works perfectly(CH340 based), with the other(PL2303 based) the response to 0x30 0x20 is 0x8A 0xFC instead of 0x14 0x10. This is probably due to the thigh timing when switching from transmit to receive. The same adapter works great in other applications.

[jonspieg]

Actually, my rs485 to usb adapter is using the ch340e chip (as well as sp485ee, which I don't really know). @YO6PVH Could you please send me a link to the exact adapter that works for you?

[YO6PVH]

The inside is same as in the picture in this link https://electronics.stackexchange.com/questions/348672/missing-component-on-the-usb-to-rs485-converter However. I just checked how they implement direction switching, and they employ the dirty trick inverting the TX line and passing on to the direction pin. In practice works for me on a 6m cable, but is not ideal all things considered. So might not work with a proper RS485 adapter, because the first bits of the response can come in before the adapter changes to receive.

[jonspieg]

@WestfW I've tried compiling using PACKS (the very same version you are using), but I'm still having some troubles. Something about avrxmega3 specified with '-mmcu=', but the build command line clearly states -mmcu=attiny1614 .

Here's the full output: C:\Jonathan\Hamezave\hamezave-omega\optiboot\optiboot\bootloaders\optiboot>make -f Makefile.mega0 optiboot_attiny1614.hex UARTTX=B2 TIMEOUT=8 LED=A7 RS485=A4 PACKS="'C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.8.332'" Using Compiler at: C:/Jonathan/Hamezave/hamezave-omega/optiboot/optiboot/bootloaders/optiboot/avr-gcc and Chip-defining PACKS at 'C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.8.332' avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax -DWDTTIME=8 -DLED_START_FLASHES=3 -DLED=A7 -DUARTTX=B2 -DBAUD_RATE=115200 -DRS485=A4 -Wl,-section-start=.text=0 -Wl,--section-start=.application=0x200 -Wl,--section-start=.version=0x1fe -Wl,--relax -nostartfiles -nostdlib -I 'C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.8.332'/include/ -B 'C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.8.332'/gcc/dev/attiny1614 -mmcu=attiny1614 -o optiboot_attiny1614.elf optiboot_x.c optiboot_x.c:1:0: error: unknown core architecture 'avrxmega3' specified with '-mmcu=' /**********************************************************/ ^ optiboot_x.c:1:0: note: supported core architectures: avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega2 avrxmega4 avrxmega5 avrxmega6 avrxmega7 avrtiny avr1 make: *** [Makefile.mega0:124: optiboot_attiny1614.elf] Error 1

Your help is greatly appreciated :) Thanks!

[jonspieg]

The inside is same as in the picture in this link https://electronics.stackexchange.com/questions/348672/missing-component-on-the-usb-to-rs485-converter However. I just checked how they implement direction switching, and they employ the dirty trick inverting the TX line and passing on to the direction pin. In practice works for me on a 6m cable, but is not ideal all things considered. So might not work with a proper RS485 adapter, because the first bits of the response can come in before the adapter changes to receive.

I'll order a bunch of these in the meanwhile :) My adapter probably does it a little better since it uses the ch340e variant which has a pin indicating whether the chip is Tx-ing, which is routed to the DE ^RE pins of the 485 chip.

[jonspieg]

@WestfW until I'll sort my issues with building optiboot for the attiny1614, could you please send me a binary with the latest code?

Thanks!

[jonspieg]

I was able to build the bootloader and I can confirm that the rs485 flashing feature is working as expected.

Thank you very much @WestfW