Hallo liebe Forengemeinde, ich versuche seit einiger Zeit, meine Beleuchtung zuhause "smarter" zu machen, stehe aber irgendwie offenbar immer noch am Anfang der Leitung. Um nicht zu weit abzuschweifen: ich habe nach langem Lesen, Ausprobieren und Scheitern mittlerweile geschafft, eine LED über GET-Requests ein- und auszuschalten. Dabei stellt sich mir aber folgendes Problem in den Weg: das Setzen einer Farbe funktioniert relativ problemlos, doch manchmal reagiert mein Controller nicht mehr. Folgerequests werden weiterhin vom WiFi-Modul korrekt behandelt, der Controller reagiert dann aber erst nach Reset wieder. Das GET-Request für den Fader führt dazu, dass entweder der Controller irgendwann (für mich nicht nachvollziehbar wann) innerhalb der Iteration der Farbe stirbt oder spätestens ein folgender Request zum Sterben führt. 1) Hardware: 1a) ATMEGA328P mit AVRISPMKII programmiert. Dieser bekommt mittels UART vom ESP01 eine Art JSON und soll diese Kommandos interpretieren. Den ATMEGA nenne ich im Folgenden µC :) 1b) ESP8288 (ESP01) mit NodeMCU, rudimentäre Funktionalität mit LUA programmiert. Der Chip parst nur das GET-Request und gibt die extrahierten Infos an den ATMEGA328P weiter. Dabei wird immer ESP_FINISHED\r\n mitgeschickt, um am µC darauf warten zu können. Ein Command besteht aus path (setRGB / fade) und commands (r=255&g=0&b=0 oder h=100&s=1&i=1) 1c) eine RGB LED hängt über drei kleine KSQs an den PWM-Pins des ATMEGA328P 2) Software: 2a) uart Library von Martyn Welch: https://github.com/mwelchuk/atmel/tree/master/atmega328p/libraries/uart Implementierung von Buffern für Rx und Tx. Stabiler als meine eigenen Versuche. In der Zwischenzeit habe ich allerdings NodeMCU auf dem ESP01 und damit wesentlich weniger Probleme mit UART im Vergleich zu den AT-Commands und den uneinheitlichen Antworten darauf. Praktisch ist, dass ich durch die Library printf() etc nutzen kann. 2b) uexpect Libary von Martyn Welch: https://github.com/mwelchuk/atmel/tree/master/atmega328p/libraries/uexpect Lesen der Response - blockt bis eine erwartete Antwort zurückkommt 3) Fehlerbilder: Mittels Debug-Ausgaben von ATMEGA328p über USB/RS232 Converter an den PC habe ich versucht, den Fehler einzugrenzen. Dabei sind mir drei Fälle aufgefallen 3a) irgendwann im Betrieb bleibt der µC wohl stecken. Es erfolgt keine Ausgabe mehr, der µC resettet auch nicht. 3b) die Prüfung, ob über UART ein Character empfangen wurde ist erfolgreich, es kommt aber nie der erwartete Response an. Lesen vom Stream blockt. Das kann imho nur an Noise auf der Leitung liegen, denn der ESP01 sendet nur definierte Antworten und nur dann, wenn ich ein Request absetze. Vielleicht liegt das aber tatsächlich an Noise, das Problem konnte ich nämlich häufig am Breadboard beobachten, auf einer gelöteten Platine allerdings nicht mehr. 3c) Unexpected Interrupt: nach einiger Recherche habe ich den BADISR_vect gefunden und eine Methode implementiert. Diese wird wohl auch aufgerufen, konnte allerdings keine Korrelation zwischen User-Aktionen und diesem Zustand herausfinden. 4) Schaltung: anhand mehrerer Tutorials habe ich die Minimalbeschaltung aufgebaut. Der Reset-Pin wurde mittels 100nF Kondensator vor Spannungsschwankungen geschützt. Ein 16MHz-Quarz findet ebenfalls Verwendung. Ein Foto der schnell zusammengelöteten Bastelplatine hänge ich an, ebenso das ATMEL Studio 7 Projekt. So, ich freue mich über jede Hilfe und jeden Ratschlag. Leider kann es von einer fehlerhaften Beschaltung über falsch gesetzten Bits bis zu Programmierfehlern alles sein. Die volatile-Variablen für den Fader stehen dabei im Verdacht, konnte aber beim "Debuggen" keine Besserung erzielen. Vielen Dank für jede Antwort, frohe Weihnachten und schöne Feiertage!
Angehängte Dateien:
-
schaltung.jpg
230 KB
Flo F. schrieb: > 1) Hardware: So geht das nicht. Schaltplan in Prosa ist scheisse. Entweder du hast sie geschickt aus dem Foto ausgeblendet oder es sind keine da. Die Abblock-Kondensatoren! Weitere Fehlerquellen in der Schaltung und in der Stromversorgung sind nicht ausgeschlossen.
Ohmy God schrieb: > So geht das nicht. Schaltplan in Prosa ist scheisse. > > Entweder du hast sie geschickt aus dem Foto ausgeblendet > oder es sind keine da. Werde noch einen Schaltplan nachreichen, sobald ich dazu kommen. Den Abblockkondensator (100nF) von RST nach VCC habe ich tatsächlich weggeschnitten auf dem Foto, sorry!
Flo F. schrieb: > Den > Abblockkondensator (100nF) von RST nach VCC habe ich tatsächlich > weggeschnitten auf dem Foto, Der ist nicht gemeint! Die anderen beiden... darum dreht es sich.
Flo F. schrieb: > Den > Abblockkondensator (100nF) von RST nach VCC habe ich tatsächlich > weggeschnitten auf dem Foto, sorry! Lies die Grundlagen über Abblock-Kondensatoren hier im Forum (https://www.mikrocontroller.net/articles/Hauptseite) oder in einer Application Note von Atmel.
Angehängte Dateien:
-
schaltplan.png
390 KB
Hi, danke für die Antworten bisher. Ich habe nun die Abblockkondensatoren nachgerüstet und es scheint so, als wären Fall 2 und 3 damit erledigt. Fall 1 habe ich mir nochmals angesehen: läuft der µC im Fader-Modus und wird ein weiteres Request empfangen, so hat es den Anschein gemacht, als würde der µC einfach stecken bleiben. Neulich ist mir aber zufällig aufgefallen, dass der µC nicht steckt, sondern irgendwie total langsam wird (~ Faktor 10). PWM läuft weiterhin, nur über UART kann nichts mehr gesendet oder empfangen werden und ein Zyklus dauert ungefähr 10x so lange wie zuvor. Hat jemand eine Idee woran das liegen könnte? Anbei ein "Schaltplan" mittels Fritzing erstellt. Hoffentlich reicht das so aus. Danke schonmal & einen schönen restlichen Feiertag! lg
Flo F. schrieb: > Anbei ein "Schaltplan" mittels Fritzing erstellt. Hoffentlich reicht das > so aus. Zum verstehen reicht es, ob es für die einwandfreie Funktion reicht kann man aus der Entfernung nicht sagen. Steckbretter und Aufbau schwanken stark in ihrer Qualität. Flo F. schrieb: > Hat jemand eine Idee woran das liegen könnte? C4 und C5 gehören nicht einfach auf Masse sondern an direkt an die Masse des Controlers (so nahe wie möglich) angeschlossen. Dein Spannungsregler hat immer noch keine Abblock-Kondensatoren, lies im zugehörigen Datenblatt dazu nach was du tun musst. Und das ist kein Luxus, sondern ein Muss. Dann empfiehlt es sich noch an Eingang vom Netzteil einen Elko 100uF zu setzen um die KSQs zu stützen. Meine nicht sehr hellseherische Glaskugel sagt mir dass der Controller durch Störungen auf der Versorgung in einen undefinierten Zustand gerät aus dem er nicht wieder in normale Operation zurückkehren kann.
Korrigiere zuerst Schwachpunkte in der Hardware. Dann geht es mit der Software weiter, falls der Fehler dann noch besteht: Du musst herausfinden, wo genau er stecken bleibt. Nutze irgendeinen freien I/O Pin, um Statusmeldungen auszugeben. Füge nach und nach Statusmeldungen zu deinem Programm hinzu, bis du den Fehlerpunkt eingekreist hast. Du kannst hier Codebeispiele und Anleitung dazu finden: http://stefanfrings.de/avr_hello_world/index.html Wenn dein serieller Port schon belegt ist, nimm eine soft-serial Implementierung wie in meinem HelloTiny.zip Beispiel.
Frickelfritze schrieb: > Meine nicht sehr hellseherische Glaskugel sagt mir dass > der Controller durch Störungen auf der Versorgung in einen > undefinierten Zustand gerät aus dem er nicht wieder in > normale Operation zurückkehren kann. Eine zweite Vermutung ist dass das ESP01-Modul seinen Dienst versagt weil seine Spannungsversorgung (siehe Spannungsregler) nicht ordnungsgemäss aufgebaut/beschaltet ist.
Frickelfritze schrieb: > C4 und C5 gehören nicht einfach auf Masse sondern an direkt > an die Masse des Controlers (so nahe wie möglich) angeschlossen. Ah, vielen Dank für diese Info. Habe bisher noch keine Skizzen gefunden, wo das so gelöst gewesen wäre. Die Adaptierung hat aber leider keine Änderung gebracht. Frickelfritze schrieb: > Dein Spannungsregler hat immer noch keine Abblock-Kondensatoren, > lies im zugehörigen Datenblatt dazu nach was du tun musst. > Und das ist kein Luxus, sondern ein Muss. Ok, laut Datenblatt gehört hier ein 1µF Kondensator her. Den habe ich aber nicht da - ist bestellt. Frickelfritze schrieb: > Dann empfiehlt es sich noch an Eingang vom Netzteil einen > Elko 100uF zu setzen um die KSQs zu stützen. Habe ich leider auch nicht da. Um das auszuschließen habe ich nun aber mal PWM deaktiviert und stattdessen textuelle Ausgaben eingebaut. Das Verhalten ist dasselbe: Entweder endet die Übertragung mitten in der Message oder an dessen Ende, es folgt aber keine weitere Ausgabe. Kann man damit sagen, dass es nicht am Einbruch der Versorgungsspannung liegt? Stefan U. schrieb: > Du musst herausfinden, wo genau er stecken bleibt. Nutze irgendeinen > freien I/O Pin, um Statusmeldungen auszugeben. Füge nach und nach > Statusmeldungen zu deinem Programm hinzu, bis du den Fehlerpunkt > eingekreist hast. Danke für deinen Input. Ich habe bereits diverse Ausgaben in meinem Programmcode. Zum Testen habe ich eine Ausgabe an erster Stelle des main-Loops, der sich nicht mehr wiederholt wenn im Fader-Modus noch ein Request empfangen wird. Hattest du etwas anderes im Sinn? Danke euch nochmals, ich bin leider ziemlich ratlos :( lg
Frickelfritze schrieb: > Frickelfritze schrieb: >> Meine nicht sehr hellseherische Glaskugel sagt mir dass >> der Controller durch Störungen auf der Versorgung in einen >> undefinierten Zustand gerät aus dem er nicht wieder in >> normale Operation zurückkehren kann. > > Eine zweite Vermutung ist dass das ESP01-Modul seinen Dienst > versagt weil seine Spannungsversorgung (siehe Spannungsregler) > nicht ordnungsgemäss aufgebaut/beschaltet ist. Das ESP-Modul sendet einerseits eine Antwort auf das GET-Request, andererseits eine UART-Message an den µC. Der Browser bekommt den Statuscode 200, die Nachricht am µC sehe ich aber nicht ... Wenn der µC bereits nicht mehr reagiert, kann ich immer noch Requests zum ESP01 pollen. Dieser antwortet aber weiterhin richtig mit 200 oder 501, je nach Request.
Jetzt musst du den Fehler durch weitere Textmeldungen einkreisen. Irgendwo hängt deine Main Loop. Das ist schonmal eine Aussage. Aber wo genau?
Flo F. schrieb: > Ok, laut Datenblatt gehört hier ein 1µF Kondensator her. Ich vermute du kannst dein Datenblatt nicht richtig lesen. Aber nachdem du es verschweigst um welchen Spannungsregler es sich handelt kann ich das nicht mit letzter Sicherheit beurteilen. Ein "U2/3.3V" reicht nicht.
Frickelfritze schrieb: > Flo F. schrieb: > Ok, laut Datenblatt gehört hier ein 1µF Kondensator her. > > Ich vermute du kannst dein Datenblatt nicht richtig lesen. > Aber nachdem du es verschweigst um welchen Spannungsregler > es sich handelt kann ich das nicht mit letzter Sicherheit > beurteilen. > > Ein "U2/3.3V" reicht nicht. Der Spannungsregler ist ein LP2950ACZ-3.3 Das Datenblatt das ich gefunden hätte, ist folgendes: https://www.onsemi.com/pub/Collateral/LP2950-D.PDF Gut möglich dass ich es nicht richtig lesen kann. Im Text steht "• Requires Only a 1.0µF Output Capacitor for Stability". Sonst weiß ich leider nicht wonach ich suchen soll.
Flo F. schrieb: > Der Spannungsregler ist ein LP2950ACZ-3.3 Der kann laut Datenblatt nur 100mA, das dürfte für Spitzen- lasten beim ESP01-Modul zu wenig sein. Kann funktionieren, muss aber nicht. Ein LM1117-3.3 wäre deutlich günstiger.
Dir ist schon klar, dass so ein ESP Modul einen 500mA Spannungsregler braucht? Dein LP2950 ist dafür viel zu schwach. Nimm zum Beispiel einen LF33CV.
Angehängte Dateien:
-
ESP01_Power.png
17 KB
Frickelfritze schrieb: > das dürfte für Spitzen- > lasten beim ESP01-Modul zu wenig sein. Hier noch ein Auszug aus dem Datenblatt für den ESP.
Scheiß auf das Datenblatt, das ist schön gerechnet (vermutlich ohne Antenne). Der ESP braucht bis zu 400mA.
Danke euch beiden. Habe ich natürlich vollkommen übersehen. Werde morgen einen geeigneten Wandler besorgen. Wie kommt man denn auf die benötigten Werte? Habe im Datenblatt zum ESP01 eine max. Angabe von 215mA gefunden. -edit- wurde bereits beantwortet während ich getippt habe :-) Und stimmt es, dass ich für den LM1117-3.3 einen 10µF benötige? Die Conrad-Produktbeschreibung gibt an: "Die Ausgangsspannungskonstanz von 1 % wird bereits mit einem Elko von nur 10 µF (bei max. Ausgangsstrom von 800 mA) erreicht." Dh. der ESP reißt den mC in den Tod? Danke euch, da sind wohl doch noch einige Baustellen :(
Flo F. schrieb: > Und stimmt es, dass ich für den LM1117-3.3 einen 10µF benötige? Warum verlässt du dich auf die Angaben eines Verkäufers wenn dir ein Datenblatt verbindliche Angaben liefert?
> Wie kommt man denn auf die benötigten Werte?
Indem man zuerst wie üblich dem Datenblatt glaubt (das damals noch
falscher war), dann auf die Schnauze fällt und dann selber nach misst.
Oder man googelt danach, was andere dazu herausgefunden haben.
Auf jeden Fall muss man erst mal dahinter kommen, dass das Datenblatt
von Espressif als Werbeprospekt vor Produktion des Chips begann und dann
erst nach und nach auf die tatsächlichen Daten korrigiert wurde.
Es stehen aber immer noch viele Halbwahrheiten drin. Normalerweise rate
ich ja immer zu RTFM, aber beim ESP rate ich dazu, woanders
Informationen zu suchen. Jede Hobbybastler-Homepage ist besser, als das.
Klinge ich untervögelt?
> Warum verlässt du dich auf die Angaben eines Verkäufers wenn > dir ein Datenblatt verbindliche Angaben liefert? Vielleicht, weil er von Datenblatt des ESP so beeindruckt wurde, dass er gar nichts mehr glaubt.
Stefan U. schrieb: > Klinge ich untervögelt? Die Zusammehänge sind mir jetzt nicht so ganz klar ....
>> Klinge ich untervögelt? > Die Zusammehänge sind mir jetzt nicht so ganz klar ... Macht nichts, nicht wichtig. Ich bin nur von diesem Sch*** Datenblatt extrem genervt.
Stefan U. schrieb: > Indem man zuerst wie üblich dem Datenblatt glaubt (das damals noch > falscher war), dann auf die Schnauze fällt und dann selber nach misst. Das ist mal eine wertvolle Ansage für mich. Versuche immer zu verstehen wie und wieso. Da hilft mir ein "ist einfach so, weil aus Erfahrung..." schon weiter. Frickelfritze schrieb: > Warum verlässt du dich auf die Angaben eines Verkäufers wenn > dir ein Datenblatt verbindliche Angaben liefert? Weil ich mit dem Datenblatt schlicht überfordert bin. Habe nochmal versucht da drin etwas zu finden. Stimmt es, dass man einen 10µF Kondensator für dein Eingang braucht und einen 100µF für den Ausgang, aber nur bei regulierbaren Wandlern? Also kann man den weglassen, weil der LM1117 auf 3,3V fixiert ist? Wie du siehst habe ich da einige Verständnisprobleme...
Flo F. schrieb: > Ah, vielen Dank für diese Info. Habe bisher noch keine Skizzen gefunden, > wo das so gelöst gewesen wäre. Nachtrag: so etwas ist in Application Notes von Atmel zu finden. Aber auch hier auf uC.net wird alle Nase lang drauf hingewiesen. Schaue dir einfach existierende Layouts an, dort wird entweder (auch) an dieser Stelle herumgemäkelt oder es ist bereits sauber gelöst.
Weiss ich jetzt nicht. Die Datenblätter von Spannungsreglern enthalten doch meisten einen kleinen Schaltplan mit konkreten Werten. Orientiere dich daran. An dein ESP-01 Modul sollte zusätzlich ein 100µF Kondensator, direkt an die VCC und GND Pins. Am besten auf das Modul drauf löten. Der läuft dann stabiler. Mein Testobjekt läuft seit April 2017 ohne Ausfall und ohne bemerkte Fehlfunktion durch. Ohne Kondenstor hatte ich in 4 Wochen 6 Ausfälle.
Flo F. schrieb: > Weil ich mit dem Datenblatt schlicht überfordert bin. Übernimm einfach die Werte aus einem im Datenblatt dargestellten Standard-Schaltungsvorschlag. Das geht in den meisten Fällen nicht schief.
Ok, dann besorge ich morgen mal ein paar Kondensatoren in besagten Dimensionen. Bin ja schon gespannt was als nächstes als völlig falsch aufschlägt. Kann mich nur noch mal bedanken, auf all das wäre ich sowieso nie selbst gekommen :) Schönen Abend allerseits
ich hatte auch den ESP826601 nur mit einen TO92 78L05 (100mA max.) versorgt und mich über sporadische Abstürze gewundert, aber mit einem BC habe ich den 78L05 einfach kurzgeschlossen durch den Atmel und so einen power reset am ESP ausgeführt, 100µF am ESP helfen auch die gröbsten Stromspitzen vom ESP zu puffern. Besser ist natürlich ein low drop Regler der den ESP auch passend mit Spitzenstrom versorgt.
Joachim B. schrieb: > aber mit einem BC habe ich den 78L05 einfach kurzgeschlossen durch den > Atmel und so einen power reset am ESP ausgeführt, Den Absatz versteh ich leider nicht. Außerdem wundert es mich, dass der ESP (zumindest augenscheinlich) der einzige stabile Part in der Schaltung ist ^^
Flo F. schrieb: > Den Absatz versteh ich leider nicht. Pfusch durch Kurzschlüsse muss man weder verstehen können noch (praktisch und theoretisch) nachvollziehen sollen.
Frickelfritze schrieb: > Pfusch durch Kurzschlüsse muss man weder verstehen können sagt ausgerechnet einer der sich frickelfritze nennt :) Der 78L05 ist kurzschlußfest und weil sich gerade ein BC NPN in der Kiste befand, war es so am leichtesten VCC wegzuschalten. LowDrop Regler für 1,5A mit enable habe ich dann später beschafft, wobei ich mit der nicht fachgerechten "Kurzschlußmethode" auch durchaus Erfolg hatte. Das Ergebnis zählt manchmal mehr als die korrekte aber dafür Nichtfunktion.
Joachim B. schrieb: > sagt ausgerechnet einer der sich frickelfritze nennt :) Wie schön dass du auf dem Weg über meinen Nick so gut über mich Bescheid weisst. Deine Vorgehensweise jedenfalls spricht Bände.
Frickelfritze schrieb: > Wie schön dass du auf dem Weg über meinen Nick so gut > über mich Bescheid weisst. an deinem Beitrag war nicht mehr zu lesen, nur Gesülze und keinerlei Nützliches für den TO. Ja meckern ohne Lösungen zu präsentieren ist ja leichter! EDIT: OK einiges Nützliches hast du ja geschrieben ich bitte um Vergebung
Angehängte Dateien:
-
schaltplan.png
410 KB
Hallo, komme gerade von der Apotheke und habe nun die benötigten Teile aufgebaut. Das Verhalten hat sich nicht großartig verändert, nur dass die anderen Fehler nun gar nicht mehr aufgetreten sind. Aber weiterhin bleibt: schicke ich schnell genug ein paar Requests über den Browser an den ESP01, bleibt der µC einfach stecken. Habe nun überall innerhalb der main-Loop Ausgaben eingebaut. Es ist offenbar indeterministisch an welcher Stelle Schluss ist, die Nachrichten kommen auch nur teilweise an. Beispiel eines Zyklus nach Abschluss der initialen Funktionen (Wifi ist connected, ...), wenn eine Nachricht empfangen wurde:
1 | entering while loop |
2 | message waiting |
3 | message received: statuscode={200};data={g=255;};path={setRGB};
|
4 | reading data |
5 | setRGB called |
6 | rgb data: g=255; |
7 | token: g=255 |
8 | end of handling incoming message |
9 | end of while loop |
wenn keine Message ankommt (Modus ist 1 f. setRGB):
1 | entering while loop |
2 | current mode: 1 |
3 | end of while loop |
4 | entering while loop |
5 | current mode: 1 |
6 | end of while loop |
7 | entering while loop |
8 | current mode: 1 |
9 | end of while loop |
und irgendwann, wenn der Controller beim Request stirbt, kommt nur noch:
1 | entering while loop |
2 | current m |
Es folgt kein Reset, keine weiteren Ausgaben... Hoffentlich sind nun zumindest mal die Hardware-Probleme beseitigt. lg
Meinst du nicht, dass deine Konstantstromquellen ein Verbindung zu GND benötigen? Wie ist da eigentlich die vorgesehene Anschlussbelegung?
Im Datenblatt finde ich nichts dazu: https://www.pollin.at/p/led-konstantstromquellen-bausatz-810037 Kannst du dir das Fehlerbild dadurch erklären? Solange ich keine Requests an den ESP02 sende, tun die KSQ ja auch ohne zu meckern.
Mach nochmal einen richtigen Schaltplan. Deine Zeichnung ist total wirr. Das passt weder der Anschluss der Konstantstromquellen, noch des Spannungsreglers. Man darf das auch mit Bleistift machen und abfotografieren! Mit viel Phantasie könnte das irgendwie passen. Es macht aber wenig Sinn wenn ich Dir bestätige, dass der Plan in meinem Kopf, der nicht deinem entspricht, ok ist.
Und was passt am Anschluss des Spannungswandlers nicht? Habe die beiden Kondensatoren lt Datenblatt hinzugefügt. Schaltplan versuche ich morgen noch zu machen.
Der 78xx hat links seinen Eingang, in der Mitte GND und rechts den Ausgang.
Ja, es ist ein 1117v33 siehe Beschriftung. Leider bekam ich das Label des Bauteils nicht weg, daher die Beschriftung darüber. Mache es dann morgen nochmal, muß ein Tool finden mit dem das brauchbar geht. TinyCAD finde ich zum Haare ausreißen :)
> muß ein Tool finden mit dem das brauchbar geht
Wie gesagt: Bleistift. Zur Not geht auch ein Kugelschreiber.
Beitrag #5257619 wurde von einem Moderator gelöscht.
Beitrag #5257671 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
schaltbild_easyEDA.png
71 KB
Hi, habe nun den Schaltplan mit easyEDA gemacht. Hoffentlich hat sich kein weiterer Fehler eingeschlichen. lg
Sorry aber so wie du den Schaltplan zeichnest ist (vermutlich) auch das Chaos in der realen Schaltung. Ich werde alleine durch die Art der Darstellung das Gefühl nicht los (ohne das wirklich begründen zu können) dass du hier einfach "mutwillig" Bauelemente miteinander verknüpfst, verdrahtest ohne eine gewisse Systematik anzuwenden. Was dann auch zu einer Fehl- funktion führen kann. Dabei schaut das mit dem Fritzing- Steckbrett noch plausibler, vernünftiger aus.
Gut, du kritisierst also alles, sagst aber auch nicht was dich genau stört oder wie es besser ginge. Die Art der Darstellung stimmt also auch nicht. Meine Schaltung ist auf einem Steckbrett aufgebaut, wie in der Fritzing-Darstellung ersichtlich. Die Platine aus dem ersten Posting war ein zusätzlicher Versuch, um Wackelkontakte auszuschließen. Ich bin Anfänger in Sachen Elektronik, versuche zu lernen und Ratschläge umzusetzen. Aber "alles ist schlecht" hilft mir nunmal nicht weiter.
> habe nun den Schaltplan mit easyEDA gemacht Sehr schön, viel besser so. Beim ESP Modul würde ich den Reset Pin noch mit 2,2k Ohm auf +3,3V ziehen. Ansonsten reagiert er manchmal aus versehen auf die Funksignale. Für die ersten Experimente ist das sicher noch egal. Ich denke, dass die Konstantstromquellen so richtig angeschlossen sind. Warum hast du eigentlich den Aufwand getrieben und nicht einfach Widerstände genommen? Nur damit wir nicht in die falsche Richtung suchen: Dein Problem ist immer noch, dass der AVR irgendwann hängen bleibt und nur noch diese Meldungen ausgibt:
1 | entering while loop |
2 | current m |
Ist das die letzte Meldung und dann passiert gar nichts mehr, oder gibt er diese beiden Meldungen wiederholt aus? Bitte sei so nett und hänge den aktuellen Quelltext an, aber nicht in diesem komischen ZIP Format, sondern nur die *.c und *.h Dateien.
Stefan U. schrieb: > Ich denke, dass die Konstantstromquellen so richtig angeschlossen sind. > Warum hast du eigentlich den Aufwand getrieben und nicht einfach > Widerstände genommen? Das ist so entstanden :-) habe erstmal Zeug bestellt, herumprobiert und herumgebastelt und dann schrittweise alles erweitert. Die KSQs haben keinen PWM-Eingang (Pollin 1€ - Teile) und da ich mittlerweile weiß dass man nicht die Last schalten darf, habe ich es so gelöst. Zum Probieren reicht das ja und funktioniert ansich auch tadellos. Stefan U. schrieb: > Nur damit wir nicht in die falsche Richtung suchen: Dein Problem ist > immer noch, dass der AVR irgendwann hängen bleibt und nur noch diese > Meldungen ausgibt: Genau, der Microcontroller bleibt innerhalb eines Schleifendurchlaufs stecken. Bei irgendeiner Ausgabe ist dann mittendrin Schluss. Es erfolgt dann keine weitere Ausgabe mehr. So, Source ist nun auch enthalten. Dass ZIP komisch ist, hab' ich vorher allerdings auch noch nie gehört ;)
> Dass ZIP komisch ist, hab' ich vorher allerdings auch noch nie gehört
In diesem Forum sind einzelne Files praktischer. Probiere mal, die
Anhänge zu öffnen.
Ja, dachte ich mir dann auch, als ich nach dem Upload die Codeansicht entdeckt habe :)
Zwischen den beiden letzten Meldungen vermisse ich
1 | message waiting (%d)\r\n |
Der Code ist schon zu umfangreich, um da da mal eben schnell Fehler drin zu erkennen. Ich würde die Serielle Ausgabe (Tx) so umprogrammieren, dass sie ohne Interruopt und ohne Puffer auskommt, also blockierend arbeitet. Etwa so wie in meinem HelloTiny Projekt (http://stefanfrings.de/avr_hello_world/HelloTiny.zip). Die Eingabe (Rx) lass ruhig so wie sie ist. Und zwar deswegen: An der unvollständigen Ausgabe erkennt man, dass der µC abgestürzt ist. Aber die Ursache ist nicht erkennbar. Wahrscheinlich ist während der interruptgesteuerten seriellen Ausgabe im Hauptprogramm irgend etwas schief gegangen. Die genau Stelle kann man an den Meldungen aber nicht erkennen. Wenn du die Ausgabe blockierend machst, dann ist garantiert, dass die Ausgaben immer vollständig sind, bevor irgendein anderer Befehl ausgeführt wird. Zweitens kann man genau erkenenn, wo er hängen geblieben ist:
1 | printf("Test a");
|
2 | tu etwas |
3 | printf("Test b");
|
Wenn die zweite Meldung fehlt, ist der Fehler garantiert zwischen den beiden Meldungen. In deinem aktuellen Code (mit Sende Puffer) kann der wahre fehler aber ganz woanders sein, weil die Daten verzögert gesendet werden. Hilft das weiter? Falls nicht, würde ich schrittweise Sachen auskommentieren, bis das Programm nicht mehr hängt. Oder du versuchst mal ganz banal, die beiden seriellen Puffer auf 30 Bytes zu verkleinern. Wenn das Programm dann plötzlich stabil läuft, hattest du vermutlich einfach nur einen Stack Überlauf, also zu wenig RAM.
Ok ja, wollte als Nächstes dann sowieso die Kommunikation austauschen um so den Fehler einzugrenzen. Sind die Hardware-Fehler deiner Meinung nach nun behoben? Dann kann ich mich auf die Software konzentrieren. Und stimmt der Schaltplan so? Kann leider noch immer nicht nachvollziehen, was am Layout so grob daneben ist. Besten Dank für deine Hilfe, irgendwann wird das Projekt vielleicht tatsächlich mal fertig ;)
Flo F. schrieb: > Sind die Hardware-Fehler deiner Meinung nach nun behoben? Die Konstantstromquellen sind nur mit GND und einem Ausgang des µC verbunden, d.h. mit keiner anderen Spannungsquelle? Das kommt mir irgendwie merkwürdig vor. Der "Schaltplan" ist schlecht lesbar; aus gutem Grund werden üblicherweise in Schaltplänen nicht Bilder von IC-Gehäusen mit der gleichen Pinanordnung, sondern logisch strukturierte Abbildungen verwendet. Versorgungsspannungs- und Masseleitungen werden auch nicht quer durch die Landschaft gezogen, sondern auch im Schaltplan kurz und übersichtlich gehalten, i.d.R. wird auf die Verbindung sogar verzichtet und nur zu einem passenden Masse- bzw. Versorgungssymbol verbunden. Das reduziert das Leitungsgewirr.
Rufus Τ. F. schrieb: > Die Konstantstromquellen sind nur mit GND und einem Ausgang des µC > verbunden, d.h. mit keiner anderen Spannungsquelle? Die KSQ sind mit +5V verbunden und mit einem PWM-Pin des AVR. Dh. ich schalte die KSQ eingangsseitig mittels PWM. Da ich nicht die Last schalten will, war das meine einzige Möglichkeit (die ich gesehen habe). Werde das aber auf Widerstände umbauen um Verwirrungen zu vermeiden. Danke für die Aufklärung zum Schaltplan, werde alsbald eine übersichtlichere Version erstellen.
Ich würde mir das
1 | returnValue = uexpect(stdin, MSG_FINISHED, NULL); |
2 | printf("message received: %s\r\n", uexpect_before); |
3 | if (returnValue == -1) { |
4 | printf("invalid return value\r\n"); |
5 | blinkR(10); |
6 | return -1; |
7 | }
|
in der Main-Routine auch nochmal genau anschauen. Was passiert, wenn ein Wert > 127 zurück kommt?
1 | uexpect(... |
liefert einen dort hochgezählten uint8_t zurück.
> Sind die Hardware-Fehler deiner Meinung nach nun behoben? Ich denke schon, ja. > Der "Schaltplan" ist schlecht lesbar Im Vergleich zu dem vorherigen Bild hat er es schon viel besser gemacht. Übung macht den Meister.
Dieter F. schrieb: > liefert einen dort hochgezählten uint8_t zurück. Kann ich nicht mehr bearbeiten - es ist ein int8_t.
Mir ist gerade was komisches aufgefallen. Beim ESP-1 Modul ist der TxD Pin als 1 markiert. Aber beim ESP-01 ist der GND Pin als 1 markiert. Aber lasst euch nicht verwirren :-)
Dieter F. schrieb: > in der Main-Routine auch nochmal genau anschauen. Was passiert, wenn ein > Wert > 127 zurück kommt? Du hast dich ja bereits korrigiert, aber um da einen Wert > 127 zurückzubekommen müsste man entsprechend viele Argumente in die Methode schicken. Habe auch die Ausgabe (invalid value) noch nie gesehen. Ich frage mich aber generell Folgendes: der Code in uexpect.c läuft doch Character für Character durch, für jeden Character wird die Liste der Patterns abgearbeitet. getc() blockt, bis ein Character am Stream verfügbar ist. D.h. die Methode kann nur dann -1 returnen, wenn am Strea UEXPECT_BUF_SIZE Characters verfügbar sind oder? Na wie auch immer, werde den Code morgen mal austauschen und dann weitersehen. Stefan U. schrieb: > Beim ESP-1 Modul ist der TxD Pin als 1 markiert. > Aber beim ESP-01 ist der GND Pin als 1 markiert. > > Aber lasst euch nicht verwirren :-) Zu spät :-D Eine generelle Frage noch: wie handhabt ihr die UART-Kommunikation in euren Projekten? Ein Problem das sich mir immer wieder stellt, ist wie ich am besten auf eine eingehende Nachricht reagieren kann. Die uart-Library liest zwar komfortabel vom Stream, blockt aber bis Characters verfügbar sind. Eine non-blocking Lösung habe ich mangels <sys/select.h> nicht hinbekommen. Denn die Idee grundsätzlich war: in jedem Schleifendurchlauf prüfe, ob eine Message vollständig empfangen wurde. Falls ja, wird der Inhalt geparst und der Modus entsprechend geändert. Sonst mache weiter wie bisher. Schönen Abend euch allen!
Ich habe eine Funktion geschrieben die mir verrät ob im Puffer ein Zeilenumbruch existiert. Nur wenn das der Fall ist lese ich eine Zeile heraus.
Ja, den Ansatz hatte ich auch. War nur mit den AT Commands nicht zuverlässig. Mit NodeMCU müsste das gehen.
Schönen Abend, liebe µC-Experten. Leider war ich diese Woche krank, daher erst heute ein Update. ----------- Was habe ich gemacht ----------- Ich habe die UART-Library nun ausgetauscht und gegen diese hier ersetzt: https://github.com/andygock/avr-uart Die Lib verwendet kein uexpect und blockt somit auch nicht, wenn der Buffer leer ist. Soweit also so gut. Dann habe ich durch Herumprobieren herausgefunden, wieso beim Faden alles so langsam wird. Es lag am _delay_ms() Call, der dafür gesorgt hat, dass der Fader nicht zu schnell die Farbe wechselt. Nur führten die 100ms dazu, dass auch die UART-Receive-Interrupts viel langsamer wurden. Durch Testausgaben konnte ich zusehen, wie das Empfangen eines Characters deutlich länger dauerte als zuvor und im "setRGB"-Modus aber weiterhin wie gewohnt ziemlich flott ging. Ich dachte eigentlich, dass die Interrupts hier nicht beeinträchtigt werden, aber naja. Jedenfalls habe ich nun die _delay_s Calls entfernt und lasse dafür einen weiteren Timer laufen. ----------- Neues (altes?) Problem aufgetaucht ----------- Das Problem war vielleicht neu oder aber ein generelles, altes Problem. Und zwar stürzte der Controller mit dem mittlerweile gewohnten Fehlerbild ab (irgendwo bleibt eine Ausgabe stecken). Nach längerem Debuggen konnte ich den Fehler fixen (war wohl ein segfault), der Fehler lies sich aber komischerweise dadurch vermeiden, indem eine Message über UART geschickt wurde... Eigenartig. Daraus schließe ich aber, dass auch die bisherigen Steckenbleiber einen ähnlichen Ursprung hatten (Stefan Us hatte das ja schon vermutet, daher sein Ratschlag auf synchrone UART umzustellen). ----------- Aktueller Zustand ----------- Ich habe noch ein paar Problemchen beim richtigen Setzen der Werte für den Fader-Timer, sonst läuft das Teil aber nun ziemlich stabil. Bleibt noch euch nochmals herzlich für all eure Mühen zu danken, da wäre ich sonst definitiv dran gescheitert. Den aktuellen Code kann ich nachreichen, falls ihn jemand haben möchte. Schönen Abend noch!
Thread beobachten
Seitenaufteilung abschaltenBitte 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.