Seriële datastroom binnenhalen en parsen in PICBASIC

Goedemiddag,

Graag had ik wat hulp bij het volgende;ik wil met een 16F877 seriële data inlezen welke via een max232 binnenkomt op rx tx van de pic.

Aanvankelijk wilde ik wat code gebruiken welke ik gebruikt heb voor het parsen van data uit een GPS-unit. Door gebruik te maken van "wait".

Dat is echter alleen mogelijk in combinatie met Hserin en niet met Hrsin.

Helaas ben ik toch gebonden aan Hrsin, dit omdat de baudrate 115200 is van de binnenkomende data. Die snelheid wordt niet ondersteunt door Hserin.

Nu heb ik na veel lezen inmiddels al weer een paar dagen een houten kop en vraag hier om een zetje ;-)

Eerst even een weergave van de binnenkomende data welke als ascii geïnterpreteerd dient te worden;

00110001 00110010 00110111 00111011 etc.

Vertaald naar ascii krijg je dan;

1 2 7 ;

Daar waar etc. staat volgen dan nog 8 bytes waarna de hele datastroom geactualiseerd op nieuw wordt aangeboden (en door mij weer ingelezen moet worden)

Wat ik er van begrepen heb is dat de USART een fifo buffer heeft welke steeds maar 2 bytes kan bevatten en daarna "een vlag geeft" als teken dat er een overflow plaats vindt.

Middels interrupts kan je steeds tijdig de buffer leeghalen maar dat maakt het (voor mij) ingewikkelder terwijl dat niet nodig lijkt.

Ik dacht het volgende toe te passen;

RCSTA=%10010000
TXSTA=%00100100
Declare Hserial_clear = on
Declare Hserial_baud = 115200

Dim serdata[4] As Word

serdata[0] = Hrsin
serdata[1] = Hrsin
serdata[2] = Hrsin
serdata[3] = Hrsin

Door het commando "Declare Hserial_clear = on" ben ik in de veronderstelling dat iedere keer als ik Hrsin gebruik de buffer wordt leeggemaakt en gevuld met de volgende 2 bytes.

Toch komt er in de pic niet binnen wat ik verwacht (ik controleer namelijk met HTerm de binnenkomende data.

Als ik de pic naar de lcd de waardes van de serdata[0] etc. laat schrijven komen er andere waardes zowel in ascii als bin.

Ziet iemand wat er fout gaat of moet ik per sé aan de interrupt?

Je leest 4 bytes in terwijl er maar 2 in het buffer kan staan

[Bericht gewijzigd door benleentje op 16 augustus 2019 16:22:30 (54%)]

Bedankt!

Ik dacht het zo geconstrueerd te hebben dat iedere Hrsin de buffer eerst leegmaakt en vervolgens de 2 bytes die er in komen er uit haalt en wegschrijft naar de array met de naam "serdata".

Die array beschikt over 4 "vakjes" met de grootte "WORD".
Zodoende zou ik verwachten dat er 4 x een vakje gevuld wordt met de bytes uit de buffer......

Niet om tegen te spreken maar juist om te leren waar ik fout denk.

Je dimt serdata[4] as word(2 bytes) x 4 = array van 8 bytes.

Je moet het array als byte voorzien aangezien de uart maar bytes kan verzenden, tenzij proton vanzelf de conversie doet, maar dat weet ik niet.

[Bericht gewijzigd door MGP op 16 augustus 2019 17:56:38 (18%)]

LDmicro user.

In weet niet wat Hrsin precies doet maar verwacht dat die gewoon 1 byte leest en niet 2. JE zegt ook niets met een interrupt te doen. dus het is heel goed mogelijk dat als je 4x keer achter elkaar leest dat je 1 byte dubbel leest of dat je dat lege bytes leest of dat er bytes over geslagen worden.

Wordt er niet ergens een flag geset of kun je een interrupt krijgen als er data beschikbaar is?

Don't Panic!

Ik gebruik altijd interrupts met daarin een ringbuffer met read/write pointer, enige manier om het betrouwbaar te krijgen bij die snelheden...
Niet echt ingewikkeld, maar een paar regels code...

[Bericht gewijzigd door Arco op 19 augustus 2019 16:32:23 (16%)]

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Niet om iedereen aan het eind even naar de mond te praten maar in ieder antwoord zit een stukje oplossing.

Aangezien ik tijd zat heb en toch op de data moet wachten zette ik een while wend lusje op welke steeds het bitje af-vraagt welke schakelt zodra er data beschikbaar is. (Bit PIR1.5 RCIF)

Dat bitje schakelt al bij één byte dus haal ik die gelijk binnen en de lees-actie zélf reset daarmee het bitje weer zodat alles weer scherp staat om de volgende byte binnen te halen.

Zodra ik voldoende bytes heb binnengehaald ga ik de zaak ontleden en de praktijk heeft inmiddels uitgewezen dat het nu werkt.

Op de foto niet te zien wàt er wordt weergegeven maar de laptop (Hterm) en het eigenbouw kastje dat de data binnenhaald van de lambda zijn het roerend met elkaar eens. Overigens haalt mijn kastje de data niet uit de lambdasonde maar uit een gekocht printje welke op zijn beurt de sonde bestuurd en uitleest.

Ik wil ieder weer hartelijk danken voor jullie bijdrage, zeer gewaardeerd.

PS ik ben nu ook we tot het inzicht gekomen dat die datasheet onontbeerlijk is en een paar regels code voor een interrupt eerder tijdwinst had opgeleverd dan vertraagd.......