Anfänger-Entwicklung einer Gärbox Steuerung

[Uli (uiimcn)]

Hallo Foristi,
hatte bereits einen Vorstellungs-Thread hier im OffTopic Forum und 
stelle fest, dass das Projekt für mich als Anfänger nur hier reinpasst. 
Ich hab Problemchen potentiell mit Allem, was dabei so während der 
Entwicklung auftaucht.

Ich strenge mich also an und versuche, mich möglichst kurz zu fasssen.

Grundelemente der Steuerung:
- Power: 12V, 2A Steckernetzteil
- IN-Buchse 5,5 * 2,1mm; Kippschalter, Fadensicherung
- DC-DC Spannungswandler 12 -> 5V, 1A
- NodeMCU ESP8266 12E, I2C, 4MB
- OLED-Display, 1.3", 4-PIN
- Heizdraht
- 2 Stck. Bimetall-Sicherungselemente
- Relais oder MSOFET zum Schalten des Heizdrahtes
- 4 Push-Buttons (3 f. Menue, 1 für temporäre Beleuchtung innen)
- geignete Spannungsteiler, um die drei Menue-Taster per ADC0 erkennen 
zu können
- 1 LED
- 4 Stck. DS18B20 Temperatursensoren (mit ALARM-Trigger)

Das lass ich jetzt mal so stehen, um viell. erste Fragen zum Grundaufbau 
beantworten zu können.

Danach schaue ich, wo's am meisten klemmt momentan.

Grüße
Uli

[Axel S. (a-za-z0-9)]

Uli schrieb:
> Ich hab Problemchen potentiell mit Allem, was dabei so während der
> Entwicklung auftaucht.

Wenn du damit solche Probleme hast, warum kaufst du dann nicht eine 
fertige Gärbox und konzentrierst dich aufs Backen?

[Uli (uiimcn)]

Guten Morgen zusammen,
kaum hier angefangen, klemmts schon gewaltig..

Zum Schalten des Heizdrahtes (12V; ca. 1,5A) nehme ich doch besser einen 
MOSFET, den IRLZ44N, TO220 Gehäuse, anstelle eines Relais.

Außer mir scheinen nun alle anderen zu wissen, wie die drei Beinchen dem 
Gate, Source und Drain zuzuordnen zu sind. Das Gate ist wohl der 
mittlere Anschluss. Aber die beiden anderen???

Ich habs gesucht und absolut nichts gefunden - stehe sicherlich auf dem 
Schlauch.

Grüße
Uli

[Klaus (feelfree)]

Uli schrieb:
> Außer mir scheinen nun alle anderen zu wissen, wie die drei Beinchen dem
> Gate, Source und Drain zuzuordnen zu sind

Dann solltest du wie alle anderen halt das Datenblatt lesen.

[Michael B. (laberkopp)]

Uli schrieb:
> Ich hab Problemchen potentiell mit Allem,

Kein Wunder, wenn ich die ellenlange Liste der Teile lese.

Wozu den ganzen Kram ?

Eine professionelle kommerzielle Gärbox besteht genau aus einer Heizung 
und einem Bimetalltemperaturregler, fertig.

Damit hätte man wohl keine Probleme.

Ja, man kann die Temperatur genauer regeln mit einem PID 
Temperaturregler, aber willst du den programmieren ?

Die Probleme sind eher eine Box die feucht hält, leicht zu reinigen ist, 
kompakt wegzupacken ist.

Dass Wärme in den Teig sowieso nur langsam eindringt, dagegen kannst du 
nichts tun.

Man könnte per Ultraschallentfernungsmessern gucken, wie weit der Teig 
aufgegangen ist, hängt das doch nicht nur von Zeit und Temperatur, 
sondern auch dem Teig ab, damit man rechtzeitig stoppt, bevor die Kiste 
voll versaut wird.

[Uli (uiimcn)]

Klaus schrieb:
> Dann solltest du wie alle anderen halt das Datenblatt lesen.

Hatte das Infineon-DaBla bereits gelesen, ohne Erfolg.

Jetzt hab ich's dank deines Hinweises doch gefunden, mit der Lupe ging 
das dann ganz gut... man lernt halt nie aus...  :-)

Michael B. schrieb:
> ... Wozu den ganzen Kram ? ...

Es hängt halt davon ab, was du machen willst.

Ich selbst stelle mir das eher so vor:

https://brotbackforum.iphpbb3.com/forum/77934371nx46130/anfaengerfragen-f6/kleiner-feiner-gaerautomat-was-soll-muss-er-alles-koennen-t10439.html#p223153

Die wesentlichen Punkte sind aufgeführt.

Grüße
Uli

[Joe G. (feinmechaniker)]

Man nehme eine kleine elektrische Heizmatte mit ca. 15W -20 W, einen 
230V Thermostat mit Fühler, eine Holzkiste und in einer Stunde ist die 
Box aufgebaut. Die eingesparte Zeit verwendet man zum Backen :-)

[Monk (roehrmond)]

Wenn es zu kalt ist stelle ich den Teig in den Backofen und schalte 
dessen Licht ein. Das reicht als Wärmequelle.

[Kurt A. (hobbyst)]

Wenn es dem Teig zu kalt ist, heize ich den Backofen mit Umluft auf ca. 
40°C auf. Mach die Heizung aus und stelle den Teig hinein. Auch das 
geformte Brot stelle ich zum Aufgehen lassen hinein. Hat der Teig zu 
kalt bei der Gärung bildet sich Essigsäure. Was dann beim backen 
säuerlich riecht. Bei richtiger Temperatur (25°-30°C) bildet sich 
angenehme milde Milchsäure.

[Jürgen F. (unterstrom)]

Guckst du hier:
das ist genau, was du bedarfst:

Beitrag "Re: SSR für Heizungssteuerung"

Auch ich habe mir fürs Brotbacken einen solchen Gärschrank gebaut. Im 
Nachhinein kann ich sagen, dass mit dem Gärschrank, also mit einer 
bekannten und konstanten Temeratur, reproduzierbaren Erfolg beim Backen 
hatte.

Jürgen

[Michael B. (laberkopp)]

Jürgen F. schrieb:
> das ist genau, was du bedarfst

Mit 6V Spannungsregler an AVR und LCD ?

Hat wohl weder ramp-Controller noch PID-Regelung.

Vielleicht doch einfach fertig kaufen

https://www.ebay.de/itm/125256234812

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uli schrieb:
> Ich strenge mich also an und versuche, mich möglichst kurz zu fasssen.
1. wenn du selber Elektronik entwickeln willst, dann musst du 
Elektronikentwicklung beherrschen
2. wenn du Elektronikentwicklung noch nicht beherrscht, musst du es 
lernen
3. wenn du Elektronikentwicklung lernen musst, dann nimm dir für die 
Grundlagen 1-2 Jahre Zeit

Und wenn du dann selber etwas entwickeln willst, ist der Prozess etwa 
so:

1. grundlegende Untersuchungen (ist es technisch überhaupt möglich?)
2. Demonstrator (mit Spucke und Heißkleber zusammengeflickt)
3. Funktionsmodell (siehe Demonstrator, nur ohne Spucke)
4. Prototyp (kann schon fast alles, hat aber noch Macken)
5. Vorseriengerät (muss für Sereintauglichkeit noch überarbeitet werden)
6. Seriengerät (braucht nur noch ein wenig Betreuung)

Diese 5 Stufen können ggfs. abgekürzt oder der Entwicklungsprozess an 
beliebiger Stelle abgebrochen werden. Dann gibt es evtl. eben nur den 
etwas zusammengebastelten Prototypen.

Du solltest also zuallererst mal mit dem Demonstrator anfangen und die 
Box selber bauen. Die nimmst du dann wie alle Welt mit einer käuflichen 
Heizung und einem 10€ Temperaturregler in Betrieb und findest heraus, 
dass diese Box so sowieso nicht taugt und geändert werden muss.

Du wirst herausfinden: Entwicklung kostet Geld und Zeit (die letztlich 
auch wieder in Geld umgerechnet werden kann).

Uli schrieb:
> Ich selbst stelle mir das eher so vor:
> 
https://brotbackforum.iphpbb3.com/forum/77934371nx46130/anfaengerfragen-f6/kleiner-feiner-gaerautomat-was-soll-muss-er-alles-koennen-t10439.html#p223153
> Die wesentlichen Punkte sind aufgeführt.

Temperatursteuerung
Einstellbare Werte
- Temperaturen von 17 bis 52°C
- Temperaturverläufe

Dir ist aber schon klar, dass
1. es ohne Umluft dank Hotspots in deiner Box nicht "die eine 
Temperatur" gibt und deshalb eine Genauigkeit auf 1°C völlig unnötig 
ist?
2. dass das Innere deines Teigklumpens erst Stunden später was von einer 
äusseren Temperaturänderung mitbekommt und im ganzen Teig dann sowieso 
jede Stellr iheren eigenen Temperaturverlauf hat?

Und dass du deshalb gar keine unötig hohen Anforderungen an die 
Temperaturregelung stellen brauchst.

Uli schrieb:
> Grundelemente der Steuerung:
> ...
> Das lass ich jetzt mal so stehen
Elektroniker kommunizieren länder- und sprachübergreifend in 
Schaltplänen.
Weil du letztendlich zur Doku sowieso einen Schaltplan braucht, solltest 
du also besser gleich von Anfang an einen Schaltplan oder eine 
schmatische Skizze machen, die zeigt, was da verbaut ist (Bauteilnamen 
und Bauteiltypen) und wie du diese Bauteile/Baugruppen miteinander 
verschalten willst.

[Al. K. (alterknacker)]

Lothar M. schrieb:
> 1. grundlegende Untersuchungen (ist es technisch überhaupt möglich?)
> 2. Demonstrator (mit Spucke und Heißkleber zusammengeflickt)
> 3. Funktionsmodell (siehe Demonstrator, nur ohne Spucke)
> 4. Prototyp (kann schon fast alles, hat aber noch Macken)
> 5. Vorseriengerät (muss für Sereintauglichkeit noch überarbeitet werden)
> 6. Seriengerät (braucht nur noch ein wenig Betreuung)
>
> Diese 5 Stufen können ggfs. abgekürzt oder der Entwicklungsprozess an
> beliebiger Stelle abgebrochen werden. Dann gibt es evtl. eben nur den
> etwas zusammengebastelten Prototypen.

Richtig..

Bei der Vorstellung von 20-40 Jahre alten Basteleien sollten diese 
Punkte auch beachtet werden.
Aber es wird eben nur über "Spucke und Heißkleber" diskutiert.

Mit freundlichen Grüßen
alterknacker

[Peter D. (peda)]

Ich würde unten eine Aluplatte nehmen und darauf 4 Widerstände im TO-220 
montieren, dann wird die Platte recht gleichmäßig warm.
Den Sensor auch im TO-220, z.B.: SMT172-TO220, der läßt sich einfach mit 
jedem µC mit Capture-Input einlesen.
Und ein PC-Lüfter für die Umluft.
Zur Versorgung ein 12V Steckernetzteil.
Experimentieren muß man eh mit der Temperatur und der Zeitdauer.
Ein Profil fahren braucht man nicht.

https://www.digikey.de/de/products/detail/angst-pfister-sensors-and-power-ag/SMT172-TO220/17827927

[J. S. (jojos)]

Al. K. schrieb:
> Aber es wird eben nur über "Spucke und Heißkleber" diskutiert.

Unfug, es wurde über einen konkreten Plan diskutiert, nicht über Pfusch.

Nur das die Grundlagen des TO so dünn sind das es langer Weg wird. 
Einfach die Wünsche nennen und hoffen das es jemand danach mundgerecht 
serviert ist hier nicht.

[Monk (roehrmond)]

Peter D. schrieb:
> Und ein PC-Lüfter für die Umluft.

Umluft trocknet den Teig aus, würde ich daher nicht einsetzen.

Im Idealfall soll die Gärbox den Teig nicht erwärmen, sondern nur warm 
halten. Der Teig sollte schon vorher durch das Kneten und temperierte 
Zutaten auf die richtige Temperatur gebracht worden sein. Ansonsten wird 
er ungleichmäßig hoch gehen.

Lothar M. schrieb:
> Temperaturen ... bis 52°C

Nach meinem Kenntnisstand sterben die Mikroben oberhalb von 40 °C. 
Sinnvollerweise sollte die Box so hohe Temperaturen gar nicht zulassen.

[Peter D. (peda)]

Noch einfacher, man nimmt zum Heizen 4 Transistoren im TO-220 (z.B. 
TIP120).
Über die 4 Emitterwiderstände wird der Strom eingestellt, so daß bei 5V 
(3,3V) an der Basis die maximale Heizleistung erreicht wird. Und eine 
PWM mit RC-Glättung stellt die Basisspannung ein, d.h. gibt den 
Heizstrom vor.

[Gerald B. (gerald_b)]

Es gibt hier fast unendlich viele Wege, die nach Rom führen.
Bei der Gärbox wäre noch zu klären, ob da Teig, oder ein Weinballon 
verarztet werden soll. Bei Letzterem wird mehr Heizleistung benötigt.
Da nur sehr rudimentäre Elektronikkenntnisse vorhanden sind, würde ich 
aus der Automatisierungstechnik einen (PID) Reglermodul nehmen, ein 
Netzteil, den passenden Fühler und ein SSR dazu, das ganze verkabeln und 
fertig ist die Steuerung.
Nur mit Elektronik- und Programmierkennttnissen macht es Sinn, die 
Steuerung selbst zu bauen.

[Lodda (Gast)]

Gerald B. schrieb:
> Bei Letzterem wird mehr Heizleistung benötigt.

Quatsch!
Ganz im Gegenteil, eine gärende Maische braucht eine Kühlung!
Der Effekt nennt sich Endothermie.

[Gerald B. (gerald_b)]

Ja, bei 100L aufwärts :-)
Bei einem kleinen 5 oder 10L Ballon zu Hause, eher nicht. Sowie die 
Frage gestellt wurde, deutet alles eher auf Letzteres hin.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Gerald B. schrieb:
> Bei der Gärbox wäre noch zu klären
Mir scheint das Ganze recht klar zu sein, denn

Uli schrieb:
> Ich selbst stelle mir das eher so vor:
> 
https://brotbackforum.iphpbb3.com/forum/77934371nx46130/anfaengerfragen-f6/kleiner-feiner-gaerautomat-was-soll-muss-er-alles-koennen-t10439.html#p223153

[Peter D. (peda)]

Axel S. schrieb:
> warum kaufst du dann nicht eine
> fertige Gärbox und konzentrierst dich aufs Backen?

Das ist natürlich der sinnvollste Ansatz. Die Hersteller solcher Geräte 
haben nämlich schon den Hauptaufwand der Entwicklung geleistet. Nämlich 
alle Parameter ermittelt, die eine optimale Gärung ermöglichen.
Vielleicht nach 1000 Broten und mehreren Konstruktionsänderungen wirst 
Du mit Deinem Selbstbau einen ähnlichen Stand erreicht haben.

Eierkocher sind auch ganz einfach aufgebaut. Die Menge des Wassers im 
Meßbecher bestimmt den Härtegrad des Eies. Trotzdem käme niemand auf die 
Idee sowas selber entwickeln zu wollen.

[Uli (uiimcn)]

Also eigentlich, ja, eigentlich, wollte ich heute Vormittag in den 
Bastelkeller gehen und dort etwas weiter machen - dieser Plan hat sich 
nach euren vielen Beiträgen nun komplett geändert...

Ich bin jedenfalls hoch erfreut, dass hier im Forum das gesamte KnowHow 
versammelt ist und zumindest die grundsätzliche Bereitschaft besteht, 
dieses auch zu teilen!

Ich selbst werde dies auf jeden gerne Fall tun, sofern es auch für 
Anfänger einigermassen passen könnte und für mich selbst transparent 
genug ist.

*Vorab herzlichen Dank an Alle!*

_Zuerst zur praktischen 'Bäckerei'_ (wir sind ja Offtopic hier):

Joe G. schrieb:
> ... Heizmatte mit ca. 15W -20 W ... 230V Thermostat mit Fühler ...
Das war meine erste Gärbox, allerdings mit nur 7W und dazu eine völlig 
ungedämmte Kunststoffbox - viel ging da nicht :-)

Ganz im Ernst:
- Ein teilweise abenteuerliches oder gar lebensgefährliches Provisorium, 
das durchaus auch ein ganzes Leben lang seinen Zweck erfüllen könnte, 
will ich für das aaktuelle Modell definitiv nicht. Und schon gar nicht 
will ich es anderen vorschlagen... Es gibt außerdem bereits (fast) 
endlos viele davon.

Im weiteren Verlauf habe ich es je nach Anwendungsfall auch ähnlich 
gemacht wie @Steve van de Grens (roehrmond) oder @Kurt A. (hobbyst).

Einer der wichtigsten Auslöser für meine Entscheidung zur öffentlichen 
Entwicklung des 'Volkswagens' war der Punkt von dir, Jürgen:

Jürgen F. schrieb:
> ... bekannten und konstanten Temeratur, reproduzierbaren Erfolg beim Backen ...
Das trifft genau auch mein praktisches Problemchen. Für mich soll eine 
vernünftige 'Minimal'gärbox ohne mein weiteres Zutun genau das 
zuverlässig und reproduzierbar machen, was ich brauche bzw. haben will:
- Vorgegebene Temperatur überr eine definierte Zeit konstant halten
- Vorgegebenen, individuell einstellbaren Temperaturverlauf nachfahren
- bei Prototyp II bis max. 52°C

Weshalb 52°C? --> Es gibt z. B. auch den Wunsch, indisches Ghee 
herzustellen. Das soll im letzten Schritt über einen längeren Zeitraum 
bei ca. 50°C gehalten werden. Das deckt die Gärbaox dann problemlos mit 
ab - weshalb auch nicht?

Zum technischen komme ich im Folgebeitrag separat.

Vielen Dank, viele Grüße
Uli

[Uli (uiimcn)]

Jürgen F. schrieb:
> Guckst du hier: ...
> Beitrag "Re: SSR für Heizungssteuerung"
> ...

Hallo @Jürgen,
hab mir den Schaltplan angeschaut - ist leider zu 'schwierig' für 
mich...

Die aktuelle Steuerung besteht (auf dem PCB) bis jetzt aus nur drei 
aktiven Teilen:
- 5V Spannungsversorgung (DC-DC Wandler 12V -> 5V)
- NodeMCU ESP 8266
- MOSFET (Schalten des Heizdrahtes)

Ich glaubs ja selbst noch nicht ganz, werde das aber bald feststellen...
Alles andere sind Einbauten in die Box selbst, also 'Peripherie' zur 
Platine.

Hallo @Lothar,
danke dir sehr für deine übersichtlichen und umfassenden Angaben und 
Beschreibungen!

Lothar M. schrieb:
> ... wenn du selber Elektronik entwickeln willst, ... dann nimm dir für die 
Grundlagen 1-2 Jahre Zeit
> ...
Ganz so schlimm wird's hoffentlich nicht werden.
Wichtige Grundlagen der Elektronik sind mir durchaus bewusst, so dass 
ich in vielen Fällen in der Lage bin, meine Aufmersamkeit auf 
mit-entscheidende Details zu lenken wie z. B.:
- Unterschied zw. Kapazitiver und Resistiver Load
- Heat Dissipation
- Störende Spannungsspitzen im Betrieb
- Lifetime-Cycles (bei geschalteten Lasten z. B.)
- etc., etc...

Lothar M. schrieb:
> Und wenn du dann selber etwas entwickeln willst, ist der Prozess etwa
> so:
> ... grundlegende Untersuchungen ... Funktionsmodell ... Prototyp ... 
Vorseriengerät ...
> ...
Bei dem, was du Vorseriengerät nennst, bin ich in etwa angelangt - es 
ist mein Prototyp II.
Der wird aktuell sehr nahe am finalen Modell gebaut und anschließend 
im Praktischen verwendet. So kommen hoffentlich auch überraschende 
Aspekte nicht zu kurz!

Lothar M. schrieb:
> ...
> Dir ist aber schon klar, dass
> 1. es ohne Umluft dank Hotspots in deiner Box ...
> 2. dass das Innere deines Teigklumpens erst Stunden später was von einer
> äusseren Temperaturänderung mitbekommt ...
> Und dass du deshalb gar keine unötig hohen Anforderungen an die
> Temperaturregelung stellen brauchst.
> ...
Kurz gesagt: Ja, ist mir klar.

Das führe ich jetzt hier meinerseits nicht weiter aus - es führt wieder 
weit vor allem in die Backpraxis hinein...

Zur Hysterese:

Unabhängig davon, welche Temperatur das Gärgut innerhalb der Box zum 
Zeitpunkt X nun 'fühlt', möchte ich die von den 4 Sensoren ermittelte 
(und gemittelte) Temperatur durchaus mit ca. +-0,5°C führen. Mehr als 
genau die gewünschte Umgebungstemperatur zum Zeitpunkt X kann man dem 
Teig in einer so einfachen Box nicht 'anbieten'. Den Rest macht dann z. 
B. der Bäcker oder die Bäckerin. ;-)

Lothar M. schrieb:
> Elektroniker kommunizieren länder- und sprachübergreifend in
> Schaltplänen.
> ...

Muss mal sehen wie und wann ich das mache- viel ist es eigentlich ja 
nicht...

Jetzt ist erst mal Mittagessen angesagt, viele Grüße
Uli

[Norbert (der_norbert)]

Lodda schrieb:
> Ganz im Gegenteil, eine gärende Maische braucht eine Kühlung!
> Der Effekt nennt sich Endothermie.

Aha … Seltsam, da hätte ich jetzt auf eine exotherme Reaktion gewettet.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uli schrieb:
> Lothar M. schrieb:
>> Elektroniker kommunizieren länder- und sprachübergreifend in
>> Schaltplänen...
> Muss mal sehen wie und wann ich das mache- viel ist es eigentlich ja
> nicht...
Am Besten macht man das im Voraus. Und ein Blatt Papier reicht da schon 
aus. So wie ein Schlosser mit einer Zeichnung auch viel mehr anfangen 
kann, als wenn du ihm erklärst "Also ich will da einen Bolzen über den 
Riegel in die Lasche schieben und dann den Hebel nach oben drehen, damit 
der Pümpel in den Schlitz greift und der so den Nippel umbiegt, damit 
irgendwas passiert."

> Bei dem, was du Vorseriengerät nennst, bin ich in etwa angelangt
Für die 2. Vorserie sollte die BOM aber schon besser fixiert sein.

> möchte ich die von den 4 Sensoren ermittelte (und gemittelte) Temperatur
> durchaus mit ca. +-0,5°C führen.
Im Hinterkopf behalten: die Sensoren sind gar nicht so genau.

Und zudem hast du  dann das Problem, dass du bei 4 Sensoren 4 
unterschiedliche Werte bekommst und nicht weißt, welcher denn nun gelten 
soll. Oder soll es ein (willkürlicher) Mittelwert sein? Oder gilt der 
Sensor mit der höchsten/niedrigsten Temperatur? Oder gilt genau der 
Sensor mit der höchsten/niedrigsten Temperatur nicht (Median statt 
Mittelwert)?

> hab mir den Schaltplan angeschaut - ist leider zu 'schwierig' für mich...
Der ist nicht schwierig, den hatte ich ohne Worte nach 10 Sekunden 
verstanden  ;-)

BTW: zum Thema "exo- oder endothermer Prozess" könnt ihr euch bitte per 
PN beleidigen.

[Uli (uiimcn)]

Hallo,
zunächst Berichtigungen, Ergänzungen, Auslassungen:

Thema Umluft
Etwas Zwangs-Umluft wird durch eine asymmetrische Anordnung des 
Heizdrahtes erzeugt. So verteilt sich die Wärme im Innenraum besser und 
lässt sich etwas leichter mit 4 DS18B20-Sensoren messen.

Thema Vorserie
Meine Darstellung war nicht vollständig. Das physische Modell, die Box 
mit Details zum inneren Aufbau wie Dämmung, Stellfläche als Lochplatte, 
darunter die Anordnung und Anbringung des Heizdrahtes, Deckel etc. 
entsprechen Prototyp II oder 'Vorserie'.
Das betrifft jedoch nicht die zu entwickelnde Steuerung. Dazu gibt es 
keinen bestimmten Vorgänger.

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

@Peter

Peter D. schrieb:
> Ich würde unten eine Aluplatte nehmen und darauf 4 Widerstände im TO-220
> montieren, ...
Das entspräche eher meiner Vorstellung von 'Mercedes', um im Bild zu 
bleiben. Hatte die Aluplatte (die auch noch gelocht wäre) zuerst hin- 
und herüberlegt und danach erst mal abgelegt.
Das wird evtl. interessant für einen Gärschrank mittlerer Größe (neues 
Projekt, völlig offen...)...

