feat: add attribute change event API

[bonnyr]

Is your feature request related to a problem? Please describe. The custom chip API allows for runtime attribute value changes using the GUI. However, to use it, the chip implementation needs to read the attribute every single time.

Since this is a simulation, this does not cost real time, but it does make the code a little different from the other APIs

Describe the solution you'd like Add a callback with something like the signature below:

on_attr_change(void *user_data, uint32_t attr);

to let the extension know when the attribute was changed so that it is not forced to read the attribute every time. This will be consistent with the other APIs for pins, timers etc.

This still allows users to read the attributes if/when they choose.

[urish]

Thanks!

Internally, we have a distinction between "attribute" and "variable":

• Attributes come from diagram.json, and never change once the simulation has started. Attributes are always represented as strings in diagram.json.
• Variable come from the controls, and can be changed while the simulation is running. They are stored as a floating point (double) value. When using the Chip API, attributes are initialized with either an attribute with the same name (assuming it exists and has a valid integer/floating point value), or, as a fallback, from the second parameter of attr_init/attr_init_float.

Right now, we expose a single API for attrs/vars (calling both attrs), that abstracts away these differences. This (and wokwi/wokwi-docs#183) make me wonder if we should redesign this part of the API to keep this distinction.

Perhaps, instead of "vars", we should call them "controls", to make it more obvious that they are related to the "controls" section in the chip JSON?

So, for attributes, we can have attr_string_init (or just attr_init), and that will always return a string, and then we can have control_init, control_init_float, control_read, control_read_float, and control_watch (which will listen to changes) to interact with variables (and their controls)?

[bonnyr]

I like the controls approach. It clearly indicates that these are used to control the chip during the run (volume control on a remote) whereas attributes are more of a definition of what the behaviour for the entire run (set the remote to be a tv vs a stereo remote)

Regarding the api, you may still want to have string controls (setting the display contents?)

[urish]

Thanks!

Regarding the api, you may still want to have string controls (setting the display contents?)

The main use case I'm seeing for controls is for setting sensor input values (e.g. temperature). I can't find a good use case for string controls, but if one comes up down the road, it shouldn't be too hard to add them as well.