Microchip MCP2200
JohnC
Posts: 64
in Propeller 1
Has anyone used Microchip's USB/UART bridge to program a Propeller? It doesn't include a DTR pin, but RTS is there, and the prop tool seems to allow either pin to be used. What have I overlooked?
http://ww1.microchip.com/downloads/en/DeviceDoc/22228A.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/22228A.pdf
Comments
Is this known to be working - did you connect a terminal and confirm Echo on loop-back, and toggle of RTS ?
As Peter mentions, not the ideal choice for a new design.
Best mid-level USB-UART looks to be the new CP2102N, as cheap as $1.16/1k, and no Xtal needed.
Upgrades include 3MBd, Flash (re) Config, and a usable 3v3 regulator.
Derived from the EFM8UB1, so you can change to that if you need high volume customize.
JMG, I just noticed the checkbox in the prop tool preferences pane. Haven't tested it myself, and we've only ever sourced legit FTDI parts and used DTR. But I'm bothered by their driver / counterfeit part issues the last year or two, and also trying to shave the BOM where possible.
Digikey sells a $14 development board for the Microchip part. I'm going to bring in a couple and see what happens.
If you want to shave the BOM, why choose a higher priced part, that also needs a crystal ?
Order a CP2102N-EK from Digikey at the same time, and try that....
I'm staying away from malware vendors as much as possible.
There is no advantage to using the MCP2200 since it needs a crystal plus caps and this costs more and takes up more pcb real estate. Many times I have seen the crystal dwarf the IC it supports.
A coworker bought some counterfeit cables via Amazon, and they didn't work well under Linux. I believe that the issue was the lack of a unique id per chip. And we needed to use two cables per system. This was not the fault of FTDI's driver, it was the counterfeit chips. I do know that FTDI windows drivers try to identify counterfeit chips and malfunction.
Have you heard of a case where FTDI's driver caused problems with legitimate FTDI chips?
No, I don't know of any problems with genuine chips and FTDI drivers.
However it is unacceptable that a company can push software onto my computer that intentionally breaks my otherwise working system. This is malware, like the worst virus or trojan.
This is a gross abuse of the Windows driver certification and update system.
I think what is really annoying is that the humble serial port has been a part of computing since the beginning of time. About the simplest interface one could have. When all those "legacy" ports that were obsoleted by USB the serial interface should have been baked into the USB specification that replaced it.
There should not even be any need for FTDI drivers.
You do dream big don't you? I like your dream world though... it sounds nice.
Just now I'm reading that Apple wants to do away with the headphone jack. Soon that will become a dream as well I guess...
I've used various types of these chips from different vendors and they all have their quirks. When we were using CP210x parts a few years ago I believe that FTDI could support higher baud rates. Maybe this has changed, but that could be a technical reason to choose FTDI. (And their headquarters is in Glasgow which has got to count for something.)
Counterfeiting is a large problem, so I expect that we'll see a similar scenario play out elsewhere. I know that there's work being done on secure chip odometers both for counterfeit detection and other purposes.
For a while, FTDI were the leaders, but that changes...
* If you wanted High Speed USB to Serial, FTDI was the only game in town.
I think there are now faster HS USB UARTS from EXAR - XR2280x offer a faster 15MBd speed, and a fractional Baud control.
* SiLabs have some CP210x that need no added drivers, and their new CP2102N fixes some quirks.
Some of the older CP210x were OTP, and their sustained speed was less than FTDI.
The CP2102N is based on their 48MHz EFM8UB1, and is lower cost and Flash based and claims 3MBd Duplex.
* Fastest FS UART is from EXAR
* Dual UARTS in available smaller packages from SiLabs and Cypress, with Cypress CY7C6521x parts able to do not just UART, but also SPI and I2C.
Peter - that's nice. I worked on GNSS chips for quite a few years and besides TCXOs & antennas, serial comms (UART & I2C) was the one thing that caused the most trouble at customers. I think that Silicon Labs has supported this for years - e.g. CP2103.
I guess for embedded designs such as smartphones we can generally assume that XON/XOFF characters aren't lost or corrupted. But what if this isn't always the case? When we added this feature in GNSS hardware I put in various features in the the hope that they would enable recovery. One example is what if an XON character is lost or corrupted. Should the device that sent the XON resend based on the serial channel being idle for too long, or should the device that received the XOFF automatically reenable after a timeout? Both? Is this so rare that you end up resetting a subsystem in the event of a hang?
Obviously for an interactive terminal session the user would just hit ^S or ^Q if the terminal wasn't behaving as expected.
I looked at this data sheet and it didn't appear to address this sort of thing. For us this turned out to be a checklist item, and everyone used nCTS/nRTS for flow control. So much pressure to add 2-wire support just to get past the gatekeepers.
However the whole lockup problem with lost XON/XOFF could have been easily resolved by having a non-buffered enq control character continually sent during these periods asking for XON status. With this in mind it doesn't seem that it would be a problem if my system continually sent XON characters while the buffer was empty, as long as these characters are always handled by the hardware as soon as the character is received rather than buffered then there shouldn't be any problem. I guess I can always try this out.
Sure, but the prices mean you do not have to connect the Ethernet part
The XR21x parts can sustain quite close to 12M - something above 9MBd of average equivalent data in one direction is possible on the tests I've done. (ie pretty much the whole USB bandwidth)
I did uncover a bug in their drivers, where they crashed on large files of ~500k Bytes.
Not sure if they fixed it yet ?
The CP2102N data mentions XON/XOFF, and I think they are locally done via FIFO watermarks.
(as are the Hardware handshake lines)
You can set the XON/XOFF chars used, in the Flash config.
Could be worth testing that ?
I will get some of my dual row Prop plug style adaptors made with both the CP2102N and the XR21x parts to test them out.
As you say, whenever bytes are dropped it's usually a sign of something really wrong which should be addressed directly. You know how it is with the large ARM based systems though. People are often running reference designs (e.g Infineon/Intel or Qualcomm) and they have no idea where to look for the serial driver. If it weren't for good apps engineers nothing would work.
Now what can happen if this product is part of an industrial automation system and/or health-care supporting device? What happen if this device, at once, after an update, receives wrong data from the PC and thus alter its functioning? I think that in both cases industrial automation and health there is human life/injury involved.
Regardless of user approval or not you can legitimately not support counterfeit products, but not silently alter its functioning thus risking to produce material and physical damages.