Adressierung über Index

[gulliver]

Hallo

Seit Tagen verbiege ich mich bei folgendem Problem:
Ich beschäftige mich zur Zeit mit der Programmierung einer Laufschrift, ähnlich der auf der Seite

http://home.wanadoo.nl/electro1/avr/dotmatrix.htm

Ich benutze aber kein intelligentes Display, sondern verwende die 5x7-Punktmatrixmodule TA07-11 von Reichelt.
Die Zeilen werden mit einem ULN2803A durchgetickert, die Spalten zeilenweise in 5 mal 74HC595 eingetaktet (40 Spalten).
Um die richtige Taktung zu überprüfen und die Zeilenfrequenz einzustellen, damit die Anzeige nicht flimmert, habe ich einen Punkt spalten- und zeilenweise durchlaufen lassen. Das ist soweit ok.

Der Zeichensatz ist zeilenweise im Speicher abgelegt (7 Zeilen je 8 Bit) und jeweils, wie üblich, über ein Label erreichbar.
Dabei habe ich mich an die Organisation des LCD-Zeichensatzes gehalten (ist einfacher, brauchte nur die Bits übernehmen).
Dies sieht dann so aus:

A:
.db 0b01110000, 0b10001000, 0b10001000, 0b10001000, 0b11111000, 0b10001000, 0b10001000, 0

B:
.db 0b11110000, 0b10001000, 0b10001000, 0b11110000, 0b10001000, 0b10001000, 0b11110000, 0

C:
.db ... usw., Sch...arbeit, den kompletten Zeichensatz einzutippen

Das Bit0 wird zuerst gelesen, der ganze Ramsch nach links rausgeschoben und in den Datenpin des 74HC595 eingetaktet.
Das erste Byte ist dabei die oberste Zeile, das letzte die unterste und die abschliessende Null wegen der Wortadressierung.
Beim Einlesen wird bis zum 6.Bit gezählt (6.Bit ist Leerspalte zwischen den Buchstaben) und der Rest wird verworfen und das entsprechende Zeilenbyte des nächsten Zeichen eingelesen. Die einzelnen Zeichen werden von rechts ins Display geschoben. So kann man den Satz Zeichen für Zeichen so einlesen, wie man ihn liest und erscheint auch so im Display. Da die Anzeige während des Eintakten abgeschaltet ist, sieht man dies nicht.

Nach jeder komplett eingelesenen Zeile wird das Display eingeschaltet. Die ganze Taktung geschieht während eines Interrupts. So ist gewährleistet, daß die Zeilen nicht gegeneinander verschoben werden.

Nun stehe ich vor dem Problem, das in ein Register eingelesene Zeichen einem Label in der Tabelle zuzuordnen. Bei Hochsprachen hat ja jedes Zeichen eine Ordnungszahl, diese könnte ich dann als Index verwenden. Da ich keine rechte Lust habe, mich in C einzuarbeiten, programmiere ich in Assembler. Da weiß ich nicht, wie diese Nuß zu knacken ist.

Z.B.: es wird 'e' eingelesen und es soll zum Label "e:" gesprungen werden und das entsprechende Zeilenbyte übernommen werden.
Die einzelnen Zeilen lassen sich über einen Index-Zähler adressieren, das wäre nicht das Problem. Das Problem ist, daß ein Label als Adresse definiert wird. An dieser Verbindung vom Zeichen zum entsprechenden Label beiße ich mir die Zähne aus.

Wäre nicht schlecht, wenn jemand einen Tip hätte. Ich hoffe, daß dies alles verständlich und nachvollziehbar ist.

mfg

Roger

[PicNick]

Weiß gott wie elektronisch ist das Thema ja eigentlich nicht.

Bei Tabellen wird in allen Hoch- und Tiefsprachen eigentlich gleich adressiert: Tab-Base + index * element-Length
Vorsicht: bei adressen im Flash muß du den Tabellen-Label * 2 nehmen, weißt du ja
Wenn du Elementlänge 7 hast, mußt du blöderweise wirklich multiplizieren, bei 8 würde shiften ja reichen
Ich würde 'e' * 7 , dann + tab-base, und dann noch + zeile

Das ist dann, wenn du die Pattern genauso wie die Zeichen angelegt hast.
Du wirst aber wohl zumindest 0x020 abziehen, nix druckbar, nix pattern.

