781
Discussion - Software / Re: FT813 CRC calculating and adressing
« on: July 30, 2018, 03:11:46 PM »
Hi Gokhan,
For Q1,
Yes, some commands such as CRC and GetPtr use the RAM_CMD FIFO to return the result. In these cases, you should still respect the rollover and should not try to get the result from an address beyond the end of the FIFO.
When you write the command, send the parameters replacing any result fields with dummy 0h values of the same size (in this case, all 3 parameters are 32-bit values including the result). Whilst CS is low, FT8xx will wrap the data around at (RAM_CMD+4095). Your own MCU's count of the offset should also perform a wrap-around.
void cmd_memcrc( uint32_t ptr, uint32_t num, uint32_t result );
Then update the write pointer and await the pointers being equal i.e. REG_CMD_READ == REG_CMD_WRITE.
Once equal, check the ending address WritePointer = REG_CMD_WRITE This would be the 12th address as you mentioned in this example. (4092 plus 4 byte command plus 12 bytes of parameter)
Now you can do a 32-bit memory read of address (RAM_CMD + WritePointer - 4) & (4095) and you will be going back by 4 bytes taking account of rollover and reading the result. Therefore, you would do a read of the 8th address as you mentioned.
The REG_CMD_READ and REG_CMD_WRITE would still be pointing at the 12th address. You would use a memread32 to retrieve the 32-bit result value beginning at the 8th address.
For Q2,
You should always use the buffer as a true circular buffer. You should start your 3012 bytes of command from the current pointer position and should not write them back to 0.
Do you use burst writes? (keeping CS asserted and streaming the commands)?
If so, as you stream the data, the FT8xx will wrap around internally at 4095 back to 0 and so the commands will stay within the buffer.
Your own MCU code should also perform the rollover so that you can write the correct value to REG_CMD_WRITE at the end of the new list. e.g. MCU would track offset as ((2048+3012) & 4095)
Best Regards,
FTDI Community
For Q1,
Yes, some commands such as CRC and GetPtr use the RAM_CMD FIFO to return the result. In these cases, you should still respect the rollover and should not try to get the result from an address beyond the end of the FIFO.
When you write the command, send the parameters replacing any result fields with dummy 0h values of the same size (in this case, all 3 parameters are 32-bit values including the result). Whilst CS is low, FT8xx will wrap the data around at (RAM_CMD+4095). Your own MCU's count of the offset should also perform a wrap-around.
void cmd_memcrc( uint32_t ptr, uint32_t num, uint32_t result );
Then update the write pointer and await the pointers being equal i.e. REG_CMD_READ == REG_CMD_WRITE.
Once equal, check the ending address WritePointer = REG_CMD_WRITE This would be the 12th address as you mentioned in this example. (4092 plus 4 byte command plus 12 bytes of parameter)
Now you can do a 32-bit memory read of address (RAM_CMD + WritePointer - 4) & (4095) and you will be going back by 4 bytes taking account of rollover and reading the result. Therefore, you would do a read of the 8th address as you mentioned.
The REG_CMD_READ and REG_CMD_WRITE would still be pointing at the 12th address. You would use a memread32 to retrieve the 32-bit result value beginning at the 8th address.
For Q2,
You should always use the buffer as a true circular buffer. You should start your 3012 bytes of command from the current pointer position and should not write them back to 0.
Do you use burst writes? (keeping CS asserted and streaming the commands)?
If so, as you stream the data, the FT8xx will wrap around internally at 4095 back to 0 and so the commands will stay within the buffer.
Your own MCU code should also perform the rollover so that you can write the correct value to REG_CMD_WRITE at the end of the new list. e.g. MCU would track offset as ((2048+3012) & 4095)
Best Regards,
FTDI Community