Druckbare Version
robo_wolf,
ich vermute stark, dass Du es mit einer der AVR-Gemeinheiten zu tun hast, vor der ich Dich schon lange hätte warnen müssen:
geht nicht. Diese Anweisung kann Konstanten nur bis 63 verarbeiten. Um ENDADR auszurechnen musst Du eine reguläre 2-Byte-Addition benutzen ;-).Code:adiw xh:xl,KONSTANTE ; mit KONSTANTE >= 64
Ciao,
mare_crisium
mare_crisium,
muss mich korrigieren...
habe nun bei der Prozedur FIFO8_WRITE
diese Zeilen eingefuegt.Code:FIFO8_WRITE:
....
;
; brge -> -64 = k = +63
mov yl,r17
mov yh,r18
;
sub yl,yh
clr yh ;
andi yl,0x3F ; ist nie groesser 63
; brge -> -64 = k = +63
cp yh,yl
brge FIFO8_WR_EXIT ; Sprung, wenn FIFO voll ist
....
Es gefaellt mir aber noch nicht so richtig.
robo_wolf,
ich fürchte, in Deinem zweiten Posting hast Du Dich ein bisschen vergaloppiert ;-) . Dein erstes Posting (Heute, 14.05. um 09:30) bezieht sich auf Zeile 122 Deines Moduls "FIFO8.asm"
Das Problem Deines zweiten Postings verstehe ich nicht. Natürlich darf FIFO_CAP grösser als 64 sein! Du musst nur zum Berechnen von ENDADR eine anderen Weg gehen (siehe oben) ;-) !Code:...
FIFO8_CREATE:
...
; FIFOkapazität speichern
std z+FIFO8_CTRL_CAP,r16 ; Kapazität speichern
; WRADR und RDADR auf Anfang setzen; ANFADR und ENDADR in RAM schreiben
mov xl,zl
mov xh,zh
adiw xh:xl,FIFO8_CTRL_LNG ; FIFO-Steuerung ueberspringen - auf erstes FIFO-Byte zeigen
std z+FIFO8_CTRL_WRADR_LOW,xl
std z+FIFO8_CTRL_WRADR_HIGH,xh
std z+FIFO8_CTRL_RDADR_LOW,xl
std z+FIFO8_CTRL_RDADR_HIGH,xh
;
std z+FIFO8_CTRL_ANFADR_LOW,xl
std z+FIFO8_CTRL_ANFADR_HIGH,xh
; !!! ACHTUNG:
adiw xh:xl,FIFO8_CAP ; ENDADR berechnen
; Über diese Zeile beschwert sich der Assembler, wenn FIFO8_CAP
; grösser als 64 ist. Deshalb musst Du sie durch
ldi r16,FIFO8_CAP
add xl,r16
clr r16
adc xh,r16
; ersetzten. Dann klappt's auch mit Kapazitäten > 64.
...
Ciao,
mare_crisium
Guten Abend mare_crisium,
...der 2.Teil bezieht sich auch auf das Posting von 09:30
>>>>
brge FIFO8_WR_EXIT ; Sprung, wenn FIFO voll ist
<<<<
Auch hier trifft das Problem mit dem k > 64 zu.
In der Version V02
wenn FIFOkapazität(r17) >64 ist reagiert das Programm anders als wenn <64 ist.Code:; prüfen, ob FIFO8 voll ist
ldd r17,z+FIFO8_CTRL_CAP ; FIFOzähler mit FIFOkapazität vergleichen
ldd r18,z+FIFO8_CTRL_ZHLR ;
/* KOMMENTAR_BEGINN!!!
...
cp r18,r17 ;
...
hier stimmt was noch nicht. Das zweite Byte wird nicht mehr geschrieben.
KOMMENTAR_ENDE !!!
*/
cp r18,r17 ;
brge FIFO8_WR_EXIT ; Sprung, wenn FIFO voll ist
< 64 tut es wie gewuenscht und
> 64 springt er gleich zu FIFO8_WR_EXIT:
robo_wolf,
ich habe versucht, das Problem nachzuvollziehen, krieg's aber nicht hin :-( . Sowohl in Deiner ersten Version (mit den notwendigen Korrekturen) als auch in der Version _V02 schreibt er klaglos in FIFOs mit Kapazität >64, bis sie voll sind. Ich nehme an, dass Du inzwischen in Deinem Programm kräftig umgebaut hast - musst den aktuellen Stand 'mal posten!
Ciao,
mare_crisium
mare_crisium,
bin ratlos...
FIFO8_V02.asm ist unveraendert die Version von Dir.
Bei LernPrgrm_FIFO_TEST_V02.asm habe ich doch nur die
.equ FIFO_FROM_SERIAL_CAP = 211 anstatt die 23 geschrieben.
Die anderen Aenderungen sind in einer V03 gemacht... :-k
Hier noch der Codeabschnitt....beim Aufruf von FIFO8_WRITE.
Ist FIFO_FROM_SERIAL_CAP <64 fuellt sich der RAM, bei >64 springt er zum Ende der Prozedur (FIFO8_WR_EXIT:).
Code:; Hauptprogramm
;
; Jetzt füllen wir mal FIFO_FROM_SERIAL mit 1,2,3,4 ... bis sie voll ist
clr r16
ldi zl,low(FIFO_FROM_SERIAL)
ldi zh,high(FIFO_FROM_SERIAL)
RS_00:
inc r16
rcall FIFO8_WRITE
brts RS_00 ; wenn Schreiben erfolgreich, weiter schreiben
; so jetzt ist sie voll
robo_wolf,
der Grund für das Problem besteht darin, dass der ATmega beim Vergleichen von "signed integer"-Werten ausgeht. Wenn Bit7 von FIFO_CAP gesetzt ist, stellt das für ihn eine negative Zahl dar. Wenn jetzt der Zähler auch 0x00 ist - die Kapazität ist auf alle Fälle kleiner. Deshalb führt er das Programm auf direktem Weg zum EXIT.
Die Lösung des Problems habe ich in _V03 eingebaut (nicht ohne Kommentar ;-) ). Ich hoffe, das Wochenende ist gerettet!
Ciao,
mare_crisium
mare_crisium,
jaaa :-) ... ist gerettet. :-)
Was mich ein wenig gewundert hat, das es bei Dir funktioniert hat....(eventuell ein Wert zwischen 63 und 127 gewaehlt?)
Ich habe mir schon eine Loesung mit der Abfrage auf das ZERO-Flag ausgedacht.
Das wird ja bei Gleichheit der Werte von r17 und r18 gesetzt.
Aber die CARRY-Flag-Loesung ist "runder". (ganz ohne Zweifel)
Was ich Dich, vor Deinem heutigen Posting, noch fragen wollte:
Was passiert eigentlich bei einer Compare-Anweisung.
Wie findet der Vergleich statt? Substraktion der Werte mit Beruecksichtung des Vorzeichens(Bit7)?
Naja... mit der Info wollte ich dann auf Fehler- bzw. Loesungssuche.
PS. bevor ich es vergesse:
Was haelst Du davon fuer die RS232 Kommunication STK500 - PC, einen neuen Thread zu eroeffnen.
robo_wolf,
freut mich :-) für Dein Wochenende!
Ich hatte den Fehler nicht bemerkt, weil ich nicht mit Kapazität > 127 experimentiert hatte. An dem Ganzen kann man gut sehen, wie leicht einem sowas durch die Lappen gehen kann und wie schwer es ist, gründlich zu testen ;-) !
Die Anweisung "cp Rd,Rr" führt tatsächlich eine Subtraktion aus. Die Registerinhalte werden als Werte in 2er-Komplement-Darstellung behandelt - dadurch bekommt Bit7 seine Bedeutung als Vorzeichen.
Das mit dem neuen Thread ist eine gute Idee; vielleicht gibt's dafür ja noch mehrere Interessenten. Aber lass' uns die FIFO noch hier fertigmachen.
Ciao,
mare_crisium
Guten Abend mare_crisium,
- weiter am FIFO -
habe in den Code nun noch die beiden Prozeduren FIFO8_FLUSH und FIFO8_GETCOUNT eingefuegt.
Leider weis ich nicht genau wo und wann sie aufzurufen sind.
FIFO8_GETCOUNT kann bei jedem MAIN-Durchlauf aufgerufen werden...
FIFO8_FLUSH setzt ein Fehlverhalten voraus. Dieses muss erst erkannt werden, bevor der FIFO resetet wird.
Kannst Du mir da noch ein paar Infos geben?
Aber sicher gibt es die. Meine Assemblererfahrung auf Atmels ist zwar nicht sehr gross, tausend Zeilen vielleicht oder zwei, aber es war MEIN Einstieg in die mikroelektronische Wunderwelt. Deshalb lese ich natürlich immer wieder mit einem Auge mit.Zitat:
Zitat von mare_crisium
Guten Morgen mare_crisium,
habe mir ein paar Gedanken zum FIFO8_FLUSH gemacht:
Gruende fuer FIFO8_FLUSH - Aufrufe:
1.
FIFO laeuft ueber
>>> Abfrage in FIFO8_GETCOUNT -- Vergleich FIFO8_CTRL_CAP mit FIFO8_CTRL_ZHLR -> wenn FIFO8_CTRL_ZHLR > FIFO8_CTRL_CAP kommt FIFO8_FLUSH
>>> im schlimmsten Fall wuerden aber andere Programmteile zerstoert !? - neues Problem entsteht
2.
????
Folgen fuer FIFO8_FLUSH - Aufrufe:
gepeicherter Inhalt(vor Fehler) ist nicht mehr verfuegbar
Sollten FIFO-Fehler signalisiert werden?
Guten Abend robo_wolf,
ich habe Dein überarbeitetes Modul durchgesehen - die Kommentare, wie üblich, in der .asm-Datei im Anhang. Viel ist mir nicht mehr dazu eingefallen ;-) .
Die GETCOUNT und FLUSH Prozeduren braucht man erst im Zusammenhang mit der konkreten Anwendung: Bei der RS232-Anwendung, die wir planen, kommt es z.B. vor, dass eine Botschaft fehlerhaft empfangen wurde. Dann hat's keinen Sinn, viel Zeit damit zu vertun, die Botschaft Byte für Byte aus der FIFO auszulesen, nur um sie zu löschen. Mit der FLUSH-Prozedur geht das viel effektiver. Besonders bei langen FIFOs.
GETCOUNT braucht man in dieser Anwendung oft, um zu prüfen, ob die Botschaft auf dem PC richtig zusammengestellt wurde. Z.B. kommt es oft vor, dass ein bestimmter Befehl vom PC an den ATmega eine bestimmte Anzahl Bytes als Parameter braucht. Da ist es praktisch, gleich mal nachzugucken, ob genug Parameter da sind, bevor man anfängt, sich durch die Dekodierung des Befehls zu quälen.
So, wie Du siehst, geht's schon los mit der RS-232-Anwendung :-) !
Ciao,
mare_crisium
mare_crisium,
zum Thema FIFO8_CTRL_ANFADR_* hast Du natuerlich Recht.
Fuer den Anfang war es fuer mich uebersichtlicher diese Groesse als Variable zu sehen und damit arbeiten zu koennen.
Der logische Schritt ist aber nun den Code schlanker und schneller zu machen.
...wollte eigentlich auch auf ENDADR verzichten, da ist der Code(zumindestens bei mir) deutlich mehr
Hier nun die geaenderte Version.
robo_wolf,
so, jetzt geht's weiter. Ich habe mir Deine Version V05 vorgenommen und noch etwas verbessert (wie ich hoffe). Die Schreibprozedur kostet jetzt max. 70 und die Leseprozedur 68 Zyklen. D.h. beide bleiben bei 16MHz unter 5 Mikrosekunden. Damit sollten sie für die RS232-Anwendung fit genug sein.
Wenn Du für die RS232 einen neuen Thread aufmachen willst: Nur zu :-) !
Ciao,
mare_crisium
mare_crisium,
Danke fuer Deine Kommentare.
Da waren ja doch noch einige Schnitzer drinnnen.
Das man den Code beschleunigen konnte war mir klar, nicht aber die Fehler... schaehm. ](*,)
Wie ich Dir schon geschrieben habe, moechte ich beim RS232 einige Daten und Gedanken zusammentragen
und mit diesen werde ich dann den Thread eroeffnen.
...hoffe noch bis zum Wochenende.