Thinking about this for a long time I’ve decided to re-factor all of my stm32 code to make it more versatile. I need to be able to turn on/off peripherals at will and set them on a schedule. The current system is very static.

So I’ve devised a way to use nodes and serve them up and configure them at will based on the server. This helps a lot with configuration and should help me put an easy configuration face onto any stm32.

I’m still torn between the PI and my hardware. I think I could add my current hardware to the PI and get really good expand ability + camera on the raspberry pi; however, I want to make sure the users are able to configure and tweak all of the settings through their pi rather then just get a video stream.

Goals:

Hardware Comm agnostic(can switch from usart to spi etc)
All perph have standard
One state machine, schedules
Will work well with Pi
each perph has its own commands

Protocol:

Encapsulated, multiple commands at once inside
ID:TotalSize:[ID:Size:Data …. n …. ID:Size:Data]CRC
The outer “ID” is the id of the server or hardware, the inner “ID” is the id of the command that will handle “Size” amount of data. The data is as such
CMD:Data
so for example a “update schedule (0x01?)” command that sends data 0xFF will cause the perph to fire on every interval of the state machine. Commands that span perphs will start with 0 commands that are custom will start at 0xFF down. So for instance a command that sends video config data will start from the upper range, and a 0xFF will mean different things to different perphs.

Actually I think we could get away with no overall size and just have a identifier followed by data. On the client side we reset on the id and continually calculate crc till we have a match.