[Scott Harden] wrote in to tell us of some success he’s having using the FT232 chip to speak SPI directly from his laptop to a AD98850 digital signal generator. At least that was his destination. But as so often in life, more than half the fun was getting there, finding some still-unsolved silicon bugs, and (after simply swapping chips for one that works) potting it with hot glue, putting it in a nice box, and putting it up on the shelf.
In principle, the FTDI FT232 series of chips has a bit-bang mode that allows you to control the individual pins from a fairly simple API on your target computer, using their drivers and without installing anything on basically any platform. We wrote this feature up way back in 2009, and [Scott] was asking himself why he doesn’t see more hacks taking advantage of bit-bang mode.
Then he answered his own question the hard way, by spending hours “debugging” his code until he stumbled on the FTDI errata note (PDF), where they admit that bit-bang mode doesn’t get timings right at all on the FT232R and FT232RL parts. FTDI has made claims that they fixed the bug in subsequent chip revisions, but the community has not been able to confirm it. If you want to use bit-bang mode, which is plenty cool, steer clear of the FT232R chips — the ones found in the ever-popular FTDI cables and many adapter dongles.
The good news here is twofold. First, now you know. Second, bit-bang mode is tremendously useful and it works with other chips from the vendor. Particularly, the FT232H and FT230X chips work just fine, among others. And [Scott] got his command-line controlled digital VCO up and running. All’s well that ends well?
We’ll wrap up with questions for the comment section. Do other manufacturers’ cheap USB-serial chips have an easily accessible bit-bang mode? Are any of you using USB bit-bang anyway? If so, what for?
The CP2104 does offer some extra pins that could be used for e.g. bit-banging, but I have never needed to use them for anything, so I do not know how easy they are to make use of.
I thonk some Silabs adapters have GPIO and I2C in addition to serial ports.
CH341A is what you want.
BTW, wasn’t one of the good things about Chinese FTDI clones that they had implemented the bitbanging correctly, while real FTDI chips didn’t?
That is correct.
May be that the clones worked better than the originals was one of the reasons FTDI deliberately released a MS autoupdate for the malware drivers to brick all the competition clone chips.
Fortunately the linux version attempt at the same dirty trick was laught at and rejected.
That also showed, that a mass produced, cheap microcontroller may be the better choice, compared to a (medium volume) custom chip.
And that’s probably the reason, why Silicon Labs and Microchip sell factory programmed microcontrollers as USB to serial/parallel converters.
I would say that if you want to build a device that works and keeps working even after a driver update, steer clear of FTDI in general. You never know what new trick they will invent next to brick your device.
It is the same with Prolific chipsets too.
More references? This was the best I found: https://www.eevblog.com/forum/beginners/bricked-prolific-usb-to-serial-converter/
But use a microcontroller instead. Why bother these less capable specialty devices? You can get cheap microcontrollers, well-supported microcontrollers like Teensy devboards, or built-in microcontrollers like the PRUs on the BeagleBone. Lots of better options.
Prolific just bluescreens randomly when it detects counterfeit, even on win10
As long as you have the real FTDI chip in your design, it will continue to work, no matter how many driver updates.
You will only run into problems if you buy fakes. But if you buy fakes, you might run into a lot of issues. They might work… or fail under certain conditions… or might be unable to handle high baud rates.
You shouldn’t complain about FTDI, you should complain about people making and selling fakes.
But I *do* complain about FTDI. Bricking end user stuff is unacceptable. And this logic is flawed.
Just write a small–and very fast, by the way–bit-banging routine in assembly language.
The Radio Shack Color Computer used software as a UART for the serial port, though you could buy a serial board. I ran Microware OS-9 on it, multitasking and multi-user. But when I was printing something, the timing meant the software UART had to turn off interrupts a lot, which slowed down other things. So if I was printing, word processing in another window would slow to a crawl, suddenly you’d see the cursor moving about the screen ever so slowly.
Hardware UARTs are the way to go.
Michael
Cypress FX2 also have this . And ( for now ) i it is easier to get them that non-counterfeit ftdis
A few comments have recommended chips that have bit-bang mode, but I don’t see anyone sharing tales of what they use it for. Surely there must be use cases out there?
I’ve been trying to think of a place where I would have used bit banging if I had it but can’t really think of one. I have a Bus Pirate that I often use to test out new chips to ensure I understand the protocol before using them in a larger system. But that’s usually SPI or I2C and so that’s what Scott Harden is doing here with the FTDI chip (and Bus Pirate has a bitbang mode so that’s another solution to add to the list of chips).
Anyone have a non-standard protocol they bit bang?
My L-Star project uses a Propeller to bitbang a 6502 but because that takes up a lot of pins on the Propeller, it’s difficult to emulate some old computers because I simply run out of pins.
My design uses an FTDI based Prop plug to communicate between the PC (needed to program the Propeller) and the project, but I’m thinking of replacing it with a PIC that has a USB interface and extra bitbang-capable pins. That way I can free up pins from the Propeller to emulate more computers. It’ll have to be a PIC though: FTDI still doesn’t make their chips in DIP format and I want to keep my design 100% through hole.
===Jac
We bitbang SWD to enable our main CPU to erase, reflash, reset etc a secondary MCU/radio-chip (an nRF52xx). For both production test, factory programming and subsequent field updates.
Nice! Are you actually sending the new firmware over SWD? Does the main CPU do error checking as it goes?
Avrdude has long supported bit-banged serial programming, and it even works with the cheap PL2303hx clones if you break out the pins.
http://nerdralph.blogspot.com/2014/05/pl-2303hx-bit-bang-avr-programmer.html
Since you can pick up a USBasp for <150c now, there's little reason to bit-bang a USB-ttl adapter. However it could be useful in a pinch if you don't have a USBasp on hand.
Actually it should be fairly easy to bitbang an USB-serial adaptor that has more then the TX RX GND pins exposed, such as DTR, RTS, CTS, DI pins. I made a while back a simple program using the serial libs of linux to toggle a DTR pin:
https://github.com/zoobab/toggledtr
Those cp2102 based breakout boards have most of the pins exposed on the board.
But I am pretty sure you could bitbang them faster with some libusb messages.
Pickle (Microchip PIC Programmer) supports FTDI Bit-Banging:
https://wiki.kewl.org/dokuwiki/projects:pickle
This S88 (model railroad protocol) Interface also use bit banging:
https://github.com/GBert/railroad/tree/master/ftdi2s88
FT245BL could do the job
FTDI is grossly overpriced.
There are many hardware alternatives, e.g. WCH chips (like CH340), not clones: https://www.eevblog.com/forum/reviews/alternatives-to-ftdi-usb-to-uart-converter/msg540847/#msg540847 or software alternatives, e.g. the CDC driver for Atmel MCUs. These alternatives can be orders of magnitude cheaper than FT232.
I once used their ‘new’ VNC2 USB micro for a production test fixture. Turned out all our problems were caused by their buggy SPI implementation. It’s really not that hard to get right (speaking as an ex digital IC designer) but that issue killed the project and I never touched those parts again.
Why not consider the Exar XR22802? It has a very low latency HID interface, which works fine under Linux. The ethernet driver can be disabled in firmware to reduce power consumption. We used the MCP2210 in the past, which is slow. FTDI chipsets were not considered because of their custom linux drivers.
Seems like a cool device, but apparently it costs about 7$ in low quantities.
Datasheet for the curious: https://www.exar.com/ds/xr22802.pdf
Maybe the dumbest one if you need to control timing from something that runs a real opsys (linux, pi, PC, MAC) that won’t bitbang- I just use an arduino, the chinesium sort, dirt cheap and realtime as I wish with my little cooperative multitasking system (which is less fancy than the name). OK, it’s big, but I’m doing infrastructure stuff anyway. I used to be a super PIC fan and designed them into product for myself and others, but Arduino is just a no-brainer anymore. ~~$4 and 30 minutes tops with a bog standard USB to talk to the host in the host’s timing while I do realtime in the Atmel? Beat that and I’m listening.
What is this Analog Devices chip of which you speak? You mean an AD9850?
FT4222 bitbang works great.
http://www.ftdichip.com/Products/ICs/FT4222H.html
I will *NEVER* *EVER* buy anything with FTDI in it (if I can avoid it). I had a student lab with 30+ arduino nano clones which stopped working after the infamous driver update (and no, sorry, how am I supposed to know if a chip marked FTDI is legit or not?). Yes, I eventually was able to fix things, but anytime any of these was connected to a different windoze machine things went badly. Too much time to fix things. Eventually just gave all of them away and got the chinese clones which are cheaper and work better. #neverFTDI