Ask HN: Current state of programming embedded devices?

There are clearly a lot of people very informed people in this thread, and a lot of goofs who have never gone through the FDA validation process (or what seems to be any other validation process other than Heh My Node.js unit tests pass!) here. Some people are recommending RasPi and holy shit someone recommended JavaScript?! Who's going to be the one who tells lil' Tommy his grandma died because her dialysis machine confused === with == ahaha. Someone suggested LISP and Go? Holy fucking god. Good rule of thumb -- immediately disregard any advice of those advocating any platform that's advocated by the "hacker" or "maker community" unless those guys do embedded for a living and have graduate degrees (Nohl, Bunnie, Tarnovsky).

Like @Matthias247 said, QNX and GreenHill are easy to get up to speed from other RTOS, well documented, and arguably most importantly has name recognition so it'll be cheaper to get into hospitals, easier to get through the FDA certification process, and easier on your chequebook when you get your liability insurance. @viraptor offers good advice as to why RPi's are a dumb dumb dumb idea to base your product off of (who knows when they'll EOL their product?). Every component on your BOM should be from a reputable vendor who can tell you with the utmost confidence how long component X will be in production, the lead times typically seen, etc. @xzion did class B/C devices and mentioned EOL'ing so take his advice too. I'd even PM him and offer him a chunk of change to audit your unit before cert testing. (5k for someone to catch that EM your engineer didn't because his H-probe was oriented in the wrong direction is worth every cent). As a manager, I'd actually keep a resource on retainer who has taken an FDA embedded product to market as a consultant for my engineer to use as much as he wants, regardless of the cost (presuming my engineer hasn't done so himself, in which case, yay!). @analog31's definitely got good advice for his field but an FDA class C's requirements are entirely different from scientific equipment. Your $300k Keysight network analyser or $700k SEM might be okay to prototype against, but when my scope crashes a tech comes out and fixes it the next day- people don't die. When my Illumina sequencer fails, a post-doc might lose a week or two of work, bummer man, there goes his JAMA article, but no big folly. You can shop around a proof of concept for kit like that, (and likely have them take delivery of your rev 1 based on that same platform!) but I'd be very very concerned about EOL'ing anything on my BOM.

