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

11–20 of 76 posts

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

#11

Post by tlubinski »

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…

Thanks for your input. (1) resistive screens and some capacitive screens can handle rubber gloves fine. (2) for our use-case (non-invasive blood sugar measurements) this is a non-issue, but out of curiosity: how is a touch screen different from a physical button (or the whole case) in this regard?

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

#12

Post by tlubinski »

analog31 wrote: post #6

I work in scientific equipment, and there is a huge trend towards devices containing a touch screen with some amount of computing power. I take a look at what competitors are using, and have opened up some gadgets. The two main things for newer equipment seem to be: * Android, when the product offers a host of mainstream computing features. I think the rationale for going with Android is: "The user already knows how…

Yep, I bought a SOM for testing. It can run Linux, Android 4.4 and Windows 7 Embedded. Windows was pre-installed so I gave it a test-run and it looks and feels very 1990s. Hence my question.

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

#13

Post by tlubinski »

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.

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

#14

Post by extrapickles »

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…

Generally for embedded work, you want to avoid any and all complexity as much as humanly possible. In most critical embedded programming its all statically allocated and has shallow call stacks (eg: a call depth of more than 8 is forbidden).

For devices that connect to the internet, I prefer a two processor approach where a very simple processor does the critical work (eg: being a thermostat), and a more general purpose processor (raspberry pi, etc) handles the human interaction (GUI or webpage) and uses your more standard programming approaches. This way if the main CPU suffers a fault, it doesn't make the device worse than useless as the simple processor is doing things like making sure the commanded temperature is not too hot/cold, the temperature actually is changing when the heat is on, etc.

With dynamic languages or even using dynamic memory you can run into unpredictable pauses that can literally cause things to catch on fire (see 3d printer extruder fires).

A good example of the lengths you go through for embedded programming is the JPL coding standard: http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

edit: fixed grammar

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

#15

Post by viraptor »

Depends on what reliability / response time / etc. you need. The requirements you list are not very specific. You should also look at what interaction you need and what kind of regulation applies to your device (since it's a medical setting, this may influence your choice).

You can potentially go with bare microprocessors and something like http://femtoos.org/ to just small ARM devices with windows. You can do everything on one chip, or split the device drivers onto separate chips and drive them over I2C where specific timing is crucial.

There are many options - I'd start with listing exactly what you need to support (display, io, inputs, timing, single/multi chip, what timing / other guarantees, hardware watchdogs, failsafe states, etc.) and then choose hardware/software based on that.

If you want to produce many devices, I'd stay away from consumer devices like RPi. Simply because you may get stuck with a supply shortage. You can pretty much always order 1k of popular chips, even if it's a shipment from Asia. You may not be able to do the same for a popular RPi model. Also some RPis will get phased out / discontinued at some point and for a medical device you may need to recertify the new model before release.

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

#17

Post by viraptor »

tlubinski wrote: post #11
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…

Thanks for your input. (1) resistive screens and some capacitive screens can handle rubber gloves fine. (2) for our use-case (non-invasive blood sugar measurements) this is a non-issue, but out of curiosity: how is a touch screen different from a physical button (or the whole case) in this regard?

Have a look at panels on devices like ECG. Usually these don't even have real buttons exposed. A common approach here is to make the whole device as smooth as possible so there are no not-cleanable holes / ridges. For example displays will be actually behind transparent part of the case, not sticking out / in a hole. Same with buttons - all of the actual switches will be behind pillow-like buttons built into the case.

See http://g02.a.alicdn.com/kf/HTB1fNYoHVXXXXbkXFXXq6xXFXXXt/Fre...

Edit: also when considering industry / medical devices, keep in mind that most touchscreen are not meant for the conditions these devices are in. You should be able to splash water / gel / oil / ... over it and just wipe it afterwards. They should also survive people who think they just need to press it harder if it responds slowly. Simple buttons (with extra protective cover) are more likely to survive this. Next time you're around in the hospital, check out how many of the button labels are completely worn down.

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

#18

Post by davidw »

tlubinski wrote: post #16
davidw wrote: post #7

We used an Android tablet for the UI here: http://www.centervue.com/productdb19.html?id=919 Other stuff is separate.

that looks great. And you used C++ or Java?

Android is programmed in Java. Other parts of the system were done with other languages.

That architecture worked for us - it may well not work for other needs, depending on communication latencies, costs, and so on.

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

#20

Post by tlubinski »

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.
Post reply on HN