Verschil echte seriële poort en USB serieel-convertor

Op vrijdag 12 december 2025 23:35:50 schreef Arco:
Nieuwere insteekkaarten op pci basis zitten in een veel hoger adresbereik, en dus niet 100% compatible.

PCI seriele poorten hebben vaak ook de optie "enable legacy addresses" en dan decoderen ze ook de oude "COM1 - 4" adressen!

Maar goed. Ze hebben het inderdaad niet allemaal.

Een DOS emulator onder Windows kan de DOS legacy COM en LPT I/O adressen mappen / interfacen op de Windows PCI COM en LPT I/O adressen (of idem voor een USB naar COM en LPT bridge). Op die manier kun je onder DOS toch gebruik maken van een PCI COM / LPT insteekkaart (of een USB naar COM en LPT bridge).

Zeker tegen de tijd dat het een USB device is, dan kan het zijn dat eea niet meer lekker werkt.

Bij een USB device kan je niet veel sneller dan 1x per 1ms "losse dingen" doen. Als je device kan streamen dan kan het veel sneller, maar losse "onverwachte" dingen schijnen minstens tot de volgende 1ms "tick" te moeten wachten.

Dit betekent dat een dos programma dat het volgende doet:


for (int i=0;i<100;i++) {
   UART->LCR |= DCD;
   delay_us (1);
   UART->LCR &= ~DCD;
   delay_us (1);
}

(LCR is het line control register, waar je signalen als RTS, CTS, DCD, CD kan uitlezen en besturen. )

ineens rond de 1000x langzamer wordt. Dat kan snel escaleren van "behapbaar", naar "onhandelbaar traag". Als er timing vereisten zijn, bijvoorbeeld: minstens 50ns, max 30 us(*), dan ga je ineens nat.

Die emulatie die werkt prima voor een modem programma wat de poort gebruikt voor waar ie voor bedoeld is en geen "rare dingen" hoeft te doen.

(*) Best haalbaar voor een 8086 - 80486 uit het dos tijdperk.

Op vrijdag 12 december 2025 18:20:21 schreef Arco:

die doen vaak aan bitbanging op de controlelijnen van de poort

Dit, en dat ga je met geen enkele USB adapter oplossen.

Veel oude programmers en hardware vertrouwden op bitbanging van de controlelijnen (RTS, CTS, ...), dat was uS werk.
Dat gaat met een USB -> RS232 nooit lukken door de enorme latency van usb poorten (tot 12mS)

Niet alle oude programmer hardware hebben timing nauwkeurige bitbanging van data- en controlelijnen nodig.
Een voorbeeld is de ALL-11 die gewoon te gebruiken is via een COM poort waarvan de I/O poort niet perse op een legacy adres hoeft te liggen.

De oudere ALL-03 en -07 wel: die hadden geen intelligentie aan boord:
Alle programmeeracties en signalen werden direct via de COM of LPT poort getimed door de PC...

Hartelijk dank voor alle reacties!

Op vrijdag 12 december 2025 18:20:16 schreef benleentje:
Welke extra signalen je nodig hebt zou je denk ik uit reverse enginering van het apparaat moeten doen. Kijken wat er allemaal echt aangesloten is.

Dat is inderdaad niet alleen Tx en Rx:

  1. RTS
  2. Rx (op Tx van controller)
  3. Tx (op Rx van controller)
  4. -
  5. GND
  6. -
  7. CTS
  8. -
  9. -

RTS en CTS worden inderdaad gebruikt, ik zie met de scoop ook hier inkomende en uitgaande signalen op de HIN232.
Dank voor je verdere toelichtingen. Misschien goed om te vermelden: ik gebruik dezelfde kabel én instellingen bij beide opstellingen.

@Arco: Ik had al zo'n vermoedde.

@flash2b: Dank voor je bevestigende reactie.

@weardguy
@bprosman

Op vrijdag 12 december 2025 19:08:41 schreef weardguy:
[...]
Je zou met usbdevview bijvoorbeeld kunnen kijken naar de diepere technische gegevens die de chip aan de computer stuurt. Hardware, manufacturer ID's en dergelijke laat Windows je alleen maar buitengewoon omslachtig zien, maar usbdevview toont alles heel overzichtelijk als een soort apparaatbeheer.

In Windows zie ik als mogelijk waardevolle informatie:

  • Leverancier: Prolific
  • Beschrijvende naam: Prolific USB-to-Serial Comm Port (COM4)

