mikrocontroller.net

Forum: Projekte & Code WordClock mit WS2812


Autor: Peter G. (ingrimsch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

mir ist gestern Abend noch ein Fehler im "Clock2" Ambilight mit weniger 
als 60 LEDs aufgefallen... ich vermute da stimmt die Offsetberechnung 
nicht.

Ausgangssituation: WC12H, WS2812 GRB, 30 LED Ambilight, Clock2, Offset 
LED bei 15

Das Ambilight an sich funktioniert und bei der "normalen" Clock macht 
der Sekundenzeiger auch brav eine Runde. Bei Clock2 fängt er dann ab der 
Offset LED an zu füllen bzw. zu leeren, kommt aber nach LED30 nicht 
weiter auf LED1, sondern tut dann für 30 Sekunden gar nichts mehr, bis 
er wieder die Offset LED erreicht hat. Danach gehts dann normal 
weiter...

Ich versuche immer wieder mal zu verstehen was genau da softwareseitig 
passiert, leider bin ich programmiertechnisch eher unbedarft, daher die 
folgenden Zeilen bitte mit der nötigen Vorsicht lesen, vielleicht habe 
ich auch einfach nicht richtig verstanden was genau da passiert. Ich übe 
noch, habt also Nachsicht falls ich nen Bock geschossen habe... ;-)

So sieht die Offsetberechnung bei "Clock" aus:
else if (display.ambilight_leds >= 30)
{
    led_idx = seconds / 2;
    led_idx += display.ambilight_led_offset;
    n_clock_leds = 30;
}

