Optiboot / optiboot

Small and Fast Bootloader for Arduino and other Atmel AVR chips
Other
1.08k stars 396 forks source link

Customize bootloader for 328PB w RS485 #305

Open mahtoyy opened 3 years ago

mahtoyy commented 3 years ago

Hey, I am writing about an issue I encountered recently. I am a hobbyist, who recently started dealing with AVR in depth. I have a project where I want to flash code through UART1 on a 328PB board. The issue is that I am using rs485 which is half-duplex and needs to pull a pin to HIGH state in order to enable transmit. I tried just to pull the pin high in the putch() function and then set it low again but unfortunatelly it did not work. When I try to flash code the device cannot respond. Do you have any suggestions, maybe changing some registers or something like that? I would be very glad if you can help me through! Thanks in advance!

WestfW commented 3 years ago

I've seen a couple of rs485 efforts "go by", but I don't think I've seen one that reached the "I have it working great; if anyone else wants the code, see ....: :-(

I don't have an rs485 knowledge or equipment, so I can't be much help.

You will almost certainly NOT want to toggle the enable separately for every byte - when optiboot has something to transmit (not often, and only in response to commands from the other side), turn on the transmitter, and don't turn it off again until Optiboot thinks it is "listening." Also note that you'll have to to delay turning off the transmitter until the last character is fully shifted out of the the transmitter, rather than just when the buffer is ready (TXC vs UDRE, at least.)

mahtoyy commented 3 years ago

My thoughts were to make the mcu frequency higher and the transmission baud rate lower in order to make the chances of error lower(during PORT shifting). It is not a thing that will be used very often(if it works once on 10 attempts then it will still be fine :)) I have never played with bootloaders before but my first step is to make the bootloader work on UART1 first and then "adapt" it to RS485(if possible). It would be a huge help if you can guide me in the right direction to do that :)

WestfW commented 3 years ago

"make atmega328pb UART=1 LED=B5" or something similar should work fine for building a 328pb bootloader that uses UART1.

mikalai-kavalchuk commented 3 years ago

Hi @mahtoyy . I started adding RS485 support for optiboot to my fork of this repository. You can find it here: https://github.com/mikalai-kavalchuk/optiboot/tree/RS485_support The basic idea is that RS485 is a multi-point communication system. So I decided to implement addressing and of course additional control for the "direction" line, which is needed for the RS485 driver IC.

As a result you can't use standard loader (because of using addressing, COBS and CRC8).. But in a few days I will make a wrapper for the standard STK500 that you can use with the RS485 optiboot.

mahtoyy commented 3 years ago

These are awesome news! I will be glad to test it when it is ready! If I can assist you in any way you can tell me!

WestfW commented 2 years ago

@mikalai-kavalchuk do you have documentation for your rs485 use? Your optiboot-side support is much more extensive than what is currently here (copied from @SodaqMoja (also doesn't have usage documentation)), so it obviously needs host-side tools as well.

DRSDavidSoft commented 9 months ago

@mikalai-kavalchuk I seriously hope your proper RS-485 support, of which the addressing is a serious must, gets merged into master. Same with Dual Boot functionality using an external SPI flash that several other people have worked on, the addition of the bytes usage worth the added functionality.

WestfW commented 9 months ago

rs485 is just an electrical spec, and I guess an implication of half-duplex with a line-turnaround signal. If you want "addressing" and the like, we need a higher-level name.

By SPI, do you mean SD card? Have you pointers to this other code?

In general, I want to keep Optiboot as a very simple serial bootloader. Anyone else is free to start with it to make something more complex.

DRSDavidSoft commented 9 months ago

@WestfW Yes, you're absolutely correct. What I mean is that in a multi-point RS-485 design, a protocol that allows for addressable nodes is valuable, for example ModBus RTU or any other protocol that uses RS-485 as the electrical underlying transport layer. Fun fact, a bootloader by @wdl83 exists that implements ModBus RTU in the bootloader!

By SPI, I actually meant SPI external flash memory, though I think using an SD card should behave the same?

Here's the fork that has implemented this: https://github.com/LowPowerLab/DualOptiboot

I know you want to keep Optiboot a simple bootloader, but I'm sad to see so many forks of Optiboot being around, being outdated or incompatible with each other. I was pleasantly surprised to see MCUdude's fork getting unstreamed, as well as Majekw and Dr. Azzy's efforts.

Currently, I'm experimenting with Urboot, which has this functionality out of the box.

Trying to implement this stuff myself gives me a headache and I'm sad to say I haven't been any successful at this :-( I've got to say, Optiboot is a very impressive, collaborative project, and I've been using it on every Arduino and custom board for the past decade, so I'm tremendously grateful for all of the efforts you and the others have put into this project. It would be spectacular if the "master" Optiboot would also have the configurable functionality of being able to be remotely programmed, either using Dual Booting (so the new firmware is downloaded using user's code), or directly via RS-485 or rather any addressable method, really.

I would also appreciate it a ton if Optiboot had the ability to re-program live, running code, but I'm not sure if this would be possible, based on the information that MCUdude told me here: https://github.com/MCUdude/optiboot_flash/issues/3

In any case, thanks again for maintaining Optiboot and adding these new features! 🎉