The world of hobby electronics have only started putting USB in projects for the last few years, and right now, pushing 1.5 Mbps down a USB port is good enough for most cases. This isn’t true for all cases; that’s a terrible data rate, really, and to get the most out of a USB connection, you can at least move up to USB Full Speed and 12 Mbps.
[Linas] is using the STM32F4 microcontroller for this example, an extremely large and very capable chip. [Linas] is using FTDI’s FT2232D USB UART to send data from an SPI port over USB. This chip does support 12 Mbps, but only after a few additions; an external EEPROM must be connected to the FTDI chip to provide a USB 2.0 device descriptor, otherwise the connection between the microcontroller and a computer is limited to 1.5 Mbps. Even using the USB on the STM32 would be a bottleneck in this case; [Linas] is moving data out of the processor using only the DMA controller – using the USB on the STM32 would eat up processor cycles in the microcontroller.
Thanks to the DMA controller inside the STM32, the microcontroller is capable of sending and receiving data through SPI at the same time. The STM32 is capable of reading and writing to the Tx and Rx buffer at the same time, but the computer is only capable of half-duplex operation – it can only read or write at any one time. [Linas] is setting up the DMA controller on the STM32 as a circular mode, putting everything in the buffer into the FTDI chip, and reading everything sent from the computer back into the STM32’s memory. After counting off the correct number of packets. the controller resets everything, moves the circular buffer back to the beginning, and starts the whole process over again.
The circuit was prototyped with an STM Discovery board. With Labview, [Linas] can see the bits coming out of the microcontroller, and send some bits back to the micro over USB. [Linas] has an extraordinarily detailed video tutorial on this project. You can check that out below.
Using a FTDI (!) chip for it’s intended purpose is a hack now?
Sounds like Astroturf after the PR mess from bricking peoples stuff that had the FTDI label on it. The cost of your own licensed 12Mbps USB VID+PID descriptor is free with any $5 Microchip mcu.
FTDI shows only arrogance after wasting hundreds of peoples time fixing their driver virus. They forgot that ironically the FTDI chip started by cloning another group’s project.
All caps titles make for easy confusion between Mb and MB. And when my preview text showed a clear 1.5Mbps, I actually had to click the article to see which was real.
H-a-D, you have mastered the nerd-snipe click-bait game, congratulations.
The past year it seems more like engadget. Anyone know of anything else?
Now hold on there. We have never written an article about Uber, a cell phone provider, or (to my recollection), anything on one company suing another. That’s the editorial purview of engadget, techcrunch, or ars technica, and does not belong here. Read what’s here, and you’re getting a DIY Linux graphing calculator, tutorials on programming the ESP8266, and finding vulnerabilities in cable boxes. All that was posted in the last 24 hours. There is obviously a difference in content.
But I’ll entertain you. What, specifically, would you like to see from Hackaday?
I can’t speak for anyone else, but I’d like to see more of the same type of content you’ve been providing.
Clever .asm tricks. FPGA shenanigans. Novel architectures. Larger projects. Not always a huge jump in complexity, but some significant physical scale would be nice once in a while. Things like the Goliath quadcopter. As you said, the ESP8266 stuff and cable box hacks were awesome. I think the particular gripe here is that the calculator is a particularly mundane and straightforward implementation of an old idea. The KnightOS comment was honestly more interesting than the article.
That said, you guys are miles above the competition. You serve a picky demographic. Hackers and engineers will, by the ever-improvement-seeking nature that made us what we are, inevitably hold you to a standard that is far higher than any other “news” source. You already do a good job of living up to that incredibly high standard; we want you to do even better. It’s just who we are.
*here and with regard to the calculator is that they are both straightforward implementations of old ideas.*
+1 on this, we are a picky and vocal group, but many of us love what you guys do, even if we don’t love every article that gets posted.
One way to make Hackaday way better would be for people to post comments on the actual hacks, add a few of their own, OR take a long walk off a short pier, instead of constantly whining and moaning about spelling, grammar, or whether an article is L33T H4X enough for them. Brian, feel for you. I vote for an article on: “Hacking Together Your Own Blog For Jerks Who Think They Can Do Better”
Here is YANFW (Yet Another New Format Whine B^)
The text on the articles start right at the left margin on my Chrome browser. It almost looks like it is being clipped.
I also agree that all caps headline is confusing with mbs and Mbs.
The following question is more directed at Mike (I’ll buy a vowel) S.
What is the name of that nerdy deli in Madison WI, that was featured here some months back?
Oh I do agree with the commentors above me that HaD is a good site.
Brian,
You are good by me, twas just being cheeky, with a touch of technical kvetching so that I had something to add. Though, in this case a title along the lines of “Full speed USB 1.0 between PC and MCU” would have not carried the ambiguity.
Eric,
You find anything else let me know and I will read both, but I haven’t found anything half as good as H-a-D yet.
It is the three bears problem: too cold/too hot/just right.
If the articles are too simple, then it bores a lot of people. On the other hand, the more technical ones gets less than 10 comments and that’s not even playing at the hard mode yet.
Stay away from posting kickstarter scams or obvious product placements or trolling as this is not crappy TV and you don’t need to resort to controversy to boost ratings.
Post a mix of the basic stuff and some of the more technical ones too. The retro stuff is certainly and so is the noob scope series – the common theme is that both has technical contents and not just buy this or that and look at me blinking LED video.
Wow, a project using National Instruments software that actually worked, i’m more amazed at that then the technical achievement of the project itself.
Haha +1
Or use a STM32F405/407 with built-in USB OTG – 1 full speed and 1 full speed or High Speed with external ULPI PHY. Yes it would use some processor cycles.
I stopped reading at the word “FTDI”
Did you guys read the article? He replaced an FTDI solution with a STM32F4 with built-in USB FS PHY. Really you don’t need to use DMA. The article is wrong. You could do it easily with PIO with a 168 MHz MCU with the code running out of TCM. That’s a whopping 448 cycles to move each 32-bits. I’ve moved data way faster than that using the HS USB, external PHY, and STDIO to a FPGA (via DMA for both).
There is a new crop of low end micros coming out next year from many companies that have built-in HS PHYs. Makes moving data on a MCU level core that much easier.
Of course if you just need device role, hobby friendly chips like the FX2LP can easily move more than 150 Mbits/s and have been doing it for more than a decade.
Pushing 20+ MB/s (~150 Mb/s, rounded to nice numbers) through an FX2LP isn’t exactly easy, actually, although most of the difficulty’s on the software side, making sure that there are always transactions ready. I don’t think you can get anywhere near 20 MB/s (and do anything useful with it) using the onboard microcontroller on an FX2LP, either, although I could be wrong. So interfacing with it with an external MCU might be a bit difficult.
Simple implementations usually get more in the 5-10 MB/s range. I’ve always found trying to push more than 10 MB/s through USB takes a bit of effort.
But as to your overall point, yeah, I agree, 1.5 MB/s is really pretty straightforward with a high-end microcontroller.
Correct WRT the Cypress FX2. You can set up an external parallel bus to stream data though one USB endpoint. Some glue logic is provided in the FX2 and configured though registers. I managed to sustain about 30MB/s into an FPGA working from the notes in Jan Axleson’s book. Apparently it’s possible to achieve nearer 40MB/s though one of these chips into custom hardware with a bit of careful tweaking.
I guess you might be able to do something useful in a microcontroller with that sort of data rate using the slave parallel bus and DMA found on a PIC32, assuming you could figure out the handshaking.
I very regularly use an FX2LP to save data at 30MB/s reliably to a PC with an 11TB RAID array attached. I can fill the entire array at that speed without ever missing a packet. (takes a few days – tested from an FPGA with a free-running counter, saving the counter allows a binary search to be used to find any missing packets, since the counter was 32 bit and each packet only 512 bytes.)
The trick to keeping the data flowing isn’t really in the software or the FX2LP – It’s that the OS will occasionally drop the ball, since USB2.0 didn’t make provision for DMA transfers on the host side. The OS’s scheduler keeps getting involved, and this means pretty frequent ~4ms long glitches where the transfer stops.
No USB2.0 HiSpeed fifo chip exists that can handle the PC dropping the ball for that long, so you need to provide your own hardware to deal with it. (ztex.de have a few fx2+dram+fpga boards that I use, and the DSLogic is the same chipset, in neater, ready-to-stream form). I’m looking into setting up a XuLA2 with a cheapo fx2lp board from ebay to do the same too. Use the fx2 in 16bit slave fifo mode, it’s easier to achieve the data rate without troubles if you can lower the clock rate. The fx2fpga link needs to be not the limiting link, since the fx2 only has about 2kB of buffer (3 if you get fancy with how it’s configured, I think.)
You need at least about 8MiB of deep fifo buffer so as not to hit a buffer-overflow condition for the whole chain, but since the peak rate is actually somewhat closer to 32MB/s, after the pause the fx2lp will relieve the pressure, clearing the buffer.
Oh, all root hubs arn’t equal either – I usually use the code at triplespark.net – either fx2pipe or the bench_in example to check to see just how fast a particular system can sustain. (intel seem to do best, although I’m holding out for an arm that can compete. ) I have seen up to about 40 MB/s I think, although I wouldn’t trust it to be the sustained rate: Need to put aside a little, or else have a huge fifo to handle sequential stoppages before hitting overflow. (ok, I actually use 64 MiB, but mostly only because I wasn’t doing anything else with the rest of the DRAM chip. 8 ought to be enough, even for windows.)
This article brought a smile to my face :)
My opinion is: Microcontrollers are cute, but unless you absolutely have to hit a low power or low cost engineering point, (or are doing it for the fun, ie, retro), FPGA’s are where it’s at. (and if you need processing flexibility, there are more and more FPGA+SoC chips around which are very capable.)
I really ought to get around to doing a similar how-to on this stuff, it’s not particularly hard, and can be done remarkably cheaply. (my pick is probably still a good fpga board with DRAM (ignore SRAM, it’s too small, and don’t bother with FIFO SRAM’s, they’re hideously expensive, and still too small). plus a cheap fx2lp board for <$10 from ebay, in 16bit slave fifo mode at perhaps 30MHz.
If you really *want* to play with microcontrollers, the fx2lp has an enhanced 8051 with all the bells-and-whistles in it, and the larger ztex boards even connect the address and data bus of it to the FPGA, as well as the fifo bus.
The ztex SDK is the very best USB firmware for any FX2 – and they're boards are much cheaper than the OpalKelly ones.
(there's example ultra-minimal firmware on the triplespark.net site, but it exploits the fact that live uploads into the 8051's program memory act as overlays to the built-in "default" fx2lp firmware, which is what you get in the event that the chip can't configure itself from the eeprom nearby. (very nice anti-brick feature! just short an address line on the eeprom with a screwdriver as you plug the board into the usb port to force the fx2 to come up from its default firmware, should you happen to end up having flashed a broken eeprom image)
I'd hoped the DSLogic's would sell at similar price to what they offered in their kickstarter campaign, but unless the neatness and logic analyzer use is attractive, for the cost the ztex.de boards are the better buy for ~$200.
Oh, and before I let NI off the hook: Their "compact-DAQ" system is basically the same hardware: (fx2lp + fpga with DRAM) but in a solid looking box, able to accept c-series modules, and be programmed through LabView. It's actually good, solid, reliable stuff – if you don't mind paying government-research-equipment or serious-engineering-company pricetags :)
DSLogic is $100 on seedstudio, thats pretty much ks price
“The ztex SDK is the very best USB firmware for any FX2 – and they’re boards are much cheaper than the OpalKelly ones.”
Sadly, it still runs the FX2 slave bus out of spec interacting with the FPGA.
Working with the slave parallel bus isn’t *that* trivial, because the bus timings are so terrible. Almost no one pays attention to them, including Cypress, and just blindly try to run the bus at like, 30 or 48 MHz, and it actually can’t run at 48 MHz at all. Worst part is that it runs at room temperature fine, but over its full temperature range it’ll fail at either the high or low end. So lots of people think that it’s simple to interface, and then wonder why the first byte is duplicated or lost when things get hot.
Okay, that ‘lots of people’ might be just me.
Not quite as fast, but a little 8-bit avr can do 6mbps async serial.
http://nerdralph.blogspot.ca/2014/05/high-speed-uart-pumping-out-data-at.html?m=1
Well High-Speed USB is doable with the STM32 just with the internal PHY… 480mbps needs an external one…
The beast has core-coupled memory so you could burst out more or less the complete RAM content with 480mbps via (an dedicated to USB) DMA and the rest of your application wouldn’t even be harmed…
It’s just a total fail… RTFM!
73
Or you could just use ATSAM3U and have 480 Mbps USB.
Datasheet:
http://www.atmel.com/Images/6430s.pdf
Whaaaaat? You have to add an EEPROM to the FTDI chip just to make it use 12mbps? How was that oversight ever approved?
Correct text is in my blog. Whole idea is to make very fast way for transferring data between MCU and PC. 99% people can deal with software data transfer, or even interrupt based, but in my case, i could not use processor time at all, since it will cause problems in microcontroller program, that is very time sensitive. If i get interrupt from computer that i need data, and i am at the middle of 48MHz 10b parallel bus transfer from camera, it will be jammed, and i will have to discard frame and start again. Each second it have to deal with 30×1024 interrupts from DCMI, and any interrupt based program will cause problems, i try that.
This application is already pushing STM32F429 limits, at the same time it has to manage motors, process image, transfer image to external sram, and do other monitoring. I did some testing, because i do all math inside mcu, i get better speeds than simply taking webcam at same resolution, stream data with max usb speed (below 480Mbps) , and process data inside labview. Any software communication will cut my computational speed, heck, even wrong loop unrolling can slow down image processing by 50%
http://hackaday.io/project/3579-12-mbps-communication-link-between-pc-and-mcu
Has anybody been able to sustain ~40 MBps over FT2232H from FPGA without getting Buffer Overflows ? I’ve my async FIFO code working with Libusb/LibFTDI, but with lots of over runs…. Had managed close to 42 MBps with FX2LP stream test app back then, but left it for its inherent complexity…. Makes me wonder now whether FTDI was ever a wrong choice ?
I tried the FT232H initially,
But I couldn’t get reliable communications into the FT232H eval board I was using – had it hooked up to a Papilio One at the time (long since moved on from). To sustain 30 MB/sec means needing more than that to the fifo chip, and this meant needing to run the 8bit bus on the Ft232h at the full 60 MHz, which is a bit too optimistic for a parallel bus over hookup wire.
Much easier to do 320 Mbps down a differential pair over hookup wire, but no one makes such a usb fifo chip. (I wish they would – with a sufficiently large fifo too please. Hell, pretty much the differential I/O on the DSLogic – which BTW, is a Damn good deal at at anywhere <$100. )
Anyway, that I couldn't get an 8 bit counter to push sequential numbers through the FT232H board made me go back and revisit the FX2. (I must admit, the first time I opened that monster of a tech ref manual, I closed it with a "an 8051?!??!! Screw that!" But if you run it in slave FIFO mode only, and don't use it for application specific things like loading your FPGA (all the new ztex boards have a CPLD for that job) – and you're only going to support linux – then just use the fx2pipe program from triplespark.net, and it's very much like running the FTDIchip in terms of ease of use: Fx2pipe does what it says: acts as a pipe, and it allows you to set the width / clock rate / clock direction and buffering settings from its command line options at run time. And it works with a eeprom-less FX2. (Which means any FX2 that you can hotplug whilst interfering with the eeprom chip address pins )
There are fx2lp boards on eBay for less than $10, and the 16bit parallel bus with the option of external clocking at a wide choice of frequencies makes it easy to add, so long as you have sufficient pins available.
I'm going to give exactly that a go with a XuLA2 board soon… Even if I end up with only two pins free to get data into the XuLA2, it'll work – that one can be the fast differential particular packet serial to usb adaptor, I have another for application purposes.
Although, if I can get a ready supply of cheap DSLogics…..