Arduboy's clock speed

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.

The documentation for this Arduino tone library has a table which says:

For an 8MHz CPU clock:
An 8 bit timer can generate from 16Hz to 4Mhz
A 16 bit timer can generate from 1/16Hz to 4Mhz

For a 16Mhz CPU clock:
An 8 bit timer can generate from 31Hz to 8Mhz
A 16 bit timer can generate from 1/8Hz to 8Mhz

The range of frequencies that the piezo speaker can produce are well within all of the above.

I’m not saying this is a good idea or a bad one, but it’s something to think about.

If we switched to the ATmega328, it would be possible to not even include the USB converter on the Arduiboy unit itself. Instead, bring out a 6 pin (5 would actually do) header wired as a standard “FTDI” connector, as is found on the Arduino Pro Mini.

You would then just plug in any compatible USB converter/programmer. They’re available in many forms, from many sources. One could be included with each Arduboy and would probably cost not much more than puting the equivalent on the Arduboy itself.

The advantage would be less power consumption when running off battery. If your battery was low or you wanted to save it, you could still plug in the programmer to provide power from USB.

Another advantage is that, when the programmer wasn’t attached, the Rx, Tx, Power and Ground signals would be available. These could be used for an Arduboy to Arduboy peer to peer connection, or for other purposes. (Rx and Tx can also be used as GPIO pins.)

A disadvantage would be that you would need to have the programmer handy whenever you wanted to load a different sketch, instead of just using a standard USB cable. It would likely be easier to replace a standard cable than the programmer if you misplaced or forgot it.

Again, this is just food for thought.

Good discussion.

From my thinking, I would strongly encourage staying within Atmel’s 8MHz limit for the voltage you are running at.

The Arduboy offers a unique and interesting value proposition. It is wallet sized, can be reloaded with a standard USB cable, and offers a reasonable suite of capabilities within that range. But none of those items are valuable if you put the reliability and resilience of the device at risk. If you push the default setup outside that range, that is risk you are taking on.

The most successful of the early handheld game units did not achieve their goal with incredible graphics or high performance. You could probably deliberately run your bicycle over it without really affecting its operation. If games needed more performance than the device could bring to bear, then those games typically never made it to market, or you found a developer who could make magic without the high performance. Furthermore, if the device had been unreliable, or some units were flaky, this would have killed the reputation.

At the core of this, I think you have to decide who this device is for, in what proportion. If it is primarily for the type of people in this forum, then you can overclock it and expect that people who own it can deal. But if a significant fraction of owners will be people who will take the cable they have, and only ever load and play games and software, then I think you want to lean very heavily towards reliability with a conservative design. Right now, from what I’m seeing, you already have a pretty conservative design.

Those of us whose first reaction to a new device is undo the cover screws and pop the top off are one group. Those who first reaction is throw the power switch and play the game, and quite possibly never undo the screws, are another group.

One group will value:

  • lots of connectivity
  • lots of performance
  • options
  • easy open case

The other group will value:

  • good value for money
  • always just works

Even with a conservative design, you still have an amazing design. The processor has an efficiency advantage of about six times more MIPS per MHz than a Z80. A classic handheld would run a Z80 at 4MHz for 0.58 MIPS. At 8 MHz you have nearly 14 times more processor power to run with. Insufficient performance will not be a limiting factor in the vast majority of cases. A solid community base will leverage what you are offering to achieve things you did you think were possible.

Although the cost of alternative cables in dollars is not a lot, the cost in time, effort, and attention for many people will be quite high. A standard micro USB cable can be replaced for a few dollars within a two minute walk. I can get them at the newstand! And if I have a sudden hankering to change games at work during lunch, I can likely do it, because there will be a spare micro USB cable there to charge my phone.

I think the ability to emulate a keyboard, mouse, or serial port is a vastly underrated feature. I am already thinking - and I doubt that I am unique - of a password manager, which can plug into a USB port and inject a selected password on command. Being able to carry such a device in my wallet is far better than carrying a card with all my passwords written on it. And again - the value of such a device plummets if the reliability is suspect.

Elsewhere here, I’ve written about trying to achieve peer-to-peer Arduboy communication and games. I think it would be very very cool. But it’s not as important as the main goals. If it can be achieved, great. If not, I’ll still have a small stack of reliable wallet sized game machines. To my thinking, that same logic applies to almost every “wouldn’t it be cool if” comment in here. Yes, it would be cool. But not as cool as reliability and target focus.

I think that the goals of resilience and reliability are key here, in a package that keeps value high and cost low by working with technologies we find around us everyday. Please do not succumb to the deadly infection that is scope creep. Stay on target, and deliver on time.

1 Like

