New feature: high speed continuous recording

[Illidann]

Thank you Nils for this great feature.

If I want to read inputs from both inputs at the same time, is it possible to do it with small changes based on your current codes? If Yes, which part should I change?

[Illidann]

One of them should be HV and the other one is LV

[Nils Roos]

I am still trying to consolidate the useful pieces of the latest developments into the public repository.

I realize that it's taking me quite long, and I'm sorry about that, I simply don't have as much time to spend on this as I'd like.

One of them should be HV and the other one is LV

It's only a minor change to have the input filters configurable individually.

[Arnold]

Hello Nils,

can you comment whats the latest status of this feature?
why do you need a Data capture buffer which is realized with BRAM?

the latest source is available here? https://github.com/HrRossi/RedPitaya/tree/dev_ddrdump

Thanks,
A

[Nils Roos]

Regarding the BRAM buffer, I wanted to get the best performance out of the AXI HP bus, and that means using bursted transfers and the largest possible bus width. The BRAM serves both functions, collecting data for a maximum length burst and packing the 14 (16) bit samples in groups of 4 onto a 64 bit bus.

the latest source is available here? https://github.com/HrRossi/RedPitaya/tree/dev_ddrdump

The ADC-to-DDR functionality has had no significant changes since then.

[martijnj]

The DMA feature is fantastic! But I wonder if it's possible to externally trigger the acquisition start? As I understand it, opening "/dev/rpad0" results in an immediate acquisition and trigger settings are ignored. Any advice on how this could be implemented?

[Nils Roos]

Well, the transfer logic tracks the internal buffer write pointer (adc_wp). And this pointer starts moving as soon as the scope is armed and waiting for trigger events.

What I'm trying to say is, it will take some changes to the logic to incorporate the trigger mechanisms.
Nothing too complicated, though, a separate address counter that only starts advancing when a trigger is recognized and keeps going until stopped by software; a separate write enable for the buffer; a stop flag on the scope control register.

You could then take the automatic start of acquisition out of the open function and use the already mapped scope IO region to set trigger parameters etc. instead.

[tfoldes]

Hi,

Could I ask you to upload the latest binaries?

btw: Thank you for the excellent work! It is very useful. I hope to use it to acquire signal from a laser spectrometer - normally triggered acquisition should be used, but I cannot find RP code that is fast enough. So I hope to read continuous (few Ms/s) data with a labview UDP receiver and post-process it to cut out the useful chunks of information.

Kind regards,
Tomas

[fisafisa]

I am a bit confused about the status of RP software development.
There is an out of date git repository (?)
There is a dev toolkit not well advertised.
There are cool projects like this one, but I do not understand on what they are based anymore?
Is this development linked to the old out-of date software version of git?
Or is it going to based on the new (closed) versions?

Just confused and the website is not helping much.

Ciao
F

[Nils Roos]

While it is true that some recent modifications have not been pushed to the public repository, these were said to not add functionality. So I still consider the repository up to date.
I was assured that the code for the next release of the ecosystem will be published as well, along with the code of the free apps.

From what I could see in beta-tests, I'd say the new release will not make this here project obsolete. Which leads me to my next point,

Update:

The code for the rp_remote_acquire and accompanying rpad-driver and ddrdump fpga have undergone some cleanup and are now merged with the latest developments in the "old" ecosystem. Please find the complete ecosystem suite here. This does away with the need to load the bitstream and kernel module, you can execute rp_remote_acquire immediately after boot. The source of the whole thing is still to be found in the branch dev_ddrdump.

The individual components are available here.

Apart from the integration into the build process, consolidation with RedPitaya/master and removal of testcode, there is now a framework for interrupts in place. Unfortunately I had to scrap my experiments with timestamping for now, I'll have to think about that some more. The ecosystem is still compatible with all common web-apps.