Sida 1 av 2

Läsa in seriell information... [AVR]

Postat: 21 september 2008, 19:19:06
av Snouser
Jag håller för tillfället på att lära mig lite Assebler och har nu stött på ett problem. Problemet är de att jag inte vet hur AVR kretsen beter sig när information skickas till den.

Meningen är att ja ska skicka information till min AVR uC och sedan spara informationen i EEprom minnet.
Prylen som skickar informationen är en RFID läsare, i manualen står det så här..
The start byte and stop byte are used to easily identify that a correct string has been received from the
reader (they correspond to a line feed and carriage return characters, respectively). The middle ten bytes
are the actual tag's unique ID.
Efter lite läsande i en uC bok som har jag listat ut att jag ska använda mig utav följande kod för att hämta information seriellt.

Kod: Markera allt

.DEF UART_Char = r16
GetChar_UART_POLL:
sbis USR, PXC
rjump GetChar_UaRT_POLL
in UART_Char, UDR
ret
Som jag förstår det så hämtar denna lilla kodsnutt bara en byte i taget. Enligt RFID läsarens manual så skickar den lite mer än så.

Nästa steg om jag (om jag får gissa lite) borde bli att spara denna byten i SREG registret, för där kan man väll spara relativt stora värden?

Hur jag har inte listat ut en.

När man sedan har hela serienumret i SREG så borde man kunna skriva detta till EEProm. Frågan är bara hur...

Någon som skulle kunna hjälpa mig på traven?


Tack på förhand.

Postat: 21 september 2008, 19:39:38
av sodjan
Vad är SREG ? Är det inte det status registret ?
Hur ska du "spara data" där ?

> När man sedan har hela serienumret i SREG...

Som sagt, jag tror att du är helt ute och cyklar... :-)

Det som du nog måste göra är att sätta dig med AVR databladet några
dagar och inte bekymra dig så mycket om koden just nu.

> Problemet är de att jag inte vet hur AVR kretsen beter sig när information skickas till den.

Som sagt, det skulle förvåna mycket om det inte står i databladet.
Du får bättre svar om du mer konkret talar om vad som var oklart
i databladet.

Postat: 21 september 2008, 19:41:08
av Micke_s
Lite pseudokod hur jag hade gjort.

Innan du börjar ta emot något.
Ladda x där med adressen för första byten ska lagras.

Kod: Markera allt

Ta emot en byte i taget lagra i ram:et
om x är carrier return kör "save eeprom" och Ladda x där med adressen för första byten ska lagras.
spara USR till X
kör Store Indirect and Post-Inc på X
om x har ökat  med 10 så sluta öka den för förhindra overflow


save-eeprom:
 Ladda x där med adressen för första byten ska lagras

kör detta 10ggr
 Load Indirect and Post-Inc på x
 spara i eepromet enligt dokumentationen

Du kan använda interrupt om du vill.

Edit: och som sodjan skriver är det bra att läsa manualen för processorn.

Postat: 21 september 2008, 19:46:10
av Fagge
Kan detta vara till någon hjälp?.

http://uppmedbilden.com/out.php/i1758_IMG4065.JPG Full Storlek

Bild

Postat: 21 september 2008, 19:56:20
av Swech
Du bör börja med något enklare..
Blinka med lite lysdioder först...
Det andra löser du nog inte utan att labba lite grundläggande först.

Ta din AVR processor, anslut en led till en pinne (med 330 ohm)
och få den att blinka...

Swech

Postat: 21 september 2008, 19:58:43
av Snouser
@Fagge Det är precis den boken jag har läst och har framför mig :D
Skrivningen till minnet tror jag att jag klarar av, men jag vet inte riktigt hur jag ska ta emot informationen som skickas till mig.
sodjan skrev:Vad är SREG ? Är det inte det status registret ?
Hur ska du "spara data" där ?

> När man sedan har hela serienumret i SREG...

Som sagt, jag tror att du är helt ute och cyklar... :-)

Det som du nog måste göra är att sätta dig med AVR databladet några
dagar och inte bekymra dig så mycket om koden just nu.

> Problemet är de att jag inte vet hur AVR kretsen beter sig när information skickas till den.

Som sagt, det skulle förvåna mycket om det inte står i databladet.
Du får bättre svar om du mer konkret talar om vad som var oklart
i databladet.
Jag tror att ja skrev lite fel, jag menar SRAM, eller är jag helt fel då också tro?

Borde man inte kunna göra någonting så här för att lägga till bitar i SRAM.

Kod: Markera allt

ldi  YH,LOW(RAMED)
ldi  YL,HIGH(RAMED)
ld Y+ r19 
Om man lägger varje byte som kommer in i r19 och sedan sparar den i Y så kan man väll sedan skriva de till EEprom.

