It was mentioned here and in the kickstarter comments that besides the SRAM, we are really going to be limited by the flash memory available to us, some of which is taken up by the bootloader.
How much of that 32kB is taken up by it on the Arduboy currently?
I’ve looked around online for some information about it, and it seems that the default bootloader is 2kB, but an optimized one might be available that is only 512 bytes. However I don’t know much about the requirements of the Arduboy, and whether this optimized one might not meet the device’s needs.
Just curious about how much space is available to us for software planning purposes.
EDIT: Another site mentioned that optiboot might not support USB or EEPROM, so if true that would probably be a dealbreaker. Still, just looking for info on what space is going to be already used.
We haven’t checked, but it does have USB functionality. I think it is the 2kb one.
When I get a chance to sit down with the compiler and such again I can follow up. I see you ordered a dev kit (thank you!) so I expect you might be able to do this before me. In a couple weeks there will be a lot of comprehensive updates on how to work with the hardware, we realize things are a little bumpy right now so stay tuned!
Looks like compiled the bootloader is 4,088 bytes. Not much room there to add anything. USB code just gets bloated quickly.
Good news is it’s pretty easy to free up about 300 bytes of the boot loader… would allow for moving some data/init there (LCD boot up, Arduboy logo) and also supporting some nifty features like paging data to flash (i.e., writing to flash from inside your sketch).
Still not sure that is enough room for a SD card bootstrap. At least not if you have to deal with the MSDOS FAT. Perhaps if the SD card were specially formatted to have the loader sketch at a specific location on the card and the card was formatted a little wonky.
You’d have to double flash to load a program though… first flash to load the loader from the fixed location, then the sketch (which now has room to breath in 28kb) can scan the FAT, show you a NICE UI of games (with images) let you choose one, then that would flash and you’d be playing it.
If it’s not already in the bootloader, and we have the space:
At a minimum, I think it would be a good idea to set the proper state for pins that have hardware connected to them.
- Buttons to INPUT_PULLUP
- Both Speaker pins to OUTPUT, LOW
- The three RGB LED pins to OUTPUT, HIGH
- OLED Display pins to a proper pre-init state.
- RXLED (LED 1) and TXLED (LED 2) to OUTPUT, HIGH (Is this already done as a result of the USB code?)
- Anything else?
If the bootloader ends up going further than this for some of the hardware, such as fully initialising the display, that’s fine.
That would all be fine if we have the room - and we make users aware that’s what we’re doing - ie, we’re shipping with a firmware, not a boot loader - i.e., it’s not something you can just replaced without likely bricking your device unless you knew what you were doing.
I think if we get an SD card figuring out swapping games is going to be a higher priority than the init stuff. So far I’ve only found 400 bytes to spare without completely throwing away the flash over USB functionality.
This is fun to discuss but doesn’t have much practical bearing until Arduboy 1.1 on similar hardware is confirmed since I really think few (if anyone) is going to re-flash their boot loader on the existing hardware. The opportunity is to SHIP a different boot loader the next time around.
True. I forgot that the production Arduboy has already been manufactured in quantity and shipping has begun.