wenn du noch platz hast , wäre schneller über vector-tabelle dazwischen

vec_tab:
db vector_a
db vector_b
....
db vector_z

vector_a: db 0, 0, 0 ,0 , 0 , 0 , 0 ; 7 byte pattern "A"
vector_b: db 0, 0, 0 ,0 , 0 , 0 , 0 ; 7 byte pattern "B"
.......
vector_z: db 0, 0, 0 ,0 , 0 , 0 , 0 ; 7 byte pattern "Z"


finden : vec_tab + Zeichen ------> address zeichen -pattern


Ist da wo eine Idee dabei, die hilft ?

[gulliver]

Hallo Robert

Nun, ja, wie elektronisch...
Einerseits ist es eine Elektronikgeschichte, andererseits auch Programmierung. In welche Sparte paßt dieses Thema am besten, ich habe mich nun mal für Elektronik entschieden. Programmierung wäre vielleicht doch geeigneter.

Das ist für mich ein sehr guter Denkansatz, ich danke dir. Hätte auch selber drauf kommen können, daß der Zeichensatz auch als fortlaufende Nummerierung interpretiert werden kann. Wenn man dann noch den Zählwert des ersten Zeichens abzieht, hat man wieder eine Basis zum Indizieren. Das mit der Elementlänge habe ich zwar nicht richtig verstanden, wie du das meinst, aber wenn du damit die Zeilen meinst, habe ich kein Problem damit. Die Anzahl der Einträge in den jeweiligen Labeln ist ja für jedes Zeichen gleich (mit dem 0-Byte sind es 8 Byte) und damit auch die Adressenabstände.

Für die Zeilen verwende ich einen Zähler von 0...6, dessen Zählerstand als Index bei der Adressierung benutzt wird. Das erste Byte würde bei Zählbeginn mit 0, das zweite Byte mit Zählerstand 1 usw. indiziert werden. Es wird ja immer eins zur Adresse hinzugezählt. Dein Gedanke, den eigentlichen Vektor über eine Vektortabelle anzuspringen und dann den Zeilenindex hinzuaddieren finde ich brillant. Da können im Zeichensatz auch Lücken elegant übersprungen werden. Diese Art der Adressierung kenne ich übrigens aus meiner Atarizeit. Habe immer noch einen auf 320 kB aufgemotzten 800XL, der sich übrigens sehr gut mit seinen 77 Assemblerbefehlen programmieren läßt, nur die Hardware drumrum macht einem das Leben ganz schön schwer. Da wird diese Adressierung sehr häufig angewendet, aber mein Kumpel Alz Heimer redet mir leider immer häufiger vieles aus , so daß mich nicht mal ein Schimmer von einem Geistesblitz erhellte. Käse, wenn man älter wird.

Werde mich morgen mal drüber hermachen. Wenn das klappt, wird die nächste Stufe angepackt. Da ich die Anzeige aus Kostengründen nur mit 8 LED-Matrixen bestückt habe, werde ich versuchen, einen längeren Text durchscrollen zu lassen. Mal sehen, ob ich da mit dem Timing noch hinkomme. Takte hätte ich in der Interrupt-Routine jedenfalls noch genug übrig.

Danke und tschüß

Roger

[kalledom]

Hallo Roger,
für PIC-Controller empfehle ich eine Internet-Seite mit ASM-Beispielen , auch mit indirekter Adressierung, die ich hierfür vorschlagen würde.

[gulliver]

Hallo Karl-Heinz

Danke dir für den Tip, aber der Link ist heute morgen noch dicht und nicht erreichbar. Egal, kein Problem. Wenn ich mich noch mit dem deutlich anderem Befehlssatz herumschlagen müßte, würde ich C vorziehen.

Ich hatte mich vor 15 Jahren mit Assembler auf dem 8-Bit-Atari beschäftigt. Dessen Befehlssatz ist mir noch sehr vertraut. Da lauten diese LDA, DEC, BCC, STA AND, INX, JMP usw. Ist zwar alles auf Akku fixiert, aber es läßt sich hervorragend auf Atmel umsetzen. Außerdem habe ich noch Assemblerlektüre, wie z.B. "Das Assemblerbuch" von Peter Finzel, darin ist die Programmierung sehr gut beschrieben. In Zukunft werde ich dieses zu meiner Standardlektüre machen .

mfg

