@Mikołaj Żbikowski If, by chance, you happen to implement DMA for communications, it would be great if you could share it on this forum. DMA access will be hardware-dependent, so you will need to rewrite the platform (platform.c). Additionally, you will likely need to divide the API functions that currently perform result reading in blocking mode throughout the entire communication. In other words, there will be an initiator function for DMA communication and a completion/restart function for DMA, perhaps an interrupt handler, buffer extraction, and result formatting. Lastly, your application will need to handle communication states as it should relinquish control after initiating communication and resume once it is completed.
@Anne BIGOT and ST Staff: As you know, a fixture with four sensors, enabling all possible result options, operating at 15 Hz x 64 zones, would occupy 100% of the time with blocking communications. Therefore, I understand that the ULD without DMA has limited practical utility.
You're welcome. If it hasn't been considered before, it doesn't seem too complicated, and surely if you were to implement DMA through the ULD, it would be, very, very advantageous. It would prevent everyone from modifying the driver all the time, with the resulting challenges of maintenance, tracking, and updating of these libraries.
I am assuming communications are implemented over the old and known I2C.
Regards.