Auf die Zweckentfremdung von IC-Kompomonenten zum Heizen kam ich selbst 
bis dato nicht - aber jetzt hab ichs ja bereits gelesen ;-)

Peter D. schrieb:
> Axel S. schrieb:
>> warum kaufst du dann nicht eine
>> fertige Gärbox und konzentrierst dich aufs Backen?
>
> Das ist natürlich der sinnvollste Ansatz. ...
> Vielleicht nach 1000 Broten und mehreren Konstruktionsänderungen wirst
> Du mit Deinem Selbstbau einen ähnlichen Stand erreicht haben. ...
Das sehe ich etwas anders.
Sicher zeigen sich materialbedingte Erscheinungen (Abnutzung, Alterung, 
Korrosion, Teile-Lebensdauer etc.) erst nach einiger, leider in diesem 
Fall undefinierbarer Zeit. Denen kann ich leider nur per allgemeinem 
Wissen, Erfahrung, Google & Co, heute auch ChatGPT (riesen 
Wissensdatenbank! - natürlich nur mit großer Vorsicht zu genießen...) 
begegnen.

Was die gesamte Art der Umsetzung, den Nutzungs- und Bedienungskomfort 
etc. betrifft, habe ich meine eigenen Ansätze. Das kannst du dir nicht 
einfach kaufen.
Und es ist der Spass, den ich dabei hab.

@Lothar

Lothar M. schrieb:
> ...
> Und zudem hast du  dann das Problem, dass du bei 4 Sensoren 4
> unterschiedliche Werte bekommst und nicht weißt, welcher denn nun gelten
> soll. Oder soll es ein (willkürlicher) Mittelwert sein? Oder gilt der
> Sensor mit der höchsten/niedrigsten Temperatur? Oder gilt genau der
> Sensor mit der höchsten/niedrigsten Temperatur nicht (Median statt
> Mittelwert)?
> ...
Genau diese Frage(n) sind bis jetzt nicht abschließend geklärt.

Ich mache zuerst mit der neuen Box Tests, um das dann auf 
experimenteller Grundlage zu entscheiden. Irgendwie musst du das ja 
machen, wenn kein technischer Overkill im Spiel ist...

Lothar M. schrieb:
> ...
> Der (Schaltplan) ist nicht schwierig, den hatte ich ohne Worte nach 10 Sekunden
> verstanden  ;-)
Könnte da ein Op-Amp drin sein? :-) - die Erinnerung ist zu schwach, 
Erfahrung praktisch nicht vorhanden ...

Das wars jetzt für heute - mehr ist zur Beschreibung des Rahmens und des 
Status auch nicht erforderlich, glaube ich.

Danke allen nochmals!

Viele Grüße
Uli

[Uli S. (uli12us)]

Es gibt zum Preis von etwas über 10€ aus China Temperaturregler, die 
können über 2 Schaltkontakte entweder heizen oder kühlen. Die Dinger 
sind zwar nur auf 1° beliebig einstellbar. Es gibt zwar da nur einen 
Sensor, aber es spricht natürlich nichts dagegen, den reihum mit 3 
zusätzlichen zu schalten.
Wie die Regelung da genau funktioniert werden zwar nur die entwickler 
wissen, wenn die Temperatur im gewünschten Rahmen pendelt, interessiert 
das
imo aber eh nicht. Damit lässt sich ganz einfach eine Heizplatte 
ansteuern,
dies entweder für die Küche oder aber zum Fotografieren gibt.
Da besteht die ganze Arbeit darin, das ganze mit den passenden 
Anschlüssen zu versehen und passend anzustecken. Falls unbedingt selber 
was gemacht werden soll würde ich  auf das 12V Netzteil verzichten und 
irgendein 0815
USB-NT dafür einsetzen. Warum solllte man sich völlig unnötige Arbeit 
machen, wenns ohne das vermutlich sogar besser geht.
Danach muss man sich halt noch ein geeignetes Gefäss, am besten mit nem 
Wassermantel suchen und falls nötig noch eine Luftumwälzung, die aber 
auch mit 5V betrieben werden kann.

[Uli (uiimcn)]

Uli S. schrieb:
> Es gibt zum Preis von etwas über 10€ aus China Temperaturregler, die
> können über 2 Schaltkontakte entweder heizen oder kühlen. Die Dinger
> sind zwar nur auf 1° beliebig einstellbar ...

Hallo Namensvetter,

das wäre dann in meiner Definition wieder eine 'Bastelarbeit', kaum 
'integriert' zu nennen, an der ich kein Interesse habe. Etwas Ähnliches 
(nur ein Fühler, Power entweder AN oder AUS) steht seit einigen Jahren 
bei mir hier zu Hause.
Damit kann ich z. B. keine Temperaturkurven fahren, die für 
ambitioniertere BäckerInnen sehr wünschenswert wären, ohne ständig dabei 
sei zu müssen und 'händisch' zu steuern.

Hier ein Beispiel dazu aus https://www.homebaking.at/dachsteinbrot/ :
/"Der Sauerteig sollte in der Anfangsphase 35°C haben *und erst in der 
zweiten Hälfte der 18-24 Stündigen Reifezeit sinkt die 
Sauerteig-Temperatur auf 22°C.*"/

Wie willst du das machen mit einer 'Bastelei'?

Uli S. schrieb:
> ... Die Dinger
> sind zwar nur auf 1° beliebig einstellbar ...
Die absolute Temperatur(genauigkeit) ist nicht so entscheidend, die 
Hysterese schon. Wichtiger als absolute Genauigkeit ist mir die 
Wiederholgenauigkeit. Kalibrieren kann man ggfs. immer (z. B. auch per 
Menue).

Uli S. schrieb:
> ...
> Danach muss man sich halt noch ein geeignetes Gefäss, am besten mit nem
> Wassermantel suchen und falls nötig noch eine Luftumwälzung, die aber
> auch mit 5V betrieben werden kann. ...
Am Ende alles doch sehr aufwendig und nicht von vornherein aufeinander 
abgestimmt bzw. entsprechend designt und konstruiert.
Und daran hab ich doch mein Interesse, U. a. für hohen Nutzerkomfort wie 
z. B. vollständige Steuerbarkeit per Menue, z. B. auch über einen ganzen 
24h-Zeitraum oder auch deutlöich länger.

Gruß
Uli

[Uli S. (uli12us)]

Das hört sich nach nem low-temperature pimp my Pizzaofen to 
smd-soldering an. Man kann natürlich aus allem ne Wissenschaft machen, 
nach meiner Erfahrung brauchts das alles aber nicht. Aktuell klappt das 
zwar nicht, wenn aber die Sonne scheint, dann kann man den Teig auch 
einfach in der abgedeckten Schüssel ins freie stellen. O Wunder, der 
wird trotzdem was,
trotz überhaupt keiner irgendwie gearteten Regelung. Und das ganze auch 
schon seit Jahrtausenden.

[Manfred P. (pruckelfred)]

Uli schrieb:
> Damit kann ich z. B. keine Temperaturkurven fahren, die für
> ambitioniertere BäckerInnen sehr wünschenswert wären, ohne ständig dabei
> sei zu müssen und 'händisch' zu steuern.

Was erwartest Du nun vom Forum?

Eine nachbaufähig fertige Lösung wird hier niemand liefern. Es bleibt 
nur, dass Du Dich selbst mit dem Mikrocontroller und dessen Software 
beschäftigst.

Jedes Wochenende ein kleines Stück:
LED blinken lassen.
Display mit beliebigem Text füllen.
Taster abfragen und im Display anzeigen.
Per Taster Relais ein- / ausschalten.
DS1820 abfragen und Werte im Display zeigen.
... usw

Wenn alle Einzelschritte beherrscht sind, fügst Du diese Stück für Stück 
zur Gesamtanwendung zusammen. So etwa läuft das bei mir, wo sich dann 
über die Zeit erprobte Einzelfunktionen ansammeln, die ich dann kopieren 
kann.

Uli S. schrieb:
> Aktuell klappt das
> zwar nicht, wenn aber die Sonne scheint, dann kann man den Teig auch
> einfach in der abgedeckten Schüssel ins freie stellen. O Wunder, der
> wird trotzdem was,

Schön für Dich, dass Du das nötige Gefühl dafür hast. Bei mir ging 
bislang fast jeder Teig in die Hose, aber eine geregelte Heizung würde 
mich vermutlich auch nicht retten.

[Monk (roehrmond)]

Manfred P. schrieb:
> Bei mir ging bislang fast jeder Teig in die Hose

Falls du dazu Hilfe haben willst  schreibe mir eine PN oder starte einen 
Thread im Off-Topic Bereich. Ich hatte Anfangs viele Fehler gemacht und 
daraus gelernt. Inzwischen habe ich ich ca. 200 Brote erfolgreich 
gebacken und der letzte Fehlschlag ist 2 Jahre her. Vermutlich kann ich 
dir helfen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Manfred P. schrieb:
> Es bleibt nur, dass Du Dich selbst mit dem Mikrocontroller und dessen
> Software beschäftigst.
Ich würde da sogar eher eine fertige Micro-SPS empfehlen. Da bekommt man 
für 150€ die fertige programmierbare Steuerung und kann die "üblichen" 
fertigen Sensoren anschließen. Und wenn damit alles funktioniert, dann 
ist das elektrotechnisch das **Funktionsmodell** (siehe oben).

Und wenn dann eine größere Serie draus werden soll, dann kann man eine 
kundenspezifische µC-Steuerung entwickeln (lassen).

[Uli (uiimcn)]

Uli S. schrieb:
> ...
> O Wunder, der [Teig] wird trotzdem was,
> trotz überhaupt keiner irgendwie gearteten Regelung. Und das ganze auch
> schon seit Jahrtausenden.
Dem stimme ich uneingeschränkt zu.

Wenn du die Anwendung bzw. Anforderungen an die Funktionalität nicht 
hast, kannst du es besser IMHO gar nicht machen. Davon machen wir im 
Allgemeinen viel zu wenig ;-)

Manfred P. schrieb:
> ...
> Was erwartest Du nun vom Forum?
Wie gesagt Hilfe, wenn's klemmt und ggfs. eure erfahrene Sicht auf 
mögliche, mir verborgene Probleme im Entwurf der Steuerung, die mir 
selbst mit allergrösster Sicherheit entgehen werden.

Manfred P. schrieb:
> ...
> Jedes Wochenende ein kleines Stück:
> LED blinken lassen.
> [etc.] ...
> ...
> So etwa läuft das bei mir, wo sich dann
> über die Zeit erprobte Einzelfunktionen ansammeln, die ich dann kopieren
> kann.
> ...
Genau dabei bin ich derzeit und es ist immer gut zu sehen, wenn ich 
nicht komplett danebenliege... Parallel dazu wird der konkrete 
Schaltplan entwickelt.(TinyCAD).

Lothar M. schrieb:
> ...
> Ich würde da sogar eher eine fertige Micro-SPS empfehlen. Da bekommt man
> für 150€ die fertige programmierbare Steuerung und kann die "üblichen"
> fertigen Sensoren anschließen.
> ...
Hmm - wir sind hier nicht 'on the same page'. *Das Gesamtbudget beträgt 
ca. EUR 50,00 -*

Der genaue Überblick fehlt mir zwar, die eingeschlagene Richtung könnte 
dennoch hinhauen ...

Lothar M. schrieb:
> ...
> Und wenn damit alles funktioniert, dann
> ist das elektrotechnisch das **Funktionsmodell** (siehe oben).
> ...
So weit verstanden, danke!

*Noch zur Bäckerei:*

Ohne dort schon länger Mitglied zu sein kann ich das Brotbackforum als 
thematisch limitiertes Forum durchaus empfehlen.
- keine Werbung
- klare Trennung zwischen Firmen betreffenden Inhalten und den Beiträgen 
enthusiastischer Hobby-User
- SEHR viel Fachwissen!
- bereit zum Teilen
- hat natürlich sein eigenes 'Gschmäckle' - es ist sehr klein, gemessen 
am Forum hier

Hier der Link zum Brotbackforum:

https://brotbackforum.iphpbb3.com/forum/index.php?nxu=77934371nx46130

Hier nochmals die Gärbox, wie ich sie mir bis dato vorstelle:

https://brotbackforum.iphpbb3.com/forum/77934371nx46130/anfaengerfragen-f6/kleiner-feiner-gaerautomat-was-soll-muss-er-alles-koennen-t10439.html#p223153

Grüße
Uli

[Uli S. (uli12us)]

Wie gesagt, das sieht für mich aus wie Pimp my Pizzaofen.
Vielleicht solltest du dir mal eine solche SMD-Ofen selbstbausteuerung
ansehen  und die Temperatur einfach runterskalieren, falls das nötig 
sein sollte. Ich hatte noch nie damit zu tun, aber öfters gelesen, dass 
da gewisse Temperaturprofile abgefahren werden. Würde mich nicht 
wundern, wenns dafür auch hier schon ein Dutzend Freds gäbe. Wie gesagt, 
ich weiss nicht,
von wo bis wo die einstellbaren Temperaturen gehen, wär ja vielleicht 
auch möglich, dass man da statt 180° einfach bloss 40° einstellen kann 
und die schön eingehalten werden.

[Manfred P. (pruckelfred)]

Lothar M. schrieb:
> Manfred P. schrieb:
>> Es bleibt nur, dass Du Dich selbst mit dem Mikrocontroller und dessen
>> Software beschäftigst.
> Ich würde da sogar eher eine fertige Micro-SPS empfehlen. Da bekommt man
> für 150€ die fertige programmierbare Steuerung und kann die "üblichen"
> fertigen Sensoren anschließen.

Ich würde mir zutrauen, die Steuerung mit einem Arduino oder ESP 
umzusetzen.

Nachdem ich jahrelang keinen µP mehr angefasst hatte, habe ich 2015 zwei 
China-Uno gekauft. Wie ich an Uli schrieb, habe ich tagelang begrenzt 
sinnvolle Dinge getrieben, mich mit dem Ding vertraut gemacht. Bis die 
Lötstation tatsächlich funktioniert hat, dürften das dreistellige 
Stunden geworden sein.

Er ist offenbar gewillt, sich einzuarbeiten, hat doch auch Zukunft für 
andere Basteleien. Warum also nicht?

Uli schrieb:
> Manfred P. schrieb:
>> ...
>> Jedes Wochenende ein kleines Stück:
>> LED blinken lassen.
>> [etc.] ...
>> ...
> Genau dabei bin ich derzeit und es ist immer gut zu sehen, wenn ich
> nicht komplett danebenliege...

Mit Geduld und ernstem Willen wird das schon. Interessant wird nachher 
der Regelalgorithmus der Temperatur, halbwegs konstant ohne große 
Überschwinger wie am dummen Backofen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uli schrieb:
> Lothar M. schrieb:
>> Ich würde da sogar eher eine fertige Micro-SPS empfehlen. Da bekommt man
>> für 150€ die fertige programmierbare Steuerung
> Hmm - wir sind hier nicht 'on the same page'.
Ja, klar, von uns beiden bin ich der, der schon einige Produkte in 
Einzel- und Serienstückzahlen entwickelt hat... ;-)

> Das Gesamtbudget beträgt ca. EUR 50,00
Für die komplette Eigenentwicklung?
Ganz ohne Witz: vergiss es, das zahlst du letztendlich locker schon an 
Portokosten.

Oder nur für das Endgerät?
Dann ist das kein Problem, nur wird dann eben die Entwicklung teurer.

> Das Gesamtbudget beträgt ca. EUR 50,00
Du hast die Zeit nicht als Kostenfaktor eingerechnet, stimmts?

Oder andersrum: wenn du 10 Stunden brauchst, um selber eine Steuerung 
zusammenzufrickeln (und sei dir sicher: du brauchst garantiert länger), 
dann könntest du stattdessen in dieser Zeit auch zum Mindestlohn beim 
Mägges Burger braten und dir hinterher eine garantiert funktionierende 
Hardware kaufen.

Manfred P. schrieb:
> Ich würde mir zutrauen, die Steuerung mit einem Arduino oder ESP
> umzusetzen.
Ich mir auch. Und ich weiß auch, wie viel Aufwand das ungefähr sein 
wird.

[Uli (uiimcn)]

Manfred P. schrieb:
> ...
> Interessant wird nachher
> der Regelalgorithmus der Temperatur, halbwegs konstant ohne große
> Überschwinger wie am dummen Backofen.
Genau.
Da sehe ich die größten Probleme momentan: die reine Physik.
Turbulente Luftströmung bei sehr kleinen Luft-Geschwindigkeiten.
Ohne Labor kaum zu fassen, wenn überhaupt...

Und dies als Grundlage des Algorithmus ;-)

Mal sehen.

Lothar M. schrieb:
> ...
> Ganz ohne Witz: vergiss es [die Kostenseite], das zahlst du letztendlich locker 
schon an
> Portokosten.
> ...
Die Portokosten sind gut geschätzt! :-)

Nicht  zu vergessen:
Das Ganze ist ein Nicht-Kommerzielles Rentner-Projekt.
Die Arbeitszeit wird nicht angesetzt, potentielle Stückzahlen beim 
Absatz gibt es nicht...

Die Kosten sind auf das Einzelstück nach der Entwicklungszeit 
angesetzt. Der Entwicklungsaufwand (-zeit) spielt keine Rolle.

Das nur zur Einordnung.

Viele Grüße
Uli

[Norbert (der_norbert)]

Uli schrieb:
> Genau.
> Da sehe ich die größten Probleme momentan: die reine Physik.
> Turbulente Luftströmung bei sehr kleinen Luft-Geschwindigkeiten.
> Ohne Labor kaum zu fassen, wenn überhaupt...

'69 sind sie mit weniger Aufwand zum Mond geflogen, gelandet und zurück 
gekommen!

Ok, zugegeben, ohne Sauerteig.

[Uli S. (uli12us)]

Turbulente Strrömung gibts doch bloss bei sehr grossen 
Geschwindigkeiten.
Unterhalb bleibts laminar.

[Norbert (der_norbert)]

Uli S. schrieb:
> Turbulente Strrömung gibts doch bloss bei sehr grossen
> Geschwindigkeiten.
> Unterhalb bleibts laminar.

Nur gut das sich diese Erkenntnis noch nicht in Richtung des 
Flugzeugbaus ausgebreitet hat. ;-)

Zumindest würde das erklären warum eine Tiger Moth fliegt und Cessnas, 
Pipers, usw. kurz nach dem Start sofort abstürzen.

[Uli (uiimcn)]

Uli S. schrieb:
> Turbulente Strrömung gibts doch bloss bei sehr grossen
> Geschwindigkeiten.
> Unterhalb bleibts laminar.

Der hier passende Begriff wäre genauer: wabernd - leider nicht 
wissenschaftlich, so weit mir bekannt.

'Laminar' geht's in der Box jedenfalls nicht zu (von sehr kleinen, 
isoliert betrachteten Raumabschnitten mal abgesehen).

:-)

[Manfred P. (pruckelfred)]

Lothar M. schrieb:
>> Das Gesamtbudget beträgt ca. EUR 50,00
> Für die komplette Eigenentwicklung?
> Ganz ohne Witz: vergiss es, das zahlst du letztendlich locker schon an
> Portokosten.

Sicher? Beim Ali kommt man mit 50€ recht weit.

Lothar M. schrieb:
> Manfred P. schrieb:
>> Ich würde mir zutrauen, die Steuerung mit einem Arduino oder ESP
>> umzusetzen.
> Ich mir auch. Und ich weiß auch, wie viel Aufwand das ungefähr sein
> wird.

Warum wohl erwähnte ich meine Lötstation ".. dürfte dreistellig gedauert 
haben"?

Uli schrieb:
>> Interessant wird nachher
>> der Regelalgorithmus der Temperatur, halbwegs konstant ohne große
>> Überschwinger wie am dummen Backofen.
> Genau.
> Da sehe ich die größten Probleme momentan: die reine Physik.
> Turbulente Luftströmung bei sehr kleinen Luft-Geschwindigkeiten.
> Ohne Labor kaum zu fassen, wenn überhaupt...
>
> Und dies als Grundlage des Algorithmus ;-)

Man muß Messungen machen und sich herantasten.

Uli schrieb:
> Das Ganze ist ein Nicht-Kommerzielles Rentner-Projekt.
> Die Arbeitszeit wird nicht angesetzt, potentielle Stückzahlen beim
> Absatz gibt es nicht...

Ich verstehe auch nicht, warum mir manche Leute fiktive Arbeitskosten 
vorrechnen. Ich kann mir die Eier schaukeln, Fernsehen gucken, Bier 
trinken oder sonstwas, da ist die Zeit doch für eine Bastelarbeit 
weitaus besser angelegt. Die Zeit ist da und kostet nichts.

[Axel S. (a-za-z0-9)]

Uli schrieb:
> Das Ganze ist ein Nicht-Kommerzielles Rentner-Projekt.

Dann mach hin. Vielleicht erlebst dann noch, daß es funktioniert.

Ich backe nun schon seit Jahren selber Brot. Mal mit Sauerteig, mal mit 
Hefe, mal beides. Eine Gärbox habe ich dazu nicht gebraucht. Natürlich 
muß man den Teig ohne Gärbox öfter begutachten. Aber bei 100% Homeoffice 
ist das machbar. Sollte es auch für einen Rentner sein.

Aber wie gesagt: nicht quatschen. Machen!

[Uli (uiimcn)]

Hallo zusammen,

Axel hat das auf den Punkt gebracht:

Axel S. schrieb:
> ... Machen!

Hab die Pin-Zuordnung m. W. jetzt vollständig - sie ist hier als PNG 
angehängt.

Kann sich das jemand von euch anschauen, ob das so machbar wäre?

Falls keine Fallen oder gar Fehler drin sind, baue ich den Schaltplan 
und die ersten praktischen Versuche darauf auf.

Grüße
Uli

Edit:
Dazu noch ein Bild von der NodeMCU.

Edit2:
Die LED läuft nicht wie angegeben über den ESP ...

[Uli (uiimcn)]

Die schematische Abb. im vorherigen Beitrag (RandomNerdTutorials) stimmt 
nicht ganz überein mit der tatsächlichen MCU.

Anbei deshalb die Zuordnung ohne LED und ein soeben gemachtes Foto.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uli schrieb:
> Falls keine Fallen oder gar Fehler drin sind,
Wenn du so viele Pins frei hast, dann leg doch einfach jeden Taster auf 
1 eignen Pin. Dann musst du weniger herumraten, wenn die Tasterkontakte 
nach kurzer Zeit anfangen zu oxidieren.

[Uli (uiimcn)]

Lothar M. schrieb:
> ...
> Wenn du so viele Pins frei hast, dann leg doch einfach jeden Taster auf
> 1 eignen Pin. Dann musst du weniger herumraten, wenn die Tasterkontakte
> nach kurzer Zeit anfangen zu oxidieren.

Hallo Lothar,
so ganz verstehe ich das erst mal nicht.

Ich bin ja froh dass es bisher gereicht hat ohne z. B. den Bootvorgang 
zu gefährden oder mir eine andere kleine 'Katastrophe' einzuhandeln...

1) Genau welche(n) Pin(s) siehst du als 'frei an? Jetzt wird nämlich 
doch noch einer für eine LED benötigt.

2) Mögliche Oxidation der Taster:
Ich sehe da keinen Unterschied zwischen Einzelbelegung mehrerer Pins und 
der gemeinsamen Nutzung des ADC0. Wenn einer nicht mehr schließt, stelle 
ich das ja in beiden Fällen über die Bedienung fest.

Grüße
Uli

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uli schrieb:
> Genau welche(n) Pin(s) siehst du als 'frei an? Jetzt wird nämlich doch
> noch einer für eine LED benötigt.
Ich sehe da 13 Pins mit "GPIOxx" und du brauchst laut deiner Aufstellung 
6+LED:
https://www.mikrocontroller.net/attachment/636625/gpios-pinout.randomnerdTutorials.png

Ergo müssten da noch ein paar Digitaleingänge frei sein...

> Mögliche Oxidation der Taster:
> Ich sehe da keinen Unterschied zwischen Einzelbelegung mehrerer Pins und
> der gemeinsamen Nutzung des ADC0. Wenn einer nicht mehr schließt, stelle
> ich das ja in beiden Fällen über die Bedienung fest.
Nimm mal an, du hast 4 Taster, von denen jeder einen zufälligen 
Übergangswiderstand mit 0..2k hat.

