Strypa hastighet USB (Löst)

[MagnusK]

MagnusK: har du rökt på eller?

Tack för den kommentaren... alltid roligt när folk är trevliga....

Det finns USB<->seriell adaptrar med 5V nivåer, de är dock alltid "specialbeställda".

Special?
Används ju av alla som håller på med arduino och kör via USB t.ex...

https://www.sparkfun.com/tutorials/215

Så , försöker man med en sådan USB->TTL Seriell adapter mot en riktig RS-232 port så lär det ju inte gå?


Däremot kan jag ha fel när det gällde min laptop... antog att det var TTL nivåer då det inte fungerade alls med det jag gjorde till den för den ville ha -12 till +12 spänningar.

[xxargs]

Seroster, xxargs, matsadona, Hur tunga dvs hur häftig processor och minne krävs det för att dra runt de program som använder RS232 porten?

Med UART och FIFO på UART och program skriven i DOS-miljö - typ en 8086-processor på 4,77 MHz och 100 kB program och 250 kB ramminne

Dagens PC och emulering via USB genom transaktionsbaserade USB-stacken så hinner man inte med i alla lägen ens med GB i ram och I7 multicore-kärnor i flera GHz då det inte är kraften och antal instruktioner per sekund som räknas, utan att man inte får resursen på nanosekunden rätt i tid och det är ett topologiskt problem att man försöker lösa kretskopplats näts behov med garanterad hållen delay och kan leverera byte för byte med ett paketorienterad dito mha. USB där man först vill bygga hela paket med kanske kB med data innan det skickas vidare till nästa steg och om det inte får det - har en lång delay och paddar de oanvända byten innan det kommer iväg - nästa steg är en transaktionshanterare som tar hand om paketet och släpper den på bandet (USB...) när det tycker att det passar - men event från musen, tangentbordet, musik till USB-ljuddelen och trafik till den externa HD kan mycket väl gå före än denna viktiga data och och leveransen är oplanerad ryckig tidmässigt samt det är lång tid när första data puttas in i systemet tills det ramlar ut i andra ändan.

På Dostiden var det några få maskinistruktioner att läsa ut registret i UART och man behövde inte knöla med något som hette multitasking mm. och värsta orosmolnet var interruptet från hårddisken och grafikkortet eftersom interupptet från UART hade lägst prioritet i kedjan och program som telix mfl. största kodvolym var just att hantera detta och speciellt innan fifo-UART började bli vanliga så var det typ 10000 interrupt i sekunden (vid 115200 Baud) som skulle hantera i konkurrens med alla andra interuptkällor med högre hårdvaruprioritet - för missade man en enda så tappade man ju ett tecken...



...

[Nerre]

Sitter det en 9-polig eller 25-polig D-SUB som serieport så kan man nog räkna med att det är korrekta RS-232-nivåer på porten. OCH att porten klarar av att kommunicera asynkront med och utan handskakning.

Så är det problem nånstans på grund av att det är USB-ansluten serieport så beror det i 99% av fallen på "dåligt" skriven programvara på datorn.

[Jan Almqvist]

Eller att det man ska kommunicera med är väldigt kinkigt när det gäller timing.

Exempel: Tål inte paus mellan tecken, kräver paus mellan tecken, använder handskakningsignaler på speciellt sätt, etc etc.

[Nerre]

Då uppfyller det man ska kommunicera med troligen inte standarderna. Och det är knappast serieportens fel.

[Icecap]

RS232 har ingen timingskrav eller liknande, RS232 är enbart en beskrivning av spänningsnivåerna! Man kan köra morsekod genom RS232 eller RS422 eller RS485 om man vill, specifikationerna uppfylls likaväl.

MagnusK: det var ju med glimten i ögat med rökningen.

Men OK, att vissa säljare påstår att deras USB-dongel är en "RS232 fast med 5V nivåer" är ju helt enkelt skitsnack! Jämför med fakta först i detta inlägg och förstå att en sådan dongel är som en ostmacka - fast utan ost.

Att de beskriver den på det vis beror på att många inte fattar vad en UART är, hur data utväxlas med en UART osv. men många fattar vad en "default" RS232 är.

[Jan Almqvist]

Hej.
Jag har ett program som ska kommunicera med en givare.
Problemet jag har är att min USB är, enligt tillverkaren, för snabb för att givaren ska hänga med.

Det fungerar i min gamla dator med RS232.

