Forum: Compiler & IDEs LCD-Problem nach Änderung der Pinbelegung


von Khan (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Kollegen,

ich habe jetzt angefangen mein LCD-Kode so zu ändern dass ich 5pins von 
PORTB verwende und 2 Pins von PORTD.
Vorher war alles auf PORTB gelegt (siehe lcd_m50530.h,c)

Allerdings funktioniert jetzt mein Kode nicht mehr seit ich es geänder 
habe.

Habe sehr viel ausprobiert und gesucht. Leider vergebens...

Vielleeicht könnt Ihr mir mit eurem guten C-Kenntnissen auf die richtige 
Spur brinnen.


grüße
Khan

von Peter D. (peda)


Lesenswert?


von Khan (Gast)


Lesenswert?

Danke dir!

Dein Kode wollte ich so wieso einbauen, aber vorher wollte ich es mal 
auf primitive Art und weise lösen...

Wenn ich dein Kode jetzt kodiere und es geht wieder schief wird es für 
mich noch schwieriger...

grüße
Khan

von Khan (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

also ich habe den v. Peter Dannegger Kode mal reingehackt.
Aber immer noch nicht weiter gekommen ;-(

Könnt Ihr mir bitte sagen ob die Zeilen 140 bis 144 so ok ist?

grüße
Khan

von Peter D. (peda)


Lesenswert?

Was ich an vielen LCD-Codemonstern nicht verstehe ist, daß da bis zu 6 
verschiedene Baustellen aufgemacht werden müssen:

Es werden extra Routinen für low und high Nibble benutzt.
Es werden extra Routinen für Daten, Kommando benutzt.
Es werden extra Routinen für Initialisierung benutzt.
Es wird unbedingt versucht, von der Initsequenz im Datenblatt 
abzuweichen.


Bei mir gibt es dagegen nur eine einzige Nibble-Routine, die dann alle 
anderen Routinen aufrufen.
Man muß also nur die eine Nibbleausgabe richtig machen, dann 
funktioniert auch der ganze Rest.


Also ich kann meine kleine Routine in Deinem Codemonster nirgends 
wiederfinden.
Wenn etwas nicht geht, dann schreibt man keinen riesen Code.
Laß erstmal alle unnötigen Funktionen weg und gib einfach nur in einer 
Zeile "Hallo Welt" aus.
Laß vor allem den Busy-Test raus. Insbesondere beim Init darf der ja 
garnicht gemacht werden!

Das LCD ist auch mit Delays schnell genug. Im Gegenteil, man muß sogar 
noch zusätzlich Delays machen, damit der Mensch Zeit hat, es überhaupt 
abzulesen.
Der Busytest hat daher nur den merkbaren Effekt, daß ein zusätzlicher 
IO-Pin belegt wird und auch deutlich mehr Code.

Wenn Du mal nen Link zum Datenblatt postest, könnte ich da mal 
reingucken.


Peter


P.S.:
Ich habe noch kein Text-LCD gehabt, das mit diesem Treiber nicht läuft.
Nur bei den EA-DOG muß man noch extra Befehle für Kontrast und Booster 
senden, steht aber alles im Datenblatt.

von Khan (Gast)


Angehängte Dateien:

Lesenswert?

Du hast ja volkommen recht!!

Ich wollte nur den schon funktionierenden Kode um die Pinflexibilität 
erweitern.
Danach den Kode optimieren...

Aber wie du siehst ist es total in die Hose gegangen...

grüße
Khan

von Khan (Gast)


Angehängte Dateien:

Lesenswert?

Sorry vorhin habe ich dir die falschen Kodefiles geschickt.

dies sind die richtigen

von Karl H. (kbuchegg)


Lesenswert?

> Ich wollte nur den schon funktionierenden Kode um die
> Pinflexibilität erweitern.
> Danach den Kode optimieren...
>
> Aber wie du siehst ist es total in die Hose gegangen...

Zurück zu Start, gehe nicht über Los.

Zurück zum funktionierenden Code, sicherstellen das er auch immer noch 
funktioniert und die Änderungen noch einmal machen. Aber diesmal in 
kleineren Schritten ändern und jede einzelne Änderung für sich alleine 
ausprobieren und testen.

von Peter D. (peda)


Lesenswert?

Khan schrieb:
> Sorry vorhin habe ich dir die falschen Kodefiles geschickt.


Hatte ich schon erwähnt, daß ich Codemonster mit 1000 Baustellen nicht 
mag?

Mach Dir eine Nibble-Ausgabe-Funktion und nur diese darf die 4 
Datenleitungen und das Enable anfassen.
Für alle anderen Funktionen sind diese 5 Signale streng verboten, sie 
dürfen nur die Nibblefunktion aufrufen.


Ich sehe auch keinen Grund, Delays selber zu basteln, wenn der Compiler 
Dir bessere Funktionen zur Verfügung stellt.
Der Code wird dadurch nur unleserlicher, da keiner weiß, was Du mit 
"short" meinst.
_delay_us( 1 ); versteht dagegen jeder sofort.


Der Chip ist etwas anders als der HD44780, aber nicht viel. Man muß nur 
fürs Kursor setzen ne zusätzliche Steuerleitung benutzen. Die Änderungen 
sind also minimal.
Ich würde auch die Initialisierung mit dem 2-maligen Setzen in den 
8Bit-Modus übernehmen, damit wird der Code sicherer.


Peter

von Khan (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

also ich habe den Fehlerort lokalisiert.
Allerdings weis ich nicht genau warum, deswegen bitte ich nochmal um 
eure Hilfe.

Die Routine
void LCD_waitReady(void)
ist schuld daran.

Die Routine funktioniert bis Zeile 157
kann aber nicht in
    if (flags & 6)
    {
      // bits 1 oder 2 gesetzt, also entweder sind wie im 8bit-mode oder 
wir haben gerade den zweiten Teil im 4bit-mode gelesen
      break;
    }
hinein springen -> endlosschleife..

d.h. dass ich
      //flags = LCD_PIN; // zeile 147

      flags = PINB & ( 1 << PB0 );
      flags |= PINB & ( 1 << PB1 );
      flags |= PINB & ( 1 << PB2 );
      flags |= PINB & ( 1 << PB3 );
falsch programmiert habe....

könnt Ihr mir bitte hierfür nochmal helfen...

Dafür bin ich echt dankbar..

Grüße
Khan

von Karl H. (kbuchegg)


Lesenswert?

Khan schrieb:

> d.h. dass ich
>       //flags = LCD_PIN; // zeile 147
>
>       flags = PINB & ( 1 << PB0 );
>       flags |= PINB & ( 1 << PB1 );
>       flags |= PINB & ( 1 << PB2 );
>       flags |= PINB & ( 1 << PB3 );
> falsch programmiert habe....
>
> könnt Ihr mir bitte hierfür nochmal helfen...

Die Technik ist grundsätzlich (fast) in Ordnung.

Was war denn die ursprüngliche Belegung von LCD_PIN
Welches Bit am LCD_PIN bedeutete was?

von Peter D. (peda)


Lesenswert?

Khan schrieb:
> flags = PINB & ( 1 << PB0 );
>       flags |= PINB & ( 1 << PB1 );
>       flags |= PINB & ( 1 << PB2 );
>       flags |= PINB & ( 1 << PB3 );

Das ist kein pinvariabler Code, nur unnütze Schreibarbeit.
Ist identisch zu:
1
flags = PINB & 0x0F;

Universell muß man es so machen, daß die Bitposition egal ist:
1
flags = 0;
2
if( LCD_D4_PIN ) flags |= 1<<0;
3
if( LCD_D5_PIN ) flags |= 1<<1;
4
if( LCD_D6_PIN ) flags |= 1<<2;
5
if( LCD_D7_PIN ) flags |= 1<<3;


Peter

von Khan (Gast)


Lesenswert?

@ Karl heinz Buchegger

LCD_PIN ist als PINB definiert.

@Peter Dannegger
hast du den high Nibble absichtlich angegeben?
Denn in der if abfrage unter dem Code wird ja nach
if (flags & 6)
gefragt, also die ersten 3 bits...

grüße
Khan

von Peter D. (peda)


Lesenswert?

Ich nenne die IOs immer nach ihrer Funktion. Und im 4-Bit Mode muß man 
am LCD D7..4 verwenden.

Ich habe nur das Codefragment umgeschrieben auf Pinunabhängigkeit.
Ob es funktioniert, weiß ich nicht, da ich den Busy-Test nicht verwende.
Er bringt ja keinerlei Vorteile.


Peter

von Khan (Gast)


Lesenswert?

Hallo Peter,

wiese bringt das Busy-test keine Vorteile?

Grüße
Khan

von Peter D. (peda)


Lesenswert?

Khan schrieb:
> wiese bringt das Busy-test keine Vorteile?

Weil der Mensch mit Ablesen viel langsamer ist, als das LCD mit festen 
Delays.

Und daher ist es egal, ob das LCD nun 1% oder 0,99% der CPU-Zeit 
verbraucht.
Wenn man einen Mehraufwand treibt, sollte es sich auch lohnen. Ansonsten 
ist es rausgeschmissene Programmierzeit und Codeverbrauch.

Im AVRFreaks hat kürzlich jemand LCD-Code mit 1ms Enablepuls 
veröffentlicht.
Er hat also garnicht gemerkt, daß der Code mindestens 50-mal langsamer 
ist, als nötig.


Peter

von Khan (Gast)


Lesenswert?

Hmm,

interessant!
Da das wass du sagst logisch klingt werde ich diesen Teil raus 
schmeissen.
Wenn ich mal fertig bin mit dem Projekt werde ich es hier 
veröffentlichen.
Leider habe ich sehr wenig Zeit um dieses Hobby so richtig ins Reine zu 
bringen. Aber irgendwann ist es soweit;-)

Dank dir für alles..
Grüße
Khan

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.