Hier ist ein Programm zum testen von DS18B20-Temperatur-Sensoren.
Die Ausgabe erfolgt über den seriellen Port und über ein I2C-LCD (optional).
Die DS18B20-Class habe ich selbst geschrieben, weil ich möglichst viel Speicher sparen wollte. Diese Klasse kann man ganz gut in eigene Projekte einbauen.
Wie gesagt, sie ist klein und lässt sich einfach abfragen. Die Temperatur wird asynchron eingelesen, wodurch man währenddessen andere Funktionen ausführen kann.
Das eigentliche einlesen geschieht dann innerhalb von 17-18 ms. Die übliche Konvertierungszeit kann man anderweitig nutzen.
Ich habe das Programm ausführlich kommentiert, sodass die Funktionsweise der Klasse hoffentlich verständlich wird.

Hier mal ein "Fritzing-Schaltplan":
   

Das Programm und die Klassen-Dateien (.cpp und .h) befinden sich im ZIP-Archiv (Anhang).

Angehängte Dateien

  DS18B20-Tester.zip (Größe: 189,7 KB / Downloads: 2)

Ich habe gerade mein neuestes Projekt fertiggestellt. Es handelt sich dabei um ein Backofen-Thermometer. Ich möchte es hier mal vorstellen.
Dabei habe ich folgendes eingesetzt:
- einen Arduino Nano (ok, einen China-Clone)
- eine RTC (DS3231)
- ein 16x2 LCD mit I2C-Backpack
- ein MAX6675 mit K-Thermoelement (0...800 Grad C.)
- ein Battery Shield für einen 18650 Li-Ionen-Akku (inkl. Lade-/Entladeschaltung und 5V-Ausgang)
- einen Dreh-Enkoder mit Taster (beim runterdrücken)
- einen aktiven Buzzer (so einen kleinen Piepser)
- und einen Schalter (zum ein-/ausschalten)
Zusammengebaut sieht es so aus:
   

Schaltplan:
   

Zitat: schrieb:Der Sketch verwendet 11058 Bytes (35%) des Programmspeicherplatzes. Globale Variablen verwenden 400 Bytes (19%) des dynamischen Speichers.

Angehängte Dateien

  Backofen_Thermometer.zip (Größe: 4,71 KB / Downloads: 1)

Da ich in meinen Projekten oftmals einen oder mehrere Taster verwende und ich zum entprellen nicht gleich eine "riesige" Library einbinden will, habe ich mal eine kleine PushButton-Klasse geschrieben. Die verbraucht nur wenig Speicher und hat doch alles, was ich so brauche (inkl. konfigurierbarer Tastenwiederholung).
Diese Klasse verwendet keine Interrupts!
Der Tastenzustand wird jedes Mal bei "Btn.pressed()" ausgelesen, was bedeutet, dass die Methode jedes Mal in der Loop-Funktion aufgerufen werden muss.
Und die Loop-Funktion darf nicht blockierend programmiert sein (was sich sowieso von selbst verstehen sollte). Delays unbedingt vermeiden!

Angehängte Dateien

  My_PushButton_Class.zip (Größe: 2,33 KB / Downloads: 3)

Um den Anfang der Jahreszeiten genau berechnen zu können, muss man schon einen 32-Bit-Mikroprozessor nehmen. Also einen ESP8266 zum Beispiel.
Ein 8-Bit ATmega (z.B. Arduino UNO oder Nano) würde ein "falsches" Ergebnis liefern. Die Ungenauigkeit liegt dort bei bis zu 12 Stunden.

Mit einem ESP8266 funktioniert das Programm aber recht genau (Abweichung liegt bei +-1 Minute).
Ich habe das Programm auf Mitteleuropäische Zeit konfiguriert. Die Sommerzeit wird automatisch addiert. Es wird keine zusätzliche Bibliothek benötigt.
Vielleicht könnt ihr so ein Programm ja gebrauchen...

Angehängte Dateien

  CalcSeason.zip (Größe: 2,92 KB / Downloads: 7)

