-
Notifications
You must be signed in to change notification settings - Fork 403
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Customize bootloader for 328PB w RS485 #305
Comments
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.) |
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 :) |
"make atmega328pb UART=1 LED=B5" or something similar should work fine for building a 328pb bootloader that uses UART1. |
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 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. |
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! |
@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. |
@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. |
rs485 is just an electrical spec, and I guess an implication of half-duplex with a line-turnaround signal. 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. |
@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: 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: MCUdude/optiboot_flash#3 In any case, thanks again for maintaining Optiboot and adding these new features! 🎉 |
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!
The text was updated successfully, but these errors were encountered: