When working on the source code of Espruino (C) and making changes, I find myself injecting logging statements to see what is going on. This is the case for my tinkering with ESP8266 port. I am wondering if on other boards or in general there is a better debugging strategy?
Is there any kind of source level debugger being used?
Should we consider the ability to include debug statement in the C source code that would be compiled out for release but present for debug builds? At present I am putting in debug statements, testing and then removing the debug statements but I would rather be able to leave them in and simply switch them off.
Actually, it depends on what possibilities the hardware has.
If you are left with pure software, you'r doing it the sole way possible.
On Arduino platforms there is a plugin in Visual Studio to inject those 'breakpoint' and 'watches' done from the IDE at compile time. This video
will show you how pratical it is. It's not free but there is an evaluation version and the prices seem 'fairly reasonnable'.
There is also a possibility to use it on ESP8266 but through the Arduino sketches. I don't think Espruino would be debuggable this way.
All other approaches are hardware specific: up to the number of hardware breakpoints versus software breakpoints.
For the ESP8266 there is this threat or this one which basically explains how to install openocd. This links, no warranty, to the specific xtensa openocd.
With other environments you could get lot's more (Keil and others professionnals), but that's expensive.
For CC3200, TI has it's own CCSv6 (eclipse+gdb+openocd+specific hardware on dev board) approach which allows to import energia sketches or use ti-rtos or even bare metal c and do step by step debugging.
For the STM32, you could see Emblocks which would handle Nucleo's out of the box: However that's windows only.
For Linux, that's the luxious situation, you have everything GDB and lot's of others.
© Espruino, powered by microcosm.
Report a problem