Tips på hur man skapar seriös USB kommunikation?

Permalänk

Tips på hur man skapar seriös USB kommunikation?

Hej!

Jag har ett litet projekt som jag vill bygga i Java och lite C, mest Java. Min idé är att skapa kommunikation mellan en PC och en annan typ av PC t.ex. Raspberry Pi. Rasperry Pi:n i sin tur ska ha USB anslutning med en Arduino.

En Arduino är ett styrkort för "hemmabruk", men det börjar bli allt mer vanligt att Arduino används i mera seriösa projekt på grund utav den låga utvecklingskostnaden Arduino erbjuder. När jag menar styrkort så menar jag en IC-krets som kan läsa utav ingångar och utgångar samt styra utgångar och ingångar.

Med ett styrkort så kan man styra relän, motorer, servo, lampor med mera. I Arduino så kan man även ha USB kommunikation och det är här min fråga kommer:

När jag har haft USB kommunikation mellan styrkort så har jag alltid programmerat en "switch case" som läser utav ingången på styrkoret. Så om jag skickar strängen "1" då ska utgång 20 vara ON och om jag skickar strängen "2" så ska utgång 20 vara OFF.

Nu är jag väldigt kritisk till denna metodik att skicka kodsträngar igenom USB då jag tycker det känns ganska "billig" lösning, trots att den fungerar. Har ni någon tips på hur man skapar en seriös USB kommunikation?

Permalänk
Medlem

Varför ens använda USB? Vanlig seriekommunikation lär ge dig betydligt mindre huvudvärk.

Visa signatur

Spela Swemantle! Du vet att du vill.

Ibland har jag fel, men då är det någon annans fel.

Permalänk
Skrivet av LemonIllusion:

Varför ens använda USB? Vanlig seriekommunikation lär ge dig betydligt mindre huvudvärk.

USB är standard på styrkort.

Permalänk
Medlem
Skrivet av heretic16:

USB är standard på styrkort.

Fast det är det ju inte. Inte ens om du begränsar dig till Arduinos är USB något du kan räkna med att alla har stöd för. Däremot kan du ge dig på att vilken mikroprocessor som helst fixar vanlig seriekommunikation.

Visa signatur

Spela Swemantle! Du vet att du vill.

Ibland har jag fel, men då är det någon annans fel.

Permalänk
Medlem

USB är ju seriekommunikation Men sen finns det olika protokoll, t.ex. RS232 som är vanligt protokoll för diverse styrkort/moderkort/integrerade grejer.

@heretic16 Jag förstår inte riktigt din fråga.

För det första, varför koppla Dator -> RPi -> Arduino, när du kan styra reläer/switchar/motorer osv direkt från RPi. Känns som lite kaka på kaka.

Sen förstår jag inte riktigt vad du inte gillar med kommunikationen över USB, eller ens vad det är för någon form av kommunikation du vill skapa. Kan du utveckla det lite?

Permalänk
Skrivet av LemonIllusion:

Fast det är det ju inte. Inte ens om du begränsar dig till Arduinos är USB något du kan räkna med att alla har stöd för. Däremot kan du ge dig på att vilken mikroprocessor som helst fixar vanlig seriekommunikation.

Skrivet av elBenko:

USB är ju seriekommunikation Men sen finns det olika protokoll, t.ex. RS232 som är vanligt protokoll för diverse styrkort/moderkort/integrerade grejer.

Nu är jag inte expert något på protokoll eller "USB-programmering". Arduino är lite mer som C++ som används som Java. All Arduino kod kan du använda till alla Arduino's, oavsett vad det är för hårdvara. Det har med att utvecklingsverktyget måste först veta om vilket typ av kort man utvecklar mot, där efter kan utvecklingsverktyget bränna den anpassade koden.

De flesta Arduino's brukar ha USB-B uttag och i Arduino så använder man serialbiblioteket så här. Som vi ser här så startar vi alltid i funktionen setup() och den körs EN gång. Där efter så körs loop() hela tiden. I setup() så deklarerar vi hastigheten till 9600 bit per sekund och vi använder klassen Serial för att anropa dessa metoder så som Serial.available() om det finns data som köar och Serial.write när vi vill skicka något från Arduino:n till PC:n.