Du siehst: Wenn du die in einem Spannungsteiler zuverlässig auswerten 
willst, wird der Spannungsteiler unglaublich hochohmig. Und die 
schlechte Kontaktgabe wird noch schlechter, weil du die Frittspannung 
und den nötig Frittstrom dann sicher nicht mehr erreichst und die Taster 
noch scheller "altern".

Wenn du jeden Taster aber über einen 10k Pullup an einzelne Digitalpins 
anschließt, dann wird jede Betätigung noch sicher erkannt.

Das Thema mit "Mehrfachbetätigung" kommt da noch dazu: was, wenn du 
schlechter werdende Taster hast und 2 davon drückst? Wird diese 
Betätigung dann zufällig als der dritte Taster erkannt?

Probiers einfach aus, du kommst drauf: Taster über Spannungsteiler 
einzulesen ist Käse.

[Uli (uiimcn)]

Lothar M. schrieb:
> ...
> Ergo müssten da noch ein paar Digitaleingänge frei sein...
> ...
Hallo Lothar,
das ist Konjunktiv ;-) - ich wollte ja wissen welche, da es doch 
einige gibt, die nur mit Vorsicht verwendet werden können. Dazu brauchts 
dann wiederum mehr Erfahrung und Wissen, als ich hab...

Lothar M. schrieb:
> ...
> Probiers einfach aus, du kommst drauf: Taster über Spannungsteiler
> einzulesen ist Käse.
Danke, das werd ich nun nicht mehr versuchen. Es lohnt sich nicht für 
meinen Bedarf, verwende nun  den D5-Pin für die LED und ADC0 für nur 
einen einzigen Taster.

Der eigentliche aktuelle Anlass ist:

Ich stehe so richtig auf dem Schlauch und hoffe schwer auf eure 
Steigbügel...

Bevor ich etwas anwenden kann, möchte ich das einigermaßen verstehen.
Was ich bis jetzt auch nach sehr vieler Sucherei nicht gefunden habe 
sind die Zusammenhänge um OLED_RESET, benötigt für das Statement: 
display.begin(SH1106_I2C_ADDRESS, OLED_RESET).

Was ist das, wo finde ich das (einen Wert z. B.), wessen Eigenschaft ist 
das, falls es eine ist???

Gedanken dazu:
1) Es gibt am 128*64 I2C-OLED selbst keinen so bezeichneten Reset-Pin, 
sondern nur die 4 üblichen I2C-pins.
2) Ein Reset des OLEDs kann eigentlich nur durch ein Signal von 
display.begin() an das OLET selbst ausgelöst werden, falls ich richtig 
vermute.

Kann mir da einer von euch helfen? Ich bin mir ja nicht mal im Klaren 
darüber, welche Informationen dazu benötigt werden.

Hänge in echt fest...

Viele Grüße
Uli

[Monk (roehrmond)]

Uli schrieb:
> Es gibt am 128*64 I2C-OLED selbst keinen so bezeichneten
> Reset-Pin, sondern nur die 4 üblichen I2C-pins.

Dann halt nicht. Wenn das Display hängt: Stromversorgung aus und wieder 
ein schalten.

Der Chip hat einen Reset Eingang. Da war den Chinesen wohl der Pin am 
Modul zu teuer, um ihn heraus zu führen.

[Uli (uiimcn)]

Monk schrieb:
> ... Wenn das Display hängt: Stromversorgung aus und wieder
> ein schalten.
>
> Der Chip hat einen Reset Eingang. ...

Falls ich dich richtig verstehe:

Was bringt dir ein Reset mit demselben 'OLED_RESET'? --> Einen erneuten 
Neustart...

Dazu kommt, dass ich bisher keinen einzigen 4-PIN OLED Chip mit 5 Pins 
gesehen habe...

[Monk (roehrmond)]

Uli schrieb:
> Was bringt dir ein Reset mit demselben 'OLED_RESET'?

Wenn das Display hängt, kannst du es zurücksetzen - falls du eine Reset 
Leitung zum Controller hast.

Die Bibliothek lässt dir die Wahl, über einen I/O Pin einen Reset-Impuls 
an den Displaycontroller zu senden oder dich alleine auf den Power-Up 
Reset zu verlassen. Das ist ein gängiges Pattern für Displays bei 
Adafruit.

"Reset pin (using Arduino pin numbering), or -1 if not used (some 
displays might be wired to share the microcontroller's reset pin)."

https://github.com/adafruit/Adafruit_SH110x/blob/master/Adafruit_SH110X.cpp

[Rbx (rcx)]

Früher ging so was mit einer 30w Glühlampe in einer Kiste ganz gut.
Bei Joghurt geht auch heiß isolieren und unter die Bettdecke packen.
Pizzateige brauchen einen ganzen Tag und nur wenig Hefe bei etwa 
Zimmertemperatur, da kommt es aber darauf an, dass der Außenrand nicht 
so verhärtet.
Grundsätzlich braucht man Erfahrung*, und die bekommt man nicht mal eben 
per Lichtschalter oder Suchmaschine - und kann die später in den Aufbau 
der automatischen Steuerung einfließen lassen.

Hobbythek - Brot einmal nicht vom Bäcker
https://www.youtube.com/watch?v=itaRwg2Xiek

*die Überprüfung der nötigen Erfahrung kann man elektronisch aufbauen: 
rot, gelb, grün :)
Zitat aus der Nachhilfe: "je mehr ich weiß, desto klarer wird mir, wie 
wenig ich weiß".

[Uli (uiimcn)]

Hallo Monk,
danke dir!

Hab das jetzt (hoffentlich) etwas besser kapiert...

Nur zum Verständnis der Programm-Umgebung:
Es geht um eine absichtlich weitgehend 'blinde' ERROR-Funktion, die so 
autark wie möglich laufen soll.

Die Funktion weiss deshalb nicht, ob und welche Geräte bzw. 
Möglichkeiten (LED, Piepser, OLED, Serial) für eine ERROR-Signalisierung 
zur Verfügung stehen.
Es geht also nicht darum, z. B. ein absichtlich 'von außen' 
herbeigeführtes RESET zu machen.

Zur Sache selbst:
Ich möchte in der Funktion ein RESET an einem 4-Pin OLED versuchen, 
unabhängig von dessen aktuellem Status.
Das Einzige, was mir dabei jetzt noch nicht klar genug ist, ist die 
Frage, ob Pin4 (=SDA) an der OLED auch ein RESET-Signal vom 
display-Objekt verstehen würde.
Ein Wert von -1 beim Aufruf von display.begin(SH1106_I2C_ADDRESS, -1) 
ist dabei ein Signal an das display-Objekt selbst: Kein RESET versuchen 
oder verwenden.

Jetzt bleibt nur noch offen:
Versteht das 4-Pin OLED an Pin4 auch ein RESET-Signal, obwohl es dafür 
nicht vorrangig eingerichtet ist?

Entscheidend scheint das im vorliegenden Fall nicht zu sein, es wäre 
aber gut zu wissen!

Jedenfalls waren deine Ausführungen sehr hilfreich für mich:

Monk schrieb:
> ...
> Die Bibliothek lässt dir die Wahl, über einen I/O Pin einen Reset-Impuls
> an den Displaycontroller zu senden oder dich alleine auf den Power-Up
> Reset zu verlassen. Das ist ein gängiges Pattern für Displays bei
> Adafruit.
>
> "Reset pin (using Arduino pin numbering), or -1 if not used (some
> displays might be wired to share the microcontroller's reset pin)."
>
> https://github.com/adafruit/Adafruit_SH110x/blob/master/Adafruit_SH110X.cpp

Viele Grüße, danke
Uli

[Uli (uiimcn)]

Rbx schrieb:
> ...
> Grundsätzlich braucht man Erfahrung*, ...

Grundsätzlich stimme ich dir zu - du brauchst mit einer 'schlauen' und 
vor allem verlässlichen Gärbox nur deutlich weniger Erfahrung mit den 
Heizköpern, dem Bett, deinen Socken etc. ;-)

Grüße Uli

[Monk (roehrmond)]

Uli schrieb:
> Das Einzige, was mir dabei jetzt noch nicht klar genug ist, ist die
> Frage, ob Pin4 (=SDA) an der OLED auch ein RESET-Signal vom
> display-Objekt verstehen würde.

Sicher nicht. Du musst dich schon an das Anschluss-schema des Display 
Moduls halten und die Software dazu passend konfigurieren.

[Uli (uiimcn)]

Monk schrieb:
> Uli schrieb:
>> Das Einzige, was mir dabei jetzt noch nicht klar genug ist, ist die
>> Frage, ob Pin4 (=SDA) an der OLED auch ein RESET-Signal vom
>> display-Objekt verstehen würde.
>
> Sicher nicht. Du musst dich schon an das Anschluss-schema des Display
> Moduls halten und die Software dazu passend konfigurieren.

Hallo Monk,
so sicher bin ich mir da mangels bisherigen eigenen Versuchen absolut 
noch nicht. Ohne den/die Links jetzt zu suchen gibt es welche, die genau 
das so sagen: Reset Signal an Pin4/SDA senden. Werds irgendwann probiert 
haben und berichten.

@Alle:

Aktueller Status:
- Erste Programmierung und Zusammenstellung der Hardware.

Eine LED und ein Piepser sind bereits kontrollierbar :-)

*Mein aktuelles Problem*:

Wo bringe ich eine eigene Bibliothek unter so, dass Arduino IDE diese 
auch findet?
Auch darüber gibt es soooo viele verschiedene Angaben (Betriebssysteme 
etc.). Weiter Rumsuchen wäre für mich noch extrem aufwendig - u. U. auch 
für Programmierer... (z. B. hier: 
https://forum.arduino.cc/t/how-to-add-an-include-file-to-ide-build-path/1194657/18).

Habt ihr einen guten Vorschlag, wo eine solche am Besten untergebracht 
wird? (WIN10, Nutzerverzeichnis 'ArduinoIDE'. Das habe ich auch noch 
gefunden auf dem PC:

C:\Program Files 
(x86)\CodeBlocks\share\CodeBlocks\templates\wizard\arduino\files\librari 
es\libraries.cpp

Viele Grüße
Uli

[Ralf G. (ralg)]

Uli schrieb:
> Wo bringe ich eine eigene Bibliothek unter

Am Einfachsten: Die Quelldateien deiner selbst programmierten Bibliothek 
einfach in den Ordner deines jetzigen Projektes kopieren.

[Georg (Gast)]

Kurt A. schrieb:
> Wenn es dem Teig zu kalt ist

Unsinn, die Hefe wärmt sich genau wie sies braucht.

Hefen gabs schon vor den Planzen und Tieren und überleben sogar im 
kühlen Weinkeller. Das ist aber vielen Lebewesen immanent implizit usw. 
etc. -

RESPEKT dem Uli sein Projekt,

wenn das fertig ist, dann ab in die Höhle der Löwen zum vermarkten des 
neuesten und allerbesten Brotteigs der Welt ...

[Norbert (der_norbert)]

Georg schrieb:
> Unsinn,

Zu diesem mehrere Wochen alten Thread kommst du etwas zu spät.

Im Grunde genommen ist bereits alles gesagt worden…

…nur nicht von jedem…

[Georg (Gast)]

Norbert schrieb:
> Im Grunde genommen ist bereits alles gesagt worden

Unsinn.

Das bestimmst Du sicher nicht, geh schlafen und träum weiter...

Du hast mich in der Bearbeitungsfrist einfach nur unnötig unterbrochen.
Zudem darf ich als neuer User sowieso nur alle halbe Stunde schreiben.

Reagier nicht automatisch wie ein Pavlovścher Hund auf alles was neu 
bellt und gut ist... also dann die Überarbeitung kopiert und nach dieser 
halben Stunde darfst auch Du wieder Deinen Unsinn zu meinem gerne dazu 
bellen.

Kurt A. schrieb:
> Wenn es dem Teig zu kalt ist

hat ihn die Oma samt Topf eine halbe Stunde unter die Bettdecke, denn
Hefe wärmt sich genau wie sies braucht. Eine Styroporbox tuts auch, 
Elektronik ist überflüssig wie Kropf, daher OT richtig,

Hefen gabs schon vor den Planzen und Tieren und überleben sogar im 
kühlen Weinkeller. Das ist aber vielen Lebewesen immanent implizit usw. 
etc. -

RESPEKT dem Uli sein Projekt,

wenn das fertig ist, dann ab in die Höhle der Löwen zum vermarkten des 
neuesten und allerbesten Brotteigs der Welt ...

----
Nachtrag- wer auch immer das war, danke für meine Erstbewertung,

ob ich mich jemals wieder melde ist fraglich bei dem rauen Ton, als Wolf 
fresse ich auch Hunde wenns nur solche gibt...

[Uli (uiimcn)]

Ralf G. schrieb:
> ...
> Am Einfachsten: Die Quelldateien deiner selbst programmierten Bibliothek
> einfach in den Ordner deines jetzigen Projektes kopieren.

Hallo Ralf,
danke für den Tip!

Für meinen aktuellen Bedarf ist das jedoch keine Lösung.

Es gibt mehrere 'Projektordner' in der ArduinoIDE mit unterschiedlichen 
Funktionen für die Steuerung. Alle sollen aktuell auf gemeinsame 
Precompiler-Declarations zugreifen können, die hauptsächlich als 
Alternative zu globalen Werten verwendet werden.

Georg schrieb:
> ...
> RESPEKT dem Uli sein Projekt,
> ...

Danke! Sehen kann man allerdings noch nicht viel - das 'Zuckerl' soll 
wie gesagt insbesondere auch beim Menue liegen - das wird sicher noch 
einige Zeit dauern, wie ich mich so kenne...

Grüße
Uli

[Uli (uiimcn)]

Hallo zusammen,

sehen kann man immer noch nicht viel - aber das muss ich euch zeigen. 
Mich hat es fast umgehauen.

Zur Vorgeschichte:
C/C++ war mir SEHR fremd, und, hätte ich gewusst was da auf mich 
zukommt, vielleicht hätte ich es gelassen, wie das eben so ist im 
Leben...

Aber, jetzt gibts ja auch noch ChatGPT (keine Diskussion jetzt bitte, 
auch diese kommt frühestens etwas später).

In Kooperation mit ChatGPT entwickle ich also die SW für die Gärbox (ich 
denke nach, mache den kreativen Teil, stelle die 'richtigen' Fragen, die 
KI antwortet, schreibt code, ich prüfe, etc. ...)

Das aktuelle Thema war und ist: Prüfung / Zählung der Darstellungslänge 
eines strings, welcher auch Umlaute (zwei byte intern) enthalten kann. 
Und dies bereits während des Kompilierens. Dazu nun ein 
Lösungsvorschlag der KI, die 'gewollt' einen Beispiel-String produziert 
hat, der auch Umlaute enthält. Nur wie sie das gemacht hat - irre, zum 
Umfallen ...

Hier der komplette code, viell. interessiert das ja jemanden, der dies 
bisher nicht versucht hat.

Die Antwort war also nicht 42, sondern:

#include <Arduino.h>
#include <U8g2lib.h>
#include <cstring>  // For std::strlen

// Initialize the display with I2C connection
U8G2_SSD1306_128X64_NONAME_F_HW_I2C u8g2(U8G2_R0, /* reset=*/ U8X8_PIN_NONE);

// Define maximum characters per line and number of lines
const int MAX_CHARS_PER_LINE = 21;
const int MAX_LINES = 3;

// Function to calculate the display length considering specific multi-byte characters
constexpr size_t display_length(const char* str) {
    size_t len = 0;
    for (size_t i = 0; str[i] != '\0'; ++i) {
        if ((str[i] & 0xC0) == 0xC0) {  // Check if it's the start of a multi-byte character
            ++i;  // Skip the next byte of the multi-byte character
        }
        ++len;
    }
    return len;
}

// Macro to check string length at compile-time
#define CHECK_LINE_LENGTH(line) static_assert(display_length(line) <= MAX_CHARS_PER_LINE, "Line exceeds maximum allowed length!")

// Messages to be displayed
const char* line1 = "This is line one"; // OK
const char* line2 = "This is Äline twö"; // OK
const char* line3 = "This line is way too long and should cause a compile error"; // Exceeds limit

// Apply the check to each line
CHECK_LINE_LENGTH(line1);
CHECK_LINE_LENGTH(line2);
CHECK_LINE_LENGTH(line3);

void setup() {
  // Initialize the display
  u8g2.begin();
}

void loop() {
  // Clear the display buffer
  u8g2.clearBuffer();

  // Draw each line on the display
  u8g2.drawStr(0, 12, line1);
  u8g2.drawStr(0, 24, line2);
  u8g2.drawStr(0, 36, line3);

  // Send the buffer to the display
  u8g2.sendBuffer();

  // Delay to control the display refresh rate
  delay(1000);
}

Man beachte die Zeile: /const char* line2 = "This is Äline twö"; // OK/

Alles Andere später...
Uli

[Uli (uiimcn)]

Hallo zusammen,
aller Anfang ist schwer - so kann man das ohne rot zu werden sagen...

Ich bin dabei, das Gerüst des Programms (ja, das Gerüst...) als Gesamtes 
zu kompilieren und verstehe noch wenig von den Gesamt-Zusammenhängen und 
vor allem jetzt von den Compilermeldungen.

Der Output ist natürlich so viel dass ich nicht weiss, wo anfangen...

1) Die Ursache z. B. von dem hier könnte einfach sein:

warning: unused variable 'selfName' [-Wunused-variable]
    3 |     const char* selfName = "02.scaffold_configure_GPIOs.h()";   /* Set self name */
      |                 ^~~~~~~~

Ist der Compiler hier tatsächlich so freundlich mir zu sagen, dass die 
Variable selfName (im aktuellen Code) nirgendwo genutzt bzw. 
referenziert wird? Das entspräche ja den Tatsachen.

Ich versteh's trotzdem nicht.

Solcherart Meldungen kommen an einer ganzen Reihe von Stellen mit 
unterschiedlichen Variablemnnamen.

Hat jemand von euch einen hilfreichen Tip wie das zu verstehen bzw. zu 
interpretieren ist?

Grüße
Uli

[Cyblord -. (cyblord)]

Uli schrieb:
> Zur Vorgeschichte:
> C/C++ war mir SEHR fremd, und, hätte ich gewusst was da auf mich
> zukommt, vielleicht hätte ich es gelassen, wie das eben so ist im
> Leben...

Ja so ist das Leben. Hat man keine Ahnung von C++ Programmierung hat man 
Probleme mit C++ Programmierung.
Wer hätte es gedacht?

Also dann setz dich hin und übe. Les Bücher. Les Tutorials. Mach 
irgendwas. Aber stress hier nicht alle mit jeder Fehlermeldung deines 
zum scheitern verurteilten Projekts.

[Klaus (feelfree)]

Uli schrieb:
> Ist der Compiler hier tatsächlich so freundlich mir zu sagen, dass die
> Variable selfName (im aktuellen Code) nirgendwo genutzt bzw.
> referenziert wird?

Genau das.

Uli schrieb:
> Ich versteh's trotzdem nicht.

Doch, du bist des englischen offenbar mächtig und hast die Warnung 
verstanden.

[Monk (roehrmond)]

Du bekommst diese Warnungen, weil der Compiler mit einem entsprechenden 
Parameter aufgerufen wurde. Entweder direkt -Wunused-variable (oder 
einen Sammel-Parameter wie z.B. -Wall der dieses Flag enthält). Ohne 
diesen Parameter würde er dich nicht warnen.

Siehe https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

Ich benutze in der Regel -Wall, um auf möglichst viele potentielle 
Fehler aufmerksam zu werden. Dann ändere ich den Code so, dass der 
Compiler keine Warnungen mehr ausgibt, auch an unkritischen Stellen und 
wo ich der Meinung bin, dass der Compiler sich geirrt hat. Das kostet 
ein bisschen zusätzliche Arbeitszeit, vermeidet aber spätere Probleme.

[Rbx (rcx)]

Uli schrieb:
> Hat jemand von euch einen hilfreichen Tip wie das zu verstehen bzw. zu
> interpretieren ist?

Das Problem, das du nicht siehst ist: Gerade am Anfang gibt es 
Verständnisprobleme, etwas Wirrwarr man kann durcheinanderkommen, man 
findet aber auch Möglichkeiten zum Vertiefen und Lernen. Diese Phase zu 
überwinden, ist viel effektiver und angenehmer, wenn du ein paar 
Grundlagen lernst, mit den üblichen Angeboten diesbezüglich, zuerst den 
Compiler, den Linker und/oder die Bibliotheken und den Arbeitstisch 
(Editor, IDE, Debugger, Disassembler, sonst noch..),  ordentlich 
einrichten, hier und da ein Algo, hier und da eine Bibliothek nutzen 
oder selber erstellen. Es gibt so einige Tricks und Kniffe der 
Programmierung - die bekommst du vor allem im Zusammenhang mit den 
Grundlagenkurs mit.
Was du hier versuchst ist, z.B. logische Zusammenhänge mit extralanger 
Bitbreite zu lernen. Viel einfacher ist es, kniffelige Fragen 
diesbezüglich auf 1, 2 oder 3 Bit anschaulichkeitshalber zu begrenzen.
Bei Kryptogeschichten kann das ein wenig anders laufen - aber auch da 
gibt es Kurse wie der C-Kurs von K+R, die laden gerade zu dazu ein, sich 
an Kryptoproblemen zu versuchen. Vorausgesetzt, man hat verstanden und 
gut verarbeitet, was die Autoren vermitteln wollten.

Das interagiert alles miteinander unter der Überschrift: Grundkurs - man 
kann aber auch darauf verzichten und in Internetforen die unsinnigsten 
C-Programme bei einfachen Fragen/Problemen posten, wo man sich als Leser 
dann fragt: "das geht doch gar nicht?! (also so ein Unfug) - aber 
scheinbar ja doch(immer wieder).

Lass dir doch von diesem Chat-Robbie gerade diese fundamentalen 
Grundkenntisse vermitteln. Das macht bestimmt auch Spaß.

[Uli (uiimcn)]

Ralf G. schrieb:
> Uli schrieb:
>> Wo bringe ich eine eigene Bibliothek unter
>
> Am Einfachsten: Die Quelldateien deiner selbst programmierten Bibliothek
> einfach in den Ordner deines jetzigen Projektes kopieren.

_Etwas zurückgreifend:_

Hallo Ralf,

danke nochmals für den Tip - jetzt gehe ich doch den einfachsten Weg 
nach deinem Vorschlag!

Zum Mitschreiben für andere Anfänger oder 'Seiteneinsteiger' wie mich:

Eigene Headerdateien oder Bibliotheken, auf englisch 'Custom Libraries', 
können in der Arduino IDE auf dem einfachstmöglichen Weg wie folgt 
eingebunden werden:
1) Im 'libraries' genannten Unterordner des jeweiligen Projektordners 
einen weiteren Unterordner mit dem Namen der einzubindenden Headerdatei 
oder Bibliothek erzeugen (jedoch ohne die Dateiendung .h oder 
Ähnlichem!)

2) In diesen neu erzeugten Ordner die Datei einfügen (diesmal 
vollständig, einschließlich der Dateiendung!)

Danach steht diese eigene Datei zum Einbinden in das Programm zur 
Verfügung.

_An Alle, zur einfacheren Verortung meines kleinen Projekts:_

ALLE meine Projekte habe ich auf Basis derselben Herangehensweise 
gemacht: 'In das Wasser springen und daran arbeiten', gemäß dem 
Sprichwort 'Jack of all trades, master of none.'
Nur in einem Fall klappte das nicht so richtig, als ich nach Jahren 
feststellen musste, dass es für das Problem des nach außen abnehmenden, 
optimalen Anstellungwinkels eines modernen Windradflügels keine 
geschlossene mathematische Lösung gibt ... danach hatte ich auch das 
ausreichend begriffen... ;-:

Klaus schrieb:
> Uli schrieb:
>> Ist der Compiler hier tatsächlich so freundlich mir zu sagen, dass die
>> Variable selfName (im aktuellen Code) nirgendwo genutzt bzw.
>> referenziert wird?
>
> Genau das.
>

Hallo Klaus,

danke für die Bestätigung, sie hat mir geholfen, etwas Ordnung in das 
aktuelle Chaos zu bringen! Jedes Detail dazu hilft sehr.
Diesen Komfort gab es vor vielen Jahren noch nicht - hatte bereits 
begonnen darüber nachzudenken, wie ich das am Besten bewerkstellige (der 
'Jack' halt in diesem Fall)...

Monk schrieb:
> Du bekommst diese Warnungen, weil der Compiler mit einem entsprechenden
> Parameter aufgerufen wurde.
> ...
> Ich benutze in der Regel -Wall, um auf möglichst viele potentielle
> Fehler aufmerksam zu werden. ...

