Arduboy's clock speed

Continuing the discussion from ATmega32u4 vs. Intel 80286:

Yes, that’s what I was trying to point out. But these poorly written libraries are probably running fine on real Arduino’s, so there are no complaints or requests to improve the code.

If these same libraries cause problems on the Arduboy, due to it using a non-standard clock speed, it may be upsetting to some users striving to develop a sketch using them. Due to the Arduboy’s popularity on Kickstater, and seeing some of the questions being asked in the comments section there, it’s obvious that many would be Arduboy developers will be neophytes in the Arduino development world. The less development headaches due to deviation from Arduino standards, the better.

I think that Kevin Bates and the Arduboy development team should determine or confirm and announce the clock speed and voltages that the CPU will be running at, sooner rather than later. Personally, I’d feel uncomfortable using or writing code for a product that was overclocked by default. I’d be concerned that I wouldn’t know if it was coding errors or issues with overclocking, if a program wasn’t behaving correctly.

It’s not technically overclocked. The chip is rated at a maximum of 16MHz at I believe 4.5-5.5V. The issue, is that the rechargeable battery in the final version will have 3.7-4.2V output. 3.7V would allow 12MHz comfortably.

They want the chip to perform the best it can with no side-effects. They want developers to get the most out of this device and a 50% boost to 12MHz is HUGE! A lot of stuff may not be possible without that speed boost.

But it’s early days, driver improvements may mean the higher clock speed isn’t necessary. The game developer will also have access to all of this, so if they don’t need the extra speed, they don’t have to use it!

Fine. I guess I should have said using a clock speed that is higher than what is recommended for the voltage at which the chip is being run, wherever I’ve used the term overclocked. Do you have a better, more technically accurate, term to describe it?

It wouldn’t hurt to improve those libraries. :slight_smile: Just because most Arduinos run at 8 or 16 doesn’t mean we should have to. Honestly I’d prefer a choice. Put a 12MHz clock crystal in there and if someone is used an incompatible library they can switch to using the internal 8MHz crystal, problem solved.

We get the best of both worlds.

[quote=“Wozza, post:2, topic:131”]
But it’s early days, driver improvements may mean the higher clock speed isn’t necessary.[/quote]

I’ll leave this under this topic, but I’d suggest that any replies or further discussion not related to clock speed be continued in a new linked topic or an existing more appropriate topic.

If I can find the time, I’ll see if I can apply any of the techniques that I used to improve the speed of the MicroView library. The MicoView (another Kickstarter campaign) uses an OLED display (though smaller) having the same SSD1306 controller as the Arduboy’s

I was able to make the MicroView’s display() function close to 4 times faster, though I don’t know if the same amount of improvement could be made to the Arduboy library. For anyone wishing to see what I did, and possibly try improving the Arduboy library in similar ways themselves, the majority my work on this is in these commits:

1 Like

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.

Then please explain section 29.5 - Maximum speed vs. Vcc of the ATmega32U4 datasheet, which states:

Maximum frequency is depending on Vcc. As shown in Figure 29-2 on page 361, the Maximum Frequency vs. Vcc curve is linear between 2.7V < Vcc < 5.5V

To me, it looks like the maximum safe clock speed at 3.6V would be about 12MHz.

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.

Just as a point of interest, the creators of the MicroView stated in their Kickstarter campaign that the device operated from 3.3V to 16V at 16MHz. When I questioned this, they added the statement:

Note: 6-16VDC is the manufacturer’s recommendation for a stable 5V 16Mhz operation. Voltages below 6VDC are for hackers that wish to drive the ATmega328P and LDO beyond the datasheet’s limit.

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! :smile: Let us know if you have any problems and we will work with you to figure it out!

I’ll repeat:
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?

Touche. :slight_smile: All good points. At this point it sounds like you’d be more effective with user education than persuading @bateske though. :-/