FTDI FT201x i2c read issues...

Go To Last Post
31 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm attempting to pass data back and forth between the computer and ATMega644 using the FT201x as an i2c/USB bridge. I've read so much about these chips being effortless but I've had nothing but trouble at every single step.

 

What I want to happen is this: A computer program will use USB to set a FT201 GPIO pin high to signal to AVR it is wanted. The AVR handshakes by setting one of it's pins high (connected to a GPIO input of the FT201). The AVR then reads a command byte from the FT201 via i2c telling it what the computer wants it to do. The AVR figures out what was asked, fetches any required data, and writes the data back to the FT201 via i2c. The AVR sets its pin low which signals to computer the AVR has finished it's job and the computer program reads the data from the FT201. 

 

I've gotten it to handshake but cannot successfully get the command byte out of the FT201. There's no error writing the command to the buffer according to the chip, but the chip will only return 96 to the AVR...96 no matter what command I write to it (128, 127, 64, 65, etc)!

 

My guess is I'm doing something wrong but I've combed over every relevant PDF from FTDI and I'm not seeing anything. Here's the code:

 

PC Code:
 

 public bool GetFirmwareVersion(string serial, ref byte [] data, byte numOfBytes, uint numOfBytesRead)
{
    FTDI.FT_STATUS ftStatus;
    bool isOK = false;                  // status of operation
    bool usbInPinIsHigh = false;        // Tracks USB In Pin
    byte lowMask = 0b00010000;          // CBUS 0 is output (4-7), all pins low (0-3) (Default Setting)
    byte highMask = 0b00010001;         // CBUS 0 is output (4-7), CBUS 3 is high
    byte inPinMask = 0b00001000;        // AND with pin states to get input pin value (Bus3)
    byte pinStates = 0;                 // Used to get the current pin values
    byte timeout = 0;                   // Used to timeout loop

    // Connect to target device
    ftStatus = connectedUSBDevice.OpenBySerialNumber(serial);

    //Check for connection errors
    if (ftStatus != FTDI.FT_STATUS.FT_OK)
        return false;

    // Set Firmware Command in buffer
    isOK = SetGetFirmwareCommand();    // Function Below    

    // Handshake with Device
    isOK = DeviceHandshake(lowMask, highMask, inPinMask);   // Function Below

    // Check if handshake failed
    if (isOK == false)
    {
        return false;
    }

    Task.Delay(10);

    // Wait until message is sent
    while ((usbInPinIsHigh == false) && (timeout <= 100))
    {
        Task.Delay(1);

        // Check for USB In pin to go high. Signals FW transfer is complete and to retrieve.
        ftStatus = connectedUSBDevice.GetPinStates(ref pinStates);

        // Is input pin high or low?
        if ((pinStates & inPinMask) == inPinMask)       // In pin high
        {
            usbInPinIsHigh = true;                      // Means uC finished sending data
        }

        timeout++;

    }
    /*** Always times out because wrong command comes back to AVR; never puts pin high ***/
}

private bool SetGetFirmwareCommand ()
{
    byte numOfbytes = 1;
    uint bytesWritten = 1;
    byte [] firmwareCmd = new byte[numOfbytes];

    firmwareCmd[0] = 128;       // 128 is Get Firmware Command

    // Write Firmware Command to Tx buffer
    ftStatus = connectedUSBDevice.Write(firmwareCmd, numOfbytes, ref bytesWritten);

    if (ftStatus != FTDI.FT_STATUS.FT_OK)
    {
        return false;
    }
    return true;
}

