Man, you are treasure. Keep posting.
The dev kit is the only one with any kind of hypothetical problem. The final version has a lithium polymer battery so everything is in spec.
The battery is for testing only. If you run into any problems testing your device with the battery just let us know we will help you out.
If you are afraid of a coin cell battery destroying your arduino, honestly the dev kit might not be your bag of chips and we would steer you to the Arduboy on kickstarter. We will be doing all sorts of compliance testing on that one, because it isn’t just a bare circuit board with buttons on it.
Thanks again for trying to keep us on the straight and narrow but when it comes to the developer kit, we consider you part of the community that is stress testing the hardware and the design.
No! If you’re clocking at 16MHz then it’s not in spec!
Refer to my post number 8 in this thread.
A lithium polymer battery has a nominal voltage of 3.7V but can be comfortably used down to about 3.4V before it starts to rapidly loose voltage to the minimum safe discharge voltage of around 2.7V.
If you do the calculations based on information in section 29.5 - Maximum speed vs. Vcc of the ATmega32U4 datasheet, you’ll find that:
- The maximum allowed clock frequency at 3.7V Vcc is 12Mhz
- The maximum allowed clock frequency at 3.4V Vcc is 10.8MHz
Unless you’ve added a boost regulator to provide at least 4.7V Vcc at all times when running on the battery, then a 16Mhz clock is above what Atmel specifies as being in spec.
I can elaborate on how I calculated these values if you don’t have an engineer on staff who can do it.
Correct from what I’ve read - though it is much better running off LIPO than a coin cell at 3V… perhaps @bateske really doesn’t understand yet he’s overclocking the chip?
@bateske: Even with LIPO you’re still overclocking. Look at most big implementations are Arduino and they are all 8Mhz at 3.x voltage… and 16Mhz at 5V.
@MLXXXp so you are advocating for 8mhz?
Is there a problem with your dev kit or are you just concerned because it’s in the danger zone of that chart?
Surely you understand his point at least? He’s saying you may have a professional responsibility to use the chip within it’s manufacturer limits. Or you risk premature device failure or a bad (less overclockable) batch of chips messing up your entire project. Just because you’ve never seen one fail at 16mhz doesn’t mean they won’t start tomorrow. There is a reason the manufacturer recommends those levels in the first place and they document is so careful.
There must be a reason MOST (no?) other commercial projects overclock the chips. 3.xV runs at 8mhz, 5v runs at 16mhz. That’s true of everything I’ve seen that Arduino sells, everything Adafruit sells, etc… not that an exception would prove it’s a good idea.
This is a $350,000 project now, you’re playing in the big leagues. Overclock and hoping for the best might be a little reckless with all that’s at stake.
If we want to run at 16Mhz why not step-up the voltage to a proper 5V and run the chip as recommended?
Is it a requirement to have a dev kit to participate on this forum? Unfortunately I don’t have one.
I’m not concerned about doing any physical damage to the processor or other component, due to overheating. This device isn’t a PC that a gamer needs to add massive cooling to in order to avoid a melt down due to overclocking.
I see it more likely that programs will become flakey or randomly crash due to corrupted RAM reads or writes, corrupted instruction reads, or other errors due to internal timing problems. If this kind of bad behaviour manifested itself on a given unit, it would be difficult to know if it was due to overclocking or something not related, like a chip that was actually failing or a subtle error in the program.
Lowering the voltage affects slew rates, which can change the shape of the edge of an internal signal and thus the time it is detected as having changed. A short pulse might not even rise to the voltage required be detected as having gone high because the slew rate has become to long. The manufacturer will compensate for this by recommending lowering the clock speed as the voltage is lowered, as Atmel has done.
And, don’t expect Atmel to help you with a problem if you haven’t followed their recommendations.
As a customer I would hope that the product is properly engineered and you “covered your butt(s)” by designing within the parts suppliers’ specifications.
We certainly have put a lot of thought into it, but it seems like you have as well. What do you think is the best solution to the issue you see? Would it be better to add a boost converter or lower the clock speed?
A boost converter would reduce battery life, right?
It depends on what’s more important, processing power, or cost and battery life.
For using a boost regulator and clocking at 16MHz:
Battery life will be reduced, possibly significantly, due to:
- Running the processor at 5V instead of a nominal 3.6V will cause it to use more power.
- A boost regulator will not be 100% efficient (probably more like 80% to 90% if well designed).
There will be added cost for the booster. Also, you might have trouble with keeping the parts small enough to maintain the desired thickness of the Arduboy.
The display inputs are rated 3.3V maximum, so you also need to add 5V to 3.3V level shifter circuitry. This is another additional cost. (Note that level shifters will probably be required even if you run the processor directly from the battery without a booster, since outputs could be as high as 4.1V with a fully charged battery)
You have to find space on the board to add and connect these parts.
For reducing the clock speed to 8MHz:
Program execution speed (instructions per second) will be halved.
The maximum SPI clock speed for controlling the display will also be halved, so display updates will be slower.
As a pro: Processor power consumption will be lower at 8Mhz than it would be at 16Mhz, which will further extend battery life.
Another pro: The processor can safely be powered at a regulated 3.3v (which you probably already have for the display), instead of running it directly from the battery. Therefore, level shifters won’t be required for the display inputs. Also, the processor will draw a bit less current at 3.3V than it would running at the higher battery voltage.
I’ll offer a third option:
Instead of using the ATmega32U4 (similar to an Arduino Leonardo or Micro), replace it with an ATmega328 and a separate USB to serial converter (similar to an Arduino Uno or Nano). The ATmega328 can safely be clocked at 16Mhz when run at 3.3V. And (as with the above ATmega32u4 / 8Mhz option), if you ran the whole system at 3.3V instead of directly from the battery, power consumption would be somewhat reduced and level shifters wouldn’t be required for display inputs (but power consumption by the new USB circuitry may offset any gains from reduced processor voltage).
For the USB to serial converter, you could use a FTDI part (as the Arduino Nano does), or a dedicated second processor (as the Arduino Uno does), or even a CH340G (as some Nano “clones” do).
One downside is that the USB port wouldn’t be able to behave as a keyboard or mouse, as the one in the ATmega32U4 can, but I don’t think that’s really important based on the Arduboy’s intended purpose. I can’t say how this approach would affect cost.
Another advantage of this option: I believe the bootloader would be quite a bit smaller, giving more space for sketches.
Granted I’m not very knowledgeable about this, but just with some quick googling it sounds like the ATmega328 is quite a bit worse than the ATmega32U4, including not supporting USB natively…
Other than that, what else?
As I said, I know very little about this and all I have is google.
“ATMEGA32U4 has more features in almost every department, and should be able to do anything a 328 can. More IO, more ADC channels, more RAM, more timers, etc. Plus it has hardware USB, which is an awesome feature.”
FWIW - I intend to use the Arduboy as a Keyboard emulator for some of the educational applications I have in mind… Granted, I’m probably not a representative user… but it would be a shame to limit this.
As with most things, there are trade-offs. You’d have to weigh the pros and cons of each processor.
If you decide to go with the voltage booster approach then fine, stick with the 32u4.
If you want to decide between a 8MHz 32u4 and a 16MHz 328 plus external USB bridge, beyond the speed and USB differences that I stated:
More IO and more ADC channels: If you’ve got enough for the buttons, speaker, LED and anything else on board, then the rest will go unused (except for hacking).
More RAM: You have to weigh loosing 0.5Kbytes of RAM over the 2Kbytes or more program space gained by a smaller bootloader. I do have to point out that having 2K of RAM to double buffer the display while still having half a K left for general storage could be a big advantage for game use. Having only 2K pretty much excludes the ability to double buffer.
1 8-bit timer and 2 16-bit timers vs. 2 8-bit timers and 1 16bit timer: Does having 16 bits in place of 8 bits on one of the timers offer a significant advantage for this purpose? In the Arduino world, most sketches don’t deal with the timers directly. You have to be careful when working with them that you don’t interfere with standard operations or other functions.
Other differences: Again, you have to compare and analyze each one and put a weight on them for making the final decision.
Let me turn that around by asking: Does the 328 have the all the features we require to allow this product to work as originally intended?
We use both timers right not for polyphonics tunes. Not sure if 8 bit timers would be precise enough.
You have to weigh loosing 0.5Kbytes of RAM over the 2Kytes or more program space gained
The maximum SPI clock speed for controlling the display will also be halved
I’ve done the math. SPI clock speed is the least of our worries, at 8 or 16. SPI clock is plenty fast to push the screen.
Another advantage of the 328 + FTDI solution is that by having a separate chip dedicated to USB / serial conversion you do not suffer from the known flakiness of uploading code with a Leonardo.
We should be careful not to call the Arduboy an Arduinoboy. That is something else entirely:
“Safe mode” should mostly remove the need to touch reset. Just hold down a special key combo when booting and it’ll allow the auto-reboot to work. Or we could even have safe mode call the bootloader itself on boot… although once the final hardware ships with a reset button this will be a lot less of an issue.
But yeah, there are some downsides to the chip running it’s own USB stack.
Sorry, that was a careless error due to me having typed Arduino so often in that post. My fingers must have gone into automatic mode. I’ve corrected it.
Thanks for pointing it out.