Slashdot Mirror

I hope FTDI continues to block counterfeit devices.
This will alert buyers who then can demand refunds, or sue the vendors who sold them low quality fakes.

Want guaranteed genuine chips? FTDI runs an online shop, reasonably priced too.
http://www.ftdichip.com/

I for one was burned once with a fake Prolific PL2302 that crashes frequently and reproducibly. Never again.

FTDI is abusing customers who attempted to purchase their product in good faith, and that's why this is both a criminal act and also a very stupid idea.

Criminal? Really? What laws are being broken exactly? Have you read the license for these drivers? FTDI seems to be making an effort to cover themselves legally with the license and it would need to be tested in court to see how successful they are. Not every court will accept every license or terms of use conditions but few people are going to spend the money to take FTDI to court over this.

An interesting section copied from their license below, see http://www.ftdichip.com/Driver... :

" 1.5 The Software will not function properly on or with a component that is not a Genuine FTDI Component. Use of the Software as a driver for, or installation of the Software onto, a component that is not a Genuine FTDI Component, including without limitation counterfeit components, MAY IRRETRIEVABLY DAMAGE THAT COMPONENT. It is the Licensee's responsibility to make sure that all chips it installs the Software on, or uses the Software as a driver for, are Genuine FTDI Components. If in doubt then contact the Licensor. "

This isn't a bug. A poster on the EEVblog forums reverse engineered their driver and posted this.

The naming of the function and variables is their own, but they've written a function which is called unconditionally and has no purpose whatsoever with respect to their own chips. It is written such that it cannot affect their own chips. This is clearly not a bug, otherwise, you'd need to argue they intended to set the PID of their own chips to 0. The only logical explanation for this code is to overwrite the EEPROM of chips which were not manufactured by them. Pretty clear cut case of destruction of property (which coincidentally, under the law, includes unwanted alterations, not simply smashing with a hammer).

Combine that with their official statement and it's pretty slam dunk:

FTDI Chip is committed to taking appropriate measures to protect our customers from the adverse impacts caused by counterfeiting of FTDI Chip devices. Many of these devices resemble FTDI Chip markings which may lead the customer to believe they are genuine. FTDI Chip has established a proactive and global process aimed at detecting and deterring such counterfeit activity.

Regardless of whether they were permanently 'bricked' or not, your initial comment was about 'technologically ignorant users' somehow 'requiring' them to support the fake product - the driver can simply refuse to work with the device.