int firstSensor = 0; // first analog sensor int secondSensor = 0; // second analog sensor int thirdSensor = 0; // digital sensor int inByte = 0; // incoming serial byte void setup() { // start serial port at 9600 bps: Serial.begin(9600); while (!Serial) { ; // wait for serial port to connect. Needed for native USB port only } pinMode(2, INPUT); // digital sensor is on digital pin 2 establishContact(); // send a byte to establish contact until receiver responds } void loop() { // if we get a valid byte, read analog ins: if (Serial.available() > 0) { // get incoming byte: inByte = Serial.read(); // read first analog input, divide by 4 to make the range 0-255: firstSensor = analogRead(A0) / 4; // delay 10ms to let the ADC recover: delay(10); // read second analog input, divide by 4 to make the range 0-255: secondSensor = analogRead(1) / 4; // read switch, map it to 0 or 255L thirdSensor = map(digitalRead(2), 0, 1, 0, 255); // send sensor values: Serial.write(firstSensor); Serial.write(secondSensor); Serial.write(thirdSensor); } } void establishContact() { while (Serial.available() <= 0) { Serial.print('A'); // send a capital A delay(300); } }

Permalänk
Skrivet av elBenko:

USB är ju seriekommunikation Men sen finns det olika protokoll, t.ex. RS232 som är vanligt protokoll för diverse styrkort/moderkort/integrerade grejer.

@heretic16 Jag förstår inte riktigt din fråga.

För det första, varför koppla Dator -> RPi -> Arduino, när du kan styra reläer/switchar/motorer osv direkt från RPi. Känns som lite kaka på kaka.

Sen förstår jag inte riktigt vad du inte gillar med kommunikationen över USB, eller ens vad det är för någon form av kommunikation du vill skapa. Kan du utveckla det lite?

Mitt mål är att använda mjukvaran ModBus för att kommunicera med andra datorer. Så tänk att du har flera datorer där din dator är master, andra datorer är billiga slavar som drivs av något enkelt Linux OS. På alla dina slavar har du en Arduino inkopplat.

Så vad kan man göra med detta? Jo, tänk att du utvecklar en applikation i Java på din PC och sedan för du över den till din smarttelefon. Så länge du har internetanslutning så kan du ansluta dina slavar och säga åt dessa vad dem ska göra med de analoga och digitala in- och utgångarna på sina Arduinos.

Det blir nästan som en PLC, fast mera mot styrkort. PLC är programmerbara och det jag tänkte göra är mest bara enkel styrning där mastern säger åt vad slavarna ska göra.

Permalänk
Medlem
Citat:

Arduino är lite mer som C++ som används som Java.

Wat?

Citat:

All Arduino kod kan du använda till alla Arduino's, oavsett vad det är för hårdvara.

Nej, bara nej. Hårdvaran sätter givetvis begränsningar på hur programmet kan se ut.

Citat:

De flesta Arduino's brukar ha USB-B uttag

De flesta Arduinos brukar ha ett inbyggt USB-anslutet serieinterface för att du ska kunna programmera den enkelt. Det är inte att likställa med att faktiskt ha stöd för USB som exempelvis Arduino Leonardo med sin ATmega32U4 har.

Citat:

och i Arduino så använder man serialbiblioteket så här. ...

Vad är din poäng? Skriver du en nybörjarguide eller behöver du tips på hur du ska förverkliga din idé?

Visa signatur

Spela Swemantle! Du vet att du vill.

Ibland har jag fel, men då är det någon annans fel.

Permalänk
Skrivet av LemonIllusion:

Vad är din poäng? Skriver du en nybörjarguide eller behöver du tips på hur du ska förverkliga din idé?

Jag frågar om det är seriöst att skriva en kommunikationsmetod mellan två enheter som bygger på kodsträngar. Eller ska koden vara ASCII-kod istället?

Så om jag skickar nummret 49 till min Ardiono så ska 49 betyda en viss funktion för en viss typ av utgång eller ingång. Är detta seriös kommunikation, eller är det en utåldrig och dåligt sätt att bygga kommunikation på?

Permalänk
Medlem
Skrivet av heretic16:

Jag frågar om det är seriöst att skriva en kommunikationsmetod mellan två enheter som bygger på kodsträngar. Eller ska koden vara ASCII-kod istället?

Så om jag skickar nummret 49 till min Ardiono så ska 49 betyda en viss funktion för en viss typ av utgång eller ingång. Är detta seriös kommunikation, eller är det en utåldrig och dåligt sätt att bygga kommunikation på?