private bool DeviceHandshake(byte lowMask, byte highMask, byte inPinMask)
{
    byte pinStates = 0;                 // Used to get Pin values from USB chip
    byte count = 0;                     // Counts number of times through loop, used a timeout
    HandshakeStatus hsStatus = HandshakeStatus.none;

    // Set mask to set CBus0 out high
    ftStatus = connectedUSBDevice.SetBitMode(highMask, FTDI.FT_BIT_MODES.FT_BIT_MODE_CBUS_BITBANG);

    //Check for connection errors
    if (ftStatus != FTDI.FT_STATUS.FT_OK)
    {
        return false;
    }

    hsStatus = HandshakeStatus.high5;

    // Wait for Device to set their out pin high as response
    while (count != 40)
    {
        Task.Delay(1);

        // Get Pin state
        ftStatus = connectedUSBDevice.GetPinStates(ref pinStates);

        // Is input pin high or low?
        if ((pinStates & inPinMask) == inPinMask)       // In pin high
        {
            // Is hsStatus high5 or low5
            if (hsStatus == HandshakeStatus.high5)
            {
                // Set out pin low, change status to low5
                ftStatus = connectedUSBDevice.SetBitMode(lowMask, FTDI.FT_BIT_MODES.FT_BIT_MODE_CBUS_BITBANG);
                hsStatus = HandshakeStatus.low5;
            }
        }
        else
        {
            // Is hsStatus low or high
            if (hsStatus == HandshakeStatus.low5)       // In pin low
            {
                hsStatus = HandshakeStatus.success;
                return true;
            }
        }

        count++;
    }

    return false;
}

 

AVR Code:
 

int main(void)
{
    /* Listen for USB */
    usbHandshake();

    if (handshakeStatus == USB_HS_HANDSHAKE)
    {
    	// If handshake was successful, we need to see what computer wants
    	usbGetCommand();
    	handshakeStatus = USB_HS_RESET;
    }
}

void usbHandshake (void)
{
    switch(handshakeStatus)
    {
	case USB_HS_HANDSHAKE:
		break;

	case USB_HS_LOW5:
		if (bit_is_clear(PIND, USB_IN_PIN))			// USB acknowledged our high 5 by driving pin low
		{
		    PORTD &= ~(1<<USB_OUT_PIN);				// Set USB Out Pin Low (Low 5)
		    handshakeStatus = USB_HS_HANDSHAKE;		// Handshake Complete
		}
		break;

	case USB_HS_NONE:
		if(bit_is_set(PIND, USB_IN_PIN))			// Check if USB wants to talk
		{
		    PORTD |= (1<<USB_OUT_PIN);				// Set USB Out Pin High
		    handshakeStatus = USB_HS_LOW5;			// High5 complete, waiting on Low 5
		}
		break;
    }
}

void usbGetCommand(void)
{
    uint8_t command[GET_USB_MSG_SIZE];
    uint8_t msgSize = GET_USB_MSG_SIZE;  // = 1
    uint8_t ACKStatus = NO_STATUS;
    uint8_t count;

    //Loop until Trans complete or Fatal Error. Allows for repeated start if error
    while ((!(TWIMasterStatusReg & TWI_FULL_TRANS_OK)) && (ACKStatus != TRANS_ABORT))
    {
	// Write to controller FTDI addr (0x22)and R bit
	ACKStatus = i2c_start(FTDI_7BIT_ADDR + I2C_READ);

	if(ACKStatus != DEVICE_ACCESSED)
	    continue;

	for (count = 0; count < msgSize; count ++)
	{
	    // Check if last byte (we need to NACK)
	    if (count == (msgSize - 1))
	    {
	        ACKStatus = i2c_readNak();					

		/*** Problem is here. ACKStatus should = 128 ***/
		if (ACKStatus == 96)
		    errorBlink(3);
                
                /*** Blinks. Arrived at 96 by testing (ACK < 128, ACK > 64, etc) ***/

	    }
	    else
	    {
		ACKStatus = i2c_readAck();
	    }

            // Error Check. Breaks loop and exits if error
	    if ((ACKStatus == TRANS_ABORT) || ( ACKStatus == TRANS_REPEAT_START))
            {
   	        continue;
	    }
	    else
	    {
	        message[count] = ACKStatus;
	    }
        }
    }
    i2c_stop();										

    usbParseCommand(command[0]);
}

Is anything jumping out to anyone? Or, for anyone with experience with these chips, is there some obscure step that you need to do before things worked for you? It's gotta be something silly, these things usually are! Thank you!

Last Edited: Mon. Dec 30, 2019 - 10:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why the hell would you want to deal with the headache of I2C when the M644 has extra USARTS?  Then you can get a simple FT232 and connect it to the spare USARTS and see how easy the parts are to use?

 

I2C can be a pain in the ass.  Do you have the pull up resistors installed? 

 