Roger

Edit: Ich muß mich korrigieren, der Link ist ok. Habe nur die Erweiterung nach dem '/' wegnehmen müssen.

[PicNick]

Wenn du vom Assembler kommst, aber nicht emotional damit verbunden bist, kann ich dir nur den C von GCC als schreibhilfe empfehlen. der nimmt dir den Kleinkram ab, haut dir aber trotzdem noch ausreichend die einzelnen Bits um die Ohren, damit du nicht auf Entzug kommst.

[kalledom]

Sorry, war mein Fehler; ich hatte für die ASM-Beispiele die Erweiterung .HTM vergessen.

[gulliver]

Hallo Robert

Mein Problem ist nicht die Sprache C an sich, sondern das ganze Procedere drumrum mit den Parametern beim Compiler/Precompiler, und auch mit der manchmal cryptischen Schreibweise mit doppelteten Unterstrichen usw. in den *.h-Dateien. Da gibt es viele Sachen, die ich nicht nachvollziehen kann. Das macht mich dann unsicher.

Ich habe nach der Wende mit Turbopascal angefangen und auch Assembler auf dem Atari noch nebenbei (hatte ich schon vor der neuen Zeitrechnung ). In Pascal gibt man den Befehl zum Compilieren und das war's, bei C muß ich erst einige Vorkehrungen treffen, wie Compilereinstellungen, Komandozeilenoptionen usw., sonst geht das in die Hose.

Mit C++ bin ich erst in einer Weiterbildung in Berührung gekommen. Vieles kann ich ja nicht übernehmen. Einige Routinen kennt die Atmel-Version nicht und außerdem gibt es da in den Bibliotheken noch so einige Unterschiede, so daß ich mit Fehlermeldungen nur so zugesch...en wurde. Dazu noch die Case-Sensitivität, da sind Fehler schon vorprogrammiert. Da verliere ich dann immer wieder die Lust und bin beim Assembler geblieben.

An sich ist Assembler ja eine klare Sprache, nur man muß genau wissen, was man tut. Viele Probleme lassen sich in einer Hochsprache relativ einfach ausdrücken. In Assembler knabbert man daran tagelang und sieht evt. den Wald vor lauter Bäumen nicht, wie in meinem Fall mit dem Zeichensatz.

Ich denke, ich muß mir nur ein komplettes C-Paket installieren und nur mit dessen Bibliotheken arbeiten, und keine Fremdbibliotheken installieren und mich dann langsam vorarbeiten. Vor allem muß ich mich öfter mit der Programmierung beschäftigen, und nicht alle 3 Wochen mal. Da festigt sich kein Wissen. Man müßte nur etwas mehr Zeit haben .
Irgendwann packe ich das auch noch. Irgendwo hatte ich mal eine Seite gesehen, wo jemand mit einem Universal-Script für den Compiler arbeitet und nur den Prozessortyp ändert. Da ich vergessen hatte, den Link zu speichern, habe ich diese Seite bis heute nicht wiedergefunden.

mfg Roger

[kalledom]

Da stimme ich Gulliver zu, ich mag aus den genannten Gründen auch kein C und habe mein Leben lang nur in Assembler programmiert. Wenn ich z.B. im PIC-Forum in den Beiträgen sehe, was für Probleme unter den C-Versionen und -Varianten auftauchen, bin ich froh, bei Assembler geblieben zu sein. Außerdem kenne ich kaum ein C-Listing, in dem nicht einige Assembler-Befehle mit drin sind. Die (frühere) Begründung für C, auf jeden Rechner übertragbar zu sein, ist ja wohl schon lange vom Tisch.

[PicNick]

C und drumherum: Nun, beim WinAVR (GCC-C) ist das ganze schon recht zusammengepackt und man ist mit dem makefile-brimborium in der Grundausstattung kaum konfrontiert. Aber klar, Übung (und Gewöhnung) braucht man für alles. C programmierer neigen ja leider zu IT-Schamanismus und unleserlichen Beschwörungsformeln, das stimmt schon.
Grad bei Microkontroller gibt es wenig zwingende Gründe, sich das anzutun. Weil, wie Kalle ja bemerkt hat, viele C-Sourcen oft ohne Not nichteinmal artenrein sind.
Die Portierbarkeit von C leidet natürlich unter solchen Konzeptlosigkeiten, ist auch richtig.