The fact that a non-FTDI chip uses FTDI's driver is fine in my book. There is a long history of third parties making hardware that works with an existing driver. Take the Sound Blaster 16 for example.
I just wanted to try to insert a sanity breakpoint in case you were truly trapped in an infinite loop from which you were now incapable of escaping (still not entirely convinced on that one though!).
It's their driver, of course they get to decide which devices it can talk to. Just like Xilinx can decide whether or not their tools will program Altera FPGAs. Even if the protocol was the same and technically it could, it's perfectly within their rights to design it so that it doesn't.
I want you to explain to me exactly what you think FTDI is accomplishing by making their driver not work with/brick/spit bad data out in the first place.
Well, the clone maker fixed the original vulnerability that allowed FTDI to tell the difference. So, FTDI wasn't really stopping future clones.
So, aside from ending up with better clones and egg on their face, what was the point?
This is no different than IBM vs Compaq. You're right, FTDI has every right to do whatever they want with their driver. However, just like with DRM, they will never win; in fact they've already lost. All it does is serve to inconvenience end users.
If it were *my* driver, ...
If it were *my* driver, I would see the writing on the wall and move on, instead of doubling down on a losing strategy. (In this case, both their driver *and* production of basic USB-UART chips is that losing strategy.)
In order to stay ahead you have to create new products and get into new markets all the time. IBM has been mentioned and even though IBM was forced out of the PC market they still exist today. Or look at Dyson. Dyson succesfully hyped bag-less vacuum cleaners and soon after that others followed with similar products. No problem for Dyson because they have a whole line of products and they even succesfully entered the hand-dryer market.
Now look at FTDI: the only products they are really known for are their USB-UART bridge chips and in a lesser extend their USB FIFO chips.
It's their driver, of course they get to decide which devices it can talk to. Just like Xilinx can decide whether or not their tools will program Altera FPGAs. Even if the protocol was the same and technically it could, it's perfectly within their rights to design it so that it doesn't.
Apples to oranges, and you know it.
Actually, this brings up a good point. I want you to explain to me exactly what you think FTDI is accomplishing by making their driver not work with/brick/spit bad data out in the first place.
Q: Why are they throwing out "bad" or "garbage" data?
A: First, it's not "bad data", "bad data" would be if they made random changes and spit out nonsense. It's not bad data, it's a message, a very clear message explaining why it's not working. The alternative would be to send nothing and bury an error code or message deep in the bowels of the system logs where it will never see the light of day.
It would have been relatively easy for FTDI to make a chip test tool and distribute it to vendors and distributors. This would allow them to test for genuine parts before incorporating them in their sales stream. Even a lot sample test of this sort would have been highly effective.
FTDI apparently did not think of this, or had some motive for not doing it. At this point in time people can use the driver to perform this test, but do not have the manufacturers assurance that passing this test will be good enough in the future.
Still seems to me that FTDI is either not handling this well, or is motivated by something not identified on this forum.
... or sending random data (from the perspective of any device attached).
... or sending random data (from the perspective of any device attached).So far, in this whole thread, nobody has made a valid point why it's wrong to send a string that contains "not a genuine chip".
... or sending random data (from the perspective of any device attached).So far, in this whole thread, nobody has made a valid point why it's wrong to send a string that contains "not a genuine chip".You are a real engineer aren't you? If you are a real engineer then you should know it is very bad to send random data to a device. I have come across several devices which lock up when confronted with data the device didn't expect. One of those was actually performing a safety critical function so yes, it is very bad to send random data to a device. I also start to doubt you can read because this has been discusses at length in this same thread so you are trying to create a new infinite loop here so lets leave this subject alone right here. You can read all about it in the previous pages.
It would have been relatively easy for FTDI to make a chip test tool and distribute it to vendors and distributors. This would allow them to test for genuine parts before incorporating them in their sales stream. Even a lot sample test of this sort would have been highly effective.
FTDI apparently did not think of this, or had some motive for not doing it. At this point in time people can use the driver to perform this test, but do not have the manufacturers assurance that passing this test will be good enough in the future.
Still seems to me that FTDI is either not handling this well, or is motivated by something not identified on this forum.
The problem with such a tool is, what do you want it to do.
1. Do you want it to check only for the actual way of checking for counterfeit chips, than you can simply use the latest driver. No need for a tool.
2. If you want a tool that checks for all possible ways to check for counterfeit chips, also methods of detecting which FTDI hasn't been used yet but keep them for future use,
well, then they should be stupid if they provide such a tool because that tool will be used by counterfeiters to check and circumvent all present and future methods of FTDI to check for counterfeit chips.
Yes, I am. Apparently you aren't otherwise you should know that a safety critical device that can cause seriouse injury because of a glitch on a serial port,
should be taken out of service immediately. There's simply no excuse for that.
You are a real engineer aren't you? If you are a real engineer then you should know it is very bad to send random data to a device. I have come across several devices which lock up when confronted with data the device didn't expect. One of those was actually performing a safety critical function so yes, it is very bad to send random data to a device. I also start to doubt you can read because this has been discusses at length in this same thread so you are trying to create a new infinite loop here so lets leave this subject alone right here. You can read all about it in the previous pages.
Yes, I am. Apparently you aren't otherwise you should know that a safety critical device that can cause seriouse injury because of a glitch on a serial port,
should be taken out of service immediately. There's simply no excuse for that.
So you are saying that legitimate vendors must assume all of the risk of being stuck with a clone chip while FTDI assumes none.