Ask HN: Any need for a better embedded development solution?

[aqsis]

I've got a plan for a different approach to software development on embedded platforms. One that doesn't required the typical edit/compile/flash/restart cycle. Instead it allows direct modification of a running system on the device itself. Just trying to gauge interest in something like this.

[aqsis]

Thanks for the responses so far, very useful. I'd just like to clarify a couple of details, in case it makes any difference to the responses. Firstly, the solution is based around a high level OO language, not raw C, so is based on a highly efficient VM. Secondly, it is targeted at the sort of device that might consider a Java KVM, so probably ~128K ram, ~512K flash, or thereabouts, might be able to squeeze certain configurations into less ram. The primary principle is to have the system running on device, and then be able to login from a remote machine and make code changes to the live environment. Please feel free to ask any questions, if I can, I will answer them.

[CyberFonic]

No matter how "efficient" the VM - it poses a performance and storage impact upon the platform. For many embedded projects that is unacceptable overhead. For the few projects I have worked on, I've only used assembler and C.

[mgse]

For me, 'restart' is generally the most used operation during debug. The vast majority of the time I want to rerun through the init code to clear out the registers and any previous transactions. If I've set something up incorrectly, I can always set a breakpoint and adjust.

So I'm not seeing an immediate benefit to direct modification for my normal workflow. There may be good use cases when writing code that isn't HW dependent or if the compile/flash cycle takes a long time, but those aren't problems I've had very often over the last ~10 years.

[gvb]

Ditto.

In addition, usually when I do something wrong in an embedded system the only way to recover is a hard reset and reload. Mishandled interrupt, corrupted stack, jump to a random location, etc.

In embedded systems, there are an infinite number of ways to crash such that there is only one way to recover (reset and reload). There are very few ways to crash that leave a non-reset recovery.

[xyzzy123]

Interesting, I guess it depends on "how embedded" you are. For linux-based routers/gateways (edge of embedded really) the compile-flash-boot cycle can be rather long, but the standard workarounds (scp-after-build or NFS mount a work dir) work adequately.

That said, anything which reduces cycle times is good.

[CyberFonic]

I have often wondered whether it would be possible to have an emulator running on a PC and by keeping a before and after image, patching the memory of the embedded system to reflect the new contents. The existing debugger or a very simple small loader/patcher is all that would be required on the embedded system.