Hier ein kleines Beispiel, wie man einen aktiven Buzzer per Timer-Interrupt ansteuern kann.
Das hat den Vorteil, dass man keine Delays und Schleifen benutzen muss. Man gibt einfach z.B. "Beep(3, 500, 200);" ein und schon werden drei Toene mit 500ms Puls- und 200ms Pausendauer abgespielt.
Weil das interruptgesteuert ist, kann man danach einfach das eigene Programm weiterlaufen lassen.
Man muss nur aufpassen, bei Programmen oder Bibliotheken, die ebenfalls den Timer1-Interrupt benutzen. Dann muss man auf einen anderen Timer-Interrupt ausweichen.

Hier mal als Fritzing-Platine:
   

Angehängte Dateien

  Buzzer-ISR.zip (Größe: 1,38 KB / Downloads: 1)

Jeder, der schonmal einen ESP8266 per OTA (over the air) programmiert hat, wird wohl schonmal mit dem Problem konfrontiert worden sein, dass die Arduino-IDE die IP-Adresse des ESP im Menü "Werkzeuge/Port" nicht anzeigt und somit eine Programmierung nicht möglich ist.
Im Netz findet man zahlreiche "Lösungen", wie IDE neustarten, Rechner neustarten, Netzwerk von Windows scannen lassen, ESP anpingen, etc...
Das hat bei mir alles nichts gebracht. Die IP-Adresse des ESP wollte nicht im Menü auftauchen.

Bis ich durch Zufall auf eine Methode stieß, die (bisher) immer funktionierte.
Lösung1: das WLAN im Router kurz ausschalten und dann wieder einschalten.
Danach taucht die IP-Adresse im Menü auf. Ich weiß nicht, warum das so ist bzw. was da im Hintergrund abläuft, aber es funktioniert jedes Mal.

Edit: Es gibt noch eine Lösung des Problems!


Lösung2: Man installiert auf einem Smartphone (das sich im gleichen WLAN befindet) die App "Fing" und scannt damit das Netzwerk.

Danach taucht die IP-Adresse ebenfalls wieder im Menü auf. Ja, im Menü der IDE auf dem PC!
Noch ein Nachtrag: Nachdem ich das jetzt einige Tage getestet habe, gefällt mir die zweite Lösung deutlich besser und es funktioniert zuverlässig jedes Mal.
Fing starten, Netzwerk scannen und schon stehen die Ports von allen ESP (im selben Netzwerk) in der Arduino-IDE zur Verfügung.

Hier ist ein kleines AutoIt-Programm, mit dem man benutzerdefinierte Zeichen für die beliebten Arduino-LCDs (16x2 oder 20x4) erstellen kann.
Man kann 4 Zeichen "zusammenpixeln" und erhält dann unten die Bitwerte, die man in die Zwischenablage kopieren und in das eigene Arduino-Programm übernehmen kann.
Ganz oben sind zwei Buttons zum löschen [0] bzw. zum setzen [1] aller Pixel. Mit den Pfeiltasten kann man die gesetzen Pixel um jeweils ein Pixel in die entsprechende Richtung verschieben.


Screenshot:
   

Angehängte Dateien

  Arduino Char-Generator_v1_1.zip (Größe: 663,58 KB / Downloads: 3)

