Dear Jeremy,
thanks for your answer. I've been able to setup the LUT in a way, it should be able to setup the slave device in SQI mode, and transfer data via SQI protocol, heeding your advice to go with IP access. And I'm really excited about the way, the peripheral is designed in order to offer maximum flexibility.
Now, however, I'm struggling with the IP RX/TX-FIFOs, and - no offence! - the i.MXRT1060 reference manual, which not only stands out by misleading wording (eg. the term "sequence number" instead of a much clearer "number of sequences"; at least "xxx number" used in a consistent way over the document), but seems to be incorrect and incomplete in many ways, e.g.
- 27.5.9.1: "If MCR0[ARDFEN] is set to 0x1," - there is no bit ARDFEN in register MCR0!
- 27.7.2.22.4: "The write address to IP RX FIFO should roll back to the start address of write window after
pushing IP TX FIFO by writing-one-clear to INTR[IPTXWE]" - shouldn't the TX FIFO roll back in that case?
Concerning the FIFO - as described in the manual, and the way it's used in the MCUExpresso framework, this doesn't look like a FIFO at all, but more like a kind of buffer used in a rather complicated manner.
In my opinion, for transmitting data, it doesn't make too much sense to set up a watermark level, fill the TX FIFO up to this watermark level, waiting until the data has been consumed completely, reset the TX FIFO, fill in the next chunk and so on. That's what one would do with a conventional buffer, and in that case, it doesn't make sense to limit the buffer size by a watermark, as the sole effect would be an increase of loops neccessary for transmitting the same amount of data, just in smaller chunks.
Even worse when receiving data: if one waits until a watermark has been reached, then picking up the fifo's content [0..watermark[, there is a certain chance of further data arriving while processing [0..watermark[. Resetting the RX fifo at this point will lose exactly this additional data received in the meantime. The risk for this constellation to occur might be low on a 600MHz machine - but usually a FIFO is dedicated to avoid this very constellation.
So I'm racking my brain if there is any reason to not making use of the FIFOs as they usually are intended for, taking the watermark as well as the IP FIFO status registers into account, which indicate the actual fill level. Any FIFO I've ever dealt with, wraps around it's data pointer automatically after having read or written the buffer's last byte (or in ths case: the last 64 bit). Everything you should have to do, is picking up the accumulated data from time to time, indicated by reaching a watermark level, providing a yet convenient time window for that job, without risk of an data overflow.
Unfortuntely, the reference manual doesn't describe the FIFOs behaviour concerning wrap around (at least, I didn't find anything about that), and doesn't specify, whether the watermark refers to a certain position within the FIFO data registers, or to the FILL field in the FIFO status registers.
Currently I can't even explore the behaviour through experimens, as my hardware will not arrive for a few more week. Could you please check if the FIFO shows some limitation or hardware bug, preventing the usual type of access, or if the documentation is just incomplete, and the provided drivers being... well... not so sophisticated as could be?
Regards
Mysterion
