My Arduino Zero based system - The next generation Arduboy?

I’ve mentioned previously that I think it would be a good idea to base the next version of the Arduboy on the Arduino/Genuino Zero. This would give a good improvement on speed, flash and RAM while remaining compatible with a standard Arduino product, for ease of development.

I bought a SparkFun SAMD21 Mini Breakout to experiment with. This product uses the same ATSAMD21G18 processor as the Zero and can use the same libraries in the Arduino IDE. Other than the processor, the system that I built uses the same components (OLED display, 6 buttons, piezo speaker, RGB LED) as the production Arduboy, plus I added a microSD card slot. I call it the Arduboy-Z because it’s based on an Arduino Zero (and a Z kind of looks like a 2 for the 2nd generation Arduboy :smirk:).

Yes, the OLED display is blue. I don’t have a white one with a CS (chip select) line, which is needed to share the SPI interface with the microSD slot. :cry:

Here is a comparison between the current production Arduboy and my Arduboy-Z:

Arduboy Arduboy-Z
Processor Atmel Atmega32U4 Atmel ATSAMD21G18
Bus Size 8 bit 32 bit
CPU Core AVR ARM Cortex-M0+
CPU Speed 16 MHz 48 MHz
Flash 32 KB 256 KB
RAM 2.5 KB 32 KB
EEPROM 1 KB None (32 KB emulated in flash)
USB Device only Device and Host
Speaker Pins 2 PWM capable 1 PWM, 1 10 bit DAC
microSD Slot No Yes
Real Time Clock No Yes (in the processor)

Things are looking pretty good so far. I’ve taken the latest development version of the Arduboy library and added in support for the SAMD architecture, while still keeping it backwards compatible with the existing AVR architecture. The SAMD code is almost fully functional (AVR is unchanged) but there are still a few things to do:

  • The display() and clear() functions could be optimized for speed, similar to the AVR versions.
  • There is no power saving code yet for SAMD.
  • Since there is no EEPROM and Arduino has not yet implemented EEPROM emulation in flash, the audio class doesn’t save the sound enabled/disabled state.
  • The development version that this library is derived from has had the tunes class removed. SAMD support has not yet been added to the ArduboyTones or ArduboyPlaytune libraries that are intended to be used with the latest Arduboy library.
  • There should probably be a standard interface added for the microSD slot, to allow loading sketches from it, as is done with the Gamebuino.

The modifications I made to the Arduboy library can be found in the ArduboyZ branch of my fork.

Sketches that don’t use EEPROM or sound, and have been modified, if necessary, to work on the production Arduboy with this version of the API, will usually run on the Arduboy-Z with little or no modification. The ArduBreakout example sketch, shown running in the photo above, only required the EEPROM code (for saving high scores) to be disabled, and the sound code changed to use Arduino tone(). My AruboyLife sketch just needed to be changed to use Arduino tone() (one line of code).

The speaker, RGB LED and microSD card slot are all working. To test the microSD slot, I wrote a sketch, based on an Arduino tutorial, which displays the directory of the card on the OLED display:

The DAC pin that the speaker is attached to will make some really nice sound possible, such as multichannel music, multiple volume levels and playback of recorded speech.

For production, if no additional hardware were added, I think that by moving the processor above the USB port and placing the microSD slot on the side at the lower right (where the processor was), the current Arduboy case could be used with just a modification to add an opening for the microSD slot. The existing battery and charge circuity could be used with just the addition of a 3.3V LDO regulator.

So @bateske, if you base the next version of the Arduboy on the ATSAMD21G18 processor, a good amount of the development work has been done. You can even use the name Arduboy-Z if you wish. :wink:


I think the EEPROM is really necessary. What would be the benefits of emulating it in flash?

There is a microSD card, so I suggest we use that to emulate EEPROM for legacy games instead of the flash. There is still quite a bit of software to write for that, but it’s doable, I think.

Have you tested how much faster (if at all) that processor is compared to Arduboy (or Arduino with same or similar processor)? Maybe we should write a benchmark. :smiley:

1 Like

I feel stupid for overlooking the ability to save stuff to an SD card. -_-


There aren’t any benefits. The ATmega32U4 microcontroller used in the current Arduboy has a separate 1K of EEPROM built in. The ATSAMD21G18 microcontroller I’m using doesn’t have a separate EEPROM area, but it provides a means to use part of the flash to “emulate” the same capability. With the ATSAMD21G18, if you want non-volatile data storage without using external components, such as an SD card or serial EEPROM, it’s the only way to do it.

As @Tomin said, it would probably be better for sketches to use the microSD card for non-volatile storage, though I’d still like to use a small amount of emulated EEPROM to store the currently defined System EEPROM values, such as the audio mute state.

Hopefully, the Arduino people will provide a standard means to access emulated EEPROM. If not we could do it ourselves.

For more info, see:

My ArduboyLife sketch runs noticeably faster (even though the library display() function hasn’t yet been optimised, so runs slower). Other sketches I’ve tried don’t show any speed difference visually because they’re paced by the setFrameRate() and nextFrame()/newframe() functions.

If you wish to provide any code “snippet” for benchmarking, I’d be happy to try it on both processors and report the speeds. I’d do the measurements using an oscilloscope, so no code to do timing is necessary.

1 Like

Awesome work, my brain is just buzzing at the thought of Arduventure developed for this!

