6
\$\begingroup\$

I have a small dedicated controller built around an Arduino that accepts commands from a PC over USB (serial). The communication is one-way -- the controller never sends data back to the PC.

Now I need to extend the controller to handle more duties, but there's no room physically or program-wise, so I'm adding a second box with another Arduino that will accept the extended commands.

I can't alter the controlling PC application or add another USB port to the PC. The application controls the hardware and is in turn driven by a script. It can only talk to one serial port (physical or virtual) at a time. We can alter the script but not the hardware/application. So my hope is that I can just bridge across the D+/- lines to feed the second controller.

If this were straight serial I'd have no problem, but with USB in the middle I see issues ahead, because the PC will want to enumerate both Arduino USBs, right?

Is there a solution here I'm overlooking? Can I use USB passively, as a listener only, with the second controller?

\$\endgroup\$
  • 6
    \$\begingroup\$ In that case how about bridging the serial lines themselves between the arduinos? Or getting one to forward unknown commands to the other? Or buying one with more program space? \$\endgroup\$ – pjc50 Apr 16 at 16:48
  • \$\begingroup\$ @pjc50 - Bridging the serial lines was my second choice, primarily because layout issues in the current display make that awkward. But it's becoming obvious that it might be the only solution. Program space is only part of the issue -- physical space matters more. \$\endgroup\$ – Jim Mack Apr 16 at 16:52
  • \$\begingroup\$ use thin wires. a USB cable and a single thin wire take about as much space as a usb cable alone, the other arduino needs 5V, ground, and the single thin wire which takes less space than a USB cable. \$\endgroup\$ – Jasen Apr 17 at 3:58
  • \$\begingroup\$ Is inserting an USB-Serial converter between the PC and the device possible? It won't need an additional USB port. Just interrupt the cable and put such a converter in-between. If that's allowed, there are alternative solutions I can describe in a proper answer. \$\endgroup\$ – vsz Apr 18 at 4:33
  • \$\begingroup\$ @vsz - I'd be interested to hear what you propose, as long as it doesn't involve a second virtual serial port on the PC. Any scheme that adds a USB device seems to run afoul of this. I'm committed to combining Rx lines at this point, but I'm curious to hear your idea, as others might benefit. \$\endgroup\$ – Jim Mack Apr 18 at 11:38
12
\$\begingroup\$

USB CDC serial is quite a complicated protocol. Even if you are only sending serial commands one way, there is USB traffic going backwards and forwards all the time. Even when the virtual serial bus is quiet, the usb host is continuously asking the usb device "do you have anything to send" and the device says "no".

Consider sending the phrase "hi" to an arduino, and getting "hello" back. On the USB bus, it will look something like this:

Host: Do you have a message?
Device: No.
Host: I have a message for you
Device: OK
Host: hi\n
Device: OK
Host: Do you have a message?
Device: No.
Host: Do you have a message?
Device: hel
Host: Do you have a message?
Device: llo\n
Host: Do you have a message?
Device: No.
etc. etc.

