undefined | Better HN

0 pointsclaytongulick2y ago0 comments

Then I guess you'd better avoid any sort of embedded libc implementation too.

Or fadecandy, or any external library.

I've been through hell in embedded systems land debugging chipmaker-supplied C compiler problems.

Should I just write it all in asm then? I've certainly made that choice for some projects.

The point is, at some point you just want to get things done and you have to trust your tool chain.

0 comments

You are completely missing my point. When I have C code and compile it, I will have opcodes which processor can run. All my bugs are going to happen only in C code and I can debug those using one debugging probe.

When I have embedded scripting, then I have C code which represents my VM and I have also scripts. Then I am hunting for a bug in C code and script itself. I need two debugging stacks to get the problem solved. Sure you can say that I can run scripts on my PC, but what if everything works on my PC, but the moment I will load it on the target, script will crash? Then without proper debugger I am screwed.

mmoskal2y ago

DeviceScript comes with a source-level debugger for the VM code.

Indeed, if you add C code and that crashes it maybe harder to debug than a pure C system, however it wasn't my experience while developing DeviceScript - it was either clearly a bug in C that didn't really depend much on the bytecode, or an exception in DeviceScript which you debug just like in TypeScript.

We also support Jacdac [0] which makes it possible to put the C code on a different MCU, isolating the problem and adding traceability. (You can also run Jacdac server on the same MCU)

[0] https://microsoft.github.io/jacdac-docs/

HumanOstrich2y ago

I appreciate your engagement throughout this post, including how you are gently educating the naysayers.

j / k navigate · click thread line to collapse