4 ms·

Solving these problems does not require moving to Linux, though. > Raw socket communication is bad because if the socket is dropped, you have to reinitialize i

Solving these problems does not require moving to Linux, though. > 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.

seanalltogether 9y ago
I get the point you're trying to make, but making everything custom adds cognitive load that isn't necessary and restricts your design space. The more time you spend thinking about your custom solutions, the less time you can spend on features that differentiate your product. I had to troubleshoot an issue that a higher up in the company was having with their bridge at home. I asked him to hit a specific endpoint on his bridge in the browser and send me the result, a win for HTTP. We just released swagger docs for internal devs and 3rd parties to plug into without needing to spend time writing excessive documentation on what our data format look like, a win for JSON. The list goes on for all the extras you get for free when working with standardized tools.
- minipci1321 9y ago
  > The list goes on for all the extras you get for free when working with standardized tools. I guess this is the balance between how much less you pay for standardized tools and tech (and R&D), and how much more for all the BOM extensions required. TTM may be important too, favoring using of-the-shelf techs. On the long run, and with big quantities, the balance might actually justify the custom-made. However, it is with the big quantities deployed that the issues of firmware upgrade -- reliability, ease of use, security -- become really serious, tipping the balance again towards the standard tech.
  - ianhowson 9y ago
    With big quantities, BOM cost becomes the overriding factor. It's the reverse of the web dev scalability argument. In web dev, you go for high abstraction and divisible components because it's the only way to handle more requests per second while keeping the software flexible. In hardware, to scale the business, you need to keep BOM cost low. To do this, you must use cheaper (smaller) hardware and specialize the software to fit. You need to eliminate abstraction and keep the software as tight as possible. Even bootup time matters -- 30 seconds for Linux to boot adds $1 of manufacturing floor time per device. Linux adds massive BOM cost, and once you're shipping more than 5000 devices per year, it's usually worthwhile to eliminate it.

seanalltogether 9y ago

I get the point you're trying to make, but making everything custom adds cognitive load that isn't necessary and restricts your design space. The more time you spend thinking about your custom solutions, the less time you can spend on features that differentiate your product. I had to troubleshoot an issue that a higher up in the company was having with their bridge at home. I asked him to hit a specific endpoint on his bridge in the browser and send me the result, a win for HTTP. We just released swagger docs for internal devs and 3rd parties to plug into without needing to spend time writing excessive documentation on what our data format look like, a win for JSON. The list goes on for all the extras you get for free when working with standardized tools.

minipci1321 9y ago
> The list goes on for all the extras you get for free when working with standardized tools. I guess this is the balance between how much less you pay for standardized tools and tech (and R&D), and how much more for all the BOM extensions required. TTM may be important too, favoring using of-the-shelf techs. On the long run, and with big quantities, the balance might actually justify the custom-made. However, it is with the big quantities deployed that the issues of firmware upgrade -- reliability, ease of use, security -- become really serious, tipping the balance again towards the standard tech.
- ianhowson 9y ago
  With big quantities, BOM cost becomes the overriding factor. It's the reverse of the web dev scalability argument. In web dev, you go for high abstraction and divisible components because it's the only way to handle more requests per second while keeping the software flexible. In hardware, to scale the business, you need to keep BOM cost low. To do this, you must use cheaper (smaller) hardware and specialize the software to fit. You need to eliminate abstraction and keep the software as tight as possible. Even bootup time matters -- 30 seconds for Linux to boot adds $1 of manufacturing floor time per device. Linux adds massive BOM cost, and once you're shipping more than 5000 devices per year, it's usually worthwhile to eliminate it.