Comment by freefriedrice | Hacker News Reader

Comment by freefriedrice | Hacker News Reader

Parent Full thread

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...)

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.ht...

True. Software is soft for a reason. There's always a new requirement or vulnernability waiting to be exploited that needs to be updated.

You're very good at inventing creative scenarios. Well done.

I don't really know where to start, you clearly want to defend your comfort zone. So I will be supportive: go work on projects that require Linux. It will be much more rewarding to you than working on constrained edge devices that are more challenging due to resource constraints.

You're also free to pretend that you can just swap in platform that requires watts of power in a scenario that requires an edge device to last a year on a battery.

Look, if you really need to get a coin cell onto the internet, then go for it. But I don't think your comments on this thread represent good advice for most engineers building typical devices. Insinuating that anyone who doesn't agree with your view is technically challenged is also kind of pathetic.

Expectations around what an internet connected device should look like and be capable of changed permanently with the launch of the iPhone in 2007. There will always be special cases like yours, but they are increasingly (sadly?) relegated to smaller corners of the internet.

I did it your way for years. Every company I've ever worked for that started off with a microcontroller based networking solution eventually migrated to an application processor because users and non-technical management kept demanding iPhone-like behavior that was either too difficult or too time consuming to deliver any other way. People expect a lot more functionality than just TCP sockets and web interfaces nowadays.

I'll add that it's not just capabilities that matter, but also the open Internet gets more and more hostile over time. In the absence of proof otherwise, eventually someone is going to transmit something that makes your device misbehave.

There are devices where both BOM and size constraints matter. Do you want to run Linux on every smart power socket, smart light switch, smart light bulb in your house? A light bulb in particular has tight volumetric and thermal budgets.

This is where stuff like ESP8266, and the controller from the post, makes sense.

I don't own any smart bulbs, but yeah -- this is a good example of a case where using a microcontroller is probably reasonable. I can't imagine people enjoy paying >$25 per bulb, and there's evidence that users are willing to put up with some truly appalling UX to get those things connected [1].

Amusingly, the most reliable smart outlet I own runs Linux on that MediaTek SoC I linked above (~500 MHz MIPS, 32MB RAM). I mean, power is definitely not a constraint when you're an inch away from the prongs, right? ¯\_(ツ)_/¯

[1] https://www.belkin.com/us/support-article?articleNum=116178

That Mediatek module is nice! Thanks for that, and for the wisdom.

I completely agree, it depends on your expectations.

With the caveat that it's not a one-way trade-off of "better" vs. "good enough for the expectations". If your customer calls you and says "My industrial CNC controller crashed and ruined a $20k prototype, is this my fault or yours? Here are the logs." and your answer is "the browser was running bad javascript that locked up too many threads for too long so it stopped counting the encoder for 20 ms", they're going to tell you that a servo amplifier has no business doing any of that stuff.

Some devices do need to be on the Internet and should therefore be running general-purpose operating systems. They may need to interact with other devices that run real-time operating systems (or bare metal, like the Teensy). Some IoT devices try to bridge the gap. Knowing and deciding which side you're on is critical.

And I think the best answer to pennypinching on the BOM is to separate your concerns into separate devices/apps. Make the CNC HMI handle the Internet connectivity. Give it one NIC that hooks up to the Wifi, let it run whatever Javascript you want. On a separate NIC, talk whatever flavor of industrial protocol you prefer on the machine. Do not bridge the two. In the servo amp, use a bare-metal/RTOS microcontroller. That device doesn't need to be burdened with Linux, and in fact is made worse by it: Let it be what it is and no more. In 20 years, it should still run reliably, regardless of whatever newfangled holographic VR HMI is loading in motion profiles.

Exactly, use the right tool for the job.

FPGAs and microcontrollers are really good for meeting (and verifying that you're meeting) hard real-time constraints.

Network connectivity (by definition) can't be real-time, so you wouldn't want to run a network stack on the real-time core anyway, even if you could.

Instead of adding another non-real-time microcontroller for networking and making it sweat, go with an application processor and just treat it like a dumb modem that happens to know how to handle VPN traffic without exploding.

There are application processors like the i.MX7 and the STM32MP1 that combine a Cortex-M4 and a Cortex-A7 on the same die for precisely this reason (and similar FPGA fabric + PowerPC / ARM Cortex-A? products from Xilinx and Altera for even longer).

Is that why they say the S in IoT stands for Security?

Reply on news.ycombinator.com