Så frågan är... Hur i helsike stryper jag min USB så att det blir lagom segt för givaren?
Går det att göra i mjukvaran, eller måste det hårvara till, och i så fall vad? Hundra meter RK? =P

Har du undersökt grundläggande saker som att ditt program över huvud taget öppnar din USB-serieport och att baudrate mm är rätt?

I gamla datorn heter porten troligen COM1 men USB-serieporten kan ju få ett annat namn.

[matsadona]

Jag har inte sagt att det är serieportens fel, eller skyllt på någon standard. Och programmet kanske var helt korrekt skrivet enligt de riktlinjer som fanns då (jag sa ju att det var gammal kod och gammal teknik). Det enda jag har påstått är att det inte fungerar när det är en emulerad com-port över USB, oavsett om det är intern på moderkortet eller extern dongel.
xxargs lämnade en ganska utförlig beskrivning av problematiken.

Nu har vi iofs inte hjälpt TS så mycket, men det borde mycket riktigt finnas inställningar att göra i enhetshanterararen (dvs baud rate osv som måste justeras).

[Seroster]

Jan Almqvist: Jag kommunicerar via rätt USBport på datorn (Com1)

Eller att det man ska kommunicera med är väldigt kinkigt när det gäller timing.

Exempel: Tål inte paus mellan tecken, kräver paus mellan tecken, använder handskakningsignaler på speciellt sätt, etc etc.

Det är en givare för 90-100% metan, EX-klassad. I princip alla EX-givare är förbannat kinkiga.

Sitter det en 9-polig eller 25-polig D-SUB som serieport så kan man nog räkna med att det är korrekta RS-232-nivåer på porten. OCH att porten klarar av att kommunicera asynkront med och utan handskakning.
Så är det problem nånstans på grund av att det är USB-ansluten serieport så beror det i 99% av fallen på "dåligt" skriven programvara på datorn.

Kan man få tag på vettig programvara någonstans då?

Kan inte svara i detalj, men vet att kommunikationen under programmering är väldigt kritiskt i realtid och inte klarar några störningar.
Pga ovanstående problematik är det inte ovanligt att det körs på gamla sunkiga Toughbooks, som inte direkt är några prestanda monster.

Nästan rätt, gamla är en Probook, nya är en Elitebook.

Nu vet jag inte vilken interface använder du från datorn till givare, men eftersom det funkade förut med RS232 då antar jag att det är USB->RS232 så borde inte gå att ändra baud rate till 9600?

Jag kör 9600baud (som givaren vill ha) genom min USB-RS232 dongel.

[Icecap]

I enhetshanteraren väljer man rätt COM-port.
* Högerklick på den och välj "Egenskaper".
* Välj flik "Portinställningar".
* Klick på "Avancerat..."

Nu kan man välja att använda FIFO eller inte. Har man ett kinkigt system kan det vara värd att testa med dessa inställningar, dels med eller utan FIFO och dels nivån på bufferterna.

[TomasL]

Skillnaden mellan USB och HW-Serieport är att serieporten är interruptstyrd och USB är pollad.
Om datorn har mycket att göra kan det då bli fördröjjningar i USB-kommunikationen.
Det finns en inställning i registret för windows som styr "Poll-Raten", kommer dock inte ihåg vad den heter.

[TomasL]

Eftersom USB är ett pollat interface, går det inte ta emot eller skicka data i realtid, USB hanterar i princip alltid data i 64 bytes paket, om jag fattat saken rätt.
I egenskaperna för USB-enheten under Avancerat bör det finnas en inställning som heter "Latency Timer", kika på den inställningen.

[hanzibal]

USB/UART-bryggan (chipet i dongeln) lär ju ha en buffert för att hantera försenade pollningar. Kanske ingen jättebuffert men troligen tillräcklig för att inte orsaka problem redan vid 9600 baud kan man tycka.

Delvis OT:
Vad jag erfarit sker pollning vid ca 1kHz för generic HID men kan ju vara annorlunda för CDC (virtuell COM-port) och skiljer troligen mellan olika OS och dess versioner.

Läste någonstans att standard pollfrekvens för möss är så låg som 125Hz.

[TomasL]

Ja, det kan nog stämma.

[TomasL]

Hittade detta:

CDC uses the USB bulk transfer type which doesn't guarantee timing but does guarantee that it will transfer the data as fast as possible. That "fast as possible" depends on what else is happening on the bus AND on the host computer.

In practice this does lead to different maximum transfer speeds for Serial on different computers (and even on the same computer under different workloads).