Closed maleadt closed 1 year ago
Let's not merge this yet. I would like to port over test_pattern so we can validate buffer ordering, but there seem to still be some issues I need to qualify.
I guess we ought to sign extend in here as well while we are at it for simplicity. We can keep the old behavior by specify an unsigned stream type.
I think if we are going to sign-extend it should be in the FPGA. If we ask for 12-bit samples, the FPGA should not sign-extend (obviously) but this is, IMO, a classic case of something good to do in the FPGA.
So there is a conflation here between the number of samples for the DMA API and the number of samples in the stream API. The requested samples are per channel in the stream API. This is causing some issues in my validation when interfacing with the higher level Soapy layers that rely on this to e.g. collect 1e6 samples in a single array.
Okay this should be good to go. Note that the acquire buffer section will need some more work, so I removed it for now: https://github.com/JuliaComputing/xtrx_julia/pull/89/commits/b5ed3376d2c8b3fd61bca3eb2b42b4058f2d1c8a
I am merging this since I need it for several other tests and bringups, and as it stand this PR only adds the high level API. The change in https://github.com/JuliaComputing/xtrx_julia/commit/b5ed3376d2c8b3fd61bca3eb2b42b4058f2d1c8a is related to the buffer handling, which we will need to revisit with synchronization as well. We can move that to a separate PR.
Together with https://github.com/JuliaTelecom/SoapySDR.jl/pull/78, the following seems to make sense now (at least when inspecting the data we get back on the loopback; didn't test actualy Tx/Rx):
simple_loopback_multichannel.jl