Homemade Arduboy - AS flavor

Hi there everyone. For some time, I’ve been eyeing the Arduboy project and finally, I have found the time to make my own PCB. I’m planning to use the bare 1.3inch SSH1103 screen and 128MB flash chip. I’m at the step of creating a schematic diagram and I’m starting to get confused. The Production Arduboy Schematic seems to be missing a lot of information.

Can you confirm if I understand how the original works?

  1. The 32u4 is powered ‘straight’ from the battery
  2. The 32u4 is running at 16MHz, going slightly out of spec at lower battery voltages
  3. The screen’s DC-DC voltage supply can run straight from the battery

And I have some more questions (Mostly about the switch from SSD1309 to SSH1106):
4) The screen’s logic supply requires a maximum of 3.5V, so a 3.3V LDO is required?
5) If I power the screen’s logic with 3.3V, are level shifters / current limiting resistors required?
6) What Iref resistor should I use?
7) If I’m going with a custom PCB, which pin wiring should I go with? Does MrBlinky’s Leonardo/Micro option with new CART_CS offer the most flexibility & support all the features?

Thanks in advance for the answers :smile: Cheers!

1 Like

Basically yes. There is a battery protection IC on the Arduboy circuit board that protects the battery by disconnecting the battery’s negative lead. Many LiPo batteries will have this protection circuit built it.

Correct but the 32u4 has proven to be tolerant of doing this.


The following answers are with regards to the Arduboy’s SSD1306 based display. It could be different for another display controller.

The display’s absolute maximum voltage specification for logic is 4V. If you want to be safe you should power it at the recommended 3.3V and thus use a regulator. However, the Arduboy throws caution to the wind and runs the display at the raw battery voltage, the same as the 32u4, which can be as high as 4.2V

Yes, if you power the display logic at 3.3V then you should limit the display’s logic input signals to 3.3V. But again, the Arduboy powers everything directly from the battery voltage, so for it no level shifting is needed or used.

The Arduboy uses 390k

The best would probably be Arduboy/Leonardo/Micro with “new design” flash cart wiring.


Thanks for the answers :smiley: I am getting on the YOLO train and going with driving the screen and flash chip at full battery voltage.

Looking around the forum, there seem to be two other great upgrades: the expansion port and the MPU6050 gyro. Having them beside the flash chip required me to move the flash’s CS pin to A4. Ideally, I would stick to the original wiring, but I guess I won’t have to change that much in software.

I have planned another feature - a power switch in form of a button. I’m not a huge fan of small mechanical switches and having a ‘power’ button adds, in theory, another user input. However, I would need two more pins :confused: Or at least one, then I can drop the power button and make the reset button turn on the console & combination of i.e. A & B & reset to turn it off.
Should both the speaker pins be driven if I only have two-ring piezos?

Here’s what I’ve got so far:

I’m aiming to make the board fully assembled by JLC (minus the USB socket). Only the MCU is an extended part (& ridiculously expensive & out of stock), so I’ll steal it from Micro boards.

A common piezo disc, or one in an enclosure, can be placed directly across the two speaker pins.

You could consider putting a capacitor in series to eliminate the DC offset voltage you would get when only one pin is driven. This might increase or improve the sound somewhat, although at the low voltages used it may not be noticeable.

1 Like

I’ll grab a piezo, a Micro and see if I can spot any difference. I’ve read somewhere that the series capacitor on Production Arduboy Schematic is actually populated by a resistor. Do you know its value?

Looks like 220 ohm.

1 Like

I have looked into the SSD1306 and SSH1106 datasheets and confronted Aliexpress sellers of both types of 1.3" screens. They seem to have matching dimensions and pinouts. Only the capacitor recommendations are different.
Also, I went with having SDA and flash CS on the same pin and ordered SSD1306 screens to hopefully be fully compatible with Arduboy FX software.
That left me with one pin for the button-based power switch. I don’t know how easy it’s going to be to incorporate the required code - I may add a physical switch footprint just to have it as an option. Here’s what I got so far:

I had to order a screen and and a Leonardo to test everything before I design the PCB. The prototype should be ready by next weekend :smile:
Are Arduboy dimensions / screen & button placement documented? I suck at making ergonomic designs.

Not that I know of, except the width and height are intended to be the same as a credit card.

1 Like

Hello! All your assumptions look to be correct! You’re discovering as many others have the device plays loose with specifications in order to deliver a minimal implementation.

1 Like

Good choice for compatibility as the SSH1106 (aka SH1106) does not support the SSD1306 display update mode that Arduboy uses. (SH1106 only supports page mode)

You may also want to check out Arduboy VMU edition by @sjm4306 He uses a MAX16054 for soft on/off. May be easier to implement.

Had a quick look at your detailed schematic and puzzled why you put C1 for the reset in series.I’m not sure it will work properly. I’d expect it to be connected to GND instead. Note that a capacitor is not really necessary. If used the atmega will not be able to detect a power on reset properly (always detects reset).


