8 ms·

PSA: Networking on microcontrollers is a giant pain in the ass. Don't get me wrong, boards like this (and ESP/Realtek boards with WiFi) are great for hacky pro

by ohazi 6y ago

PSA: Networking on microcontrollers is a giant pain in the ass. Don't get me wrong, boards like this (and ESP/Realtek boards with WiFi) are great for hacky prototypes. But if you're building an embedded device that will be deployed in any sort of volume, a small application processor running Linux will make your life dramatically easier. You can keep it asleep most of the time if your power budget is tight. The hard part is not cramming in an Ethernet PHY or a 2.4 GHz radio, it's the mountain of software that you need to run on top of it to get the kind of reliable, secure communications channels that we've come to expect. Bare metal networking stacks like LwIP have a reputation for being buggy, and are nowhere near as battle-tested as the Linux/BSD networking stacks security-wise. Some of the more memory constrained devices can barely fit a complete certificate chain. Are you really prepared to roll out updates on a system like this when the next Heartbleed comes along? Also, the layers tend to pile on, so while you might get away with a bare-bones wire protocol initially, you'll be starting your project close to the limits of what is practical. Somebody will eventually ask you if you can connect to a websocket. I know buildroot and yocto look a little scary at first, but they're better than designing yourself into a corner before you even get off the ground.