Hallo Monk,

danke für die Info!

Zu mehr als der Einstellung von Optionen betr. der 'Verbosität' des 
Compilers in der IDE bin ich allerdings nicht in der Lage - das genügt 
mir für diesen Zweck auch.
Ansonsten kann ich nur zustimmen:
Stabilität und 'Sauberkeit' des Codes ist auch mir extrem wichtig, um 
viele evtl. später auftauchende Fehler von Anfang an zu vermeiden.

Rbx schrieb:
> ... Das Problem, das du nicht siehst ...
> ...
> Lass dir doch von diesem Chat-Robbie gerade diese fundamentalen
> Grundkenntisse vermitteln.

Hallo Rbx,

danke für Deine Zeit, du hast (fast?) alle Probleme im aktuellen Chaos 
mit viel Arbeit zusammengefasst! Bin mir glücklicherweise der Meisten 
davon bewusst.

Die KI jedenfalls werde ich nicht nach den 'falschen' Dingen fragen - 
sie raubt mir sonst noch die wenige, begrenzte Zeit, und den Nerv dazu 
;-)
Sie ist allerdings bereits gut zu gebrauchen als Enzyklopädist und 
Schreiberling, wenn die Fragen/Anforderungen passend gestellt werden.

*Zum Abschluss für heute:*

Das modular, flexibel angelegte Gerüst für ein Arduino/ESP8266 - 
Programm wollte ich bereits letztes Wochenende einstellen - jetzt wird's 
halt noch etwas dauern.

Für manchen Anfänger ist das dann auch sicherlich zu gebrauchen, denke 
ich.

Viele Grüße
Uli

[Sheeva P. (sheevaplug)]

Uli schrieb:
> C/C++ war mir SEHR fremd, und, hätte ich gewusst was da auf mich
> zukommt, vielleicht hätte ich es gelassen, wie das eben so ist im
> Leben...

Hm, komisch. Ein Großteil dessen, was in C++ gemacht wird, gilt doch 
auch schon in C als guter Stil. ich meine, man muß doch wohl nicht 
gleich damit anfangen, Operatoren zu überladen oder eigene Templates zu 
entwickeln?

Vielleicht magst Du ja mal erklären, was und warum Dich an C++ so 
irritiert. Hier gibt es großartige und extrem kompetente Leute wie 
Wimalopaan (sp?), die Dir sicherlich gerne helfen.

[Sheeva P. (sheevaplug)]

Monk schrieb:
> Ich benutze in der Regel -Wall,

hystel -Wextra -Wpedantic... ;-)

[Monk (roehrmond)]

Sheeva P. schrieb:
> man muß doch wohl nicht gleich damit anfangen, Operatoren
> zu überladen oder eigene Templates zu entwickeln?

Exakt.

Leider stößt man dann beim Lernen manchmal auf Programmbeispiele, die 
man mangels Know-How nicht versteht. Das ist die Kehrseite der Medaille, 
nicht nur bei C++.

Eine Programmiersprache absichtlich primitiv zu machen (wie Go) ist aber 
auch keine dauerhaft bessere Lösung. Damit arbeite ich zur Zeit 
beruflich und muss sagen, dass ich die Vereinfachung keineswegs als 
Erleichterung empfinde. Wegen "fehlender Features" muss ich an wenigen 
Stellen hässliche Workarounds bauen. Wegen fehlender Exceptions 
programmiere ich mir einen Wolf zur Fehlerbehandlung, da praktisch jede 
Funktion einen error zurück liefern kann. Das ist nur anders (und 
angeblich moderner) aber nicht besser.

Glaube mir, C/C++ ist gar nicht so schlecht. Es hat schon seinen Grund, 
warum diese Programmiersprachen so lange überlebt haben und immer noch 
Vorbild für andere sind.

[Rbx (rcx)]

Monk schrieb:
> Leider stößt man dann beim Lernen manchmal auf Programmbeispiele, die
> man mangels Know-How nicht versteht. Das ist die Kehrseite der Medaille,
> nicht nur bei C++.

Wobei es vor dem didaktischen Hintergrund gut ist, den mehr abstrakten 
Teil von C++ gleich am Anfang mit einzuflechten. Die Templates sind 
eigentlich ein Stichwort für den fortgeschrittenen Teil - welcher 
standardmäßig von den Meyers Büchern beflügelt wird.
C++ soll ja vor allem auch bei der Roboter-Programmierung dominant sein, 
habe ich mir sagen lassen. Eine Gärbox, die auch Fussballspielen kann, 
oder nach Musik gefällig tanzen, wäre wirklich mal was anderes.

[Uli (uiimcn)]

Sheeva P. schrieb:
> Uli schrieb:
>> C/C++ war mir SEHR fremd, ...
>
> Hm, komisch. Ein Großteil dessen, was in C++ gemacht wird, gilt doch
> auch schon in C als guter Stil. ...

Hallo Sheeva,
so langsam begreife ich, dass mit C/C++ lediglich die 'modernere', 
objektorientierte Programmiersprache gemeint ist und ich diese Abkürzung 
bisher 'verkehrt' verwendet habe...

Weder mit C, noch mit C/C++ hatte ich bisher Berührung. Nur 
interpretierte Sprachen, und das eher gelegentlich...

[Monk (roehrmond)]

Uli schrieb:
> so langsam begreife ich, dass mit C/C++ lediglich die 'modernere',
> objektorientierte Programmiersprache gemeint ist

Nein, das ist falsch.

C und C++ sind zwei unterschiedliche Programmiersprachen. C++ kam später 
und baut auf C auf. Es gibt aber kein C/C++. Der Schrägstrich bedeutet 
je nach Kontext "und" oder "oder". Er ist nicht Bestandteil des Namens.

[Uli (uiimcn)]

Monk schrieb:
> ...
> C und C++ sind zwei unterschiedliche Programmiersprachen. ...

Danke Dir!

@All:
Bisher kam ich ja mit viel Geduld einigermassen vorwärts mit 
Hilfestellung des Enzyklopädists und Schreiberlings ChatGPT.

Das zusammenhängende KnowHow bzw. die Übersicht eines Kenners der 
Materie kann es natürlich nicht ersetzen.

Habe Vieles versucht und bin hier keinen Millimeter weitergekommen:
(Programmieren tu ich immer in Englisch)

Nach Einfügen von

  // Constructor to initialize keyValueSettings
  ButtonPress(PublicKeyValuePairs& keyValueSettings) : 
    keyValueSettings(keyValueSettings) {}

und

    // Reference to key-value settings
    PublicKeyValuePairs& keyValueSettings;

in eine Klasse streikt der Compiler.
Die erste Meldung diesbezüglich ist:

...07.scaffold_button_presses.h:12:34: error: expected ')' before '&' token
   12 |   ButtonPress(PublicKeyValuePairs& keyValueSettings) :
      |              ~                   ^
      |                                  )

Als erster Anhaltspunkt liegt die Datei bei, welche den Fehler 
verursacht.

Hoffe sehr, dass jemand von euch helfen kann bei der Suche bzw. 
Identifikation dieses Fehlers (der liegt höchstwahrscheinlich in einer 
falschen Syntax).

Falls Weiteres benötigt wird bevor Ratschläge gemacht werden können, 
bitte lasst mich das wissen!

Grüße
Uli

[Uli (uiimcn)]

Hallo zusammen,
das Problem hat sich erledigt.

Inzwischen hatte ich wegen zusätzlicher Funktion einen anderen Weg 
gewählt, auf welchem dies nicht mehr aufgetreten ist :-)

Viele Grüße
Uli

[Uli (uiimcn)]

Hallo @Alle,

bis jetzt hatte ich das Thema globale Variablen (=böse), defaults und 
user-settings erfolgreich hinausgezögert...

Nun, gegen Ende der Fertigstellung des Programm-Gerüsts MUSSTE ich 
dieses entscheiden.

Weil die dafür erstellte Klasse universell verwendbar ist, stelle ich 
sie hier als erstes Modul zur Verwendung auch für andere, rein private 
Zwecke, ein.

Die Lizenz für alle hier eingestellten Arbeiten ist eine
*Creative Commons, Attribution-NonCommercial-ShareAlike International, 
CC BY-NC-SA 4.0, https://creativecommons.org/licenses/by-nc-sa/4.0/*

*Zur Klasse selbst:*

*1)* In der Klasse selbst gibt es eine Unterscheidung zwischen 
konstanten DEFAULTS und variablen User-Settings. Für den User gibt es 
diesen Unterschied nicht.

*2)* Zugegriffen wird auf alle Werte mit einem Schlüssel-Namen ohne das 
Präfix "DEFAULT_". Die Klasse handhabt dann die Werte entsprechend der 
Konzept-Logik.

*3)* Alle DEFAULTs sind innerhalb der Klasse selbst vorzugeben, alle 
variablen User-Settings werden jeweils mit LittleFS (Kleines Filesystem) 
auf den Flash-Speicher geschrieben.

*4)* Wird kein Wert in der Liste der User-Settings gefunden, wird der 
default verwendet.

*Zu ChatGPT:*

Die KI bzw. AI hat die meiste Schreib- und Kodierarbeit geleistet gemäß 
meiner Aufgabenstellung, Konzept-Logik, Pseudo-Code etc.
Ohne die KI hätte ich nicht die Geduld, den Sketch sauber reinzutippen! 
So wurden dann die KI-Vorschläge genutzt, die Logik etc. kontrolliert 
und ggfs. angepasst sowie der Stil für mich als Anfänger editiert.

Eine Klasse für Defaults und User-Settings wird in fast allen Sketches 
benötigt - ich hoffe deshalb sehr, dass diese Grundlage von Anderen auch 
genutzt werden kann.

Von der Seite der Software her sehe ich momentan keine Hürde dazu.

Viele Grüße
Uli

P.S.: JEDE Anmerkung ist sehr willkommen und wird ggfs. in die Klasse 
eingebaut. In diesem Fall wird der Urheber selbstverständlich in den 
Danksagungen (Credits) aufgeführt!

[Monk (roehrmond)]

"Mit KI erstellt" wirkt auf mich ähnlich reizvoll wie "mit 
Separatorenfleisch".

Das define für die LED wird in der loop ignoriert (nicht verwendet).

Welchem Zweck dienen dreifach wiederholte Kommentare?

Das Konzept, bei jedem Zugriff auf Settings nach dem Key als String zu 
suchen und dann ggf. nochmal mit Default-Prefix, gefällt mir nicht. Das 
ist sehr ineffizient. Sowas dürfte ich auf der Arbeit nicht mal auf 
großen Cloud Systemen machen.

Effizienter wären Strukturen (Klassen), deren Zugriffe vom Compiler 
aufgelöst werden, anstatt zur Laufzeit zu suchen.

[Uli (uiimcn)]

Monk schrieb:
> ... wie "mit Separatorenfleisch". ...

Oder 'Analogkäse' ...

Du rennst bei mir grösstenteils offene Tore ein - kann erst später 
darauf eingehen...

[Monk (roehrmond)]

Denke auch an Typ-Konvertierung. Jedes mal, wenn du einen Integer 
brauchst, must du den konvertieren (String -> Integer).

[Uli (uiimcn)]

Hallo Monk!

Nur kurz zu deinen Stichworten:

ChatGPT

... war und ist für mich leider die einzige Möglichkeit, das Projekt 
noch in der verbliebenen Restzeit meines Lebens zu schaffen...
(Das beantwortet natürlich nicht das Wohl oder Wehe von KI...)

LED

... war 'ne Notlösung, überhaupt eine Reaktion der MCU erkennen zu 
können. Irgendwie funktioniert gerade der serielle Monitor nicht.
Die drei kopieren Zeilen hatten jedenfalls die beabsichtigte Wirkung ;-)

Effizienz (v. a. Geschwindigkeit)

So dramatisch sehe ich das nicht momentan.
Viel wichtiger sind mir die Grundsätze einer KISS Herangehensweise (Keep 
It Simple and Stupid).

Konkreter:
- Das Lesen der Werte im Normalablauf ist definitiv schnell genug!
Auch während des Startens ist das m. E. nach kein Problem. Es sind nicht 
viele Werte zu erwarten.

- Das Schreiben variabler Werte geschieht nur dann, wenn der Nutzer 
gelegentlich eine Einstellung ändert. Falls in diesem Fall bis zu 
einer Sekunde mehr benötigt würde, ist das zu verschmerzen.
Der Aufwand zur Optimierung der File-Leseoperationen scheint nicht im 
Verhältnis zum Ertrag zu stehen (s. KISS)

Was ich verm. überhaupt nicht verstanden habe:
Wie könnten Precompiler Directives für variable Settings verwendet 
werden?

ToDo:
Möglicherweise können noch komplette Checks entfallen - das ist erstmal 
aufgeschoben..

Viele Grüße

Uli

[Monk (roehrmond)]

Uli schrieb:
> Wie könnten Precompiler Directives für variable Settings verwendet
> werden?

Das ist die falsche Frage. Deine Settings sind nicht wirklich Variabel. 
Zum Zeitpunkt der Compilierung stehen Anzahl und Namen bereits fest. 
Wenn du die dafür vorgesehenen Mittel der Programmiersprache (struct, 
class) nutzen würdest, könnten die teuren String-Operationen und der 
damit verbundene Speicherplatz "einfach so" entfallen

[Uli (uiimcn)]

Monk schrieb:
> ... Das ist die falsche Frage. Deine Settings sind nicht wirklich Variabel. ...

Ok, jetzt verstehe ich das etwas besser.

Es gibt jeweils zwei _in ihrer inhaltlichen Bedeutung bzw. Verwendung 
identische_ Elemente (bzw. Labels, Namen), die einen sind Konstanten, 
die anderen Variablen.

1) Defaults, konstant

2) Nutzer-Settings, variabel, welche die entsprechenden defaults dann 
priorisieren, wenn es ein entsprechendes Setting gibt.

Um nun alles am selben Ort innerhalb der einen Klasse zu haben, werden 
die defaults zum Zeitpunkt der Instantitierung / Initialisierung aus der 
Klasse selbst in die map eingelesen. Diese defaults könnten als 
#define(s) festgelegt werden, was ich in diesem Fall aus o. g. Gründen 
nicht haben möchte.

Grüße

Uli

[Monk (roehrmond)]

Deine Scheu vor globalen Variablen (bzw. Objekten) halte ich für 
unangemessen. Solange es nur eine zentrale Konfiguration für das System 
gibt, ist eine globale Variable sinnvoll, denn sie bildet die Realität 
ab.

Eventuell helfen verschachtelte Strukturen, das ganze ordentlich zu 
kapseln. Die zentrale Config könnte eine Struktur oder Klasse sein, 
welche die Konfigurationen aller Subsysteme bündelt. Struktur und 
Defaults der Subsysteme könnte in den jeweiligen Header Dateien der 
Subsysteme definiert sein.

Settings enthält:
  WifiConfig
  UartConfig
  MotorConfig

Diese drei Objekte enthalten so viele Variablen, wie nötig, sowie 
entsprechend viele getter, die ggf. Defaults zurück geben:

GetBaudrate():

if baudrate==0 
  return 19200
else
  return baudrate

Das ist leicht zu verstehen und erzeugt kompakten Code.

Die Initialisierungsroutine vom seriellen Port würde die Config etwa so 
bekommen:

serialPort = new Uart(settings.UartConfig)

Das geht in jeder Programmiersprache so ähnlich.

[Uli (uiimcn)]

Danke Dir!

Werde noch sehen, genau wie diese grundlegenden Strukturen und Werte 
dann am Besten implementiert werden. Dies ggfs. umzuschreiben wäre dann 
nicht allzu viel Aufwand.

Erlaube mir noch eine Frage in diesem Zusammenhang:

Wie und wo schreibt und liest man in einem Sketch für eine ESP8266-MCU 
üblicherweise solche 'variablen' Nutzer-Settings (um für mein 
Verständnis erst mal bei dieser Laien-Sprache zu bleiben)?

[Chris S. (schris)]

Z.b EEPROM.get(0,&settings)
if(settings.ok!=1) settings=DEFAULT_SETTING;

Zum Speichern
EEPROM.put(0,&settings)
EEPROM.Commit()

[Sheeva P. (sheevaplug)]

Monk schrieb:
> Leider stößt man dann beim Lernen manchmal auf Programmbeispiele, die
> man mangels Know-How nicht versteht. Das ist die Kehrseite der Medaille,
> nicht nur bei C++.
>
> Eine Programmiersprache absichtlich primitiv zu machen (wie Go) ist aber
> auch keine dauerhaft bessere Lösung. Damit arbeite ich zur Zeit
> beruflich und muss sagen, dass ich die Vereinfachung keineswegs als
> Erleichterung empfinde. Wegen "fehlender Features" muss ich an wenigen
> Stellen hässliche Workarounds bauen.

Ach, ich weiß nicht. Einerseits gibt es da ein paar wirklich nervige 
Sachen an Go, das stimmt,und manchmal muß man mit Workarounds arbeiten, 
die sicher keine Schönheitspreise gewinnen. Aber obwohl ich jetzt erst 
seit einem guten halben Jahr mit Go arbeite, hat die Einfachheit auch 
etwas für sich -- zum Beispiel, daß ich in Go bisher noch keine 
Programmbeispiele gesehen habe, die ich wegen fehlenden Know-Hows nicht 
sehr schnell verstanden hätte.

In moderneren Versionen von C++ passiert es mir hingegen immer noch, daß 
ich eine Weile für mein Verständnis brauche, obwohl ich bald über 
dreißig Jahre mal mehr, mal weniger intensive Erfahrungen damit 
gesammelt habe. Wenn ich so an die eine oder andere Boost-Library [1] 
denke oder ans Web Toolkit Wt [2] (unten im Link findet man deren "Hello 
World")... Klar: daß ich seit vielen Jahren viel zu selten mit C++ 
arbeite, spielt dabei sicher eine Rolle, aber verglichen mit dem C++ der 
frühen Neunziger, das ich mal gelernt habe, ist es eine andere Sprache. 
Und das sage nicht ich, sondern Bjarne selbst. :-)

Verglichen mit C++ bin ich in Go aber trotz allem viel schneller. Okay, 
in Python bin ich nochmals... aber das ist natürlich kein seriöser 
Vergleich, denn Python ist nunmal (meistens) eine interpretierte 
Skriptsprache und mit Flask oder FastAPI zur Laufzeit gegen Go eine 
ganze Größenordnung langsamer.

[1] https://www.boost.org/doc/libs/
[2] https://www.webtoolkit.eu/wt/doc/tutorial/wt.html

> Wegen fehlender Exceptions
> programmiere ich mir einen Wolf zur Fehlerbehandlung, da praktisch jede
> Funktion einen error zurück liefern kann. Das ist nur anders (und
> angeblich moderner) aber nicht besser.

Ja, das gehört unbedingt zu den nervigeren Teilen von Go, genauso wie 
das Einbinden eigener Bibliotheken, die mitunter kruden 
Template-Sprachen, die manchmal häßlichen Closures zur Vermeidung von 
Globals, und ein paar andere Dinge. Na klar, das kann man alles 
hinbekommen, oft sogar halbwegs elegant, aber es kostet halt oft viel 
Boilerplate. Aber dafür ist es offensichtlich, eindeutig und mit ein 
bisschen Übung auch sehr gut lesbar.

> Glaube mir, C/C++ ist gar nicht so schlecht. Es hat schon seinen Grund,
> warum diese Programmiersprachen so lange überlebt haben und immer noch
> Vorbild für andere sind.

Dem möchte ich mich unbedingt anschließen. C++ ist eine wundervolle 
Sprache und extrem mächtig, und wer den Sprachkern verstanden hat, dann 
damit nicht nur sehr leistungsfähige Software entwickeln, sondern seine 
Kenntnisse auch auf andere Sprachen anwenden.

Beim TO hingegen weiß ich nicht so genau, ob das so eine gute Idee ist, 
nicht nur die ganzen Hardwaregeschichten, sondern dabei gleichzeitig 
auch noch eine nicht ganz einfache Programmiersprache wie C++ zu lernen, 
und dabei auch noch mit, naja: nicht immer ganz einfachen Protokollen 
wie 1-Wire zu arbeiten. Das würde ich erstmal mit einem Raspi oder 
ähnlichen SBC anfangen, auch wenn das zweifellos Overkill ist. Aber wenn 
der Prototyp läuft, kann man sich in Ruhe darum kümmern, die ganze 
Veranstaltung effizienter zu machen und zum Beispiel auf Arduino oder 
eine eigene Hardware zu portieren. YMMV. :-)

[Sheeva P. (sheevaplug)]

Monk schrieb:
> C und C++ sind zwei unterschiedliche Programmiersprachen.

*HÜSTEL!* :)

[Monk (roehrmond)]

Uli schrieb:
> Wie und wo schreibt und liest man in einem Sketch für eine ESP8266-MCU
> üblicherweise solche 'variablen' Nutzer-Settings

Ich würde die gespeicherten Werte normalerweise in setup() lesen und 
nach jeder Änderung abspeichern.

[Uli (uiimcn)]

*Im Moment geht nix mehr. Gar nix.* ... ... ... ... ...

Um wieder halbwegs festen Boden unter die Füße zu bekommen bitte ich 
euch um allgemeinverständliche Begriffs- und Funktionsklärungen.

Dazu stelle ich in meinen Worten das zusammen, was ich mir momentan so 
denke bzhw. so zusammenspekuliere...

Betr. Speicherarten bzw. Bereiche in einer NodeMCU
- Boot-Bereich (hier negiert)
- Flash-Speicher

-- Ist der Speicher erster Priorität für die Ablage des Programmcodes

-- Der Programmcode wird ab der Adresse 0 / null des Flash-Speichers 
aufwärts gespeichert

-- Der Speicherbereich für den Programmcode ist 1MB groß, unabhängig 
davon, ob der phyische Speicher gößer ist

-- Bei einer NodeMCU berägt die Flash-Speichergröße 4MB (das stimmt bei 
meiner NodeMCU mit der per SW ausgelesenen Größe überein)

- EEPROM (komplett unklarer Bereich)

-- Physisch soll ein EEPROM 512Kb haben (?)

-- Bei einer NoceMCU gibt es verm. kein physisches EEPROM, es wird 
lediglich emuliert, falls überhaupt...

-- Hat mich ein EEPROM überhaupt zu interessieren?

- EEPROM.h (hier wirds richtig lustig...)

-- Greife ich mit EEPROM.h de facto auf den Flash-Speicher zu, obwohl es 
EEPROM.h heisst???

-- Vergesse ich also am Besten den Namen der Bibliothek?

-- Kann ich mittels EEPROM.h auf alle Speicherbereiche innerhalb der 4MB 
zugreifen?

Falls niemand etwas gegen meine Spekulationen bzw. Phantasierereien hat, 
hat sich das evtl. über Nacht etwas sortiert... - jetzt versuche ich 
erst mal, die Steckerleiste an die 4-Pin OLED zu löten. Oh mei..

Beste Grüße

Uli

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uli schrieb:
> Um wieder halbwegs festen Boden unter die Füße zu bekommen bitte ich
> euch um allgemeinverständliche Begriffs- und Funktionsklärungen.
Du hast umfassende Lücken beim Verständnis deines µCs und der 
Programmierung desselben. Was soll man da raten? Arbeite dich in das 
Thema ein. Der ESP ist zum Start in die µC-Technik allerdings ein sehr 
harter, großer und schwer verdaulicher Brocken. Zudem findet sich viel 
halbgare Dokumentation und viele schlechte Beispiele (die die KI dann 
als Grundlage für ihren erzeugten Code hernimmt...).

> -- Greife ich mit EEPROM.h de facto auf den Flash-Speicher zu
Nein, die EEPROM.h enthält nur die Namensdefinitionen. Sie ist wie ein 
Adressbuch, das sagt, welche Funktionen in der EEPRO.cpp "wohnen" und 
wie sie  aufgerufen werden müssen.

> Der Speicherbereich für den Programmcode ist 1MB groß
Wenn deine Gärboxsteuerung auch nur 20% dieses Speichers belegt, dann 
ist der Code recht ineffizient programmiert.

[Uli (uiimcn)]

Lothar M. schrieb:
> ... Arbeite dich in das
> Thema ein. ...
Darum  geht es ja

Lothar M. schrieb:
> Zudem findet sich viel halbgare Dokumentation und viele schlechte Beispiele (die 
die KI dann als Grundlage für ihren erzeugten Code hernimmt...). ...
Genau

