element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Open Source Hardware
  • Technologies
  • More
Open Source Hardware
Blog Implementing Non-FTDI USB-to-UART Serial Interfaces
  • Blog
  • Forum
  • Documents
  • Events
  • Polls
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Open Source Hardware to participate - click to join for free!
  • Share
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: shabaz
  • Date Created: 1 Feb 2016 8:11 AM Date Created
  • Views 6672 views
  • Likes 12 likes
  • Comments 26 comments
  • uart-to-usb
  • exar
  • silicon_labs
  • microchip
  • silabs
  • exar_marketing
  • ftdigate
  • cypress_semiconductor
  • cypress
  • usb-to-uart
Related
Recommended

Implementing Non-FTDI USB-to-UART Serial Interfaces

shabaz
shabaz
1 Feb 2016

Introduction

It looks like the FTDI USB-Serial saga continues. A USB-Serial (also known as USB-to-UART) interface is used to connect up PCs to hardware devices using the USB port. FTDI was traditionally a manufacturer of the interface chips for this purpose.

 

This blog post examines how to connect up UART (serial) based devices to a PC. This feature was often relegated to a FT232 chip from FTDI. However nowadays many microcontrollers have built-in USB interfaces and this ancillary FTDI part is not needed.

 

For the scenarios where a dedicated USB Serial IC is needed, there are options other than FTDI parts. Nowadays there is some motivation to examine non-FTDI parts for this function.

An example design: the Arduino Uno doesn’t use an FTDI part – it has used an Atmel ATmega part for half a decade.

image

 

About eighteen months ago, FTDI did something that possibly could have caused people to claim for legal damages in many countries. It went against ethics according to some engineers, and as mentioned it was possibly actionable in law in certain countries. Manufacturers can be legally liable for damage that their products cause to other property. According to reports the FTDI driver deliberately 'bricked' (by which I mean rendered inoperable for non-technical users, requiring detailed procedures to revert back to the original state) the USB Serial interface in products that had a chip which was not manufactured under license from them but was attempting to use their driver. They did this by forcibly zeroising an EEPROM memory field in the user's product.

It is unknown how many devices were bricked, nor if FTDI offered to make good and provide compensation to users who had bricked products. FTDI's go-to guy for press releases was asked several times to comment last month but he refused.

 

FTDI's Current Solution

FTDI eventually backtracked to a degree and their recent drivers no longer perform such EEPROM memory overwriting. But, it seems that their solution is to make their driver generate 'fake' serial data which spells out 'NON GENUINE DEVICE FOUND'. This data is unobservable to a normal non-technical user of products.  The user may just experience unusual symptoms, or complete failure of their product. The unusual symptoms will vary from product to product. Note that non-genuine could mean a fake part or a clean room design. Also note that reverse-engineering can sometimes be legal.

The subtle difference between the situation now and the situation eighteen months ago is that the product can be effectively rendered temporarily unusable by FTDI without modifying EEPROM contents. By not modifying EEPROM contents any longer perhaps FTDI are trying to avoid liability but in my opinion it is still questionable if this is responsible practice nor am I sure on the legality.

 

Who Suffers?

There is a school of thought that what FTDI is doing is a valid thing to do - after all, they are protecting their investment and if a product fails to work with the new drivers, the user has some rights to take the product back to the manufacturer. The product manufacturer can then compensate the user, and then seek liability from the distributor of the USB-serial chip that they used. In theory everyone gets compensated along this chain apart from the manufacturer of the supposedly fake parts. In practice not all loss is recoverable even if everyone along the chain pays what they legally owe. Pure economic loss is not legally recoverable in some countries for example. Nor is it always possible to prove causation. If you lose a potential 100-million-dollar deal due to people hearing about your flaky product that had a ‘fake’ FTDI chip inside it, it will be hard to recover the 100-million dollars from your supplier.

Furthermore in practice the (non-technical) user suffers because the user was not aware of the origins of the chip (which forms just a fraction of the end product), nor whether the chip was produced under license from FTDI or not.

image

 

Some users could throw out their product thus suffering some loss if their product was outside the warranty period and they had naturally assumed some part had reached the end of its life.

