PCIE-ADIO16-16F DMA HT

[bob-white-23]

I have a PCIe-ADIO16-16F. I have the mpcie_aio16_16f_dma.c example working for all 16 channels. However my application would greatly benefit from the ability to do half transfers instead of full transfers looking at apci_common.h, apci_ioctl.h and apcilib.h it is not clear if that is supported. Does this card support HT. If so is there an example of configuring api_ioctl to support HT instead of TC.

[JHentges]

Hello,
"APCI" doesn't support half-transfer IRQs, but you can freely change the size of each DMA transfer: halve the amount of data per transfer and the impact is the same.
The key variable is:
"#define FIFO_SIZE 0xF00 /* FIFO Almost Full IRQ Threshold value (0 < FAF <= 0xFFF */
Each FAF IRQ determines DMA transfer start, and this threshold determines the transfer size. Lower the value from 0x0F00 and your latency will decrease proportionally.
Let me know if you have any questions -- or if I have misunderstood anything! I'm here to help.

[bob-white-23]

Thank you for the response. That makes sense. I modified the FIFO_SIZE and am now getting much more data. However, on occasion I am getting discarded data results from
apci_dma_data_ready(fd, 1, &first_slot, &num_slots, &data_discarded)
I understand that can mean that the data is not removed from the FIFO in a timely fashion. I have taken out any code processing samples from the "log_main" method to remove any overhead but after a while I still have discards and the thread is blocked at
status = apci_wait_for_irq(fd, 1); // thread blocking
After that happens the application needs to be restarted to recover. I have tried "RST FIFO", "RST ADC" and "RST BOARD".
This consistently happens when starting the application with systemd and at random times after the application is restarted.
Is there a way to recover without having to restart the application.

[jdolanIV]

The data_discarded means that in order to remove data from the FIFO we had to discard that data because there was no room in the buffers for it.
There are two approaches. You can try to avoid discarding data, or you can recover from it. This depends on your use case.
For avoiding the discard, you can try having more slots for the ring buffer. You can also look for ways to optimize your processing, and you should definitely compare release and debug build performance. I think increasing the number of slots is the easiest thing to try first.
For recovering from discarded data, you should keep in mind that the data being discarded is the new data, and that the data in all the slots of the ring buffer are going to be unchanged until apci_dma_data_done() is called to free up slots. We don't have experience with setting up a full recovery mechanism, but the approach I have in mind would be to call apci_dma_data_done() with num_slots equal to the number of slots in the ring buffer to let the driver start inserting new data.
The driver should be able to handle discarding data indefinitely so it is concerning that apci_wait_for_irq() becomes stuck.
Please let us know how we can help or any other information we can provide for getting your system working the way you want.