I'd like to build a simple command-line based debugging/hacking/tweaking tool to inspect and modify variables while a sketch is running into many of my sketches. My goal with this is to be able to connect to running systems and tweak some settings in real-time or see what state they're in. Similar to a very limited debugger.
The question I have is how best to implement that, specifically, how to create the meta-data that is needed to name and locate the variables.
For example, I may have a global variable `rexmit_timeout` that is the current retransmission timeout for some RF data packets and with this tool I could connect and change the timeout "live" to test something. Or I may have a variable that has the time of the last received ping response and where there is a problem I could connect and see what the value is.
The command-line could be over the serial port or a network connection.
In terms of implementation, my first attempt uses a C++ class and a #define. Instead of writing something like
```
static uint32_t lastPing = 0
```
I write
```
static DBGVAR(uint32_t, lastPing, 0);
```
which is macro-expanded to
```
static uint32_t lastPing = 0; DBGVAR __lastPing("lastPing", &lastPing, 4);
```
where DBGVAR is a class whose constructor takes the name of the variable, its address and size, packages that up into a descriptor, and inserts that into a global linked-list.
This approach works, but requires that all variables that are to be accessible are specially coded using the macros and it sucks from a readability point of view.
What I'd really like is to extract the set of global variables in the main application files from the ELF symbol or debug info, then generate the meta-data, and finally add it into the binary. Is that something for which there are existing tools I could leverage?
built-in variable 'tweaker'
Re: built-in variable 'tweaker'
You would need to marshel changes. Rarely does a variable stand alone.
Mostly variables live within a context; number of bytes written & time spent writing. Alter one alone and you insert a bug. Also atomic issues e.g. update a uint64_t or double.
So you have to code this stuff or maybe use a debugger but then you would need to halt the processor whilst updating.
The JTAG debugger has atomic update capability. Perhaps you can add a console front end and/or see how it decodes the symbol table.
Personally I use a string key map of Boost any & add both a CLI and RESTful api. I store everything useful in my database and attach controlers/observers. It works but I don't avoid your declaration concerns. I dont have the pins to leaver JTAG though.
People use Python and Javascript on ESP so if you yearn introspection then that's maybe another route. You don't escape atomic however unless the coder acknowledges the console update or you halt during update.
Performance & resources would also take a hit.
Mostly variables live within a context; number of bytes written & time spent writing. Alter one alone and you insert a bug. Also atomic issues e.g. update a uint64_t or double.
So you have to code this stuff or maybe use a debugger but then you would need to halt the processor whilst updating.
The JTAG debugger has atomic update capability. Perhaps you can add a console front end and/or see how it decodes the symbol table.
Personally I use a string key map of Boost any & add both a CLI and RESTful api. I store everything useful in my database and attach controlers/observers. It works but I don't avoid your declaration concerns. I dont have the pins to leaver JTAG though.
People use Python and Javascript on ESP so if you yearn introspection then that's maybe another route. You don't escape atomic however unless the coder acknowledges the console update or you halt during update.
Performance & resources would also take a hit.
& I also believe that IDF CAN should be fixed.
Who is online
Users browsing this forum: No registered users and 93 guests