That's not how you develop embedded stuff normally. You usually do that over some serial line to control the remote debugger-related interrupts and whatnot and drive it via GDB. You can also emulate many SoC's via Qemu, Bochs, etc. (to varying degrees) during the development process.

Further, you don't run hard realtime applications on a normal OS. Preemptive multitasking can cause a userspace program to drift out of sync, or have other side effects - for example.

There is a pretty well known RTOS but the name is escaping me.

You wouldn't really benefit from prototyping on the pi as a lot of that software has to be purpose built for the hardware.

RPi+Linux+sensors has an easier learning curve, and is accessible to people with a wider range of backgrounds/skills.

I don't disagree with you, it's just that medical equipment that is critical (e.g. ICU monitors) would benefit from real, robust hardware. It's not about learning curves.

You'd be surprised. When I started my career in medical devices, we specifically based our product on Windows & C++ in part because it was a well-known platform and we would have no trouble finding developers. That system, and its descendents ran on off the shelf single-board Windows PCs.

There is a lot of medical equipment out there that's running Windows. FWIW, I have one next to me right now that uses Linux for its UI.

> It's not about learning curves.

When it comes to experimenting and prototyping I think it is. The lower the learning curve the more cross polinations take place, projects and ideas get shared.

Clearly RPI is not optimal for clinical machinery that is supposed to run unattended by engineers in the real world but for prototyping why not?

Because there isn't a lot in the way of "prototyping" necessary. We already know how to effectively monitor patients. A lot of the shitty parts are actually in software and licensing and process - not hardware.

If you "prototype" for raspi, you will have to completely start from scratch if you want to manufacture reliable devices later on. It's not like porting a program from one system to another.

Go build it!