Ik zie die Chinese naar 6V gaan... Weliswaar in de buurt van TTL-niveau. Maar de polariteit is wel volgens RS232.

RS232 kan al met +3V/-3V... alleen hier is dat dus opgeschoven t.o.v. de nul volt.

[Edit] Volgens mij lees ik de scoopbeelden verkeerd af qua spanning.... Hoeveel Volt per division is het nu?

[Bericht gewijzigd door Franzki op (22%)]

Op 23 november 2011 23:31:29 schreef Franzki:
Ik zie die Chinese naar 6V gaan... Weliswaar in de buurt van TTL-niveau. Maar de polariteit is wel volgens RS232.

TTL niveau is: L<=0,4, H>=2.4 V (zend zijde) dus eigenlijk moeten we het daar niet over hebben, want dat is nog slechter!

@ Henri62

Ja en nee, RS232 is geïnverteerd, ze hebben alleen de spanning niet aangepast. Het werkt soms namelijk wel. Dus of het is een geïnverteerde TTL uitgang, of een serieele uitgang met niet de officiële spanningen, maar het is het in ieder geval allebei net niet.

Of het een trigger probleem is zou ik niet direct gokken. Dat je chinees krijgt komt omdat je geen stopbit hebt en je data zorgt soms toevallig voor je startbit...

[crap, ik schrijf allebei blijkbaar altijd fout...]

Op 23 november 2011 23:31:29 schreef Franzki:
PS: Let op ... de schaal van de scoop is 1.2V per division.

Nee, de trigger staat op 1.2V, de V/div is 1V.
Je ziet ook de spanning readout, de ene 4.5V, de andere 5V

[Bericht gewijzigd door Henry S. op (22%)]

Op 23 november 2011 23:34:44 schreef Ganzz:
@ Henri62

Ja en nee, RS232 is geïnverteerd, ze hebben alleen de spanning niet aangepast. Het werkt soms namelijk wel. Dus of het is een geïnverteerde TTL uitgang, of een serieele uitgang met niet de officiële spanningen, maar het is het in ieder geval allebijei net niet.

Omdat de spanning niet klopt is het RUK, precies zoals ik zeg.
Als het wel toevallig wel werkt is het dom toeval. Ook de slew-rate, maximale stroom er is niks wat er bij de meeste USB-RS232 klopt.

Die Chinezen verkopen dit spul voor PDA's en telefoons en daarmee werkt het meestal wel omdat die over het algemeen niet kritisch naar het signaalniveau kijken..

Bij een microcontroller gebruik je voor RS232-communicatie normaal gesproken een MAX232 zodat het signaal geïnverteerd wordt en de levels kloppen.

Als je TTL gebruikt, is dat niet nodig. Die sluit je direct op de UART van de Pic aan.

De Chinese convertor kun je trouwens wèl direct gebruiken als je software UART gebruikt en dan zelf in de software inverteert.

Op 23 november 2011 23:38:44 schreef Franzki:
Die Chinezen verkopen dit spul voor PDA's en telefoons en daarmee werkt het meestal wel.

Fijn voor je klanten! Wat staat er in de handleiding?
"Als U geluk heb en U sluit het kabeltje aan werkt het ook"

Daar moeten ze een import verbod op maken, onder het motto van een milieu delict, die kunnen rechtstreeks de kliko in.

De Chinese convertor kun je trouwens wèl direct gebruiken als je software UART gebruikt en dan zelf in de software inverteert.

Soms kun je de uC pin kwa polariteit omschakelen op de ingebouwde UART.

En dan sluit je een keer een echte (voor zover je er een kunt vinden) converter op aan die wel de juiste spanning geeft: Dan is je controller naar de filistijnen.

Ik heb er hier een paar (goedkope) liggen... en die Chinezen documenteren het inderdaad slecht. Sommigen geven 5V... andere 3V. En ik heb ook een duurdere die misschien wel gewoon RS232-levels geeft. Maar ik heb geen scoop om te testen.

Overigens heb ik de kabeltjes niet om een RS232-interface te hebben die 100% volgens de normen werkt. Ik heb ze om een 'el cheapo' verbinding met een PIC op te zetten.

Zelf ga ik er vanuit dat je een RS232-poort op een microcontroller-project gewoon met een MAX232 maakt... dan kan hij vermoedelijk met een grote variëteit aan signaalniveaus overweg.

Wow, wat een hoop antwoorden!

Ik werk niet met een MAX232 omdat het plan was om deze convertors te ontdoen van de DB9 en ze te solderen in ons project.
Ik heb nu de RX en TX door een 7404 lopen.
De microcontroller ontvangt de data van de usb/serieel omzetter prima.
Microcontroller->PC wilt nog niet lukken, er blijven rare tekens binnen stromen.

Edit, en dat laatste leek dus een driver probleem. Convertor er uit en er terug in en het werkt wel. Rare Chinezen...

Mocht er iemand een suggestie hebben voor een driver die wel goed werkt (Windoos, OSX en eventueel Linux zou fijn zijn) dan hou ik me aanbevolen!

Alvast bedankt allemaal!