Lothar M. schrieb:
> ... EEPROM.h enthält nur die Namensdefinitionen. Sie ist wie ein
> Adressbuch, das sagt, welche Funktionen in der EEPRO.cpp "wohnen" und
> wie sie  aufgerufen werden müssen.
Ja, gut und soweit bekannt. Ich muss ja nicht zwingend etwas über eine 
EEPROM.cpp wissen. Zunächst genügt mir das Einbinden per #include - wenn 
sie denn das bietet, was ich gene hätte.

> ... Wenn deine Gärboxsteuerung auch nur 20% dieses Speichers belegt, dann
> ist der Code recht ineffizient programmiert.
Das hat momentan keine praktische Bedeutung für das Projekt

Nochmals zum aktuell entscheidenden Thema, etwas länger bzw. anders 
ausgedrückt:
- Ist die EEPROM.h nun irreführend benannt und trotz des NAmens auch 
dazu geeignet und geschrieben, mittels der in der EEPROM.h enthaltenen 
Klassen(-Namen, -Definitionen, was auch immer) den Flash-Speicher 
schreiben und lesen zu können?
Wenn nein, welche Bibliothek schlagt ihr dazu vor? Habe bisher nichts 
sicher Passendes gefunden, direkte Speicherzugriffe auf den 
Flash-Speicher auszuführen. Und darum geht es, wenn serielle, langsame 
Zugriffe vermieden werden sollen.
- Ist die Flash-Speichernutzung fest definiert (festgelegt) auf 1MB (aus 
den gesamten 4MB) für den Programmcode?

Chris S. schrieb:
> Z.b EEPROM.get(0,&settings)
> if(settings.ok!=1) settings=DEFAULT_SETTING;
> ...
Das war der Auslöser für die Hoffnung und Verzweiflung (Haare rauf...)

Ohne konkretere allgemeinverständliche Aussagen komme ich da nicht viel 
weiter im Grundverständnis der entscheidenden Zusammenhänge.

Bitte verzeiht - bin wohl wirklich an der Grenze...

[Uli (uiimcn)]

Zwischendurch mal was Anderes:

OLED verlötet, verdrahtet, angesteuert, geflasht -> Auf Anhieb voller 
Erfolg:

Die OLED sagt Hello!

Jetzt habe ich außer der LED auch ein OLED, um mehr Infos ausgeben zu 
können (Serieller Monitor funktioniert ja z. Zt. nicht) und bin sicher, 
ggfs. genauere Fragen stellen zu können, falls es beim direkten 
Speicherzugriff weiter so hakt.

Bis bald
Uli

[Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)]

Nach dem ich den ganzen Thread überflogen habe, vermisse ich ein Bild 
vom ersten Backergebnis.

Uli schrieb:
> - Heizdraht

Statt Heizdraht, würde ich hier Peltier-Elemente vorschlagen um etwas 
Strom fürs Heizen zu sparen. Auf die Warm- und auf die Kaltseiten ließe 
sich je ein Kühlkörper einer CPU mit Lüfter plazieren.

Wenn Du Stromrichtung durch die Peltierelemente umdrehst, kannst Du die 
Box zwischezeitlich als (Reise)Kühlbox fürs Bier verwenden. Mit dünnen 
Kabeln in einem Kühlschrank ohne Gefrierfach hineingestellt, wird das 
eine Eisbox/Gefrierbox.

[Chris S. (schris)]

Arduino eeprom code 10k commits oder Änderungen, eeprom kann auch 4k 
sein.
ESP_EEPROM bei 204 Byte Eeprom 200k , bei 408 Byte sind es 100k. Es 
werden 8byte an Verwaltungsstruktur gebraucht und die Page ist 4k. 
Eeprom_rotate sind es bei 4M Flash 4pages und je Page werden 3byte zur 
Verwaltung gebraucht, macht wenn ich beim obigen Beispiel bleibe 
anstelle von 200k sind es dann 800k. Wenn man wie beschrieben für das 
OTA die zwei Zeilen reingibt dann kann man anstelle von 4 Pages 8 
benutzen und die 800k verdoppeln sich und werden 1600k . Weiters gibt es 
noch eine Lib welche den Speicherplatz auch inkrementelle updated. Dies 
jetzt alles ohne die Sector Formatierung zu ändern.
Aber Achtung, im neuen SDK wird für das Eeprom ein nvm pair blob 
verwendet, was einen Rückschritt im Vergleich zu den externen libs 
darstellt.

[Klaus (feelfree)]

Chris S. schrieb:
> Arduino eeprom code 10k commits oder Änderungen, eeprom kann auch 4k
> sein.
> ESP_EEPROM bei 204 Byte Eeprom 200k , bei 408 Byte sind es 100k. Es
> werden 8byte an Verwaltungsstruktur gebraucht und die Page ist 4k.
> Eeprom_rotate sind es bei 4M Flash 4pages und je Page werden 3byte zur
> Verwaltung gebraucht, macht wenn ich beim obigen Beispiel bleibe
> anstelle von 200k sind es dann 800k. Wenn man wie beschrieben für das
> OTA die zwei Zeilen reingibt dann kann man anstelle von 4 Pages 8
> benutzen und die 800k verdoppeln sich und werden 1600k . Weiters gibt es
> noch eine Lib welche den Speicherplatz auch inkrementelle updated. Dies
> jetzt alles ohne die Sector Formatierung zu ändern.
> Aber Achtung, im neuen SDK wird für das Eeprom ein nvm pair blob
> verwendet, was einen Rückschritt im Vergleich zu den externen libs
> darstellt.

Interessant!
Aber was wolltest du mit deinem wohl strukturierten, didaktisch 
herausragend ausgearbeiteten und leicht verständlichen Beitrag nun 
eigentlich sagen?

[Uli (uiimcn)]

Dieter D. schrieb:
> ... Statt Heizdraht, würde ich hier Peltier-Elemente vorschlagen um etwas
> Strom fürs Heizen zu sparen.

Hallo Dieter,
bevor ich mir einen freien Tag von dieser schweren Arbeit nehme ;-) 
muss ich doch noch nachfragen:

Habe ich dich richtig verstanden?

Wenn ich Wärme aus Strom haben will, ist ein passives Element, das den 
Strom mit einem Wirkungsgrad von 100% einfach 'verbrät' (hier: 
Heizdraht) nicht zu schlagen.

Unter gar keinen Umständen von einem Peltier-Element.

Gruß

Uli

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uli schrieb:
> Wenn ich Wärme aus Strom haben will, ist ein passives Element, das den
> Strom mit einem Wirkungsgrad von 100% einfach 'verbrät' (hier:
> Heizdraht) nicht zu schlagen.
Es ist prinzipiell schnurzegal, wie die die elektrische Energie in Wärme 
umwandelst. Die Hautpsache ist, dass diese Wärmeenergie dorthin kommt, 
wo du sie brauchst.

> Unter gar keinen Umständen von einem Peltier-Element.
Wenn dieses Peltrierelement auf einem Kühlkörper hängt, dann taugt es 
nicht zum heizen. Denn ein Peltierelement ist (egal ob mit oder ohne 
Strom) ein guter Wärmeleiter. Es lässt die Innenwärme also recht gut 
durch auf den Kühlkörper aussen.

Aber generell ist ein Peltierelement eine Heizung, die die elektrische 
Energie in Wärme umwandelt, dafür zum Dank aber auf einer Seite ein paar 
Grad kälter wird. Wenn du die heiße Seite also nicht abkühlst, dann ist 
dein Peltierelement z.B. auf der heißen Seite 80°C warm und auf der 
kalten Seite nur 60°C (20°C weniger). Wenn du es schaffst, die heiße 
Seite auf 25° Zimmertemperatur abzukühlen, dann hat sie kalte Seite 5°C 
(20°C weniger).

Fazit: zum Heizen ist ein Peltierelement nur sinnvoll, wenn es komplett 
in der Heizkammer liegt. Ohne Kühlkörper nach daussen an die 
Umgebungsluft. Dann nur dann bleibt die komplette aus Strom in Wärme 
gewandelte Energie im Heizraum. Und es juckt die erzeugte Wärme auch 
nicht, dass das Peltierelement auf einer Seite ein wenig kälter ist...

Uli schrieb:
> Ist die EEPROM.h nun irreführend benannt und trotz des NAmens auch dazu
> geeignet und geschrieben, mittels der in der EEPROM.h enthaltenen
> Klassen(-Namen, -Definitionen, was auch immer) den Flash-Speicher
> schreiben und lesen zu können?
Kurz: ja, sie ist dafür vorgesehen, Werte, die sich so gut wie nie 
ändern, dauerhaft zu speichern. Der Flashspeicher wird verwendet, um ein 
EEPROM nachzubilden. Mit signifikanten Einschränkungen: in einem EEPROM 
kannst du meist jede einzele Speicherzelle adressieren und löschen, und 
das bis zu 1Mio mal. In einem Flash gibt es größere Blöcke, die gelöscht 
werden und jeder überlebt das nur 10000 Schreibzyklen.
Wenn du 10 Werte hast, die beim Programmstart nacheinander geschrieben 
werden, wird der Block bei jedem Programmstart 10 mal gelöscht und eben 
nur 1000 Einschaltzyklen überleben.

> Wenn nein, welche Bibliothek schlagt ihr dazu vor?
Die EEPROM.h ist nur die Spitze des Eisbergs. Dazu gehört eben auch ein 
Sourcecode und/oder eine aus dem Sourcecode erzeugt Bibliothek. Und der 
Compiler bzw. der Linker sorgen dann dafür, dass anhand des Namens und 
der Difinition, die du aus der Headerdatei verwendest, der passende 
(Object-)Code zur endgültigen Binärdatei dazugenommen wird.

Aber nochmal: du hast absolut keine Ahnung, wie die Toolchain aus 
Präprozessor, Complier, Assembler und Linker funktioniert. Von daher 
wird es auch nichts bringen, wenn ich dich mit Fachwörtern zutexte. Ich 
weiß nicht, was daran so unheimlich schwer ist, sich wie zigmillionen 
Anderer in die Grundlagen dieser Programmiersprache und ihrer Toolchain 
selbständig einzuarbeiten?

[Manfred P. (pruckelfred)]

Lothar M. schrieb:
> Die EEPROM.h ist nur die Spitze des Eisbergs.

Wozu braucht er die überhaupt? Ich habe die in meiner Lötstation, dort 
kann ich per Drehencoder die Temperatur verstellen und dauerhaft 
ablegen. Hätte ich mir sparen können, wenn ich ein Drehpoti verbaut 
hätte.

In einer PWM-Steuerung mit geringen Genauigkeitsanforderungen habe ich 
zwei Drehpotis, die liest der Arduino ein und fertig. Weil es der evtl. 
kritisch warm werden kann, habe ich NTC und Lüfter am Kühlkörper - die 
drei Schwellwerte stehen im Programmcode und fertig, dafür brauche ich 
kein EEPROM.

Lothar M. schrieb:
> Ich weiß nicht, was daran so unheimlich schwer ist,
> sich wie zigmillionen Anderer in die Grundlagen
> dieser Programmiersprache und ihrer Toolchain
> selbständig einzuarbeiten?

Ich auch nicht.

Uli schrieb:
> Manfred P. schrieb:
>> ...
>> Jedes Wochenende ein kleines Stück:
>> LED blinken lassen.
>> [etc.] ...
>> ...
>> So etwa läuft das bei mir, wo sich dann
>> über die Zeit erprobte Einzelfunktionen ansammeln, die ich dann kopieren
>> kann.
>> ...
> Genau dabei bin ich derzeit und es ist immer gut zu sehen, wenn ich
> nicht komplett danebenliege...

Das war vor 8 Wochen und ich lese nichts, was auf eine strukturierte 
Arbeitsweise hin deutet, also einzelne Bröckchen ausarbeiten und testen.

[Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)]

Uli schrieb:
> Wenn ich Wärme aus Strom haben will, ist ein passives Element, das den
> Strom mit einem Wirkungsgrad von 100% einfach 'verbrät' (hier:
> Heizdraht) nicht zu schlagen.
>
> Unter gar keinen Umständen von einem Peltier-Element.

Zusätzlich zur Wärme durch die Eigenerwärmung, wird auch Wärme von Außen 
nach Innen importiert. Somit läge der Wirkungsgrad bei 120...130%. Diese 
Wärme wird aber dem Raum entzogen in dem dann das Gerät steht und über 
die Wärmeverluste der Box wieder in den Raum zurückgegeben.

Noch besseren Wirkungsgrad würde natürlich eine Wärmepumpe haben.

Wobei ich eine Autokühlbox mit Peltierelement besitze und wenn ich die 
als Gärbox verwenden wollte, bräuchte ich nur nur das Netzteil umpolen. 
D.h. eine Box mit Heißdraht selber zu bauen entfällt damit komplett. 
Wenn so eine Box bei Dir nicht zufällig steht, wird man nicht ein paar 
zehn Euronen für Peltierelement ausgeben, außer eine Kühlbox sollte auch 
noch gebaut werden.

[Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)]

Um ein Kilo Teig um 10 Grad zu erwärmen, wirst Du rund 10 Wh an Wärme 
einbringen in die Box. Du darfst daher vorher berechnen, wie groß die 
Teigmenge maximal sein soll und wie lange die Aufheizzeit dauern darf. 
Wobei der Teig aber auch kein guter Wärmeleiter ist und damit die 
Aufheizzeiten bereits lange sind, die Leistung aber nicht weiter 
hochgefahren werden kann, weil sonst der Teig an der Oberfläche bereits 
gart statt gärt.

[Joachim B. (jar)]

Manfred P. schrieb:
> ich lese nichts, was auf eine strukturierte
> Arbeitsweise hin deutet

hihi, wer mag denn noch arbeiten, ich gestehe ich auch nicht mehr!

[Uli (uiimcn)]

Moin zusamen!

Zuerst:
Meine Schwierigkeiten betr. Kommunikation lassen sich leider nicht 
einfach ausräumen. Dazu kommt, dass meine Arbeits- und Herangehensweise 
grundsätzlich und fallabhängig mal chaotisch, unstrukturiert, mal 
pedantisch, übergenau ist.

Um nun die restlich verbliebenen Klarheiten auch noch zu beseitigen, 
hier eine etwas umfassendere Zusammenstellung des aktuellen 
Projektstands ;-)

*Die Gärbox (Soll-Funktionen):*

Ist beschrieben hier: 
https://brotbackforum.iphpbb3.com/forum/77934371nx46130/anfaengerfragen-f6/kleiner-feiner-gaerautomat-was-soll-muss-er-alles-koennen-t10439.html#p223153

*HW Steuerungs-Komponenten:*

(Auf eine Auflistung wird an dieser Stelle verzichtet)

*Schaltplan:*

Erstellung mit TinyCAD. Soweit bisher ersichtlich ohne nennenswerte 
Hindernisse. Wird zu passender Zeit eingestellt.

*PIN-Zuordnung:*

Siehe aktualisierte Abb.

*Steuerungsprogramm:*

... Konzepte:

Gesamtprogramm: Das modulare Konzept steht weitgehend. Es umfasst das 
(sehr wichtige) Programmgerüst, das Menue (MMI-Interface) sowie die 
Aufteilung der Aufgaben und Funktionen auf einzelne Headerdateien.

... Stand Programmgerüst:

Die einzelnen Headerdateien sind derzeit:
- 01.precompiler_drectives.h (keine Unklarheiten vomn Bedeutung)
- 02.scaffold_configure_GPIOs.h (dto.)
- 03.(deprecated)
- 04.scaffold_communication_protocols.h (dto.)
- 05.scaffold_oled_print.h (ist für die Anzeige von längeren Texten noch 
ziemlich aufwendig programmiert. Evtl. finde ich dafür noch eine 
geeignete Bibliothek, ODER, die genutzte U8g2 bietet bereits solche 
Möglichkeiten. Bisher nicht weiter untersucht.)
- 06.scaffold_errorhandling.h
- 07.scaffold_button_presses.h
- 08.scaffold_key_value_pairs.h (Dabei bin ich gerade. Knackpunkt1 ist 
die Abwägung von KISS-Prinzipien gegen Effektivität: Sequentielle gegen 
indizierte Speicherung von gelegentlich veränderbaren Werten. 
Knackpunkt2 ist mein sich erst langsam aufhellendes Verständnis der 
Speicherarten , der geeigneten Bibliotheken sowie der zur Verfügung 
stehenden Methoden für read/write Zugriffe auf 'den' Speicher)
- 09.measure_button_bouncing.h (Mach ich dann um zusehen, wie das bei 
den Billig-Tastern genauer aussieht...)
- (Sobald das Gerüst sicher genug steht, geht es an die Benutzer-, 
Steuerungs- und Sicherheitsfunktionen selbst)

Die Reihenfolge und Funktionsaufteilung der Headerdateien kann sich noch 
etwas ändern.

Auf einige der vorhergegangenen Punkte gehe ich in einem zweiten Beitrag 
ein.

Viele Grüße

Uli

[Joachim B. (jar)]

Uli schrieb:
> Um nun die restlich verbliebenen Klarheiten auch noch zu beseitigen

Ich brauche mehr Details, schreiben Sie es auf, ich werde es mir später 
durchlesen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uli schrieb:
> Die Reihenfolge und Funktionsaufteilung der Headerdateien kann sich noch
> etwas ändern.
Die Reihenfolge von Headerdateien sollte bei anständig programmierten 
Headern völlig unwichtig sein.

> scaffold_communication_protocols
Du musst nicht unbedingt in Englisch programmieren. Statt "scaffold" als 
englisches Wort für "Grundgerüst" nimmt man in der SW-Entwicklung 
normalerweise "framework".

> Sobald das Gerüst sicher genug steht
Mit Headerdateien baut man kein "Gerüst" auf. Headerdateien sind in etwa 
der Unwichtigste Teil eines Programms. Sie enthalten keine Struktur und 
keine Funktion. Bestenfalls werden darin Steuerwerte für die bedingte 
Compilierung definiert. Sowas wie bedingte Compilierung braucht dein 
"Mikroprojekt" aber garantiert nicht, weil es keine mehrfachen 
"Gärboxsteuerungsvarianten" hat.

> measure_button_bouncing.h (Mach ich dann um zusehen, wie das bei den
> Billig-Tastern genauer aussieht...)
Du denkst dir da eine besondere Lösung für ein "Pseudoproblem" aus. Der 
Praktiker entprellt die Tasten einfach in 5 Zeilen mit 100ms und fertig.

[Joachim B. (jar)]

Lothar M. schrieb:
> Der
> Praktiker entprellt die Tasten einfach in 5 Zeilen mit 100ms und fertig

Praktiker hin oder her, ich liebe PeDas 10ms Entprellroutine bullet 
proof und nutze die überall wo sie gebraucht wird -> AVR und ESP32

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Joachim B. schrieb:
> ich liebe PeDas 10ms Entprellroutine
Wenn die im 10ms Interrupt aufgerufen wird, entprellt sie für 30ms. Und 
die eigentliche Entprellung hat nur 5 Zeilen, der Rest ist Wrapper für 
die Auswertung... ;-)

[Uli (uiimcn)]

Hallo zusammen,

jetzt möchte ich noch auf mir wesentlich erscheinende Punkte und 
zurückliegende Beiträge eingehen, um das Ganze hoffentlich etwas weiter 
abzurunden.

*Das Wie und Wo des Speicherns gelegentlich geänderter Einstellungswerte 
(User-Settings)*

Das 'Wie' bezieht sich dabei auf für diesen Zweck geignete Bibliotheken 
bzw. deren zur Verfügung gestellte Methoden, das 'Wo' bezieht sich dabei 
a) auf einen geeigneten Speicherbereich des Flash-Speichers und b) eine 
eventuelle 'Rotation' bez. Verschiebung desselben innerhalb des bei mir 
4MB großen Speichers, um einem vorzeitigen Verschleiß desselben 
vorzubeugen.

*Zu Wie.a):*

Hier geht es um entweder sequentiellen Zugriff auf in einer Datei 
gespeicherte Daten (z. B. mittels LitteFS) oder direkten bzw. 
indizierten Direkt-Zugriff auf spezifische, indizierte Speicherbereiche.

Da mir die anfallende Menge solcherart Daten noch nicht ausreichend 
bekannt ist bzw. ich diese noch nicht ausreichend abgeschätzt habe, 
lässt sich hier eine passende Entscheidung noch kaum treffen.

*Zu Wie.b)*

Darauf treffen ähnliche Überlegungen zu. Insbesondere die Frage, wie 
häufig solche Flash-Speicherbereiche verm. einen write-Zugriff 
'aushalten' müssten. Davon abhängig wiederum ist zu entscheiden, ob das 
Memory-Management z. B. 'Rotation' oder 'Verschiebung' beinhalten 
sollte.

Darunter fällt dann auch die Fragestellung, mit welcher(n) 
Bibliothek(en) / Methoden können einzelne Byte-Bereiche im Speicher oder 
lediglich (größere) Speicherblöcke beschrieben werden.

Bei der voraussichtlich nicht sehr großen Zahl solcher variabler Daten 
kann evtl. auf solcherart, dem KISS-Prinzip nicht sehr nahe stehende 
Methoden verzichtet werden und anstelledessen ausschliesslich die 
Methoden aus der LittelFS-Bibliothek genutzt werden.

Betr. LittleFS ist mir gestern erst aufgefallen, dass es eine 
file.seek() Methode geben könnte! Viell. bietet diese Methode die 
gewünschten Funktionalität!? (Ist als Nächstes zu untersuchen)

Soeben finde ich die Bibliothek Preferences, verm. geeignet zum 
Abspeichern von Key-Value Datenpaaren.

Es ist bei meinem Kenntnisstand einfach noch zu früh zu entscheiden, 
welche Möglichkeiten die wohl geeignetsten sind. Insbes. da auch eine 
über das Key-Value Prinzip hinausgehende Verwendung von variablen Daten 
noch nicht ausgeschlossen ist.

Das ist erstmal abgelegt. Bis dahin wird LittleFS (ggfs. auch ausschl. 
sequentiell), verwendet.

*Mein allg. Kenntnisstand, 'beste' Dokumentation*

Bessert sich allmählich ...

Nachdem ich auf 
https://arduino-esp8266.readthedocs.io/en/stable/index.html gestossen 
bin sowieso! ;-)

Lothar M. schrieb:
> ...
> Aber nochmal: du hast absolut keine Ahnung, wie die Toolchain aus
> Präprozessor, Complier, Assembler und Linker funktioniert.

Keine Sorge, die Morgendämmerung naht ;-)

Wichtig bleibt eine allgemeinverständliche Sprache, soweit das dem Thema 
gemäss machbar ist.

Jedenfalls reichen mir die aktuellen Kenntnisse betr. Preprocessor und 
Compiler aus, Assembler(-Code) brauch ich eh nicht zu verstehen und der 
Linker wird schon wissen, was er tut...

Lothar M. schrieb:
> ...
> Ich weiß nicht, was daran so unheimlich schwer ist, sich wie zigmillionen
> Anderer in die Grundlagen dieser Programmiersprache und ihrer Toolchain
> selbständig einzuarbeiten?

Wie kommst auf den Eindruck nicht selbständig?

Der praktische Fortschritt

Manfred P. schrieb:
> ... ich lese nichts, was auf eine strukturierte Arbeitsweise hin deutet, also 
einzelne Bröckchen ausarbeiten und testen.

Funktioniert ja ziemlich gut auf diese Art, es ist jedoch eher selten zu 
erkennen. Alle in der Zusammenfassung erwähnten Teilbereiche sind 
größtenteils lauffähig ausprobiert, auch auf der HW.

Diverses
Joachim B. schrieb:
> ... Ich brauche mehr Details, schreiben Sie es auf, ich werde es mir später 
durchlesen.

?

Lothar M. schrieb:
> ... Die Reihenfolge von Headerdateien sollte bei anständig programmierten
> Headern völlig unwichtig sein.
Ja, ist so. Die Numerierung dient vorrangig meinem Gedächtnis

Lothar M. schrieb:
> ... Du musst nicht unbedingt in Englisch programmieren. Statt "scaffold" > als 
englisches Wort für "Grundgerüst" nimmt man in der SW-Entwicklung
> normalerweise "framework".
Ja, ist klar. Hatte mit disesm unüblichen Begriff angefangen und bisher 
nicht geändert. Das Englische betreffend: Deutsch ist zu wenig 
verbreitet beim Programmieren, auch wenn es bei der Sprache immer 
Optimierungsmöglichkeiten gibt ...

Lothar M. schrieb:
> ...
> Mit Headerdateien baut man kein "Gerüst" auf.
Mea culpa! Hatte Bibliotheken fälschlicherweise als Headerdateien 
bezeichnet, geleitet von er gleichen Dateiendung '.h' Solcherart Fehler 
passieren leider.

