mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ringpuffer... ich verstehe es irgendwie nicht...


Autor: Dennis Brücke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi @all mal wieder ;),

ich versuche mich gerade in eine art Konfigurationsoberfläche per UART
zusammen zu basteln. Leider komme ich mit dem "Ringpuffer" Prinzip
zeichen zu empfangen nicht wirklich klar... und diese dann evtl.
Auszuwerten...

in meiner RX_ISR mache ich derzeitig folgendes:
********************************************************************
Uart_RX_Complete:
          push temp1
          push temp2
          push temp3
          in Save_SREG, SREG

          sbr Flags, 1<<USART_RX

          in temp1, udr
          st x+,temp1
          inc rs_puffer
          cpi rs_puffer, 8
          breq rs_count

          out SREG, Save_SREG
          pop temp3
          pop temp2
          pop temp1
reti

rs_count:
          clr rs_puffer
          ldi xl, low(rs232_rx_puffer)
          ldi xh, high(rs232_rx_puffer)
reti
********************************************************************

Wenn ich jetzt davon ausgehe, das ich 8 Zeichen Empfangen habe (welche
ja nach und nach kommen) wie lese ich diese jetzt gescheit aus...
irgendwie bin ich durcheinander... bis jetzt hab ich das immer so
gemacht.

ISR setzt ein Flag das ein byte empfangen wurde, liest dieses aus und
stored es in den SRAM

Main schaut ob RX Flag gesetzt wurde und weis jetzt das ein Zeichen da
ist und springt zu einem RS232 Receive Handler welcher das eine Zeichen
verarbeitet...

nur komme ich im moment nicht mit dem kopf weiter als ein zeichen...

Gruß Dennis

P.S: @peter habe mir deinen Bootloader auch angeschaut nur verstanden
hab ich es immer noch nicht...

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

du solltest, bei der Verwendung von mehreren reti's in einer ISR auch
bei beiden deine Register wieder vom Stack holen.

Matthias

Autor: Dennis Brücke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias,

uppss... hab ich noch gar nicht gesehen ;) Wird gleich gemacht ;)
aber verstanden hab ich es leider dennoch nicht... (mit dem auswerten)

Gruß Dennis

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder einfach mal umstellen:

Uart_RX_Complete:
          push temp1
          push temp2
          push temp3
          in Save_SREG, SREG

          sbr Flags, 1<<USART_RX

          in temp1, udr
          st x+,temp1
          inc rs_puffer
          cpi rs_puffer, 8
          brne URXC1        ;Bei Zeichen < 8 zu URXC1

          clr rs_puffer
          ldi xl, low(rs232_rx_puffer)
          ldi xh, high(rs232_rx_puffer)

URXC1:    out SREG, Save_SREG
          pop temp3
          pop temp2
          pop temp1
          reti

Bei anderweitiger Verwendung von X XL und XH auch noch auf den Stack
pushen und poppen.
Dabei muß dann natürlich deren Inhalt im SRAM abgelegt werden.

Gruß
Andi

Autor: Dennis Brücke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andi,

ok auch danke für den Hinweis ;) spart ein wenig mehr Code ;)
nur auch dies ist noch nicht wirklich die beantwortung / hilfestellung
für meine Frage ;)

Wie werte ich den Ringpuffer den ich mit jedem ISR mit einem Zeichen
fülle wieder aus ?

Gruß Dennis

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schätze, Du benötigst 2 mal einen Pointer für den Ring-Buffer.
Zum einen einen für die ISR und zum anderen einen für das
"Abholprogramm" in der Main.
Das Abholprogramm vergleicht zuerst seine Zugriffsadresse mit der
Zugriffsadresse der ISR.
Sind beide Adressen identisch, sind keine neuen Bytes zum abholen da
sind sie unterschiedlich ist mindestens 1 Byte zum abholen da.
Genauso die ISR.
Die prüft vorher auch ihre Zugriffsadresse mit der vom Abholprogramm
als Kontrolle, ob vom vermeintlich noch vollem Buffer mindestens 1 Byte
abgeholt wurde oder nicht.
Ist die Zugriffsadresse von der ISR um 1 kleiner, mit Berücksichtigung
des 8-ter Sprunges, als die vom Abholprogramm, ist der Buffer noch voll
ansonsten kann die ISR ein weiteres Byte in den Buffer schreiben.
Ich würde an Deiner Stelle erst mal die Zugriffsadressen im SRAM
speichern, sonst hast Du irgend wann keinen X- und Y-Pointer mehr für
andere Dinge zur Verfügung.

