LCD-Display 20X4 ohne I2C-Schnittstelle

[nutzi]

Warum nimmst du da nicht die Pins 20 und 21 für I2C, da brauchst du doch keine analogen Pins bzw. mit SoftwareI2C arbeiten.

Weiter oben habe ich bereits gesagt, dass ich diese ebenfalls schon verwende.

Ok.....dieser Satz war jetzt für mich entscheidend.
Der sagt aus, du willst es nicht lernen, willst aber von uns eine Lösung.

Ja, weil ich es nicht verstehe. Meine Güte, ich wette die meisten von euch fahren auch Auto und können das, obwohl sie keine Ahnung haben, wie ein Auto funktioniert. Was ist daran schlimm?

[HotSystems]

Weiter oben habe ich bereits gesagt, dass ich diese ebenfalls schon verwende.

Wenn du alles nicht kannst, dann musst du es eben anders machen.
Nur wozu verwendest du diese I2C-Pins ?

Du hast uns noch nie geschrieben, was du damit machst.
Wenn du alles geheim hällst, ist eine Hilfe kaum möglich.

Ja, weil ich es nicht verstehe.

Und das kann man lernen.
Man muss nur wollen.

Meine Güte, ich wette die meisten von euch fahren auch Auto und können das, obwohl sie keine Ahnung haben, wie ein Auto funktioniert. Was ist daran schlimm?

Aber wenn du ein Auto fährst, musst du es bedienen können. Und das muss man auch lernen.
So ist es eben auch in der Programmierung.

Und du baust dein Auto ja auch nicht selbst.
Möchtest aber etwas mit dem DUE bauen.
Das sind halt die feinen Unterschiede.

Aber ok, ich bin jetzt tatsächlich raus.

Danke für die Unterhaltung.

[combie]

Leider ist dieser Thread sehr "schief" gelaufen....
Falls dir nicht klar ist, wo es klemmt.
Hier mal eine kurze Aufstellung.

Problem 1:
Es wird anfangs nicht gesagt, dass es sich um einen DUE dreht.
Also gehen alle von einem UNO o-ä. aus.
Quelle

Problem 2:
Es werden Nebelkerzen gezündet, welche ich mal als A4 und A5 bezeichne.
Quelle
Das ist für Unos, Nanos, usw wahr.
Für den DUE jedoch völlig falsch.


Problem 3 + 4:
Dann findet sich eine Unwahrheit, und eine Mangelinformation
Quelle
> Habe einen Due und schon alles belegt.
Nach geschlagenen 16 Postings kommt eine Kerninformation DUE
Aus meiner Sicht Unfassbar!

Die Unwahrheit: "und schon alles belegt"
Nachweis:
Wenn alles belegt wäre, dann wäre auch kein Platz für den parallelen Anschluss des LCD

Die Mangelinformation:
Womit belegt?


Problem 5:
Nach mittlerweile 46 Postings ist noch nicht klar, womit "und schon alles belegt" denn jetzt belegt ist. Vielleicht kann man ja noch was frei schaufeln. Umorganisieren.
OK... Alternativen scheinen nicht gewünscht zu sein.. ok

Und wieso man 2 unabhängige I2C Ports mit irgendwas belegt, wenn man (evtl) noch ein I2C LCD verwenden will.
Die Logik dahinter kann ich nicht erschließen.
Denn das sind ja Bus Ports.
An jeden Bus kann man locker ein Dutzend LCDs oder andere Dinge anschließen. Mit Multiplexer auch Hunderte.


----------------

Aus meiner Sicht, hast du Sorgen, viel Nichtwissen, und eine innere Abwehrhaltung, mit der du dich selber blockierst und die Helfer, einen nach dem anderen, frustrierst.
Selber, bist du dann auch frustriert, wenn sich alle abwenden.

Aus Erfahrung kann ich dir sagen, dass alle Threads die mit Geheimhaltung einher gehen, oder auf Salamitaktik beruhen unglücklich enden, oder im Sande verlaufen.

Der Grund ist ganz einfach:
Um helfen zu können benötigt man Information.
Diese Information muss WAHR sein.  (siehe A4 A5)
Sie muss ausreichend sein um das Problem zu lösen. (Was ist an den Wire und Wire1 Pins angeschlossen?)

Kommt diese nicht freiwillig, dann ist das Buch fix zu und der Frust auf beiden Seiten groß.

[my_xy_projekt]

Meine Güte, ich wette die meisten von euch fahren auch Auto und können das, obwohl sie keine Ahnung haben, wie ein Auto funktioniert. Was ist daran schlimm?

Richtig. Ich fahre Auto und betätige die Bedienelemente. Und erwarte, das es das macht was mir erklärt wurde, wenn ich das jeweilige Element benutze.