Lothar M. schrieb:
> ... Der Praktiker entprellt die Tasten einfach in 5 Zeilen mit 100ms und fertig.

Das ist mir nun doch zu vage - es kursiseren jetzt Zeiten zwischen unter 
10 bis zu 100ms.

100ms können intuitiv bereits wahrgenommen werden, denke ich.

Bin noch nicht sicher, ob ich mir einen Test erpsparen kann.

Grüße

Uli

[Joachim B. (jar)]

Lothar M. schrieb:
> Wenn die im 10ms Interrupt aufgerufen wird, entprellt sie für 30ms.

falsch, du kennst sie nicht, sie prüft 4x 10ms und nur wenn alle gültig 
sind ist die Taste entprellt.
Beitrag "Tasten entprellen - Bulletproof"
Beitrag "Universelle Tastenabfrage"

[Klaus (feelfree)]

Joachim B. schrieb:
> Lothar M. schrieb:
>> Wenn die im 10ms Interrupt aufgerufen wird, entprellt sie für 30ms.
>
> falsch, du kennst sie nicht, sie prüft 4x 10ms und nur wenn alle gültig
> sind ist die Taste entprellt.

Und wieviel Zeit vergeht zwischen 4 Abtastungen?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Joachim B. schrieb:
> Lothar M. schrieb:
>> Wenn die im 10ms Interrupt aufgerufen wird, entprellt sie für 30ms.
> falsch, du kennst sie nicht
Sei dir sicher: ich kenne sie in und auswendig. Du musst nochmal drüber 
nachdenken. Der Schlüssel zum Erfolg: nach dem letzten Zählerschritt 
wird nicht mehr gewartet.

> sie prüft 4x 10ms
Zaunpfahlproblem: wie lang ist ein Zaun mit 10m langen Feldern und 4 
Pfosten? Wie lange ist die Zeit mit 10ms Abstand und 4 Abtastungen?

[Joachim B. (jar)]

Lothar M. schrieb:
> Wie lange ist die Zeit

ach nun komme mir doch nicht mit Details ;-)

Lothar M. schrieb:
> Der
> Praktiker entprellt die Tasten einfach in 5 Zeilen mit 100ms

du wolltest 100ms und PeDa schrieb mal in 40ms ist auch die störrichste 
Taste entprellt.

Bei 10ms mehr oder weniger mache ich mir doch nicht ins Hemd, Hauptsache 
erkannt und sicher ohne Wartezeit.

[Klaus (feelfree)]

Joachim B. schrieb:
> falsch, du kennst sie nicht

Joachim B. schrieb:
> Bei 10ms mehr oder weniger mache ich mir doch nicht ins Hemd

Erst große Klappe und dann den eigenen Denkfehler unter den Teppich 
kehren wollen. Großartig. Nicht.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Joachim B. schrieb:
> du wolltest 100ms
Pi ist eine Konstante und e auch. Aber die 100ms sind der erste Schuss 
auf die vom TO vermutete schlechteste auffindbare "Billig-Taste".

> und PeDa schrieb mal in 40ms ist auch die störrichste Taste entprellt.
Dann sollte er seine Routine aber mit 13..14ms Abstand aufrufen...  ;-)

> Bei 10ms mehr oder weniger mache ich mir doch nicht ins Hemd
Es ist halt einfach das klassische "off-by-one" Problem.

Uli schrieb:
> Das Englische betreffend: Deutsch ist zu wenig verbreitet beim
> Programmieren.
Hört sich fast danach an, dass du meinst, dein Programm würde mit 
englischen Begriffen besser funktionieren oder es wäre "hochwertiger". 
Das wird nicht der Fall sein. Ich bin mir völlig sicher, dass niemals 
ein fremdsprachiger Mensch je deinen Code verstehen muss. Und wenn, dann 
wird er mit solchen falschen "Fachbegriffen" eher verwirrt als dass sie 
ihm helfen.

> Bin noch nicht sicher, ob ich mir einen Test erpsparen kann.
Das geht so: nimm einen Pullup, deinen schlechtesten "Billig-Taster" und 
ein Digitaloszi. Stell das Oszi auf "Nachleuchtdauer unendlich", dann 
drückst du die Billig-Taste 1000 mal und hast alle Preller und 
automatisch auch die längste Prellzeit auf dem Bildschirm. Dieser Test 
ist ganz gemütlich in 10 Minuten erledigt.

> 100ms können intuitiv bereits wahrgenommen werden, denke ich.
Wie schon gesagt: du "denkst" dir Probleme her, die entweder gar nicht 
da oder völlig unwichtig sind. Denn dieses "Problem" kannst du bei 
Notwendigkeit in kürzester Zeit lösen.

> Hatte Bibliotheken fälschlicherweise als Headerdateien bezeichnet,
> geleitet von er gleichen Dateiendung '.h'
Compilierte Bibliotheken sind Object-Code. Die enden sicher nicht auf 
*.h

> Solcherart Fehler passieren leider.
... wenn man die Toolchain nicht kennt.

[Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)]

Uli schrieb:
> Bin noch nicht sicher, ob ich mir einen Test erpsparen kann.

Wenn Du die Taster über ein Monoflop entprellst ...

https://www.elektronik-kompendium.de/news/thema/entprellen/

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Dieter D. schrieb:
> Wenn Du die Taster über ein Monoflop entprellst ...
Echt jetzt? Wenn da ein µC im System ist? Dann entprellen noch die 
allerhärtesten Frickler über zusätzliche Hardwarebauteile.

[Uli (uiimcn)]

Lothar M. schrieb:
> Dieter D. schrieb:
>> Wenn Du die Taster über ein Monoflop entprellst ...
> Echt jetzt? Wenn da ein µC im System ist? Dann entprellen noch die
> allerhärtesten Frickler über zusätzliche Hardwarebauteile.

:-)

[Uli (uiimcn)]

@Alle

Nach viel Arbeit habe ich jetzt eine zweite Version der defaults und 
custom-settings erstellt.

Ausgehend von der (konstruktiven) Kritik von Monk

Monk schrieb:
> ...
> Das Konzept, bei jedem Zugriff auf Settings nach dem Key als String zu
> suchen und dann ggf. nochmal mit Default-Prefix, gefällt mir nicht. ...
> ...
> Effizienter wären Strukturen (Klassen), deren Zugriffe vom Compiler
> aufgelöst werden, anstatt zur Laufzeit zu suchen.

konnte ich zwar die Anmerkung am Ende des Zitats weder verstehen noch 
umsetzen, konnte jedoch die Zugriffe sowohl auf die defaults als auch 
auf Nutzer-Werrte dazu bzw. Nutzer-Einstellungen deutlich verbessern 
(indizierte, direkte Zugriffe).

Alle Daten werden in direktem Zugriff auf die betreffenden Sektionen in 
den Strings bzw. der Datei gemacht.

Danke Dir Monk!

Die KI konnte dabei nicht viel helfen, im Gegenteil: Sie hat Vieles 
wieder und wieder 'kaputtgemacht' ...
Insbesondere bei scheinbar einfacher Algebra, die jedoch etwas 
Verständnis der Aufteilung und Definitionen für die Key-Value Sektionen 
in den Strings oder der Datei voraussetzt, ging fast alles schief...

Was die KI dann sehr schön gemacht hat war der DOC-String und natürlich 
schönes Schreiben des Codes. Der Stil stammt dabei aus meiner eigenen 
Feder.

Der Vorteil dabei war: Das Verständnis von C/C++ wächst ...

Den Abschluss der Arbeit mit der KI an dieser Klasse möchte ich doch 
noch hier einstellen:

Ich:

/Thank you very much! This was hard work fo a beginner like me and a 
language-based AI-model! See you!/

Sie:

/You're welcome! You've done a great job navigating this, and I'm glad I 
could help. Don’t hesitate to reach out if you need more assistance in 
the future. Happy coding, and see you next time!/

Als Sprachmodell ist das Ding doch bereits ziemlich leistungsfähig! Und 
das  war die 'einfachere' Version!

Vielleicht findet jemand die Zeit, um das mal zu überfliegen?

Wäre toll!

Viele Grüße

Uli

[Klaus (feelfree)]

Uli schrieb:
> Nach viel Arbeit habe ich jetzt eine zweite Version der defaults und
> custom-settings erstellt.

Warum fängst Du eigentlich mit dem Unwichtigsten an, oder ist der ganze 
Rest schon fertig?

Du willst eine Gärbox-Regelung, stattdessen schlägst Du dich Default- 
und Usersettings rum, und denkst jetzt schon daran Tasten zu entprellen.

Das ist ungefähr so wie wenn jemand ein Auto bauen möchte, und anstatt 
erstmal mit 4 Rädern, 2 Achsen und einem Chassis anzufangen, er erstmal 
die Blinkersteuerung realisiert.

[Monk (roehrmond)]

Gefällt mir schon vom Grundkonzept her schon nicht. Du programmierst den 
Mikrocontroller, als sei das ein Desktop PC bei dem Speicherbedarf und 
Performance egal ist.

Ich verstehe nicht, warum nicht mit simplem structs fester Größe 
arbeitest.

Ungeprüftes Beispiel:

#include <Arduino.h>
#include <EEPROM.h>

// ======================================== 

struct ServoSettings {
    int minPwmValue = 1100;
    int centerPwmValue = 1500;
    int maxPwmValue = 2400;
};

class ServoController {
    public:
      ServoController(ServoSettings&);
    private:
      ServoSettings &settings;
};

ServoController::ServoController(ServoSettings &s) : settings(s) {
    Serial.print(F("Init servo with minPwmValue="));
    Serial.println(settings.minPwmValue);
    // ...
}

// ======================================== 

struct TemperatureSettings {
    float min = 22.5;
    float max = 24.1;
};

class TemperatureController {
    public:
      TemperatureController(TemperatureSettings&);
    private:
      TemperatureSettings &settings;
};

TemperatureController::TemperatureController(TemperatureSettings &s) : settings(s) {
    Serial.print(F("Init user temp controller with min="));
    Serial.println(settings.min);
    // ...
};

// ========================================

struct UserSettings {
    char name[20] = "noname";
    char password[20] = "dummy";
};

class UserManagement {
    public:
      UserManagement(UserSettings&);
    private:
      UserSettings &settings;
};

UserManagement::UserManagement(UserSettings &s) : settings(s) {
    Serial.print(F("Init user with name="));
    Serial.println(settings.name);
    // ...
}

// ========================================

struct AllSettings {
    uint8_t test; // 0xFF indicates that the EEPROM is new and not initialized
    TemperatureSettings temperature;
    UserSettings user;
    ServoSettings leftServo;
    ServoSettings rightServo;
};

AllSettings globalSettings;

TemperatureController *temperatureController;
UserManagement *userManagement; 
ServoController *leftServoController;
ServoController *rightServoController;

void setup()
{
    AllSettings tmp;
    EEPROM.get(0, tmp);
    if (tmp.test==0xFF) {
        // copy defaults to EEPROM
        EEPROM.put(0, globalSettings);
    } else {
        // replace defaults in RAM by settings from EEPROM
        globalSettings=tmp;
    }

    Serial.print(F("Welcome "));
    Serial.print(globalSettings.user.name);

    temperatureController=new TemperatureController(globalSettings.temperature);
    userManagement= new UserManagement(globalSettings.user);
    leftServoController=new ServoController(globalSettings.leftServo);
    rightServoController=new ServoController(globalSettings.rightServo);
}

void loop() {
    // ...
}

Jede Struktur definiert eine Gruppe von Settings für einen Teil der 
Maschine, sowie ihre Default Werte. AllSettings kombiniert sie, damit 
sie sich leicht am Stück ins EEPROM übertragen lassen.

In einem echten Projekt wären die drei Klassen (TemperatureController, 
UserManagement und ServoController) in separaten *.h und *.cpp Dateien 
platziert.

Die Haupt-Datei (*.ino) Kombiniert alle Settings zusammen in eine 
Struktur mit fester Größe und initialisiert Objekte mit dem jeweils 
benötigten Teil der Konfiguration.

In einem gelöschten EEPROM haben alle Bytes anfangs den Wert 0xFF. Die 
globale Variable globalSettings.test wird jedoch mit 0 initialisiert (da 
ich keinen anderen Start-Wert angegeben habe). Wenn wir Daten aus dem 
EEPROM laden, können wir am aktuellen Wert von tmp.test erkennen, ob wir 
gerade ein gelöschtes EEPROM gelesen haben, oder ob es bereits mit den 
sinnvollen Werten beschrieben wurde.

Wenn du keine eigenen Klassen programmieren willst: auch gut, niemand 
zwingt dich. Dennoch kannst du die Settings wie gezeigt verschachtelt 
strukturieren. Oder du packst alles in eine einzige Struct, falls dir 
das lieber ist. Auf die Performance hat das keinen Einfluss, denn 
Lesezugriffe finden in allen Fällen direkt über Zeiger bzw. Referenzen 
statt - da muss nichts gesucht, gesplittet und konvertiert werden.

Was man auf jeden Fall noch einbauen sollte:
- Nicht immer an die gleiche Stelle im EEprom speichern.
- Sicherstellen, dass das EEPROM neu initialisiert wird, wenn die 
Settings strukturell verändert wurden.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Monk schrieb:
> Du programmierst den Mikrocontroller, als sei das ein Desktop PC bei dem
> Speicherbedarf und Performance egal ist.
Die KI macht das... ;-)

Hölle, ein µC-System für eine simple Temperatursteuerung und gleich ein 
Dateisystem:

    File file = LittleFS.open("/custom_key_value_pairs.txt", "r");

Das ist technischer Overkill.

Ich traue mir zu, die gesamte Steuerung der Gärbox in die 275 Zeilen zu 
packen, die bisher in der defaults_user_settings.ino allein die 
Verwaltung und Speicherung der Produkteinstellungen braucht.

> Was man auf jeden Fall noch einbauen sollte:
> Nicht immer an die gleiche Stelle im EEprom speichern.
Im Besonderen, wenn dieses EEPROM nur ein in einem Flash simuliertes 
"EEPROM" ist.

Uli schrieb:
> Vielleicht findet jemand die Zeit, um das mal zu überfliegen?
Du musst die vorgekauten und eigengelobten Templates der KI schon an 
deine Erfordernisse anpassen, sonst "stürzt" dein Programm an sowas ab:

   while (true); // Endless loop

> Als Sprachmodell ist das Ding doch bereits ziemlich leistungsfähig!
Sie ist gut im Bauchpinseln, weil sie bei vielen anderen gelernt hat, 
dass das gut ankommt.

[Uli (uiimcn)]

Klaus schrieb:
> ...
> Warum fängst Du eigentlich mit dem Unwichtigsten an, oder ist der ganze
> Rest schon fertig?
> ...
> Das ist ungefähr so wie wenn jemand ein Auto bauen möchte, und anstatt
> erstmal mit 4 Rädern, 2 Achsen und einem Chassis anzufangen, er erstmal
> die Blinkersteuerung realisiert.

Hallo Klaus,
wie gesagt geht es mir im ersten Schritt um das Gerüst, den Rahmen, 
innerhalb dessen dann die 'eigentlichen' Steuerungs-Funktionen laufen. 
Ohne dies bin ich ständig dabei, Platzhalter zu setzen.

Das ist schätzungsweise zu 70% fertig mit den weiter oben genannten 
Teilen.


Monk schrieb:
> ...
> Ich verstehe nicht, warum nicht mit simplem structs fester Größe
> arbeitest.

Hallo Monk,
das setzt bei mir noch viel zu viel KnowHow betr. C/C++ voraus.

In Teilen hab ich schon verstanden, wie du dir das vorstellst - das wäre 
sicher 'richtig' so.

Was ich in keiner Weise verstanden habe:

---> /Wie stellst du fest, ob und welcher DEFAULT (=Konstant) -Wert 
durch eine Nutzer Einstellug überschrieben werden soll?/

Jedenfalls bleibe ich so lange mein Verständnis von C/C++ so gering ist 
besser beim absoluten KISS-Prinzip, bis es tatsächlich Speicherprobleme 
gibt...


> Was man auf jeden Fall noch einbauen sollte:
> - Nicht immer an die gleiche Stelle im EEprom speichern.
> - Sicherstellen, dass das EEPROM neu initialisiert wird, wenn die
> Settings strukturell verändert wurden.

Ja, das steht auf der Liste, muss aber noch zuwarten.

Viele Grüße

Uli

[Uli (uiimcn)]

Lothar M. schrieb:
> Monk schrieb:
>> Du programmierst den Mikrocontroller, als sei das ein Desktop PC bei dem
>> Speicherbedarf und Performance egal ist.
> Die KI macht das... ;-)

Das siehst du falsch. So wollte ich das!

> ...
> Hölle, ein µC-System für eine simple Temperatursteuerung und gleich ein
> Dateisystem:

Verstehe nicht. Wo bzw. wie würdest du denn Nutzer-Einstellungen 
speichern?

> ...
>    while (true); // Endless loop

Das ist so gewollt in diesem Stadium. Es ist ein Platzhalter.

>...
>> Als Sprachmodell ist das Ding doch bereits ziemlich leistungsfähig!
> Sie ist gut im Bauchpinseln, weil sie bei vielen anderen gelernt hat,
> dass das gut ankommt.

:-)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uli schrieb:
>> ...
>> Hölle, ein µC-System für eine simple Temperatursteuerung und gleich ein
>> Dateisystem:
> Wo bzw. wie würdest du denn Nutzer-Einstellungen speichern?
Auf einem µC ohne dedizierten und entnehmbaren Speicher? Garantiert 
nicht mit einem Filesystem in einer Textdatei, die dann erst mal 
aufwendig geparst werden muss. Das ist ein sicherer Weg, jeden µC 
langsam zu bekommen.

Uli schrieb:
> Lothar M. schrieb:
>> Monk schrieb:
>>> Du programmierst den Mikrocontroller, als sei das ein Desktop PC bei dem
>>> Speicherbedarf und Performance egal ist.
>> Die KI macht das... ;-)
> So wollte ich das!
Ja, so ist das: wenn Laien der KI sagen, was sie wollen, dann bekommen 
sie das, was sie wollen. Es ist aber nicht gesagt, dass es sich mit dem 
deckt, was sie brauchen.

[Monk (roehrmond)]

Uli schrieb:
> Wie stellst du fest, ob und welcher DEFAULT (=Konstant) -Wert
> durch eine Nutzer Einstellug überschrieben werden soll?

Beim ersten Start stehen die Defaults im Speicher. Dein 
Benutzer-Frontend kann Werte direkt in den globalen Settings direkt 
ändern, wodurch die Defaults dort überschrieben werden.

Irgendwann danach muss das natürlich noch ins EEPROM kopiert werden, 
damit die Einstellung auch ohne Stromversorgung erhalten bleiben. Dazu 
habe ich keinen Code gezeigt, weil das eine andere Baustelle ist.

[Klaus (feelfree)]

Uli schrieb:
> wie gesagt geht es mir im ersten Schritt um das Gerüst, den Rahmen,

Du arbeitest aber eben NICHT am Gerüst.
Siehe mein Vergleich mit dem Autobauer. Die Blinkerschaltung nützt dir 
nichts, solange du nicht mal ein Chassis mit 4 Rädern dran hast.

[Manfred P. (pruckelfred)]

Monk schrieb:
> Irgendwann danach muss das natürlich noch ins EEPROM kopiert werden,
> damit die Einstellung auch ohne Stromversorgung erhalten bleiben. Dazu
> habe ich keinen Code gezeigt, weil das eine andere Baustelle ist.

Hast Du überhaupt schon einmal irgendwo anfängertauglichen Code gezeigt?

[Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)]

Lothar M. schrieb:
> Echt jetzt? Wenn da ein µC im System ist?

Natürlich, nur so kann er vermeiden nicht doch versehentlich bei einer 
Erstinbetriebnahme die SW-Entprellung zu testen. ;o)

Uli schrieb:
> :-)

Die ;o) in unseren Posts sind ihm nicht entgangen.

[Uli (uiimcn)]

Klaus schrieb:
> Uli schrieb:
>> wie gesagt geht es mir im ersten Schritt um das Gerüst, den Rahmen,
>
> Du arbeitest aber eben NICHT am Gerüst.
> Siehe mein Vergleich mit dem Autobauer. Die Blinkerschaltung nützt dir
> nichts, solange du nicht mal ein Chassis mit 4 Rädern dran hast.

Das ist verm. Definitionssache.

Besser ist ein Vergleich mit einem tatsächlichen Gerüst. Das wird 
aufgestellt, um *den 'Inhalt'* bauen zu können.
Der Inhalt enthält dann die Gärbox-Steuerungsfunktionen.

Das käme der Sache schon näher.

Grüße

Uli

[Klaus (feelfree)]

Uli schrieb:
> Besser ist ein Vergleich mit einem tatsächlichen Gerüst. Das wird
> aufgestellt, um *den 'Inhalt'* bauen zu können.
> Der Inhalt enthält dann die Gärbox-Steuerungsfunktionen.

Passt.

Nur ist alles, was Du bisher hier gezeigt hast, eben kein Gerüst.
Das was Du bisher von deiner KI bauen lassen hast kann man alles 
problemlos weglassen, die Gärbox-Steuerung funktioniert trotzdem.

Ein Gerüst bei diesem Vergleich wäre eine funktionierende Toolchain. 
Editor, Compiler, Linker, Debugger. Eben alles was man braucht, um den 
Inhalt zu bauen.
Ja, auch eine Tastenentprellung ist Inhalt, aber halt vollkommen 
unwichtig am Anfang. Das ist quasi die Kontrolleuchte deiner 
Blinkerschaltung im Auto. Schön wenn die funktioniert, nur ohne Chassis 
und Räder sinnlos.
Oder die Parameter-Speicherung: Es ist schön, wenn mein Auto später beim 
Einschalten den Sitz automatisch in die richtige Position fährt. Ich 
würde trotzdem mit den Rädern anfangen.

[Joachim B. (jar)]

Manfred P. schrieb:
> Hast Du überhaupt schon einmal irgendwo anfängertauglichen Code gezeigt?

frage ich mich auch, mittlerweile hat er unter seine 3 mir bekannten 
Namen über 60000 Beiträge in 3 Jahren, also 54 Beiträge pro Tag, wo war 
da Code?

[Monk (roehrmond)]

Dieter D. schrieb:
>> Echt jetzt? Wenn da ein µC im System ist?

> Natürlich, nur so kann er vermeiden nicht doch versehentlich bei einer
> Erstinbetriebnahme die SW-Entprellung zu testen.

Nicht lästern!

Für jemanden, der das Programmieren gerade begonnen hat, ist es doch 
völlig legitim, die Entprellung erst mal in Hardware zu erledigen. Er 
hat schon genug andere offene Baustellen.

[Uli (uiimcn)]

Hallo zusammen,

ohne im Moment auf Vorhergegangenes eingehen zu können:

Hat jemand zu diesem 'Schluckauf' einen Rat?

Evtl. hab ich bereits die erste Node MCU geliefert? Jedenfalls hab ich 
erstmal NULL Erklärung für diesen endlosen Loop.

Der (zusammengestrichene) Code:

#define DEBUG_08X_scaffold_key_value_pairs true

#include <Arduino.h>

class KeyValuePairs {
  // void

  public:
  // Constructor
  KeyValuePairs() {
    #if DEBUG_08X_scaffold_key_value_pairs
    Serial.begin(9600);
    Serial.println("Serial print started.");
    ESP.wdtDisable();
    Serial.println("WatchDogTimer (WDT) disabled!");
    #endif
  }

  // void
};

void setup() {
  // Initialize serial communication for debugging
  #if DEBUG_08X_scaffold_key_value_pairs
  Serial.begin(9600);
  Serial.println("Setup() started.");
  #endif

  // Create an instance of KeyValuePairs
  KeyValuePairs kvPairs;
}

void loop() {
  // Empty loop

}

Und das kommt raus (Arduino IDE, Serieller Monitor):
(Die Monitor-Ausgabe kann ich leider nicht per Klicken kopieren - geht 
nicht...)

--> Eine endlose Schleife, die lediglich Output von KeyValuePairs() 
{...} wiederholt. Das Programm kommt nicht bis zum regulären setup() 
Bereich.

Hat jemand von euch eine Erklärung?

Bin gespannt!

Grüße

Uli

[Rbx (rcx)]

Hierzu müsste man sich u.a. damit beschäftigen - braucht man nicht 
unbedingt, ist aber oft sehr hilfreich:
https://de.wikipedia.org/wiki/Endlicher_Automat

Sowas weiß man aber auch, wenn man in vielen Monaten die Grundlagen 
eingeübt hat.
Damit auch - und ist ebenfalls nichts anderes als gute Grundlagenhilfe:
https://blog.modellbahnshop-lippe.com/2020/04/01/modellbahn-signale-richtig-aufstellen/

[Ralf G. (ralg)]

Uli schrieb:
> Hat jemand von euch eine Erklärung?

Ursache: Verwendung von uninitialisierten Zeigern (mehrere 
Möglichkeiten)

Wirkung: ganz normaler Programmabsturz und Neustart

[Uli (uiimcn)]

Rbx schrieb:
> ...  sehr hilfreich:
> https://de.wikipedia.org/wiki/Endlicher_Automat
> ...

Das Problem ist ja, dass das System KEIN Endlicher Automat ist!

Moment ... das ist falsch:

Ich bin mir sicher, DASS es eines ist!
(Auch dann, wenn die Spannungsversorgung nicht unterbrochen wird)

Ralf G. schrieb:
> ...
> Ursache: Verwendung von uninitialisierten Zeigern (mehrere
> Möglichkeiten) ...

Welche Sprachelemente aus dem Obigen sind denn C++ 'Zeiger' (Da reicht 
mein aktueller Kenntnisstand nicht aus..)? Dann könnte ich die 
uninitialisierten leichter finden.

Grüße

Uli

[Klaus (feelfree)]

Uli schrieb:
> Da reicht
> mein aktueller Kenntnisstand nicht aus..

Du hast keine Ahnung vom Programmieren (nicht schlimm!). Aber statt eins 
nach dem anderen zu lernen (Hello World, LED blinken lassen, Taster 
abfragen, Kombinationen davon, ...), lässt Du dir von einer KI Programme 
zusammenschustern, die Du selbst nicht verstehst.
Das funktioniert halt nicht, Du bist da der beste Beweis.
Lerne Grundlagen!

[Monk (roehrmond)]

Warum deaktivierst du den Watchdog? Man sollte das nicht ohne guten 
Grund tun.

Die wirren Zeichen in der Ausgabe lassen vermuten, dass dein ESP Chip 
neustartet. Den Grund für den Neustart zeigt er in der Regel an. Dazu 
musst du aber am PC auf 74880 Baud umstellen, damit die wirren Zechen zu 
lesbaren werden. Wenn du magst, kannst du auch die Ausgaben von deinem 
Sketch auf 74880 umstellen, dann siehst du beides.

Warum hast du zweimal "Serial.begin(9600);" im Code? Vielleicht macht 
der zweite Aufruf davon Probleme, während gleichzeitig die gepufferten 
Zeichen des vorherigen Serial.prinln() ausgegeben werden.

Ich sehe in dem zusammen gestrichenen Code keine nicht initialisierte 
Variable. Interessanter wäre der wirkliche Code, den du ausgeführt hast. 
Vielleicht belegst du zu viel RAM. Lokale Variablen liegen auf dem Stack 
und der ist auf etwas weniger als 5 kB beschränkt.

[Uli (uiimcn)]

Klaus schrieb:
> ...
> Du hast keine Ahnung vom Programmieren (nicht schlimm!). Aber statt eins
> nach dem anderen zu lernen (Hello World, LED blinken lassen, Taster
> abfragen, Kombinationen davon, ...), lässt Du dir von einer KI Programme
> zusammenschustern, die Du selbst nicht verstehst.
> Das funktioniert halt nicht, Du bist da der beste Beweis.
> Lerne Grundlagen!

Mach ich doch alles - hatte das bereits geschildert.

Das läuft parallel. Die KI bringt nur sehr wenig dazu. Syntax und 
Schreiben. Das kann sie recht gut.


Monk schrieb:
> Warum deaktivierst du den Watchdog?
Ist nur zum Debuggen, weil der Watchdog auch MNeustarts verursachen 
kann.

> ... damit die wirren Zechen zu
Jetzt ist schon etwas mehr zu entziffern - aber nicht alles. Werde damit 
momentan leider auch nicht schlauer.

> Warum hast du zweimal "Serial.begin(9600);" im Code? Vielleicht macht
> der zweite Aufruf davon Probleme, während gleichzeitig die gepufferten
> Zeichen des vorherigen Serial.prinln() ausgegeben werden.
Das war ein Fehlerr von meiner Seite. in setup() sollte der Schalter 
logisch verneint sein. Das war er nicht... Hat dann nach der Korrektur 
nicht mehr gebracht als vorher (mit den 74880 Baud).


> Ich sehe in dem zusammen gestrichenen Code keine nicht initialisierte
> Variable. Interessanter wäre der wirkliche Code, den du ausgeführt hast.
Der ausgeführte ist genau der, den ich hochgeladen hatte. Würde ich 
nachträglich ändern (Teile löschen), bringt das ja nur noch mit viel 
Glück etwas...

> Vielleicht belegst du zu viel RAM. Lokale Variablen liegen auf dem Stack
> und der ist auf etwas weniger als 5 kB beschränkt.
Kann ich mir bei den paar Zeilen nicht vorstellen.

Das Einfachste wäre, wenn jemand den Code auf seiner MCU ausführen 
würde. Dann wäre zumindest klarer, ob es ein HW-Problem sein könnte.

Danke dir sehr für die  konkreten Hinweise!

Grüße

Uli

[Ralf G. (ralg)]

@TO

Bring das erstmal in eine sinnvolle Reihenfolge.
'Serial.begin()' wird einmalig im Programm 'für alle' ausgeführt, das 
versteckt man nicht ganz hinten in irgendeinem Konstruktor:

#define DEBUG_08X_scaffold_key_value_pairs true

#include <Arduino.h>

class KeyValuePairs 
{
public:
  KeyValuePairs() 
  {
    ESP.wdtDisable();
#if DEBUG_08X_scaffold_key_value_pairs
    Serial.println("WatchDogTimer (WDT) disabled!");
#endif
  }
};

void setup() 
{
// Initialize serial communication for debugging
  Serial.begin(9600);
#if DEBUG_08X_scaffold_key_value_pairs
  Serial.println("Setup() started.");
#endif

// Create an instance of KeyValuePairs
  KeyValuePairs kvPairs;

}

void loop() 
{

}

Uli schrieb:
> (Die Monitor-Ausgabe kann ich leider nicht per Klicken kopieren - geht
> nicht...)

Lässt sich die Ausgabe markieren? Normalerweise kriegt man mit Ctrl-C 
alles kopiert.

[Monk (roehrmond)]

Uli schrieb:
> Die KI bringt nur sehr wenig dazu

Deine wiederholten Hinweise auf die Unfähigkeit der KI nerven. Meinem 
Chef brauchte ich nur einmal sagen, dass KI uns (noch) nicht weiter 
bringt.

Deine Ausgaben bestätigen jedenfalls meinen Verdacht, dass der ESP 
unerwartet neu startet. Offenbar nach einem Absturz, denn wenn nur der 
Watchdog den Neustart auslösen würde, wäre die gesamte Ausgabe lesbar.

Ich würde jetzt mal die Stromversorgung und die Zugriffs-Parameter zum 
Flash Speicher kontrollieren.

Zur Stromversorgung: Verwende ein unverbrauchtes Kabel dessen Stecker 
noch gut fest sitzen. Verwende auch einen gut fest sitzenden USB Port am 
PC. Falls nicht vorhanden, schließe ein 5..9V Netzteil an Vin und GND 
an.

Vielleicht ist der Flash Speicher langsamer, als deine Konfiguration 
verlangt. Falls du in der "NodeMCU" Board Definition keine Flash 
Parameter ändern kannst, versuche es mal mit dem "Generic ESP8266" und 
den Einstellungen:

Flash Frequency: 40 MHz
Flash Mode: DOUT

Falls das Board auf einem Steckbrett sitzt, betreibe es ohne oder 
entferne die reservierten Pins (siehe 
http://stefanfrings.de/esp8266/index.html#nodemcu)

Probiere die anderen Code-Beispiele auf dieser Webseite.

Probiere eine ältere Version des ESP8266 Cores. Ich weiß, dass die alte 
Version 2.3.0 zuverlässig läuft (auch mit der aktuellen IDE).

[Uli (uiimcn)]

Ralf G. schrieb:
> ...
> Bring das erstmal in eine sinnvolle Reihenfolge.

Das ist hier doch irrelevant.


> ...
> Lässt sich die Ausgabe markieren? Normalerweise kriegt man mit Ctrl-C
> alles kopiert.
Leider nicht - keine Ahnung, woran's hier nun wieder klemmen könnte...


Monk schrieb:
> ...
> Deine wiederholten Hinweise auf die Unfähigkeit der KI nerven. ...
Mich auch. Gehe jetzt nicht mehr brav auf entsprechende Kommentare ein.

> Ich würde jetzt mal die Stromversorgung ... kontrollieren.
Die konnte es ja nicht sein. Das Programm konnte hochgeladen werden und 
lief - wenn auch sehr 'merkwürdig' ...

> Vielleicht ist der Flash Speicher langsamer, ...
Bingo!!! Das war das Problem!

Hab jetzt mit Erfolg erst mal die delay(...) erhöht, um dem Speicher 
mehr Zeit zu geben. Nach den Flash-Parametern schaue ich anschliessend.

Dat war 'n Ding ...

Danke Dir!

Uli

[Monk (roehrmond)]

Uli schrieb:
>> Ich würde jetzt mal die Stromversorgung ... kontrollieren.
> Die konnte es ja nicht sein. Das Programm konnte hochgeladen werden

Spannend wird es, wenn die Funkschnittstelle aktiv wird. Am Hochladen 
scheitert es selten.

>> Vielleicht ist der Flash Speicher langsamer, ...
> Bingo!!! Das war das Problem!

Na also, herzlichen Glühstrumpf und viel Glück mit weiteren fake 
Produkten aus China.

Allerdings bezweifle ich, dass

> Hab jetzt mit Erfolg erst mal die delay(...) erhöht

Welche delay(...) meinst du, dein Programm enthält doch angeblich gar 
keine?! Ich bezweifle, das delay(...) Aufrufe einen Einfluss auf die 
Taktfrequenz und Zugriffsmodi des Flash Speichers haben.

[Uli (uiimcn)]

Hallo zusammen,
ich möchte dem Problem des Überlaufs von Speicherkapazität(en) 
näherkommen.

Dazu fange ich erst mal mit dem HEAP an und frage mich, wie ihr das 
macht, um  einen Überlauf zu verhindern.

0) Die HEAP-Grösse bei meiner Node MCU ESP8266 12E beträgt ca. 50kB. 
Getestet wurde dies mittels einem ständig wachsenden Nutzungs-Bereich 
innerhalb einer Schleife.

1) Wenn der HEAP nun vorab reserviert wird *und immer nur innerrhalb 
dessen geschrieben wird*, kann er nicht überlaufen. Es können aber 
versehentlich Speicherbereiche überschrieben werden --> Laufzeitfehler 
mit hoher Absturzwahrscheinlichkeit ...

2) Solche Laufzeitfehler könnten z. B. vermieden werden, wenn definierte 
Bereiche genau vorhergeplant wären und nur jeweils in dieselben 
geschrieben würde. Da habe ich noch keine Idee, das praktisch 
umzusetzen.

3) Seht ihr Optionen dazu?

Mich würde sehr interessieren, wie ihr das im Praktischen macht.

Grüße

Uli

[Monk (roehrmond)]

Uli schrieb:
> Mich würde sehr interessieren, wie ihr das im Praktischen macht.

Da bei den meisten Mikrocontrollern Heap und Stack aufeinander zu 
wachsen, kontrolliere ich im Zweifelsfall durch Antesten*, wie viel 
Platz dazwischen noch frei ist. Nach einer Weile bekommst du ein Gefühl, 
wie viel freier Platz für das jeweilige Projekt nötig ist.

*) Ich teste, ob ich 50 Bytes belegen kann und gebe sie direkt wieder 
frei. Dann versuche ich 100 Bytes, dann 200 Bytes, dann 400 Bytes, usw. 
So kann ich fortlaufend anzeigen, wie groß der größtmögliche freie 
Speicherblock ungefähr ist. In der Regel (wenn ich den Speicher nicht 
fragmentiert habe) ist das der Bereich zwischen Stack und Heap, so dass 
er für beides gilt.

Beim ESP wachsen Heap und Stack aber nicht aufeinander zu, so das die 
obige Methode hier nicht passt. Für den Heap enthält der Arduino Core 
entsprechende Funktionen, siehe 
https://arduino-esp8266.readthedocs.io/en/latest/libraries.html#esp-specific-apis 
. Für den Stack leider nicht. Keine Ahnung wie man den elegant 
kontrollieren kann.

Beim Arduino Framework bietet die String Klasse viele Möglichtkeiten, 
sich ins eigene Knie zu schießen, indem man den Speicher versehentlich 
fragmentiert. Deswegen vermeide ich es, Strings zu verändern. Das mache 
ich lieber mit klassischen C-Library Funktionen und char-Arrays, weil 
ich dabei besser durchblicke, was dort passiert.

Dort habe ich noch weitere Tips in diesem Zusammenhang: 
http://stefanfrings.de/esp8266/index.html#fallstricke

[Uli (uiimcn)]

Monk schrieb:
> ...
> Dort habe ich noch weitere Tips in diesem Zusammenhang:
> http://stefanfrings.de/esp8266/index.html#fallstricke

Danke dir sehr für die hilfreichen Tips! Insbesondere die Infos von 
Stefan Frings Website erhellen die doch sehr 'empfindlichen' technischen 
Grundlagen von Mikrocontrollern hervorragend!

Was meine liebe Node MCU betrifft gehe ich inzwischen doch davon aus, 
dass ich die HW (Flash-Speicher) mindestens an einer Stelle beschädigt 
habe.

Selbst einfachste Test-Programme können abstürzen... Was *zuverlässig 
UND wiederholbar* funktioniert ist ein Programm, bestehend aus einem 
leeren setup(); und loop();

Ein technisch vollständiges Minimalprogramm also...

Mache jetzt unabhängig von HW am Programm selbst weiter und kümmere mich 
um Speicherfragen erst dann wieder, wenn neue Teile da sind.

Beste Grüße

Uli

[Uli (uiimcn)]

Hallo zusammen,
komme jetzt erst wieder dazu, am Projekt 'Gärbox-Steuerung' 
weiterzumachen und hänge komplett an einer Sache fest, die bereits mal 
funktioniert hatte...

Um modular vorgehen zu können, binde ich eigene Programmteile per 
#include "my-function.h" ein.

Diese Datei liegt in einem Verzeichnis Namens ../my-function, also 
../my-function/my-function.h.

Angefangen mit dem Sketch-Ordner selbst sieht das dann so aus:

.../sketches/my-sketch/my-sketch.ino
.../sketches/my-sketch/libraries/my-function/my-function.h

Der Kompiler scheint die Datei so nicht zu finden.

Entweder mach ich auf meinem Rechner was verkehrt in den Namen oder ist 
etwas anderes nicht wie es sein soll. Jedenfalls scheint das nicht zu 
funktionieren.

Wäre das denn so grundsätzlich richtig?

Grüße
Uli

[Peter D. (peda)]

Uli schrieb:
> Der Kompiler scheint die Datei so nicht zu finden.

Wenn man Libs in einem anderen Verzeichnis als das aktuelle 
Arbeitsverzeichnis anlegt, muß man sie auch dort compilieren und dann 
dem Linker angeben, wo er die daraus erzeugten Objektdateien findet.

[Cyblord -. (cyblord)]

Uli schrieb:
> my-function.h

Super Benamung.

Wie wäre es mit ordentlichen Modulen die ordentlich benannt werden?

Aber dazu müsste man programmieren können, geht also nicht.

[Uli (uiimcn)]

Peter D. schrieb:
> Uli schrieb:
>> Der Kompiler scheint die Datei so nicht zu finden.
>
> Wenn man Libs in einem anderen Verzeichnis als das aktuelle
> Arbeitsverzeichnis anlegt, muß man sie auch dort compilieren und dann
> dem Linker angeben, wo er die daraus erzeugten Objektdateien findet.

Hätte dazusagen sollen, dass das mit der ArduinoIDE zusammenhängt - den 
Compiler rufe ich ja in dem Zusammenhang nicht direkt auf.

Die aktuelle Lösung des Problems in der ArduinoIDE ist:

Alle eigenen 'Bibliotheken' sind jetzt im Verzeichnis

./Arduino/sketches/defaults_user_settings/libraries

untergebracht. Dort werden sie von der IDE problemlos gefunden.

Cyblord -. schrieb:
> Uli schrieb:
>> my-function.h
>
> Super Benamung.
>
> Wie wäre es mit ordentlichen Modulen die ordentlich benannt werden?
>
> Aber dazu müsste man programmieren können, geht also nicht.

Gell, ein wirklich schönes Minuszeichen!

[Norbert (der_norbert)]

Uli schrieb im Mai:
> …dass das Projekt für mich als Anfänger nur hier reinpasst.
> Ich hab Problemchen potentiell mit Allem, was dabei so während der
> Entwicklung auftaucht.

Tja, Augen auf bei der Wahl der Programmiersprache (insbesondere für 
Anfänger). Eine etwas sorgfältigere Wahl und deine Gärbox hätte zum 
jetzigen Zeitpunkt bereits eine viertel Tonne Teig ausgebrütet. Nur mal 
so als Anmerkung am Rande…

[Uli (uiimcn)]

Norbert schrieb:
> Uli schrieb im Mai:
>> …
>> Ich hab Problemchen potentiell mit Allem, was dabei so während der
>> Entwicklung auftaucht.
>
> Tja, Augen auf bei der Wahl der Programmiersprache ...

C/C++ war nicht meine Lieblingswahl, weil es mir als kompilierte Sprache 
viel zu fremd war. Allerdings muss ich sagen, dass ich inzwischen besser 
verstehe, weshalb viele darauf schwören. Die Sprache ist sehr mächtig!

Wie auch immer, die Kompaktheit und der Support gaben dann den 
Ausschlag. Bei Python z. B. wäre beides nicht in diesem Umfang gegeben.

Grüße
Uli

[Norbert (der_norbert)]

Uli schrieb:
> Wie auch immer, die Kompaktheit…
Für einen Anfänger? Ernsthaft?

> und der Support gaben dann den Ausschlag.
Drei Monate und kein Ende in Sicht – für eine im schlimmsten Fall wenige 
Tage beanspruchende Aufgabe sprechen eine andere Sprache.

> Bei Python z. B. wäre beides nicht in diesem Umfang gegeben.
Aaaaaaa jaaaa. Du hast also noch nie zuvor Python programmiert. Und 
schon gar nicht die Dokumentationen dazu gelesen.

Sorry, aber das sind alles keine Argumente, schon gar nicht im Privat- 
und Anfängerbereich.

[Manfred P. (pruckelfred)]

Uli schrieb:
>> Wenn man Libs in einem anderen Verzeichnis als das aktuelle
>> Arbeitsverzeichnis anlegt, muß man sie auch dort compilieren und dann
>> dem Linker angeben, wo er die daraus erzeugten Objektdateien findet.
>
> Hätte dazusagen sollen, dass das mit der ArduinoIDE zusammenhängt - den
> Compiler rufe ich ja in dem Zusammenhang nicht direkt auf.
>
> Die aktuelle Lösung des Problems in der ArduinoIDE ist:

... die Library über dessen Menü einzubinden, dann legt die IDE sie in 
das passende Verzeichnis.

Uli schrieb:
>> Tja, Augen auf bei der Wahl der Programmiersprache ...
> C/C++ war nicht meine Lieblingswahl, weil es mir als kompilierte Sprache
> viel zu fremd war.

Die A*-IDE und deren siebenundschwanzigtausend Beispiele machen den 
Einstieg ziemlich einfach.

Norbert schrieb:
>> und der Support gaben dann den Ausschlag.
> Drei Monate und kein Ende in Sicht – für eine im schlimmsten Fall wenige
> Tage beanspruchende Aufgabe sprechen eine andere Sprache.

Ich habe ziemlich zu Beginn eine strukturierte Arbeitsweise angeregt, 
erstmal einzelne Teilfunktionen zu testen. Ich sehe nicht, dass das 
umgesetzt wurde.

[Uli (uiimcn)]

Norbert schrieb:
> ...
> Aaaaaaa jaaaa. Du hast also noch nie zuvor Python programmiert. ...

Muss ich auch nicht.

*Jeder/jede* muss sich jedoch von Fall zu Fall auf Mutmaßungen stützen 
für Entscheidungen.

Falls du einigermaßen belastbare Vergleichszahlen betreffend des 
Ressourcenbedarfs hast, nehme ich diese gerne in künftige Projekte mit 
rein!

Manfred P. schrieb:
> ... die Library über dessen Menü einzubinden, dann legt die IDE sie in
> das passende Verzeichnis. ...
Mir ist es immer lieber wenn ich weiß, was, wo weshalb abgelegt wird. 
Über diesen Weg kam ich dann glücklicherweise auf das 
./Arduino/sketches/defaults_user_settings/libraries Verzeichnis.

Wobei auch dabei bereits die Alarmglocken schrillen:
Wenn in diesem VZ sowohl user als auch default-Daten stecken, was 
geschieht dann z. B. bei einem Update?

Manfred P. schrieb:
> ...
> Die A*-IDE und deren siebenundschwanzigtausend Beispiele machen den
> Einstieg ziemlich einfach.

Auf jeden Fall!

Grüße
Uli

[Uli (uiimcn)]

Hallo zusammen!

Überraschungen gibt's tatsächlich genügend ;-)

Gibt es ein bekanntes Problem mit dem Arduino-Vector oder mache ich 
etwas falsch (was natürlich in keinster Weise ausgeschlossen werden 
kann...)?

Hier sind zwei identische Programme, eines mit dem std::vector, das 
andere mit dem Arduino Vector.

Das mit dem std::vector läuft fehlerfrei, das Programm mit dem Arduino 
Vector stürzt mit einem Stack-Fehler (28) ab.

Kann sich jemand einen Reim daraus machen?

[Monk (roehrmond)]

Uli schrieb:
> Kann sich jemand einen Reim daraus machen?

Read the docs!

"A sequence container similar to the C++ std::vector, but instead of 
allocating memory dynamically, this container points to an external, 
statically allocated c style array. The maximum size is fixed at compile 
time...Static memory allocation is used to avoid dynamic 
allocation...Care must be taken not to ... use without setting the 
storage array."

Darunter kommen Beispiele, wie man diese Klasse richtig anwendet.

https://github.com/janelia-arduino/Vector

[Uli (uiimcn)]

Monk schrieb:
> ... Read the docs! ...

Unendlich, das Thema - hätte ich gewusst was ich such und es dann auch 
noch gefunden ... :-)


Monk schrieb:
> ...
> Darunter kommen Beispiele, wie man diese Klasse richtig anwendet.
>
> https://github.com/janelia-arduino/Vector

Super und ein großes DANKE!

Schaue morgen dort rein.

Was immer noch nicht klar genug ist, auch nach einigem Lesen nicht:

Das Speicherthema, HEAP, std::strings und / oder Arduino Strings etc.

Der HEAP-Verwalter (wie immer das nun heißt) kann ja nur danach schauen, 
ob und wo gerade Platz frei ist, um etwas Neues dort abzulegen, denke 
ich.

Umgekehrt werden bestimmte Speicherbereiche freigegeben, sobald diese 
nicht mehr benötigt werden.

Sicher passen dabei immer wieder 'etwas zu große' neue Objekte etc. in 
keine der wieeder freigegebenen Lücken, so das ein neuer Bereich dafür 
angelegt werden muss.

Und so kann es früher oder später dazu kommen, dass der gesamte HEAP de 
facto belegt ist, obwohl es dort ungenutzte Bereiche gibt.

So weit, so gut.

Jetzt meine eigentliche Frage:
*Worin genau unterscheidet sich in diesem Zusammenhang denn ein 
statischer und ein dynamischer Bedarf*? Beide müssen doch gleichermassen 
freigegeben werden, sobald sie nicht mehr benötigt werden?

Ein besseres Verständnis würde sehr weiterhelfen - das 'Problem' kommt 
ziemlich sicher noch...

Grüße
Uli

[Monk (roehrmond)]

Statischer Speicherbedarf liegt schon zum Zeitpunkt der Compilierung 
fest. Statischer Speicher wird weder belegt noch freigegeben, er ist 
einfach fest reserviert.

Was dahinter übrig bleibt, kann als STACK und HEAP verwendet werden.

https://onlinedocs.microchip.com/pr/GUID-317042D4-BCCE-4065-BB05-AC4312DBC2C4-en-US-2/index.html?GUID-27757112-8BE1-49C2-B023-CD94AD06C5E2

[Uli (uiimcn)]

