SparkFun will be closed Nov 26th and 27th for the Thanksgiving holiday. Orders placed after 2:00pm MT on the 25th will ship out Monday the 30th.



Member Since: June 3, 2013

Country: United States

  • I went through a very similar exercise in developing an H-bridge not too long ago. In my case, I was translating TTL into +/- 12 VDC for an EV charging station circuit. The problem I had was that the input was a microcontroller output, which sometimes is Hi-Z. When it is, what happens is that the first stage transistors were biasing each other, and you short +12 to -12. I wound up using MOSFETs to solve the problem. Since there’s (effectively) no gate current, a relatively high pull-up resistance is sufficient to prevent any ambiguity in the state when the input was undriven. It also made the whole thing a lot faster. With BJTs, there was a tension between the speed and the base bias resistors and the pull-up. With MOSFETs, there’s no longer any gate bias resistor, just a pull-up to the common gate on the primary side (my circuit is two stages. The first stage turns the TTL into complimentary switching used to drive the secondary pair that switches the output voltage).

  • This is a personal first: Kudos to Microsoft for doing the right thing.

  • Well THIS little incident isn’t going to do good things for their reputation, that’s certain.

  • FTDI doesn’t own the Linux driver. What they’re doing prevents you from using an affected device with Linux.

  • Pretty sure that talking my mother through that procedure is a non-starter.

  • How confident are you that, having done this once, that FTDI won’t make a mistake in the future and release a driver that accidentally bricks legitimate FTDI devices?

  • For all intents and purposes, reprogramming the PID to zero bricks the chip. It’s not just unusable by their driver, it becomes unusable by ANY driver on any OS. It is recoverable by a guru, but suggesting that this isn’t sabotage is disingenuous.

  • That other companies may or may not have done it doesn’t make it more acceptable.

    Oh, and [citation needed]

  • If they did what prolific did a while ago and BSOD/panic on detection, I’d be fine with that.

    Deliberate hardware bricking is unacceptable in any context.

  • I can understand that. And I’m not calling on SparkFun to throw away stock on hand. But when products need to be revised or new products created, I hope SparkFun will remember the dangers involved in trusting FTDI not to pull a Stuxxnet.

    Besides, what if the next time they try this little stunt they mess something up and it starts bricking legitimate FTDI product? Maybe a chip revision they missed in driver testing? Who knows what might happen. It’s just not worth the risk to use their chips.

No public wish lists :(