Earlier, I mentioned that you have to write in 16-byte pages to the device. This applies only when writing to the NVRAM, probably as a safeguard to protect it from faulty code.

This means I should be able to perform a 256-byte write with all the register data, which I load from the project file using an XML library. Before doing that, I need to test writing to the registers.

I chose IO12 because it isn't connected to anything, and I successfully changed its configuration using the byte write function I created. Afterward, I implemented a reset function: if you write a 1 to register 1601, it resets the device and reloads settings from NVRAM. This worked perfectly, and the device returned to factory defaults. I suppose we have to treat register 1601 as a "scary bit" during NVRAM programming. Could it send the device into a boot loop, or is it disabled in the NVRAM? I don't want to find out.

Next, I need to include the XML library, read the NVRAM portion from the selected project file, feed that into our register_data vector, and send it. If successful, the device should have the functionality I specified from the cookbook example.

Suddenly, from the dark corners of the room, feature creeps appeared, or are they scope creeps? One of them suggested, "You should make an awesome CLI interface for the SLG46826V GreenPAK program!" Another one chimed in, "You should use TUI and include all the cool stuff!" Then, someone quickly interjected, "Cursive is the way to go. It's a tool and shouldn't be bloated." The discussion was on, but I tried to ignore them. Still, another voice said, "We should use another SLG46826V to manage power for all systems!" Yet another stepped out of the shadows, saying, "There are PowerPAKs for that purpose, and we should use one of those instead!" I made a note for the later stages of the project, where I will look at power management.