This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1230E6PM: TM4C VCP Driver port

Part Number: TM4C1230E6PM

Folks,

Our customer is asking:

Do you know of any drivers that ported the VCP driver from the (SiLabs) CP21xx to the TM4C?  

They would like to control this device via USB like the AM57 does in their existing products.

TY,

CY

  • Hi Chris,

    Aren't those usually UART to USB chips? USB into the SiLabs FTDI, and then it translates it to UART to communicate with a micro? That's what I recall from some MSP430-based EVMs. If so, we don't really have any specific drivers for that since usually if a customer wants USB w/ a TM4C123x device they just pick another device which has USB functionality and leverage our driverlib/usblib. I am not sure their added cost would justify their approach but that said there shouldn't be anything on a technical side preventing them from going that route.
  • Thanks Ralph,
    I think you have a good point. These are generally UART to USB conversion ICs. I guess the remaining underlying question is this: do we have similar VCP (Virtual COM Port) drivers from TivaWare, for instance, that would suffice from a TM4C replacement perspective. That way, the customer could still control the TM4C device is the same way they currently do like the AM57xx does in their existing products. I guess if we can confirm that, which I believe the answer is yes, we'd be able to offer that as an option, potentially.
    LMK if this makes sense.
    -Chris
  • Hello Chris,

    I am fairly certain our USB CDC example enumerated explicitly as a VCP up until Windows 10 changes the whole USB architecture, so that's what I would point them towards as far as out of the box examples go. If it enumerates right on a LaunchPad for them, then they should be good to go with using the CDC example.

    We don't have a specific example labelled as VCP, but again as far as I can tell the CDC example should fit that role.

    As long as Windows (or their choice of other OS) recognizes the TM4C CDC as equivalent to their current VCP setup then it should be fine.
  • Thanks Ralph, appreciate your quick and insightful input today. I'll run this past the customer to see if they agree with our combined thought process on this one. For now, case close and thanks again. Rock on man!

    -Chris
  • TI Friends and Family,

    We all pretty much agree that this certainly can be done, but perhaps just with a little bit of work. I’m assuming the aforementioned driver is for the SiLabs solution, but should be able to be followed and then modified to support the TM4C Tiva implementation. Even if there is a Linux piece to this whole equation, in my mind, that should effectively still be the same between either SiLabs or TI since that piece would be effectively abstracted - assuming of course that the necessary VCP/CDC drivers are operable.

    That being said, any additional comments or input from TI directly or from the general development community are appreciated and welcomed - in the event someone has already done this?

    TY,
    CY
  • Hello Chris,

    If the driver is for SiLabs, then it sounds like it would be the Linux driver between the SiLabs part and Linux? If so, then it would be a bit complex as while we provide Windows drivers, we don't really have Linux drivers nor the Linux knowledge to support making one. There are a few E2E posts on the topic I believe and I could dig those up if that ends up being useful, but if it's linking TM4C CDC port to Linux as a VCP via a driver, that doesn't really exist now and will be a challenge to implement. I think to link back to what you were saying, I don't think that can be efficiently abstracted as we don't have a functional Linux CDC driver to provide.
  • Hey Ralph,
    Appreciate your detailed input. What they potentially have is a Tiva TM4C as the Host controller communicating to the CP2110 as the Slave. Therefore we all agree that the Linux driver can be mimic'd and adapted to the appropriate Tivaware host commands. They are going to start to work with the dev board and investigate the feasibility. So while we might have some follow-up later on, after we dig in a little deeper, I think we are all set for the time being. Case closed.
    Thanks man,
    Chris
  • May it be noted,  "BEWARE"  whenever: Client, Boss, Wife (or esteemed GF) notes,  "Task as Easy - NOT too demanding..."

    Devil resides (often) in "Not too obvious details" - which (too often) are "missed"  (from 50,000 feet)  and which become "painfully evident" when at,  "Ground Zero!"      (NOT to ask - HOW I know...)

  • CB1 you are wise beyond your years! Yes indeed the devil is in the details. We do at least agree on how to proceed with a "proof of concept/feasibility" stage at this point. There will be bumps in the road for sure. That's why engineers are for the most part still gainfully employed across the world!

    Regards,
    Chris
  • It is assumed that you intended, "Dog Years" (as a "wisdom measurement unit") is that not so, Chris?

    What's being attempted - to my mind - Does make sense!    That said - the identification of (potential) "Key/Critical Roadblocks" - sooner rather than later - likely separates, "men from boyz."    And likely "guards against"  the  always (painful),  "Failed Use of Resources..."

    It IS - bit "hard to hear" - over the corporate hounds'  (there are two)  "joyful communicating."

  • Too funny, a 'wisdom unit of time measurement'...I like that. Appreciate your input as well, Sir! The best project management practices outline exactly what you suggested. Spend the time upfront, do the due diligence effort, create proper requirements and establish a practical development schedule. Once again, appreciate your input and wise words.

    -Chris
  • How kind of you, Sir!     Crack (mostly millennial) staff - appreciate as well - yet their (none too disguised) eye-rolls - are - occasionally detected...

    My primary role (aside from (lurking) here) is to insure that the "usual" design pitfalls are anticipated - and guard-banded - so that "youthful energy & focus" (minus great experience) becomes fully & properly "deployed & leveraged" - and (morale-sapping) "miscues/roadblocks" - are eliminated.     (or at least - significantly nulled - and/or bypassed...)      (maybe)