That’s exactly what I had on mind. I’ve seen that it is possible to use the SSH1106 (thanks to you, isn’t it? :blush:), but all games have to be recompiled. While I don’t mind at all, I will be making 5 of them and probably distributing the spare ones between less tech-savvy friends.

The whole power switch solution is so hacky that the capacitor’s function may not be obvious.
When the reset button is pressed, PWR_EN is pulled low through D1, activating the Q2 mosfet and connecting VCC to the battery. At the same time, R1 and C1 form a high-pass filter - they turn the button press into a low-state spike of a constant length.
The idea was to make the 32u4 pull EN high, activating Q1, which activates Q2 so the board will stay powered on when the reset button is released.
The code would have to wait i.e. a second before pulling EN high. Then pressing the reset button for more than one second would turn it on / reset the 32u4, while a short press would turn it off.
Generally, Q1 is not needed, but some current would flow through R8 and the body diode of the EN pin, discharging the battery. Also, now when I think about it, D1 is not needed. I reused the circuit from another project, but the power switch was not acting as a reset button and it was needed so that the low state of PWR_EN would not be seen on a digital pin as a button press.
Does this make sense?

If a simple solution works, then it’s the best solution :smiley: It’s a nice contrast to my daily work, where every component needs to be derated ~50% and extensively simulated just to be sure.

Edit: I have put together a clone to test if my ideas would work. They won’t :stuck_out_tongue:

I don’t really have experience with 32u4 based boards and I did not know that resetting and power cycling have different outcomes. The bootloader takes way too long after a reset. I guess using the MAX16054 or similar and not relying on the 32u4’s code is the way to go.

I understood most of what it is supposed to do. But was just wondering about the capacitor. Like once it’s charged. How is it discharged so you can use it to reset the atmega again.

Yes. With the stock caterina bootloader a power on reset starts the sketch immediately but a reset triggers bootloader mode bootloader mode is exited after about 8 seconds of no programming activity.

I like the idea of using reset button to turn on/off Arduboy with reset button. a couple of years ago I made an experimental bootloader for Arduboy Mini (has no power switch) to use double reset to put atmega in power down mode. (~1uA power down current)

Here’s a copy of hex file. Not sure it uses SDA for flash cs chip select but it may be useful for some testing.


maybe OLED_RESET could be used as a power enable to control the power to display and other stuff to keep standby current to a minimum.

ofcourse using a MAX16054 would be the most simple. for a soft on/off

1 Like

I managed to add a flash chip to the setup today. While it wasn’t hard, I have encountered some problems.

When I was shopping for the flash, there were a few items that I needed and no shop sold all of them. I finally found one, but they only had the W25Q128 as bare 6x5mm WSON chips - so that’s what I got. The WSON chips have the same dimensions and pin spacing as SOIC-8, so A DIL-8 adapter should work. What I didn’t check is that the WSON has a central pad that is so big that it touches all pads on adapter boards. I had to cover it with kapton tape and solder it like this.
I also managed to buy a 1.8V only flash. Not having any 1.8V LDOs on hand, I used a buck regulator with an adjustable output and a 4-channel logic level converter.
I spent some time understanding what I had to do to write to the flash chip as the FXactivator asked for an updated bootloader - Cathy3K was needed.
The final problem was quite bizarre - writing to the chip took ~10 minutes and after a reboot there was only the action category and none of the programs worked. I have followed the ‘lite’ flash connection diagram and I have left the WP pin floating. Finally, after setting the pin high, the flash was burned in under a minute and everything worked!

One thing I didn’t expect was how the reset button works in Cathy3K - it loads the main menu in under a second! That could mean that the idea of using the reset button as a power switch could be still viable.
I tried to compile Catarina but since Arduino IDE no longer provides make I was not able to do it for now. I tried to go with Ubuntu in WSL2, but had no success there too.

Can you provide some insight into how you compile Arduboy bootloaders :grinning_face_with_smiling_eyes:? Maybe I’m overcomplicating things…

I’ll look into the bootloader you provided, just wanted to sort out the flash first. Though, I belive that the screen will draw a lot of current even in reset state - I think only the charge pump circuit has a sleep mode. As there is no need for the console to wake itself up, cutting power to all chips sounds like a much simpler plan.

1 Like

Great you got it all working.

Odd I can imagine the chip acting odd if the HOLD/RESEt pin is left floating but not WP. I recommend to pull-up both WP and HOLD / RESET.

I’m using my own assemby optimized version and built it using WinAVR.

1 Like

I looked through Cathy3K code, but WinAVR is what I was missing :smiley: I tried to start with the simpler Catarina written in C and eventually try to modify Cathy3K, but with WinAVR and your .bat files it is so easy to compile the latter that I will jump straight to step 2. I don’t have much experience with assembly (except for finishing TIS-100) but I guess checking a pin state and setting a pin high isn’t really rocket science.

