I have a couple of questions about a known issue in the release notes, and also what looks like a comment about a bug in the SPItoFTDI example. Can you have a look at the attached doc?
The known issue section of the release note was, unfortunately, poorly written. The release note should have reported that, when in DMA mode, the bTxIncrement field of the ADI_SPI_TRANSCEIVE_TYPE data structure is always treated as 'true'. So, if you need bTxIncrement='false' functionality, you cannot use DMA mode. When in PIO mode the bTxIncrement field functions correctly for both the 'true' and 'false' case.
In PIO mode the SPI driver was sending out an additional byte for each transceiver call when the SPI controller was configured as a master (this is not a slave mode issue since the clock is controlled by the master). If you connect a scope to the SPI you would have been able to observe an extra 8-bits of data being transmitted.
As far as the ftdi() comment
// one too many is resulting in the Win32 Event not being triggered
is concerned, this is related to the SPI additional byte being transmitted issue. As that issue was resolved in this release the comment should have been removed. We apologize for the confusion that this comment caused. Although we have not tried sending two 8KB buffers, there should be no reason why this would not work.
As far as the "Added DMA data chunking" comment in the release note is concerned, that section of the release note is related to release 220.127.116.11. Unfortunately, the 18.104.22.168 release note was structured to subsume the previous release notes (allowing users to see all release notes at once). However, the document uses an "automatic numbering" feature and when the "automatic number" was change to 22.214.171.124 all sections were changed to 126.96.36.199 (including the section for release 188.8.131.52).
All of these issues have been logged and will be addressed in the next release. We thank you for bringing them to our attention and, again, apologize for the confusion that they caused.
Can I ask one more question ... for a bit of advice? I'm trying to run the new example you just added, SPItoFTDI.
I bought the FTDI board and wired it up, and am in the process of trying to get the FTDI C++ example, spi_slave_test_slave_side.cpp, to compile/run on the Windows side of things. I noticed in that example that you set the ADuCM350 be the SPI master in SPItoFTDI.c, and the FTDI board to be the SPI slave in spi_slave_test_slave_side.cpp. Can you comment on the advantages/disadvantages as far as setting up the SPI master and SPI slave in this way (as opposed to making the ADuCM350 be the SPI slave and the FTDI be the SPI master)?
I'd like to extend your SPItoFTDI example so that I can continuously stream 8 kbyte chunks of data from the ADuCM350 (in a double-buffering scheme) up to Windows in order to log the data to a file. Do you think extending SPItoFTDI is a good approach (i.e. do you think keeping the ADuCM350 as the SPI master and the FTDI board as the SPI slave) is a good approach for what I want to achieve?
Retrieving data ...