Sigrok driver

[gusmanb]

Would be desirable to create a Sigrok driver as it's a widely used software to handle logic analyzers.

[DatanoiseTV]

There has been some work done, maybe you can take a look? https://github.com/perexg/picoprobe-sump

Also, it might be worth looking into the protocol used by DSLogic. DSview as a GUI is nice (and open source) and has a ton of analysers.

[X-Ryl669]

For sigrok users, there's this implementation for RP2040. Triggering is done in software on the PC, on the last revisions (starting from rev2), and it's more limited since you can only capture at 120Msps for 400ks (so typically, less than 1/3 of a second at full resolution, else it's limited to 500ksps, for USB streaming bandwidth).

However, this repository contains everything in one place and it's very well explained, so if the software were running on Linux, it'd be perfect to use. Sigrok is more complex to set up and use, not sure about the linked driver.

[gusmanb]

There has been some work done, maybe you can take a look? https://github.com/perexg/picoprobe-sump

Also, it might be worth looking into the protocol used by DSLogic. DSview as a GUI is nice (and open source) and has a ton of analysers.

From what I see in that implementation it seems to use the SUMP protocol instead of implementing a custom driver for Sigrok. I will take a look but for now I will prefer to go the driver route as the analyzer exposes some non-standard functions (for the trigger type) and I think that with a custom driver as it exposes its own config options (that's what I understand from the documentation of Sigrok driver programming) it will be more flexible.

And about DSView, it seems that it uses a modified libsigrok version, so in theory the same driver for Sigrok should be enough to use it.

[pico-coder]

Comments from someone who's built a sigrok driver:

1. Don't expect your changes to get pulled into the main pulseview repo any time soon, maybe ever. There are currently 60 pending pull requests at https://github.com/sigrokproject/libsigrok , including How do i work with the PCB-files in Ver 6.0 #181 (mine posted Mar 1,2022) and CLCapture 'capture' mode returns all zeros. All 3 UF2s, Windows and RasPiOS workstations, usb-serial and network connections. #137 (tiny logic friend) among some others that use some kind of MCU to implement a logic analyzer. So far we've seen no responses from a sigrok moderator as to which if any would ever be pulled. See this thread on the sigrok email reflector: https://sourceforge.net/p/sigrok/mailman/message/37678040/

2. One option might to try to merge your PIO code with the PICO code that I have and my sigrok driver. I already support reading data from a dma'd stream and sending to the host. And I have support for trigger settings and run length encodings. If your interested in that path let me know. I currently release windows builds to a dropbox location (because pulseview installers are greater than the max github file size), and many folks have built pulseview for Mac and Linux. I could probably also generate Mac and Linux installers as well, but nobody has pushed me to do it...

3. I'm not sure how you might try to communicate the three triggering modes you have. While PV has trigger settings for each channel (rising/falling/level) there is no way to send miscellaneous information to the device that I'm aware of. There is some kind of "firmware" mode for devices that need to load a firmware and it might be possible to leverage that to just read a user defined text file to send configuration. Or you might just build 3 different images, or select the mode via strapping pins or .... If you find a way to communicate misc settings from the user to the device I'd be interested in it.

Thanks,
Shawn (pico-coder)

[Harvie]

Any opensource logical analyzer (and perhaps even oscilloscope) project should focus on sigrok support. i don't understand why you would handle development of your own protocol decoders, when sigrok (pulseview) already has all you need.

[gusmanb]

Comments from someone who's built a sigrok driver:

1. Don't expect your changes to get pulled into the main pulseview repo any time soon, maybe ever.  There are currently 60 pending pull requests at https://github.com/sigrokproject/libsigrok , including #181 (mine posted Mar 1,2022) and #137 (tiny logic friend) among some others that use some kind of MCU to implement a logic analyzer.  So far we've seen no responses from a sigrok moderator as to which if any would ever be pulled.  See this thread on the sigrok email reflector: https://sourceforge.net/p/sigrok/mailman/message/37678040/

2. One option might to try to merge your PIO code with the PICO code that I have and my sigrok driver.  I already support reading data from a dma'd stream and sending to the host.  And I have support for trigger settings and run length encodings.  If your interested in that path let me know.  I currently release windows builds to a dropbox location (because pulseview installers are greater than the max github file size), and many folks have built pulseview for Mac and Linux.   I could probably also generate Mac and Linux installers as well, but nobody has pushed me to do it...

3. I'm not sure how you might try to communicate the three triggering modes you have.  While PV has trigger settings for each channel (rising/falling/level) there is no way to send miscellaneous information to the device that I'm aware of.  There is some kind of "firmware" mode for devices that need to load a firmware and it might be possible to leverage that to just read a user defined text file to send configuration.  Or you might just build 3 different images, or select the mode via strapping pins or ....  If you find a way to communicate misc settings from the user to the device I'd be interested in it.

Thanks, Shawn (pico-coder)

Thanks a lot for all the info Shawn, it's really useful.

I have re-read the sigrok wiki and it seems I misunderstood how the driver worked, I thought the driver told sigrok which kind of settings wanted to present to the user but now that I read it more carefully it asks for a predefined set, not custom defined settings...

I will take a look again in the future but for now I will put this idea on hold, I will concentrate on the multiplatform app that is going to be a lot faster to develop and will allow me to implement the settings explicitly for my device.

Also, now that I'm reading the docs it seems that sigrok triggering specification is very limited, only edge triggers for a channel what completelly breaks the purpose of the device. I do a lot of retrocomputing stuff (programming, hardware development and repairs) and having 24 channels is not a coincidence, my target is to have a device that is capable of capturing data when a concrete address is accessed as it helps a lot for diagnostics (and even debugging), so if sigrok is not able to configure complex patterns like a 16 bit number for the address bus makes no sense for me to implement it.

Maybe what can be a lot easier and flexible enough would be to add to my app support for exporting captured data in a compatible format so you can capture with it and then analyze the data with sigrok. Even a more simple program, a console app, could be created to configure and trigger the captures and then use sigrok to analyze.

Cheers.

[gusmanb]

Any opensource logical analyzer (and perhaps even oscilloscope) project should focus on sigrok support.

Sorry but I completelly disagree, that's a nice way to create a monopoly, having a single option even if it's opensource is always a bad idea, who knows what can happen to a project in the future, it may disappear, it can be bought or whatever.

i don't understand why you would handle development of your own protocol decoders

The answer is simple, for fun primarily. If I do this kind of projects is not to gain anything, I do these in my spare time because I enjoy creating hardware and software, and then I publish them as opensource as a bit of a kind of retribution. I have learnt a lot from open source projects, I use open source tools, and this is my way to contribute to the community. My projects may not have the goal to become a "golden standard" or commercial products, but if someone can learn anything from what I publish, finds it useful or has fun using it then I'm more than happy.

Cheers.

[gusmanb]

If you want to use the LogicAnalyzer under Linux or MacOSX before the multiplatform app is completed or want to use it with Sigrok/PulseView check Release 1.0.0.3

[Harvie]

Being able to import data CSV to pulseview is certainly good start. But providing real sigrok driver to be able to configure device and capture directly through sigrok or pulseview would be even better 😇

[pico-coder]

I finally got some more time to have a look around at your implementation. I was at first wanting to somehow merge the best attributes of each ours into a common code base, but we make a lot of different fundamental assumptions on how DMA engines etc are managed (yours is very well focused on accurate pre/post trigger capture, mine focuses on overlapping data transmit with capture to maximize usb link bandwidth and also to optimize trace storage (at 4 channels I can store 800k samples)). And while such a merge is possible it would likely get full of bugs...

I'm now thinking the way to do this is to leave both of our code separate but combined into the same build and based on the user configs figure out which to use. Both of our code should easily fit in the 1MB of flash, then all I have to do is tweak your DMA dumps to be send over the host protocol I set up. (I pick my protocol because of the RLE and because it supports analog channels)
But I want to make sure I understand your three PIO modes, as I think I originally thought they were more complicated then they are. Specifically I thought the "complex" mode would support triggering on a sequence of values but I think it instead is a single level value.
So assuming the user sets up a bunch of triggers in pulseview which could be level/rising I think the algorithm is something like this:
A flow chart starting at the top:
1)If more than 32k samples are selected, or if any analog channels are selected, or if no trigger is specified then use my flows.
2) If a single channel is picked as rising or falling use your simple..
3) If up to 5 channels of level value triggers are picked use your fast.
4) If 5-16 channels of level value triggers are picked use your complex.
5) If none of 2-4 apply then use my flows, with the understanding that high speed captures likely won't be successful.

