3 ms·

I read this as "embedded devs don't know how to consume REST APIs", and I also found it unlikely. Where this might become difficult is when embedded projects t

I read this as "embedded devs don't know how to consume REST APIs", and I also found it unlikely. Where this might become difficult is when embedded projects try to re-invent the wheel instead of just using existing code for these things. I was on an embedded project a few years ago that had this problem -- the real-time/embedded devs wanted to use some crazy board that couldn't run anything useful (proprietary modified version of C compiler), and thus were going to have to implement an entire network stack just to be able to talk to an API server. We ditched their approach and went with a board that could run Rust and the rest was easy.

whatshisface 6y ago
>I read this as "embedded devs don't know how to consume REST APIs", and I also found it unlikely. >the real-time/embedded devs wanted to use some crazy board that couldn't run anything useful You said it was unlikely, but then described how it happens. The reflex of many embedded devs is not to use big processors running standard software speaking standard protocols. IoT represents people realizing that there are many applications where it's a good idea to use a $20 board and standard software to do something that could technically be accomplished by a $0.02 chip and 100 different serial protocols.
- LeifCarrotson 6y ago
  There was a great primer on embedded Linux boards by Jay Carlson a couple weeks ago that touched on the network limitations and various tradeoffs that devices in this class need to make: https://jaycarlson.net/embedded-linux/ https://jaycarlson.net/embedded-linux/ In summary, if you can't have your IoT device plugged into the wall, or connected by a "crazy" 802.15.4 low-power serial wireless network to a hub device that is, and especially if you have BOM cost constraints, battery life requirements, or processing needs that mean you can't use Linux or lwIP, you're going to have a bad time.
- sam0x17 6y ago
  I guess my followup question then is "why do embedded board manufacturers design boards that don't work with industry standard tools and languages"?
jbay808 6y ago
> the real-time/embedded devs wanted to use some crazy board that couldn't run anything useful (proprietary modified version of C compiler) Lots of chips have proprietary compilers. Something as simple as an MSP430 fits that description, which would probably be a choice driven by battery life requirements. I'm sure you checked with the embedded devs before you "ditched" their "crazy" approach, but did they have any reasons behind it?
- sam0x17 6y ago
  For them it was a matter of preference. The board they selected was priced similarly to the pi zero, but they were afraid of making things too easy I guess ;)

whatshisface 6y ago

>I read this as "embedded devs don't know how to consume REST APIs", and I also found it unlikely. >the real-time/embedded devs wanted to use some crazy board that couldn't run anything useful You said it was unlikely, but then described how it happens. The reflex of many embedded devs is not to use big processors running standard software speaking standard protocols. IoT represents people realizing that there are many applications where it's a good idea to use a $20 board and standard software to do something that could technically be accomplished by a $0.02 chip and 100 different serial protocols.

LeifCarrotson 6y ago
There was a great primer on embedded Linux boards by Jay Carlson a couple weeks ago that touched on the network limitations and various tradeoffs that devices in this class need to make: https://jaycarlson.net/embedded-linux/ https://jaycarlson.net/embedded-linux/ In summary, if you can't have your IoT device plugged into the wall, or connected by a "crazy" 802.15.4 low-power serial wireless network to a hub device that is, and especially if you have BOM cost constraints, battery life requirements, or processing needs that mean you can't use Linux or lwIP, you're going to have a bad time.
sam0x17 6y ago
I guess my followup question then is "why do embedded board manufacturers design boards that don't work with industry standard tools and languages"?

jbay808 6y ago

> the real-time/embedded devs wanted to use some crazy board that couldn't run anything useful (proprietary modified version of C compiler) Lots of chips have proprietary compilers. Something as simple as an MSP430 fits that description, which would probably be a choice driven by battery life requirements. I'm sure you checked with the embedded devs before you "ditched" their "crazy" approach, but did they have any reasons behind it?

sam0x17 6y ago
For them it was a matter of preference. The board they selected was priced similarly to the pi zero, but they were afraid of making things too easy I guess ;)