realharo 6y ago
How are things on the commonly used RTOSes? I'm not really into hardware much, only fairly recently learned basic electronics as a hobby, but I've seen ARM push their "mbed" (https://os.mbed.com/ https://os.mbed.com/) thing in many places recently (most recently saw their logo printed on a nRF52 BLE dev kit). I've also seen Amazon get more involved with (in charge of?) FreeRTOS (https://aws.amazon.com/freertos/ https://aws.amazon.com/freertos/) quite some time ago. Don't such things solve most of these issues?
- adammunich 6y ago
  The RTOS world is much less of an 'operating system' and more so a bare-bones task scheduler. It's not like a POSIX environment at all.
  - realharo 6y ago
    Right, but doesn't it also provide some very basic level of abstraction that things like network stack implementations can target? And then many projects also come with their "standard" (not bundled, just designed for) set of basic libraries? That's the impression I'm getting from skimming through the docs. (https://docs.zephyrproject.org/latest/guides/networking/net-stack-architecture.html https://docs.zephyrproject.org/latest/guides/networking/net-..., https://www.mbed.com/en/technologies/security/mbed-tls/ https://www.mbed.com/en/technologies/security/mbed-tls/, https://docs.aws.amazon.com/freertos/latest/userguide/freertos-mqtt-2.html https://docs.aws.amazon.com/freertos/latest/userguide/freert..., etc.)
    - jnwatson 6y ago
      You are correct.
  - nikofeyn 6y ago
    that's not really true anymore. it may apply to things like pharlap or vsworks, but there are more modern options that give you a nice real-time linux environment. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/installation_guide/chap-why_use_rt_to_optimize_latency https://access.redhat.com/documentation/en-us/red_hat_enterp... https://www.ni.com/en-us/innovations/white-papers/13/introduction-to-ni-linux-real-time.html https://www.ni.com/en-us/innovations/white-papers/13/introdu...
    - numpad0 6y ago
      Linux with RT patches isn’t exactly RTOS, it’s Linux with such patches.
      - nikofeyn 6y ago
        how is it not an RTOS? and national instruments and red hat are both large companies that would seem to disagree with you. national instruments has completely replaced pharlap and vxworks in their newer products with their linux real-time OS, so them and their users writing real-time applications would also disagree with you.
- comboy 6y ago
  I wonder what's your use case for RTOS? I don't really know any problems that couldn't be solved with micros communicating with linux. Seems like even SpaceX gets away with it. I mean there seem to be the market so clearly there are some people who need it, I just would like to learn more about where is it really needed.
  - realharo 6y ago
    Stuff powered from a coin cell battery?
    - comboy 6y ago
      From coin cell battery you can power a microcontroller that is sleeping most of the time, not a real-time operating system.
      - dekhn 6y ago
        You can do exactly this with an ESP32. It's got an RTOS (FreeRTOS) which will spend most of its time sleeping https://learn.circuit.rocks/esp32-deep-sleep https://learn.circuit.rocks/esp32-deep-sleep
        comboy 6y ago
        Debatable. Personally I would not try to do a project that uses wifi on a cell battery. And if you don't need wifi then you have much better options that use low current not only while sleeping (e.g. nrf series) But my main point which I should have included in the previous reply was - what does real time OS have to do with the project being run from a cell battery?
        realharo 6y ago
        So my assumptions in the original question a number of comments above (in the context of the comment above it) were: - something running regular Linux would be too heavy (though I don't know if that's really the case, especially if you only turn it on a few times a day on average for a little bit) - adding the "OS" abstraction would presumably result in access to higher quality ecosystem of libraries than whatever is available on bare metal directly (as I assume some of those libraries depend on the "OS" for event handling etc.) - which was the complaint in the comment I was replying to But like I said, I know very little about this area, so if any of this doesn't make sense, just ignore my comment :D
ex3ndr 6y ago
I was puzzled finding a good linux board for cheap device. Decent linux is like 10$ price minimum and you probably need something better. It could easily sky rocket to 30$ and this is out of budged of almost any devices. 30$ makes your device retail cost ~100$ already. While you can get M4 for under a 1$ having all built in and very power efficient. Also no need to hustle with linux deployment and update rollouts.
closeparen 6y ago
>Are you really prepared to roll out updates on a system like this when the next Heartbleed comes along? Implying that embedded systems get updated...
- HeyLaughingBoy 6y ago
  Lots of them do. I have a bigass board right next to me with a couple dozen wires sticking out that can get updates by flash drive. We ship tons of hardware that gets updated over Ethernet or OTA.
subhobroto 6y ago
> The hard part is not cramming in an Ethernet PHY or a 2.4 GHz radio, it's the mountain of software that you need to run on top of it to get the kind of reliable, secure communications channels that we've come to expect Have you looked into PJON?
im_down_w_otp 6y ago
The power budget isn't the only reason you go for an MCU. Often you're doing it for the real-time guarantees or the hardware qualification (e.g. for applications where you need something with a safety rating). That said, yes... TCP/IP based networking in the traditional embedded world isn't comparatively pleasant.
cactus2093 6y ago
On a similar note, does anyone know of good resources for beginners for prototyping all the way through small-scale manufacturing of an embedded device? As a web & backend developer who likes to tinker with Arduino/Teensy style projects, I've always been curious what all would be involved in actually getting some units manufactured, like for a small kickstarter run or something. It seems pretty doable these days to get pcb boards printed and even assembled once you have a final design. What I haven't been able to find much of, is advice along the lines of going from a prototype board like an Arduino or Teensy system, to a productionalized system in terms of both the software and hardware - what platform is easiest to build on (like this advice to use a Linux-based system if you need any networking), how to hook up a bootloader, how to build a system that allows users to update firmware for future bugfixes or features, etc. plus I'm sure there are a million other unknown unknowns I would never even think of.
- looperhacks 6y ago
  Lately I've been prototyping a small board with my goal of maybe 10 units built. For me, the process is literally putting it together on a breadboard to check if it works, then design a PCB and send it to a Chinese manufacturer. Repeat if your PCB design is faulty. (Do double check your design though, you don't want to pay for new boards and shipping every other week)
  - cactus2093 6y ago
    I guess one big gap for me is just the build process of how to even load code onto the device to be executed, and what type of EEPROM or flash storage or other components are required for that, once you've removed the training wheels of the plug and play dev environment.
    - cowboysauce 6y ago
      It really depends on what you're using. Most microcontrollers don't require external memory to store their program because it's stored in on-chip flash memory. Additionally, you can generally order microcontrollers from a distributer that are already flashed with your program. Though this may require ordering 1000+ units. If that isn't an option then you'll have to ensure that the pins used for programming are exposed in some fashion and then you'll flash it. The exact details are dependent on exactly which microcontroller and toolchain you're using. It mostly comes down to reading the documentation for the specific microcontroller that you're using.
