Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Current state of programming embedded devices?

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 76 posts

Re: Ask HN: Current state of programming embedded devices?

#41

Post by striking »

contingencies wrote: post #40
striking wrote: post #10

Earlier quoted context omitted.

Dynamic languages have unpredictable usage of memory. This is okay when you have many gigabytes of memory. This is not okay when you have a handful of megabytes (or a single gigabyte) of memory. Being able to accurately profile how much memory will ever be in use is very valuable. Being able to prevent unexpected usage or stop-the-world collection issues means your device is that much safer. Also, static languages ar…

But if you can get by with a tiny ARM chip, why shouldn't you? Features, complexity, cost/availability of humans that can comprehend it, availability of existing software components, simplicity of software development process, etc.

ARM chips have feature parity with Atom chips except for their x86 architecture and power. ARM chips and their implementations are less complex, not more. Software components can be a bother, but ARM runs Linux perfectly well. If Linux doesn't suit your fancy, there are plenty of RTOS waiting for you.

And I kind of touched on the simplicity of software development. Yes, it's possible to quickly shove in a really tiny x86 computer and be done with it, but it ends up being cost prohibitive and energy hungry. Embedded environments are a place where you can get by with a tiny ARM chip; they're power efficient and cost effective. If you're in the embedded field, dev isn't as simple as a REPL, you have to put it directly on your device or otherwise emulate your device in some way. This forces you to come up with robust solutions.

Dev in this environment is already hard. It has to be robust anyway. Maybe we should pick the right tool for the job while we're at it.

And I am happy using a robust solution that I know won't fail me. If you're in a situation where failing to write bug-free code can kill, you would be too. Medical devices are one such field.

(But to each his own, of course! You can do awesome things with any tool.)

Re: Ask HN: Current state of programming embedded devices?

#42

Post by contingencies »

striking wrote: post #41
contingencies wrote: post #40

Earlier quoted context omitted.

But if you can get by with a tiny ARM chip, why shouldn't you? Features, complexity, cost/availability of humans that can comprehend it, availability of existing software components, simplicity of software development process, etc.

ARM chips have feature parity with Atom chips except for their x86 architecture and power. ARM chips and their implementations are less complex, not more. Software components can be a bother, but ARM runs Linux perfectly well. If Linux doesn't suit your fancy, there are plenty of RTOS waiting for you. And I kind of touched on the simplicity of software development. Yes, it's possible to quickly shove in a really tiny…

Complexity refers to overall cognitive load, hassle and lead time for developers and the business as a whole (hardware sourcing, cross-compiling, testing, etc.) and not just chip features.

Hard limits to processing power, memory, energy availability, etc. do exist in some applications, but the OP doesn't seem to have these issues.

Re: Ask HN: Current state of programming embedded devices?

#43

Post by tclmeelmo »

nickpsecurity wrote: post #38
tclmeelmo wrote: post #36

I don't think there's any simple answer to your specific questions based on what you've provided so far. I'm going to word vomit a bunch of stuff that might, with some Google/Wikipedia searches, help give you a better view (I hope!). I hope this is helpful. So much depends on the stage of the development process you're in, what the goal is of this project (i.e., internal testing, research use only, human use), when y…

This advice reflects what I've seen in safety-critical field reading on all kinds of deployments. This plus other comments to use simplest microcontrollers with tiny RTOS or no OS using simplified software. Good advice and good alias.

Thanks and thanks. To further bloviate, Tcl is my not-so-secret weapon. I first used it when doing exploratory work with some embedded one-off instruments and it made an impression because those doohickies are still running strong to this day, well beyond the design goal. They had sensors that were communicating over a serial console: Tcl made interfacing quick and painless, and a control GUI in Tk practically built itself. It's robust and a known quantity (flaws and all). There's also some level of je ne sais quoi where, like Lisp, I don't feel like I will paint myself into a corner: need more performance? drop down to C. language is limiting? make a better DSL. So I guess I'm either a fan or delusional (likely, both).

I don't personally know of anyone in medical using it, but your comment about no OS does prod me to say that I have wondered if running Forth on bare metal for medical is viable and/or desirable on a greenfield project. I'm not saying I would do it, but I would happily cheer on someone else. (OP, don't do this, I'm delusional)

And OP, I really hope that my wall of text won't be discouraging in any way. Personally, I found that documentation is (a la Homer Simpson) the cause of, and solution to, all of life's problems in a regulated environment. If you master that, document honestly and eagerly, it's downhill from there and life will be good.

Re: Ask HN: Current state of programming embedded devices?

#44

Post by pedalpete »

tlubinski wrote: post #13
pedalpete wrote: post #5

I'd go with a Raspberry Pi or other linux supported board. Particularly for prototyping. If you're looking at building an interface, are you considering web-based? I'm going to plug my own little project here, I'm also new to embedded development, but hate how everything is hard-coded to the platform you build on. I built a hardware agnostic library to make it easy to run your business logic on different hardware. It…

It's a good idea but I'd be worried it isn't "snappy" enough on (somewhat slow) embedded devices.

I think it depends on the application, I agree it isn't for everything.

What I find a bit funny about some embedded stuff is that I don't think performance is always as important as in other systems.