This is not just theoretical. Another manufacturer of USB-serial chips, Prolific, had a slightly similar issue in the past with their PL2303 IC. They upgraded their driver, rendering some products inoperable. It is unknown if it was deliberate like FTDI. One of my USB-Serial adapters was from a well-known high-street store, and it contained what I believed to be a genuine PL2303 part. I had no reason to believe (and I still don't) that the high-street store's supplier had used a manufacturer that would deliberately source parts that were non-genuine Prolific parts. Without further information I believe it had been accidental. The workaround of modifying Windows '.inf' files was complex - definitely not something that non-technical users may wish to attempt.

There is also the possibility that more serious harm could occur if a product behaved unexpectedly. FTDI parts are used in vehicle on-board diagnostic (OBD) tools; imagine if someone relied on erratic or incorrect data egressing from the software for such a device to adjust their vehicle. FTDI are in the unfortunate position that they won’t always know about the end product that their chip is used for. However they are not the only ones.

 

I was happy to know an Engineering Director who committed to removing (and did remove) licensing lock limits in a communications product simply because he couldn’t guarantee that the lock might prevent communications for a user during a hypothetical emergency (public emergency for example) for want of a license fee that was late. It was better to trust that the vast majority of users will be honest and at some stage pay up, and take the hit that some won’t, and sleep better at night knowing your product will function in emergencies regardless of whether the purchaser forgot to pay the license fee or not. Not everything in life has to be about revenue policing.

There is a suggestion that the FTDI 'NON GENUINE DEVICE FOUND' problem can be avoided in new designs by engineers not using FTDI USB-serial chips inside products - then there is no risk of their product containing a non-genuine FTDI part by accident.

 

When and Why is Reverse Engineering Allowed for Interoperability?

It could be considered that possibly ‘fake’ or ‘clean room design’ manufacturers should write their own drivers and that therefore FTDI are in their right to do whatever they desire to prevent interoperability. However at the same time it is worth noting is that in Europe it has been legal for a very long time to have interoperability at software interfaces, and in certain circumstances it is even legal to reverse engineer existing software to achieve this aim under Europe’s Software Directive. For FTDI to take the stance to send data strings containing ‘NON GENUINE DEVICE FOUND’ means they are deliberately preventing interoperability at a particular interface which can be legal. But it may (this is just a personal opinion – seek legal advice) also allow people to legitimately have the right to continue to examine and reverse engineer FTDI parts in order to continue to achieve interoperability in the future with clean room designs that interoperate at that boundary. Why is this important? Imagine a product with an embedded copy of Windows running inside it. It could be a high-end test instrument costing tens of thousands of dollars. And its accessories might all contain FTDI parts which connect to the USB interfaces on the test tool. Ten years from now either FTDI and/or the product manufacturer may have moved on to other things or the products and software may no longer be under any support, and users may wish to connect third party or custom accessories because the original accessories are no longer fit for purpose, or to resolve bugs in the hardware discovered long after FTDI ceases to exist. Many parts including FTDI parts have errata. If it is illegal to interoperate using third party devices, the entire test instrument investment may be lost. This might seem a contrived example but the point is that the future cannot always be accurately predicted.

 

What can we do?

We can't change a mindset easily it appears. Eighteen months on the repercussions are still being felt and fake data is being generated by FTDI drivers when they detect (in FTDI's opinion) non-'genuine' devices. But we can design USB to Serial interfaces with the wealth of other interesting parts if we wish to.

 

What other USB Serial Interface Parts are Available?

Four choices which require no crystal and the bare minimum parts (usually just a couple of capacitors) were investigated and their attributes are listed in the table further below and compared with the FT231X chip used in FTDI’s Nero project. Although the investigation is merely a datasheet comparison, it would be great to hear people’s experiences on these and other parts. To kick off, I have tried the MCP2221. I also intend to try the Cypress part in the table below.

 

The Microchip MCP2221 is a nice part as can be seen from the table. It is available in prototype-friendly packages (including DIP!) and is extremely easy to use. For an example MCP2221 project see here.

Here it is being used with the BeagleBone Black..

image

 

The CP2102 from Silicon Labs is another option. It works well and is therefore extremely popular.

image

 

A very interesting device appears to be Cypress CY7C65213 - it looks ideal for modern applications where the device can negotiate higher current for battery charging. It is available in a fairly easy-to-prototype SSOP package as well as QFN for compactness. The Exar XR21B1421 has built-in 15kV ESD protection and supports very high baud rates.

 

#Feature