Frågan är bara hur informationen som anländer till uC ser ut. Läggs allt sammtidigt i UDR eller hur fungerar det?

Tack för hjälpen hittills.

Postat: 21 september 2008, 20:00:32
av Snouser
Fagge skrev:Kan detta vara till någon hjälp?.

http://uppmedbilden.com/out.php/i1758_IMG4065.JPG Full Storlek

Bild
Det har jag redan lyckats med.
Efter drygt 750 sidor så börjar man förstå hur det fungerar.

Jag kanske har börjat på lite för svåra saker, men, vad är det värsta som kan hända.

Man borde lära sig nått...

Postat: 21 september 2008, 20:21:23
av sodjan
SREG eller SRAM, det är ju en *jäkla* skillnad... :-)

> Frågan är bara hur informationen som anländer till uC ser ut. Läggs allt sammtidigt i UDR eller hur fungerar det?

UDR är väl registret där mottagna bytes ("tecken" om du vill) hamnar.
Du ska få 12 tecken/byte och får alltså läsa UDR 12 gånger. Enklast är
naturligtstvis at låta USART'en trigga ett interrupt där du tar hand om tecknen.

Om du inte läser ut datat från UDR så skrivs det över (och det borde
sättas någon "overrun" flagga) och det enda du har kvar är stopp-tecknet.

Postat: 21 september 2008, 20:25:30
av Snouser
Men UDR klarar ifall att ta emot alla information på samma gång, och sedan kan man plocka en byte i taget, har jag förstått rätt?

Postat: 21 september 2008, 20:30:41
av sodjan
NEJ.

Postat: 21 september 2008, 20:32:10
av Icecap
En UART-funktion i en µC är till för att ta emot en byte åt gången, hårdvaran tar hand om "allt". Oftast kan man ställa den i lite olika lägen men vi utgår ifrån standardläget.

Det finn "alltid" en flagga som betyder "en byte har tagits emot", inte sällan kan den utlösa en interrupt om man vill det, i annat fall får man polla.

Det man gör är att kolla flaggan (antingen vid att använda interrupten eller polla) och när det kommer en byte läser man den och sparar på rätt plats i den buffer man har reserverat.

Sedan räknar man upp pekaren (vilken plats i buffern) och börjar om.

Om man vill kan man få den att trigga på vissa förhållanden, t.ex. ett visst värde eller ett visst antal tecken eller annat.

Postat: 21 september 2008, 20:37:48
av Fagge
Mycket bra förklaring Icecap!. :tumupp:

Postat: 21 september 2008, 20:46:39
av Snouser
Icecap skrev:En UART-funktion i en µC är till för att ta emot en byte åt gången, hårdvaran tar hand om "allt". Oftast kan man ställa den i lite olika lägen men vi utgår ifrån standardläget.

Det finn "alltid" en flagga som betyder "en byte har tagits emot", inte sällan kan den utlösa en interrupt om man vill det, i annat fall får man polla.

Det man gör är att kolla flaggan (antingen vid att använda interrupten eller polla) och när det kommer en byte läser man den och sparar på rätt plats i den buffer man har reserverat.

Sedan räknar man upp pekaren (vilken plats i buffern) och börjar om.

Om man vill kan man få den att trigga på vissa förhållanden, t.ex. ett visst värde eller ett visst antal tecken eller annat.
Okej, nu börjar jag förstå..

Men skickar inte sändaren all information på samma gång?
Eller är det så att uC hinner bearbeta informationen varje byte innan en ny kommer?

Jag menar, om en enhet skickar en massa tecken, och mottagaren inte hinner med försvinner det då inte information längs med vägen?

Postat: 21 september 2008, 20:54:47
av sodjan
> Men skickar inte sändaren all information på samma gång?

Nej, det går ju inte. Det är ju bara en kabel... :-)
Det går ju inte att skicka mer än en signal åt gången på en kabel.

> Eller är det så att uC hinner bearbeta informationen varje byte innan en ny kommer?

Det är bara att räkna lite på det.

Vilken hastighet (baud rate) kör du med ?
Hur lång tid blir det då *mellan* varje tecken ?
Hur mycket (hur många instruktioner) hinner en AVR med på samma tid ?

Postat: 21 september 2008, 20:58:47
av Andax
Har man ingen typ av flödeshantering finns risk att tecken försvinner om man inte läser av tillräckligt snabbt. Kör man vanlig seriekommunikation och inte på maxad baudrate brukar det inte vara något problem.

Det är därför det är bra att använda en interrupt-rutin att läsa av UDR till en RAM-buffer eftersom man minskar risken att tappa tecken.