Ich dachte mir, ich kombiniere mal wieder zwei meiner Hobbys (AutoIt und Arduino).
Eine kleine Arduino-Schaltung stellt ein LC-Display bereit, auf dem Meldungen angezeigt werden, die von einem AutoIt-Script verschickt werden.
Was brauchen wir an Hardware:
1. Ein Steckbrett
2. Ein Arduino Nano (oder China-Clone) reicht völlig aus
3. Ein 4x20 Zeichen LCD mit I2C-Interface (z.B. das hier: https://www.amazon.de/AZDelive…fRID=R5VCX62DR4AE9ZQ93QK9)
4. Einen von diesen kleinen PushButtons (Taster), die man gut auf das Steckbrett stecken kann.
5. Einen Piezo-Summer (siehe Fritzing-Bild oder auch diese kleinen steckbaren Piezos). Keinen Lautsprecher! Der Piezosummer muss schon beim anlegen der Spannung einen Piepton ausgeben.
6. Ein paar dieser Steckbrett-Strippen.
Kosten:
Alles zusammen geschätzte 20 - 25 € (je nachdem wo man einkauft oder ob man bereits etwas davon hat).

Ich habe mal mit Fritzing einen "Schaltplan" erstellt:
   
Das Display dort ist ein 2x16 Zeichen-Display. Wird aber ebenso über I2C angesteuert. Ist also von der Verkabelung völlig identisch. Das muss man nur in der Software anpassen.
Das obige 4x20 Zeichen-Display benutze ich und das braucht (bei eingeschalteter Hintergrundbeleuchtung) ca. 32mA. Somit kann man die ganze Schaltung noch vom Nano versorgen (über das USB-Kabel).
An der I2C-Zusatzplatine befindet sich ein kleines Poti, mit dem man den Display-Kontrast einstellen kann. Falls auf eurem Display also nichts zu sehen ist, mit einem kleinen Schraubendreher das Poti etwas verstellen.
Der PiezoSummer piept bei einer neuen Nachricht (das Display wird hell und zeigt die Nachricht) und der PushButton (Taster) ist zum bestätigen der eingetroffenen Nachricht (schaltet dann das Display wieder dunkel).

Software:
Im ZIP-Archiv "NewsDisplay_Arduino.zip" befindet sich das Programm für den Arduino (inkl, meiner PushButton-Klasse zum entprellen).
Im ZIP-Archiv "NewsDisplay_AutoIt.zip" befindet sich das AutoIt-Programm (inkl. meiner SerialComm-UDF).
Beim AutoIt-Script müsst ihr noch den COM-Port anpassen (je nachdem, welchen Port euer Nano belegt).
Die Baudrate muss in beiden Programmen gleich sein. Bei mir hat es mit hohen Baudraten (>19200) nicht funktioniert. Mit 19200 läuft es aber stabil. Zur Not könnt ihr auch auf 9600 runtergehen.
Mit 19200 Baud dauert die Übertragung von 4 Zeilen je 20 Zeichen ca. 57 ms.
Das AutoIt-Script ist wohl weitgehend selbsterklärend. Das Arduinoprogramm habe ich ausführlich kommentiert.

Ihr könnt die Programme nach euren Vorstellungen anpassen oder als Vorlage für Größeres nehmen.
Ich bin mal gespannt, auf was für Ideen ihr kommt, wofür man das Display verwenden kann.  

Edit 14.01.2019:
- Das Arduino-Programm ist jetzt ohne "delay" beim Piepton.
- Man kann jetzt einstellen, wie viele Pieptoene ausgegeben werden sollen.
- Außerdem kann man die Piepton- und die Pieptonpausenzeit einstellen.
- Die interne LED (an Pin 13) blinkt jetzt zusammen mit den Pieptönen.
- Und der Arduino sendet ein "ok" zurueck, wenn die Nachricht angekommen ist.
- Auf der AutoIt-Seite habe ich noch ein AutoIt-GUI-Script als Beispiel geschrieben. Das empfängt dann auch das "ok" und zeigt es in der Statuszeile an.
- Dort kann man auch den Arduino-COM-Port aus einer Liste der vorhandenen COM-Ports auswählen (Combo-Select).

Edit 16.01.2019:
- Das neue Arduino-Programm ("NewsDisplayMulti_Arduino_v1_1.zip") kann jetzt bis zu 15 Nachrichten speichern. Mit dem Pushbutton kann man die letzte Nachricht löschen. Es wird dann die vorherige Nachricht angezeigt (falls vorhanden).
- Durch das puffern der Nachrichten kommt die I2C-LCD-Anzeige nicht mehr dazwischen und somit sind jetzt auch schnellere Schnittstellen-Geschwindigkeiten möglich (z.B. 115200 Baud).
- Wenn der Nachrichtenspeicher voll ist, wird das als Status an das AutoIt-Programm zurückgeschickt.
- Beim Start (bzw. Reset) des Nano wird nun die Versionsnummer, die Schnittstellengeschwindigkeit und die Anzahl der speicherbaren Nachrichten angezeigt.
- Im neuen AutoIt-Programm ("NewsDisplay_AutoIt_v1_1.zip") kann man nun auch die Schnittstellengeschwindigkeit auswählen.
- Außerdem zeigt es die neuen Statusmeldungen an, sowie die Übertragungsdauer (in ms).

Angehängte Dateien

  NewsDisplay_AutoIt.zip (Größe: 4,2 KB / Downloads: 3)
  NewsDisplay_Arduino.zip (Größe: 3,3 KB / Downloads: 4)
  NewsDisplay_AutoIt_v1_1.zip (Größe: 4,35 KB / Downloads: 4)
  NewsDisplayMulti_Arduino_v1_1.zip (Größe: 4,21 KB / Downloads: 4)

Seit der AutoIt-Version 3.3.14.3 (glaube ich) gibt es ja ein paar zusätzliche GDI+ Funktionen.
Damit kann man ganz gut GIF-Animationen in eigenen GUIs nutzen. Bei dem Beispielscript (siehe Anhang) habe ich mal das transparente GIF aus dem alten Thread über ein Hintergrundbild gelegt.
Außerdem wird es jetzt mit "_WinAPI_BitBlt" in die GUI geblittet. Das ist noch etwas schneller.
Es gibt auch noch einen Pause-Button und im Pause-Modus dann einen Einzelschrittmodus. Zusätzlich wird die Größe und die Anzahl der GIF-Frames angezeigt, sowie die Durchschnittszeit, die AutoIt braucht, um den Frame anzuzeigen.
Auf meinem Rechner sind das ca. 14ms pro Frame.
Die GIF-Animation und das Hintergrundbild befinden sich BASE64-kodiert am Ende des Scripts.

Angehängte Dateien

  GIF-Anim.au3 (Größe: 688,16 KB / Downloads: 16)

Bei diesem Script handelt es sich um ein Programm, zum testen von Flash-RAM (USB-Sticks, SD-Karten, SSDs), aber auch von Festplatten.

Wichtiger Hinweis:
Das Fenster kann während des Tests nicht bewegt werden! Während der Bewegung würde die Ausführung des Scripts blockiert werden und somit zu falschen Messwerten führen.
Auch sonst sollte während des Tests nicht so viel im Hintergrund laufen. Mein Programm läuft zwar mit Priorität "Hoch", aber gleichzeitige Zugriffe auf das zu testende Laufwerk führen zu falschen Messwerten.

21.12.2018 Neu! Version 1.0.0,0 (als Anhang)
Die erste richtige Version ist jetzt fertig (keine Beta-Version mehr)!
Das Projekt besteht jetzt aus zwei Programmen ("FlashTest" und "FlashTest-Viewer"). Beide als 32- und als 64-Bit-Version.
"FlashTest" ist das eigentliche Programm zum testen der Laufwerke. "FlashTest-Viewer" zeigt das Test-Ergebnis an und kann das Ergebnis als "Text", als "HTML" oder als "HTML + Grafik" speichern. Die Grafik kann dabei in der Größe frei gewählt werden.
Weil es jetzt eine 32 und eine 64-Bit-Version gibt, deren Testdateien nicht miteinander kompatibel sind, werden die Testdateien mit unterschiedlichen Dateiendungen benannt (.ft32 und .ft64). Das Testergebnis wird mit der Dateiendung ".ftr" gespeichert (im "results"-Unterverzeichnis).
Es gibt jetzt am unteren Fensterrand eine CPU-Auslastung und eine RAM-Belegung, damit man in etwa abschätzen kann, ob das Ergebnis plausibel ist. Wenn die CPU-Auslastung und/oder die RAM-Belegung dauernd bei 100% sind, dann werden die Messwerte für das Laufwerk nicht korrekt sein.
Während der Test läuft, kann man das Fenster jetzt nicht verschieben (habe ich blockiert, es erscheint dann ein Warnhinweis), damit die Ausführung des Scripts nicht angehalten wird.

29.12.2018 Neu! Version 1.1.0.0 (als Anhang)
Diese Version ist jetzt eine Multiprozessing-Version. Das Hauptprogramm startet ein Slave-Programm, welches dann die Schreib-/Leseoperationen durchführt.
Da führte kein Weg drumherum, weil die Schreib-/Leseoperationen das übrige Script ausgebremst haben. Bei schnellen Testlaufwerken (>64 MB/s) hat man das nicht so gemerkt, aber bei langsamen Laufwerken ruckelte die CPU-Anzeige und es erschien oft die Windows-Sanduhr, weil das Programm quasi "hing".
Ein kleinerer Buffer hatte das Problem zwar auch verringert, aber dann sank auch die Transferrate.
Jedenfalls übernimmt nun ein zweiter Prozess das Ganze. Ich habe viel herumexperimentiert, wie ich die Interprozesskommunikation löse. Unsichtbare Edits, TCP und NamedPipe, alles lief nicht richtig rund, weil der eine Prozess auf den Anderen warten musste.
Bis ich auf die MailSlot-UDF von "trancexx" stieß. Damit war es dann ganz einfach.
Somit gibt es jetzt drei Programme (das Hauptprogramm "FLashTest.exe", das Slaveprogramm "Flashtest-Slave.exe", sowie das Auswerteprogramm "FlashTest-Viewer.exe") und diese drei Programme nochmal als x64-Variante.

06.02.2020 Neu! Version 1.2.0.0 (als Anhang)
Es gibt nur eine kleine Änderung. Beim auswählen des Laufwerks wird jetzt zusätzlich die Modellbezeichnung ausgelesen und mit angezeigt.
Das ist hilfreich, wenn man z.B. mehrere USB-Sticks mit gleicher Größe hat. Dann kann man anhand der Modellbezeichnung diese unterscheiden.

07.02.2020 Neu! Version 1.3.0.0 (als Anhang)
Bug behoben: Der Bustyp wurde bei neueren Laufwerken (die z.B. mit NVMe angeschlossen sind) zwar ausgelesen, aber die Einträge gab es im Array nicht, sodass ein Zugriff auf ein nicht existierendes Array-Element erfolgte, was in einem Absturz des Programms endete.
Vielen Dank an UEZ für die Hilfe bei der Beseitigung des Fehlers!

08.02.2020 Neu! Version 1.4.0.0 (als Anhang)
Ok, wenn ich das Programm schonmal wieder neu bearbeite, dann werden noch ein paar Kleinigkeiten bereinigt:
- Beschriftung für den Speicherplatz geändert in: "Speicherplatz für den Schreibtest"
- Beim Button "Nur Lesetest" steht jetzt die Größe der Testdaten dahinter
- Die CPU-Prozentanzeige etwas "beruhigt" (Mittelwert von drei Messungen)
- RAM-Belegung auf 1 MB gerundet, damit die Anzeige nicht so oft neu gezeichnet wird
- Das einlesen vom Laufwerksmodell geht jetzt viel schneller (keine Wartesekunde mehr beim umschalten des Laufwerks)
- Es gibt jetzt einen Button "Viewer starten", mit dem man den FlashTest-Viewer starten kann

Anleitung:
Mit der Combobox oben links wählt man das zu testende Laufwerk aus. Es werden dann einige Laufwerksinformationen angezeigt (rechts).
Bei "Test-Speicherplatz" kann man auswählen, ob der gesamte freie Speicher (nur volle GigaByte) oder nur eine bestimmte Anzahl an GigaByte getestet werden sollen.
Es gibt jetzt zwei Start-Buttons. Einmal "Schreib-/Lesetest" und einmal "Nur Lesetest". Der Button "Nur Lesetest" ist nur dann aktiviert, wenn sich auf dem Laufwerk bereits Testdateien befinden.
Man kann damit dann die vorhandenen Dateien ein weiteres Mal testen.

Links davon wird der Fortschritt angezeigt und unten eine Grafik über den Testverlauf. Rechts neben der Grafik wird noch der Maximal-, der Durchschnitts- und der Minimalwert angezeigt.
Beim Schreiben werden immer 1 GB große Dateien auf dem Laufwerk geschrieben. Diese Dateien enthalten bestimmte Bytefolgen, die beim auslesen überprüft werden.
Achtung! Sollten dabei Fehler auftreten, ist entweder der Datenträger defekt oder es handelt sich um eine Fälschung (die Kapazitätsangabe ist größer als das tatsächlich vorhandene Flash-RAM).

Ganz rechts befindet sich der "Testbericht". Dort wird eine Zusammenfassung der Meldungen des Scripts angezeigt. Dieser Testbericht wird am Ende des Tests gespeichert und zwar in einem Unterverzeichnis ("results") von dem Scriptverzeichnis.
Der Testbericht bekommt als Dateinamen das Datum und die Uhrzeit im Format: "yyyy_mm_dd__HH_MM_SS.ft" zugewiesen.

Screenshots:
           

Angehängte Dateien

  FlashTest_v1_4_0_0.zip (Größe: 4,16 MB / Downloads: 7)