These messages will also be mingled in with messages sent to other devices on the same hub (even if you don't have a USB hub in the system, there may well be one inside the computer. So you could easily see messages to your mouse and keyboard mixed in).

The USB protocol is extremely complicated, so splitting it in the way you mention is not going to be practical. You can "sniff" it though. If you connect the D+ and D- lines, it is possible to see the traffic on the bus. As long as the sniffer doesn't try to manipulate the D+/D- lines, the USB bus will keep working. The sniffer would then need to identify which messages were relevant and decode them. Building a sniffer out of an arduino would be difficult but probably not impossible. It almost certainly isn't the best solution for your problem.

\$\endgroup\$
  • 4
    \$\begingroup\$ Actually building a sniffer out of an Arduino would be impossible in this case. The ATmega programmatic USB hacks are USB low speed and rely on part of the USB spec not being literally enforced to work. But the existing USB CDC implementation will be USB full speed, and so too fast to sniff this way. Possibly at the extreme of loading a custom firmware on the existing 16u2 (if the existing Arduino is a true Uno) one could make that operate in semi-compliant low speed mode and thus be sniffable, but your last statement is the key one: "isn't the best solution for your problem." \$\endgroup\$ – Chris Stratton Apr 16 at 17:34
  • \$\begingroup\$ Thanks for the tutorial. It's been made abundantly clear that there's no way a simple bridging could work, so I'm off to plan B. \$\endgroup\$ – Jim Mack Apr 16 at 17:38
  • 1
    \$\begingroup\$ @ChrisStratton I was thinking of seriously abusing the USB hardware on a Leonardo. I never use the ones with a separate 16U2 as a usb/serial converter, and had kinda forgotten that most of them were like that. I believe it would be possible to bring up the USB hardware on a 32U4 in such a way that it didn't manipulate the bus but still listened. Didn't look at the datasheet to check though. \$\endgroup\$ – Jack B Apr 16 at 17:52
  • \$\begingroup\$ @JimMack Glad it was helpful. \$\endgroup\$ – Jack B Apr 16 at 17:56
  • 1
    \$\begingroup\$ @JackB - no, that would not work. To sniff, you would need something where you can get your fingers in the fine grained USB function implementation, not a fixed function peripheral block. And realistically at that point you'd be better off grabbing a dual-USB STM32F4 and making something that grabbed whatever it wanted and passed the rest of the virtual serial payload stream through to the Arduino hanging off its OTG port. But then you take a step back and realize you should just replace the Arduino with something that does everything OP needs, or add software to talk to a second device. \$\endgroup\$ – Chris Stratton Apr 16 at 18:02
4
\$\begingroup\$

No you can't split USB, but what prevents you from connecting the UART receive pins of two Arduinos together so both receive same UART data, or making the first Arduino to send commands it does not understand to the other Arduino?

\$\endgroup\$
  • \$\begingroup\$ Both are possible and I'll likely bridge the Rx lines in the end, but was hoping for a simple solution that doesn't require any modification to the existing controller. \$\endgroup\$ – Jim Mack Apr 16 at 16:56
2
\$\begingroup\$

Can I use USB passively, as a listener only, with the second controller?

Technically yes, you can build a device that is passively looking at USB traffic and be able to get information from it and take any actions. In fact, devices like that do exist. They are called "USB Protocol Analyzers".

Typical architecture of such devices consists of an non-invasive sniffer on D+/D- lines (high-impedance voltage divider plus gain compensating wideband amplifier), which feed a standard (stand-alone) USB PHY. The serial-parallel output interface from the PHY (ULPI or UTMI or PIPE3) is then watched/logged by a sizeable FPGA that has decoding tools and can trigger off USB protocol events. Examples: Teledyne-LeCroy, Ellisys.

enter image description here enter image description here

So you can watch USB traffic and get data. To get them in real time you will need to program FPGA and run it at sufficient clock rate to implement most elements of USB Serial Interface Engine (except forming ACK/NAK replies).

\$\endgroup\$
1
\$\begingroup\$

One solution could be to essentially implement a daisy-chained local serial topology of Arduinos. One of these at the 'front' of the chain would expose its USB CDC interface. Then you'd wire a pair of pins configured for SoftwareSerial to the next Arduino's Serial pins (D0/D1) and so forth. Then you could echo the serial traffic received up and down the chain as necessary, with every member of the chain deciding whether it should respond as appropriate.

\$\endgroup\$
  • \$\begingroup\$ Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at. \$\endgroup\$ – vicatcu Apr 16 at 21:55
  • \$\begingroup\$ Thanks, I've decided the only practical method is to tie the two Rx lines together. It means physically modifying the original controller, but that appears unavoidable. \$\endgroup\$ – Jim Mack Apr 17 at 0:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.