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:
The other group will value:
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.
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.
Wtf?
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?
@ChrisS,
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! 
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.
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. 
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.
Hmmā¦ I might be mistakenā¦ When did you see first see the kickstarter page?
On May 11, the day it started. And, I specifically remember wanting to know the clock speed and looking for it but not finding it.
Sorry! Youāre right. I just couldnāt believe that while reading a topic like this for so long. I stand by my other conclusions even more now.
