This is my quick and dirty guide to get up and running fast with single .ino file. I think this is also useful to anyone, who hasn’t got their Arduboy yet. You still probably need to have the Arduino IDE installed but with these steps you can bypass it.
Compiling & uploading to Arduboy device: install Arduino Command Line Interface by following the instructions closely. Download here. Make sure the example in the README compiles and you’re able to upload binary to your Arduboy.
Emulation: to run the compiled code in emulator instead of uploading it to the device each time, use simavr-arduboy. Follow the build instructions closely and you should end up with sim_arduboy binary to which you pass *.hex file generated by Arduino CLI (step 1).
Automation: Every time you save your file(s), compile the code and execute/re-run the emulator with the fresh binary. For this, I hacked a little Makefile:
Out of curiosity, when you say ‘write the code in my own editor’ do you mean something you wrote yourself or anything better than the Arduino IDE? There are other options, including VSCode and PlatformIO that can compile Arduino code from within their IDE - albeit using the Arduino code below it.
I personally use VSCode and think its pretty good and its the right price! (Free)
If the Arduino CLI doesn’t work out for you:
Do you run VIM in a terminal window on some sort of GUI desktop?
If so, do you mind installing and running the Arduino IDE just for compiling and uploading?
If so, you can easily use any external editor for writing code, and then compile and upload from the Arduino IDE.
In the IDE, open Preferences: File > Preferences
Select: ☑ Use external editor
Click on OK at the bottom right
Now, when you open your sketch in the IDE, the code will be greyed out and read only. If you edit and save your code using an external editor, the changes will be automatically updated in the IDE when you switch to it. You can then use the IDE to compile and/or upload.
So long as when you save the document you intend to flash it. I wouldn’t worry about running out of reflash cycles, you should be good for over a million flashes. Which if you were continously developing 24/7 would only last you a couple years so, should be ok!
Assuming the datasheet is accurate, that would mean that if you were doing 28 flashes per day the flash would pass the guarantee within 1 year.
(Obviously it’s likely to last longer than that, but after that point it’s anyone’s guess.)
This usually isn’t too much of a problem,
but if you’ve got a tool set up to flash the Arduboy every time a code file is edited then I don’t think 28 flashes per day (or even more) is an unrealistic figure.
The data sheet says lots of things! We don’t live in a data sheet however:
Just to make it clear, if you run out of write cycles (doing normal things, and not destructively testing them) on your Arduboy, let me know at contact.arduboy.com because you’ll be the first!
I’ve only heard a few stories of people wearing out their Arduinos, and in those circumstances they were actually being used every day being re flashed dozens of times per day for years on end. Being used in classrooms and labs.
I crunched the numbers for their “2 hours each weekday and 8 hours over the weekend on their Arduino, flashing it once every 5 minutes” scenario,
and it comes out at 32.0512 weeks, (or roughly 224.3589 days),
which is just ~2/3 of a year (there’s around 52.17857 weeks in a year).
2 * 60 / 5 = 24 (flashes per weekday)
8 * 60 / 5 = 96 (flashes per weekend)
(24 * 5) + (96 * 2) = 312 (flashes per week)
10,000 / 312 = 32.051282051282051282051282051282 (flashes until ‘death’)
I don’t think the 8 hours per week figure is realistic for game development.
For hardware development maybe, but not game development.
Either way, flashing the chip every time a code file is saved would tally up to more than that,
which is my main point here.
As for the ‘dangerous prototypes’ project,
the article only specifies EEPROM figures, not flash figures,
and EEPROM has 10 times the number of writes anyway.
This is my point.
Code files are edited potentially 25-100 times per day depending on the individual,
so flashing every time a code file is more than just average use.
I’m not saying average users have to worry about flash usage,
I’m saying that flashing every time a code file is saved is a cause for concern.