New features / improvments

[mengstr]

After having used the software for 5 minutes while making the captures for USB LS/FS I've discovered that I miss a few things even for doing something so simple as that. So I have a bunch of ideas/observations here:

1. The Zoom factor of 2000 is far too little to feel useful. Please increase that so the entire samples range can be displayed at once. If it's a speed issue maybe that can be mitigated by having a secondary array of samples where the data is pre-merged, maybe 32 real samples merged into one where 0 means "all was zeros", 1="all was ones", 2="mixed zeros and ones" and then use that array for displaying at high zoom factors.

2. (This is somewhat mitigated if we can zoom more) but when I cleaned up the LS sample I wanted to remove all "dead" samples before and after the part I wanted. It took a lot of mark-a-range, right-click, and select cut-range to remove 95% of a 100K samples. So a Cut-from-start-to-here and also a Cut-from-here-to-end would be nice to have.

3. The context/right-click menu items could be on the standard top-menu as well. It took me quite a while to discover that I had to right click on the marked region to do anything with it.

4. It would be great if it was possible to mark regions or set the blue dashed marker by clicking in the traces directly instead of just at the top line with the tick marks.

5. When marking a region, show the region across all traces and not just at the top.

6. Always show timing information about the marked region, even while dragging/setting the region start/end points.

7. Showing the duration between each transition in the trace being hovered over would also be a super great feature - I think that is what I miss the most.

8. I guess having the mini-map showing all of the samples at the bottom just above the scroll handle could be there all the time and not just when dragging the handle. It's a good way of seeing if anything was captured. With the rather limited sampling depth I had to retry many times before I captured anything usable and I had to go down and hover over the scroll bar each time. The mini-map could be a quite a bit smaller vertically, and I guess only showing the first four of the channels would be good enough.

9. The numbers in the Frequency Pre/Postsamples in the Capture Settings screen do have a lot of 0's normally. I really can't tell if it is 100000000 or 10000000 I have entered in a field. Allowing (and displaying) with thousands-spaces like 100 000 000 or maybe even better allow for 100M to be entered would be great. For me the increment/decrement arrows in those fields are useless - I think they could be removed.

10. Warn if invalid samples rates are entered. Now I can enter 89712738 as a sample rate which I doubt can be generated in the RP2040. Or can it without resorting to fractional/temporal dithering? If it could it'd be super cool.

[gusmanb]

Hi.

Let me answer some.

1. The new version reaches up to 4k samples in screen and I possibly will increase it even more, I have improved drastically the rendering speed and now is feasible.

2. You can already do that, click once and place the user marker, then go at the end (or beginning) of what you want to cut and shift+click, it will select the full span, all is explained in the Wiki.

3. All that is explained in the Wiki....

4. Will think about it.

5. Ok, will check what I can do.

6. Not sure about that... I hate floating windows that folow the cursor... If I think a way of showing it properly, will check it.

7. Ok, sounds reasonable, will check it.

8. Ok, that's a problem, I have many many users that use the application in old computers with small screens, and that would eat too much space. I will think in adding a "pin" button to fix it by choice.

9. Need to check if the avalonia's control allows to do it.

10. You can set any frequency you want but it may jitter a bit, the frequency what controls is the PIO clock and what the system does is to extend periodically a cycle to n + 1 so is a steady jitter that happens always at the same interval. I will think in adding a label next to the frequency indicating the jitter percentage.

Cheers.

[mengstr]

Thank you for the reply and considerations of my suggestions. :-)

A bit unrelated to the above I thought I might ask you if it's possible to use the PIO engine to shift bits. Chatgtp indicates that it's possible to read a single GPIO pin eight times and shift those bit into a byte and then store that byte to memory using the DMA.

Considering the low-low price of a RP2350 it would not be prohibitively expensive to take 32 of them and gang them up to read 32 bits together at the full speed and storing up to 8*512K= 4G samples.

It'd be silly to hook that up to the PC with 32 separate USB cables ^__^ so the remaning unused GPIO would have to be connected as a bus to a master communication RP.

Would that be feasible in theory at least?

[artgodwin]

Do you have any plans for a 2350B software and buffer card ? I have just received a board from https://www.lectronz.com/products/rp2350-stamp-xl and there may be others available too now.

[gusmanb]

Not for now.

[artgodwin]

Is that a matter of priorities or do you feel stacking analysers (which is a great feature) is a better way to tackle wider captures ?

[gusmanb]

Right now is a matter of priorities, I'm in the middle of developing V6.0 which includes massive changes to the software, major changes to the firmware and the new board to support the Pico 2.
Also I have here a PiMoroni with PSRAM that I would like to test after V6.0 is released and check what could be achieved with it.
Then I may check the stamp, it would be cool to expose 32 channels directly from one board, but I must go step by step :)

[artgodwin]

Yes, that's certainly plenty to keep you busy :).
I think the stamp also has an unpopulated PSRAM site but usage should be similar.
If you develop any performance tests I may be able to run them.

[mengstr]

My main concern for this was the rather limited sample depth, 32K->128K samples is not much - basically what we had in the 1980s. So if it was possible to just use one bit per RP and shift/collect into a full byte before storing it to memory the 128Ksamples would be increased 8-fold.

But storing the data in external PSRAM sounds even better! 8 mega samples @ 8 bits per device and 4 devices in a chain.

Is there any way to have the firmware to sample according to an external clock - I.E synchronously? Or does the PIO architecture not support that in any reasonable speed?

[gusmanb]

With the daisy chain you will sample 32 channels at once, (or 16, or 8) and then once the memory is filled other will continue where it left, so you will achieve the same result (not for a single channel, but 4Msamples would be already enough :D)

