This especially makes breadboard setups simple and cheap. I intend to use this at a school to build very small and cheap game devices.
It’s pretty close to the real thing. Video is slightly slower but games like ShadowRunner run nice and smooth out of the box. Both audio outputs are also there and even two of the three LEDs can be dimmed.
Small video:
Sound delay and screen flickering are artifacts of the video capture. In real life both don’t happen.
The Nano actually has a significant advantage over the Arduboy: It has about 5k more usable flash. The following is the result of two otherwise identical builds of Nineteen43:
Nano:
Sketch uses 25662 bytes (83%) of program storage space. Maximum is 30720 bytes.
Global variables use 1594 bytes (77%) of dynamic memory, leaving 454 bytes for local variables. Maximum is 2048 bytes.
Leonardo:
Sketch uses 28524 bytes (99%) of program storage space. Maximum is 28672 bytes.
Global variables use 1732 bytes (67%) of dynamic memory, leaving 828 bytes for local variables. Maximum is 2560 bytes.
This is due to two things: A) the bootloader of the nano is smaller leaving more free flash space and B) the nano does not need USB at runtime which reduces the sketch size itself. Of course one can reduce sketch size on the arduboy by disabling the USB runtime part but you’ll then need the reset button to upload a new sketch.
Also the ram difference is less than 500 bytes since the USB runtime parts also need ram. It may additionally also use some heap and stack which would make the difference even smaller.
Another big plus for the Nano is the dedicated FTDI chip for USB to Serial, which means none of the dodgyness around failed uploads and trial-and-error reset timings (which seriously must account for such a significant percentage of the newbie FAQs here on the community?) this is something I raised way back when the final hardware specs were still up in the air…
If you disable USB using the functions provided by the Arduboy2 library, you can use the DOWN button to reset, instead of having to push the reset button.
But, as you’ve said, you can eliminate the USB code.
The main reason for the nano and the i2c display is that i wanted to use the parts i had lying around anyway. And have a look at the price tag. You can get all components for a total of less than $5. That’s something you can ask kids to pay when joining an “electronics afternoon class”. You can even buy all parts twice and let them assemble the breadboard variant and have them design a small pcb. The atmega328 is even available in dip package. I am still unconvinced about the power supply but i think something like http://r.ebay.com/uwFPNg and an AAA battery fits nicely.
This setup is so super trivial. You don’t need level shifters since with i2c the pullups are on display side and the signals will thus never rise above the displays own power level.
I am not trying to suggest that this super cheap setup is better than the real thing. There are definitely things the real thing does better, especially super geeky USB stuff. But several other threads here indicated that using the nano and/or an i²c display would have major drawbacks. That triggered my curiosity. And to my surprise the setup works totally acceptable and even has some unexpected advantage when it comes to flash space.
This is by no means an arduboy replacement. But if you just want to plug some cheap parts together to have some gaming fun then this is imho the right setup to go with.
A Nano clone and a Pro Micro clone are about the same price. A 0.96" SSD1306 based I2C or SPI OLED are also about the same price. So why not go with the more compatible Pro Micro and SPI OLED?
It might make more sense depending on where people are.
Around here, a Nano is far more easily available than a Pro Micro. Same goes for the I2C screen.
Nice job on making the port. I had a quick look at the display code and noticed
you’re using more than double the standard speed of 400KHz (~888.9KHz) this makes it half as slow as I previously thought. But doing some quick calculations, updating the display still takes about ~10.3 msec a frame so at 60 fps thats ~63% of MCU time where the original SPI display takes just ~6.9% of MCU time. This will cause lag with miscellaneous games.
If I was that kid though I’d rather pay $1-$2 more for a Pro Micro and SPI display for smooth games and easy upload.
Out of curiosity. What exactly are the components in that $5?
So you basically argue that what i am doing here isn’t powerful enough and that spending 50% more gives me something better? Isn’t that exactly what other people say about the arduboy?
The display is $2.40, the Nano is $1.40 and it’s possible to buy the rest for $1.20 …
I don’t want to start an argument but simply wanted to point out theres a considerable speed difference with using an I2C display. In your first post your writing:
Your down sizing the disadvantage. When someone who wants to build an Arduboy reads this they will get the wrong impression. It’s not slightly slower but almost 9 times slower. A sketch running at 60 fps will have about ~40% MCU power compared to a MCU with SPI display.
The I2C display isn’t necessarily cheaper then an SPI one. So if you can choose I2C isn’t the prefered choice.
Anyway It’s still cool that it’s possible on the atmega328 to shift data out over I2C faster than 400KHz. If this is possible with the atmega32u4 too. I’ll consider adding support to the homemade board package.
The videos look fine to me. I work for an IT company that sells top end $$ infrastructure amongst other things. Its amazing how two seemingly different machines (# of CPUs, memory, etc) perform similarly for normal use cases. The differences are very obvious in certain workloads however.
I assume the exercise here is to get the kids doing something - a little bit of electronics, some coding, learning and having fun. By the time one of them is writing code that pushes the screen refresh rates to the limit they will probably have already bought an Arduboy or moved on to something bigger.
What are you planning to use for support material?
As Disraeli (or was it Twain) said, ‘Lies, Damned Lies, and Statistics’.
I’m surprised ArduboyLife runs at all but I can’t imagine it’s running properly. The screen is double buffered. A copy of the screen buffer is made to a local variable array where it’s analysed and used to update the actual screen buffer for the next generation.
Each buffer is 1K, for 2K total. With only 2K available on a Nano, that leaves no RAM for any other variables or the stack or heap.
ArduboyLife would at least start. The second 1K screen buffer is a local variable which isn’t allocated until the Life engine function is called, so the initial start up screens will work properly.
Once the game is running, it’s possible that the allocated second buffer ends up overlapping part of the global screen buffer only, but no other global or local variables. This would likely result in the game appearing to run properly but in reality some cells would be corrupted.
In fact, it appears that there is corruption in the video.
We can use the fact that if no buttons are pressed, the initial “button help” screen is used as the starting pattern. Therefore, an untouched game will always run the same after powering up.
After about step 64, two honey farms have been generated near the top left corner. On a real Arduboy, both of these will remain until about step 835, at which point the right hand one will start to be destroyed. In the video, the right hand honey farm is destroyed shortly after the left hand one is created.
How does it run on I2C?
#/media/File:Conways_game_of_life_honey_farm.png){kind=link}