DANIU ADS5012H 100MHz 500 Ms/s portable scope for $80 USD ??

[Kosmic]

I tested a similar setup (9 pulse each 300ms) on my unit (older model with 4 relays). At 2.5kHz in single / normal it's working fine. 5 kHz it start struggling and the waveform is shifted to the left. At 10 kHz, half the waveform is shifted to the left.

Auto mode is just not working with this type of waveform.

[dave j]

I believe there is a possibility for reading every sample for trigger detection may be at 25 MSPS or may be a bit more. After his, there will be windows of inactivity.
I don't think they tried to optimize very hard the capture process. With open firmware and ability to make incremental progress.

I've been thinking about what could be done with software based trigger detection.

The DSP instructions in the MCU's Cortex-M4 core mean you could check 4 samples with a single USUB8 instruction. For a rising trigger, if you subtract the trigger values from 4 samples the result will be zero if none of the samples exceed the trigger. So processing 4 samples could be:

Code: [Select]

LDR samples, [buf], #4
USUB8 res, samples, triggers ; For rising trigger, swap samples and triggers for a falling one.
CBNZ res, found

With some loop unrolling and instruction reordering to hide the latency of the load you'd have code that looks like:

Code: [Select]

LDR samples, [buf], #4
CBNZ res, found
USUB8 res, samples, triggers
LDR samples, [buf], #4
CBNZ res, found
USUB8 res, samples, triggers
LDR samples, [buf], #4
CBNZ res, found
USUB8 res, samples, triggers

which would check for a trigger occurring in 4 samples every 3 processor clock cycles - or 224MSPS with the MCU's 168MHz clock..

Obviously the whole thing wouldn't go that fast, but I think that 100MSPS might be realistically achievable.

[ataradov]

Obviously the whole thing wouldn't go that fast, but I think that 100MSPS might be realistically achievable.

And that's exactly why I'm excited about this project. I never had a chance to do deep DSP optimizations on Cortex-M4. And this project is pretty contained in its scope (no pun intended).

[dave j]

And that's exactly why I'm excited about this project. I never had a chance to do deep DSP optimizations on Cortex-M4. And this project is pretty contained in its scope (no pun intended).

With MCU based scopes, most of the DSP fun comes from implementing the automatic measurement functions - which can be a bit of a rabbit hole if you let it. Best leave that until you've got the basic scope functionality working.

[rvalente]

Nice little gadget I would buy one if:

There was VGA screen instead of WVGA: after using my THS720P, U1602B, DS1052 and others the 320x240 is just to low be really useful.
Please ad a rotary encoder, this push to increase/decrease the time base and voltage scale is just non sense, even if they are shared between vertical and horizontal.

Besides that, yeah, for this money, why not? Oh, I would never use this in any mains connected stuff, zero protection from what I've seen

[ataradov]

The device is very well balanced. Bigger higher res screen will not add a whole lot of value.
Buttons also feel good. They are not overloaded as some other devices, so you get used to them pretty fast. I actually would not want an encoder on this specific unit. It is like a thing between the real scope and a multimeter, and it is surprisingly good for what it is.

Also, my shipment of GigaDevice parts from LCSC has been sitting at LAX airport for more than a week now. Not sure what is going on there.

[rvalente]

My complain with QVGA screen is that sometimes there is a high frequency in the middle, and you cant see nothing besides of a white filled polygon.
Screen resolution is always better, phones have gone crazy with it and is something we do not want to step back, also a QVGA and VGA screen costs basically the same nowadays.

As for the encoder, the majority of the scopes, except few handhelds, have been using them. its a personal taste but I feel its much more enjoyable to turn CW or CCW a dial with nice detents feedback to increase/decrease time base or volts scale them a rubber buttons but, as you said, they feel good and I never tried this equipment before.

[splin]

