Track My Order
Frequently Asked Questions
International Shipping Info
Mon-Fri, 9am to 12pm and
1pm to 5pm U.S. Mountain Time:
Chat With Us
June 3, 2013
News - Project Fails
about a year ago
My biggest fail was designing a clock controller with an ATTinyx5 and a 32.768 kHz crystal and not adding any loading caps because I had misread the datasheet. And then having a batch of 300 of them manufactured. All of them were ~120 ppm fast. Fortunately, I was able to work-around it in firmware, but for a moment there I was faced with the prospect of sending a freshly manufactured batch of boards to the Albuquerque landfill to rot alongside the ET 2600 game.
News - According to Pete: Charge…
about 4 years ago
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).
News - FTDI Drivers and Counterf…
about 4 years ago
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 
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.
No public wish lists :(
Forgot your password?
No account? Register one!