Assemblerprobleme PIC16F84 vs. LCD (HD44780)

"Christof Rueß" schrieb:

Und was soll da deiner Meinung nach ablaufen? Du schickst den PIC ja ins Nirwana.

Gruß Dieter

Hallo Dieter!

Wie meinst du das? Lasse ich den PIC dadurch abstürzen, oder?

MfG

Chris

Der PIC kann keine Daten direkt aus dem Befehlsspeicher holen, nur über einen Umweg. Microchip hat für den PIC eine Application Note erstellt (AN556), in der das detailliert beschrieben wird:

Thomas.

Hallo Thomas!

Eigenartig.

Mit dem "kleinen" Charset (2 Tabellen) hat es prima geklappt. Leider war mir die Anzeige zu klein. Ich habe aber auch ein paar Beispiele aus dem Internet, in denen solche Tabellen vorkommen.

Zur allgemeinen Belustigung kann ich ja den Code mal in meinen Webspace hochladen.

MfG

Chris

Nein, ich vermute hier ein Misverst=E4ndnis.=20 =20

Macht er ja auch nicht. DT erzeugt einen Table, d.h. eine Folge von RETLW-Befehlen und die kann der 16F84 lat=FCrlich verarbeiten.=20

Michael

Michael hat das Missverständnis bereits geklärt: der Pseudo-Op "dt" legt Daten offensichtlich als "retlw xx" an.

Dann kann Dein Problem mit "abstürzenden Tabellen" nur noch daran liegen, dass ein Seitenüberlauf stattfindet und der Befehlszeiger dann sonst wo landet. Was bei Tabellen bis 255 Byte zu beachten ist, steht in der schon erwähnten AppNote 556:

Und wie man Tabellen größer als 255 Byte adressieren kann, steht hier:

Thomas.

Hallo Thomas!

Klingt einleuchtend

Leider kann ich damit recht wenig anfangen. Ich glaub ich bin zu bekloppt für ASM. Wenn ich den Befehlszeiger auf 0 oder irgendetwas anderes setze wir wohl nicht helfen.

Zum Ansehen und vermutlich Totlachen über meine programmierkünste habe ich die ASM-Datei hochgeladen.

(Die funktionierenden Programmteile stammen von Uwe Nagel)

Da die Anzeige noch in den DCF-Code wandert, denke ich, dass es in dieser ASM-Datei und der DCF-Datei unterschiedlich ist, wie der Charset "interpretiert" wird. Kann das sein?

Mfg

Chris

Hallo Dirk!

Wenn man C kann, eine tolle Sache. Aber was ist mit denen, die kein C können - wie mich? soll ich jetzt noch zusätzlich C lernen?

Nein danke!

MfG

Chris

Solche Tabellen duerfen keine 256-Wort Grenzen uebertreten! Moeglicherweise funktioniert es schon, wenn Du die Tabelle in die Naehe des Programmanfangs legst.

Marc

Doch das solltest Du. Ist IMHO inzwischen eine Universalsprache, um die Du nicht mehr herum kommst. Assembler kannst Du natürlich auch in C einbetten, wenns mal schneller gehen soll, aber gerade um so einen Murks wie "RETLW XX" (mir wird einfach schlecht bei sowas) oder Bankswitching zu vermeiden, ist eine Sprache mit einem höheren Abstraktionslevel sinnvoll.

Aber ich sehe schon, dass Du zu stolz dafür bist. Bitte dann fummel Dich ebend durch. Der Gewinn ist aber gleich null.

Übrigens sind die PICs und auch die kleinen Atmel-Dinger der größe Murks in Assembler, den ich bisher gesehen habe (selbst 8031 ist da noch besser). Schade dass Reichelt die kleineren Controller von Fujitsu oder Mitsubishi nicht führt. Die PICs und Atmel waren wohl etwas eher da.

Tschö Dirk