Ett bra protokoll är enkelt att förstå och enkelt att använda. Att skicka "SET 20 ON" ASCII-kodat må vara lätt att förstå, men textsträngar är i allmänhet jobbigt att hantera, särskilt när du har begränsad prestanda. Dessutom kan samma budskap kan förmedlas med betydligt mindre data skickad med ett mer genomtänkt protokoll. Ett exempel skulle kunna vara att skicka heltalen 1, 1, 20 efter varandra där första ettan står för funktion (set pin state), andra för nya tillståndet (hög) och 20 för pinnen som ska påverkas. Förutsatt att du dokumenterar ordentligt är detta både lätt att förstå och lätt att implementera. Om du inte behöver så många olika kommandon i ditt protokoll kan du till och med trycka in allt detta i en byte, men det kanske är att dra det lite väl långt. Det låter inte som att du behöver göra allt för att maximera prestandan, så prioritera hellre ett lättförståeligt och lättunderhållet protokoll.

Visa signatur

Spela Swemantle! Du vet att du vill.

Ibland har jag fel, men då är det någon annans fel.

Permalänk
Medlem

Först för att klara upp lite: På arduino sidan gör du inte USB kommunikation, utan vanlig simpel seriekommunikation. Samma som om du hade kört RS232 direkt. USB kontakten är bara en enkel USB-till-TTL-seriekommunikationsadapter, troligen ett FTDI eller CH340 chip, vilket mest är till för att du ska kunna koppla in enheten varsomhelst.

Jag är inte säker på att jag förstår vad du menar med "seriös USB kommunikation", men jag tolkar det som att du vill ha ett finare, mer avancerat/utökningsbart protokoll än det simpla en-karaktär-per-kommando protokollet du gjort nu? Jag kan tänka mig att det redan finns lite färdiga bibliotek för att få ett lite finare "kommandorads interface" till Arduino, men annars hade jag väl skrivit ett eget i stil med följande (obs lite pseudokod och så. Ej prövat att kompilera):

const uint OPERATOR_BUF_SIZE = 128; const uint OPERANDS_BUF_SIZE = 10; const uint LINE_BUF_SIZE = 256; enum OperandType { INT, FLOAT, }; struct Operand { OperandType type; union { int i; float f; }; }; struct Command { char operator[OPERATOR_BUF_SIZE]; Operand operands[OPERANDS_BUF_SIZE]; uint n_operands; }; bool read_serial_line(char* buf, uint buf_size) { for (uint i = 0; Serial.available() > 0; i++) { if (i >= (buf_size - 1)) { return false; } char c = Serial.read(); if (c == '\n') { buf[i] = '\0'; } else { buf[i] = c; } } return true; } bool parse_operator(char** ss, char* op_out) { char* s = *ss; char* first_space = strchr(s, ' '); if (first_space != NULL) { *first_space = '\0'; } strcpy(op_out, s); *ss = s + strlen(s) + 1; return true; } bool parse_operand(char* s, Operand* op_out) { if (strchr(s, '.')) { op_out->type = FLOAT; op_out->f = atof(s); } else { op_out->type = INT; op_out->i = atoi(s); } } bool parse_operands(char* s, Operand* ops_out, uint* n_ops_out) { char* boundary; uint i; for (i = 0; boundary = strchr(s, ' '); i++) { *boundary = '\0'; if (!parse_operand(s, &ops_out[i])) { return false; } s = boundary + 1;; } *n_ops_out = i; return true; } bool parse_command(char* s, Command* cmd_out) { char** ss = &s; return parse_operator(ss, &cmd_out->operator) && parse_operands(*ss, &cmd_out->operands, &cmd_out->n_operands); } /// Returns whether the command read was successful bool read_serial_command(Command* cmd_out) { char line_s[LINE_BUF_SIZE]; if (!read_serial_line(line_s, LINE_BUF_SIZE)) { return false; } return parse_command(line_s, cmd_out); } bool execute_set(Operand* args, uint n_args) { if (n_args > 0 && args[0].type == INT) { uint port = args[0].i; if (n_args == 1) { digitalWrite(port, HIGH); return true; } else if (n_args == 2 && args[1].type == FLOAT && args[1].f <= 1.0) { analogWrite(port, (int)(args[1].f * 255.0 + 0.5)); return true; } } return false; } bool execute_unset(Operand* args, uint n_args) { if (n_args == 1 && args[0].type == INT) { digitalWrite(args[0].i, LOW); return true; } else { return false; } } // Commands: // SET (int PORT) // Sets the value of a port to `1` // SET (int PORT) (float VALUE) // Sets the value of a port to `VALUE` [0.0, 1.0] // UNSET (int PORT) // Sets the value of a port to `0` /// Returns whether the command execution was successful bool execute_command(Command cmd) { switch (cmd.operator) { case "SET": return execute_set(cmd.operands, cmd.n_operands); case "UNSET": return execute_unset(cmd.operands, cmd.n_operands); default: return false; } } void loop() { Command cmd; if (!read_serial_command(&cmd)) { Serial.write("Error reading command"); } else if (!execute_command(cmd)) { Serial.write("Error executing command"); } }