MrBuddyCasino 6y ago
But what to use? The Pi Zero can't be used for mass-production, because you can't get it in quantity. Other options exist, but they are even more expensive, or obscure chinesium for which you can't get documentation or someone to talk to.
- joefourier 6y ago
  If you want an decently peforming SBC that can match the Pi Zero in price, unfortunately you're out of luck. But if you're willing to put in a bit of work, make your own board and suffer most things not working out-of-the-box, you have a wide variety of cheap SoCs and MPUs. E.g. the STM32 MPU line, which has a decent enough ecosystem and plenty of devboards available, and has some chips under $5/unit in bulk.
  - MrBuddyCasino 6y ago
    None of which have wifi, as far as I can see?
    - joefourier 6y ago
      You need an external module for WiFi, but the standard Linux networking tools and drivers work.
    - numpad0 6y ago
      The original ESP8266 ESP-01 was among such devices to add Wi-Fi to host CPU over SPI or UART...
- chillacy 6y ago
  Is particle.io considered one of the more expensive ones? I've used them for one-off projects but it looks like they do volume discounts.
- throwaway9d0291 6y ago
  Development kits like the Pi Zero are usually intended solely for development and experimentation. When it comes to production, you either take the product the dev kit is wrapped around or there's some kind of module you can use. For example Raspberry Pi has the Compute Module, ESP32 comes as a solderable module and for the Teensy I suspect you'd just put a IMXRT1062 in your design.
jnwatson 6y ago
There are several vendors of embedded RTOSs that will give you a decent TCP stack. Especially on the lower end, Linux is not a good option.
rwmj 6y ago
It has a 32 bit processor and at least 1 MB of RAM and 8 MB of flash. This makes it considerably more powerful than the first PC I owned. Could it run Minix 3?
- Hello71 6y ago
  as I recall, PCs from the 90s also had extremely poor networking support.
- ChuckMcM 6y ago
  Yes. And in fact a 32 bit microprocessor with a meg of flash and 256K of RAM can run a number of useful OSes that have networking capability. What I find interesting about the situation is the Arduino environment. The Teensy originated as an "Arduino" type dedicated controller board. The Arduino environment originated on something that had 32K of flash memory and 2K of RAM. (Think Altair 8800 or IMSAI 8080). It was designed so that people new to embedded controllers could get something running quickly on a very simple processor. The Cortex-M architecture (which the Teensy uses, as does the STM32 parts) is somewhere between the 68000 and the 80286 in terms of its capability (no MMU though). On at $30 dev-board (STM32F429-DISCO) from ST-Micro I've run a full shell/loadable program environment with networking based on a FreeRTOS kernel and a shell of my own devising. It is the Arduino environment that cripples these things, if they ran the equivalent of MS-DOS none of these complaints would make any sense at all. (and they are very capable of running that level of OS)