@bateske buy this man a beer and ring up SEEED Studio :wink:


I still think an accelerometer is a must. :stuck_out_tongue: Have you thought of adding any extra features or are you pretty set with this design?

You should definitively prototype a PCB, send it to OSH Park or similar and see how it works.
How about including that awesome color display you mentioned in another thread?
Edit: this one
You should call it ArduZed, or ArduZee :smiley:


What would you use an accelerometer for other than detecting the player shaking the Arduboy?

(Oh, and the obvious:)


Games. There’s also this old handheld toy/game/thing I used to play with when I was a kid that I would love to recreate on the Arduino. It used something like an accelerometer. I can imagine someone using it in a racing game, like @emutyworks’s. :stuck_out_tongue:

Really fantastic work! :smile:

1 Like

An accelerometer (and/or a gyroscope and/or magnetometer) can be small and quite easy to interface to, so one could probably be squeezed in, if it was really desirable and the extra cost could be justified. I even have a board with all three, plus a barometer (another Kickstarter campaign) which I could hook up and experiment with, if it was considered worth it.

Personally I’m concerned about feature creep. I was hoping to come up with something that would address the most commonly discussed issues with the current Arduboy, without increasing the cost too much and being able to get it to market fast.

EDIT: Note that the fact that the ATSAMD21G18 provides USB Host mode opens up numerous possibilities for control. You could hook up a USB mouse or keyboard or game controller. A Sparkfun Pro Micro or clone could be wired to an accelerometer and programmed to emulate a USB mouse.

That would require a new, probably larger case, and probably a larger battery, meaning higher cost and likely longer time to market. My current design is intended to be a relatively “quick and dirty” evolutionary, not revolutionary, product. Also, compatibility with existing sketches was a consideration.


Totally understand! That’s one of the appeals of the Arduboy! It’s simple! If I had my way, we’d see another button, accelerometer, SD card slot, IR port and a lil’ faster processor. You’ve even convinced me that getting rid of EEPROM would be a good route to go, too.

Precisely this.

Core features such as volatile and non-volatile memory should always be primary because of their universal usefulness, but additional peripherals require more consideration given their esoteric nature. Perhaps a formal poll or debate would be more beneficial than the odd comment here or there.

I think when it comes down to it, USB-based peripherals would provide a better solution than building in some of the more use-case-specific peripherals into the console itself. Granted the speed of the USB bus might be a limitation in some cases, but there aren’t many peripherals that would require updating more than a few times a second, and transitions can always been interpolated if a sufficient way of measuring time is available (I’m not quite sure what clocks the Arduboy has available).

I must admit though, personally (aside from more work RAM and the already-being-considered SD/microSD slot) a 4-colour screen would be my favourite upgrade to have, more so than clocks, barometers or other peripherals. I understand the memory implications, but I feel 4-colour is sort of a happy medium when it comes to managing screen detail - not too much demand, but enough to provide depth via shading. Plus (with the right screen) it should still be possible to have a 2-colour mode to maintain backwards compatibility (within reason).

1 Like

I’d be more interested in the IR port than the accelerometer or a faster processor. Giving Arduboys the ability to communicate with each other (even if in a limited capacity) would be really handy. Admitedly that could probably be done with the USB, but I don’t know how common mircoUSB to microUSB cables are and IR is probably more convinient anyway. Plus it could be used for other purposes like emulating a remote control (if the protocol was known).

As an adide: I used to have a tamagotchi that had IR capabilities. Can’t quite remember which generation mine was, but it was probably like this:

1 Like

The game that used an accelerometer that I played was like a Tamagotchi. PvP with IR would be really cool to implement.

Again, for quick development and low cost, I was hoping that the existing case could be re-used, with just a minor change to add an opening for the microSD slot (creating a mold for a plastic case is quite expensive). If you can find a colour display that fits the bill, ideally at least 128x64 so existing sketches won’t need major modification, let us know.

You’d probably need to use something like a Vishay tfbs4652. It would only work over a few feet at best, would draw far more current when in use than all the rest of the circuitry combined, and is a fairly expensive part.

microUSB to microUSB cables are available, but it would probably be easer to get an OTG microUSB male to full size USB-A female adapter, and join it to the standard USB full size male to micro-A male cable that you use for programming/charging.

I keep looking.
I’ve found some 128x64 16-colour (4-bit) greyscale screens and some 96x64 RGB screens but I haven’t found the ideal screen yet. I hold out hope though. As I said, it’s an ideal rather than a must.

As for the IR vs USB cable thing, it’s a bit of a catch 22 given the major drawback to both methods. Aparently the reason micro USB to micro USB cables are so uncommon is because it’s against the spec specifically for the reason they wanted it to be clear which device is the host and which is the slave. When it comes to wireless connections, that’s made obvious via the protocol (e.g. TCP) but aparently the USB protocol doesn’t account for the situation where both devices are attempting to be the master device (or something along those lines).

IR would solve that issue because the protocol would probably be a custom protocol or there may be existing protocols that permit master-slave negotiation. But obviously then there are the other issues involved.

The only other option I can think of for Arduboy to Arduboy communication is some kind of radio-based wireless transceiver, but they face similar issues to the IR. It’s nice to know they’re SPI compatible though.

That’s what USB On-The-Go (OTG) is for.