Continuing the discussion from Dev Kit Hardware:
I’ve started this topic to discuss what we know, speculate and suggest about what the final specifications and design of the Arduboy will be, as delivered to backers of the Kickstarter campaign.
I’ll start with details of my thoughts on the subject. Brace yourself, this is a long post!
I’ll refer to the existing Development Kit version, that some people already have and are testing and experimenting with, as the Dev Kit. I’ll refer to the example product shown on Kickstarter as the Prototype.
The final version should be as close as possible to what is described and specified in the Kickstarter campaign, including anything stated by the Creator @bateske (Kevin Bates) in updates or comments.
Kickstarter specifies an Atmel ATmega32U4 and that’s what the Dev Kit uses, so this is pretty much set in stone.
Kickstarter specifies a 180 mAh Thin-Film Lithium Polymer battery will be used to provide portable power. I’m guessing this likely is a GEB 014461. It’s specified as having a nominal voltage of 3.7V but can be as high 4.2V when charging or fully charged and can safely be used down to 3.0V. Based on typical lithium-ion battery discharge curves the voltage will probably drop quite rapidly when about 3.4V is reached.
The battery is charged from 5V provided by the specified Micro-USB port. A charge controller will be required to safely charge the battery. The photos of the Prototype show a 5-pin SOT-23 IC in the lower left corner. This is probably the charge controller (maybe a Linear Technology LTC4054).
I assume that the Arduboy will be able to run from the USB port while plugged in to charge the battery. The easiest way to allow switching between battery and USB power would be to actually just run the unit from the battery all the times. The 5v from USB would be fed to the input of the charge controller. The output of the charge controller would go to the battery and also to the power switch. The other side of the power switch would go the the rest of the circuitry.
As already stated, the battery voltage can be as high as 4.2V. The ATmega32U4 can operate safely over the full battery voltage range but the OLED display is only specified to be powered from 1.65V to 3.3V. If the chip at the lower left on the Prototype really is a charge controller, then I don’t see any sign of a voltage regulator for the display. I hope that the display isn’t being powered directly from the battery. If it is, I would add a 3.3V LDO regulator, such as a Micrel MIC5205, to power it.
If the ATmega32U4 remains powered directly at battery voltage, there is still a problem. The outputs that are driving the display inputs could go as high as 4.2V, which exceeds the absolute maximum 3.6V that the display allows. Level shifting circuitry could be added to safely drive the inputs, but it’s easier to just run the processor on the 3.3V from the regulator, as well.
The regulator output might start to drop when the battery goes below about 3.4V but this wouldn’t be a problem. There won’t be much life left in the battery when it’s between 3.4V and the 3.0V minimum, anyway.
Processor Clock Speed:
I think almost everyone agrees, from discussions under the Arduboy’s clock speed topic and elsewhere, that the ATmega32U4 is not running within spec, at 16MHz, if Vcc is below 4.5V (and thus the Dev Kit, at 16MHz with a 3V coin cell is being clocked out of spec). At 3.3V, up to a 10MHz clock is safe. However, looking at the ATmega32U4 datasheet I believe that only a 8MHz or 16Mhz clock can be used if you want to use the USB interface (please correct me if I’m wrong). Besides, any speed other than 8MHz or 16MHz could possibly cause problems with some aspects of Arduino compatibility. Therefore, I think an 8MHz clock should be used.
There’s been some discussion and desire to allow software to be able to switch the clock up to 16MHz, at the risk of possible unstable operation. This may be possible. A 16Mhz crystal would be used to generate the system clock. The CKDIV8 fuse would be programmed, which would set the clock prescaler to divide by 8 on power up, resulting in a 2MHz CPU clock. The bootloader would then set the prescaler to divide by 2, for 8MHz, and make any other settings so that all internal peripherals would behave exactly as an 8Mhz Arduino system would, before the user’s sketch starts executing. A sketch could then use a library function or some other means to switch the clock and peripherals between 16MHz and 8MHz operation.
I not sure if @bateske would be interested, or have the time to implement this overclocking capability. Those wishing to have this should probably implement and test it on the Dev Kit, to show everyone that it works and has no impact on 8MHz operation, and convince @bateske to include it in the final product.
Personally, I think just an 8MHz crystal should be used, with no overclocking capability. This would avoid possible disappointment for someone whose overclocked games kept crashing because their Arduboy had a processor with a newer revision or from a batch that wasn’t tolerant of running out of spec. It would also mean that it would be likely that a custom bootloader wouldn’t be required. A standard ATmega32U4 compatible Arduino bootloader could be used, meaning one less custom thing to develop and maintain.
@bateske has said that the Arduboy will be fully open-sourced, both hardware and software. I’m guessing that he wouldn’t object, and possibly even strive to make it relatively easy when possible, for someone to build their own Arduboy compatible device using readily available modules and discrete parts, without requiring custom circuit boards, surface mount parts, or other difficult construction. A compatible display module is available from Adafruit and from sources on eBay and other places. Many suitable batteries and charge control modules are available. Piezo speakers, LEDs, buttons, and other discrete components are available in through-hole or with terminals for easy soldering or breadboarding.
However, the ATmega32U4 processor is only available in surface mount packages, making it difficult to use as a discrete part. Being able to use a standard Arduino product that uses an ATmega32U4 processor would make things easier. If we want to run at 3.3V and 8MHz there aren’t many choices available, but the SparkFun Pro Micro - 3.3V/8MHz would probably be suitable. Its limitation is that it has fewer I/O pins brought out than an Arduino Leonardo or Arduino Micro (pins 11, 12, 13, A4, A5 are missing). I’ve kept this in mind in this proposal (but had some problems which I’ll note).
@bateske has stated in the Kickstarter comments:
With that in mind, I’ve tried to avoid using GPIO pins that have alternate functions which I feel would be especially useful for connecting to external devices:
- 0 (PD2) USART1 Rx
- 1 (PD3) USART1 Tx
- TXLED (PD5) XCK1 This would allow the USART to be used as a second SPI host interface.
- 2 (PD1) SDA for I2C
- 3 (PD0) SCL for I2C
As far as I know, none of these pins have currently been used in the Dev Kit or Prototype.
On the Dev Kit the speaker is connected to both pins A2 and A3 shorted together. This is not good because if both A2 and A3 were made outputs, with one set high and the other low, it could cause damage to the processor. The intent was likely to allow different tones on each output to play on the speaker simultaneously. However, external mixing circuitry should have to be added to achieve this.
There’s been discussion that there may be an advantage to having the speaker on a PWM output. I suggest moving it to a single pin, 5. Pin 5 is capable of PWM from either Timer 3 or Timer 4. On the Dev Kit, pin 5 used for the Right button, so Right will have to be moved to a different pin.
It has also been suggested by @ChrisS that it may be useful to have both leads of the speaker each be connected to an I/O pin, instead of having one lead connected to ground. This may accomplish what was intended by connecting two shorted pins to the speaker. If this proves to be true and we want to implement it, then I suggest that pin 13 be used. Like pin 5, it also supports PWM using Timer 3 or Timer 4. If connected in this way, pin 13 would have to be programmed as an output set low when not in use, or else driving just pin 5 would make no sound.
With a Pro Micro, pin 13 isn’t brought out, so one of the spare “hacker” pins might have to sacrificed, along with minor code changes, for this functionality. For this reason, it would be good to recommend that sketches use primarily pin 5 to drive the speaker unless two pin operation is required. The Pro Micro would work properly with any sketches that didn’t use pin 13, by simply tying the second lead to ground.
@bateske has indicated that a new Start button will be added. There has been discussion about using this button (possibly using a long press) to put the unit into a low power “Sleep” mode and also to wake it back up. For a wake up, the button would have to generate an interrupt. I suggest using pin 7, since it can generate Arduino interrupt 4. The other Arduino interrupts, 0 to 3, are on my “hacker” designated pins. Other pins are capable of generating an interrupt but they aren’t directly supported by Arduino, so may be more difficult to use.
The display is controlled using the SPI interface. MOSI and SCLK must be connected as they are now. RST, CS and DC can each go on any GPIO pin. Unless circuit board routing becomes an issue, I’d leave them where they are on the Dev Kit: RST 12, CS 6, DC 4.
With a Pro Micro, pin 12 isn’t brought out, so another pin may have to be found for display reset, along with minor code changes. It’s possible that the SPI MISO pin could be used. It can be a GPIO pin when not in SPI mode, so the code would have to disable SPI mode to reset the display then re-enable SPI mode. A switch or jumper may also be needed to disconnect MISO from the display, if using an ICSP to program the bootloader is required. A reset would probably only be done once, when initialising the display. Some available modules don’t even provide a reset line. They just reset the display using on board hardware upon power up.
On the Dev Kit, the LED is connected to pin 17. I’d leave it there.
On the Pro Micro, pin 17 is wired to the RXLED and not brought out to a pad. The RXLED would become the Ardyboy LED. If it was desired to move the LED off board, some wiring and soldering work would be required.
The 6 existing buttons could each go on any GPIO pin. I suspect the pins used on the Dev Kit were chosen only because their physical location on the processor made them easy to route to the buttons. Unless routing becomes an issue they may as well stay where they are, except Right on pin 5, which is now used for the speaker. I’d move Right to pin A2.
There has been interest in having the processor be able to monitor the state of the battery. If we power the processor from a 3.3V regulator then we have a suitably accurate and stable voltage that can be used as the reference by the processor’s ADC. We just need to connect the unregulated battery voltage, after the power switch, to an ADC capable pin. Since the ADC input would not be allowed to go above 3.3V the battery output would have to be connected through a series resistor divider to scale the voltage to be within range. Scaling down to 75% would be about right but the exact ratio could be chosen so as to make the calculation of the true battery voltage easier. I’d make the total resistance of the two divider resistors be around 1Meg ohm and use 1% or better tolerance resistors.
A problem with the above technique is that if the battery goes too low (below about 3.4V), it will be below the dropout voltage of the regulator. If the regulator output starts to droop then the reference will change and the battery voltage readings will no longer be accurate (probably appearing not to change). There is a way, though, to detect this situation. Still with Vcc as the reference, we could occasionally use the ADC to measure the value of the bandgap. This reading should remain the same (within a small tolerance) as long as the regulator output remains at the proper 3.3V. However, if Vcc, and thus the reference voltage, starts to fall below 3.3V then the bandgap measurement value will rise in proportion. When we detect the bandgap voltage rising over time, it signals that the battery voltage is lower than the required regulator dropout voltage. We could use this to signal a battery low condition. Of note is that we can use this technique to detect a low battery even if we don’t implement the battery connection to a ADC pin. This is another advantage of powering the CPU via a regulator instead of straight from the battery.
In summary, having a battery to ADC input pin connection allows us to accurately measure the actual battery voltage, from fully charged to the point that it’s lower than the regulator dropout voltage. Measuring the bandgap for increasing over time allows us to detect that the battery voltage has fallen below the regulator dropout voltage.
I’d use pin A3 for the battery monitor input. Pin A3 is connected to the speaker on the Dev Kit, but moving it is recommended, as has previously been discussed.
Pads for hacking:
Again, @bateske has stated the intention of bringing unused pins out to test pads. I’ve actually thought of 24 signals that may be useful to have easy access to, for enhancing or repurposing an Arduboy. It would be nice if these signals:
- were available on the back of the circuit board and not covered by the battery.
- were on pads arranged in one or more straight rows, with pads spaced 0.1 inch apart.
- had through holes so that standard 0.1 inch headers could be soldered in.
Even without holes for headers, rows of 0.1 inch spaced pads could make it easy to construct some kind of docking station, or an extended back containing another circuit board, using spring loaded “pogo” headers to make contact with the pads.
If I’m right that the battery will be 44.5mm x 61mm (66mm including leads), and it were placed at the bottom of the unit, then possibly there would be room to squeeze in all the pads, and traces to them, at the top, above and/or under the display. Some might also be able to go between the battery terminals.
Here are the signals:
0/RXD1(PD2), 1/TXD1(PD3), TXLED/XCK1(PD5)
This is for USART1. It could be used for async serial communications, possibly to connect two Arduboys for multi-player games. It could also provide a second hardware SPI host interface.
On the Pro Micro, TXLED is an LED and not brought out to a pad. You would have to remove and/or tap off of the LED circuit to gain access to XCK1 for SPI.
These are the I2C data and clock pins. Many devices are avaliable which communicate using I2C bus protocol. I2C only requires these two signals plus ground. Since devices are individually addressed, more than one can be connected at the same time. One example would be an IMU board, allowing you to control the Arduboy by tilting, rotating or moving it in any direction.
11(PB7), 13(PC7), A4(PF1), A5(PF0)
Pins 11 and 13 are PWM capable. We’d only bring out pin 13 if we decide not to use it for the speaker.
On the Pro Micro, none of these pins are brought out to pads.
14/MISO(PB3), 15/SCLK(PB1), 16/MOSI(PB2), Processor RESET
MOSI and SCLK are used to control the display. All are required to flash the bootloader and for other In Circuit Serial Programming (ICSP). They could be used to control other SPI devices, along side of the display, by using other output(s) as CS (chip select) line(s).
GND, 3.3V, VBATT switched, VBATT unswitched
3.3V is the regulator output. It could provide power to external devices. The amount of current available would depend on the regulator used. VBATT is unregulated power straight from the battery (or through a polyfuse added for safety), before and after the power switch.
8/UP(PB4), 9/LEFT(PB5), 10/DOWN(PB6), A2/RIGHT(PF5), A0/A(PF7), A1/B(PF6)
When a button isn’t pressed, it essentially isn’t in the circuit. Therefore any button pin could be used for other purposes, or even just to have an external button perform the same function.
For a pin configured as an input, if you needed to protect whatever output you connected from being shorted to ground, if the button was accidentally pressed, you just have to add a resistor between the pin and your output.
If you configure a button pin as an output, you’d have to make sure that the button wasn’t pressed when the output was high, maybe with a cover or something. Depending on what you’re driving, you could also protect from an accidental button press by setting the pin to an output for a low level but as an input, with either the internal pull-up enabled or with and external pull-up, for a high level.
All of the button pins except Start are ADC capable. So, for example, you could connect analog joysticks to them, which may be better than buttons for some games.
This is the end of my thoughts about what the ideal final Kickstarter Arduboy should be, taking into consideration what has been described and specified, while deviating as little as possible from what is known about the Dev Kit and Prototype, and attempting to remain practical.