Binary sketch size: 28,350 bytes (used 99% of a 28,672 byte maximum) (1.26 secs)

Binary sketch size: 28,350 bytes (used 99% of a 28,672 byte maximum) (1.26 secs)

Either I need to stop adding dynamic patterns to my POV code, find more ways to cut the size, or replace the hardware. I could get rid of the bootloader and gain 4K, but then I also lose USB support, which I need.

You’re going to have to store those patterns in external memory. Or store the patterns mathematically. Bit like moving from bit-mapped fonts to vector (TT).

They are already done mathematically. And I have no idea of how to dump them to something external and have the MCU read them in when it needs them. Honestly, I think I just need to stop. 13 internal patterns is plenty. It’s meant to use the external SD card anyway. The internal ones are in case there isn’t an SD card present.

28,278 as of right now … found a couple of stray INTs and rewrote one of routines that called random8() excessively …

Sorry. I was rather brief with the concept.

As most uses of Atmel chips use a compiled language, rather than an interpreted language, it is impossible to have nice commands, such as eval().

So your only choice here is to create an ‘interpreted’ language. This core program sits in the Atmels program memory and runs from there. The program ‘executes’ instructions (p-code) from other memory (e.g. external flash or SD card). This is where the ‘code’ for your patterns exist. Not in the Atmel memory. You can ‘buffer’ to a certain extent in RAM if needed.

A lot of work, but very rewarding results. A dedicated interpreted language for the display of LED patterns. Almost unlimited possibilities then. You can keep adding more and more p-code memory without needing to alter the interpreter. With an SD card, your ‘programs’ can be individual files pulled as needed.

This, I think is a parallel to FastLED. The interpreter is a complete product (with FastLED as its core), like the Arduino boot loader and is loaded once by the developer into their platform. Then the developer writes p-code patterns and this is what they load. Rather compiling C code. The concept is a bit like a programmable logic controller (PLC).

It is over the top, but once the basics are implemented, the addition of extra p-code functions would be pretty easy. And it should still be pretty responsive. It would make alterations and new projects very easy once the ground work is done.

Yeah, that’s well outside the scope of the Arduino IDE, not to mention my own brain cells. :slight_smile:

Hey @Adam_Sharp , do you have any links to documentations or what not that I can peruse about this particular method you’re talking about? Not that I’m planning on implementing it, but I want to read and find out more about it.