
Ask HN: Current state of programming embedded devices? - tlubinski
Hi,<p>I recently switched to a hardware company and we are working on a medical device. We need a nice, touch-based user interface on a 5&quot;-10&quot; inch display. Some math calculations in the background, but no realtime stuff. I am an experienced developer on different platforms but I never programmed an embedded device.<p>What is the mainstream OS on embedded devices right now? Linux, Android, Win 7 Embedded? What about Windows 10 IOT?<p>What is a good setup? Rasberry Pi + official touch screen? Are there medical grade devices out there (doesn&#x27;t matter if it is expensive)?<p>What about developer tools? Okay, Visual Studio for windows? But what about the other platforms? Still C?<p>You see, I&#x27;m pretty clueless, so any help is much appreciated!<p>Thanks.
======
mrlyc
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 to a doctor's gloves to the
screen then to another doctor and another patient.

~~~
contingencies
_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.

~~~
mangamadaiyan
What alternative would you recommend?

~~~
IshKebab
Pretty much anything!! Java, C#, Rust, Go, OCaml, Lisp, ... even C++ would be
a much better choice.

Check this out: [http://tobyho.com/2008/03/30/how-safe-is-your-
programming/](http://tobyho.com/2008/03/30/how-safe-is-your-programming/)

There also used to be a website that ranked programming languages according to
various parameters (which is faster, which is safer) by asking visitors
pairwise comparisons (Which is faster - Matlab or C?). I was going to link it
but can't find it unfortunately. Anyway I'm pretty sure C would come second-
last in the safety ranking, right above assembly.

------
analog31
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 to use it."

* Linux, when the product is cheaper, and has a more bare bones or restricted function set. I don't know for sure, but I think that a Linux build can be more stripped down. Little boards like Raspberry Pi and BeagleBone abound, and if nothing else, you can create a nice proof-of-concept with one of those. I've actually done this, writing my code in Python, with the expectation that the "real" programmers would turn it into something else.

I'm not in the skill areas that actually develop this stuff, so I don't know
any lower level details. My job tends to be supplying the theory of operation
for the actual measurement.

Both systems use SOM's (system on a module) that are typically sold with the
software tools to get you started, such as a working demo OS. It is rare to
see real-time stuff done on the main computer. Since you're usually talking to
some sort of device hardware anyway, it's usually more convenient to put the
real-time stuff on a separate microcontroller, that's got little or no
interrupt overhead to deal with.

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

~~~
analog31
There was a previous generation of products that used embedded Windows for the
same reason: "The user already knows how to use it," plus there was the hope
of being able to transfer Windows programming skills and tools to the embedded
target.

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

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

------
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/](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.

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

------
any1
I 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 starting out, I'd recommend using Yocto. It's a
build/development environment for embedded Linux. Look it up.

Edit: By they way, if it's not real-time critical, there's nothing stopping
you from using any programming language you like except how difficult they can
be to cross-compile.

For hard real-time stuff you need a dedicated rt system and you'll have to use
C, C++ or maybe Rust.

For soft real-time stuff you can get away with RT-patched Linux. Any language
with GC is generally bad with the exception of Erlang, Go and Nim; where the
GC is optimised for low latency rather than bulk through-put.

~~~
tlubinski
Why are you moving away from Qt?

~~~
any1
A few reasons:

* It's easier to find people with JS skills than C++ skills

* It takes ages to build Qt and it's unreasonably hard to compile. Building the Linux kernel is far less painful.

* It takes ages to build a single Qt project and we have multiple architectures to deploy to (ppc, arm, x86).

* Remote connections are trivial. People only need a browser to connect remotely.

The people at the company who have been using it like it a lot. They just have
to put together a few tags and _boom_ there's your GUI.

The GUI has access to some system variables via WebSocket. We have a two-way
binding abstraction so people don't have to think too much about events and
such.

I wouldn't recommend HTML for a small company though. Better stick to Qt if
you're a small group of competent C++ programmers.

~~~
daxfohl
Is most of your gui simple forms and data? I've done critical care monitors
and photobooths, and both seem too complex for html to me. I'd be afraid the
HTML would be too slow to process and display, too eager to show scrollbars,
too likely not to be optimized for the embedded gpu, etc. Have any experience
there? The last time I tried going higher level I tried embedded flash, and
that was too limiting.

------
daxfohl
Forget everything you think you know. RPi is great for hobbyists but not what
you want to put in your final product, or even really your prototype. Others
have already mentioned the reasons. In web development, a commercial-quality
stack and a hobbyist stack are essentially the same. With embedded
development, they're far different and the commercial stack is still largely
vendor-driven.

Call up TI and Freescale, let them know what you're up to, and they'll come
demo/loan a few products. Talk to their engineers about your product at a high
level so they can immediately drill in on a few options, then talk about hard
requirements and even personal preferences/interests and they'll be happy to
make recommendations on hardware, OS, language. The naming schemes and jargon
can get confusing and features seem to overlap, so make sure to ask lots of
questions.

Oftentimes the CPU will determine your OS; some will be more stable and have
more complete drivers on Windows, some on Linux, some on specialty OSes. Of
course you could take the Linux Kernel and tune it yourself, but unless you
really know what you're doing that's not going to be the easiest route.
Oftentimes you'll come across sites/videos showing how to get unsupported OS A
to work on CPU B and get excited. Ignore those, as what the video _doesn 't_
show is all the things that still _don 't_ work, and that rabbit hole goes
deep.

In general for your first project try to avoid straying too far from the
beaten path and the recommendations you get from your vendor.

~~~
daxfohl
In addition, if you're still reading this, be ready for this to be not-the-
most-interesting software project. Most of it will be reading vendor
documentation and hunting down config errors. And compiling. And figuring out
FDA stuff.

Coding-wise you probably won't learn a whole lot. You'll be using old
technology and likely limited from using any fancy techniques you want to cook
up. Accept that in advance. Thrive in that actually; force yourself to take
the safe road software-wise so you can take the time to read through FDA docs
and understand all the lingo better. Also spend time with your EE and learn
more about that side of the coin. Spend time with the customer-facing side and
learn the market. Learn some actual medicine so you're seeing the device as a
tool rather than as a platform. All this stuff is way more valuable in the
medical field than knowing the latest five JS frameworks (or Haskell plugins,
or ruby test platforms, or whatever software-y stuff floats your boat).

~~~
tlubinski
Yes, I'm still reading this and I'm not afraid of working by the rules (or
learning them). I'm just surprised how fragmented the whole embedded device
stack is. The whole software development process could (and should) be more
defined. Let me gather some more experience and see if I can come up with
something more clever :).

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

~~~
tlubinski
I already talked to a bunch of consultants and everyone has a different "right
path". Hence my question here to get it in front of a lot of experts.

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

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

~~~
percept
I wonder if there are any industry-focused resources (meetups, mailing lists,
etc.) available, to offer specific guidance.

------
anonymous_iam
The mainstream OS choices are: Wind River VxWorks, Green Hills Integrity,
BlackBerry QNX, Linux, Android, and (god forbid) some variant of Windows.

A great deal of embedded software is still done in C/C++. (Embedded is not a
good environment for dynamic languages.)

~~~
pedalpete
Can I ask why you dislike dynamic languages in an embedded environment? Or why
you think they are 'not good'?

~~~
striking
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 are usually faster and more predictable, to a certain
degree. This is advantageous in an industry that would rather spend years
developing something than have a small chance of killing someone. Bugs are
unacceptable.

If you're willing to pack an Intel Atom or something into your device, fine.
But if you can get by with a tiny ARM chip, why shouldn't you?

~~~
contingencies
_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.

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

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

------
pedalpete
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's in javascript (I've asked anonymous_ian why
he doesn't like dynamic languages in embedded).
[http://getfavor.net](http://getfavor.net)

Keen to hear your thoughts.

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

~~~
pedalpete
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.. :)

~~~
rdc12
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](https://en.wikipedia.org/wiki/Control_theory)

------
galleghost
Reading these comments tells me that the state of embedded programming is as
strong and as fragmented as current web development.

My company uses VxWorks, MQX, Android, Windows CE and Linux. We're dropping
VxWorks because it's costly and cumbersome. MQX is being replaced by whatever
Freescale/NXP is pushing now, we put a lot of resources into the older version
of MQX and aren't following them into their new incarnation. We use Android
for special devices, but it seems to take a good amount of work to put it on
custom hardware.

The OS that makes the most sense for embedded work nine times out of ten is
Linux. It's widely used, documented enough, and has the most vendor support.

A good setup? You can get an AM335x EVM with an LCD, which is the same
processor as a Rasberry Pi. I believe i.MX6 has an EVM with an LCD as well.
Bottom line, you should talk to vendors, to see what they have to offer. Since
it sounds like you have limited experience in this area, working with a vendor
that will give you support is probably the most important thing.

Your developer tools are entirely dependent on your OS and chip. Ultimately,
doing embedded work you're most likely going to use C/C++, but if you're on
Linux or any modern operating system, then you have the ability to use a
scripting language.

------
danhorner
I recently implemented something like this, albeit for a research-use-only
device. We used an embedded intel board with separate PCAP touchscreen
connected to the LVDS+USB interface. X.org supported it out of the box. Out
product runs on linux/C++ with html/js UI. There are a couple of embeddable
web browsers. I've been very satisfied with a simple X11 browser based on
Chromium embedded framework.

PCAP touchscreen worked well with double-gloved fingers and there are touch
controllers that will reject a stray water droplet on the screen.

I'm not sure about the OS considerations for medical device use, but for linux
you might consider the yocto project, which is designed for this kind of
stripped down deployment. It will limit the number of moving parts you have to
validate. If you're less devoted to the open source route, check out QT's
boot-to-qt offering. QT ui's are common in this field and I believe there are
supported boards at a range of price points.

You wouldn't want to hitch your design to Rasperry Pi or Beaglebone or such
because of the short support lifetime of individual models and components.
Part of what you pay for with the industrial vendors is a commitment to supply
the system for 5-10 years.

If any of this is helpful, drop a note using the email in my profile.

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

~~~
tlubinski
no one tried Win 10 IOT yet? ;)

