Added a new driver for a new instrument: Pico SCPI labTool (PST)

[michaelstoops]

Added a new instrument driver for Pico SCPI labTool (PST), an USBTMC instrument based on a Raspberry Pi Pico.

I did this primarily to familiarize myself with the QCoDeS and build portfolio material for this job posting: https://www.linkedin.com/jobs/view/4368406324.

I think that this unsolicited contribution warrants addition to the maintained codebase because:

1. This instrument can provide hands-on experience with physical, functional VISA and QCoDeS instruments with a very low barrier to entry.
2. I suggest that it's a worthy training exercise for driver authors. Perhaps onboarding for driver developers should include acquiring a PST and either recreating or improving this driver.
3. The underlying device, and potentially the QCoDeS instrument, is quite functional, despite being simple and cheaper than a cup of coffee.

The instrument hardware can be purchased online for $4. With the v0.01 firmware, it offers:

• Four digital outputs
• Four digital inputs

The underlying Pico hardware could provide significant infrastructure/automation capabilities, even if it doesn't produce scientific-quality measurements. It can perform many more modes of operation:

• More digital I/O
• PWM
• ADC and DAC
• Other sensors and devices via I2C, SPI, 1-wire, etc, and potentially 2.4 GHz ISM-band radio.

The v0.01 firmware is based on other authors' work, which includes some support for the above additional hardware. Jan Cumps' work specifically implements a I2C/SPI interface for ADS1115, a 16-bit ADC on the USBTMC interface. I had intended to add support for the excellent Bosch Sensortec series of environmental sensors, but I didn't have the time.

This is my most significant contribution to QCoDeS so far. I'm sure I missed something, so let me know. I think I didn't build the docs and verify that all of my formatting came out right. I'm also not sure whether that step applies to contrib-status drivers.

• Build and test the docs

Thanks for your time, and please do help me get through the recruitment gauntlet for that job posting. I would like to write instrumentation drivers for you.

Michael

[codecov]

Codecov Report

❌ Patch coverage is 0% with 24 lines in your changes missing coverage. Please review.
✅ Project coverage is 10.11%. Comparing base (e668de8) to head (7285ff2).
⚠️ Report is 148 commits behind head on main.

Files with missing lines	Patch %	Lines
...rc/qcodes_contrib_drivers/drivers/Pico/Pico_PST.py	0.00%	24 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #520      +/-   ##
==========================================
- Coverage   10.12%   10.11%   -0.02%     
==========================================
  Files         168      169       +1     
  Lines       22235    22259      +24     
==========================================
  Hits         2252     2252              
- Misses      19983    20007      +24     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jenshnielsen]

@michaelstoops This looks like a useful tool that would be nice to allow users to get started with VISA instruments. I noticed however that this seems to be based on a fork of the firmware. Would it be possible to avoid having a fork that is specific to qcodes?

[michaelstoops]

Would it be possible to avoid having a fork that is specific to qcodes?

The short answer is yes. I didn't change very much. That said, the things that I changed probably should be changed. I'll see if I can get them pushed upstream. I have no idea whether the author will agree.

I wanted the four digital outputs to animate the MS logo, but it's not strictly necessary. I could also add a compile-time switch for alternate layouts.

I think a Pico instrument as an introduction is useful. I don't know whether your users are interested in off-the-shelf industrial-grade sensors, but if they are, a Pico would make a fine bridge to SPI/I2C devices.

If I had my preference, I'd want the Pico VISA interface built on MicroPython/CircuitPython, rather than the Pico C/C++ SDK. The SDK works well on Raspberry Pi OS on a Raspberry Pi computer, but it's pretty miserable to use on Mac. Implementing it in Python could skip all that and support drag-and-drop scripts that your users might appreciate. There's also a bunch of off-the-shelf integration available via Adafruit: https://docs.circuitpython.org/projects/bundle/en/latest/drivers.html.

The catch is that the USBTMC device profile isn't currently available to the Pico's Python environment, so it would take at some work to integrate them.

Thanks,

Michael

[michaelstoops]

Sorry to let this go idle. I'm looking at it again today. I hope to have some updates soon.

[michaelstoops]

I've worked with the upstream developer on some updates, and changed this driver to work with the upstream firmware.

This update withholds some documentation that I'm still noodling on. I wanted to get at least this functional change through.

[jenshnielsen]

To fix the docs build issue you probably need to mark this notebook as not being executed during docs build. Please see https://microsoft.github.io/Qcodes/examples/writing_drivers/Creating-Instrument-Drivers.html#Documentation for how to do that