...
if (n_clock_leds)
{
    if (led_idx >= n_clock_leds) // wrap around
            {
                led_idx -= n_clock_leds;
            }
...

Wenn ich es richtig verstehe würde hier also zu den 30 LEDs in led_idx 
noch der Offset addiert (in meinem Beispiel 15), dann wird etwas später 
die eingestellte Anzahl der LEDs wieder subtrahiert falls led_idx den 
Wert von n_clock_leds übersteigt.

Bei Clock2 scheint der zweite Teil zu fehlen bzw. etwas anders gestaltet 
zu sein. I wird hier auf jeden Fall größer als n_clock_leds wenn man 
einen Offset benutzt, das Programm landet also in der Schleife und zieht 
die fest eingestellten 60 von i ab. Müssten da statt 60 nicht eigentlich 
eher n_clock_leds von i subtrahiert werden?
if (n_clock_leds)
{
    CALC_LED_RGB(rgb, dimmed_ambilight_colors);
    if (ambilight_clock_increasing)
        {
            for (idx = 0; idx <= led_idx; idx++)
                {
                    uint_fast8_t i = idx + display.ambilight_led_offset;
                   if (i >= n_clock_leds)  // wrap around
                    {
                        i -= 60;
                    }

                    display_set_ambilight_led (i, &rgb, 0); // switch LED on
                }
         }
else

Habe leider gerade keine Hardware zum testen hier, aber vielleicht kann 
mir ja jemand sagen ob ich halbwegs verstanden habe was da passiert. :-)


Ich hätte auch noch zwei Punkte für die Wünschliste:

- Bei der deceleration der Rainbow Animation würde ich mir noch ein oder 
zwei Abstufungen zwischen "0" und "1" wünschen

- Wenn die Rainbow Animation läuft ist das Display trotz unterster 
eingestellter Stufe bei der Helligkeit noch ziemlich hell. Auf der 
kleinen Fläche der Tischuhr ist das ziemlich viel Licht auf sehr wenig 
Raum. Ich würde mir hier die Möglichkeit wünschen, die Helligkeit noch 
weiter runter regeln zu können falls es nicht zu viel Aufwand ist.

Gruß,
Peter

Autor: Bernhard S. (b_sa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Torsten,

die Shields sehen wirklich gut aus. Allerdings scheinen, wenn mich mein 
mittlerweile nicht mehr ganz so geschärfter Blick nicht täuscht, die 
Befestigungsbohrungen beim Redesign abhanden gekommen zu sein. Beim 
Nucleo-Shield nicht ganz so tragisch, da das Nucleo-Board ja welche hat, 
beim Mini-Dev-Board wären dann allerdings gar keine mehr vorhanden. Ich 
weiß, dass des schwierig ist, die in den Zwischenböden auf Grund der 
Platzverhältnisse "ordentlich" zu verschrauben, aber es widerstrebt mir 
eigentlich, die Boards einzukleben.

Gruß,
Bernhard

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter G. schrieb:
> Müssten da statt 60 nicht eigentlich
> eher n_clock_leds von i subtrahiert werden?

Ja, sieht so aus. Ich schaue mir die Stelle nochmal im Source an.

> Ich hätte auch noch zwei Punkte für die Wünschliste:
>
> - Bei der deceleration der Rainbow Animation würde ich mir noch ein oder
> zwei Abstufungen zwischen "0" und "1" wünschen

Ui, so flott lässt Du das laufen? Ich schaue mal, was sich da machen 
lässt.


> Ich würde mir hier die Möglichkeit wünschen, die Helligkeit noch
> weiter runter regeln zu können falls es nicht zu viel Aufwand ist.

Mit der nächsten Version (2.6.0) kannst Du die Helligkeitskurve im 
Browser selbst anpassen.

Autor: Torsten Giese (wawibu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard S. schrieb:
> Allerdings scheinen, wenn mich mein
> mittlerweile nicht mehr ganz so geschärfter Blick nicht täuscht, die
> Befestigungsbohrungen beim Redesign abhanden gekommen zu sein.
Ja - die sind komplett entfallen. Da der Boden eh nur sehr dünn ist, 
hatte ich nicht damit gerechnet, dass die Boards jemand wirklich 
festschraubt. Daher habe ich die Löcher und mir damit Platz für das 
ESP12F, den UART Jumper, den APA102 Jumper und die 2 Taster geschaffen 
ohne das Board in der Größe zu ändern.
Ich bekomme die Bohrlöcher nur dann wieder rein, wenn ich das Board 
vergrößere - was ich vermeiden will.
Persönlich klebe ich die Boards immer mit etwas Heißkleber fest. Das hat 
bisher super funktioniert.

Gruß,
Torsten

Autor: Bernhard S. (b_sa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Torsten,

Torsten G. schrieb:
> Da der Boden eh nur sehr dünn ist,
> hatte ich nicht damit gerechnet, dass die Boards jemand wirklich
> festschraubt.

Hatte ich ja bereits angemerkt, dass das 'ne ziemliche "Fummelei" ist 
und ich weiß auch, dass die Dinger keiner als Reise(uhr|wecker) benutzt, 
aber man hat schließlich seinerzeit mal gelernt, dass die eingestzten 
Bauteile "ordentlich befestigt" gehören.

> Ich bekomme die Bohrlöcher nur dann wieder rein, wenn ich das Board
> vergrößere - was ich vermeiden will.

Das habe ich schon gesehen und wenn es für neue Funktionen nicht 
zwingend erforderlich ist muss das Board auch nicht künstlich 
vergrössert werden

> Persönlich klebe ich die Boards immer mit etwas Heißkleber fest. Das hat
> bisher super funktioniert.

Dann will ich mal versuchen, mich mit dieser Befestigungsmethode 
anzufreunden ;-).

Gruß,
Bernhard

Autor: Peter G. (ingrimsch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ui, so flott lässt Du das laufen? Ich schaue mal, was sich da machen
> lässt.

Ich selbst nicht, war eine Anfrage aus dem Freundeskreis. 0 war zu 
schnell und 1 war zu langsam. Egal was man tut, man kann es halt nie 
allen recht machen :-)

> Mit der nächsten Version (2.6.0) kannst Du die Helligkeitskurve im
> Browser selbst anpassen.

Tolle Sache! War mir nicht sicher ob der Punkt auf der ToDo Liste das 
auch abdeckt.


Ich habe am Wochenende auch endlich mal den ganzen Kram für die WC12h 
Tischuhr bei Thingiverse hochgeladen, dokumentiert und heute die Infos 
dazu hier im Wiki ergänzt. Ich hoffe das ist in Ordnung und dass ich 
nichts vergessen habe.
Falls ihr Fehler findet, Anmerkungen oder Probleme mit den Modellen habt 
schreibt mir einfach hier im Thread oder per PN.

Bedingt durch die geringe Größe der Uhr und die gängigen Größen der 
Druckbetten in aktuellen 3D Druckern musste ich das Gehäuse leider für 
"krumme" 90 LED/m Strips konzipieren. Dadurch sollte jetzt aber so 
ziemlich jeder mit einem 3D Drucker die Möglichkeit haben, die kleine 
Tischuhr nachzubauen.

Weitere Infos gibt es im Wiki:
https://www.mikrocontroller.net/articles/WordClock...

Die Tischversion der WC24h liefere ich die Tage auch noch nach, die ist 
aber sowohl was den mechanischen Aufbau, als auch die Voraussetzungen an 
den Drucker angeht, deutlich komplizierter. Kann ich echt nur 
fortgeschrittenen Druckern/Bastlern/Lötern empfehlen.


Gruß,
Peter

Autor: Torsten Giese (wawibu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter G. schrieb:
> Ich habe am Wochenende auch endlich mal den ganzen Kram für die WC12h
> Tischuhr bei Thingiverse hochgeladen, dokumentiert und heute die Infos
> dazu hier im Wiki ergänzt. Ich hoffe das ist in Ordnung und dass ich
> nichts vergessen habe.

Hi Peter,
das ist super! Wenn ich nur endlich mal die Zeit finden würde meine 
Tischuhr fertig zu bauen......
Ich bestelle mir jetzt einfach mal die Stripes und dann wird das schon 
werden.

Konnte auf Anhieb keinen Fehler / nichts fehlendes in der Beschreibung 
finden.

Grüße,
Torsten

Autor: Peter G. (ingrimsch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Torsten,

danke fürs Überfliegen!


Torsten G. schrieb:
> Wenn ich nur endlich mal die Zeit finden würde meine
> Tischuhr fertig zu bauen......

Oh ja, das liebe Zeitproblem... kenn ich auch. ;-)
Hattest du dich über die große Menge bestellter Zwischenböden in der 
aktuellen Sammelbestellung gewundert? Ich muss bis September noch 
insgesamt 8 (!) versprochende Wanduhren fertig bekommen, danach sieht es 
mit der Freizeit vermutlich erstmal ziemlich mau aus, denn dann wird der 
bestellte Nachwuchs geliefert. Die Vorbereitung läuft aktuell noch so 
nebenher, aber da muss ja zwischendurch auch noch fleißig renoviert, 
gemalert und aufgebaut werden. Vielleicht sollte ich mir Frank als 
Unterstützung holen, der kann ja sogar während eines Umzugs noch 
nebenher basteln und hat dann auch noch Zeit für 
Frontplattentauschaktionen übrig! (Danke nochmal!) ;-P

> Ich bestelle mir jetzt einfach mal die Stripes und dann wird das schon
> werden.

Für die gedruckte WC24h brauchst du ja ohnehin 144LED/m Strips um die 
ganzen LEDs unter zu bringen. Die SK6812 gibt es als kleine 3535SMD 
(leider nur in RGB) Version. Bei Aliexpress gibt es Streifen auf denen 
die Dinger verbaut sind, die schmaler sind als die normalen 144LED/m 
Streifen. Würde ich dir empfehlen, denn sonst musst du die Streifen 
teilweise übereinander kleben und es wird deutlich schwieriger 
Streulicht in den umliegenden Lichtschächten zu vermeiden.

Ich hatte nach meinem ersten Versuchen mit regulären 144LED/m Strips 
diese hier bestellt: 
https://www.aliexpress.com/item/1mX-addressable-7-...

Leider kam ich auch noch nicht dazu hiermit eine komplette Uhr 
aufzubauen. Die testhalber gedruckte WC12h wird ein Geburtstagsgeschenk 
für meine Schwester, die auch schon sehnsüchtig auf deine 24h 
Zwischenböden wartet. Ihr Freund hatte sie zu der großen 24h für die 
Wand überredet, jetzt bekommt sie halt noch ne kleine 12h für den 
Schreibtisch. :-)

Gruß,
Peter

Autor: Thomas B. (dnw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
>> Ich hätte auch noch zwei Punkte für die Wünschliste:
>>
>> - Bei der deceleration der Rainbow Animation würde ich mir noch ein oder
>> zwei Abstufungen zwischen "0" und "1" wünschen
>
> Ui, so flott lässt Du das laufen? Ich schaue mal, was sich da machen
> lässt.

Hallo Frank,

einen Wunsch bzgl. Rainbow Animation hätt ich da auch noch. ;)
Wär es möglich den Geschwindigkeitsregler mehr oder weniger nach oben 
offen zu gestalten? Fände es auch ganz interessant, wenn man den 
Farbdurchlauf auf 1x alle 24h oder evtl. sogar 1x pro Woche stellen 
könnte...

PS: Evtl. hat das ja auch was mit dem obigen Punkt zu tun, hab da grad 
nicht so den Überblick...

Gruß
Tom

Autor: Florian R. (florifranzl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich warte aktuell auf die Lieferung der Zwischenböden, aber 
interessehalber schon mal eine Frage dazu: Die scheinen ja nicht viel 
kleiner zu sein als die Fronten, oder? Sieht man also bei rahmenloser 
Montage bei schräger Ansicht den hölzernen Zwischenboden, so dass man 
den eigentlich weiß/schwarz anmalen müsste? Wie habt ihr das gelöst? Die 
Möglichkeit eines Rahmens habe ich gesehen, aber ich finde die Uhr 
rahmenlos eigentlich schöner.

Autor: Günter H. (gnter_h534)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Florian R. schrieb:
> Sieht man also bei rahmenloser
> Montage bei schräger Ansicht den hölzernen Zwischenboden, so dass man
> den eigentlich weiß/schwarz anmalen müsste?

Ja.

> Wie habt ihr das gelöst?

Einfach mal hier im Forum nach "Umleimer" oder "lackieren" suchen.

Autor: Peter G. (ingrimsch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Florian R. schrieb:
> Wie habt ihr das gelöst?

Hi Florian,

kommt ein wenig drauf an ob du die 24h oder 12h baust und ob du ein 
Ambilight verbaust.

Bei der 12h mit Ausfräsungen für das Ambilight male ich die Ecken i.d.R. 
einfach nur in schwarz/weiß/Wandfarbe an. Ohne Ambilight genauso. 
Alternativ hatte ich mal bei zwei Uhren an den Ecken jeweils 3mm per 
Kreissäge weggeschnitten und dann über die ganze Länge 3mm starke 
Plexiglass Streifen in milchig angeklebt. Bei den letzten 12h die ich 
gebaut habe, hatte ich ein weißes Objekt auf dem 3D Drucker erstellt, 
dass genau in die Ambilightausfräsungen passte und die Ecken passend 
dazu weiß lackiert. Ich würde sagen es kommt etwas darauf an wo die Uhr 
hängt und wie perfektionistisch oder empfindlich du bei solchen Dingen 
bist.

Ich persönlich mag die sichtbaren Kanten in Holzfarbe nicht, aber sobald 
man die Sichtflächen weiß/schwarz angemalt hat, stört mich auch die 
Ausfräsung fürs Ambilight nicht mehr. Bei mir schaut man nur sehr selten 
auf die seitlichen Kanten.

Mit der 24h habe ich bisher keine Erfahrungen machen können (mit der 
laufenden Sammelbestellung baue ich jetzt erstmals auch welche).

LG,
Peter

Autor: Florian R. (florifranzl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Info. Habs mir schon gedacht. 12h ohne Ambilight wird es 
bei mir. Weiße Farbe fliegt hier noch genug rum, dann werde ich den 
Rahmen vermutlich auch anmalen.

Autor: Jens L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
>> Zweite Frage:
>> Auf der Arbeit darf ich die Uhr weder ins WLAN bringen, noch einen AP
>> aufspannen. Gibt es die Möglichkeit WLAN per Software ganz abzuschalten
>> und erst mittels User-Button wieder zu aktivieren?
>
> Ich könnte einbauen, dass der ESP in den Sleep-Mode geschickt wird. Der
> Power-Down-Pin kann nämlich vom STM32 gesteuert werden. Beim Drücken des
> User-Buttons könnte dann der ESP wieder aufgeweckt werden. Kommt auf die
> TODO-Liste.

Hallo Frank,

ich hatte dieses Feature zwischenzeitlich mal auf der ToDo-Liste 
gesehen, nun ist es aber wieder verschwunden. Kann das sein, oder bin 
ich blind?

Eine weitere Frage zum "Abschalten des Wlan":
Könnt ihr bestätigen, dass die Uhr keine AP mehr aufmacht, auch wenn man 
sie in den Client-Modus in ein nicht vorhandenes Netz bringt?

Ich habe einfach mal als SSID "Test" und Kennwort "Test" verwendet. Die 
Uhr versucht sich damit zu verbinden, zeigt aber natürlich keine IP an.
In diesem Zustand verbleibt sie dann einfach und tauch nicht mehr in der 
WLan-Liste auf.

So könnte ich sie doch dann an Orten betreiben, an denen ich kein Wlan 
aufspannen / "stören" darf, oder was meint ihr?

Befindet sich der ESP so quasi im Sleep-Mode was das Wlan angeht?

Vielen Dank und Gruß,
Jens

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens L. schrieb:
> ich hatte dieses Feature zwischenzeitlich mal auf der ToDo-Liste
> gesehen, nun ist es aber wieder verschwunden. Kann das sein, oder bin
> ich blind?

Nein, Du hast Recht. Ich hadere noch, ob ich mir die damit verbundene 
Arbeit für einen Einzelnen antun soll. Schließlich bist Du der Einzige, 
der explizit ein abgeschaltetes WLAN wünscht. Desweiteren ist für den 
ESP-12F überhaupt keine Steuerung des CH_PD-Pins mehr vorgesehen. Hier 
liegt der Pin über einen Pullup fest auf 3,3V. Das Feature "Abschalten 
des ESP" wäre also nur noch für die aussterbende Variante mit dem ESP-01 
zu machen.

Außer Du hängst an CH_PD noch einen Schalter, der dann gegen GND 
schließt. So könntest Du den ESP zumindest manuell abschalten. Ich 
müsste in der STM32-Software aber immer noch dafür sorgen, dass diese 
trotzdem weiterläuft und nicht beleidigt ist, wenn der ESP nicht mehr 
antwortet.

> Ich habe einfach mal als SSID "Test" und Kennwort "Test" verwendet. Die
> Uhr versucht sich damit zu verbinden, zeigt aber natürlich keine IP an.
> In diesem Zustand verbleibt sie dann einfach und tauch nicht mehr in der
> WLan-Liste auf.

Ja, ist so. Bis Du die User-Taste drückst, bleibt der ESP im 
Client-Mode.

> So könnte ich sie doch dann an Orten betreiben, an denen ich kein Wlan
> aufspannen / "stören" darf, oder was meint ihr?

Prinzipiell ja, solange es kein Flugzeug ist. ;-)

> Befindet sich der ESP so quasi im Sleep-Mode was das Wlan angeht?

Das würde ich so nicht vergleichen.

Autor: Vo M. (vo_m)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo zusammen,

... ich schiebe die Entschuldigung gleich vorweg, aber ich finde nix:

Gibt es für die WordClock12h (mit Ambilight) eine (evtl. bemaßte oder 
CAD) Datei zur Erstellung des Zwischenbodens?

Viele Grüße & vielen Dank,
Volker

Autor: Ph L. (filo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

sind noch Frontplatten und Zwischenböden für die 12h Variante aus der 
Sammelbestellung zu haben? Hab den Termin leider verpasst.
Wäre der Hammer.
Grüßle

Autor: Torsten Giese (wawibu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vo M. schrieb:
> Gibt es für die WordClock12h (mit Ambilight) eine (evtl. bemaßte oder
> CAD) Datei zur Erstellung des Zwischenbodens?
Eine CAD Datei gibt es nicht.
Die wichtigen Maße zu dem Boden findest Du noch in dem ersten Artikel 
zur WordClock
https://www.mikrocontroller.net/articles/Word_Cloc...

Es sind dort aber keine Maße für die Taschen oder für die 
Ambilightaussparung drin. Wenn Du die Böden selber machen willst, kannst 
Du diese aber auch dann individuell machen.

Gruß,
Torsten

Autor: Peter G. (ingrimsch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vo M. schrieb:
> Gibt es für die WordClock12h (mit Ambilight) eine (evtl. bemaßte oder
> CAD) Datei zur Erstellung des Zwischenbodens?

Hi Volker,

es gibt Infos zu den Maßen im Artikel der ursprünglichen Version der 
Wordclock: 
https://www.mikrocontroller.net/articles/Word_Cloc...

Da findest du auch ein 3D PDF und eine STP Datei, sowie Angaben zu den 
Frästiefen. Die Fräsausschnitte auf der Rückseite haben sich zwar 
verändert, aber ich bin mir  nicht sicher was der Grund dafür war, oder 
ob sie passen würden.

Vielleicht kannst du damit ja was anfangen... ich glaube ein aktuelleres 
Layout wurde nie veröffentlicht, weil es dazu keine CAD Datei mehr gab 
oder die Zwischenplatten von einer Schreinerei erstellt wurden.

Gruß,
Peter

Autor: Torsten Giese (wawibu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ph L. schrieb:
> Hallo zusammen,
>
> sind noch Frontplatten und Zwischenböden für die 12h Variante aus der
> Sammelbestellung zu haben? Hab den Termin leider verpasst.
> Wäre der Hammer.
> Grüßle

In dem WordClock Artikel steht doch beschrieben, an wen man sich wenden 
soll, wenn man entsprechende Teile haben möchte
https://www.mikrocontroller.net/articles/WordClock...

Frontplatte >> Frank
Böden >> ich

Wenn Du Dich beeilst, kann ich ggf die von Dir benötigte Menge an Böden 
noch an meine Bestellung dranhängen. Mein Bestand/Reserve ist nämlich 
auf 0.

Gruß,
Torsten

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ph L. schrieb:
> sind noch Frontplatten und Zwischenböden für die 12h Variante aus der
> Sammelbestellung zu haben? Hab den Termin leider verpasst.

Da sich immer wieder ein paar Nachzügler melden, habe ich 
vorsichtshalber ein paar mehr Frontplatten bestellt. Du kannst Dich also 
noch an der Sammelbestellung beteiligen. Melde Dich einfach per PN.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas,

Andreas M. schrieb:
> Ich weiß, Du hast jetzt wenig Zeit, aber wann wäre die neue ESP-Version
> verfügbar? Ich würde einen Aufruf für die App implementieren, um die
> Einstellungen von der Uhr laden zu können. Ich würde aber gerne mit der
> aktuellsten Version anfangen, um die Unterschiede klein zu halten.

Hattest Du meine PN bekommen? Dort hatte ich Dir den Download-Link auf 
die aktuellen ESP-Sources genannt.

Autor: Andreas M. (andiator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

ja, danke, habe ich gesehen. Ich hatte den Eindruck, dass Du Codemäßig 
da noch mehr machst, deswegen warte ich lieber auf eine Release-Version. 
Also habe ich nicht viel mehr geändert, nur mal getestet, wie ich an die 
Variablen rankomme. Meine Idee ist, dass die Android-App die 
Einstellungen von der Uhr holt und die Uhr nicht automatisch mit 
Einstellungen bombardiert ;) Die in der App gespeicherten Profile halte 
ich aber für sinnvoll, so kann man schnell eine neue Uhr einrichten oder 
Vorhandene umschalten.

SVN finde ich sehr gut, da muss man aber diszipliniert vorgehen, nur 
funktionierende Sachen einchecken und so. Wir würden uns wahrscheinlich 
ab und zu in die Quere kommen, weil wir die selben Dateien verändern 
würden.
Ist aber alles handelbar.

MfG,
Andreas

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> ja, danke, habe ich gesehen. Ich hatte den Eindruck, dass Du Codemäßig
> da noch mehr machst, deswegen warte ich lieber auf eine Release-Version.

Weitere Neuerungen kommen da nicht mehr rein, nur Fixes aufgrund der 
Tests vor dem Release. Die dürften aber minimal sein. Du kannst Dich 
also ruhig austoben. Mittels diff kriege ich Deine Änderungen ziemlich 
schnell synchronisiert.

> Also habe ich nicht viel mehr geändert, nur mal getestet, wie ich an die
> Variablen rankomme. Meine Idee ist, dass die Android-App die
> Einstellungen von der Uhr holt und die Uhr nicht automatisch mit
> Einstellungen bombardiert ;)

Der ESP hält sämtliche Einstellungen von der Uhr immer up-to-date. Wenn 
sich etwas auf dem STM32 ändert, wird der ESP direkt darüber informiert. 
Der STM32 muss also gar nicht gefragt werden, der ESP kann der APP 
sofort eine Antwort geben auf die Fragen:

   "Welchen RGB-Wert hat das Display?"
   "Welche Helligkeit?"
   "Welchen Animation ist eingestellt?"
   usw.

Oder vielleicht so:

   "Schick mir mal Deine kompletten Einstellungen rüber."

und der ESP sendet dann direkt alle an die App - ähnlich, wie es STM32 
und ESP auch untereinander machen.

> Die in der App gespeicherten Profile halte
> ich aber für sinnvoll, so kann man schnell eine neue Uhr einrichten oder
> Vorhandene umschalten.

Ja, halte ich auch für sehr sinnvoll. Ich bringe meine WC24h immer 
durcheinander, wenn ich zuletzt den Typ auf WC12h in der App eingestellt 
habe - wegen einiger Tests auf einer WC12.

> SVN finde ich sehr gut, da muss man aber diszipliniert vorgehen, nur
> funktionierende Sachen einchecken und so.

Nein, es können auch ungetestete Sachen eingecheckt werden. Hauptsache 
der Compiler geht durch und bis zum Release ist es auch getestet. Wenn 
Du etwas an der Funktionalität A bastelst und ich an B, stört es mich 
nicht im Geringsten, wenn A mal eine zeitlang nicht richtig arbeitet. 
Ich arbeite dann an B und Disfunktionalität bei A macht mir dann gar 
nichts.

> Wir würden uns wahrscheinlich
> ab und zu in die Quere kommen, weil wir die selben Dateien verändern
> würden.

Solange es nicht dieselben Zeilen innerhalb derselben Datei sind, ist 
das überhaupt kein Problem. Deshalb sollte man auch zeitnah einchecken, 
damit die Unterschiede nicht zu groß werden.

Autor: Andreas M. (andiator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Weitere Neuerungen kommen da nicht mehr rein, nur Fixes aufgrund der
> Tests vor dem Release

Als ich da reinschaute, war da eine Tabelle mit grünen Felder und Namen 
zu sehen? Und der meine Änderungen (Lokaler STM Update Reiter) hatte ich 
nicht gesehen, so hatte ich angenommen, dass das noch unvollständige 
Testsachen sind.

Frank M. schrieb:
> "Schick mir mal Deine kompletten Einstellungen rüber."

So hatte ich mir das auch gedacht. Das einzige, was man beachten sollte, 
ist, dass die App-Version zu der Uhr-Version passt.
Ich überlege auch eine automatische IP-Ermittlung, weiß aber noch nicht 
ob es mit dem ESP klappt (UDP Broadcast).

Über den SVN-Zugang können wir uns dann per PN austauschen. Das aber 
erst nach der Arbeit.

MfG,
Andreas

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Als ich da reinschaute, war da eine Tabelle mit grünen Felder und Namen
> zu sehen? Und der meine Änderungen (Lokaler STM Update Reiter) hatte ich
> nicht gesehen, so hatte ich angenommen, dass das noch unvollständige
> Testsachen sind.

Hm, okay, ich überprüfe das nochmal. Eigentlich sollten Deine Änderungen 
alle drin sein... Ich melde mich per E-Mail - morgen oder übermorgen.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Und der meine Änderungen (Lokaler STM Update Reiter) hatte ich
> nicht gesehen

Ich habe gerade in den Source geschaut: Ich habe vergessen, die Zeile

  menu_entry ("flash_stm32_local", "Local Update");

in http_menu() zu übernehmen. Daher ist der neue Reiter bei Dir 
"unsichtbar" ;-)

Durch Einfügen dieser Zeile sollten Deine Änderungen sichtbar und damit 
wirksam werden.

Sorry,

Frank

Autor: Andreas M. (andiator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, ich wollte mich da nicht aufdrängen :)

Gestern sind endlich die "nackten" ESPs gekommen, so werde ich demnächst 
mir eine W12h Uhr bauen (Danke an Peter für die 3D Modelle).
Bis jetzt ist die "Uhr" nur auf dem Breadboard und die LEDs immer noch 
aufgerollt. Ist etwas schwierig zu erkennen, was angezeigt wird ;)

MfG,
Andreas

Autor: Jens L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Jens L. schrieb:
>> ich hatte dieses Feature zwischenzeitlich mal auf der ToDo-Liste
>> gesehen, nun ist es aber wieder verschwunden. Kann das sein, oder bin
>> ich blind?
>
> Nein, Du hast Recht. Ich hadere noch, ob ich mir die damit verbundene
> Arbeit für einen Einzelnen antun soll. Schließlich bist Du der Einzige,
> der explizit ein abgeschaltetes WLAN wünscht. Desweiteren ist für den
> ESP-12F überhaupt keine Steuerung des CH_PD-Pins mehr vorgesehen. Hier
> liegt der Pin über einen Pullup fest auf 3,3V. Das Feature "Abschalten
> des ESP" wäre also nur noch für die aussterbende Variante mit dem ESP-01
> zu machen.
>
> Außer Du hängst an CH_PD noch einen Schalter, der dann gegen GND
> schließt. So könntest Du den ESP zumindest manuell abschalten. Ich
> müsste in der STM32-Software aber immer noch dafür sorgen, dass diese
> trotzdem weiterläuft und nicht beleidigt ist, wenn der ESP nicht mehr
> antwortet.
>
>> Ich habe einfach mal als SSID "Test" und Kennwort "Test" verwendet. Die
>> Uhr versucht sich damit zu verbinden, zeigt aber natürlich keine IP an.
>> In diesem Zustand verbleibt sie dann einfach und tauch nicht mehr in der
>> WLan-Liste auf.
>
> Ja, ist so. Bis Du die User-Taste drückst, bleibt der ESP im
> Client-Mode.
>
>> So könnte ich sie doch dann an Orten betreiben, an denen ich kein Wlan
>> aufspannen / "stören" darf, oder was meint ihr?
>
> Prinzipiell ja, solange es kein Flugzeug ist. ;-)
>
>> Befindet sich der ESP so quasi im Sleep-Mode was das Wlan angeht?
>
> Das würde ich so nicht vergleichen.

Hallo Frank,

vielen Dank für die ausführliche Antwort.
Dann stecke da auch bitte keine Arbeit mehr rein. So reicht es 
vollkommen.
Der ESP im Client-Modus beeinflusst nicht merklich.
Ich werde also für diese Einsatzzwecke beim ESP-01 bleiben und habe mir 
das Layout sowie die Software "eingefroren".

LG
Jens

Autor: Peter G. (ingrimsch)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

ich habe mittlerweile erfolgreich ein Shield von Torsten auf einen 
ESP-12F umgebaut und kann jetzt endlich auch den STM flashen und neu 
starten. So weit so gut... klappt jedenfalls so lange bis ich alles 
einmal vom Strom getrennt und wieder angeschlossen habe. Danach startet 
irgendwie der STM nicht sauber hoch, das Display bleibt aus, auf dem 
UART gibt es keine Meldungen (nur RX verbunden/USB UART/TTL nicht 
verbunden macht keinen Unterschied), aber ich kann per WLAN auf das Teil 
zugreifen. Ich habe mal versucht es in Bildern festzuhalten...

2_stm_incomplete_boot_main.PNG
--> Keine Ausgabe auf Display oder UART, WLAN Zugriff ist aber möglich. 
Hier fällt mir auf, dass auch das EEPROM nicht erkannt wird...

3_stm_incomplete_boot_network.PNG
--> zumindest die IP stimmt

4_stm_reset_ueber_webinterface.PNG
--> Wenn ich jetzt per Knopf oder Button im Webinterface den STM neu 
starte...

5_stm_nach_reset.PNG
--> dann funktioniert alles wie gehabt. Display und UART melden sich, 
das EEPROM wird erkannt, usw.

Danach funktioniert alles so lange, bis ich den Strom kappe. Ist der 
Strom wieder da geht das Spiel wieder von vorne los... ich bin irgendwie 
der Meinung hier schon mal ein ähnliches Fehlerbild gelesen zu haben, 
finde aber gerade den entsprechenden Post nicht. Hast du eine Idee was 
die Ursache für das beschriebene Verhalten sein könnte? Kann ich noch 
irgendwas testen oder sinnvolle Informationen ergänzen?

Gruß,
Peter

: Bearbeitet durch User
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter G. schrieb:
> So weit so gut... klappt jedenfalls so lange bis ich alles
> einmal vom Strom getrennt und wieder angeschlossen habe. Danach startet
> irgendwie der STM nicht sauber hoch,

Das Phänomen ist bekannt und wurde hier schon diskutiert. Das liegt 
daran, dass GPIO16 vom ESP beim Boot kurzzeitig einen HIGH-Pegel erzeugt 
und damit den STM32 wieder in den Bootloader-Modus bringt. Das hindert 
den STM32 am Durchstarten.

Leider ist das Verhalten des ESP nicht änderbar, das scheint eine 
hartverdrahtete Macke des GPIO16 zu sein.

Aus diesem Grund wird ab Version 2.6.0 auch GPIO4 statt GPIO16 
verwendet. Torsten hat das bereits beim Shield v3 berücksichtigt und 
einige User hier im Forum haben das auch schon getestet. Danach startet 
der STM32 normal durch. Sobald die 2.6.0 erscheint, wird auch die 
Umbauanleitung im Artikel angepasst.

Bis zum Erscheinen der Version 2.6.0 empfehle ich Dir, die Strippe von 
GPIO16 an BOOT0 rauszuziehen. Dann sollte beim Power-Up der STM32 wieder 
normal starten.

: Bearbeitet durch Moderator
Autor: Peter G. (ingrimsch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

ach, ich bin doch doof! Ich hab in der Zwischenzeit auch die 
entsprechenden Beiträge gefunden und gelesen. Auf meinem Adapter ist 
sogar schon ein kleiner Lötjumper für die Umstellung vorgesehen, ich 
hatte gar nicht mehr daran gedacht... -.-

Ok, dann hat sich das ja mit der nächsten Version erledigt und ich kann 
auch bestehende Uhren auf OTA upgraden, wo doch jetzt alles so schön 
funktioniert. :-)

Danke für den Hinweis!

Gruß,
Peter

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert

Das schon länger angekündigte Update 2.6.0 ist nun online.

Änderungen:

  • Neu: WPS Button, damit ESP8266 sich per WPS mit dem Router (AccessPoint) verbinden kann.
  • Neu: Liste der verfügbaren Access-Points im Webinterface.
  • Neu: Abschaltbares Ambilight per WebInterface - ungetestet.
  • Neu: Ein-/Ausschalten des Ambilights über Timer - ungetestet.
  • Neu: Ambilight-Animation "Clock" jetzt mit 5-Sekunden-Marker (ungetestet).
  • Neu: Konfigurierbare Helligkeitskurve bei automatischer oder manueller Regelung.
  • Neu: Geschwindigkeitsregelung der Ticker-Texte
  • Neu: OTA-Update des STM32 nun auch mit Upload vom lokalen PC aus möglich.
  • Neu: Konfigurierbarer Host und Pfad für OTA-Updates - geplant für die zukünftige Herausgabe von Pre-Testversionen im neuen Pfad "test".
  • Optimierung der DS18xx/OneWire/Delay-Funktionen, um die Prozessorlast zu minimieren.
  • Bugfix: Falsche Berechnung von Überläufen in CLOCK2-Animation für Ambilight (Anzahl Ambilight-LEDs = 30) korrigiert.
  • Bugfix: Diverse Korrekturen im Layout English2 für WC12h.
  • Neu: Zusätzliches Layout für WC12h: "Schweizerdeutsch 2".
  • Neu: WCtris, noch ein Tetris-Clone. Bedienbar über die Android-App.
  • Änderung der Verbindung zwischen ESP-12F und STM32: GPIO4 (und nicht mehr GPIO16) muss nun mit BOOT0 des STM32 verbunden werden.
  • Umstellung der IDE von EmBlocks 2.3.0 auf EMBitz 1.11.
  • Android App: Beim Start (oder auf Knopfdruck) werden die aktuellen Einstellungen von der Uhr geladen.
  • Android App: Es können bis zu vier Profile angelegt werden, um die Einstellungen für bis zu vier Uhren zu steuern.
  • Android App: Gamepad für Spiele wie z.B. Tetris

Update: Bitte vor dem Lesen des aktualisierten Wiki-Artikels WordClock mit WS2812 einmal F5 drücken, um die Bilder neu zu laden. Sonst werden nämlich die alten Bilder aus dem Browser-Cache angezeigt.

Ich hoffe, für jeden ist etwas dabei. Die Dokumentation im Artikel habe ich bereits zum größten Teil angepasst. Es fehlen aber noch ein paar kleinere Teile bzw. sind unvollständig, die ich am Wochenende anpasssen werde.

Zum WPS-Button: Dieser wird nicht nur als Taste auf dem neuen Shield v3 ausgeführt sein, sondern ist auch als Schaltfläche im Web-Interface vorhanden. Bei älteren Shields kann die Taste nachgerüstet werden.

Die neuen Ambilight-Funktionen konnte ich leider nicht testen, da ich momentan kein Ambilight an meiner Test-Uhr habe. Ich bitte daher diejenigen, die eins angeschlossen haben, um Feedback.

Ich werde in Zukunft in kürzeren Abständen Test-Versionen anbieten. Dadurch, dass im Webinterface nun der Installationspfad auf dem Host angegeben werden kann, können zukünftig ambitionierte Tester Zwischenversionen testen. Dank OTA ist so ein Update ja nun eine Sache von wenigen Mausklicks.

Apropos OTA: Diejenigen, die es vielleicht nicht mitbekommen haben: Die Verbindung vom ESP-12F zum BOOT0-Pin des STM32 hat sich mit der Version 2.6.0 geändert: Statt GPIO16 wird nun GPIO4 verwendet. Das wird auf der Update-Seite im Web-Interface nochmal extra angegeben, damit man das nicht vergisst. Das Shield V3 berücksichtigt diese Änderung natürlich schon.

Zu WCtris: Das Spiel ist momentan nur über die neue Android-App bedienbar. Ich plane aber auch noch, dies für die IR-Fernbedienung einzubauen. Wer weder IR-FB noch Android hat, dem kann ich ein kleines Windows-Console-Programm zukommen lassen, mit dem er das Spiel auf der Uhr über die Tastatur bedienen kann.

Die Weiterentwicklung der Android App hat nun Andreas M. (andiator) übernommen. Er hat da schon in kürzester Zeit eine Menge Änderungen eingebaut, zum Beispiel das Holen der aktuellen Einstellungen von der Uhr. Somit ist der bisherige Kritikpunkt, die App zeige beim Start nicht die aktuellen Einstellungen, vom Tisch. Hat man mehrere WordClocks im Haus, war das mit der alten App auch ein Problem. Jetzt können in der App bis zu 4 Profile gespeichert und damit auch 4 WordClocks gesteuert werden. Weitere App-Erweiterungen werden folgen. Vielen Dank an Andreas!

Das war bisher das größte Update der WordClock-Software. War zwar eine Menge Arbeit, hat aber auch Spaß gemacht :-)

Auch Euch viel Spaß mit der neuen WordClock-Software,

Frank


: Bearbeitet durch Moderator
Autor: Bernhard S. (b_sa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

Frank M. schrieb:
> Das schon länger angekündigte Update 2.6.0 ist nun online.

Richtig tolle Arbeit, Danke! Leider habe ich zur Zeit keine komplette WC 
(ESP-12F und WS2812B Stripes treiben sich irgendwo zwischen China und 
hier rum), sonst würde ich das glatt testen.

Nur so nebenbei gefragt: Bei den Neuerungen der Version 2.4 tauchte auch 
eine Animation Flicker auf, die allerdings bislang, wenn man sich das 
WIKI ansieht weder im Webinterface noch in der App auftaucht. Auch in 
der API Kommandotabelle ist sie nicht aufgeführt. Ob sie im aktuellen 
Webinterface auftaucht kann ich gerade nicht nachsehen(Teile fehlen, 
siehe oben).

Nochmal Dank für die tolle Arbeit.

Gruß
Bernhard

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard S. schrieb:

> Nur so nebenbei gefragt: Bei den Neuerungen der Version 2.4 tauchte auch
> eine Animation Flicker auf, die allerdings bislang, wenn man sich das
> WIKI ansieht weder im Webinterface noch in der App auftaucht.

Dann lädt Dein Browser die Bilder vom Wiki-Artikel aus seinem Cache, 
denn ich habe heute nacht sämtliche Web-Interface-Bilder im Wiki-Artikel 
auf den aktuellen Stand gebracht.

Drücke mal im Browser die Taste F5, um die Wiki-Seite neu zu laden. Dann 
siehst Du auch die Einstellungen zur Animation "Flicker" :-)

Es scheint ein generelles Problem des Wikis zu sein, dass die Browser 
die Bilder lieber aus dem Cache als von der Seite holen. Ich werde mal 
Andreas auf dieses Problem ansprechen. Vielleicht hat er ja eine Lösung 
dafür.

> Auch in der API Kommandotabelle ist sie nicht aufgeführt.

Schaue ich mir an. Wie oben erwähnt, sind noch nicht alle Passagen des 
Artikels auf dem aktuellen Stand. Ist halt mittlerweile eine ganze Menge 
Stoff, den es zu verarbeiten gilt.

> Ob sie im aktuellen
> Webinterface auftaucht kann ich gerade nicht nachsehen(Teile fehlen,
> siehe oben).

Doch, sie taucht dort auf. :-)

> Nochmal Dank für die tolle Arbeit.

Danke fürs Danke.

Frank

: Bearbeitet durch Moderator
Autor: Thomas Geissbühler (thomas_g18)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank und Andreas

Ich habe mich schon lange auf dieses Update gefreut und bin sehr erfreut 
darüber was es alles kann!
Es ist wirklich sehr Umfangreich ausgefallen und es sind viele Optionen 
für spätere Erweiterungen hinzugekommen.
Das Tetris-Game ist der Hingucker!
Danke an alle die hier dauernd Ihre Freizeit investieren um dieses 
Projekt weiterzubringen!

Dass es niemanden Langweilig wird habe ich auch schon einen Bug 
gefunden.
An meiner Uhr (12h Ws2812 mit Ambilight) ist das Ambilight per 
Webinterface nicht An und Abschaltbar.Ich weiss es absolut nicht schlimm 
und es ist auch als ungetestet deklariert!
Selbst brauche ist es nicht einmal.
Der Fehler stellt sich bei mir so dar.Wenn ich im Clock oder Clock2 
modus das Ambilight abschalte friert es einfach ein.Es bleibt die Farbe 
und Position bestehen.




Gruess und nochmals Besten  Dank!

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas G. schrieb:
> Der Fehler stellt sich bei mir so dar.Wenn ich im Clock oder Clock2
> modus das Ambilight abschalte friert es einfach ein.Es bleibt die Farbe
> und Position bestehen.

Danke für den Hinweis. Offenbar fehlt da noch irgendwo ein explizites 
Switch-Off für etwaige Ambilight-Animationen. Weitere Updates der 
Ambilight-LEDs werden wohl unterbunden - deshalb friert es dann auch ein 
- aber da fehlt wohl noch was für die Animation selbst.

Gehe ich richtig in der Annahme, dass das Ein-/Ausschalten des 
Ambilights nur dann funktioniert, wenn keine Ambilight-Animation 
eingestellt ist? Das würde mich schon mal auf die richtige Spur bringen.

Mal schauen, vielleicht stricke ich morgen mal ein Ambilight an meine 
Test-Uhr dran...

Autor: Thomas Geissbühler (thomas_g18)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank

Das Ambilight lässt sich auch nicht steuern wenn Normal aktiv ist.
Wenn sogar die Rainbow Animation aktiv ist verändert sich die Farbe wie 
auf dem Display weiter.
Gruss

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas G. schrieb:
> Wenn sogar die Rainbow Animation aktiv ist verändert sich die Farbe wie
> auf dem Display weiter.

Okay, danke. Dann muss ich das mal debuggen morgen...

Autor: Peter G. (ingrimsch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

vielen Dank an Andreas und dich für die ganzen Neuerungen in der neuen 
Version. Ich teste gerade alles mögliche durch...

Was mir bisher so aufgefallen ist:

- Die Clock2 Animation mit <60 LEDs und Offset funktioniert bei meiner 
Testuhr jetzt einwandfrei

- Die Helligkeitsregelung ist toll gelöst! Funktioniert jetzt auch in 
Kombination mit der Rainbow Animation und auf "1" ist die Uhr sogar 
Schlafzimmertauglich :-) Manuell klappt es schon mal super! Werde morgen 
mal einen LDR suchen und anklemmen...

- WPS = <3 (auch wenn mein Home-WLAN scheinbar an den Sonderzeichen 
scheitert. War vorher auch schon so, ich war nur bisher zu faul es 
umzubenennen und meinen Gerätezoo ins neue Netz zu bringen. Das 
Aushandeln von Name und Passwort klappt jedenfalls laut UART tadellos)

- Ambilight per Timer deaktivieren hat bei mir gar keine Funktion 
(Clock2, feste Farbe, Display auf Rainbow 4)

- Ambilight per Knopf deaktivieren klappt so halb: Die Animation stoppt, 
es bleibt aber der letzte Wert stehen und im Display läuft eine 
Animation ab. Die Animation läuft auch beim Wiedereinschalten, das 
Ambilight wird wieder normal angesteuert. Es müsste also vermutlich nach 
dem Abschalten einfach noch ein "Aus" (oder ganz luxuriös: ein Fadeout) 
an die Ambilight LEDs geschickt werden.
EDIT: Auch wenn Rainbow aktiviert ist wird das Ambilight im 
ausgeschalteten Zustand nicht mehr aktualisiert (Clock2). Im Modus 
"Normal" kann ich das von Thomas beschriebene Verhalten nachvollziehen: 
Es wird noch aktualisiert

- Wenn ein Ticker über die Uhr läuft wird das Ambilight nicht mehr 
aktualisiert. Ist der Ticker durchgelaufen gehts weiter.

- Wenn die Temperatur auf dem Display angezeigt wird und die "Flicker" 
Animation läuft, dann sind gleichtzeitig alle Buchstaben der Uhrzeit und 
der Temp. beleuchtet. Das gilt für das Ein- und auch für das Ausblenden

Zu guter Letzt noch eine Beobachtung meines Freundes mit dem Faible für 
das "Turbo-Rainbow" Display: Das Ambilight wird scheinbar nur 1x pro 
Sekunde aktualisiert. Wenn die Farbanimation auf dem Display schnell(er) 
läuft springt das Ambilight wahrnehmbar und man nimmt diese Sprünge 
deutlich wahr.
EDIT: Habs eben mal selbst getestet: Betroffen sind nur die beiden Clock 
Aninmationen, Normal wird passend zum Display aktualisiert.

Nochmal Danke für die tollen Features in der neuen Version und ein 
sonniges Restwochenende :-)
Peter

PS: Kannst du mir bei Gelegenheit den Link zu dem Tetris 
Konsolenprogramm zukommen lassen? Ich bin wegen eines Ausfalls zwar 
gerade Androidenfrei aber irgendwie neugierig ;-)

: Bearbeitet durch User
Autor: Thomas Geissbühler (thomas_g18)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank und Andreas

Mir ist da noch etwas aufgefallen bei der Verwendung von der App und 
Weboberfläche.
Dass die App alle aktuellen Daten von der Uhr bezieht ist super 
gelungen.Leider ist es in der anderen Richtung nicht so.
Der Fehler oder vielleicht auch meine Fehlbedienung stellt sich so dar:
Ich stelle alles per Weboberfläche ein und die Uhr läuft nach meinem 
Einrichtungen.
Ich starte dann die App und mache dort noch ein paar Enstellungen oder 
Spiele Tetris.
Nachdem ich in der App Synchronisiere und Speichere sind die 
Einstellungen in der Weboberfläche wieder auf neutral.
Dass heisst: die in der Weboberfläche angezeigte Zeit ist 00:00 im 
Januar 1900 (die Uhr zeigt aber noch die korrekte Zeit an) oder ist vor 
dem öffnen der App Ambilight Modus Clock 2 aktiv ist nach schliessen der 
App nur noch Abilight Normal aktiv.
Auch ein Browser Refresh bringt die Uhr und die Weboberfläche nicht auf 
den gleichen Stand.Ich benutze jeweils nicht die Weboberfläche oder die 
App gemeinsam.

@Frank:
Kannst du freundlicherweise beim Layout Schweizerdeutsch 2 machen dass 
UHR nicht angezeigt wird? Es liest sich komisch wenn es heisst ES ESCH 
ACHTI UHR.Es reicht absolut wenn es heisst ES ESCH ACHTI.Sorry für meine 
Extrawünsche.

Grüsse

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Peter,

Peter G. schrieb:

> - Ambilight per Timer deaktivieren hat bei mir gar keine Funktion
> (Clock2, feste Farbe, Display auf Rainbow 4)

Wenn der Button nicht funktioniert, fuktioniert auch der Ambilight-Timer 
nicht, denn das geht über dieselbe interne Funktion.

> - Ambilight per Knopf deaktivieren klappt so halb:

Danke für die Ausführungen. Ich habe da mittlerweile eine Idee im Kopf, 
wie ich das Problem lösen kann.

> - Wenn ein Ticker über die Uhr läuft wird das Ambilight nicht mehr
> aktualisiert. Ist der Ticker durchgelaufen gehts weiter.

Das ist momentan normal: Wenn der Ticker läuft, wird alles andere nicht 
mehr ausgführt. Das ärgert mich schon längere Zeit und ich wollte das 
schon vor einer gefühlten Ewigkeit ändern. Leider sind meine Versuche, 
den Ticker in eine Statemachine zu packen, bisher nicht erfolgreich 
gewesen. Immer kam irgendein blödes Event (z.B. die Aktualisierung der 
Uhrzeit bei jeder vollen Minute) dazwischen und hat den Ticker zerstört. 
Das steht aber weiterhin auf meiner Todo-Liste. Die Ticker-Funktionen 
sind intern auch schon darauf vorbereitet - es fehlt da noch an der 
letzten Umsetzung.

> - Wenn die Temperatur auf dem Display angezeigt wird und die "Flicker"
> Animation läuft, dann sind gleichtzeitig alle Buchstaben der Uhrzeit und
> der Temp. beleuchtet. Das gilt für das Ein- und auch für das Ausblenden

Witzig. Schaue ich mir an.

> Zu guter Letzt noch eine Beobachtung meines Freundes mit dem Faible für
> das "Turbo-Rainbow" Display: Das Ambilight wird scheinbar nur 1x pro
> Sekunde aktualisiert. Wenn die Farbanimation auf dem Display schnell(er)
> läuft springt das Ambilight wahrnehmbar und man nimmt diese Sprünge
> deutlich wahr. EDIT: Habs eben mal selbst getestet: Betroffen sind nur
> die beiden Clock Aninmationen, Normal wird passend zum Display
> aktualisiert.

Wie gesagt: Momentan habe ich kein Ambilight zum Testen. Werde ich aber 
in Kürze nachrüsten.

> PS: Kannst du mir bei Gelegenheit den Link zu dem Tetris
> Konsolenprogramm zukommen lassen? Ich bin wegen eines Ausfalls zwar
> gerade Androidenfrei aber irgendwie neugierig ;-)

Findest Du nun im Artikel unter Download. Die Doku dazu fehlt noch. Das 
sollte erstmal reichen:

 - Eingabeaufforderung starten
 - Aufruf: wctris.exe ipadresse

Das Programm gibt die zu benutzenden Tasten aus.

Gruß,

Frank

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

Thomas G. schrieb:
> Dass heisst: die in der Weboberfläche angezeigte Zeit ist 00:00 im
> Januar 1900 (die Uhr zeigt aber noch die korrekte Zeit an) oder ist vor
> dem öffnen der App Ambilight Modus Clock 2 aktiv ist nach schliessen der
> App nur noch Abilight Normal aktiv.

Die Weboberfläche zeigte prinzipiell 1900 mit 00:00 Uhr an. Das hatte 
mit Android überhaupt nichts zu tun. Ich habe den Fehler gefunden und 
beseitigt. Der STM32 überträgt jede Minute das Datum und die Uhrzeit zum 
ESP. Dieser hat die Daten jedoch fehlinterpretiert und dann nicht bzw. 
fehlerhaft angezeigt.

> Kannst du freundlicherweise beim Layout Schweizerdeutsch 2 machen dass
> UHR nicht angezeigt wird? Es liest sich komisch wenn es heisst ES ESCH
> ACHTI UHR.Es reicht absolut wenn es heisst ES ESCH ACHTI.Sorry für meine
> Extrawünsche.

Habe ich geändert. Update ist online, Ankündigung folgt im nachfolgenden 
Beitrag.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Update 2.6.1 ist online:

* Bugfix: Ein-/Ausschalten des Ambilights inkl. Timer funktioniert nun. 
Ich habe noch einen kurzen Streifen mit WS2812 in der Schublade gefunden 
und kurzerhand als Ambilight eingesetzt. Damit konnte ich den Fehler 
finden.

* Bugfix: Das aktuelle Datum/Uhrzeit wird im Webinterface nun wieder 
angezeigt. Wie ich oben schon schrieb, hat der ESP die regelmäßig 
übertragene Uhrzeit nicht korrekt angenommen.

* Änderung Schweizerdeutsch2: Die Anzeige von "UHR" wird unterdrückt.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Word-Clock hat ja mittlerweile unendlich viele Features xD

Gibts da eigentlich ein Video, in dem die Features demonstriert werden? 
:)