Now, however, you take that 'technically ignorant user' who went out and bought say 3 x 4GB USB dongles that happened to have fake FTDI chips in them, unaware of that fact of course, who then copies his business critical data, say 3 years worth of work, onto all 3 of them (for safe keeping)... then his machine auto-updates his driver (because, again, he's a technically ignorant user) and suddenly he can't get to his data... in fact, again, technically ignorant, he tries all 3 dongles (if the first one fails, try the backup(s) right?).

Now, he can't even take them to another machine that maybe didn't get the driver update, or a Linux machine without the proprietary FTDI driver... sure, it's 'fixable' by him say paying an IT geek (a non-technically-ignorant person) to reprogram the USB ID, but that's a cost he is incurring because of what FTDI did to his devices. And that isn't to mention that perhaps he needed that data to bid on a potential $million contract with someone, on a deadline that he's now missed because of what FTDI did to 'damage' his devices.

He most certainly, if it can be proven that FTDI is *deliberately* breaking (even temporarily) the devices in question, has a good case for damages from FTDI.

Actually, what I said was:

I'll say it again. FTDI went about this the wrong way, but just as ignorance of the law isn't a defense, a consumer's ignorance of technology shouldn't require a manufacturer to support those who steal their designs and profit from them.

Since (based on what you wrote) you misunderstood my statement, I'll explain. I make two points:
1. FTDI blundered badly (whether that bites them with legal action, we'll have to see) by having their driver reset the PIDs of counterfeited FTD232 chips to '0'.
2. Many folks posting on this thread (not you, BTW) seem to be making the argument that FTDI should somehow suck it up and support counterfeited chips with their drivers. That isn't the case, IMHO. Caveat emptor.

You pointed out that:

Now, however, you take that 'technically ignorant user' who went out and bought say 3 x 4GB USB dongles that happened to have fake FTDI chips in them, unaware of that fact of course, who then copies his business critical data, say 3 years worth of work, onto all 3 of them (for safe keeping)... then his machine auto-updates his driver (because, again, he's a technically ignorant user) and suddenly he can't get to his data... in fact, again, technically ignorant, he tries all 3 dongles (if the first one fails, try the backup(s) right?)

[emphasis added]

As TFA (and much of the discussion here) points out, the chip in question (FTD232) is a USB/Serial converter (UART) and isn't used for flash drives -- nor is the driver, so your example isn't realistic. Sure, modifying the PID will inconvenience users, but it doesn't put anyone's data at risk.

The updated driver modified the PID setting (to a value of '0') on hardware not manufactured by FTDI that was using FTDI's assigned VID/PID.

One more time: I do not think that FTDI did the right thing and I suspect it will come back to bite them in the ass. But FTDI did not damage anyone's hardware.

Ooh, it gets better. They've published an official statement all but explicitly stating they're sabotaging other chips. (Note, I said all but. They don't say how they're detecting them or what their "proactive and global process" is.)

FTDI Chip is committed to taking appropriate measures to protect our customers from the adverse impacts caused by counterfeiting of FTDI Chip devices. Many of these devices resemble FTDI Chip markings which may lead the customer to believe they are genuine. FTDI Chip has established a proactive and global process aimed at detecting and deterring such counterfeit activity.

It looks like they are trying to hide behind their EULA, which says that "Use of the Software as a driver for a component that is not a Genuine FTDI Component MAY IRRETRIEVABLY DAMAGE THAT COMPONENT." But there are reports that this new driver is being delivered via Windows Update, which presumably doesn't show you this EULA.

Microsoft would be wise to pull this update.

Here you go http://www.obdev.at/products/vusb/index.html
vusb is a USB stack for the AVR line of chips. They even have a diagram of how to wire it up. You could also just use any number of micros that come with a USB interface.
As to the number of parts needed to blink an LED using the USB port... You could do it really simply with this http://www.ftdichip.com/Products/ICs/FT232R.htm

This isn't a recent change; component distributors such as mecanique (see https://web.archive.org/web/20070825070852/http://www.mecanique.co.uk/products/usb/pid.html) used to on-sell blocks of PIDs from their VID many years ago, but the USB-IF started cracking down a number of years ago. Likewise, voti.nl was threatened with legal action (see http://www.voti.nl/shop/catalog.html?USB-PID-10).

For some projects, you can obtain a PID from the manufacturer of a USB chip (eg http://www.ftdichip.com/Support/Knowledgebase/caniuseftdisvidformypr.htm), but this generally means using the manufacturer supplied driver, and doesn't really help if you want to customize things more.

There doesn't seem to be a reasonable solution for small runs beyond the prototype phase. So in effect the USB-IF is motivating hobbyists to simply reuse VID/PID pairs from similar devices, which is only going to lead to compatibility headaches in the future.

I can understand that they wish to have an orderly process so that operating systems can have automatic device recognition and driver installation, but it is short-sighted not to provide an opportunity to licence a much smaller address space at a reasonable cost.

(For futher information, the prototype VID is 0x6666 and many known VID/PID pairs in http://www.linux-usb.org/usb.ids)

yeah yeah you keep telling yourself that.

http://www.ftdichip.com/Products/ICs/FT800.html this into an atmel?

I think there wold be a better market for this thing as providing io to raspberry pi projects rather than arduino.. it's a rather ridiculously mismatched with an 8 bit atmel.. sure you can have 2000 sprites but uh are you going to have ram on the arduino to keep tabs on even where they are?

Or this...
http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm

On that topic you may appreciate this: http://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_DB9-USB-RS232.pdf One of my students sent this through a few weeks ago. Very interesting and above all quick solution to the lack of serial problem on new laptops. I work at an industrial plant built in the 60s. Keeping old laptops going, and cheap RS232->USB converters working is becoming a full time job. For an interface that is still very widely used it was made obsolete all too quickly.

> Oh, so we just have to wait a couple of weeks for some teenager to crack it. Awesome.

If it's hardware-based 2048-bit encryption, it's not going to be hacked in a couple of weeks. CSS encryption used on DVDs was a complete joke of an encryption standard, and everyone knew it at the time. It was security by obscurity, and almost worked for a couple of years.

When it comes to military-grade hardware encryption, Motorola doesn't screw around.

If Motorola doesn't back down, realistically the best prospect for reflashing a DroidX is a homebrew JTAG programmer built with a FTDI 2232H on a breakout board -- http://ftdichip.com/Products/FT2232H.htm

About $30 worth of parts (plus shipping) from Digikey -- http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=768-1030-ND

God, talk about the Law of Unintended Consequences -- savor the irony if Motorola becomes the company that makes JTAG a household word :D

Apple dropped the floppy in 1998, that was 12 years ago. Even the comments from PC users so far, right here on Slashdot, seems to indicate that a lot of technical people haven't used a floppy disk in nearly a decade.

The floppy is dead, and so are the parallel port, the serial ports* and Adobe Flash**.

* FTDI makes reliable USB-to-serial cables with drivers for the three main operating systems so stop bitching about the lack of serial ports on new computers.
** Mwahahaha!

A lot of boards these days are populated with FTDI FT232 chips or comparable. http://www.ftdichip.com/Products/FT232BM.htm Usually using a separate 'console' USB port separate from the host/device ports provided in addition. Pretty much every desktop system comes with FT232 drivers, so all that's needed is a cable, or possibly an INF file or similar if they use a nonstandard MID/PID. Eventually we'll probably see these on-chip on SoC devices that already have USB support. But RS232E is quite practical and easy to troubleshoot, and I don't know any embedded engineer or board designer who doesn't know how to wire that up. I agree TFTP and flashing from a USB stick is nice, but a console is great to figure out why that might be failing, to see kernel panics, etc. Of course, a JTAG adapter and debugger that can talk to it is a huge time saver when it comes to actually fixing boot loader, flashing, or kernel bugs...

I don't have firsthand experience; but FTDI says that there are drivers for its USB/serial products for FreeBSD. FTDI based usb/serial converters are reasonably common. Both Sparkfun and Adafruit industries use them a lot with their arduino related products.

Reports also suggest that the PL-2303 is supported in FreeBSD. You can get an adapter based on it from Sparkfun.

It's a nuisance not to be able to just grab anything; but it looks like you do have options.

They now give us cheap usb=serial adapters with the things. They have crappy drivers that always change the port#, but they work.

The latest drivers let you change the port number with Device Manager.

a: For the wired version: Support for Power over Ethernet. This way, separate power isn't needed in many installations.

The development board and DCME itself break out pins from the PHY for this purpose. No problems here. You just need to hook up something like a MAX5941 and you're set. (I haven't been interested in this yet, tho.)

b: A single USB port for both versions

The FTDI FT232BM is what you're looking for. RS232 to USB, with drivers for Windows, Mac, and a linux usbserial driver to boot. $5/chip in one-offs. Great chip for interfacing with any serial device, microcontroller, etc. Mouser sells this chip on a nice backpack board with all the external logic you need -- just connect the power, tx, and rx, and you're done!

Of course, this won't get you USB HOST (which is probably what you want), so in that case you may have to pursue another design.

The fact that the author used a USB game pad as the electronic base of his device brings up an issue which increasingly plagues electronics hobbyists... Manufacturers are beginning to see many useful protocols (such as RS232) as obsolete and completely remove support for them from their products. While the average American consumer, who uses arbitrary metrics and units-of-measurement-become-buzzwords (megapixels... gigahertz... etc.) to judge the worth of a device, would not care much about seeing those ugly trapezoidal plugs disappear from the back of their computers, it presents a huge problem for us hobbyists who rely on good-old '232 and similar "old" interfaces for easy communication with a computer. Anyone who's ever written (or tried to write) USB interface code knows that's Hell to work with. Fortunately, though, there are solutions... including handy interface chips which handle all the nasty USB work and provide a simple asynchronous serial interface on the project end. However, I still will never buy a motherboard without RS232!

Also, many projects rely on the cypress EZ-USB too, some of which even ended-up on sourceforge.

Also, many projects rely on the cypress EZ-USB too, some of which even ended-up on sourceforge.

When we bought 8 USB interface chips from FTDI via our local distributor, we got 8 id's for free [FT232BM (serial) or FT245BM (parallel)]. And there are drivers for many os-es for. I'm a member of an association for amateur research for embedded systems however.

When we bought 8 USB interface chips from FTDI via our local distributor, we got 8 id's for free [FT232BM (serial) or FT245BM (parallel)]. And there are drivers for many os-es for. I'm a member of an association for amateur research for embedded systems however.

I'd recommend buying a USB-RS232 chip.
USB is USB - just a lot of specs to follow and nothing innovative.
It gives you time to concentrate on 'your own' hardware, which after all is what you want.
You get to use the vendors device drivers and VID, and get a couple of PIDs for your own use.

My company has worked quite a bit with FTDI.
They make reliable chips (AFAIKT), and give excellent support.

The Z8F640x z8encore devel kit only costs $50 (check the future active page) and comes with an IDE which lets you play with both C and ASM. The CPU is of the most basic variety so don't expect running linux on the board but you will feel at home having done Z80 coursework.

There are 2 kits for the ez80acclaim (eZ80F91 and eZ80F92) which both come with ethernet sockets. They cost 199 and 399 each. Again, these are microcontroller boards so they might not be suited for your needs.

All things considered, a $50 investment is not bad for a devel board + software, especially if you want to experiment with embedded applications. You might also want to add one of these for added fun (talk to your microcontroller board over USB 1.1).

On the other hand, if you want to use linux/uclinux on a devel board, embedded cpus like arm, xscale (intel) and coldfire (motorola) come to mind, but an off the shelf devel board will cost you a lot more. In any case, check here.

I just treated it as a matter of subsystems.

The system core is currently based on a 20MHz PIC which reads and encodes the CCD image data and also controls the position of the pan and tilt sub-micro servos with regular 1.5-2.5ms pulse trains. The frequency of the pulse trains isn't critical (PPM/PCM radio control systems are typically using between 50 and 60 frames per second) so it only needs to update the servos ocassionally. I figured it was a lot easier to use off-the-self servos instead of trying to build my own gear trains and position encoders.

The system core then only needs to talk to the USB comms hardware. This is currently an FTDI FT232BM which takes care of all the USB interfacing, protocols and packetizing the traffic. I don't need to worry about the USB side of it at all. The core CPU only needs to encapsulate the image and status information into different packet types (packets in the context of my own serial protocol) which are then extracted for use by the application on the Host System which just thinks of the device a serial port.

Once I've chosen the appropriate 10/100Base-T chip or module, it should be a simple matter to change the core PIC's comms software to provide the status and image information as separate entities, particularly if I go for a module which has a HTTP server built in.

Hope this helps you with your project, too!

I just treated it as a matter of subsystems.

The system core is currently based on a 20MHz PIC which reads and encodes the CCD image data and also controls the position of the pan and tilt sub-micro servos with regular 1.5-2.5ms pulse trains. The frequency of the pulse trains isn't critical (PPM/PCM radio control systems are typically using between 50 and 60 frames per second) so it only needs to update the servos ocassionally. I figured it was a lot easier to use off-the-self servos instead of trying to build my own gear trains and position encoders.

The system core then only needs to talk to the USB comms hardware. This is currently an FTDI FT232BM which takes care of all the USB interfacing, protocols and packetizing the traffic. I don't need to worry about the USB side of it at all. The core CPU only needs to encapsulate the image and status information into different packet types (packets in the context of my own serial protocol) which are then extracted for use by the application on the Host System which just thinks of the device a serial port.

Once I've chosen the appropriate 10/100Base-T chip or module, it should be a simple matter to change the core PIC's comms software to provide the status and image information as separate entities, particularly if I go for a module which has a HTTP server built in.

Hope this helps you with your project, too!

are you an engineer that writes software or a computer science major who does electrical engineering

To some extent, I would fall into the latter category. My degree has "computer science" printed on it, but I've done custom hardware to solve some problems. When we got some security cameras in that didn't provide for computer control, I reverse-engineered the bundled remote control (just a bunch of switches and resistors, really) and built a replacement control that handles up to 8 cameras and plugs into a USB port. I didn't even build a prototype before having boards made, but when I got the boards back and stuffed all the parts onto one of them, it worked the first time I powered it up. I wish more of my software projects were like that. :-) (In all fairness, though, it really wasn't that complicated a design...the FT245BM takes most of the pain out of working with USB.)

(I started out majoring in computer engineering, but inattentiveness in class led to some less-than-desirable grades in courses needed for that degree. I switched over to computer science and didn't switch back...hell, I goofed off a bit too much with some upper-level math classes there, too. I started college in 1989, but didn't graduate until 2001.)

1) USB interface. Add a microcontroller, learn to program microcontroller (maybe 2-3 months to learn, if you're a competent coder already), get the programming hardware ($20 if you make it yourself, $100 if you buy it), connect LEDs and resistors to microcontroller.

You might want to have a look at this page. In particular, you might find the FT245BM interesting...it supports a "bit-bang" mode that allows you to read/write bits on an 8-bit parallel port. I've designed it into a pan/tilt interface for some security cameras we've obtained that supports up to 8 cameras. That interface uses this chip, a couple of 8-to-1 muxes, and some passive components...no microcontroller is needed. Connecting to the parallel port would still be easier/cheaper/faster, but the hardware and software exist to make USB much less hairy than it initially appears. (Two FT245BMs cost less than $20, shipped from Australia to the US in about a week. There is a distributor in New York, but that company has a $30 minimum order.)