[

Code: [Select]

With some loop unrolling and instruction reordering to hide the latency of the load you'd have code that looks like:

[code]LDR samples, [buf], #4
CBNZ res, found
USUB8 res, samples, triggers
LDR samples, [buf], #4
CBNZ res, found
USUB8 res, samples, triggers
LDR samples, [buf], #4
CBNZ res, found
USUB8 res, samples, triggers

which would check for a trigger occurring in 4 samples every 3 processor clock cycles - or 224MSPS with the MCU's 168MHz clock..

Obviously the whole thing wouldn't go that fast, but I think that 100MSPS might be realistically achievable.

The Cortex M4 load instructions are actually 2 cycles to execute but sequential loads are pipelined so only the first takes 2 cycles. So best to load a block of registers first to minimize the extra cycle overhead of the first load.

Also the memory reads have to compete with the DMA writes of the ADC data to RAM so some loads may stall by an extra cycle. They might not of course - it depends on the relative priorities of the DMA and the M4 core and the implementation of the arbitration. Since DMA implementation is vendor specific I guess the behaviour will differ between the STM32F407 and the GD32 version.

The good news though is that, from the other thread, the GD32F407 must be overclocked to 250MHz, otherwise it wouldn't be able to read the ADC data at 125MSPs. Note that the STM32F407 requires 4 clock cycles for each GPIO to memory DMA transfer so it only works on the GD32.

Conclusion: hopefully it will be just possible to handle the triggering without the DMA overrunning, depending on the internal bus contention impact. There will also be some additional overhead in swapping the DMA buffers over, but this will be amortized over a whole buffer (64k?) so should be minimal.

It may be possible to avoid having to check, and reset, the 'DMA buffer half full flags' which you would normally do to know when to supply the DMA with the address of the next buffer when the current one is full. This might be avoidable by padding the trigger detect code with enough NOPs such that it's execution time exactly matches the incoming data rate.

[EDIT] Using a 'load multiple' instruction to load a block of ADC samples into registers might not work - I don't know if it would stall a DMA write until the ldm instruction completes which would cause a DMA overrun.

[ataradov]

Also the memory reads have to compete with the DMA writes of the ADC data to RAM so some loads may stall by an extra cycle. They might not of course - it depends on the relative priorities of the DMA and the M4 core and the implementation of the arbitration. Since DMA implementation is vendor specific I guess the behaviour will differ between the STM32F407 and the GD32 version.

The DMA has double buffer mode. And the buffers can be split between SRAM1 and SRAM2, which can be accessed concurrently. So DMA can fully autonomously receive the data while CPU processes the other buffer.

I frankly expected a bit more. I've got spoiled by SAM V71 where there is true multi-port SRAM and DMA with real linked transfers. But the double buffer mode may be better this this case actually, since reloading linked transfer descriptors also takes time.

SRAM2 is only 16K, so the total sample memory would be 32K samples.

The actual performance would have to be tested on the real hardware.

Note that the STM32F407 requires 4 clock cycles for each GPIO to memory DMA transfer so it only works on the GD32.

Where does it says this? I can't find it on a quick scanning of the datasheet.

[splin]

The DMA has double buffer mode. And the buffers can be split between SRAM1 and SRAM2, which can be accessed concurrently. So DMA can fully autonomously receive the data while CPU processes the other buffer.

I meant to point that out but I was assuming that it might be necessary to execute the code from SRAM code. Finally getting round to looking at the GD32 D/S I see the FLASH is zero wait state so not necessary.

I frankly expected a bit more. I've got spoiled by SAM V71 where there is true multi-port SRAM and DMA with real linked transfers. But the double buffer mode may be better this this case actually, since reloading linked transfer descriptors also takes time.

Yes I was a bit shocked when I discovered how basic it is, especially that the only documented way of monitoring progress is to use the buffer half full and full flags / interrupts which is limiting depending on fast the DMA is.  However it turns out you can monitor progress by reading the DMA destination address register which can be helpful.

Note that the STM32F407 requires 4 clock cycles for each GPIO to memory DMA transfer so it only works on the GD32.

Where does it says this? I can't find it on a quick scanning of the datasheet.

It's not in any documentation that I can find for any of the STM32 devices which is irritating. According to a post on the ST forums the read speed depends on a number of factors including bus contention,  FLASH accesses that are in program etc.  Also input data is resynchronised which will cost a clock or two. The CLK/4 comes from others experimentation - for writes at least, but I can't now find anything specific about GPIO reads so they could be even slower. There is some good information at:

cliffle.com/blog/pushing-pixels

He manged to achieve clk/4 for DMA writes to GPIOs so reads are unlikely to be any faster. Unfortunately his blog seems to be broken now so only part of this blog is navigable which is a shame because he gives some interesting insights into some poorly documented aspects of the STM32F407 buses and DMA and he does it in a concise but very readable form.

The GD32 implementation is presumably very different so his information wouldn't be relevant anyway.

You probably know but be aware that only DMA2 can be used for GPIO to memory (on the ST part anyway).

[rigol52]

Tablet Scope FNIRSI 1013D vertical sensitivity of 50mV/div is really unacceptable poor.

Par example competitor Micsig last tablet model Micsig STO1152C Plus has 100 times better vertical sensitivity of 0.5mV/div.

Even micro toy DSO112A has better vertical sensitivity of 2mV/div.

One more thing that need to be improved.