Autor: Mirco D. (bpoh_voodoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Frank
können wir die klassische Clock mit einzelnen umlaufenden LED ohne 5 
Sekunden Marker wieder haben?

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mirco D. schrieb:
> können wir die klassische Clock mit einzelnen umlaufenden LED ohne 5
> Sekunden Marker wieder haben?

Es ist geplant, das konfigurierbar zu machen. In der nächsten Version 
gibts dafür im Webinterface ein Häkchen.

Autor: Burkhard Drechsler (burkadius)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,
in der "Anschlusstabelle" auf der Hauptseite zu diesem Forum sind die 
Anschlüsse von Devices zu den zwei möglichen Boards aufgeführt. Dort 
steht zu Device ESP8366 RST/CH_PD für Verbindung zum STM32F103 
Mini-Board   GPIO:RST=PA0 CH_PD=PA1
Das war beim ESP8266-01 so. Aber ist das für den ESP8266-12F auch noch 
so? Im Anschlussplan ESP8266 für das Mini-Shield geht CH_PD ja über 
R13/10K an +3V3.
Ich bin darüber gestolpert, weil ich meine WC12h SW 2.4 umbaue auf das 
ESP-12F. Leider bis Dato ohne Erfolg. Ich kann den ESP nicht flashen 
obwohl es beim ESP-01 ohne Problem immer ging. Die neue SW 2.6 habe ich 
auf das STM32 -Mini Board geflasht. Aber der ESP-12F weigert sich noch. 
Ich hoffe aber, dass ich auch bald die vielen neuen Features testen 
kann:-)
Gruß
Burkhard

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Burkhard D. schrieb:
> Das war beim ESP8266-01 so. Aber ist das für den ESP8266-12F auch noch
> so?

Du kannst CH_PD weiterhin auch an den STM32-Pin anschließen, da der 
STM32 aus Kompatibilitätsgründen diesen Pin weiterhin bedienen wird. 
Aber momentan macht er dort nichts anderes, als diesen auf High zu 
stellen, also 3V3.

> Im Anschlussplan ESP8266 für das Mini-Shield geht CH_PD ja über
> R13/10K an +3V3.

Ja, das neue Mini-Shield v3 nutzt diesen STM32-Pin nicht mehr, da es 
keinen Mehrwert bringt, ihn dort anzuschließen.

> Ich bin darüber gestolpert, weil ich meine WC12h SW 2.4 umbaue auf das
> ESP-12F. Leider bis Dato ohne Erfolg. Ich kann den ESP nicht flashen

Was heisst das? Du kannst ihn nicht über die serielle Schnittstelle 
flashen? Benutzt Du das im Artikel erwähnte Adapterboard für den 
ESP-12F? Sonst stell bitte mal Fotos ein.

Autor: Burkhard Drechsler (burkadius)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank, Danke für die schnelle Antwort.
Ich benutze nicht das im Artikel erwähnte Adapterboard. Es ging bis 
jetzt immer mit einem FTDI 232USB auf TTL Serien Converter mit 
Umschalter des Ausganges auf 5V oder 3,3V Pegel.Siehe Bild.
Falls das der Grund für mein Problem Sen sollte: Ich habe hier noch ein 
Nucleo-Board mit einem ST-Link-V2 Programmierclone rumliegen. Sollte ich 
das nutzen? Hatte ich auch schon mal überlegt, dann aber verworfen, weil 
bis dato immer alles mit o.g. Board funktionierte.
Auf dem ST-Link-V2 Programmerclone gibt es RX und TX und noch einen 6 
pol. Connector CN4. Auf CN4 sind GND u. VCC sowie SWCLK und SWDIO wie 
auch auf dem Bild mit dem ST-LINK-V2 Adapter angegeben. Werden diese 
dann benutzt? Laut Beschreibung " Anschluß USB-UARTAdapter" kommt dann 
an A9->RX und A10->TX vom STM Mini Board. Aber wie verhält es sich auf 
diesem ST-Link vom Nucleoboard, werden dort RX und TX benutzt ?
Wäre toll wenn du mich aufklärst, weil ich mit diesem Clone noch nicht 
gearbeitet habe.
Danke
Burkhard

Autor: Burkhard Drechsler (burkadius)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank sorry, aber ich habe deine Frage nicht richtig beantwortet. 
Zum ESP-12F: ja, ich benutze genau das im Artikel beschrieben 12F Modul 
mit Adapterplatte. Der vorhergehende Artikel bezieht sich auf den 
Programmer, mit welchem ich flashe.
War ein Missverständnis
Gruß
Burkhard

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Burkhard D. schrieb:
> Ich benutze nicht das im Artikel erwähnte Adapterboard. Es ging bis
> jetzt immer mit einem FTDI 232USB auf TTL Serien Converter mit
> Umschalter des Ausganges auf 5V oder 3,3V Pegel.Siehe Bild.

Ich vermute, der FTDI auf Deinem Adapterboard ist ein Fake. Du kannst 
Dir dazu mal folgenden Artikel anschauen:

  Beitrag "FTDI zerstört Fake Chips durch Windows-Update"

FTDI hat irgendwann spitzgekriegt, dass viele FTDI-Fakes kursieren und 
hat daher den Treiber so geändert, dass die Fakes "kaputtprogrammiert" 
und damit unbrauchbar wurden. Das Ganze wurde per Windows-Update auf den 
PCs installiert - also ohne Zutun des Users. Erst als die Kritik und der 
Druck auf FTDI deswegen zu groß wurden, haben sie den Treiber so 
geändert, dass er nicht mehr 100%ig mit den Fakes zusammenarbeitet, aber 
diese nicht mehr zerstört. Ich vermute, Du hast Dir so ein 
"Treiberupdate" auch irgendwann per Windows-Update eingefangen. Hier in 
diesem Thread haben schon einige darüber berichtet, dass ihr 
FTDI-Adapter den ESP nicht (mehr) flashen konnte. Deshalb findest Du 
auch im Artikel unter

https://www.mikrocontroller.net/articles/WordClock...

den Hinweis: "Bei USB-UART-Adaptern mit FTDI-Chip oder Prolific 
PL2303-Chip sind Fakes im Handel, die von der Original-Treibersoftware 
nicht korrekt unterstützt werden. Besser sind Adapter mit CH340G- oder 
CP2102-Chip."

Ich empfehle Dir daher, den UART-Adapter zu wechseln. Ich selber benutze 
den CP2102 oder den UART-Adapter, der bei jedem Nucleo-Board dabei ist.

> Falls das der Grund für mein Problem Sen sollte: Ich habe hier noch ein
> Nucleo-Board mit einem ST-Link-V2 Programmierclone rumliegen. Sollte ich
> das nutzen?

Ja, mit dem geht das einwandfrei.

> Auf dem ST-Link-V2 Programmerclone gibt es RX und TX und noch einen 6
> pol. Connector CN4. Auf CN4 sind GND u. VCC sowie SWCLK und SWDIO wie
> auch auf dem Bild mit dem ST-LINK-V2 Adapter angegeben. Werden diese
> dann benutzt?

Ja, ganz genau.


> Laut Beschreibung " Anschluß USB-UARTAdapter" kommt dann
> an A9->RX und A10->TX vom STM Mini Board. Aber wie verhält es sich auf
> diesem ST-Link vom Nucleoboard, werden dort RX und TX benutzt ?

Um den auf dem Nucleo befindlichen ST-Link und USB-UART-Adapter zu 
verwenden, musst Du diesen vom Rest trennen - entweder durch Durchsägen 
der Sollbruchstellen oder durch Entfernen der entsprechenden Lötbrücken 
auf der Rückseite. Es gibt da eine PDF-Dokumentation UM1724 von ST, wo 
das haarklein beschrieben ist:

http://www.st.com/content/ccc/resource/technical/d...

> Ich empfehle das Durchsägen, so habe ich das auch gebracht. Dann kannst Du mit 
den SWD-Pins beliebige STM32 programmieren und hast zusätzlich auch noch einen 
USB-UART-Adapter.

Wenn Du mit dem abgetrennten Adapter den STM32 auf dem Nucleo-Rest 
programmieren möchtest, musst Du halt die SWD-Pins mit dem Nucleo-Rest 
per Steckkabel wieder verbinden.

