Interesting research! I write software to talk through FTDI devices all the time (not by choice) so this is definitely something to keep in mind in near-realtime applications: Keep the packets at 2048 bytes or less, or you lose half of your effective bandwidth. Thanks for posting!
I would guess that there might be a [particular laptop or motherboard configuration that might implement the USB in a more optimised manner. But that's almost like the days of the PCW bench tests where computers were tested against each other in ridiculously specific manners. RS485 is definitely a nice rugged industrial data transfer system. Quite fascinating in its own right. (Although the more technical details of the 120 ohm characteristic impedance are quite frankly not very entertaining at all.)
+bigclivedotcom I had a problem with some VTR which used 485 remote control. One day, someone replaced one of the units and we started getting intermittent errors. It turns out that all of the VTRs had their termination switches ON and they were looped together. It worked with four switches on (30 ohms!) , but five caused problems. We turned all of them off and used an external terminator on the last one in the chain.
+Chris W That's the thing about 485 - when done right it's bombproof, but can "sort-of" work if not wired correctly. First thing to do on any 485 setup is an end-to-end resistance check for opens & wrong termination.
+mikeselectricstuff +1 to the soft-of work part, especially on a multi-drop network! We use 485 nearly exclusively in our products at work. Sometimes though (usually user error) the network is terminated/polarity inverted/transceiver mode set incorrectly and the issue pops up in a random location on the bus. Agree with checking resistance, found the point of issue quickly that way. Fun when the data is corrupted/inverted due to one of the two lines being O/C or S/C.
Great video as always. Looks like Easysync may have gone out of business in December 2021. A shame as their equipment is very good. Ebay may be the only source now.
Love your vids. Been subbed for two years or so, and if I may, can we have some more year down vids please sir? I would send some stuff if shipping wasn't off the scale from NC to you! Thanks to Mike and his electric stuff!
I was just wondering why you up loaded a wide screen (16 x 9 ish) video within a 4 x 3 frame? Thought it was odd, you being a tech kind of guy! interesting vid however.
Maybe if the USB size limit is a common issue (OS rather than motherboard, for example) then perhaps you could use a client-server setup, either with a PC hammering data across Ethernet to its clients or using Raspberry Pi, etc. as a smart "here's a big fat packet, now chop it up and bang it out to your USB ports" device.
I am using SPI interface of FT2232H, it is very nice, and can get 30Mbps with no problem ( good thing is DMA can get 65535 space, just like maximum packet size. And it use bus quite well. For very short packets it can be 10KHz repetition rate, and for longer packets, it will shift more data. And only at small packets, bus utilization is not very efficient, but with larger packets, it is very good. But yes, it's for single point communication, unless you will change SPI to differential signaling or something... FTDI just released USB 3.0 with parallel interface i think i will give a try
This is why you EE guys really need to get into Linux. Often these edge cases are much better handled - or if not at least there is an opportunity to do something about it.
+Gooberslot Everyone has different experiences and needs and all the various OS fans get too hung up on which OS they think everyone should have to use/not use. I love Linux for servers and some development work and use it heavily for such, but it is nothing but headaches for me on the workstation front so I am not terribly fond of Linux for workstation use nor would I try to make my less than tech savvy family use Linux workstations. Plus constantly needing to emulate Windows under Linux can be a headache as I have a lot of commercial software and drivers that do not have comparably effective Linux counterparts and I have better things to do than reinvent the wheel and author all the code required to replace them. To each their own!
+Ethan Poole Yeah - but you seem rather hung up on your non-support for Linux. It's only a suggestion. Mike can consider the suggestion, and look into it - or not. Of course a transition would require some changes to workflow - that's one of the costs of trying something new, and why many people dual-boot. I'm just saying that many people - myself included have benefited in their projects from having access to the inner workings of their OS. Which is why I'm saying it's a useful tool to have on hand.
+Gooberslot At 7:36, he appears to be using LibreOffice Calc - so he clearly doesn't have too big a problem with it. Also it's nice to see non-Linux users gaining awareness of the need for LibreOffice over Apache OpenOffice.
Revisiting this video after a very long time, since You said it's a driver issue, I'm curious whether there would be the same problem in a Linux/BSD environment. I'll definitely keep that in mind when dealing with these.
Did you try using a different pair of ports? I know a lot of PCs these days actually have multiple USB controllers, so if you got one of those on each of them you'd have better results.
Please update the description to be more clear/specific. What is the source (PC with software?) and what is the sink (µC with RS-232)? What are you measuring where? Many things only got clear as I watched the video. "Shoving multiple data streams out of one USB port to UARTs" Would be more descriptive.
did you try a multi-threaded (/multi-process) application? I wouldn't be too surprised if your write call is blocking just that thread... It could possibly permit even better parallelism with the sub-2k packets, and would likely bring down the inter-port latency with larger packets too... unless the FTDI driver is genuinely badly implemented.
Looks to me as if an IT guy programmed that part. This is the exact same way a lot of routers handle packets larger than a particular size (i.e. just drop)
+mikeseletricstuff some ealier usb 3.0 boards use different chipsets for the USB 3.0 and USB 2.0 ports maybe that,s a way to go around the port limits?
I suspect the Linux drivers won't have these issues. I think for windows a libusb based driver tuned to handling multiple ports via better scheduling/multiple threads might be the way to go.
Ftdi_sio and usbserial modules? As you say, these are probably good as I think they are open source. Libftd2xx.so is most certainly closed and most certainly buggy.
+mikeselectricstuff : The driver should implement scatter/gather I/O (Vectored I/O) ; It's quiet common in driver/kernel world with hardware buffer limitation. From the user point of view the driver will split the big packet in 2k chunk, and send it to the hardware. Quite easy to implement, shame on FTDI driver guys.