Technically speaking no, each clock runs at its own pace, but a synchronized trigger can be raised to all at the same time and then it will have a +-1 cycle of jitter (that's what I do for the 120 channels and gives a very good result).

Also, if you want a pure sync (each sample is managed by the clock, not only the initial trigger) then the biggest problem is the ammount of instructions.

To achieve 100Mhz in the 200Mhz Pico I had to implement a tight loop that has only two instructions:

POST_CAPTURE:

    in pins 32			        ;read sample
    jmp x-- POST_CAPTURE	;loop if more samples **needed**

Let's say that you now want to sync this through a pin, you would have something like this:

CAPTURE:

    jmp pin CAPTURE      ; wait for trigger
    in pins 32		       ;read sample
    jmp x-- CAPTURE       ;loop if more samples needed

Simple, right? Well, not so much, adding a single instruction has reduced the effective speed from 100Mhz to 66Mhz... and the more complex the code, the slower it happens...

For faster things a CPU is not the correct tool, even the PIO has its limitations, this is the most abusive use possible of them and I don't think its designers had in mind moving such a massive ammount of data so fast... think that the 100Mhz analyzer is moving 3.2Gbit/s, that's just impressive.... but it is limited on what can you do while this transfer happens. And if I get the Pico 2 to run properly at 400Mhz is going to move 6.4Gbit/s... that's just brutal :)

There are other tools that could be a lot better for this kind of device, for example the Tang Primer FPGA module has 20K LUTS, comes with 128Mb of DDR3, has a massive ammount of IO's and it costs around 30€... with one you can create an analyzer that literally obliterates the professional ones, but, that's a very different beast, to use it you need to create an appropiate pcb, Verilog is a lot more complex and then it is not as easy to implement by a hobbyst that just wants to know what the hek is happening on that screen that can't get to work with its Arduino :)

That's the beauty of this project, you have a pico lying around your stash of boards, need an analyzer and is as simple as dropping the firmware to it, and voi-la! you have an analyzer with decent capabilities. And if you want to measure things that are not 3.3v you have a simple shifter board (or even you can create your one), and even more, you can chain multiple to get more channels!

The only thing that I wished for the Pico 2 and that did not happened was to get a faster USB, the USB on this chip is slow as hell, you can't get more than 128-130Kb/s at best... If it had come with a USB 2.0 then things would be extremely different, I could stream the data directly from the PIO to the USB port, and then we would have infinite captures up to 30Mhz (still not the 200Mhz but for slower signals would be really good).

[mengstr]

With the daisy chain you will sample 32 channels at once, (or 16, or 8) and then once the memory is filled other will continue where it left, so you will achieve the same result (not for a single channel, but 4Msamples would be already enough :D)

4Msamples should be plenty - I assume that would be only for the Pimori/PSRAM board?

Technically speaking no, each clock runs at its own pace, but a synchronized trigger can be raised to all at the same time and then it will have a +-1 cycle of jitter (that's what I do for the 120 channels and gives a very good result).

That is a 200MHz cycle jitter? I.E +/- 5ns. If so I really can't complain :)

Also, if you want a pure sync (each sample is managed by the clock, not only the initial trigger) then the biggest problem is the ammount of instructions.

Considering one doesn't need to massively oversample when having an external clock even speed downwards to 20MHz would make me happy for most of my usage cases.

That's the beauty of this project, you have a pico lying around your stash of boards, need an analyzer and is as simple as dropping the firmware to it, and voi-la! you have an analyzer with decent capabilities. And if you want to measure things that are not 3.3v you have a simple shifter board (or even you can create your one), and even more, you can chain multiple to get more channels!

Ahem..... I just realised that I think the card I did the ISO7816 samples on was a 5 volt card, and I just hooked the pins of the Pico straight into them. Lemme check what voltage I have on the lines... Nah... It was a Class B card so 2.9 volts. No worries.

The only thing that I wished for the Pico 2 and that did not happened was to get a faster USB

I guess using the PIO + CPU to do a 480mbit bitbanging of USB HS is far far out of reach. ;-) ;-) I'm actually been spending a bit of time now designing a 74-series -only design that can (will) handle the initial initialisation and then communicate 8 byte blocks in and out to the host using setup-frames. I'm glad LS is so slow and feature limited....

[gusmanb]

• No, if you daisy chain 8 devices and capture 1 to 8 channels (1 byte) you would have 4M samples
• Yes, that would be +- 5ns :)
• Then, it is possible.
• In reality is not too much of a problem, the pico is 5v tolerant, is not recommended for long usages but it does not blow immediatelly :)
• 😆

[gusmanb]

Hi! If you want to test, I have linked a preview of the V6.0 here

It contains multiple of your suggestions implemented:

• Shows duration of state when hovered
• Shows jitter ammount based on your selected frequency
• Numeric selectors show thousands/millions separator
• Preview can be pinned

And also some surprises, check the link for more info ;)

Cheers.

[mengstr]

Nice! I'll have a look at it tomorrow and capture some USB LS - hopefully I've got a bit banged vendor class implementation working by then.

[MichaelM4]

Is there a second cursor that can measure the time between two points on the graph? I am looking for a simple way to measure the time between the transitions on different channels.

[gusmanb]

There is but right now is broken, if you drag over the top bar and select a range, you can right-click and in the menu select "measurements".

[MichaelM4]

OK, I though it worked like that in the previous version (5.1). But I always question my memory. :)

[gusmanb]

The function is there but the dialog will measure the full range of samples, not only what is selected, I will try to fix it tomorrow and upload a new beta.

[MichaelM4]

Sounds good. This is a great tool. Thank you for all your effort.