Ask HN: Any need for a better embedded development solution?
1–7 of 7 posts
Re: Ask HN: Any need for a better embedded development solution?
#2So 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.
Re: Ask HN: Any need for a better embedded development solution?
#3For 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…
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.
Re: Ask HN: Any need for a better embedded development solution?
#4For 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…
That said, anything which reduces cycle times is good.
Re: Ask HN: Any need for a better embedded development solution?
#5Re: Ask HN: Any need for a better embedded development solution?
#6Thanks 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 c…