feature request: higher speed logic capture with shift registers

[nerdralph]

Nice project. I wrote a simple high-speed logic capture firmware for the AVR atmega8 a few years ago, and have been thinking of doing something better with the STM32 ever since. I have a fx2lp-based logic capture device that works well up to 12Msps, and find most of the time 1 or 2 of the 8 channels is all I use. With a 74HC595, and some minor additions to the buck50 firmware, you could support single-channel 48Msps logic capture. The STM32 needs to output the 48MHz clock to SRCLK, and a 6Mhz clock (or whatever speed you are reading the 8-bits of data) to RCLK. The input would be hooked up to SER.
Using the same concept with 2 shift registers, 2 channels at 24Msps should be possible.

[thanks4opensource]

Thanks, @nerdralph . Interesting idea. Let me "meditate" on it. My intended use-case was always multiple channels (thus the "gang" feature), but I can certainly imagine 2 channels at higher than 6 MHz being beneficial. Not so sure about 1 except maybe to capture glitches, and I wonder if c. 50 MHz speeds are really practical with the "Blue Pill" (unshielded, not using real probes). Again, I'm usually interested in order/timing of events between multiple signal lines. There would be an issue with port assignments for reading 16 bits of parallel data (the 48-pin F103 doesn't bring out all of GPIOA or B, USB's 11 and 12 are in the middle of A, PB2 is unusable because is BOOT1, etc) so there'd likely be some extra shifting and OR'ing slowdowns in the capture loop. Hmmm.

Out of curiosity, what kind of speeds were you getting with the atmega8? (I have no experience with AVR MCUs.) Were you doing timestamped sparse samples like "buck50" or just reading ports and writing them to memory (or using DMA)?

[nerdralph]

I've had no trouble with 44Mhz on a breadboard @5v, so 50+ @3.3V should be fine.
http://nerdralph.blogspot.com/2015/07/externally-clocking-and-overclocking.html

I was looking back over the f103 specs again, and noticed it has 2 SPI ports, which support at least a 18Mhz clock rate, and maybe even 36Mhz. So without any external hardware, you should be able to support 2-channel 18Msps logic capture. With SPI DMA, you'll have more free cycles left for RLE.

I agree the port pinout is not ideal, with PB9-PB15 being one of the best options I can think of for the 2nd shift register. I don't think the barrel shift operand is available in the thumb2 instructions, but maybe you could avoid the need for an and operation by enabling the pulldowns on the other PORTB pins.

The classic 8-bit AVRs like the m8 don't have DMA, so I wrote the code in assembler to get 2 channels at 2.4Msps.
http://nerdralph.blogspot.com/2014/05/24-megasamples-per-second-continuous.html

[thanks4opensource]

I come from a software background, so I'll yield to your experience and experiment for myself when I get a chance. I've always read that anything above 1 MHz was pushing it on breadboards (solderless, unless you're talking about something else).

Once again, very interesting ideas about using the SPI peripheral. I'm not sure that continuously reading the data register, or using DMA, would guarantee no pauses in the MISO sampling and SCK pulse train between the reads. I understand that the "timestamping" design of buck50 is effectively the same as RLE, but it's implemented differently. Again unclear if there's time in the tight inner loop to read SPI DR, decide if it's all 1's or all 0's, and retrigger the read, or if using DMA how to do that and reset or advance the DMA pointer, all without introducing pauses in the sampling. There's also the issue of whether DMA slows down CPU memory accesses, which I've experimented with but never found any decent explanation from ST.

All food for thought.

Yes, the buck50 assembly code relies heavily on the unused GPIO bits staying low via internal pulldowns. Also how the "bad" ones are shifted off the MSB of the word, and the ARM OR-with-shifted-source-register instructions.

[nerdralph]

I come from a software background, so I'll yield to your experience and experiment for myself when I get a chance. I've always read that anything above 1 MHz was pushing it on breadboards (solderless, unless you're talking about something else).

Don't believe everything you read. The scope screen shots of the 44Mhz oscillator output were done with it plugged into a cheap solderless breadboard. A breadboard will have higher stray capacitance and inductance than a PCB, but they are low enough that you can generally ignore them with microcontroller signals up to 20Mhz or so.

Once again, very interesting ideas about using the SPI peripheral. I'm not sure that continuously reading the data register, or using DMA, would guarantee no pauses in the MISO sampling and SCK pulse train between the reads. I understand that the "timestamping" design of buck50 is effectively the same as RLE, but it's implemented differently. Again unclear if there's time in the tight inner loop to read SPI DR, decide if it's all 1's or all 0's, and retrigger the read, or if using DMA how to do that and reset or advance the DMA pointer, all without introducing pauses in the sampling. There's also the issue of whether DMA slows down CPU memory accesses, which I've experimented with but never found any decent explanation from ST.

Those are good points. I'll have to dig out the F103 reference manual to figure out those details, and then actually test them to confirm. Right now I'm tinkering around with a couple AVR and 8051 projects, so I probably won't get to the F103 stuff for a couple weeks.

[thanks4opensource]

Thanks, @nerdralph. I'll be interested in hearing what you find out when you get around to it.