@deKees: COM4 werkt niet beter dan de eerder gebruikte COM6. Wat precies het probleem is kan ik nog niet inschatten.

Op vrijdag 12 december 2025 19:25:07 schreef GJ_:
[...]Die bestaat niet.
Je kunt hoogstens per toepassing zoeken naar een oplossing.
Of zo'n converter werkt hangt van te veel factoren af.

Ik hoop nog op een passende oplossing met de componenten die ik heb. Maar ik zie steeds meer dat het een 'vaag' probleem betreft :)

Op vrijdag 12 december 2025 19:39:12 schreef Bobosje:
Voor moederborden met een vrij PCI Express slot is deze insteekkaart te koopl

Ik zou het graag werkend krijgen op m'n (moderne) laptop. Dank voor de suggestie. Een kabel met FDTI chip is ook nog het overwegen waard. @bprosman noemde dat deze ook aardig werkende handshake signalen genereren.

Op vrijdag 12 december 2025 21:59:59 schreef buckfast_beekeeper:
Prolific is vaak een ramp. Soms werkt het maar veel vaker niet. FTDI is vrij betrouwbaar.

Dat geeft weinig hoop met de huidige kabel. Een andere kabel proberen lijkt steeds meer de oplossing. Het delen van jullie ervaringen geeft mij een hoopvolle oplossing. :)

Op zaterdag 13 december 2025 06:19:25 schreef mel:
Ik heb een paar PLC,s welke een serieele poort nodig hebben, daarvoor gebruik ik een 486 pc,met ouderwets DOS erop.En voor het programmeren voor Motorola mobilofoons. Verder gebruik ik dat ding nergens voor.

Net zoals ik nu voor de lichtkrant doe... Je zou denken dat dat toch anders zou moeten kunnen. Mooi hobbyprojectje om een tussen convertor te maken - en niet onmogelijk lijkt mij. Maar dat vraagt heel wat tijd en uitzoekwerk!

Op zaterdag 13 december 2025 13:20:28 schreef Sine:
[...]
Dit, en dat ga je met geen enkele USB adapter oplossen.

& verdere opmerkingen:
Hmm, interessante info. Het zet mij aan het denken - maar dat is dan een ander project zoals ik zojuist noemde :) Ik zie voor de lichtkrant nu alleen een andere kabel als oplossing.

Op vrijdag 12 december 2025 23:35:50 schreef Arco:
Ik gebruik altijd kabeltjes met een CP2102 erin: werken (voor de meeste applicaties) goed...

Is dat met een volledig bezette 9 polige SUB-D stekker?
Of is dat alleen met DTR, TXD, RXD, 5V, GND en 3.3V?

Op zaterdag 13 december 2025 17:37:06 schreef Lambiek:
[...]
Is dat met een volledig bezette 9 polige SUB-D stekker?

Nee,

Handshake signalen gebruik ik (bijna) nooit...

[Bericht gewijzigd door Arco op (11%)]

Mbt FDTI: dat zijn toch die dingen waarvan je vrijwel enkel fakes tegenkomt? Registers instellen.. waarom werkt het kreng niet... hadden dus maar gewoon het geheugen weggelaten.

Ik heb nog met geen enkele FTDI problemen gehad. Maar ze kwamen dan ook altijd van bij Mouser. Goedkoop is dan duurkoop. Als ze een chip klonen, dat ze dan wel zo eerlijk zijn de nodige software zelf te schrijven.

Op zondag 14 december 2025 10:40:12 schreef buckfast_beekeeper:
Ik heb nog met geen enkele FTDI problemen gehad. Maar ze kwamen dan ook altijd van bij Mouser. Goedkoop is dan duurkoop. Als ze een chip klonen, dat ze dan wel zo eerlijk zijn de nodige software zelf te schrijven.

Met Chinese fakes ook nog nooit problemen gehad dus zo "duurkoop" is het niet. En nee, registers kun je niet opslaan wat logisch is als de EEPROM er niet bij zit.

