44-Pin QFN Surface Mount Package. 32k flash, 2.5k ram, and 1k eeprom. Running on an external oscillator at 16mhz. Some of the memory is taken up by the Leonardo bootloader and drivers and the device is also technically overclocked. The processor can be programmed by the onboard bootloader via USB. If the software program has crashed and cannot be programed by usb, you can reset the device manually. The entire chip can also be reprogrammed via ISCP test pads on the front and back of the board.
128x64 pixel, 1-bit black and white active matrix display. The OLED display requires no backlight and is very power efficient. Because each pixel is actually it’s own led it is also very a crisp and sharp display making it look great despite its small size and low resolution. The display is controlled through Hardware SPI, recieving both initization and graphic data through the serial communication. Comunication is one way, there is no way to read data from the display.
The controller is a SSD1306 which is installed directly on the glass of the OLED. It directly drives the pixels on the display also including a voltage boost converter.
Two pins, A2 and A3 directly drive a piezoelectric element inside of a small black plastic housing. Caution there is no circuit protection these pins: Theoretically there could be some problems with driving both pins as outputs, we suggest configuring one pin to input. In practice this has not caused any issues to date but please comment if you have any issues!
#define SPK_1 A2 #define SPK_2 A3
##Buttons##
6 Momentary Tactile Buttons are arranged on the PCB in the layout best suited for gaming. A directonal pad on the left and two action buttons on the right.
#define RIGHT 5 #define UP 8 #define LEFT 9 #define DOWN 10 #define A_BUTTON A0 #define B_BUTTON A1
Blue LED
The surface mount LED is connected to the RX port of the atmega32u4. Under normal operation this pin will be illuminated during a USB connection and also during program upload. The LED port can be accessed through the arduino IDE on pin number 17.
#define LED 17
Battery Connector
On the bottom of the board is a connector for a CR2016 battery. Operating under battery voltage is out of specification for the processor and is for testing purposes only. Battery should last around 3 hours or more.
*Documentation linked is for reference only, Arduboy is not affiliated with the hosted website.
Looking at the first picture, it shows the piezo speaker as being on pins A2 and A3. By that I would assume that one lead of the speaker was connected to A2 and the other to A3, or that both A2 and A3 were connected to one lead of the speaker through some sort of mixer.
However, looking at the following board layout picture, I can see that pins A2 and A3 (physical pins 38 and 39) are actually directly shorted together!
Everyone with a dev kit, unit make sure you don’t set A2 and A3 as digital outputs at the same time! You risk damaging the chip by shorting two outputs together.
Why was were the pins wired this way? What purpose does it serve?
In practice the atmel chips are really robust. We are looking at adding pin protection and a resistor. If you have a problem with your dev kit or have specific suggestions for how to fix some problem you see… please let us know
I’m a big fan of the rugged circuits setup. What they say is true but it is also advertising for their board. There is internal protection on the chip, they would say it isn’t enough of course. Series resistsors is certainly some extra protection and we have considered it. The dev kit is meant to test the hardware!
@bateske, Please provide a reference to where Atmel documents that there is internal protection against excessive current through a pin configured as an output.
From the datasheet, in section 10.2.6 Unconnected Pins:
Connecting unused pins directly to Vcc or GND is not recommended, since this may cause excessive currents if the pin is accidentally configured as an output.
Although you’re not connecting the pins to Vcc or GND, shorting two outputs together then setting one high and the other low is essentially the same thing.
From the same datasheet, in section 29.1 Absolute Maximum Ratings:
DC Current per I/O Pin . . . . . . . 40.0mA
Why would this rating be necessary if there was protection? Again, refer to some Atmel documentation that confirms that there is internal overcurrent protection circuitry.
Instead of resistors, I suggest you use two diodes:
But for the dev kit, unless it can be proven that it’s safe, I’d still warn against attempting to use both A2 and A3 as outputs at the same time
Informative and well thought out post @MLXXXp, much appreciated. Although I have nothing in particular to add to the conversation, and would normally just send a like to the post so as not to clutter the topic… you help set the standard for what a productive post can look like, and we appreciate it.
i have a question
when i received the board today it was possible to power the board from the USB port
i went to a shop to go for a battery and dit some playing with the game
but now when i wanted to play with the code and tried to write a basic code it was not possible anymore
tried everything also when the batt is in. the blue led goes one time on and immediately back off. when i get connection to the board after several attempts and flash a code it shut down the board so the connection broke
but just power the board with usb is not possible anymore
did i something wrong
I’ll have to retract my suggestion to use two diodes to mix the speaker signals.
Adding diodes makes the pins only capable of driving the output high, instead of both high and low as when directly connected. This will work with a magnetic coil speaker because the low impedance of the coil is enough to pull the signal down. However, a piezo speaker has a very high DC resistance so there’s no path to pull the signal low.
You could put a low value resistor in parallel with the speaker but this is a waste of power. The easiest, but possibly a bit costly, way would be to use an or gate, such as a 74LVC1G32, instead of diodes. You might also require pull-down resistors on the gate’s inputs because the processor’s pins will start as high impedance inputs until set as outputs.
However, I still question why you want have two pins able to drive the speaker in the first place? This only seems useful if at least one pin has the ability to generate a tone strictly via hardware. That is, you use software to set the frequency and start and stop the tone, but no software need be executed to toggle the pin to generate the tone.
I think the only way to create a hardware generated tone is to use PWM, but neither A2 or A3 are PWM capable.
If software is required to set a pin high and low to generate a tone, then if you want to do the equivalent of connecting two pins to the speaker, you just have to use a software or function to mix two signals to a single pin, that would have gone to separate pins.
So, can anyone offer any reason why both A2 and A2 should be driving the speaker, instead of only one of them?
I’ve thought of both these points and need to do some testing. It WOULD be nice if A2 or A3 were PWM capable… seems it would offload a lot of the logic for tone generation.
I think the problem is interrupt resolution for multiple tones. It’s easy to play say 25khz and 22khz, but if you want them both one a single pin then just to do the proper virtual toggling you’d have to find some interrupt multiple that would allow you to accurately hit both - and it’s going to be a lot smaller resolution than just a single tone. And now you can’t just flip the pin each time you have to do some counters and math to figure out which pin it’s time to flip, etc. Pretty soon you’re using 50% of your CPU just for the music interrupts. Just a guess at one of the big potential issues.
I’m not sure if it’s quite that bad (or worse), but I think that’s a big part of it.
To be clear lower notes are a lot less of an issue than the high notes… and our tune library goes as high as 25Khz.
Can’t you just use two timers, with one for each tone? Two interrupt service routines could both use a single physical pin. Each just has to keep track of a separate virtual pin (using a RAM location) that the other can read. After toggling its virtual pin, a service routine just ors it with the other’s and sets the result on the physical pin.
I’m not sure the “correct” value for 1/0 is 1 though… I don’t know enough about the electricity of the matter. Could be it’s 0.5 which means you’d have to PWM the pins at a high enough frequency to get the same output two sep pins would give.
Top View
