Hello,

Unfortunately I am not aware of a specific case where EVE has been use to produce a HUD, but again the ability to achieve this is more related to the LCD panel being used.

I am aware that special high brightness displays are available for such an application. You could try looking at winstar, display technology or Newhaven's product stacks to see if they have an applicable display for your application.

Best Regards,
FTDI Community

Hello,

I had the dev team look at this and unfortunately they cannot reproduce what you are seeing:
The only thing they did note was to ensure the first character is at ASCII 32, not 31.


Best Regards,
FTDI Community

Hello,

Since this is not one of our products, although it utilises our device, I am unable to support it.
Product Manufacturers are responsible for supporting end-users of their products.
FTDI cannot control how the USB ICs are used and often has no knowledge of the entire product.
Please see the following document for reference:

http://www.ftdichip.com/Support/Documents/TechnicalNotes/TN_102_OEM_Technical_Support_Requirements_for_FTDI_Products.pdf

The OEM product may not use our standard drivers.
If it does, see the information below.

Usually windows will automatically find and install the driver if you are connected to the internet. Simply plug the device into the PC.
However, you can use the setup executable found on our website.
Note: you may need to save to PC, right-click and select run as administrator.
This will install the drivers on your PC with licensing information, so next time you plug in the device the device should be enumerated with those drivers.

Also refer to the Installation Guides. The 2.12.28 drivers can be pointed manually in Device Manager.

Best Regards,
FTDI Community

Hello,

The USB subsystem requires root user privileges to access on Linux, as a result the sudo command may be required.

Best Regards,
FTDI Community

Hello,

We have measured i2c write/read on Windows and Linux platform.

The test consists of:
1.            Read / Write 10 bytes
2.            Using different frequency 500Kbps/1000Kbps/3400Kbps

The difference is very small:

Linux i2c write                                 
500Kbps  1000Kbps   3400Kbps
305us      206us        250us

Windows i2c write                                         
500Kbps  1000Kbps   3400Kbps
309us      170us        250us

Linux i2c read                                   
500Kbps  1000Kbps   3400Kbps
818us      760us        577us

Windows i2c read                                           
500Kbps  1000Kbps  3400Kbps
712us      660us       652us

So this shouldn't cause an issue of data within 10ms of data available.

You are also in contact with our support team via email. Please work with the support person and post any resolution here to help other community users.

Best Regards,
FTDI Community

Hello,

In Linux, 'FT4222 A' is the interface 0 description of device. Not the chip code of the device.
See code output below:

cc get-version.c -lft4222 -WI,-path,/usr/local/lib
sudo./a.out

Device 0: 'FT4222 A'
  Chip version: 42220400, LibFT4222 version: 01040409
I have requested support from our R&D engineers to see if there are any known issues with LibFT4222 which could cause issues like you are seeing. Please expect significant delays in the process.

Best Regards,
FTDI Community

Hello,

The description in the chip will be shown when the device is initially connected but in device manager Windows will replace the name with those taken from the inf files of the driver (e.g. USB Serial Port). This will happen for other USB devices too including our other USB-serial chips.

To change the string, you would need to edit the inf files but the latest versions of Windows have these digitally signed and so if you edit these you would not be able to install the driver in normal user mode on Windows. If your device was to be distributed to customers you would normally get a custom PID and program the device with this and have a driver edited to match your PID along with the new strings. You would then get reseller rights from Microsoft to re-sign your driver. Microsoft require you to purchase an EV certificate and so this would involve costs.

An alternative is to keep the VID/PID and the inf file as default, but to open the device using our D2xx driver as you can open by description. This means your application can find the device with no effort by the user. As a trade-off you would not get your device name in the device manager but on the other hand it saves cost and time. But if your main objective is to make the device easy to find and open with minimal hassle to users then this might be a good solution.

If you already have an application on Windows that uses VCP, you can even open the device by description in D2xx, check the COM port number via FT_GetCOMPortNumber and then close it and pass this to your VCP program.

Best Regards, FTDI Community

Hello,

The libMPSSE uses separate FT_Write commands to send each part of the SPI transaction and so there will be a delay between the data and the CS operations as each FT_Write will be a new request to the host controller and will be at least on the next USB uframe (could be longer depending how the host schedules it). This is to make the library more generic as SPI peripherals have many different requirements.

As you mentioned, you can use D2xx and you can send the chip select GPIO command and the clocking command and data and the CS de-assert GPIO command all in one buffer with one FT_Write. If you add all these into one data array and pass to FT_Write, there will be much less delay between them (almost no delay between CS and data if you only clock in/out a few bytes).

When you have a known peripheral which needs a certain sequence, optimising the code like this will make a big improvement.

We also have the source code of libMPSSE and you can make the same change there.

Best Regards, FTDI Community