That sound about right?
Also, I've had lots of success running the PICO sys_clk overclocked to 240Mhz running PIO, ADC, DMA, and the cpu cores. So I would tend to just assume that we'd run sys_clk at 2x the sample rate in high speed cases. That still might miss a trigger in complex mode, but usually users run the sample rate a bit higher than the signal rates anyway.
And perhaps we might run sys_clk at 3x sample rate if it remained under 240Mhz.
Thanks,
Shawn
https://github.com/pico-coder/sigrok-pico

[gusmanb]

I finally got some more time to have a look around at your implementation. I was at first wanting to somehow merge the best attributes of each ours into a common code base, but we make a lot of different fundamental assumptions on how DMA engines etc are managed (yours is very well focused on accurate pre/post trigger capture, mine focuses on overlapping data transmit with capture to maximize usb link bandwidth and also to optimize trace storage (at 4 channels I can store 800k samples)). And while such a merge is possible it would likely get full of bugs...

I'm now thinking the way to do this is to leave both of our code separate but combined into the same build and based on the user configs figure out which to use. Both of our code should easily fit in the 1MB of flash, then all I have to do is tweak your DMA dumps to be send over the host protocol I set up. (I pick my protocol because of the RLE and because it supports analog channels) But I want to make sure I understand your three PIO modes, as I think I originally thought they were more complicated then they are. Specifically I thought the "complex" mode would support triggering on a sequence of values but I think it instead is a single level value. So assuming the user sets up a bunch of triggers in pulseview which could be level/rising I think the algorithm is something like this: A flow chart starting at the top: 1)If more than 32k samples are selected, or if any analog channels are selected, or if no trigger is specified then use my flows. 2) If a single channel is picked as rising or falling use your simple.. 3) If up to 5 channels of level value triggers are picked use your fast. 4) If 5-16 channels of level value triggers are picked use your complex. 5) If none of 2-4 apply then use my flows, with the understanding that high speed captures likely won't be successful.