Since teh FTDI device is a slave, I would suggest you make your life easier and use the Peter Fleury I2C library as opposed to rolling your own.  Its widely used and pretty easy to understand.

 

OR....

 

Scrap the part you are using now and go with the USART solution....UNLESS the PC boards are already built....are they? winkcrying

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jim, Thanks for the reply!

Ya, boards are already built. And honestly I find i2c very easy to use (but I admit I have very little experience with USART). The driver is basically a modified Fleury (notice the i2c function names...I kept his) but added bus timeouts (no more getting stuck in while loops), stuck bus recovery and interrupt-driven multi-master support. There are 2k2 pullups and the i2c works fine as there are 3 I/O expanders that are set up at runtime; it's just this chip that's giving me the headache...at every single step too, lol!

 

I use that errorBlink() function as a "Trace.WriteLine" so I can find the exact line of trouble code. I originally tried a 10-bit address for the FT201, but that was Nack'ing the first address byte (start was OK). I tried to simplify and went with the default 0x22 7-Bit address and now it will ACK normally it just gives bogus data. Point being, I think the i2c part of this is OK, but rather the chip config or how I'm trying to use it is the problem (which is normally the case, haha).

Last Edited: Mon. Dec 30, 2019 - 11:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sothis wrote:
I find i2c very easy to use (but I admit I have very little experience with USART).

 

You are a truly unique bird then.  I'll take SPI and USARTS any day of the week, but then I might be considered a strange bird.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
You are a truly unique bird then.  I'll take SPI and USARTS any day of the week, but then I might be considered a strange bird.

Haha! No, pretty sure I'm the strange bird. I was definitely very scared of i2c based on what seemed to be the general consensus but I guess I was lucky and had very little problems with it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you contacted FTDI for support?

 

https://www.ftdichip.com/FTSupport.htm

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
Have you contacted FTDI for support?

 

No. My experience with them directly so far has been pretty bad. I contacted them once for information about whether the FT201 or FT260 would be better with an explanation of what I wanted to do and they literally responded with links to the two aforementioned products plus eval board links and ignored the rest of my questions. 

 

Then, I asked for help on their forum for a previous problem with this chip and their response was to again send a link to an app note...an app note I mentioned by name saying I had read many times over...and again ignored the specific questions.

 

So, as someone who does exhaustive research to the best of my ability because I don't like bothering people by asking questions, answering them by telling me to read a little harder is kinda insulting.

Last Edited: Tue. Dec 31, 2019 - 01:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Got some new data. Part of the issue is that they have a programming guide for their c++ driver, but for their C# wrapper, there's functions missing, some have the names changed and no documentation to help sort through it. I finally found the C# version of a function that displays the number of bytes in Tx buffer, so right after I write to the chip I call this function but get 0 bytes, not 1. The write operation returns that it was successful however, so it's looking like this is the problem. Here's code of what I'm talking about:

private bool SetGetFirmwareCommand ()
{
    byte numOfbytes = 1;
    uint bytesWritten = 1;
    byte [] firmwareCmd = new byte[numOfbytes];

    firmwareCmd[0] = 128;       // 128 is Get Firmware Command

    // Write Firmware Command to Tx buffer
    ftStatus = connectedUSBDevice.Write(firmwareCmd, numOfbytes, ref bytesWritten);
    Trace.WriteLine(bytesWritten);

    // Check bytes in Tx buffer
    connectedUSBDevice.GetTxBytesWaiting(ref bytesWritten);
    Trace.WriteLine(bytesWritten);

    // Just in case we've mixed up our directions
    connectedUSBDevice.GetRxBytesAvailable(ref bytesWritten);
    Trace.WriteLine(bytesWritten);

    if (ftStatus != FTDI.FT_STATUS.FT_OK)
    {
        return false;
    }
    return true;
}

Console Output:
1

0

0

What could cause the chip to think things were fine and then no longer have the data a few cycles later?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is going to be a significant complication in this project. Which one is master? ASYNC serial (ie, UART) has no master and either can originate data. With I2C, one has to be the master. There is probably a multi-master mode, but why add that complexity? My hunch is that this feature, on its own, is going to be a major source of headache. My hunch is that the FTDI device defaults as the master.

 

