> Raw socket communication is bad because if the socket is dropped, you have to reinitialize it
I don't know what to say here. This is a fundamental requirement of network programming and not a difficult one to meet.
Best case, you can re-use an existing connection. Worst-case, you have to establish one from scratch, which puts you in exactly the same position as an HTTP-based solution.
Once you factor in the large time required to establish an SSL session on a small CPU, you really want to think about holding connections open.
> new commands require lots of custom dev instead of using a standard REST library
You still need to implement the REST client and server code.
> Binary packets...
If you're reading fields out of a struct with no version checking or inline layout description, with full knowledge that the layout might change, again, I have no words. This is basic software engineering. The packet length ought to tell you which frame format you've got...
JSON doesn't really solve this. You've got limited RAM, remember? There's no limit on the length of a JSON document.
At least use protobufs or Avro or something.
> bridge data was stored in a custom vector format
Not all the world's an SQL database. An array of structs will fit even the tiniest computers and serve most of the same use cases.
> built an entire bridge around udp thinking this would mean everything would be 1 or 2 milliseconds faster
Eliminating TCP session startup and teardown could easily explain this. It sounds like a reasonable decision for some applications.
> they used to just download new firmware over http, check the hash and then apply it directly
Most cheap IoT devices do exactly this. It's not good, but it's common, and if you have a simple recovery bootloader it works well enough.
Using the A-B partition switching makes this mechanism basically foolproof (once you add verification of firmware blobs).
So you can do one of two things:
1. Run Linux and try to do in-place updates 2. Run something smaller and use the extra flash space for a backup partition
I would go for (2) every time on robustness and simplicity grounds. My clients prefer it too as it makes their devices cheaper and simpler.