Can a USB port passively 'listen only'?Connect to Arduino Mega serial interface by C codeIs my SparkFun RS232 Shifter SMD faulty?Firmware & Circuit of ATtiny45 direct USB 2.0 ConnectionChaining Multiple USB Hub Controllers for Serial InterfacingATMEGA328P send MIDI via USB10Mbs USB to serial communicationμC <-> USB <-> μC advice please!Serial Over USB Reading With GNU Octave ProblemsHow can I convert from 12v serial to 5v serial?
Anonymous reviewer disclosed his identity. Should I thank him by name?
SHA3-255, one bit less
My second game: War Card game V.1
Does it require less energy to reach the Sun from Pluto's orbit than from Earth's orbit?
As an interviewer, how to conduct interviews with candidates you already know will be rejected?
Non-electric Laser
Could quantum computing help resolve some computability problems like p vs np or the halting problem?
Determine the Winner of a Game of Australian Football
Maintaining distance
Can 35 mm film which went through a washing machine still be developed?
Use floats or doubles when writing mobile games
Is Zhent just the term for any member of the Zhentarim?
How come the Russian cognate for the Czech word "čerstvý" (fresh) means entirely the opposite thing (stale)?
Coffee Grounds and Gritty Butter Cream Icing
Search for something difficult to count/estimate
What benefits are there to blocking most search engines?
Would we have more than 8 minutes of light, if the sun "went out"?
How fast are we moving relative to the CMB?
The work of mathematicians outside their professional environment
Are there any tricks to pushing a grand piano?
Using the Grappler feat, can you grapple and pin (restrain) in the same action?
What kind of nut is this
Network dynamic failover does not work if IP address differs between ethernet and wifi
Should I be able to see patterns in a HS256 encoded JWT?
Can a USB port passively 'listen only'?
Connect to Arduino Mega serial interface by C codeIs my SparkFun RS232 Shifter SMD faulty?Firmware & Circuit of ATtiny45 direct USB 2.0 ConnectionChaining Multiple USB Hub Controllers for Serial InterfacingATMEGA328P send MIDI via USB10Mbs USB to serial communicationμC <-> USB <-> μC advice please!Serial Over USB Reading With GNU Octave ProblemsHow can I convert from 12v serial to 5v serial?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;
$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?
usb serial arduino-uno
edited Apr 16 at 17:55
Dave Tweed♦
137k11 gold badges175 silver badges300 bronze badges
asked Apr 16 at 16:29
Jim MackJim Mack
1365 bronze badges
$endgroup$
add a comment
|
$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?
usb serial arduino-uno
edited Apr 16 at 17:55
Dave Tweed♦
137k11 gold badges175 silver badges300 bronze badges
asked Apr 16 at 16:29
Jim MackJim Mack
1365 bronze badges
$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
add a comment
|
$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?
usb serial arduino-uno
edited Apr 16 at 17:55
Dave Tweed♦
137k11 gold badges175 silver badges300 bronze badges
asked Apr 16 at 16:29
Jim MackJim Mack
1365 bronze badges
$endgroup$
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?
usb serial arduino-uno
usb serial arduino-uno
edited Apr 16 at 17:55
Dave Tweed♦
137k11 gold badges175 silver badges300 bronze badges
asked Apr 16 at 16:29
Jim MackJim Mack
1365 bronze badges
edited Apr 16 at 17:55
Dave Tweed♦
137k11 gold badges175 silver badges300 bronze badges
asked Apr 16 at 16:29
Jim MackJim Mack
1365 bronze badges
edited Apr 16 at 17:55
Dave Tweed♦
137k11 gold badges175 silver badges300 bronze badges
edited Apr 16 at 17:55
Dave Tweed♦
137k11 gold badges175 silver badges300 bronze badges
edited Apr 16 at 17:55
Dave Tweed♦
137k11 gold badges175 silver badges300 bronze badges
137k11 gold badges175 silver badges300 bronze badges
asked Apr 16 at 16:29
Jim MackJim Mack
1365 bronze badges
asked Apr 16 at 16:29
Jim MackJim Mack
1365 bronze badges
asked Apr 16 at 16:29
Jim MackJim Mack
1365 bronze badges
1365 bronze badges
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
add a comment
|
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
6
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$
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$
@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$
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$
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
$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
add a comment
|
4 Answers
4
active
oldest
votes
$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: hin
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: llon
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.
answered Apr 16 at 17:30
Jack BJack B
10.5k1 gold badge22 silver badges38 bronze badges
$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
|
show 8 more comments
$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?
answered Apr 16 at 16:50
JustmeJustme
7,9852 gold badges8 silver badges22 bronze badges
$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
add a comment
|
$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.
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).
answered Apr 17 at 15:39
Ale..chenskiAle..chenski
31.8k1 gold badge22 silver badges73 bronze badges
$endgroup$
add a comment
|
$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.
answered Apr 16 at 21:53
vicatcuvicatcu
16.7k8 gold badges64 silver badges136 bronze badges
$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
add a comment
|
Your Answer
StackExchange.ifUsing("editor", function ()
return StackExchange.using("schematics", function ()
StackExchange.schematics.init();
);
, "cicuitlab");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "135"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f432888%2fcan-a-usb-port-passively-listen-only%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
$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: hin
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: llon
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.
answered Apr 16 at 17:30
Jack BJack B
10.5k1 gold badge22 silver badges38 bronze badges
$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
|
show 8 more comments
$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: hin
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: llon
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.
answered Apr 16 at 17:30
Jack BJack B
10.5k1 gold badge22 silver badges38 bronze badges
$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
|
show 8 more comments
$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: hin
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: llon
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.
answered Apr 16 at 17:30
Jack BJack B
10.5k1 gold badge22 silver badges38 bronze badges
$endgroup$
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: hin
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: llon
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.
answered Apr 16 at 17:30
Jack BJack B
10.5k1 gold badge22 silver badges38 bronze badges
edited Apr 16 at 19:14
answered Apr 16 at 17:30
Jack BJack B
10.5k1 gold badge22 silver badges38 bronze badges
answered Apr 16 at 17:30
Jack BJack B
10.5k1 gold badge22 silver badges38 bronze badges
answered Apr 16 at 17:30
Jack BJack B
10.5k1 gold badge22 silver badges38 bronze badges
10.5k1 gold badge22 silver badges38 bronze badges
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
|
show 8 more comments
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
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$
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
$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
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$
@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
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
Apr 16 at 17:56
1
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
$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
|
show 8 more comments
$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?
answered Apr 16 at 16:50
JustmeJustme
7,9852 gold badges8 silver badges22 bronze badges
$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
add a comment
|
$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?
answered Apr 16 at 16:50
JustmeJustme
7,9852 gold badges8 silver badges22 bronze badges
$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
add a comment
|
$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?
answered Apr 16 at 16:50
JustmeJustme
7,9852 gold badges8 silver badges22 bronze badges
$endgroup$
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?
answered Apr 16 at 16:50
JustmeJustme
7,9852 gold badges8 silver badges22 bronze badges
answered Apr 16 at 16:50
JustmeJustme
7,9852 gold badges8 silver badges22 bronze badges
answered Apr 16 at 16:50
JustmeJustme
7,9852 gold badges8 silver badges22 bronze badges
answered Apr 16 at 16:50
JustmeJustme
7,9852 gold badges8 silver badges22 bronze badges
7,9852 gold badges8 silver badges22 bronze badges
$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
add a comment
|
$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
$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
$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
add a comment
|
$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.
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).
answered Apr 17 at 15:39
Ale..chenskiAle..chenski
31.8k1 gold badge22 silver badges73 bronze badges
$endgroup$
add a comment
|
$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.
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).
answered Apr 17 at 15:39
Ale..chenskiAle..chenski
31.8k1 gold badge22 silver badges73 bronze badges
$endgroup$
add a comment
|
$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.
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).
answered Apr 17 at 15:39
Ale..chenskiAle..chenski
31.8k1 gold badge22 silver badges73 bronze badges
$endgroup$
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.
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).
answered Apr 17 at 15:39
Ale..chenskiAle..chenski
31.8k1 gold badge22 silver badges73 bronze badges
answered Apr 17 at 15:39
Ale..chenskiAle..chenski
31.8k1 gold badge22 silver badges73 bronze badges
answered Apr 17 at 15:39
Ale..chenskiAle..chenski
31.8k1 gold badge22 silver badges73 bronze badges
answered Apr 17 at 15:39
Ale..chenskiAle..chenski
31.8k1 gold badge22 silver badges73 bronze badges
31.8k1 gold badge22 silver badges73 bronze badges
add a comment
|
add a comment
|
$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.
answered Apr 16 at 21:53
vicatcuvicatcu
16.7k8 gold badges64 silver badges136 bronze badges
$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
add a comment
|
$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.
answered Apr 16 at 21:53
vicatcuvicatcu
16.7k8 gold badges64 silver badges136 bronze badges
$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
add a comment
|
$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.
answered Apr 16 at 21:53
vicatcuvicatcu
16.7k8 gold badges64 silver badges136 bronze badges
$endgroup$
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.
answered Apr 16 at 21:53
vicatcuvicatcu
16.7k8 gold badges64 silver badges136 bronze badges
edited Apr 16 at 22:26
answered Apr 16 at 21:53
vicatcuvicatcu
16.7k8 gold badges64 silver badges136 bronze badges
answered Apr 16 at 21:53
vicatcuvicatcu
16.7k8 gold badges64 silver badges136 bronze badges
answered Apr 16 at 21:53
vicatcuvicatcu
16.7k8 gold badges64 silver badges136 bronze badges
16.7k8 gold badges64 silver badges136 bronze badges
$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
add a comment
|
$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
$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$
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
$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
add a comment
|
Thanks for contributing an answer to Electrical Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f432888%2fcan-a-usb-port-passively-listen-only%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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