…and I doubt it would work as solidly and consistently as this does! @Mr.Blinky has engineered a great solution here - why would you want to switch to SD cards?
I have seen so many issues, even with massive commercial products, where a particular brand or size or even specific batch of SD cards just don’t work - and it becomes a guessing game / experiment for users to hope that theirs will… not to mention all the hidden / system files that infiltrate an SD card every time a user plugs it in to a different machine!
I think @Mr.Blinky made the absolute correct decision moving away from SD cards and towards this design. I remember reading some comments on reddit from BennVenn (who has ‘been there’, and done the work of implementing low-level FAT / SD libraries) that really cemented it for me:
Anyway, if this leads to further discussion then let’s agree now to start a new thread about it rather than fill this one up with tangential debate!
I’d definitely would need that spare 1K for that. But i’m not persuing the SD card idea. In a nutshell flash memory is more reliable, lightweight to interface with and convenient.
Yeah, it’s pretty awesome. I just can’t really see the Arduboy 2 going that way. It really doesnt fit in your pocket if it requires you to carry around 20 flash cartridges with it. Otherwise it’s awesome. So many amazing cartridge systems over the years.
Spent an hour yesterday curating a good 60 games and setting up images for the games selection screen and I am still nowhere near the max amount that can fit the 16MB chip I bought. Now if only we had a GUI based solution to automatically scrub .arduboy archives for the necessary hex, png, and title info, update the cart index csv file, make the cart bin using blinky’s python script, and allow direct uploading to an arduboy with installed cart (with blinky’s screen patching selection of course). Not that it’s difficult doing everything manually, but it would streamline the process to have such a utility.
It should be trivial to do all this and I would myself but I’m a bit overextended right now with side projects. That plus it’s been ages since I’ve done anything gui related in java (I’m more of a real time embedded high power system controller programmer now).
Too bad we can’t simply act as a USB disk device. Or could we? I know the ARM CPUs can… it’s still a device, not a host… is there some difference to be a Storage Device or perhaps the code would just be too large?
I had a quick question about the use of game saves in eeprom and the flash cart that may have been answered before that I have not seen (if so forgive me). So if you have multiple games that use the same locations in eeprom to save progress what happens? Is there contention and the data is overwritten/corrupts or is the eeprom backed up to the serial flash before a new game is flashed (which then would overwrite eeprom with its own save data)? Thanks for putting up with my silly questions.
Maybe too much german but maybe if leads to some new ideas. They solved the software upload issue by transmitting the data via a 3.5mm audio jack and coding the data by frequency shift keying. So with the online editor, after you have finished your animation, you can upload your data via the audio plug to the rocket. I thought this might be feasible to upload data to the cartridge? Just an oldschool 3.5mm jack, pc, volume up and off you go.
I’ve also seen projects that use a phototransistor or properly reverse biased LED that can read color flashes on an lcd screen to transfer data. The idea then would require no physical connection or special hardware. Just hold the device to a screen, play the video file or web applet that flashes a small box in the center of the screen, and download the new program.
They get over written. The bootloader has no support to backup/restore eeprom. sketches can use backup or restore saves in flash memory though.
Altough fun (reminds of of writing a 22KHz tapeloader for ZX spectrum), loading from audio is inferior to Arduboys USB loading. Its also much easier to optain a micro USB cable then a 3.5mm audio jack cable.
I’ve seen some projects using LEDs as phototransistors before. A single led to transmit and receive. Pretty cool. It would be cool if two Arduboys could kiss each other to transfer data. But since the LEDs are tied to Vcc I’m not sure if this is possible.
Using lcd screen ‘color’ flashes for transfering data will be really slow.
Let there be no misunderstanding. The data is currently written to the flash cart over USB in bootloader mode. The same way as a sketch is written to Arduboy.
I only brought up using color as a means of encoding as you can increase bandwidth (each channel is a subcarrier) but would require more I/O and some clever coding. This is what the reasearch into LIFI uses to transfer HD video in real time just using overhead RGB based lighting. Alternatively using an LED as a light detector still requires a specific color as the bandgap of the LED determines both what color light it emits as well as the spectral response of its sensitivity.
Phototransistors and LEDs are inherently fast so a bandwidth in the range of MHz is possible, the limiting factors would be transmission distance (without a bandwidth wasting carrier like ir uses with 38kHz you are likely to see only a few inches with lots of errors) and the atmega depending on how the transmit and receive are coded. Should be possible to use a protocol like UART serial though so we could utilize the hardware to handle everything. I think I’ll throw together a demo with variable packet length, crc and retransmit requests when I get some time and see how fast I can push it.
Did a quick board design for how a sd card shaped version of the flashcart would look. The pins are laid out such that no damage will occur if you accidentally put this in an actual sd card slot or put a real sd card in the arduboy. Dimensions for all features are pulled from the official sd card spec. This would be the base contact layer half thickness with another pcb layer glued on top (with cutout for the chip) to allow the thickness to match an sd card. Plenty of room to add status led indicators or add two more pins for other functionality. Any level shifting would have to occur in the arduboy and a standard sd card socket can then be used with this card (either friction fit or click in, click out). I can have some prototypes made for free through my youtube pcb manufacturing sponsor.
each other to transfer data. But since the LEDs are tied to Vcc I’m not sure if this is possible.