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 do we bend a book to keep it straight?
How to react to hostile behavior from a senior developer?
Should I use a zero-interest credit card for a large one-time purchase?
What are the pros and cons of Aerospike nosecones?
Seeking colloquialism for “just because”
Apollo command module space walk?
Can a non-EU citizen traveling with me come with me through the EU passport line?
What LEGO pieces have "real-world" functionality?
How to call a function with default parameter through a pointer to function that is the return of another function?
Identifying polygons that intersect with another layer using QGIS?
Why did the IBM 650 use bi-quinary?
What causes the vertical darker bands in my photo?
At the end of Thor: Ragnarok why don't the Asgardians turn and head for the Bifrost as per their original plan?
Dating a Former Employee
How do database operations (write, update, alter) on particular cell in a table are written to disk without overwriting entire file?
Why aren't air breathing engines used as small first stages
How would the world control an invulnerable immortal mass murderer?
What is Arya's weapon design?
What exactly is a "Meth" in Altered Carbon?
Why did the rest of the Eastern Bloc not invade Yugoslavia?
illegal generic type for instanceof when using local classes
Denied boarding although I have proper visa and documentation. To whom should I make a complaint?
51k Euros annually for a family of 4 in Berlin: Is it enough?
Can an alien society believe that their star system is the universe?
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 3 hours ago
Dave Tweed♦
125k10155269
asked 4 hours ago
Jim MackJim Mack
1143
$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 3 hours ago
Dave Tweed♦
125k10155269
asked 4 hours ago
Jim MackJim Mack
1143
$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
4 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
4 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 3 hours ago
Dave Tweed♦
125k10155269
asked 4 hours ago
Jim MackJim Mack
1143
$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 3 hours ago
Dave Tweed♦
125k10155269
asked 4 hours ago
Jim MackJim Mack
1143
edited 3 hours ago
Dave Tweed♦
125k10155269
asked 4 hours ago
Jim MackJim Mack
1143
edited 3 hours ago
Dave Tweed♦
125k10155269
edited 3 hours ago
Dave Tweed♦
125k10155269
edited 3 hours ago
Dave Tweed♦
125k10155269
125k10155269
asked 4 hours ago
Jim MackJim Mack
1143
asked 4 hours ago
Jim MackJim Mack
1143
asked 4 hours ago
Jim MackJim Mack
1143
1143
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
4 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
4 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
4 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
4 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
4 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
4 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
4 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
4 hours ago
add a comment |
2 Answers
2
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 3 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
3 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
3 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
3 hours ago
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
3 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
3 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 4 hours ago
JustmeJustme
2,4261413
$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
4 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
2 Answers
2
active
oldest
votes
2 Answers
2
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 3 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
3 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
3 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
3 hours ago
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
3 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
3 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 3 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
3 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
3 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
3 hours ago
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
3 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
3 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 3 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 3 hours ago
Jack BJack B
10.2k12137
edited 1 hour ago
answered 3 hours ago
Jack BJack B
10.2k12137
answered 3 hours ago
Jack BJack B
10.2k12137
answered 3 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
3 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
3 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
3 hours ago
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
3 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
3 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
3 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
3 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
3 hours ago
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
3 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
3 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
3 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
3 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
3 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
3 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
3 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
3 hours ago
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
3 hours ago
$begingroup$
@JimMack Glad it was helpful.
$endgroup$
– Jack B
3 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
3 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
3 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 4 hours ago
JustmeJustme
2,4261413
$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
4 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 4 hours ago
JustmeJustme
2,4261413
$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
4 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 4 hours ago
JustmeJustme
2,4261413
$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 4 hours ago
JustmeJustme
2,4261413
answered 4 hours ago
JustmeJustme
2,4261413
answered 4 hours ago
JustmeJustme
2,4261413
answered 4 hours ago
JustmeJustme
2,4261413
2,4261413
$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
4 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
4 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
4 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
4 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
4 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
4 hours ago