Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Current state of programming embedded devices?

news.ycombinator.com

Post reply on HN
Print view View original

71–76 of 76 posts

Re: Ask HN: Current state of programming embedded devices?

#71

Post by tclmeelmo »

blacksqr wrote: post #70
tclmeelmo wrote: post #43

Earlier quoted context omitted.

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…

Rosea ( http://chiselapp.com/user/mangoa01/repository/mrtools/wiki?n... ) is a tcl-based tool designed specifically for embedded medical applications where provable quality is critical. I think it deserves more attention.

This is really interesting. Do you know of anyone using it in production?

Re: Ask HN: Current state of programming embedded devices?

#72

Post by daxfohl »

any1 wrote: post #53
tlubinski wrote: post #23

Earlier quoted context omitted.

Why are you moving away from Qt?

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…

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.

Re: Ask HN: Current state of programming embedded devices?

#73

Post by [deleted] »

any1 wrote: post #53
tlubinski wrote: post #23

Earlier quoted context omitted.

Why are you moving away from Qt?

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…

[deleted]

Re: Ask HN: Current state of programming embedded devices?

#74

Post by blacksqr »

tclmeelmo wrote: post #71
blacksqr wrote: post #70

Earlier quoted context omitted.

Rosea ( http://chiselapp.com/user/mangoa01/repository/mrtools/wiki?n... ) is a tcl-based tool designed specifically for embedded medical applications where provable quality is critical. I think it deserves more attention.

This is really interesting. Do you know of anyone using it in production?

The author works for a custom embedded code shop, and I believe has been using it and its antecedents for years for his customers. He's on my short list of personal coding heroes.

Re: Ask HN: Current state of programming embedded devices?

#75

Post by daxfohl »

daxfohl wrote: post #62

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…

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

Re: Ask HN: Current state of programming embedded devices?

#76

Post by tlubinski »

daxfohl wrote: post #75
daxfohl wrote: post #62

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…

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…

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 :).
Post reply on HN