Verwerking data in AVR

Ik ben niet bekend met AVR, maar het lijkt me dat je, direct na het ontvangen van een byte je deze overhevelt naar een interne variabele.
Bij voorkeur een string/array waarbij je in de ontvangstroutine bijhoudt in welke index de ontvangen byte moet worden opgeslagen,

Kijk eens naar de interrupts, daar staat minstens 1 interrupt tussen die bruikbaar is.

Er staat een voorbeeldje in de datasheet.

Wat hadv zegt klopt; een AVR onthoud alleen de laatst ontvangen byte. Die moet je uitlezen voordat de volgende byte ontvangen is, anders ben je hem kwijt.

Het komt ongeveer hierop neer:
1 Wacht totdat een teken ontvangen is
2 Doe iets met dat teken
3 Ga naar 1.

Meestal is "doe iets" stop in een buffer en wacht totdat je genoeg tekens (of het "einde commando"-teken hebt.

Met interrupts kun je het mooier maken, maar begin eens zonder.

Ik zou het simpel houden en het wiel niet opnieuw gaan uitvinden:

- upload de Arduino bootloader, en gebruik dan de Serial class die hierin zit

OF

- gebruik de lib van Peter Fleury en lees serieele data dmv van die functies

Bedankt voor de reacties!
Ik had al het idee om ze telkens in een string te duwen maar ik heb niet veel kennis van het programmeren..
Heeft iemand misschien een voorbeeldje van een code?
Ik zou echt niet weten hoe ik dit byte per byte er uit moet halen.

Telkens je een karakter ontvangen hebt moet je het wegschrijven in een buffer.
In pseudocode:

int cnt = 0;
char data[5]; //X123 + linefeed

ISR(USART_RXC_vect)
{
    data[cnt] = UDR;
    if((++cnt) > 4)
        cnt = 0;
}

edit: stukje code werkt met interrupts dus niet vergeten om sei() op te roepen en de juiste interrupt te enabelen.

Nvm, vraag verkeerd begrepen...

[Bericht gewijzigd door Nieko op vrijdag 28 november 2014 14:56:35 (92%)

TS geeft aan dat hij nauwelijks kan programmeren en dan meteen met interrupts aan de slag? Grote kans dat hij niet weet wat het zijn.

Tsja... Da's lullig voor de TS. Maar UART op polling basis?

Het advies om een bestaande implementatie te nemen is denk ik beter.

Weeral bedankt voor de antwoorden.
Ik weet wat interrupts zijn, alleen welke juist is bij welke situatie is nog wat uitzoeken aangezien de uitleg beperkt is in de les.

Vergeet die les. Lees een datasheet, scoor een development board en ha spelen. Veel leerzamer dan die les.

Vergeet dat datasheet. Leer de les. Zo'n datasheet is zonder basis kennis niet te snappen.

Eric heeft gelijk hoor, zo'n datasheet leer je een hoop van. Maar het kost wat tijd-en-ervaring voordat je effectief kan omgaan met een datasheet. Een atmega32 is dan nog wel een mooi ding, omdat het datasheet redelijk van begin tot eind te lezen is. Bepaalde afdelingen moet je dan 1 klein stukje goed bestuderen, en dan meteen door naar het volgende hoofdstuk. Zo heb je de instructies. Probeer van 1 of 2 te begrijpen wat er staat en daarna volgende hoofdstuk! Idem met de elektrische specs. Nu niet van belang. Probeer een enkele tabel (bijvoorbeeld de "absolute maximum ratings") uit te pluizen en een grafiekje (bijvoorbeeld IO pin current versus voltage fig 171 en 175, en verklaar de verschillen!)

Bij een STM32 met een datasheet van rond de honderd en dan een reference manual van rond de duizend paginas is dat dus niet te doen.

Op 28 november 2014 16:27:49 schreef EricP:
Maar UART op polling basis?

Als eerste begin? Lijkt me verstandiger om eerst een UART op polling basis te doen, en dan pas op basis van interrupts.

Dan hoef je maar een ding tegelijk te leren, en dat is makkelijker dan twee tegelijk.

Los daarvan zijn er heel veel applicaties waar een UART op polling basis gewoon prima is, en daarmee dus de beste oplossing (want simpeler, en simpeler is beter. Mits nog steeds functioneel uiteraard.)

Los daarvan zijn er heel veel applicaties waar een UART op polling basis gewoon prima is, en daarmee dus de beste oplossing (want simpeler, en simpeler is beter. Mits nog steeds functioneel uiteraard.)

Houd toch op man... Dat is gepruts in dezelfde hoek als delays enzo. Niet aan beginnen. Garantie voor gezeur. Spul gebruiken zoals het bedoeld is en je niet in bochten gaan wringen omdat 'het ook zo kan'.

En joh... Dan begin je met timer interrupts. Dan heb je dat kunstje door, pak je daarna de UART. Dat moet toch in een uur of 2 te regelen zijn?

Op 30 november 2014 21:34:26 schreef EricP:
[...]Houd toch op man...
Dat moet toch in een uur of 2 te regelen zijn?

Beetje rare reactie, Rome is ook niet in een dag gebouwd, kleine stapjes werken vaak het beste zeker voor een beginneling. Laat TS eerst even lekker prutsen. Ik zou dit als beginneling (van wat ik er nog van weet) dit zeker niet in 2 uur voor elkaar krijgen. Eerder een paar dagen 'lekker' prutsen.

Vanuit jou perspectief als iemand met veel ervaring zal interrupt driven het beste zijn voor deze situatie en dat is ook zo, maar polling is in veel situaties ook prima, daar een uC vaak 98% van de tijd niks zit te doen. Ik ben het zeker met je eens dat dit niet de beste oplossing is voor deze situatie, maar om het te leren is het prima.

Eerder een paar dagen 'lekker' prutsen.

Een paar dagen??? Het staat op 1 kantje datasheet. Hoe vaak wil je dat lezen dan? De compiler handelt stack-gedoe af (instinker in assembly: bij een ISR zet een AVR z'n flags niet op de stack; als je ze om zeep helpt dus zelf doen), dus daar hoef je ook niet over na te denken. Ik weet niet precies welke AVR TS heeft, maar vaak staat er een hapklaar voorbeeld in de datasheet en anders wel in een application note. Dus zelfs met copy&paste moet het (weliswaar zonder enig begrip) kunnen draaien.

maar polling is in veel situaties ook prima

Sterker nog... Er zijn situaties op bepaalde controllers waar polling DE oplossing is - omdat het (in die situatie) sneller is dan interrupt driven (en nee, dat gaat niet over een UART). Dat zijn heel uitzonderlijke situaties. En meestal vergt dat wel wat studie (en assembly) om het controllertje precies te laten doen wat je wilt. Dat je daar nog nog eens een paar dagen mee zit te prutsen en te proberen... soit.

Het is me gelukt om de data juist uit te lezen met behulp van de gegeven code door the-x en het is gelukt via een interrupt.
Erg bedankt voor alle gegeven hulp en tips!