Voor de driver moet je gewoon even uitzoeken welke chipset er in de convertor zit.

Vervolgens kun je op de website van de fabrikant (van de chipset) de nieuwste downloaden.

Deze dingen doen zich voor als een PL2303 van Profilic. Maar als je de driver van Profilic installeert doen de convertors helemaal niks. Als je de RX en TX doorverbind krijg je geen echo in de terminal. Nu heb ik een of andere rare driver van het mini cdtje dat er bij zat geinstalleerd ("810driver") en deze werkt "af en toe".

Heb je wel de goede communicatie-instellingen in de terminal staan?

Het is misschien geen PL2303! (Maar vaak met hetzelfde vendor en product id) Je kunt de driver voor de 'CH341 USB-SERIAL BRIDGE' downloaden op de site van de fabrikant: http://www.wch.cn/download/list.asp?id=65

Een andere PL2303 'clone' driver is deze, hier heb ik ooit een vergelijkbare dongle (pcb zag er hetzelfde uit) op windows aan de praat gekregen (deze werkte wel met de linux pl2303 driver maar niet de windows pl2303 drivers (device gezien, maar geen TX en RX activiteit)): http://arailla.info/USB_BF.rar

Ik zou beide drivers eens proberen, kans dat een clone pl2303 dongle met 1 van de 2 werkt is behoorlijk groot.

Niet helemaal mee eens...

Er zijn inderdaad verschillende chipsets en ook daar zijn de Chinezen nooit helemaal duidelijk over.

Maar ik zag ergens een 810-driver (via Google) en die was dan weer voor een convertor met een Prolific chip.

Het kan trouwens wel zo zijn dat de drivers elkaar nu een beetje in de weg zitten. Heb je de oude drivers allemaal verwijderd?

Op 24 november 2011 00:01:37 schreef Stijn S:
Mocht er iemand een suggestie hebben voor een driver die wel goed werkt (Windoos, OSX en eventueel Linux zou fijn zijn) dan hou ik me aanbevolen!

Linux drivers werken over het algemeen gewoon goed. Zeker voor iets wat veel gebruikt wordt als een PL2303 driver.

De driver-hell zal ik dan maar laten oplossen door wat groepsleden.
Ik maak gebruik van een MSP430F2132 microcontroller. Bij z'n hardware UART is het blijkbaar niet mogelijk om de polariteit om te keren.
Ik zal dan maar eens uitzoeken hoe ik een software UART geprogrammeerd krijg.

Niet aan beginnen. Een inverter of torretje+R kost maximaal 25 cent.
Daar kun je niet tegen werken met een SW uart oplossing, dan heb je twee keer ellende.

Het zoeken naar een software UART heb ik ondertussen ook al opgegeven, dat kost echt te veel moeite. Zo hebben de pennen waar nu de usb/Serial aan hangt geen pinchange interrupts en das dan "redelijk vervelend" programmeren.
Het zal inderdaad een convertortje bestaande uit 2 torren en 4 weerstanden worden, kost toch bijna niks.

Je kan in plaats van een USB <->RS232 converter ook een GSM kabel kopen.Als je zoekt op CA-42 ,da's een seriele communicatie kabel voor een oud model Nokia telefoon.Die kabels worden volop aangeboden tegen belachelijk lage prijzen.Hier zit een 'soort' PL2303 chip in de USB stekker,aan de andere kant van de draad zit een rare connector voor de Nokia telefoon en die kun je er gewoon afknippen.
Hier heb je dan Rx en Tx op TTL nivo en kan direkt op een UART worden aangesloten zonder inverteren.
Goed,klinkt leuk, maar er zijn toch een paar maaren :Er zit namelijk geen echte PL2303 chip in,maar een kloon.Ze leveren een CD'tje bij met driver software en da's een oude versie van de Prolific driver.
De nieuwe Prolific drivers testen of er een 'echte' PL2303 chip inzit,en als dat niet zo is weigert deze te werken.
Je kunt dus voor deze kabeltjes nog wel een betrouwbare driver vinden voor Windows XP,maar niet voor W7 of Vista.
Ik heb ook al CA-42 kabels gehad met een andere soort IC erin van Akmicro.Je weet dus eigenlijk niet wat je gaat krijgen.

Je weet dus eigenlijk niet wat je gaat krijgen.

En dat is het grootste probleem. Ik heb hier nog 10 stuks van dx liggen van vorig jaar waar een PL-2303HX & ADM211 op zit. Die werken prima, maar als ze op zijn moet ik weer opzoek ...

Ik vind het wel heel vreemde schermfoto's.
Om te beginnen, de "A" is in ascii 0100 0001 (met 8 databits), of 100 0001 (met 7 databits). Er zijn dus 5 nullen op een rijtje.
In het eerste schermplaatje is het lange blok inderdaad vijfmaal zo lang als de korte pulsen. Maar in het tweede plaatje is het lange blok maar viermaal zo lang!

--
Volgens de RS232 omschrijving is de 'stop' polariteit (dus wat er in rust op de lijn staat) dezelfde als waarmee de '1' verzonden wordt. We weten ook dat het LSB als eerste verstuurd wordt; op de scoop staan de bitjes dus van laag naar hoog, 'verkeerdom' dus.

Kijk ik nu naar het bovenste plaatje, dan zie ik, na de rustperiode, het volgende:
start, 1, 0, 0, 0, 0, 0, 1, 0, stop_____ (waarbij stop uiteraard overgaat in de rustpolariteit).
Dat is dus een correcte 'A' (0100 0001) met 8 databits en geen pariteit, en met dezelfde polariteit als normaal op een RS232 verbinding tussen computers of van een computer naar een modem.
De plus is hoog genoeg, meer dan 3V; het enige wat afwijkt van de RS232 omschrijving is dat de 'min' nul volt is. Maar goed, dat doet de compoort van mijn laptop ook.

Het tweede plaatje heeft de rustpolariteit omgedraaid. Dat is OK, maar voor je daarmee naar 'buiten' gaat moet je nog inverteren. Klassiek was dat bv. met een 1488/1489 paartje.
Afgezien daarvan, maar er wel rekening mee houdend, staat daar dus:
start, 0, 1, 0, 1, 1, 1, 1, 0, stop_____
Dat is dus 0111 1010, een 'z' (kleine letter). Ik krijg daar met geen mogelijkheid een hoofdletter 'A' uit, of ik nu de bitjes inverteer of de volgorde omdraai.

Lang verhaal samengevat:
Plaatje 1: Correcte A, correcte spanning en polariteit om rechtstreeks aan de RS232 connector (een DB9 bijv) te verbinden.

Plaatje 2: Géén A, eerder een z; geïnverteerde spanning, moet nog via een inverter/line driver voordat je naar de DB9 gaat.

Toen ik van de week even snel keek, kreeg ik we wel 2 keer een A uit, alleen miste bij een een startbit, maar ik kan er naast zitten. Verder nog dit

klik

Dus als je win7 hebt en een officiële profilic converter, kun je al de Chinese weg gooien...

Toen ik van de week even snel keek, kreeg ik we wel 2 keer een A uit, alleen miste bij een een startbit, maar ik kan er naast zitten.

Je kunt in asynchrone datacommunicatie geen startbit missen.
In rust heb je stoppolariteit. De eerste keer na rust dat de polariteit wisselt, dus naar startpolariteit gaat, is dat het startbit.
De ontvangkant gaat daarna de databits inlezen. Hoe zou hij anders weten wanneer hij moet starten?
Een converter die geen startbit uitzendt, is defect.

Het stopbit dat na de databits komt is minimaal net zo lang als een databit1), maar kan ook veel langer duren: namelijk net zolang totdat het volgende karakter arriveert.

1)Er bestaan nog settings 1½ en 2, maar dat komt eigenlijk nooit voor (behalve bij baudot-code: start, 5 data en 1½ stop).

Prolific strongly recommend to only purchase USB-to-Serial cables from company-branded products providing technical support. It is not advisable to buy from unknown cable makers (no-brand cables) made in China. Prolific does not manufacturer any end-product cables and will not provide direct support to end-users.

Dit geldt voor de meeste chipset-fabrikanten. Die verwijzen voor drivers en support altijd naar de fabrikant/leverancier van het eindproduct.

@FET: Ook in moderne microcontrollers moet je nadat een byte ontvangen is een interrrupt triggeren en het serial-data-register (SDR) uitlezen. Als je daar langer dan 1 of twee databits over doet, moet het serial-data-register dubbel worden uitgevoerd: anders wordt de data overschreven door de volgende. Dit zit wel snor in moderne apparatuur waar ze in PCs meestal 16 bytes buffer hebben en in b.v. de FTDI chips 64 bytes.

Maar vroeger toen het nog veel geld kostte om zo'n serial data register dubbel uit te voeren ging dat dus niet. Toen waren er apparaten die het dus niet haalden om op 1200 baud binnen 1 bittijd het SDR leeg te halen. Dan sprak je dus af om 2 stopbits te gebruiken om de ontvanger de tijd te geven om z'n interrupt routine te starten en uit te voeren.....

Ik heb in de tijd van 120MHz pentiums wat aan PC interrupts zitten meten. 20 microseconden. Dus 1 bittijd van 115k2 halen we nu nog steeds niet. Maar met een 16-byte buffer in de chip is er geen enkel probleem. Een dubbel gebufferde SDR in een AVR geeft je ook op 115k2 bijna 100 microseconden. Dat is makkelijk haalbaar. Veel minder ook wel. :-)

Vandaar dat al 20, 30 jaar nauwelijks meer 1.5 of 2 stopbits worden gebruikt: De hardware heeft een buffertje, 8 of 16*8 bits, en de computers/controllers zijn snel genoeg geworden.

Dat klinkt allemaal logisch.
Maar ik ben pas in de jaren 80 ('van de vorige eeuw', tjee wat klinkt dat oud) met UARTS begonnen. Wat ik me herinner was dat er een 16 karakter buffertje in zat, en bij de toen gebruikelijke snelheden heb ik nooit anders dan 1 stopbit gebruikt.
Je moest tòch op je modem wachten. :)