In mijn ervaring werken de fdti chip sets het beste. Helemaal echt oude systemen kunnen problemen maken. De ouderwetse 25 polige seriele poort trok direct aan de interrupt lijnen van de cpu. Er zaten alleen nog twee in cascade geschakelde interupcontrolers tussen. (Interupt twee kon je nooit gebruiken omdat die gebruikt werd door de cascade. Als er dus een byte verstuurd was werd door de interrupt de seriële poort interrupt service routine (ISR) gestart. De reactie duurde dan ook maar enkele microseconden. Het ontvangende apparaat was dan ook gemaakt om zo snel mogelijk een reactie te ontvangen. Dat was in de tijd dat cpu snelheid nog 4,77MHz was. Met het sneller worden van processors kwamen er dus de problemen met de baudsnelheid timing e.d. Die waren echter eenvoudig op te lossen door in de ISR routine, cpu kloksnelheid afhankelijke wachtlussen in te bouwen.

Intussen was ook de 25 polige aansluiting niet meer nodig. Daar zaten oorspronkelijk nog hardware signalen ( zoals het bel, EOL enz.) in. Dus ging de aansluiting van 15 polig naar 9 polig en op laatst werd het zelfs drie polig. Omdat bij drie polig ook de DSR, CTS enz. weg waren moest de synchronisatie en timing van de signalen anders worden opgelost. En dat ging men doen door de lengte van de signalen te meten. Dat kon ook makkelijk omdat de processors veel sneller geworden waren.

Het nieuwe probleem kwam doordat alles nu via USB gedaan moest worden. USB krijgt een een keer bulk data en dan weer een hele tijd niet. En dat is iets wat de oude RS232 apparatuur nu net niet kan. Die wil een constante data stroom hebben en niet af en toe een paar bits en dan weer even niets.

Ik ken eigenlijk alleen de ftdi chip die het eigenlijk redelijk goed doet. Met andere type chips heb ik gewoon slechte ervaringen.

De door Arco al genoemde CP2102 werkt prima, die heeft me nog nooit in de steek gelaten.

Echte FTDI chips ook niet, FTDI kloontjes kunnen wel eens problematisch zijn, zeker als FTDI weer eens een driver denkt uit te moeten brengen die kloontjes bricked.

https://www.elektroda.com/qa,ftdi-ft232-scandal-driver-bricking-2024.h…

[Bericht gewijzigd door Sine op (23%)]

In spullen van Ome Ali zitten (bijna) altijd clones. FTDI chips zijn duur. Dat er FTDI op de chip staat zegt niets.

Ik heb al een hoop timingproblemen gezien, minder betrouwbare communicatie. Maar ook met FTDI chip via USB. Recentelijk had ik een project dat nogal gevoelig was op poorttiming, hoge bitrate, en software die geen retry doet etc. Dat schudt er meteen alle fouten uit. Ik kreeg die alleen goed aan de gang met echte seriële poorten op het moederbord, of kaart (geen USB) met poorten. Ook FTDI geeft zijn problemen, maar soms krijg je die weg door je timers in Windows aan te passen.

Verder geeft FTDI continue driver updates met maar 1 doel: fake FTDI chips detecteren en uitschakelen. Dan heb je een werkend systeem met echt FTDI (dat denk je tenminste) en na een paar maanden werkt het niet meer: https://it.slashdot.org/story/16/01/31/1720259/ftdi-driver-breaks-hard…

Ik gebruik liever echte RS232 poorten.

De USB-Serial kabel die ik en benleenje linkte heb ik getest met een FTDI python script welke fakes kan detecteren. Hij kwam goed door de test, geen fake.

De kabeltjes hebben al 100en uren goed hun werk gedaan.

https://marcan.st/transf/detect_ftdi_clone.py

Op zondag 14 december 2025 13:48:59 schreef Hoeben:
Ik gebruik liever echte RS232 poorten.

Maar die worden steeds zeldzamer. Al zeker op een laptop. Op vele laptops zit er zelfs geen ethernet poort meer. Moet je maar een USB-C=>ethernet adapter gebruiken. Ook HDMI en DisplayPort worden vaker niet meer aangeboden. Loopt ook via USB-C. Niet moeilijk dat oudere hardware het daar moeilijker mee krijgt.

@ .., .., en etc.

Met de ervaring mbt fakes ben ik dus niet de enige. Naar de prijs hoef je namelijk ook niet te kijken, de fakes zijn/waren ook niet goedkoop. Uiteindelijk uit Engeland laten komen. Wat een genot... je set een register, prikt het ding ergens in en het werkt.
Waren die chips niet ook lange tijd slecht verkrijgbaar?

Mbt andere chips: voor gewone seriele communicatie volgens mij nooit problemen gehad en dat ding wat op de arduino zit volgens mij ook nooit driver (windows) problemen gehad. Met die CP2102 iirc wel, maar is sowieso al jaren geleden.

flash2b: zo'n scriptje had destijds handig geweest, zit je misschien nog steeds met een fake, maar je niet uren af te vragen wat je nu weer verkeerd doet.

Als je genoeg budget hebt zou je ook een mini industrieel PCtje kunnen overwegen. Zo duur zijn die ook weer niet. Er zijn er in allerlei uitvoeringen, hier is er een met veel RS232 poorten. https://www.amazon.com/BASOARO-Industrial-Windows-Fanless-Ethernet/dp/…

Als ik de nummering van Intel goed begrijp is het duizenden getal de generatie. Dus dat is een 4e generatie core I7, terwijl we nu ergens in de 12, 13, 14? zitten. Tien generaties terug die CPU....

Daar heeft intel hele mooie tabelletjes van.


Marketing Status                       Discontinued
Launch Date                            Q3'13
Servicing Status                       End of Servicing Lifetime
End of Servicing Updates Date          Wednesday, June 30, 2021

https://www.intel.com/content/www/us/en/products/sku/75460/intel-core-…

Dus ja, dat is ouwe meuq

[Bericht gewijzigd door Sine op (17%)]

Dat maakt voor PLC programmering helemaal niet uit. Al helemaal niet voor die oude Siemens systemen. Wat ik liet zien was maar het eerste voorbeeld dat ik tegenkwam, er zijn er veel meer. Ook op die site, maar ook veel andere merken. Je zou wel kunnen overwegen er een te nemen die W11 aankan.

Mijn OUDE laptop heeft al een 11th gen. i9-11900H, 2.5 GHz, W11, 48GB geheugen, 2 SSD's (2TB en 4 TB). Ik ben alweer na aan het denken over een volgende laptop. Alhoewel de specs dan toch niet zoveel hoger gaan worden, misschien een 50% winst, merk je amper.

Hoe snel de processor ook is, USB werkt nu eenmaal met die pakketten en een andere timing, het blijft moeilijk. Hardware RS232-poorten zijn veel handiger en werken altijd.

Ik zie een schat aan waarde wat hier allemaal genoemd wordt. En er zal vast nog veel meer niet genoemd zijn, maar wel bekend. Ik stel me dan een controller voor met aan de ene kant een USB poort en aan de andere een ouderwetse seriële poort (of meerdere types) die met alle protocollen overweg kunnen. Een controller daar tussen in (ik denk dat bijvoorbeeld een ESP32 daar krachtig genoeg voor is) samen met een mooie FDTI-chip en een stukje geheugen om aan beide zijde te bufferen die de brug slaan tussen een moderne computer en de ouderwetse randapparatuur zodat (bijna) alle denkbare problemen als sneeuw voor de zon verdwijnen. Dat zou toch mooi zijn :)

