Very theoretical, and I’m not sure this is Q3VM related, but what if instead of reading bladestyles from the SD in real time, (which entails all that @profezzorn noted here: Blade Styles from SD post),
maybe someday there could be a way to load precompiled code from the SD card instead, so as to load different configs using just the saber?
Like, compile using config A, and store it on the SD.
Then compile using config B, and do the same.
Then have some way to make the board flash itself using one of those compiled packages?
Something along the lines of what this uses: Proffieboard programmer,
although I don’t see how it could work without a third party interface like a computer, unless there was a 3rd bootable area of the board that was the flasher, or this Q3VM magical thing.
Not Q3VM related at all, and not really all that theoretical either.
In fact, it’s a pretty good idea.
(Which is why I took the liberty of moving your post to a new thread…)
It would work something like this:
I would construct a program capable of reading the SD card and flashing memory. This program would need to fit in RAM.
Then ProffieOS could load that program from the SD card into RAM and execute it. At this point, the flash memory is not used anymore, so the RAM program can load data from the SD card and write it into flash memory. Once done, it will reset the chip to jump back into flash memory.
I’m not sure, but I don’t think writing this program would be all that difficult actually.
The harder problem might be that if this process fails, you need a computer to reprogram the board. The builtin bootloader would not know how to do it.
A related, but less compelling option would be to make an external flasher. A raspberry PI, or a teensy or possibly another proffieboard… something that could be connected to your saber to switch the program.
It seems like a good way to work around running out of memory by just having on-the-fly .bin file selection.
I can imagine some kind of prop-driven action that would activate the program chooser? Something way out of the way and unused like Shake while hold both buttons or whatever, or a dedicated switch. Maybe put that Rotary encoder code to use…
Maybe it is menu driven like preset selection… or, of course simple prev/next could work.
With delusions of grandeur, one could imagine Hilt ID and a universal chassis that loads the right programming based on the saber it’s in.
This would be pretty cool, especially if it could be done relatively quickly maybe? I’d imagine moving data from the SD card to the RAM to do all that would be pretty quick, right? (and the flashing process itself doesn’t take long as far as I’m aware…)
The main question I would have would be, if it’s seamless enough and could be used as another “layer” of moving through presets (maybe I’m very crazy here, but even appearing to the end user like a folder kind of system?), how badly does flashing wear down the chip? It’s not much of an issue with the way I think most people use their boards atm, but if it would be the sort of thing where you’re potentially flashing the board maybe a few times every single time you use it, as I’m thinking, that seems like you would drastically decrease the MCU lifespan.
From the data sheet, it looks like flashing can’t take less than 2 seconds.
The flash memory is only guaranteed to last for 10000 writes, so if you used it a lot it would wear down pretty quickly.
2 seconds, in addition to the extra time needed for moving the code, and rebooting shouldn’t be too bad then.
Also, unless my brain really isn’t working… let’s say you reflash 10 times a day, times 5 days a week, times 52 weeks in a year, and divide 10,000 by that, you still get nearly 4 years, and that is ridiculously heavy usage I think. If you picked it up once a week on average and reflashed 10 times, then that’s like 20 years.
And that’s the guaranteed amount, so you’d get possibly a bit more?
That’s a pretty crazy lifespan, since I think most people actively in the hobby who would be using their saber that much would also probably be looking forward to the next board also? And those who don’t have that heavy usage will probably break or get rid of the saber after 20 years, or that usage won’t be sustained and it’ll last longer?
Still a significant tradeoff, and it’s not like most people can just replace the mcu itself once it dies, but it doesn’t seem too life-decreasing to be a necessarily bad idea?
Yeah, no, I meant having a completely different switch to cycle through each bank of presets, so you have, say 20 in each, or a couple big ones in another
well I have one preset for all my FO cal fonts that like 24 fonts for one preset style. and one for my OWK and ANI fonts… I also use it for my vader font. You can have presets that cover many fonts. But to have all styles settings on SD card, would be a totally rework of the proffie OS. Even if its do able.
update your config(s) to match and you’re good to go.
Each sub-dir adds one read operation.
Reading subdirs takes one read per 16 entries, rounded up.
If you have 16 configurations, with 40 fonts each, you would get two extra reads compared
to having one configuration with 40 fonts. Each read takes ~0.3ms, so it adds up to an extra 0.6ms while opening files.
It’s not perfect, because each file open takes a little longer, but it’s better than just putting all the fonts in the root directory. If you put 16 * 40 fonts in the root directory, you get up to 40 extra reads, which would be 12ms, which will cause an audio glitch every time you open a file.
One possible solution to all of these issues is to have the EFFECT struct remember the fat entry and length that contains the directory that contains the entries for that set of files. By doing it that way, the path leading up to the font name doesn’t matter anymore.
There are a few reasons why I haven’t done this already though:
V3 and other new boards are intended to have faster SD access, which would make this moot
it’s a fair amount of work, because I would need to add code to the arduino-proffieboard plugin for opening and reading directories by fat entry rather than by filename.
It would make porting ProffieOS to new platforms harder, because these new platforms might not have or expose the APIs needed to open/read directory by fat entries.
Not sure I’m following all that this would entail, I’d just want to make sure this would be optional and/or wouldn’t take up memory or interfere with existing OS for those of us who would have no use for it. I assume so, but just wanted to put it out there. I can easily fit all of the presets I want on any saber AND I can easily update my saber anytime I get bored with them
I wonder if it’s possible to make the flashing code tiny? (like 8k or less) If so, it would be possible to to keep the flashing code in the flash memory as a secondary bootloader. This would make it possible to re-try if a a programming failed.
It also opens up an interesting possibility: It might be possible to control the flashing by simply switching the SD card. The secondary bootloader could check the SD card something to flash, and if it doesn’t match what is in flash memory, it would do the flashing before booting.
Wow really I have a little over 100 in my root. I never seem to have an issue. But if you had 16 preset x 40 fonts would be rather insane with 640 fonts running. I also run really fast cards.
But I will change it up how I handle the file management.
How much would it effect the flash if you were to switch cards multiple times a day. I know you where talking about a set up that flashed changes many times per day. And that would cause the memory to wear faster.
what about adding in bmp reading for ignition retraction and effects like blasters clashes? like what happens with the oled. Like CFX can do? It would give people without much technical knowledge to customize them. and you could vary up your presets. just by adding in these.
