Beiträge von KaiR

    Hallo Pius,


    ich werde wahrscheinlich erst am kommenden Wochenende deine Vorschläge mal genauer anzuschauen und drüber nachzudenken. Aber Deine Frage kann ich jetzt schon beantworten.


    SAVE_PORTB und SAVE_PORTD am Anfang des Programms sind (Sicherungs)kopien von PORTB und PORTD. Sie sind global, damit ich sie nicht an (eine) Funktion(en) gesondert übergeben muss.


    Die Bitmanipulationen erfolgen in der 16 Bit Variable "value" in der Loop-Schleife. Ich habe das bewusst so gewählt, weil ich so keine zwei Variablen/Register mit Bedingungen bearbeiten muss (if wert > 64 oder ähnliches) , sondern alles in einer Variable in den zwei FOR-Schleifen erledigen kann. Wenn ich statt sieben vielleicht mal neun LEDs anschließen möchte, brauche ich nur die Grenzen der Laufvariable ändern, sonst nichts.


    In der Funktion set_ports() werden die 16 Bit in zwei 8 Bit Werte aufgeteilt, damit ich die beiden 8 Bit Register beschreiben kann. Das geschieht dadurch, dass der SAVE_PORTX (also die Kopie und nicht das "Original) mit der passenden 8Bit Variante "geodert" wird und dieses Ergebnis PORTX zugewiesen wird. So habe ich alles in einem Rutsch gemacht ohne Bits, die nichts mit meinen LEDs zu tun haben zu verändern. Ich muss also nicht 7 Bits einzeln setzen.


    Natürlich ginge das in die Hose, wenn ich z.b. alle 16 Bit der "value" Variable verändern würde. Dann brächte die "Sicherung" nichts. Darum ist das nicht so ganz ausgegoren. Das war nur ein erster Ansatz, wie ich mit möglichst wenig Aufwand, in einem Rutsch nur die Bits in den Registern manipuliere, welche gerade relevant sind,ohne andere "unbeteiligte" zu verändern. Z.B. wenn D0 und D1 auch noch für einen anderen Zweck genutzt würden.


    Das "Auseinandernehmen" der 16 Bit Variable funktioniert auch mit einer etwas verständlicheren und deshalb wahrscheinlich auch besseren (weil Programmiererfreundlicheren) Variante. Satt der Dereferenzierung und dem Cast geht es auch wie folgt:

    Code
    1. new_portb = bits_set >> 8; // high byte of bits_set
    2. new_portd = bits_set & 0x00FF; // low byte of bits_set (Obere 8 Bit werden gelöscht nur die Low Byte Bits bleiben über)

    Die Erste und diese Variante funktionieren natürlich nur auf Systemen, die im Little Endian Format arbeiten. Ich nehme an, das trifft auf alle gängigen Amtels zu.


    Wie gesagt, es waren meine ersten Versuche mit Registern und evtl. ist das, was ich mir da ausgedacht habe, aus verschiedenen Gründen gar nicht zweckmäßig. Aber funktioniert hat es.


    Du hast in Deinem letzten Kommentar geschrieben, das funktioniert in der Amtel Umgebung nicht, weil PORTB keinen "const " Wert darstellt. Das verstehe ich gerade auch nicht so ganz. Const Werte können doch nach ihrer Initialisierung nicht mehr verändert werden. Aber Register Variablen müssen doch verändert werden können?!


    Gruß Kai

    @PIUS: Danke für Deine Anmerkungen und die Zeit die Du dafür investiert hast. Nun muss ich mir die mal in Ruhe zu Gemüte führen, einiges verstehe ich momentan nämlich nicht. Für heute ist aber mein Kopf leer ;)


    itoa ist nen guter tip.. nur leider werden auch da führende Nullen bei der (Binär)Ausgabe weggelassen. Das soll aber nicht. Müsste ich dann wieder was zusammenbasteln ... da scheint mir meine "Hilfsroutine" auf den ersten Blick einfacher.


    Was meinen Satz "Im Vordergrund stand, möglichst ohne zusätzliche Bibliotheksfunktionen auszukommen." betrifft: Natürlich geht es nicht darum keine zu benutzen, das ist nur auf diese "Übung" bezogen. Man muss sich das Leben ja nicht unnötig schwer machen und in der Regel dürften Bibliotheken besseres bieten als man selber zusammenstuppeln kann.


    Was ich gar nicht begreife ist Dein Kommentar:

    // PI-> PORTx ist bereits ein Register

    PORTD = (SAVE_PORTD | new_portd);
    PORTB = (SAVE_PORTB | new_portb);


    Das ist genau die Stelle, welche die LEDs zur richtigen Zeit, am richtigen Platz zum Leuchten bringt, indem die Bits gesetzt oder gelöscht werden.



    Gruß Kai

    @Pius:

    in loop() wird in den Schleifen ein (unsigned)16 Bit Wert genutzt um ein Bit zu "rotieren". In set_ports() wird dieser 16 Bit Wert in zwei (unsigned)8 Bitwerte

    auseinander gebröselt. Diese beiden Werte werden zum Setzen der zwei Register PORTB und PORTD genutzt. Das siehst Du also richtig.


    Arduino-Nano-Pinout.jpg


    In dem PIN Layout sieht man gut, wie die beiden Register zusammen hängen (linke Bildseite).


    Die LEDs hängen an D2 bis D8 ... ich habe in den Kommentaren im Quellcode versucht, das zu verdeutlichen. D2 bis D7 entsprechen den Registern PD2 bis PD7. Die siebte LED an D8 wird über PB0 angesteuert... also einem weiteren Ausgaberegister des Arduino.


    Ich könnte noch die Ausgänge D9-D12 (PB1-PB5) ebenfalls mit LEDs bestücken. Dann müssten lediglich die Laufvariablen in den beiden Schleifen in loop() angepasst werden.


    Die Hilfsfunktion print_byte_as_bits(uint8_t val) gibt den Inhalt eines Bytes binär aus. Ich nutze das so, dass bei der Debugausgabe alle Bits der beiden Register ausgegeben werden. Dadurch sieht man, ob die Software richtig arbeitet, auch wenn gar keine LEDs angeschlossen sind. Man kann sich das Bitmuster jeden Schleifendurchaufes anschauen. Das sieht dann so aus:


    Man sieht quasi das Hin- und Herlauf des LED Lichtes. Mit der Anzahl der LEDs hat das allerdings nur bedingt etwas zu tun. Eher mit den möglichen Bits in den beiden Registern. Es würden also auch gesetzte Bits angezeigt, die mit den LEDs nichts zu tun haben. Der Code ist so gebaut, dass Bits, die nichts mit dem Lauflicht zu tun haben, nicht angetastet werden. Dafür sorgen die beiden globalen SAVE_PORT Variablen, die eine Ursprungskopie der Register enthalten, bevor sie durch mein Programm manipuliert werden.


    @René: Die Videos kenne ich leider nicht. Ich hatte jedoch Hilfe durch das Buch "AVR-Mikrocontroller - Programmierung in C" von Heimo Gaicher. Ohne das, hätte ich das mit dem AD-Wandler wohl nicht hinbekommen, auch wenn alles im Prinzip auch im Atmega328 Datasheet steht. Ich musste lediglich manche Werte an die Hardware anpassen. Aber es ist halt "learning by doing".

    Nur lesen reicht nicht. Man muss es machen. So etwas hast Du ja auch dem Hans64 geschrieben.... Ich finde Du hast recht :-).

    Ich habe in meinem Leben (auch beruflich) zwar schon so einiges programmiert. Aber diese Bit-Schieberei war da eher selten, weil nicht notwendig.

    Die "Denke" muss man sich erst mal wieder "draufschaffen".


    Gruß Kai

    Hallo zusammen,


    ich habe René's Arduino Aufgabe aus Lektion 9 auch mal gelöst. Allerdings ziemlich "low level", weil mich die direkte Programmierung der Register des AVR Controllers interessiert hat. Also ist das nicht gerade Einsteigerstoff. Dennoch habe ich mir gedacht, meine ersten Schritte ich diese Richtung hier zu veröffentlichen, weil das evtl. für den einen oder anderen von Euch hier im Forum dennoch interessant ist.


    Im Vordergrund stand, möglichst ohne zusätzliche Bibliotheksfunktionen auszukommen. Das Lauflicht erfordert die Programmierung min. eines Ausgangsregisters. Für das Einlesen des Spannungswertes am Potentiometer ist die Programmierung des AD-Wandlers notwendig. Letzteres erwies sich als die größere Herausforderung und erforderte etwas Fachliteratur. Umgesetzt habe ich die Aufgabe mit einem Arduino Nano Clone (hab keinen UNO).


    Lauflicht_photo1.jpg



    Weil ich sieben LEDs ansteuern wollte (Pin D2 - PIN D8) ergab sich eine (für mich) kniffelige Besonderheit. Das Ausgaberegister PORTD steuert die PINS D2-D7. Für die siebte LED, also Port D8, muss zusätzlich das Ausgaberegister PORTB benutzt werden. Nun wollte ich das Programm so klein wie möglich entwickeln und deshalb sollten auch aufwändige "if then" Konstrukte oder ähnliches vermieden werden.


    Ich habe es über einen direkten Zugriff auf den Speicherbereich gelöst. Am Ende braucht das Programm gerade mal 992 Bytes im Flash und 13Bytes im RAM.


    Lauflicht-scrs1.png


    Evtl. hat ja auch jemand von Euch noch Verbesserungsvorschläge oder Hinweise was man besser machen kann oder besser nicht machen sollte.


    Der Quellcode:



    Wie gesagt, das mit der Microcontroller-Programmierung, in der Tiefe wie ich das heute betrieben habe, ist auch für mich relativ neu.

    Darum bin ich für Hinweise dankbar aber auch für Fragen offen :-).


    Ich habe die Quellcodedatei auch angehangen. Wer sie in der Arduino IDE Compilieren möchte, muss die Endung "*.CPP" wieder in "*.INO" umgenennen.


    Gruß Kai

    Dateien

    • lauflicht.zip

      (1,76 kB, 1 Mal heruntergeladen, zuletzt: )

    Wenn man ein Terminalprogramm, wie z.B. das von René erwähnte Putty nutzt, kann auch die serielle Ausgabe beeinflusst werden.


    Es gibt z.B. über die Bibilotheksverwaltung die Möglichkeit die vt100 Bibliothek nachzuladen und dafür zu nutzen (über den Link "More info" kommt man auch zum Beispielcode). Wer es etwas funktionsreicher mag, kann auch die Bibliothek mcurses nutzen. Sie ist von der ncurses Bibliothek (Unix und (hardcore) ;)Linuxnutzern dürfte sie ein Begriff sein) abgeleitet und auf geringen Speicherplatzverbrauch optimiert (1,9Kb).


    Ich habe mal einen Beispielcode ausprobiert. Das sieht dann so aus:

    Terminal.JPG


    Der Screenshot zeigt nur eine Momentaufnahme. Es ist in Wirklichkeit eine Animation.


    Diese mcurses Bibliothek gibt es leider nicht über die Bibliotheksverwaltung. Sie muss händisch in das Arduino libraries Verzeichnis kopiert werden.

    Das ZIP-File: mcurses.zip


    Mehr Informationen es auf mikrocontroller.net in einem Artikel.


    Wichtig ist, genau wie bei der seriellen Konsole von der Arduino IDE, auf die korrekte Baudrateneinstellung von putty zu achten. Die ist standardmäßig auf 9600 Baud eingestellt.

    Diese mcurses Bibliothek ermöglicht die Programmierung eine Userinterfaces. Sie kann also nicht nur ausgeben, sondern auch Eingaben entgegennehmen.


    Die Ausgabe eines carriage return (char(13)) auf der Arduino Konsole funktioniert leider nicht. Der Serial.print Befehl gibt trotzdem alles aneinander gereiht aus.


    Gruß Kai

    Es kommt evtl. auch darauf an, wie dein WLAN-Router konfiguriert ist.

    Ist evtl. eine MAC-Sperre angeschaltet? Also, dass das Wlan Interface des ESP erst für den WLAN Router zugelassen werden muss?


    Läuft der DHCP-Dienst, damit der ESP überhaupt eine IP Adresse bekommt oder wird sie im Programm fest vorgegeben?


    Das wären mal so zwei Dinge, die mir unabhängig vom Programm auf anhieb einfallen.

    Hallo Jürgen,


    ich hatte seinerzeit, als ich untenstehenden Beitrag schrieb, den ESP über die USB Schnittstelle meines Laptops mit Strom versorgt und versucht das Display am 5V Ausgang des NodeMCU Boards zu betreiben. Das hat nicht funktioniert.

    Ich bin der Sache aber nicht auf den Grund gegangen. Vielleicht war einfach der Gesamtverbrauch für die Schnittstelle zu groß.


    Ob dieses Heltec Board so einen 5V Ausgang hat, weiß ich nicht. Laut Datenblatt des ESP (5.2 Recommended Operating Conditions) sind max. 40mA (High level souce current) und max. 28mA (Low level sink current) bei 3,3V möglich.


    ESP Datenblatt

    ESP32 Pinout Reference


    Was das Bild in meinem Beitrag betrifft, 3,3V und GND sind über Steckbrücken (nicht sichtbar) unter dem NodeMCU-Board in die Mitte des Breadboards geführt. Die Spannung und GND wird über die, im Bild sichtbaren, Drahtbrücken am Levelkonverter wieder abgegriffen.


    Gruß Kai

    Hallo Jürgen,


    gern geschehen. Ich habe nur meine eigenen Neugier befriedigt ;-).


    Statt eines Levelkonverters, habe ich gerade einen einfachen Spannungsteiler aus zwei Widerständen (pro Leitung) ausprobiert. Das haut nicht hin.


    Gruß Kai

    Hallo Jürgen,


    die Sache mit dem LCD ist ziemlich einfach. Lade die Dateien esp8266_i2c_lcd.py (nicht vom Dateinamen irritieren lassen, der Code funktioniert auch auf dem ESP32) und lcd_api.py auf den ESP. Ich habe es mal mit den PINs 21 (SDA) und 22 (SCL) probiert. Im Quellcode müssen die Pins eingegeben werden. Ein Beispiel:


    Da ich kein 2x16er Display habe, musste ich ein 4x20 Display benutzen. Aber das macht im Prinzip keinen Unterschied. Bei einem 2x16 LCD muss der Befehl lcd = I2cLcd(i2c, DEFAULT_I2C_ADDR, 4, 20) in lcd = I2cLcd(i2c, DEFAULT_I2C_ADDR, 2, 16) geändert werden. Je nachdem was man für ein Backpack auf dem Display hat, unterscheidet sich die I2C Adresse. Oft ist sie 0x27, in meinem Fall ist sie 0x3F. Das ist wichtig für die Definition "DEFAULT_I2C_ADDR", welche auch in dem vorgenannten Befehl benutzt wird.


    Mit dem Aufruf der Methode lcd.move() wird die Cursorpostition bestimmt. Der erste Wert ist die Zeichenposition in der Zeile. Der zweite Wert gibt die Zeile an. Es wird bei 0 angefangen zu zählen. Die Methode lcd.putstr() gibt einen gegebenen Textstring, an der vorher gesetzten Cursorposition aus.


    Es gibt noch einige Befehle mehr, die kann man sich in den Beispielcodes auf der von René angegebenen Seite anschauen, bzw. dem dort angegebenen Link auf Github LCP Micropython Code.


    Ich habe die zwei notwendigen Systemdateien und die Testdatei hier angehangen: ESP32-Micropython-LCD.zip


    Hier ein Bild vom Aufbau:

    ESP32-LCD.jpg


    Das kleine blaue Teil links im Hintergrund ist ein Levelconverter. Hier wird die 5V Spannung vom LCD Display auf 3,3V (und umgekehrt) geregelt, damit man sich nicht den ESP zerstört. Ein Spannungsteiler (z.b. 4,7kΩ zu 9,1kΩ oder ähnlich) könnte auch klappen, habe ich aber noch nicht ausprobiert. Das LCD hat auch eine eigene Stromversorgung (es braucht um die 35-40mA). Der 5V Ausgang vom ESP bringt das nicht. Das kleinere 2x16er Display wird weniger brauchen. Wie viel genau, kann ich nicht sagen, weil ich keins habe um das nachzumessen. Es kommt auch etwas darauf an, wie hell man das Backlight einstellt. Evtl. ist der Verbrauch gering genug, dass der ESP das noch schafft.


    So ... falls Du dein LCD Display doch noch benutzen willst, hast Du jetzt eigentlich alles was Du dafür brauchst.


    Gruß Kai


    PS: Wer das fehlende „a“ findet, darf es behalten ;-).

    ardu :


    Ich habe es heute mal ausprobiert. Es funktioniert durchaus ein ESP32-NodeMCU Board mit einem 0,96 OLED Display. Wie René bereits geschrieben hat, müssen die PIN Angaben im Programmcode angepasst werden.


    Link auf PIN-Layout fuer ESP32-DevKit Board


    Ausgehend vom Code aus dem Übungsbeispiel "oled_demo.py" aus Lektion 5 müssen lediglich die Angaben für SDA und SCL auf Pin 22(SDA) und PIN 23(SCL) geändert werden.

    Der Abschnitt für die Aktivierung des Moduls wird gar nicht benötigt.


    Alles andere kann unverändert bleiben.



    ESP32-069OLED.jpg


    Die Stromversorgung des Displays erfolgt im vorliegenden Beispiel über der 3,3V und den GND Pin des Boards.


    Gruß Kai

    Ich habe ja vor kurzem das Funksensor-Projekt vorgestellt. Weil der Zugriff auf die Daten nur per Webbrowser möglich ist, wollte ich noch ein "klassisches" Anzeigegerät bauen. Dieses sollte möglichst mit Batterie oder Akku betrieben werden, um es portabel gestalten zu können. Portabel heißt kabellos, was eine Funkverbindung zum Server erfordert, um aktuelle Daten abrufen zu können.


    Auf der Suche nach einer Lösung bin, ich über den ESP8266 gestolpert. Dieser µController schien gut geeignet, weil er WLAN Zugriff ermöglicht, billig zu haben und auch sehr weit verbreitet ist. Um einen Datenaustausch zu ermöglichen, habe ich mich dazu entschieden das MQTT Protokoll zu nutzen. Es ist recht einfach und im Internet sind viele Informationen dazu zu finden.


    Da es für die Pimatic-Software, welche ich einsetze, um Sensordaten zu verarbeiten auch ein MQTT Plugin gibt, habe ich auf dem Raspberry Pi den MQTT Broker Mosquitto installiert und eingerichtet.


    Zur Kontrolle, ob der MQTT -Broker wie gewünscht funktioniert, ist das Programm MQTT.fx (MQTT Client) sehr hilfreich. Dieses Programm gibt es für Windows, macOS und auch für Linux. Damit kann recht komfortabel kontrolliert werden, ob eine Verbindung zum Broker möglich ist und ob die Daten wie gewünscht zur Verfügung gestellt werden.


    Auf dem ESP8266 habe ich einen entsprechenden Client programmiert. Orientiert habe ich mich dabei an folgender Seite:


    Verschlüsselter MQTT Transport


    Der Gedanke war, eine Verschlüsselung vorzusehen, falls mal Daten über öffentliche Netze ausgetauscht werden. Natürlich war auch Neugier dabei, ob und wie das Ganze funktioniert. Allerdings, um es vorwegzunehmen, es funktioniert gut, kostet jedoch Rechenpower und macht den Programmablauf auf einem ESP8266 merklich langsamer. Darum habe ich das wieder abgeschaltet (auskommentiert), weil nicht über das Internet, sondern nur im internen Netz kommuniziert wird.


    Zuerst habe ich zur Anzeige der Daten ein LCD Display (HD44780 2004 - 4x20) benutzt. Es war angedacht, dass das System per Knopfdruck startet, die Daten für etwa 2Min. anzeigt und sich anschließend wieder deaktiviert. Es hat sich jedoch herausgestellt, dass das nicht effizient genug für den gewünschten, dauerhaften Batteriebetrieb ist.


    Außerdem hatte das verwendete Entwicklerboard (NodeMCU) ein Manko. Normalerweise verbraucht der ESP8266 um die 20µA im DeepSleep-Mode. Diese NodeMCU Entwicklerboards verbrauchen aber um die 26mA. Das ist viel zu viel. Also musste der µController ohne Entwicklerboard eingesetzt werden. Hier hat mir der Artikel auf folgender Seite geholfen:


    ESP8266 Einführung und Platine


    Die dort vorgestellte Platine kann für 2,90€ in deren Platinenshop bezogen werden. Allerdings muss man sich die Komponenten noch besorgen und SMD löten. Dieses Board kommt einem Entwicklerboard sehr nahe, benötigt aber wegen des eingesetzten Spannungswandlers (MCP1700-3302E) nur sehr wenig Ruhestrom. Zum Programmieren braucht man zusätzlich einen FTDI-Adapter.


    02-epaper.jpg

    ESP8266 Platine (oben)


    03-epaper.jpg

    ESP8266 Platine (unten)


    Weil mir die LCD Lösung nicht gefallen hat, habe ich weitergesucht und bin über sog. ePaperdisplays gestolpert. Diese Technik fand ich interessant für das Projekt, weil diese Displays sehr stromsparend sind und ihre Darstellung auch im ausgeschalteten Zustand behalten. Meine ersten Versuche habe ich mit einem Display gemacht, das einen eingebauten SPI Controller und Levelkonverter hat. Hierbei gab es jedoch Probleme mit der Schaltung und auch mit dem Stromverbrauch. Eine Antwort auf meine Frage im Arduinoforum brachte etwas Klarheit, warum es diese Probleme gab:


    Problem mit 3.3V ESP und ePaperdisplay


    04-epaper.jpg

    DESPI-C02 ePaper Connectorboard für RAW-Displays


    Es sollte also ein "Bare" Display mit einem Connectorboard (ohne Levelkonverter) verwendet werden. Diese DESPI-C02 Connectorboards scheint es aber nur in China zu geben, also habe ich mir eins über Aliexpress besorgt und an das vorhandene Display angeschlossen, indem ich den Displayanschluss vom vorhandenen Controller abgeklemmt und mit dem DESPI-C02 verbunden habe.


    01-epaper.jpg


    In dieser Kombination funktioniert der Aufbau sehr gut. Der µController holt alle 5 Minuten Daten vom MQTT Broker, stellt sie auf dem Display dar und geht dann (inkl. Display) in den DeepSleep-Mode. Die auf dem ePaperdisplay angezeigten Daten bleiben, wie schon erwähnt, auch nach dem Ausschalten erhalten. Ein großer Vorteil dieser Technik.


    Als Nachteil der ePaper-Displays kann angeführt werden, dass sie sehr langsam sind. Außerdem sind sie nicht beleuchtet. Im Dunkeln sieht man deshalb nichts.


    Nun fehlt noch ein vernünftiges Gehäuse (sollte jemand Tipps für den Gehäusebau haben, die werden gerne entgegengenommen :-) ), außerdem kann die etwas spröde Anzeige noch etwas verschönert werden.


    Der Quellcode: MQTT-ePaper.zip.


    Damit sich alles compilieren lässt, ist es notwendig das Verzeichnis MqttData in den "libraries" Ordner der Arduino IDE zu kopieren. Außerdem wird benötigt:


    Der URL "http://arduino.esp8266.com/stable/package_esp8266com_index.json" muss im Feld "zusätzliche Bordverwalter URLs" bei den Voreinstellungen eingetragen werden.


    Außerdem müssen die Module:

    PubSubClient (Nock O'Leary Version 2.70)

    GxEPD2 (Jean-Marc-Zingg Version 1.2.3)


    mit Hilfe der Bibliotheksverwaltung (Werkzeuge/Bibliotheken verwalten) nachinstalliert werden.


    Das war's erstmal. Guten Rutsch ins Jahr 2020 wünsche ich.

    Vielleicht machst du die Variable nicht global, sondern fügst an die Funktion zeige_zeit() die Befehlszeile return zeit an.

    Code
    1. def zeige_zeit():
    2. #print(time.localtime())
    3. #time.localtime:YYYY, MM, DD, HH, MM, SS, day of week (0=Mon), day of year
    4. zeit = time.localtime()
    5. sekunden = time.mktime(zeit) + 3600
    6. zeit = time.localtime(sekunden)
    7. print(zeit)
    8. return zeit


    Dann kannst Du den Befehl text_line(str(time.localtime()[3]),5,1)#Std in text_line(str(zeige_zeit()[3]),5,1)#Std ändern ;).


    Nur so als "quick hack" (schön ist anders). Wenn ich den Quelltext (auf die schnelle) richtig verstehe, ist die Funktion zeige_zeit() nur dazu da, um die Zeit auf der Konsole auszugeben aber nicht auf dem OLED Display.


    Gruß Kai

    Hallo Brocki,


    René hat es im Prinzip ja schon beantwortet. Ich möchte nur mehr darauf eingehen warum die Fehlermeldung "zeit ist nicht definiert" erscheint.


    Wenn Du in dem an diesen Post angehangenen Code nur die Zeile "text_line(str(time.localtime()[3]),5,1)#Std" in der Funktion anzeigen() geändert hast, muss die genannte Fehlermeldung zwangsläufig kommen, weil die Variable "zeit" nur in der Funktion zeige_zeit() definiert ist. Es ist keine globale Variable und deshalb in der Funktion anzeigen() nicht bekannt.


    Gruß Kai

    Hallo Schlaeppi,


    normalerweise kannst Du die Sprache umstellen wenn du in das Menü „File-> Preferences“

    gehst und dort die „Editor language“ auf Deutsch oder „System default“ einstellst.


    Gruß Kai

    Ich möchte einmal auf folgendes Projekt aufmerksam machen:


    DIY Funkwetterstation mit DHT22, ATtiny85 und Radiohead


    Dieses Projekt stammt nicht von mir. Ich habe es lediglich nachgebaut. Ich hatte einige Jahre ein Außenthermometer, das mir die Temperatur an eine kleine simple Basisstation gesendet hat. Nachdem die Technik aber ihren Geist aufgegeben hat, wollte ich mir erst ein neues kaufen. Allerdings dachte ich mir, es wäre vielleicht schöner, so etwas einmal selber zu basteln.

    Bei der Recherche im Internet, wie man so etwas umsetzen könnte, bin ich über oben genannten Link gestolpert. Das war mein Einstieg in die Welt der Mikrocontroller.


    Letztendlich sind drei Komponenten miteinander zu verbinden:


    1. Die unter dem oben eingestellten Link beschriebene Schaltung des Funksensors.

    2. Ein Arduino Nano, der als Empänger und serielles Gateway dient.

    3. Ein Raspberry Pi, an dem der Arduino Nano per USB angeschlossen ist und die Daten mit Hilfe der Software Pimatic verarbeitet und in einem Webbrowser abrufbar gemacht werden.


    An dem Raspberry Pi ist noch ein BME280 Modul angeschlossen, welches mir neben (Innen-)Temperatur und Luftfeuchte auch Luftdruckdaten zur Verfügung stellt.


    Es handelt sich um ein rel. kleines Projekt, welches dennoch ein recht breites Feld an Technikkomponenten verbindet.


    Da für die Software auf dem ATtiny kaum Platz ist, kann er nur ohne Bootloader programmiert werden (was wieder ein gutes KByte spart). Hier muss man sich also mit der ISP Programmierung befassen. Auch hierzu hat der oben verlinkte Autor einen Artikel verfasst:


    Arduino als ISP Programmer

    ATtiny Mikrocontroller mit der Arduino IDE programmieren


    Man muss sich also nicht unbedingt einen Programmer für AVR Chips kaufen.


    Ein PCB für den Funksensor habe ich auch entworfen und so meine ersten Gehversuche bei der Erstellung von PCBs gemacht:

    Platine bei Aisler


    Was mir anfänglich am meisten Schwierigkeiten bereitet hat, war der Empfang der Daten mit dem 433 Mhz Modul.

    Hier werden vielfach Sender/Empfänger vom Typ XY-FST Sender + XY-MK-5V Empfänger angeboten. Die Sender sind voll in Ordnung aber die Empfänger sind absoluter Schrott.


    Erst nachdem ich auf einen Empfänger vom Typ RXB6 umgestiegen bin, hatte ich auf über 40m, auch durch die Hauswand, keine Empfangsprobleme mehr. Ein einfacher 17,3 cm langer Draht als Antenne ist ausreichend. Mit erstgenanntem Empfänger war nach drei bis vier Metern schon Schluss. Weil ich aber ein Außenthermometer haben wollte, ging das natürlich gar nicht.


    Das Projekt ist zwar nicht auf meinem Mist gewachsen, ich habe es lediglich nachgebaut, allerdings wollte ich es einmal vorstellen, weil man hierbei viel lernen kann. Möglicherweise ist es aber auch für fortgeschrittene Hobbyelektroniker interessant.

    Hier ein paar Bilder


    Ich habe die Stromversorgung des Außen- und eines Innensensors noch um eine Solarzelle ergänzt, was auch gut funktioniert. Das machte aber den Umstieg auf LiPo-Akkus notwendig, weil es dafür einfache Laderegler gibt. Das ist bei NiMh Akkus nicht so einfach.


    Am Ende habe ich also mein Außenthermometer bekommen. Was ich dafür so alles ausgegeben habe (ich hatte weder Lötkolben noch Ahnung *g*), dafür hätte ich mir sehr viele Außenthermometer kaufen können. Aber das hätte nicht annähernd so viel Spaß gemacht. Vom umfangreichen Erkenntnisgewinn mal ganz abgesehen.


    Gruß Kai

    Mal zurückgefragt:

    Wenn Du dein Programm ohne die LED Matrix benutzt, dann sind die Werte in Ordnung (serial output) ?

    Wenn du Versuchst die Matrix in Betrieb zu nehmen werden die Werte falsch (auch serial output)?


    Dann könnte man vermuten, dass es ein Problem mit der Stromversorgung gibt (Spannung/Strom) und deshalb die Werte des HX711 verfälscht werden.


    Was ist es denn für eine Matrix und wie hast Du sie angeschlossen? Je nachdem was es für eine ist, braucht sie vielleicht zu viel Strom für die LEDs.

    Bei der Definition von const "Variablen" hat mal halt eine Typprüfung beim Compilervorgang. Bei #define ist der Typ von Konstanten nicht definiert.


    Von daher zitiere ich mal aus dem Buch "AVR-Microcontroller - Programmieren in C" von Heimo Gaicher:

    Zitat

    Die Variante Konstanten mit const zu definieren ist also immer vorzuziehen, da sie eine sichere Variante ist und auch die Compilergeschwindigkeit erhöht

    Das mit der Compilergeschwindigkeit glaube ich jetzt einfach mal so.


    Gruß Kai