There was a time, not so long ago, when all the cool kids were dual-booting their computers: one side running Linux for hacking and another running Windows for gaming. We know, we were there. But why the heck would you ever want to dual-boot an Arduino? We’re still scratching our heads about the application, but we know a cool hack when we see one; [Vinod] soldered the tiny surface-mount EEPROM on top of the already small AVR chip! (Check the video below.)
Aside from tiny-soldering skills, [Vinod] wrote his own custom bootloader for the AVR-based Arduino. With just enough memory to back up the AVR’s flash, the bootloader can shuffle the existing program out to the EEPROM while flashing the new program in. For more details, read the source.
While you might think that writing a bootloader is deep juju (it can be), [Vinod]’s simple bootloader application is written in C, using a style that should be familiar to anyone who has done work with an Arduino. It could certainly be optimized for size, but probably not for readability (and tweakability).
Why would you ever want to dual boot an Arduino? Maybe to be able to run testing and stable code on the same device? You could do the same thing over WiFi with an ESP8266. But maybe you don’t have WiFi available? Whatever, we like the hack and ‘because you can’ is a good enough excuse for us. If you do have a use in mind, post up in the comments!
You can use it to backup a previous version of your program before any modification. This way you can quickly revert to the previous one in case you messed up.
Or use git.
See it as a hardware git.
Enterprise grade network components actually allow you to do that. Ciscos have just a flash memory where you can store some firmware files. HP Procurve/Aruba switches offer primary and secondary flash storage for the firmware files. So whenever something goes wrong with your updated firmware, you still can revert to the old one without having to copy over another image.
Maybe in a master/slaves context. You could maybe program all your devices the same, and then switch one to be a master easily. Can be useful if the program and/or the server programs takes more than half the flash space.
(just a wild idea)
Cool kids were dual booting, real power users left windows behind.
…. and installed wine???
Heck from where I’m from, you can’t even do banking without activeX
Unless you play computer games, you can’t play games on Linux unless you use a wine wrapper and those kill the performance.
Except that hasn’t been true in a while, when windows 8 and their app store said they wouldn’t allow ‘in-app purchases’ valve told microsoft to shove it and that they didn’t need their two-bit operating system. This is why SteamOS is a thing and Steam on linux is so big, they’re using their influence to force developers to develop for linux.
Yes, but these are relatively recent developments (I do love Steam) and the article said “back in the day”, a timeframe for which the assertions of gaming sucking on linux are true.
You’re right, but your point is irrelevant. :)
We were dual-booting because how else were you ever going to manage to use all 80MB of your harddrive?! 40 for Windows, 40 for Linux…
There was a point where it seemed reasonable you had Dos/WFWG3.11, Win95a, OS/2 Warp, and Slackware configured to quad boot, probably with LILO unless you had some spawn of lucifer drive overlay software.
Switch between debug and production code.
As a professional software dev, you should not be debugging on your production device. If you cannot afford to have 2 MCU boards, then I would argue that you probably dont truly have a “production” environment anyway.
A possible use for this would be an on-board backup copy, in case the primary software bits decided to rot, a little watchdog could toggle this to the backup side and reset the MCU… If the backup came online and passed a self-check, it could even reflash the “primary” from the backup? A self-healing system?
I have this kind of setup on my ebike. After small bugfixes I’m often lazy enough to test them, so instead I’ll test them the next morning. But I still have to get to work somehow, so if it fails, I just have a button to restore previous working firmware. And if it works, I press another button which copies the firmware to backup area.
Probably not “real production” by your standards, but pretty useful nonetheless.
I kind of disagree. You can have a production mode and an engineering mode or a production mode and a failsafe mode. Walking an enthusiastic customer through a customizing procedure is much better than product return. Granted, you might not need two firmwares for that, just a toggle switch for the existing one.
I know what it’s good for…. if you do one of those arduino arcade things and also want to do mini basic or something…. or anything else that might use similar display/input and you might like to switch. Or didn’t we see forth and lisp as other options to switch between.
That’s exactly the same concept that MySensors uses to provide over-the-air updates.
Synthesizing previous comments a little, how about a fail-safe system for field updatable firmware? Imagine uploading new firmware to a satellite – you don’t want to permanently update the only flash on the device, blindly assuming that the update will work correctly, because you’ll never be able to plug a serial cable into that device, ever, once deployed.
So instead you have multiple “slots” for system software, and only update one at a time. You could have some kind of reversion system, where a failure in version n causes a reboot into n-1, and too many failures results in booting into version zero, a debug mode.
Pretty cool trick kinda reminds me of what some motherboards that have a backup bios chip do.
If there were no Arduino, would Hackaday exist?
Yeah, we’d just argue about 80c51s vs PIC and Basic Stamp.
What a sacrilege. Obviously the basic stamp is superior! (in some very specific way, for a very specific use scenario, but I’ll defend my stupid stance until death)
Maybe the dual boot can be used for a recovery mode if an update fails???
Think this is more or less the same thing, without the sophistication of a custom bootloader…
http://www.hobbytronics.co.uk/arduino-external-eeprom
What appeals to me is having a big ROM you can switch out all of these…
http://www.nootropicdesign.com/hackvision/games.html
Plus this..
https://halfbyteblog.wordpress.com/tag/tiny-basic/
and a bunch of saved programs for it.
and you’ve got a neat little system.
if only there was a THIRD system of memory, a three-memory system with the usual RAM and FLASH but with a third bus titled program-RAM, one that wont wear-out from constant rebooting, if this project were to dual-boot into the other system every 2 mins flash wears out quick… but for once-a-week updates ect its perfect.
I’m using ESP8266 with Arduino core. And I see a big use for it.
When your primary bin is too big to flash via OTA.
So, you keep a minimal version, as a second bin, capable to flash via OTA.
Then, enter in second boot and overwrite the primary bin.
The gamebuino classic loads programs from an SD card which it flashes to the Atmega328p. Not sure what bootloader it uses. Neat trick though!