Hacker News new | comments | show | ask | jobs | submit login

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.




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


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: