Can a USB port passively 'listen only'? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)Connect to Arduino Mega serial interface by C codeIs my SparkFun RS232 Shifter SMD faulty?Writing to a Parallel to USB convertorDual power supply confusing TTL serial?Firmware & Circuit of ATtiny45 direct USB 2.0 ConnectionConnecting three keytars to the NESChaining Multiple USB Hub Controllers for Serial InterfacingATMEGA328P send MIDI via USB10Mbs USB to serial communicationArduino TTL level converters 5V -> 3.3V
Why are Kinder Surprise Eggs illegal in the USA?
Using audio cues to encourage good posture
When a candle burns, why does the top of wick glow if bottom of flame is hottest?
How to answer "Have you ever been terminated?"
Why did the IBM 650 use bi-quinary?
3 doors, three guards, one stone
Fundamental Solution of the Pell Equation
Why do we bend a book to keep it straight?
How do I stop a creek from eroding my steep embankment?
Why are there no cargo aircraft with "flying wing" design?
Using et al. for a last / senior author rather than for a first author
How to bypass password on Windows XP account?
Denied boarding although I have proper visa and documentation. To whom should I make a complaint?
How to react to hostile behavior from a senior developer?
How to call a function with default parameter through a pointer to function that is the return of another function?
Apollo command module space walk?
porting install scripts : can rpm replace apt?
What LEGO pieces have "real-world" functionality?
Can a USB port passively 'listen only'?
Should I discuss the type of campaign with my players?
How to deal with a team lead who never gives me credit?
Why aren't air breathing engines used as small first stages
What causes the vertical darker bands in my photo?
Why did the Falcon Heavy center core fall off the ASDS OCISLY barge?
Can a USB port passively 'listen only'?
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)Connect to Arduino Mega serial interface by C codeIs my SparkFun RS232 Shifter SMD faulty?Writing to a Parallel to USB convertorDual power supply confusing TTL serial?Firmware & Circuit of ATtiny45 direct USB 2.0 ConnectionConnecting three keytars to the NESChaining Multiple USB Hub Controllers for Serial InterfacingATMEGA328P send MIDI via USB10Mbs USB to serial communicationArduino TTL level converters 5V -> 3.3V
.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 9 hours ago
Dave Tweed♦
125k10155269
asked 11 hours ago
Jim MackJim Mack
1264
$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 9 hours ago
Dave Tweed♦
125k10155269
asked 11 hours ago
Jim MackJim Mack
1264
$endgroup$
4
$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
11 hours ago
$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
11 hours ago
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 9 hours ago
Dave Tweed♦
125k10155269
asked 11 hours ago
Jim MackJim Mack
1264
$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 9 hours ago
Dave Tweed♦
125k10155269
asked 11 hours ago
Jim MackJim Mack
1264
edited 9 hours ago
Dave Tweed♦
125k10155269
asked 11 hours ago
Jim MackJim Mack
1264
edited 9 hours ago
Dave Tweed♦
125k10155269
edited 9 hours ago
Dave Tweed♦
125k10155269
edited 9 hours ago
Dave Tweed♦
125k10155269
125k10155269
asked 11 hours ago
Jim MackJim Mack
1264
asked 11 hours ago
Jim MackJim Mack
1264
asked 11 hours ago
Jim MackJim Mack
1264
1264
4
$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
11 hours ago
$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
11 hours ago
add a comment |
4
$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
11 hours ago
$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
11 hours ago
4
4
$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
11 hours ago
$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
11 hours ago
$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
11 hours ago
$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
11 hours ago
add a comment |
3 Answers
3
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 10 hours ago
Jack BJack B
10.2k12137
$endgroup$
2
$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
10 hours ago
$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
10 hours ago
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
10 hours ago
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
9 hours ago
$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
9 hours ago
|
show 2 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 11 hours ago
JustmeJustme
2,4361413
$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
10 hours ago
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 6 hours ago
vicatcuvicatcu
16.2k862131
$endgroup$
$begingroup$
Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at.
$endgroup$
– vicatcu
5 hours ago
$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
2 hours ago
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/3.0/"u003ecc by-sa 3.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
3 Answers
3
active
oldest
votes
3 Answers
3
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 10 hours ago
Jack BJack B
10.2k12137
$endgroup$
2
$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
10 hours ago
$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
10 hours ago
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
10 hours ago
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
9 hours ago
$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
9 hours ago
|
show 2 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 10 hours ago
Jack BJack B
10.2k12137
$endgroup$
2
$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
10 hours ago
$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
10 hours ago
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
10 hours ago
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
9 hours ago
$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
9 hours ago
|
show 2 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 10 hours ago
Jack BJack B
10.2k12137
$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 10 hours ago
Jack BJack B
10.2k12137
edited 8 hours ago
answered 10 hours ago
Jack BJack B
10.2k12137
answered 10 hours ago
Jack BJack B
10.2k12137
answered 10 hours ago
Jack BJack B
10.2k12137
10.2k12137
2
$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
10 hours ago
$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
10 hours ago
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
10 hours ago
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
9 hours ago
$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
9 hours ago
|
show 2 more comments
2
$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
10 hours ago
$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
10 hours ago
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
10 hours ago
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
9 hours ago
$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
9 hours ago
2
2
$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
10 hours ago
$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
10 hours ago
$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
10 hours ago
$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
10 hours ago
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
10 hours ago
$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
10 hours ago
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
9 hours ago
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
9 hours ago
$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
9 hours ago
$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
9 hours ago
|
show 2 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 11 hours ago
JustmeJustme
2,4361413
$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
10 hours ago
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 11 hours ago
JustmeJustme
2,4361413
$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
10 hours ago
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 11 hours ago
JustmeJustme
2,4361413
$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 11 hours ago
JustmeJustme
2,4361413
answered 11 hours ago
JustmeJustme
2,4361413
answered 11 hours ago
JustmeJustme
2,4361413
answered 11 hours ago
JustmeJustme
2,4361413
2,4361413
$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
10 hours ago
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
10 hours ago
$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
10 hours ago
$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
10 hours ago
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 6 hours ago
vicatcuvicatcu
16.2k862131
$endgroup$
$begingroup$
Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at.
$endgroup$
– vicatcu
5 hours ago
$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
2 hours ago
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 6 hours ago
vicatcuvicatcu
16.2k862131
$endgroup$
$begingroup$
Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at.
$endgroup$
– vicatcu
5 hours ago
$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
2 hours ago
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 6 hours ago
vicatcuvicatcu
16.2k862131
$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 6 hours ago
vicatcuvicatcu
16.2k862131
edited 5 hours ago
answered 6 hours ago
vicatcuvicatcu
16.2k862131
answered 6 hours ago
vicatcuvicatcu
16.2k862131
answered 6 hours ago
vicatcuvicatcu
16.2k862131
16.2k862131
$begingroup$
Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at.
$endgroup$
– vicatcu
5 hours ago
$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
2 hours ago
add a comment |
$begingroup$
Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at.
$endgroup$
– vicatcu
5 hours ago
$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
2 hours ago
$begingroup$
Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at.
$endgroup$
– vicatcu
5 hours ago
$begingroup$
Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at.
$endgroup$
– vicatcu
5 hours ago
$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
2 hours ago
$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
2 hours ago
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
4
$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
11 hours ago
$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
11 hours ago