robo_wolf,
jau, danke für den Hinweis auf den Fehler - ist schon korrigiert!
Es macht richtig Spass, mitzulesen, wie Du Dich in das Thema hineinwühlst
! Am Besten gefällt mir Deine Schlussfolgerung:

Zitat von
robo_wolf
Aber dieses Thema einmal komplett durchdacht und abgearbeiten - kann mann diesen Treiber immer wieder verwenden, in andere Projecte includen.
Zu genau demselben Schluss bin ich nach ein paar Monaten auch gekommen und bin damit seither gut gefahren. Ein Programm-Modul deckt bei mir jeweils eine Funktion komplett ab (im Sinne von Kapselung, wie man sie von objektorientiertem Programmieren her kennt). Z.B. steckt die Handhabung des TWI-Busses und meines eigenen TWI-Protokolls in einem Modul. Wenn ich Daten über den Bus versenden will, schreibe ich sie byteweise in die Ausgangs-FIFO, rufe im TWI-Modul die Prozedur TWI_SEND auf und weiter geht's. Über die ganze interne Abwicklung im Modul brauche ich nie mehr (
) Gedanken zu machen.
Die Module werden einfach per "include"-Anweisung eingebunden. Z.B. sieht der "include"-Block in meinem 13kB-Programm so aus:
Code:
.include "ASTWI16_V01.asm" ; Modul zur TWI-Abwicklung
.include "ASTWIIF16_V04.asm" ; Interface zwischen Hauptprogramm und TWI-Modul, enthält die Dialogstruktur
.include "FIFOk16_V01.asm" ; Ein- und Ausgangs-Datenpuffer für TWI-Bus
.include "System16_V02.asm" ; div. Utilities, z.B. ASCII_to_hex u.ä.
.include "MathLibSF24_16_V07.asm" ; 32-Bit Fliesskomma Bibliothek
.include "M2KNavigation_16_V08.asm" ; Koppelnavigations-Algorithmus
.include "ADNS2610SPI16_V05.asm" ; SPI-Kommunikation mit dem Maussensor
.include "ASADNS2610IF16_V04.asm" ; Interface zwischen Hauptprogramm und Maussensoren
.include "ZstAutomat16_V04.asm" ; der Zustandsautomat zum Hochfahren und Überwachen der Maussensoren usw.
Dieses Vorgehen führt zu etwas erhöhtem Zeitbedarf, weil man sich bestimmte Vorschriften setzen und sie einhalten muss. Z.B. werden bei mir alle verwendeten Register mit "push"- und "pop"-Anweisungen gesichert, damit ich nicht jedesmal nachgucken muss, welche Register verändert werden. Trotzdem hat das Verfahren sich sehr bewährt, weil es mir erlaubt, mit Assembler fast wie in einer Hochsprache Programme zu schreiben. -
Der Vollständigkeit halber habe ich im Anhang noch die Geschichte mit dem Zustandsautomaten zuendegeführt. Bin gespannt auf Dein nächstes "Lernprogramm". Als Takt für den Timer-Interrupt schlage ich vor, zunächst mit so 2 bis 5 Hz anzufangen; da kann man das Flackern noch sehen. Wenn dann alles fehlerfrei läuft, kannst Du's immer noch schneller machen.
Ciao,
mare_crisium
@oberallgeier,
ja, für diese Anwendung könnte ein endlicher Zustandsautomat ein gangbarer Weg sein. Natürlich nur, wenn er in Assembler programmiert ist, nicht in cäh
!
mare_crisium
Lesezeichen