At this stage, it would cause significant delays changing chip and circuit design… surely? I think the question is simply whether 32u4 @ 8MHz will be too limiting for game design or cause other issues (USB Sync). Versus running the 32u4 overclocked and running every unit through an internal QA procedure undervolted, before shipping.

If you’re developing a game specifically for the Arduboy, you work within its specifications and limits. If one of those specifications is an 8MHz clock, then so be it. As @ChrisS pointed out above, 8MHz is still plenty fast for the intended purpose.

Issues could arise if you desired to port a game from a platform that runs at a higher speed. If this game uses a fair amount of processing power then its performance may not be adequate when attempting to run it on a lower speed Arduboy. The game also could have been implemented using somewhat bad programming practices, such as software timing loops, that make it clock speed dependent, which would make porting more difficult.

A specific example is the Gamebuino. Its hardware is very similar to the Arduboy, the main difference being it having a lower resolution LCD screen. It runs at 16MHz. There are probably many games written for it that would be quite easy to port. However, if the Arduboy ran at 8MHz, some ported games might end up being sluggish or to slow to be usable.

The same issues could potentially arise with some of the games developed using the 16MHz Arduboy Dev Kit platform.

As for possible hardware issues resulting from lowering the clock, the SparkFun Pro Micro is available in both 5V/16MHz and 3.3V/8MHz versions, with the only hardware differences being the values of the crystal and the on-board voltage regulator. I’ve not heard of any problems that occur on one version but not the other due to differing speeds.

Keep in mind that using a separate USB to serial converter is just an alternative possibility available if we switched to an ATmega328. It’s not a requirement; just something I threw out there for consideration. With an on-board converter, as I originally proposed, you would use just a standard USB cable for programming.

With an on-board converter, the only major difference between USB with a 32U4 and a 328 would be the 32U4’s ability to appear as a keyboard or mouse, which although possibly desirable to some, is not a main goal. I would posit that peer-to-peer connectivity is a more desirable feature, in the context of the Arduboy’s goals, than keyboard/mouse emulation, if not outweighed by the drawbacks of a separate converter/programmer.

I’m the only one who found this thread so disturbing? NOW, by the end of campaign, it shows that no one knows what is the cpu frequency.

Have to say that I do not like the third option. That extra RAM is hugely important. If we had 2KB RAM, the dual screen buffer method for getting grey on screen would be impossible (I’m aware of other methods, but this was the first method used). Other projects with high amounts of generated data would become that bit harder. From my experience so far, RAM is the last thing we would want to cut down and it would be the first thing I would want increased.

The other options are also hard to choose between. The extra cost of boosters and the lower battery life is not ideal and neither is the halved performance of 8MHz, however efficiencies can be made to make the most out of the lower clock speed more efficiently. Creating generated content during a loading screen is one of the simplest ways of doing so. There are other methods that are not as simple to explain but you see what I mean. Processing speed is more expendable because it can be offloaded to a later time. RAM on the other hand, once its full its full especially with no ability to cache to storage.

Think it would have to be option 2 to me. 8MHz and no additional components. But add the ability for user overclocking, or maybe ship them at 12MHz if it is found 100% stable.

If we were in the early stages of planning, I would completely agree. But everything about the Kickstarter says that this is a locked in design, only needing to be ramped up. I share some of the nervousness expressed below that this discussion is happening at this point in the process.

So for keyboard/mouse vs peer-to-peer? Peer-to-peer is not mentioned anywhere in the design or details on the Kickstarter sight. The most you get is “more games can be downloaded”. Keyboard and mouse capability is explicitly mentioned at 25 seconds into the first video on the top of the Kickstarter page. For myself, I never mentioned it before because it was so clear - no point in discussing something when it’s planned, and demonstratable on the same hardware in other projects.

Even if everyone agreed on the priority of these options, there’s over 8000 devices committed to with “keyboard/mouse” clearly indicated as included. There may be concerns outside of the technical area about pulling a feature so clearly promised during the campaign.

Can I ask how exactly this device is used as a keyboard and mouse? To be used with a PC? Or something else?

I must apologise, then. It’s been a long time since I watched the video. The words keyboard or mouse do not appear anywhere in the text on the Kickstarter page. It’s a good thing 16MHz was never mentioned, either! :wink:

Just for the record, even though I proposed the option of switching to an ATmega328 as a possible solution to allow safely remaining at 16MHz, my preference has always been to basically keep the current hardware design and just drop the clock to 8MHz. I thought I’d remain publicly neutral for a while and play devil’s advocate, in hopes that everyone could weigh the pros and cons of all proposed options, without the possibility of being swayed by my bias.

Arduino Mouse and Keyboard libraries

