Raspberry Pico as USB test device - part 2: a working USBTMC compliant instrument

RE: Raspberry Pico as USB test device - part 2: a working USBTMC compliant instrument

Jan Cumps — Fri, 03 Feb 2023 14:18:38 GMT

If you use this project as starting point, part 2:

The main file does not use (or know) the instrument api in the source/gpio folder. Except for the initialisation function.
That function prepares the hardware used in the instrument - in this case: sets the gpios to out and low.

Putting this initialisation call in the main file was a design decision, not random, but maybe not the best.
I usually make my instruments like this, to have the hardware ready before I initialise the SCPI parser. In particular when I make an instrument with a screen / buttons in parallel with the SCPI engine, this makes sense. I make the user interface call the instrument functions directly. I don't make them call the SCPI parser.

In this particular case, where I made an instrument that's only controllable via SCPI, it makes sense to do the initialisation in the scpi_instrument_init() body.
That would give the advantage that the USBTMC core does not have to know *anything* about what SCPI commands are supported or what the instrument does. You could reuse the code for any instrument.
In particular, because that same initialisation code could (should?) also be used in the *RST handler ...

RE: Raspberry Pico as USB test device - part 2: a working USBTMC compliant instrument

Jan Cumps — Fri, 03 Feb 2023 13:38:42 GMT

If you use this project as starting point, I tried to keep the code modular:

there's only two files that knows the instrument-specific scpi commands. Both are located in source\scpi:
scpi.h has the *IDN? reply settings.
scpi.c has the supported commands, and what instrument code they should call.

In my case, there is only one custom command that the device supports:

    {.pattern = "DIGItal:OUTPut#", .callback = SCPI_DigitalOutput,},

Implementation:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:e4ac1b79-0f32-4e5f-abfd-fd3149b1b814:type=c_cpp&text=static%20scpi_result_t%20SCPI_DigitalOutput%28scpi_t%20%2A%20context%29%20%7B%0D%0A%0D%0A%0D%0A%20%20scpi_bool_t%20param1%3B%0D%0A%20%20int32_t%20numbers%5B1%5D%3B%0D%0A%0D%0A%20%20%2F%2F%20retrieve%20the%20output%20index%0D%0A%20%20SCPI_CommandNumbers%28context%2C%20numbers%2C%201%2C%200%29%3B%0D%0A%20%20if%20%28%21%20%28%28numbers%5B0%5D%20%3E%20-1%29%20%26%26%20%28numbers%5B0%5D%20%3C%20pinCount%28%29%29%29%29%20%7B%0D%0A%20%20%20%20SCPI_ErrorPush%28context%2C%20SCPI_ERROR_INVALID_SUFFIX%29%3B%0D%0A%20%20%20%20return%20SCPI_RES_ERR%3B%0D%0A%20%20%7D%0D%0A%0D%0A%20%20%2F%2A%20read%20first%20parameter%20if%20present%20%2A%2F%0D%0A%20%20if%20%28%21SCPI_ParamBool%28context%2C%20%26param1%2C%20TRUE%29%29%20%7B%0D%0A%20%20%20%20return%20SCPI_RES_ERR%3B%0D%0A%20%20%7D%0D%0A%0D%0A%20%20setPinAt%28numbers%5B0%5D%2C%20param1%20%3F%20true%20%3A%20false%29%3B%0D%0A%0D%0A%20%20return%20SCPI_RES_OK%3B%0D%0A%7D]

All instrument code is in source\gpio. Here I wrote the functions that can be called by the parser:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:9e8119c6-3d0d-48f6-a28d-033529c1d103:type=c_cpp&text=uint32_t%20pinCount%28%29%20%7B%0D%0A%20%20%20%20return%20sizeof%28pins%29%2Fsizeof%28pins%5B0%5D%29%3B%0D%0A%7D%0D%0A%0D%0A%2F%2F%20...%0D%0A%0D%0Avoid%20setPinAt%28uint32_t%20index%2C%20bool%20on%29%20%7B%0D%0A%20%20%20%20gpio_put%28pins%5Bindex%5D%2C%20on%29%3B%0D%0A%7D]

RE: Raspberry Pico as USB test device - part 2: a working USBTMC compliant instrument

DAB — Tue, 31 Jan 2023 19:59:05 GMT

Great blog Jan.

RE: Raspberry Pico as USB test device - part 2: a working USBTMC compliant instrument

shabaz — Mon, 30 Jan 2023 23:16:47 GMT

Very useful blog post! This will come in handy, because the Pico is being used more and more in testbeds for all sorts of measurement or control purposes.

I'm looking forward to giving this code a shot, as a starting point for creating such projects.

RE: Raspberry Pico as USB test device - part 2: a working USBTMC compliant instrument

Jan Cumps — Mon, 30 Jan 2023 20:08:35 GMT

And maybe investigate in the SCPI library how you can detect if a query is fully replied to.

I did the investigation for you: the current implementation of the SCPI libs takes care that the scpi_instrument_input() only returns when data is written. You could start the semaphore just before calling that function (when data arrived via usb) and release it right after the function returns.
Not tested by me, but confidence by reading code [emoticon:c4563cd7d5574777a71c318021cbbcc8]