Med ovan kod skulle du kommunicera över serieporten med ett text-baserat protokoll. Att lägga till nya kommandon är så enkelt som att lägga till ett nytt `case` i `execute_command` och funktion motsvarande `execute_set`/`execute_unset` som verifierar parametrar och kör kommandot.

Exempelkommandon med nuvarande kodexemplet:

Sätt på port 3 / sätt port 3 till HIGH: > SET 3 Sätt port 20 till en halv, i.e. `analogWrite(20, 127)`: > SET 20 0.5 Stäng av port 10 / sätt port 10 till 0: > UNSET 10

Ett övrigt tips till nästa gång du gör en sån här post är att du fokuserar mer på din frågeställning och mindre på bakgrundsbeskrivning. Om folk inte redan vet vad arduinos är lär de inte heller kunna besvara frågor relaterade till dem.

Visa signatur

Arbets- / Spelstation: Arch Linux - Ryzen 5 3600 - RX 7900 XT - 32G DDR4
Server: Arch Linux - Core i5-10400F - 16G DDR4

Permalänk
Skrivet av Bryal:

Jag är inte säker på att jag förstår vad du menar med "seriös USB kommunikation", men jag tolkar det som att du vill ha ett finare, mer avancerat/utökningsbart protokoll än det simpla en-karaktär-per-kommando protokollet du gjort nu? Jag kan tänka mig att det redan finns lite färdiga bibliotek för att få ett lite finare "kommandorads interface" till Arduino, men annars hade jag väl skrivit ett eget i stil med följande (obs lite pseudokod och så. Ej prövat att kompilera):

Ja. Jag är mer intresserad utav lite mera finare protokoll än simpla ett-bitt-i-taget-kommunikation. Tror ni att ModBus skulle vara ett bra alternativ för mig?

Permalänk
Medlem
Skrivet av heretic16:

Ja. Jag är mer intresserad utav lite mera finare protokoll än simpla ett-bitt-i-taget-kommunikation. Tror ni att ModBus skulle vara ett bra alternativ för mig?

1. Det finns väldigt få universala protokoll som inte är seriella bortsett saker som pcie och likande som behöver enorm bandbredd och de är oftast över kortare avstånd.

2. Du kan göra parallella protokoll men vad är det du måste skicka som är så krävande att det berättigar arbetet?

Det känns som att du sitter på massor av halvfärdig kunskap och skapat enda lösningar på det, min rekommendation vore att tex följa en guide om just olika kommunikation med arduino.
Jag har gjort liknande, inget fel i det men du gör dig själv ingen tjänst att göra antaganden om kunskap.

Skickades från m.sweclockers.com

Visa signatur

"One is always considered mad, when one discovers something that others cannot grasp."
- Ed Wood

Permalänk
Skrivet av Ferrat:

Det känns som att du sitter på massor av halvfärdig kunskap och skapat enda lösningar på det, min rekommendation vore att tex följa en guide om just olika kommunikation med arduino.
Jag har gjort liknande, inget fel i det men du gör dig själv ingen tjänst att göra antaganden om kunskap.

Skickades från m.sweclockers.com

Jag har hållit på med enkel seriell kommunikation med Arduino och det var inte svårt, men jag tyckte att det gick rätt segt.

Permalänk
Medlem

@herectic16

Vad är 'fint' i dina ögon?? - sådant är högst subjektivt. För en som felsöker i fältet ett antal år senare ser gärna en ASCII-baserat protokoll med tydliga kommandon som kan sniffas via serieport eller annan nivå-adapter.

För dataintrigtet så kanske man vill ha det i paket med synk-sekvens i början och checksumma i slutet för att veta att paketet är helt och komplett utan korruption - och i svårt störda fall tom. med FEC för att inte behöva repetera meddelandet för många gånger och ta upp bandbredd i onödan.