baybal2 6y ago
> But if you're building an embedded device that will be deployed in any sort of volume, a small application processor running Linux will make your life dramatically easier. Can you name some? I think of most embedded network stacks as being easier than raw socket APIs on Linux or Windows. Programming network on Linux only looks that easy because of megatons of ready to use abstraction libraries available.
chapplap 6y ago
Yes, this is a very good point. Low-end application processors capable of running Linux are also very cheap now and it is easy to build a minimal system for around a few bucks (eg. Allwinner F1C100s, although it does not have an Ethernet MAC built in). Not great for hard real-time stuff, but if the requirements there are limited a separate microcontroller could work.
CamperBob2 6y ago
Look at the NetBurner products. For the most part they Just Work, and their uCos-derived OS is a pleasure to use. It has a distinctly simplistic old-school vibe, but they have updated it to support WebSockets and numerous other new(ish) features. The end result is a good compromise between LwIP and full-blown Linux/BSD. No association with the company, just a satisfied user.
freefriedrice 6y ago
That's a matter of opinion. If you don't know jack about network programming, then of course you can retreat to Linux. But Linux is not an edge / IoT platform by any stretch of the imagination. Micro RTOS is closer, but still overkill for embedded Wi-Fi. Specifically for Wi-Fi, LWIP is -the- stack to use for embedded TCP/IP. It is under 30K with full TCP/IP and offers everything you need. Then there is COAP or MQTT, which are miniscule compared to HTTP. mbedTLS adds another 80K for full TLS compatibility on 40MHz processors. On top of this every major wifi vendor has an SDK that fits nicely into LWIP (some even ship it), some are small (CC5000) some are larger (like the WF200), but the APIs are pretty straightforward. Now, leaving TCP/IP and 802.11 will add headaches (BLE, ZigBee, Zwave) due to additional learning curves, but only because most people in embedded networking already understand TCP/IP and 802.11 phy. If you want to play in the embedded space, you gotta learn about it. Running back to linux might work in some cases, but not constrained IoT space. EDIT: I had my #s reversed, LWIP is under 30K, mbedTLS is around 80K, TLS is most of that (esp. RSA stuff, I could have disabled everything I didn't need [mbed has highly granular config] based on the ciphersuite and shrunk it considerably since ECC is smaller and faster than RSA). Just checked my map file, and I was in -O0 optimization mode. EDIT2: On second thought: if people want to complain that they need linux to do networking on the edge, please complain! I'll interview after you and demonstrate MQTT with TLS v1.3 running off an MCU with a 2032 coincell for months (eh, I'm weirdflexing a little, but still...)
- ohazi 6y ago
  I think it's less a matter of opinion and more a question of expectations around the device you're building. To illustrate, let's say we build the embedded device your way. Six months later, we get a support request from a customer that needs to get the device onto the captive portal at a hotel. The portal is a javascript monstrosity full of CORS failures. What is your immediate response? a) Oh, shit, I didn't think of that. I can probably come up with a workaround, but I'll need at least a month, and it'll end up being a huge hack that involves tethering with a phone or laptop (but not via WiFi, since the radio we're using can't do AP and STA modes simultaneously), and the UI will be such a disaster that the customer is immediately going to want to find a better product. or b) This is an industrial CNC controller... WTF are you doing on a hotel WiFi network? If your answer is (a), then your approach is almost certainly the wrong one. If your answer is (b), your approach might be reasonable, but there are still other factors to consider. It's possible to know everything there is to know about network programming but still not want to debug or re-implement 30 years worth of accumulated cruft around firewalls, MTU sizes, MS-CHAPv2 bugs, malformed packet crashes, anything IPv6, etc. And that's just the table stakes... leaky abstractions mean that sooner or later, everything connected to the internet is going to need to do something higher up the stack that's just barely out of reach for your microcontroller, even one that's beefy enough to run Windows 95. What are you going to do when there's some new web standard where the only implementation is in the Chrome source code as of three months ago? You'll be able to make it work, but it'll take thousands of person-hours to make it work well. Or you can just "run back to Linux." Separately, if you're running a company that builds embedded devices, do you want to pay your engineers to fix network stack bugs that were solved in 1999, or do you want to pay them to develop your company's value-add? Weirdflex all you like, it's still (usually) a terrible business decision. I don't think pennypinching on the BOM is a valid justification when things like [1] exist. [1] https://www.seeedstudio.com/MT7688AN-BIT3-1-Module-p-4011.html https://www.seeedstudio.com/MT7688AN-BIT3-1-Module-p-4011.ht...
swiley 6y ago
I totally get what you're saying. Although I'll add that Linux has it's fair share of networking bugs and quirks (less now than before, but still plenty.)
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
vaxman 6y ago
Instead of that, how about an nRF5340 running Linux Foundation's Zephyr Project OS on its application core?

by ohazi 6y ago

realharo 6y ago

