LCD W204B-NLW

[Schüler (Gast)]

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

[Teo D. (teoderix)]

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

[Harry L. (mysth)]

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"

[Schüler (Gast)]

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.

[Schüler (Gast)]

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:

uint8_t cmd[2];
  port_state = (port_state & 0x0f)  | nibble;
  cmd[0]= port_state | ( 1<< E_PIN);
        cmd[1] = port_state

Im ersten Durchlauf:
  port_state & 0x0f ergibt 0x00
  ( 1<< E_PIN) ist 0x04
        port_state = (port_state & 0x0f)  | nibble; ergibt port_state = nibble;
        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.

[Harry L. (mysth)]

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

[Schueler (Gast)]

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