[colug-432] c++ struct serialization?

[Rick Hornsby]

> On Dec 14, 2019, at 13:35, Mike Schoenborn <rtfm at columbus.rr.com> wrote:
> 
> On Thu, 12 Dec 2019 21:23:32 -0800
> Rick Hornsby <richardjhornsby at gmail.com> wrote:
> 
>> There’s no way the code should be this primitive … or better put,
>> dumb?
> 
> Something less "primitive" and something you may have experience
> using with Python/Ruby is JSON, or for this case "ArduinoJson".

Sorry, I didn’t mean to imply C++ was primitive. It is a lower level (closer to the metal) language for sure, but the _implementation_ stub I included in the OP seems caveman primitive and ugly to me.

> Your processor may experience a small performance hit, but your
> programming efforts will likely experience a performance benefit.
> 
> Based on the "3*RGB" in your code comments I'm guessing this application
> (or part thereof) isn't going to suffer from the time hit (Blinking
> Christmas lights, are we?).

Similar, yep. I’m building decorative stage lights using WS2812 strips.

For the moment, I have two predefined/hardcoded 3-color schemes. Along with some other “writable” config, I’m trying to use the ESP32’s EEPROM to store a third, custom, color scheme. The “preferences” library itself seems easy enough to use. You can read and write primitive types - various size ints, byte arrays, etc. Pretty much what’d you expect.

How to get from a struct that holds all the settings to an array of bytes, and array of bytes back to struct is where I’m having a hard time. While there might be architecture specific things to work out, I don’t think this is an ESP32 specific problem. I think if I can understand the general (x86?) case, I can work out the specifics.

Serializing the struct seems like the right way to do it. But there are other approaches, like explicitly storing each setting contained in the struct one at a time. That doesn’t scale, obviously.

>  On the other hand if your structure had to
> do with ESP32 transmit/receive registers and time critical code then the
> link Chris provided would be a good way to get down into the
> nitty-gritty.

Nah, it’s not at all time critical. In this case, the settings are only read from EEPROM on startup and only written when a message comes in over the network changing something.

Eventually I’ll drive the fixtures with DMX/ArtNet and keep no state on the ESP32 controller. For now, a semi-static approach is a compromise. This whole thing is also a learning exercise where I’m trying to figure how to do it right, rather than bludgeoning my way to a solution :)

One of the frustrations I’m running into is that I keep finding search results for MSFT C++ or C# - the latter of which is completely wrong (being more or less Java), and the former I’m not really sure, but seems Windows-specific.