Microchip

MCP2221

Silicon Labs

CP2102

Cypress

CY7C65213

Exar

XR21B1421

FTDI

FT231X

1MemoryYes, for configuration1kByte 100,000 write cycles512Byte 100,000 write cyclesOTP2kByte 2,000 write cycles
2Baud Rate300-1M300-1M300-3M300-12M300-3M
3Current Consumption13mA20mA13mA13mA8mA
4Suspend Consumption46uA80uA5uA850uA125uA
5USB Impedance MatchingBuilt-inBuilt-inBuilt-inBuilt-inRequires external resistors and capacitors
6Internal LDOYes – 3.3V unclear if available to external circuitsYes – 3VYes but not available to external circuitsYes – 3.3V unclear if available to external circuitsYes – 3.3V 50mA output capability
7Hardware Flow Control PinsNoYesYesYesYes
8General Purpose I/OYes - 4NoYes - 8Yes – 10 (shared with Flow Control pins)Yes - 4
9USB Battery Charger DetectionNoNoYes, SDP, CDP, DCPNoYes, DCP
10Wake up time from Suspend65ms25us20ms
11ESD Protection (HBM)4kVRequires TVS diodes2.2kV15kV2kV
12Additional Feature HighlightsUSB HID capability, Built-in I2C Master, Built-in ADC (3 channel), DAC and InterruptCan use pin-compatible CP2109 with PROM for lower cost production devicesSupports PHDC (Personal Healthcare Device Class)USB HID capabilityUART inversion capability
131.8V I/O SupportYesNo, requires external level convertersYesYesYes
14Price in GBP each (qty of 100)1.061.70

1.35

(0.94 for 2000)

1.68

1.37

(1.00 for 1000)

15Packages availableDIP-14, SOIC-14, TSSOP-14, QFN-16QFN-28SSOP-28, QFN-32QFN-24, QFN-28SSOP-20, QFN-20

 

Note: The data in the table is believed to be reasonably accurate but please check the product datasheets before implementing a design!

 

Summary

Depending on requirements there are some great options available. For hobbyists the MCP2221 comes in easy-to-use packages and has a lot of interesting features to save time and money as well as USB HID which is excellent to see. It is a great all-round part. For commercial designs it is available in extremely compact packages and at low cost. For modern designs with extremely low standby current (this would make it ideal for connecting to mobile phone handsets!) and ultra-fast wake up times, high density of digital I/O as well as the ability to support charge current negotiation, the Cypress CY7C65213 could be a very good option.

  • Sign in to reply