en stor del av protokollet är i hur man skall hantera olika felsituationer, störningar, hur den gör när det inte kommer svar mm.

Paketorientering brukar också behövas i samband kanalkodning för att tex. kunna passera galvaniskt isolerande barriärer som ethernet-trafo - skall du koppla till en sak rummet bredvid så behöver du en isolerande barriär såvida inte ändprylen är helt försörjd med spänning via kommunicerade kabeln eller matad med en dubbelsiolerad väggvårta (som dessvärre ändå är en osäkerhetsfaktor med dagens kina-krafter)

Mycket av de nämnda problemem försvinner om all signalering går redan från början via en trafo - precis som Ethernet har gjort från dag 1. men då krävs lite skill i protokoll-skrivandet och en del klurighet för kanalkodningen om man skall använda den befintliga UART för en resulterande DC-neutral (över en antal bitar räknat) pulståg ut

Protokoll är sannerligen inget man skriver ihop på en kafferrast och början är att studera andra protokoll och se vad som är bra eller dåligt med dem.

tänk på att många protokoll är gamla och skrivet efter dom fysisk förutsättningar och ofta inte så höga ambitionerna för vidareutveckling (främst hastighetsmässigt) vid den tiden och många av dem inte tål längre sträckor och/eller köras med högre takt för att man varit ignoranta för tex. transmissionsmässiga egenskaper, jordströmmar i kablar och skärmar, inte kan passera transformator som isolerande barriär etc. etc.

tex RS485-signalering kan passera trafos rent tekniskt - men få protokoll är skrivna för det eftersom man använder inbyggda UART i MCU:erna anpassad för RS232 och kanalkodningen därmed inte är DC-neutralt och därför inte fungerar att transporteras via isolerande trafos. (vid för många '1' eller '0' i rad så går trafon i magnetisk mättning i endera kanten)

titta och utvärdera olika (ofta hemsnikrade protokoll) tex. över R485, mod-bus, 1-wire, i2c mfl. och fundera på hur långa sträckor du skall köra, hur fort och om de skall gå till andra rum med andra jordpotentialer i sina eluttag - USB är ingen hit om du skall ha mer än fåtal metrar och det är heller inte galvaniskt isolerande mellan enheter vilket innebär trubbel med jordströmmar om du skall ha apparater utanför samma rum och matande stickpropp.

Permalänk
Medlem
Skrivet av heretic16:

Jag har hållit på med enkel seriell kommunikation med Arduino och det var inte svårt, men jag tyckte att det gick rätt segt.

Arduino är inte super snabb men är du säker att du får ut max? vet inte mycket mycket data du måste föra över men arduino kör 16Mhz, du borde kunna få upp det i iaf 1Mbit över SPI om du inte har extremt mycket annat som kör, en ascii tar 8bit.
1E6/8 = 125 000, med 125 000 borde du ha så det räcker och blir över att skicka med då du bara skickar ett bar chars antar jag, så vi snackar överföringstider av ett par ms kanske max.
Ditt problem är nog snarare latens av olika slag, det löser du genom att effektivisera koden och lära dig alla arduinos olika hårdvaru grejer etc, interrupts kan nog hjälpa här t.ex.

Menar inte att verka negativ, du kommer tjäna mer på att lära dig vad den faktiskt kan göra istället för säga vad du vill den ska göra, i vissa fall kanske du måste ha viss hårdvara runt för att lösa vissa saker osv. Det är lätt att använda men svårt att bemästra saker som t.ex. arduino, jag är inte fyskam på det, senast i våras byggde vi en robot med motorer och sensorer på min utbildning med just arduino som kärna och kan säga att jag är en av de bättre i min klass av ~50+ Elektroteknikstuderande på just arduino och programmering. Jag vet inte ens hälften av vad en arduino kan göra på rak arm och har ändå läst nästan hela Atmel manualen för chippet.

Över USB kommer du aldrig få något bra resultat är min gissning, tror du underskattar vad du kan göra med I/O med, om du bara ska switcha pga olika conditions så varför inte bara länka Arduinon och Pi'ens I/O och sköt det så? RPi är absurt mycket snabbare än arduino så den kan lätt ta emot sådana signaler och ha ett loopande program i bakgrunden som gör det du vill beroende på input?

Visa signatur

"One is always considered mad, when one discovers something that others cannot grasp."
- Ed Wood

Permalänk
Skrivet av Ferrat:

