Verschil echte seriële poort en USB serieel-convertor

Zou een zogenaamde 'level converter' misschien een oplossing kunnen bieden?

Echte RS232 werkt met met +/- 15V maximaal meestal is dat +/-12V

USb serial converter heb je in veel soorten en maten een goed gebruikt een FDTI chip die ook +/-12V maakt.
Daarnaast hebben eenvoudige converters niet altijd een handshake of de andere hulpsignalen ter beschikking die in RS232 wel zitten.

Je moet met USB converter ook heel erg goed op de pin-out letten want de TX en RX zitten soms omgedraaid.

of kan de manier waarop data omgezet wordt ook verschillend zijn waardoor problemen ontstaan?

Volgens mij zit daar het probleem niet het is meer signaal niveau, handshake en hulpsignalen en pinnen die niet op de goede plaats zitten.

Je hebt wel verschil in RS232 en Serial TTL. Die laatste is alles inverteerd en zijn de signalen TTl niveau ipv van +/-12V

Na problemen met enkele USB to serial converters heb ik op aanraden van flash2b deze gekocht. Deze werkt bij nu naar volle tevredenheid.

Ik wou alleen dat ik hem ergens ander had kunnen kopen ipv van op Amazon. Maar nood breekt wet.
https://www.amazon.nl/dp/B07MYYCMJT?ref_=pe_111809601_1111269701_t_fed…

[Bericht gewijzigd door benleentje op vrijdag 12 december 2025 17:56:58 (25%)]

Dank voor je snelle reactie benleentje!

Op de USB serieel-convertor staat natuurlijk weer niks - dan ga ik er gemakshalve van uit dat het er eentje is zonder de oude vertrouwde FDTI chip.

Interessant wat je schrijft over de handshake of de andere hulpsignalen. Misschien moet (kan?) ik mijn USB serieel-convertor eens nader onderzoeken. Hoe test ik dit? Kan dat met Putty bijvoorbeeld - wat ik al wel eens gebruik maar niet in thuis ben, samen met een oscilloscoop of heeft iemand een beter idee? Ik ben er niet zo thuis in namelijk

Voordat ik een flash2b ga bestellen op Amazon (voor mij ook geen voorkeur!)

flas2b is een lid van dit forum en gaf toen ik dit advies wat ik je nu verteld.

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.

Of er pinnen van je converter op de verkeerde plaats zitten kan je wel meten. De pin-out heeft te maken met de DB9 connector die je dan in vrouwelijk of mannelijk hebt. En soms moet daar dan een nul-modem kabel tussen.

RS232 het was ooit zo makkelijk maar nu met al die converters die niet doen wat ze moeten doen is het een drama.

Voordat ik een ... ga bestellen op Amazon

Ik was na 2 dagen van alles proberen er ook wel klaar mee en heb dan toch 2 van deze besteld.

Ik vergeet nog 1 ding of meer
Als het met een echte compoort wel gelukt is kijk dan even goed in de instelling van de poort en kijkt op de Converter dezelfde instellingen gebruikt. Dat scheelt tenminste weer werk want ik wist toen ook niet precies de instellingen.

Vooral oudere programma's en hardware werken niet altijd met virtuele RS232 poorten, omdat de timing niet klopt, of de poort eenvoudig niet gevonden wordt.
(die doen vaak aan bitbanging op de controlelijnen van de poort of verwacht een RS232 poort op de vaste ISA bus adressen, 0x3f8, 0x2f8, 0x3e8 en 0x2e8)

Van die DSD Tech SH-RS232A heb ik er nu 3 in gebruik. Ik vind ze super werken.

Er is er ook een met een female DB9 connector: https://www.amazon.nl/DSD-TECH-SH-RS232G-vrouwelijke-FT232RL-chip/dp/B…

Op vrijdag 12 december 2025 18:07:14 schreef OPTOdesign:
Op de USB serieel-convertor staat natuurlijk weer niks - dan ga ik er gemakshalve van uit dat het er eentje is zonder de oude vertrouwde FDTI chip.

Interessant wat je schrijft over de handshake of de andere hulpsignalen. Misschien moet (kan?) ik mijn USB serieel-convertor eens nader onderzoeken. Hoe test ik dit?

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.

Op de USB serieel-convertor staat natuurlijk weer niks - dan ga ik er gemakshalve van uit dat het er eentje is zonder de oude vertrouwde FDTI chip.

Dat kun je zien aan het VID/PID ID in je device manager , of aan de driver welke chip er in zit.
Die FTDI dingen hebben nog aardig werkende handshake signalen ook.
Je kunt op de connector van de lichtkrant kijken welke pennen gebruikt worden.
2/3 als RXD/TXD en 5 als GND, en als er verder nog iets aan de connector zit zal t wel handshake zijn. En hoe is je kabel bedraad ?

Compoorten zijn altijd al een drama geweest. Pin bezetting, handshake lijnen, timing, signaal levels enz.

En sommige programma's ondersteunen alleen COM1 t/m COM4.

