vlug herkennen van strings in ingelezen data

Hallo,
Ik heb het volgende probleem:
Met een µC lees ik data van een PC in, over UART. Deze data is eigenlijk een config.ini file, waaruit de µC dus allerlei instellingen moet halen. De ini file bevat standaard strings zoals bvb: "NUMBER=0100".
De data die ik inlees komen in een buffer die groot genoeg is om 2 a 3 van bovenstaande strings te bevatten, maar niet alle 50 of zo die in de ini file zitten. Ik moet dus de strings eruit halen en verwerken voor de overdracht compleet is en ik een bufferoverrun heb. Allemaal niet echt een probleem op 2 dingen na:

1. Wat gebeurt als er juist een string valt op het einde van de buffer (deze wordt dan verdeelt over de laatste en de eerste plaatsen van de buffer). De detectie van de strings die ik nu gebruik kan daar niet mee lachen.

2. De detectie van de strings moet snel gaan. Baudrate ligt niet echt vast, maar moet zo hoog mogelijk liggen (lijn moet zo vlug mogelijk weer vrij zijn), maar de µC moet wel alle string eruit kunnen halen. Ik zoek dus een supersnelle methode om strings uit een buffer te halen.

Tania

Waarom een buffer? Je hebt meer aan een 50 bytes geheugen en je moet natuurlijk al je strings in het geheugen hebben (EEPROM?).

Wat je doet is het volgende: Kijk bij elke byte alle 50 strings na (alleen het eerste caracter), is het caracter goed dan verhoog je het getal (begint bij 0) in het corresponderende geheugenplekje. Dat geheugenplekje bepaalt dus welke letter van welke string gecontroleerd moet worden. Aan het eind van elke string zet je een niet gebruikte waarde, bij ASCII kun je dus alles tussen 128 en 255 gebruiken. Als je die waarde tegenkomt weet je dat je een volledige string binnen hebt en welke het is!

Volgens mij gaat dat op 115200 baud wel lukken trouwens. Da's namelijk bij 1,7,0,1 data maar 12800 caracters per seconde. Dus heb je bij een 8Mhz AVR er 625 instructies voor per caracter.

Op 2 maart 2004 10:40:42 schreef Benadski:
Waarom een buffer? Je hebt meer aan een 50 bytes geheugen en je moet natuurlijk al je strings in het geheugen hebben (EEPROM?).

Ik moet niet alle strings in het geheugen hebben, alleen de waarde (in mijn voorbeeld 0100). De rest van de string is om ervoor te zorgen dat de dummy gebruiker er kan mee werken (om die reden is het plaatsen van een niet gebruikt karakter op het einde ook niet echt een goed idee) Trouwens met 50 byte geheugen kom ik nooit toe om alles in te lezen.

Je hebt toch al een caracter aan het eind van de string, namelijk de newline?

Als ik je voorbeeld goed begrijp is alles tussen het = teken en de \n dus een waarde die je nodig hebt. Je begint met bufferen zodra er een = langskomt, en stopt hiermee bij de newline. Dan heb je precies de waarde in je buffer.

Daar dacht ik ook al aan, maar om te weten welke waarde je dan binnenleest moeten alle waarden inde ini file in een specifieke volgorde staan, en dat wil ik (gebruikersgemak) vermijden. Dus moet ik de hele string inlezen, kijken over welke het gaat, en dan de waarde inlezen.

Op 2 maart 2004 11:12:26 schreef Ben_:
Je hebt toch al een caracter aan het eind van de string, namelijk de newline?

Als ik je voorbeeld goed begrijp is alles tussen het = teken en de \n dus een waarde die je nodig hebt. Je begint met bufferen zodra er een = langskomt, en stopt hiermee bij de newline. Dan heb je precies de waarde in je buffer.

ik zou het ook zo doen maak een beetje je iegen protocol die de piv verstaat de karakters "NUMBER" worden nodeloos verzonden ik zou deze zelfs niet verzenden

je kan dat in 2 bytes gewoon adresbyte en dan databyte

Op 2 maart 2004 11:43:45 schreef Sp3ci3S:

ik zou het ook zo doen maak een beetje je iegen protocol die de piv verstaat de karakters "NUMBER" worden nodeloos verzonden ik zou deze zelfs niet verzenden

je kan dat in 2 bytes gewoon adresbyte en dan databyte

Zo zal het dan worden. Moet ik gewoon nog een VBprogje schrijven zodat de dummy's die het moeten gebruiken er wijs uit geraken (zullen er niet echt kunnen mee lachen anders).

Op 2 maart 2004 11:53:38 schreef Tommi_G:

Zo zal het dan worden. Moet ik gewoon nog een VBprogje schrijven zodat de dummy's die het moeten gebruiken er wijs uit geraken (zullen er niet echt kunnen mee lachen anders).

ik gebruik deze methode ook

ik gebruik in VB gewoon vb chr(20) en dan de data
ik gebruik wel 2 databytes omdat er 16 bit zaken moeten verzonden worden

een vraagje aan jou hoe lees je dat binnen in de PIC met die buffers waar je het over had?

