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.
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.
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
- 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.
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!
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.