Assemblerprobleme PIC16F84 vs. LCD (HD44780)

[Heiko Nocon]

Dirk Ruth wrote:

So so und wie würde der "assemblerorientierte Entwickler" das
Busysignal einen Interrupt triggern lassen, wenn dazu eine komplette
Leseoperation notwendig ist (44780u)?

Ganz einfach. Man nimmt einen Timerinterrupt zu Hilfe.

Schreibt man was zum Display, schaut die Schreibroutine, ob der Timer
schon läuft. Wenn nein, wird direkt zum Display geschrieben und der
Timer mit dem zu erwartenden Delay gestartet. Wie groß das für die
jeweilige Operation ist, kann man dem Datenblatt entnehmen. (Siehe S.
24)
Wenn ja, wird das Datum nicht geschrieben, sondern statt dessen einfach
in einem FIFO-Puffer abgelegt.

In der Interruptoutine wird nun geguckt, ob noch was im FIFO steht. Wenn
ja, dann wird (nur zur Sicherheit) einmal das Busyflag gelesen, das
nächste Datum aus dem FIFO geschrieben und der Timer mit dem neuen Delay
erneut gestartet. Das gute alte buffered IO Prinzip, nur leicht
abgewandelt, eben entsprechend den Eigenschaften der konkreten Hardware.

Normalerweise wird man nicht einen Extra-Timer dafür verheizen, da meist
sowieso schon einer für irgendwelche Zwecke läuft. In dessen
Interruptroutine wird der zusätzliche Handler einfach mit eingeklinkt.

Vielleicht sollte der "assemblerorientierte Entwickler" die Doku zum
44780u nochmal eingehender studieren

Das hat er bereits vor sehr langer Zeit getan.

 

[Dirk Ruth]

On Mon, 04 Aug 2003 16:02:30 +0200, Heiko Nocon <Heiko.Nocon@gmx.net>
wrote:

Dirk Ruth wrote:

So so und wie würde der "assemblerorientierte Entwickler" das
Busysignal einen Interrupt triggern lassen, wenn dazu eine komplette
Leseoperation notwendig ist (44780u)?

Ganz einfach. Man nimmt einen Timerinterrupt zu Hilfe.

Natürlich macht man das so.Ist aber auch nichts anderes als ebend
pollen.

Darf ich zitieren:

Der assemblerorientierte Entwickler würde das Busysignal einen Interrupt
triggern lassen und den Code in eine Interruptroutine packen.
Dann kann der ľC nämlich in der Zwischenzeit andere nützliche Aufgaben
erledigen, statt nur sinnlos in einer Warteschleife rumzuturnen.

Wo triggert da das Busy ein Interrupt-Signal???

Ich weiß, das der uralte 44780u leider ein bisschen vermurkst ist und
endlich mal abgelöst werden könnte, aber er ist ebend Standart und
jeder kann damit umgehen.

Mir ist auch klar, dass Du darauf hinauswolltest, dass man mit
Assembler meißt einen engeren Bezug zur Hardware herstellt und das
nicht schlecht ist.

In vielen Fällen ist das aber nicht sinnvoll bzw. unnötig. Wenn Du mit
einem Auto fährst, dann denkst Du auch nicht immer auf atomarer Ebene,
um in den nächsten Supermarkt zu kommen. Man abstraiert ebend und
verwendet ein Modell. Der Compiler stellt so eine Modellumgebung zur
Verfügung und kennt z.B. eine long- oder float-Variable oder ein
mehrdimensionales Array. Der Prozessor kennt die nicht und deshalb
bildet der Compiler diese auf dem Controller ab. Dabei ist es völlig
egal, ob das nun ein PIC oder ein Atmel oder sonstwas ist. Damit
kannst Du den Controller als Modell verwenden, was ja letztendlich
auch die Portierbarkeit verbessert. Gerade die kleinen Controller sind
mit ihrem Bankswitching ein gutes Beispiel dafür, dass der Compiler
überprüfen kann, ob ich einen Fehler gemacht habe.

Irgendwie hat sich mit der Zeit ebend herausgestellt, dass bestimmte
Fehler immer wieder gemacht werden (Stackhandling, Parameterübergabe
usw.). Das sind alles features des Compiler, die er überprüfen kann.
Natürlich kann man sich auf den Standpunkt stellen, wer das nicht
selber macht ist ebend zu doof dazu (Zitat:"C-geschädigte
Entwickler"), ich habe aber auch schon eine Menge gehackten Asm-Mist
gesehen, der 10x solange an Zeit brauchte, um nach einem halben Jahr
zu verstehen, was da gemacht wurde. Schon allein so Dinge wie
Syntax-Highlight und Einrückung mittels Tab sind wärend der Arbeit
eine echte Erleichterung.

Gute Compiler machen guten Code. Assembler-Programmierer machen in
kleinen Stücken sehr guten Code, wärend Compiler bei umfangreichen
Code einfach besser sind. Deshalb ist meine persönliche Meinung, dass
ein C-Programm, im Notfall (und nur dann) garniert mit kleinen
Asm-Stücken das Optimum an Programmierung darstellt. Dabei geht man
i.A. so vor, dass man sich erstmal ansieht, was der Compiler generiert
und dann evtl. bestimmte Teile durch eigenen Asm-Code ersetzt. Es ist
schon empfehlenswert, sich mal anzusehen, was der Compiler da so
generiert. Da kann man sich z.T. auch einiges abschauen.
Compiler-Entwickler sind ebend nicht nur "C-geschädigte Entwickler".

Extrem wird's dann im mathematischen Bereich. Ich bin mir recht
sicher, dass Du mit selbstgeschriebenen Asm von
e^(pi-X)->(Dezimal)->UARTweder schneller in der Codierung noch in der
Laufzeit bist.

Tschö
Dirk