ik zend vanuit de pic een byte om te zeggen dat VB het volgende mag doorzenden (soort goed ontvangen code )

Ten eerste gebruik ik geen PIC :r maar een AVR :) (doet er eigenlijk niet toe)
Die buffers waar ik het over heb zijn ringbuffers. Je reseveert gewoon een brok geheugen (bvb 64bytes) waar je de binnengekomendata in opslaat. Je neemt twee variabelen die het begin en einde onthouden. De eerste verhoog je als je iets schrijft in de buffer, de tweede als je er iets uitleest. Als de twee variabelen dezelfde waarde hebben is het buffer leeg. Is de eerste variabelen op het einde van de buffer, dan begint hij gewoon vooraan weer. Als de eerste buffer de tweede inhaalt heb je een buffer overflow. di je buffer zit vol, je leest sneller in dan je verwerkt.
Ik was niet van plan om een terugkoppeling te gebruiken. PC stuurt gewoon alles achter elkaar, en de µC moet het maar verwerken. Dit is (denk ik) sneller als dat de PC elke keer moet wachten op een acknowledge. Nadeel is wel dat je zeker moet zijn dat de µC alles verwerkt krijgt.

Op 2 maart 2004 14:02:26 schreef Tommi_G:
Ten eerste gebruik ik geen PIC :r maar een AVR :) (doet er eigenlijk niet toe)
Die buffers waar ik het over heb zijn ringbuffers. Je reseveert gewoon een brok geheugen (bvb 64bytes) waar je de binnengekomendata in opslaat. Je neemt twee variabelen die het begin en einde onthouden. De eerste verhoog je als je iets schrijft in de buffer, de tweede als je er iets uitleest. Als de twee variabelen dezelfde waarde hebben is het buffer leeg. Is de eerste variabelen op het einde van de buffer, dan begint hij gewoon vooraan weer. Als de eerste buffer de tweede inhaalt heb je een buffer overflow. di je buffer zit vol, je leest sneller in dan je verwerkt.
Ik was niet van plan om een terugkoppeling te gebruiken. PC stuurt gewoon alles achter elkaar, en de µC moet het maar verwerken. Dit is (denk ik) sneller als dat de PC elke keer moet wachten op een acknowledge. Nadeel is wel dat je zeker moet zijn dat de µC alles verwerkt krijgt.

PIC of AVR pfff doet er einderdaad niet toe

ok van dat ringbuffer dat versta ik

maar voor het binnennemen van de data, je inleesbuffer (toch bij PIC) is maar 2 bytes dacht ik
bij overrun ben je de data kwijt, of werk je met een interrupt?

ik hou nu mijn cyclustijd zo kort mogelijk en ik doe iedere cyclus een controle of er een byte in het USART-register zit, indien ja leeg ik dit buffer en verwerk de data direct (ik zend ook een byte terug naar de PC "goed aangekomen")indien nee doe ik loopt programma gewoon verder

ik heb eigenlijk geen ringbuffer nodig omdat de data direct verwerkt wordt.
dit alles lukt nog maar als mijn cyclustijd groter zal worden ben ik bang dat ik af en toe een overrun zal hebben, als ik geen bevestiging geef naar de PC dat een byte goed ontvangen is

of los jij dat anders op?

Die ringbuffer dient net om niet altijd in het UDR (UART DATA REGISTER) te moeten gaan kijken.
Als op de UDR iets binnenkomt krijg ik een interrupt. Om het interruptprogramma zo kort mogelijk te houden, zet het enkel de data van de UDR in de ringbuffer, en update de variabele die het einde van de ringbuffer bijhoud.
In mijn hoofdlus kijk ik of er iets in de ringbuffer zit waar ik iets kan mee doen.

Op 2 maart 2004 15:02:26 schreef Tommi_G:
Die ringbuffer dient net om niet altijd in het UDR (UART DATA REGISTER) te moeten gaan kijken.
Als op de UDR iets binnenkomt krijg ik een interrupt. Om het interruptprogramma zo kort mogelijk te houden, zet het enkel de data van de UDR in de ringbuffer, en update de variabele die het einde van de ringbuffer bijhoud.
In mijn hoofdlus kijk ik of er iets in de ringbuffer zit waar ik iets kan mee doen.

mm dat bedoelde ik
ik zal dat ook eens proberen te programmeren met zo een interrupt

dan ben je wel zeker dat de zaken zoiezo in het ringbuffer belanden, met een kwestie van dan goed te shiften ben je ervan af

steek je dan een vertraging tussen het zenden van de verschillende bytes in VB ?

Tommi_G -> Ik heb je mail gisteren beantwoord, dus die zit nu in je mailbox ;)

2 Sp3ci3S
Ik was niet van plan een vertraging in te bouwen. De hardware-tests zullen moeten uitwijzen of dit in dit geval nodig is.

2 Bastiaan
Hem hem juist pas gezien, krijgt meteen er eentje terug.

even ter info

het gedoe met het ringbuffer en onvangen van data op interrupt werkt perfect

vanuit VB moet je niks van vertragingen steken:)

bedankt voor het idee