------
davidw
We used an Android tablet for the UI here:
[http://www.centervue.com/productdb19.html?id=919](http://www.centervue.com/productdb19.html?id=919)

Other stuff is separate.

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

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

------
muricula
You 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/](http://www.reachtech.com/)

------
petra
This is a framework for medical software development, they have a few papers
talking about the experience and benefits :

[http://www.lambdanative.org/](http://www.lambdanative.org/)

------
manav
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?

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

~~~
daxfohl
You may want to consider something like rs485 instead of USB. One less attack
vector for bugs and viruses. Or users plugging in mice or whatever and
expecting them to work.

------
ap46
usage of the Leap motion controller should actually be encouraged more, right
here!

------
tclmeelmo
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 you're going under design control, and what market/regulatory
framework you're working under (FDA, CE, CFDA, etc.).

Your requirements documents are a good guide here. I personally separate them
as Engineering Requirements Document (ERD), Software Requirements Document
(SRD), and Market Requirements Document (MRD); your questions would touch all
of these.

You've hinted that you are wanting a display and also wanting to do
calculations; as others have suggested, good practice would be to separate
this functionality. Your ERD/MRD should specify a minimum duration for
projected parts availability. Dealing with part variations is a pain, but
having to replace an end-of-life'd (EOL'd) part is worse. For your own
personal sanity, you probably shouldn't be looking at consumer-level parts and
instead look for more industrial-style parts (a weak example might be to use a
BeagleCore instead of an RPi for an internal project). You'll need to be
mindful of your environmental requirements too, if for example your design
called for a sealed enclosure that could greatly impact the parts you could
include in your design due to thermal management. Even when using consumer
level stuff, say USB, you should look for the industrial/ruggedized versions
(e.g., that will have retaining screws).

Touchscreens for medical devices are, in my experience, a mixed bag depending
on the application. If you're using a good design, they can be easier to keep
clean and disinfected vs. buttons. On the other hand, depending on the touch
technology you use and the type of information you're displaying, the display
may not look great (i.e., a 2D plot can look fine on a resistive touch panel,
but video may look foggy). Depending on what your users are doing, you could
have smudges of some sort of fluid (or boogers, or giblets) obscuring info on
the display. Also, I think users expect a modern multitouch experience now and
I personally haven't been thrilled with that style of interface on anything
other than capacitive displays.

If you're using a contract manufacturer (CM), they are a great resource.
You'll be dealing with them during design for manufacture (DFM), but it's a
good idea to engage them early so that you can design for DFM (if that makes
sense). I don't know what your expected volumes will be, but on things other
than durable goods (like scalpels), "high volume" medical quantities are
considered "low volume" for other areas and this will greatly influence your
design. I also found it frustrating because you're limited to
suppliers/distributors/CMs/whatever that will be satisfied with the lower
volumes.

Handwavy answers are that your safety-critical stuff is going to be hard real-
time and running an OS developed under an appropriate quality system (QMS)
like vxWorks, Integrity, QNX, etc. I don't have experience with it, but there
is also FreeRTOS with an SIL (safety integrity level) 3 SafeRTOS option that
could be an interesting contender. The software you develop will also need to
be developed under a QMS as a broader part of your software development
lifecycle (SLDC) and greater product lifecycle management (PLM). There are
guidelines to use software of unknown pedigree (SOUP) by bringing it under
your QMS, but this can be undesirable depending on circumstances. Most
commonly the software is developed under C or C++ with an appropriate coding,
review, and testing standard; for a greenfield project I think that
considering Ada/SPARK or Java (with the appropriate compiler/VM) could be
smart.

For things outside of the safety-critical areas, you have greater options, and
it might be largely sufficient to develop under a QMS. You're going to need to
be very mindful of software licenses to make sure that they are aligned with
your project's requirements. If you're set on Linux then Yocto would be worth
exploring, but NetBSD would be my first consideration due to licensing. For
your GUI, FLTK could be worth considering if it met your requirements. Even if
your product is Class A, it's maybe helpful to keep the more stringent
requirements for Class B/C products in mind, so that you can (when and if it
makes sense) develop expertise and institutional knowledge for Class B/C
products later on.

I'd recommend the Stanford Biodesign textbook as a one resource to help get up
to speed: [http://www.amazon.com/Biodesign-Process-Innovating-
Medical-T...](http://www.amazon.com/Biodesign-Process-Innovating-Medical-
Technologies/dp/110708735X)

Finally, considering your questions and I say this in the kindest intentions,
you should be participating in the process but not be signing the decisions.
If your company doesn't have the expertise in house, it would be worthwhile to
either bring someone on board or engage a consultant.

Good luck!

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

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

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

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

~~~
nickpsecurity
Gotcha. Look into REBOL/RED while you're at it. RED is a REBOL
clone/modification for system programming. They're LISP like advantages
without the parenthesis and having small footprint. RED is already used in one
OS project. I keep thinking of modifying it for system use. People keep
telling me to check out Nim as it's like Pascal and Python combined with extra
safety, macros, and C code generation.

So, there you have it: REBOL, RED, and Nim. Maybe Ivory language from Galois,
too, but you need to know Haskell for that.

~~~
tclmeelmo
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](https://news.ycombinator.com/item?id=11530097)

~~~
nickpsecurity
Me too on Haskell. Mainly plan to try other two. Saw Little but didn't really
get it past adoption. Then, your comment led me to the Why page which told me
that was _exactly_ the point. Along with programming in the large support.
Funnier when I found out the boss wrote that.

I'd say it's not a good language to go with today for same reasons I'd say Tcl
isn't. It's an interesting improvement especially to get better syntax with
legacy compatibility with field-proven, TCL modules. And TK is still the shit
for portable, easy-to-build GUI's. A TCL shop should definitely experiment
with it and maybe incrementally upgrade their code. I think I'd be fine with a
more typed, efficient, and fixed version of Tcl for some apps. Especially a
command shell replacement or prototyping system.

Just not production unless it's non-critical like what you use it for. I don't
even use it to glue to critical things as the glue is part of the TCB to a
degree. Gotta find close-to-metal, abstract, typed, efficient, and macro'd
stuff to replace it. At least we have contenders.

