We are developping a board CYUSB3014(fx3) based connected to high data rate sensor. data Rate is typically beyond 1Gbps and is dedicated to medical applications.
Furthermore, for security reasons, the board is also connected (through I2C) to a data logger that delivers small (typically 16 to 32 bytes) packets to be included in high data rate flux at every packet. The change from the data logger is asynchronous from the high data rate flux but we have to send those data in flux.
For example :
High Data Packet 1 (~32 KB) < 32 bytes status #1 logger> High Data Packet 2 (~32 KB) < 32 bytes status #1 logger> ...
High Data Packet 40 (~32 KB) < 32 bytes status #1 logger>High Data Packet 41 (~32 KB) < 32 bytes status #2 logger (new set)> ... etc.
with "manual_byte" operations mode, we retrieve the 32 KB packets from high data rate and add the logger's data before recommit. this is working, but the rythm is not that fast, less than expected.
we would like to daisy chain dma operations to use an auto_mode dma process where the "32 bytes signature" data would be located in memory and be automatically added to flux as above.
Would it be possible to proceed like in CyU3PDmaDscrChainCreate function but to create such a "flux" / "memory" / "flux" dma operation chain ?
Thank you for your help,
Solved! Go to Solution.
The main difference between a MANUAL channel and an AUTO DMA channel is that in case of a MANUAL channel, there is a provision for the CPU intervention to commit the data to the consumer socket where as in case of AUTO channel, the commit action is taken care automatically without any intervention from the CPU.
In AUTO channel, since there's no CPU intervention, you can't add the data from the data logger to the high data rate stream since you can't take a buffer out and replace the data with the data from the data logger.
Also, can you please specify which channel type are using for you application?
Is it a multichannel or a single channel?
The slowness in data stream is because of the way you are committing the data to the consumer socket. Since you are holding a data buffer and replacing some part of the data, all of the data after that buffer starts accumulating in the DMA buffers and once that action is done, the data committing is continued.
So, in doing so, the pipe is actually halted until the data in that buffer is replaced with the new data from the data logger.
thank you for your help.
We are using a multichannel.
We don't want to replace data, but to insert data from the key logger inside high data rate flux.
key logger has a much smaller data rate, so its memory content of data is not changed during several high data rate packets reception.
In auto mode, dma is auto committed from producer to consumer with the definition of a dma chain descriptor using specific procedure. Auto mode in these procedures is clearly designed to have size of producer = size of consumer.
But we would like to change this for obtaining something where dma "producer" keeps comitting consumer dma and then the consumer dma would be buffer producer + buffer key logger (not changed for a while) from memory location for example.
chain would be something like :
producer medical apparatus dma end -> producer dma key logger memory start -> producer dma key logger memory end -> dma auto consume start -> dma auto consume end -> and this looped while streaming.
I suppose defining a correct chain dma could do this, but we aren't familiar with this and libs functions aren't design for this kind of behavior.
thank you for your feedback.
Too sad, but I will process another way.
thank you for your help,