LCD W204B-NLW

Schüler Gast #5811540
Lesenswert?
• ▲
▼ 
Hi

Ich baue gerade ein Programm aus dem Forum hier um, damit ich es auch 
mit dem STMBoard nutzen kann.
Ich hätte soweit mal alles geändert und das Programm kompiliert so auch, 
aber das Display initialisiert einfach nicht.
Ich arbeite mit dem 4-bit Modus und wollte das Meiste mit dem Busy-Flag 
erledigen.

Da das Programm aber nicht einmal richtig initialisiert, habe ich 
einfachheitshalber eine "längere" Wartezeit eingefügt als verlangt.

Ich wäre euch dankbar um einen Rat

Schüler
Angehängte Dateien:
Beitrag melden Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Markierten Text zitieren Antwort Antwort mit Zitat
Schüler Gast #5811578
Lesenswert?
• ▲
▼ 
Teo D. schrieb:
> Schüler schrieb:
>> Ich arbeite mit dem 4-bit Modus und wollte das Meiste mit dem Busy-Flag
>> erledigen.
>
> Dann solltest du das OBERE Nibble lesen....

Ich passe es später noch an, aber im Moment habe ich die Funktion 
ausgeblendet und es initialisiert trotzdem nicht.

Harry L. schrieb:
> Ist das selbe Display, nur an eiem PCF8574-Portexpander
>
> In dem Code kannste dir sicher was abschauen:
>
> Beitrag "Re: [STM32/HAL] generischer Treiber für die beliebten
> I²C-Text-Displays"

Werd ich mir ansehen.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Schüler Gast #5812737
Lesenswert?
• ▲
▼ 
Harry L. schrieb:
> Ist das selbe Display, nur an eiem PCF8574-Portexpander
>
> In dem Code kannste dir sicher was abschauen:
>
> Beitrag "Re: [STM32/HAL] generischer Treiber für die beliebten
> I²C-Text-Displays"

Ich habe mir das lcd.c angesehen, jedoch verstehe ich das in dem 
Zusammenhang wie ich es benötige überhaupt nicht.
Beispielsweise wird im Init das Senden send_nibble() verwendet.
In der 3. Zeile im lcd_Init wird 0x30 geschickt.
Der Vorgang ist dabei so:

1
uint8_t cmd[2];

2
  port_state = (port_state & 0x0f)  | nibble;

3
  cmd[0]= port_state | ( 1<< E_PIN);

4
        cmd[1] = port_state

5


6
Im ersten Durchlauf:

7
  port_state & 0x0f ergibt 0x00

8
  ( 1<< E_PIN) ist 0x04

9
        port_state = (port_state & 0x0f)  | nibble; ergibt port_state = nibble;

10
        port_state | ( 1<< E_PIN) ergibt 0x06



Ich verstehe zwar was in jeder Zeile passiert, aber wozu das Ganze soll, 
verstehe ich nicht.
Er sendet also cmd[] = {0x06, 0x02) an irgend ein IC per I2C.

Die Zeiten im Init mit HAL_Delay(MILLISEKUNDEN), entsprechen auch nicht 
gerade den Zeiten im Datenblatt des entsprechenden LCD Controllers.

Ich möchte das Ganze auch nicht in Frage stellen, weil das so 
funktioniert.
Kann mir niemand sagen, was bei mir das Problem ist? Ich arbeite nicht 
mit I2C.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Harry L. #5812765
Lesenswert?
• ▲
▼ 
Wenn ich 3 Bytes via I²C an den Portexpander sende, ändert sich nach 
jedem übertragenen Byte der Zustand der Ausgänge entsprechend dem 
empfangenen Byte.
3 Byte entsprechen also 3 Takten zum Display.
Als Erstes leg ich die Daten auf die oberen 4 bit, und danach setz ich 
zusätlich E und dann nochmal den nibble ohne E.

Der relativ langsame I²C-Takt sorgt immer automatisch dafür, daß die 
Übertragung "langsam genug für das Display" läuft, und ich mich nicht 
weiter darum kümmern muß.

Die delays die du in meinem Code gefunden hast, stecken nur in der 
init-Funktion.
Im weiteren Betrieb gibts keine delays mehr.

Wenn du dein Display direkt an einem parallel-Port hast, kannst du 
einfach den I²C-Transfer weglassen, aber die Bytes, die du in dein Port 
schreibst sind die selben.

Nur für das passende Timing mußt du dann selbst sorgen (delay())
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Schueler Gast #5812802
Lesenswert?
• ▲
▼ 
Harry L. schrieb:
> Wenn ich 3 Bytes via I²C an den Portexpander sende, ändert sich
> nach jedem übertragenen Byte der Zustand der Ausgänge entsprechend dem
> empfangenen Byte.
> Wenn du dein Display direkt an einem parallel-Port hast, kannst du
> einfach den I²C-Transfer weglassen, aber die Bytes, die du in dein Port
> schreibst sind die selben.
>
> Nur für das passende Timing mußt du dann selbst sorgen (delay())

ok ich versuche das Mal
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren