It’s worth noting that it’s not guaranteed to be unique and many people haven’t bothered to set theirs either through lack of awareness or simply not feeling the need to.
The author should be informed for any game that does this. The system EEPROM area (the first 16 bytes) is off limits for use by sketches. Sketches should use EEPROM_STORAGE_SPACE_START and above.
But it could be made unique enough for the purposes of keeping track of individual Arduboys for a given dock.
For an ID that’s never been set, it will read back as 0xFFFF. The dock could use this to warn about an unset ID and possibly even allow setting the ID, along with listing the IDs that it’s already handling, to avoid duplicates.
That’s a clever idea.
Yey! The clock functionality
And the communication protocol is almost done.
I want one! (plus some extra characters to get me over 20 !)
So, this time the “streaming” of games is actually working. In the past the list was hardcoded to the Arduboy, not anymore. Here is a quick glimpse of the functionality:
It is not clean and cheap (in memory) but gets the job done. Also kudos to @Pharap for several advices and tips. I would appreciate any help in the code, open to changes, etc:
I am thinking on getting all the functionality working first and then start to polish stuff. I am going to focus now on how to create the savegames, load them, detect current game, etc.
This looking sooooooo good !
With the bit your working on now it should also know what arduboy is being used
It’s not a big deal as I would imagine most only play on the production version, but one of my goals is build all of the current games to work on dev kit
Does it need to be Jessie lite?
No, but that is the smallest
How on earth did I miss this thread I remember seeing the teaser post, this is so cool I can’t put it into words. Has there been anymore progress with features?
You’re not the only one. I just discovered this thread. Awesome project @eried I’m wondering now if I could add a simple dock loader to the bootloader so it doesn’t have to be flashed as a sketch. I haven’t looked into your project yet but simple display and scanbuttons commands should be feasable.
I hate to be the one to mention it but the one downside to this project is that it reduces the write lifetime of the flash memory because it increases the number of times the memory is flashed, but otherwise it’s a very good project.
That’s why I’m thinking of adding some support to the bootloader to allow writing to display and read buttons. So you could use Arduboy as a mini terminal to control the docking station.
Not really but the lastest version works OK, load and update games from my repo, clock functionality, etc. So, besides polishing it (listing the games is slow and buggy), the functionality is there.
Any known figures about when the flash stops working? because considering:
That means if you upload 20 games a week, arduboy can safely live 10 years -> 5 years if all those games were loaded from my dock
Hmmm I load a game up to 100 times a day when I’m testing things, but it will last at least a year I’m ok with that
I think you are safe for many years, Atmel estimations are pretty conservative, i.e. eeprom:
The 32u4 datasheet also claims 10,000 Flash cycles, which means if the device were flashed 28 times a day it would be dead within a year.
Realistically it’s probably more than that, they probably under-estimate as a precaution.
I think it’s still worth considering designing an Arduboy Dock 2.0 (or an Arduboy Dock Type B) with a screen and buttons.
Unless @Mr.Blinky can pull off a bootloader miracle of course, in which case you’ll have the best of both: not needing a screen or buttons and not halving the Arduboy’s lifespan.
But just note that there’s a difference between program flash memory and EEPROM.
The ATmega32U4 datasheet states:
Write/Erase Cycles: 10,000 Flash/100,000 EEPROM
EEPROM is rated for 10 times as many write cycles as program flash. However, I won’t argue that the ratings in either case may be conservative.