Hallo,
mache gerade meine ersten Schritte mit Arduinos und habe auch ein
LCD-Dispay
20x4 welches ich eigentlich gerne ansteuern wollen würde. Habe das
Display mit der Adresse 0x27 identifizieren können. Jetzt würde ich
gerne was auf diesem Display anzeigen lassen, aber da tut sich leider
nichts. Nur die erste und die dritte Zeile sind ausgefüllt. Mit diesem
Code habe ich gearbeitet:
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
LiquidCrystal_I2C lcd(0x27, 20, 21);
void setup() {
lcd.clear();
lcd.begin(20, 4);
lcd.backlight();
lcd.setCursor(0, 0);
lcd.print("Hallo");
}
void loop() {
}
Das Display ist auch bei Pin 20 und 21 angeschlossen, grad verwende ich
den Arduino Mega, mit dem Uno hatte ich das selbe Problem. Es wird auch
kein Fehler angezeigt und alles problemlos hochgeladen. Bin echt noch am
Anfang also ein paar Tipps und eine einfache Erklärung wären super!
Vielen Dank im voraus!
Athuro D. schrieb: > Bin echt noch am > Anfang also ein paar Tipps und eine einfache Erklärung wären super! Zuerst zeigst du mal deinen Schaltplan und den Aufbau. Sonst werden wir krass aneinader vorbeireden.
Athuro D. schrieb: > LiquidCrystal_I2C lcd(0x27, 20, 21); Hier gibt man nicht die Pin-Nummern an sondern die Anzahl der Zeilen und Characters pro Zeile. Das Display schliesst man genau an den I2C-Pins des jeweiligen Controllers (Arduino) an. Plus Stromversorgung. Es gibt so viele Maker-Vorschläge wie das zu machen ist, warum fängst du nicht mit einem Code von dort an? Copy&Paste solltest du doch noch schaffen, auch wenn du das alles nicht verstehst.
Sag mal Arthuro,
Hat wastl nicht recht, erst mal Grundlagen.
Sein Beispiel ist gut dokumentiert.
Was kommt bei deinem Aufbau raus, Nix/Hallo ...
Wenn da Hallo kommt, dann ist das schon mal halbwegs richtig
angeschlossen
Dann würde ich probieren:
lcd.setCursor(1, 1);
lcd.print("Hallo1");
lcd.setCursor(2, 2);
lcd.print("Hallo2");
usw.
den Rest findest dann schon selber raus!
LG
A.H
Gelegentlich stimmt die in der Produktbeschreibung angegebene I2C-Adresse nicht oder der User schließt an den falschen Pins an. In den Beispielen der Arduino-IDE gibt es auch einen I2C-Scanner. Lade den mal auf den Arduino und lass ihn laufen. Dann siehst du, ob das Display überhaupt richtig angeschossen ist und welche Adresse es hat. Bevor das nicht funktioniert, brauchst du garnicht weitermachen ...
Wastl schrieb: > Athuro D. schrieb: >> LiquidCrystal_I2C lcd(0x27, 20, 21); > Hier gibt man nicht die Pin-Nummern an sondern die Anzahl > der Zeilen und Characters pro Zeile. Wenn das denn mal so einfach wäre, das hängt vom I2C-Adapter und der Library ab. Bei mir steht LiquidCrystal lcd(12, 11, 5, 4, 3, 2); und eine Weile später lcd.begin(20, 4); lcd.print("Tach Manfred :-)"); Wastl schrieb: > Es gibt so viele Maker-Vorschläge wie das zu machen ist, warum > fängst du nicht mit einem Code von dort an? Warum soll man selbst forschen, wenn doch fragen im Internet einfacher scheint? Axel H. schrieb: > Dann würde ich probieren: > lcd.setCursor(1, 1); > lcd.print("Hallo1"); > lcd.setCursor(2, 2); > lcd.print("Hallo2"); Ich habe gerade vor ein paar Stunden mal wieder Arduino bespielt, mit einem 1602-LCD. Ich habe aber auch 2004 mit I2C in Betrieb. SetCursor beginnt mit Null, wie in der Computerei üblich. Es geht also oben links mit 0,0 los und die vierte Zeile bei 3,0. "lcd.setCursor(2, 2)" wäre dann die dritte Stelle der dritten Zeile.
Angehängte Dateien:
So schaut das ganze Konstrukt aus. Am Display ist auf der Rückseite ein Transferboard. Verbunden hab ich GND - GND, VCC - 5V, SDA - SDA Pin 20, SCL - SCL Pin 21, hoffe das hilft
Axel H. schrieb: > Was kommt bei deinem Aufbau raus, Nix/Hallo ... Es verändert sich nichts am Display
Athuro D. schrieb: > Jetzt würde ich > gerne was auf diesem Display anzeigen lassen, aber da tut sich leider > nichts. Nur die erste und die dritte Zeile sind ausgefüllt. Wieso sind dann die erste und die dritte Zeile ausgefüllt (und mit was)? Athuro D. schrieb: > So schaut das ganze Konstrukt aus. Ich sehe keine Pull-Up Widerstände für den I2C. Sind die in deinem Konstrukt irgendwo vorhanden? Entdeckt der I2C-Scanner aus den Arduino-Beispielen deinen I2C-Umsetzer? Die Kontrastspannung vom Display ist passend eingestellt?
:
Bearbeitet durch User
Rainer W. schrieb: > Athuro D. schrieb: >> Jetzt würde ich >> gerne was auf diesem Display anzeigen lassen, aber da tut sich leider >> nichts. Nur die erste und die dritte Zeile sind ausgefüllt. > > Wieso sind dann die erste und die dritte Zeile ausgefüllt (und mit was)? Bei einem 4*20 DOT-Matrix-Display sind die Zeilen 1 und 3 eine Zeile, aus Sicht des Controllers. Gleiches gilt für die Zeilen 2 und 4. Anders ausgedrückt ist es aus Sicht des Controllers ein 2*40 Display. http://www.sprut.de/electronic/lcd/index.htm#4x20 http://www.sprut.de/electronic/lcd/index.htm
:
Bearbeitet durch User
Rainer W. schrieb: > Wieso sind dann die erste und die dritte Zeile ausgefüllt (und mit was)? Nicht initialisiert! Gruss Chregu
Frank E. schrieb: > In den Beispielen der Arduino-IDE gibt es auch einen I2C-Scanner. Lade > den mal auf den Arduino und lass ihn laufen. Habe ich gemacht, da kam ich dann eben auf die Adresse 0x27.
:
Bearbeitet durch User
Athuro D. schrieb: > Hallo, mache gerade meine ersten Schritte mit Arduinos und habe auch ein > LCD-Dispay 20x4 welches ich eigentlich gerne ansteuern wollen würde. Na, dann hast Du Dir ja gleich etwas ausgesucht, was für die ersten Schritte eher unpassend/ungeeignet ist. Diese Displays müssen in der Regel alle am Anfang initialisiert werden.
> am Anfang initialisiert das sollte mit der eingangs gezeigten Software lcd.clear(); lcd.begin(20, 4); lcd.backlight(); lcd.setCursor(0, 0); erledigt worden sein. Und den I2C-Scanner hat er auch benutzt > Habe das Display mit der Adresse 0x27 identifizieren können. stand alles schon im ersten Post. Die Frage, ob die 1. und 3. Zeile sinnvollen Text enthält oder nur alle Pixel leuchten, hat Athuro noch nicht beantwortet. Nur letzteres könnte einen Initialisierungsfehler bedeuten. Zum Schaltplan eine Frage: blau ist rot und plus ist minus? der blaue steckt in +5V und der rote in GND. Dem Strom ist die Farbe natürlich egal.
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > Dem Strom ist die Farbe natürlich egal. Anders gesagt: Elektronen sind sowieso farbenblind und blau ;-)
Frank E. schrieb: > Gelegentlich stimmt die in der Produktbeschreibung angegebene > I2C-Adresse nicht oder der User schließt an den falschen Pins an. Und gelegentlich wurde vom Hersteller vergessen, die Adresskonfigurationseingänge (A0 bis A2) des PCF8574 an irgendwas anzuschließen. Das hat zur Folge, daß die Adresse nicht lange 0x27 bleibt.
Hast du auch mal das Kontrastpoti von Anfang bis Ende durchgedreht?
Die Kontrasteinstellung ist ein Argument! Ist mir mal vor Jahren passiert: Ich dachte das Display funktioniert nicht und hab tagelang am Code herumgemacht ... bis ich zufällig auf die Idee mit dem Kontrast kam und feststellen musste, dass es vom ersten Moment an funktioniert hat, ich habs bloß nicht gesehen :-( Stell mal den Kontrast (Spannungsteiler?) so ein, dass du die einzelnen Zeichenpositionen schwach aber deutlich als Rechteck sehen kannst ...
Angehängte Dateien:
-
LCD-5X8-Pixels-1024x576.jpg
120 KB
Sehen die Zeilen so aus? Das wäre der Kontraststeller https://geekysoumya.com/arduino-i2c-lcd-usage-problem-solving-guide/ Vielleicht sind SDA und SCL vertauscht? Auf dem Fritzing-"Schaltplan" verschwinden die Leitungen hinter dem Display, da kann man nichts erkennen.
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > Sehen die Zeilen so aus? Das wäre der Kontraststeller > > https://geekysoumya.com/arduino-i2c-lcd-usage-problem-solving-guide/ > > Vielleicht sind SDA und SCL vertauscht? Auf dem Fritzing-"Schaltplan" > verschwinden die Leitungen hinter dem Display, da kann man nichts > erkennen. Ja, das ist der richtige Steller. Wenn SDA und SCL vertauscht wären, würde der I2C-Scanner nichts finden, das kann man m.E. ausschließen. Gemäß der Strategie des "systematischen Einkreisens" von Fehlern würde ich nun auf falsche Steuerbefehle an das Display tippen. Oft werden die Displays für den Amateur-Bereich ja quasi "nebenbei" aus gerade vorhandenen Komponenten zusammengeklöppelt. Es ist also nicht völlig unwahrscheinlich, dass am Display ein anderer Controller klebt, als angenommen. Bietet die verwendete Lib da Auswahl bzw. Einstellmöglichkeiten? Oder auch mal eine andere Lib ausprobieren ... Ich hab auch schonmal einfach Zufallszahlen in ein fremdes Display gepumpt, manchmal zeigen sich dann irgendwelche kryptischen Zeichen. Damit weiss man dann zumimindest, dass es prinzipiell funktioniert :-)
:
Bearbeitet durch User
Stimmt, der Scanner hat ja funktioniert. Der Adapter hat doch meistens einen PCF8574A von Philips/NXP drauf. Da kann die Software nicht viel falsch machen, es sei denn, die Portausgänge sind unterschiedlich verschaltet. Hier ein Schaltplan: https://content.instructables.com/F6G/GQ4H/HSTP2N7H/F6GGQ4HHSTP2N7H.png aus: https://www.instructables.com/LCD-display-I2C-adapter-for-Arduino-with-PCF8574A/
Christoph db1uq K. schrieb: > Da kann die Software nicht viel falsch machen, es sei denn, die > Portausgänge sind unterschiedlich verschaltet. Genau das. Die Software kann sehr viel falsch machen, wenn die Ports des PCF8574A auf dem Modul anders verschaltet sind, als die Software annimmt. Dann funktioniert nicht einmal die Initialisierung. Ein funktionierender I2C-Zugriff auf den Portexpander ist eine notwendig Bedingung, aber lange noch nicht hinreichend, damit sich das eigentliche Display korrekt ansprechen lässt. Wenigstens 6 der Port-I/Os müssen passend zur Library bzw. Konfiguration in der Software verdrahtet sein. Von den anderen beiden kann RW normalerweise auch fest auf W verschaltet sein und das Steuersignal für die LED ist optional. Das einfachste wird sein, sich die Signale am Port vom Display mit dem Logikanalysator anzugucken.
:
Bearbeitet durch User
Angehängte Dateien:
-
Arduino_uno_po.png
1,3 MB
Athuro D. schrieb: > So schaut das ganze Konstrukt aus. Am Display ist auf der Rückseite ein > Transferboard. Verbunden hab ich GND - GND, VCC - 5V, SDA - SDA Pin 20, > SCL - SCL Pin 21, hoffe das hilft Moin, was du da verbunden hast ist +5V, GND, RX und TX. Nix SCL oder SDA. Im Anhang die Pin-Belegung und ein Beispiel. [Edit] Das Beispiel sollte nur 1x da sein, sorry.
:
Bearbeitet durch User
Jörg schrieb: > RX und TX. Nix SCL oder SDA. Er spricht aber vom Arduino Mega. Wer lesen kann ist klar im Vorteil. Du redest Käse. Athuro D. schrieb: > Arduino_mit_LCD-Display.png
Jörg schrieb: > was du da verbunden hast ist +5V, GND, RX und TX. Nix SCL oder SDA. Wachteleier und Straußeneier vergleichen? Das eine ist ein Arduino MEGA2560 und deins ein UNO... Edit: Und der I²C-Scanner findet "das Display" auch.
:
Bearbeitet durch User
Athuro D. schrieb: > gerne was auf diesem Display anzeigen lassen, aber da tut sich leider > nichts. Nur die erste und die dritte Zeile sind ausgefüllt. Ganz klar: 1) Kontrast ist gut genug eingestellt, um die Funktion checken zu können. Jegliche Änderungen hier sind nur noch Optimierung. 2.a) Die Init-Sequenz erricht den Controller nicht.-> Probleme bei der Verdrahtung oder bei der Wahl der I2C-Adresse, oder bei der Implementierung des I2C-Unterbaus. 2.b) Die Init-Sequenz paßt nicht zum Controller. Recht unwahrscheinlich. Alle üblichen Implementierungen versuchen schon, das HD14780-kompatibel hinzubekommen und alle Displays versuchen, zumindest diesbezüglich 100%ig HD1470-kompatibel zu sein. Bei Betrieb über I2C haben die Implementierungen auf der Client-Seite sogar fast keine andere Wahl als kompatibel zu sein, weil dann das Timing "nach unten" keine Rolle mehr spielt. Der Client kann also nicht mehr zu schnell sein. Und er kann und darf beliebig langsam sein, das war schon immer so. 3) Das Target ist garnicht HD14780-kompatibel (relativ unwahrscheinlich, aber nicht unmöglich). Dann wird's schwierig. Man muß was exlizit passendes finden. Oder selber schreiben...
Ob S. schrieb: > Die Init-Sequenz erricht den Controller nicht.-> Probleme bei der > Verdrahtung oder bei der Wahl der I2C-Adresse, oder bei der > Implementierung des I2C-Unterbaus. Wenn man keine Init-Sequenz aufruft kann sie auch nicht den Display-Controller erreichen. Im Beispiel das ich gepostet habe wird ein <lcd.init()> aufgerufen welches ich an anderer Stelle nicht finde. Aber dass man auf solche Trivialitäten erst hinweisen muss ist schon traurig.
> Trivialitäten Hier gibt es kein init, nur begin: https://arduinogetstarted.com/reference/library/arduino-lcd-library Arduino - lcd.begin() Description Initializes the interface to the LCD screen, and specifies the dimensions (width and height) of the display. begin() needs to be called before any other LCD library commands. syntax lcd.begin(cols, rows) und das steht auch in Athuros ersten Post. Eventuell darf das lcd.clear erst nach dem begin "before any other" folgen. aber vielleicht muss es in seinem Programm ja init heissen, wir haben noch nicht erfahren, woher die Software stammt. https://www.arduino.cc/reference/en/libraries/liquidcrystal-i2c/ sehr geschickt, es gibt hier beides in keywords.txt: init KEYWORD2 begin KEYWORD2
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > https://www.arduino.cc/reference/en/libraries/liquidcrystal-i2c/ > sehr geschickt, es gibt hier beides in keywords.txt: > init KEYWORD2 > begin KEYWORD2 Was findest du daran so bemerkenswert. Init() ruft doch automatisch begin() auf.
Es gibt mehrere LiquidCrystal_I2C auf Github: https://github.com/marcoschwartz/LiquidCrystal_I2C https://github.com/johnrickman/LiquidCrystal_I2C https://github.com/lucasmaziero/LiquidCrystal_I2C https://github.com/fdebrabander/Arduino-LiquidCrystal-I2C-library wahrscheinlich noch weitere. Anscheinend gibt es Unterschiede, bei mindestens einer muss man sich erst registrieren, um näheres zu erfahren. Welche hat Athuro benutzt?
Christoph db1uq K. schrieb: > Es gibt mehrere LiquidCrystal_I2C auf Github: Es gibt eine "Lib" auf der Arduino-Seite, dazu gibt es eine Referenz, und mit diesen beiden sollte man glücklich werden (können). https://www.arduino.cc/reference/en/libraries/liquidcrystal-i2c/ Wenn man nicht glücklich werden will nimmt man was anderes und schlägt sich ggf. mit einem Sprach-Wirrwarr herum, was unter Anderem zu diesen vielen Beiträgen führt.
Christoph db1uq K. schrieb: > Die Frage, ob die 1. und 3. Zeile sinnvollen Text enthält oder nur alle > Pixel leuchten, hat Athuro noch nicht beantwortet. Nur letzteres könnte > einen Initialisierungsfehler bedeuten. 1. und 3. Zeile enthalten keinen sinnvollen Text und die Pixel leuchten einfach nur, wenn ich den Kontrast runterdrehe verschwinden die Pixel in der 1. und 3. Zeile, erscheinen tut dann aber am Display trotzdem nichts, wenn ich den Code uploade > Zum Schaltplan eine Frage: blau ist rot und plus ist minus? der blaue > steckt in +5V und der rote in GND. Dem Strom ist die Farbe natürlich > egal. Ja der blaue von 5V zu VCC und der rote von GND zu GND, die Farben auf dem Bild stimmen nicht mit den echten überein, sind halt einfach Female 2 Male Long Kabeln.
Helmut -. schrieb: > Hast du auch mal das Kontrastpoti von Anfang bis Ende durchgedreht? Ja hab ich mit dem Schraubenzieher schon komplett durchgedreht, zwar verschwinden dann irgendwann die Kästchen in der 1. und 3. Zeile, auf dem Display erscheint dann trotzdem nix, hab den Code schon bei unterschiedlichen Kontrasteinstellungen laufen lassen, getan hat sich aber bis jetzt nix
> Es gibt eine "Lib" auf der Arduino-Seite, dazu gibt es eine > Referenz, und mit diesen beiden sollte man glücklich werden > (können). Genau hab die Lib von Arduino verwendet, glaube die sollte ja eigentlich auch ausreichend sein oder? Den Code hab ich selber mit Unterstützung von Chatgpt zusammengebaut
Athuro D. schrieb: > erscheinen tut dann aber am Display trotzdem nichts, wenn ich den > Code uploade Dann ist es jetzt allmählich Zeit, das Problem systematisch anzugehen und nicht einfach zu erwarten, dass irgendein LCD mit irgendeinem I2C-Adapter mit irgendeiner Bibliothek funktioniert. Besitzt du irgendwelche Messmittel, um zeitaufgelöst Signale zu betrachten (LA, Oszi)? Die Datenblätter zu den Bausteinen auf deinen Modulen könnten auch helfen. Athuro D. schrieb: > Den Code hab ich selber mit Unterstützung von Chatgpt zusammengebaut Dann kann an dem Code ja nichts falsch ein ;-(
:
Bearbeitet durch User
Athuro D. schrieb: > Den Code hab ich selber mit Unterstützung > von Chatgpt zusammengebaut Dann zeig den doch mal. Eigentlich funktionieren diese Displays mit der Arduino-Lib sofort out-of-the-box. Super simpel, ein Mensch kann da eigentlich garnichts falsch machen. Die "KI" ist da vielleicht erfinderischer. Oder probier mal den Beispiel-Code zu der Lib, und lass ChatGPT da NIX dran ändern, Adresse 0x27 steht da schon drinnen, 20×4 Zeilen auch schon: https://github.com/johnrickman/LiquidCrystal_I2C/blob/master/examples/HelloWorld/HelloWorld.pde
Athuro D. schrieb: > Genau hab die Lib von Arduino verwendet Und warum verwendest du dann nicht den im Library Archiv enthaltenen Beispielcode. Genau der ist doch kompatibel mit der Library. Man braucht nichts tun ausser die LCD Parameter anzupassen.
Christoph db1uq K. schrieb: > Eventuell darf das lcd.clear erst nach dem begin "before any other" > folgen. Ich kenne die benutzte Lib nicht. Aber üblicherweise wollen Arduino-Libs für Datenübertragungen, dass man zu allererst ein begin() aufruft. Das begin() initialisiert zunächst mal den I2C-Controller im µP, bevor es das LCD über diesen Bus ansprechen kann. Wenn man vorher etwas mit dem uninitialisierten I2C-Controller macht, also z. B. lcd.clear(), dann muss man schon Glück haben, wenn es nicht in die Hose geht.
Εrnst B. schrieb: > Athuro D. schrieb: > Oder probier mal den Beispiel-Code zu der Lib, und lass ChatGPT da *NIX* > dran ändern, Adresse 0x27 steht da schon drinnen, 20×4 Zeilen auch > schon: > > https://github.com/johnrickman/LiquidCrystal_I2C/blob/master/examples/HelloWorld/HelloWorld.pde Der Code hat tatsächlich funktioniert! Vielen Dank für die Hilfe, ich dachte bei solchen simplen Dingen kann Chatgpt schon helfen, aber anscheinend hab ich da wohl irgendeinen Blödsinn gebaut. Auch Danke an alle anderen die sich in den letzten Tagen mit meinem Problem befasst haben, sehr nettes und kompetentes Forum :)
Ok das heisst, die Verbindung zum I2C-Port PCF8574 funktioniert noch, aber das Display selbst fühlt sich nicht angesprochen. Die zwei weißen Zeilen sind einfach ein Einschaltzustand des LCD ohne Initialisierung. Wastls "offizielle" Library ist die Version von Frank de Brabander / Marco Schwartz. Das ist leider die mit "Status: Archived This repository has been transfered to GitLab at https://gitlab.com/tandembyte/LCD_I2C"; und dort wollen sie erst mal eine Registrierung. In dem ohne Registrierung hier noch downloadbaren zip-File "1.1.2 (latest)" stehen drei .pde Beispielprogramme, das kleinste ist HelloWorld.pde. Darin, wie es Wastl schreibt, der init-Befehl als allererstes: lcd.init(); // initialize the lcd Dann folgt eine Textausgabe mit Cursorsteuerung in beiden Zeilen. nochmal zum Vergleich Athuros Programm aus dem Eingangspost LiquidCrystal_I2C lcd(0x27, 20, 21); lcd.clear(); lcd.begin(20, 4); lcd.backlight(); lcd.setCursor(0, 0); lcd.print("Hallo"); und in HelloWorld.pde zuerst die I2C-Schnittstelle "address to 0x27 for 16 chars and 2 line": LiquidCrystal_I2C lcd(0x27,20,4); komisch, die 16*2 sehe ich da nicht, klingt eher nach 20*4 ab hier sollte das Display zuhören: lcd.init(); // initialize the lcd lcd.init(); Wieso kommt danach dasselbe nochmal? Schreibfehler? lcd.backlight(); lcd.setCursor(3,0); lcd.print("Hello, world!"); lcd.setCursor(2,1); lcd.print("Ywrobot Arduino!"); Das sind unterschiedliche LCD-libraries. Schon die I2C-Parameter sind verschieden, und dann lcd.begin / lcd.init.
:
Bearbeitet durch User
Rolf schrieb: > Aber üblicherweise wollen Arduino-Libs > für Datenübertragungen, dass man zu allererst ein begin() aufruft. Üblicherweise ist es kein Fehler, einmal kurz in die Bibliothek rein zu gucken, z.B. werden in o.g. Bibliothek beide begin()-Routinen (I2C aka wire und LCD) in der init() aufgerufen. https://github.com/johnrickman/LiquidCrystal_I2C Was in Arduino-Libs üblich ist, spielt für eine spezielle Bibliothek überhaupt keine Rolle (s. Beispiel).
:
Bearbeitet durch User
Mein letzter Text hat sich jetzt mit Athuros Post überschnitten. Johnrickman scheint mit der "offiziellen" Library eher kompatibel zu sein, auch die Ungereimtheiten im HelloWorld sind identisch. Doch das doppelte lcd.init(); ist beseitigt, aber die 16*2 stehen noch im Kommentar.
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > ab hier sollte das Display zuhören: > lcd.init(); // initialize the lcd Wie meinst du das? Vor Aufruf der lcd.init() funktioniert noch nicht einmal die Kommunikation vom µC zum I2C-Portexpander.
Hier ist der Ablauf einzeln erklärt: https://arduinogetstarted.com/tutorials/arduino-lcd-20x4 erst die LCD-library einbinden: #include <LiquidCrystal_I2C.h> // Library for LCD Dann die I2C-Adresse und Typ des LCD angeben: - stimmt, damit ist noch nichts angesprochen nur deklariert. LiquidCrystal_I2C lcd(0x27, 20, 4); // I2C address 0x27, 20 column and 4 rows jetzt die eigentliche Initialisierung, danach kann das LCD angesprochen werden, dabei wird als erstes der PCF8574 eingestellt und noch mehrfach geändert: lcd.init(); //initialize the lcd Licht an, sonst ist es schlecht lesbar: lcd.backlight(); //open the backlight dann endlich die Textausgabe, wenn nötig mit Cursorsteuerung. Der "lcd.init" muss einiges an Zeitverzögerungen enthalten. Wenn man die nicht befolgt kann die Initialisierung schiefgehen. Im Datenblatt zum HD44780 (Ob S. hat ihn dreimal falsch geschrieben) sind das mindesten 20 Millisekunden. Im Vergleich zu den 16 MHz Takt des Arduino "eine halbe Ewigkeit". https://de.wikipedia.org/wiki/HD44780 https://cdn-shop.adafruit.com/datasheets/HD44780.pdf auf S.46 steht das Initialisierungsdiagramm
:
Bearbeitet durch User
Moin, Hier die TWI Welt von Gerhard😊: Ich rate, bei fremden Libs und Modulen mit Libs unbedingt IMMER eines der meist mitgelieferten Beispiele vorschriftsmäßig zu beschalten und erst ausprobieren, ob das "out of the box" läuft. Wenn so weit alles on Ordnung ist, dann erst mit eigenen Ausflügen die Welt nach eigenen Ermessen zu erforschen:-) Immer sicherstellen, daß die vorgeschriebenen Pullup Widerstände tatsächlich angeschlossen sind und sich die Werte im Rahmen der üblichen Vorgaben bewegen. Bei vielen Teilnehmern empfiehlt es sich die Werte im erlaubten Rahmen kleiner zu machen. Aufpassen, daß TWI Taktfrequenzen für die zu verbindenden Busteilnehmer zusammenpassen. Im Zweifelfall immer mit "Langsam" wie 30-100khz anzufangen. Bei SMB TWI beachten, daß hier eine minimale Taktraten Vorgabe existiert. Bei zuverlässigen Designs immer testen welche Busteilnehmer sich vom Host Zwangs-rücksetzen lassen. Datenblätter geben meist darüber Aufschluß. Wenn ein Busteilnehmer da nicht mitspielt, dann die HW Beschaltung so zu gestalten, daß so ein Teil durch Power-Cycling wieder "vernünftig" gemacht werden kann und sorgfältig testen. TWI Verbindungen sollten nicht unnötig lang sein, um unnötige kapazitive Busbelastungen minimal zu halten. SDA/SCL sollten nach Möglichkeit auf keinen Fall verdrillt sein, um die Möglichkeit von "Übersprechen" zu minimieren. Auch ist es bei der Flachbandkabel Pin-Auswahl besser, SDA und SCL auseinander zu halten, anstatt sie nebeneinander zu legen. (Ich habe übrigens mit guten Erfolg, Vier-Leiter Telefonstrippen als TWI Verbinder, z.B. bei LCD Displays mit TWI IO-Expander Verbindung wie die handelsüblichen PCF8574 Bords, verwendet). Bei TWI empfiehlt es sich immer, einen TWI Scanner zur Verfügung zu haben, um bestätigen zu können, daß alle Busteilnehmer wie erwartet, erkannt werden. Es gibt dafür zahlreiche Beispiele. Bei gewissen TWI Käfern wie z.B. EEPROMSs kann manchmal noch eine unerwartete zusätzliche Adresse erkannt werden. Das kommt manchmal vor, um auf spezielle Bereiche solcher Individuen zugreifen zu können. Das ist zwar relativ selten, aber nicht unmöglich. (bei EEPROMS auf manchen Chinesischen DS3231 RTC Modulen konnte ich solches Verhalten in der Tat beobachten). Immer aufpassen, die zugehörigen Port TWI Pins richtig anzuschliessen. Bei uC mit mehr als einer TWI Schnittstelle sich zu vergewissern, wie man deswegen die Initialisierung konfigurieren muß, damit auf den beabsichtigten Port zugegriffen wird. Glückwunsch, daß es jetzt funktioniert. Duck und weg... Gerhard
:
Bearbeitet durch User
Angehängte Dateien:
-
ChatGPT.png
33 KB
Athuro D. schrieb: > Den Code hab ich selber mit Unterstützung von Chatgpt zusammengebaut Das nächste mal die 'Bots, Chats & Co' am besten nur dahingehend fragen, an wen man sich bei einem Problem eventuell wenden könnte, denn auf sich selbst werden sie in der Antwort vermutlich nicht verweisen – im Anhang ein Screenshot. Mit jeder Generation wird es immer lustiger und absurder auf dieser Welt.
:
Bearbeitet durch User
Gregor J. schrieb: > Athuro D. schrieb: >> Den Code hab ich selber mit Unterstützung von Chatgpt zusammengebaut > > Das nächste mal die 'Bots, Chats & Co' am besten nur dahingehend fragen, > an wen man sich bei einem Problem eventuell wenden könnte, denn auf sich > selbst wird er in der Antwort vermutlich nicht verweisen – im Anhang ein > Screenshot. Mit jeder Generation wird es immer lustiger und absurder auf > dieser Welt. Was ist an der Neugierde mit GPTs so schlimm? Zur Zeit ist es eben noch eine Neuheit. Ob es in solchen Fällen sinnvoll ist, mag dahingestellt sein. Ich würde es nicht ganz in einem so negativen Licht sehen. (Die wirklichen Gefahr kommt vom sozialen politisch motivierten organisiert betriebenen Missbrauch von KI Werkzeugen durch systematische Manipulation der Schwachstelle Mensch. Das wird uns in voraussehbarer Zeit durch fabrizierte Lügengespinste die größten Probleme verursachen. Die Bösewichte lecken sich doch schon lange ihre Finger nach solchen Werkzeugen. Und jetzt hat man ihnen in naiverweise eines der schlimmste Instrumente in der Geschichte der Menschheit, noch frei dazu, in deren Hand gegeben) "Wer keinen Spieltrieb, wie ein Kind mehr, sein Eigen nennen kann, ist technisch gesehen, schon fast tot":-)
:
Bearbeitet durch User
Gerhard O. schrieb: > Ob es in solchen Fällen sinnvoll ist Genau in diesem Fall – und in vielen ähnlichen Fällen auch – ist es eben überhaupt nicht sinnvoll. Wer das nicht differenzieren kann, der sollte seine Fragen am besten anders formulieren, wie von mir oben schon erwähnt worden ist. _ Gerhard O. schrieb: > Was ist an der Neugierde mit GPTs so schlimm? Es wurde von mir auch nicht behauptet, dass an der Neugierde mit Bots etwas schlimmes sei, insofern ist der vermeintliche Erklärungsversuch auch ein Fehlgriff – einfach nochmal in Ruhe durchlesen und nachsinnen.
Gerhard O. schrieb: > Was ist an der Neugierde mit GPTs so schlimm? Wenn man das einfach nur so aus Jux macht, meinetwegen. Wenn man aber versucht, reale Probleme damit zu lösen, und sei es auch nur so eine Bastelübung wie hier, dann gibt man die eigenen Fähigkeiten an der Tür ab. Stell' Dir mal vor, der Kram hätte funktioniert, ohne Fehler. Was wäre davon gelernt worden? Nichts. Und je mehr fertig vorverdautes Zeug aus irgendeinem ChatBlubber kommt, desto weniger versteht dessen Nutzer, was da eigentlich passiert. Wenn es dann nach einiger Gewöhnung doch mal klemmt, ist der Nutzer komplett hilflos, denn er hat selbst keinerlei Fähigkeiten entwickelt, außer vielleicht "Prompts" zu formulieren.
Angehängte Dateien:
-
I2C-Kabel.jpg
77 KB
Gerhard O. schrieb: > Hier die TWI Welt von Gerhard😊: Viel zu viele Bedenken, I2C am Arduino ist gutmütig, wenn man sich nicht extrem dämlich anstellt. Auf dem Bild bedient der Nano fünf I2C-Komponenten, das sind China-Platinchen mit PullUp am I2C drauf, je 10kOhm. Die Topologie ist ein Stern mit fünf Enden geworden, verkabelt mit den "DuPont-Kabeln" vom Ali. Falls dort ein Modul ausfallen sollte, käme man dank der Steckverbindungen überall gut heran. Recht hast Du natürlich damit, dass man bei externen Libs erstmal die mitgelieferten Beispiele austestet. Daraus sollte sich eine eigene Sammlung funktionierender Klassen ergeben, die man dann zu dem komplexeren Projekt zusammenführt. Gerhard O. schrieb: > Was ist an der Neugierde mit GPTs so schlimm? Zur Zeit ist es eben noch > eine Neuheit. Es nervt einfach nur noch, ständig von KI zu lesen und zu hören. Wenn jemand wirklich der Meinung ist, er müsse sich eine Arduino-Software per KI erzeugen lassen, kann ich ihn noch nicht einmal bedauern. Ich dilettantiere seit einer Weile daran herum, DCF77 zuverlässig zu decodieren. Eine fertige .lib will ich nicht einsetzen, weil ich deren Art der Signalerkennung nicht sinnvoll finde. Da werde ich noch viele Stunden dran sitzen, aber ganz sicher nicht mit dem GPT-Idioten spielen. Harald K. schrieb: >> Was ist an der Neugierde mit GPTs so schlimm? > Wenn man das einfach nur so aus Jux macht, meinetwegen. Wenn man aber > versucht, reale Probleme damit zu lösen, und sei es auch nur so eine > Bastelübung wie hier, dann gibt man die eigenen Fähigkeiten an der Tür > ab. Man gibt keine Fähigkeiten ab, weil man sie garnicht erst erworben hat.
Harald K. schrieb: > Gerhard O. schrieb: >> Was ist an der Neugierde mit GPTs so schlimm? > > Wenn man das einfach nur so aus Jux macht, meinetwegen. Wenn man aber > versucht, reale Probleme damit zu lösen, und sei es auch nur so eine > Bastelübung wie hier, dann gibt man die eigenen Fähigkeiten an der Tür > ab. Stell' Dir mal vor, der Kram hätte funktioniert, ohne Fehler. Was > wäre davon gelernt worden? Nichts. > Und je mehr fertig vorverdautes Zeug aus irgendeinem ChatBlubber kommt, > desto weniger versteht dessen Nutzer, was da eigentlich passiert. > > Wenn es dann nach einiger Gewöhnung doch mal klemmt, ist der Nutzer > komplett hilflos, denn er hat selbst keinerlei Fähigkeiten entwickelt, > außer vielleicht "Prompts" zu formulieren. 100% Ack. Ich versuchte aber, nur eine einigermassen gerechte Representation zu erfassen. Was meine Person angeht, habe ich aus diversen Gründen noch keine Zeit damit verschwendet, da ich momentan in meinem Umkreis wenig realen Nutzen für mich sehe. Ich kenne allerdings einige Bekannte, die ein williges "Opfer" der GPT geworden sind, weil man sich unrealistische Erwartungen machte. Man muß abwarten was die Zukunft bringt. "Vor dem Erfolg setzten die Götter den Schweiß" - Vielleicht mit Recht... Aus meiner Sicht hätte man mit dem "Loslassen in die Welt" noch warten sollen, bis genug effektive Sicherheitsmaßnahmen erfunden worden sind, um "Informations-Terrorismus" in Schach zu halten. Das /GPT KI Schadenspotenzial in systematischer Informationsfälschung bzw. Gespinste aller Art ist leider wegen der Leichtgläubigkeit vieler Internet-Informationssüchtigen Konsumenten enorm und wird uns in absehbarer Zeit (weltpolitisch) noch viel unangenehme Vorfälle bescheren, da Authentizität der GPT Gespinste nur in den seltensten Fällen bestätigt werden kann und so nur für eine generelle gehobene Unsicherheit der menschlichen Informationsdiskrimination sorgt. Von diesem Standpunkt aus hätte man w.g. GPT noch nicht auf die Menschheit loslassen sollen. Die Leichtgläubigkeit gewisser Informationskonsumer spielt da sehr in die Hände der Intriganten. Bis man ausreichend sichere Wasserzeichenmarkierungsmöglichkeiten gut genug beherrscht, kann damit (mit leichtgläubigen Konsumenten) zu viel Unfug getrieben werden. Aber leider siegt hier höchstwahrscheinlich wieder einmal die Profitgier der Macher um diese Technik so schnell wie möglich breitflächig kommerzialisieren zu können. GPT hat das Potenzial einer Informationsbombe. Abgesehen davon sprachen sich schon einige Industriegrößen gegen eine zu schnelle Verbreitung aus.
Manfred P. schrieb: > Gerhard O. schrieb: >> Hier die TWI Welt von Gerhard😊: > > Viel zu viele Bedenken, I2C am Arduino ist gutmütig, wenn man sich nicht > extrem dämlich anstellt. Naja. Ich wollte nur eine kleine nützliche Zusammenfassung aufstellen. > > Auf dem Bild bedient der Nano fünf I2C-Komponenten, das sind > China-Platinchen mit PullUp am I2C drauf, je 10kOhm. Die Topologie ist > ein Stern mit fünf Enden geworden, verkabelt mit den "DuPont-Kabeln" vom > Ali. Ich finde Deine Aufbauten immer sehr interessant. Was ist das übrigens für ein Gerät? > > Falls dort ein Modul ausfallen sollte, käme man dank der > Steckverbindungen überall gut heran. Modularität hat schon immer Vorteile gehabt. Bei einen solchen Aufbau, sind auch die TWI Verdrahtungen ziemlich gutmütig. Manchmal kann man es durch "saubere" Verdrahtung noch schlimmer machen. Kabelbaum (übersprechen) gegen lose Verdrahtung. > > Recht hast Du natürlich damit, dass man bei externen Libs erstmal die > mitgelieferten Beispiele austestet. Daraus sollte sich eine eigene > Sammlung funktionierender Klassen ergeben, die man dann zu dem > komplexeren Projekt zusammenführt. Auf alle Fälle. Wenn ich etwas Neues ausprobiere, mache ich das immer so. > > Gerhard O. schrieb: >> Was ist an der Neugierde mit GPTs so schlimm? Zur Zeit ist es eben noch >> eine Neuheit. > > Es nervt einfach nur noch, ständig von KI zu lesen und zu hören. Wenn > jemand wirklich der Meinung ist, er müsse sich eine Arduino-Software per > KI erzeugen lassen, kann ich ihn noch nicht einmal bedauern. Mich auch. Aber leider sind wir Einzelne in der Wildnis... > > Ich dilettantiere seit einer Weile daran herum, DCF77 zuverlässig zu > decodieren. Eine fertige .lib will ich nicht einsetzen, weil ich deren > Art der Signalerkennung nicht sinnvoll finde. Da werde ich noch viele > Stunden dran sitzen, aber ganz sicher nicht mit dem GPT-Idioten spielen. Ich sehe das genauso. > > Harald K. schrieb: >>> Was ist an der Neugierde mit GPTs so schlimm? >> Wenn man das einfach nur so aus Jux macht, meinetwegen. Wenn man aber >> versucht, reale Probleme damit zu lösen, und sei es auch nur so eine >> Bastelübung wie hier, dann gibt man die eigenen Fähigkeiten an der Tür >> ab. > > Man gibt keine Fähigkeiten ab, weil man sie garnicht erst erworben hat. Edison formulierte das besonders schön: "Invention*) is two parts inspiration and ninety-eight parts perspiration" *) wo man invention mit Erfolg auswechseln könnte.
:
Bearbeitet durch User
Gerhard O. schrieb: >> Viel zu viele Bedenken, I2C am Arduino ist gutmütig, wenn man sich nicht >> extrem dämlich anstellt. > Naja. Ich wollte nur eine kleine nützliche Zusammenfassung aufstellen. Die ich inhaltlich in Ordnung finde, aber den Bastler (TO) mehr verwirrt als ihm zu helfen. >> Auf dem Bild bedient der Nano fünf I2C-Komponenten, das sind >> China-Platinchen mit PullUp am I2C drauf .. > Ich finde Deine Aufbauten immer sehr interessant. Was ist das übrigens > für ein Gerät? 2-Kanal Akkutester, Konstantstrom und schreibt alle 15s Spannung / Strom auf die SD-Karte. Auf den beiden Kühlkörpern je drei MOS-FETs und auf dem vorderen vier Hochlastwiderstände. Bilder habe ich 2018 als pdf gebaut, hänge ich an. >> Falls dort ein Modul ausfallen sollte, käme man dank der >> Steckverbindungen überall gut heran. > Modularität hat schon immer Vorteile gehabt. Bei einen solchen Aufbau, > sind auch die TWI Verdrahtungen ziemlich gutmütig. Manchmal kann man es > durch "saubere" Verdrahtung noch schlimmer machen. Kabelbaum > (übersprechen) gegen lose Verdrahtung. TWI ist für kurze Strecken gedacht, z.B. ICs innerhalb der Leiterplatte eines Fernsehgerätes. Wie weit sie über ein Stück Kabel funktionieren, habe ich nie probiert. Da es ein unsymmetrisches Signal ist, natürlich nicht verdrillt und selbst ein Schirm könnte stören. Zu Anfang meiner Erwerbstätigkeit hatte ich mit Beschallung und Tonstudiotechnik zu tun, Radio und Fernsehton liefen über Baugruppen, die wir entwickelt und gefertigt haben. Das Wissen aus dieser Zeit, Übersprechen oder Symmetrie, war mir später an anderen Stellen nützlich. >> Recht hast Du natürlich damit, dass man bei externen Libs erstmal die >> mitgelieferten Beispiele austestet. Daraus sollte sich eine eigene >> Sammlung funktionierender Klassen ergeben, die man dann zu dem >> komplexeren Projekt zusammenführt. > Auf alle Fälle. Wenn ich etwas Neues ausprobiere, mache ich das immer > so. Man sieht es ständig in anderen Threads: Da werden Projekte zusammenkopiert, anstatt sich stückweise heran zu arbeiten. >> Es nervt einfach nur noch, ständig von KI zu lesen und zu hören. Wenn >> jemand wirklich der Meinung ist, er müsse sich eine Arduino-Software per >> KI erzeugen lassen, kann ich ihn noch nicht einmal bedauern. > Mich auch. Aber leider sind wir Einzelne in der Wildnis... Andere stufen uns als fortschrittsfeindlich ein, weil wir nicht jede Hype mitspielen. >> Ich dilettantiere seit einer Weile daran herum, DCF77 zuverlässig zu >> decodieren. Eine fertige .lib will ich nicht einsetzen, weil ich deren >> Art der Signalerkennung nicht sinnvoll finde. Da werde ich noch viele >> Stunden dran sitzen, aber ganz sicher nicht mit dem GPT-Idioten spielen. > Ich sehe das genauso. Ich werde auch nicht auf µC-net fragen. Das ist wieder eines dieser Probleme, wo die Lösung über mir schwebt, ich sie aber noch nicht greifen kann. Eine Weile nichts tun, wird sie mir irgendwann auf den Teller fallen, während das Frühstücksei im Kocher steckt.
Manfred P. schrieb: > Gerhard O. schrieb: >>> Viel zu viele Bedenken, I2C am Arduino ist gutmütig, wenn man sich nicht >>> extrem dämlich anstellt. >> Naja. Ich wollte nur eine kleine nützliche Zusammenfassung aufstellen. > > Die ich inhaltlich in Ordnung finde, aber den Bastler (TO) mehr verwirrt > als ihm zu helfen. OK. Das bedachte ich nicht. > >>> Auf dem Bild bedient der Nano fünf I2C-Komponenten, das sind >>> China-Platinchen mit PullUp am I2C drauf .. >> Ich finde Deine Aufbauten immer sehr interessant. Was ist das übrigens >> für ein Gerät? > > 2-Kanal Akkutester, Konstantstrom und schreibt alle 15s Spannung / Strom > auf die SD-Karte. Auf den beiden Kühlkörpern je drei MOS-FETs und auf > dem vorderen vier Hochlastwiderstände. Bilder habe ich 2018 als pdf > gebaut, hänge ich an. Sieht und hört sich als sehr nützlich an. Die Schalterstreifen auf der Oberseite gefallen mir. Sehen sehr solide aus. An sich hätte man die Kühlaggregate möglicherweise auch innen mit Lüfter unterbringen können. Wenn es Dich interessiert: In den 80ern konstruierte ich in der Firma einen Batterietester mit ungewöhnlichem Design. Was den Betrieb betrifft enthielt das Teil einen CV/CC Reglerschaltung zum Laden und ein CC Entladeteil. Für die Steuerung war eine Bord voller CMOS verantwortlich, die über einen Vierfach Drehwähler vier Impulszählwerke dirigierte und es erlaubte bis zu vier Lade und Entladezyklen durchlaufen zu lassen. Die Zählwerke wurden mit Minuten Impulsen angesteuert und gaben die Kapazität der Akkus viermal an. Ein Tiefentladungeinsteller beendete jeden Zwischenzyklus. Nach so einem Zyklus hatte man eine Aufzeichnung, wie sich die Kapazität der Akkus über diesen Zeitraum verhielt. Es funktionierte ausgezeichnet. Mit einem Rückstell-Knopf konnte man dann den Drehwähler wieder in die Ausgangsposition bringen. Leider habe ich das Teil nicht und fürchte es wurde nach Auflassung des Labors dann irgendwann verschrottet. Schon verrückt was man in jungen Jahren anstellt... > >>> Falls dort ein Modul ausfallen sollte, käme man dank der >>> Steckverbindungen überall gut heran. >> Modularität hat schon immer Vorteile gehabt. Bei einen solchen Aufbau, >> sind auch die TWI Verdrahtungen ziemlich gutmütig. Manchmal kann man es >> durch "saubere" Verdrahtung noch schlimmer machen. Kabelbaum >> (übersprechen) gegen lose Verdrahtung. > > TWI ist für kurze Strecken gedacht, z.B. ICs innerhalb der Leiterplatte > eines Fernsehgerätes. Wie weit sie über ein Stück Kabel funktionieren, > habe ich nie probiert. Da es ein unsymmetrisches Signal ist, natürlich > nicht verdrillt und selbst ein Schirm könnte stören. Naja. Ich steckte ein 4x20 LCD in ein klares Hammond Gehäuse hinein und verbinde es mit einem vier-adrigen 1.5m langen Telefonstrippe mit dem uC. Es gab noch nie Probleme. Scheint ausreichend zu übertragen. Ich sollte allerdings mal die Flanken zwischen Ansteuerung und LCD Seite vergleichen. > > Zu Anfang meiner Erwerbstätigkeit hatte ich mit Beschallung und > Tonstudiotechnik zu tun, Radio und Fernsehton liefen über Baugruppen, > die wir entwickelt und gefertigt haben. Das Wissen aus dieser Zeit, > Übersprechen oder Symmetrie, war mir später an anderen Stellen nützlich. Das glaube ich Dir aufs Wort. > >>> Recht hast Du natürlich damit, dass man bei externen Libs erstmal die >>> mitgelieferten Beispiele austestet. Daraus sollte sich eine eigene >>> Sammlung funktionierender Klassen ergeben, die man dann zu dem >>> komplexeren Projekt zusammenführt. >> Auf alle Fälle. Wenn ich etwas Neues ausprobiere, mache ich das immer >> so. > > Man sieht es ständig in anderen Threads: Da werden Projekte > zusammenkopiert, anstatt sich stückweise heran zu arbeiten. Ja. Ich mache das aber teilweise auch (Schäm). Allerdings erarbeitete ich mir über 25 J uC genug Wissen, um mir meist selber helfen zu können. Abgesehen davon gab es das früher nicht. Ich fing mit PICs an und da gab es damals nichts zum Abschreiben. Da mußte man sich auch zwangsweise damit gründlich befassen. Aber mit dem Alter wurde ich bequemer und halte mich an die Device: "If you must steal, only steal from the best!" > >>> Es nervt einfach nur noch, ständig von KI zu lesen und zu hören. Wenn >>> jemand wirklich der Meinung ist, er müsse sich eine Arduino-Software per >>> KI erzeugen lassen, kann ich ihn noch nicht einmal bedauern. >> Mich auch. Aber leider sind wir Einzelne in der Wildnis... > > Andere stufen uns als fortschrittsfeindlich ein, weil wir nicht jede > Hype mitspielen. Das macht unser Alter. Man merkt sich Erfolge und deren Gegenteil. Man durchschaut oft den Hype und das kommt dann so an. Ich bin eher ein langsamer Adoptier. Ich warte meist die "Bleeding Edge" ab, bis sich die scharfen Ecken abrunden und beobachte eine Weile. Ich kommentiere da wie Obelix, ... die spinnen... > >>> Ich dilettantiere seit einer Weile daran herum, DCF77 zuverlässig zu >>> decodieren. Eine fertige .lib will ich nicht einsetzen, weil ich deren >>> Art der Signalerkennung nicht sinnvoll finde. Da werde ich noch viele >>> Stunden dran sitzen, aber ganz sicher nicht mit dem GPT-Idioten spielen. >> Ich sehe das genauso. Macht ja auch mehr Spaß, sich eigene Lösungen zu erarbeiten. Speziell, wenn es um klar dokumentierte umrissene Standards wie DCF geht. Ich würde es übrigens mit ISR over-sampling machen und dann mit Auf- und Ab-Zählern de-glitchen. Das machte ich mal bei einem Datenfunk Projekt und hatte sich sehr bewährt, weil kurzzeitige Aussetzer und Störungen nicht gleich zu Datenfehlern führten. > > Ich werde auch nicht auf µC-net fragen. Das ist wieder eines dieser > Probleme, wo die Lösung über mir schwebt, ich sie aber noch nicht > greifen kann. Eine Weile nichts tun, wird sie mir irgendwann auf den > Teller fallen, während das Frühstücksei im Kocher steckt. Ja. Geht mir manchmal auch so. Macht aber mehr Spass die verschiedensten Möglichkeiten durchzugehen. ...
:
Bearbeitet durch User
Manfred P. schrieb: > Ich dilettantiere seit einer Weile daran herum, DCF77 zuverlässig zu > decodieren. Eine fertige .lib will ich nicht einsetzen, weil ich deren > Art der Signalerkennung nicht sinnvoll finde. Was gefällt Dir denn daran nicht? Hier mal ein schon recht alter Code: Beitrag "DCF77 Uhr in C mit ATtiny26" Da sind auch ne Menge Fragen und Erläuterungen mit bei.
Gerhard O. schrieb: > .............. TLDR Vielleicht müsste "man" auch mal mit der Zitat-Funktion üben damit der geneigte Leser überhaupt dekodieren kann wer was gesagt hat und was gesagt werden soll. Bei diesem Kauderwelsch von ASCII vergeht einem wirklich das Lesen. Hinweis: Es gibt die Möglichkeit Leerzeilen einzufügen um die Lesbarkeit und Übersichtlichkeit eines Textes zu verbessern. Schon mal drüber nachgedacht?
Wastl schrieb: > Gerhard O. schrieb: >> .............. > > TLDR > > Vielleicht müsste "man" auch mal mit der Zitat-Funktion üben > damit der geneigte Leser überhaupt dekodieren kann wer was > gesagt hat und was gesagt werden soll. Bei diesem Kauderwelsch > von ASCII vergeht einem wirklich das Lesen. Hinweis: Es gibt > die Möglichkeit Leerzeilen einzufügen um die Lesbarkeit und > Übersichtlichkeit eines Textes zu verbessern. > > Schon mal drüber nachgedacht? Es geht nicht wirklich um das "Können"! Ich stimme Dir zu und sehe es genauso. Aber mit dem iPad und Safari funktioniert die Zitat Funktion des Forums bei mir zumindest schlicht und einfach nicht richtig. Forums Teil-Zitat-Wahl geht nämlich überhaupt nicht. Ist mir alles bewußt, aber ich habe es aufgegeben mich darüber zu ärgern. Am PC ist dies alles kein Thema. Und alles manual mit dem iPad zu editieren ist mir wiederum zu viel Arbeit und möchte es mir nicht antun.
:
Bearbeitet durch User
Gerhard O. schrieb: > Aus meiner Sicht hätte man mit dem "Loslassen in die Welt" noch warten > sollen, bis genug effektive Sicherheitsmaßnahmen erfunden worden sind, > um "Informations-Terrorismus" in Schach zu halten. (...) > GPT hat das Potenzial einer Informationsbombe. Abgesehen davon sprachen > sich schon einige Industriegrößen gegen eine zu schnelle Verbreitung aus. Immer locker bleiben, denn auch damit wird die Population des Homo sapiens im Kern schon fertig und es – der Wahrscheinlichkeit nach – sehr gut überleben. Dass einige am Rande von solchen Dingen Panikattacken bekommen, durchdrehen, Ängste schüren oder gar Verschwörungstheorien daraus konstruieren, ist leider auch normal und Teil des Programms im Gehirn von Homo sapiens – der Zahn der Zeit wird es schon glätten, dann ist im Mittelwert alles wieder halbwegs normal, was auch immer unter 'normal' in der jeweiligen Epoche verstanden werden kann, denn auch das unterliegt einer ständigen Verformung wie das Kneten einer Knettmasse. Die richtige, belebte AI atomar aufgebaut ist eh noch nicht auf der Erde – sie wird in der Zukunft noch von jemandem geschrieben/gebaut, denn was im Moment da ist, könnte man im Vergleich dazu nur als Spielereien von Kindern bezeichnen – auch das sagt die Wahrscheinlichkeit voraus oder die extrapolierte Vergangenheit, die als Zukunft in dieser Wirklichkeit mit dem begrenzten Bewusstsein verstanden werden kann und von allen auch so erlebt wird.
:
Bearbeitet durch User
Gregor J. schrieb: > Dass einige am Rande von solchen Dingen Panikattacken > bekommen, durchdrehen, Ängste schüren oder gar Verschwörungstheorien > daraus konstruieren, ist leider auch normal und Teil des Programms im > Gehirn von Homo sapiens Diese Unterstellung ist mal wieder typisch. Kritik ist für Befürworter der Totalverblödung gleich Angst, Panik oder Verschwörungstheorie. Klar. Muss ja. Denn das eigene hysterisch technikgläubige Weltbild darf keinen Kratzer bekommen. Die Kritik von Menschen mit etwas mehr Lebenserfahrung an Menschen mit weniger Lebenserfahrung ist nun nichts neues, auch wenn das angebliche Zitat eines wahlweisen antiken Griechen (Plato, Sophokles oder wer auch immer) tatsächlich der Neuzeit entstammt und erst ab etwa der Mitte des letzten Jahrhunderts immer wieder falsch zitiert wird. Dennoch ist die im Moment zu beobachtende flächendeckende Totalverblödung etwas neues.
Gregor J. schrieb: > Gerhard O. schrieb: >> Aus meiner Sicht hätte man mit dem "Loslassen in die Welt" noch warten >> sollen, bis genug effektive Sicherheitsmaßnahmen erfunden worden sind, >> um "Informations-Terrorismus" in Schach zu halten. (...) >> GPT hat das Potenzial einer Informationsbombe. Abgesehen davon sprachen >> sich schon einige Industriegrößen gegen eine zu schnelle Verbreitung aus. > > Immer locker bleiben, denn auch damit wird die Population des Homo > sapiens im Kern schon fertig und es – der Wahrscheinlichkeit nach – sehr > gut überleben. Dass einige am Rande von solchen Dingen Panikattacken > bekommen, durchdrehen, Ängste schüren oder gar Verschwörungstheorien > daraus konstruieren, ist leider auch normal und Teil des Programms im > Gehirn von Homo sapiens – der Zahn der Zeit wird es schon glätten, dann > ist im Mittelwert alles wieder halbwegs normal, was auch immer unter > 'normal' in der jeweiligen Epoche verstanden werden kann, denn auch das > unterliegt einer ständigen Verformung wie das Kneten einer Knettmasse. > Die richtige, belebte AI atomar aufgebaut ist eh noch nicht auf der Erde > – sie wird in der Zukunft noch von jemandem geschrieben/gebaut, denn was > im Moment da ist, könnte man im Vergleich dazu nur als Spielereien von > Kindern bezeichnen – auch das sagt die Wahrscheinlichkeit voraus oder > die extrapolierte Vergangenheit, die als Zukunft in dieser Wirklichkeit > mit dem begrenzten Bewusstsein verstanden werden kann und von allen auch > so erlebt wird. Moin, Deine Argumente sind natürlich stichhaltig. Aber bedenke, in den USA stehen bald Wahlen an und viele Amerikaner sind dafür bekannt alles zu glauben was sie von der Glotze und Internetseiten ohne gesunde Kritik und Menschenverstand leichtgläubig einsaugen. Das kann, je nachdem wie man die augenblickliche Welt sieht, zu unglücklichen Wahlergebnissen führen, wenn man z.B. das Großmaul bevorzugt. Andere sehen das möglicherweise als die richtige Entscheidung. Es ist klar abzusehen, daß KI in allen ihren Inkarnationen als politische Waffe eingesetzt werden wird. Das kann zu empfindlichen Störungen der Demokratieideologie führen. Deep Fakes u.ä. sind schwierig zu erkennen und können viel Verwirrung stiften und zu ungesundes Mißverstehen führen. Ich bin der Meinung, daß öffentliche Informationen von professionellen Mitarbeitern begutachtet und moderiert sein sollen, anstatt einer wilden Meute von politischen Möchtegerns zu überlassen. Ich bin der Meinung, daß, so wie KI oft mißbraucht wird, die Fundamente unserer modernen globalen Gemeinschaft angegriffen werden. Man mag das sehen, wie man will, ich finde, daß trotz aller Unzulänglichkeiten unser globalen Institutionen, wie z.B die UNO, dieser Zustand besser ist, als die zu erwartenden Alternativen. Es ist traurig, daß Konventionen wie z.B. die Genfer Kriegsregeln total mißachtet werden. Aber genug von der Politik. Jedenfalls sollte man sich "Wie" des "Loslassen" der KI in die Allgemeinheit gut überlegen und sich im Klaren sein, inwieweit sie von kriminellen und politisch motivierten Bösewichten und deren Agendas mißbraucht werden wird. Es ist oft sehr schwierig Fälschungen zu erkennen und ist in der volatilen, unserer Gegenwart , vielleicht nicht unbedingt wünschenswert. Man mag mich für meine Vorbehalte kritisieren, finde aber trotzdem, daß Bedacht und Vorsicht keine schlechten Prinzipien in der Verbreitung von KI sind. Vorsicht und Vernunft hat noch nie jemand geschadet. Und Eile tut wirklich nicht not, damit leichtsinnig umzugehen. Die Welt gerät schließlich deswegen nicht aus ihren Fugen. Werden wir damit fertig werden? Wir müssen. Ganz gleich, welche Fehler Homo Sapiens machen wird. Wird es unnötige Nackenschläge geben? Bestimmt. Würde es schaden, aufzupassen und voraussehbare Fehler zu vermeiden? Das soll jeder Maßgebliche selber entscheiden. Seid Wachsam! Gerhard
:
Bearbeitet durch User
Gerhard O. schrieb: >> 2-Kanal Akkutester > Die Schalterstreifen auf der Oberseite gefallen mir. > Sehen sehr solide aus. Marquardt 80er Jahre, werden nicht mehr gefertigt. Dazu gibt es Bleche für 4, 8, 12 oder 16 Stück. Lochraster geht nicht, 19mm-Abstand. > An sich hätte man die > Kühlaggregate möglicherweise auch innen mit Lüfter unterbringen können. Design follows stock. Wie immer, habe ich geschaut, was ich im Regal habe und mit vorhandenem Material bauen kann. Gehäuse kaufen ist immer teuer und Lüfter mag ich nicht. Gerhard O. schrieb: >> TWI ist für kurze Strecken gedacht, z.B. ICs innerhalb der Leiterplatte >> eines Fernsehgerätes. .. > Naja. Ich steckte ein 4x20 LCD in ein klares Hammond Gehäuse hinein Wenn es Sinn macht, die abgesetzt zu betreiben. > und > verbinde es mit einem vier-adrigen 1.5m langen Telefonstrippe mit dem > uC. Es gab noch nie Probleme. Scheint ausreichend zu übertragen. Die flexiblen Telefonkabel sind weder geschirmt noch verdrillt, wird passen. Gerhard O. schrieb: >> Man sieht es ständig in anderen Threads: Da werden Projekte >> zusammenkopiert, anstatt sich stückweise heran zu arbeiten. > Ja. Ich mache das aber teilweise auch (Schäm). Du kopierst nicht irgendwas doof zusammen, sondern hast erprobte Klassen oder schaust sie vorher an. > Allerdings erarbeitete > ich mir über 25 J uC genug Wissen, um mir meist selber helfen zu können. > Abgesehen davon gab es das früher nicht. Ich fing mit PICs an und da gab > es damals nichts zum Abschreiben. Da mußte man sich auch zwangsweise > damit gründlich befassen. Bei mir war es 6504 in Assembler, dann 6502 auf selbst entworfener Europakarte und dann MC68HC805 - auch in Assembler. Habe ich keine Lust mehr drauf und bastele mit Arduino. Mein erstes A*-Projekt war die Lötstation mit Weller und 1602-I2C-Display. Ich habe ein paar Stunden gebraucht, die passende I2C-LCD-lib zu finden und das Display zu bedienen. Danach fällt es mir schwer, warum andere Leute das nicht auch eigenständig lösen können, falsche Erwartung und fehlende Ausdauer? Bevor ich das angegangen bin, habe ich einen China-Uno mit Tastern, Drehpoti, LEDs und Display zusammengelötet, erstmal Grundlagen ausgetestet. Gerhard O. schrieb: >> Ich dilettantiere seit einer Weile daran herum, DCF77 zuverlässig zu >> decodieren. Eine fertige .lib will ich nicht einsetzen, weil ich deren >> Art der Signalerkennung nicht sinnvoll finde. Da werde ich noch viele >> Stunden dran sitzen > Macht ja auch mehr Spaß, sich eigene Lösungen zu erarbeiten. Speziell, > wenn es um klar dokumentierte umrissene Standards wie DCF geht. Ich > würde es übrigens mit ISR over-sampling machen und dann mit Auf- und > Ab-Zählern de-glitchen. Meine Uhr von ca. 1990 (6502-ASM) pollt das Signal und ist damit ziemlich robust gegen Gewitter. In meinem Arduino-Aufbau läuft ein Interrupttimer mit 5ms und zählt zwei Variablen hoch, Port high / Port low. Low (100ms) gibt dann ca. 20 und high (200ms) etwa 40, das Empfängermodul liefert gemessene 120 / 220 ms. War ich vorhin wieder 2 Stunden dran, ich bin auf dem richtigen Weg, habe aber noch 10..20% Fehlerkennungen. Gerhard O. schrieb: >> Ich werde auch nicht auf µC-net fragen. Das ist wieder eines dieser >> Probleme, wo die Lösung über mir schwebt, ich sie aber noch nicht >> greifen kann. Eine Weile nichts tun, wird sie mir irgendwann auf den >> Teller fallen, während das Frühstücksei im Kocher steckt. > Ja. Geht mir manchmal auch so. Macht aber mehr Spass die verschiedensten > Möglichkeiten durchzugehen. Es fehlt der Kollege aus dem Prüfmittelbau, wo wir unsere Probleme miteinander diskutieren konnten. Peter D. schrieb: > Eine fertige .lib will ich nicht einsetzen, weil ich deren >> Art der Signalerkennung nicht sinnvoll finde. > Was gefällt Dir denn daran nicht? > Hier mal ein schon recht alter Code: > Beitrag "DCF77 Uhr in C mit ATtiny26" > Da sind auch ne Menge Fragen und Erläuterungen mit bei. Die von mir gefundenen Arduino-libs lösen bei Pegelwechsel am Port einen Interrupt aus, gefällt mir nicht. Deinen habe ich nicht angeschaut.
Manfred P. schrieb: > Deinen habe ich nicht angeschaut. PeDas Code ansehen könnte aber nützlich sein, er schreibt wirklich schlanken und nützlichen Code obwohl der Code nicht immer sofort leicht zu verstehen ist, hält aber die grauen Zellen in Bewegung. Manfred P. schrieb: > In meinem Arduino-Aufbau läuft ein > Interrupttimer mit 5ms und zählt zwei Variablen hoch, Port high / Port > low. Low (100ms) gibt dann ca. 20 und high (200ms) etwa 40, das > Empfängermodul liefert gemessene 120 / 220 ms. War ich vorhin wieder 2 > Stunden dran, ich bin auf dem richtigen Weg, habe aber noch 10..20% > Fehlerkennungen. so mache ich das auch aber werte in PeDas Subroutine in C on the fly aus.
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.