Hi,

Yes that's correct, the RAM_G is just for loading assets like fonts and images and the other RAM areas (like RAM_DL, RAM_CMD and RAM_REGISTERS) are all separate areas of the memory map. Therefore the fullness of RAM_G won't cause EVE to slow down or cause it to work incorrectly.

Best Regards, FTDI Community

Hello,

FTDI devices use USB Bulk transfers and those are designed to transfer large amounts of data with error-free delivery, but with no guarantee of bandwidth.

You could try reducing the latency timer to 1ms to see if it helps.

Best Regards,
FTDI Community

Hello,

Thank you for your feedback, the current macOS VCP driver is still a beta and we appreciate any information you can provide on its operation.

Could you just confirm that the driver installed correctly from the /Applications folder on your system?
and are you seeing COM ports created for an applicable device? (which device are you using the driver with?)

Best Regards,
FTDI Community

Hello,

Unfortunately this is not something that has been done before.

We only ever recommend to connect one EEPROM as per the datasheet.

There may be other FTDI community users who have done this and may be able to help you.

In any case, the device would need to be reset or power cycled to allow for the EEPROM contents to be read and applied.

You may be safer to use a multi-chip solution.

Best Regards,
FTDI Community

Hi,

You can use RAM_G without affecting the speed or performance of the chip as the display list is created in RAM_DL which is separate. The amount of RAM_G used wont cause the device to slow down. In some cases, using an image instead of a complex series of shapes may be beneficial as it can save on RAM_DL entries.

If you load compressed images, there is one area (the top 42K bytes) which is used as a scratch area by the decoder and so it is best to avoid this if you expect to use CMD_LOADIMAGE etc. to load PNG images.

Best Regards, FTDI Community


 

Hi,

Could you post an example display list which shows the issue?

Also, which framework/library are you using to send the commands?

In general, in terms of hardware, the SPI lines should be kept very short (or having the FT813 and the MCU on the same PCB). You may find that the MCU drive strength or slew rate settings help although if the SCK and MOSI and CS look nice and square when measured at the pins of the EVE IC itself then this may not be the issue in this case.

Best Regards, FTDI Community

Hello,

Thank you for your question.

The udev system on Linux will only pull the ATTRS{serial} attribute from the parent device and note the individual interfaces on the device. this is why the channel letters are not appended to the serial number when udev is used to obtain attributes for a device (this appears to be what serial.tools.list_ports.comports() is doing).

Please see the attached 'udev.png' for an example of the output for the following command issued when a FT4232H was enumerated on an Ubuntu system:

udevadm info --name=/dev/ttyUSB0 --attribute-walk

Please note the output is for the parent device.

It is possible via the D2XX driver to obtain and access devices via their serial number, please see simple.PNG for an example output from the 'simple' Sample included in the D2XX driver download for Linux. This lists the serial numbers of all connected devices and then opens the first one it can find, in this case channel A of the FT4232H.


Best Regards,
FTDI Community