undefined | Better HN

0 pointsohazi5y ago0 comments

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.

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

0 comments

aswanson5y ago

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

pingswept5y ago

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

freefriedrice5y ago

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.

ohaziOP5y ago

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.

nitrogen5y ago

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.

nine_k5y ago

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.

1 more reply

LeifCarrotson5y ago

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.

ohaziOP5y ago

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

j / k navigate · click thread line to collapse

0 pointsohazi5y ago0 comments

I think it's less a matter of opinion and more a question of expectations around the device you're building.

What is your immediate response?

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.

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

[1] https://www.seeedstudio.com/MT7688AN-BIT3-1-Module-p-4011.ht...

0 comments

aswanson5y ago

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

pingswept5y ago

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

freefriedrice5y ago

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

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.

ohaziOP5y ago

nitrogen5y ago

nine_k5y ago

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

1 more reply

LeifCarrotson5y ago

I completely agree, it depends on your expectations.

ohaziOP5y ago

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.

j / k navigate · click thread line to collapse