6 ms·

IoT is just the sexy name for embedded, and folks have been doing embedded remotely for a long time. You need someone local to set things up (just like you nee

IoT is just the sexy name for embedded, and folks have been doing embedded remotely for a long time. You need someone local to set things up (just like you need on-prem IT folks to deal with equipment), but for 95% of the use cases, you can set up simulators, cameras, and remote access equipment to develop embedded software.

whatshisface 6y ago
IoT is embedded plus an internet connection. The internet connection is sometimes a big deal that changes a lot. There have been "run the wire from A to B" networks of controllers since forever, but with an internet connection the number of links grows as N instead of N^2, and you can connect to nodes around the world with no additional cost. For some applications, that's hugely significant. Internet protocol is huge and unweildy, but since you can buy standard components and install free software to handle it, it gains another huge advantage over the "100 serial protocols" world of yesteryear.
- sam0x17 6y ago
  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 ;)
com2kid 6y ago
> IoT is just the sexy name for embedded, and folks have been doing embedded remotely for a long time. When I worked on embedded, we had to take boards down to the lab to get rewired/modified not too infrequently. All of the preproduction boards that ever came in straight from the factory needed reworking, and being able to change things 'as needed' was super useful. Having someone sitting in the next office over with an oscilloscope to help debug strange issues on a bus was useful. Embedded is one of those fields where it really is an entire team with distinct, but overlapping, skills all working together. One of the MEs can do some EE, some of the EEs can code, some of the software engineers can do EE work and assembly, a few of the UI people know how to do assembly and C++, some of the C++ people know how to work with design and marketing, and if everyone works together a product ships out the door. Could it be done remotely? Sure, but productivity would take a huge drop.
pvarangot 6y ago
IoT is only a part of embedded, and no it's not anything with a micro-controller and an internet connection. Aerospace, automotive, automation and self driving, oil and gas, power... all of those employ thousands of embedded engineers. Saying the nav systems for a plane, a satellite, an electric car of a self driving system are "IoT" only because they have a network connection and you can pull and push stuff to them from the Internet is a a stretch. There's also a lot of consumer electronics that are not IoT, like peripheral software for laptops and consoles, appliances, audio, musical instruments, toys, displays and signage, etc...

whatshisface 6y ago

IoT is embedded plus an internet connection. The internet connection is sometimes a big deal that changes a lot. There have been "run the wire from A to B" networks of controllers since forever, but with an internet connection the number of links grows as N instead of N^2, and you can connect to nodes around the world with no additional cost. For some applications, that's hugely significant. Internet protocol is huge and unweildy, but since you can buy standard components and install free software to handle it, it gains another huge advantage over the "100 serial protocols" world of yesteryear.

sam0x17 6y ago
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 ;)

com2kid 6y ago

> IoT is just the sexy name for embedded, and folks have been doing embedded remotely for a long time. When I worked on embedded, we had to take boards down to the lab to get rewired/modified not too infrequently. All of the preproduction boards that ever came in straight from the factory needed reworking, and being able to change things 'as needed' was super useful. Having someone sitting in the next office over with an oscilloscope to help debug strange issues on a bus was useful. Embedded is one of those fields where it really is an entire team with distinct, but overlapping, skills all working together. One of the MEs can do some EE, some of the EEs can code, some of the software engineers can do EE work and assembly, a few of the UI people know how to do assembly and C++, some of the C++ people know how to work with design and marketing, and if everyone works together a product ships out the door. Could it be done remotely? Sure, but productivity would take a huge drop.

pvarangot 6y ago

IoT is only a part of embedded, and no it's not anything with a micro-controller and an internet connection. Aerospace, automotive, automation and self driving, oil and gas, power... all of those employ thousands of embedded engineers. Saying the nav systems for a plane, a satellite, an electric car of a self driving system are "IoT" only because they have a network connection and you can pull and push stuff to them from the Internet is a a stretch. There's also a lot of consumer electronics that are not IoT, like peripheral software for laptops and consoles, appliances, audio, musical instruments, toys, displays and signage, etc...