Echte hardware serial poorten zijn moeilijk te vinden tegenwoordig. En als je ze al vind gebruiken ze vaak nog steeds een interne USB verbinding.

Als het goed is kun je aan je converter wel zien of het RS232 is of een TTL-level serial poort. De eerste heeft altijd een DB9 connector, de andere meestal alleen een pin header met 4 of 6 pinnen. Als je al een kabeltje hebt met een DB9 connector dan gaat een level converter niet helpen.

En dan ben je ook nog afhankelijk van de driver die bij het kabeltje hoort. De meeste (ook FTDI) hebben een eigen proprietary protocol met bijbehorende windows driver. Je lichtkrant applikatie moet dan wel met de driver overweg kunnen. Die interface zou tamelijk standaard moeten zijn, maar kleine verschillen gooien zorgen soms weer voor problemen.

PS, In de windows device manager kun je alle details bekijken die je maar wilt. Ik zit tegenwoordig niet meer op windows dus ik kan het nu niet even proberen.

Op linux gaat dat soort dingen heel anders (veel gemakkelijker).

Op vrijdag 12 december 2025 17:43:21 schreef OPTOdesign:
Echter ben ik op zoek naar een oplossing.

Die bestaat niet.

Je kunt hoogstens per toepassing zoeken naar een oplossing.
Of zo'n converter werkt hangt van te veel factoren af. Ik heb meegemaakt met twee laptops, tegelijk gekocht, zelfde processoren, zelfde OS, zelfde software en op de ene werkt het wel en op de andere niet.
Nog gevaarlijker is als het lijkt te werken, maar het niet echt goed werkt. Bij Siemens S5 heb ik meegemaakt dat het allemaal prima werkte tot ik beter ging kijken en er hele bouwstenen werden overgeslagen. Maak je een back up, blijkt er geen OB1 in te zitten.

Ik gebruik nu nog maar weinig RS232, en ik heb nog twee laptops met een echte RS232 op de laptop zelf. Het meeste kan tegenwoordig gelukkig met ethernet. Voor de beruchte S5 heb ik nu een ethernet kabel die goed werkt. Voor andere antieke toepassingen heb ik voor ieder zijn eigen oplossing.

Eén oplossing voor al je RS232 problemen bestaat niet.

Als je nog een kabeltje zoekt met FTDI chip dan kun je ook hier eens kijken:

https://www.mediamarkt.nl/nl/product/_aten-uc232af-usb-naar-seriele-om…

Geen garanties. Ik heb deze nooit gebruikt. Ik werk uitsluitend met ttl-level interfaces en basic verbinding met alleen RxD en TxD.

Voor moederborden met een vrij PCI Express slot is deze insteekkaart te koop.

Delock PCI Express x1 Card to 2 x Serial RS-232 + 1 x Parallel IEEE1284

https://www.delock.com/produkt/90413/merkmale.html

Prolific is vaak een ramp. Soms werkt het maar veel vaker niet. FTDI is vrij betrouwbaar. De CH340 werkt ook heel vaak maar is meer bedoeld voor TTL niveaus.

Op vrijdag 12 december 2025 19:25:07 schreef GJ_:
Bij Siemens S5 heb ik meegemaakt dat het allemaal prima werkte tot ik beter ging kijken en er hele bouwstenen werden overgeslagen. Maak je een back up, blijkt er geen OB1 in te zitten.

Dat is toch echt ook een software probleem, ik dacht dat Siemens in die tijd nog wel fatsoenlijke producten kon maken maar ook toen viel het blijkbaar al tegen.

Één probleem is dat USB niet met losse bytes werkt, maar het pakketjes. Zo'n converter moet dus meerdere bytes ontvangen en op een bepaald moment besluiten dat er genoeg data is om te versturen. Doorgaans zullen ze voor een bepaalde tijd of aantal bytes verzamelen, of als er een bepaalde tijd niets nieuws binnen is gekomen, voordat ze een pakketje maken om te versturen. Als de software dan ongeduldig is en al een timeout heeft gedetecteerd, omdat het apparaat gewoonlijk veel sneller reageert, zal de communicatie fout gaan.

Een aantal moederboarden hebben nog een Com poort aan boord, alleen is dat een header waar geen kabel met DB9 aan zit.
Kan je ook eens naar kijken of je geluk hebt en het een vaste pc is natuurlijk.
En anders idd een pci kaartje.

Meeste compatibiliteit heb je inderdaad met een on-board rs232 poort.
Die wordt rechtstreeks ondersteund door de Southbridge en zit op de legacy adressen. (daar kan oude soft/hardware ook mee overweg)

Nieuwere insteekkaarten op pci basis zitten in een veel hoger adresbereik, en dus niet 100% compatible.
De MSI mb's hadden tot en met de Z590 allen een ser/par header onboard, ASUS bijv. al sinds 2005 niet meer...

Ik gebruik altijd kabeltjes met een CP2102 erin: werken (voor de meeste applicaties) goed...

[Bericht gewijzigd door Arco op vrijdag 12 december 2025 23:38:29 (10%)]

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.

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...