Druckbare Version
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.