Gruß
Andi

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, die Zugriffsadressen sind ja nur 1 Byte groß (0 - 7).
Mit 8Bit-Befehlen kannst Du einfache Vergleiche durchführen und wenn Du
die konkrete Adresse benötigts einfach die Zugriffsadresse auf den
Anfang des Buffers addieren:

 lds r16,ISRAdr
 ....
 ....
 ldi xl,low(RingBuffer)
 ldi xh,high(RingBuffer)
 add xl,r16
 clr r16
 adc xh,r16

.dseg
ISRAdr:     .byte 1
RingBuffer: .byte 8

Gruß
Andi

Autor: Dennis Brücke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andi,

klingt als währst Du ein wenig skeptisch ;) Hab ich vieleicht das
Prinzip allgemein mir selber "VerKompliziert"?

Oder ist die Herangehensweise mit dem Flag setzen und in Main
überprüfen schon der richtige weg ?

Gruß Dennis

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin überhaupt nicht skeptisch!
Das mit dem Flag ist vielleicht nicht der falsche Weg.
Aber mit für Beide Routinen, ISR-Empfang und Abholprogramm im Main, ist
es glaube ich einfacher und effizienter es mit 2 Pointern zu machen.
Man kann es auch wie folgt machen:

Variablen:
1. Pointer für die ISR = BuffISRAdr (1 Byte)
2. Pointer für das Abholprogramm = BuffMainAdr (1 Byte)
3. Füllstandsanzeige für den Buffer = BuffFill (1 Byte)
4. Der Buffer = Buffer (8 Bytes)

Die ISR prüft vor dem ablegen eines Byte BuffFill.
Ist BuffFill kleiner als 8 kann das Byte an der Adresse BuffISRAdr +
Buffer abgelegt werden, BuffFill um 1 erhöht werden und BuffISRAdr um 1
erhöht werden (bei 8 auf 0 setzen).
Ansonsten ist der Buffer voll weil vom Abholprogramm noch nichts
abgeholt wurde und das Byte verschwindet dann.
Genauso überprüft das Abholprogramm BuffFill.
Ist BuffFill ungleich 0 kann mindestens ein Byte abgeholt
werden,BuffFill um 1  verringert werden  und BuffMainAdr um 1 erhöht
werden (bei 8 auf 0 setzen).
Bei BuffFill = 0 ist kein Byte zum abholen da.
Im Abholprogramm kann das dann in einer Schleife durchgeführt werden
bis eine Kopie von BuffFill für die Schleife 0 ist.

Die Variablen dafür kann man ja im SRAM speichern und mit LDS und STS
darauf zugreifen:
.dseg
BuffISRAdr:  .byte 1
BuffMainAdr: .byte 1
BuffFill:    .byte 1
Buffer:      .Byte 8

Gruß
Andi

Autor: Dennis Brücke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andi,

