ATMEGA328 Led-Fader Projekt instabil

[Flo F. (grange)]

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!

[Ohmy God (Gast)]

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.

[Flo F. (grange)]

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!

[Einer K. (Gast)]

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.

[Ohmy God (Gast)]

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.

[Flo F. (grange)]

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

[Frickelfritze (Gast)]

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.

[Stefan F. (Gast)]

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 (Gast)]

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.

[Flo F. (grange)]

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

[Flo F. (grange)]

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.

[Stefan F. (Gast)]

Jetzt musst du den Fehler durch weitere Textmeldungen einkreisen. 
Irgendwo hängt deine Main Loop. Das ist schonmal eine Aussage. Aber wo 
genau?

[Frickelfritze (Gast)]

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.

[Flo F. (grange)]

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.

[Frickelfritze (Gast)]

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.

[Stefan F. (Gast)]

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.

[Frickelfritze (Gast)]

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.

[Stefan F. (Gast)]

Scheiß auf das Datenblatt, das ist schön gerechnet (vermutlich ohne 
Antenne). Der ESP braucht bis zu 400mA.

[Flo F. (grange)]

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 :(

[Frickelfritze (Gast)]

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?

[Stefan F. (Gast)]

> 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?

[Stefan F. (Gast)]

> 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.

[Frickelfritze (Gast)]

Stefan U. schrieb:
> Klinge ich untervögelt?

Die Zusammehänge sind mir jetzt nicht so ganz klar ....

[Stefan F. (Gast)]

>> 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.

[Flo F. (grange)]

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...

[Frickelfritze (Gast)]

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.

[Stefan F. (Gast)]

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.

[Frickelfritze (Gast)]

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.

[Flo F. (grange)]

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

[Joachim B. (jar)]

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.

[Flo F. (grange)]

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 ^^

[Frickelfritze (Gast)]

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.

[Joachim B. (jar)]

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.

[Frickelfritze (Gast)]

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.

[Joachim B. (jar)]

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

[Flo F. (grange)]

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:

entering while loop
message waiting 
message received: statuscode={200};data={g=255;};path={setRGB};
reading data
setRGB called
rgb data: g=255;
token: g=255
end of handling incoming message
end of while loop

wenn keine Message ankommt (Modus ist 1 f. setRGB):

entering while loop
current mode: 1
end of while loop
entering while loop
current mode: 1
end of while loop
entering while loop
current mode: 1
end of while loop

und irgendwann, wenn der Controller beim Request stirbt, kommt nur noch:

entering while loop
current m

Es folgt kein Reset, keine weiteren Ausgaben...
Hoffentlich sind nun zumindest mal die Hardware-Probleme beseitigt.
lg

[Stefan F. (Gast)]

Meinst du nicht, dass deine Konstantstromquellen ein Verbindung zu GND 
benötigen?

Wie ist da eigentlich die vorgesehene Anschlussbelegung?

[Flo F. (grange)]

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.

[Stefan F. (Gast)]

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.

[Flo F. (grange)]

Und was passt am Anschluss des Spannungswandlers nicht? Habe die beiden 
Kondensatoren lt Datenblatt hinzugefügt.

Schaltplan versuche ich morgen noch zu machen.

[Stefan F. (Gast)]

Der 78xx hat links seinen Eingang, in der Mitte GND und rechts den 
Ausgang.

[Flo F. (grange)]

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 :)

[Stefan F. (Gast)]

> muß ein Tool finden mit dem das brauchbar geht

Wie gesagt: Bleistift. Zur Not geht auch ein Kugelschreiber.

[Flo F. (grange)]

Hi,

habe nun den Schaltplan mit easyEDA gemacht. Hoffentlich hat sich kein 
weiterer Fehler eingeschlichen.

lg

[Frickelfritze (Gast)]

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.

[Flo F. (grange)]

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.

[Stefan F. (Gast)]

> 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:

entering while loop
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.

[Flo F. (grange)]

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 ;)

[Stefan F. (Gast)]

> 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.

[Flo F. (grange)]

Ja, dachte ich mir dann auch, als ich nach dem Upload die Codeansicht 
entdeckt habe :)

[Stefan F. (Gast)]

Zwischen den beiden letzten Meldungen vermisse ich

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:

printf("Test a");
tu etwas
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.

[Flo F. (grange)]

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 ;)

[Rufus Τ. F. (rufus)]

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.

[Flo F. (grange)]

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.

[Dieter F. (Gast)]

Ich würde mir das

      returnValue = uexpect(stdin, MSG_FINISHED, NULL); 
      printf("message received: %s\r\n", uexpect_before);
      if (returnValue == -1) {
        printf("invalid return value\r\n");
        blinkR(10);
        return -1;
      }

in der Main-Routine auch nochmal genau anschauen. Was passiert, wenn ein 
Wert > 127 zurück kommt?

uexpect(...

 liefert einen dort hochgezählten uint8_t zurück.

[Stefan F. (Gast)]

> 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. (Gast)]

Dieter F. schrieb:
> liefert einen dort hochgezählten uint8_t zurück.

Kann ich nicht mehr bearbeiten - es ist ein int8_t.

[Stefan F. (Gast)]

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 :-)

[Flo F. (grange)]

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!

[Stefan F. (Gast)]

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.

[Flo F. (grange)]

Ja, den Ansatz hatte ich auch. War nur mit den AT Commands nicht 
zuverlässig. Mit NodeMCU müsste das gehen.

[Flo F. (grange)]

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!