Assemblerprobleme PIC16F84 vs. LCD (HD44780)

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.

Das hat er bereits vor sehr langer Zeit getan.

Reply to
Heiko Nocon
Loading thread data ...

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

Darf ich zitieren:

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

Reply to
Dirk Ruth

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.