How are things on the commonly used RTOSes? I'm not really into hardware much, only fairly recently learned basic electronics as a hobby, but I've seen ARM push their "mbed" (https://os.mbed.com/ https://os.mbed.com/) thing in many places recently (most recently saw their logo printed on a nRF52 BLE dev kit). I've also seen Amazon get more involved with (in charge of?) FreeRTOS (https://aws.amazon.com/freertos/ https://aws.amazon.com/freertos/) quite some time ago. Don't such things solve most of these issues?

adammunich 6y ago
The RTOS world is much less of an 'operating system' and more so a bare-bones task scheduler. It's not like a POSIX environment at all.
- realharo 6y ago
  Right, but doesn't it also provide some very basic level of abstraction that things like network stack implementations can target? And then many projects also come with their "standard" (not bundled, just designed for) set of basic libraries? That's the impression I'm getting from skimming through the docs. (https://docs.zephyrproject.org/latest/guides/networking/net-stack-architecture.html https://docs.zephyrproject.org/latest/guides/networking/net-..., https://www.mbed.com/en/technologies/security/mbed-tls/ https://www.mbed.com/en/technologies/security/mbed-tls/, https://docs.aws.amazon.com/freertos/latest/userguide/freertos-mqtt-2.html https://docs.aws.amazon.com/freertos/latest/userguide/freert..., etc.)
  - jnwatson 6y ago
    You are correct.
- nikofeyn 6y ago
  that's not really true anymore. it may apply to things like pharlap or vsworks, but there are more modern options that give you a nice real-time linux environment. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/installation_guide/chap-why_use_rt_to_optimize_latency https://access.redhat.com/documentation/en-us/red_hat_enterp... https://www.ni.com/en-us/innovations/white-papers/13/introduction-to-ni-linux-real-time.html https://www.ni.com/en-us/innovations/white-papers/13/introdu...
  - numpad0 6y ago
    Linux with RT patches isn’t exactly RTOS, it’s Linux with such patches.
    - nikofeyn 6y ago
      how is it not an RTOS? and national instruments and red hat are both large companies that would seem to disagree with you. national instruments has completely replaced pharlap and vxworks in their newer products with their linux real-time OS, so them and their users writing real-time applications would also disagree with you.
comboy 6y ago
I wonder what's your use case for RTOS? I don't really know any problems that couldn't be solved with micros communicating with linux. Seems like even SpaceX gets away with it. I mean there seem to be the market so clearly there are some people who need it, I just would like to learn more about where is it really needed.
- realharo 6y ago
  Stuff powered from a coin cell battery?
  - comboy 6y ago
    From coin cell battery you can power a microcontroller that is sleeping most of the time, not a real-time operating system.
    - dekhn 6y ago
      You can do exactly this with an ESP32. It's got an RTOS (FreeRTOS) which will spend most of its time sleeping https://learn.circuit.rocks/esp32-deep-sleep https://learn.circuit.rocks/esp32-deep-sleep
      - comboy 6y ago
        Debatable. Personally I would not try to do a project that uses wifi on a cell battery. And if you don't need wifi then you have much better options that use low current not only while sleeping (e.g. nrf series) But my main point which I should have included in the previous reply was - what does real time OS have to do with the project being run from a cell battery?
        realharo 6y ago
        So my assumptions in the original question a number of comments above (in the context of the comment above it) were: - something running regular Linux would be too heavy (though I don't know if that's really the case, especially if you only turn it on a few times a day on average for a little bit) - adding the "OS" abstraction would presumably result in access to higher quality ecosystem of libraries than whatever is available on bare metal directly (as I assume some of those libraries depend on the "OS" for event handling etc.) - which was the complaint in the comment I was replying to But like I said, I know very little about this area, so if any of this doesn't make sense, just ignore my comment :D

ex3ndr 6y ago

I was puzzled finding a good linux board for cheap device. Decent linux is like 10$ price minimum and you probably need something better. It could easily sky rocket to 30$ and this is out of budged of almost any devices. 30$ makes your device retail cost ~100$ already. While you can get M4 for under a 1$ having all built in and very power efficient. Also no need to hustle with linux deployment and update rollouts.

closeparen 6y ago

>Are you really prepared to roll out updates on a system like this when the next Heartbleed comes along? Implying that embedded systems get updated...

HeyLaughingBoy 6y ago
Lots of them do. I have a bigass board right next to me with a couple dozen wires sticking out that can get updates by flash drive. We ship tons of hardware that gets updated over Ethernet or OTA.

subhobroto 6y ago

> The hard part is not cramming in an Ethernet PHY or a 2.4 GHz radio, it's the mountain of software that you need to run on top of it to get the kind of reliable, secure communications channels that we've come to expect Have you looked into PJON?

im_down_w_otp 6y ago

The power budget isn't the only reason you go for an MCU. Often you're doing it for the real-time guarantees or the hardware qualification (e.g. for applications where you need something with a safety rating). That said, yes... TCP/IP based networking in the traditional embedded world isn't comparatively pleasant.

cactus2093 6y ago

On a similar note, does anyone know of good resources for beginners for prototyping all the way through small-scale manufacturing of an embedded device? As a web & backend developer who likes to tinker with Arduino/Teensy style projects, I've always been curious what all would be involved in actually getting some units manufactured, like for a small kickstarter run or something. It seems pretty doable these days to get pcb boards printed and even assembled once you have a final design. What I haven't been able to find much of, is advice along the lines of going from a prototype board like an Arduino or Teensy system, to a productionalized system in terms of both the software and hardware - what platform is easiest to build on (like this advice to use a Linux-based system if you need any networking), how to hook up a bootloader, how to build a system that allows users to update firmware for future bugfixes or features, etc. plus I'm sure there are a million other unknown unknowns I would never even think of.

looperhacks 6y ago
Lately I've been prototyping a small board with my goal of maybe 10 units built. For me, the process is literally putting it together on a breadboard to check if it works, then design a PCB and send it to a Chinese manufacturer. Repeat if your PCB design is faulty. (Do double check your design though, you don't want to pay for new boards and shipping every other week)
- cactus2093 6y ago
  I guess one big gap for me is just the build process of how to even load code onto the device to be executed, and what type of EEPROM or flash storage or other components are required for that, once you've removed the training wheels of the plug and play dev environment.
  - cowboysauce 6y ago
    It really depends on what you're using. Most microcontrollers don't require external memory to store their program because it's stored in on-chip flash memory. Additionally, you can generally order microcontrollers from a distributer that are already flashed with your program. Though this may require ordering 1000+ units. If that isn't an option then you'll have to ensure that the pins used for programming are exposed in some fashion and then you'll flash it. The exact details are dependent on exactly which microcontroller and toolchain you're using. It mostly comes down to reading the documentation for the specific microcontroller that you're using.

