Assemblerprobleme PIC16F84 vs. LCD (HD44780)

[Christof Rueß]

Hallo NG!

Ich versuche mich ab und zu mit Assembler (MPLAB) für meinen PIC16F84 und
möchte eine "Bigfont" für meine Funkuhr machen. Das ganze soll auf einem
4zeiligem LCD (Charset) ablaufen.

Bis jetzt hat mir Uwe Nagel (schreibt ab und zu auch hier drin) seehr viel
geholfen. Ich möchte ihn aber nicht weiter beanspruchen, da er sicher
besseres zu tun hat...

Aber nun zu meinem Problem:
Ich habe in den CG-RAM des Displays 8 Symbole drin, die zusammengesetzt
Zahlen ergeben.
Den "Charset" habe ich in Tabellen abgelegt, die in etwa so aussehen:

chrlnaa: addwf PCL,f
dt
0x00,0x00,0x00,0x00,0x04,0x04,0x00,0x04,0x00,0x00,'x','x','x','x','x','x'

Davon sind 12 Stück in der ASM-Datei. (Jedes Symbol hat 3x4 Zeichen - siehe:
http://mitglied.lycos.de/elektronikalshobby/EloPC/LCD/my_lcd.jpg [Programm
läuft vom PC aus])

nur leider erscheinen die Zahlen sehr "verkrüppelt" auf dem LCD. (Falls
nötig kann ich auch ein Bild in meinen Webspace laden.)

Kann mir jemand von euch sagen, was ich falsch mache?

Ich möchte die ASM-Datei hier drin nicht posten, da sie >10KB groß ist.

Ich hoffe, es finden sich ein "Profi", der sich mein Problem ansehen kann.

MfG

Chris

--
http://www.hobby-elektronik.de.vu
ICQ: 176979879

 

[Dieter Wiedmann]

"Christof Rueß" schrieb:

chrlnaa: addwf PCL,f
dt
0x00,0x00,0x00,0x00,0x04,0x04,0x00,0x04,0x00,0x00,'x','x','x','x','x','x'

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


Gruß Dieter

 

[Christof Rueß]

Hallo Dieter!

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

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

MfG

Chris

 

[Th. Rehm]

Christof Rueß wrote:

Lasse ich den PIC dadurch abstürzen, oder?

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:
http://www.microchip.com/download/appnote/pic16/00556e.pdf

Thomas.

 

[Christof Rueß]

Hallo Thomas!

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:
http://www.microchip.com/download/appnote/pic16/00556e.pdf

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

 

[Michael Dunin v. Przychow]

Th. Rehm wrote:

Christof Rueß wrote:
Lasse ich den PIC dadurch abstürzen, oder?

Nein, ich vermute hier ein Misverständnis.

Der PIC kann keine Daten direkt aus dem Befehlsspeicher holen,

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

Michael

 

[Th. Rehm]

Christof Rueß wrote:

Mit dem "kleinen" Charset (2 Tabellen) hat es prima geklappt.

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:
http://www.microchip.com/download/appnote/pic16/00556e.pdf

Und wie man Tabellen größer als 255 Byte adressieren kann, steht hier:
http://massmind.org/techref/microchip/bigtable.htm

Thomas.

 

[Christof Rueß]

Hallo Thomas!

Dann kann Dein Problem mit "abstürzenden Tabellen" nur noch daran
liegen, dass ein Seitenüberlauf stattfindet und der Befehlszeiger
dann sonst wo landet.

Klingt einleuchtend

Was bei Tabellen bis 255 Byte zu beachten ist, steht in der schon
erwähnten AppNote 556:
http://www.microchip.com/download/appnote/pic16/00556e.pdf

Und wie man Tabellen größer als 255 Byte adressieren kann, steht hier:
http://massmind.org/techref/microchip/bigtable.htm

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.
http://www.hobby-elektronik.de.vu/dse/big.asm
(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

 

[Christof Rueß]

Hallo Dirk!

Genau für solchen Mist gibt's ja C-Compiler.

Wollte ich nur mal für die Asm-Fraktion loswerden ;-))

Wenn es darum geht, was besser ist, dann schreien mind. 10 Leute, das
Asm so viel besser und schneller ist, alle anderen sind einfach nur zu
blöd.
Wenn's dann um konkrete Hilfe geht, ist dann nur noch einer zur
Stelle.

Meine Empfehlung:
Schmeis den Mist in die Tonne, wenn Du Dir nicht zu stolz dafür bist
zuzugeben, dass ein Compiler an der Stelle einfach ökonomischer ist.

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

 

[jetmarc]

Mit dem "kleinen" Charset (2 Tabellen) hat es prima geklappt.

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

Marc

 

[Dirk Ruth]