I think the best choice here might be 8 AND 12Mhz. Though I’m not sure how to do that in hardware (a 24MHz clock crystal?). 8Mhz would be the default and anyone who REALLY needed the extra boost would compile at 12Mhz and have to deal with any associated issues that might include (mostly timing being off). The timing routines that are written in tuned assembler would need to be rethought for a 12MHz clock or a converter routine would have to be done in software (like trueMillis() in the prescaler library).

8MHz is still crazy fast if you use the right code. With some library improvements I’ve gotten the Megaman demo rendering loop down to 3ms. That’s a potential frame rate of 166 frames per second (at 8Mhz) - when our hardware is capped at 150 or so. Now that’s not counting the speed of game logic (the demo really has none) but that’s just showing you can do a TON of stuff with this processor if programmed properly.

And that is a very complex demo at 166 FPS. Breakout (unoptimized) runs perfectly acceptably at 60FPS using about 50% CPU. (at 8Mhz).

I as I’ve mentioned, I think it’s best to run the processor at a regulated 3.3V; the advantage being that you wouldn’t need level shifters on the display signals. (I don’t know if @bateske even considered the possibility of needing to level shift, since I don’t see any evidence of related components on the unit pictured on Kickstarter, unless they’re on the back.) The same advantage would apply to people who wanted to hack the unit and connect maximum 3.3V tolerant devices to the spare signal pads we’ve been promised will be provided.

If you want to stay within spec, the maximum clock rate at 3.3V is 10.4 MHz (which you would probably round down to 10MHz. Even if running on raw battery voltage, the battery will still have useful life when it’s voltage has dropped below 3.3V, so you’re still restricted to 10MHz.

Being able to shift from 8MHz up to 10MHz could be a bit tricky and probably not of too much benefit anyway. Now, if you want to allow 12 MHz to those who are willing to take the risk of overclocking, then that’s a different story.

Ah, I wasn’t thinking about 3.3v. As you know I’m game for 8Mhz default and hackable 16. :slight_smile: Which is easy with a 16Mhz oscillator just by booting to 2Mhz and then jumping to 8Mhz via the bootloader (or core lib). Anyone who wants 16Mhz just has to compile with the proper board file and then bump the speed in their init sequence. As I think very few will be refreshing the bootloader I think it’s “safe” to put the 2mhz > 8mhz code there. If someone does want to build their own it can be a documented fact that they need to bump up the clock speed in there modified bootloader if they want 8mhz.

I think we’ve already proven with what 3v coin cells that 16mhz would be “hackable safe” driven with 3.3v.

jumping to 8Mhz via the bootloader

Actually even requiring the core lib or making it known you need a few LOC to set the clock speed wouldn’t be the worst thing in the world without that code in the bootloader… I just think since 90+% of people aren’t going to touch the bootloader it probably makes sense to put the code there (since we have to compile our own bootloader anyways).

Edit 2: I had my facts wrong. The cpu speed was never advertised on kickstarter.

If it’s possible to simply use a software change to decide between 8Mhz and 16Mhz, this should be the solution, regardless of any, and all, consequences.

I’m not very adept with these kinds of issues, but as far as I’m aware, this is the only way to provide what was advertised on the kickstarter without some major hardware changes; the project absolutely should not be delayed signifigantly by redesigning it without consent from virtually every backer unless something is impossible to fix through software without causing extremely severe issues, as the risk statement and other information clearly indicated that it was very close to complete and other information in the comments said that things would possibly be redesigned for a second model. With the amount of RAM advertised as such, and the fact that it is so small, anything less would most likely damage the credibility of the arduboy team permenantly to a very large extent, given that the reason for doing so would be associated with a complete failure to properly consider a major part of electronic hardware design. The keyboard/mouse functionallity is not the main reason I backed this product, but it certainly played a major role, as I intend to use it for my wearable/pocket computer. While the loss of that feature would not be as detrimental to the credibility of the aduboy team, I don’t see that as insignifigant at all if it is likewise associated with the hardware design failure.

If I’m not mistaken, somewhere on the kickstarter website, it was mentioned by staff that the cpu was NOT overclocked. I definitely think admiting the falseness of this statement, saying it was a mistake, and explaining why it won’t be made true would be preferable to changing the hardware signifigantly under any circumstance, and certainly better than reducing features or, especially, RAM.

edit: I think adding a button or buttons is generally agreed upon to be worth delaying the release relatively signifigantly.

The clock speed of the final design has never been advertised on Kickstarter, either on the main campaign page, or by the Creator in the comments section, or in an update. In fact, the Tindie site offering the Dev Kit falsely states:

Atmega32u4: 8MHz, 32KByte Flash Memory, 2.5KByte SRAM, USB support, Arduino bootloader.

(Emphasis on 8MHz added by me)

Therefore, no Kickstarter backers should have a reason to feel misled. Clocking the Arduboy at a fixed 8MHz would be perfectly fine, from the point of view of what was promised.