Top Comments

  • johnbeetem
    johnbeetem over 9 years ago +6
    Personally, I think it's stupid for FTDI to do this. While I understand that they are legitimately upset at counterfeit chips and want to do something to stop them, the reality is that most end users aren…
  • ntewinkel
    ntewinkel over 9 years ago +5
    Great writeup, Shabaz! I agree, if any client asked me I would highly recommend staying away from FTDI parts - the risk of a product turning into a (support / return / customer loss) nightmare is much…
  • mcb1
    mcb1 over 9 years ago +4
    Very nice write-up. I do agree that support long after companies move on is going to be an issue. Many embedded devices could still be running 25-30 years from now. If you think that is a fallacy then…
  • shabaz
    shabaz over 8 years ago

    Looks like there will be a Cypress CY7C65213 dev-kitCypress CY7C65213 dev-kit available soon.

    Just to keep the info easy to find: Microchip MCP2221 notes: Building a USB UART Serial Adapter

    Microchip MCP2221 gerber files: HAL-CAM 9001 - Building a Power over Ethernet (PoE) Supply  (discussed in the comments section).

     

    I'm looking forward to trying the Cypress part, it has some cool features and 1.8V support.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • shabaz
    shabaz over 9 years ago in reply to mcb1

    Hi Mark,

     

    I think a different manufacturer (or even an individual) providing a driver with the same VID would make FTDI's position super interesting : )

    (Putting aside the issue of whether refusing to work or inserting fake data is an appropriate thing to do, and just focussing on whether it is legal to use the same VID or VID/PID or not):

     

    It sounds like FTDI believe that because they paid for a VID, no-one else can use their VID or VID/PID combination. But I can't see under what rule that could be true.

     

    I think purchasing a VID provides the benefit of being able to use a USB-IF logo, and also the benefit of knowing that the same VID won't be sold to another customer by USB-IF.

    However USB-IF isn't the only source of VIDs, and if a VID was copied, I can't see what law that would contravene. VIDs cannot be used to prevent interoperability (Directive 2009/24/EC explicitly distinguishes the parts of software needed for connecting to hardware and affords people rights to be able to reverse engineer to achieve interoperability).

     

    Another interesting thing could be, what if an individual (one of us!) declared all remaining VIDs their own? That person didn't have to purchase them from USB-IF. In that scenario, would USB-IF close their VID-issuing operations overnight, or would they continue to issue VIDs knowing that they now overlap? In that case, by continuing FTDI's line of thinking, the tables would have turned and USB-IF would be 'stealing' VIDs from us and passing them off as their own. A silly situation.

     

    I agree it would totally weaken FTDI's argument further if the manufacturers did provide a driver as you say. It would be interesting if such provided drivers still used the same VID/PID! many users may likely throw away the CD (since many people like using the latest drivers and often allow Windows to automatically find the driver online instead) and FTDI's Windows driver would inevitably get used. I wonder how FTDI's argument would then change.. since they can't insist other manufacturers buy their VIDs from USB-IF.

     

    Anyway, I've decided to just avoid FTDI parts, makes life easier and I feel I'm supporting those individuals who wrongly had their hardware break on them, by voting with my feet and putting in effort to use different vendor parts. It is always a good thing to be able to second-source anyway, and in this case a slight hardware modification to use a different vendor to FTDI is as close to a second-source as possible in this case.

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • mcb1
    mcb1 over 9 years ago in reply to shabaz

    It has been established that it is not mandatory to pay USB-IF to obtain a VID/PID

    Without a recognised VID/PID, the automatic driver install would be impossible.

     

    This doesn't mean that the manufacturer can't simply supply the driver, or let windows default to a modem device.

     

    However it does seem a very high price to pay for a number.

    Mark

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • shabaz
    shabaz over 9 years ago in reply to clem57

    Hi clem57

     

    FTDI are unhappy about a few things it seems.

    (1) FTDI don't like seeing counterfeits

    (2) FTDI don't like seeing parts masquerading as FTDI parts

    (3) FTDI don't like people 'stealing' numbers - VID/PID

     

    From what I can tell, even FTDI acknowledge that the chips they are concerned about are not silicon copies, rather they are clean room designs. The interface is copied but for the purposes of interoperability this is not illegal under the European Software Directive. So they don't sound like counterfeits to me.

     

    FTDI don't like chips branded FTDI when they are not FTDI chips. Yet no-one sees the branding, since it is buried in a molded USB connector often. You'd have to hack away with a knife to see this. There is an interesting thought experiment. What if the FTDI logo was sanded off prior to molding it into a USB connector? Or what if the engraved marking was carefully filled in with epoxy first, and then painted over? How is this different for an end user compared with encasing it in plastic with a mold? What if the 'FTDI' characters were needed as part of the machining process (I agree this is implausible, but this is a thought experiment and I can see the situation where, say, concentric squares were a brand logo, and yet such etchings were needed during machining), and then are subsequently polished off by the chip manufacturer or the manufacturer of the end product? If we intentionally take the ridiculous situation to the extreme then what if some unique toroid transformer design needed this style of etching on the surface as part of the manufacturing process, but was then molded over:

    image

    What if tomorrow Chanel decides to get into the transformer business.. could they argue that such an etching was masquerading of the Chanel logo?

     

    Finally, can a number actually be stolen? It has been established that it is not mandatory to pay USB-IF to obtain a VID/PID, provided that the USB-IF logos are not used on the product.

    (USB-IF logos, shrunk for fair use)

    image

    FTDI might argue that a VID/PID combination is sufficient to be equivalent to branding a product as FTDI. Yet for interoperability purposes under the Software Directive this would not be the case. Otherwise, every manufacturer could prevent software interoperability by stating that any header value in their API content was an identifier of their brand. Even if some fictitious API content explicitly had four consecutive numbers indicating 'FTDI' in ASCII, that would still not prevent other manufacturers from using it for interoperability.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • clem57
    clem57 over 9 years ago in reply to mcb1

    That story on $2k for 1 vid so you can use just one unique pid is ludicrous money making scheme by USB-ORG!image

    Clem

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube