rs232 probleem

Beetje vage probleemomschrijving, maar goed...

Je COM parameters staan allemaal goed? Klinkt als een datalength probleem wat bij je 1st experiment per ongeluk goed gaat. Het zou ook kunnen dat je bitrate een te grote fout heeft. Heb je die divisor goed berekend?

Welke PIC?
Welk karakter kwam goed aan en welke niet?

Baudrate, aantal databits, pariteit (even,odd,mark,space,none) en aantal stopbits goed ingesteld?

Edit: Marco was me net voor.

[Bericht gewijzigd door logic op maandag 24 oktober 2005 17:31:40 ]

ik verstuurde geen karakters maar gewoon hex waardes namelijk
0x22
0x33
0x44
0x55
dat was gewoon om te testen.
en alleen de 0x22 kwam aan

oja ik heb alles gecontroleerd en ik kan niks fout vinden.

Hex 22 = Chr( 34 )
Hex 33 = Chr( 51 )
Hex 44 = Chr( 68 )
Hex 55 = Chr( 85 )

Als je een Hex-waarde verstuurt, verstuur je ook een karakter.
Het is alleen een andere schrijfwijze, dat is alles.

Wat je uiteindelijk verstuurt, zijn bits.
Decimaal 34 = Hex 22 = bitreeks 00100010
Met een startbit en 1 stopbit wordt dat 0 00100010 1 (zonder parity)

Welke PIC gebruik je ?

inderdaad ik gebruik een stopbit en een startbit, en geen parity en mijn baudrate staat op 9600.

ik gebruik een pic16f877a

ik denk dat het een probleem met de baudrate is.
want ik heb net even de pic heel veel achter elkaar laten sturen. en de data komt steeds slechter aan. op het laatst stonden er zelfs 9 dingen op een regel.
en daar hoorde er maar 1 de staan.

Wat heb je aan instructies in je code staan om de USART in te stellen ?

Ik heb het probleem gevonden.
het lag aan het verzenden. er moest steeds tussen het verzenden een kleine pauze.

maar ik heb nu nog een klein vraagje waarvoor zijn de DTR en RTS lijnen op de comport.

De PC heeft even tijd nodig om het binnengekomen karakter in te lezen, dus die kleine pauze kan wel kloppen.

DTR is een signaal waarmee de PC aangeeft dat 'ie "aanwezig" is: Data Terminal Ready.
De PC wordt gezien als een data-terminal.

Het signaal wat hierbij hoort is DSR: Data Set Ready.
B.v. een modem geeft zo te kennen dat 'ie "aanwezig" is.

RTS en het bijbehorende CTS staan voor: Request To Send (PC wil gegevens versturen) en Clear To Send (modem kan gegevens ontvangen)

RTS en CTS worden ook wel eens handshake-signalen genoemd.
(Heel soms worden DTR en DSR als handshake gebruikt.)

Bedankt voor je hulp.
en over die dtr en rts signalen ik wou het gewoon even weten want je ziet het overal staan.

Jij zou die signalen zelf ook kunnen gebruiken.

Er hangt nu geen modem aan je PC, maar een PIC.
Maar dat maakt niks uit.

Het versturen van karakters gaat dan zo vlug mogelijk zonder fouten.

De PC heeft even tijd nodig om het binnengekomen karakter in te lezen, dus die kleine pauze kan wel kloppen.

Stierepoep.

In het algemeen (ik heb geen ervaring met PICs): elke UART heeft een shift register wat 'naar buiten' geschoven wordt als er serieel wat verstuurd moet worden. Doorgaans heet dat ding iets als een USR, UART Shift Register (maar er zijn zat andere namen voor hoor). Als je nou een wat luxere UART hebt, zit hier nog een register voor, het UDR (UART Data Register). Zodra je hier wat in schrijft EN het USR is leeg, wordt het UDR naar het USR gecopieerd en wordt het USR leeg geschoven (effectief: de byte wordt verzonden). Bytes blijven zo altijd intact. Eenvoudiger UARTs missen een UDR. Je schrijft dus rechtstreeks in het USR. Gevolg is dat wanneer jij de volgende byte schrijft voordat de huidige geheel naar buiten geschoven is, de huidige cyclus afgebroken wordt en een nieuwe gestart wordt. Dat gaat zo snel dat de PC UART daar niets van merkt, behalve dat de laatste bits redelijk 'random' zijn.

De mooie manier om hier mee om te gaan is een interrupt laten genereren als het volgende character geschreven kan worden . Dat kan een PIC vast wel. Iets minder mooi, is pollen of het USR al leeg is. Geen idee hoe, maar het lijkt me heel sterk dat een PIC dat niet kan.

Dan die handschakelijnen: dat komt oorspronkelijk uit de tijd dat modems een heel erg luxe artikel waren en nog half-duplex werkten.