On Sat, 2 Aug 2003 21:25:55 +0200, "Christof Rueß"
<chrissprivat@gmx.de> wrote:

Hallo Dirk!

Genau für solchen Mist gibt's ja C-Compiler.

Wollte ich nur mal für die Asm-Fraktion loswerden ;-))

Wenn es darum geht, was besser ist, dann schreien mind. 10 Leute, das
Asm so viel besser und schneller ist, alle anderen sind einfach nur zu
blöd.
Wenn's dann um konkrete Hilfe geht, ist dann nur noch einer zur
Stelle.

Meine Empfehlung:
Schmeis den Mist in die Tonne, wenn Du Dir nicht zu stolz dafür bist
zuzugeben, dass ein Compiler an der Stelle einfach ökonomischer ist.

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!

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.

 

[Heiko Nocon]

Dirk Ruth wrote:

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.

 

[Andreas Tönne]

"Heiko Nocon" <Heiko.Nocon@gmx.net> schrieb im Newsbeitrag
news:hunoiv0n3gtas273qck0u7b73jve73rv8e@4ax.com...

Dirk Ruth wrote:

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...

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

 

[Dirk Ruth]

On Sun, 03 Aug 2003 03:13:21 +0200, Heiko Nocon <Heiko.Nocon@gmx.net>
wrote:

Dirk Ruth wrote:

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.

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

 

[Michael Dunin v. Przychow]

Christof Rueß wrote:

Hallo Thomas!
Dann kann Dein Problem mit "abstürzenden Tabellen" nur noch daran
liegen, dass ein Seitenüberlauf stattfindet und der Befehlszeiger
dann sonst wo landet.

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

http://www.hobby-elektronik.de.vu/dse/big.asm

Du schreibst da so nett drüber:
| ; Darauf achten, dass diese Tabelle vollständig in Seite 0 steht, also unter 0x100

was nach grobem Durchzählen aber nicht der Fall ist. Irgendwo in der
Gegend von chrlncb: müßte der Wechsel von 0x0ff zu 0x100 stattfinden.

Übrigens ist "Seite 0" schon etwas größer (2k-Words) und die Tabellen
müssen nicht unter 0x100 sein, sondern die Grenze darf innerhalb einer
Tabelle nicht übersprungen werden (oder Du mußt den kompletten
Programmcounter PCHCL 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

 

[Olaf Kaluza]

Dirk Ruth <d.ruth@expressnet.info> wrote:

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?

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.)

 

[Christof Rueß]

Hallo Michael!

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

http://www.hobby-elektronik.de.vu/dse/big.asm

Du schreibst da so nett drüber:
| ; Darauf achten, dass diese Tabelle vollständig in Seite 0 steht, also
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.

was nach grobem Durchzählen aber nicht der Fall ist. Irgendwo in der
Gegend von chrlncb: müßte der Wechsel von 0x0ff zu 0x100 stattfinden.

Übrigens ist "Seite 0" schon etwas größer (2k-Words) und die Tabellen
müssen nicht unter 0x100 sein, sondern die Grenze darf innerhalb einer
Tabelle nicht übersprungen werden (oder Du mußt den kompletten
Programmcounter PCHCL manipulieren, nicht nur das Lowbyte PCL).

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

..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

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

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

MfG

Chris

 

[Michael Dunin v. Przychow]

Christof Rueß wrote:

Hallo Michael!
Schreib doch einfach:
| .org 0x100
| chrlnca:

Ohne dem Punkt klappte das Kompilieren

*Ups* der Punkt war ein AVR-Gruß ;-)

und kontrollier im lst-File nochmal die Adressen, dann sollte es
funktionieren.
Wie meinst du das genau?

Im Listing stehen die Adressen, da kann man schnell kontrollieren ob ein
Überlauf 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
3402 3420 3402
3402 3478 3478
3478 3478 3478
3478
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ür Werte
von 0 bis 7 in W klappt das auch, bei W=8 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).

Verlagerst Du nun die ganze Tabelle nach 0x100, bleibt das Highbyte der
Tabelle gleich und alle Sprünge werden korrekt ausgeführt.

hth, Michael

 

[Michael Dunin v. Przychow]

Christof Rueß wrote:

Was findest du dann besser: PIC oder AVR?

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

Also ab CHRLNDA liegt alles ab adresse 0x100.

Was weiß ich, was in Deiner pic16cxy.inc noch an Code drin steht.

Ich werde etwas mit dem org-Befehl herumprobieren müssen...

Analysieren statt probieren wäre imo praktischer.

Michael

 

[Heiko Nocon]

Dirk Ruth wrote:

Bei einer Routine zur Ansteuerung
eines Displays brauch ich aber bestimmt kein Assembler. Muss da eh nur
ständig auf's Busy warten.

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.