MrBuddyCasino 6y ago

But what to use? The Pi Zero can't be used for mass-production, because you can't get it in quantity. Other options exist, but they are even more expensive, or obscure chinesium for which you can't get documentation or someone to talk to.

joefourier 6y ago
If you want an decently peforming SBC that can match the Pi Zero in price, unfortunately you're out of luck. But if you're willing to put in a bit of work, make your own board and suffer most things not working out-of-the-box, you have a wide variety of cheap SoCs and MPUs. E.g. the STM32 MPU line, which has a decent enough ecosystem and plenty of devboards available, and has some chips under $5/unit in bulk.
- MrBuddyCasino 6y ago
  None of which have wifi, as far as I can see?
  - joefourier 6y ago
    You need an external module for WiFi, but the standard Linux networking tools and drivers work.
  - numpad0 6y ago
    The original ESP8266 ESP-01 was among such devices to add Wi-Fi to host CPU over SPI or UART...
chillacy 6y ago
Is particle.io considered one of the more expensive ones? I've used them for one-off projects but it looks like they do volume discounts.
throwaway9d0291 6y ago
Development kits like the Pi Zero are usually intended solely for development and experimentation. When it comes to production, you either take the product the dev kit is wrapped around or there's some kind of module you can use. For example Raspberry Pi has the Compute Module, ESP32 comes as a solderable module and for the Teensy I suspect you'd just put a IMXRT1062 in your design.

jnwatson 6y ago

There are several vendors of embedded RTOSs that will give you a decent TCP stack. Especially on the lower end, Linux is not a good option.

rwmj 6y ago

It has a 32 bit processor and at least 1 MB of RAM and 8 MB of flash. This makes it considerably more powerful than the first PC I owned. Could it run Minix 3?

Hello71 6y ago
as I recall, PCs from the 90s also had extremely poor networking support.
ChuckMcM 6y ago
Yes. And in fact a 32 bit microprocessor with a meg of flash and 256K of RAM can run a number of useful OSes that have networking capability. What I find interesting about the situation is the Arduino environment. The Teensy originated as an "Arduino" type dedicated controller board. The Arduino environment originated on something that had 32K of flash memory and 2K of RAM. (Think Altair 8800 or IMSAI 8080). It was designed so that people new to embedded controllers could get something running quickly on a very simple processor. The Cortex-M architecture (which the Teensy uses, as does the STM32 parts) is somewhere between the 68000 and the 80286 in terms of its capability (no MMU though). On at $30 dev-board (STM32F429-DISCO) from ST-Micro I've run a full shell/loadable program environment with networking based on a FreeRTOS kernel and a shell of my own devising. It is the Arduino environment that cripples these things, if they ran the equivalent of MS-DOS none of these complaints would make any sense at all. (and they are very capable of running that level of OS)

baybal2 6y ago

> But if you're building an embedded device that will be deployed in any sort of volume, a small application processor running Linux will make your life dramatically easier. Can you name some? I think of most embedded network stacks as being easier than raw socket APIs on Linux or Windows. Programming network on Linux only looks that easy because of megatons of ready to use abstraction libraries available.

chapplap 6y ago

