Skip to content
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

Update bootloaders #535

Open
mirh opened this issue May 18, 2023 · 4 comments
Open

Update bootloaders #535

mirh opened this issue May 18, 2023 · 4 comments

Comments

@mirh
Copy link

mirh commented May 18, 2023

I get that that your QA is infinite, that you want to care about only production models, and that there's much else ado too (in fact, updating avrdude is also sorely in need imho, and it would in turn certainly come handy for this issue)

But frankly enough, optiboot wasn't exactly the most polished gem on the shed back in the days, and after almost a decade from the last version bump the amount of shortcomings that have been piling up here is just huge (my pet peeve is reading EEPROM returning instead the flash memory, but I suppose that 2023 could also be the year of auto-baud not hurting either).

IMHO you should either update it (I believe that versions with all features enabled in just 512B should exist) or switch to Urboot.

@MCUdude
Copy link

MCUdude commented Jun 14, 2023

I wouldn't expect Arduino to update their bootloaders. Optiboot 4(.4?) does work for what the official Arduino packages are providing, so from their point of view, a newer bootloader won't provide new functionality for the average user.

Personally, If I'm using a bootloader, I would like to have the best one possible, combines with the best upload tool there is.
That is why all my "classic" 3rd party Arduino AVR cores will move over to Urboot sooner or later. It won't make much of a difference for the average Arduino user, but you'll get auto baud, EEPROM upload/download support, sketch metadata support, write to flash from a user application (SPM), and better Avrdude integration. All this in a package that's smaller than Optiboot in size.

Avrdude 7.2 will be released this summer, and it's yet another leap in terms of functionality compared to 7.3. Meanwhile, Arduino still uses 6.3, which was released in 2016. In 7.2, the terminal mode (-t) has gotten an overhaul, and you can read, write and analyze all memories, upload files/data to fixed memory locations, and have byte-access r/w for all memories. There is also a fuse configurator you can use instead of bothering with remembering fuse bits.

@mirh
Copy link
Author

mirh commented Jun 14, 2023

As you know avrdude is hopefully going to be updated soon™
And I suppose the awfully long time might be half-way explained by the program itself kinda changing its development process (and maybe on this side of the affair, by the arduino-cli and arduino-ide revamps sucking away resources?)

Then, I do guess time is of the essence too... But while a generic "one day" timeline still kinda makes sense eventually, not even an once-in-a-decade update would look overly lazy.

p.s. "being bugged" is already present functionality waiting to be actually delievered tbh (unless the point is that anything past booting a sketch isn't really of concern for the average joe and you could call it a day)

@MCUdude
Copy link

MCUdude commented Jun 14, 2023

Arduino has actually released a statically build version of Avrdude 7.1, here: https://github.com/arduino/avrdude-packing. They just haven't bundled it with their Arduino AVR/megaAVR board packages (yet?).
Arduinos avrdude-build-script repo is AFAIK dead.

I'm not trying to defend them, I'm just trying to make sense of why they don't fix obvious bugs. And the most logical reason to me would be that Optiboot 4.4 "still works", and Avrdude 6.3 "still works" for what they are using them for.

@mirh
Copy link
Author

mirh commented Jun 15, 2023

And I'm not trying to push anyone, but it really just boils down to how low of a bar you want to set for the "it works" expectations.
I wouldn't know who the average "user" could even be expected to be then (like.. the most vanilla scenario is still using an IDE to upload code to a microcontroller board, isn't it?) but although it's unlikely for any given single bug to be encountered, conversely I would argue that there are enough of them that the probability of bumping into at least one is high.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants