11.02.2020, 14:13
(Dieser Beitrag wurde zuletzt bearbeitet: 11.02.2020, 14:30 von reflection.)
Salu zusammen
Ich bin immer noch dabei den Touchscreen, respektive dessen Programmierung zu erstellen. Hier steckt so einiges an Arbeit drin und wenn sich in diesem Teil Fehler einschleichen, dann kann das ziemlich mühsam für den weiteren Verlauf der Arbeiten werden. Und da ich sonst gerade nichts Neues zu zeigen habe dachte ich mir, ich erläutere einfach einmal wie denn das mit dem Display und der Elektronik so funktioniert. Ich versuche es einfach zu formulieren. Da ich jedoch beruflich aus dieser Ecke komme habt bitte Nachsicht mit mir wenn einmal etwas ein bisschen technisch geschrieben ist. Fragen sind natürlich jederzeit willkommen.
Konzept:
Das Konzept lässt sich am besten anhand eines Blockschaltbildes erklären. Der Aufbau besteht zurzeit aus drei Teilen.
- Humidor
- Humidifier
- Display
Das Display wird, wie ich bereits in einem Beitrag weiter vorne angekündigt habe, direkt in den Rahmen des Humidors integriert. Der Humidifier ist innerhalb des Humidors und stellt somit einen eigenständigen Teil dar. Dies ist auch der Grund wieso der Humidifier über einen eigenen Sensor sowie einen eigenen Mikrocontroller verfügen wird. Ziel ist es, dass er auch einmal eigenständig benutzt werden kann.
Aber nun der Reihe nach. Was ist wofür, warum, wieso, weshalb…
Humdior:
Der Humidor verfügt über zwei Luftfeuchte- sowie Temperatursensoren welche jeweils im oberen und unteren Drittel an der Rückwand angebracht sind. Die Sensoren werden durch Magnete in Position gehalten und können somit zur Reinigung respektive Kalibration einfach entfernt werden.
Verbaut wurden hier: 2x BME280 (Luftfeuchte) und 2x MCP9808 (Temperatur).
Ebenso ist im Boden des Humidors ein 200mm Lüfter verbaut welcher für eine ordentliche Luftzirkulation sorgt.
Humidifier:
Der Humdifier besteht aus:
- Einem Sensor (Luftfeuchtigkeit & Temperatur)
- Lüfter
- Zwei mechanischen „Iris Diaphragm“ welche die Luftzufuhr / Luftabfuhr steuern
- Wasserstands Messung
Der Humidifier wird ein eigenständiges Gerät werden. Er wird mittels eines Steckers im inneren des Humidors an der Rückwand eingesteckt und kann so mit dem Rest der Elektronik kommunizieren. Sollte aus welchem Grund auch immer diese Kommunikation versagen, kann er eigenständig weiterarbeiten.
Hierzu gibt es noch keine vorzeigbaren Bilder. Werde dies aber natürlich, sobald ich anfange auch hier einstellen.
Display:
Das Display übernimmt die visuelle Darstellung aller Messgrössen und ist auch als Eingabedevice nutzbar. Somit können Veränderungen der Parameter direkt über die Touch Oberfläche getätigt werden.
Da die Elektronik des Humidifiers mit derjenigen des Humidors kommunizieren kann (serielle Verbindung) werden auch Messdaten und Aktuatorzustände des Humidifiers angezeigt und können bei Bedarf ebenfalls verändert werden.
Programmierung:
Kommen wir von der Hardware zur Software… Nun wird es ein bisschen technischer
Wieso schreibt er immer wieder vom Display werden sich hier wohl einige Fragen…
Ein kleiner Exkurs: „Grafik braucht Leistung“ und dies ist das Hauptproblem. Um ein Display anzusteuern reicht es leider fast nie aus, wenn man als Rechenunit lediglich einen Mikrocontroller verwendet. Auch hier wurde in den letzten Jahren fleissig entwickelt, aber als Bastler sind solche Systeme meist nicht kauf- respektive bezahlbar. Ebenso ist die Einarbeitungszeit enorm. Nun werden vermutlich einige denken: Wieso nimmt er dann nicht ein Raspberry Pi oder etwas in dieser Art. Nun, dies hat einen einfachen Grund. Auf all diesen Systemen läuft ein Betriebssystem und dies ist hier nicht unbedingt förderlich. Aufstartzeiten, kein realtime Programming, Overhead usw.
Was wäre nun wenn man beide Teile physikalisch trennen würde? Sprich: Ein Teil übernimmt die Datenakquisition, der andere Teil kümmert sich um die Darstellung und Bedienung. Dort wo Rechenleistung benötigt wird ist sie vorhanden, dort wo realtime programming, Bit shifterei ect. benötigt wird befindet man sich auf einem low level Mikrocontroller. Eigentlich die Lösung, wenn man die Kommunikation schlank halten kann. Und genau diesen Ansatz verfolge ich hier. Der einzige „Unterschied“ ist, dass der Part mit der Rechenleistung direkt vom Display übernommen wird. Das Display verfügt also über einen eigenen Prozessor welcher mit ordentlichem Speed die grafischen Teile übernimmt.
Jeder der einmal etwas mit grafikfähigen Displays selber programmiert hat weiss, das ist nicht lustig. Framebuffer, Routinen um grafische Elemente darzustellen, Touchscreen Auswertungen, Overlays ect. müssen mühsam von Hand programmiert werden. Klar, es gibt für gängige Displays auch hie und da Librarys welche verwendet werden können, aber in meiner ganzen Berufslaufbahn habe ich noch nichts gefunden womit man wirklich glücklich wird. Da ich keine Lust habe zig Monate in die Programmierung der Grafik zu versenken, habe ich mich für ein Display entschieden bei welchem all diese Teile bereits vorhanden – und vor allem lauffähig sind.
Und wie läuft das nun genau ab?
Das Display verfügt intern über einen 200MHz Prozessor und in meinem Fall über 128MB Flash Speicher. Die komplette grafische Oberfläche welche statisch ist, wird nun über einen mitgelieferten Editor programmiert. Hierbei muss man (wenn man nicht möchte) keine einzige Zeile Code schreiben. Man klickt sich sozusagen die Oberfläche aus bestehenden Elementen (Text, Slider, Picutres, Checkboxen, Hotspots usw.) zusammen. Das kann man sich in etwa so vorstellen wie wenn man früher bei Visual Basic ein Formular erstellt hat.
Das obenstehende Bild zeigt einen Teil der Grafik welchen ich selber erstellt habe. Es können natürlich mehrere Screens gemacht werden. Hier wird sozusagen dem Entwickler freie Hand gelassen.
Das Bild welches zu sehen ist habe ich in Photoshop gezeichnet, aber ohne die darzustellenden Werte. Diese müssen zuerst vom Arduino erfasst und anschliessend zum Display übertragen werden. Wie man weiter sieht hat es „Platzhalter“ an welcher Stelle ein Wert dargestellt werden kann (gelbe Label).
Das läuft dann einfach ausgedrückt ungefähr so ab:
Der Arduino akquiriert z.B. die Drehzahl des Lüfters in % und sendet diesen Wert an das Display
--> Display: Zeige bei HandFanV die aktuelle Geschwindigkeit des Lüfters in % an.
Der Clou ist nun, dass die Bilder, Texte usw. direkt auf dem Display gespeichert sind und nicht erst mühsam vom Mikrocontroller zum Display übertragen werden müssen. Das Display macht den ganzen Rest selbstständig (Framebuffer, Overlays ect).
Wo Licht ist, ist auch Schatten:
Tönt ja gerade so als ob das die eierlegende Wollmilchsau wäre.
Tja, leider eben doch nicht. 
Die ganze Geschichte ist sehr rudimentär gehalten. Es fehlen einem immer wieder Elemente. Texte können zwar dynamisch dargestellt werden, aber man hat keinerlei grafische Eigenschaften zur Verfügung wie Schatten, Glanz ect. Das ist funktionstechnisch zwar nicht weiter schlimm, aber schön ist es nicht. Gerade solche Feinheiten machen aus einer Standardoberfläche etwas Spezielles.
Nun muss man sich als Entwickler halt etwas einfallen lassen.
Wenn die Schrift nicht schön aussieht, dann kann man ja z.B. den Text in Photoshop erstellen und als Bild ablegen. Anstatt den entsprechenden Text nun als Textelement einzubinden bedient man sich dann eines Bildes.
Nehmen wir den Lüfter von oben… Der Wertebereich ist 0% - 100% Drehzahl. Entweder man schickt nun den entsprechenden Prozentwert direkt ans Display und stellt einen Text dar, oder man macht halt 101 Bilder (Wert 0-100) und zeigt jeweils das Bild mit dem richtigen Wert an. Optisch um einiges ansprechender und da ja nicht jedes Bild vom Mikrocontroller ans Display übertragen werden muss, auch geschwindigkeitsmässig kein Problem.
Und wer nun bis hierhin durchgehalten hat, Chapeau
Ist ein bisschen länger geworden als gedacht, aber vielleicht nützt es ja jemandem von Euch wenn ihr auch einmal ein solches Projekt angehen wollt. Wie sagt man so schön: Viele Wege führen nach Rom - und dies ist einer davon.
Viele Grüsse und bis bald wenn es weiter geht mit der ganzen Geschichte.
reflection
Ich bin immer noch dabei den Touchscreen, respektive dessen Programmierung zu erstellen. Hier steckt so einiges an Arbeit drin und wenn sich in diesem Teil Fehler einschleichen, dann kann das ziemlich mühsam für den weiteren Verlauf der Arbeiten werden. Und da ich sonst gerade nichts Neues zu zeigen habe dachte ich mir, ich erläutere einfach einmal wie denn das mit dem Display und der Elektronik so funktioniert. Ich versuche es einfach zu formulieren. Da ich jedoch beruflich aus dieser Ecke komme habt bitte Nachsicht mit mir wenn einmal etwas ein bisschen technisch geschrieben ist. Fragen sind natürlich jederzeit willkommen.
Konzept:
Das Konzept lässt sich am besten anhand eines Blockschaltbildes erklären. Der Aufbau besteht zurzeit aus drei Teilen.
- Humidor
- Humidifier
- Display
Das Display wird, wie ich bereits in einem Beitrag weiter vorne angekündigt habe, direkt in den Rahmen des Humidors integriert. Der Humidifier ist innerhalb des Humidors und stellt somit einen eigenständigen Teil dar. Dies ist auch der Grund wieso der Humidifier über einen eigenen Sensor sowie einen eigenen Mikrocontroller verfügen wird. Ziel ist es, dass er auch einmal eigenständig benutzt werden kann.
Aber nun der Reihe nach. Was ist wofür, warum, wieso, weshalb…
Humdior:
Der Humidor verfügt über zwei Luftfeuchte- sowie Temperatursensoren welche jeweils im oberen und unteren Drittel an der Rückwand angebracht sind. Die Sensoren werden durch Magnete in Position gehalten und können somit zur Reinigung respektive Kalibration einfach entfernt werden.
Verbaut wurden hier: 2x BME280 (Luftfeuchte) und 2x MCP9808 (Temperatur).
Ebenso ist im Boden des Humidors ein 200mm Lüfter verbaut welcher für eine ordentliche Luftzirkulation sorgt.
Humidifier:
Der Humdifier besteht aus:
- Einem Sensor (Luftfeuchtigkeit & Temperatur)
- Lüfter
- Zwei mechanischen „Iris Diaphragm“ welche die Luftzufuhr / Luftabfuhr steuern
- Wasserstands Messung
Der Humidifier wird ein eigenständiges Gerät werden. Er wird mittels eines Steckers im inneren des Humidors an der Rückwand eingesteckt und kann so mit dem Rest der Elektronik kommunizieren. Sollte aus welchem Grund auch immer diese Kommunikation versagen, kann er eigenständig weiterarbeiten.
Hierzu gibt es noch keine vorzeigbaren Bilder. Werde dies aber natürlich, sobald ich anfange auch hier einstellen.
Display:
Das Display übernimmt die visuelle Darstellung aller Messgrössen und ist auch als Eingabedevice nutzbar. Somit können Veränderungen der Parameter direkt über die Touch Oberfläche getätigt werden.
Da die Elektronik des Humidifiers mit derjenigen des Humidors kommunizieren kann (serielle Verbindung) werden auch Messdaten und Aktuatorzustände des Humidifiers angezeigt und können bei Bedarf ebenfalls verändert werden.
Programmierung:
Kommen wir von der Hardware zur Software… Nun wird es ein bisschen technischer
Wieso schreibt er immer wieder vom Display werden sich hier wohl einige Fragen…
Ein kleiner Exkurs: „Grafik braucht Leistung“ und dies ist das Hauptproblem. Um ein Display anzusteuern reicht es leider fast nie aus, wenn man als Rechenunit lediglich einen Mikrocontroller verwendet. Auch hier wurde in den letzten Jahren fleissig entwickelt, aber als Bastler sind solche Systeme meist nicht kauf- respektive bezahlbar. Ebenso ist die Einarbeitungszeit enorm. Nun werden vermutlich einige denken: Wieso nimmt er dann nicht ein Raspberry Pi oder etwas in dieser Art. Nun, dies hat einen einfachen Grund. Auf all diesen Systemen läuft ein Betriebssystem und dies ist hier nicht unbedingt förderlich. Aufstartzeiten, kein realtime Programming, Overhead usw.
Was wäre nun wenn man beide Teile physikalisch trennen würde? Sprich: Ein Teil übernimmt die Datenakquisition, der andere Teil kümmert sich um die Darstellung und Bedienung. Dort wo Rechenleistung benötigt wird ist sie vorhanden, dort wo realtime programming, Bit shifterei ect. benötigt wird befindet man sich auf einem low level Mikrocontroller. Eigentlich die Lösung, wenn man die Kommunikation schlank halten kann. Und genau diesen Ansatz verfolge ich hier. Der einzige „Unterschied“ ist, dass der Part mit der Rechenleistung direkt vom Display übernommen wird. Das Display verfügt also über einen eigenen Prozessor welcher mit ordentlichem Speed die grafischen Teile übernimmt.
Jeder der einmal etwas mit grafikfähigen Displays selber programmiert hat weiss, das ist nicht lustig. Framebuffer, Routinen um grafische Elemente darzustellen, Touchscreen Auswertungen, Overlays ect. müssen mühsam von Hand programmiert werden. Klar, es gibt für gängige Displays auch hie und da Librarys welche verwendet werden können, aber in meiner ganzen Berufslaufbahn habe ich noch nichts gefunden womit man wirklich glücklich wird. Da ich keine Lust habe zig Monate in die Programmierung der Grafik zu versenken, habe ich mich für ein Display entschieden bei welchem all diese Teile bereits vorhanden – und vor allem lauffähig sind.
Und wie läuft das nun genau ab?
Das Display verfügt intern über einen 200MHz Prozessor und in meinem Fall über 128MB Flash Speicher. Die komplette grafische Oberfläche welche statisch ist, wird nun über einen mitgelieferten Editor programmiert. Hierbei muss man (wenn man nicht möchte) keine einzige Zeile Code schreiben. Man klickt sich sozusagen die Oberfläche aus bestehenden Elementen (Text, Slider, Picutres, Checkboxen, Hotspots usw.) zusammen. Das kann man sich in etwa so vorstellen wie wenn man früher bei Visual Basic ein Formular erstellt hat.
Das obenstehende Bild zeigt einen Teil der Grafik welchen ich selber erstellt habe. Es können natürlich mehrere Screens gemacht werden. Hier wird sozusagen dem Entwickler freie Hand gelassen.
Das Bild welches zu sehen ist habe ich in Photoshop gezeichnet, aber ohne die darzustellenden Werte. Diese müssen zuerst vom Arduino erfasst und anschliessend zum Display übertragen werden. Wie man weiter sieht hat es „Platzhalter“ an welcher Stelle ein Wert dargestellt werden kann (gelbe Label).
Das läuft dann einfach ausgedrückt ungefähr so ab:
Der Arduino akquiriert z.B. die Drehzahl des Lüfters in % und sendet diesen Wert an das Display
--> Display: Zeige bei HandFanV die aktuelle Geschwindigkeit des Lüfters in % an.
Der Clou ist nun, dass die Bilder, Texte usw. direkt auf dem Display gespeichert sind und nicht erst mühsam vom Mikrocontroller zum Display übertragen werden müssen. Das Display macht den ganzen Rest selbstständig (Framebuffer, Overlays ect).
Wo Licht ist, ist auch Schatten:
Tönt ja gerade so als ob das die eierlegende Wollmilchsau wäre.
Tja, leider eben doch nicht. Die ganze Geschichte ist sehr rudimentär gehalten. Es fehlen einem immer wieder Elemente. Texte können zwar dynamisch dargestellt werden, aber man hat keinerlei grafische Eigenschaften zur Verfügung wie Schatten, Glanz ect. Das ist funktionstechnisch zwar nicht weiter schlimm, aber schön ist es nicht. Gerade solche Feinheiten machen aus einer Standardoberfläche etwas Spezielles.Nun muss man sich als Entwickler halt etwas einfallen lassen.
Wenn die Schrift nicht schön aussieht, dann kann man ja z.B. den Text in Photoshop erstellen und als Bild ablegen. Anstatt den entsprechenden Text nun als Textelement einzubinden bedient man sich dann eines Bildes.
Nehmen wir den Lüfter von oben… Der Wertebereich ist 0% - 100% Drehzahl. Entweder man schickt nun den entsprechenden Prozentwert direkt ans Display und stellt einen Text dar, oder man macht halt 101 Bilder (Wert 0-100) und zeigt jeweils das Bild mit dem richtigen Wert an. Optisch um einiges ansprechender und da ja nicht jedes Bild vom Mikrocontroller ans Display übertragen werden muss, auch geschwindigkeitsmässig kein Problem.
Und wer nun bis hierhin durchgehalten hat, Chapeau
Ist ein bisschen länger geworden als gedacht, aber vielleicht nützt es ja jemandem von Euch wenn ihr auch einmal ein solches Projekt angehen wollt. Wie sagt man so schön: Viele Wege führen nach Rom - und dies ist einer davon.Viele Grüsse und bis bald wenn es weiter geht mit der ganzen Geschichte.
reflection
![[+]](https://zigarren-community.de/images/collapse_collapsed.png)