That sound about right? Also, I've had lots of success running the PICO sys_clk overclocked to 240Mhz running PIO, ADC, DMA, and the cpu cores. So I would tend to just assume that we'd run sys_clk at 2x the sample rate in high speed cases. That still might miss a trigger in complex mode, but usually users run the sample rate a bit higher than the signal rates anyway. And perhaps we might run sys_clk at 3x sample rate if it remained under 240Mhz. Thanks, Shawn https://github.com/pico-coder/sigrok-pico

Hi.

It may be more complex than it looks. The biggest problem you will face is transferring the data while the PIO is capturing. I don't think you will be able to stream the data through USB directly, the bus fabric is running at its limits, when I tried to receive data using USB at the same time that capturing using DMA the device most of the times crashed because it got clogged, it's writting to memory on each 2 cycles and needs to read instructions at the same time, so there is no time left for the bus fabric to serve more access requests. If you check my code the capture is stored directly to memory and processed afterwards and meanwhile I keep the CPU activity as low as possible, it guarantees the possibility to write a 32bit word each two cycles and that nothing will delay those writes, else the bus may stall and you will lose captures making the device unreliable (in the best case, the worst would be a crash).
The only safe way that comes to my mind to make it work is let the capture as is without messing with its DMA's and send the data after processing like it is doing right now, you can then apply the RLE encoding to maintain the protocol compatibility.

Next, I use all the available memory in the device, there is very little room to add anything else, if I recall it right there are left 16Kb more or less, so adding both implementations may get very hard (not sure how much ram does your implementation use), maybe you can reuse the buffers I create, but beware, these are aligned for the DMA ring so they can't be moved.

About overclocking, the device is already overclocked to 200Mhz, I choosed that speed because is the minimum that I found that all my boards were stable, I have some boards that reach up to 320Mhz, but others top at 200Mhz so I used that speed to make it safe no matter which board you have, if more speed is needed then a custom PCB could be created instead of using the pico as-is, increasing the core voltage and using a faster flash could make it reach 400Mhz, but that is out of the scope of this project (create a powerful enough device that anyone can assemble without spending much money).

Cheers.