Monk schrieb:
> Statischer Speicherbedarf liegt schon zum Zeitpunkt der Compilierung
> fest. Statischer Speicher wird weder belegt noch freigegeben, er ist
> einfach fest reserviert.
>
> Was dahinter übrig bleibt, kann als STACK und HEAP verwendet werden.
>
> 
https://onlinedocs.microchip.com/pr/GUID-317042D4-BCCE-4065-BB05-AC4312DBC2C4-en-US-2/index.html?GUID-27757112-8BE1-49C2-B023-CD94AD06C5E2

Das hilft sehr!

Noch eine Zusatzfrage:

Prinzipiell kann für jedes Objekt ein bestimmter Speicherplatz 
rewerviert werden.

Vermute ich das richtig, wenn der Vorteil der statischen Belegung 
lediglich eine manuelle Reservierung erübrigt und dadurch etwas 
'bequemer' sein kann?

Dann erschiene das Prinzip erstmal klar genug.

[Uli (uiimcn)]

Wie macht ihr das, einen Widerstand in das Breadboard einstecken?

Wegen der weichen Drähte war das etwas nervig - jetzt hab ich zum 
Probieren an den Enden zwei Elemente einer Buchsenleiste angelötet.

Gibt es da weitere praktische Optionen?

[Norbert (der_norbert)]

Uli schrieb:
> Wie macht ihr das, einen Widerstand in das Breadboard einstecken?

Das ist ein hochkomplexer Vorgang.
Bevor ich da etwas versaue hole ich mir meistens Hilfe von Fachleuten.

[Uli (uiimcn)]

Norbert schrieb:
> Uli schrieb:
>> Wie macht ihr das, einen Widerstand in das Breadboard einstecken?
>
> Das ist ein hochkomplexer Vorgang.
> Bevor ich da etwas versaue hole ich mir meistens Hilfe von Fachleuten.

'Frotzelst' du so gerne?

Alle versammelten Fachleute dieser Erde kommen nirgendwo hin, wenn 
du dort nur etwas tiefer reingehen würdest...

Praxis hab ich halt auch kaum - so ist das.

[Norbert (der_norbert)]

Uli schrieb:
> 'Frotzelst' du so gerne?

Eindeutig: JA

Bietet sich aber auch an, wenn man schon Hilfe braucht einen Draht in 
ein dafür vorgesehenes Loch zu stecken.

Aber um deine ursprüngliche Frage zu beantworten: Ich nehme den Draht 
zwischen Daumen und Zeigefinger der rechten Hand.
Dann suche ich das für den Betrieb der Schaltung notwendige Loch auf dem 
Breadboard.
Ich nähere meine Hand diesem Loch und versuche, so gut es mir eben 
möglich ist, Draht und Loch zueinander passend auszurichten.
Anschließend führe ich den Draht vorsichtig ein und überwinde behutsam 
den ersten leichten Widerstand, welchen die sich unter dem Loch 
befindliche Klemmvorrichtung ausübt.
Diese Vorwärtsbewegung halte ich aufrecht, bis ein größerer Widerstand 
den Boden des Abgrundes ankündigt.

OBACHT NUN, DAS IST WICHTIG:
Erst Daumen und Zeigefinger lösen, dann die Hand wegnehmen. Nicht 
umgekehrt. Sonst war die ganze Arbeit umsonst.

[Monk (roehrmond)]

Uli schrieb:
> Frotzelst' du so gerne?

Ja sorry, aber was erwartest du? Man steckt ihn einfach rein!

Mein Ex Kollege hätte danach noch "oder sind zu wenig Haare drumherum?" 
gesagt.

Wo ist das Problem, was gibt es da zu fragen? Die Frage ist doch schon 
reinste Blödelei.

[Uli (uiimcn)]

Das kam sicher anders rüber als es gedacht war.

Mit den Versuchsaufbauten ist Einiges an 'Pfriemelei' verbunden, mehr 
noch, wenn deine 'Tricks' noch nicht entwickelt sind.

In diesem Zusammenhang wollte ich einfach wissen, ob jemand von euch 'ne 
geniale Idee dazu hat - ich jedenfals wurstle nicht mehr mit den Fingern 
und dem weichen Draht rum...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uli schrieb:
> Gibt es da weitere praktische Optionen?
Man nimmt Google und sucht nach Bildern von Steckbrettaufbauten. Ubd 
findet so heraus, dass man mit ein wenig Fingerspitzengefühl die Drähte 
des Widerstands mit einer Pinzette direkt einstecken kann, solange sie 
halbwegs gerade sind:
- https://www.google.com/search?q=widerstand+steckbrett&tbm=isch

Bei ganz billigen Steckbrettern kann das schon mal ein wenig hakeln.

Aber wenn du jetzt mit Steckbrettern herumfummelst, dann bist du noch in 
der Funktionsmodell-Phase. Und nicht beim Prototypen oder gar bei einer 
Vorserie....

[Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)]

Uli schrieb:
> Gibt es da weitere praktische Optionen?

Vielleicht was fertig konvektioniertes verwenden?

Zum Beispiel:
https://de.elv.com/p/elv-experimentier-set-prototypenadapter-inkl-make-sonderheft-P252102/

[Uli (uiimcn)]

Lothar M. schrieb:
> ...
> Man nimmt Google und sucht nach Bildern von Steckbrettaufbauten. ...
Wenn ich für die Idee mit der Pinzette Google brauch dann lass ich die 
praktische Seite lieber ganz weg :-) - meine Finger sind leider nicht 
mehr ruhig genug dazu.

Betr. Prototyp: Wie gesagt betrifft das nicht die Steuerung selbst.

/Bevor das hier untergeht bitte ich nochmals um Erhellung zum Thema 
Speicher:/

Falls lediglich Adressen bzw. Pointer (mit sehr niedrigem 
Speicherbedarf) statisch festgelegt und die eigentlichen Daten dann doch 
im HEAP abgelegt werden (z. B. beim Arduino-Vector), wie kann dieses 
Konzept denn einer rein dynamischen Speicherbelegung überlegen sein?

Wie könnten dadurch z. B. Speicher 'Zerklüftung' bzw. 'memory-leakage' 
Probleme seltener werden???

[Uli (uiimcn)]

Ich muss hier im Forum am Thema Speicher dran bleiben, so lange die 
Grundkonzepte nicht klar genug sind.

Es geht vorrangig um die Vermeidung von Fragmentierung.

Fragmentierung bedeutet so weit ich verstanden habe, dass immer 
kleinere, immer mehr Speicherbereiche im HEAP nicht mehr genutzt werden 
können, weil in diese kleinen Bereiche nichts mehr von dem reinpasst, 
was neu (dynamisch) gepeichert werden soll.

Die Summe dieser Bereiche kann nun - je nach Nutzung des Speichers - im 
Laufe der Zeit permanent anwachsen, so weit, dass es schließlich zum 
Absturz kommt, weil nichts Neues mehr gespeichert werden kann.

Das ist die Situation wie ich sie bisher verstehe.

Wenn nun bestimmte Bereiche bereits beim Kompilieren festgelegt werden 
(also: statisch), existiert dieses Problem verständlicherweise nicht.

Bedeutet das nun im Umkehrschluss, dass im Bereich Zeichenketten ALLES 
Andere als char 's wie z. B. String 's, Vector 'en etc. letztlich 
dasselbe Fragmentierungsproblem beim Speichern von Zeichenketten haben?

[Klaus (feelfree)]

Uli schrieb:
> Das ist die Situation wie ich sie bisher verstehe.

Wie immer kümmerst Du dich um Probleme, die du gar nicht hast.
Der Prototyp wäre seit einem Vierteljahr fertig, wenn Du mit der 
Kernfunktionalität angefangen hättest.
Aber so wie Du es angehst, wird es wohl auch spätestens in einem 
Vierteljahrhundert was werden.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Klaus schrieb:
> Aber so wie Du es angehst, wird es wohl auch spätestens in einem
> Vierteljahrhundert was werden.
... frühestens...

Ich glaube aber eher "niemals".

Wenn so eine kleine Gärbox-Temperatursteuerung irgendeinen Heap oder 
Stack zum Überlaufen bringt, dann ist die grauenhaft schlecht 
programmiert. Und wenn sie den Heap/Stack nicht zum Überlauf bringt, 
dann ist der auch völlig uninteressant.

Uli schrieb:
> String 's, Vector 'en
Das hier völlig falsch verwendete Hochkomma nennt sich im Volksmund 
zurecht "Deppenapostroph". Der zusätzliche Plenk macht die Sache nicht 
besser. Diese Interpunktionsextravaganzen zeigen aber auch in die selbe 
Richtung wie der Rest hier im Thread: du willst unbedingt deinen eigenen 
Weg gehen, statt einfach mal mit den nötigen Grundlagen zu beginnen.

[Uli (uiimcn)]

Ich verstehe wirklich nicht, wo euer Problem ist.

Braucht Ihr dringend 'ne Gärbox? Dann sagt es mir und ich werde sehen, 
ob das auch anders geht.

[Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)]

Lothar M. schrieb:
> Ich glaube aber eher "niemals".

Fürchte, da könntest Du recht behalten.

Aktuell sehe ich nur als Zielführend die Schüssel mit dem Teig in den 
Ofen bei niedrigste Temperatur zu stellen, sich jeweils auf dem 
Smartphone einen Wecker zu stellen und ein Thermometer mit Warnsignalton 
in den Teig zu stecken.

[Klaus (feelfree)]

Uli schrieb:
> Ich verstehe wirklich nicht, wo euer Problem ist.
> Braucht Ihr dringend 'ne Gärbox? Dann sagt es mir und ich werde sehen,
> ob das auch anders geht.

Außer dir will hier keiner eine Gärbox bauen. Und außer dir gibt es auch 
kaum jemanden, der so konsequent jeden einzelnen Ratschlag ignoriert und 
stattdessen einfach jeweils die nächste Baustelle aufmacht.

[Uli (uiimcn)]

Klaus schrieb:
> Uli schrieb:
>> ... Dann sagt es mir ...
>
> Außer dir will hier keiner eine Gärbox bauen. Und außer dir gibt es auch
> kaum jemanden, der so konsequent jeden einzelnen Ratschlag ignoriert und
> stattdessen einfach jeweils die nächste Baustelle aufmacht.

Auf diese Art kann ich etwas anfangen damit - danke!
Heute bin ich allerdings erst mal weg.

[Monk (roehrmond)]

Ich habe eine stumpfe Nadel herum liegen, mit der weite ich die Kontakte 
neuer Steckbretter etwas auf, wenn sie klemmen.

[Uli (uiimcn)]

*Kurz:*
Lösungen für die übergeordnete Sachlage sehe ich bislang keine auf Basis 
der begrenzten Möglichkeiten im Forum.

*Etwas länger, der Reihenfolge nach:*

Lothar M. schrieb:
> ...
> Wenn so eine kleine Gärbox-Temperatursteuerung irgendeinen Heap oder
> Stack zum Überlaufen bringt, dann ist die grauenhaft schlecht
> programmiert.

Das vermute ich inzwischen auch. Ich begreife Sachverhalte allerdings 
gerne, bevor sie mir auf die Füße fallen.
Zur Sache selbst: Hältst du deine Aussage unverändert bei, falls die 
Steuerung im Dauerbetrieb laufen sollte?


Lothar M. schrieb:
> ... Interpunktionsextravaganzen ..

Hast du einen konkreten oder - noch besser: tollen - Vorschlag für den 
Fall des 'Vektor' (hier brauchen wir ein Genitiv -s)?

Und weiter:

Klaus schrieb:
> Uli schrieb:
>> Das ist die Situation wie ich sie bisher verstehe.
>
> Wie immer kümmerst Du dich um Probleme, die du gar nicht hast. ...

Und das soll ich jetzt als dummer Anlernling schlicht entsprechend 
interpretieren und so handhaben? Das geht halt leider so nicht.

Klaus schrieb:
> Uli schrieb:
>> ...
>> Braucht Ihr dringend 'ne Gärbox? ...

Klar, der gemeinsame Nenner ist die Steuerung

Klaus schrieb:
> ...
> Und außer dir gibt es auch
> kaum jemanden, der so konsequent jeden einzelnen Ratschlag ignoriert und
> stattdessen einfach jeweils die nächste Baustelle aufmacht.

Dass dies so rüberkommt kann ich gut nachvollziehen. Meine 
'Sprunghaftigkeit' ist unwidersprochen. Ich weiss bis dato allerdings 
nicht, wie dieses individuelle Vorgehen (durchaus einer gewissen 
Systematik folgend), nachvollziehbar kommuniziert werden könnte.

Vom Forum hatte ich mir deshalb wie weiter 'oben' gesagt erwartet: 
'Hilfe, wenn's klemmt'.

Das geht so halt leider auch nicht wirklich...

Mehr als ein /'Mal sehen, wie's weitergeht hier.'/ erscheint deshalb - 
Status heute - als nicht realistisch.

Grüße
Uli

P.S.:
Warte auf Teile, bevor es mit dem Versuch an einer Klasse OledPrint() 
weitergehen kann.

Bevor es dazu Sticheleien gibt: Die Teile kommen von einer Firma aus den 
Niederlanden.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uli schrieb:
> Lothar M. schrieb:
>> Wenn so eine kleine Gärbox-Temperatursteuerung irgendeinen Heap oder
>> Stack zum Überlaufen bringt, dann ist die grauenhaft schlecht
>> programmiert.
> Zur Sache selbst: Hältst du deine Aussage unverändert bei, falls die
> Steuerung im Dauerbetrieb laufen sollte?
Ja. Wenn ich eine kleine Temperatursteuerung entwickle, die dauernd 
läuft, dann sorge ich auch dafür, dass die Software auch dauerhaft 
laufen kann. Oder andersrum: die Steuerung hat noch Fehler in der 
Software, wenn man sie einmal im Monat neu starten muss, weil sie 
seltsame Dinge macht.

Uli schrieb:
> Lothar M. schrieb:
>> ... Interpunktionsextravaganzen ..
> Hast du einen konkreten oder - noch besser: tollen - Vorschlag für den
> Fall des 'Vektor' (hier brauchen wir ein Genitiv -s)?
Im Falle des Vektors würde ich einfach "des Vektors" schreiben, so wie 
das im Duden vorgeschlagen wird.

Uli schrieb:
> char 's wie z. B. String 's, Vector 'en
chars, Strings und Vektoren (und wenn schon englisch, dann vectors).
Und ich könnte noch weitermachen: LEDs, Displays, Pins, IOs, ...

Uli schrieb:
> Lothar M. schrieb:
>> ... Interpunktionsextravaganzen ..
> Hast du einen konkreten oder - noch besser: tollen - Vorschlag
Ja: wenn etwas seltsam und unüblich aussieht, dann nimm Google.
- https://www.google.com/search?q=Vektor+deklination

Um zu erkennen, ob etwas seltsam oder unüblich ist, muss man natürlich 
auch mal was anderes anschauen.


Uli schrieb:
> Ich begreife Sachverhalte allerdings gerne, bevor sie mir auf die Füße
> fallen
Dann tu das. Von Anfang an mit einfachen Programmen, die du selber 
geschrieben und verstanden hast.

[Ralf G. (ralg)]

Uli schrieb:
> Versuch an einer Klasse OledPrint()
Sollte das nicht 'ne Gärbox werden? ...

[Ralf X. (ralf0815)]

Ralf G. schrieb:
> Uli schrieb:
>> Versuch an einer Klasse OledPrint()
> Sollte das nicht 'ne Gärbox werden? ...

Böttcher wollte auch Gold erfinden und fand stattdessen das Porzellan.
Zufallsergebnisse müssen also nicht schlecht sein. :-)

[Klaus (feelfree)]

Uli schrieb:
> Klaus schrieb:
>> Wie immer kümmerst Du dich um Probleme, die du gar nicht hast. ...
>
> Und das soll ich jetzt als dummer Anlernling schlicht entsprechend
> interpretieren und so handhaben? Das geht halt leider so nicht.

Natürlich geht das, Du willst halt nur nicht.

Das ist deine Liste aus dem ersten Beitrag:

Uli schrieb:
> Grundelemente der Steuerung:
> - Power: 12V, 2A Steckernetzteil
> - IN-Buchse 5,5 * 2,1mm; Kippschalter, Fadensicherung
> - DC-DC Spannungswandler 12 -> 5V, 1A
> - NodeMCU ESP8266 12E, I2C, 4MB
> - OLED-Display, 1.3", 4-PIN
> - Heizdraht
> - 2 Stck. Bimetall-Sicherungselemente
> - Relais oder MSOFET zum Schalten des Heizdrahtes
> - 4 Push-Buttons (3 f. Menue, 1 für temporäre Beleuchtung innen)
> - geignete Spannungsteiler, um die drei Menue-Taster per ADC0 erkennen
> zu können
> - 1 LED
> - 4 Stck. DS18B20 Temperatursensoren (mit ALARM-Trigger)

Und das wäre meine:

- Stromversorgung
- uC
- 1 (Ein!) Temperatursensor
- Heizdraht mit geeignetem MOSFET als Schalter.

Und daraus kannst Du dann eine funktionierende Gärbox bauen.
Du wirst allein für diesen ersten Schritt noch ein halbes Jahr brauchen.
Und dann hast Du hoffentlich so viel gelernt, dass Du an die nächsten 
Schritte gehen kannst, mit Bedienelementen und Display.

Nochmal ein hinkender Autovergleich: Du willst bei einer Wüstenrallye 
teilnehmen. Anstatt erstmal den Führerschein zu machen um Autofahren zu 
lernen, versuchst Du schon mal deine GPS-Geräte zu verstehen und lernen, 
wie man einen Reifenschaden reparieren kann. Klar, für das Endziel musst 
da alles können, aber jeder vernünftig denkende Mensch würde mit dem 
Führerschein anfangen.

[Uli (uiimcn)]

*@Lothar:*

Teilw. dreht sich das im Kreis. Deshalb nur letzte Bemerkungen dazu:

Lothar M. schrieb:
> ...
> Wenn ich eine kleine Temperatursteuerung entwickle, die dauernd
> läuft, dann sorge ich auch dafür, dass die Software auch dauerhaft
> laufen kann. ...

Genau darum ging und geht es (man beachte das 'dauernd').

Lothar M. schrieb:
> ...
> Im Falle des Vektors würde ich einfach "des Vektors" schreiben, so wie
> das im Duden vorgeschlagen wird.

Genau das möchte ich tunlichst vermeiden, wenn auf eine explizite 
Unterscheidung zw. den allgemeinsprachlichen und den fachspezifischen 
bzw. C/C++ Begriffen NICHT verzichtet werden kann. Meine pers. Grenzen 
sind diesbezüglich naturgemäß höher angesetzt als z. B. deine.

*@Klaus:*

Ich dachte immer du machst Witze - das scheint nun doch nicht der Fall 
zu sein...

Zum Mitschreiben:
- Ich HABE eine Bastellösung und brauch keine Zweite.
- Ich BAUE eine velässliche und komfortable (Gärbox-) Steuerung. Daran 
habe ich meinen Spass.

[Klaus (feelfree)]

Uli schrieb:
> Ich HABE eine Bastellösung

Das klang vor 4 Monaten noch anders:

Uli schrieb:
> Außer mir scheinen nun alle anderen zu wissen, wie die drei Beinchen dem
> Gate, Source und Drain zuzuordnen zu sind.

Dann mag' ich den diesbezüglichen Fortschritt überlesen haben.

[Uli (uiimcn)]

Klaus schrieb:
> Uli schrieb:
>> Ich HABE eine Bastellösung
>
> Das klang vor 4 Monaten noch anders:
>
> Uli schrieb:
>> Außer mir scheinen nun alle anderen zu wissen, wie die drei Beinchen dem
>> Gate, Source und Drain zuzuordnen zu sind.
>
> Dann mag' ich den diesbezüglichen Fortschritt überlesen haben.

Das war viell. nicht so ohne Weiteres verständlich dargestellt:
Die Steuerung der bisherigen Bastellösung besteht lediglich aus einem 
CN-Thermostat, also ohne eigens dafür aufgebaute Elektronik. Mit den 
gesammelten Erfahrungen aus dieser Box ging ich dann an die Entwicklung 
der physisch komplett neuen Gärbox einschl. der Steuerung.

[Klaus (feelfree)]

Uli schrieb:
> Die Steuerung der bisherigen Bastellösung besteht lediglich aus einem
> CN-Thermostat, also ohne eigens dafür aufgebaute Elektronik.

Also hatte ich doch Recht.
Anstatt die Regelung (=das Herz deiner Gärbox) aufzubauen und in Betrieb 
zu nehmen (das geht ganz ohne Bedienelemente!), kümmerst Du dich um 
Tasten, Tastenentprellung, Display, Strings, Vektoren, 
Speicherfragmentierung, Heap, Stack, und tausend anderen Mist. Jahre 
später kann das Ding dann alles, außer heizen bzw. die Temperatur halten 
oder gar regeln.
Kann man so machen, wenn man gerne scheitert.

[Uli (uiimcn)]

Klaus schrieb:
> ...
> Kann man so machen, wenn man gerne scheitert.

Das kann man schon so sehen - das tatsächliche 'Ende vom Lied' ist 
jedoch unbekannt.

Meine Sicht eines 'Gerüsts' oder 'Frame' weicht in diesem Fall diametral 
von deiner ab.

Um beim Vergleich mit einem Auto zu bleiben:

Das 'Fahren' ist für mich das eigentliche Steuerprogramm, das gesamte 
Auto ist für mich die SW-technische Umgebung bzw. Voraussetzung, fast 
'Nebensache', die allerdings vom Steuerprogramm benötigt wird um die 
gewünschten Funktionen (das Fahren) umsetzen zu können.

So gesehen fang ich vom anderen Ende her an.

[Klaus (feelfree)]

Uli schrieb:
> Meine Sicht eines 'Gerüsts' oder 'Frame' weicht in diesem Fall diametral
> von deiner ab.

Mag sein. Deinen Autovergleich verstehe ich nicht.
Ich fange halt mit der Kernfunktion an. 4 Räder, Motor. Feste 
Geschwindigkeit.
Wenn das läuft, Gaspedal und Tachometer.
Du machst es umgekehrt. Implementierst ein Gaspedal und ein fancy 
Infotainment, weißt aber bis zum Schluss nicht, ob der Motor überhaupt 
ins Auto passt.

Auch im Sinne der Lernkurve machst du es falsch. Das HelloWorld eines 
Mikrocontroller Programms ist eine blinkende LED. Dann kommt das 
Auslesen eines Sensors und in deinem Fall das Setzen eines PWM-Ausgangs. 
Jetzt noch eine Regelung und fertig ist Version 0.1 deiner Box. Der 
ganze Rest kommt danach.

[Uli (uiimcn)]

Sehe ich das richtig, dass mein letzter Beitrag gelöscht wurde?

Wenn ja, weshalb?

Er enthielt ein Bild des aktuellen Versuchsaufbaus.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Uli schrieb:
> Sehe ich das richtig, dass mein letzter Beitrag gelöscht wurde?
> Wenn ja, weshalb?
Ja, weil du ein Foto unmäßig groß als PNG gepostet hast. Nimm JPEG dazu. 
DAS ist das Format für Fotos. Diese Begründung hast du auch per Mail 
erhalten.

> Er enthielt ein Bild des aktuellen Versuchsaufbaus.
Und poste dann auch noch einen Schaltplan zu diesem Aufbau. Oder sollen 
sich den jetzt alle von deinem Foto "abzeichnen"?

[Uli (uiimcn)]

Lothar M. schrieb:
> ...
> Ja, weil du ein Foto unmäßig groß als PNG gepostet hast. ...
> ...
> Und poste dann auch noch einen Schaltplan zu diesem Aufbau. Oder sollen
> sich den jetzt alle von deinem Foto "abzeichnen"?

Danke - verstehe!

Das Foto war ja jetzt nicht dazu gedacht, das Ganze mal genauer 
durchzuschauen. Es soll einfach den Status auf der praktischen Seite 
zeigen, damit klarer wird, wo diese Seite steht momentan.

Eine 'saudumme' Frage dazu:
Mit welcher Methode erreicht man am ehesten, dass der Schaltplan dan 
tatsächlich mit dem Versuchsaufbau übereinstimmt ...? Fehler können sich 
ja ganz gerne mal überall einschleichen...

Super klein geworden jetzt!

[Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)]

Uli schrieb:
> Ich BAUE eine velässliche und komfortable (Gärbox-) Steuerung.

In dem Falle benoetigst Du noch einen zweiten analogen 
Übertemperaturschutz. Willst sicherlich nicht die Bude thermisch 
Abreißen durch SW- Fehler oder Prozessoraufhaenger.