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
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?
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
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.
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.
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
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 :-)
Wenn es zu kalt ist stelle ich den Teig in den Backofen und schalte dessen Licht ein. Das reicht als Wärmequelle.
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.
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
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
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.
1 | Temperatursteuerung |
2 | Einstellbare Werte |
3 | - Temperaturen von 17 bis 52°C |
4 | - 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.
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
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
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.
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.
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.
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.
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.
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.
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
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.
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
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
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.
Beitrag #7675573 wurde von einem Moderator gelöscht.
Beitrag #7675596 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
Gaerbox_Steuerung.PNG
160 KB
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.
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
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 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
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.
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.
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.
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 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
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.
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.
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.
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
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.
Turbulente Strrömung gibts doch bloss bei sehr grossen Geschwindigkeiten. Unterhalb bleibts laminar.
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 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). :-)
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.
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!
Angehängte Dateien:
-
gpio-use.png
120 KB -
gpios-pinout.randomnerdTutorials.png
140 KB
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 ...
Angehängte Dateien:
-
gpio-use.02.png
97 KB -
MCU-foto_700x_.01.png
910 KB
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.
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.
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
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.
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
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.
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...
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
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ß".
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
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
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.
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
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.
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 ...
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…
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...
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
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:
1 | #include <Arduino.h> |
2 | #include <U8g2lib.h> |
3 | #include <cstring> // For std::strlen |
4 | |
5 | // Initialize the display with I2C connection
|
6 | U8G2_SSD1306_128X64_NONAME_F_HW_I2C u8g2(U8G2_R0, /* reset=*/ U8X8_PIN_NONE); |
7 | |
8 | // Define maximum characters per line and number of lines
|
9 | const int MAX_CHARS_PER_LINE = 21; |
10 | const int MAX_LINES = 3; |
11 | |
12 | // Function to calculate the display length considering specific multi-byte characters
|
13 | constexpr size_t display_length(const char* str) { |
14 | size_t len = 0; |
15 | for (size_t i = 0; str[i] != '\0'; ++i) { |
16 | if ((str[i] & 0xC0) == 0xC0) { // Check if it's the start of a multi-byte character |
17 | ++i; // Skip the next byte of the multi-byte character |
18 | }
|
19 | ++len; |
20 | }
|
21 | return len; |
22 | }
|
23 | |
24 | // Macro to check string length at compile-time
|
25 | #define CHECK_LINE_LENGTH(line) static_assert(display_length(line) <= MAX_CHARS_PER_LINE, "Line exceeds maximum allowed length!")
|
26 | |
27 | // Messages to be displayed
|
28 | const char* line1 = "This is line one"; // OK |
29 | const char* line2 = "This is Äline twö"; // OK |
30 | const char* line3 = "This line is way too long and should cause a compile error"; // Exceeds limit |
31 | |
32 | // Apply the check to each line
|
33 | CHECK_LINE_LENGTH(line1); |
34 | CHECK_LINE_LENGTH(line2); |
35 | CHECK_LINE_LENGTH(line3); |
36 | |
37 | void setup() { |
38 | // Initialize the display
|
39 | u8g2.begin(); |
40 | }
|
41 | |
42 | void loop() { |
43 | // Clear the display buffer
|
44 | u8g2.clearBuffer(); |
45 | |
46 | // Draw each line on the display
|
47 | u8g2.drawStr(0, 12, line1); |
48 | u8g2.drawStr(0, 24, line2); |
49 | u8g2.drawStr(0, 36, line3); |
50 | |
51 | // Send the buffer to the display
|
52 | u8g2.sendBuffer(); |
53 | |
54 | // Delay to control the display refresh rate
|
55 | delay(1000); |
56 | }
|
Man beachte die Zeile: /const char* line2 = "This is Äline twö"; // OK/ Alles Andere später... Uli
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:
1 | warning: unused variable 'selfName' [-Wunused-variable] |
2 | 3 | const char* selfName = "02.scaffold_configure_GPIOs.h()"; /* Set self name */ |
3 | | ^~~~~~~~ |
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
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.
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.
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.
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ß.
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
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. 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.
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.
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...
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.
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
1 | // Constructor to initialize keyValueSettings
|
2 | ButtonPress(PublicKeyValuePairs& keyValueSettings) : |
3 | keyValueSettings(keyValueSettings) {} |
und
1 | // Reference to key-value settings
|
2 | PublicKeyValuePairs& keyValueSettings; |
in eine Klasse streikt der Compiler. Die erste Meldung diesbezüglich ist:
1 | ...07.scaffold_button_presses.h:12:34: error: expected ')' before '&' token |
2 | 12 | ButtonPress(PublicKeyValuePairs& keyValueSettings) : |
3 | | ~ ^ |
4 | | ) |
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
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
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!
"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.
Monk schrieb: > ... wie "mit Separatorenfleisch". ... Oder 'Analogkäse' ... Du rennst bei mir grösstenteils offene Tore ein - kann erst später darauf eingehen...
Denke auch an Typ-Konvertierung. Jedes mal, wenn du einen Integer brauchst, must du den konvertieren (String -> Integer).
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
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
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
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.
1 | Settings enthält: |
2 | WifiConfig |
3 | UartConfig |
4 | MotorConfig |
Diese drei Objekte enthalten so viele Variablen, wie nötig, sowie entsprechend viele getter, die ggf. Defaults zurück geben:
1 | GetBaudrate(): |
2 | |
3 | if baudrate==0 |
4 | return 19200 |
5 | else |
6 | return baudrate |
Das ist leicht zu verstehen und erzeugt kompakten Code. Die Initialisierungsroutine vom seriellen Port würde die Config etwa so bekommen:
1 | serialPort = new Uart(settings.UartConfig) |
Das geht in jeder Programmiersprache so ähnlich.
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)?
Z.b EEPROM.get(0,&settings) if(settings.ok!=1) settings=DEFAULT_SETTING; Zum Speichern EEPROM.put(0,&settings) EEPROM.Commit()
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. :-)
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.
*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
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.
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...
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
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.
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.
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?
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
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?
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.
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.
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.
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!
Angehängte Dateien:
-
gpio-use.06.png
100 KB
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
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.
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.
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
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... ;-)
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
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"
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?
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?
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.
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.
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.
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/
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.
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. :-)
@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
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.
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:
1 | #include <Arduino.h> |
2 | #include <EEPROM.h> |
3 | |
4 | // ========================================
|
5 | |
6 | struct ServoSettings { |
7 | int minPwmValue = 1100; |
8 | int centerPwmValue = 1500; |
9 | int maxPwmValue = 2400; |
10 | };
|
11 | |
12 | class ServoController { |
13 | public:
|
14 | ServoController(ServoSettings&); |
15 | private:
|
16 | ServoSettings &settings; |
17 | };
|
18 | |
19 | ServoController::ServoController(ServoSettings &s) : settings(s) { |
20 | Serial.print(F("Init servo with minPwmValue=")); |
21 | Serial.println(settings.minPwmValue); |
22 | // ...
|
23 | }
|
24 | |
25 | // ========================================
|
26 | |
27 | struct TemperatureSettings { |
28 | float min = 22.5; |
29 | float max = 24.1; |
30 | };
|
31 | |
32 | class TemperatureController { |
33 | public:
|
34 | TemperatureController(TemperatureSettings&); |
35 | private:
|
36 | TemperatureSettings &settings; |
37 | };
|
38 | |
39 | TemperatureController::TemperatureController(TemperatureSettings &s) : settings(s) { |
40 | Serial.print(F("Init user temp controller with min=")); |
41 | Serial.println(settings.min); |
42 | // ...
|
43 | };
|
44 | |
45 | // ========================================
|
46 | |
47 | struct UserSettings { |
48 | char name[20] = "noname"; |
49 | char password[20] = "dummy"; |
50 | };
|
51 | |
52 | class UserManagement { |
53 | public:
|
54 | UserManagement(UserSettings&); |
55 | private:
|
56 | UserSettings &settings; |
57 | };
|
58 | |
59 | UserManagement::UserManagement(UserSettings &s) : settings(s) { |
60 | Serial.print(F("Init user with name=")); |
61 | Serial.println(settings.name); |
62 | // ...
|
63 | }
|
64 | |
65 | // ========================================
|
66 | |
67 | struct AllSettings { |
68 | uint8_t test; // 0xFF indicates that the EEPROM is new and not initialized |
69 | TemperatureSettings temperature; |
70 | UserSettings user; |
71 | ServoSettings leftServo; |
72 | ServoSettings rightServo; |
73 | };
|
74 | |
75 | AllSettings globalSettings; |
76 | |
77 | TemperatureController *temperatureController; |
78 | UserManagement *userManagement; |
79 | ServoController *leftServoController; |
80 | ServoController *rightServoController; |
81 | |
82 | void setup() |
83 | {
|
84 | AllSettings tmp; |
85 | EEPROM.get(0, tmp); |
86 | if (tmp.test==0xFF) { |
87 | // copy defaults to EEPROM
|
88 | EEPROM.put(0, globalSettings); |
89 | } else { |
90 | // replace defaults in RAM by settings from EEPROM
|
91 | globalSettings=tmp; |
92 | }
|
93 | |
94 | Serial.print(F("Welcome ")); |
95 | Serial.print(globalSettings.user.name); |
96 | |
97 | temperatureController=new TemperatureController(globalSettings.temperature); |
98 | userManagement= new UserManagement(globalSettings.user); |
99 | leftServoController=new ServoController(globalSettings.leftServo); |
100 | rightServoController=new ServoController(globalSettings.rightServo); |
101 | }
|
102 | |
103 | void loop() { |
104 | // ...
|
105 | }
|
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.
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:
1 | 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:
1 | 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.
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
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. :-)
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.
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.
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.
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?
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.
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
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.
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?
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.
Angehängte Dateien:
-
schluckauf-1.png
260 KB
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:
1 | #define DEBUG_08X_scaffold_key_value_pairs true
|
2 | |
3 | #include <Arduino.h> |
4 | |
5 | class KeyValuePairs { |
6 | // void
|
7 | |
8 | public:
|
9 | // Constructor
|
10 | KeyValuePairs() { |
11 | #if DEBUG_08X_scaffold_key_value_pairs
|
12 | Serial.begin(9600); |
13 | Serial.println("Serial print started."); |
14 | ESP.wdtDisable(); |
15 | Serial.println("WatchDogTimer (WDT) disabled!"); |
16 | #endif
|
17 | }
|
18 | |
19 | // void
|
20 | };
|
21 | |
22 | void setup() { |
23 | // Initialize serial communication for debugging
|
24 | #if DEBUG_08X_scaffold_key_value_pairs
|
25 | Serial.begin(9600); |
26 | Serial.println("Setup() started."); |
27 | #endif
|
28 | |
29 | // Create an instance of KeyValuePairs
|
30 | KeyValuePairs kvPairs; |
31 | }
|
32 | |
33 | void loop() { |
34 | // Empty loop
|
35 | |
36 | }
|
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
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/
Uli schrieb: > Hat jemand von euch eine Erklärung? Ursache: Verwendung von uninitialisierten Zeigern (mehrere Möglichkeiten) Wirkung: ganz normaler Programmabsturz und Neustart
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
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!
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.
Angehängte Dateien:
-
schluckauf-2.png
260 KB
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
@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:
1 | #define DEBUG_08X_scaffold_key_value_pairs true
|
2 | |
3 | #include <Arduino.h> |
4 | |
5 | class KeyValuePairs |
6 | {
|
7 | public:
|
8 | KeyValuePairs() |
9 | {
|
10 | ESP.wdtDisable(); |
11 | #if DEBUG_08X_scaffold_key_value_pairs
|
12 | Serial.println("WatchDogTimer (WDT) disabled!"); |
13 | #endif
|
14 | }
|
15 | };
|
16 | |
17 | void setup() |
18 | {
|
19 | // Initialize serial communication for debugging
|
20 | Serial.begin(9600); |
21 | #if DEBUG_08X_scaffold_key_value_pairs
|
22 | Serial.println("Setup() started."); |
23 | #endif
|
24 | |
25 | // Create an instance of KeyValuePairs
|
26 | KeyValuePairs kvPairs; |
27 | |
28 | }
|
29 | |
30 | void loop() |
31 | {
|
32 | |
33 | }
|
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.
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:
1 | Flash Frequency: 40 MHz |
2 | 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).
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
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.
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
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
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
Beitrag #7724709 wurde von einem Moderator gelöscht.
Beitrag #7724711 wurde von einem Moderator gelöscht.
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:
1 | .../sketches/my-sketch/my-sketch.ino |
2 | .../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
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.
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.
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
1 | ./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!
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…
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
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.
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.
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
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?
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
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
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
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.
Angehängte Dateien:
-
IMG_20240915_150354.700.png
540 KB
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?
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.
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.
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.
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.
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...
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....
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/
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???
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?
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.
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.
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.
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.
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.
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.
Ich habe eine stumpfe Nadel herum liegen, mit der weite ich die Kontakte neuer Steckbretter etwas auf, wenn sie klemmen.
*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.
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. 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. :-)
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.
*@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.
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.
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.
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.
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.
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.
Beitrag #7740897 wurde von einem Moderator gelöscht.
Beitrag #7740913 wurde von einem Moderator gelöscht.
Sehe ich das richtig, dass mein letzter Beitrag gelöscht wurde? Wenn ja, weshalb? Er enthielt ein Bild des aktuellen Versuchsaufbaus.
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"?
Angehängte Dateien:
-
versuchsaufbau-3.jpeg
240 KB
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!
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.