Further, Async is full duplex and TWI is not. Somehow, you hare going to have to buffer data blocks. My head aches on this one.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Dec 31, 2019 - 02:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Further, Async is full duplex and TWI is not. Somehow, you hare going to have to buffer data blocks. My head aches on this one.

 

My apologies Jim, I didn't mean to cause you harm.

 

The AVR is the master, FT201X the slave as far as i2c is concerned. Don't worry, it's not that complicated though. I've made this much simpler by using 2 IO pins between the FT201X and AVR: 1 out of FT201 to AVR in, 1 out of AVR to FT201 in. These pins are used to flag each other for certain things so we only need to use the HW buffers of the FTDI chip.

 

For instance, if the PC wants to send or receive data to/from the AVR, it will write a command to it's Tx buffer and set it's output pin high. The AVR will find this as it polls and set it's out pin high to acknowledge and will read the command.  The PC does other things knowing the AVR is on the case. The AVR will keep that pin high until it finishes, at which point the PC sees the low AVR pin and processes.

 

So in this case, I'm trying to send the firmware version of the AVR to the PC; when that pin goes low it will know that the AVR got the command byte saying "firmware version, please" and there are now 4 firmware version bytes in the buffer. The AVR is the master, FT201X the slave.

 

If either pin high means the other has to wait its turn. This way, data can actually go both ways without too much hassle or arbitration issues and whatnot.

Last Edited: Tue. Dec 31, 2019 - 03:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@awniel: Funny, I contacted FTDI support as you mentioned and told them everything up to the latest where I identified the exact problem in post #8. I got this and ONLY this:
 

Keep in mind the FT201X is an I2C slave – did you first configure the AVR as an I2C master, and then initiate the I2C  transfer from the AVR master?   You also need to specify the correct slave address (0x22) of the FT201X in the I2C master code

The following applications note may be of help:
 

So, new question... Any recommendations for a USB to i2c (preferably slave) chip that is not an FTDI product? Might an ATTiny with USB be a good option?  Does Microchip still allocate USB Product IDs?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe if you asked your question in their native language you would get better answers, do you speak bocce, or would you need a droid to translate?  devil

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sothis wrote:
So, new question... Any recommendations for a USB to i2c (preferably slave) chip that is not an FTDI product?

 

Since you seem to be giving up on the FTDI. which means a new spin of PC Board why not think about a suggestion made in post #2? devil

 

HINT:  LAST line of the post wink

 

East Coast Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
Maybe if you asked your question in their native language you would get better answers, do you speak bocce, or would you need a droid to translate?  devil

 

Are they an Italian company? I thought they were from Scot...annnnnddd I just looked it up. I'm so ashamed I didn't get a good Star Wars reference. So funny. blush

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

Since you seem to be giving up on the FTDI. which means a new spin of PC Board why not think about a suggestion made in post #2? devil

 

HINT:  LAST line of the post wink

 

East Coast Jim

Lol, Sorry East Coast Jim. No disrespect, I made my decision to abandon whilst writing the post.

Actually, the FT201 is on a small IO board connected to the large main board that houses the AVR via ribbon cable. I'm not above hacking a PCB but those AVR TQFP pins are intimidating.

 

If I did go that route though, you still recommend the FT232? Or something else?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sothis wrote:
If I did go that route though, you still recommend the FT232? Or something else?

 

I use Silicon Labs parts, and if I want to use the GPIO I need to configure that with an external software package(its pretty easy, but lets not dwell on that for the moment).  There are also CH340 devices, and the FTDI devices.  Do a digikey search to see all the manufacturers.

 

The FTDI devices are insanely simple to use...but they re pricey compared to other devices on the market.  I have used a few of them and they all pretty much do as advertised.

 