PS: Mit C löst man ein Problem mit dem eigenen Gehirn, in Assembler erforscht man die Gedankengänge und Kuriositäten des Controller-Herstellers.

...sagen C-only-Programmierer. Und dann muß es ja stimmen. Und wenn den Typen dann jemand zeigt, das mit einem Drittel der Hardwareanforderungen dasselbe möglich ist, was sie gerade verbrochen haben, dann gibt es ja immer noch das Große Portabilitätsmärchen, das man dem Chef erzählen kann...

Ist das nicht auf Dauer ein wenig peinlich? Also ich würde mir da irgendwie komisch vorkommen.

Alles hat doch seine Vor- und Nachteile:

- Assembler kommt klarerweise mit weniger Hardware aus -> geringere Serienkosten

- C ist deutlich einfacher zu programmieren -> geringere Entwicklungskosten, weniger Fehler, besser zu ändern

Wenn man eine 500 Worte Einfach-Anwendung für eine 10.000er Serie benötigt, würde ich auch Assembler nehmen. Wenn es darum geht, einen Mega128 zu füllen und man vielleicht nur 1000 Stück absetzt, ist wohl C geeigneter.

Ihr leidet unter dem Goldener-Hammer-Syndrom. Nicht gefährlich, aber ansteckend.

Andreas

--

===================================================
Andreas Tönne @ home
mailto:atoenne@t-online.de * http://www.atoenne.de
phone x49 231 52 97 00 * mobile 0179 5457 222
===================================================
Dipl.Inform. Andreas Tönne * Prokurist
Georg Heeg eK  * Informatikleitung
mailto:atoenne@heeg.de * http://www.heeg.de
phone  x49 231 9 75 99 0/36 * fax x49 231 9 75 99 20

Nee ist nicht peinlich. Peinlich ist, wenn Dein Chef seinem Kunden erzählt hat, dass schaffen wir in 3 Wochen und er ihm nach 3 Wochen sagen muß, dass Du noch 2 Wochen zusätzlich brauchst, aber dann dafür alles in Assembler programmiert ist.

Übrigens kann ich auch Assembler programmieren und das schon seit über 10 Jahren, verwende das aber nur an unbedingt nötigen Stellen und schreibe das dann in den C-Code. Bei einer Routine zur Ansteuerung eines Displays brauch ich aber bestimmt kein Assembler. Muss da eh nur ständig auf's Busy warten.

Merke:

1. C ist ein Standard (ANSI)
2. Assembler ist kein Standard.
3. Verwende Standards, wo immer Du nur kannst.

Schon mal drüber nachgedacht, warum Du mit dem passenden Schlüssel jede Schraube aufbekommst ohne das Du Dir Gedanken darüber nachen mußt, welche Steigung, Ausengewinde, Nenngewinde, Kerndurchmesser, Flankendurchmesser, Tragtiefe und Flankenüberdeckung diese Schraube hat?

Tschö Dirk

Wow, Thomas hat ne verdammt gute Kristallkugel, ich konnte mit "geschreddeter Zeichnsatz" nicht viel anfangen. =20

Du schreibst da so nett dr=FCber: | ; Darauf achten, dass diese Tabelle vollst=E4ndig in Seite 0 steht, = also unter 0x100

was nach grobem Durchz=E4hlen aber nicht der Fall ist. Irgendwo in der Gegend von chrlncb: m=FC=DFte der Wechsel von 0x0ff zu 0x100 stattfinden.

=DCbrigens ist "Seite 0" schon etwas gr=F6=DFer (2k-Words) und die = Tabellen m=FCssen nicht unter 0x100 sein, sondern die Grenze darf innerhalb einer Tabelle nicht =FCbersprungen werden (oder Du mu=DFt den kompletten Programmcounter PCH:PCL manipulieren, nicht nur das Lowbyte PCL).

Schreib doch einfach: | .org 0x100 | chrlnca:

und kontrollier im lst-File nochmal die Adressen, dann sollte es funktionieren.

Michael

Hast du schonmal darueber nachgedacht warum du dir als Konstruktoer ei der Auswahl einer Schraube fuer ein neues Produkt dir auch genau darueber gedanken machen musst?

Siehst du? Deswegen denken andere darueber nach ob fuer ein bestimmtes Projekt C oder Assembler besser ist.

Olaf

--
D.i.e.s.S. (K.)

Hallo Michael!

unter 0x100

Ich habe in dem Posting, in dem ich den Link geschrieben habe, auch erwähnt, dass die funktionierenden Programmteile von Uwe Nagel stammen. Ich habe mir über diesen Kommentar nicht großartig nachgedacht, da es vorher ja geklappt hat.

.Org 0x100 schluckte er nicht. Da brachte er beim Kompilieren eine Fehlermeldung: Error[108] BIG.ASM 164 : Illegal character (0) Ohne dem Punkt klappte das Kompilieren ;)

Wie meinst du das genau? Wie gesagt bin ich ein vollkommener Trottel im Gebiet ASM...

MfG

Chris

*Ups* der Punkt war ein AVR-Gru=DF ;-) =20

Im Listing stehen die Adressen, da kann man schnell kontrollieren ob ein =DCberlauf stattfindet. Hier der wichtige Teil:

Adresse, Befehl Zeile Mnemonic

00F7 0782 00173 chrlnda: addwf PCL,f 00F8 3402 3405 3405 00174 dt 0x02,0x05,0x05,0x02,0x20,0x02,0x02,0x20,0x02,0x02,'x','x','x','x','x','x' 3402 3420 3402=20 3402 3420 3402=20 3402 3478 3478=20 3478 3478 3478=20 3478=20 0108 0782 00175 chrlndb: addwf PCL,f

und genau in dieser Tabelle ist der Fehler. Die Tabelle liegt im Adressbereich 0x00F8 bis 0x0107, addwf PCL verursacht einen Sprung auf

0xF8+W, allerdings halt nur im Lowbyte des Programmcounters. F=FCr Werte von 0 bis 7 in W klappt das auch, bei W=3D8 springt der PIC nach 0x00, da ja PCH nicht auf 0x01 gesetzt wird. D.h. er springt nach 0000 2980 00052 goto main

startet also das Programm neu, wobei vom "call chrlnda" noch die aufrufende Adresse auf dem Stack liegt (nix gut).=20

Verlagerst Du nun die ganze Tabelle nach 0x100, bleibt das Highbyte der Tabelle gleich und alle Spr=FCnge werden korrekt ausgef=FChrt.

hth, Michael

8051=20 Hast Du so viel Popcornaktien? Nach C-vs-ASM noch PIC-vs-AVR aufzumachen, tststs

Was wei=DF ich, was in Deiner pic16cxy.inc noch an Code drin steht.=20

Analysieren statt probieren w=E4re imo praktischer.=20

Michael

Das ist so ein typischer Fall, wie C-geschädigte Entwickler handeln. Sie sehen nicht das System insgesamt.

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.

Genau aus solchen Sachen resultieren die größeren Einsparungen bei Assemblerprogrammierung und nicht aus den paar Takten und Bytes, die man spart, weil das menschliche Gehirn immer noch ein Stück cleverer ist als der beste optimierende C-Compiler. (Obwohl auch ein paar Takte oder Bytes manchmal schon entscheidend sein können, um den µC eine Nummer kleiner wählen zu können)

Den entscheidenden Vorteil bringt also nicht die Sprache an sich, sondern die Tatsache, daß ein guter Assemblerprogrammierer i.d.R. sehr viel mehr über die Hardware weiß und deswegen eher Möglichkeiten zur Optimierung findet. Er denkt regelrecht ganz anders als ein C-Programmierer, weil er im Gegensatz zu diesem immer die Hardware im Hinterkopf hat.