fietser28
commented
4 months ago After manually implementing a SCPI commands set using the nice scpi-parser library I have a new insight on this request, that will probably make the implementation also easier:
Add a SCPI option (specifing the command and maybe arguments) to actions and global variables. This generates the SCPI structure (const scpi_command_t scpi_commands[]) and the wrappers for SCPI commands. This will not cover every possible SCPI command but will do the (boring to implement) bulk of commands.
More specific:
- A variable has an option to a SCPI command (set) and a SCPI query (get). This just needs to specify the command and query string (in the common notation). The parameter for the command equals the variable type. The result from the query is easily derived from the variable type.
- A native action has an option to specify the SCPI command to trigger the action. No parameters needed.
- A flow action has an option to specify the SCPI command to trigger the action with the inputs as parameters.
- Add a scpi.h file with a template for the scpi_commands structure and a ${eez-studio SCPI_COMMANDS} in it. This allows manual addition of other/more complex SCPI commands.
Regarding parameters:
- integer, float, double, boolean, string can be mapped 1:1 to corresponding SCPI types
- enums can be treaded as choice (scpi_choice_def_t and SCPI_ParamChoice)
A separate SCPI task maybe not trivial in this case because execution of commands and queries will take place during the ui_tick()?
In embedded EEZ-Flow projects I would like to be able to easily generate code that processes SCPI commands. For this a UI interface is needed to specify the SCPI commands (probably a panel derived from existing SCPI panel in studio) and the SCPI errors. In the UI the defined SCPI commands will have some properties, mainly the action (and parameters) the SCPI command will trigger.
Additionally it would be nice if the EEZ-Flow project also generated the definition (IEXT file) to have studio as a control interface via SCPI for the device. During development it would be nice to point to the changing project instead of an IEXT file that needs reloading each time.
SCPI command processing might be done in a different task as the UI processing. I think it would be most flexible to implement a eez_scpi_init() and eez_scpi_tick() functions and give the user freedom to incorporate it in ui_init and ui_tick functions or separately.