I2C is somewhat simple to use(don't read my threads in the XMEGA forum though - LOL), but as I wrote in post #2, why would you want to make your life so difficult when using the USARTS is so easy.

 

If your creation is talking to a PC, which looks at the FT devices as a com port anyway, then simply carry that on through.  With teh USART solution, you do not need to deal with Master/Slave, Bus arbitration, syncing issues etc.  THe USART being asynchronous takes care of everything for you.

 

YMMV.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sothis wrote:
Any recommendations for a USB to i2c (preferably slave) chip that is not an FTDI product?
MCP2221A

Sothis wrote:
Might an ATTiny with USB be a good option?
No USB tinyAVR other than V-USB (low-speed USB); there are USB megaAVR and USB XMEGA AVR (full-speed USB)

Recent USB PIC are crystal-less and in PDIP.

Sothis wrote:
Does Microchip still allocate USB Product IDs?
Yes

 


https://www.avrfreaks.net/forum/ch340g-ic-vendor#comment-2819391 (MCP2221A, I2C master, SMBus master)

Sequence : USB host, USB device, AVR TWI master, AVR TWI slave

A USB device can issue a USB resume after the USB host issues a USB suspend.

Reset, Suspend, and Resume Commands - Developer Help

 

>> Little Wire (tiny85)

an instance of Little Wire though not I2C : debugWIRE via USB UART | AVR Freaks

 

Pololu - P-Star Programmable Controllers

PIC18F25K50 - Microcontrollers and Processors

...

Internal 48MHz Oscillator with USB Accuracy -Via Active Clock Tuning from USB Host

...

USB SOF has an accuracy requirement.

 

Atmel Corporation - Technical Support - Using ATMEL VID/PID

FAQ: Using Atmel VID/PID

FAQ: How to use a USB VID and PID from the USB sub-licensing program

Memos From the Cube » Obtaining a VID and PID (LUFA, search for Atmel, search for Microchip)

 

edit :

LUFA Library: TWI Driver - LUFA/Drivers/Peripheral/TWI.h

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Jan 1, 2020 - 12:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

I use Silicon Labs parts, and if I want to use the GPIO I need to configure that with an external software package(its pretty easy, but lets not dwell on that for the moment).  There are also CH340 devices, and the FTDI devices.  Do a digikey search to see all the manufacturers. 

 

Thank you so much East Coast Jim! I had a look at both CH340 and the Silicon Labs parts and there's plenty of good options. I like the Silicon Labs better I think, I should have more flexibility with them than I did with the FTDI part (More IO, bigger buffers, etc).

 

jgmdesign wrote:

The FTDI devices are insanely simple to use...but they re pricey compared to other devices on the market.  I have used a few of them and they all pretty much do as advertised.

 

I2C is somewhat simple to use(don't read my threads in the XMEGA forum though - LOL), but as I wrote in post #2, why would you want to make your life so difficult when using the USARTS is so easy.

 

If your creation is talking to a PC, which looks at the FT devices as a com port anyway, then simply carry that on through.  With teh USART solution, you do not need to deal with Master/Slave, Bus arbitration, syncing issues etc.  THe USART being asynchronous takes care of everything for you.

Ya, it's a shame. Knowing their driver and how the chip works, I shouldn't be having any problems. Like none. I played around a bit more (I'm honestly out of ideas and tech support didn't respond to my follow up), and I basically just swapped the problematic "Write" function out for anything I thought would apply (GetSerial, Get Description, etc.) and they all worked fine. Just the Write function doesn't work. I'm 95% convinced this is a driver issue or maybe a bad buffer.... something super simple but something I need their help to fix. So I'm going to lose a month of work, plus like $100 for the boards all because I can't find their App Note "AN631: What To Do When We Call You A Moron, Ignore Your Actual Question, And Refer You To An Irrelevant App Note, v4".

Last Edited: Wed. Jan 1, 2020 - 03:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

gchapman wrote:

MCP2221A

 

Thank you gchapman! This part looks really good too. And since it's both i2c and UART I can keep my buddy Jim happy and experiment with both! Win-Win.

 

So I guess the question becomes how hard are these chips to get the IO working (nice to have so I can use a smaller cable) and to handle the USB functionality with C#? Like with the FTDI I should be able to call "Write" and then read that byte/s in the Tx buffer with i2c. So simple. The thing I didn't like it that it seemed like it was going to be a chore to have their driver not display FTDI and have our company name. Not a big deal, but it does cause confusion when a customer potentially has a problem and contacts them for support. We know how that turns out.

 

Looks like those chips (the Silicon Labs and Microchip) can both be used as an HID class device which solves that problem, especially if there's a similar dll that handles the USB for me. They both have something similar to D2XX?

 

Happy New Years Gentleman! I sincerely appreciate your help!!

Last Edited: Wed. Jan 1, 2020 - 03:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sothis wrote:
I had a look at both CH340 and the Silicon Labs parts and there's plenty of good options.
Silicon Labs and Nanjing Qinheng Microelectronics (WCH, CH340) have 8051 cores with USB controllers.

MCU series chip - Jiangsu Qinheng Co., Ltd.

[WCH]

[mid-page]

8-bit enhanced USB series MCU (USB + Touchkey + Type-C + ADC)

...

A few of the WCH USB 8051 have DMA; USB XMEGA AVR have DMA.

WCH USB 8051 I2C is bit-bang :

ch554_sdcc/examples/usb_device_cdc_i2c at master · Blinkinlabs/ch554_sdcc · GitHub

via How To Program A Really Cheap Microcontroller | Hackaday

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sothis wrote:
... and to handle the USB functionality with C#?
Windows or Linux?

An alternative to C# is Python :

I2C | CircuitPython Libraries on any Computer with MCP2221 | Adafruit Learning System

 

Have confirmed for the in-stock e-mail list of the Adafruit MCP2221A breakout board; will post when it's back in stock.

Adafruit MCP2221A Breakout - General Purpose USB to GPIO ADC I2C [Stemma QT / Qwiic] ID: 4471 - $6.50 : Adafruit Industries, Unique & fun DIY electronics and kits

 

MCP2221A is in PDIP.

MCP2221A - USB - USB Bridge

MCP2221A-I/P Microchip Technology | Mouser

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sothis wrote:
something super simple but something I need their help to fix.

if you buy your parts at digikey, they have tech reps that can help you cut through the fog, 

mouser may as well, as I’ve only used support at digikey.

you might try that avenue to see if it helps.

jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

gchapman wrote:
Windows or Linux?

 

An alternative to C# is Python :

Great information man, thank you! Doing this on Windows (WPF) and hoping I can port it to Mac at some point. Honestly I'm a bit reluctant to try Python cause I just spent 2 months teaching myself WPF, MVVM and C# (know C/C++). cool I'm behind already.

But, it doesn't look like we are hurting for good options here tho, huh? I'll dive more into this tomorrow.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

if you buy your parts at digikey, they have tech reps that can help you cut through the fog, 

mouser may as well, as I’ve only used support at digikey.

you might try that avenue to see if it helps.

 

This is solid info, Jim... I didn't even think about this!!! Thank you, I'll try it!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sothis wrote:
... MVVM ...
Model-View-ViewModel

Thanks for am now aware.

Sothis wrote:
I'm behind already.
Time is relative.

Consider continuing to roll (.NET, UWP, web app) as that knowledge enables embedded Windows 10 and Windows 10X on PC.

fyi, C# is on MCU and MPU including SAM9X35.

Sothis wrote:
But, it doesn't look like we are hurting for good options here tho, huh?
yes

 


The Model-View-ViewModel Pattern - Xamarin | Microsoft Docs

UWP - Universal Windows Platform

AT91SAM9X35 - Microprocessors

C# :

Home - GHI Electronics

TinyCLR OS

nanoframework – Making it easy to write code for embedded systems. (C#)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

gchapman, good looking out! My apologies for not getting bad sooner but I've been sick.

 

A little update:
I still have not gotten this to work, however, an associate at FTDI did step up and has been helping. He actually created a simple console app with an arduino to simplify the problem and he was able to pass data to and from the FT201. I then tried to write my own simple console app in C/C++ (since I don't use arduino), but couldn't get it to compile. All 13 of the errors were coming from their ftd2xx.lib driver file.

 

So my theory is that all of this has something to do with that I'm using VS2019, where maybe a standard library changed or something and it's causing the driver to fail. I sent FTDI my file and he told me they were on VS2017, so maybe this is why no one else seems to be having issues yet. He told me early yesterday that he was upgrading to VS2019 just so he could open my solution, which is pretty cool, but I haven't heard anything since. I assume that means they couldn't compile it either and are figuring out what is going on.

 

In the meantime though, I also decided to give myself some options and designed new boards around the Silicon Labs CP2112. I downloaded some example files and they compile so we're good on the driver front too! Hopefully within the next few days I'll have at least one working example!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Reading this whole thread I know you said you preferred I2C and hence the desire to use I2C-USB for the PC connect but the fact is that the rest of the world all use UART and UART-USB so there's a ton more devices to choose from and there's a wealth of knowledge about the things across the internet - they are also dirt cheap - encapsulated devices in line with USB cable and all the connectors usually run at about $0.99 on ebay (just search "ebay usb ttl" - possibly prefer "CH340" over "PL2303")

 

Rather than backing yourself into an I2C corner personally I'd put a bit effort into becoming UART savvy. The fact is that the UARTs in lower end AVRs are just about the simplest implementation of UART you'll find anywhere. About the only complication in the whole exercise is the baud rate calculation. (you can ignore pretty much everything else as the things default to 8N1 which is what the world tends to use these days anyway).

 

EDIT: by the way how do you handle the inbound data at the PC end anyway? Presumably the USB bridge enumerates as HID or something? But doesn't that mean this also requires specific PC software to be written too. Again an advantage of USB-UART is that because it enumerates as CDC-ACM (COM port) you don't need to write PC side software - just use a terminal that can open a COM port (or in Python / C# or whatever just use generic COM handling).

Last Edited: Fri. Jan 10, 2020 - 11:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson, great post. Thank you!

Honestly, I went with i2c just because it is what I know. When I made the jump to digital (AVR micros) about 5-6 years ago, I began using PCA95XX i2c IO expanders to handle buttons and LEDs too.

 

Based on the (great) advice I got in this thread, I went back and read Dean Camera's excellent USART tutorials. I was reading thinking "That's it? Oh ya, this is sooooo much easier". The problem there, besides the main board being designed, is that I forgot I am using the USART Rx input for MIDI. Now, this may not be a showstopper because they won't be used at the same time...we'd only have to manage that Rx line. Can multiple USART devices share pins in this manner?

 

clawson wrote:
by the way how do you handle the inbound data at the PC end anyway? Presumably the USB bridge enumerates as HID or something? But doesn't that mean this also requires specific PC software to be written too.

I dunno yet indecision. I haven't gotten that far cause of this read/write problem. crying I wanted it to be like any firmware update software you'd get with a printer or whatever, complete with the "Would you like to check for updates" and all that. The GUI "shell" is basically done and you can navigate from page to page, right now it can only connect to the device (but with a cool animation of data going back and forth!!!).

 

The FTDI chip enumerates as a custom class (or VCP) and you use their API to handle things. The Silicon Labs part enumerates as HID but again you have their API (very similar to the FTDI, btw) to handle the hard stuff. It's supposed to be as simple as this:
 

FT_HANDLE deviceHandle;
FT_STATUS status;
DWORD RxNumOfBytes;
DWORD NumOfBytesReceived;
char RxBuffer[256];

...Code to open device...

status = FT_Read(deviceHandle, RxBuffer, RxNumOfBytes, &NumOfBytesReceived);

...Error Check. Do stuff with RxBuffer data...

So, we'll see. 

Now clawson, before you scold me for making this way too hard on myself, know that I 110% agree with you.laugh

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Sothis wrote:
My apologies for not getting bad sooner but I've been sick.
No need as no problems.

May you heal well!

Glad there's motion on FTDI.

Sothis wrote:
In the meantime though, I also decided to give myself some options and designed new boards around the Silicon Labs CP2112.
Prolific Technology in Taiwan is popular; their earlier USB bridges can be sourced though couldn't locate a source for the new series (crystal-less)

 

PL23C3 USB HID to I²C Bridge Controller | Prolific USA | IC Design & Manufacturing

PL23C3 USB HID to I2C Bridge Controller (Prolific Technology HQ)

https://octopart.com/search?currency=USD&q=pl23&manufacturer_id=2648&start=0

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Rather than backing yourself into an I2C corner personally I'd put a bit effort into becoming UART savvy. 

Or maybe put an I2C-to-UART bridge on the board, and connect that to the PC with a USB-to-UART cable ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...