(add:)

The advanced functionality isn't required for this device. It's my attempt to grow "building SCPI firmware" skills. That's the reason why I called them experimental. And took care to not let them interfere with standard functionality.

I'm convinced that this design is a valuable lab instrument as it is.
And I like to use it to get some niche SCP skills - both for LabVIEW and instrument firmware development.

I'm trying to keep all of that in the open - publishing my (sometimes naive) code and LabVIEW drivers. The only way to get good feedback is by publishing what you do - and hope that it gets challenged/reviewed.

But my goal is not just to build a SCPI instrument. I also want to improve my own capabilities. That's why you'll see  a mix of needed functionality and fancy stuff.
If you have similar goals, feel free to contribute to the core. Or to use this project to grow your own professional skills.

Don't worry, DAB . All releases are incremental. This firmware is still compatible with the initial release. And with all previous versions of the SCPI driver.

in essence, there is

• a set of simple functionality. With a LabVIEW block to support each of them:
  • digital in and out
  • analogue in and out
• a medium advanced function. Still supported by a LabVIEW block, but requires you to connect an ADC IC to the Pico:
  • high precision analogue in
• advanced functionality, supported by lower level LabVIEW write and read blocks:
  • the instrument specific registers

All of this works in isolation. You can get a useful design by just using the simple functions.

hehe. We use a backlog

We don't scrum,

We have milestones that represent release trains / schedules

and we do peer code reviews. Here's an example of shabaz reviewing my code:

(all actions below Shabaz review are performed by github automation)

> Is raising SRQ expected, or yet to be coming? 

To do. I could not get it to work. The code knows when to fire the SRQ, but I don't know (yet?) what to do in usbtmc to send correct data back

> Also, am I correctly doing the setup for SRQ be fired up? 

Looks correct.

To make (example) pin 2 (also bit 2 of the custom register) fan out from CONDITION to EVENT:

1 set the edge filter. Positive, negative, or both

STATus:OPERation:DIGItal:INPut:NTRansition 4
STATus:OPERation:DIGItal:INPut:PTRansition 4

If you use the first statement, negative edge will set the EVENT bit 2. If you use query 2, a positive transition will do that. If you call both, any state transition on pin 2 will fan out to the event register.

2 enable fan out of EVENT register sum to OPERation status register, bit 0:

STATus:OPERation:DIGItal:INPut:ENABle 4

3 From then on, to fan out to the OPER bit of the Status Byte register (bit 7):

STATus:OPERation:ENABle 1

4 And to call the SRQ when the OPER bit is set (that does not answer correctly at the moment):

*SRE 128

 This will actually call my function setControlReply(). I have developed attempts to reply the correct answer, but the reply wasn't spotted by the SCPI client (LabVIEW, or the Interactive test tool from NI). 
Currently its implementation is empty. I'm studying the TinyUSB code to see how I can put the state machine in the right state that it sends the data.
At this moment, I only managed to send data after I received a command. The service request is different - I have to reply on an internal firmware status change. And I haven't managed to get that working yet.

TL;DR: Custom registers work. Fanout works. OPER and STATUS BYTE work. SRE does not work.

Jan, you are moving much faster than I can keep up.

Don't stop, I will work with which ever version I can get into my Pico.