Edit: Okay, I may be really wrong here but there is a small problem:
It seems that the bootloader available through the Homemade Arduboy IDE package is not the same as the bootloader in the Cathy3K repo (probably older).
When I burn it using IDE, the flash chip is being recognized and the menu loads. When I burned the compiled hex from the repo, only USB boot is displayed. If I upload FXactivator sketch, it shows that the flash is there - but if I try to burn it, I get an error saying it is not detected.
I burned the IDE bootloader again and read it with avrdudess. The hex files are not the same…
Now the flash may not be recognized because I have quite long wires coming to the chip and the level shifter is based on 10k pullups and nmos transistors - they may be just too slow if the reading/writing speed was changed between the bootloaders.
I may also be totally wrong, I’m outside my knowledge zone…

only the pro micro(alternate wiring) bootloaders from the installed package 1.2.9 are slightly different (Green LED fix). However the bootloaders are the same if you use the bootloaders from the bordpackage source folder.

Then you’ve probably burned the wrong bootloader. Which pinl do you use for flash chip select and which hex file did you burn?

Welp, wrong bootloader sounds like a fitting cause. I burned the ‘standard’ bootloader but seeing that the bootloaders stored in IDE come in menu/game and sda/rx flavors I should have suspected that some changes have to be made…
Looking through the .asm, CART_CS is set to 2, PD2 is RX… :sweat_smile:

I use a bunch of #ifdef’s for building different versions. The batch file creates 76 variants which are also included with the Homemade package. The readme file will also give a hint which hex file you need :wink:

1 Like

Well, you were right, the versions are the same - but I was using files from the wrong repository :see_no_evil: I was using the files from your discontinued (I think) “Arduboy” repo instead of the bootloader’s own one. Compiling and uploading using avrdudess work wonderfully so I can start modifying it :smiley:

Edit: Sooo I made something:

VID_20211020_2357321 (1)

And it works wonderfully! The bootloader sets PF1 low when all pin modes are set. Then, after some initialization steps, it checks if the up arrow is pressed. If yes - it goes into an infinite loop, if not - it sets PF1 high and continues initialisation.
You can ‘break’ it by pressing the reset button very fast - then, it shuts off because PF1 is not set high fast enough.

The circuit works as it should, but there is a problem that I cannot overcome - some games modify the state of the PF1 pin. Circuit Dude, Catacombs of the Damned, etc set the pin low, cutting the power off. I cannot see a way around this. I could add an inverter, but I’m sure I will find some games that set the pin high or activate the pullup. In a different MCU, some peripheral could be multiplexed to the pin instead of the GPIO, but here it is not possible.
My last idea is to use the TX_LED or RX_LED pin. The diodes are rather redundant, but the same thing may happen - do you know any games that use them…?

Your doubts were on point, the circuit I proposed didn’t work. Making a prototype pays off :+1: I had to add a resistor to discharge the capacitor:

I also played a bit with element placement. I have stuck with nearly identical dimensions and screen placement, but I had to move all buttons up towards the display.

As the expansion port is right under the screen and the cheapest ~180mAh LiPos I could find were 5x20x30mm, I was thinking about placing all components on the top side. The PCB would act as the back of the enclosure - maybe with a thin layer of PET to isolate any contacts. If I were to add testpoints, they will only fit there. Also, I could not find SMD angled goldpin headers, but I swear I have seen them. I’m not sure about their durability, though.

The pushbutton pads should support the standard clicky switches as well as the 6x6x5mm silent buttons. I saw some people use them, do they feel nicer or are they just used because of the lack of sound?

I’m also pretty sure I will drop the MPU6050 from the schematic - it’s just too expensive, especially if making 5x, 10x boards. And I can always make an expansion card using the generic gyro boards - they have all that is needed, including an LDO.


This whole thing keeps bugging me. I wanted this project to have something unique, hence the idea of dropping the switch. At the same time, MAX16054 and other ON/OFF controllers are really expensive for what they do.
My last idea to save the on/off/reset button is to add an SR latch. Then, it wouldn’t matter if a game would change the state of PF1. Pressing the reset button would have to:
a) Create a low state pulse on 32u4’s reset pin
b) Reset the latch
c) Turn on the power without setting the latch
The PF1 pin should set the latch and the set input should be dominant over the reset input.

Thus, I extended the circuit. It is possible to add a latch IC, but I wanted to do it with discrete components - it’s cheaper and more fun.
I created the following schematic in LTSpice and simulated the circuit:

It requires 7 more elements than the current circuit. I think there might be a way to rearrange things to lower the part count even more. Nevertheless, here’s what the simulation shows:

It should work. If I end up using this circuit, I will surely add a footprint for the switch just in case - I don’t want to end up with five consoles that cannot be powered on.

Edit: I really wanted to get rid of the second 0.1$ p-mos and managed to do it :smiley:
Only four new components are needed - two resistors, a capacitor and a diode.

Works on the same basis. The only downside is that it depends on the VCC capacitance and the load - VCC has to collapse before C3 is charged. I believe that turning on all LEDs will be enough to make sure that happens.