Make your BOM as jellybean friendly and as reliable as possible from the best vendors you could possibly afford. I strongly advocate ARM's for the following reasons. 1) IDE - Keil's MDK is basically the best IDE I've ever used (and I've used a lot). I can't even begin to delineate the functionality of it, just download the demo. It's better than having a bond-out chip and an in-circuit emulator with live debug. Really, it's crazy good and it's "free" (lacking some functionality) because ST subsidized it as a loss-leader (the first hit's always free...) 2) CMSIS-RTOS has a not-too-steep learning curve such that you could swap in any given engineer who's worked with on QNX4 and jump right in (for me, the learning curve was about as painless as Java 1.6 -> C#2 => ~2 weeks). Works on any M3 or higher (you aren't locked into any specific vendor), even licensed out with everything the IDE is reasonably priced as is the OS. So you don't run into the "Jane Street OCaml / Haskell shop hiring problem" of having a few pool of very very talented applicants, who are all in high demand as a result of their specific skillset. A good engineer won't have a problem. 3) Again, no specific vendor! If ST goes out of business (haha yeah right), NXP (a division of Philips) would definitely supply you with a same chip, with the same pin out, same package, same everything. Model everything on your BOM with a contingency in case lead times surge unexpectedly.

There are niche RTOS solutions out there (FreeRTOS works on ARM with a modicum of ST documentation. ST, Mentor, NXP, and all the other name-brands use it as the defacto standard if you're not going to go with a 'name-brand' RTOS.) eCos is probably the second pick with more of a hacker-community vibe to it, which, is probably good for getting that roto-copter's altitude up an extra few hundred feet but not really something you want your dialysis machine to be running on.

---

Here's an idea of what you're looking at (this is based on fed work from an engineering then from a bean-counter POV, but I've taken a Class B to market on the software side and it's got enough parallels that I feel this advice is pertinent).

Your cost breakdown is for first-product-to-market going to be 40% NRE for all the licensing, a board design engineer for your board layout (Cadence OrPCB / Altium 16 license), a software engineer with embedded experience (i.e., a good indicator is he's taken a lot of EE classes, or on the other end of the spectrum, has gone to the graduate level in theoretical computer science -- had great experiences with employees that fall into those categories) + Keil IDE or whatever, industrial engineer for your enclosures (Solidworks license) [you _might_ be able to bypass this step, but purchasing authorities ask "Can we change this font color" more often than "how efficient is it" - humans are significantly influenced by the aesthetics/how something interfaces with you. I'm guilty of this too, any industrial IP67 gear that feels chinsy, any relay that feels light, etc, I have a preformed biased against. (Aesthetics are a large part of Apple's value, along with exclusivity and status signalling; though, when I had my Macbook Air it felt like I could bend it in two, it's been on my desk for 3 years, and my daily driver is a Thinkpad I've neglected so much I'd have gone through 3 or 4 MBP's by now)

Legal and insurance will predictably be a fixed recurring (maybe 15%). Certification and re-spin costs can range from 5% to a lot more. Don't skimp on stupid things to save a few k here and there - pay a firm to do pre-EMI testing beforehand. Buy brand-name everything just as an insurance policy. $9 dollars extra for that precision thick-film resistor @ 10k vs $.13x10 might save you 8.70 a unit, but the engineering time it takes to find why your chip is clocking out spurious data but only once every 3 weeks at random times (oops, those resistors were 10% not 1%, which is normally fine except when you bring CE low for > x NS while doing Y, which heats up the bypass cap near Vcc increasing the ESR, and whoops, your cap's resistant factor is drawing an excess of current that shoulda went to Vcc! Again, Keil IDE helps so so much finding bugs like that.) Uh, yeah so, buy Nichicon and breathe easy. Use pre-certified industrial components that your competitors have already used if you can.

Office space can be finagled from other startups usually at pennies on the dollar. The commercial real estate market even in NYC is soft and I could get class-A space in midtown month-to-month at $3/sqft/mo (utils and furnished). I'd imagine SF is the only place where you'd have difficulty finding a reasonably priced space from someone who wants to let go of 800 or 1000 sqft. The rest is going to go to your marketing and/or sales team who will ultimately make or break you. Not for the faint of heart. If you don't have a mentor/family friend/guy on your board with existing contacts or know someone on the Cerner/EPIC/Meditech sales team with a big-fat Rolodex, you're going to be in for a tough, tough time. In government contracting (SBA, tiny contracts, fighting over the scraps really), we used to keep former decorated career military men on our board. They'd pocket 180k a year to literally fly down once every quarter and play golf while we got access to his Rolodex- medicine's the same.

I never thought of Tcl to be used in safety- or security-critical systems. It's certainly simple and easy to use. We played with it for agent-oriented programming back in the day. Had serious, design-level issues for security and was harder to parse than some others (eg LISP's).

Rather than just a critique, I'm curious where and how you use it with what benefits it brings you? I could certainly see it in UI or untrusted parts. Maybe also during development in a way that auto-generates C or something that runs in production.

I only use it like you guessed (and what I think it's best/appropriate for): gluing things together, embedded scripting, and Tk on internal tools/gizmos and early prototypes. I wasn't clear earlier, sorry.

To be perfectly fair, on the decision matrix Tcl gets a helpful boost due to my own familiarity with it and playing nice with C; if a butterfly had flapped it's wings just a little bit differently or I was starting out today I would probably be using something else. Probably Java. Ada would be great, but the lack of ecosystem diversity makes me apprehensive.

I remember playing around with REBOL a long time ago and it seemed useful and practical, but for reasons long forgotten I never used it. Maybe licensing? RED does look cool and I hadn't heard of it before, thanks for the tip.

Don't have any experience with Nim, but I share your interest for the same reasons. Haskell and I don't get along, maybe I'm too old and set in my ways?

Did you catch the link to/discussion of Little shared on here a few days ago? It might be of interest. https://news.ycombinator.com/item?id=11530097

For the thermostat it could well depend on the context to how much the latency matters.

If your recording average ambient temperature it probably doesn't matter much. If instead it is part of a physics experiment it could matter a lot. If it is part of some industrial control system [1] it could be critical.

For the ordering button the time taken doesn't matter, but the less time it takes (especially with the wifi hardware), is going to be a factor in how much power it consumes, and therefore battery life.

[1] https://en.wikipedia.org/wiki/Control_theory