DSR/DTR is redelijk bekend (verbinding opgezet, klaar om te kleppen / terminal klaar etc. RTS / CTS is wat complexer. Modems waren toen nog half-duplex. Dus als je wat wilde versturen als terminal, gaf je eerst een RTS. Het modem schakelde dan om van ontvangst op zenden. Als het dat gedaan had, gaf het CTS terug. De terminal kon dan z'n bytes gaan versturen.

Tegenwoordig worden ze meer voor flow control gebruikt. Met name als het ene device data sneller kan genereren dan het andere het kan verwerken. Echte specificaties hiervoor zijn er niet. Dus dat is doorgaans een beetje avonturen. Vaak kun je het wel instellen. Als beide kanten hetzelfde doen en verwachten (en je kabel 'klopt', werkt dat prima.

Gevolg is dat wanneer jij de volgende byte schrijft voordat de huidige geheel naar buiten geschoven is, de huidige cyclus afgebroken wordt en een nieuwe gestart wordt.

Hoe weet je of hij dat zo doet. Je kent z'n broncode toch niet?
Ik neem aan dat een volgend byte pas verstuurd wordt wanneer de voorgaande volledig verzonden is.

Met name als het ene device data sneller kan genereren dan het andere het kan verwerken.

Dat is precies wat ik bedoel: de PIC verstuurt de data sneller dan dat de PC ze inleest.
Vanuit de PIC gezien moet je dus een kleine pauze inlassen voordat je de volgende byte verstuurt.

Vanwaar dan "stierepoep" ?

Hoe weet je of hij dat zo doet. Je kent z'n broncode toch niet?
Ik neem aan dat een volgend byte pas verstuurd wordt wanneer de voorgaande volledig verzonden is.

Dat is hardware. Hardware heeft geen source.

Dat is precies wat ik bedoel: de PIC verstuurt de data sneller dan dat de PC ze inleest.
Vanuit de PIC gezien moet je dus een kleine pauze inlassen voordat je de volgende byte verstuurt.

Wederom stierepoep. De PIC verstuurt geen volledige characters, zoals reeds omschreven, en dat is het probleem. Dat heeft niets met de snelheid van een PC te maken of hoe snel het binnen komt. Een 8250 redt het prima op 9600bps, zelfs onder M$ winshit. De huidige UARTs zoals ze in PCs toegepast worden, hebben nagenoeg zonder uitzondering een fifo. Die doen het dus helemaal op hun sloffen.

Op 26 oktober 2005 17:19:35 schreef huubsel:
Ik heb het probleem gevonden.
het lag aan het verzenden. er moest steeds tussen het verzenden een kleine pauze.

Je test toch wel TXIF of TRMT tijdens het zenden ???

@Marco69:

De TS schrijft in de openingspost:

... ik heb een paar dingen naar de pc gestuurd ...

Hij verstuurt dus iets VANUIT de microcontroller NAAR de computer.
Dus waarom begin je dan over een UART?

Er is geen externe UART aangesloten: de PIC heeft een interne UART.
In de datasheet van de 16F877a staat:

The TXREG register is loaded with data in software.
The TSR register is not loaded until the Stop bit has
been transmitted from the previous load. As soon as
the Stop bit is transmitted, the TSR is loaded with new
data from the TXREG register (if available).

Wat daar staat, betekent: er wordt GEEN nieuwe byte in de seriele transmitter geladen voordat de vorige byte VOLLEDIG is verstuurd (inclusief stopbit).
Er wordt dus niet met het verzenden van een nieuwe byte begonnen terwijl het versturen van de huidige byte nog aan de gang is.

Het scenario wat jij schetst,

... Gevolg is dat wanneer jij de volgende byte schrijft voordat de huidige geheel naar buiten geschoven is, de huidige cyclus afgebroken wordt en een nieuwe gestart wordt. ...

kan dus helemaal niet!

Wat wel mogelijk is, is dat de bytes vanuit de PIC te snel worden verstuurd.
De PC heeft toch (een zeer korte) tijd nodig om een binnengekomen byte in te lezen, of niet soms?

Hij verstuurt dus iets VANUIT de microcontroller NAAR de computer.
Dus waarom begin je dan over een UART?

Er is geen externe UART aangesloten: de PIC heeft een interne UART.

Make your point. Niemand heeft het over een externe UART gehad. Of het ding nou in de PIC zit of niet is 'wurst'.

De PC heeft toch (een zeer korte) tijd nodig om een binnengekomen byte in te lezen, of niet soms?

Nee. De tijd die de volgende byte nodig heeft om binnen te komen is daar meer dan toereikend voor. Als-ie dat niet is, mis je een compleet character. Op 9600bps (waar je dus zomaar 1mS hebt om een character ongebufferd te lezen uit de PC UART), redt zelfs M$ winshit dat zonder mankeren, dus dat scenario gaat niet plaats vinden.

Het scenario wat jij schetst...

Daar heb je dus de luxe versie, zoals omschreven (vertelde al, ken de MicroChip architectuur niet). Dan is het verhaal eigenlijk nog veel eenvoudiger: Hij rost die bytes zo snel de TXREG in (blijkbaar de MicroChip benaming voor wat ik UDR noemde), dat de laatste er al in zit voordat de eerste verzonden is. Bedenk dat je op 9600N81 10 bits moet versturen per byte. Je doet daar dus een dikke 100uS over. Dat zijn heel wat clock cycli!

Overigens zit de oplossing van het verhaal in de opmerking van JoWi: even kijken of je wel een nieuwe byte kunt schrijven. Ofwel: de polling methode zoals ik die eerder omschreef. Zie ook pag 117 van de MicroChip datasheet. De U(S)ART implementatie van MicroChip schematisch uitgelegd.

Hij rost die bytes zo snel de TXREG in (blijkbaar de MicroChip benaming voor wat ik UDR noemde), dat de laatste er al in zit voordat de eerste verzonden is.

Dat zeg ik dus net: dat kan helemaal niet.
TXREG is een 8-bits register waarin je een byte klaar zet die je wilt versturen.
Die byte wordt pas in de TSR (Transmit Shift Register) geladen als deze leeg is, dus als de vorige byte IN Z'N GEHEEL verzonden is.

TXREG is wat jij noemt de USR.
TSR is wat jij noemt de UDR.
We hebben niet te maken met "Eenvoudiger UARTs missen een UDR.", maar met de luxe uitvoering.
Het is dus niet mogelijk dat "de huidige cyclus afgebroken wordt en een nieuwe gestart wordt".

Nogmaals: RTFD.

Dat zeg ik dus net: dat kan helemaal niet.

Alweer stierepoep. Eerst lezen, dan zeuren. (om je even op weg te helpen: je kunt die dingen zo snel de TXREG in schrijven als je wilt. Wat er acuteel in staat zal verstuurd worden als TSR leeg is. Althans, dat staan in de door jou zo geprezen datasheet )

TXREG is wat jij noemt de USR.
TSR is wat jij noemt de UDR.

Bijna goed. Precies andersom.

Nogmaals: RTFD.

Lijkt me inderdaad voor jou niet overbodig. Overigens: pak dan ook even een willekeurige datasheet van een 8250 (of willekeurig welke algemeen gebruikte UART) of een AVR. Die zijn wat uitgebreider in hun uitleg over hoe een UART werkt.

je kunt die dingen zo snel de TXREG in schrijven als je wilt

Ja, nou en? Hoe snel je die dingen (je bedoelt "bytes" neem ik aan?) ook TXREG in schrijft en wat er op een bepaalt moment ook in TEXREG staat, feit blijft:

Er wordt GEEN nieuwe byte in de seriele transmitter geladen voordat de vorige byte VOLLEDIG is verstuurd (inclusief stopbit).
Er wordt dus niet met het verzenden van een nieuwe byte begonnen terwijl het versturen van de huidige byte nog aan de gang is.

Het scenario wat jij schetst,
"... Gevolg is dat wanneer jij de volgende byte schrijft voordat de huidige geheel naar buiten geschoven is, de huidige cyclus afgebroken wordt en een nieuwe gestart wordt. ..."
kan dus helemaal niet!

Daar veranderd niets aan.

TXREG is wat jij noemt de USR.
TSR is wat jij noemt de UDR.
Bijna goed. Precies andersom.

Je hebt gelijk: precies andersom.

pak dan ook even een willekeurige datasheet van een 8250 (of willekeurig welke algemeen gebruikte UART) of een AVR

Waarom? Dat bedoel ik dus: we hebben het hier niet over een 8250 of 16450 of AVR of wat voor aliens dan ook maar: we hebben het hier over een PIC.
En zoals je zelf al aangaf:

ik heb geen ervaring met PICs

Dus: RTFD

@logic:
Dit heeft absoluut niets met PICs te maken. Dit heeft alles te maken met algemeen begrip van seriele communicatie en hoe een UART dat doet. In elke post die je doet geef je er weer blijk van dat je de bel wel hebt horen luiden, maar geen idee hebt over wat een klepel is (laat staan dat je weet waar die hangt). Vandaar dat ik je aanraad om je daar eens iets in te verdiepen. Het is best leuke materie, en als het muntje eenmaal gevallen is, is het eigenlijk redelijk simpel en straight forward. En stiekem komt het in veel meer communicatie voor dan je in eerste instantie zou denken.

Verder lees je erg slecht wat ik tik (je blijft op een eerste aanname van mij hakken waarvan ik vooraf al aangaf dat het een aanname was en later zelf al aangegeven heb dat die onjuist blijkt te zijn), dus nog een reactie daarop is zinloos.

@huubsel: Kijk nog even naar TXIF, check die voordat je de volgende byte stuurt. Mooier nog: doe het op interrupt basis (alhoewel dat best nog even een uitdaging kan zijn als je daar niet in thuis bent). Komt het helemaal voor elkaar. Zolang je op 9600bps zit hoef je je absoluut geen zorgen te maken over de 'receiving side' als dit een PC is. Overigens... Als je vanaf de PC ook data terug gaat sturen, is het denk ik een vereiste om de Rx van de PIC op interrupt basis te doen. Polling kan wel, maar doorgaans is het erg tricky programmeeren, met een redelijke kans op gemiste bytes. Er is vast wel een AN van MicroChip die dat voorkauwt (onder het motto: beter goed gejat dan slecht zelf verzonnen).