In the dev kit it’s overclocked, technically the 32u4 is a USB chip so it wants USB voltage… In practice we have not seen any problems running the chip on a coin cell battery until about 3.2v or lower, so you have maybe 4-5 hours on the coin cell battery maybe a bit longer if used in short bursts.
The full version of arduboy will be lithium polymer battery which won’t go any lower than 3.6 so should be just fine!
Just for safety (and if your manufacturing process allows easily setting the fuses) could we fuse the chip so it boots at 2Mhz (1/8 clock divisor fuse) and then set the speed to 16Mhz as the system comes in in the Ardoboy lib? This would allow someone the ability to choose their own speed at boot-up time (16, 8, etc) WITHOUT ever requiring the chip run at 16Mhz… i.e. if someone had a borderline chip that was flakey at 16Mhz they could still install 8Mhz games without issue. I think it would be a nice hedge against future issues (with almost no downside if you can easily program the fuses).
Of course one can program the divisor to 1/2 now after the chip boots but there is still a short period it’s running at full clock speed, and if that should not work then the unit would be essentially bricked. It seems like from your testing we are talking about edge cases here, but again it seems like an easy thing to hedge against.
Edit: Another reason I care about 8MHz so much is it uses far less power. If we can optimize the library so games run quickly at 8MHz there may not be a reason to run the board at 16Mhz all the time. It could be something individual games opt in or opt out of (they choose their speed). If the power draw at 8Mhz is 1/2 what it is at 16Mhz and the CPU is half the power equation that would turn 8 hours of battery life into 12 hours - just by running at a slower clock.
I think @batske is saying they’ve done a lot of testing of multiple parts in real life and found the documentation is overly pessimistic about required voltage. I’ve already stated my desire to hedge our bets by booting at 2MHz and letting the software decide whether to bump it to 8Mhz or 16Mhz. I’m glad we’re having a serious discussion about this though.
The documentation is very scary when it talks about potential random EEPROM corruption if the voltage levels are too low… so we may not just want to test playing breakout all day long, we may want to thoroughly test that the EEPROM is safely read and written at 16Mhz at 3.7V across a variety of samples.
@bateske Have you considered the possibility that over-clocking might not be good for the chips long-term health? I know brown-outs are not good for electronic equipment. Ie, it works fine now but 2 years from now it will fail - vs working for years and years if it was run at the voltage recommended by Amtel.
That’s not an acceptable practice for production products unless you test and qualify each and every unit separately, with a heavy load over the full intended temperature range, for a long period of time. This is not practical for a low cost product like the Arduboy.
In the future, the manufacturer of the Arduboy could receive a batch of chips that came off a different production line, or were a newer or older version, or were manufactured using a different process, possibly (under legal license) by a third party. These might be more critical of clock speed but still work fine when clocked within the specified range.
All of a sudden you find that all your units are unstable or don’t run properly at all. If you discover this before shipping, you have to scrap or re-work the entire batch. If they get out into the field, you have to deal with irate customers and product replacements or compensation.
And then what do you do? Do you start shipping units with a lower clock speed and now have two different versions in the field? Some programs written for the old version may not run properly on the new one, or vice versa.
Any respectable, well engineered product will not be designed to operate outside the component manufacturers’ recommendations. You never know how or when it might bite you, and you have no one to blame but yourself.
One, possibly minor, consideration about this is that the creators may desire to use a standard, unmodified version of a compatible Arduino bootloader and fuse settings. This means they don’t have to maintain this code themselves. Not having to allocate resources and find the time to fork, make modifications and test a custom version of the code can be a time and cost advantage.
This can be an advantage for users as well. For instance, let’s say sometime in the future the Arduboy creators decide to no longer maintain the product. Then, a new version of the standard Arduino bootloader becomes available with a feature or fix that would be desirable to have on the Arduboy. A user with the required resources could just grab and burn the new bootloader without worrying about having to make modifications themselves, or waiting for or finding an Arduboy version that someone else has created.
To me the fuse settings are part of the hardware. The hardware already makes a lot of decisions that someone using it has to deal with. How the buttons are pinned, which pin the LCD clock signal is on, etc… when the product is ready we need to ship an official board file for “Arduboy” so then Arduino software knows what the right fuse settings are for our product - just like any other Arduino board.
If we decide to boot at 2Mhz and all software has to do is set the clock divisor then that’s part of the hardware documentation. Anyone developing for the platform needs to do that - and the core lib would make it easy to do. If they don’t want to use the core lib they could copy the necessary few lines of code into their own app. It’s reasonable to make that type of decision as a hardware builder.
I think I agree with you on the clock speed and risk. I see my solution as a compromise that allows for EVERYONE to have what they want. It sounds like @bateske is really sold on the 16MHz, but please keep trying to persuade him against.
I don’t think the chip should boot any faster than 8MHz… but having an “overdrive” mode also seems kind of cool and retro in a way.
I’m not sure what this means. As far as I know you can reflash the bootloader without touching the fuses (unless you need to change the bootloader size fuse). The thing that does the hardware setup of the platform for actual apps is in the arduboy.cpp file, not the bootloader.
I’ve seen many Arduino compatible products that don’t have their own board file. Their documentation just says something like set the board type to Arduino Leonardo when uploading sketches or when burning the bootloader. If they do provide their own board file, which is optional for the user to install, it’s just an exact copy of the one for the official Arduino product they mentioned, with only the product name changed.
Again, this eliminates (perhaps only a small amount of) work, for both the manufacturer and user, to create, maintain and install a board file, and possibly a custom bootloader, for the product. I don’t know if this is something that’s important to the creators of the Arduboy.
That said, I’m certainly not opposed to the initially safe but variable clock speed ideas that you’re proposing, if they’re easy and relatively painless to implement and use.
It’d be a few lines of code that we’d provide… and likely something you’d just configure with a #define… #define 16mhz or #define 8mhz… and then the library code would setup the chip properly.
I plan to add support for 8mhz anyway and run all my sketches at 8mhz when possible just to save battery life. I think it would be good policy to encourage everyone to do the same if they don’t need that extra power. We can make the battery last about 50% longer by cutting the clock in half.
Besides severely under-volting the chip there is not much you can do to damage these chips in our research. We have tested many of these chips before, and also looked online… It’s really pretty difficult to see people complaining about a truly broken chip.
That said, this is a developer kit, we want to test these things in the wild before we start mass production so give them a test! Let us know if you have any problems and we will work with you to figure it out!
I doesn’t matter how much you test existing units or look at other similar current products. If you use a clock faster than recommended for the voltage you’re running the chip at, you can never guarantee that you won’t have problems with future builds. The manufacturer of the microcontroller (Atmel) could change their manufacturing procedure, or revise the chip layout to address other issues or for cost savings, etc. Any changes made could affect the chip’s tolerance for overclocking but still remain stable when run within the specifications of the datasheet.
The next batch of processors you receive may not handle your overclocked design, even though all of your previous units have. Unless you’re prepared to fully stress test each and every unit before shipping, under heavy load over your full recommended temperature range, you may be asking for trouble in the future.
If there was no possibility of having problems with clocking higher than what Atmel recommends, then why wouldn’t they just relax the specification in the first place? Releasing a consumer product that runs out of spec by default is not a responsible engineering practice. It’s fine for a user to do it at their own risk, but not for the manufacturer, unless you clearly make the user aware that you’re doing it and what the risks are.
Maybe you should contact Atmel and see how they feel about it? If they say it’s OK then you can relax and reassure your customers that it’s fine.
How many ATmega32U4 based products, made by respected manufacturers, did you find that are clocked out of spec by default, when you looked online?
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.