Autor: Jens Müller (jbm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

Ich habe Probleme mit dem Update über OTA. Das Einspielen von Updates 
für den ES8266 ESP-12F hat funktioniert.

Name  Value
Update Host
uclock.de
Save
Update Path
update
Save

ESP8266 flash size  4194304
ESP firmware version  2.6.1
ESP firmware available  2.6.1
Update ESP Firmware
WordClock firmware version  2.5.0
WordClock firmware available  2.6.1

 Flash STM32Reset STM32
updating STM32 firmware...
Downloading the image file...
Start Bootloader
Trying...
Timeout
timeout, no ACK
End Bootloader
Done.

Hat jemand eine Idee was ich falsch mache?
GPIO4 des ESP8266-12F habe ich an BOOT0 des STM32F401 angeschlossen.
Flaschen über den abgesägten St-Link will auch nicht funktionieren. Den 
St-Link habe ich wie in der Abbildung angeschlossen.

freundliche Grüße
Jens .

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Jens M. schrieb:
> Ich habe Probleme mit dem Update über OTA.

Es geht hier offenbar um das OTA-Flashen eines STM32F401. Ich werde in 
den nächsten Tagen mal einen ESP-12F an mein Nucleo F401 anschließen, um 
das Problem zu reproduzieren.

> Hat jemand eine Idee was ich falsch mache? GPIO4 des ESP8266-12F habe
> ich an BOOT0 des STM32F401 angeschlossen.

Das ist korrekt.

> Flaschen über den abgesägten St-Link will auch nicht funktionieren. Den
> St-Link habe ich wie in der Abbildung angeschlossen.

Deine Abbildung ist zu klein, um etwas zu erkennen. Aber ich nehme an, 
dass es das Bild aus dem Artikel ist.

Dazu ist zu sagen, dass man - um das abgesägte ST-Link von "internes" 
auf "externes Programmieren" umzustellen, die beiden CN2-Jumer vom 
ST-Link abgezogen werden müssen, siehe Bild im Anhang (stammt aus UM1724 
von ST, ist lesenswert). Ich werde das Bild auch noch im Artikel an 
geeigneter Stelle plazieren.

EDIT:
Sollte das Flashen über den ST-Link auch bei abgezogenen CN2-Jumpern 
nicht funktionieren, empfehle ich noch, den Pin1 (VDD) vom SWD-Header 
(das ist der oberste Pin, viereckiges Lötauge) noch mit 3V3 auf dem 
Nucleo zu verbinden. Der ST-Link misst damit die Betriebsspannung des 
STM32.

: Bearbeitet durch Moderator
Autor: Torsten Giese (wawibu)
Datum:
Angehängte Dateien:

Bewertung
4 lesenswert
nicht lesenswert
kurzes Update von mir - die LEDs und Shields sind bereits eingetroffen.

Die nur LED Besteller sollten ihre Pakete bereits erhalten haben.
Die LED und Shield oder nur Shield Besteller bekommen ihr Paket diese 
Woche.

Der Rest wird dann versendet, sobald ich die Böden habe.

Grüße,
Torsten

Autor: Jan H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Ich habe Probleme mit dem Update über OTA.

Das ist bei mir auch:

Start Bootloader
Trying...
Timeout
timeout, no ACK
End Bootloader

Ich versuche von 2.6.0 auf 2.6.1 ein Update durchzuziehen.

Dieser Versuch basiert auf Nucleo411 mit ESP8266-f12.

Autor: Burkhard Drechsler (burkadius)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Torsten,
Habe das Nucleoboard vom Programmer ST-Link abgesägt.

> Laut Beschreibung " Anschluß USB-UARTAdapter" kommt dann
> an A9->RX und A10->TX vom STM Mini Board. Aber wie verhält es sich auf
> diesem ST-Link vom Nucleoboard, werden dort RX und TX benutzt ?

Um den auf dem Nucleo befindlichen ST-Link und USB-UART-Adapter zu
verwenden, musst Du diesen vom Rest trennen - entweder durch Durchsägen
der Sollbruchstellen oder durch Entfernen der entsprechenden Lötbrücken
auf der Rückseite. Es gibt da eine PDF-Dokumentation UM1724 von ST, wo
das haarklein beschrieben ist:

http://www.st.com/content/ccc/resource/technical/d...

> Ich empfehle das Durchsägen, so habe ich das auch gebracht. Dann kannst Du mit 
den SWD-Pins beliebige STM32 programmieren und hast zusätzlich auch noch einen 
USB-UART-Adapter.

Dann habe ich STM-Mini-Board/A10 über einen Jumper mit St-Link 
Programmer ->CN4/SWD4(SWDIO) verbunden. Alle Boards untereinander 
geerdet und +3V3 STM-Mini mit Programmer CN4 (Pin1, VDD_TARGET) 
verbunden.
A9 am STM-Mini ist mit ESP-12F GPIO13 verbunden. Alles andere laut 
Vorgaben.
Dann starte ich die in der Flashanleitung beschriebene Prozedur 
(zwischen A10 und STM-Programmer ist noch kein Jumper gesetz. Reset am 
STM gedrückt/halten. PA6 gedrückt /halten. Reset öffnen.Nach 2s PA6 
öffnen. Jumper A10->CN4/SWDIO setzen. Flashprogramm (ESP Download tool 
2.3 oder ESP8266-flasher)starten und es ergibt sich das gleiche Bild wie 
mit meinem anderen FTDI-USB Converter:
test running: False
serial port opened
connecting...
chip sync error
com closed
Was mache ich falsch, bestimmt ein total blöder Fehler. kann der ESP-12F 
die Ursache sein? ich habe 2 aus einer Charge. Kein Unterschied.
Gruß
Burkhard

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Burkhard D. schrieb:
> Hallo Torsten,

Ich heiße Frank, nicht Torsten ;-)

> Habe das Nucleoboard vom Programmer ST-Link abgesägt.
>
> Laut Beschreibung " Anschluß USB-UARTAdapter" kommt dann
> an A9->RX und A10->TX vom STM Mini Board. Aber wie verhält es sich auf
> diesem ST-Link vom Nucleoboard, werden dort RX und TX benutzt ?

Ich glaube, Du wirfst da etwas durcheinander. Um das ESP-12F zu flashen, 
brauchst Du A9->RX und A10->TX überhaupt nicht. Das ist nur notwendig, 
wenn Du über OTA den STM32 flashen willst.

Auch brauchst Du keine SWD-Verbindung, um den ESP zu flashen.

Du brauchst für das Flashen des ESP über Draht:

1. Einen bereit geflashten STM32
2. Einen UART-Adapter mit den Verbindungen RX, TX und GND
3. RESET- und User-Button (oder Jumper "Flash" auf dem Mini-Board)

Mehr brauchst Du nicht. Wenn der STM32 bereits geflasht ist, brauchst Du 
keine SWD-Verbindungen mehr. Die sind nur zum Flashen des STM32.

Da Deine Beschreibung etwas chaotisch ist, habe ich erstmal ein paar 
Verständnisfragen:

1. Der STM32 für die Uhr ist auf dem Mini-Board oder auf dem Nucleo?
2. Ist der STM32 bereits per ST-Link geflasht?

> Dann habe ich STM-Mini-Board/A10 über einen Jumper mit St-Link
> Programmer ->CN4/SWD4(SWDIO) verbunden. Alle Boards untereinander
> geerdet und +3V3 STM-Mini mit Programmer CN4 (Pin1, VDD_TARGET)
> verbunden.

A. Du musst RX vom ST-Link mit TX vom Mini-Board verbinden.
B. Du musst TX vom ST-Link mit RX vom Mini-Board verbinden.
C. Du musst GND vom SWD mit GND vom Mini-Board verbinden.
D. Du hältst den RESET-Button runter
E. Du verbindest die beiden Flash-Pins kurz, z.B. mit Schraubendreher
   oder Jumper
F. Du lässt Reset los

> A9 am STM-Mini ist mit ESP-12F GPIO13 verbunden. Alles andere laut
> Vorgaben.

Um es nicht zu kompliziert zu machen und die Fehlermöglichkeiten zu 
begrenzen: Zum Flashen des ESP reichen die "klassischen" Leitungen, die 
unter

https://www.mikrocontroller.net/articles/WordClock...

im Prinzipschaltbild an K1 liegen. Die an K2 liegenden Signale brauchst 
Du erst, wenn Du später mal den STM32(!) per OTA updaten willst. Aber 
soweit bist Du noch nicht. Reduziere bitte die Verbindungen vom 
ESP-12F-Adapter erstmal auf die Leitungen, die an K1 liegen. Dann die 
Schritte A - F (siehe oben) durchführen. Wenn es dann geklappt hat, 
kannst Du die zusätzlichen Verbindungen an K2 durchführen. Sie stören 
zwar nicht beim Flashen, aber ich denke, dass wenn Du das Setup auf das 
minimal nötige reduzierst, eliminierst Du auch eventuelle 
Verdrahtungsfehler.

Autor: Bernhard S. (b_sa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Burkhard,

Burkhard D. schrieb:
> Dann habe ich STM-Mini-Board/A10 über einen Jumper mit St-Link
> Programmer ->CN4/SWD4(SWDIO) verbunden

CN4 ist das SWD Interface, um den ESP zu flashen benötigst du das 
Serielle Interface CN3 (RX/TX). Die müssen, wie angegeben, mit A9/A10 
verbunden werden, GND nicht vergessen und dann kann's was werden ;-). 
Die Verbindung mit dem ESP macht dann der STM (> PA6 gedrückt 
halten...).

Autor: Torsten Giese (wawibu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Burkhard D. schrieb:
>> Hallo Torsten,
>
> Ich heiße Frank, nicht Torsten ;-)

Du kannst Dich aber auch anstellen :D

Autor: Burkhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Halo Frank, habe alles laut deinen Tipps durchgeführt.
Ich benutze ein STM32F103 Mini Dev. Board und habe es nun mit dem 
abgesägten ST-Link Programmer mit der letzten SW geflasht.( Alle 
Verbindungen zwischen den Boards sind gelötet, kein WC Shield im Einsatz 
!)
Ergebnis :

power_init() called
switching power on

Welcome to WordClock Logger!
----------------------------
Version: 2.6.1
rtc is online
ws2812: no external pullup detected
eeprom is online
current eeprom version: 0x00020600
ESP8266 LOGGER
read rtc: Tu 2000-01-03 05:54:25
read rtc: Tu 2000-01-03 05:54:45
RTC temperature: 22
(var N152c00)
var_send_buf: expected ESP8266_OK, got 255
(ERROR)
esp8266 now up
(var T0001000003055500)
var_send_buf: expected ESP8266_OK, got 255
(ERROR)

den ESP8266-12F habe ich dann mit den 6 Leitungen lt. K1 verbunden: 3,3V 
an STM u. ESP-12F. Masse an STM,ESP und Programmer. RX ESP->A2 STM, TX 
ESP->A3 STM, Reset ESP->A0 STM.
 CM3 vom Programmer Board: TX ->PA9 STM, RX->PA10 STM. Habe sie auch mal 
vertauscht, ohne Erfolg. Es kommt immer chip sync error.
Du schreibst:
D. Du hältst den RESET-Button runter
E. Du verbindest die beiden Flash-Pins kurz, z.B. mit Schraubendreher
   oder Jumper
F. Du lässt Reset los

Im Pkt. "Konfiguration des WLAN-Moduls" folgt dann noch, dass die 
User-Taste (bei mir PA6=User Taste bzw Flash-pin) nach 2 s loslassen. 
Oder ist das egal ?
die beiden Jumper auf dem STM103 bei mir sind auf Position "0", also 
nach links. Wenn ich das alles richtig in Erinnerung habe wurde doch so 
auch der ESP-01 programmiert oder?Und das ging immer!
Aber immerhin kann ich nun schon mit dem ST-Link Programmer das STM 
Board flashen.
Ich denke ich versuche es mal mit einem neuen ESP8266-12F oder hast du 
noch eine Idee?
Gruß
Burkhard

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Burkhard schrieb:
> Im Pkt. "Konfiguration des WLAN-Moduls" folgt dann noch, dass die
> User-Taste (bei mir PA6=User Taste bzw Flash-pin) nach 2 s loslassen.

Stimmt: User-Taste darf erst nach Loslassen der Reset-Taste losgelassen 
werden. Da habe ich mich ungenau ausgedrückt.

> die beiden Jumper auf dem STM103 bei mir sind auf Position "0", also
> nach links.

Ja, solange Du nicht über OTA programmierst, ist das richtig.

> Wenn ich das alles richtig in Erinnerung habe wurde doch so
> auch der ESP-01 programmiert oder?Und das ging immer!

Ja, absolut genauso. Der Chip auf dem ESP-12F ist ja auch identisch mit 
dem Chip auf dem ESP-01. Lediglich der Flash-Chip (extra Gehäuse neben 
dem ESP) ist auf dem ESP-12F größer.

> Aber immerhin kann ich nun schon mit dem ST-Link Programmer das STM
> Board flashen.

Gratuliere.

> Ich denke ich versuche es mal mit einem neuen ESP8266-12F oder hast du
> noch eine Idee?

Im Moment nicht. Sorry. Es muss aber eine Kleinigkeit sein. Alle 
Verbindungen nochmal geprüft? Was für einen Schaltregler hast Du vor dem 
ESP als Spannungsversorgung? Elko angeschlossen? Der ESP reagiert 
empfindlich auf Spannungseinbrüche.

Autor: Burkhard Drechsler (burkadius)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank, danke für die schnelle Hilfe.

Frank schrieb:
>Was für einen Schaltregler hast Du vor dem
>ESP als Spannungsversorgung? Elko angeschlossen? Der ESP reagiert
>empfindlich auf Spannungseinbrüche.

Ich benutze im Moment ein Labor-NT, 2 x 30V, 1,5A
Speziell am ESP habe ich noch direkt einen 330myF und einen 10nF 
angelötet.
Na mal sehen was ein neuer Aufbau mit neuen Komponenten bringt. Auf alle 
Fälle sehe ich in vielen Punkten nun klarer, was die Fehlersuche 
unterstützt.
Ich berichte weiter
Gruß
Burkhard

Autor: Andreas M. (andiator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Burkhard,

das ist jetzt ein Schuss ins Blaue, aber ich kann den ESP auch nicht 
flashen, wenn der STMF103 am Strom hängt. An (meinem) Breadboard ist es 
natürlich kein Problem, da Strom abzuziehen.

Ich habe da nicht weiter untersucht, denn mein Aufbau entspricht ja 
nicht dem "Standard".

MfG,
Andreas

Autor: Jens Müller (jbm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> EDIT:
> Sollte das Flashen über den ST-Link auch bei abgezogenen CN2-Jumpern
> nicht funktionieren, empfehle ich noch, den Pin1 (VDD) vom SWD-Header
> (das ist der oberste Pin, viereckiges Lötauge) noch mit 3V3 auf dem
> Nucleo zu verbinden. Der ST-Link misst damit die Betriebsspannung des
> STM32.

Danke Frank.... mit Pin1 (VDD3,3V) vom ST-Link auf die 3,3V vom Nucleo 
war das Flaschen kein Problem.
ESP8266 flash size  4194304
ESP firmware version  2.6.1
ESP firmware available  2.6.1
Update ESP Firmware
WordClock firmware version  2.6.1
WordClock firmware available  2.6.1


OTA-Flashen eines STM32F401 funktioniert leider nicht, aber ich bin 
weiter auf der Fehlersuche.
updating STM32 firmware...
Downloading the image file...
Start Bootloader
Trying...
Timeout
timeout, no ACK
End Bootloader
Done.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens M. schrieb:
> Timeout

Wie ich schon schrieb : ich werde das nochmal explizit mit eine F401 
testen. Wahrscheinlich sind die Timeouts zu eng gewählt. Die STM32F4xx 
haben ja einige Bootloader-Devices mehr zu bieten als der kleine F103. 
Ich melde mich,  sobald ich dad Problem in den Griff bekommen habe. 
Warum sich jetzt allerdings  nach mehreren Wochen mehrere Leute 
innerhalb von 24 Stunden melden, ist mir schleierhaft. ;-)

: Bearbeitet durch Moderator
Autor: Bernhard S. (b_sa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Burkhard,

Burkhard schrieb:
> var_send_buf: expected ESP8266_OK, got 255
> (ERROR)
> esp8266 now up
> (var T0001000003055500)
> var_send_buf: expected ESP8266_OK, got 255
> (ERROR)

solche Meldungen hatte ich auch schon mal, da lag es an Problemen mit 
der Stromversorgung. Du kannst den ESP nicht mit den 3,3V vom STM 
betreiben. Wenn man den an einem eigenen 3,3V LDO betreibt treten 
(zumindest bei mir) diese Probleme nicht auf.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> ich werde das nochmal explizit mit eine F401 testen. Wahrscheinlich sind
> die Timeouts zu eng gewählt. Die STM32F4xx haben ja einige
> Bootloader-Devices mehr zu bieten als der kleine F103. Ich melde mich,
> sobald ich dad Problem in den Griff bekommen habe.

Die Tests mit dem STM32F401 (gilt auch für den STM32F411) Nucleo haben 
folgendes zutage gebracht:

 - Die Timeouts müssen höher gewählt werden, der STM32F4xx-Bootloader
   reagiert nicht so schnell wie der STM32F103 auf den Bootloader-
   Start durch Senden eines "Magic Bytes" - vermutlich, weil er
   zu Beginn auf mehreren Devices "horcht".

 - Der Standard-Erase-Befehl vor dem eigentlichen Programmieren
   funktioniert beim STM32F4xx nicht. Hier muss das sogenannte
   "Extended Erase Command" verwendet werden. In der ST-Doku
   steht dazu, dass ein STM32 entweder den einen oder den anderen
   Erase-Befehl unterstützt - aber niemals beide. Also habe ich es
   so gelöst, dass ich erst den Standard-Befehl und dann das
   Extended-Erase Command probiere. So funktioniert das nun
   sowohl auf STM32F103 als auf STM32F4xx.

Wieder etwas dazugelernt...

Fazit:

Das OTA-Flashen funktioniert nun auch mit den Nucleos. Heute abend gibt 
es noch ein Update dazu.

P.S.
Ich habe gerade gemerkt, dass die beiden Prinzipschaltbilder unter 
WordClock mit WS2812: Umbau von ESP-01 auf ESP-12F noch GPIO16 statt 
GPIO4 an den BOOT0-Pin des STM32 gehen. Das passe ich gleich noch an.

: Bearbeitet durch Moderator
Autor: Jens Müller (jbm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Frank für die schnelle Lösung.
Ich hatte meine Uhr mit dem nicht abgesägten ST-Link geflascht und da 
ist mir der Fehler beim OTA nicht aufgefallen.

danke.... :)

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Update 2.6.2 ist online.

2 Änderungen:

 - Anpassung des Bootloaders an Nucleo STM32F4xx
 - Ambilight-Mode Clock: 5 Sekunden Marker nun an- und abschaltbar

Damit können nun auch die Nucleos über OTA geflasht werden.

Autor: Jens Müller (jbm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

bei funktioniert es leider das flaschen über OTA mit dem Nucleo 
STM32F401/c3
noch nicht.
Meldung:
updating STM32 firmware...
Downloading the image file...
Start Bootloader
Trying...
unprotected
Trying again...
Erasing flash...
no ACK: (0x1f)
Ignoring error, using extended erase command instead...
Successful!
Flashing Image...
Flashing STM32...
File size: 9696
Bytes flashed: 3328
errors: 0
Flash successful
End Bootloader
Done.

mit ST-Link kein Problem.

gruß Jens B.

Autor: Jens Müller (jbm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens M. schrieb:
> Hallo Frank,
>
> bei funktioniert es leider das flaschen über OTA mit dem Nucleo
> STM32F401/c3
> noch nicht.


Nach dem Flaschen hängt sich die Uhr auf und lässt sich auch nicht mehr
starten.Warm- oder Kaltstart ist dabei egal. Erst nach einem erneuten 
flaschen über z.B. ST-Link läuft die Uhr wieder.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens M. schrieb:
> updating STM32 firmware...
> Downloading the image file... Start Bootloader
> Trying...
> unprotected
> Trying again...
> Erasing flash...
> no ACK: (0x1f)
> Ignoring error, using extended erase command instead...
> Successful!
> Flashing Image...
> Flashing STM32...
> File size: 9696

9696 Bytes sind zuwenig. Die Datei wurde offenbar unvollständig 
heruntergeladen. Es hätten 158164 Bytes sein müssen.

> Flash successful

Das Flashen war erfolgreich, jedoch nicht vollständig.

Ich habe mal eben in der Logdatei des Update-Servers reingeschaut:

Du hast offenbar die Datei wc24h-stm32f401-ws2812-grb.hex 
heruntergeladen, aber nach ca. 1/10 der Datei aufgehört. Dafür habe ich 
noch keine Erklärung.

Nach Dir hat noch jemand die Hex-Datei heruntergeladen, und zwar 
vollständig. Da müssen wir "nur" noch herausfinden, warum das 
ausgerechnet bei Dir anders läuft. Welchen Browser benutzt Du?

Hast Du mal OTA über "Local Update" versucht?

: Bearbeitet durch Moderator
Autor: Jens Müller (jbm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Hast Du mal OTA über "Local Update" versucht?

nein noch nicht...

Autor: Jens Müller (jbm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Welchen Browser benutzt Du?

Google Chrome V56.0.2924.87

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens M. schrieb:
> Google Chrome V56.0.2924.87

Daran liegts nicht. Bei mir klappt es auch mit Google Chrome.

Flashing STM32...
File size: 138008
Bytes flashed: 50164

Das ist korrekt. Die Datei ist 141147 Bytes groß und hat 3139 Newlines, 
die das Progrmam nicht mitzählt: 138008 + 3139 = 141147. Passt.

Ich sollte trotzdem einen Check einbauen, ob die Datei vollständig 
heruntergeladen wurde. Es ist natürlich Unsinn, eine unvollständige 
Datei zu flashen. Darüber mache ich mir morgen mal Gedanken.

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi zusammen,

baue derzeit wieder zwei neue Uhren. Mit dem Shield Version 1. Habe 
soweit alle Teile aus dem Warenkorb bestellt und soweit zusammengebaut. 
Allerdings sind noch zwei/drei Fragen aufgetauscht:

-> Das Bild der Rückseite der Uhr - ist da Top die Oberseite der Uhr 
nehem ich an?

-> wie das flashen funktioniert ist mir noch nicht ganz klar. Ich habe 
den ST-Link V2 mit USB dazu bestellt zum flashen. Kann ich damit auch 
das WLAN Modul flashen? Wie muss ich genau vorgehen? Mein PC hat kein 
WLAN, muss ich mir jetzt extra einen Stick anschaffen?

-> Vom Netzteil zur Uhr - wie habt ihr das angeschlossen? Ich suche 
schon drei Tage im Netz aber finde kein Kabel mit der passenden 
Kupplung. Oder sollte man den Stecker abschneiden und einfach ein Kabel 
anklemmen?

Fragen über Fragen ;-)

Grundsätzlich möchte ich mich aber auch auf diesem Wege bei euch allen 
für den Support und Euren Einsatz bedanken. Die Uhr gefällt mir wirklich 
super und es hängt bereits seit 2 Jahren eine bei mir an der Wand und 
ich freue mich täglich darüber.

Viele Grüße - Volker

Autor: Andreas M. (andiator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Volker,

> wie das flashen funktioniert ist mir noch nicht ganz klar
zum Flashen kann Dir Frank mehr sagen als ich.
So viel ich weiß, um den ESP zu flashen, ist ein serieller (USB-)TTL 
Adapter nötig. Der ist, glaube ich auf dem ST-Link vom Nucleo-Board 
drauf. Aber ob er auch auf Deinem drauf ist?

> Mein PC hat kein WLAN
Wenn Du einen WLAN-Router hast, dann brauchst Du keinen WLAN-Stick.
Auch ein Smartphone reicht aus, die können alle WLAN und haben 
Webbrowser onboard.

MfG,
Andreas

Autor: Günter H. (gnter_h534)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Volker schrieb:

> -> Vom Netzteil zur Uhr - wie habt ihr das angeschlossen? Ich suche
> schon drei Tage im Netz aber finde kein Kabel mit der passenden
> Kupplung. Oder sollte man den Stecker abschneiden und einfach ein Kabel
> anklemmen?

Ich habe das so gelöst:

Beitrag "Re: WordClock mit WS2812"

Gruß
Günter

Autor: Günter H. (gnter_h534)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Volker schrieb:

> baue derzeit wieder zwei neue Uhren. Mit dem Shield Version 1. Habe
> soweit alle Teile aus dem Warenkorb bestellt und soweit zusammengebaut.
> Allerdings sind noch zwei/drei Fragen aufgetaucht:
>
> -> Das Bild der Rückseite der Uhr - ist da Top die Oberseite der Uhr
> nehme ich an?

Welches Bild meinst Du? Im Artikel gibt es mittlerweile so viele Bilder.

> -> wie das flashen funktioniert ist mir noch nicht ganz klar. Ich habe
> den ST-Link V2 mit USB dazu bestellt zum flashen. Kann ich damit auch
> das WLAN Modul flashen? Wie muss ich genau vorgehen? Mein PC hat kein
> WLAN, muss ich mir jetzt extra einen Stick anschaffen?

Mit welchen Komponenten (Mini Dev- oder Nucleo-Board, welches ESP-Modul) 
hast Du die Steuerung für Deine Uhr aufgebaut?

Das Flashen von STM32-Board und ESP-Modul ist im Artikel detailliert 
beschrieben - besser kann ich es hier auch nicht. An welchem 
Arbeitsschritt genau hast Du Probleme?

Wenn Du das STM32-Mini-Development-Board verwendest, braucht Du 
zusätzlich zum STM32 ST-Link-Adapter einen USB-UART-Adapter, der mit 3,3 
V-Pegeln arbeitet und möglichst mit CH340G- oder CP2102-Chip bestückt 
ist - siehe Artikel.

Wir helfen Dir gerne, brauchen aber auch einige konkrete Angaben.

Autor: Burkhard Drechsler (burkadius)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, wollte nur mitteilen, dass ich nun die ESP-12F flashen kann. Das 
Problem waren 2 defekte ESP-12F Module. Habe mir dann neue geholt und 
alles geht. Nochmals vielen Dank an alle, insbesondere an Frank für die 
Hilfestellungen. Und das Flashen mit dem ST-Link-Adapter, abgesägter 
Teil vom Nucleo Board, geht echt viel besser als mit den FTDI Teilen.
Da meine Uhr WC12h mit SK6812RGBW bestückt ist habe ich aber das 
Problem, dass die SW 2.6.2 für diesen LED Typ nicht läuft. Die Uhr 
startet nach flash + Reset nicht mehr. Wenn ich dann WS2812 SW für WC12h 
auswähle ist alles gut.
In dem Zusammenhang ist mir bei der Android App 2.6.0 aufgefallen, das 
dort die SK6812 nicht unterstützt werden. Bei der älteren V2.1.0 konnte 
man auf den Typ umschalten.
Andreas,ist das noch in Arbeit und somit geplant?
Gruß
Burkhard

Autor: Thomas Glass (taximan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Burkhard D. schrieb:
... Das
> Problem waren 2 defekte ESP-12F Module. Habe mir dann neue geholt und
> alles geht...

Haben die Dinger wirklich so einen Ausschuß, oder sind die so 
empfindlich?

Autor: Thomas Glass (taximan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Frank M.; sag doch bitte Bescheid, wenn du dich ans Wetter machst. Ich 
hab da noch 1-2 Änderungen.

Thomas

Autor: Andreas M. (andiator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Burkhard D. schrieb:
> Andreas,ist das noch in Arbeit und somit geplant?

Das soll die App automatisch erkennen, sobald Deine Uhr läuft ;)
(So ist zumindest der Plan, RGBW-Variante habe ich noch nicht getestet 
:) )

MfG,
Andreas

PS
Und ja, ein paar Sachen an der App werden noch geändert

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Burkhard D. schrieb:
> Da meine Uhr WC12h mit SK6812RGBW bestückt ist habe ich aber das
> Problem, dass die SW 2.6.2 für diesen LED Typ nicht läuft.

Wie äußert sich das? Fehlt lediglich die Anzeige? Siehst Du 
Log-Meldungen vom STM32 am UART-Anschluss? Lief die 2.5.0 mit den 
SK6812RGBW korrekt? Ich habe da nämlich schon lange nichts mehr 
geändert.

Der einzige Unterschied: Seit 2.5.0 werden die insgesamt 30 
Firmware-Varianten per Script unter Linux erzeugt. Wenn die 2.5.0 aber 
korrekt lief, dann liegts nicht an den Scripts. Am SK5812-Source habe 
ich seit 2.5.0 aber auch nichts mehr geändert...

Welche Hex-Datei hast Du denn ausgewählt? Hast Du über OTA oder Kabel 
geflasht? Wieviele Bytes wurden dabei geflasht?

> Die Uhr
> startet nach flash + Reset nicht mehr. Wenn ich dann WS2812 SW für WC12h
> auswähle ist alles gut.

Die LEDs zeigen dann etwas an, obwohl das WS2812-Timing komplett anders 
ist? Bitte die Probleme präziser beschreiben.

Kann jemand der anderen SK6812-User bestätigen, dass die SK6812-Version 
nicht läuft?

: Bearbeitet durch Moderator
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Jens M. schrieb:
> Flashing STM32...
> File size: 9696
>
> 9696 Bytes sind zuwenig. Die Datei wurde offenbar unvollständig
> heruntergeladen. Es hätten 158164 Bytes sein müssen.

Das Problem habe ich einkreisen können. Wenn der ESP schneller die Daten 
herunterladen kann als die Internet-Leitung sie liefert, kann es zu 
einem vorzeitigen Timeout kommen und der Download wird abgebrochen. Ich 
selber konnte das Problem nie reproduzieren, da meine Internet-Leitung 
mit 50MBit ziemlich flott ist.

Ich habe nun folgende Maßnahmen für den STM32-Flash über OTA eingebaut:

1. Übernahme der Dateigröße aus dem HTTP-Header des Webervers
2. Kein vorzeitiges Timeout, solange nicht die angegebene Größe
   erreicht ist.
3. Check sämtlicher Checksums in der heruntergeladenen Hex-Datei
4. Erst wenn alle Prüfungen erfolgreich sind, wird der STM32 geflasht.

Ein Update der ESP-Firmware kommt dann morgen. Ich mache noch ein paar 
Checks und möchte die Ausgabe während des Flashens noch ein wenig 
informativer machen. Mittlerweile habe ich es auch geschafft, die Infos 
live im Browser zu aktualisieren und nicht erst am Ende, wenn alles 
vorüber ist.

Autor: Christian S. (c_h_r_i_s_u)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Uhr ist echt der Hammer und ist als Geburtstagsgeschenk zum 50. sehr 
gut angekommen. Ich werde mich jetzt dann auch dran machen und noch zwei 
weitere Uhren basteln, dann aber mit dem neuesten Shield.

Jetzt hab ich aber noch zwei Fragen und eventuell damit zwei Punkte 
wobei ich mich bei dem Projekt mit einbringen kann:

Es gibt ja für die Uhr eine Android App mit der man alles steuern kann. 
Gibt es auch eine iPhone App oder ist eine in Planung? Wenn nicht, dann 
könnte ich - sobald meine zweite Uhr fertig ist - eine iPhone App 
entwickeln.

Und die zweite Frage (ich denke die kann sicher am besten Frank M. 
beantworten) ist, wieviel Platz ist noch auf dem Chip, damit man 
eventuell die Steuerungswebseite noch ein wenig mit CSS designen könnte? 
Wenn da noch Platz vorhanden ist und Bedarf wäre, könnte ich das ganze 
auch grafisch ein wenig anpassen.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian S. schrieb:
> Es gibt ja für die Uhr eine Android App mit der man alles steuern kann.
> Gibt es auch eine iPhone App oder ist eine in Planung?

Nein, bisher nicht.

> Wenn nicht, dann
> könnte ich - sobald meine zweite Uhr fertig ist - eine iPhone App
> entwickeln.

Das hört sich sehr gut an! Melde Dich bitte per PN bei mir :-)

> Und die zweite Frage (ich denke die kann sicher am besten Frank M.
> beantworten) ist, wieviel Platz ist noch auf dem Chip, damit man
> eventuell die Steuerungswebseite noch ein wenig mit CSS designen könnte?

Auch eine gute Idee. Ich hatte da schon mal ein wenig mit CSS 
rumgespielt, das aber wegen Zeitmangel dann erstmal beiseite geschoben. 
Für ein wenig CSS ist gewiss noch Platz. Der ESP ist jedoch nicht gerade 
der schnellste, was die Ausgaben über WLAN betrifft. Daher sollte man 
das nicht soooo sehr aufblähen. Sonst wird der Seitenaufbau einfach zu 
langsam.

> Wenn da noch Platz vorhanden ist und Bedarf wäre, könnte ich das ganze
> auch grafisch ein wenig anpassen.

Ja, gern. Wie gesagt: Melde Dich am besten per PN.

: Bearbeitet durch Moderator
Autor: Burkhard Drechsler (burkadius)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,
Hallo Andreas
vergesst bitte meine Meldung, es läuft nun alles super mit SK6812 RGBW. 
Ich hatte wirklich die falsche FW ausgewählt (STM32F401 anstelle 
STM32F103.
App läuft auch und erkennt die RGBW selbstständig. Nun muß ich noch OTA 
verdrahten und testen.

Hallo Thomas Glass,
zum Ausschuss ESP8266-12F: hatte ich auch noch nie! Ich habe in anderen 
Projekten schon mehrere ESP8266-01 und auch NODEMCU verbaut, nie ein 
Problem! Deshalb konnte ich auch nicht glauben, dass nun gleich 2 defekt 
sind. Mir ist dann, nachdem die neuen 2 Module beide laufen, 
aufgefallen, dass die defekten beim Anschließen von VSS auch keine Reset 
machen (aufblitzen der blauen LED auf dem ESP-12F-Board).
In Zukunft werde ich besser immer ein Stück pro Händler bestellen.
Gruß
Burkhard

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Burkhard D. schrieb:
> vergesst bitte meine Meldung, es läuft nun alles super mit SK6812 RGBW.
> Ich hatte wirklich die falsche FW ausgewählt (STM32F401 anstelle
> STM32F103. App läuft auch und erkennt die RGBW selbstständig.

Freut mich. Ich hatte sowas schon vermutet. Mir ist das nämlich bei den 
hunderten von Tests auch schon passiert. ;-)

> Nun muß ich noch OTA verdrahten und testen.

Wenn Du im PATH-Feld test statt update einträgst, dann bekommst Du die 
aktuelle Test-Version 2.6.3 präsentiert. Dort liegt die bereits gestern 
abend angekündigte neue ESP-FW. Diese ist - was das Herunterladen der 
STM32-Hex-Dateien betrifft, wesentlich stabiler. Wenn Du testest, dann 
bitte mit dieser. Das ist zwar noch nicht die endgültige 2.6.3, aber bis 
auf ein paar neuere Meldungen beim Flashen soweit fertig.

: Bearbeitet durch Moderator
Autor: Burkhard Drechsler (burkadius)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank
ich schon wieder.
OTA Test
ESP Flash funktioniert wohl (ich habe aber schon die 2.6.2 per ST-Link 
installiert gehabt, daher ?)
STM32F103 Flash: Ich hatte ebenfalls per ST_LINK wie kurz berichte die 
FW STM32F103 SK6812RGBW installiert, da war alles ok.
Dann habe ich per OTA probiert. Wie im Bild die FW ausgewählt und "Flash 
STM32"gedrückt:Ergebnis:Download startet und läuft wohl normal durch. 
Allerdings wird eine völlig andere FW eingestellt und wohl auch 
geflasht. Siehe Bild. Dann habe ich "Reset STM32" betätigt. Über die 
WEB-Oberfläche ist die Uhr erreichbar,allerdings fehlen alle Inhalte, 
EEPROM und RTC offline, Version ohne Inhalt, nur Network zeigt ESP FW 
2.6.2 und IP sowie SSID an. aber die Uhr steht! Nach Hardrestart (reset 
am STM32 keine Änderung) bleibt das Display aus. Wahrscheinlich wegen 
der falschen FW Es wird ja WS2812-gbr ausgewählt.
Deshalb habe ich mich gestern wohl auch selber reingelegt. Mir war nicht 
aufgefallen, dass sich nach richtiger Auswahl der FW nach dem Flash 
Befehl sofort die falsche FW einstellt (WS2812-rgb) und wohl auch 
installiert.
Wenn ich dann per ST-Link wieder die richtige FW flashe ist alles wieder 
gut.
Das habe ich nun 2 mal gemacht, immer gleiches Ergebnis
Gruß
Burkhard

Autor: Burkhard Drechsler (burkadius)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank, diese Bild ist vor dem Flash ESP STM32f103 sk6812-rgbw
Hatte ich vergessen anzuhängen.
Burkhard

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Burkhard D. schrieb:
> Dann habe ich per OTA probiert. Wie im Bild die FW ausgewählt und "Flash
> STM32"gedrückt:Ergebnis:Download startet und läuft wohl normal durch.

Naja, ganz normal ist das nicht, schaue mal in Deine eigenen Bilder 
rein.

4684 geflashte Bytes sind entschieden zu wenig. Auch Du hast das 
Problem, dass die Hex-Dateien unvollständig heruntergeladen werden.

Deshalb lies nochmal meinen Beitrag von 11:11 Uhr bzw. meine PN, die ich 
Dir geschrieben habe. Im Path test statt update gibt es eine Pre-Version 
von 2.6.3 für das ESP-Modul, damit genau das, was Dir da passiert ist, 
nicht passiert.

> Allerdings wird eine völlig andere FW eingestellt und wohl auch
> geflasht.

Nein. Es wird die geflasht, die Du ausgewählt hast. Nach dem Klick auf 
"Flash STM32" wird dann das Standard-Hex-File angezeigt, weil der ESP 
nicht mehr auf die Hardware-Konfiguration des STM32 zugreifen kann, um 
die richtige Datei anzuzeigen. Das ist aber lediglich ein 
Anzeigefehler, den ich mittlerweile hier beboben habe.

> Siehe Bild. Dann habe ich "Reset STM32" betätigt. Über die
> WEB-Oberfläche ist die Uhr erreichbar,allerdings fehlen alle Inhalte,
> EEPROM und RTC offline, Version ohne Inhalt, nur Network zeigt ESP FW
> 2.6.2 und IP sowie SSID an. aber die Uhr steht!

Ja, siehe oben: 4684 Bytes sind nur ein Bruchteil des STM32-Programms. 
Hole Dir die ESP-Test-Version und teste bitte damit.

> Nach Hardrestart (reset
> am STM32 keine Änderung) bleibt das Display aus. Wahrscheinlich wegen
> der falschen FW Es wird ja WS2812-gbr ausgewählt.

Ja, es wird der Standard ausgewählt, weil der STM32 nicht mehr 
antwortet, nachdem er unvollständig geflasht wurde.

> Deshalb habe ich mich gestern wohl auch selber reingelegt.

Nein. Es wird das geflasht, was Du auswählst, die Anzeige ist lediglich 
nach dem Betätigen des Flash-Button falsch - solange, bis Du den STM32 
resettest und dieser wieder seine Hardware-Konfiguration an den ESP 
schicken kann - falls er sie schicken kann.

Ich werde den ausgewählten Dateinamen auch noch auf die Webseite 
schreiben, der da heruntergeladen wird, um alle Zweifel zu beseitigen.

Autor: X. O. (overflow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe eine WC12h mit ESP12f schon seit längerem am Laufen mit Fw2.4
OTA will ich nicht nutzen.

Kann ich die Uhr auf 2.6 upgraden?
(umlöten ist nicht möglich, da der ESP12f und STM32 fix auf der Platine 
verlötet sind.)

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
X. O. schrieb:
> Kann ich die Uhr auf 2.6 upgraden? (umlöten ist nicht möglich, da der
> ESP12f und STM32 fix auf der Platine verlötet sind.)

Ja, warum sollte das nicht gehen? Der ESP-12F lässt sich genauso wie der 
ESP-01 auch mit Kabeln flashen - wie gehabt mit dem User-Button. Dafür 
brauchst Du auch die zusätzlichen Kabel-Verbindungen nicht.

Autor: Burkhard Drechsler (burkadius)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank, hier das Testergebnis von der Update Test page als Anlage.
Hat gut funktioniert und die Uhr lädt auch noch obwohl in dem 
FW-Auswahlfenster wieder eine andere FW als ich runter geladen hatte 
anzeigt :-)
Gruß
Burkhard

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Burkhard D. schrieb:
> Hat gut funktioniert und die Uhr lädt auch noch obwohl in dem
> FW-Auswahlfenster wieder eine andere FW als ich runter geladen hatte
> anzeigt :-)

Da lese ich aus Deinem Bild:

File size: 800

Das ist viel zu klein. Korrekt wäre 141372 Bytes.

Aber glücklicherweise wird dieser Unsinn nicht mehr geflasht, so dass 
Dein STM32 dann nicht mehr hängenbleibt, denn:

Bytes flashed: 0

Der ESP hat die unvollständige Übertragung erkannt und diese 
abgebrochen:

Flash failed.

> wieder eine andere FW als ich runter geladen hatte anzeigt :-)

Die Test-Version ist von gestern abend. Da hatte ich den Anzeigefehler 
noch nicht repariert.

Fazit:

Das Herunterladen funktioniert immer noch nicht zuverlässig. Aber 
immerhin wird das nun vom ESP erkannt. Ich werde an entsprechender 
Stelle noch eine Fehlermeldung einbauen, damit da nicht "successful" 
erscheint.

Was mich ein wenig wundert: Der Webserver sagt, dass er bei Dir zum 
ersten Mal die Hex-Datei vollständig übertragen hat. Blöderweise kann 
ich das alles überhaupt nicht reproduzieren. Bei mir läuft alles 
reibungslos - auch nach ein paar dutzend Versuchen.

Ich bleibe dran und schaue mal, ob ich heute abend noch eine weitere 
Testversion hinbekomme. Irgendwie muss das ja in den Griff zu bekommen 
sein.

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Günter H. schrieb:
> Volker schrieb:
>
>> baue derzeit wieder zwei neue Uhren. Mit dem Shield Version 1. Habe
>> soweit alle Teile aus dem Warenkorb bestellt und soweit zusammengebaut.
>> Allerdings sind noch zwei/drei Fragen aufgetaucht:
>>
>> -> Das Bild der Rückseite der Uhr - ist da Top die Oberseite der Uhr
>> nehme ich an?
>
> Welches Bild meinst Du? Im Artikel gibt es mittlerweile so viele Bilder.
>
>> -> wie das flashen funktioniert ist mir noch nicht ganz klar. Ich habe
>> den ST-Link V2 mit USB dazu bestellt zum flashen. Kann ich damit auch
>> das WLAN Modul flashen? Wie muss ich genau vorgehen? Mein PC hat kein
>> WLAN, muss ich mir jetzt extra einen Stick anschaffen?
>
> Mit welchen Komponenten (Mini Dev- oder Nucleo-Board, welches ESP-Modul)
> hast Du die Steuerung für Deine Uhr aufgebaut?
>
> Das Flashen von STM32-Board und ESP-Modul ist im Artikel detailliert
> beschrieben - besser kann ich es hier auch nicht. An welchem
> Arbeitsschritt genau hast Du Probleme?
>
> Wenn Du das STM32-Mini-Development-Board verwendest, braucht Du
> zusätzlich zum STM32 ST-Link-Adapter einen USB-UART-Adapter, der mit 3,3
> V-Pegeln arbeitet und möglichst mit CH340G- oder CP2102-Chip bestückt
> ist - siehe Artikel.
>
> Wir helfen Dir gerne, brauchen aber auch einige konkrete Angaben.

Hi
erstmal Danke für die Antworten. Ich meinte das Bild (Aufgebaute WC12h 
mit WS2812 Streifen -dort wo man die Aluplatte komplett sieht) Würde das 
dann ähnlich einbauen.
Ich bin ehrlich gesagt was Elektrik angeht nicht so versiert, erkennt 
ihr aber sicher am Niveau der Fragen im Vergleich ;-)

Was das flashen angeht habe ich den ST-Link V2. Zusammengelötet habe ich 
das MiniDevBoaed mit STM32F in der Version 1. Die Firmwaredatei kann ich 
auch laden. mir ist nur noch nicht ganz klar wie ich die Datei auf das 
Board bringe - einfach copy und Paste?
Das flashen des WLAN Moduls kommt ja dann erst in der Folge...

Viele Grüße
Volker

Autor: Burkhard Drechsler (burkadius)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
Das lese ich aus Deinem Bild:

File size: 800

Das ist viel zu klein. Korrekt wäre 141372 Bytes.

Aber glücklicherweise wird dieser Unsinn nicht mehr geflasht, so dass
Dein STM32 dann nicht mehr hängenbleibt
Was mich ein wenig wundert: Der Webserver sagt, dass er bei Dir zum
ersten Mal die Hex-Datei vollständig übertragen hat. Blöderweise kann
ich das alles überhaupt nicht reproduzieren. Bei mir läuft alles
reibungslos - auch nach ein paar dutzend Versuchen.

Ich bleibe dran und schaue mal, ob ich heute abend noch eine weitere
Testversion hinbekomme. Irgendwie muss das ja in den Griff zu bekommen
sein.

Hallo Frank, danke für die Mühe. Wenn ich helfen kann melde dich kurz 
über PN, das sehe ich früher. Ich habe die nächsten Tage Zeit zum testen 
und die Uhr liegt unbekleidet auf dem Tisch :-)
Gruß
Burkhard

Autor: Torsten Giese (wawibu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Volker schrieb:
> Hi
> erstmal Danke für die Antworten. Ich meinte das Bild (Aufgebaute WC12h
> mit WS2812 Streifen -dort wo man die Aluplatte komplett sieht) Würde das
> dann ähnlich einbauen.
> Ich bin ehrlich gesagt was Elektrik angeht nicht so versiert, erkennt
> ihr aber sicher am Niveau der Fragen im Vergleich ;-)
Wenn Du dieses Bild meinst
>> https://www.mikrocontroller.net/articles/Datei:Auf...

Dann ja, TOP ist oben. Das Bild hatte ich mal gemacht. Das Shield ist 
dort in der rechten Tasche (von vorne gesehen). Auf dem Bild ist das 
Shield in der linken Tasche, da das Bild die Rückseite zeigt :)

Gruß,
Torsten

Autor: Burkhard Drechsler (burkadius)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,
Test zwei mal durchgeführt ( die ersten beiden FW Downloads waren 
falsch, meine Schuld).Ergebnis siehe BS-Foto. Den ESP-Flash hatte ich 
auch noch einmal angestoßen. Nur zur Sicherheit.
Ist denn nun alles ok? Die Uhr läuft noch !
Gruß
Burkhard

Autor: Christian S. (c_h_r_i_s_u)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Burkhard,

ich bin zwar nicht Frank, aber nach deinen beiden Screenshots würde ich 
mal sagen, da ist noch immer irgendwo der Wurm drinnen. Bei den 
Screenshots sieht man, dass die Datei die geladen wurde nur 
unvollständig war. Kein EOF wurde gefunden und die Datei war nur 800 
Bytes groß. Also genauso wie schon davor. Aber die Datei müsste um die 
141 Kilobytes groß sein.

Viele Grüße,
Chrisu

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Burkhard D. schrieb:
> Test zwei mal durchgeführt ( die ersten beiden FW Downloads waren
> falsch, meine Schuld).Ergebnis siehe BS-Foto. Den ESP-Flash hatte ich
> auch noch einmal angestoßen. Nur zur Sicherheit.

Vorab: Bitte kopiere den Text aus dem Browser nächstes Mal als Text (mit 
der Maus markieren, dann STRG-C) und schiebe ihn hier rein. Dann kann 
ich die einzelnen Zeilen kommentieren.

Der Webserver sagt für Deinen Download:
GET /test/wc12h-stm32f103-sk6812-rgbw.hex HTTP/1.1" 200 141372 "-" "-" 90 141588

Herauszulesen ist dabei:

Der Error-Code ist 200. Das heisst: OK. Dieser wird natürlich vom ESP 
auch ausgewertet, sonst wird der Flashvorgang direkt abgebrochen.

Die Dateigröße ist 141372 Bytes. Das ist korrekt. Übertragen wurden 
141588 Bytes, nämlich noch ein wenig mehr wie der HTTP-Header. Das passt 
alles.

Jetzt zu Deinem Output:

"Checking HEX File"

Das heisst: Das ESP-Programm geht die komplette Datei durch und prüft:

 - 3144 Checksums am Ende einer jeden Zeile
 - Test auf Vorhandensein eines EOF-Records am Ende der Datei

"Check successful"

Alle Checksums in der Datei sind korrekt und es wurde auch ein 
EOF-Record (End-Of-File) in der HEX-Datei gefunden.

Ergebnis: Die Datei ist vollständig bei Dir angekommen.

Jetzt wird es aber problematisch:

"Flashing STM32"

Die Hex-Datei, die vorher heruntergeladen wurde und lokal auf dem ESP im 
SPI-Flash gespeichert wurde, wird ein zweites Mal geöffnet (also nicht 
mehr heruntergeladen), und dann geflasht. Dazu sendet der ESP an den 
STM32 für jede Page (256 Bytes) einen Flash-Befehl. Und genau dieser 
wird von Deinem STM32 abgelehnt, denn da steht:

no ACK: (0x1f)

Der Code 0x1f bedeutet: NACK - also NOT Acknowledge, auf Deutsch: 
"Abgelehnt".

Die weiteren Meldungen sind einfach falsch, denn der Flash-Vorgang wird 
abgebrochen.

Hier handelt es sich um Folgefehler:

"File size 800"

Nach Einlesen von 800 Bytes (das entspricht ca. 256 im Flash, also einer 
Page) wurde das Lesen der Datei abgebrochen und deshalb nicht 
weitergezählt, wie groß die Datei tatsächlich ist.

"Error: no EOF-Record found"

Ist auch falsch, diese Meldung hätte auch beim vorherigen Check kommen 
müssen. Dadurch, dass der Flash-Vorgang abgebrochen wurde, hat das 
Programm  aber nicht mehr bis zum Ende der Datei gelesen und damit auch 
nicht mehr den EOF-Record lesen können.

Diesen Teil konnte ich bei mir nie testen, weil bei mir alle 
Flash-Vorgänge auf STM32F103 und STM32F4xx immer erfolgreich waren. 
Diese Meldungen werde ich zukünftig in den Check-Teil verschieben und 
beim Flash unterdrücken, denn sie sind hier unsinnig, wenn vorher der 
Flash-Vorgang abgebrochen wurde.

Fazit:

Dein STM32F103 lehnt den Flash-Vorgang ab, obwohl ich vorher das Flash 
"unprotected" habe (siehe Bild), was heisst: Das Flash wurde vorher 
entsperrt. Alles andere wie das Herunterladen und Checken funktioniert! 
Wir sind also einen Schritt weiter.

Aber warum ausgerechnet Dein STM32 den Flash-Befehl ablehnt, weiß ich 
noch nicht. Dazu muss ich mich nochmal durch die ST-Dokumentation 
wühlen, wann und wieso dieser Fehler auftreten kann.

Wir sind also nicht mehr weit von einer Lösung entfernt. Ich melde mich, 
sobald ich mehr weiß.

Autor: Peter G. (ingrimsch)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Na toll, ich hatte die Anleitung schon fertig und beim Bilder anhängen 
hat das Forum dann meinen Text gefressen. Grrrrrr.... also nochmal. :-(


Hi Volker,

Volker schrieb:
> Ich bin ehrlich gesagt was Elektrik angeht nicht so versiert, erkennt
> ihr aber sicher am Niveau der Fragen im Vergleich ;-)

Ich bin auch fachfremd, aber Projekte wie dieses finde ich wirklich 
klasse zum üben und lernen. Man behandelt zumindest oberflächlich einige 
Themen, bekommt am Ende ein Ergebnis mit Wow!-Effekt und kann sich dann 
ggf. noch tiefgreifender damit beschäftigen warum etwas funktioniert 
oder auf eine spezielle Art und Weise gelöst wurde. Selbst Kinder, die 
sich sonst für (fast) nichts begeistern können, sind auf einmal Feuer 
und Flamme, haben Spaß an Basteleien und interessieren sich dafür wie 
die Dinge funktionieren.

Ich hab auch noch keinen Meister vom Himmel fallen sehen. :-) Einfach 
dranbleiben, nicht frustrieren lassen wenn etwas nicht sofort klappt wie 
gewünscht, Fragen stellen wenn was unklar ist und wenn doch Fehler 
passieren versuchen herauszufinden was genau falsch gelaufen ist.

> Was das flashen angeht habe ich den ST-Link V2. Zusammengelötet habe ich
> das MiniDevBoaed mit STM32F in der Version 1. Die Firmwaredatei kann ich
> auch laden. mir ist nur noch nicht ganz klar wie ich die Datei auf das
> Board bringe - einfach copy und Paste?
> Das flashen des WLAN Moduls kommt ja dann erst in der Folge...

Zuerst musst du den ST-Link Adapter und das MiniDevBoard so verkabeln, 
dass beide miteinander sprechen können. Schau dir dazu einfach im Wiki 
(https://www.mikrocontroller.net/articles/WordClock...) 
das entsprechende Bild "Flashen per St-Link v2 Clone" an: 
https://www.mikrocontroller.net/articles/Datei:STM...

Wenn beides miteinander verbunden ist brauchst du noch ein Programm, 
dass die gewünschte Software in das MiniDevBoard schreiben kann. Ich 
benutze dazu schon länger das "STM32 ST-Link Utility" 
(http://www.st.com/en/embedded-software/stsw-link004.html)

1. ST-Link Adapter in einen freien USB Port stecken und die Software 
starten
2. File --> Open --> und die Software passend zu deine Hardware 
auswählen (wenn du z.B. mit WS2812B LED Streifen und dem MiniDevBoard 
eine Wordclock 12h bauen willst, wählst du hier 
"wc12h-stm32f103-ws2812-grb.hex" aus). Ist die Datei geladen siehst du 
erstmal etwas kryptisch den Inhalt der Datei...
3. Dann klickst du auf Target --> Program & Verify und bestätigst das 
nächste Fenster um die Software in das MiniDevBoard zu schreiben. Ich 
habe leider gerade keine Hardware hier um entsprechende Fotos zu machen, 
aber du schaffst das schon... ;-)

Im unteren (Log-)Bereich der Software sollten nach dem Schreibvorgang 
Meldungen wie "flash write complete" und "verify complete" auftauchen. 
Dann ist die Software im Flash und du kannst dir Franks Anleitung zum 
flashen des WLAN Moduls 
(https://www.mikrocontroller.net/articles/WordClock...) 
vornehmen. Dazu brauchst du dann aber einen USB UART / USB TTL Adapter, 
wie z.B. diesen hier: 
Ebay-Artikel Nr. 142303807172

Grüße und viel Erfolg
Peter

: Bearbeitet durch User
Autor: Günter H. (gnter_h534)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

das mit dem "Fressen" von Text im Forum kenne ich irgendwie...

Die angehängte pdf-Datei war fast fertig - Du warst schneller. 
Wenigstens gibt es aus meiner Sicht inhaltlich keine Widersprüche.


Hallo Volker,

das sieht zu Beginn ziemlich verwirrend aus, Schritt für Schritt kommst 
Du dem Ziel näher.

Gruß
Günter

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dank Burkhards intensiver Hilfe als Tester konnte ich die Bugs in 
STM32-OTA-Flash-Routinen nun beseitigen und das ganze noch weiter 
stabilisieren.

Es gibt daher ein Update für den ESP-12F mit nur einem Punkt:

ESP Version 2.6.3:

   Diverse Korrekturen in den STM32-OTA-Flash-Routinen.

Diese Version könnt Ihr nun entweder aus dem Artikel laden und klassisch 
"über Kabel" installieren oder direkt über OTA.

Diese ESP-Version ist auch bereits mit dem neuen Shield v3 für das 
Mini-Dev-Board erfolgreich getestetet.

: Bearbeitet durch Moderator
Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter und Günter: Top - Vielen Dank :-)

Und das mit der Begeisterung sehe ich ganz genauso!!

Viele Grüße
Volker

Autor: Günter H. (gnter_h534)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Volker schrieb:

> Zusammengelötet habe ich
> das MiniDevBoaed mit STM32F in der Version 1.

Peter G. schrieb:
> und du kannst dir Franks Anleitung zum
> flashen des WLAN Moduls
> 
(https://www.mikrocontroller.net/articles/WordClock...)
> vornehmen. Dazu brauchst du dann aber einen USB UART / USB TTL Adapter,
> wie z.B. diesen hier:
> Ebay-Artikel Nr. 142303807172

Hallo Volker,

wenn Du wirklich die erste Version des Shields für das STM32-MiniBoard 
einsetzt ((c) March 2016 by Torsten Giese), beachte bitte, dass bei 
dieser Version des Shields bei den Anschlüssen für den UART die 
Bezeichnungen TX und RX vertauscht sind. Deshalb werden - nur bei diesem 
Shield - TX vom USB UART-Adapter mit TX auf dem Shield und weiterhin RX 
mit RX verbunden.

Normalerweise werden RX mit TX und TX mit RX verbunden.

Viel Erfolg
Günter

: Bearbeitet durch User
Autor: Jan R. (pinguin895)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
nachdem ich vor Weihnachten eine Uhr (wc24h-stm32f411-ws2812-grb) gebaut 
habe (wobei ihr mir auch schon geholfen habt, vielen Dank nochmal 
dafür!), wollte ich diese heute von der Version 2.4 auf 2.6.2 updaten.

Das Flashen hat auch laut der Ausgabe von der ST-Link Utility 
funktioniert, aber seit dem geht meine Uhr nicht mehr.
Die LEDs auf den Boards (inkl. der auf der RTC und dem WLan Modul) 
leuchten, aber die WS2812 LEDs gehen nicht mehr an. Ich kann außerdem 
das W-Lan Modul (ESP8266 ESP-01) nicht flashen, das Tool sagt mir immer, 
dass die Verbindung fehlschlägt und in PuTTY sehe ich auch keine Ausgabe 
mehr. Außerdem ist die Uhr auch nicht mehr im Netzwerk angemeldet.
Ich habe dann probiert wieder die Ursprungsversion aufzuspielen, was 
auch erst einmal vom flash Vorgang her funktioniert hat, aber auch die 
alte Software Version funktioniert jetzt nicht mehr...

Ich kann natürlich nicht ausschließen, dass ich beim Anschließen des 
ST-Link irgendwelche Kabel abgerissen, Lötstellen zerstört oder etwas 
anderes kaputt gemacht habe, aber alle sichtbaren Lötstellen sehen nach 
wie vor gut aus und das was ich nachmessen konnte hat auch nach wie vor 
eine Verbindung.

Ich weiß, dass das ein sehr allgemeines Problem ist, aber hat jemand 
evtl. doch eine Idee woran das liegen könnte oder hatte sogar mal das 
selbe Problem?

Schon mal vielen Dank im Voraus und viele Grüße
Jan

Autor: Peter G. (ingrimsch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Günter H. schrieb:
> Wenigstens gibt es aus meiner Sicht inhaltlich keine Widersprüche.

Klasse Anleitung! Wenn ich kommende Woche ein wenig Leerlauf habe würde 
ich die Anleitung ins Wiki übertragen und auch deine Bilder übernehmen 
wenn du nichts dagegen hast. Ist für Einsteiger bestimmt hilfreich und 
an der Stelle einfach besser aufgehoben, ich hatte nur neulich nicht die 
Zeit dafür (die Wiki Syntax und ich stehen ein wenig auf Kriegsfuß, ohne 
ständiges nachlesen läuft da gar nichts ;-))

@Jan

Hast du auch mit der Version 2.4 Probleme den ESP zu flashen? Falls ja, 
dann zieh mal den ESP ab, schreibe den STM nochmal neu (2.4 oder 
aktuell) und schau mal ob du dann Ausgaben per UART bekommst (ruhig mal 
den STM per Reset Knopf neu starten wenn UART verbunden ist). Da sollten 
auf jeden Fall die ersten Meldungen erscheinen...

Wenn das klappen sollte nimm den Strom weg, steck das ESP Modul wieder 
auf, halte die User Taste fest und steck das Netzteil wieder ein. Nach 
der Wartezeit dann die User Taste wieder loslassen und versuchen das ESP 
Modul zu flashen.

@Frank


> Diverse Korrekturen in den STM32-OTA-Flash-Routinen.

Klasse, vielen Dank! Habe gerade keine Hardware zum testen, aber jetzt 
wo meine LED Streifenplatinen für die 12h fertig sind komme ich 
vielleicht die Tage dazu meine eigene Uhr mal auf das aktuelle Projekt 
und SK6812 RGBW umzubauen. Werde dann ausführlich testen! Und 
Schwiegerpapa bekommt sein ESP-12F Uprade jetzt auch wenn wir die Tage 
mal wieder da sind, sollte ja mittlerweile robust genug sein, damit auch 
ein Spielkind da nichts mehr kaputt machen kann. ;-)

Schönes Wochenende,
Peter

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die erste Uhr mit Shield v3 :-)

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan R. schrieb:
> Das Flashen hat auch laut der Ausgabe von der ST-Link Utility
> funktioniert, aber seit dem geht meine Uhr nicht mehr.

An der neuen Version kanns nicht liegen, die läuft und ist mehrfach 
getestet. Es kann höchstens sein, dass Du die falsche STM32-Software 
gewählt hast. Damit machst Du den STM32 zwar nicht kaputt, aber dann 
läuft er nicht mehr, bis Du das korrekte Image geflasht hast.

Welche Datei hast Du denn geflasht?

> Die LEDs auf den Boards (inkl. der auf der RTC und dem WLan Modul)
> leuchten, aber die WS2812 LEDs gehen nicht mehr an. Ich kann außerdem
> das W-Lan Modul (ESP8266 ESP-01) nicht flashen, das Tool sagt mir immer,
> dass die Verbindung fehlschlägt und in PuTTY sehe ich auch keine Ausgabe
> mehr. Außerdem ist die Uhr auch nicht mehr im Netzwerk angemeldet.

Geht noch der UART-Log? Also siehst Du eventuelle Boot-Meldungen?

> Ich habe dann probiert wieder die Ursprungsversion aufzuspielen, was
> auch erst einmal vom flash Vorgang her funktioniert hat, aber auch die
> alte Software Version funktioniert jetzt nicht mehr...

Du hast vermutlich irgendeine Kabelverbindung abgerissen. Wenn Du arg 
unvorsichtig warst, könnte es noch eine statische Entladung sein. Das 
wäre dann nicht so gut.

Gehe bitte systematisch vor:

1. STM32 nochmals flashen, wenn das geht, ist der STM32 erstmal ok.
2. UART-Log kontrollieren, eventuell hier zeigen.
3. Kommen Meldungen, die in runden Klammernn gezeigt werden? Das
   sind nämlich Meldungen vom ESP.
4. Kontrollieren, ob UART-Adapter mit RX und TX korrekt angeschlossen
   ist und ob GND auch Verbindung hat.
5. Spannung an den Stripes kontrollieren.
6. Einen 1,5K Pullup an DIN von der ersten LED anlöten, also zwischen
   DIN und 5V.

Bitte teile auch mit, ob WC24h, Nucleo oder Mini-Board. Foto wäre auch 
nicht schlecht.

Autor: Jan H. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen!

Ich habe auf dem ESP8266-f12 die aktuelle version 2.6.3 drauf.
allerdings kann ich kein lokales update durchführen.

ist das nur bei mir so?

Autor: Andreas M. (andiator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jan,

wie erkennst Du dass es nicht geklappt hat?

Denn laut Deinem Screenshot hat es funktioniert...

MfG,
Andreas

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan H. schrieb:
> allerdings kann ich kein lokales update durchführen

Das Flashen war erfolgreich. Hast Du vergessen, danach den Button Reset 
STM32 im Webinterface zu drücken? Solange verbleibt der STM32 nämlich im 
Booloader-Modus.

: Bearbeitet durch Moderator
Autor: Jan H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Hallo Jan,
>
> wie erkennst Du dass es nicht geklappt hat?

Hallo Andreas!

Das erkenne ich daran,
das ich immer mein eigenes Süppchen koche.
(Hex-file erstellen)
Und die Änderungen garnicht zur Geltung kommen.
Hab auch schon versucht das Hex-File einzuspielen über Online-Update 
einzuspielen, indem ich auf meinen Homepage ein Download-Ordner angelegt 
habe um von dort das Hex-File einzuspielen.
"Update Host" und "Update Path" geändert geht aber nicht, weil die Uhr 
da angeblich nichts findet.
Letztendlich hab ich die Uhr von der Wand genommen und das Hexfile mit 
Kabel eingespielt und siehe da, meine Änderungen waren da.

Autor: Jan H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Das Flashen war erfolgreich. Hast Du vergessen, danach den Button Reset
> STM32 im Webinterface zu drücken? Solange verbleibt der STM32 nämlich im
> Booloader-Modus.

Den Reset-Button hab ich gedrückt.

Autor: Marco R. (majestick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

danke für das Update läuft soweit super, muss jetzt nur noch meine 
Änderungen einbauen ;)

Hast du evt. noch einen Tip für einen STM32F103 der sich über OTA nicht 
flashen lassen möchte und immer in ein Timeout rennt. Er scheint den 
Bootloader nicht zu erreichen.
Entferne ich den ESP kann ich den STM einwandfrei über UART am PC 
flashen.
Die ESP Module funktionieren aber einwandfrei an anderen Boards.

hast du evt. eine debug version um die Kommunikation über gpio 13 und 15 
zu testen / kontrollieren?



Hallo Jan,

wenn du deinen eigenen "Update Server" haben möchtest benötigst du noch 
ein paar Dateien mehr auf dem Server:

wc-list.txt         enthält alle Dateinamen der Images
wc.txt              enthält die Versionsnummer für STM
ESP-WordClock.txt   enthält die Versionsnummer für ESP
releasenote.html    Infos

In der neuen Version kommt auf dem ersten Blick auch noch ein Filter zur 
Geltung der nur Images für deine HW anzeigt. muss ich mir aber noch mal 
genauer ansehen.

Dennoch hätte ein lokales Update funktionieren sollen.

Gruß
Marco

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marco R. schrieb:
> wc-list.txt         enthält alle Dateinamen der Images
> wc.txt              enthält die Versionsnummer für STM
> ESP-WordClock.txt   enthält die Versionsnummer für ESP
> releasenote.html    Infos

Korrekt.

> In der neuen Version kommt auf dem ersten Blick auch noch ein Filter zur
> Geltung der nur Images für deine HW anzeigt.

Auch das ist richtig. Wenn der STM32 im Run-Modus ist, filtert der ESP 
auf den verwendeten Typ, also f103, f401 oder f411.

Da liest mal jemand den Source :-)

Autor: Jan H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marco R. schrieb:
> Hallo Jan,
>
> wenn du deinen eigenen "Update Server" haben möchtest benötigst du noch
> ein paar Dateien mehr auf dem Server:
>
> wc-list.txt         enthält alle Dateinamen der Images
> wc.txt              enthält die Versionsnummer für STM
> ESP-WordClock.txt   enthält die Versionsnummer für ESP
> releasenote.html    Infos

Hallo Marco!

Stirnklatsch Jetzt geht es auch mit dem Online-Update über Web-Server.

Trotzdem wäre mir der lokale Update-Modus lieber.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan H. schrieb:
> Stirnklatsch Jetzt geht es auch mit dem Online-Update über Web-Server.

Immerhin :-)

> Trotzdem wäre mir der lokale Update-Modus lieber.

Ja, natürlich. Ich kann Deine Beschreibung auch mittlerweile 
nachvollziehen. Ich habe mal in main.h die Version geändert und dann ein 
Local Update durchgeführt. Ergebnis: Es erscheint die alte Version.

Dann habe ich es auf den Webserver geschoben und ein Remote Update 
gemacht: Es erscheint die neue Version.

Ich verstehe im Moment nur nicht, wo da der Unterschied ist. Beide 
Varianten laden die Datei runter und speichern sie im lokalen 
SPI-Filesystem. Danach rufen sie die Flash-Routinen auf. Muss irgendwas 
blödes sein...

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fehler gefunden:

Local-Update speichert die Datei in "/stm32.hex"
Remote-Update speichert die Datei in "stm32.hex"

Flash-Routine flasht "stm32.hex".

Offenbar versteht der ESP unter "/stm32.hex" und "stm32.hex" zwei 
verschiedene Dateinamen im SPI-Filesystem. Fällt natürlich nicht auf, 
wenn man immer dieselbe Hex-Datei flasht.

Ich habe das nun vereinheitlicht. Danach klappte das mit dem 
Local-Update und die gepatchte Versionsnummer wurde auch gezeigt.

Update ESP 2.6.4 kommt gleich...

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Update für ESP8266-12F ist online.

Einziger Punkt:

Bugfix in Local Update über OTA: Es wurde in V2.6.3 immer diejenige 
Datei geflasht, die zuletzt über das Remote Update heruntergeladen 
wurde.

@Jan: Kannst Du das nochmal testen - nur um sicher zu gehen?

Autor: Jan H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> @Jan: Kannst Du das nochmal testen - nur um sicher zu gehen?

Hallo Frank!

Kann ich bestätigen. Jetzt geht der Lokale-Update Modus.
Besten Dank.

Autor: Jan R. (pinguin895)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

Peter G. schrieb:
> Hast du auch mit der Version 2.4 Probleme den ESP zu flashen?

Nein, mit der 2.4 hat es damals alles Einwandfrei funktioniert. Aber 
selbst wenn ich die 2.4 jetzt wieder aufspiele klappt es nicht mehr, 
weshalb ich aktuell nicht von einem Software Fehler ausgehe.



Frank M. schrieb:
>
> Welche Datei hast Du denn geflasht?

die "wc24h-stm32f411-ws2812-grb.hex" wobei selbst wenn ich wieder die 
selbe Datei flashe wie im Dezember funktioniert es nicht.

>
> Geht noch der UART-Log? Also siehst Du eventuelle Boot-Meldungen?
>
nein, nur als ich irgendwann vergessen habe während des flashens die 
PuTTY Verbindung zu trennen, habe ich ein paar kryptische Zeichen 
gesehen. Sonst nichts.

> Du hast vermutlich irgendeine Kabelverbindung abgerissen. Wenn Du arg
> unvorsichtig warst, könnte es noch eine statische Entladung sein. Das
> wäre dann nicht so gut.

Das ist durchaus möglich, wobei ich zumindest alle sichtbaren 
Kabelverbindungen "durchgepiepst" habe und sie alle noch Kontakt 
haben...

> Gehe bitte systematisch vor:
>
> 1. STM32 nochmals flashen, wenn das geht, ist der STM32 erstmal ok.
-> geht
> 2. UART-Log kontrollieren, eventuell hier zeigen.
-> steht nichts drin
> 3. Kommen Meldungen, die in runden Klammernn gezeigt werden? Das
>    sind nämlich Meldungen vom ESP.
-> nein
> 4. Kontrollieren, ob UART-Adapter mit RX und TX korrekt angeschlossen
>    ist und ob GND auch Verbindung hat.
-> ist es meines Erachtens. Zumindest hat es so mal funktioniert.
> 5. Spannung an den Stripes kontrollieren.
-> ist vorhanden
> 6. Einen 1,5K Pullup an DIN von der ersten LED anlöten, also zwischen
>    DIN und 5V.
-> habe ich aktuell nicht hier. Müsste ich also kaufen. Kann das die 
Ursache dafür sein, dass das W-Lan Modul nicht läuft?

> Bitte teile auch mit, ob WC24h, Nucleo oder Mini-Board. Foto wäre auch
> nicht schlecht.
WC24h mit Nucleo Board. Fotos sind im Anhang

Vielen Dank und viele Grüße
Jan

Autor: Jan H. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jan!

Schau mal ganz genau nach ob die Anschlussbeine,
von den Kondensatoren keinen Kurzschluss mit dem Quarzgehäuse 
verursachen.
Ich würde die Kondensatoren auf die Rückseite verlagern.


Gruß Jan

Autor: Torsten Giese (wawibu)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Artikel sind nun auch die Einträge für bei Shields erweitert worden. 
Es wurden Bilder im bestückten Zustand hinzugefügt und die Beschreibung 
entsprechend erweitert.

Beim MiniDev hat sich dann leider doch der kleine Fehlerteufel 
eingeschlichen.....

Der 4-polige Pin-Header JP6 für den UART kann nur als 3-poliger 
Pin-Header ausgeführt werden, da der +5V Pin vom STM Board verdeckt 
wird. Das ist aber nicht weiter dramatisch. Der +5V Pin wird im nächsten 
Release eh entfallen, da man sich dadurch nur eine Fremdspannung 
einfangen kann. TX  RX  GND sind als 3-poliger Pin-Header erreichbar 
und für die Funktionalität ausreichend.

Dieser Fehler trifft leider auch den 3-poligen Pin-Header JP12 zum 
wechseln zwischen PROG / RUN. Hier müssen 3 Adern ins Shield gelötet 
werden die dann entweder an einen Umschalter kommen oder and denn 
externen 3-poligen Pin-Header (so wie im Bild).
Im nächsten Release werde ich den Pin-Header um eine Raste zum 
Platinenrand verschieben. Dann ist das Problem gelöst.

Grüße,
Torsten

Autor: Jan R. (pinguin895)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jan,

> Schau mal ganz genau nach ob die Anschlussbeine,
> von den Kondensatoren keinen Kurzschluss mit dem Quarzgehäuse
> verursachen.

das sieht man auf dem Bild relativ schlecht, aber der Quarz liegt ein 
wenig höher als die Kondensatoren. Da ist über 1mm Platz zwischen und 
laut Multimeter besteht dort auch auf keinem anderen Weg Kontakt

Viele Grüße
Jan

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan R. schrieb:
>> 2. UART-Log kontrollieren, eventuell hier zeigen.
> -> steht nichts drin

Mal RX/TX vertauscht?

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marco R. schrieb:
> Hast du evt. noch einen Tip für einen STM32F103 der sich über OTA nicht
> flashen lassen möchte und immer in ein Timeout rennt. Er scheint den
> Bootloader nicht zu erreichen.

Du hast GPIO4 mit BOOT0 verbunden? Kannst Du mal den Text aus dem 
Browser kopieren, damit ich sehe, an welcher Stelle der Timeout kommt?

Du musst zumindest den TX von einem evtl. vorhanden USB-UART-Adapter vom 
Shield trennen. Der stört sonst. Aus diesem Grund gibt es einen 
Run/Prog-Jumper auf dem Shield v3, was genau das tut.

> Entferne ich den ESP kann ich den STM einwandfrei über UART am PC
> flashen.

Der ESP schaltet normalerweise GPIO13 und GPIO15 auf Input, damit er 
einen eventuell vorhandenen UART-Adapter am UART-Anschluss des Shields 
nicht stört. Nur beim STM32-Flashen über OTA schaltet er die beiden 
Anschlüsse um auf TX/RX.

> Die ESP Module funktionieren aber einwandfrei an anderen Boards.
>
> hast du evt. eine debug version um die Kommunikation über gpio 13 und 15
> zu testen / kontrollieren?

Das blöde ist, dass man den Vorgang über den ESP-UART nicht loggen kann, 
da dieser für das OTA-Flashen des STM32 belegt ist. Da helfen nur die 
Meldungen im Browser. Kopiere diese deshalb mal hier rein.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas hat eine neue Version der Android-App rausgegeben.

Download wie gehabt unter: WordClock mit WS2812: Download

Behobene Fehler:
- Animations- und Anzeigelisten konnten nicht gescrollt werden
- Titel der Animations- und Modus-Dialoge war falsch (%d wählen)
- Display Ein und Aus zeigten als Meldung immer "Display Ein gesendet!"

Änderungen:
- Farbregler automatisch verbergen, wenn Regenbogen-Farbanimation
  gewählt wurde.
- Automatische IP-Suche.
- Laden und Speichern der Profile in einem Dialog zusammengefasst.
- Info anzeigen, wenn beim Starten keine Netzwerkverbindung besteht.

Viel Spaß,

Frank

Autor: Michael K. (damichl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurze Frage: wo ist Pin1 des IRF9310 auf dem neuen Nucleo Shield?

Danke!

Autor: Michael K. (damichl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann gebe ich mir mal selbst die Antwort, habe es gerade nachgemessen.

Pin 1 ist bei "IRF" des Bestückungsdrucks.

mfg

Autor: Torsten Giese (wawibu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael K. schrieb:
> Dann gebe ich mir mal selbst die Antwort, habe es gerade nachgemessen.
>
> Pin 1 ist bei "IRF" des Bestückungsdrucks.
Da hast Du Recht - in Eagle kann ich das gut erkennen, doch auf dem 
Bestückungsdruck ist die Linie, welche die abgeflachte Seite anzeigt, 
genau an der Kante der Lötaugen. Ich mache da mal einen Hinweis im 
Artikel.

Gruß,
Torsten

Autor: Michael K. (damichl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, ich glaube das wäre hilfreich. Bin nun mit der Bestückung soweit 
fertig, mangels SMD-Teilen und dank des tollen Bestückungsdrucks war das 
diesmal echt easy :)

Wenn man nun - aus welchem Grund auch immer - den STM32 per SWD oder 
JTAG flashen möchte, muss man ihn aus dem Shield entfernen und die jew. 
Signale manuell anschließen oder? Evtl. könnte man bei der V4 (falls es 
diese jemals geben sollte, einen Anschluss ähnlich TagConnect, z.B. 
http://protofusion.org/wordpress/2016/02/open-sour... 
vorsehen). Mir ist klar, dass das Zukunftsmusik ist, soll nur ein 
konstruktiver Vorschlag sein, z.B. falls man die SW mal debuggen möchte.

mfg

Michael

Autor: Torsten Giese (wawibu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu debuggen / flashen ist doch der UART rausgeführt. Die Pins liegen 
zwar unter dem Nucleo, können aber entsprechend verwendet werden.

Schaue mir das aber gerne mal an.

Gruß,
Torsten

Beitrag #4949290 wurde von einem Moderator gelöscht.
Autor: Jan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

nachdem mein ESP-12F nun endlich aus China eingetroffen ist, habe ich 
mich an den Umbau der 12h-Worclock mit Shield V1 gemacht.

Der ESP-12F scheint auch problemlos zu funktionieren. Ich kann mich 
verbinden und das OTA-Update des ESP-12F (von 2.6.3 auf 2.6.4) klappt 
auch.

Erst wenn ich die zwei Pins für TX/RX also PA9/PA10 anschließe, startet 
die Uhr nicht normal bzw. verbindet sich nicht mit dem WLAN. Es wird die 
Uhrzeit angezeigt aber es läuft nicht die IP durchs Display.

Putty kann ich ja nicht anschließen, da die Pins belegt sind.

Wer weiß Rat?

Die Anleitung ist etwas verwirrend... Ich habe den 10k Widerstand 
zwischen Boot und GND (siehe eingekringelte Zeichnung) direkt auf dem 
ESP-Shield eingelötet. Müsste das Selbe sein, wie auf dem Bild mit dem 
STM, oder?

Autor: Andreas M. (andiator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jan,

Jan schrieb:
> Müsste das Selbe sein, wie auf dem Bild mit dem
> STM, oder?

Ja, ist der selbe Widerstand.

Jan schrieb:
> startet
> die Uhr nicht normal bzw. verbindet sich nicht mit dem WLAN

Kommst Du dann mit dem Browser nicht auf den ESP drauf? Falls ja, zeigt 
es vernünftige Werte wie z.B. die EEPROM-Version an?

Und ansonsten die Verbindungen noch mal prüfen.

MfG,
Andreas

Autor: Marco R. (majestick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jan,


ja den R1 kannst du so lassen, darfst nun aber das WLAN Modul nicht mehr 
abziehen da aufgrund der dann fehlenden GND Verbindung das STM Modul 
möglicherweise nicht mehr startet.

Warum das WLAN Modul nicht startet gute frage, Pins vertauscht? 
PA10/PA09
evt. mal durch messen.

Einen UART Adapter solltest du noch anschließen können, solange du TX 
nicht verbindest. Damit solltest du mitlesen können.

Gruß
Marco

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Kommst Du dann mit dem Browser nicht auf den ESP drauf? Falls ja, zeigt
> es vernünftige Werte wie z.B. die EEPROM-Version an?

Nein, ich komme nicht drauf.


Marco R. schrieb:
> Warum das WLAN Modul nicht startet gute frage, Pins vertauscht?
> PA10/PA09
> evt. mal durch messen.

Ich habs noch mal durchgemessen und mit der Anleitung verglichen... Ich 
hatte Rx mit Rx und Tx mit Tx verbunden.

Nun habe ich diese mal getauscht und siehe da... Beim UART-Adapter hat 
es aber nach ersterer Verbindungsart immer geklappt...

Danke

Autor: Marc D. (unbekann21)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hallo zusammen,

ich wollte mal fragen ob jmd auch noch die probleme mit "flacker" usw 
hat.
foto anbei sollte zeigen was ich meine, zeit wird korrekt angezeigt aber 
zwischendurch verschieben sich die led ansteuerungen einfach mal um ein 
paar buchstaben

zuerst lag die vermutung auf dem LDR (diese probleme hab ich gelesen)
LDR aktiv -> uhr "spinnt"
LDR inaktiv -> uhr läuft einwandfrei


mittlerweile ist der fehler dauerhaft und auch wenn der LDR abgesteckt 
ist tritt der fehler auf.

mit sonnen einfall kann ich sie auch zu diesem fehler bringen (LDR 
angsteckt aber in der steuerung deaktiviert)

vllt hat jmd ähnliche probleme, symptome auf seiner uhr


M.

Autor: Thomas H. (supergrobi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kurze Frage:

woran kann es liegen, wenn die IP-Adresse nicht ausgegeben wird?

Welcome to WordClock Logger!
----------------------------
Version: 2.6.2
rtc is online
ws2812: no external pullup detected
eeprom is online
current eeprom version: 0x00020600
ESP8266 LOGGER
read rtc: Su 2000-01-01 00:10:08
esp8266 now up
(- setup UDP)
(- local port: 2421)
(- setup server UDP)
(- local port: 2424)
(FIRMWARE 2.6.2)
(- connected to AP)
(AP SGHome)
(MODE client)
(IPADDRESS 192.168.2.130)

das web interface kann ich aufrufen, aber an den LEDs ändert sich nichts 
mehr. die Ersten LEDs werden angezeigt "ES ist ... irgendwas Uhr" aber 
danach, wenn eigentlich die IP durchscollen sollte ändert sich nichts 
mehr...

Autor: Thomas H. (supergrobi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc D. schrieb:
> ich wollte mal fragen ob jmd auch noch die probleme mit "flacker" usw
> hat.

hab ich auch, aber mich nicht weiter darum gekümmert, da ich es erstmal 
auf den LDR geschoben hatte. Bei mir war es beim einstellen einer festen 
Helligkeit verschwunden. Auch die Rainbow Animation läuft ohne Flackern 
durch...

Autor: Horst B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Marc D. und Thomas H.!

Um euch helfen zu können wäre es hilfreich wenn ihr uns mitteilt wie 
euer
Aufbau aussieht. Welches Board (Nucleo oder STM32F103) habt ihr?
Was für ein W-Lan Modul ist verbaut. Ist die richtige Firmware drauf?
Ist der Aufbau mit Shields durchgeführt worden, oder over fly?

Habt ihr euren Aufbau auch wirklich 3 x kontrolliert?

Autor: Thomas H. (supergrobi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Horst,
Bei mir handelt es sich um den f103 mit mini shield Aufbau. Jedoch mit 
neuer Firmware 2.6.2.  Hier habe ich auch noch das alte f01 WLAN Modul 
verbaut.
Beim automatischen dimmen verschieben sich die Buchstaben um 1-2 stellen 
nach links.

Autor: Günter H. (gnter_h534)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas H. schrieb:

> ws2812: no external pullup detected

Hast Du mal getestet, ob ein 1k8 pullup-Widerstand (Data In --> +5 V) 
den Fehler behebt?

Gruß
Günter

Autor: Marc D. (unbekann21)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo horst

hab den nucleo 411 verbaut mit shield und die neue 2.6.2 fW drauf (auch 
auf dem esp01)

aufbau ist sauber gemacht

hab jetzt mal für den LDR die widerstände angepasst, wie es bei der 
aufbau seite beschrieben ist (hatte alle widerstände nach shield/list 
bestückt)

hab jetzt diese gewechselt wie es für bestimmte LDRs angegeben ist

aber leider keine änderung des problems

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan schrieb:
> Hallo zusammen,
>
> nachdem mein ESP-12F nun endlich aus China eingetroffen ist, habe ich
> mich an den Umbau der 12h-Worclock mit Shield V1 gemacht.
>
> Der ESP-12F scheint auch problemlos zu funktionieren. Ich kann mich
> verbinden und das OTA-Update des ESP-12F (von 2.6.3 auf 2.6.4) klappt
> auch.

Hallo Jan,

ich versuche auch gerade eine WC auf ESP12 umzubauen und habe dieselbe 
Adapterplatine verwendet wie du im Bild.

Wie hast du den Lötjumper eingestellt?

Vielen Dank und viele Grüße
Jens

Autor: Dario C. (dario) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal eine Frage zur Batterie auf dem RTC:

Sehe ich das richtig, dass man die nicht zwingend benötigt.

Ich verstehe das so: wenn die Batterie fehlt, dann hat die Uhr nicht 
direkt nach dem Einschalten die richtige Uhrzeit, sondern muss diese 
erst per NTP aus dem Netz ziehen, bzw. über DCF empfangen.

Ansonsten funktioniert aber alles wie gehabt, die Config ist ja im 
EEPROM gespeichert und das verliert die Daten ja nicht bei 
Spannungsausfall.

Oder habe ich etwas übersehen?

Dario

Autor: Thomas H. (supergrobi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Günter H. schrieb:
> Hast Du mal getestet, ob ein 1k8 pullup-Widerstand (Data In --> +5 V)
> den Fehler behebt?

werde ich machen...
wird aber etwas dauern. Hab gerade viel um die Ohren

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dario C. schrieb:
> Ich habe mal eine Frage zur Batterie auf dem RTC:
>
> Sehe ich das richtig, dass man die nicht zwingend benötigt.

Ja, Du kannst sie weglassen, allerdings sollte man dann VBat mit GND 
verbinden. So stehts im Datenblatt:

     "If VBAT is not used, connect to ground."

Allerdings bekommt man die CR2032 für unter 1 EUR und hält angeblich an 
der DS3231-RTC bis zu 10 Jahre. Ob man daher hier sparen muss, bleibt 
Dir überlassen.

Autor: Thomas H. (supergrobi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas H. schrieb:
> Günter H. schrieb:
>> Hast Du mal getestet, ob ein 1k8 pullup-Widerstand (Data In --> +5 V)
>> den Fehler behebt?
>
> werde ich machen...
> wird aber etwas dauern. Hab gerade viel um die Ohren

Edit ging leider nicht mehr...

hab es doch eben schnell gemacht :) Jedoch ohne Änderung.

Welcome to WordClock Logger!
----------------------------
Version: 2.6.2
rtc is online
ws2812: external pullup detected
eeprom is online
current eeprom version: 0x00020600
ESP8266 LOGGER
read rtc: Su 2000-01-01 00:00:03
esp8266 now up
(- setup UDP)
(- local port: 2421)
(- setup server UDP)
(- local port: 2424)
(FIRMWARE 2.6.2)
(- connected to AP)
(AP SGHome)
(MODE client)
(IPADDRESS 192.168.2.130)

wahrscheinlich irgend ein dummer Fehler von mir. Was fehlt ihm da vor 
dem Senden der IP ?

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Wie hast du den Lötjumper eingestellt?

Hallo Jens,
welchen Lötjumper meinst du? Meine Uhr hängt wieder verschraubt an der 
Wand... Meinst du die Rückseite der Platine? Da habe ich nichts 
gemacht...
Was bewirkt der Lötjumper? :)

Autor: Dario C. (dario) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

Du schriebst:
>> Batterie ... nicht zwingend benötigt.
> Ja, Du kannst sie weglassen, ...
> Ob man daher hier sparen muss, bleibt Dir überlassen.

Du hast recht, aber mit geht es nicht ums sparen.

Vielmehr habe ich meine Holzplatten so gefräst, dass der RTC mit 
Batterie nicht reinpasst und ich die Batteriehalterung bislang immer 
ablöte, mit Kabeln verlängere und daneben in die Tasche klebe. Heute kam 
mir die Idee, das ich mir die Arbeit eventuell ja gar nicht machen muss.

Danke für die Antwort,

Dario.

Autor: Günter H. (gnter_h534)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas H. schrieb:

>> Günter H. schrieb:
>>> Hast Du mal getestet, ob ein 1k8 pullup-Widerstand (Data In --> +5 V)
>>> den Fehler behebt?
>
> hab es doch eben schnell gemacht :) Jedoch ohne Änderung.

Der pullup-Widerstand sollte auch eher diesen Fehler bei deiner Uhr 
beheben:

> Beim automatischen Dimmen verschieben sich die Buchstaben um 1-2 Stellen
> nach links.

Autor: Michael K. (damichl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne jetzt in den Code zu sehen, habe ich eine kleine Frage:

In welchem Zeitraum wird eine als gültig empfangene DCF77-Zeit durch die 
NTP-Zeit überschrieben?

Ich habe mir übrigens erlaubt, den Wiki-Eintrag bzgl. der Einbaurichtung 
des Mosfets zu ergänzen.

Vielen Dank!

: Bearbeitet durch User
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael K. schrieb:
> In welchem Zeitraum wird eine als gültig empfangene DCF77-Zeit durch die
> NTP-Zeit überschrieben?

Die NTP-Zeit wird alle 3800 Sekunden geholt. Demnach ist der Zeitraum, 
wann eine DCF77-Zeit überschrieben wird, sehr unterschiedlich.

Autor: Jens (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jan schrieb:
> Jens schrieb:
>> Wie hast du den Lötjumper eingestellt?
>
> Hallo Jens,
> welchen Lötjumper meinst du? Meine Uhr hängt wieder verschraubt an der
> Wand... Meinst du die Rückseite der Platine? Da habe ich nichts
> gemacht...
> Was bewirkt der Lötjumper? :)

Hallo Jan,

ehrlich gesagt habe ich keine Ahnung, was er bewirkt. Auch den üblichen 
Shopseiten bekomme ich dazu auch keine Angaben. Es sieht mir aber nicht 
nach einfachen Durchkontaktierungen aus. Daher dachte ich, dass es ein 
Lötjumper ist (siehe Bild).
Dann werde ich es auch mal ohne versuchen.
Danke
Gruß
Jens

Autor: Bernhard S. (b_sa)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jens,

Jens schrieb:
> Daher dachte ich, dass es ein
> Lötjumper ist (siehe Bild).

Das ist kein Lötjumper sonder der Einbauplatz für einen optionalen 
Spannungsregler (bei manchen Angeboten im Lieferumfang enthalten) dazu 
muss dann aber auf der Oberseite noch der mittlere 0 Ohm Widerstand 
entfernt werden (siehe Bild). das hat den Vorteil, dass man dann den ESP 
auch mit 5V versorgen kann.

Autor: Günter H. (gnter_h534)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:

> Wie hast du den Lötjumper eingestellt?

Der "Lötjumper" kann dazu verwendet werden, einen 3,3 V-Spannungsregler 
einzulöten, er ist im Normalfall auf der Adapterplatine mit einem Null- 
Ohm-Widerstand überbrückt. Das kann auch alles so bleiben, da auf dem 
Shield schon eine "externe" 3,3 V-Versorgung vorgesehen ist.

Weiterhin sind auf der Adapter-Platine schon folgende Widerstände 
eingebaut:
Pin CH_PD vom ESP-12 Adapter-Platine über 10k an VCC (3,3 V),
Pin GPIO15 vom ESP-12 Adapter-Platine über 10k an GND.

Getrennt eingelötet werden müssen noch folgende Widerstände:
Pin GPIO02 vom ESP-12 Adapter-Platine über 10k zu VCC (3,3 V),
Pin GPIO4 vom ESP-12 Adapter-Platine an 
BOOT0-Jumper/STM32-Mini-Dev-Board  (Mittlerer Anschluss) und an Pulldown 
10k.

Viel Erfolg
Günter

: Bearbeitet durch User
Autor: Mirco D. (bpoh_voodoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Günter H. schrieb:
> Thomas H. schrieb:
>
>> ws2812: no external pullup detected
>
> Hast Du mal getestet, ob ein 1k8 pullup-Widerstand (Data In --> +5 V)
> den Fehler behebt?
>
> Gruß
> Günter

Hallo,

habe das Flackern, bzw. Verschieben auch. Ob die autom. 
Helligkeitsregelung an oder aus ist, spielt auch keine Rolle. Mit LDR 
tritt es jedoch häufiger auf. Den WS2812 Pullup habe ich seit jeher 
eingebaut. Das Problem tritt jedoch erste seit Firmware 2.6.x auf. 
Scheint also doch irgendwie an der Firmware zu liegen.

Specs:
altes Schield Umbau auf ESP-12
STM32F103
"Vollausbau"

PS: Ging auch nach dem Umbau noch einwandfrei mit 2.5.0

: Bearbeitet durch User
Autor: Günter H. (gnter_h534)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mirco D. schrieb:

> Ging auch nach dem Umbau noch einwandfrei mit 2.5.0

Hast Du berücksichtigt, dass beim Firmware-Update von 2.5.x zu 2.6.x 
auch eine Änderung der Verbindung zwischen ESP-12F und STM32 notwendig 
ist?

GPIO4 (und nicht mehr GPIO16) muss nun mit BOOT0 des STM32 verbunden 
werden.

Gruß
Günter

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mirco D. schrieb:
> habe das Flackern, bzw. Verschieben auch. Ob die autom.
> Helligkeitsregelung an oder aus ist, spielt auch keine Rolle. Mit LDR
> tritt es jedoch häufiger auf. Den WS2812 Pullup habe ich seit jeher
> eingebaut. Das Problem tritt jedoch erste seit Firmware 2.6.x auf.
> Scheint also doch irgendwie an der Firmware zu liegen.

Ich versuche am Wochenende, dieses Problem zu reproduzieren. Wird aber 
wohl schwierig, weil ich dieses Problem erstmal so nicht habe und mir im 
Moment auch überhaupt nicht vorstellen kann, wie der LDR bzw. die 
Analogmessung die LED-Ausgabe beeinträchtigen kann. Aber jetzt, wo es 
schon 3 Leute sind, die das Phänomen beobachten können, bin ich guter 
Dinge, das auch hinzukriegen.

Autor: Thomas H. (supergrobi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Günter H. schrieb:
> Hast Du berücksichtigt, dass beim Firmware-Update von 2.5.x zu 2.6.x
> auch eine Änderung der Verbindung zwischen ESP-12F und STM32 notwendig
> ist?
>
> GPIO4 (und nicht mehr GPIO16) muss nun mit BOOT0 des STM32 verbunden
> werden.

So wie ich das verstanden habe, ist das für die Update Funktion 
notwendig. Korrigiert mich bitte, wenn ich falsch liege.
Bei mir tritt das flackern mit dem alten esp auf. Ohne gpio 4 /16an 
boot0.

Lg Thomas

Autor: Günter H. (gnter_h534)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

die Verbindung GPIO4 (vorher GPIO16) mit BOOT0 des STM32 ist für die 
Update-Funktion mit dem ESP-12F notwendig. Es war eine (vage) Vermutung 
von mir, dass wegen "falscher Verschaltung" das Update des Boards nicht 
richtig geklappt hat.

Die Tatsache, dass das Flackern auch beim ESP-01 auftreten kann, zeigt, 
dass das Problem anderswo zu suchen ist.

Gruß
Günter

Autor: X. O. (overflow)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mittlerweile sind die Platinen eingetroffen. :)
2-3 kleine(und wirklich dämmliche) Patzer sind mir unterlaufen, aber 
nichts wirklich gravierendes, die Uhr läuft, das ist die Hauptsache. 
(USB Portbelegung gespiegelt, Reset Button war 90° verdreht aufgelötet, 
der Pull-Up an der WS2812b war etwas zu groß)

Für die Unterstützung der OTA Funktion war ich leider zu schnell :P

Autor: Thomas H. (supergrobi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas H. schrieb:
> kurze Frage:
>
> woran kann es liegen, wenn die IP-Adresse nicht ausgegeben wird?

Für alle, die es interessiert: ich hab die Ursache gefunden.

Wenn man ein neues EEPROM beim Update abbricht, also etwa hier:
...
current eeprom version: 0x44434241
updating EEPROM to version 0x00020600
...

dann steht wohl irgendein Müll im Eprom und die Uhr hängt sich auf.
Hab das jetzt mit einigen Modulen durch. :)

Könntet Ihr da bitte irgendwas einbauen, dass man einen FirmwareReset 
durchführen kann und das EEPROM löscht ?

danke und lg

Autor: Thomas H. (supergrobi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

ich hab das mal etwas weiter verfolgt.

wofür ist die Variable gmain.update_hosts ?
wenn die ans ESP gesendet wird, hängt er sich auf.

ich hänge mal ein Screenshot von den Watches an...

lg

Autor: Romi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
X. O. schrieb:
> Mittlerweile sind die Platinen eingetroffen. :)

Können Sie Ihr Schema teilen?

En
Can you share your schema?

Autor: Mirco D. (bpoh_voodoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Mirco D. schrieb:
>> habe das Flackern, bzw. Verschieben auch. Ob die autom.
>> Helligkeitsregelung an oder aus ist, spielt auch keine Rolle. Mit LDR
>> tritt es jedoch häufiger auf. Den WS2812 Pullup habe ich seit jeher
>> eingebaut. Das Problem tritt jedoch erste seit Firmware 2.6.x auf.
>> Scheint also doch irgendwie an der Firmware zu liegen.
>
> Ich versuche am Wochenende, dieses Problem zu reproduzieren. Wird aber
> wohl schwierig, weil ich dieses Problem erstmal so nicht habe und mir im
> Moment auch überhaupt nicht vorstellen kann, wie der LDR bzw. die
> Analogmessung die LED-Ausgabe beeinträchtigen kann. Aber jetzt, wo es
> schon 3 Leute sind, die das Phänomen beobachten können, bin ich guter
> Dinge, das auch hinzukriegen.

Hallo Frank
natürlich habe ich nach dem Software Update auch die GPIOs des ESPs 
angepasst.
Was mir noch aufgefallen ist. Wenn die Datumsanzeige kommt (bei mir alle 
2 Min) hangen die Sekunden solange bis das Datum durch ist. Beim 
Minutenwechsel hängen die Sekunden auch kurz.

Das Verschieben tritt immer bei Aktualisierung des Streifens auf. Z.B. 
wenn der LDR die Helligkeit anpasst, etc. Mit der automatischen 
Helligkeitsregelung lässt sich das zuverlässig reproduzieren. Zumindest 
bei mir. Machmal tritt das Verhalten auch bei 15 Sek auf (was auch immer 
da passiert).
Meistens ist es nur sehr kurz zu sehen (1/10s oder so) machmal aber dann 
auch länger.
Hoffe die Infos helfen irgendwie.

Ich hätte da noch einen Vorschlag. Können wir nicht einen Stable und 
einen Dev. Brach für die Updates machen. die 2.5.0 lief super, aber 
hatte ein paar Bugs (Temperatur Offset nicht speicherbar und GPIO 
Wechsel). Ansonsten hätte ich gerne die erstmal weiter benutzt. Notfalls 
kann ich mir das Zeugs aber auch selbst kompilieren.

: Bearbeitet durch User
Autor: X. O. (overflow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir tritt das Springen der Wörter mit 2.6.2 auch auf. Es tritt immer 
direkt auf, wenn ich mich mit der Hand dem Sensor nähere, sich die 
Helligkeit also ändert. Abkleben des LDR behebt das Problem.

Probeweise hatte ich nochmals auf 2.4.0 gewechselt. Dort funktioniert 
das automatische Dimmen tadellos ohne dem Springen der Wörter.

: Bearbeitet durch User
Autor: X. O. (overflow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ps. Es handelt sich um eine WC12h mit Stm32F103 Controller und esp12f

Autor: Thomas H. (supergrobi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich versuche am Wochenende, dieses Problem zu reproduzieren. Wird aber
> wohl schwierig, weil ich dieses Problem erstmal so nicht habe und mir im
> Moment auch überhaupt nicht vorstellen kann, wie der LDR bzw. die
> Analogmessung die LED-Ausgabe beeinträchtigen kann. Aber jetzt, wo es
> schon 3 Leute sind, die das Phänomen beobachten können, bin ich guter
> Dinge, das auch hinzukriegen.

Hab jetzt mal eine identische Platine aufgebaut:
WC24h F103, ESP07, EEPROM, LDR Shield V1.

hier tritt das Flackern nicht auf...
einziger unterschied ESP 07 statt 01

...kann mir also nur vorstellen, das es an den WS2812 liegt

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas H. schrieb:
> Wenn man ein neues EEPROM beim Update abbricht, also etwa hier:
> ...
> current eeprom version: 0x44434241
> updating EEPROM to version 0x00020600
> ...
>
> dann steht wohl irgendein Müll im Eprom und die Uhr hängt sich auf. Hab
> das jetzt mit einigen Modulen durch. :)

Du hast schon einige Module beim EEPROM-Update "abgebrochen"? Wie machst 
Du das? Ich baue in das 2.6.3er Update ein, dass bei nicht-plausiblen 
EEPROM-Versionen die Standard-Werte neu geschrieben werden. Das sollte 
Dein Problem beheben.

Mirco D. schrieb:
> Ich hätte da noch einen Vorschlag. Können wir nicht einen Stable und
> einen Dev. Brach für die Updates machen. die 2.5.0 lief super, aber
> hatte ein paar Bugs (Temperatur Offset nicht speicherbar und GPIO
> Wechsel).

Ich bringe erst eine neue x.y.0 raus, wenn alle bekannten Bugs der 
Vorgänger-Version gefixt sind. Das Problem ist die Varianten-Vielfalt: 3 
verschiedene µCs, WC12h/WC24h, 4 verschiedene LED-Typen, mit oder ohne 
optionale LDRs/DS18xx usw. Ich kann das nicht immer alles durchtesten, 
dafür gibt es zuviele mögliche Kombinationen. Aber Du kannst davon 
ausgehen, dass die x.y.z mit der höchsten z-Version eine stabile Version 
ist. Von der 2.5er war das tatsächlich die 2.5.0, denn es gab keine 
2.5.1 mehr. Davor war es die 2.4.2.

Die nächste Version ist dann die 2.6.3. Dies wird voraussichtlich die 
nächste Stable-Version sein. Denn das einzige bekannte Problem bei der 
2.6.2 ist das Springen der Buchstaben um 1 oder 2 Stellen und das obige 
EEPROM-Problem, wenn man sich die Daten im EEPROM zerschießt.

Erst danach wird es eine 2.7.0 geben. Wahrscheinlich vorher noch ein 
paar Pre-Versionen, denn mit dem OTA-Update können die engagierten User 
Vorabversionen testen. Diese werden dann beim Download im Path "test" 
statt "update" liegen. Damit haben wir dann eine Art "Dev-Branch", so 
wie Du ihn Dir vostellst.

X. O. schrieb:
> Bei mir tritt das Springen der Wörter mit 2.6.2 auch auf. Es tritt immer
> direkt auf, wenn ich mich mit der Hand dem Sensor nähere, sich die
> Helligkeit also ändert. Abkleben des LDR behebt das Problem.

Danke für den Tipp. Im Moment habe ich gerade keinen LDR zur Hand, aber 
ich versuche gerade, das durch Code-Analyse herauszubekommen. Ansonsten 
simuliere ich das mal mit ein paar Helligkeitssprüngen direkt in der 
Software. Leider hatte ich dieses Wochenende weniger Zeit, als ich 
dachte. Ich versuche, das in der kommenden Woche zu lösen.

Autor: 0xef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bzgl. des Problems der springenden Buchstaben:

Da das ganze mit dem A-D Wandler das LDR zusammenzuhängen scheint: 
werden da irq's gesperrt oder ein busy-polling betrieben?
(ich finde im Code auf den Schnelle nix, ist aber ein wenig 
verstreut...)
Ich hätte nämlich die DMA-Interruptroutine zum berechnen der LED-Daten 
für den Timer im Verdacht. Wenn der DMA-IRQ zu lange warten muss, werden 
veraltete Daten ausgegeben und das LED-Muster verrutscht.

Könnte man da evtl. ne Logmeldung für diesen Fall einbauen? (Also wenn 
am Ende der Berechnung das Interrupt-flag schon wieder gesetzt ist, die 
Berechnung also der Ausgabe zu weit hinterherläuft?)

Oder versuchsweise doppelt soviele Bits in einem Rutsch berechnen: spart 
Overhead des IRQ-Aufrufs.

0xef

PS.: Theorie basiert darauf, dass dieses Problem mit dem großen 
LED-Buffer nicht auftrat. Laut Changelog war die v2.5 die erste mit dem 
kleinen DMA-Buffer. Kann jemand bestätigen, dass das springen auch mit 
2.5 auftritt? Das wäre ein starkes Indiz für obige These....

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0xef schrieb:
> Da das ganze mit dem A-D Wandler das LDR zusammenzuhängen scheint:
> werden da irq's gesperrt oder ein busy-polling betrieben?
> (ich finde im Code auf den Schnelle nix, ist aber ein wenig
> verstreut...)

Die Hauptschleife pollt:

main.c: main() -> ldr_poll_brightness()
ldr.c: ldr_poll_brightness() -> adc_poll_conversion_value()
adc.c: adc_poll_conversion_value() -> ADC_GetFlagStatus ()

> Ich hätte nämlich die DMA-Interruptroutine zum berechnen der LED-Daten
> für den Timer im Verdacht. Wenn der DMA-IRQ zu lange warten muss, werden
> veraltete Daten ausgegeben und das LED-Muster verrutscht.

Da gibt es keinen ADC-Interrupt

> PS.: Theorie basiert darauf, dass dieses Problem mit dem großen
> LED-Buffer nicht auftrat. Laut Changelog war die v2.5 die erste mit dem
> kleinen DMA-Buffer. Kann jemand bestätigen, dass das springen auch mit
> 2.5 auftritt? Das wäre ein starkes Indiz für obige These....

Laut den obigen Angaben gibt es das Problem in 2.5 nicht, erstmals mit 
2.6. Deswegen habe ich den kleinen DMA-Buffer, an den ich auch schon 
gedacht habe, mittlerweile ausgeschlossen. Auch soll das Problem nur bei 
Helligkeitsänderungen auftreten.

Autor: X. O. (overflow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,
es tritt auch bei der 2.5.0 auf.
Weiß jetzt nicht ob es was damit zu tun hat, aber was mir aufgefallen 
ist, nach dem Upgrade des STM und ESP steht bei EEPROM Version immer 
noch 2.4.0 drin.

PS. 2.5.0 hatte ich bisher nie ausprobiert. Nur die 2.4.0 und 2.6.4

: Bearbeitet durch User
Autor: Casi239 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo@  Torsten Giese (wawibu),
ich hatte Dir eine PN geschrieben. Ich benötige für meine WC
ein STM32 Nucleo Shield v3 OTA und den Zwischenboden (WC24h).
Ich hoffe du kannst mir da etwas anbieten.
Wegen der Front habe ich bereits UKW eine PN geschrieben.
Gruß Carsten

Autor: Thomas H. (supergrobi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Du hast schon einige Module beim EEPROM-Update "abgebrochen"? Wie machst
> Du das? Ich baue in das 2.6.3er Update ein, dass bei nicht-plausiblen
> EEPROM-Versionen die Standard-Werte neu geschrieben werden. Das sollte
> Dein Problem beheben.

Ich bekomme immer einen Schreck, wenn ich einschalte und es leuchtet 
keine Status LED. Ich denke ich habe irgendwo einen kurzen gebaut und 
schalte wieder aus... :)

Autor: Mirco D. (bpoh_voodoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mirco D. schrieb:
> Was mir noch aufgefallen ist. Wenn die Datumsanzeige kommt (bei mir alle
> 2 Min) hangen die Sekunden solange bis das Datum durch ist. Beim
> Minutenwechsel hängen die Sekunden auch kurz.

Kann das denn auch jemand verifizieren?

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mirco D. schrieb:
> Was mir noch aufgefallen ist. Wenn die Datumsanzeige kommt (bei mir alle
> 2 Min) hangen die Sekunden solange bis das Datum durch ist. Beim
> Minutenwechsel hängen die Sekunden auch kurz.

Wenn ein Ticker durchläuft, bleibt erstmal alles andere stehen. Das ist 
(im Moment noch) gewollt so. Bei der asynchronen Anzeige gibt es 
Konkurrenzprobleme: Was passiert, wenn der Ticker über eine volle Minute 
läuft und das Display für die Uhrzeit aktualisiert werden muss?

Ich habe schon mehrmals probiert, das asynchron laufen zu lassen, habe 
es aber noch nicht geschafft, alle Events, die auf das Display zugreifen 
(kann z.B. auch Temperatur-Anzeige sein) dabei derart zu 
synchronisieren, dass es keinen Datensalat auf der Anzeige gibt. Steht 
aber weiter auf meiner TODO-Liste, das zu implementieren.

> Das Verschieben tritt immer bei Aktualisierung des Streifens auf. Z.B.
> wenn der LDR die Helligkeit anpasst, etc.

Also nicht nur durch Änderung der LDR-Helligkeit? Auch wenn Du im 
Webinterface die automatische Helligkeitsregelung abschaltest und dann 
die Helligkeitsregelung manuell per Schieber im Browser vornimmst? Das 
kriege ich nicht hin, das habe ich gestern ein paar dutzend Mal 
probiert.

Also: Was heißt "etc." am Ende Deines Satzes? Ich möchte das Phänomen 
gern zu packen bekommen. Aber auch hier schrieb am Wochenende jemand, 
dass es an seiner zweiten Uhr nicht vorkommt. Nicht, dass es an 
irgendwelchen elekrischen Eigenschaften liegt, z.B. weil das LDR-Signal 
nahe an der WS2812-Datenleitung vorbeiläuft. Dann kann ich lange in der 
Software suchen.

Also: Exakte Beschreibung, bitte.

Autor: 0xef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc D. schrieb:
> zwischendurch verschieben sich die led ansteuerungen einfach mal um ein
> paar buchstaben

Das Bild zeigt klar, dass die Pixeldaten um genau 2 LED's in 
Kettenrichtung verschoben sind (also je nach Zeile um 2 nach links oder 
rechts und die rausrutschenden Daten in der darunterliegenden Zeile).
-> Die Pixeldatenberechnung klemmt.

bisher ist das Problem beobachtet worden bei wc24h mit MiniSTM32 und 
ws2812 led's ab Firmware v2.5.

Nach durchsicht des ASM-Listings für wc24h-stm32f103.ws2812-grb sind 
drei Dinge klar:
- Nirgendwo werden IRQ's lange genug gesperrt um ein Problem zu sein.
- Die Verarbeitungskette des LDR blockiert nix. Der LDR kann also 
höchstes der Auslöser, nicht aber das Problem sein. Das hatte Frank ja 
oben schon geschrieben, ich habs hiermit eine Ebene drunter verifiziert.
- Die meisten IRQ-Routinen sind kurz genug. Probleme könnte 
TIM2_IRQHandler machen: diese Routine ist recht lang und ruft auch noch 
die irmp routine auf, welche auch nicht gerade kurz ist. Und wenn ich 
den Code richtig lese, das ganze auch noch 15000 mal pro Sekunde.

Für mich ergeben sich daraus zwei Fragen:
- tritt das Problem auch mit dem NucleoF4x1 auf (der taktet etwas 
schneller)
- wie ist der TSOP für die Fernbedingung angeschlossen/abgeblockt?
  (evtl. 'erkennt' ja der STM irgendwelche Störimpulse und braucht 
dadurch in der Interruptroutine länger.) <= Meine Vermutung

Ideen zur Abhilfe:
- evtl. doppelt sovile LED-Daten berechnen (Puffergröße verdoppeln -> 
mehr Zeit, bis es kritisch wird).
- Priorität des DMA-Interrupt erhöhen? bisher laufen ja alle auf 
gleicher Prio.
- evtl. noch ein mitloggen der benötigten Taktzyklen (über einen bisher 
unbenutzten timer) in die IRQ-Routinen einbauen und bei überschreiten 
von ca. 24*90-x eine Warn-Logmeldung ausgeben.

So und jetzt halte ich die Klappe zu dem Thema und bastel weiter am 
Makefile (und suche die 4 extra bytes die er mir jetzt reinbaut).

0xef

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0xef schrieb:
> - Die meisten IRQ-Routinen sind kurz genug. Probleme könnte
> TIM2_IRQHandler machen: diese Routine ist recht lang und ruft auch noch
> die irmp routine auf, welche auch nicht gerade kurz ist. Und wenn ich
> den Code richtig lese, das ganze auch noch 15000 mal pro Sekunde.

Die IRMP-ISR ist zwar ziemlich lang, trotzdem werden wegen der 
Statemachine in der ISR immer nur wenige Zeilen durchlaufen. So 
funktioniert das sogar auf einem ATtiny noch mit 15000 Durchläufen pro 
Sekunde.

> Für mich ergeben sich daraus zwei Fragen:
> - tritt das Problem auch mit dem NucleoF4x1 auf (der taktet etwas
> schneller)

Ich habe in Erinnerung, dass jemand das Problem auch auf seinem Nucleo 
hat.

> - wie ist der TSOP für die Fernbedingung angeschlossen/abgeblockt?

Andere Frage: Ist überhaupt ein TSOP angeschlossen? Wenn nein, ist der 
STM32-Pin wie im Artikel beschrieben auch per Pullup "stillgelegt" oder 
driftet der lustig herum? In diesem Fall kann das schon mal zu einem 
Problem werden, wenn die IRMP-ISR nach dem verwendeten Protokoll sucht. 
Dasselbe gilt auch für den DCF77-Pin. Auch diesen sollte man per Pullup 
stillegen, wenn kein DCF77 benutzt wird.

>   (evtl. 'erkennt' ja der STM irgendwelche Störimpulse und braucht
> dadurch in der Interruptroutine länger.) <= Meine Vermutung

Eher durch fehlende Pullups bei Nicht-verwendung.

> So und jetzt halte ich die Klappe zu dem Thema

Ich halte Deine Analysen für sehr sinnvoll. Wenn Dir noch mehr einfällt, 
immer raus damit.

Autor: 0xef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Wenn Dir noch mehr einfällt,
> immer raus damit.

Zur Entschärfung der Problematik:
- Fix the Hardware.
- LED-Pixeldatenpuffer verdoppeln. (Mehr Zeitpuffer bis Probleme 
auftauchen)
- Interruptdauern im simulator oder 'live' mitmessen. (Hilft bei 
Entscheidung über nächsten Punkt.)
- Den TIM2_IRQHandler aufspalten (IRMP + Rest). (Dauer der längsten 
IRQ-Routine verkürzen.) ((Der 'Rest' ist ja eigentlich nur eine 'setze 
Flag X, falls counter X wert Y hat' - Orgie. Da liesse sich nur Zeit 
sparen, indem man dekrementiert, statt zu inkrementieren:
  aus:
    X_cnt ++;
    if (x_cnt == F_INTERRUPTS/Y) { x_cnt=0; x_flag=1};

  würde:
    if (!--x_cnt) {x_cnt=F_INTERRUPTS/Y;x_flag=1};
  mit passender Initialisierung.

- Interrupts priorisieren. (DMA-IRQ bekommt höchste Prio. Da wird der 
bisherige TIM2_IRQHandler für LDR/DCF77/ESP/EEPROM eben mal ein bisschen 
später ausgeführt....)

Erstmal warten, was X.O. und Marc D. zu ihren TSOP/DCF77 sagen.
(Oder wer sonst noch dieses Problem hat.)

0xef

PS.: @Frank: Ich hatte den Ergeiz, das Makefle so umzuschreiben, dass es 
identische Binaries ausspuckt. Leider scheint das umbenennen von Dateien 
die Reihenfolge zu verändern in der der Linker sie im Binary 
zusammenklebt.
So handele ich mir jetzt zweimal einen long-branch (32bit opcode) ein, 
statt einem kurzen (16bit opcode). Und die binaries sehen (im Vergleich 
vorher/nachher) wild verwürfelt aus. Ist das ein Problem, oder 
akzeptabel, sofern das Binary weiterhin tut, was es soll?

PPS.: @Frank: stopf das Ambilight doch in das Ende des LED-updates 
(während /nachdem die RESET-Pause ausgegeben wird/wurde.) Dann läuft es 
IMMER mit. Spart Kopfweh über State-machines. (Und das ambilight ist 
nicht so irre aufwendig).

Autor: Mirco D. (bpoh_voodoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Also: Was heißt "etc." am Ende Deines Satzes? Ich möchte das Phänomen
> gern zu packen bekommen. Aber auch hier schrieb am Wochenende jemand,
> dass es an seiner zweiten Uhr nicht vorkommt.
Das "etc." heißt in meinem Fall, dass es bei mir auch bei WC Tetris mit 
abgeschaltetem LDR auftritt. Selten kann man es auch bei der Snake 
Animation sehen.


> Nicht, dass es an
> irgendwelchen elekrischen Eigenschaften liegt, z.B. weil das LDR-Signal
> nahe an der WS2812-Datenleitung vorbeiläuft. Dann kann ich lange in der
> Software suchen.
Was ist denn "Nahe" reichen 2 cm Abstand?
Notfalls kann ich zum Test den LDR abklemmen und den 10k Pullup 
draufpacken.
Kann man sonst die Datenleitung ausschließen, meinetwegen, wenn ich ein 
geschirmtes Kabel nehme und die Schirmung auf GND lege?

Spricht nicht gegen ein Datenleitungsproblem des WS2812, dass ich diese 
Probleme früher nicht hatte?

: Bearbeitet durch User
Autor: 0xef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mirco D. schrieb:
> Spricht nicht gegen ein Datenleitungsproblem des WS2812, dass ich diese
> Probleme früher nicht hatte?

Hallo Mirco,

eben genau nicht. Wenn es mit V2.4 läuft, aber mit v2.5+ nicht mehr, ist 
die Ursache die veränderte Routine zum berechnen der LED-Pixeldaten.
Die funktioniert Fehlerfrei, sofern nicht zu lange der entsprechende 
DMA-Interrupt blockiert wird. (den brauchte man vorher so nicht).

Der einzige Softwareteil, der diesen Interruot blockieren kann, scheint 
der TIM2_IRQHandler zu sein, in dem u.a. DCF77 und TSOP abgefragt 
werden.
Sollten diese Eingänge 'lustige Störimpulse' auffangen (z.B. TSOP nicht 
installiert, aber auch kein Pull-down dran) kann diese Interruptroutine 
so lange brauchen, dass das berechnen der LED-pixeldaten nicht 
hinterherkommt. Es werden dann 2x alte Daten übermittelt -> Die Anzeige 
'springt' um 2 LED-Positionen.

Also: Hast du TSOP/DCF angeschlossen? evtl. hilft nich ein 
filterkondensator am tssop (zwischen + und masse). Testweise bitte auch 
mal den tssop mit schwarzem klebeband abkleben ((die fernbedienung geht 
dann latürnich nich) und kucken, ob man das Problem irgendwie 'nicht 
haben' kann. Dann bitte Report hier.

0xef

Autor: Mirco D. (bpoh_voodoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, hier erstmal die Specs:

WC24h
altes Schield (V2) Umbau auf ESP-12
STM32F103
"Vollausbau" (LDR, TSOP, DCF77, TEMP)
60 Ambilight LEDs.

TSOP abgeklebt, LDR aktiviert
Bei LDR Werteänderungen ist das Phänomen immer noch zu beobachten,

also:
Uhr von der Wand WS2812 Kabel neu verlegt bis auf die Status LED (in der 
Mitte von LDR und TSOP) haben die jetzt maximal möglichen Abstand > 15 
cm.

Leider immer noch keine Besserung.
Hoffe das hilft irgendwie weiter.

: Bearbeitet durch User
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mirco D. schrieb:
> Notfalls kann ich zum Test den LDR abklemmen und den 10k Pullup
> draufpacken.

Ja, mach das bitte mal. Genau das ist nämlich meine aktuelle 
Testsituation und ich bekomme das Problem noch nichtmals zu sehen. :-(

Wichtig wäre auch die Info, ob Du einen TSOP angeschlossen hast und wenn 
nicht, ob ein entsprechender Pullup als Ersatz angeschlossen ist. Das 
gleiche gilt für den DCF77-Pin.

0xef schrieb:
> Sollten diese Eingänge 'lustige Störimpulse' auffangen (z.B. TSOP nicht
> installiert, aber auch kein Pull-down dran) kann diese Interruptroutine
> so lange brauchen, dass das berechnen der LED-pixeldaten nicht
> hinterherkommt. Es werden dann 2x alte Daten übermittelt -> Die Anzeige
> 'springt' um 2 LED-Positionen.

Ja, das klingt sehr plausibel. Bei mir sind natürlich sowohl TSOP-Pin 
als auch DCF-Pin sauber auf Pullups gelegt, weil sie beide sonst offen 
wären. Aber ich kann ja jetzt nicht noch alle Fälle durchtesten, die 
durch Nichtbeachtung der entsprechenden Kapitel im Artikel auftreten 
könnten.

> Also: Hast du TSOP/DCF angeschlossen? evtl. hilft nich ein
> filterkondensator am tssop (zwischen + und masse).

Die Shields haben schon immer einen Tiefpass (R=100, C=4,7µF) am 
Vcc-Anschluss des TSOPs vorgesehen, wie es auch im Datenblatt empfohlen 
wird.

Autor: Mirco D. (bpoh_voodoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Wichtig wäre auch die Info, ob Du einen TSOP angeschlossen hast und wenn
> nicht, ob ein entsprechender Pullup als Ersatz angeschlossen ist. Das
> gleiche gilt für den DCF77-Pin.


Specs einen Beitrag über deinem ;-)

Wenn ich den LDR abklemme wird es aber schwierig mit der Repruduktion 
des Fehler, das kann dan etwas dauern.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mirco D. schrieb:
> "Vollausbau" (LDR, TSOP, DCF77, TEMP)

Zu DCF77 fällt mir noch ein, dass ich das irgendwann in 2.5 oder 2.6 von 
Pollen aus der Hauptschleife auf Pollen aus der Timer-ISR umgestellt 
habe.

Was passiert, wenn Du im Browser die automatische Helligkeitsregelung im 
Tab "LDR" komplett abschaltest? Bekommst Du dann trotzdem noch 
Störungen, z.B. im Tetris?

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mirco D. schrieb:
> Wenn ich den LDR abklemme wird es aber schwierig mit der Repruduktion
> des Fehler, das kann dan etwas dauern.

Lass ihn dran und schalte ihn bitte über Browser ab, wie oben 
beschrieben.

Autor: 0xef (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mirco D. schrieb:
> Leider immer noch keine Besserung.

Hallo Mirco,

ich hänge dir mal TESTVERSIONEN (aktuelle Version aus dem SVN: r90 
v2.6.2) an, bei denen der TSOP+DCF deaktiviert ist.
Kannst du bitte die für deine LED's passende Version testen und schauen, 
ob das Problem damit weg ist?

0xef

Autor: Mirco D. (bpoh_voodoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So LDR aus, Tetris zocken.
TSOP ist noch abgekleistert.
Es trat einmal in einer Minute auf, also sehr viel seltener.
Aber er ist noch da.

Autor: 0xef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Die Shields haben schon immer einen Tiefpass (R=100, C=4,7µF) am
> Vcc-Anschluss des TSOPs vorgesehen, wie es auch im Datenblatt empfohlen
> wird.

Hallo Frank,

das weiss ich. Aber ich hatte schonmal nen TSOP der 'gesponnen' hat.
10µF Filter C + 1K pulldown extra lösten das Problem.

0xef

Autor: Torsten Giese (wawibu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Casi239 schrieb:
> Hallo@  Torsten Giese (wawibu),
> ich hatte Dir eine PN geschrieben. Ich benötige für meine WC
> ein STM32 Nucleo Shield v3 OTA und den Zwischenboden (WC24h).
> Ich hoffe du kannst mir da etwas anbieten.
> Wegen der Front habe ich bereits UKW eine PN geschrieben.
> Gruß Carsten

Hi Carsten,

Du solltest eine Mail von mir erhalten haben.

Grüße,
Torsten

Autor: Mirco D. (bpoh_voodoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So geflasht und teste

Start Bootloader
Trying to enter bootloader mode...
Bootloader version: 2.2
Flash now unprotected
Trying to enter bootloader mode again...successful
Erasing flash (standard method)... successful!
Checking HEX file...
Check successful

File size: 146719
Flashing STM32...
........................................................................ 
........
........................................................................ 
........
............................................
Lines read: 3263
Pages flashed: 204
Bytes flashed: 52144
Flash write errors: 0
Flash successful
End Bootloader
Done. Please Reset your STM32 now!

Autor: Mirco D. (bpoh_voodoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So getestet, habe aber meine Zweifel das es mit dem flaschen geklappt 
hat, denn den LDR kann man immer noch aktivieren.
Sofern ich den auslasse hat es diesmal jedenfalls in 5 Minuten kein 
Auftreten gegeben.

PS:
Ach ich Dummerchen war ja auch TSOP+DCF und nicht LDR.

Wenn man den LDR anschaltet, ist er wieder da.

PPS: Bei einer Laufschrift (Datumsanzeige) habe ich das bis dato noch 
nicht beobachten können.

: Bearbeitet durch User
Autor: 0xef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mirco,

Ich glaube ich habs (oder ich lesen den Code falsch):
im ws2812.c wird ws2812_dma_status zu zeitig wieder auf 0 gesetzt.
(nämlich am beginn der Pause, nicht am Ende.)
eine geänderte Helligkeit triggert einen Refresh, welcher zu zeitig den 
nächsten DMA-transfer wieder anlaufen lässt.
Warum das pixelmuster in diesem Szenario genau 2 leds springt, verstehe 
ich aber nicht.

0xef

Ich versuch morgen mal eine Version mit doppeltem DMA-puffer zu bauen, 
heute wirds wahrscheinlich nicht mehr.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0xef schrieb:
> im ws2812.c wird ws2812_dma_status zu zeitig wieder auf 0 gesetzt.

Hm, das kann ich im Source nicht erkennen.

Hier mal der Source für den STM32F103:
    if (DMA_GetITStatus(WS2812_DMA_CHANNEL_IRQ_TC))                                 // check transfer complete interrupt flag
    {
        DMA_ClearITPendingBit (WS2812_DMA_CHANNEL_IRQ_TC);                          // reset flag

        if (current_dma_buf_pos < current_data_pause_len)
        {
            ws2812_setup_dma_buf (1);
        }
        else
        {
            DMA_Cmd (WS2812_DMA_STREAM, DISABLE);                                   // disable DMA
            ws2812_dma_status = 0;                                                  // set status to ready
        }
    }

Für den STM32F4xx ist die Routine entsprechend.
Dabei ist:

current_data_pause_len  = DATA_LEN(n_leds) + PAUSE_LEN;

Die Variable beschreibt also den kompletten Dateninhalt - inkl. Pause.

Erst wenn der Transfer-Complete-Interrupt gekommen ist und keine 
weiteren Bytes mehr übertragen werden müssen, wird ws2812_dma_status = 0 
gesetzt. Dann ist auch das letzte Bit raus. Oder habe ich da einen 
Denkfehler?

: Bearbeitet durch Moderator
Autor: 0xef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

Da hab ich den Code nicht richtig vestanden.
So wie du es beschreibst, wäre es richtig.
Aber ich komm einfach nicht drauf, was den DMA-IRQ lange genug 
blockieren könnte und durch den ldr-ausgelöst wird.

Die andere Idee war, dass evtl. eine Race-kondition nach dem berechnen 
der ersten 2 LED's den Zeiger neu initialisiert und damit die ersten 2 
leds nochmal berechnet. (ausgelöst duch 
ldr-änderungen->ws2812_refresh()).
Aber du hast das gut gegeneinander gelockt, soweit ich den code richtig 
lese.

Und: warum nur bei diesem user? warum hat sonst keiner das Problem?
(Oder meldet sich sonst keiner?)

0xef

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0xef schrieb:
> - evtl. doppelt sovile LED-Daten berechnen (Puffergröße verdoppeln ->
> mehr Zeit, bis es kritisch wird).

Ja, das wäre eine Möglichkeit. Bei der Vorausberechnung der Werte für 4 
LEDs statt 2 bleibt mehr Zeit für anderes.

> - Priorität des DMA-Interrupt erhöhen? bisher laufen ja alle auf
> gleicher Prio.

Das kann ich nicht nachvollziehen. Auszug aus ws2812.c:
    dma.DMA_Priority            = DMA_Priority_VeryHigh;                    // DMA_Priority_High;
...
    nvic.NVIC_IRQChannelPreemptionPriority  = 0;
    nvic.NVIC_IRQChannelSubPriority         = 0;


vs. Timer-Interrupt in main.c:
    nvic.NVIC_IRQChannelPreemptionPriority  = 0x0F;
    nvic.NVIC_IRQChannelSubPriority         = 0x0F;
]

Somit hat der Timer-Interrupt in main.c die niedrigste Priorität und 
diejenige in ws2812.c die höchste Priorität. So habe ich es jedenfalls 
verstanden.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0xef schrieb:
> Und: warum nur bei diesem user? warum hat sonst keiner das Problem?

Ich habe bisher 3 gezählt.

> (Oder meldet sich sonst keiner?)

Tja, das ist die Frage.

Autor: Mirco D. (bpoh_voodoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0xef schrieb:
> Warum das pixelmuster in diesem Szenario genau 2 leds springt, verstehe
> ich aber nicht.

Ähh, ich will euch ja nicht ärgern oder so, aber das sind nicht immer 2 
LEDs. Manchmal auch nur eine. Am häufigsten jedoch 2. Oder das ist nur 
zu schnell und ich erkenne nur das Verschieben von einer. Kann auch 
sein.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach längeren Recherchen habe ich einen Hinweis erhalten, der vielleicht 
was bringt. Und zwar soll man beim STM32 den Systick-Handler vor allen 
anderen Interrupts mit ihren Prioritäten initialisieren, sonst könnte 
das mit den Prioritäten-Steuerungen schiefgehen:

Bisher stand in main.c:
    timer2_init ();                                                         // initialize timer2 for IRMP, DCF77, EEPROM etc.
    delay_init (DELAY_RESOLUTION_5_US);                                     // initialize delay functions with granularity of 5 us

Ich habe das mal umgedreht:
    delay_init (DELAY_RESOLUTION_5_US);                                     // initialize delay functions with granularity of 5 us
    timer2_init ();                                                         // initialize timer2 for IRMP, DCF77, EEPROM etc.

da delay_init() den Systick-Handler verwendet.

@Mirco: Ich lade das gleich mal hoch, dann kannst Du das mal testen über 
OTA.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, die 2.6.3pre1 ist online im Update-Path test.
Einzige Änderung: Das Vertauschen der beiden obigen Befehle (s. 
vorhergehenden Beitrag).

Autor: Mirco D. (bpoh_voodoo)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Geflascht und getestet.

Hab mal ein Video gemacht.
Das wars leider noch nicht.

Autor: X. O. (overflow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
https://youtu.be/pB5v6Q6dTuE

Bei mir schauts mit 2.5.0 so aus. Vielleicht könnt ihr die Verschiebung 
ja irgendetwas zuordnen.
"Es ist halb neun" war die Uhrzeit.

Es ist ein STM32F103c8t6 mit Esp12f, in der Verschaltung ohne OTA. An 
den WS2812b ist ein Pull-up von 1.5kohm installiert. Sowie der Rest ist 
mehr oder weniger 1:1 das MiniDevBoard.

Woran es liegt würde mich natürlich schon interessieren. Mit der 2.4.0 
läuft die Uhr aber stabil, von daher kann ich auch damit leben, wenn 
wirklich nur ich betroffen bin.

Autor: Ph L. (filo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe die letzten Tage meine erste WordClock zusammengebaut und 
musste nun leider feststellen, dass ein Kurzschluss zwischen Ground und 
5V ist.
Ich vermute den Fehler entweder "im" Shield oder auf dem STM32. 
Sichtbare Lötstellen sind alle schon als Fehlerquelle ausgeschlossen.
Ist es denn allgemein möglich, dass Leiterbahnen im Shield irgendwo 
kurzgeschlossen sind?

Des Weiteren ist auch der 3.3V Pin auf dem STM32 in Kontakt mit Ground.
Aus diesem Grund denke ich, dass ich vielleicht den Microcontroller beim 
Löten gegrillt habe.
Würde mich über eine professionelle Einschätzung freuen.:)

Autor: Günter H. (gnter_h534)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ph L. schrieb:
> Würde mich über eine professionelle Einschätzung freuen.

Dafür wären (detailreiche) Bilder der Löt- und auch der Bestückungsseite 
der Platine hilfreich.

: Bearbeitet durch User
Autor: 0xef (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Somit hat der Timer-Interrupt in main.c die niedrigste Priorität und
> diejenige in ws2812.c die höchste Priorität.

Stimmt, das hatte ich überlesen. Allerdings haben die UART's auch prio0 
und damit die höchste...

Auch kann ich keinen Aufruf von NVIC_SetPriorityGrouping(0) aus 
core_cm3.h bzw. core_cm4.h finden. Nicht, dass hier 'spezielle' MCU's am 
werkeln sind, welche da ein explizites setzen brauchen.
(mehr info: 
http://infocenter.arm.com/help/topic/com.arm.doc.d... 
)

@Mirco, @X.O.:
Danke für die Videos, das hilft ungemein. Das Riesenboard von X.O. sieht 
hammergeil aus! (Ist da ein Original STM32F103c8t6 drauf? oder evtl ein 
GD32... clone?)
Anbei hier eine TESTVERSION-2.6.2 mit folgenden Modifikationen:
- ws2812 berechnet 2 LED's am Stück (Mehr 'Luft' fürs IRQ-handling)
- pause der ws2812 verdreifacht (ich möchte 'komische' LED's als Ursache 
ausschliessen)
- IRQ-Prio der UARTS auf 3 abgesenkt (von 0). Damit darf der DMA-IRQ 
diese unterbrechen.

Danke fürs testen und rückmelden.

0xef

Autor: 0xef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein kleiner Info-brocken:
Ich hab mir mal das errata vom stm32f103c8t6 angesehn und dabei zwar 
viel interessantes, aber nichts relevantes gefunden. Also einen 
(bekannten und vom Hersteller veröffentlichten) Hardwarebug auf 
MCU-Seite könnte man auszuschließen versucht sein.

0xef

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0xef schrieb:
> Stimmt, das hatte ich überlesen. Allerdings haben die UART's auch prio0
> und damit die höchste...

Stimmt. Aber das dürfte für das Phänomen keine Rolle spielen, denn durch 
eine Helligkeitsregelung (wie mit der Taschenlampe im Video) wird keine 
explizite UART-Kommunikation angestoßen.

Es wird aus main.c dann aufgerufen:
display_set_display_brightness (ldr_value, FALSE, FALSE);

wobei die beiden FALSE-Parameter dafür sorgen, dass die neue Helligkeit 
weder im EEPROM abgespeichert noch als Aktualisierungs-Info über den 
UART an den ESP8266 geschickt wird.

> - ws2812 berechnet 2 LED's am Stück (Mehr 'Luft' fürs IRQ-handling)

Sinnvoll. Du kannst mir gern die dafür notwendigen Änderungen schicken.

> - pause der ws2812 verdreifacht (ich möchte 'komische' LED's als Ursache
> ausschliessen)

Ok. Aber ich glaube nicht, dass dies hier das Problem ist.

> - IRQ-Prio der UARTS auf 3 abgesenkt (von 0). Damit darf der DMA-IRQ
> diese unterbrechen.

Das ist sinnvoll - auch wenn es sich hier kaum um den zu findenden 
Fehler dreht, s.o.

: Bearbeitet durch Moderator
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Es wird aus main.c dann aufgerufen:display_set_display_brightness
> (ldr_value, FALSE, FALSE);
>
> wobei die beiden FALSE-Parameter dafür sorgen, dass die neue Helligkeit
> weder im EEPROM abgespeichert noch als Aktualisierungs-Info über den
> UART an den ESP8266 geschickt wird.

Leider ist das nur die halbe Wahrheit. Bei größeren 
LDR-Helligkeitsschwankungen wird der aktuelle LDR-Wert doch an den 
ESP8266 geschickt, damit dieser die aktuelle LDR-Helligkeit im 
Webinterface anzeigen kann. Das ist wichtig für die Kalibrierung.

Auszug aus main.c:
            if (ldr_raw_value + 16 < last_ldr_raw_value || ldr_raw_value > last_ldr_raw_value + 16)         // difference greater than 16
            {
                debug_log_printf ("ldr: old raw brightnes: %d new raw brightness: %d\r\n", last_ldr_raw_value, ldr_raw_value);
                last_ldr_raw_value = ldr_raw_value;
                var_send_ldr_raw_value ();
            }

Den letzten Befehl "var_send_ldr_raw_value ();" könnte man testweise mal 
auskommentieren. Ich halte diesen für einen heißen Kandidaten. Die 
UART-Prio-Korrektur könnte dieses Problem also doch tatsächlich lösen.

P.S.
Die debug_log_printf()-Calls sind nur in der Debug-Variante aktiv, sonst 
werden sie durch den Preprocessor komplett eliminiert.

: Bearbeitet durch Moderator
Autor: Mirco D. (bpoh_voodoo)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
0xef schrieb:
> Danke fürs testen und rückmelden.


So habe deine neue Version drauf.
Jetzt hüpft es anders

Siehe Video

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mirco D. schrieb:
> So habe deine neue Version drauf.
> Jetzt hüpft es anders

Ja, komplett anders. Von einer Verschiebung um 1 oder 2 Stellen kann man 
hier gar nicht mehr reden.

Hattest Du mal meine Version von gestern abend probiert?

Beitrag "Re: WordClock mit WS2812"

(ich bin eher für moderate Tests, wenn man zuviel auf einmal ändert, 
dann weiß man am Ende gar nicht mehr, woran es gelegen hat).

Autor: Mirco D. (bpoh_voodoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
siehe

Beitrag "Re: WordClock mit WS2812"

das Video war von der 2.6.3pre1

: Bearbeitet durch User
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mirco D. schrieb:
> Beitrag "Re: WordClock mit WS2812"

Achso, das Video hatte ich mir zwar angeschaut, aber ich hatte nicht 
erkannt, dass das eine direkte Antwort auf meinen Beitrag war...

Ich habe im Update-Path "Test" mal eine Pre2-Version abgelegt. Diese 
unterdrückt das Übertragen der Helligkeit per UART zum ESP. Allerdings 
kann man dann den LDR nicht mehr kalibrieren... also nicht tun, bitte 
nur Testen ;-)

Autor: Mirco D. (bpoh_voodoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> also nicht tun, bitte
> nur Testen ;-)

Dein Wunsch ist mir Befehl.

Leider keine Änderung zur pre1.

Ergänzungsinfo LDR
Ich benutze den "A 906032" von Reichelt und habe entsprechend R1 = 10K 
eingesetzt. R2 ist unbestückt auf dem Shield.

: Bearbeitet durch User
Autor: Harald Leitner (howy075)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich lese jetzt schon eine zeit lang mit wegen des "springen" Problems.
Meine Uhr verhält sich bei jedem Minutenwechsel so wie im Video zu sehen 
ist.
Jetzt meine Frage, ist dieses Verhalten normal oder das von euch 
beschriebene Problem?
Bei jedem 5 Minuten Wechsel läuft die Animation normal durch.
Helligkeitssensor ist verbaut aber deaktiviert.
Es handelt sich um die wc12h-stm32f103-ws2812-grb.

Grüße
Howy

Autor: X. O. (overflow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0xef schrieb:
> @X.O.:
> Danke für die Videos, das hilft ungemein. Das Riesenboard von X.O. sieht
> hammergeil aus! (Ist da ein Original STM32F103c8t6 drauf? oder evtl ein
> GD32... clone?)

Ja, es ist ein original STM.

Autor: Frank D. (frank512)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

nachdem meine Uhr lief, waren alle in der Familie begeistert.
Aber sie hat manchmal "Display" Fehler :-( (siehe Bild, sollte 
normalerweise alles in blau sein)

Man konnte durch aus und wieder ein den Fehler beheben, aber nun nicht 
mehr.

Leider habe ich keine Idee woran das liegen kann, bzw., wo ich mit der 
Suche ansetzen soll.

Hat jemand eine Idee?



Mein Version von der Uhr:
WordClock12h mit
STM32F103C8T6 Mini-Development Board
ESP8266
DS3231
als 3,3V Netzteil habe ich AMS1117LDO 800MA

: Bearbeitet durch User
Autor: Marco R. (majestick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank D.,
Hallo Harald,

habt ihr beide den ca. 1,8K PullUp Widerstand der LEDs eingebaut? 
Welches Board wird verwendet (Version)?

Aus eigener Erfahrung kann ich hier nur empfehlen, nochmals alle Masse 
Verbindungen der LEDs zu prüfen. Hatte erst vor 2 Tagen eine Uhr da, bei 
der an einer Minuten LED die GND Leitung vergessen wurde und der Fehler 
sah wie auf dem Bild von Frank D. aus.
Witziger Weise trat der Fehler auch nur bei bestimmten Farben auf.

Möglich wäre aber auch eine defekte LED, hier z.B. das T, da in den 
WS2812 das Signal in jeder LED aufbereitet und weitergeleitet wird, muss 
hier nur eine nicht ganz sauber arbeiten schon können Fehlfarben und 
Sprünge möglich sein. Und leider musste ich feststellen das die 
aktuellen LEDs aus China nicht mehr so gut laufen, wie die die ich vor 
ungefähr 1,5 Jahren bestellt habe. Sprich die LED ausfälle häufen sich. 
Im Gegensatz zu meiner ersten Uhr die immer noch an der Wand hängt und 
nie wieder angefasst werden musste.

Ich kann euch hier nur empfehlen mal nur Teile des LED Streifens zu 
benutzen und den Display Test öfters laufen zu lassen.

Viel Erfolg

Gruß
Marco

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mittlerweile glaube ich auch, dass der Fehler nicht in der Software zu 
finden ist. Ich habe mittlerweile von vielen Leuten per Mail die 
Mitteilung bekommen, dass die aktuelle Version bei ihnen stabil läuft. 
Auch bei mir ist das Springen der Buchstaben nicht im geringsten 
reproduzierbar.

Außerdem haben 0xef und ich hier mehrere Testversionen bereitgestellt, 
um
"verdächtige" Abschnitte in der Software abzuchecken. Sämtliche Tests 
waren nicht erfolgreich. Es konnte keine Ursache in der Software 
entdeckt werden. Zudem kann man annehmen, dass ein Software-Fehler bei 
allen auftritt und nicht bei einzelnen. Beim Shield v3 hat auch noch 
niemand einen derartigen Fehler (Springen der Buchstaben) gemeldet.

Daher nehme ich an, dass die Ursache eher im individuellen 
Hardware-Aufbau liegt.

Deswegen mal eine Checkliste:

1. Alle GND-Verbindungen sauber vorhanden?

2. Ist ein 1,8K (oder 1,5K) Pullup an DIN der ersten WS2812-LED?

3. Ist ein 220 Ohm Serienwiderstand zwischen dem Data-Pin und DIN der 
ersten WS2812-LED? Wenn ja, diesen bitte brücken.

4. Die Data-Leitung zu DIN sollte möglichst kurz gehalten (max. 30-40cm) 
werden. Je kürzer, desto besser.

5. Die Data-Leitung sollte nicht in unmittelbarer Nachbarschaft zu 
anderen Datenleitungen wie LDR, TSOP und DS18xxx geführt werden. Die 
Data-Leitung sollte auch zusammen mit GND mittels zweipoligem Kabel an 
die erste LED geführt werden. Ich persönlich verwende dafür ein 
2-poliges oder 3-poliges Flachbandkabel, indem ich einfach 2 Leitungen 
vom vorhandenen 16-pol. Flachbandkabel abtrenne. Beim 2-poligem Kabel 
verwende ich GND und Data, beim 3-poligem +5V, Data und GND dafür.

6. Das Netzteil zur Versorgung der Stripes sollte mindestens einen Strom 
von 4A leisten können. Die Versorgungsspannung der Stripes sollte 
mindestens in jeder zweiten Zeile neu eingespeist werden. Die 
Versorgungsspannung sollte auch sehr nahe an 5V (4,9V-5,1V) sein. 
Größere Abweichungen führen zu Fehlern. Am besten misst man die Spannung 
während des Display-Tests einmal am Anfang der LED-Kette und einmal am 
Ende. Bei zu großen Differenzen klappt das nicht mit der 
Zwischeneinspeisung der Spannung in jeder zweiten Zeile. Unbedingt 
überprüfen!

7. Wurden WS2812-LED-Stripes verwendet, auf denen auch 
Entkoppelkondensatoren für jede(!) LED verlötet sind? Es gibt durchaus 
China-Anbieter, welche weniger oder gar keine Entkoppelkondensatoren für 
ihre Stripes verwenden.

Autor: Harald Leitner (howy075)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Marco,
Also der Wiederstand ist verbaut, Board ist Version 3, also die neueste.
Verbindungen sind alle in ordnung, auch beim Displaytest leucchten alle 
Led's richtig.
Ich habe eine zweite uhr (zumindest die Elektronik) aufgebaut und dort 
ist der selbe "hüpfer" bei den minutenwechsel.
Software ist die aktuelle.
Hab von diesem auch ein Video gemacht.

Grüße
Howy

PS.: Die Uhr ist auch so der Hammer und ich danke allen die dazu 
beigetragen haben. Der kleine Bug stört mich jetzt auch nicht wirklich. 
Aber wäre halt noch eine steigerung wenn der auch noch beseitigt wäre.

Autor: 0xef (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
anbei eine TESTVERSION von v2.6.2:
- 9 LED's auf einmal berechnen statt einer.
  (wenn ich nicht komplett daneben liege, sollte also die erste Zeile 
einer WC24h nicht springen (der rest hoffentlich auch nicht))

Ich kuck gerade noch die Interrupts durch und lade dann eine Version mit 
deaktivierten Interrupts hoch. Ich möchte endlich wissen, wieso ich das 
Problem nicht reproduzieren kann und ob andere interrupts an dem Problem 
beteiligt sind.

0xef

Autor: Harald Leitner (howy075)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Mittlerweile glaube ich auch, dass der Fehler nicht in der Software zu
> finden ist. Ich habe mittlerweile von vielen Leuten per Mail die
> Mitteilung bekommen, dass die aktuelle Version bei ihnen stabil läuft.
> Auch bei mir ist das Springen der Buchstaben nicht im geringsten
> reproduzierbar.
>
> Außerdem haben 0xef und ich hier mehrere Testversionen bereitgestellt,
> um
> "verdächtige" Abschnitte in der Software abzuchecken. Sämtliche Tests
> waren nicht erfolgreich. Es konnte keine Ursache in der Software
> entdeckt werden. Zudem kann man annehmen, dass ein Software-Fehler bei
> allen auftritt und nicht bei einzelnen. Beim Shield v3 hat auch noch
> niemand einen derartigen Fehler (Springen der Buchstaben) gemeldet.
>
> Daher nehme ich an, dass die Ursache eher im individuellen
> Hardware-Aufbau liegt.
>
> Deswegen mal eine Checkliste:
>
> 1. Alle GND-Verbindungen sauber vorhanden?

Habe ich alle nachkontrolliert und sind in Ordnung

>
> 2. Ist ein 1,8K (oder 1,5K) Pullup an DIN der ersten WS2812-LED?

Ja ist bei beiden verbaut

>
> 3. Ist ein 220 Ohm Serienwiderstand zwischen dem Data-Pin und DIN der
> ersten WS2812-LED? Wenn ja, diesen bitte brücken.

Ist soviel ich herausgefunden habe beim Board V3 nicht vorgesehen

>
> 4. Die Data-Leitung zu DIN sollte möglichst kurz gehalten (max. 30-40cm)
> werden. Je kürzer, desto besser.

Gerade noch mal gekürzt, jetzt unter 30 cm
>
> 5. Die Data-Leitung sollte nicht in unmittelbarer Nachbarschaft zu
> anderen Datenleitungen wie LDR, TSOP und DS18xxx geführt werden. Die
> Data-Leitung sollte auch zusammen mit GND mittels zweipoligem Kabel an
> die erste LED geführt werden. Ich persönlich verwende dafür ein
> 2-poliges oder 3-poliges Flachbandkabel, indem ich einfach 2 Leitungen
> vom vorhandenen 16-pol. Flachbandkabel abtrenne. Beim 2-poligem Kabel
> verwende ich GND und Data, beim 3-poligem +5V, Data und GND dafür.

Bei meiner testversion kein LDR und kein Tsop und DS18xxx testweise 
direkt angelötet

>
> 6. Das Netzteil zur Versorgung der Stripes sollte mindestens einen Strom
> von 4A leisten können. Die Versorgungsspannung der Stripes sollte
> mindestens in jeder zweiten Zeile neu eingespeist werden. Die
> Versorgungsspannung sollte auch sehr nahe an 5V (4,9V-5,1V) sein.
> Größere Abweichungen führen zu Fehlern. Am besten misst man die Spannung
> während des Display-Tests einmal am Anfang der LED-Kette und einmal am
> Ende. Bei zu großen Differenzen klappt das nicht mit der
> Zwischeneinspeisung der Spannung in jeder zweiten Zeile. Unbedingt
> überprüfen!

Netzteil 10A
>
> 7. Wurden WS2812-LED-Stripes verwendet, auf denen auch
> Entkoppelkondensatoren für jede(!) LED verlötet sind? Es gibt durchaus
> China-Anbieter, welche weniger oder gar keine Entkoppelkondensatoren für
> ihre Stripes verwenden.

Jede LED hat einen kondensator.

Grüße
Harald

PS meine Konfiguration ist: wc12h-stm32f103-ws2812-grb mit Board V3
Nochmals herzlichen Dank an dich!

: Bearbeitet durch User
Autor: Marco R. (majestick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Harald,

wie werden die LEDs mit Strom versorgt? In dem 2. Video sieht man das 
der 16pol Anschluss nicht verwendet wird.

Kannst du vielleicht einfach mal testhalber die Minuten LEDs rausnehmen 
und DOUT vom Board direkt an die erste LED des Strips an klemmen? bzw. 
dann auch mal erst beim 2. Strip anfangen?

Habe wie gesagt mittlerweile schon einige Fehlerbilder gesehen und bei 
mir waren es meist LEDs, die defekt waren.


Bei deiner Testversion sind kein LDR und TSOP angeschlossen, die 
alternativ Widerstände/ Schaltung ist drin? Sehe in dem Video die 
Drahtbrücke für den TSOP nicht und den R2 für den LDR.
Bzw. kann es im Video nicht wirklich erkennen.

Gruß
Marco