Ich entwickle keines!

Geb Deinen DUE an jemanden, der Dir das zusammenbaut, was Du willst und bediene den dann so, wie Du es möchtest.

Und noch eines als Ergänzung zu combie:
Spätestens seit #30 wo eindeutig auf den UNO Bezug genommen wurde, hättest Du aufwachen müssen.

[HotSystems]

Spätestens seit #30 wo eindeutig auf den UNO Bezug genommen wurde, hättest Du aufwachen müssen.

So sehe ich das auch, aber da der TO nicht lernen will, erwartet er von uns, ihn darauf hinzuweisen.
Das Aufwachen kommt dann später.

[agmue]

Ausgehend von der falschen Annahme, es handle sich um eine UNO, habe ich mich nun schon seit geraumer Zeit mit diesem Thema beschäftigt. Die sich daraus ergebenden Erkenntnisse:

• Nachdem ich mehrere Kombinationen aus SoftI2C und LiquidCrystal Bibliotheken probiert habe, muß ich leider feststellen, daß ich keine funktionierende gefunden habe. Leider finde ich kein Beispiel zu NewLiquidCrystal\SoftI2CMaster.h und der Verwendung. Bin ich zu dusselig oder ist es etwa doch nicht so einfach, wie manche Beiträge in diesem Thema glauben machen wollen?
• Einzige bislang funktionierende Lösung ist die spezielle LiquidCrystal_SoftI2C, Beispiel anbei, getestet mit meinem UNO.

Code: [Select]

#include <LiquidCrystal_SoftI2C.h>

// Setzt SDA an Pin 8 und SCL an Pin 9
SoftwareWire *wire = new SoftwareWire(8, 9);

// Setzt die LCD Adresse auf 0x27 für ein 20 Zeichen und 4 Zeilen Display
LiquidCrystal_I2C lcd(0x27, 20, 4, wire);

void setup()
{
  lcd.begin();
  lcd.print("Hallo Welt!");
}

void loop() {}


[my_xy_projekt]

• Einzige bislang funktionierende Lösung ist die spezielle LiquidCrystal_SoftI2C, Beispiel anbei, getestet mit meinem UNO.

Das scheint eine andere NewLiquidCrystal mit gleichem Namen zu sein.https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home

Vielleicht wirds ja besser.

[combie]

Bin ich zu dusselig oder ist es etwa doch nicht so einfach, wie manche Beiträge in diesem Thema glauben machen wollen?

Viele Libraryersteller, kommen offensichtlich nicht auf die Idee, dass:

• Man evtl auch mal Wire1 nutzen möchte
• Dass der Baustein, der Begierde, hinter einem Multiplexer sitzt
• Auch mal SoftI2c zum Einsatz kommen soll

Auch ist es weit verbreitet, in der begin() oder init() Methode ein Wire.begin() zu machen.
Fatal!

• Es macht einem den SlaveMode kaputt, bzw. deaktiviert ihn
• Manchmal muss man bei Wire.begin() die Pins mitgeben
• Manchmal ist Wire.begin() falsch und es sollte besser Wire1.begin() heißen

Alles in allem, sehr unangenehm.

[agmue]

Vielleicht wirds ja besser.

Leider nicht, denn auf der Seite habe ich schon gelesen, aber nichts mich Erhellendes gefunden.

Auch ist es weit verbreitet, in der begin() oder init() Methode ein Wire.begin() zu machen.
Fatal!

In der Bibliothek hd44780 finde ich zumindest:

/*
    * First, initialize the i2c (Wire) library.
    * This really shouldn't be here
    * because Wire.begin() should only be called once, but
    * unfortunately, there is no way to know if anybody
    * else has called this.
    * I believe that it is unreasonable to require the the user
    * sketch code to do it, because all that should change between
    * hd44780 i/o interfaces should be the constructor
    * So we go ahead and call it here.
    */
   Wire.begin();

Getreu Minus mal Minus ergibt Plus, habe ich aus was Schlechtem mit was Schlechtem etwas Funktionierendes gemacht (getestet mit UNO):

Code: [Select]

#include <SoftwareWire.h>
SoftwareWire myWire( 8, 9);
#define Wire myWire
// hd44780 with hd44780_I2Cexp i/o class
#include <hd44780.h> // include hd44780 library header file
#include <hd44780ioClass/hd44780_I2Cexp.h> // i/o expander/backpack class
hd44780_I2Cexp lcd; // auto detect backpack and pin mappings

#define LCD_COLS 20
#define LCD_ROWS 4

void setup()
{
  lcd.begin(LCD_COLS, LCD_ROWS);
  lcd.print("Hallo Welt!");
}

void loop() {}