Hello,

Please see some simple Visual Basic examples here:

http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/VB.htm

We have not encountered this particular issue before, maybe someone else in this community will help if they have seen this issue before.

You may also be interested in TN_167 FTDI FIFO Basics.

Best Regards,
FTDI Community

Hello,

As previously mentioned the BT815/6 (like the previous FT80x) includes 1MByte of internal graphics RAM, which will limit you to ~2000 instructions. However these new ICs include support for external flash memory which can be used to store/offload graphics elements such as images. Alternately you could store images on an SD card if your MCU has support for this.

Best Regards,
FTDI Community

Hello,

Yes, the BT815/6 supports QSPI NOR flash chips with I believe a capacity of up to 265 MiB.

Best Regards,
FTDI Community

Hello

Unfortunately you cannot use sound with the CMD_VIDEOSTART / CMD_VIDEOFRAME commands.

However if you have a look at the following demo application, this covers video playback using CMD_PLAYVIDEO where the video doesn't consume the whole screen as well as having overlaid graphics:
ftp://ftp.ftdichip.com/CES/FT81xLiftDemoWithVideo/FT_App_Lift_EW2016.zip

Best Regards,

FTDI Community

Hi Alexei,

I'm afraid that each individual port on the device can only be opened once / with one handle. As you mentioned any further attempts whilst already open will fail.

One thing you could consider is to have a 'routing' process open which talks to the port and then pass any data to this from any other processes and it can send to the device, and vice versa for reading. That way there is only one process opening the port.

Best Regards, FTDI Community

Hello,

Can you just clarify which product you are using?

Best Regards,
FTDI Community

Hello,

Please check AN_157 Vinculum II Memory Management for all available information on memory management.

The Thread Manager can also be useful. See the Help menu with in the IDE:



Have you considered our latest MCUs?
A more recent solution is to use the FT90x which allows more customisation than the Vinculum products.

There are significant benefits of FT90x:

-Eclipse based IDE
-Source code for API drivers is provided
-Significant performance improvement
-Actively in development by R&D
-Improved documentation and software examples

Best Regards,
FTDI Community

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