also das letzte hab ich nun wirklich nicht so ganz verstanden ... :(
habe jetzt erfolgreich geschaft Byte für Byte im SRAM abzulegen.

Mache in der RX_ISR jetzt folgendes:

    ldi xl, low(RingBuffer)      RingBuffer adresse laden
    ldi xh, high(RingBuffer)

    lds temp1, BufferAnzahl      Anzahl der Zeichen
    add xl, temp1                zur Adresse addieren
    clr temp2
    adc xh, temp2

    in temp2, udr                UDR einlesen
    st x, temp2                  und an aktuelle adr store
    inc temp1                    Dann +1 der Zeichen
    cpi temp1, 8                 vergleichen mit max
    brne nochok1                 Überlauf?
    clr temp1                    dann anzahl auf 0
    sts BufferAnzahl, temp1      und storen

nochok1:
    sts BufferAnzahl, temp1      ansonsten store akt. anz.

    sbr Flags, 1<<USART_RX       Flag setzen für Zeichen da


Das Speichern in den Ringpuffer funktioniert prinzipiell schon.
Ich habe mir mal Peter Danneger seinen Bootloader angeschaut, und finde
es sehr interessant wie er die empfangen "Strings" per Sprungtabelle
auswertet nur so richtig verstanden hab ich das ganze ganz und gar
nicht... war ne lange ratlose nacht gestern...

Warum ich das ganze immer noch nicht verstehe ? Keine Ahnung nach so
vielem Lesen und Schreiben meines Sources vollkommen durcheinander...
arggg... schrei

Gruß Dennis

P.S.: @Andi, vieleicht erbarmst Du dich noch einmal und versuchst es
mir anders zu erklären... thnks.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Dennis,

hast du allgemeine Verständnis-Probleme mit Ringspeichern? Guck dir mal
diesen Link an, vielleicht hilft er dir:

http://www.zeiner.at/c/ringbuffer.html

Ich habe diesen jetzt mal mit Abwandlungen für mich übernommen, und es
geht, soweit ich das beurteilen kann. Ich brauche ihn, genauso wie du,
für meine serielle Schnittstelle. Dort habe ich das Problem, dass ich
trotz Hardware-Handshake einige Bytes verliere (der PC reagiert nicht
schnell genug auf das Sperren der Handshake-Leitungen), daher mache ich
es nun über den Ringbuffer.

Gruß Ralf

Autor: Dennis Brücke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Ralf,

wie ich den Ringpuffer aufbauen muss um zu speichern, hab ich soweit
verstanden... nur wie ich diesen dann auswerte, da hängt es bei mir...
ein einzelnes Byte auswerten ist ja nicht wirklich ein Problem nur
mehrere Bytes auswerten und vor allem den Puffer dann wieder richtig
auszulesen. Diese Kombination zwischen auslesen und auswerten, da hängt
es irgendwie, das ich einfach nicht weis wie ich es aufbauen soll.

Nehmen wir einfach mal an, das ich sage ich möchte die Uhrzeit in einem
DS1337 speichern. z.B. Byte C für Uhr einstellen und dann zeit
übergeben. (Ist aber nur ein Beispiel für mein Problem)

Gruß Dennis

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, das mit dem Auswerten ist halt so ne Sache.
Kommt auch darauf an, was Du vor hast.
Willst Du Deinem Kontroller Befehle in Klartext übergeben brauchst Du
komplette Vergleiche von Zeichenketten.
Willst Du Byte-Befehle übergeben ist das einfach mit Zahlenvergleichen
zu machen und dann halt noch die Parameter (Uhrzeit) in entsprechend
gleicher Reihenfolge zu übergeben.
Der Buffer ist nur dazu da, damit der Prozessor bei extremer
Beschäftigung anderswo möglichst keine Bytes verliert.
Und wenn er das doch tut, kann man den Buffer vergrößern.
Für die Auswertung von mehreren Bytes brauchst Du ein weiteres
Zwischenlager im SRAM mit x Bytes wo das Abholprogramm (GET) die Bytes
der Reihe nach hineinschreibt.
Diese Größe hängt auch von dem ab, was Du anstellen willst.

Gruß
Andi

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Dennis,

jetzt wird mir dein Problem klarer.

Wenn ich es richtig verstanden habe, brauchst du das gleiche, was ich
für meinen ISP-Programmer realisiert habe:

Ich würde erstens mal das AUSLESEN vom AUSWERTEN komplett trennen.
Der Ringbuffer ist nur für deine Schnittstelle da, sonst für NIX.

Ich habe mir Gedanken zum Datensatz-Aufbau gemacht, den ich für den
Programmer verwende. Das sieht bei mir wie folgt aus:

Das erste Byte ist immer ein darstellbares Zeichen aus dem ASCII-Satz
und dient als "Befehlskennung"
Alle weiteren Zeichen des Datensatzes sind immer ASCII-Hex-Zeichen,
also "0" - "9" und "A" - "F" und somit Daten. Jeder Befehl wird
mit dem CR-Zeichen (Return) abgeschlossen.

Ich empfange die Daten und setze sie in einen Ringbuffer, der nur für
die serielle Schnittstelle da ist. Aus dem Ringbuffer lese ich die
Daten in den "Befehlsbuffer" bis zum CR-Zeichen ein, wobei ich alle
Zeichen bis auf das erste dahingehend prüfe, ob es wirklich
ASCII-Hex-Zeichen sind.

Dann wird aus dem Befehlsbuffer das erste Zeichen (-> Befehlszeichen)
gelesen und geprüft, ob der Befehl bekannt ist. Wenn ja, übergebe ich
den kompletten Befehls-Buffer der zum Befehl gehörenden Subroutine, die
ihrerseits die Auswertung der restlichen Daten vornimmt (passt die Menge
der Daten zum Befehl, sind die Daten unsinnig, usw.). Zum Beispiel eine
Routine für das Lesen, wobei der Aufbau wie folgt ist:

RAAAAMM

R als Klartext (ASCII-Zeichen "R") für Read
AAAA ASCII-Hex-Zeichen für die Adresse
MM ASCII-Hex-Zeichen für die Menge der auszulesenden Datenbytes

In deinem Fall heisst das dann wohl, das du beim Befehl "C" die
SetClock-Routine aufrufst, die die restlichen Daten im Befehlsbuffer
prüft, und wenn sie gültig sind, schreibst du die Uhrzeit in deinen
Uhren-IC.

Kannst du damit was anfangen?
(Nebenbei, wenn es sich einfacher lösen lässt, bin ich für Vorschläge
dankbar ;-))