Consider something like Nest. If it takes 50ms or 500ms for the thermastat to respond, what is the implications. Compare that to a webpage, and all of a sudden, performance isn't a prime factor. Another example is a decibel meter I'm currently building. I need it to send data to a server when sounds reach above a certain level. How important is performance in that scenario. As well as things like Amazon's nifty little ordering button, I'm quite sure performance doesn't really matter on that.

So, in devices where performance is a primary concern, at the moment, javascript probably isn't the way to go. Though, with progress in things like asm.js, that may change in the near future too.

I'm not suggesting this is the tool for everything, but as I look at it, IoT probably has fewer use-cases where performance is a primary concern than other environments.

Of course, probably all safety systems, self-driving cars, drones, etc. etc. are not recommended to be done in JS... yet.. :)

Re: Ask HN: Current state of programming embedded devices?

#45

Post by manav »

tlubinski wrote: post #20
manav wrote: post #19

Raspberry Pi isn't an enterprise/medical grade device in my opinion. I wouldn't want to have a SD card as primary storage either. Do you need to integrate a lot of sensors or have a lot of IO?

No, data generation and collection is done by other components. I only need to send a start signal to those (through USB). This is only for UI.

Actually if that is your use case, why not use a tablet? You can get an enterprise level of support on the hardware side, and run on linux, android, or windows.

Re: Ask HN: Current state of programming embedded devices?

#46

Post by mangamadaiyan »

contingencies wrote: post #39
mrlyc wrote: post #3

I've done a few safety-critical embedded devices for medical equipment and an air traffic control system. We used Linux/C so we didn't kill people. The combination of "medical device" and "touch-based user interface" started me twitching. Some things to bear in mind are (1) will the interface work if the users are wearing rubber gloves? (2) there could be a problem with an infectious agent transferring from a patient…

We used Linux/C so we didn't kill people. I'm not sure that C the best language for life critical high level applications... it's far too easy to shoot yourself in the foot.

What alternative would you recommend?

Re: Ask HN: Current state of programming embedded devices?

#47

Post by [deleted] »

contingencies wrote: post #39
mrlyc wrote: post #3

I've done a few safety-critical embedded devices for medical equipment and an air traffic control system. We used Linux/C so we didn't kill people. The combination of "medical device" and "touch-based user interface" started me twitching. Some things to bear in mind are (1) will the interface work if the users are wearing rubber gloves? (2) there could be a problem with an infectious agent transferring from a patient…

We used Linux/C so we didn't kill people. I'm not sure that C the best language for life critical high level applications... it's far too easy to shoot yourself in the foot.

[deleted]

Re: Ask HN: Current state of programming embedded devices?

#48

Post by Matthias247 »

The current state is that there is no real current state of programming on those devices. In the real embedded device field (things that need to be cheap but still need to fulfill mission critical tasks with more or less realtime requirements) you have choices between lots of CPU architectures, dozens of realtime OSes or directly going the bare metal route and you will mostly develop in C (or maybe a subset of C++ - I guess most embedded compilers are still not up to C++11).

Depending on your safety and realtime requirements you might be very restricted on component choice as well as coding style. E.g. for a deterministic system no heap allocations might be allowed. I guess that should be the case for most medial devices.

However your project sounds more like an embedded device in the sense of "user can't modify it", but it is still running some PC/Smartphone like applications. For that kind of stuff Android and Linux are often seen (in order from most-consumer like to most realtime capable). You get the benefit of being able to reuse standard drivers, frameworks and applications but being able to guarantee that it will always work is basically impossible.

Many devices therefore also use a multi-cpu architecture, where the criticial stuff is running on a microcontroller with RTOS and the fancy UI is running on a speedier SOC with a normal OS.

QNX and GreenHills Integrity are somewhere in the middle, by providing a realtime OS which still incorporates some consumer features and are often chosen if a realtime device should directly draw UI.

You should checkout the detailed requirements for your projects and what would be possible and accepted. I guess medical has some quite strong regulations for certifications. And I'm sure using normal consumer chips (no extended temperature range, no certificated manufacturing process, ...) will always be not possible.

Re: Ask HN: Current state of programming embedded devices?

#49

Post by tlubinski »

boznz wrote: post #27

I don't want to sound too negative but If you have moved to a hardware company then the resident Electronics Engineer (EE) should be determining much of the embedded hardware configuration. Sure the choice of CPU architecture, OS, GUI Widgets etc will/should involve you but hardware choice is determined by user requirement, gui, reliability (watchdog timers, failure modes), power requirements, BOM Costs/long term ava…

Thanks, but the Electronics Engineer will ask you what you'd like to run on this device and then pick a suitable piece of hardware. Cost is not our biggest concern.

Re: Ask HN: Current state of programming embedded devices?

#50

Post by tlubinski »

Matthias247 wrote: post #48

The current state is that there is no real current state of programming on those devices. In the real embedded device field (things that need to be cheap but still need to fulfill mission critical tasks with more or less realtime requirements) you have choices between lots of CPU architectures, dozens of realtime OSes or directly going the bare metal route and you will mostly develop in C (or maybe a subset of C++ -…

> The current state is that there is no real current state of programming on those devices.

Yes, that's what I suspected but I feel there _should_ be some advices/best practices.

Post reply on HN