Yes, this is a very good point. Low-end application processors capable of running Linux are also very cheap now and it is easy to build a minimal system for around a few bucks (eg. Allwinner F1C100s, although it does not have an Ethernet MAC built in). Not great for hard real-time stuff, but if the requirements there are limited a separate microcontroller could work.

CamperBob2 6y ago

Look at the NetBurner products. For the most part they Just Work, and their uCos-derived OS is a pleasure to use. It has a distinctly simplistic old-school vibe, but they have updated it to support WebSockets and numerous other new(ish) features. The end result is a good compromise between LwIP and full-blown Linux/BSD. No association with the company, just a satisfied user.

freefriedrice 6y ago

That's a matter of opinion. If you don't know jack about network programming, then of course you can retreat to Linux. But Linux is not an edge / IoT platform by any stretch of the imagination. Micro RTOS is closer, but still overkill for embedded Wi-Fi. Specifically for Wi-Fi, LWIP is -the- stack to use for embedded TCP/IP. It is under 30K with full TCP/IP and offers everything you need. Then there is COAP or MQTT, which are miniscule compared to HTTP. mbedTLS adds another 80K for full TLS compatibility on 40MHz processors. On top of this every major wifi vendor has an SDK that fits nicely into LWIP (some even ship it), some are small (CC5000) some are larger (like the WF200), but the APIs are pretty straightforward. Now, leaving TCP/IP and 802.11 will add headaches (BLE, ZigBee, Zwave) due to additional learning curves, but only because most people in embedded networking already understand TCP/IP and 802.11 phy. If you want to play in the embedded space, you gotta learn about it. Running back to linux might work in some cases, but not constrained IoT space. EDIT: I had my #s reversed, LWIP is under 30K, mbedTLS is around 80K, TLS is most of that (esp. RSA stuff, I could have disabled everything I didn't need [mbed has highly granular config] based on the ciphersuite and shrunk it considerably since ECC is smaller and faster than RSA). Just checked my map file, and I was in -O0 optimization mode. EDIT2: On second thought: if people want to complain that they need linux to do networking on the edge, please complain! I'll interview after you and demonstrate MQTT with TLS v1.3 running off an MCU with a 2032 coincell for months (eh, I'm weirdflexing a little, but still...)

ohazi 6y ago
I think it's less a matter of opinion and more a question of expectations around the device you're building. To illustrate, let's say we build the embedded device your way. Six months later, we get a support request from a customer that needs to get the device onto the captive portal at a hotel. The portal is a javascript monstrosity full of CORS failures. What is your immediate response? a) Oh, shit, I didn't think of that. I can probably come up with a workaround, but I'll need at least a month, and it'll end up being a huge hack that involves tethering with a phone or laptop (but not via WiFi, since the radio we're using can't do AP and STA modes simultaneously), and the UI will be such a disaster that the customer is immediately going to want to find a better product. or b) This is an industrial CNC controller... WTF are you doing on a hotel WiFi network? If your answer is (a), then your approach is almost certainly the wrong one. If your answer is (b), your approach might be reasonable, but there are still other factors to consider. It's possible to know everything there is to know about network programming but still not want to debug or re-implement 30 years worth of accumulated cruft around firewalls, MTU sizes, MS-CHAPv2 bugs, malformed packet crashes, anything IPv6, etc. And that's just the table stakes... leaky abstractions mean that sooner or later, everything connected to the internet is going to need to do something higher up the stack that's just barely out of reach for your microcontroller, even one that's beefy enough to run Windows 95. What are you going to do when there's some new web standard where the only implementation is in the Chrome source code as of three months ago? You'll be able to make it work, but it'll take thousands of person-hours to make it work well. Or you can just "run back to Linux." Separately, if you're running a company that builds embedded devices, do you want to pay your engineers to fix network stack bugs that were solved in 1999, or do you want to pay them to develop your company's value-add? Weirdflex all you like, it's still (usually) a terrible business decision. I don't think pennypinching on the BOM is a valid justification when things like [1] exist. [1] https://www.seeedstudio.com/MT7688AN-BIT3-1-Module-p-4011.html https://www.seeedstudio.com/MT7688AN-BIT3-1-Module-p-4011.ht...

swiley 6y ago

I totally get what you're saying. Although I'll add that Linux has it's fair share of networking bugs and quirks (less now than before, but still plenty.)

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

vaxman 6y ago

Instead of that, how about an nRF5340 running Linux Foundation's Zephyr Project OS on its application core?