Falls du den entsprechenden Code-Schnipsel haben möchtest, sag
Bescheid.

Gruß Ralf

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dennis,

der Trick bei meinem Empfangspuffer ist, daß er komplette 256 Byte
belegt.
Wenn man dann das High-Byte der Adresse konstant hält:

;                               Receive Interrupt
;------------------------------------------------
URXCint:
        ldi     xh, high(rx_buff)       ;set high address byte
        in      ia0, UDR
        st      x+, ia0
        reti

ergibt sich ein automatisches Umlaufen ohne irgendwelche Tests.
Der X-Pointer ist dabei für den Interrupt reserviert, da man ja im
Hauptprogramm bequem mit 2 Pointern (Y,Z) auskommt.

Und bei der Auswertung wird dann auch immer nur das Low-Byte
hochgezählt:

exec_command:
        ldi     zl, low( command_table * 2 - 3 )
        ldi     zh, high( command_table * 2 - 3 )
        mov     a1, yl                  ;save command start
_coi1:  adiw    zl, 3                   ;skip rjmp + odd zero byte
        andi    zl, 0xFE                ;adjust to next word
        mov     yl, a1
        clt
        rjmp    _coi3
_coi2:  ld      a0, y
        inc     yl                      ;increment low address only !
        eor     a0, r0
        andi    a0, 0x5F                ;ignore case
        breq    _coi3
        set                             ;not matching
_coi3:  lpm     r0, z+
        tst     r0
        brne    _coi2
        brts    _coi1                   ;test next command
        lsr     zh                      ;byte to word address
        ror     zl
        ijmp                            ;jump after command string


Somit ist kein extra Umkopieren notwendig.
In der command_table stehen die einzelnen Kommandos gefolgt von einem
RJMP zu der entsprechenden Funktion.

Frag ruhig, wenn Du etwas nicht verstehst.


Peter

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber man könnte es auch noch mittels AND auf eine 2-er-Potenz
verkleinern (für andere Zwecke):
Z. B. für einen Buffer mit 64 Byte:
URXCint:
        ldi     xh, high(rx_buff)       ;set high address byte
        in      ia0, UDR
        st      x+, ia0
        andi    xl,0x3F   ;0b00111111
        reti

Das AND sorgt dafür, das sich der Pointer nur von 0 bis 63 (relative
Adresse) bewegt.
Bei 32 oder 16 Byte dann "and xl,0x1F" oder "and xl,0x0F"
Natürlich muß man auch da aufpassen, das der Buffer keine 256
Byte-Schwelle überschreitet was man mit .org Sicherstellen kann.

Gruß
Andi

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andi,

URXCint:
        ldi     xh, high(rx_buff)       ;set high address byte
        in      ia0, UDR
        st      x+, ia0
        andi    xl,0x3F   ;0b00111111
        reti

Oh oh oh oh, ganz böses Foul !

"andi    xl,0x3F" ändert das SREG, also schleunigst sichern !!!


Peter

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups...
... ist schon klar.
War ja nur mal als Beispiel eingeworfen.
OK, kostet wieder Rechenzeit, und wie es bei Deiner Routine aussieht,
ändert kein Befehl das SREG was wiederum Zeit spart wenn man es nicht
sichern (und andere Register) muß.

Gruß
Andi

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.