Ik stel me dan voor dat de pc iets stuurt rechtstreeks naar het betreffende apparaat (de 'ontvanger') en de controller mee kijkt naar de overdracht. Zodra hier een probleem optreed gaat de controller bij een volgende poging te verbinden de ontvanger emuleren als het gewenste protocol duidelijk is. De controller de ontvanger na, maar dan op USB snelheid en buffert alle data in een geheugen om vervolgens de de pc richting de ontvanger na te doen die alle data volgens gewenst protocol en snelheid over brengt.
Maar misschien is dit technisch wel heel lastig en niet markt aantrekkelijk - kan ik me voorstellen.

Als je nog wat tijd over hebt...

Je kunt eens spelen met:

https://github.com/satoshinm/pill_serial.git

het is een projectje voor een STM32F103C8T6 (A.K.A. "Blue Pill") die 3 seriele poorten bij tovert op een USB poort. Ik heb dat ooit eens geflashed op een breadboard, een paar draadjes tussen de verschillend RxD / TxD pinnen gelegd en toen verschillende terminal emulators opgestart om met elkaar te kletsen. Werkte best leuk. En zoals gebruikelijk, herkende Linux de serie poorten zonder extra drivers. maar daarna is het project weer dood gebloed.

Maar voor de verschillen... Met USB wordt de data in pakketjes gehakt. Dat kan misschien problemen geven bij sommige protocollen, ook al is dat best slordig. Een "echte" RS232 werkt niet alleen met hogere spanningen +/- 10V ofzo, maar inverteert de data ook. Kijk eens naar de werking van de goede oude MAX232 chip.