Arduino är inte super snabb men är du säker att du får ut max? vet inte mycket mycket data du måste föra över men arduino kör 16Mhz, du borde kunna få upp det i iaf 1Mbit över SPI om du inte har extremt mycket annat som kör, en ascii tar 8bit.
1E6/8 = 125 000, med 125 000 borde du ha så det räcker och blir över att skicka med då du bara skickar ett bar chars antar jag, så vi snackar överföringstider av ett par ms kanske max.
Ditt problem är nog snarare latens av olika slag, det löser du genom att effektivisera koden och lära dig alla arduinos olika hårdvaru grejer etc, interrupts kan nog hjälpa här t.ex.

Menar inte att verka negativ, du kommer tjäna mer på att lära dig vad den faktiskt kan göra istället för säga vad du vill den ska göra, i vissa fall kanske du måste ha viss hårdvara runt för att lösa vissa saker osv. Det är lätt att använda men svårt att bemästra saker som t.ex. arduino, jag är inte fyskam på det, senast i våras byggde vi en robot med motorer och sensorer på min utbildning med just arduino som kärna och kan säga att jag är en av de bättre i min klass av ~50+ Elektroteknikstuderande på just arduino och programmering. Jag vet inte ens hälften av vad en arduino kan göra på rak arm och har ändå läst nästan hela Atmel manualen för chippet.

Över USB kommer du aldrig få något bra resultat är min gissning, tror du underskattar vad du kan göra med I/O med, om du bara ska switcha pga olika conditions så varför inte bara länka Arduinon och Pi'ens I/O och sköt det så? RPi är absurt mycket snabbare än arduino så den kan lätt ta emot sådana signaler och ha ett loopande program i bakgrunden som gör det du vill beroende på input?

Jag tror att SPI fungerar bra för mig. Jag byggde SPI själv igenom att knacka pascal-kod för PLC en gång i tiden. Fungerade bra. En fördel med Arduino är att dem har redan färdigt SPI bibliotek.

Du menar att jag ska bygga hjulet på nytt för att lära mig?

Permalänk
Medlem

Kom ihåg att SPI (för kommunikation inom kretskort och användes långt innan för olika skifterregister mm innan Motorola satte varumärke på gränssnittet) och I2C (för kommunikation inom apparatskal som TV-apparater som Philips en gång designade) är inte avsedda för inkoppling av perferi som involverar mer än några dm kabel och allt försörjs av samma strömförsörjning och kopplas till samma jord.

Så fort du skall ha oberoende separata enheter utanför apparatlåda, har egen kraft (jordad eller dubbelisolerad spelar ingen roll) eller kabel till annat rum så bör ni titta på RS485 och helst med galvaniskt isolerande drivers - ja om man inte kör på färdiga ethernet nätverksanslutningar...

Så fort det är lite kabellängd så måste man gå ned i fart och då kan SPI-gränssnittet gå lite väl snabbt om inte klockan går att styra över från några 10tal kHz till många MHz. - tänk på att kabel är stökig impedansmässigt med komplexa impedanser när man är under 200 kHz (ger kraftigt avrundade pulståg att de kan se ut som nästa som sågtandsvåg för att olika frekvenskomponenter som bygger 4-kantvågen dämpas olika kraftigt på olika frekvenser - samt reflexer ger ringningar) .. och dämpningen är en faktor att räkna med när man är över 200 kHz

Kör balanserat - även på obalanserade utgångar och ledningar genom att ha en returledare (aka jord) inkopplad så nära utgångspinnen av datautgången som möjligt) _på varje signal_ mha. tvistad par. Aldrig någonsin att man använder gemensam ensam jordledare för samtliga signalledare, gör man det så är det stor risk för överhörning och fel i överföring och ökar snabbt med kabellängd och använda klockhastighet.

För längsta överföring med hög takt så måste driver och mottagare vara matchad impedansmässigt så att det stämmer med använda kabelns karaktäristiska impedans (att PATA slutade att användas berodde på att man inte respekterade detta och slog huvudet i taket pga. reflexer trots kortade 2-3 dm och extra tätledad bandkabel, medans SCSI vid den tiden körde dubbla takten per ledare på vanlig bandkabel på upp 6 meter kabel utan problem - allt berodde på om systemet var terminerat och impedansanpassat eller inte...) Att ha balanserad utgång och ingång höjer marginalerna avsevärt även i impedansmatchade system.

- all modern överföring i hög takt kör balanserat och inget av det skulle fungera om man körde med samma topologi och geometrier som med tex R232...