Hi, I made a few devices like that in the medical sector. Back then it was Windows CE, today Linux would be the way to go i guess. If you are like me, using Raspberry pi & co after decades of windows development, check out VisualGDB. Microsoft recently released a similar product as native Visual Studio Plugin. I understand they plan to support cross compiling as well. That will be so awesome.
Ask HN: Current state of programming embedded devices?
21–30 of 76 posts
Re: Ask HN: Current state of programming embedded devices?
#22Hi, I made a few devices like that in the medical sector. Back then it was Windows CE, today Linux would be the way to go i guess. If you are like me, using Raspberry pi & co after decades of windows development, check out VisualGDB. Microsoft recently released a similar product as native Visual Studio Plugin. I understand they plan to support cross compiling as well. That will be so awesome.
no one tried Win 10 IOT yet? ;)
Re: Ask HN: Current state of programming embedded devices?
#23I work at a company that's in the food industry. Currently, we're running Linux with Qt 4 on PowerPC. We're moving to a newer CPU (i.MX6 quad core). Freescale announced that they would continue manufacturing and supporting it for 15 years and it comes in industrial grade and consumer grade packaging depending on your needs. We're moving away from Qt for the GUI. HTML5 is the way of the future. ;) For people who are s…
Why are you moving away from Qt?
Re: Ask HN: Current state of programming embedded devices?
#24I work at a medical device consultancy, but we're mostly developing custom Class B/C devices at the bare metal level. It sounds like you'll be developing a Class A device and cost isn't a huge issue so I'd probably recommend going the Android route. Find a reputable supplier who's worked with medical devices before, and check their availability guarantee (since the production lifetime of most Android devices is short).
Class A basically means follow common sense, so as long as document your architecture/design, use source control and test critical parts of the code you should be right to use whichever Android development framework you want.
Re: Ask HN: Current state of programming embedded devices?
#25usage of the Leap motion controller should actually be encouraged more, right here!
Re: Ask HN: Current state of programming embedded devices?
#26This is a framework for medical software development, they have a few papers talking about the experience and benefits :
Re: Ask HN: Current state of programming embedded devices?
#27I 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 availability, IP Ratings, enclosures, emi, electrical safety etc and is a totally different discipline which you need an EE and can seriously backfire and not get approval if not done correct.
Saying all that working as a programmer in a hardware business will teach you a lot of the above and give you a bigger influence in future projects.
Re: Ask HN: Current state of programming embedded devices?
#28In today's world, a truly embedded device implies an original firmware driving all the hardware on the device.
These are not so common anymore. Most devices use existing OS platforms depending on the task. - time/resource critical? real time OSes - GUI/multimedia/telephony? Android - a platform for you app? Linux
Dev tools are very dependent on the hardware platform. C is common, as is C++. This is also very vendor specific. Intellectual Property add-on's for different micro's, etc.
You really should consult an expert to get guidance - you can probably do the work yourself, but making the right initial hardware choices matching the requirements will help get everything else right afterwards. Once you have hardware chosen, the rest will fall into place.
I work at a research and design firm, our projects are making custom hardware for people who don't have the expertise or time. Our most frequent customers? "We got this started and now ..." Save yourself the headache of getting half way into the project and discovering a problem you can't solve, then need to hire a consultant to fix it, which will entail redoing and eliminating features because the initial decisions won't support the desired outcome. Make a consultation, and get set on the right path from the start.
Re: Ask HN: Current state of programming embedded devices?
#29You may be interested in reach technology's display modules. You program the GUI and send it some commands and it will display whatever you want. You can write some really snazzy Qt touch widgets. I interned for these guys a couple years ago and it sounds very similar to what you're asking for.
http://www.reachtech.com/
Re: Ask HN: Current state of programming embedded devices?
#30Earlier quoted context omitted.
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…
It should also be noted that a common practice in medical environments is to cover any control panels with a static-cling plastic sheet (usually light blue color, I imagine everyone is using the same brand) that can be quickly replaced between patients. So make your legends large and high-contrast.