FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Author Topic: Using a MPSSE interface for SPI and I2C, proper setup and reset  (Read 487 times)

driver

  • Newbie
  • *
  • Posts: 3
    • View Profile
Using a MPSSE interface for SPI and I2C, proper setup and reset
« on: February 19, 2019, 11:01:19 AM »

I have been reading all the ANs about FTDI libMPSSE and FTD2XX library, and can not find any explicit description of the proper procedure to use a single MPSSE channel for both I2C and SPI, initialisation and deinitialisation. We are using FTDI2232H. Should we use FT_Purge, FT_Close and FT_Open (with FT_CyclePort if there are any errors), or is just a simple FtdiDevice.SetBitMode(0x00, 0x00); enough to reset the MPSSE interface (and libMPSSE library) to enable initialisation of other protocol?
« Last Edit: February 19, 2019, 12:26:54 PM by driver »
Logged

driver

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Using a MPSSE interface for SPI and I2C, proper setup and reset
« Reply #1 on: March 19, 2019, 05:56:15 PM »

I found there are problems with libMPSSE.dll v0.6 (win) channel init and deinit (I used it with FTDI2232H), as it seemed in my initial tests.

When using a MPSSE channel for SPI twice (SPI_InitChannel and SPI_OpenChannel), the MPSSE channel will not initialise to SPI the second time if SPI_CloseChannel(handle) is used (followed with a Cleanup_libMPSSE). Using the returned handle, FT_WriteGPIO returns Invalid Handle status.

When using only Cleanup_libMPSSE to deinitialise SPI channel, not using SPI_CloseChannel, SPI works fine after multiple init deinit sequences. But then the I2C does not initialise after using SPI. And my task requires combined SPI/I2C usage for the channel.

Any ideas?
At the moment, rewriting the I2C part to use FTD2XX.dll seems like the only solution for this problem. Do you know of a way the libMPSSE.dll can be used to access SPI and I2C devices on the same MPSSE channel?
Logged

FTDI Community

  • Administrator
  • Sr. Member
  • *****
  • Posts: 261
    • View Profile
Re: Using a MPSSE interface for SPI and I2C, proper setup and reset
« Reply #2 on: March 21, 2019, 03:24:27 PM »

Hello,

How long do you leave the device after closing and before re-opening? It may take some time for the port to close and Windows to release the handle.

Do you get an error when you try to re-open it as I2C?

If you write the code in D2xx, you can reset the bitmode by calling FtdiDevice.SetBitMode(0x00, 0x00); and then SetBitMode back into MPSSE mode. (you could probably even just start sending the new commands after ensuring that you had read all the existing data which had come back from the device and sending GPIO commands to configure the data and direction of the AD and AC buses but resetting the bit mode will provide a cleaner start).

Best Regards, FTDI Community



Logged

driver

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Using a MPSSE interface for SPI and I2C, proper setup and reset
« Reply #3 on: March 25, 2019, 12:17:21 PM »

I2C_OpenChannel() returns FT_DEVICE_NOT_OPENED (FT_STATUS==3), and a handle==0, when called after SPI channel deinit. Then all calls to I2C_DeviceRead, I2C_DeviceWrite, FT_WriteGPIO return FT_INVALID_HANDLE. I2C_GetNumChannels() returns the same number (2) as when all is working, so the MPSSE channel is seemingly properly deinitialised.
SPI MPSSE does initialise and deinitialise on the same channel B even when I2C stops initialising.

Note I did not use SPI_CloseChannel(), rather only Cleanup_libMPSSE(), because only in this way does my 1.SPI init, 2.SPI work, 3.SPI deinit sequence work more than once. But I did use I2C_CloseChannel() because for I2C not using it impeded functionality (did not work).
Logged