

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.

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

