Minutengenaue 24 Stunden-Wortuhr - wer will mitbauen?

[Joachim B. (jar)]

Frank M. schrieb:
>> hast du noch mal nach der verschollenen PN geschaut?
>
> Gerade nochmal auf den Weg geschickt.

das war nur die VorVor PN und keine bessere Antwort

ich weiss ja das ich dem Linker noch was mitteilen muss um im Bootsektor 
zu arbeiten, aber ich weiss nicht wie!

1. im Studio 4.18 compilen funktioniert, linken verschiebt das 
Textsegment nicht!
2. im Studio 4.18 mit externen makefile arbeiten klappt auch nicht.

ich frage mich aber ob ich micht mit weiterem Aufwand einarbeiten soll, 
ob das lohnt?

Optiboot mit 1 Mbps funktioniert, meinen die wirklich 100kByte/s ? kommt 
mir langsamer vor, nachgemessen habe ich noch nie 20kB Code brauchen 
aber trotzdem 20s oder mehr gefühlt.

Die Umrüstung zu 18,432MHz würde ja nur die serielle Schnitte zur 
virtuellen Com von 38kBd zu 230kBd mit Nullfehler beschleunigen 
(theoretisch)

Herbert P. schrieb:
> Ich brauche keine WLAN-Anbindung (es muss doch eine vernünftige, präzise
> RTC geben

hmm ich grübel gerade in meinem RTC Code, der DS3231 ist ja der bessere 
aber auch der hat Probleme mit der Temperatur, steht auf der Heizung 
(genauer auf der Fensterbank und drunter ist die Heizung) und läuft 
gleich schneller, dafür ist eine Tempsensor eingebaut um das zu 
kompensieren, da müsste ich noch mal ran, aber mit zusaätzlich word 
Temperaturanzeige wäre auch nicht schlecht

Momentan habe ich gerade den Sekundenblink in einer Status LED 
aktiviert, immer schön in gleicher aktueller Farbe, die alle Minute auch 
umschaltet.

DCF77 Empfang immer noch mies, nun kommt bald wlan ran.

[Herbert P. (herb3472)]

Joachim B. schrieb:
> hmm ich grübel gerade in meinem RTC Code, der DS3231 ist ja der bessere
> aber auch der hat Probleme mit der Temperatur, steht auf der Heizung
> (genauer auf der Fensterbank und drunter ist die Heizung) und läuft
> gleich schneller, dafür ist eine Tempsensor eingebaut um das zu
> kompensieren, da müsste ich noch mal ran, aber mit zusaätzlich word
> Temperaturanzeige wäre auch nicht schlecht

Was ich nicht verstehe: es gibt jede Menge Billigsdorfer-Digitaluhren, 
Uhrenradios, Wecker etc., die alle mehr oder weniger genau gehen,ohne 
dass man sie jede Woche nachstellen muss. Was ist also das Problem der 
RTC-Module?

Temperatursensor: was, wenn man das RTC-Werkel thermisch isoliert in ein 
kleines Gehäuse einpackt und thermostatgeregelt elektrisch beheizt?

[Joachim B. (jar)]

Herbert P. schrieb:
> Temperatursensor: was, wenn man das RTC-Werkel thermisch

Joachim B. schrieb:
> hmm ich grübel gerade in meinem RTC Code,

gemach gemach, das bekomme ich auch noch gelöst, denke es liegt noch am 
code.

Weil ich die Uhrzeit aus der Compilezeit ableite weil DCF77 und wlan 
noch nicht läuft wird die RTC immer zu spät gestellt, Lade und 
Speicherzeiten zum Arduino.

Jetzt läuft der Sekundenblink in der aktuellen Uhrfarbe, 200ms on -> off 
bis zur nächsten Sekunde.

BTW wir sprachen über die Status LED Buchstaben

N NTP in sync
D DCF77 in sync
I IR Quittungsblink
bleibt noch

S für Sekundenblink ?

momentan stürzt das portierte Arduino m328p Code zu 1284p nicht mehr ab, 
jetzt muss der LED Stripe ran und dann wlan und DCF

was Torsten schon erwähnte, Farbfading von Minute zu Minute würde mir 
auch gefallen, jetzt schalte ich alle Minute die Farbe hart um, sieht 
auch gut aus.

[Herbert P. (herb3472)]

Joachim B. schrieb:
> S für Sekundenblink ?

Halte ich grundsätzlich für eine gute Idee - die Frage ist lediglich, 
wie es sich optisch macht, dass die LED nicht in der Mitte ist (man 
könnte evtl. auch ein Nightrider-Lauflicht machen, solange die anderen 
LEDs nichts Besseres zu tun haben), und ob die dauernde Blinkerei nicht 
vielleicht auf die Dauer störend wirkt.

[Joachim B. (jar)]

Herbert P. schrieb:
> Halte ich grundsätzlich für eine gute Idee - die Frage ist lediglich,
> wie es sich optisch macht, dass die LED nicht in der Mitte ist

nun ja darüber kann man reden, kann auch abgeschaltet werden, mir 
gefällts (beruhigend und ist ein Lebenszeichen, man schaut ja nicht 
immer hin)

nun läuft auch der Lichtsensor in % am m1284p im Wohnzommer aktuell 
Wolke grad vor 52% mit LED Strahler beleuchtet komme ich auf 93% 
entspricht direkter Sonneneinstrahlung, mit der Hand abgedunkelt, TV 
dunkel komme ich auf 7-10% das sollte genügen um die Uhr passend zu 
dimmen.

ToDo

IRMP reinbauen
DCF77 (trotzdem)
wlan
LED Stripe ansteuern

nun aber zum Kaffee zu meiner Oma, sie ist vor dem Nikolaus 95 geworden.

[Herbert P. (herb3472)]

Joachim B. schrieb:
> nun läuft auch der Lichtsensor in % am m1284p im Wohnzommer aktuell
> Wolke grad vor 52% mit LED Strahler beleuchtet komme ich auf 93%
> entspricht direkter Sonneneinstrahlung, mit der Hand abgedunkelt, TV
> dunkel komme ich auf 7-10% das sollte genügen um die Uhr passend zu
> dimmen.

Das klingt ja vielversprechend - besser als ich erwartet hatte! :-)

[Torsten C. (torsten_c)]

Herbert P. schrieb:
> es gibt jede Menge Billigsdorfer-Digitaluhren,
> Uhrenradios, Wecker etc., die alle mehr oder weniger genau gehen

Die haben m.W. alle einen verstellbaren Ziehkondensator^^.

Ich war als Kind mal auf einem Werbe-Stand der Firma Timex. Die haben 
den Deckel meinen Tchibo-Billiguhr geöffnet, sie auf ein Kalibrier-Gerät 
gelegt und mit einem kleinen Schraubendreher mit wenigen Handgriffen so 
genau eingestellt, dass sie mehrere Wochen auf eine Sekunde genau ging.

Sie SW Lösung (Dauer der letzten Sekunde ändern) finde ich praktischer.

Die Armbanduhr ging natürlich auch nur dann genau, wenn sie am Arm immer 
26°C hatte. Daher der Temperatursensor. Aber im Wohnzimmer hat ma ja 
auch recht konstante Temperaturen. Eine Temperaturkompensation ist daher 
m.E. gar nicht nötig.

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Sie SW Lösung (Dauer der letzten Sekunde ändern) finde ich praktischer.

  http://www.mikrocontroller.net/articles/AVR_-_Die_genaue_Sekunde_/_RTC

Hier wird so etwas gemacht.

[Herbert P. (herb3472)]

Frank M. schrieb:
> Torsten C. schrieb:
>> Sie SW Lösung (Dauer der letzten Sekunde ändern) finde ich praktischer.

Klar ist diese Lösung praktischer. Gefällt mir auch besser. 
Problematisch wird die Sache nur dann, wenn man die Uhr dem Designer 
Hubert schenkt, der zwar auf dem Mac supertolle Entwürfe macht, aber von 
Computern technisch keine Ahnung hat und 200 km weit weg wohnt. Oder der 
Cousine Denise, die ihren Computer nur für Facebook und zum Bestellen 
bei Zalando verwendet.

[Joachim B. (jar)]

Herbert P. schrieb:
> Klar ist diese Lösung praktischer. Gefällt mir auch besser.

dann machen wir es doch automatisiert rein

DCF77 Empfang ist ja ehe vorgesehen und wer keine Probleme hat nutzt den 
und lässt die RTC nachstellen, ich denke optimal in der Nacht von 3-4 
Uhr da schlafen die meisten und Zeitsprünge stören nicht.
Der Atmel oder jeder andere kann die nachlaufende RTC selber überwachen 
und nachstellen

wlan mit NTP ist ja auch möglich

Herbert P. schrieb:
> Problematisch wird die Sache nur dann, wenn man die Uhr dem Designer
> Hubert schenkt, der zwar auf dem Mac supertolle Entwürfe macht, aber von
> Computern technisch keine Ahnung hat und 200 km weit weg wohnt.

da hätte ich noch keine Idee wie man SSID und PW reinbekommt, wir können 
es ja im Quellcode hinterlegen, in der Arduino Ide gibt es auch die 
Möglichkeit von SerialInput, also über die Schnittstelle am PC im 
Terminal SSID und PW einzugeben und im EEPROM zu speichern, geht auch 
per RDP oder VNC wie man Onkel Hubert auch den Mauscusor führen würde 
per Fernsitzung, Bedingung er kann die Uhr anstecken am PC, notfalls 
muss er den Schenkenden einladen, mit Flugticket und Unterkunft und 
Bewirtung, bei meinem Freund 300km entfernt klappt das :-) (OK die fahre 
ich eher)

[Charly B. (charly)]

Mann mann mann,

macht ihr das so kompliziert.....
beim stellen der Uhr wird die gestellte Zeit u. Datum im EE
abgelegt, beim naechsten stellen der Uhr kann man die diff.
zw. ist und soll errechen und ein 'korrekturfaktor' ebenso
im EE hinterlegen. So kann zb. auch ein 'feintuning' erfolgen
indem die Uhr nach einem Tag, dann nach einer Woche, nach
einem Monat usw. nachgestellt wird und so der korrekturfaktor
immer genauer wird

vlG
Charly

[Holger W. (holgerw)]

Joachim B. schrieb:
> a hätte ich noch keine Idee wie man SSID und PW reinbekommt, wir können
> es ja im Quellcode hinterlegen,

Wenn der ESP keine Verbindung bekommt schickt man ihn in den Accesspoint 
Mode. Dann kann man sich damit connecten und die Parameter z.b. per URL 
eingeben.
Holger

[Torsten C. (torsten_c)]

Herbert P. schrieb:
> Tja, mein Problem wird sein, das Ganze für meinen Bedarf abzuspecken.
> Ich brauche keine WLAN-Anbindung

Für "ohne WLAN" und "ohne DCF77" und "Cousine Denise" hat Charly meines 
Erachtens die pragmatischste Lösung: "Beim nächsten Stellen der Uhr kann 
man die Differenz zwischen ist und soll errechen und einen 
'Letzte-Sekunde-Offset' im EEPROM hinterlegen."^^

Für "mit WLAN" ginge auch ein Remote-Service, aber das lassen wir 
lieber, das würde lange Diskussionen bringen.

Das "Abspecken" sollte durch eine Art "config.h" kein Problem sein. Das 
ist bei mir berücksichtigt.

Bei CoIDE (und den meisten anderen IDEs) werden die in "config.h" 
ausgeschalteten Teile im Code grau hinterlegt. Man kann sie dann auch 
einfach löschen, wenn man will.

@Frank: Wegen der anderen LEDs habe ich bisher nur versucht, die uart2.h 
von Dir zu übernehmen. Mir bleibt nur UART3 und die Lib läuft über DMA. 
DMA hat auch Nachteile, aber egal. Kompatibel ist aktuell nur 
"uart3_init()". Meine uart3.h sieht im Moment so aus:

// Konsens
extern void    uart3_init (uint32_t baudrate);
extern void    uart3_putc (uint8_t);         // noch nicht implementiert
extern uint8_t uart3_getc (void);            // noch nicht implementiert, blockiert ggf. CPU
extern uint8_t uart3_poll (uint8_t *);       // noch nicht implementiert
extern void    uart3_flush ();               // noch nicht implementiert, blockiert CPU bis TX-Puffer leer
extern int     uart3_read (char *, int);     // noch nicht implementiert, blockiert CPU bis genügend Zeichen empfangen
extern int     uart3_write (char *, int);    // noch nicht implementiert, kann auch \000 übertragen, warum keine void-Rückgabe?

// neu
extern int     uart3_write0 (const char *);  // überträgt 0-terminierten String
extern int     uart3_readAll (char *, int);  // liest alle Zeichen aus Puffer, maximal so viele wie angegeben
extern int     uart3_countRX();              // Anzahl der Zeichen im RX-Puffer
extern bool    uart3_newChar();              // true, wenn seit dem letzten Aufruf von newChar() mindestens ein weiteres Zeichen empfangen worden ist
extern int     uart3_FindLF();               // liefert die Position des ersten \n im Puffer zurück

Verbesserungsvorschläge sind willkommen.

[Joachim B. (jar)]

Charly B. schrieb:
> Mann mann mann,
>
> macht ihr das so kompliziert.....

weil wir laut denken?
störts dich denn?

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Hier wird so etwas gemacht.

Schaue ich mir an, bevor ich was anderes implementiere. Danke. :-)

Joachim B. schrieb:
> weil wir laut denken?

Gerade das ist doch produktiv! Ich finde das gut!

Gelebte "Konstruktive Streitkultur" (Wikipedia) ist produktiver als 
"Recht haben wollen".

[Torsten C. (torsten_c)]

Holger W. schrieb:
> Wenn der ESP keine Verbindung bekommt schickt man ihn in den Accesspoint
> Mode. Dann kann man sich damit connecten und die Parameter z.b. per URL
> eingeben.

Genau so oder so ähnlich wäre das bei jedem kommerziellen Produkt.

Viele machen das auch über einen "Longpress", dann blinkt für ca. 120 
Sekunden eine LED und man kann sich in dieser Zeit mit dem ESP verbinden 
und bekommt im Browser eine Konfig-Seite angezeigt.

Diese Seite würde dann alle Netze aus "AT+CWLAP" in einem 
Dropdown-Listenfeld zur Auswahl stellen und ein Eingabefeld für das 
Passwort haben.

Ohne https bitte!

Bis das jemand fertig hat (mal sehen, viellicht ist mal wieder jemand 
schneller als ich), würde ich das Passwort im Code hardcodiert 
hinterlegen.

Aktuell bastel ich gerade eine API für den ESP und einen kleinen 
Webserver. Erstmal für NetIO, aber später auch gern für eine 
Konfig-Seite.

Wenn alles so klappt, wie es soll, sollte der Webserver auch auf einem 
ATMEGA laufen.

[Charly B. (charly)]

Joachim B. schrieb:
> Charly B. schrieb:
>> Mann mann mann,
>>
>> macht ihr das so kompliziert.....
>
> weil wir laut denken?
> störts dich denn?

das laute denken nicht, aber die unnoetigen Nonsenskomentare schon!

ich wollte damit nur eine Moeglichkeit schildern wie man es
event. auch machen kann. Ein Komentar" ist gut so", oder "ist
nicht gut weil.... " ist/waehre ok, aber.....

Also sorry das ich gestoert habe!, soll nicht wieder vorkommen

[Torsten C. (torsten_c)]

Charly B. schrieb:
> Also sorry das ich gestoert habe!, soll nicht wieder vorkommen

Das war hoffentlich nicht Dein Ernst. Wie gesagt: "Konstruktive 
Streitkultur" (Wikipedia) ist gut!

Lass Dich Durch Nonsenskomentare nicht stören. Manchmal sind es nur 
Missverständnisse.

PS:
> … sollte der Webserver auch auf einem ATMEGA laufen, …
… daher hätte ich gern einheitliche *.h-Dateien (Schnittstellen).

[Torsten C. (torsten_c)]

Wer arbeitet jetzt eigentlich gerade an was?

Frank scheint mit der WS2812/STM32-Variante "fertig" zu sein, bis auf:
* Speichern in externem EEPROM
* Anbindung der DS3231-RTC
* Farbprogramme

Ich bin noch mit der "Fernsteuerung" per WLAN und der Ansteuerung der 
LED-Display-Module per DMA beschäftigt, das wird aber 'ne 16x16-Matrix, 
klar, oder? Dananch könnte ich vielleicht oder hoffentlich den Rest von 
Frank übernehmen.

Gibt es sonst noch Aktivitäten, die wir vielleicht synchronisieren 
sollten? Nicht, dass der Eindruck entsteht, dass hier jeder "sein 
eigenes Ding" machen will - falls es nicht so ist. ;-)

Irgendwie steht bei mir seit einer Stunde ein ganz merkwürdiger Index im 
UART-Ringbuffer-Tail-Pointer, obwohl UART und DMA seit zwei Tagen 
problemlos funktioniert haben. Ich blicke gerade nicht durch und glaube 
ich mache erstmal mit LED-DMA weiter und schlafe 'ne Nacht drüber.

[Torsten C. (torsten_c)]

Torsten C. schrieb:
> Irgendwie steht bei mir seit einer Stunde ein ganz merkwürdiger Index im
> UART-Ringbuffer-Tail-Pointer

Aha: Der ESP antwortet mit "busy now\r\n". :-(

Wahrscheinkich macht es keinen Sinn, weiter über dieses 
AT-Kommando-Interface mit Suche nach "\r\n+IPD," und

printf("AT+CIPSEND%d,%d\r", Channel, TotalLength);

usw. weiter zu machen und Martin hat die richtige Entscheidung 
getroffen, mit "I’ve decided not to use external MCU and utilize the 
chip itself…":

http://harizanov.com/2014/11/esp8266-powered-web-server-led-control-dht22-temperaturehumidity-sensor-reading/

Mist! Sackgasse?

[Holger W. (holgerw)]

Welche Version hat der ESP ?
Mit der 9.2.2 läuft es recht gut. Ich denke aber das es für einen 
Nachbau ohnehin notwendig ist die Firmware auf einen bestimmten Stand zu 
bringen, bei einem Kauf ist das wohl eher Zufall.

Holger

[Torsten C. (torsten_c)]

Holger W. schrieb:
> Welche Version hat der ESP ?

AT+GMR => 00160901

Holger W. schrieb:
> Mit der 9.2.2 läuft es recht gut.

Und wie heißt dann meine? 16.9.1?

Dass meine Version schlecht läuft, kann ich nicht sagen. Mit diesem 
AT-Befehlssatz und dem internen Timing im ESP ist es halt nur so, wie 
den ganzen Flur durch den Briefschlitz zu tapezieren.

http://www.witz-des-tages.de/berufe/der-malermeister-im-arbeitsamt/

Holger W. schrieb:
> Ich denke aber das es für einen
> Nachbau ohnehin notwendig ist die Firmware auf einen bestimmten Stand zu
> bringen, bei einem Kauf ist das wohl eher Zufall.

Mein erster Ansatz war, dass man mit dem Standard-Befehlssatz auskommt 
und alles weitere abwärts-kompatibel ist. Ich bin auch schon kurz davor, 
das alles fertig ist. Aber das dachte ich vor sechs Stunden auch schon 
fast.

Wie sind denn die anderen Meinungen aus der WLAN-Fraktion? HTTP-Server 
über Standard-AT-Befehlssatz oder über Firmware mit eingebautem Server 
wie bei Martin^^?

Wie gesagt: Einmal drüber schlafen, mal sehen, heute mache ich nur noch 
an der LED-Matrix per SPI, USART und DMA weiter.

[Joachim B. (jar)]

Torsten C. schrieb:
> Wer arbeitet jetzt eigentlich gerade an was?

ich bin immer noch bei "meinen" Code von Arduino Nano328p auf 
mighty1284p zu bringen, sind einige Timer und Prozzi Anpassungen 
(Adressen)

Ab und an verzettel ich mich in den Registern und es geht 1 Schritt 
zurück.

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> ich bin immer noch bei "meinen" Code von Arduino Nano328p auf
> mighty1284p zu bringen

Das klingt für mich nach den besten Vorausstzungen dafür (z.B. erstmal 
mit #define) eine Code zu bauen, der auf beiden Prozessoren läuft.

Ich finde es erstrebenswert, dass wir einen gemeinsamen Code haben, 
der sich für ARM und AVR compilieren lässt.

Ich hatte das mal mit AtmelStudio und

#ifdef _AVR_IOM2560_H_
// …
#ifdef _AVR_IOM328P_H_
// …

gemacht. Ging super!

… oder zumindest gemeinsame .h-Datei-Schnittstellen.

@Joachim: Wie siehst Du das?

@All: Wie seht Ihr das?

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Frank scheint mit der WS2812/STM32-Variante "fertig" zu sein, bis auf:
> * Speichern in externem EEPROM
> * Anbindung der DS3231-RTC
> * Farbprogramme

Ja, diese Punkte will ich auch selber fertigmachen.

> Ich bin noch mit der "Fernsteuerung" per WLAN und der Ansteuerung der
> LED-Display-Module per DMA beschäftigt, das wird aber 'ne 16x16-Matrix,
> klar, oder?

Da ich an 16x16 nicht interessiert bin, wäre es schön, wenn Du das 
übernehmen könntest.

> Dananch könnte ich vielleicht oder hoffentlich den Rest von
> Frank übernehmen.

Das ist nicht notwendig, das übernehme ich selber.

Es wäre von Vorteil, wenn Du Dich erstmal auf einige wenige Dinge 
konzentrieren würdest, statt immer wieder neue Baustellen gleichzeitig 
aufzureissen. Die Konsequenz wäre nämlich, dass nix fertig wird, weil Du 
fortwährend auf mehreren Hochzeiten tanzt.

> Gibt es sonst noch Aktivitäten, die wir vielleicht synchronisieren
> sollten? Nicht, dass der Eindruck entsteht, dass hier jeder "sein
> eigenes Ding" machen will - falls es nicht so ist. ;-)

Wie gesagt: Mein Source ist offen und kann von jedem wiederverwendet 
werden. Ich glaube auch, dass meine Strukturierung des Sources dieses 
möglich macht, auch was andere µCs wie ATmega angeht. Lediglich die 
Low-Level-Sachen müssen neu geschrieben werden.

> Irgendwie steht bei mir seit einer Stunde ein ganz merkwürdiger Index im
> UART-Ringbuffer-Tail-Pointer, obwohl UART und DMA seit zwei Tagen
> problemlos funktioniert haben.

Wenn da ein Problem ist: "Seit zwei Tagen" ist nicht unbedingt ein 
Kriterium dafür, dass Deine Ringbuffer-Funktionen korrekt arbeiten. 
Schau Dir meine an, die sind seit Jahren erprobt und laufen stabil.

Torsten C. schrieb:
> Aha: Der ESP antwortet mit "busy now\r\n". :-(

Kenne ich, habe ich desöfteren mit meinen Tests gehabt. Dagegen ist kein 
Kraut gewachsen ausser PowerOff des WLAN-Moduls. Ziemlich ätzend das 
Ding.

Nach vielen Versuchen habe ich es dann geschafft, mit den 
Timeout-Routinen (siehe mein STM32-Projekt) die Kommunikation so stabil 
zu bekommen, dass dieses Problem erst gar nicht mehr auftritt.

> Wahrscheinkich macht es keinen Sinn, weiter über dieses
> AT-Kommando-Interface mit Suche nach "\r\n+IPD,"
> undprintf("AT+CIPSEND%d,%d\r", Channel, TotalLength);usw. weiter zu
> machen und Martin hat die richtige Entscheidung
> getroffen, mit "I’ve decided not to use external MCU and utilize the
> chip itself…":

Noch 'ne Baustelle aufreissen? Ich glaube, Du verzettelst Dich...

> Mist! Sackgasse?

Die Firmware des ESP8266 ist ein richtiger Graus, da waren wohl Leute 
dran, die keine Ahnung von Kommunikationsprotokollen haben. Die 
Antworten auf AT-Befehle sind absolut uneinheitlich. Man hat überhaupt 
keine Chance, Fehler abzufangen und darauf korrekt zu reagieren. Die 
Modems der 80er Jahre waren da um Längen besser. Aber offenbar kennt die 
keiner mehr, obwohl sie den AT-Befehlssatz nachahmen wollen :-(

Torsten C. schrieb:
> Mein erster Ansatz war, dass man mit dem Standard-Befehlssatz auskommt
> und alles weitere abwärts-kompatibel ist. Ich bin auch schon kurz davor,
> das alles fertig ist. Aber das dachte ich vor sechs Stunden auch schon
> fast.

Es wäre schön, wenn man mit dem Standard auskommt. Man kann einem 
Otto-Normal-Anwender nicht zumuten, dass man ein ESP8266 erstmal flashen 
muss. Aus diesem Grunde bin ich von UDP auf TCP umgestiegen.

> Wie sind denn die anderen Meinungen aus der WLAN-Fraktion? HTTP-Server
> über Standard-AT-Befehlssatz oder über Firmware mit eingebautem Server
> wie bei Martin^^?

Meinst Du nicht auch, dass ein HTTP-Server eher eine Kanone auf Spatzen 
ist?`Das geht einfacher.

Torsten C. schrieb:
> Ich finde es erstrebenswert, dass wir einen gemeinsamen Code haben,
> der sich für ARM und AVR compilieren lässt.

Ja, spricht ja nichts dagegen. Die Unterschiede kann man mit

#if defined (STM32F4XXX)
   Hier STM32-F4-Code (Disco und Nucleo)
#elif defined (STM32F1XXX)
   Hier STM32-F1-Code (Deine China-Module)
#elif defined (__AVR_ATmega2560__)
   Hier ATmega-2560-Code
#else
   #error Unknown Target Controller
#endif

erschlagen. Läuft im IRMP auch so, welcher u.a. AVR, PIC, XMC und 
STM32 unterstützt.

> … oder zumindest gemeinsame .h-Datei-Schnittstellen.

Das ist zuwenig. Was soll das bringen?

[Joachim B. (jar)]

Torsten C. schrieb:
> Das klingt für mich nach den besten Vorausstzungen dafür (z.B. erstmal
> mit #define) eine Code zu bauen, der auf beiden Prozessoren läuft.

Torsten C. schrieb:
> dass wir einen gemeinsamen Code haben,
> der sich für ARM und AVR compilieren lässt.

Torsten C. schrieb:
> @Joachim: Wie siehst Du das?

ich sehe das genauso, bin ja dabei den Code mit #defines auf

Arduino IDE > 0 und und ab 105 , sowie
pur Atmel AVR Studio zu bringen

den Rest für STM müssen andere.

aber da Frank schon angekündigt hatte eigenen code zu verarbeiten weiss 
ich nicht so recht, ich mache wie gesagt oberes erst mal weiter.

Wer was wie übernimmt ist mir dann egal, ich denke jeder hat andere 
Voraussetzungen, ich meine I2C Tastatur und mein Nokia Display was 
vermutlich hinter der Uhr landet, dadurch (und durch meine ineffektive 
Proggerei) wird der Code größer und ich nutze meinen Arduino Clone 
m1284p.

Nicht jeder braucht das, deswegen würde vermutlich ein m328p oder ein 
m32 reichen, aber das kommt später welche HW Basis auf dei Platine soll

Arduino, purer Atmel oder STM

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Mein Source ist offen und kann von jedem wiederverwendet werden.
>
> Torsten C. schrieb:
>> Dananch könnte ich vielleicht oder hoffentlich den Rest von
>> Frank übernehmen.
>
> Das ist nicht notwendig, das übernehme ich selber.

Wie meinst Du das? Einerseits ist Dein Code offen und kann von mir 
verwendet werden, andererseits ist das nicht notwendig? Was meinst Du 
mit "übernehme ich selber"?

> Es wäre von Vorteil, wenn Du Dich erstmal auf einige wenige Dinge
> konzentrieren würdest, statt immer wieder neue Baustellen gleichzeitig
> aufzureissen.

Ich konzentriere mich nur auf zwei Dinge: (1) Die Uhr per NetIO (o.Ä.) 
steuern und (2) die LED-Kacheln ansteuern: 2 x SPI-Slave und 1 x USART 
synchron als Master per DMA. Meinst Du "neue Baustellen aufreissen" 
wegen des Ringbuffers, oder wie?

Frank M. schrieb:
> Meinst Du nicht auch, dass ein HTTP-Server eher eine Kanone auf Spatzen
> ist? Das geht einfacher.

vom HTTP-Request werte ich nur die erste Zeile aus, also die URL. Im 
Response muss wenigstens so viel drin stehen, dass der Browser keinen 
Fehler meldet ("Die Seite kann nicht angezeigt werden."). Einfacher geht 
m.E. kaum, oder? "HTTP-Server" hört sich nach einem Monstrum an, aber 
mehr steckt m.E. nicht dahinter.

Frank M. schrieb:
> Schau Dir meine an, die sind seit Jahren erprobt und laufen stabil.

Mal sehen. Ich hatte den sportlichen Ehrgeiz, den UART-Ringbuffer per 
DMA laufen zu lassen. Vielleicht bleibe ich auch dabei. Oder spricht was 
dagegen?

[Herbert P. (herb3472)]

Torsten C. schrieb:
> Frank M. schrieb:
>> Mein Source ist offen und kann von jedem wiederverwendet werden.

Welcher Source ist bitte damit gemeint? Ich hab mir das wclock24h 
Zip-File heruntergladen und entpackt, aber mangels Dokumentation und 
Kommentaren kann ich damit nicht viel anfangen. Habe ich was übersehen, 
oder suche ich am falschen Fleck, oder wird da noch was nachgeliefert?

[Joachim B. (jar)]

Herbert P. schrieb:
> Habe ich was übersehen,
> oder suche ich am falschen Fleck, oder wird da noch was nachgeliefert?

da du ja auch Arduino machst bekommst du ja "meinen" Code wenn er fertig 
ist

oder brauchst du vorab was?

[Herbert P. (herb3472)]

Direkt brauchen tu ich vorab nix, aber interessieren würde es mich.

[Joachim B. (jar)]

Herbert P. schrieb:
> Direkt brauchen tu ich vorab nix, aber interessieren würde es
> mich.

kann dir was vom Testcode schicken,

Arduino

wordclock für m328p nanoV3

ws2812 Stripe Ansteuerung mit mighty1284p

brauche noch mal deine email per PN die habe ich nicht grad hier

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Wie meinst Du das? Einerseits ist Dein Code offen und kann von mir
> verwendet werden, andererseits ist das nicht notwendig? Was meinst Du
> mit "übernehme ich selber"?

Sorry, Missverständnis. Vergiss es ;-)

Herbert P. schrieb:
> Welcher Source ist bitte damit gemeint? Ich hab mir das wclock24h
> Zip-File heruntergladen und entpackt, aber mangels Dokumentation und
> Kommentaren kann ich damit nicht viel anfangen. Habe ich was übersehen,
> oder suche ich am falschen Fleck, oder wird da noch was nachgeliefert?

Dokumentation:

Eine Anleitung, wie das Programm zu bedienen ist, findest Du schon seit 
über einer Woche im Artikel:

      http://www.mikrocontroller.net/articles/WordClock24h#STM32F4_Discovery_Projekt

Diese Anleitung wird nach und nach ausgebaut, ist aber jetzt schon 
"enduser-tauglich", da alle notwendigen Schritte erklärt werden. Ich 
verstehe nicht, wo da was fehlt, um das Programm zum Laufen zu bewegen. 
Wo hapert es?

Und welche Kommentare vermisst Du im Source?

[Herbert P. (herb3472)]

Frank M. schrieb:
> Diese Anleitung wird nach und nach ausgebaut, ist aber jetzt schon
> "enduser-tauglich", da alle notwendigen Schritte erklärt werden. Ich
> verstehe nicht, wo da was fehlt, um das Programm zum Laufen zu bewegen.
> Wo hapert es?

Sorry, da ist mir offensichtlich im Vorweihnachtsstress etwas entgangen 
:-(

[Herbert P. (herb3472)]

Frage zum STM32:

Wieso benötigt man einen "ST-Link/V2 zum Flashen 
http://www.st.com/web/catalog/tools/FM146/CL1984/SC724/SS1677/PF251168";, 
wenn der beim Discovery Board lt. Beschreibung eh schon integriert ist? 
Oder hab' ich da was missverstanden?

[Torsten C. (torsten_c)]

Herbert P. schrieb:
> Oder hab' ich da was missverstanden?

Vielleicht, ist aber alles richtig, was Du sagst: Zum flashen benötigt 
man einen ST-Link/V2 und sowohl im Discovery als auch im Nucleo ist 
jeweils einer drin, also brauchst Du kein separates.

Es gibt Billig-Boards z.B. aus China für ca. 4€ ohne ST-Link/V2, die 
kannst Du mit dem ST-Link/V2 aus einem Discovery oder Nucleo 
programmieren, zu sehen links im Bild im 
Beitrag "24h-Wortuhr mit LED-Display-Matrix - Aufbau"

[Herbert P. (herb3472)]

Torsten C. schrieb:
> Vielleicht, ist aber alles richtig, was Du sagst: Zum flashen benötigt
> man einen ST-Link/V2 und sowohl im Discovery als auch im Nucleo ist
> jeweils einer drin, also brauchst Du kein separates.

> Es gibt Billig-Boards z.B. aus China für ca. 4€ ohne ST-Link/V2, die
> kannst Du mit dem ST-Link/V2 aus einem Discovery oder Nucleo
> programmieren, zu sehen links im Bild im
> Beitrag "24h-Wortuhr mit LED-Display-Matrix - Aufbau"

Zufällig habe ich mein Discovery Board nicht in China, sondern bei 
rs-components gekauft. Wer vom STM32F4 (noch) keine Ahnung hat, weiß 
auch nicht, dass es in China auch Boards ohne dieses Feature gibt (auf 
dem Foto ist das nicht unbedingt zu erkennen, und wer schaut da schon so 
genau hin?)

Jedenfalls habe ich mich Schritt für Schritt an die Anleitung im 
Wordclock24h Wiki gehalten und schön brav das Ding bestellt. Leider bin 
ich zu spät draufgekommen, dass das gar nicht notwendig war. 30 € beim 
Fenster rausgeschmissen. Na ja, vielleicht kann das Ding ja wer 
brauchen....

Wer auch immer für den Wiki-Eintrag "Software für Windows" 
verantwortlich zeichnet: es wäre nett, wenn da ein wenig mehr drin 
stehen würde als 4 unkommentierte Links. Wovon der ST-Link/V2 - Link 
ohne Zusatzinfo eigentlich problematisch ist, wenn jemand ein Original 
Disco-Board hat.

Warum ist eigentlich die CooCox Toolchain aus dem Rennen?

Und was haltet Ihr von Tilen Majerles Arbeiten?

http://stm32f4-discovery.com/2014/05/all-stm32f429-libraries-at-one-place/

Er scheint übrigens auch seine liebe Not mit dem ESP8266 zu haben:
"Parsing ESP8266EX modules is really unexpected thing. You never know 
what will come from these devices" :D

[Torsten C. (torsten_c)]

Herbert P. schrieb:
> "Parsing ESP8266EX modules is really unexpected thing. You never know
> what will come from these devices"

Auf Espressif’s web site ist ja der Firmware-Sourcecode, vielleicht kann 
ich das Verhalten daraus rekonstruieren? Ich befürchte, falls ich so 
tief einsteige, kann ich auch schon fast direkt die WC24h auf dem 
ESP8266 implementieren. ;-)

Herbert P. schrieb:
> Und was haltet Ihr von Tilen Majerles Arbeiten?

Mit fertigen Bibliotheken ist das immer so 'ne Sache: Wenn's 
Funktioniert ist's gut, wenn nicht, muss man den fremden Code verstehen, 
um den Fehler zu finden. Ich finde den Link gut, dann kann ich in der 
"tm_stm32f4_spi.c" z.B. mal schauen, was Tilen gemacht hat, z.B. wenn's 
bei mir mal nicht läuft. Ich bei fremden Bibliotheken, die ich nicht auf 
Anhieb verstehe, sehr skeptisch.

Ich brauche jetzt SPI mit 3 Bits (RGB) parallel. Ich schalte dazu drei 
SPIs paralell: Der erste (Blau) ist der Master, die anderen beiden (Grün 
+ Rot) laufen als Slave. Bei Blau + Grün (USART1 + SPI2) geht das auch 
schon per DMA. Bei Rot (SPI1) suche ich noch nach dem Fehler.

Hier hilft mir Tilen z.B. kaum weiter, er arbeitet immer mit:

spi.SPI_Direction = SPI_Direction_2Lines_FullDuplex;

Ich arbeite mit:

spi.SPI_Direction = SPI_Direction_1Line_Tx;

Jeder hat seine eigene Arbeitsweise. Ich bevorzuge: Ein großer 
Bildschirm, wo auch das Datenblatt drauf passt, links lesen und rechts 
programmieren.

[Joachim B. (jar)]

Torsten C. schrieb:
> Ich brauche jetzt SPI mit 3 Bits (RGB) parallel.

warum?

spi ist doch perfekt um die 3 Bytes hintereinander auf einer Strippe für 
die WS rauszujagen.........

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> spi ist doch perfekt um die 3 Bytes hintereinander auf einer Strippe für
> die WS rauszujagen...

Habe ich ja auch gesagt, aber Frank hat Timer genommen. WS2812 auf SPI 
mit DMA habe ich seit einem halben Jahr am Laufen, das ist nicht das 
Problem.

Ich arbeite momentan nicht an WS2812 (ist ja auch schon Fertig, wäre ja 
doppelt), sondern an den LED-Display-Modulen ("Kacheln", rechts im Bild 
^^). Die sind viel billiger als WS2812 und schon fertig im 
20x20mm²-Raster.

Die meisten haben aber 1/8-Scan und brauchen 6 Bit parallel (R1, G1, B1, 
R2, G2, B2). Eventuell nehme ich dafür deshalb ein "xmc4500 relax lite" 
für 10€, davon habe ich auch noch 2 Stück in der Bastelkiste. Die sind 
übrigens von der Bauhöhe die kleinsten von allen, da gar_keine 
Pin-Header bestückt sind.

Der xmc4500 kann nämlich 2 Bits und 4 Bits parallel auf SPI und 2 + 4 = 
6 für 1/8-Scan. Mal sehen.

Herbert P. schrieb:
> Warum ist eigentlich die CooCox Toolchain aus dem Rennen?

Irgend ein µC machte damit Ärger (siehe oben). Ich benutze seit über 
einem Jahr CooCOX und müsste auch erst umsteigen. Mal sehen.

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> spi ist doch perfekt um die 3 Bytes hintereinander auf einer Strippe für
> die WS rauszujagen.

Wahrscheinleich meintest Du das genau so wie folgt oder? Ich muss immer 
zwei Bits aus "RGBBuffer" in ein Byte des "FrameBuffer" packen:

int TagretPtr = 0;
uint8_t TempSrc;
union {
    uint32_t WordData;
    uint8_t BytesData[4];
} TempDst;
for (int index = 0; index < RGBBufferSize; ++index) {
    TempSrc = RGBBuffer.SingleBytes[index];
    TempDst.WordData = 0;
    for (int bitIndex = 0; bitIndex < 8; ++bitIndex) {
        TempDst.WordData <<= 4;
        if (TempSrc & 0x1) {
            TempDst.WordData |= 0b0000;
        } else {
            TempDst.WordData |= 0b1110;
        }
        TempSrc >>= 1;
        bitIndex += 1;
        TempDst.WordData <<= 4;
        if (TempSrc & 0x1) {
            TempDst.WordData |= 0b1000;
        } else {
            TempDst.WordData |= 0b1111;
        }
        TempSrc >>= 1;
    }
    FrameBufferRGB[TagretPtr++] = TempDst.BytesData[0];
    FrameBufferRGB[TagretPtr++] = TempDst.BytesData[1];
    FrameBufferRGB[TagretPtr++] = TempDst.BytesData[2];
    FrameBufferRGB[TagretPtr++] = TempDst.BytesData[3];
}

[Joachim B. (jar)]

Torsten C. schrieb:
> Wahrscheinleich meintest Du das genau so wie folgt oder? Ich muss immer
> zwei Bits aus "RGBBuffer" in ein Byte des "FrameBuffer" packen:

verstehe ich nicht

ich dachte an 8 Bit PWM pro Farbe und diese werden doch als 24 Bit in WS 
geschoben

also ein Array oder Struct anlegen RGB Byte und die per SPI Index für 
Index und damit Byte für Byte rausschieben, also pro Index 3 Byte 
hintereinander.

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> verstehe ich nicht

SPI = Clock (SCK) + Daten (MOSI)

Die WS2812 hat keinen Clock. Die braucht immer PWM:

* Logisch 1 ≈ 75% High und 25% Low => 0b1110;
* Logisch 0 ≈ 25% High und 75% Low => 0b1000;

Oben wird der USART statt SPI benutzt, daher sind das mit Start- und 
Stop-Bit zusammen immer 10 Bits und ich brauche einen Inverter, daher 
ist das Muster etwas anders.

Verstanden?

Torsten C. schrieb:
> Bei Rot (SPI1) suche ich noch nach dem Fehler.

So, ROT geht nun auch. Klassiker:

> RCC_APB1PeriphClockCmd(RCC_APB2Periph_SPI1, ENABLE);

Was stimmt da nicht? Richtig, es muss heißen:

> RCC_APB2PeriphClockCmd(RCC_APB2Periph_SPI1, ENABLE);

Ich bin ein Blindfisch!

24,67µs / Zeile (Bild) => Ein Frame dauert rund 400µs, nun kommen die 
Helligkeitsstufen dran, oder ich mache erstmal die Verknüpfung mit 
tables.h.

[Torsten C. (torsten_c)]

Torsten C. schrieb:
> Oben wird der USART statt SPI benutzt.

Das hat den Grund, dass sich die Baudrate beim STM32-USART exakt 
einstellen läßt, also mit "Mantissa" und "Fraction". Beim SPI geht das 
nur in 2er-Potenzen. Bei SPI müsste man den Master-Clock anpassen, um 
das exakte Timing zu erreichen.

Im Artikel WS2812 Ansteuerung ist das Timing näher beschrieben, oder 
noch genauer bei Tim (cpldcpu):

https://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/

> * A “0” can be encoded with a pulse as short as 62.5 ns, but should
>   not be longer than ~500 ns
> * A “1” can be encoded with pulses almost as long as the total cycle
>   time, but it should not be shorter than ~625 ns

Also sollte ein Puls von (1250ns/3 = 417ns) für 'ne "0" und 833ns für 
'ne "1" auch gehen, dann könnte man sogar 3 Bits in ein Byte packen. Das 
spart RAM-Speicher (DMA_BufferSize). Der UART würde dann im 7-Bit-Modus 
mit Start- und Stop-Bit laufen, also 1 + 7 + 1 = 9 = 3 x 3.

Ich probiere das gelegentlich mal aus. Oder ist das dringend? Der Code 
steht dann auf Github.

Klar, man braucht dazu den Inverter^^. Wegen der 5V-Pegel ist ein 
Inverter m.E. aber ohnehin als Pegelwandler sinnvoll.

[Frank M. (ukw) (Moderator)]

Herbert P. schrieb:
> Wieso benötigt man einen "ST-Link/V2 zum Flashen
> http://www.st.com/web/catalog/tools/FM146/CL1984/SC724/SS1677/PF251168";,
> wenn der beim Discovery Board lt. Beschreibung eh schon integriert ist?
> Oder hab' ich da was missverstanden?

Ja, natürlich brauchst Du nur die ST-Link/V2-Software. Sowohl auf dem 
Nucleo-Board als auf dem Discovery ist die ST-Link-Hardware schon 
vorhanden.

Herbert P. schrieb:
> Wer auch immer für den Wiki-Eintrag "Software für Windows"
> verantwortlich zeichnet: es wäre nett, wenn da ein wenig mehr drin
> stehen würde als 4 unkommentierte Links. Wovon der ST-Link/V2 - Link
> ohne Zusatzinfo eigentlich problematisch ist, wenn jemand ein Original
> Disco-Board hat.

Für den Wiki-Eintrag bin ich verantwortlich.

Was hast Du an der Überschrift Software nicht verstanden? Von ST-Link 
Hardware stand da nix. Der Link zeigt auch auf die Windows Software. 
Für die benötigte Hardware hatte ich ein eigenes Unterkapitel angelegt. 
Da kam kein ST-Link-Device vor.

Gerne kann ich die Wiki-Links aber noch näher beschreiben, indem ich die 
Buzz-Words Software, keine Hardware noch ein paarmal in den Text 
einstreue, damit solche Missverständnisse nicht nochmal auftreten.

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Habe ich ja auch gesagt, aber Frank hat Timer genommen.

Genaugenommen habe ich DMA mit Timer genommen. Diese Methode findet 
man auch in diversen anderen öffentlichen Quellen in Verbindung STM32 
mit WS2812.

Es nützt mir nichts, wenn Du sagst, dass Du das schon seit vielen 
Monaten im stillen Kämmerlein anders machst, aber keine Quellen 
veröffentlichst. Das hilft mir nicht weiter. Ich werde das nun auch 
nicht mehr umstellen, da das so wie es ist, auch stabil läuft.

Dass Joachim auf seinem ATmega kein DMA nutzen kann, liegt an der Natur 
der Sache. Daher lassen sich STM32 und ATmega hier sowieso nicht unter 
einen Hut bringen. Daher kann ich mit Deiner Formulierung

> Habe ich ja auch gesagt, aber Frank hat Timer genommen.

absolut nichts anfangen.

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Link zeigt auch auf die Windows Software.

Ich hatte mich auch gewundert, die HW-Bilder stechen irgendwie mehr ins 
Auge, habe das mal geändert. Ist das eine "Eigenheit" der EM::Blocks 
IDE? Bei CooCox brauchte ich m.E. nix extra installieren.

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Es nützt mir nichts, wenn Du sagst, dass Du das schon seit vielen
> Monaten im stillen Kämmerlein anders machst, aber keine Quellen
> veröffentlichst. Das hilft mir nicht weiter. Ich werde das nun auch
> nicht mehr umstellen, da das so wie es ist, auch stabil läuft.

Das steht oben schon. Ich kann gern alles veröffentlichen, will meinen 
Code aber nicht wie "anbieten wie sauer Bier". Außerdem ist er ständig 
in Veränderung, dann müßte ich alles aktualisiert halten. Ich mache das 
auf Anfrage, einverstanden? Wie gesagt:

Torsten C. schrieb:
> Ich probiere das gelegentlich mal aus. Oder ist das dringend? Der Code
> steht dann auf Github.

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Klar, man braucht dazu den Inverter^^. Wegen der 5V-Pegel ist ein
> Inverter m.E. aber ohnehin als Pegelwandler sinnvoll.

Ein Pegelwandler ist nicht notwendig. Die Stripes laufen direkt am 
STM32, wenn Du DMA mit Timer machst. Bei DMA mit USART benötigst Du 
einen zusätzlichen Inverter. Den habe ich eingespart ;-)

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Das steht oben schon. Ich kann gern alles veröffentlichen, will meinen
> Code aber nicht wie "anbieten wie sauer Bier".

Das liegt allein in Deinem Ermessen.

> Außerdem ist er ständig
> in Veränderung, dann müßte ich alles aktualisiert halten.

Diese Verantwortung muss man halt tragen, wenn man Code veröffentlicht, 
der möglichst allgemein verwendbar sein soll.

> Ich mache das auf Anfrage, einverstanden?

Dein Ding. Aber bis dahin lass das bitte mit Deiner dauernd 
wiederholenden Aussage "DMA mit USART ist besser als DMA mit Timer". Das 
hilft hier keinem weiter.

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Bei DMA mit USART benötigst Du
> einen zusätzlichen Inverter. Den habe ich eingespart ;-)

Das steht ja oben auch schon alles. Ist halt eine Abwägung: Viel 
RAM-Speicher (DMA_BufferSize) XOR Inverter. Da gibt's kein "richtig" und 
kein "falsch".

Ich habe halt wenig RAM und je nach Kabellänge kommen Störungen. Bei 
30cm geht das natürlich auch bei mir ohne Pegelwandler. Die gleiche 
Hardware nehme ich für meine Wohnzimmerbeleuchtung, und da sind die 
Kabel zu lang.

Torsten C. schrieb im Beitrag 
Beitrag "Re: Minutengenaue 24 Stunden-Wortuhr - wer will mitbauen?" :
> Ist für Euch auch der Fortschritt mit den Matrix-Kacheln interessant?
> Oder brauche ich dazu hier nix schreiben?

PS zum Thema "anbieten wie sauer Bier"^^: Bei Interesse bitte melden, 
danke.

Frank M. schrieb:
> Aber bis dahin lass das bitte mit Deiner dauernd
> wiederholenden Aussage "DMA mit USART ist besser als DMA mit Timer". Das
> hilft hier keinem weiter.

Das war nur 'ne Antwort auf "spi ist doch perfekt um die 3 Bytes 
hintereinander auf einer Strippe für die WS rauszujagen...". Das war 
kein Angriff. Wo ist Dein Problem?

[Frank M. (ukw) (Moderator)]

Herbert P. schrieb:
> Warum ist eigentlich die CooCox Toolchain aus dem Rennen?

Hatt ich geschrieben:

Der µC, der auf dem Nucleo-Board sitzt, wird von CooCox nicht 
unterstützt.

Ausserdem ist die V2-Beta, die auf der CooCox-Homepage angepriesen wird, 
ziemlich defekt. Die kann noch nichtmals mehr vorhandene Projekte 
kompilieren.

Zudem ist EM::Blocks wesentlich schlanker, schneller und stabiler. 
Bisher im Gegensatz zu CooCox noch nie abgestürzt.

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Zudem ist EM::Blocks wesentlich schlanker, schneller und stabiler.
> Bisher im Gegensatz zu CooCox noch nie abgestürzt.

Danke für den Erfahrungsbericht, dann versuche ich mal einen "Umstieg". 
:-)

[Torsten C. (torsten_c)]

Zum Thema "Code, der möglichst allgemein verwendbar sein soll":

/*------------------------------------------------
 * display clock time (LEDs & mcurses)
 *------------------------------------------------
 */
void dsp_clock (uint8_t mode, uint8_t hour, uint8_t minute, uint8_t second, uint8_t update_leds_only) {
    // …
    dsp_all_leds_off ();
    // …
}

Um die SW-Module kompatibel zu halten, versuche ich in der dsp.h 
exportierten Funktionen möglichst kompatibel zu halten. Die Parameter 
"second" und "update_leds_only" kann ich ja ignorieren, aber bei den 
Display-Kacheln kann ich kein "dsp_all_leds_off();" machen, sonst würde 
es flackern oder ich müßte einen DoubleBuffer machen. OK?

Jetzt bitte nicht wieder "Dein Ding" antworten. Mit "Mach was Du willst, 
interessiert keinen" könnte ich eher was anfangen, dann brauche ich mir 
nämlich keine Mühe geben, kompatibel zu bleiben.

[Herbert P. (herb3472)]

WÜnsche allen Mitstreitern einen guten Rutsch in's neue Jahr und für 
"das Neue" Gesundheit, privates Glück und beruflichen Erfolg! Und uns 
allen wünsche ich Erfolg bei diesem Projekt! Möge die Übung gelingen!

Ich freue mich auf ein "Wiederlesen" im neuen Jahr!

LG Herbert

P.S. an Torsten: Deine Matrix-Module würde ich mir im neuen Jahr gern 
einmal näher anschauen.

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Um die SW-Module kompatibel zu halten, versuche ich in der dsp.h
> exportierten Funktionen möglichst kompatibel zu halten. Die Parameter
> "second" und "update_leds_only" kann ich ja ignorieren, aber bei den
> Display-Kacheln kann ich kein "dsp_all_leds_off();" machen, sonst würde
> es flackern oder ich müßte einen DoubleBuffer machen. OK?

Du hast den Sinn und Zweck dsp_all_leds_off() nicht verstanden. Hier 
werden keine LEDs ausgeschaltet, sondern es wird lediglich der Buffer 
für die LEDs gelöscht.

Da flackert nichts.

Das Vorgehen ist folgendes:

   - dsp_all_leds_off() löscht den Buffer

   - dsp_led_on() trägt gezielt den Soll-Zustand "LED an" in
     den Buffer ein.

   - dsp_fade() schickt mittels ws2812_refresh() den Buffer
     an die LEDs. Das passiert timergesteuert, damit diese dann
     weich überblenden. Solange kein ws2812_refresh() aufgerufen
     wird, passiert GAR NICHTS mit den LEDs. Ich arbeite also mit
     einem "Double-Buffer". Es gibt immer einen Ist-Zustand und
     einen Soll-Zustand.

> Jetzt bitte nicht wieder "Dein Ding" antworten. Mit "Mach was Du willst,
> interessiert keinen" könnte ich eher was anfangen, dann brauche ich mir
> nämlich keine Mühe geben, kompatibel zu bleiben.

Ich verstehe Deine Aggressionen nicht. Versuche bitte erst, den Source 
zu verstehen, bevor Du irgendwelche Unterstellungen machst. Oder 
probiere ihn doch einfach mal aus. Du hast doch ein Disco-Board.

P.S.
Die seconds sind damit drin, damit ich im mcurses-Terminal die Uhrzeit 
sekundengenau anzeigen kann. Damit gleiche ich die Zeiten nach einem 
DCF77- oder nach einem Time-Server-Zugriff ab. Die Sekunden also mit ans 
Display-Modul zu übergeben halte ich deshalb für legitim bzw. sogar für 
"allgemein". Wer weiß, vielleicht zeigen wir ja irgendwann auch noch 
irgendwo die Sekunden mit an? Das könnte z.B. eine LED sein, die durch 
alle Regenbogenfarben fadet, um dann bei 59 -> 00 wieder auszugehen.

P.P.S.
Ich verstehe auch nicht, warum Du an dsp.c ansetzt und deren Funktionen 
neu schreibst. Einfacher wäre es, wenn Du dsp.c so lässt wie es ist 
(schmeiss meinetwegen einfach die mcurses-Blöcke raus) und die 
ws2812-Funktionen neu implementierst. Nur da passiert der Low-Level-IO.

Zur Erläuterung: Die Low-Level-Module sind in Unterordnern, nämlich 
irmp, i2c, mcurses, uart, ws2812 bzw. usb-lib. Alle Hi-Level-Module 
befinden sich auf der gleichen Ebene wie main.c. Diese sind weitgehend 
µC-unabhängig und können für andere Mikrocontroller wie ATmega etc. fast 
ungeändert übernommen werden. Das DCF77-Modul iat dabei eine Abweichung 
von diesem Schema. Vielleicht trenne ich das noch auf in Low- und 
Hi-Level-Routinen. Mal sehen, halte ich momentan für nicht so wichtig.

[Joachim B. (jar)]

Herbert P. schrieb:
> WÜnsche allen Mitstreitern einen guten Rutsch in's neue Jahr und für
> "das Neue" Gesundheit, privates Glück und beruflichen Erfolg! Und uns
> allen wünsche ich Erfolg bei diesem Projekt! Möge die Übung gelingen!

ich dir doch auch

übrigends das hier gefunden

Beitrag "Re: billige Frontplatte für Worduhr"

Platte V2A 40 € hört sich doch gut an.....

[Torsten C. (torsten_c)]

Wie ich schrieb:
> Ich konzentriere mich … auf … die LED-Kacheln ansteuern

Uns dabei wollte ich möglichst kompatibel sein. Ich habe nichts dagegen, 
die Sekunden mit ans Display-Modul zu übergeben, hatte ich doch 
geschrieben^^.

Den Sinn und Zweck dsp_all_leds_off() hatte ich tatsächlich falsch 
verstanden, das sind je 2 Bits pro LED:

> #define CURRENT_STATE   0x01
> #define TARGET_STATE    0x02

Frank M. schrieb:
> Einfacher wäre es, wenn Du dsp.c so lässt wie es ist
> (schmeiss meinetwegen einfach die mcurses-Blöcke raus) und die
> ws2812-Funktionen neu implementierst. Nur da passiert der Low-Level-IO.

Stimmt! "dsp_all_leds_off();" kann also so bleiben. Sorry. Ich meinte 
wohl eher den "rgb_buf[WS2812_LEDS];" Lagsam fällt der Groschen. Bitte 
keine Unterstellung hinein interpretien!

Bei den "Matrix-Modulen" = "LED-Kacheln" ist das nämlich anders als bei 
WS2812: Die müssen dauernd Signale bekommen (siehe 
"Kachel-Timing2.PNG"). Dieser "Dauer-Datenstrom" wird per DMA im 
Hintergrund aus einem "rgb_buf" sichergestellt.

Die WS2812 behalten im Gegensatz dazu bis "ws2812_refresh();" ihre alten 
Werte.

Und der "rgb_buf[WS2812_LEDS];" ist ja in "ws2812.c". :-) Also ist alles 
gut.

Frank M. schrieb:
> Ich verstehe Deine Aggressionen nicht.

Welche Aussage klingt für Dich aggressiv?

Ich verstehe Deine Aggressionen nicht.
* "bis dahin lass das bitte"
* "bevor Du irgendwelche Unterstellungen machst"
* "dass Du das … im stillen Kämmerlein … machst"
* …

Aber vielleicht sehen wir ja beide Gespenster?

Ich wünsche auch allen hier einen guten Rutsch ins neue Jahr!

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Ich wünsche auch allen hier einen guten Rutsch ins neue Jahr!

Danke, das wünsche ich auch allen Beteiligten.

Ich habe gerade Version 0.6 hochgeladen und im Artikel dokumentiert.

Änderungen:

    - Konfiguration des WLAN-Moduls (SSID & Key) ist nun nicht
      mehr hart im Code verdrahtet, sondern kann nun über das
      Terminal vorgenommen werden. Nach Drücken von 'c' (configure)
      wird man aufgefordert, die SSID und den Key einzugeben.
      Da diese Einstellungen im ESP8266-Modul permanent gespeichert
      werden, ist diese Konfiguration nur einmal notwendig.

    - Automatische Erkennung der DCF77- und ESP82666-Module:

      Wenn eines oder beide Module nicht verwendet werden, sind die
      entsprechenden Anschlüsse (Eingänge) auf GND zu legen, siehe
      Anmerkungen im Artikel.

    - ESP8266: Zugriff auf den Time-Server:

      Einstellung der Zeitzone. Standardmäßig ist GMT+1 eingestellt.
      Für andere Länder kann das nun geändert werden. Das ist nur
      relevant bei Verwendung des ESP8266-Moduls!

    - ESP8266: Zugriff auf den Time-Server:

      Automatische Umschaltung von Winter-/Sommerzeit eingebaut.

    - I2C-Lib hinzugefügt

    - Routinen für I2C-EEPROM-Modul hinzugefügt

    - Routinen für I2C-RTC-Modul (DS3231) hinzugefügt

Die EEPROM- und RTC-Routinen hängen momentan noch "in der Luft", d.h. 
sie werden noch nicht verwendet. Der Grund ist einfach: Mein 
RTC-/EEPROM-Modul ist leider immer noch nicht eingetroffen und ich 
konnte die Routinen noch nicht testen. Sobald es eintrifft, werde ich 
die Routinen einhängen und auch im Artikel den Anschluss des I2C-Moduls 
dokumentieren.

Guten Rutsch! :-)

[Herbert P. (herb3472)]

Frank M. schrieb:
> Automatische Umschaltung von Winter-/Sommerzeit eingebaut.

Betrifft das nur das ESP8266 Modul oder auch den DCF77 Empfänger?

[Frank M. (ukw) (Moderator)]

Herbert P. schrieb:
> Frank M. schrieb:
>> Automatische Umschaltung von Winter-/Sommerzeit eingebaut.
>
> Betrifft das nur das ESP8266 Modul oder auch den DCF77 Empfänger?

Das deutsche DCF77-Signal beinhaltet bereits selbst die Sommerzeit, wenn 
Sommer ist. Daher braucht man da nichts selber umzuschalten.

Ein Time-Server im Internet dagegen "tickt" anders, er arbeitet generell 
mit UTC ("Universal Time Coordinated"), da man diesen ja auf der ganzen 
Welt erreichen kann - egal wo man gerade ist. Hier muss man die Zeitzone 
und evtl. Sommerzeit selbst mit einrechnen. Ersteres war schon drin 
(jedoch noch nicht konfigurierbar), zweiteres noch nicht. Spielte aber 
in der letzten Woche wg. Winterzeit noch keine Rolle ;-)

[Torsten C. (torsten_c)]

Hallo zusammen und frohes neues Jahr!

Torsten C. schrieb:
> nun kommen die Helligkeitsstufen dran

Ich habe mich deshalb mal mit dem Artikel LED-Fading beschäftigt. 
Ich sehe dabei zwei unterschiedliche Aspekte:

❶ Wie stark muss man die Gesamthelligkeit dimmen, damit man die 
WordClock einerseits bei hellem Sonnenlicht noch ablesen kann und damit 
sie beim Candle Light Dinner nicht als "störend" ausgeschaltet werden 
muss.

❷ Ein langsam eingeblendetes Wort soll "aus dem Dunkel" kommen und nicht 
den Eindruck machen, dass es plötzlich von 0% auf 80% springt, um dann 
langsam von 80% auf 100% zu faden. Wie hell darf also der "dunkelste 
Wert" beim ein- und ausblenden sein?

Für Beides zusammen ist der Kontrastumfang 1:255 der WS2812 ziemlich 
eingeschränkt, also beim Einblenden im gedimmten Zustand.

Bei den LED-Kacheln hat man den Kontrastumfang voll unter Kontrolle. 
Lediglich die Maximalhelligkeit von nur ca. 75Lux ist vorgegeben (alle 
LEDs eingeschaltet, Abstand 1m). Die WS2812 ist etwa zehnmal heller: 
760lux.

Das WS2812-Problem habe ich bei meinem Wohnzimmer (Bild siehe [1]) so 
gelöst, dass ich beim Dimmen unter Stufe 130/255 jede zweite LED 
einschalte und wieder auf Stufe 255/255 springe. Wenn man weiter dimmt, 
schaltet der Streifen irgendwann auf jede dritte LED, vierte LED usw. 
um. Dadurch habe ich einen theoretischen Helligkeitsbereich von 0,008 .. 
230lux auf 1m, den ich aber nicht komplett nutze.

So eine Möglichkeit haben wir bei der Wordclock jedoch nicht.

Zu ❶: Von den 75Lux bleiben z.B. bei "ES IST ZWANZIG UHR FÜNZEHN" etwa 6 
Lux übrig. Eine Kerze (ca. 1 Meter entfernt) hat vergleichsweise 1 Lux. 
Eine Dimmung auf 1:6 sollte also reichen. Was meint Ihr? Sollte der 
Dimmer-Bereich größer sein?

Zu ❷: Ich denke, ein Verhältnis 1:200 ist reichlich bemessen, also 32 
Schritte mit ca. 0,24 Blendenstufen:

$$2^{32\cdot0,24}\approx200$$

Frank hat das Problem der physiologisch linearen Helligkeitsverteilung 
bei einem Kontrastumfang von 1:255 sehr gut angenähert (siehe Bild).

$$y=\frac{b^{\,x/r_x}-1}{b-1}\cdot r_y$$

Ich versuche, mit dieser Formel nun einen Kontrastumfang von 6 x 200, 
also 1:1200 mit physiologisch linearer Helligkeitsverteilung für die 
LED-Kacheln umzusetzen, die Zahlen stehen aber noch nicht fest.

[1] http://www.mikrocontroller.net/topic/goto_post/3260177

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Da ich die STM32-Version ja noch auf das kleinere STM32F4 Nucleo F401
> Board portieren will…

Vielleicht stand das schon irgendwo:

  Warum ein NUCLEO-F401RE und kein NUCLEO-F411RE?

* http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1877/PF260049

* http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1810/PF258797

Bei der Gelegenheit noch ein Hinweis: "The Evaluation Board shall not 
be, in any case, directly or indirectly assembled as a part in any 
production of Yours. … Do not use the Evaluation Board until You have 
read and agreed to this Agreement" steht im EVALUATION BOARD LICENSE 
AGREEMENT.

Wie seht Ihr das? Man könnte die WC24h also nur illegal verkaufen. 
Verschenken mag gehen, so genau habe ich den Text nicht gelesen.

Oder: Wo kein Kläger, da kein Richter?

Torsten C. schrieb:
> Ich versuche … nun einen Kontrastumfang von … 1:1200 mit physiologisch
> linearer Helligkeitsverteilung für die LED-Kacheln umzusetzen.

Wobei ich dazu entweder mein 4€-Modul vielleicht um einen CPLD erweitern 
muss, oder ich nehme ein "xmc4500 relax lite", das kann SPI mit mehreren 
Bits parallel.

"SPI mit mehreren Bits parallel" kann wohl keines dieser Discovery- oder 
NUCLEO-Boards, oder habe ich was übersehen?

Das LICENSE-Problem träfe mich beim "xmc4500 relax lite" leider auch, 
daher tendiere ich zum 4€-Modul ggf. mit CPLD.

Was meint Ihr?

Einige meinen ja, dass "Discovery" und "Nucleo" langfristig besser 
verfügbar sind als China-Module. Ich habe keine Glaskugel, würde aber 
auf das Gegenteil wetten.

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Einfacher wäre es, wenn Du dsp.c so lässt wie es ist … und die
> ws2812-Funktionen neu implementierst. Nur da passiert der Low-Level-IO.

Bin dabei. Soll ich das bei mir so wie folgt machen, oder soll sich die 
Schnittstelle zu dem LED-Kachel-Low-Level-IO noch ändern?

int brightness_from_WS2812(int b) {
    if (b <   1) return  0;
    if (b <   2) return  1;
    if (b <   3) return  2;
    if (b <   4) return  3;
    if (b <   5) return  4;
    if (b <   6) return  5;
    if (b <   8) return  6;
    if (b <  11) return  7;
    if (b <  15) return  8;
    if (b <  19) return  9;
    if (b <  23) return 10;
    if (b <  29) return 11;
    if (b <  35) return 12;
    if (b <  41) return 13;
    if (b <  48) return 14;
    if (b <  56) return 15;
    if (b <  64) return 16;
    if (b <  72) return 17;
    if (b <  82) return 18;
    if (b <  92) return 19;
    if (b < 102) return 20;
    if (b < 114) return 21;
    if (b < 126) return 22;
    if (b < 138) return 23;
    if (b < 152) return 24;
    if (b < 166) return 25;
    if (b < 180) return 26;
    if (b < 196) return 27;
    if (b < 212) return 28;
    if (b < 228) return 29;
    if (b < 246) return 30;
                 return 31;
}

Ich würde bei mir z.B. gern noch einen zusätzlichen Dimming-Wert 
ergänzen, wo ich zusätzlich nochmal z.B. 32 Gesamt-Dimming-Stufen habe, 
die mit der "brightness_from_WS2812" kombiniert wird.

@Frank, was meinst Du?

Die LED-Hardware ist bei mir anders und es gibt ja auch noch Ideen zu 
monochromen LEDs mit TLC5947 und 12 Bit Farbtiefe, da ist dann wieder 
alles anders.

Eine gute "Hardware-Abstraction" ist leider nicht einfach, daher 
versuche ich, mich mit Dir abzustimmen.

Bitte diesmal nicht böse sein, falls ich wieder Deinen Code falsch 
verstanden habe.

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Wie seht Ihr das? Man könnte die WC24h also nur illegal verkaufen.
> Verschenken mag gehen, so genau habe ich den Text nicht gelesen.

Wer will die WC24h denn verkaufen? Das soll ein Nachbauprojekt werden. 
Von daher gibt es kein Problem.

Wenn ich die WC24h wirklich verkaufen wollte, dann würde ich ein eigenes 
Board machen, wo alle Komponenten schon drauf wären.

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Bin dabei. Soll ich das bei mir so wie folgt machen, oder soll sich die
> Schnittstelle zu dem LED-Kachel-Low-Level-IO noch ändern?
>
> [c]int brightness_from_WS2812(int b) {
>     if (b <   1) return  0;
>     if (b <   2) return  1;
>     if (b <   3) return  2;
>     ...

Wofür brauchst Du das? In dsp.c gibt es ein Array, welches eine 
physiologische Helligkeit von 0 bis 31 auf eine physikalische Helligkeit 
von 0 bis 255 umrechnet. Warum brauchst Du da noch die Umrechnung in 
umgekehrter Richtung?

Wenn Du wirklich die Umrechnung in umgekehrter Richtung brauchst (ich 
wüsste aber nicht, warum), würde ich in einer Schleife auf das Array 
zurückgreifen statt 31 ifs zu programmieren ;-)

> Ich würde bei mir z.B. gern noch einen zusätzlichen Dimming-Wert
> ergänzen, wo ich zusätzlich nochmal z.B. 32 Gesamt-Dimming-Stufen habe,
> die mit der "brightness_from_WS2812" kombiniert wird.

Ganz verstanden habe ich das noch nicht, was Du da genau willst. 
Möchtest Du insgesamt 64 statt 32 Helligkeitsstufen verwenden?

> Eine gute "Hardware-Abstraction" ist leider nicht einfach, daher
> versuche ich, mich mit Dir abzustimmen.

In dsp.c ist eine Formel bzw. eine kleine C-Funktion als Kommentar 
enthalten, welche x Helligkeitsstufen auf y viele RGB-Werte umrechnen 
kann und auf stdout C-Quelltext erzeugt, welches ein Array 
initialisiert. Diese C-Funktikon kannst Du unter Windows oder Linux 
kompilieren und ausführen. Dann bekommst Du auf stdout ein Array, 
welches Du dann als µC-Quelltext verwenden kannst.

Ich habe das Array dann aber noch manuell "frisiert", indem ich 
Array-Positionen, die auf gleiche RGB-Werte kommen (das ist halt leider 
so bei nur 256 Sufen im unteren Bereich), um eins hochgezählt habe, um 
Unterschiede zu erzwingen.

Diese C-Funktion kannst Du verwenden, um auch Arrays mit z.B. 
12-Bit-RGB-Werten zu erzeugen.

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Wofür brauchst Du das?

OK, ich kam schon mit 'ner Lösung, statt das Problem zu beschreiben. 
Sorry. Hinsichtlich der Lösung bin ich flexibel.

Die LED-Kacheln werden in mehreren "Zeitschlitzen" aktualisiert. Diese 
sind unterschiedlich lang (siehe Bild). Aktuell sind bei mir neun 
Zeitschlitze umgesetzt: 24,7µs, 28,1µs, 32,0µs, 36,4µs, 41,5µs, 47,2µs, 
148,0µs, 278,0µs und 579,2µs, siehe "4. D (PA12)".

Mit diesen Zeitschlitzen erreiche ich - in bestimmten Kombinationen - in 
32 Stufen eine exakte Kurve für die "physikalische Helligkeit", also 
ohne Abweichungen wie in Bild "physiologischLinear.png"^^.

> In dsp.c gibt es ein Array, welches eine
> physiologische Helligkeit von 0 bis 31 auf eine physikalische Helligkeit
> von 0 bis 255 umrechnet. Warum brauchst Du da noch die Umrechnung in
> umgekehrter Richtung?

Die Abbildung von 5 auf 9 Bits (pro Zeitschlitz ein Bit) ist dabei für 
mich "low-level" bzw. "Hardware-Abstraktion". Wie siehst Du das?

Es könnten auch 8 oder 10 Zeitschlitze (Bits) sein, das ist "low-level".

> Ganz verstanden habe ich das noch nicht, was Du da genau willst.
> Möchtest Du insgesamt 64 statt 32 Helligkeitsstufen verwenden?

Ich könnte z.B. für jede Gesamt-Helligkeitsstufe ein separates 
Zeitschlitze-Array (also ein "Kennfeld") hinterlegen, dann wäre die 
"RGB-Gammakorrektur" auch "low-level".

Ich nenne das mal "RGB-Gammakorrektur", weil man den Begriff von der 
Monitor-Kalibrierung kennt, auch wenn der Begriff nicht exakt stimmt.

Vielleicht mache ich sogar jewels drei separate Kennfelder für Rot, Grün 
und Blau und 10 statt 9 Zeitschlitze, das ist dann noch exakter.

Ob nun ein Kennfeld mit 32 Gesamt-Helligkeitsstufen oder mehr oder 
weniger ist noch offen.

Es geht natürlich auch anders, aber dann kann ich die blaue und die 
grüne Kurve aus "physiologischLinear" nicht so gut auf Deckung bringen, 
so wie bei der "Beule" bei 1..7 bei der WS2812.

Ich könnte z.B. auch 24 Zeitschlitze definieren, aber dann würde die 
Gesamt-Helligkeit geringer werden. Vielleicht sollten wir das Thema noch 
weiter detaillieren, das hängt mit der maximalen Taktfrequenz "11. Clock 
(PA8)" und der Refresh-Rate (Flimmern) zusammen. Aktuell erreiche ich 
bei größter Gesamt-Helligkeitsstufe 101 fps, das ist gerade erträglich, 
wenn man mit den Augen rollt (KFZ-LED-Bremslicht-Flacker-Effekt).

Bei einer Gesamt-Helligkeitsstufe 1/32 kann ich 563 fps erreichen, wenn 
ich das entsprechende Zeitschlitz-Array nehme.

Vielleicht würdest Du das "Problem" anders lösen?

Die Werte beziehen sich alle auf 1/16-Scan-Kacheln. Ich denke, 
langfristig muss ich mein "low-level-IO" noch auf 1/8-Scan-Kacheln 
umstellen, daher die Fragen nach CPLD oder dem "XMC4500 Relax Lite Kit", 
da ich dann nicht drei sondern sechs Bit parallel brauche. Und parallele 
Ausgabe über DMA ist doof, weil man pro 6-Bit-Wert immer 32 Bits im 
DMA-Buffer für das BSRR-Register benötigt (18,0 KBytes statt 3,4 
KBytes).

[Torsten C. (torsten_c)]

Herbert P. schrieb:
> Deine Matrix-Module würde ich mir im neuen Jahr gern
> einmal näher anschauen.

Ich hatte aus China mal vier Module für 6,30€ pro Stück bekommen. Da 
leuchten aber immer ein paar ausgeschaltete LEDs mit, siehe Bild; es ist 
ein Blatt Papier über sie obere Kachel gelegt.

Dieses "glimmen" liegt nicht an einer falschen Ansteuerung sondern an 
der billigen Hardware. Ich muss mal die teureren Kacheln ausprobieren, 
die kosten ja auch nur ca. 12,50€.

Damals hatte ich noch nicht auf 1/8- oder 1/16-Scan geachtet. Diese 
6,30€-Kacheln sind nicht nur preiswert sondern billig.

Da ich bei 1/16-Scan nur 3 Bits parallel brauche, benutze ich erstmal 
die billigen Kacheln, die kann ich mit einem SPI im Master-Modus und 
zwei SPIs im Slave-Modus prima per DMA füttern.

Kacheln mit 1/8-Scan sind in allen Größen viel besser verfügbar und 
etwas heller (etwa 150 Lux), daher würde ich die auf Dauer bevorzugen 
und da glimmen wahrscheinlich auch keine falschen LEDs mit.

[Herbert P. (herb3472)]

Torsten C. schrieb:
> Kacheln mit 1/8-Scan sind in allen Größen viel besser verfügbar und
> etwas heller (etwa 150 Lux), daher würde ich die auf Dauer bevorzugen
> und da glimmen wahrscheinlich auch keine falschen LEDs mit.

Wie groß sind diese Matrizen (wieviele Spalten/ Zeilen, welcher 
Abstand?)

[Torsten C. (torsten_c)]

Herbert P. schrieb:
> Wie groß sind diese Matrizen (wieviele Spalten/ Zeilen, welcher
> Abstand?)

Hier ist eine ganz gute Übersicht, was es alles gibt:

http://www.led-card.com/index.php?cPath=27

Die Preise des "LED Card Store" sind allerdings kein Maßstab.

Bei aliexpress kann man z.B. suchen nach:

* "320*160mm Screen Module"
* "p10 Screen Module"
* "32x16 Screen Module"
* "32*16 Screen Module"

Es gibt auch einfarbige, das Suchwort "full color" heißt "RGB".

Zwei Stück "P10 32*16 dots 1/8 scan" wären meines Erachtens optimal.

P10 = 10mm Pixel-Abstand, also 32cm breit, wie gewünscht.

"outdoor" dürfte egal sein, die Blende kann man meistens abschrauben, 
wenn sie stört:

http://www.mikrocontroller.net/attachment/236627/Matrix.jpg

[Torsten C. (torsten_c)]

Torsten C. schrieb:
> total (tbl_minutes+tbl_hours+tbl_modes+illumination): 7014 bytes

Hmmm, WP_ES und WP_IST sind manchmal in tbl_minutes und manchmal in 
tbl_hours gesetzt. Macht das Sinn, oder könnte man MAX_MINUTE_WORDS 
verkleinern, indem man WP_ES und WP_IST nur in tbl_hours steuert?

Vielleicht habe ich es auch nur nicht ganz verstanden.

PS:

In der .accdb für 16x16 fehlt noch das DUMMY-Wort mit dem Index 0.

Ich würde beim nächsten Update der Tabellen "END_OF_WORDS"
bevorzugen, statt "DUMMY".

[Torsten C. (torsten_c)]

So, noch eine kleine Änderung in der dsp.c und es ging:

https://www.youtube.com/watch?v=1j045td7XLE
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Frage 1:
  Weiss jemand, warum der SPI im Slave-Modus mit DMA erst beim
  zweiten Byte sendet?

http://www.mikrocontroller.net/attachment/242398/Kachel-Timing2.PNG

In diesem ^^ Bild sieht man, dass ich immer 9 Bytes senden muss.

Den USART (Master-SPI) initialisiere ich mit

DMA1_Channel4->CMAR = (uint32_t) (&(HUB08_MatrixData[HUB08_CurrentTimeslot][HUB08_DMA_Row].Blue))-1;

… und die Slave-SPIs mit

DMA1_Channel5->CMAR = (uint32_t) (&(HUB08_MatrixData[HUB08_CurrentTimeslot][HUB08_DMA_Row].Green));
DMA1_Channel3->CMAR = (uint32_t) (&(HUB08_MatrixData[HUB08_CurrentTimeslot][HUB08_DMA_Row].Red));

Bei allen drei DMA-Kanälen ist "CNDTR = 9", nur so geht es bisher.

Frage 2:
  Ist so eine Unterscheidung (speziell für WS2812) nicht
  besser "low-level"?

/*-------------------------------------------------------------------------------------------------------------------------------------------
 * switch one LED on
 *-------------------------------------------------------------------------------------------------------------------------------------------
 */
void
dsp_led_on (uint8_t y, uint8_t x, uint8_t refresh)
{
    uint16_t    n;
    #ifdef HUB08_H
        n = y * WC_COLUMNS + x;
    #else                                                     // torsten_c: auskommentiert, da speziell für WS2812
        if (y & 0x01)                                         // odd row: count from right to left
        {
            n = y * WC_COLUMNS + (WC_COLUMNS - x);
        }
        else                                                  // even row: count from left to right
        {
            n = y * WC_COLUMNS + x;
        }
    #endif
                                                            
    led_state[n] |= TARGET_STATE;
}

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> Ich suche immer noch den Link zu RGB - HSV und umgekehrt Code

Bist Du inzwischen fündig geworden?

Frank hat ja in der dsp.c (dsp = display) umgesetzt:

> * Decrement red brightness (LED7)
> * Increment red brightness (LED8)
> * Decrement green brightness (LED9)
> * Increment green brightness (LED10)
> * Decrement blue brightness (LED11)
> * Increment blue brightness (LED12)

HSV finde ich aber besser als RGB.

Andreas K. (necromancer1982) hat ja hier mal ein Bild geposted:

http://www.mikrocontroller.net/attachment/236320/Wordclock.jpg

Bei den LED-Kacheln habe ich vier LEDs pro Buchstaben-Kammer, gut zu 
sehen im Video^^. Ich würde daher gern sowas ähnliches wie bei 
necromancer1982 umsetzen, aber mit 32x32 RGB-Werten, dann wird der 
Verlauf etwas "weicher". Ich nenne das mal "Hintergrund-Grafik".

Dazu muss ich aber die dsp.c komplett neu schreiben, oder ich nehme 
einfach den Rot-Wert als "Brightness" und verknüpfe diesen mit der 
Hintergrund-Grafik. "green brightness" und "blue brightness" fliegen 
dann raus. Vielleicht gibt es pro Modus eine separate Grafik, mal sehen.

BTW: 32 Helligkeitsstufen sind etwas wenig zum ein- und ausblenden. Das 
ruckelt. Ich werde meine "Zeitschlitze"^^ nochmal überarbeiten.

[Torsten C. (torsten_c)]

Torsten C. schrieb:
> Bei aliexpress kann man z.B. suchen

Ich kann übrigens "JS INDUSTRIAL LTD" empfehlen. Der Verkäufer "Winter" 
ist auch nett. Meine letzte Lieferung erfolgte per Express innerhalb 
weniger als einer Woche. Aber Vorsicht bei DHL Express!

Für den, dem die Helligkeit reicht, hier meine Empfehlung für die
16x16-Wordclock in 32x32cm für 2 x 15,82€:

http://www.aliexpress.com/item/-/1791940107.html

Wegen der Einfuhrumsatzsteuer sollte man eine zweite Bestellung erst 
aufgeben, wenn die erste bereits verschickt wurde. Entweder unter 26€ 
incl. Versand bleiben, oder vorher mit Winter reden, wie man das 
Zoll-Problem löst.

Hier gibt's noch mehr von Winter:
http://www.aliexpress.com/store/1090165

WS2812 sind natürlich heller.

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Versuche bitte erst, den Source
> zu verstehen, bevor Du irgendwelche Unterstellungen machst. Oder
> probiere ihn doch einfach mal aus.

Ausprobieren ging erst heute, weil ich jetzt erst die Ansteuerung per 
HUB08 mit Helligkeitsstufen umgesetzt habe.

Torsten C. schrieb:
> Vielleicht gibt es pro Modus eine separate Grafik, mal sehen.

Wobei man dann für die Mode-Umschaltung ein anderes

void dsp_fade(bool changed)

benötigt, da "TARGET_STATE" und "CURRENT_STATE" dann jeweils eigene 
RGB-Werte wären und keine einzelnen Bits mehr.

[Torsten C. (torsten_c)]

Torsten C. schrieb:
> Für den, dem die Helligkeit reicht, hier meine Empfehlung für die
> 16x16-Wordclock in 32x32cm für 2 x 15,82€

Wobei das die 1/8-Scan-Version ist, also heller als meine jetzige 
1/16-Scan.

Ich habe für die 1/8-Scan-Version noch keine Meinung von Euch gehört, ob 
man dafür lieber einen STM32 mit CPLD (EPM3032A) oder einen XMC4500 
nehmen sollte. Ich hätte beides in der Bastelkiste, warte aber noch auf 
Euer Feedback.

Andererseits meinte meine Freundin: Mach die 1/16-Scan mit 192x192mm² 
fertig und dann ist Schluss! Für 120€ bekommt man auch einen 54,6cm 
Full-HD-Monitor plus "Android TV-Stick". Teurer darf die Wordclock nicht 
werden.

[Torsten C. (torsten_c)]

Frank M. schrieb:
> In dsp.c ist eine Formel bzw. eine kleine C-Funktion als Kommentar
> enthalten, welche x Helligkeitsstufen auf y viele RGB-Werte umrechnen
> kann und auf stdout C-Quelltext erzeugt, welches ein Array
> initialisiert.

Irgendwas passt da nicht, vielleicht ist ja auch die Formel im Artikel 
LED-Fading falsch?! Die gelbe Linie aus der C-Funktion habe ich zum 
besseren Verglich nicht auf ganze Zahlen gerundet.

Siehe auch:
Beitrag "LED-Fading - Kennlinie des Auges - GAMMA?"

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> BTW: 32 Helligkeitsstufen sind etwas wenig zum ein- und ausblenden. Das
> ruckelt. Ich werde meine "Zeitschlitze"^^ nochmal überarbeiten.

Ich habe mir Dein YouTube-Video angeschaut. Das ruckelt aber heftig. Bei 
mir ist das wesentlich weicher. Das kann deshalb nicht an den lediglich 
32 Helligkeitsstufen liegen, sondern muss eine andere Ursache haben.

Torsten C. schrieb:
> Irgendwas passt da nicht, vielleicht ist ja auch die Formel im Artikel
> LED-Fading falsch?! Die gelbe Linie aus der C-Funktion habe ich zum
> besseren Verglich nicht auf ganze Zahlen gerundet.

Ich habe die Formel nicht aus dem Artikel, sondern aus der Diskussion 
zum Artikel, siehe Link im Quelltext. Diese Formel fand ich damals 
wesentlich logischer und setze sie auch in mehreren Projekten ein - bei 
12-Bit-PWMs.

[Herbert P. (herb3472)]

Torsten C. schrieb:
> Torsten C. schrieb:
>> Für den, dem die Helligkeit reicht, hier meine Empfehlung für die
>> 16x16-Wordclock in 32x32cm für 2 x 15,82€

Ich habe starke Bedenken, dass die 4 LEDs pro Buchstaben keine schöne, 
gleichmäßige Ausleuchtung ergeben. In der Mitte wird wohl immer ein 
dunklerer Fleck bleiben?

Torsten C. schrieb:
> STM32 mit CPLD (EPM3032A) oder einen XMC4500

Ich habe (wie viele andere auch) weder das eine noch das andere in der 
Bastelkiste - ganz einfach deshalb, weil ich mit dem Elektronikbasteln 
schon vor längerer Zeit aufgehört und das meiste verschenkt oder 
entsorgt habe.

Ich muss mir also für das Wordclock-Projekt bis zum letzten Widerstand 
alles extra kaufen. Schon wieder ein neuer Mikrocontroller wird mir 
zuviel - außer ich finde einen Abnehmer für das STM32 Discovery Board, 
weil das hab' ich ohnehin noch nicht angerührt.

[Herbert P. (herb3472)]

Torsten C. schrieb:
> Für 120€ bekommt man auch einen 54,6cm
> Full-HD-Monitor plus "Android TV-Stick". Teurer darf die Wordclock nicht
> werden.

Fehlkäufe (Arduino, m1284p, STM32 Discovery Board, STLink/V2, diverse 
Clock- und WLAN-Module, LED-Matrizen, etc.) mitgerechnet, habe ich für 
das Wordclock-Projekt bisher schon wesentlich mehr ausgegeben.

[Herbert P. (herb3472)]

Herbert P. schrieb:
> Torsten C. schrieb:
>> Für 120€ bekommt man auch einen 54,6cm
>> Full-HD-Monitor plus "Android TV-Stick". Teurer darf die Wordclock nicht
>> werden.
>
> Fehlkäufe (Arduino, m1284p, STM32 Discovery Board, STLink/V2, diverse
> Clock- und WLAN-Module, LED-Matrizen, etc.) mitgerechnet, habe ich für
> das Wordclock-Projekt bisher schon wesentlich mehr ausgegeben. Meine 
"Bastelkiste" mit Bauteilen und Baugruppen, die ich dann offensichtlich 
letztendlich für die Wordclock doch nicht benötige, wächst ständig :-(

[Herbert P. (herb3472)]

> Torsten C. schrieb:
>> Für 120€ bekommt man auch einen 54,6cm
>> Full-HD-Monitor plus "Android TV-Stick". Teurer darf die Wordclock nicht
>> werden.

Fehlkäufe (Arduino, m1284p, STM32 Discovery Board, STLink/V2, diverse
Clock- und WLAN-Module, LED-Matrizen, etc.) mitgerechnet, habe ich für
das Wordclock-Projekt bisher schon wesentlich mehr ausgegeben. Meine
"Bastelkiste" mit Bauteilen und Baugruppen, die ich dann offensichtlich
letztendlich für die Wordclock doch nicht benötige, wächst ständig :-(

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Das kann deshalb nicht an den lediglich
> 32 Helligkeitsstufen liegen, sondern muss eine andere Ursache haben.

Ja, ich habe gestern abend mal einen "Graukeil" dargestellt, da sind 
"Huckel" drin. Ich hatte die "Zeitschlitze" zunächst nur annähernd 
berechnet, ohne die Dunkel-Zeit zwischen zwei Updates und die Zeit für 
den DMA-IRQ-Handler zu berücksichtigen. Ein Nachmessen per LA hilft. ;-)

Ich rechne gerade neue Zeitschlitze aus, wenn der Graukeil dann stimmt, 
schaue ich mir das Ruckeln nochmal an.

Herbert P. schrieb:
> Torsten C. schrieb:
>> STM32 mit CPLD (EPM3032A) oder einen XMC4500
> Ich habe (wie viele andere auch) weder das eine noch das andere in der
> Bastelkiste

So ein Problem habe ich vermutet. Falls jemand eine 16x16 mit "Kacheln" 
mit 1/8-Scan nachbauen will, müsste ich dafür eine Ansteuerung mit DMA 
im "Bit-Banging-Modus" umsetzen. Dann wird bei meinem 4€-Board der 
Speicher knapp, aber mit dem Discovery ginge das.

Herbert P. schrieb:
> In der Mitte wird wohl immer ein dunklerer Fleck bleiben?

Ab ca. 15mm Abstand verschwindet der dunkle Fleck vollständig, ohne 
zusätzliche "Wattebäuschchen" o.Ä. in der Buchstaben-Kammer.

Meine Test-Kacheln haben 6mm Pitch, da reichen 9mm. Aktuell nutze ich 
einfaches Kopierpapier als Mattscheibe. Das könnte z.B. bei Mattglas 
natürlich geringfügig anders sein.

[Frank M. (ukw) (Moderator)]

Herbert P. schrieb:
> Fehlkäufe (Arduino, m1284p, STM32 Discovery Board, STLink/V2, diverse
> Clock- und WLAN-Module, LED-Matrizen, etc.) mitgerechnet, habe ich für
> das Wordclock-Projekt bisher schon wesentlich mehr ausgegeben.

Es ist normal, dass diejenigen, die in der Entwicklung vorne mitgehen, 
zusätzliche Kosten haben. Entweder man nimmt diese in Kauf oder man 
macht halt vorne nicht mit, sondern wartet ab, bis das Projekt fertig 
ist.

Wenn Du schon ein STM32 Disco hast, warum probierst Du dann das 
STM32-Projekt aus dem Artikel nicht aus? Ich kann auch eine fertige 
HEX-Datei im Artikel ablegen, falls Du die IDE nicht installieren 
möchtest. Dann brauchst Du für den Test nur noch die Hex-Datei zu 
flashen.

Ich weiß irgendwie nicht, wie Du Dich in diesem Projekt positionieren 
möchtest. Einerseits kaufst Du ein Entwicklungsboard, andererseits lässt 
Du das dann in der Schublade vergammeln. Vielleicht kannst Du da mal 
Aufklärung schaffen.

P.S.
Wenn Du keinen Abnehmer für das Disco-Board findest, kann ich Dir das 
auch abnehmen. Mein Port auf das Nucleo-Board (klein, aber fein) ist 
auch schon fast fertig abgeschlossen. Melde Dich einfach per PM.

[Herbert P. (herb3472)]

Torsten C. schrieb:
> Ich habe für die 1/8-Scan-Version noch keine Meinung von Euch gehört, ob
> man dafür lieber einen STM32 mit CPLD (EPM3032A) oder einen XMC4500
> nehmen sollte.

Frank M. schrieb:
> Ich weiß irgendwie nicht, wie Du Dich in diesem Projekt positionieren
> möchtest. Einerseits kaufst Du ein Entwicklungsboard, andererseits lässt
> Du das dann in der Schublade vergammeln. Vielleicht kannst Du da mal
> Aufklärung schaffen.

Ich möchte nur, dass wir uns nicht verzetteln. Seit Projektbeginn wurden 
bereits 4 verschiedene µC bzw. Boards ins Spiel gebracht: Arduino Uno, 
Atmega1284p, STM32 Discovery und STM32 Nucleo Board. Wenn jetzt Torsten 
noch andere Boards bzw. Controller im Auge hat, die seiner Meinung nach 
noch besser geeignet wären, dann bin ich durchaus einverstanden - sofern 
wir uns auf eine - oder höchstens zwei - gemeinsame Linie(n) einigen 
können.

Vielleicht sollten wir auch von Haus aus eine Stufe höher greifen, damit 
wir nicht immer "nachbessern" müssen. Meines Erachtens macht es keinen 
Sinn, sich wegen 5 Euro auf oder ab den Kopf zu zerbrechen. Und wenn das 
Controllerboard 5 Timer und 20 I/O-Ports zuviel hat, soll's mir recht 
sein - solange wir in einer Größenordnung von unter 50,- Euro bleiben. 
Einzige Einschränkung: das Board muss noch in der Uhr Platz finden.

Wir sollten lediglich einmal einen Punkt erreichen, von dem wir sagen 
können: "That's it!"

[Frank M. (ukw) (Moderator)]

Herbert P. schrieb:

> Ich möchte nur, dass wir uns nicht verzetteln.

Da bin ich absolut Deiner Meinung.

> Seit Projektbeginn wurden
> bereits 4 verschiedene µC bzw. Boards ins Spiel gebracht: Arduino Uno,
> Atmega1284p, STM32 Discovery und STM32 Nucleo Board.

Das liegt daran, dass insgesamt 3 Entwickler verschiedene Wege gehen 
möchten:

1. Joachim: ATmega (z.B. Arduino), weil er nix anderes kennt.
2. Torsten: STM32 China-Module (ohne ST-Link-Anschluss, wenig Memory).
3. Frank: Disco als Entwicklungsboard, Nucleo als endgültiges Board.

> Wenn jetzt Torsten
> noch andere Boards bzw. Controller im Auge hat, die seiner Meinung nach
> noch besser geeignet wären, dann bin ich durchaus einverstanden - sofern
> wir uns auf eine - oder höchstens zwei - gemeinsame Linie(n) einigen
> können.

Bei Torsten ist das so eine Sache, er schweift öfter mal vom 
eigentlichen Ziel ab und wirft dann plötzlich solche Sachen wie "eigenes 
Betriebssystem", "CPLD", "XMC4500", "Probleme beim Wclock24h verkaufen" 
usw. hier ins Geschehen. Auch verfrickelt er sich öfter in Details: Zum 
Beispiel verursacht bei mir diese Diskussion um irgendwelche 
Gamma-Korrekturen, die nicht genau 1:1 in allen Nachkommastellen stimmen 
mögen, bei mir leider nur Augenrollen. Das sind Details, um die man sich 
auch später kümmern kann. Diese ziemlich weitschweifenden Gedanken sind 
leider wenig zielführend - ganz im Gegenteil: sie verunsichern den Leser 
hier nachhaltig.

Meine Devise: First make it work, then make it fine.

> Vielleicht sollten wir auch von Haus aus eine Stufe höher greifen, damit
> wir nicht immer "nachbessern" müssen. Meines Erachtens macht es keinen
> Sinn, sich wegen 5 Euro auf oder ab den Kopf zu zerbrechen.

Sehe ich genauso. Deshalb bleibe ich meiner Linie treu: Disco als 
Entwicklungsboard, Nucleo als Nachbau-Board. Wobei ich das Nucleo erst 
deshalb in die Planung mit aufgenommen habe, als Du das Problem mit der 
Höhe angesprochen hast. Das Nucleo ist gerade mal 1,5 cm hoch, wenn man 
die Pins auf der Unterseite mit der Zange abpitscht. Dafür habe ich 
knapp 5 Minuten gebraucht. Ausserdem ist es klein genug, damit es hinter 
der Frontplatte im unbeleuchteten Bereich (Rand) passt. Und es hat eine 
ST-Link-Schnittstelle, so dass jeder unbedarfte User per Mini-USB-Kabel 
die Hex-Datei flashen kann. Nur so macht das Ganze auch Sinn.

> Und wenn das
> Controllerboard 5 Timer und 20 I/O-Ports zuviel hat, soll's mir recht
> sein - solange wir in einer Größenordnung von unter 50,- Euro bleiben.

Das Nucleo kostet gerade mal 12 EUR, hat jede Menge Schnittstellen und 
mehr als ausreichend Speicher, bekommt man in Deutschland und die 
Lieferzeit beträgt 2-3 Tage. Und es ist einigermaßen zukunftssicher.

> Einzige Einschränkung: das Board muss noch in der Uhr Platz finden.

Eben: Aus diesem Grunde ist das Nucleo-Board die Lösung. Ich will 
keine China-Module supporten, die noch nichtmals direkt per USB-Kabel 
programmierbar sind (ich also noch ein teures ST-Link-Programmiergerät 
kaufen muss), nur damit das Board dann 5 EUR kostet. Das mag in einer 
Serienproduktion sinnvoll sein, aber nicht als Nachbauprojekt.

> Wir sollten lediglich einmal einen Punkt erreichen, von dem wir sagen
> können: "That's it!"

Dafür müssten auch alle an demselben Strang ziehen. Da habe ich noch 
erhebliche Zweifel. Ich kann daher nur für mich sprechen: Ich ziehe das 
Projekt genau so durch, wie ich es hier (und im Artikel) umrissen 
habe.

[Herbert P. (herb3472)]

Frank M. schrieb:
> Eben: Aus diesem Grunde ist das Nucleo-Board die Lösung. Ich will
> keine China-Module supporten, die noch nichtmals direkt per USB-Kabel
> programmierbar sind (ich also noch ein teures ST-Link-Programmiergerät
> kaufen muss), nur damit das Board dann 5 EUR kostet. Das mag in einer
> Serienproduktion sinnvoll sein, aber nicht als Nachbauprojekt.

Da ich ja nun wegen eines Missverständnisses stolzer Besitzer eines 
ST-Link/V2 Programmiergeräts bin, stelle ich mich gerne gegen einen 
geringen Unkostenbeitrag zur Programmierung von STM32 Modulen zur 
Verfügung. Wenn jemand Bedarf an diesem Programmiergerät hat - es ist 
fabriksneu, ich gebe es gerne zum Selbstkostenpreis ab).

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Auch verfrickelt er sich öfter in Details: Zum
> Beispiel verursacht bei mir diese Diskussion um irgendwelche
> Gamma-Korrekturen, die nicht genau 1:1 in allen Nachkommastellen stimmen
> mögen, bei mir leider nur Augenrollen. Das sind Details, um die man sich
> auch später kümmern kann.

Ja, stimmt. So bin ich. Allerdings ist sind bei den Kacheln

* die kürzest mögliche PWM-Einschatdauer und

* der mindestens erforderliche Kontrastumfang

ziemlich essentielle Parameter, die man später ohne Hardware-Änderung 
nicht so ohne weiteres ändern kann. Sorry, wenn Euch das zu sehr ins 
Detail geht.

> ... wirft dann plötzlich solche Sachen wie "eigenes
> Betriebssystem", "CPLD", "XMC4500", "Probleme beim Wclock24h verkaufen"
> usw. hier ins Geschehen.

Falls wir uns hier einig sind, dass wir uns über "Probleme beim 
verkaufen" keine Gedanken machen wollen, ist das OK. Aber man muss 
darüber doch mal reden dürfen, um den Konsens festzuhalten.

Zu "CPLD" und "XMC4500": Ich schaue mal, in wieweit man die Ausgänge der 
Kacheln wieder an die Eingänge anschließen kann, also ob das mit der 
Verzögerung der Signale bei der nötigen SPI-Taktfrekuenz noch sicher 
Funktioniert. Dieser Gedanke ist mir erst gestern gekommen.

Theoretisch kommt man mit einem einzigen SPI aus, auch bei 1/8-Scan, 
wenn man den Rot-Ausgang der zweiten Kachel an den Grün-Eingang der 
ersten anschließt und den Grün-Ausgang der zweiten Kachel an den 
Blau-Eingang der ersten (usw. bei 1/8 Scan).

Praktisch hat das ganze aber Grenzen, wegen

* des Flimmerns (KFZ-LED-Bremslicht-Flacker-Effekt),

* der maximalen Takt-Rate des SPIs und

* des erreichbaren Kontrastumfangs.

Grob über den Daumen geschätzt, sollte es mit jedem STM32-Board mit 
einem oder zwei SPIs auch ohne CPLD auch mit 1/8-Scan-Kacheln gehen. Ich 
melde mich, wenn ich es ausprobiert habe.

[Herbert P. (herb3472)]

Torsten C. schrieb:
> Falls wir uns hier einig sind, dass wir uns über "Probleme beim
> verkaufen" keine Gedanken machen wollen, ist das OK. Aber man muss
> darüber doch mal reden dürfen, um den Konsens festzuhalten.

Von dem Gedanken an eine kommerziellen Fertigung hatte ich wegen des 
erforderlichen hohen Aufwands für Produktion, Vertrieb und 
Administration (und Gebrauchsmusterschutz) schon Abstand genommen, bevor 
ich meine Idee hier vorgestellt habe. Ich denke jedoch, dass nichts 
dagegen einzuwenden sein wird, wenn der eine oder andere in paar 
Einzelstücke in seinem Bekanntenkreis verscherbelt. Sollte doch jemand 
damit kommerzielle Interessen verfolgen, würde ich Wert drauf legen, mit 
von der Partie zu sein.

[Frank M. (ukw) (Moderator)]

Neues vom Nucleo-Port:

Nachdem ich gestern stundenlang probiert habe, aus dem MCO-Ausgang des 
integrierten ST-Link-ICs den Systemtakt für den µC herauszukitzeln[1], 
habe ich dann irgendwann frustriert einen 8MHz-Quarz auf die auf dem 
Nucleo-Board dafür vorgesehene Stelle gelötet... klappte sofort.

Der Stand des Ports ist:

  - MCURSES läuft (Disco: USB->VCP, Nucleo: USB->USART2)
  - IRMP läuft
  - ESP8266 läuft (Disco: USART2, Nucleo: USART6)
  - DCF77 läuft
  - WS2812 mangels Zeit noch nicht getestet

Da EM::Blocks Multi-Targeting beherrscht, konnte ich sowohl das Disco- 
als auch das Nucleo-Target in dasselbe Projekt stopfen. Die Sourcen sind 
auch alle nur einmal vorhanden, denn sie können für beide Targets 
übersetzt werden. Bei den Low-Level-Modulen werden die Unterschiede 
zwischen Disco- und Nucleo per Preprocessor-Makros behandelt.

Heute abend oder morgen lege ich die neuen Sources im Artikel ab und 
dokumentiere die notwendigen HW-Maßnahmen am Nucleo (ein paar Lötbrücken 
entfernen, Quarz und zwei Kondensatoren einlöten - Arbeit für 5-10 
Minuten).

Dann wird es auch zum ersten Mal fertige HEX-Dateien zum Herunterladen 
geben. Das heisst, eine Installation der IDE (EM::Blocks o.ä.) zum 
Kompilieren ist dann nicht mehr unbedingt notwendig.

---
[1] HSE-PLL konnte trotz RCC_CR_HSEBYP und aller möglichen anderen 
Versuche nicht einrasten. MIT HSI wollte ich mich nicht zufriedengeben, 
da der integrierte Oszillator nicht genügend genau ist.

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Neues vom Nucleo-Port

Ich würde mir vorzugsweise ein NUCLEO-F411RE bestellen, um die 
Ansteuerung incl. der Helligkeitsstufen für 1/8-Scan-Kacheln darauf zu 
portieren. Das 411 sollte ja zum 401 kompatibel sein, oder?

Meine Herausforderung: Auch eine Mischfarbe (z.B. Orange) wird im stark 
gedimmter Darstellung noch weich ausgeblendet, ohne dass sich dabei der 
Farbton nennenswert verändert.

Auch die Zeitdauer der Ausblendung sollte im gedimmten Zustand nicht 
anders sein als im hellsten Modus, ohne dass man Stufen wahrnimmt.

An einfachsten wäre natürlich "ein/aus" mit einer einfachen Farbe (Rot, 
Grün, Blau, Gelb, Violett, Blaugrün, Weiss), also ohne fading. Würde 
Euch das reichen?

Frank M. schrieb:
> Diese ziemlich weitschweifenden Gedanken sind
> leider wenig zielführend - ganz im Gegenteil: sie verunsichern den Leser
> hier nachhaltig.

Ich zermartere mir das Hirn, wie ich mit einem STM32 optimal die Kacheln 
ansteuere und muss dann sowas lesen. Ist das 'ne Einzelmeinung? Ich habe 
keinen Bock mehr, ständig diese Aggressionen zu lesen.

Frank M. schrieb:
> HSE-PLL konnte trotz RCC_CR_HSEBYP und aller möglichen anderen
> Versuche nicht einrasten.

Hmmm, lohnt es vielliecht, C10 (20pF[N/A]) zu bestücken? Keine Ahnung, 
nur 'ne Idee.

Frank M. schrieb:
> Sachen wie "eigenes Betriebssystem"

Ein "Betriebssystem" wollte ich nie!

Frank, Du hättest jetzt vielleicht gleich wieder von einer 
"Unterstellung" gesprochen. Ich meine:

1. wir sollten die Bälle hier flacher spielen und

2. die Bibliotheken sollten mit abgesprochenen Schnittstellen möglichst 
vielseitig verwendbar oder ggf. austauschbar sein, z.B. WS2812 gegen 
1/8-Scan-Kacheln. Mit einem "Betriebssystem" hat das nix zu tun.

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Ich würde mir vorzugsweise ein NUCLEO-F411RE

War ja klar, dass es natürlich wieder ein anderes Board sein muss. :-(

Aber meinetwegen, mir ist das schnuppe. So groß werden die Unterschiede 
zum 401er nicht sein.

> Meine Herausforderung: Auch eine Mischfarbe (z.B. Orange) wird im stark
> gedimmter Darstellung noch weich ausgeblendet, ohne dass sich dabei der
> Farbton nennenswert verändert.

Wenn Du drei 12-Bit-PWMs (oder mehr) benutzt, sollte das kein Problem 
sein.

> Ich zermartere mir das Hirn, wie ich mit einem STM32 optimal die Kacheln
> ansteuere und muss dann sowas lesen. Ist das 'ne Einzelmeinung?

Frag doch mal Herbert. Er hat schon seinen Unmut über dieses Hin und Her 
geäußert. Er redete von "verzetteln". Natürlich ist er verunsichert. Und 
anderen (stillen) Lesern wird es auch so gehen. Dauernd packst Du was 
neues aus - wie jetzt zum Beispiel wieder das F411RE statt F401RE.

> Ich habe
> keinen Bock mehr, ständig diese Aggressionen zu lesen.

Ich werde zukünftig über Deine Hardware-Schwankungen einfach nichts mehr 
schreiben. Ich wusste nicht, dass so etwas für Dich aggressiv 
rüberkommt.

> Hmmm, lohnt es vielliecht, C10 (20pF[N/A]) zu bestücken? Keine Ahnung,
> nur 'ne Idee.

Keine Ahnung, C10 ist zwar im Schaltplan angedeutet, es wird aber kein 
Wort darüber im User Manual verloren. Ist mir jetzt auch egal, denn die 
Lösung mit dem eigenen Quarz ist mir sowieso lieber.

Grund:
Es könnte hinter der Frontplatte eng werden. Man kann den ST-Link-Teil 
absägen. Damit reduziert sich die Breite des Teils von 7 cm (quer) auf 5 
cm (längs). Den ST-Link kann man dann wieder für Update-Flashs über den 
SWD-Stecker seitlich anflanschen. Ich möchte da ungern permanent das 
8MHz-Signal auch drüber führen.

> Frank M. schrieb:
>> Sachen wie "eigenes Betriebssystem"
>
> Ein "Betriebssystem" wollte ich nie!

Komisch:

  Beitrag "Re: Minutengenaue 24 Stunden-Wortuhr - wer will mitbauen?"

Zitat:

> Man könnte eine Art "Betriebssystem" einsetzten, um das zu umgehen.
> Wollen wir eins nutzen?

> Frank, Du hättest jetzt vielleicht gleich wieder von einer
> "Unterstellung" gesprochen. Ich meine:
>
> 1. wir sollten die Bälle hier flacher spielen und
>
> 2. die Bibliotheken sollten mit abgesprochenen Schnittstellen möglichst
> vielseitig verwendbar oder ggf. austauschbar sein, z.B. WS2812 gegen
> 1/8-Scan-Kacheln. Mit einem "Betriebssystem" hat das nix zu tun.

Wie gesagt: ich halte von nun an den Mund und werde Deine Schwankungen 
nicht mehr kommentieren. Mitmachen werde ich sie keinesfalls. Sonst 
werde ich ja nie mehr fertig.

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Sonst werde ich ja nie mehr fertig.

Für mich hat das Projekt noch viel Zeit. Wer weiss, ob und wann die 
Frontplatten in 16x16 kommen. So hat jeder seine eigene Perspektive auf 
das Projekt. Die eigene Perspektive anderen aufdrücken zu wollen, ist 
nicht Zielführend. Die fremden Perspektiven verstehen, akzeptieren oder 
bei Bedarf zu hinterfragen dagegen sehr.

Frank M. schrieb:
> Frag doch mal Herbert. Er hat schon seinen Unmut über dieses Hin und Her
> geäußert.

Darum ja nun "Kachel mit Nucleo". Ist das gewünscht? Dazu sagst Du nix!

Mir "Hin-und-Her" und "Schwankungen" vorzuwerfen ist schon wieder Mist!

Wenn jedes "hinterfragen" als störend empfunden wird, ist das hier nicht 
mehr mein Projekt. Mir macht mein Hobby Spaß, weil ich verschiedene 
Lösungen durchdenken, ausprobieren und die (möglichst im Konsens beste) 
Lösung umsetzen kann.

Mit Streitereien muss ich meine Zeit auch nicht verplempern. Es gibt 
genügend andere Leute, mit denen ich Projekte mache, die sich nicht mit 
mir streiten wollen.

Jeder weiss, dass Design-Fehler, die man am Anfang eines Projektes 
entdeckt, nur ein Bruchteil an Mehraufwand bedeuten wie bei Fehlern, die 
man erst kurz vor Projektende entdeckt. Ein "Hinterfragen" zu 
kritisieren ist daher nicht zielführend. Hier haben wir offenbar 
gegensätzliche Meinungen.

Aber was soll der ständige Kampf? Akzeptiere doch mal, dass es auch 
andere Meinungen gibt!

Eine Lösung, die vielleicht ohne CPLD funktioniert, ist mir halt erst 
Dienstag eingefallen. Von Dir kam die Idee nicht, sondern nur Vorwürfe.

Frank M. schrieb:
> Dauernd packst Du was
> neues aus - wie jetzt zum Beispiel wieder das F411RE statt F401RE.

Es ist doch beruhigend für andere (stille) Leser, wenn die WC24h mit 
beiden Boards gleich gut geht und wir das vorher ausprobiert haben. 
Warum siehst Du das negativ, ich sehe das positiv.

Ich mache das ja nicht Grundlos. Aber wenn keiner nach dem Grund fragt, 
habe ich bislang auf ungefragte Romane verzichtet.

Bevor Du mit "Hin-und-Her" und "Schwankungen" kommst, weil Du den Grund 
nicht erkennst, frag doch einfach!

Frank M. schrieb:
> Wenn Du drei 12-Bit-PWMs (oder mehr) benutzt, sollte das kein Problem
> sein.

Ach nee. Aber Dann flacker's (KFZ-Bremslicht^^^). Wenig zielführend. :-(

Frank M. schrieb:
> Ist mir jetzt auch egal, denn die
> Lösung mit dem eigenen Quarz ist mir sowieso lieber.

Ich werde mir den MCO-Ausgang mal anschauen, das muss gehen. Mehr löten 
(sind SMD-Bauteile dabei?) könnte Nachbauer auch abschrecken. Muss aber 
nicht, ich sags ja nur.

Der Satz "Man könnte eine Art 'Betriebssystem' einsetzten" sollte den 
Gedanken eines Gemeinschaftsprojekts mit wiederverwendbaren gemeinsamen 
Bibliotheken und Schnittstellen voran bringen. Statt hier inhaltlich 
weiter zu kommen, wird daraus von Dir ein Vorwurf gemacht.

Frank M. schrieb:
> werde Deine Schwankungen nicht mehr kommentieren

Das ist gut so, es sind ja auch keine da, die es zu kommentieren gäbe. 
Vermutlich sind es Fehlinterpretationen oder Streitsucht, keine Ahnung.

Das ist auch mein letzter "Roman" hier. Ich schreibe lieber C-Code statt 
Beiträge wie diese. Das ist zielführender, macht mehr Spaß, und lenken 
vom inhaltlichen Fortschritt ab.

Trotzdem schöne Grüße an die "Chips und Cola Frakion". ;-)

Frank M. schrieb:
> Wie gesagt: ich halte von nun an den Mund

Ich hatte bis eben noch auf Zusammenarbeit gehofft. Kann ich die 
Hoffnung begraben?

[Herbert P. (herb3472)]

Torsten C. schrieb:
> 2. die Bibliotheken sollten mit abgesprochenen Schnittstellen möglichst
> vielseitig verwendbar oder ggf. austauschbar sein, z.B. WS2812 gegen
> 1/8-Scan-Kacheln. Mit einem "Betriebssystem" hat das nix zu tun.

Da möchte ich mich gleich anschließen:

ich habe nach wie vor die Idee einer einfärbig warmweißen LED-Anzeige 
mit TLC5940 nicht aufgegeben und bin dabei auf eine klar definierte 
Schnittstelle angewiesen.

Heute ist sehr viel geschrieben worden. Leider habe ich im Augenblick 
nicht die Zeit, das alles durchzulesen, ich hoffe, dadurch nichts zu 
versäumen!

[Herbert P. (herb3472)]

@ Frank & Torsten:

Jetzt habe ich mir doch die Zeit genommen, Euren Meinungsaustausch (oder 
Schlagabtausch, oder wie immer man das nennen mag), durchzulesen. Dazu 
möchte ich nichts sagen außer Euch zu empfehlen: seid bitte so gut und 
schlaft eine Nacht darüber!

Es wurde auch die 16 x 16 Matrix angesprochen. Mein Letztstand ist der 
vom November. Im Augenblick habe ich kaum Zeit, aber ab übernächster 
Woche stehe ich gerne zur Verfügung, um die Wortkombinationen der 16 x 
16 Matrix zu überprüfen und ggf. umzustellen.

[Torsten C. (torsten_c)]

Herbert P. schrieb:
> ich habe nach wie vor die Idee einer einfärbig warmweißen LED-Anzeige
> mit TLC5940 nicht aufgegeben

Dazu gibt' einen Haufen fertige Projekte zum kopieren modifizieren oder 
zum fertig kaufen. Das erste was ich gefunden habe ist z.B.:

http://www.solderlab.de/index.php/hardware/matrix-controller-board

Um mit der Idee weiter zu kommen, wäre eine Abgrenzung interessant: Was 
ist hier doof? Oder gibt's was, was man übernehmen könnte? Hattest Du 
schon mal selbst nach Projekten geschaut?

Warum zwei Colorduinos = Rainbowduinos doof sind, habe ich noch nicht 
ganz verstanden. Klar, normalerweise sind da RGB-LEDs dran, aber die 
Farben sind egal, die LEDs können auch alle die gleiche Farbe haben.

Das heißt ja nicht, dass die Wordclock-Firmware auf so einem 
LEDMATRIXduino laufen soll, die LEDMATRIXduinos kann man ja per I²C oder 
UART steuern. Vorteil: Fertig zu kaufen, keine Bauteile löten, Firmware 
modifizierbar.

Uch kann Dir zum ausprobieren einen zuschicken, falls es die nicht aus 
Deutschland geben sollte.

Die LEDs könnte man direkt in die MDF-Platte stecken (Presspassung), mit 
Fädeldraht verlöten und mit den "LEDMATRIXduinos" verbinden. Oder wurde 
diese Variante schon für doof befunden?

Ein Riesen-PBC mit TLC5940 und LEDs hat natürlich auch seinen Reiz, 
ist aber mit 320x320 sehr teuer.

[Joachim B. (jar)]

Torsten C. schrieb:
> Joachim B. schrieb:
>> Ich suche immer noch den Link zu RGB - HSV und umgekehrt Code
>
> Bist Du inzwischen fündig geworden?

ne nicht wirklich, habe aber momentan ganz andere Probleme mit dem 
mighty m1284p

FastLED LIB vom Arduino funzt am m328p aber spinnt total am m1284p

am m328p (Arduino) funzt Timer1 Nokia LCD, RTC, I2C, WS2812b

das selbe Programm bereinigt mit den verschiedensten Ports funzt am 
m1284p mit Timer1 nicht, Abhilfe Timer3 nehmen, ist ja keine große 
Sache.

aber selbst das mini Blink Programm der FastLED Lib spuckt am m1284p

aus schön blinkendes Rot abwechselnd mit Schwarz gedimmt mit 
setbrightness() am m328p wird grellstes WEISS ohne Blink.

#include "FastLED.h"

// How many leds in your strip?
#define NUM_LEDS 6

// For led chips like Neopixels, which have a data line, ground, and power, you just
// need to define DATA_PIN.  For led chipsets that are SPI based (four wires - data, clock,
// ground, and power), like the LPD8806 define both DATA_PIN and CLOCK_PIN
#define DATA_PIN 3
//#define CLOCK_PIN 13

// Define the array of leds
CRGB leds[NUM_LEDS];

void setup() { 
      // Uncomment/edit one of the following lines for your leds arrangement.
      // FastLED.addLeds<TM1803, DATA_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<TM1804, DATA_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<TM1809, DATA_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<WS2812, DATA_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<WS2812B, DATA_PIN, RGB>(leds, NUM_LEDS);

// statt FastLED.addLeds<NEOPIXEL, DATA_PIN, RGB>(leds, NUM_LEDS);

FastLED.addLeds<NEOPIXEL, DATA_PIN, GRB>(leds, NUM_LEDS); // braucht der WS2812b
      // FastLED.addLeds<UCS1903, DATA_PIN, RGB>(leds, NUM_LEDS);

      // FastLED.addLeds<WS2801, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<SM16716, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<LPD8806, RGB>(leds, NUM_LEDS);

      // FastLED.addLeds<WS2801, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<SM16716, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
      // FastLED.addLeds<LPD8806, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
}

void loop() { 
  // Turn the LED on, then pause
  leds[0] = CRGB::Red;
  FastLED.show();
  delay(500);
  // Now turn the LED off, then pause
  leds[0] = CRGB::Black;
  FastLED.show();
  delay(500);

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Jeder weiss, dass Design-Fehler, die man am Anfang eines Projektes
> entdeckt, nur ein Bruchteil an Mehraufwand bedeuten wie bei Fehlern, die
> man erst kurz vor Projektende entdeckt. Ein "Hinterfragen" zu
> kritisieren ist daher nicht zielführend. Hier haben wir offenbar
> gegensätzliche Meinungen.

Wo ist das STM32F401 Nucleo ein "Designfehler". Bei mir läuft 
mittlerweile die komplette Uhr auch auf dem Nucleo.

> Aber was soll der ständige Kampf? Akzeptiere doch mal, dass es auch
> andere Meinungen gibt!

Es erweckt bei mir nur den Eindruck, dass Du aus Prinzip eine andere 
Meinung hast.

> Es ist doch beruhigend für andere (stille) Leser, wenn die WC24h mit
> beiden Boards gleich gut geht und wir das vorher ausprobiert haben.
> Warum siehst Du das negativ, ich sehe das positiv.

Weil ich jetzt noch ein Board kaufen muss, nämlich das 411er, damit ich 
das auch unterstütze.

Soll ich jetzt das 401er in die Tonne werfen?

Ich bin auch schon dabei, ein Morpho-Shield-PCB für das 401er zu 
entwerfen und habe gerade nachgeschaut ins User Manual: Glücklicherweise 
ist das PinOut exakt identisch vom 411er!

Genau das hat Herbert hier schon genervt angemerkt: Er hat sich schon 
jede Menge Hardware gekauft: Für nix!

Jetzt sag mir bitte, warum Du jetzt plötzlich das 411er willst und 
warum das 401er nicht ausreicht. Wenn Du gute Gründe hast, bestelle ich 
mir halt das 411er und lege noch ein Target "Nucleo-411" im 
EM::Blocks-Projekt an.

> Ich mache das ja nicht Grundlos. Aber wenn keiner nach dem Grund fragt,
> habe ich bislang auf ungefragte Romane verzichtet.

Dann sag mir bitte den Grund, warum Du jetzt wieder ein anderes Board 
als das 401er nehmen willst.

> Bevor Du mit "Hin-und-Her" und "Schwankungen" kommst, weil Du den Grund
> nicht erkennst, frag doch einfach!

Hiermit getan, siehe oben.

> Ach nee. Aber Dann flacker's (KFZ-Bremslicht^^^). Wenig zielführend. :-(

Nicht bei genügend hoher PWM-Frquenz. Mit 8-Bit-PWM bekommst Du immer 
Farbverschiebungen im unteren Helligkeitsbereich - das liegt an der 
Natur der Sache. Bei kleineren RGB-Werten ist sind die Verhältnisse von 
R zu G zu B immer ungenauer. Dein Orange ist spätestens bei RGB=1,0,0 
kaputt.

> Ich werde mir den MCO-Ausgang mal anschauen, das muss gehen. Mehr löten
> (sind SMD-Bauteile dabei?) könnte Nachbauer auch abschrecken. Muss aber
> nicht, ich sags ja nur.

Das geht wahrscheinlich auch mit der Revision "MB1136 C-02" 
out-of-the-box, denn da wird diese Konfiguration auch so ausgeliefert. 
Ich habe aber die ältere Revision "MB1136 C-01". Und die wird 
standardmäßig mit HSI-Einstellungen ausgeliefert - siehe User-Manual. 
ST-Microelectronics weiß auch bestimmt, warum.

> Der Satz "Man könnte eine Art 'Betriebssystem' einsetzten" sollte den
> Gedanken eines Gemeinschaftsprojekts mit wiederverwendbaren gemeinsamen
> Bibliotheken und Schnittstellen voran bringen. Statt hier inhaltlich
> weiter zu kommen, wird daraus von Dir ein Vorwurf gemacht.

Ich habe Dir lediglich vorzuwerfen, dass Du hier in der Vergangenheit 
immer wieder neue Gedanken hier eingeworfen hast, die einen vom 
eigentlichen Ziel eher weiter wegbringen statt näher.

Statt erstmal in Ruhe nachzudenken, wird hier erstmal das Buzzword 
"CPLD" reingekippt. Jetzt sagst Du, Du brauchst doch keinen "CPLD". Aber 
Du solltest mal drüber nachdenken, welchen Eindruck Du damit dem Leser 
hier vermittelst. Ich als Unbefangener würde denken "Nur ein Haufen 
Chaoten hier, kommen jeden Tag mit was anderem und kriegen nix auf die 
Reihe". Glücklicherweise kann ich das persönlich besser einschätzen.

> Das ist gut so, es sind ja auch keine da, die es zu kommentieren gäbe.

Eben. Es gibt nur viel Text von Dir hier.

> Das ist auch mein letzter "Roman" hier. Ich schreibe lieber C-Code statt
> Beiträge wie diese. Das ist zielführender, macht mehr Spaß, und lenken
> vom inhaltlichen Fortschritt ab.

Das sehe ich absolut genauso. Ich bin gespannt auf Deine ersten 
Ergebnisse ;-)

> Ich hatte bis eben noch auf Zusammenarbeit gehofft. Kann ich die
> Hoffnung begraben?

Wenn Du nicht dauernd querschießt, habe ich nix gegen Zusammenarbeit.

Aber wenn ich mich seit vielen Wochen aufs 401er festlege, Du aber - 
ohne einen Grund anzugeben - jetzt plötzlich das 411er nehmen willst, 
kommt man zwangsweise auf den Gedanken, dass Du nur aus Prinzip das 
411er und nicht das 401er wählst.

Als ich das eben las, bekam ich erstmal einen Schreck: "Muss ich jetzt 
das 401er in die Tonne schmeißen und mir das 411er bestellen? Muss ich 
jetzt mein PCB-Layout fürs 401er-Shield wegwerfen und neu machen? Was 
mache ich, wenn er übermorgen wieder ein anderes Board nehmen will?".

Verstehst Du, was ich meine? Genau das hat Herbert auch gemeint, als 
er sich hier beklagte, bereits jede Menge unnütze Hardware für das 
Projekt angeschafft zu haben.

[Joachim B. (jar)]

Frank M. schrieb:
> Genau das hat Herbert auch gemeint, als
> er sich hier beklagte, bereits jede Menge unnütze Hardware für das
> Projekt angeschafft zu haben.

nun ja zu STM zu wechseln kam nicht vom Herbert, nicht von Torsten und 
nicht von mir, sollte mal festgestelt werden.

Soweit ich mich erinnere wollte Herbert und auch ich von Anfang an 
Arduino oder AVR kompatibel, aber es stört ja nicht wenn du auf STM 
(oder für beide arbeitest)

Kaufte Herbert und ich nicht eine 16 x 16 Matrix und irgendwie wurde 16 
x 18 draus?

und nun peace.

Joachim B. schrieb:
> ne nicht wirklich, habe aber momentan ganz andere Probleme mit dem
> mighty m1284p

sogar einen 2ten aufgebaut, alles im Beispiel Programm blink minimiert

am m1284p kann es nicht liegen.

nur warum funzt am m328p der Timer1 und warum tillt Timer1 am m1284p?

muss mir das noch mal mit den OCR1A Pins ansehen.

aber egal welcher Timer, ob Timer1 oder Timer2 WS2812B funktioniert an 2 
m1284p nicht, egal welche Ports.

Auf dem Oszi sieht man immer 24 Bit auf 1 was auch bei Ausgabe ROT 
volles Weiss ergibt ich hätte ja nur für rot 8 Bit 1 und 16 Bit 0 
erwartet

eventuell doch ein Timingproblem, aber 0 und 1 sollte doch verschieden 
ausfallen,

https://dlnmh9ip6v2uc.cloudfront.net/assets/b/a/2/9/c/51f04d33ce395f687c000001.png

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> eventuell doch ein Timingproblem, aber 0 und 1 sollte doch verschieden
> ausfallen

Ich kenne zwar den ATMega auch ganz gut, aber mit den Bibliotheken und 
wie sich die gegenseitig stören, da kann ich kaum helfen. Warum 
"NEOPIXEL" und nicht "WS2812"

* Interrupts nicht ausgeschaltet?

* Mal alle andere Programmteile deaktiviert und nur WS2812 ausprobiert?

* Mal WS2812 per SPI in Erwägung gezogen?

Ich befürchte, ich bin hier keine große Hilfe.

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Es gibt nur viel Text von Dir hier.

Du kannst es nicht lassen!

Joachim B. schrieb:
> und nun peace.

Ack! Darum lasse ich alles, was nix bringt, unbeantwortet.

Frank M. schrieb:
> Glücklicherweise ist das PinOut exakt identisch vom 411er!

Hatte ich ja auch schon geschrieben. Ein paar Pins sind nicht 
5V-kompatibel, daher wollte ich nochmal sicher gehen, bevor ich mir das 
falsche bestelle.

Frank M. schrieb:
> Wenn Du gute Gründe hast, bestelle ich
> mir halt das 411er und lege noch ein Target "Nucleo-411" im
> EM::Blocks-Projekt an.

Nur - wie gesagt - damit wir die Kompatibilität testen, weil es mehr für 
den gleichen Preis kann, weil ich nicht so viele untzerschiedliche 
Boards haben will (Austauschbarkeit) und weil ich damit vielleicht auch 
mal mit dem "Batch Acquisition Mode" spielen will. Ich sehe keinen 
Grund, warum Du oder Herbert einen F411 nehmen solltet.

Frank M. schrieb:
> Als ich das eben las, bekam ich erstmal einen Schreck.

Das tut mir Leid, ich dachte, ich hätte mich klar ausgedrückt. Merkst Du 
was? Du hättest viel "Text von Dir" sparen können. Es war ein 
Missverständnis!

Frank M. schrieb:
> Nicht bei genügend hoher PWM-Frquenz.

Eine "Pulsweite" ist immer mindestens so lang, wie der SPI (je nach 
Verdratung) für 96 Bits benötigt. Kürzer geht, aber dann leidet die 
100%-Helligkeit.

Frank M. schrieb:
> Mit 8-Bit-PWM bekommst Du immer Farbverschiebungen im unteren
> Helligkeitsbereich

Im Moment arbeite ich an BAM mit variablen (optimierten) 
pulse-stretch-Werten. PWM ist ähnlich, aber hier gelten andere Gesetze, 
siehe Seite 8 hier:

http://www.artisticlicence.com/WebSiteMaster/App%20Notes/appnote011.pdf

Damit müsste es auch ohne Farbverschiebungen machbar sein. Aber falls 
niemand Wert drauf legt, kann ich mir das Leben auch einfacher machen 
und komme schneller voran.

Frank M. schrieb:
> Wenn Du nicht dauernd querschießt, habe ich nix gegen Zusammenarbeit.

Ein Tipp: Wohlwollende Grundhaltung! Also: Wie könnte eine Äußerung 
gemeint sein, wenn man sie versucht, nicht negativ (z.B. als Querschuss) 
zu interpretieren? Das gelingt mir aber selbst nicht immer. Lohnt sich 
aber immer wieder, wenn man dran denkt!

Herbert P. schrieb:
> Es wurde auch die 16 x 16 Matrix angesprochen.

Wie gesagt: Wegen mir keine Hektik!

[Frank M. (ukw) (Moderator)]

Version 0.7 ist im Artikel WordClock24h online.

Neuerungen/Änderungen:

  - Portierung der Software auf STM32F401RE Nucleo Board
  - uart2.c generalisiert auf uart.c (verschiedene UARTs möglich)
  - eeprom.c und ds3231.c vervollständigt
  - Lesen/Schreiben der RTC in den Programmcode integriert
  - Bugfix im UART-Ringbuffer-Code (Interrupt-Sperre)
  - Anzeige der Online-Devices (ESP8266, DCF77, EEPROM, RTC) im Terminal
  - Verschiedene Optimierungen

Vor dem Auspacken der Zip-Datei sollte man einen etwaigen alten noch 
vorhandenen Ordner löschen, damit keine Dateileichen liegenbleiben.

Die Software läuft nun 1:1 auch auf dem STM32F401RE Nucleo Board. Die 
Anschlüsse und was sonst noch zu tun ist, sind im Artikel komplett 
beschrieben.

Bei der Gelegenheit habe ich die Dokumentation des Projekts im Artikel 
weiter vervollständigt.

Viel Spaß,

Frank

[Torsten C. (torsten_c)]

Noch ein Gedanke, vielleicht findet den ja jemand gut:

Ein Chat z.B. am Wochenende oder Abends, wo man sich mal unkompliziert 
austauschen kann. Skype ginge vllt. auch, ich kenne mich da nicht so 
aus.

In der Firma nennen wir das "Web Conference". Falls Interesse besteht: 
Vielleicht finden wir 'ne gemeinsame Basis-Technik.

Zumindest könnte man sich gegenseitig besser kennenlernen und mal ohne 
"Interpretiererei" miteinander reden und sich effizient untereinander 
abstimmen.

Frank M. schrieb:
> lege noch ein Target "Nucleo-411" im EM::Blocks-Projekt an.

Ich muss dann ja eh EM::Blocks installieren und mache das auch gern 
selbst. OK?

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Frank M. schrieb:
>> lege noch ein Target "Nucleo-411" im EM::Blocks-Projekt an.
>
> Ich muss dann ja eh EM::Blocks installieren und mache das auch gern
> selbst. OK?

Dein Projekt mit den Kacheln ist eh ein anderes. Ich habs gestern abend 
bei mir schon gemacht. Ich lass den 411er erstmal mit den gleichen 
PLL-Werten laufen wie den 401er. Die 16MHz mehr brauche ich nicht. Das 
Projekt compiliert nun auch für den 411er. Das geänderte Projekt werde 
ich nachher noch hochladen.

Aber Du hast mir meine gestrige Frage nicht beantwortet: Wofür brauchst 
Du denn unbedingt den 411er Nucleo, was beim 401er fehlt?

[Herbert P. (herb3472)]

Torsten C. schrieb:
> Ein Chat z.B. am Wochenende oder Abends, wo man sich mal unkompliziert
> austauschen kann. Skype ginge vllt. auch, ich kenne mich da nicht so
> aus.
>
> In der Firma nennen wir das "Web Conference". Falls Interesse besteht:
> Vielleicht finden wir 'ne gemeinsame Basis-Technik.

Halte ich für eine sehr sehr gute Idee! Skype habe ich, mir wäre aber 
auch ein anderes Vehikel recht.

[Herbert P. (herb3472)]

Frank M. schrieb:
> Version 0.7 ist im Artikel WordClock24h online.

Hab's nur kurz überflogen (wenig Zeit): sauber gemacht, Gratulation!

[Frank M. (ukw) (Moderator)]

Herbert P. schrieb:
> Halte ich für eine sehr sehr gute Idee! Skype habe ich, mir wäre aber
> auch ein anderes Vehikel recht.

Skype habe ich auch. Das Problem ist nur: Eine Skype-Konferenz bedingt 
synchrone Kommuikation, d.h. alle Beteiligten müssen gleichzeitig 
verfügbar sein. Das kann zu einem Problem werden.

Alternativ kann ich eine Entwickler-interne Mailingliste 
wclock24h-ml(at)uclock.de anlegen. Sämtliche Mails an diese Adresse wird 
dann an die angemeldeten User verteilt. Ich halte eine derartige 
Kommunikation für effektiver. Solche Mailinglisten benutzen wir auch im 
fli4l-, eisfair- und im bisherigen WordClock-Projekt.

[Frank M. (ukw) (Moderator)]

Version 0.7.1 ist online.

Einzige Änderung:

  - Portierung auf Nucleo-Board STM32F411

Es kann also jetzt das 401er oder 411er Board benutzt werden. Beide 
werden identisch genutzt, d.h. es ist prinzipiell egal, welches von 
beiden man nimmt. Das 411er ist etwas schneller. Das wird vielleicht in 
einer späteren Version ausgenutzt - auch wenn ich jetzt dafür noch 
keinen Bedarf sehe. Egal ob 84MHz oder 100MHz... affenschnell sind sie 
beide.

Ich habe den Artikel angepasst und die Anleitungen auf das 411er Board 
erweitertert.

Wer keine IDE installieren will, kann auch direkt die Hex-Dateien aus 
dem Artikel herunterladen. Es gibt jeweils eine fürs Disco-, 401er und 
411er Nucleo-Board.

Viele Spaß.

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> am m328p wird grellstes WEISS ohne Blink.

Welchen Wert hat F_CPU bei Dir?

Frank M. schrieb:
> Dein Projekt mit den Kacheln ist eh ein anderes. Ich habs gestern abend
> bei mir schon gemacht.

Ich meinte durchaus, dass ich das mit Deinem Projekt ggf. selbst 
mache, aber OK, um so besser.

Frank M. schrieb:
> Entwickler-interne Mailingliste

Ich habe da nix gegen, aber die effiziente Kommunikation, wo man z.B. 
auch mal mit "Stop, das war anders gemeint" unterbrechen kann, bevor der 
andere unnötige lange Romane zuende tippt, hätte man dann nicht.

Den Unterschied zwischen Mailingliste und Forum empfinde ich als 
minimal. Geheimnisse, für die wir 'ne Mailingliste bräuchten, sehe ich 
nicht. Mit einer zusätzlichen Mailingliste wird es unübersichtlicher, 
weil man sich die Infos aus einer weiteren Quelle zusammen suchen 
müsste.

Der Gedanke war eher: "Sich gegenseitig besser kennenlernen, mal ohne
'Interpretiererei' miteinander reden und sich effizient untereinander
abstimmen."

Ob man das dann regelmäßig wiederholt oder nach dem ersten Mal 
feststellt, dass das vielleicht einmal ganz gut war, aber eine 
Wiederholung keinen Sinn macht, könnten wir dann ja gleich zum Abschluss 
besprechen.

Frank M. schrieb:
> Aber Du hast mir meine gestrige Frage nicht beantwortet: Wofür brauchst
> Du denn unbedingt den 411er Nucleo, was beim 401er fehlt?

Ich bin mir nicht sicher, ob ich dazu noch was schreiben soll, also ob 
das jetzt eine Stichelei oder eine Verständnisfrage zu meiner ersten 
Antwort ist, oder ob Du meine erste Antwort ^^ nicht gelesen hast.

Ich möchte nicht so viele unterschiedliche Boards in der Bastelkiste 
haben, um bei Problemen oder Varianten schnell mal das Board wechseln zu 
können, z.B. um das Board als Fehlerursache ausschließen zu können. Die 
WC24h ist ja nicht mein einziges Projekt und wenn ich das Board 
bestelle, bestelle ich ja nicht nur ein einzelnes.

Gibt es denn einen Grund das weniger leistungsfähige pinkompatible 
F401-Board für den gleichen Preis statt des F411 in mein 
"Bastelkisten-Sortiment" aufzunehmen?

Aus my.st.com:
> double RAM, lower power, higher speed and doubled port speed.
> The only difference seems to be in the pins PA0, PA4, PA5, PB5 -
> these pins are 5V compatible in the 401, but no more in the 411

Die AppNote AN4515 zum neuen "Batch Acquisition Mode" ist ja leider 
immer noch nicht raus. Ich bin gespannt, was genau dahinter steckt und 
was mir das bringen könnte (nicht unbedingt für die WC24h, sondern ggf. 
in geeigneten Projekten).

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Der Gedanke war eher: "Sich gegenseitig besser kennenlernen, mal ohne
> 'Interpretiererei' miteinander reden und sich effizient untereinander
> abstimmen."

Ja okay, mal schauen, wann wir da alle mal zur gleichen Uhrzeit Zeit 
haben werden...

> Ich möchte nicht so viele untzerschiedliche Boards in der Bastelkiste
> haben,

Weia. Ich dachte, jetzt kommt was technisches. Also damit DU nicht so 
viele unterschiedliche Boards in der Bastelkiste haben willst, soll 
ICH mir viele unterschiedliche Boards in die Bastelkiste legen?!?

Ich habe das 401er schon seit einem Monat und arbeite damit die ganze 
Zeit. Du wusstest das. Tut mir leid, Dein Argument ist nicht 
stichhaltig. Oder willst Du mir jetzt weismachen, dass Du das 411er auch 
schon länger hast?!? Das würde ich nicht glauben, denn bisher hast Du 
nur mit China-Modulen gearbeitet.

Aber gut, ich habe mir nun auch ein 411er bestellt. Sollte Montag 
ankommen.
Ich hoffe, Du kommst übermorgen nicht mit einem weiteren Board :(

> Gibt es denn einen Grund das weniger leistungsfähige pinkompatible
> F401-Board für den gleichen Preis statt des F411 in mein
> "Bastelkisten-Sortiment" aufzunehmen?

Der Grund ist einfach: Ich hatte schon eins! Und zwar als erster. Aber 
ist jetzt auch egal. Die 12 EUR kann ich verkraften.

> Aus my.st.com:
>> double RAM, lower power, higher speed and doubled port speed.
>> The only difference seems to be in the pins PA0, PA4, PA5, PB5 -
>> these pins are 5V compatible in the 401, but no more in the 411

Uninteressant. Das 401er ist gerade mal 16% langsamer. Aber immer noch 
affenschnell.

P.S.
Falls Du es eben nicht mitbekommen hast, weil sich unsere Posts eben 
überschnitten haben: Ich habe die 411er Version eben hochgeladen und den 
Artikel aktualisiert.

P.P.S.
Das 401er und das 411er gibts hier http://www.exp-tech.de/ direkt aus 
Deutschland. Die liefern ziemlich schnell.

[Joachim B. (jar)]

Torsten C. schrieb:
> Welchen Wert hat F_CPU bei Dir?

na 16MHz

sonst würde ja alles Timing (Sekundenblink 200/800) nicht passen

und die nano micros haben auch alle 16 MHz

für den 1284p habe ich mir die 18,432 MHz erst mal abgeschminkt

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Uninteressant. Das 401er ist gerade mal 16% langsamer

Sehe ich für das WC24h-Projekt auch so.

Frank M. schrieb:
> Das 401er und das 411er gibts hier …

Meinen Mouser-Warenkorb hatte ich zum Glück noch nicht abgeschickt, da 
nehme ich gleich noch zwei F411er-Boards mit rein, dann habe ich keine 
weiteren Versandkosten und es dauert auch meist nur 4-5 Tage.

Danke trotzdem, für alle anderen Leser.

------- doch nochmal Frank-Torsten-Kram -------


Frank M. schrieb:
> Also damit DU nicht so
> viele unterschiedliche Boards in der Bastelkiste haben willst, soll
> ICH mir viele unterschiedliche Boards in die Bastelkiste legen?!?

Hat denn das nie ein Ende? ;-) Wie kommst Du darauf?

Von Deiner Bastelkiste habe ich nicht gesprochen. Ich verstehe Dein 
Problem immer noch nicht und ich glaube, es gibt auch gar keins.

Ich habe nur gefragt, warum ein F401 und kein F411, also ob ich das 
statt dessen das F411 nehmen kann.

Die Anwtort wäre ganz einfach gewesen:

    Ich hatte schon ein F401. Aber das F411 geht auch.

Soviel "Gesabbel" wäre echt nicht nötig gewesen.

Zur Erinnerung:
Torsten C. schrieb:
> Vielleicht stand das schon irgendwo: Warum ein NUCLEO-F401RE und
> kein NUCLEO-F411RE?
Torsten C. schrieb:
> Ich würde mir vorzugsweise ein NUCLEO-F411RE bestellen …
> Das 411 sollte ja zum 401 kompatibel sein, oder?
Torsten C. schrieb:
> … daher wollte ich nochmal sicher gehen, bevor ich mir das
> falsche bestelle. … Ich sehe keinen
> Grund, warum Du oder Herbert einen F411 nehmen solltet.

Ist das Thema damit geklärt?

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Ist das Thema damit geklärt?

Nein. Wenn man gemeinsamen Code verwenden will, wäre auch eine 
gemeinsame Hardware vorteilhaft. Du willst "Kooperation", aber Du willst 
den 411er nehmen, weil ich vorher den 401er ausgewählt habe. Wie passt 
das zusammen?

Um Frieden zu halten, tille ich mein 401er und kaufe mir auch ein 411er, 
damit die gemeinsame Hardware-Basis gewährleistet ist und DU nur eine 
Variante in der Schublade hast.

Diese Sache machst Du aber nur genau einmal mit mir. Einen weiteren 
HW-Wechsel aus irgendeiner Laune heraus mache ich nicht mehr mit.

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Diese Sache machst Du aber nur genau einmal mit mir.

Ich habe nix mit Dir gemacht, sondern (zum vierten Mal) nur eine Frage 
gestellt. Jeder zieht sich den Schuh an, der ihm passt!

Frank M. schrieb:
> Torsten C. schrieb:
>> Ist das Thema damit geklärt?
> Nein. … Wie passt das zusammen?

Also für mich ist das Thema durch, das bringt nix. Ein F411 geht 
offenbar, macht keinen Unterschied bezüglich "gemeinsame 
Hardware-Basis", es nicht der Rede Wert und passt alles zusammen. Danke. 
:-)

Frank M. schrieb:
> Um Frieden zu halten …

Frieden ist gut! Danke. :-)

[Joachim B. (jar)]

Joachim B. schrieb:
> eventuell doch ein Timingproblem, aber 0 und 1 sollte doch verschieden
> ausfallen,

so zurück zu meinem m1284p Problemchen mit FastLED

mal ein Bild,
gelb vom m328p die 30µs für 24 Bit ganz gut eingehalten 4µs/DIV x 7
weiss vom m1284p die 30µs für 24 Bit nicht mehr eingehalten 4µs/DIV x 
8,x

warum ist der m1284p so lahm, liegts am 3 Programcounter REG ? wegen 
128k flash?


Torsten C. schrieb:
> Ich kenne zwar den ATMega auch ganz gut, aber mit den Bibliotheken und
> wie sich die gegenseitig stören, da kann ich kaum helfen. Warum
> "NEOPIXEL" und nicht "WS2812"

weils am m328p geht

> * Interrupts nicht ausgeschaltet?
> * Mal alle andere Programmteile deaktiviert und nur WS2812 ausprobiert?

im Demo Blink ist nix drin, hatte ja den Sketch gezeigt

> * Mal WS2812 per SPI in Erwägung gezogen?

müsste ich mal, aber dafür Arduino LIB ?

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> gelb vom m328p die 30µs für 24 Bit ganz gut eingehalten 4µs/DIV x 7
> weiss vom m1284p die 30µs für 24 Bit nicht mehr eingehalten 4µs/DIV x
> 8,x

Ich blicke durch "lib8tion.h" noch nicht durch. Ist das Timing per 
asm("..."); umgesetzt? Wirkt sich eine Veränderung der 
Compiler-Optimierung aus?

Alternative: Mal an "F_CPU" herumschrauben (und sei es nur, um die 
Ursache einzukreisen). Einen "Dreisatz" kannst Du ja aus dem 
"m1284p_timing.jpg" berechnen.

> weils am m328p geht

Ich hatte inzwischen auch selbst geschaut und konnte keinen Unterschied 
im Timing erkennen, sieht so aus, wie ein anderes Farbmodell, aber das 
sollte erstmal egal sein.

> im Demo Blink ist nix drin, hatte ja den Sketch gezeigt

Ja, sorry, zu spät gesehen.

>> * Mal WS2812 per SPI in Erwägung gezogen?
> müsste ich mal, aber dafür Arduino LIB ?

Nein, war von mir auch noch nicht ganz zuende gedacht, sorry.

[Frank M. (ukw) (Moderator)]

@Herbert:

Ich benutze die tables.h und display.h mit der Version

      WC24h_18x16_V2_2010_2003_15_Dez_2014, CodeGen v0.09

Gibts da was neueres? Da sind nämlich immer noch Fehler drin oder ich 
interpretiere die Mode-Tabelle falsch:

Nehmen wir mal die Uhrzeit 12:45.

Mode 6 Ossi:

    http://uclock.de/?x=6&h=12&m=45

Falsch:  "viertel vor eins"
Richtig: "dreiviertel eins".

Mode 8 Ösi:

    http://uclock.de/?x=8&h=12&m=45

Es wird "dreiviertel eins" ausgegeben. Ist das korrekt für Ösi?

Mode 10 Rhein/Ruht:

Falsch:  "dreiviertel eins"
Richtig: "viertel vor eins".

Jetzt dieselben Modes für "12:40":

Mode 6 Ossi:

    http://uclock.de/?x=6&h=11&m=40

Falsch:  "es ist minuten nach halb zehn zwölf"
Richtig: "es ist zehn minuten nach halb zwölf"

Das ist aber nur eine falsche Auswahl des Wortes "zehn" und ein ganz 
anderer Fehler.

Mode 8 Ösi:

    http://uclock.de/?x=8&h=11&m=40

Das richtig aus, obwohl ich mir nicht sicher bin, wie die Österreicher 
die Uhrzeit ansagen.

Mode 10 Rhein/Ruhr:

    http://uclock.de/?x=10&h=11&m=40

Das ist ebenso korrekt.

Ich dachte erst, dass ich mal wieder irgendwo eine Verschiebung um eins 
in meinem Programm habe. Dem scheint aber nicht so zu sein, denn für 
12:40 stimmt (fast) alles - bis auf die eine Anzeige der falschen 
"zehn".

Jedoch scheinst Du "viertel nach/vor" in den jeweiligen Sprachvarianten 
Ossi und Rhein/Ruhr vertauscht zu haben?!?

Hier nochmal zur Klarheit die Systematik für Viertel:

12:15  Wessi         viertel nach zwölf
12:45  Wessi         viertel vor eins

12:15  Rhein/Ruhr    viertel nach zwölf
12:45  Rhein/Ruhr    viertel vor eins

12:15  Ossi          viertel eins
12:45  Ossi          dreiviertel eins

12:15  Schwaben      hier wie Ossi
12:45  Schwaben      hier wie Ossi

Ossi und Rhein/Ruhr scheint bzgl. "viertel" vertauscht zu sein, siehe 
oben.

Jetzt nochmal die Systematik für Zwanzig:

12:20  Wessi         zehn vor halb eins
12:40  Wessi         zehn nach halb eins

12:20  Rhein-Ruhr    zwanzig nach
12:40  Rhein/Ruhr    zwanzig vor

12:20  Ossi          zehn vor halb eins
12:40  Ossi          zehn nach halb eins

12:20  Schwaben      hier wie Wessi
12:40  Schwaben      hier wie Wessi

Die Schwaben verhalten sich also einmal wie Ossi (für viertel) und 
einmal wie Rhein/Ruhr (für zwanzig).

Zu dem Ösi-Modus kann ich nichts sagen, daher weiß ich nicht, ob obiges 
korrekt ist.

[Joachim B. (jar)]

Torsten C. schrieb:
> Alternative: Mal an "F_CPU" herumschrauben (und sei es nur, um die
> Ursache einzukreisen). Einen "Dreisatz" kannst Du ja aus dem
> "m1284p_timing.jpg" berechnen.

hatte ich versucht, ohne Erfolg

mit F_CPU 15000000 und F_CPU 17000000



aber nun einen 18,432 MHz Quarz eingelötet und es geht!
war zu erwarten ca. 10% schneller und so werden aus 33µs was schief geht 
30µs was passt

Die Pulslänge ist genau wie beim m328p

nun bleibt es spannend, klappt die Komunikation noch mit dem PC?

[Frank M. (ukw) (Moderator)]

Joachim B. schrieb:
> aber nun einen 18,432 MHz Quarz eingelötet und es geht!

Lese ich das richtig? Du verwendest einen 18,432 MHz Quarz und dabei 
F_CPU von 16000?

> war zu erwarten ca. 10% schneller und so werden aus 33µs was schief geht
> 30µs was passt

So gehts auch. Kannst Du nicht einfach die Timingkonstanten im Programm 
anpassen? Oder kommst Du da nicht dran, weils eine "geheime" Arduino-Lib 
ist?

> nun bleibt es spannend, klappt die Komunikation noch mit dem PC?

Da wirst Du F_CPU dann wieder auf 16 zurückbiegen müssen. Könntest Du 
vielleicht mit

#undef F_CPU
#define F_CPU 16000000L

machen. Aber mir würden bei solchen Tricks die Fußnägel automatisch 
hochrollen. ;-)

[Joachim B. (jar)]

Frank M. schrieb:
> So gehts auch. Kannst Du nicht einfach die Timingkonstanten im Programm
> anpassen? Oder kommst Du da nicht dran, weils eine "geheime" Arduino-Lib
> ist?

wenn ich die ganze Arduino LIB durchschauen würde vielleicht, ist ja 
bitbanging und in C++ wo ich keinen Plan habe!

Frank M. schrieb:
> Da wirst Du F_CPU dann wieder auf 16 zurückbiegen müssen. Könntest Du
> vielleicht mit
> #undef F_CPU
> #define F_CPU 16000000L

wäre so ne Idee, was aber krank ist

Frank M. schrieb:
> Aber mir würden bei solchen Tricks die Fußnägel automatisch
> hochrollen. ;-)

mir irgendwie auch

natürlich klappt die PC Komunikation jetzt nicht mehr, wie sollte es 
auch weil der Code für 16MHz compiliert wurde......

eigentlich wäre mir im bitbanging ein #define lieber,

#if defined(__AVR_ATmega1284P__)
// hier die für den m1284p modifizierten bit bang routinen
#else
// hier die vorigen bit bang routinen
#endif

[Torsten C. (torsten_c)]

Frank M. schrieb:
> WC24h_18x16_V2_2010_2003_15_Dez_2014, CodeGen v0.09
> Gibts da was neueres?

Warte, ich schau mal:

http://www.mikrocontroller.net/articles/Datei:WC24h_18x16_V2_Office_2010.zip

Nein, inhaltlich hat sich Nix geändert, nur "Bugfix tbl_minutes; 
tbl_word Feld 'text' indiziert ohne Whg."

Frank M. schrieb:
> Ich dachte erst, dass ich mal wieder irgendwo eine Verschiebung um eins
> in meinem Programm habe.

Wenn Dein Browser dabei nicht abschmiert, kannst Du zum Vergleich auch 
die Horror-Seite nehmen:

https://rawgit.com/TorstenC/1a59b9c73730eb8e144d/raw/WC24h_18x16_Test.html#M7T2145

Dda steht auch
* "VIERTEL VOR EINS" und
* "Version: WC24h_18x16_V2_2010_2003_15_Dez_2014"

Also: Keine Verschiebung um eins

[Joachim B. (jar)]

Joachim B. schrieb:
> eigentlich wäre mir im bitbanging ein #define lieber,

habe auf github mal dem autor geschrieben, mal sehen......

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> wenn ich die ganze Arduino LIB durchschauen würde vielleicht, ist ja
> bitbanging und in C++ wo ich keinen Plan habe!

Ich habe das ZIP nicht ausgepackt, ist das diese hier?

https://github.com/FastLED/FastLED/blob/master/clockless2.h

for(register uint32_t i = 7; i > 0; i--) {
    SET2_HI; delaycycles<3>(); SET2_HI2;
    delaycycles<T1 - 6>(); // 6 cycles - 1/1 store, 1/1 test, 1/1 if, 1/1 port lookup
    if(b & 0x80) { SET2_HI; } else { SET2_LO; }
    if(c & 0x80) { SET2_HI2; } else { SET2_LO2; }
    b <<= 1; c <<=1;
    delaycycles<T2 - 8>(); // 3 cycles, 1/1 store, 1/1 store/skip, 1/1 shift , 1/1 port lookup
    SET2_LO; SET2_LO2;
    delaycycles<T3 - 6>(); // 4 cycles, 1/1 store, 1 sub, 1 branch backwards, 1/1 port lookup
}
// extra delay because branch is faster falling through
delaycycles<1>();

Das Timing wird hier in "delaycycles" per asm("..."); korrigiert und die 
Compiler-Optimierung hat m.E. durchaus einen Einfluss auf das Timing, 
wenn ich das richtig verstanden habe.

Wie wirkt sich denn nun eine Veränderung der Compiler-Optimierung aus? 
Oder hast Du das noch nicht ausprobiert? Oder ist das in der Arduino-IDE 
nicht vorgesehen?

Im o.g. Code kann man das Timing m.E. korrigieren. Jetzt müsste man noch 
schauen, wie man das elegant geht mit

#if defined(__AVR_ATmega1284P__)
// hier die für den m1284p modifizierten bit bang routinen
#else
// hier die vorigen bit bang routinen
#endif

[Joachim B. (jar)]

Joachim B. schrieb:
> habe auf github mal dem autor geschrieben, mal sehen......

natürlich habe ich unwissend wie ich bin dem github service geschrieben, 
nix zu sehen wo man dem Autor schreiben kann.....


ist das nervig

auch am Code rumpfuschen hat mich noch nicht richtig weitergebracht:

Original:
// Adjust the timer
long microsTaken = nLeds x CLKS_TO_MICROS(24 x (T1 + T2 + T3));

Fälschung:
// Adjust the timer
long microsTaken = (11 x nLeds x CLKS_TO_MICROS(24 x (T1 + T2 + 
T3)))/10;

also 11/10 für 10% schneller

sah erst vielversprechned aus, aber nicht wirklich, Länge unverändert, 
Treffer zufällig

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> Original:
> // Adjust the timer
> long microsTaken = nLeds * CLKS_TO_MICROS(24 * (T1 + T2 + T3));

Das ist m.E. nur die berechnete Zeit, für die Übertragung gebraucht 
wird. Da die Interrups so lange inaktiviert werden, zählt der 
System-Timer nicht weiter und die Zeit muss hinterher korrekt addiert 
werden - wenn ich den Code richtig verstanden habe.

Mein vorheriger Beitrag kam gleichzeitig. Gesehen?

[Joachim B. (jar)]

Torsten C. schrieb:
> Das Timing wird hier in "delaycycles" per asm("..."); korrigiert

wenn ich cpp verstehen würde könnte ich selber fummeln.....

Torsten C. schrieb:
> Wie wirkt sich denn nun eine Veränderung der Compiler-Optimierung aus?
> Oder hast Du das noch nicht ausprobiert? Oder ist das in der Arduino-IDE
> nicht vorgesehen?

ist in der Arduino-IDE nicht vorgesehen

Torsten C. schrieb:
> Im o.g. Code kann man das Timing m.E. korrigieren. Jetzt müsste man noch
> schauen, wie man das elegant geht

das ist ja von mir

#if defined(_AVR_ATmega1284P_)
// hier die für den m1284p modifizierten bit bang routinen
#else
// hier die vorigen bit bang routinen
#endif

nur wie modifiziere ich passend? da blicke ich am source nicht durch

und es gibt zwei clockless2.h & clockless.h und noch viel mehr was 
ineinander greift.

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> nur wie modifiziere ich passend?

#define NOP __asm__ __volatile__ ("cp r0,r0\n");
#define NOP2 __asm__ __volatile__ ("rjmp .+0");

template<> __attribute__((always_inline)) inline void delaycycles<-6>() {}
template<> __attribute__((always_inline)) inline void delaycycles<-5>() {}
template<> __attribute__((always_inline)) inline void delaycycles<-4>() {}
template<> __attribute__((always_inline)) inline void delaycycles<-3>() {}
template<> __attribute__((always_inline)) inline void delaycycles<-2>() {}
template<> __attribute__((always_inline)) inline void delaycycles<-1>() {}
template<> __attribute__((always_inline)) inline void delaycycles<0>() {}
template<> __attribute__((always_inline)) inline void delaycycles<1>() {NOP;}
template<> __attribute__((always_inline)) inline void delaycycles<2>() {NOP2;}
template<> __attribute__((always_inline)) inline void delaycycles<3>() {NOP;NOP2;}
template<> __attribute__((always_inline)) inline void delaycycles<4>() {NOP2;NOP2;}
template<> __attribute__((always_inline)) inline void delaycycles<5>() {NOP2;NOP2;NOP;}

delaycycles<T1 - 6>() heißt z.B., wenn T1 == 8, dann baue per 
Inline-Assembler zwei (=8-6)Takte Verzögerung ein.

Hier hast Du viele Zahlen zum Spielen, da kommen in clockless2.h leider 
noch viele weitere:

SET2_HI; delaycycles<3>(); SET2_HI2;
delaycycles<T1 - 6>();
delaycycles<T2 - 8>();
delaycycles<T3 - 6>();

PS: Wobei man die Ausgabe nur bei positiven Zahlen beschleunigen kann. 
Bei <0>, <-1>, <-2>, … hat man keinen Effekt durch Veränderungen.

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:

> template<> __attribute__((always_inline)) inline void delaycycles<-6>()

Gruselig.

Beachtet der Code eigentlich irgendwo F_CPU? Wenn sowieso nicht, sollte 
Joachim tatsächlich mit 18,432 MHz arbeiten und diesen Wert dann auch 
projektweit in F_CPU angeben. Dann läuft der andere Code drumherum 
wenigstens auch.

Ich sehe schon: Ein ATmega für dieses Vorhaben und dazu noch ein nicht 
beherrschbarer fremder Code... das kann nicht gutgehen.

Sorry Joachim, ich bin da einfach skeptisch - auch wenn ich Dir das 
beste für Dein Vorhaben wünsche.

[Joachim B. (jar)]

Frank M. schrieb:
> Beachtet der Code eigentlich irgendwo F_CPU?

braucht er eigentlich nicht, alle AVR Arduino laufen mit 16MHz
aber das Macro F_CPU gibt es, warum die das nicht nutzen? keine Ahnung

Frank M. schrieb:
> auch wenn ich Dir das
> beste für Dein Vorhaben wünsche.

danke danke, ich wurschtel mich schon durch

Torsten C. schrieb:
> delaycycles<T1 - 6>() heißt z.B., wenn T1 == 8, dann baue per
> Inline-Assembler zwei (=8-6)Takte Verzögerung ein.

ah danke das hilft schon mal

deswegen hat auch eine Änderung von
delaycycles<T1 - 6>() auf
delaycycles<T1 - 7>() nix gebracht

ich dachte doch glatt wenn ich einen delay cycle mehr abziehe wirds 
schneller

hat aber überhaupt nix bewirkt, komisch

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> deswegen hat auch eine Änderung von
> delaycycles<T1 - 6>() auf
> delaycycles<T1 - 7>() nix gebracht

Wenn T1 nicht größer als 6 ist, bringt das nix mehr. Genau. Hast Du die 
verwendeten Werte für T1, T2, ... schon herausgefunden?

[Joachim B. (jar)]

Torsten C. schrieb:
> Wenn T1 nicht größer als 6 ist, bringt das nix mehr. Genau. Hast Du die
> verwendeten Werte für T1, T2, ... schon herausgefunden?

nö und ich lasse das auch

Tim CPLD hat ja nun auch für die Arduino eine LIB gemacht und die LÄUFT 
!!!

gerade eben blink Test gestartet......


https://github.com/cpldcpu/light_ws2812
Beitrag "Lightweight WS2811/WS2812 Library"

juhu, ich bin weiter nur noch den Source an die neue LIB anpassen.....

mühsam nährt sich das Eichhörnchen, das WE kann kommen.

und ich wollte heute krankfeiern, dicken Kopp, Husten ohne Ende und Nase 
zu

aber daheim hätte ich nie das Timing bemerkt, nie den 18,432MHz Quarz 
ausprobiert.

ist schon gut so!

Danke an alle die mit mir fühlten und Anteil nahmen!

[Herbert P. (herb3472)]

Einfach einmal was zur Aufheiterung:

http://www.susay.de/das-nenn-ich-mal-frei-verdrahtet/

Wünsche Euch noch einen schönen Abend!

[Torsten C. (torsten_c)]

Torsten C. schrieb:
> … Full-HD-Monitor plus "Android TV-Stick".

Solange ich noch kein NUCLEO-F411RE habe, bastel ich mal etwas an der 
Android-Version weiter.

Aber auf das NUCLEO-F411RE freue ich mich auch schon:

dma.DMA_PeripheralBaseAddr = (uint32_t) &(GPIOB->ODR);

Bei der Geschwindigkeit sollte die "Farbtiefe" bei den
1/8-Scan-Kacheln ^^ hoffentlich kein Klemmer mehr sein.

[Frank M. (ukw) (Moderator)]

Neue STM32-Version 0.8 online im Artikel WordClock24h:

Änderungen:

 - Neue IR-Fernbedienungs-Tasten POWER und OK

 - Einbau einer konfigurierbaren "Nachtzeit", in der sich die
   Uhr selbstständig abschaltet

 - Konfiguration des Time-Servers über MCURSES-Monitor

 - Speichern/Laden sämtlicher Konfigurations-Daten in externem EEPROM

 - Initialisierung des ESP8266 verbessert (warten, bis nach PowerOn
   eine WLAN-Verbindung besteht)

 - Aufteilung der Anzeige-Logik und des MCURSES-Monitors auf dsp.c und
   monitor.c

 - Aufteilung der ESP8266-Routinen auf esp8266.c (low-level) und
   timeserver.c (high-level)

 - Diverse Optimierungen - u.a. durch Einsatz von uint_fast8_t

 - Ein paar kleine Bugfixes

[Frank M. (ukw) (Moderator)]

Frank M. schrieb:
> [1] HSE-PLL konnte trotz RCC_CR_HSEBYP und aller möglichen anderen
> Versuche nicht einrasten. MIT HSI wollte ich mich nicht zufriedengeben,
> da der integrierte Oszillator nicht genügend genau ist.

Heute habe ich das frisch eingetroffene STM32F411er Nucleo-Board 
ausgepackt und angeschlossen. Die WordClock24h-Software für das 411er 
Board (siehe Download im Artikel) lief sofort im HSE-PLL-Modus, ohne 
dass ich irgendeine Lötbrücke umsetzen oder gar einen Quarz einlöten 
musste. Der Takt kommt hier vom ST-Link-Device. Ein Bypass mittels 
RCC_CR_HSEBYP war nicht notwendig.

Das 411er Board hat die Revision "MB1136 C-02". Offenbar klappt das mit 
dem Takt aus dem ST-Link nicht bei den Revisionen "MB1136 C-01", welches 
mein 401er Board hat.

Trotzdem werde ich (wie in der Anleitung im Artikel beschrieben) den 
Quarz einlöten, weil ich das abtrennbare ST-Link-Platinenstück absägen 
werde, damit die Platine (Maße dann 5cm x 7cm) hinter den 
Frontplatten-Rand passt.

[Frank M. (ukw) (Moderator)]

Ich habe gestern abend noch einen Prototyp-Shield für das Nucleo-Board 
auf Lochraster erstellt, siehe Foto.

Insgesamt beträgt die Höhe des Aufbaus 2cm, ist also wie gewünscht sehr 
dünn. Die Breite ist 5cm, die Länge wird beim endgültigen Shield (als 
PCB) ca. 9cm betragen.

Die Breite von 5cm kann nur erreicht werden, wenn der obere Teil des 
Nucleo-Boards (ST-Link-Device) abgetrennt wird (im Foto ist der 
ST-Link-Teil noch vorhanden). Man wird das ST-Link-Device aber wieder 
über ein 6-poliges Kabel ("SWD") anschließen können, damit auch später 
noch Updates eingespielt werden können. Damit passt dann die komplette 
Schaltung bequem hinter den unbeleuchteten Rand der Frontplatte.

Angeschlossen werden können:

 - Externe 5V-Spannungsversorgung für Board/Shield und WS2812 Stripes
 - WS2812 Stripes
 - RTC/EEPROM I2C-Modul
 - TSOP31238 als IR-Empfänger
 - DCF77-Empfänger (optional)
 - ESP8266 als WLAN-Modul mit eigenem 3,3V Spannungsregler (optional)

Wer wäre an einer professionell hergestellten Platine als Shield 
interessiert?

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Wer wäre an einer professionell hergestellten Platine als Shield
> interessiert?

Ja, würde ich auch machen / haben wollen. Vielleicht geht das 
stressfrei. ;-)

Frank M. schrieb:
> Insgesamt beträgt die Höhe des Aufbaus 2cm

Das ist schon mal gut. Was haltet Ihr von "Low Profile Through-Board 
Sockets"?

http://solutions.3m.com.sg/wps/portal/3M/en_SG/InterconnectSingapore/Home/Products/Catalog/?PC_Z7_U00M8B1A083U80A89JEQ3F0I63000000_nid=7NC2KDZ7KMitWK7G49LP38glV3Z9WQHCB8bl

http://solutions.3m.com.sg/wps/portal/3M/en_SG/InterconnectSingapore/Home/Products/Catalog/?PC_Z7_U00M8B1A083U80A89JEQ3F0I63000000_nid=PV9ZR58P38itWK7G49LP38glQVZMZPDNK2bl

Damit das was bringt, müssten in das Shield sicher ein paar 
Ausfräsungen.

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Das ist schon mal gut. Was haltet Ihr von "Low Profile Through-Board
> Sockets"?

Das bringt nichts. Die Steckerleisten auf der Oberseite sind so lang, 
dass der Abstand Board <-> Shield nicht geringer wird. Und die 
Steckerleisten auf der Oberseite auf eine geringere einheitliche(!) Höhe 
pitschen ist ein Abenteuer, auf das ich mich nicht einlassen möchte. Mit 
2cm Höhe liegen wir schon verdammt gut. Außerdem lässt sich der 
Zwischenraum noch für Hühnerfutter wie Widerstände und (liegende) Elkos 
nutzen.

Ich habe diese hier verwendet, weil ich sie gerade herumliegen hatte:

  http://www.reichelt.de/Buchsenleisten/BL-2X10G8-2-54/3/index.html?ACTION=3&GROUPID=3221&ARTICLE=51833

Wenn man 2 davon hintereinander steckt, kommt man auf insgesamt 40 Pins. 
Das Nucleo hat aber nur 38 pro Steckerleiste. So habe ich im Moment 2 
Pins zuviel.

Beim endgültigen PCB würde ich dann 2x12 mit 2x07 (gibts auch bei 
Reichelt) kombinieren. Dann kommt man auf genau 2x19 = 38 Pins.

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Das bringt nichts. Die Steckerleisten auf der Oberseite sind so lang

Darum ja "Ausfräsungen"^^, sonst bringt das wirklich nix. Aber wie Du 
meinst, war ja nur 'ne Frage, damit's flacher wird.

Zur Pin-Belegung:

+-------------------------+-------------------------+-------------------------+
| Device                  | STM32F4 Discovery       | STM32F4x1 Nucleo        |
+-------------------------+-------------------------+-------------------------+
| User button             | GPIO:   PA0             | GPIO:   PC13            |
| Green LED               | GPIO:   PD12            | GPIO:   PA5             |
+-------------------------+-------------------------+-------------------------+
| TSOP38238 (IRMP)        | GPIO:   PC14            | GPIO:   PC10            |
| DCF77                   | GPIO:   PC15            | GPIO:   PC11            |
| MCURSES terminal (USB)  | USB:    OTG             | USART2: TX=PA2  RX=PA3  |
| ESP8266                 | USART2: TX=PA2  RX=PA3  | USART6: TX=PA11 RX=PA12 |
| I2C DS3231 & EEPROM     | I2C3:   SCL=PA8 SDA=PC9 | I2C3:   SCL=PA8 SDA=PC9 |
| WS2812                  | DMA1:   PC6             | DMA1:   PC6             |
+-------------------------+-------------------------+-------------------------+

Können wir ein GPIO-Byte für die China-Kacheln reservieren bzw. auf dem 
PCB herausführen?

Dazu benötigt man 6 Bits "am Stück" für DMA Bit-Blit, aber da immer ein 
ganzes Byte in das ODR*[0..7] beschrieben wird, sind 8 Pins belegt.

Hier kommen in Frage:

* PB0..PB7: VREF+ könnte man lassen, wir nutzen nur PB[0,2,3,…]

* PC0..PC7: TIM3_CH1 (WS2812-DMA1) wäre ja "Exclusiv-Oder", würde
  also nicht kollidieren. DMA für PC[0..5]

Für "Clock" könnten wir ja auch den TIM3_CH1 nehmen, PC6 wird doch bei 
"AF02" vom ODRC[0..7] nicht überschrieben, oder?

Output-Enable muss ein weiterer TIM-OC sein, da geht dann TIM3 nicht 
mehr, weil der schon den "Clock" macht.

Bei dem Pin für "Latch-Enable" wäre ich flexibel, vielleicht geht PC7 
(muss ich ausprobieren), dann wäre PC[0..7] komplett.

Spontan gefällt mir "PC0..PC7" am besten: Es wird weniger "Alternate 
function"-Peripherie belegt (Table 9. Alternate function mapping) und 
TIM3_CH1 wird entweder für die WS2812 XOR für den Kachel-Clock belegt.

+-------------------------+-------------------------+-------------------------+
| Device                  | STM32F4 Discovery       | STM32F4x1 Nucleo        |
+-------------------------+-------------------------+-------------------------+
| HUB-75-Interface        |                         | R1: PC0                 |
|                         |                         | G1: PC1                 |
|                         |                         | B1: PC2                 |
|                         |                         | R2: PC3                 |
|                         |                         | G2: PC4                 |
|                         |                         | B2: PC5                 |
|                         |                         | Ck: PC6 (TIM3_CH1)      |
|                         |                         | LE: PC7                 |
|                         |                         | OE: ??  (TIM*_CH*)      |
|                         |                         | A: ??                   |
|                         |                         | B: ??                   |
|                         |                         | C: ??                   |
+-------------------------+-------------------------+-------------------------+

PS:
A..C ergänzt, siehe auch "LINSN-HUB75 Interface" unter
http://www.rayslogic.com/propeller/programming/AdafruitRGB/AdafruitRGB.htm

A..C wären vorzugsweise drei zusammenhängende Bits, dann wird die ISR 
etwas schneller.

PPS:
Die HUB75-Pfostenleiste könnte auch auf die Stirnseite (Kante) des PCB 
gelötet werden, um die Bauhöhe zu verringern. Bei FR4 mit 1,6mm ginge 
das ganz gut.

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Zur Pin-Belegung:

+-------------------------+-------------------------+-------------------------+
| ESP8266                 | USART2: TX=PA2  RX=PA3  | USART6: TX=PA11 RX=PA12 |
+-------------------------+-------------------------+-------------------------+

Nur zur Info:
Diese Zeile habe ich für Version 0.9 mittlerweile erweitert:

+-------------------------+---------------------------+---------------------------+
| Device                  | STM32F4 Discovery         | STM32F4x1 Nucleo          |
+-------------------------+---------------------------+---------------------------+
| ESP8266 USART           | USART2: TX=PA2  RX=PA3    | USART6: TX=PA11 RX=PA12   |
| ESP8266 GPIO            | GPIO:   RST=PC5 CH_PD=PC4 | GPIO:   RST=PA7 CH_PD=PA6 |
+-------------------------+---------------------------+---------------------------+

Ich kann nun CH_PD und RST vom ESP8266 steuern. Über CH_PD kann ich den 
ESP8266 in den Schlafzustand bringen. Dann verringert sich der bisherige 
Stromverbrauch von ca. 200mA beträchtlich. Das macht die 0.9er Software 
bereits in den (konfigurierbaren) Nachtstunden, wenn sich die Uhr 
automatisch abschaltet.

RST wird verwendet, um den ESP8266 zu resetten, wenn der sich mal wieder 
in einer Busy-Schleife aufgehängt hat.

> Können wir ein GPIO-Byte für die China-Kacheln reservieren bzw. auf dem
> PCB herausführen?

Klar, das Nucleo hat ja genügend ;-)

> * PC0..PC7: TIM3_CH1 (WS2812-DMA1) wäre ja "Exclusiv-Oder", würde
>   also nicht kollidieren. DMA für PC[0..5]

PC0..PC7 gefällt mir am besten.

> Für "Clock" könnten wir ja auch den TIM3_CH1 nehmen, PC6 wird doch bei
> "AF02" vom ODRC[0..7] nicht überschrieben, oder?

Keine Ahnung, müsstest Du mal testen.

> Bei dem Pin für "Latch-Enable" wäre ich flexibel, vielleicht geht PC7
> (muss ich ausprobieren), dann wäre PC[0..7] komplett.

Gut.

> Spontan gefällt mir "PC0..PC7" am besten:

Sehe ich genauso.

> Die HUB75-Pfostenleiste könnte auch auf die Stirnseite (Kante) des PCB
> gelötet werden, um die Bauhöhe zu verringern. Bei FR4 mit 1,6mm ginge
> das ganz gut.

Okay, warum nicht. Sind 0,8mm nicht ein ungewöhnliches Raster für 
Flachbandkabel? Sorry, ich verwende immer Kabel mit 1,27 Raster, d.h. 
die Steckerleisten haben für mich gewöhnliche 2,54 mm.

[Torsten C. (torsten_c)]

Gut, RST=PA7 CH_PD=PA6 stören ja nicht und Reset ist auch gut! :-)

Frank M. schrieb:
> die Steckerleisten haben für mich gewöhnliche 2,54 mm.

Das passt auch. Hub-75 hat die ganz normalen doppelreihigen 
2,54mm-Pfostenleisten.

Wenn man die Stiftdicke von 0.63mm abzieht, bleiben 1,91mm Zwischenraum. 
Mit "Stirnseite" ^^ meinte ich, die Platinen-Kante in diesen 
Zwischenraum zu schieben und die Stifte SMT zu verlöten. Die Differenz 
1,91mm - 1,60mm = 0,31mm verteilen sich auf beide Seiten (Top/Bottom).

Mit "Bei FR4 mit 1,6mm ginge das ganz gut." ^^ meinte ich, es müssen 
jeweils nur 0.155mm mit Lötzinn "überbrückt" werden. Man kann auch die 
vier Pins in den Ecken etwas zusammen biegen, damit die Pfostenleiste 
zum Verlöten etwas fixiert ist. Beim Verbau am besten eine 
Dummy-Buchsenkeiste aufstecken, damit sich nix verbiegt oder verschmort.

Oder wäre das "schlimmes Gebastel"? Dann ginge auch eine 
Winkel-Stiftleiste.

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Oder wäre das "schlimmes Gebastel"?

Finde ich schon schlimm ;-)

> Dann ginge auch eine Winkel-Stiftleiste.

Ja, genau danach habe ich eben mal bei Reichelt geschaut:

    http://www.reichelt.de/index.html?ACTION=3;ARTICLE=19489;SEARCH=SL%202X10W%202,54

Die kürzeste, die sie haben, ist 10 Pins lang, also 2x10. Aber man kann 
die Steckerleiste durchaus mit dem Messer kürzen... klack.

Ich schaue aber mal, ob ich diese noch an den Seiten unterbringe.

Im Anhang findest Du das PCB, an dem ich mich zur Zeit versuche. Wundere 
Dich nicht, dass einige Stiftleisten stehend zu sehen sind. Das liegt 
daran, dass Target diese nicht in 3D-Sicht hat. Die Kondensatoren werde 
ich auch noch durch liegende ersetzen.

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Dann ginge auch eine Winkel-Stiftleiste.

Ich habe mal eine stehende (K10) eingebaut, da ich kein 3D-Modell für 
eine abgewinkelte habe. Du musst Dir K10 also einfach als gewinkelte 
vorstellen ;-)

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Du musst Dir K10 also einfach als gewinkelte
> vorstellen

Ja cool, auch der Ausschnitt gefällt mir. A, B und C müssen wir noch 
festlegen.

Nochmal was anderes: Die Android-Version blendet die Buchstaben schon 
fein ein und aus, das geht prima mit der Property-Animation-API:
http://developer.android.com/guide/topics/graphics/prop-animation.html

tables.h und display.h kann Java so nicht lesen, auch sollen die Daten 
bei Android ja nicht im ROM stehen. Ich generiere daher einen 
JSON-String. Mein erster Versuch war ziemlich "aufgebläht". Ich mache 
den String nun etwas schlanker (Array[…] statt Objekt{…}), falls man 
später mal per ESP8266 die Tabellen dynamisch per HTTP laden möchte.

@Hans H. (loetkolben):

Vielleicht wäre das auch was für den Screensaver, dann muss der
nicht immer neu compiliert werden, sondern lädt eine JSON-Datei,
die im cmd-File übergeben wird (lokal oder per HTTP z.B.
aus http://cdn.rawgit.com).

Oops, ich sehe gerade, ich muss die URLs im Wiki mal anpassen auf das 
Format:

  "cdn.rawgit.com/user/repo/tag/file"

[Joachim B. (jar)]

Frank M. schrieb:
> Da wirst Du F_CPU dann wieder auf 16 zurückbiegen müssen. Könntest Du
> vielleicht mit#undef F_CPU
> #define F_CPU 16000000L
>
> machen. Aber mir würden bei solchen Tricks die Fußnägel automatisch
> hochrollen. ;-)

du wirst lachen, diese Idee verhalf mir zumindest zu einem patch

Klar ist das Problem nicht gelöst, es liegt definitiv am FastLED

ich maile ja schon mit dem Autor, aber der kommt nicht so aus dem Knick

1. Begründung, es gibt keine m1284p Arduinos
2. Begründung er macht viel zu viel als das er den bit bang code 
tauschen könnte
3. Begründung er hat keinen m1284p

so nun mit Franks Trick

also mein m1284p hat wieder den 16MHz Quarz und abeitet so wie er soll 
ausser im bitbang der ws2812b Ansteuerung, die ist pro LED immer noch 
10% zu lahm, also eingefügt:

#if defined(_AVR_ATmega1284P_)
#undef F_CPU
#define F_CPU 14400000
#endif

mal eben diese CPU für 10% lahmer erklärt und es läuft genau wie auf dem 
m328p

nur weiss ich grad noch nicht wo noch Nebenefekte auftreten können?

Nokia 5110 Display störts nicht
na meiner I2C Tastaturabfrage auch nicht, ob die nun alle 9ms oder 10ms 
oder 11ms efolgt ist ja egal, dem I2C Timing scheints auch nicht zu 
stören,

sogar Franks IRMP kommt damit zurecht

und auch serial print mit 38400 Bd

da ich keine Soft Uhr habe sondern 3x pro Sekunde die RTC lese und das 
LCD update merke ich bis jetzt nix.

[Frank M. (ukw) (Moderator)]

Joachim B. schrieb:
> #if defined(_AVR_ATmega1284P_)
> #undef F_CPU
> #define F_CPU 14400000
> #endif

Wo hast Du das denn definiert? Nur in dem Source-Modul, welches auf 
die LEDs zugreift?

> sogar Franks IRMP kommt damit zurecht

Wo wird der IRMP-Timer definiert? Auch in dem Source-Modul, wo Du F_CPU 
runtergesetzt hast?

Wenn ja:

Das ist heftig. IRMP arbeitet aber bei allen IR-Protokollen mit 
Toleranzen zwischen 5% und 40% - je nachdem, wie stark bzw. wie wenig 
die Timings mit anderen Protokollen konkurrieren, also ein Konflikt 
entstehen könnte.

Wenn nein:

Dann ist alles in Ordnung und IRMP läuft optimal ;-)

> und auch serial print mit 38400 Bd

Ja, klar, das ist ja ein externes Modul, wo die UART-Parameter 
ausgerechnet werden. Das bekommt von Deinem F_CPU-Patch nichts mit.

Wie gesagt: Du solltest dafür sorgen, dass Dein F_CPU-Patch nur in dem 
Modul ist, wo Du die LEDs ansteuerst. Ich glaube aber nicht, dass Du 
alles in einen großen Source geklatscht hast ;-)

[Joachim B. (jar)]

Frank M. schrieb:
> Joachim B. schrieb:
>> #if defined(AVR_ATmega1284P)
>> #undef F_CPU
>> #define F_CPU 14400000
>> #endif
>
> Wo hast Du das denn definiert? Nur in dem Source-Modul, welches auf
> die LEDs zugreift?

nein, in meinem Source Code!

Frank M. schrieb:
> Wenn ja:
>
> Das ist heftig. IRMP arbeitet aber bei allen IR-Protokollen mit
> Toleranzen zwischen 5% und 40% - je nachdem, wie stark bzw. wie wenig
> die Timings mit anderen Protokollen konkurrieren, also ein Konflikt
> entstehen könnte.

ist mir klar, ich grübel schon ob ich einen workaround zum workaround 
mache also überall F_CPU + Korrektur einfüge.......
aber bis jetzt arbeitet ja nur die WS Fernsteuerung NEC_Protokoll da und 
mehr solls nicht werden weil ich diese FB ja mit meiner wordclock 
nutze(n will)

Frank M. schrieb:
> Ja, klar, das ist ja ein externes Modul, wo die UART-Parameter
> ausgerechnet werden. Das bekommt von Deinem F_CPU-Patch nichts mit.

das war mir nicht klar.....

Frank M. schrieb:
> Wie gesagt: Du solltest dafür sorgen, dass Dein F_CPU-Patch nur in dem
> Modul ist, wo Du die LEDs ansteuerst.

dazu müsste ich fastLED patchen?

das ist mir leider so umfangreich das ich nicht durchblicke zumal ich 
kein CPP kann, sonst hätte ich längst den bitbang code getauscht, 
irgendwo muss doch die aufbereitete LED Data rausgejagt werden und Tim 
hier CPLDCPU schafft es ja auch im Timing perfekt für den m1284p mit 
seiner ws2812b LIB nur finde ich nicht den Hebel wo ich das bit bang 
tauschen kann.

Ich war drauf und drann alles auf die ws2812 LIB umzuschreiben aber die 
fastLED ist einfach userfreundlicher, ein set brightness arbeitet sofort 
perfekt auf alle Farben und RGB zu HSV läuft auch bestens im 
Hintergrund.

[Frank M. (ukw) (Moderator)]

Joachim B. schrieb:
> nein, in meinem Source Code!

Ist das eine große C++-Datei? Sorry, ich weiß nicht, wie Dein Source 
Code aufgebaut ist.

> aber bis jetzt arbeitet ja nur die WS Fernsteuerung NEC_Protokoll da und
> mehr solls nicht werden weil ich diese FB ja mit meiner wordclock
> nutze(n will)

NEC ist ziemlich unproblematisch. IRMP arbeitet bei NEC mit 30% 
Toleranz.

> Frank M. schrieb:
>> Wie gesagt: Du solltest dafür sorgen, dass Dein F_CPU-Patch nur in dem
>> Modul ist, wo Du die LEDs ansteuerst.
>
> dazu müsste ich fastLED patchen?

Keine Ahnung, ich weiß ja nicht, wo das Timing ausgerechnet wird.

> Ich war drauf und drann alles auf die ws2812 LIB umzuschreiben aber die
> fastLED ist einfach userfreundlicher, ein set brightness arbeitet sofort
> perfekt auf alle Farben und RGB zu HSV läuft auch bestens im
> Hintergrund.

Hm, dann lass es doch erstmal so und konzentriere Dich auf andere Dinge, 
die für die Uhr erledigt werden müssen. Kommt Zeit, kommt Rat ;-)

[Joachim B. (jar)]

Frank M. schrieb:
> Keine Ahnung, ich weiß ja nicht, wo das Timing ausgerechnet wird.

ich doch auch nicht

Frank M. schrieb:
> Ist das eine große C++-Datei? Sorry, ich weiß nicht, wie Dein Source
> Code aufgebaut ist.

wenn du schauen magst?

Frank M. schrieb:
> Hm, dann lass es doch erstmal so und konzentriere Dich auf andere Dinge,
> die für die Uhr erledigt werden müssen. Kommt Zeit, kommt Rat ;-)

ist auch mein Gedanke

jetzt wo fastLED, RTC, I2C Tastatur, Nokia 5110 Display, IRMP läuft

Binäre Sketchgröße: 26.956 Bytes (von einem Maximum von 130.048 Bytes)

fastLED_ws2812_ok.cpp.elf
   text    data     bss     dec     hex filename
  26540     416     958   27914    6d0a

noch genug flash und Ram frei

kann ich endlich mit ESP 8266 für NTP und DCF77 weitermachen

ach noch 2 Bildchen

[Torsten C. (torsten_c)]

Torsten C. schrieb:
> A, B und C müssen wir noch festlegen.
Frank M. schrieb:
> Keine Ahnung, müsstest Du mal testen.

@Frank:
Ich habe meine Mouser-Bestellung mit dem STM32F411RE-Nucleo noch nicht 
abgeschickt. Wie dringend ist meine finale Pin-Festlegung? Wenn das 
Board da ist, brauche ich noch etwa ´ne Woche, um folgendes zu testen:

Ich habe gerade eine verwegene Idee: A, B, C und LE auch per Timer 
bzw. DMA steuern. Das bedeutet: Ich belege drei Timer, würde dann aber 
IRQs sparen. Aktuell habe ich alle 64 DMA-Bytes einen IRQ. Falls ich 
alle o.g. Signale per DMA und Timer steuern würde, hätte ich nur alle 
512 Bytes einen IRQ. Bei einem 10MHz-Clock hängt der µC bei 64 DMA-Bytes 
ziemlich oft in der ISR. Wäre die Belegung von drei Timern für das 
"low-Level" HUB-75-Interface Dich OK? Bis wann brauchst Du ein Ergebnis?

* 10MHz / 64 = 156 KHz IRQ
* 10MHz / 512 = 20 KHz IRQ

Eine ISR braucht etwa 4µs, es ginge also Beides. Aber bei z.B. 20MHz 
Clock würden die LEDs noch marginal heller leuchten oder der 
Kontrastumfang wäre deutlich größer, je nach Applizierung.

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> Klar ist das Problem nicht gelöst, es liegt definitiv am FastLED

Wolltest Du nicht die Lib von Tim (cpldcpu) nehmen?

BTW: Interessiert der Android-Kram, oder soll ich Euch damit in Ruhe 
lassen?

Die Arduino-Bibliotheken sind ja in C++ und Java und C++ haben eine sehr 
ähnliche Syntax. Vielleicht könnte man fast identischen Code für 
Android, Arduino und STM32 nutzen. Hier mal ein Link zu dem Thema C++, 
nämlich zum xpcc-Projekt:
* http://xpcc.kreatives-chaos.com/api/
* http://xpcc.kreatives-chaos.com/
siehe auch:
* http://wp.me/PCum-qm (meine Notizen dazu)

[Joachim B. (jar)]

Torsten C. schrieb:
> Wolltest Du nicht die Lib von Tim (cpldcpu) nehmen?

wollte ich, aber was bis jetzt läuft gefällt mir mit fastLED besser

in Tims Code blicke ich weniger durch und ich finde es weniger 
komfortabel.

Torsten C. schrieb:
> BTW: Interessiert der Android-Kram, oder soll ich Euch damit in Ruhe
> lassen?

also ich finde Arduino Kram toll weil viele damit was anfangen können.

[Torsten C. (torsten_c)]

> Torsten C. schrieb:
>> BTW: Interessiert der Android-Kram, …?
> also ich finde Arduino Kram toll weil viele damit was anfangen können.

enum Magnitude {
    Mag_little,
    Mag_medium,
    Mag_big
};
if (Android != Arduino) Verwirrung(Mag_big));

Wie gesagt, ich bastel gerade an JSON + Android ,
also 90€ HDTV-Monitor + 15€ Android-TV-Stick incl. Wifi.

JSON kann man natürlich per ESP8266 mit WiFi auch
in den Arduino einlesen. ;-)

Links im Bild ich schrieb:
> … bastel ich mal etwas an der Android-Version weiter.

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> Ich habe meine Mouser-Bestellung mit dem STM32F411RE-Nucleo noch nicht
> abgeschickt. Wie dringend ist meine finale Pin-Festlegung?

Übehaupt nicht dringend. Solange Du Dich nicht festlegst, gibt's halt 
kein PCB als Shield ;-)

> Ich habe gerade eine verwegene Idee: A, B, C und LE auch per Timer
> bzw. DMA steuern.

Du weisst, was ich brauche.

Die Tabelle hast Du ja selber aus main.c zitiert.

DMA ist XOR, d.h. Du hast alle DMA-Kanäle zur Verfügung. Timer brauche 
ich 2 Stück: Einen für WS2812, der ist also auch XOR. Den anderen Timer 
(ist Timer2) brauche ich universell als Zeitscheiben für IRMP, ESP8266, 
DCF77, die Uhr selbst und zum Faden der LEDs. Der ist also nicht frei. 
Die benutzen GPIO-Pins kennst Du ja auch. Eventuell lässt sicher der 
eine oder andere noch umlegen, wenn Du irgendwelche Pins als 
zusammengehörendes Stück benötigst.

> Das bedeutet: Ich belege drei Timer, würde dann aber
> IRQs sparen.

Interessant: Erst warst Du vehement gegen DMA & Timer, jetzt willst Du 
es genauso machen. Gratulation zur Einsicht ;-)

Also: Kannst Du gerne machen. Es gibt ja genügend Timer. Es wäre aber 
dabei weise, wenn Du beim 411er kompatibel zm 401er bleiben würdest, 
also die speziellen 411er Features nicht nutzen würdest.

[Joachim B. (jar)]

so ich kann weitermachen,

für alle die es interessiert:

ich habe ja diese FB gekauft
http://www.dx.com/de/p/24-key-wireless-infrared-ir-remote-controller-for-rgb-led-light-bulb-1-cr2025-47019#.VLpgjiwucck

Sauerei hier mit Empfänger billiger
http://www.ebay.de/itm/24Key-IR-Remote-Controller-Fernbedienung-For-12V-RGB-3528-5050-LED-Leuchten-Neu-/311167993548?pt=DE_M%C3%B6bel_Wohnen_Lampen_Lichtzubeh%C3%B6r&hash=item48730ec6cc

aber egal, das Teil überbrückt sagenhafte 7m! (weiter weg keinen Bock 
zum umbauen) respektabel bei der kleinen Batterie!, sollte also auch für 
große Zimmer reichen.

in Verbindung mit TSOP 31236
http://www.reichelt.de/Fotodioden-etc-/TSOP-31236/3/index.html?ACTION=3&GROUPID=3045&ARTICLE=107208&OFFSET=16&;

ich nehme gerne 36kHz hat bis jetzt optimal alles erwischt von 30-40kHz 
was so bei mir rumfliegt.

Die FB sieht auch interessant aus
http://www.ebay.de/itm/24-44-Key-IR-Remote-Controller-DC-12V-for-RGB-LED-3528-5050-SMD-Strip-Lights-/121195315034?pt=US_Lighting_Parts_and_Accessories&var=&hash=item1c37cdbf5a

44 Keys! und mit den RGB up/down Pfeilen könnte Herbert an seinem LED 
Weissabgleich feilen :-)

mal 4 bestellt und hier billiger gefunden (na egal, kanns verschmerzen)
http://www.ebay.de/itm/24-44-Key-IR-Remote-Controller-DC-12V-for-RGB-LED-3528-5050-SMD-Strip-Lights-/121195315034?pt=US_Lighting_Parts_and_Accessories&var=&hash=item1c37cdbf5a


Den ESP 8266 wlan kann ich noch nicht in Betrieb nehmen, mein RECOM 
R7833 0,5 arbeitet nicht ab 4,4V (wohl zu viele Entkopplungsdioden am 
USB in Serie), der LE33CZ low drop 3,3V Regler arbeitet zwar aber bringt 
die 0,4A für den wlan nicht......

muss ich mir noch was einfallen lassen.

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> Torsten C. schrieb:
>> Joachim B. schrieb:
>>> Ich suche immer noch den Link zu RGB - HSV und umgekehrt Code
>> Bist Du inzwischen fündig geworden?
> ne nicht wirklich, …
Herbert P. schrieb:
> Literatur über … C++ beschafft
Joachim B. schrieb:
> … und in C++ wo ich keinen Plan habe!

Weil C++ viele Vorteile hat (siehe "meine Notizen dazu"^^) und Ihr Euch 
eh damit beschäftigt:

Zum Thema "RGB - HSV":
https://www.c-plusplus.net/forum/viewtopic.php?t=11633#382273

Bei meiner Android-Java-Version probiere ich gerade 
"Color.getHSBColor(…)" aus.

Was auch an C++ genial ist, sind die Bitsets (Mengenlehre aus der 
Schule), die nutze ich in Android-Java auch: Sowohl für "welches Wort 
ist on/off", als auch für "welcher Buchstabe ist on/off". Das ist echt 
eine Erleichterung und der Code ist besser verständlich:

* http://www.cplusplus.com/reference/bitset/bitset/
* http://docs.oracle.com/javase/7/docs/api/java/util/BitSet.html

Bitsets kann man natürlich auch "manuell" implementieren, hier ein 
extrem effizient programmiertes Beispiel:

https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/blob/master/2012/11/13/src/StaticBitSet.java

[Joachim B. (jar)]

Torsten C. schrieb:
> Weil C++ viele Vorteile hat (siehe "meine Notizen dazu"^^) und Ihr Euch
> eh damit beschäftigt:
>
> Zum Thema "RGB - HSV":

ich habe genug andere Baustellen, RGB HSV macht ja das nun bei mir 
funktionierende fastLED

jetzt läuft es, kann schon die Temperatur aus der RTC3231 wieder diesmal 
in Arduino auslesen (früher in pur C meine eigenen I2C Routinen genutzt, 
aber 2 I2C Routinen zu nutzen hat ja kaum Sinn im Arduino) aktuell 
22,5°C

Lichtsensor aktuell 19% steuert schon die LED Helligkeit (schick wenn 
man den Sensor bestrahlt >50% und die LEDs mit 100% zurückstrahlen)
einige LED Spielereien laufen auch wieder
nun noch VCC und V33 auslesen

wenn die 3,3V mit Power 0,3A läuft -> wlan Chip in Betrieb nehmen

hach ist das schön mit 128kB flash und 16 kB Ram (hey ihr STM User nicht 
zu laut schmunzeln, für Arduino oder AVR Nutzung bin ich zufrieden)

Ich wüsste auch noch nicht wie ich die 128k vollbekomme,
vielleicht mit LED Bilder:
Wassertropfen, Wellen auf dem Buchstabenfeld, kleine sinnfreie 
Animationen, Videos, Equilizer (Mic am Arduino), FFT

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> ich habe genug andere Baustellen

Meinst Du damit "C++ == Baustelle?"

Aus der Version für den "Android TV Stick", siehe
Beitrag "Re: China SUPER Bauteile-Schnäppchen Thread" unter 26€:

protected BitSet getOnOffFromTime(int hour, int minute) {
    BitSet result = this.minuteWords[this.currentMode][minute];
    if (this.hourOffsets[this.currentMode][minute]) hour += 1;
    result.or(this.hourWords[this.currentMode][hour]);
    return result;
}

Ohne BitSets sähe das anders aus.

Ich will hier niemanden bekehren! Das ist nur mal zum Nachdenken.

[Joachim B. (jar)]

Torsten C. schrieb:
> Ich will hier niemanden bekehren!

no problem, das haben nur wenige geschafft und nicht in Religion :-)

jedenfalls liefert der billig RTC aus China jetzt auch unter Arduino die 
richtige Temperatur, mit Kältespray getestet :-)

ist ein nettes Gadget, weniger für die Uhr (wir haben keine Buchstaben 
für die Temperatur über und ein (Nokia5110) Display will ja keiner oder?
(wozu Temperatur? man kann sogar die RTC nach Temperatur kallibrieren!)

aber wenn ich es auf meinem Testboard schon mal habe.......


Die Ribba 50x50 sind auch gekauft, könnte ja mal die 32 x 32 Kacheln 
einsetzen, es geht voran.

Nächste Baustelle DCF77

[Joachim B. (jar)]

kann mal einer der C-Progger rüberschauen?

ich tue mich mit Vorzeichen (MSB) von vorzeichenbehafteten 10 Bit Zahlen 
etwas schwer.

Function trimm_string(); verlängert die Zeichenkette auf n Zeichen für 
LCD Ausgabe hier maximal 3 Zeichen erwartet, führendes Zeichen ist ein 
SPACE = ' '
Function insert_char(); fügt an Stelle n ein Komma ein, hier an 2ter 
Stelle

Die Uhr liefert binär 1/4°C, mir genügt als Anzeige 1/10

sollte links vom Komma ein ' ' SPACE sein wird das zur '0' ersetzt

Die Funktion kann auch in pur C am Compiler eingesetzt werden (Atmel AVR 
Studio mit I2C Lib)

//#define AGING_OFFSET    16 // 10H SIGN DATA DATA DATA DATA DATA DATA DATA Aging Offset
#define MSB_TEMP    17 // 11H SIGN DATA DATA DATA DATA DATA DATA DATA MSB of Temp
#define LSB_TEMP    18 // 12H DATA DATA 0 0 0 0 0 0 LSB of Temp
#define DS1307_ID               0x68

#if defined(ARDUINO) && ARDUINO >= 100 // ist nicht von mir sieht falsch aus weil wenn nicht ARDUINO wieso ELSE?
  #define printIIC(args) Wire.write((uint8_t)args)
  #define readIIC() Wire.read()
#else
  #define printIIC(args) Wire.send(args)
  #define readIIC() Wire.receive()
#endif


char *temperatur_str_rtc(BYTE offset) // BYTE auf neudeutsch int8_t
{ static double _rtc_temp=0.0;
  static char _rtc_temp_str[5]={0};
  char s[6]={0};
  char *komma;
  WORD __temp=0; // WORD auf neudeutsch int16_t

#if (ARDUINO>0)
#if (ARDUINO <  100)
  /*__temp = Wire.receive();*/ ####error
#else                 
  if(test_flags&(1<<RTC_3231)) 
  {
    Wire.beginTransmission(DS1307_ID);
    printIIC(MSB_TEMP);
    Wire.endTransmission(); // ggffs. var _error einfügen -> _error = Wire.endTransmission();
    Wire.requestFrom( ( DS1307_ID ), 2);       // request secs, min, hour, dow, day, month, year
    __temp = (readIIC() & 0x00ff);       
    __temp <<= 8;      
    __temp |= (readIIC() & 0x00ff);              
  }
#endif
#else
  i2c_start_wait(DS3231+I2C_WRITE);  // set device address and write mode
  i2c_write(MSB_TEMP);
  i2c_rep_start(DS3231+I2C_READ);     // set device address and read mode
  __temp=i2c_readAck();
  __temp<<=8;
  __temp|=i2c_readNak();
  i2c_stop();
#endif
  __temp>>=6;

  (__temp>511) ? strcpy(_rtc_temp_str, "-") : strcpy(_rtc_temp_str, " ");
  (__temp>511) ? __temp-=1024 : __temp+=0;
  _rtc_temp=__temp*2.5;
  strcat(_rtc_temp_str, insert_char( trimm_string(' ',itoa( (UWORD)( _rtc_temp+(offset*10)),  s, 10), 3 ), ',', 2));
  komma=strstr(_rtc_temp_str, ",");
  komma--;
  if(*komma==' ')
    *komma='0';
  return _rtc_temp_str;
}

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> kann mal einer der C-Progger rüberschauen?
> ich tue mich mit Vorzeichen (MSB) von vorzeichenbehafteten 10 Bit Zahlen
> etwas schwer.

Und wie kann man Dir helfen?

  (__temp>511) ? strcpy(_rtc_temp_str, "-") : strcpy(_rtc_temp_str, " ");
  (__temp>511) ? __temp-=1024 : __temp+=0;

Die vorzeichenbehaftete 10 Bit Zahl geht ja von -512..511.

Da __temp ein "int16_t" ist, muss bei "__temp > 511" halt 1024 abgezogen 
werden, um die Formate zu konvertieren.

Joachim B. schrieb:
> Die Uhr liefert binär 1/4°C, mir genügt als Anzeige 1/10

Aber mit plusminus 3 Grad, für ein Wohnzimmer-Thermometer ungeeignet. 
Oder was hast Du damit vor? Vielleicht könnte man noch einen 
verstellbaren Offset einbauen, um das Thermometer zu kalibrieren.

Aber da wird ja auch nicht die Wohnzimmer-Temperatur gemessen, sondern 
die Temperatur der Platine, die vom Spannungsregler und ggf. den LEDs 
erwärmt wird.

Ein DS18B20 oder ein DHT22 wären vielleicht Alternativen, die sind
auf 0.5°C genau. Den könnte man auch so anordnen, dass die Temperatur
vom Wohnzimmer gemessen wird.

[Torsten C. (torsten_c)]

Die Schnittstellen zwischen der Applikation, der LED-Steuerung und den 
Funktionen für den Zugriff auf die Steuer-Daten sollte so gestaltet 
sein, dass sie die gewünschten Möglichleiten unterstützen.

Da ich gerade beim implementieren bin, und später nicht wieder alles 
aufgebaute wieder einreißen will, habe ich mal ein paar Anforderungen 
aufgeschrieben. Falls ich was vergessen habe: Je früher ich einen 
Hinweis bekomme, um so geringer ist der Zusatzaufwand.

/*
 *  Ein-/Ausblenden
 *  ===============
 *  Jeder Buchstabe kann langsam ein- oder ausgeblendet werden
 *  - durch einen Mode-Wechsel (z.B. per Fernbedienung) oder
 *  - durch einen Uhrzeit-Wechsel.
 *  Tritt eines dieser Ereignisse während eines laufenden Umblend-Vorgangs
 *  ein, wird der laufende Umblend-Vorgang unterbrochen und vom aktuellen
 *  RGB-Wert in einem neu gestarteten Umblend-Vorgang zum neuen Ziel-
 *  wert umgeblendet, damit alle Umblend-Vorgänge gleichzeitig enden
 *  und damit es keine Sprünge gibt.
 *
 *  Beim Einblenden wird immer zu einer globalen Ziel-Helligkeit umgebeblendet:
 *
 *  Helligkeit
 *  ==========
 *  Es gibt einen globalen Helligkeitswert. Damit das Einstellen nicht
 *  träge wirkt, wird die Helligkeit sofort (ohne zusätzlichen Umblend-Effekt)
 *  angepasst.
 *  Da sich die globale Helligkeit sofort auswirkt, gibt es keinen Konflikt mit
 *  einem ggf. aktiven Umblend-Vorgang.
 *  Helligkeits-Sprünge werden ggf. durch die Bedienung verhindert, z.B. durch kleine
 *  Schritte, oder durch einen Tiefpass am Helligkeitssensor.
 *
 *  Farben
 *  ======
 *  Die Buchstaben-Farben können auf verschiedene Arten individuell durch die Applikation
 *  festgelegt werden (Skinning), z.B.:
 *  - Alle aktiven Buchstaben haben die gleiche Farbe.
 *  - Jeder Buchstabe bekommt eine individuelle Farbe.
 *  - Jedes Wort bekommt eine individuelle Farbe,
 *  - Die Buchstaben-Farben werden durch ein Hintergrund-Bild festgelegt,
 *    z.B. durch einen animierten Farbverlauf
 *  - Ein "Hintergrund-Bild" hat bei "Screen-Modules" 32 x 32 Pixel, bei WS2812-LEDs
 *    hat es 18x16 oder 16x16 Pixel.
 *  Die Farben oder Hintergrundbilder können vom "Skin" z.B.
 *  - nach Zufall oder
 *  - nach einem abgerollten Farbkreis,
 *  - nach Tageszeit oder
 *  - nach Modus (Ossi-/Wessi-/...),
 *  oder aus einer Kombination davon festgelegt werden.
 */

[Torsten C. (torsten_c)]

Frank M. schrieb:
> WC24h_18x16_V2_2010_2003_15_Dez_2014, CodeGen v0.09
> … Da sind nämlich immer noch Fehler drin

Dazu noch ein Hinweis: Die Mode-Nummern im JSON-File und von Frank 
entsprechen nicht den Nummern aus der Datenbank. Hier die Übersetzung:

enum HourMode {
HM_1,  // 0 = Mode  1: "HH (12) (ZWÖLF)"
HM_2,  // 1 = Mode  2: "HH (12) - (MITTERNACHT, ZWÖLF)"
HM_3,  // 2 = Mode  3: "HH UHR (12) (NULL UHR, ZWÖLF UHR)"
HM_4,  // 3 = Mode  4: "HH UHR (12) NACHTS"
HM_5,  // 4 = Mode  5: "HH UHR (24)"
HM_6,  // 5 = Mode  6: "ES IST HH UHR (12)"
HM_7,  // 6 = Mode  7: "ES IST HH UHR (24)"
HM_24, // 7 = Mode 24: "MITTERNACHT"
HOUR_MODES_COUNT // Number of HourModes
};
 
enum MinuteMode {
MM_1,  // 0 = Mode  1: "ES IST MM NACH"
MM_2,  // 1 = Mode  2: "ES IST MM MINUTEN NACH"
MM_3,  // 2 = Mode  3: "ES IST MM MINUTEN NACH (VIERTEL NACH, HALB, VIERTEL VOR) - OSSI"
MM_4,  // 3 = Mode  4: "ES IST MM MINUTEN NACH (VIERTEL NACH, HALB, DREIVIERTEL) - OESI"
MM_5,  // 4 = Mode  5: "ES IST MM MINUTEN NACH (VIERTEL, HALB, DREIVIERTEL) - RHEIN/ RUHR"
MM_6,  // 5 = Mode  6: "ES IST MM MINUTEN NACH (VIERTEL NACH, HALB, DREIVIERTEL) - SCHWABEN"
MM_10, // 6 = Mode 10: "MM"
MM_11, // 7 = Mode 11: "UND MM MINUTEN"
MM_12, // 8 = Mode 12: "ES IST MM MINUTEN VOR"
MM_7,  // 9 = Mode  7: "ES IST MM MINUTEN NACH (VIERTEL, HALB,DREIVIERTEL) - WESSI"
MINUTE_MODES_COUNT // Number of MinuteModes
};

Also z.B. Minute-Mode 6 in der SW = Minute-Mode 10 in der .accdb!

Das JSON-Format liegt hier:
* https://gist.github.com/TorstenC/1aa1c8940c65603c6cc5 oder
* https://cdn.rawgit.com/TorstenC/1aa1c8940c65603c6cc5/raw/

[Joachim B. (jar)]

Torsten C. schrieb:
> Und wie kann man Dir helfen?
> Da __temp ein "int16_t" ist, muss bei "__temp > 511" halt 1024 abgezogen
> werden, um die Formate zu konvertieren.

ich habs ja gelöst, kommt mir nur umständlich vor und frage ob es 
eleganter geht?

> Aber mit plusminus 3 Grad, für ein Wohnzimmer-Thermometer ungeeignet.
> Oder was hast Du damit vor? Vielleicht könnte man noch einen
> verstellbaren Offset einbauen, um das Thermometer zu kalibrieren.

nun ja Präzision ist ja hier nicht gefordert (im Wohnzimmer)

hier ist aktuell auf der RTC 21,5°C in 1,2m Entfernung auf einer Funkuhr 
wird 22,5°C angezeigt.

Wer lügt ist mir fast egal.....

Aber du hast Recht in einer verbauten Platine mit DC/DC Wandler war die 
Temperatur immer 3° höher durch die Bauteile, in meinem Source ist 
Offset abziehen ja vorgesehen und einen DS18B20 dazuzupacken wäre kein 
Problem, der aber auf einer aufgewärmten Platine dasselbe Problem hätte.

Für das Timing der RTC kann man sogar den Oszillator der RTC abgleichen, 
aber das ist bis jetzt noch Spielerei und Zeitverschwendung.

[Herbert P. (herb3472)]

Hallo Wordclock Community!

War jetzt mehrere Tage außer Gefecht gesetzt, melde mich wieder vom 
Krankenstand zurück! :-)

Da wurde in der Zwischenzeit ja mächtig viel geschrieben! Mal schauen, 
ob und was ich da versäumt habe!

Torsten C. schrieb:
> Frank M. schrieb:
>> WC24h_18x16_V2_2010_2003_15_Dez_2014, CodeGen v0.09
>> … Da sind nämlich immer noch Fehler drin

Bitte um detailliertere Info, damit ich das korrigieren kann.

Die 16 x 16 Matrix liegt meines Wissens seit Anfang Dezember auf Eis, 
oder hat sich schon jemand die Mühe gemacht, die zu überprüfen?

[Frank M. (ukw) (Moderator)]

Hallo Herbert,

Herbert P. schrieb:
>>> … Da sind nämlich immer noch Fehler drin
>
> Bitte um detailliertere Info, damit ich das korrigieren kann.

Details stehen hier:

  Beitrag "Re: Minutengenaue 24 Stunden-Wortuhr - wer will mitbauen?"

[Joachim B. (jar)]

Herbert P. schrieb:
> Die 16 x 16 Matrix liegt meines Wissens seit Anfang Dezember auf Eis,
> oder hat sich schon jemand die Mühe gemacht, die zu überprüfen?

ne aber ich bin bald dran, sobald ich einen Termin bei meinem 
Gitterfräser bekomme, hängt halt von unser beider Zeit ab. Bis jetzt 
fehlten mir die Ribba 50x50 cm² Rahmen, aber die sind nun in weiss und 
schwarz gekauft, bekomme ich am Donnerstag geliefert, dann Maße nehmen, 
Gitter fräsen und Bodenplatte zur Aufnahme der beiden 8 x 16 Flächen 
WS2812b und ich kann mit dem m1284p (genug Speicher, flash und ram) 
loslegen.

[Torsten C. (torsten_c)]

Herbert P. schrieb:
> … melde mich wieder vom Krankenstand zurück!

Schön zu hören. :-) Willkommen zurück!

Joachim B. schrieb:
> ne aber ich bin bald dran

Bei mir hat sich gerade das Thema "Hausautomatisierung" etwas dazwischen 
gedrängelt (findet die Familie wichtiger). Ich muss sehen, dass ich asap 
mit einem STM32F411NUCLEO die Pinbelegung für die Screen-Module (aka 
"Kacheln") validieren kann, damit Frank das PCB fertig machen kann. Erst 
danach werden für mich die konkreten tables.h und display.h für 16x16 
relevant.

[Joachim B. (jar)]

Torsten C. schrieb:
> Bei mir hat sich gerade das Thema "Hausautomatisierung" etwas dazwischen
> gedrängelt

Einspruch 16 x 16 ist wichtiger !

ausserdem ist das Thema "Hausautomatisierung" so komplex, da wirst du 
nie fertig.

Wer will schon im kalten dunklen sitzen wenn der Compi spinnt, egal ob 
Hardware oder Software?

Torsten C. schrieb:
> Erst danach
> werden für mich die konkreten tables.h und display.h für 16x16 relevant.

machs zuerst, ich mache immer die Dinge zuerst die vermutlich leichter 
fertig werden können als Dinge die nie fertig werden, aber das andere 
deswegen liegenbleibt.

[Herbert P. (herb3472)]

Frank M. schrieb:
> Details stehen hier:
>
>   Beitrag "Re: Minutengenaue 24 Stunden-Wortuhr - wer will mitbauen?"

Oki thx!

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> ich mache immer die Dinge zuerst die vermutlich leichter
> fertig werden

Ja, und die, die die family will! Die WC24h-Android-Version läuft seit 
ein paar Tagen mit Log.i(…) im Demo-Mode (s. Bild). Wenn es eine neue 
Version der .accdb für 18x16 gibt, gehe ich das Log mal nach Fehlern 
durch.

Jetzt muss ich erstmal WLAN-Funkschalter bauen. :-(

[Joachim B. (jar)]

Torsten C. schrieb:
> und die, die die family will!

never !

habe ich mir abgewöhnt :-)

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> never !

WAF-Ignorant! ;-) (Zwinkern nicht übersehen!)

http://de.wikipedia.org/wiki/Woman_acceptance_factor

[Ralf (Gast)]

Joachim B. schrieb:
> interessanter wären aktuell für mich 42 - 52 /m non waterproof von mir

k.a. warum die "60 IP30" genannt werden, laut Beschreibung "5M 48leds/m 
WS2812B 5V Non waterproof white PCB":

http://www.aliexpress.com/item/30-60-leds-m-5M-WS2812B-5050-SMD-WS2812-IC-Smart-led-pixel-strip-DC5V/32266168779.html

[Torsten C. (torsten_c)]

Ralf schrieb:
> laut Beschreibung "5M 48leds/m WS2812B 5V"

Das Thema hatten wir schon mal. ^^ Solche "5V 48leds/m" hat bisher 
niemand gefunden, Glückwunsch!

Aber ob's stimmt? Bei diesen exorbitanten Versandkosten spiele ich 
nicht das Versuchskaninchen.

[Joachim B. (jar)]

Torsten C. schrieb:
> WAF-Ignorant! ;-)

und jetzt stolz drauf, wo kämen wir denn dahin, nur weil wir alten Kerle 
altersmilde werden muss man doch nicht Zicken ertragen.

Torsten C. schrieb:
> Solche "5V 48leds/m" hat bisher
> niemand gefunden, Glückwunsch!

ich auch nicht und dort waren doch 30/60 LEDs/m genannt?

[Frank M. (ukw) (Moderator)]

Da heute das RTC-/EEPROM-Modul ankam, habe ich das als Anlass genommen, 
die EEPROM- und RTC-Funktionen zu überarbeiten und zu vervollständigen.

ES gibt nun eine neue Version 0.9 des STM32-Programms.

Die wichtigsten Neuerungen:

  - Zusätzlicher Anschluss von RST und CH_PD des ESP8266-Moduls

  - Verbesserung der ESP8266-Konfiguration dank Hardware-Reset

  - Nutzung des Stromsparmodus im ESP8266, wenn die Anzeige
    abgeschaltet wird

  - Konfiguration der Zeitzone über MCURSES-Monitor

  - Test und Überarbeitung der EEPROM und RTC-Funktionen

  - Synchronisation der RTC-Zeit mit dem µC-Timer

  - Speichern folgender Daten im EEPROM:

       EEPROM-Version
       IRMP-Daten einer angelernten IR-Fernbedienung
       Aktuell eingestellte Farben und Anzeigemodus
       IP-Adresse des Time-Servers
       Zeitzone

Damit ist für mich die Uhr nun voll lauffähig. Die nächste Version heißt 
dann 1.0.

Die Features, die danach kommen, dienen lediglich einem verbesserten 
Komfort, z.B. die Farbprogramme und die Fernsteurung per Android App.

Es werden wahrscheinlich im Laufe der Zeit noch weitere Gimmicks folgen, 
klar ;-)

Die Dokumentation passe ich gerade im Artikel an.

Viel Spaß,

Frank

[Joachim B. (jar)]

interessant,

Frank M. schrieb:
> Da heute das RTC-/EEPROM-Modul ankam,

welches?

Frank M. schrieb:
> - Synchronisation der RTC-Zeit mit dem µC-Timer
>
>   - Speichern folgender Daten im EEPROM:
>
>        EEPROM-Version
>        IRMP-Daten einer angelernten IR-Fernbedienung
>        Aktuell eingestellte Farben und Anzeigemodus
>        IP-Adresse des Time-Servers
>        Zeitzone

Klasse

Frank M. schrieb:
> Die Dokumentation passe ich gerade im Artikel an.

wo? (bitte um Link ich bin so schlecht im linkmerken .-) )

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> wo? (bitte um Link ich bin so schlecht im linkmerken .-) )

Du sollst doch selber auch beim Pflegen der Wiki-Seite mithelfen!

* Anschauen: WordClock24h
* Mithelfen: Links unter "▶ Dieser Artikel" oder
             neben jeder Überschrift steht "Bearbeiten".

> White 60 IP30: 5M 48leds/m WS2812B 5V Non waterproof white PCB
> Black 60 IP30: 5M 48leds/m WS2812B 5V Non waterproof Black PCB

OK, ich nehme meine Glückwunsch^^ zurück. Das ist eindeutig ein 
Tippfehler!

[Frank M. (ukw) (Moderator)]

Joachim B. schrieb:
> Frank M. schrieb:
>> Da heute das RTC-/EEPROM-Modul ankam,
>
> welches?

Hatte ich hier schon mal geschrieben. Hier ein Link:

  http://www.amazon.de/SODIAL-winzige-AT24C32-Praezision-Echtzeituhr-Modul/dp/B00K67X496

Bei eBay findest Du die Dinger noch günstiger, einfach nach

     ds3231 eeprom

suchen. Kosten knapp 2 EUR das Stück, wenn Du in China bestellst. Ich 
habe mir von diesen bei eBay vor ein paar Tagen noch ein halbes Dutzend 
bestellt.

Ich setze da noch ein oder zwei Fotos in den Artikel WordClock24h.

[Joachim B. (jar)]

Frank M. schrieb:
> - Test und Überarbeitung der EEPROM und RTC-Funktionen

doofe Frage, ich bin ja nicht so geübt im proggen,

warum definierst du die Bits "ausgerechnet" ?

#define CTRL_CONV       0x20   // Convert Temperature

ich mache das aus Gewohnheit so als Bit:
#define RTC_TEMP_BSY       6

BTW fragst du busy nicht ab?

wo hast du die RTC Register definiert ? (ich lerne gerne von Profis)

Temperatur scheint im Code noch nicht gefragt werden zu können oder habe 
ich das übersehen?

Da die RTC DS1307 und die DS3231 die selbe Basisadresse haben und die 
Zeitregister identisch sind stelle ich erst mal Vorhandensein fest, RTC 
an Adresse 0 lesen, RTC -> ja und dann den Typ fest, die DS1307 hat 56 
Byte Ram, also Versuch die letzte Adresse 0x3F zu lesen,

Arduino Style, getestet

test_flags|=(1<<RTC_CHIP);
Wire.beginTransmission(DS1307_ID);
printIIC(0x3F);
(Wire.endTransmission()) ? test_flags|=(1<<RTC_3231) : test_flags|=(1<<RTC_1307);

(test_flags&(1<<RTC_3231)) ? Serial.println(F(" DS3231 RTC ")) : Serial.println(F(" DS1307 RTC "));

alternativ gehts auch in Standard C ohne Arduino

ungetestet, aber der Weg sollte klar sein

uint8_t test_rtc(void)
{ static unsigned char status;
  status=0;
  if(_test_i2c_rtc)
  {  i2c_start_wait(DS3231+I2C_WRITE); //set device address and write mode
     i2c_write(0x3F);       // write address = last RAM
     i2c_rep_start(DS3231+I2C_READ);   // set device address and read mode
     i2c_stop();
  }
  return status;
}

somit können beide Chips für die Zeit genutzt werden, die Temperatur und 
die Alarmregister natürlich nur bei Vorhandensein.

witzig dabei, von C kommend vor Arduino habe ich auch die Adresse
#define DS3231_ADDR     0xD0
 als 8 Bit genutzt,

aber die Arduino Jungs stritten (mit mir) weil die default I2C Adressen 
ja nur 7-bittig sind (das 8-te Bit ist read/write), egal ich weiss es 
jetzt und kann mit beiden umgehen, was nun die "richtige" Betrachtung 
ist weiss ich nicht.

"I2C device found at address 0x68; 1101000x; << 0xD0; 11010000 DS3231 
RTC"

[Frank M. (ukw) (Moderator)]

Joachim B. schrieb:
> warum definierst du die Bits "ausgerechnet" ?
>
> #define CTRL_CONV       0x20   // Convert Temperature
>
> ich mache das aus Gewohnheit so als Bit:
> #define RTC_TEMP_BSY       6

Ich definiere Masken, Du definierst Bits. Das ist Geschmackssache. Da 
ich das CTRL-Register sowieso einfach auf 0x00 setze, weil ich keines 
der CTRL-Bits nutze, ist mir das sowieso schnurz. Die 
Preprocessor-Konstanten habe ich nur der Vollständigkeit halber 
definiert - falls ich mal in den nächsten hundert Jahren vorhabe, mal 
was dran zu ändern ;-)

> BTW fragst du busy nicht ab?

Nö. Ist das bei 100kHz I2C-Geschindigkeit notwendig? Ich habe bei meinen 
Test noch nie einen Aussetzer gehabt. Aber ich werde da nochmal das 
Datenblatt studieren.

EDIT: Gerade nachgeschaut: Busy muss ich nur checken, wenn ich eine 
Temperaturmessung starte. Das mache ich aber gar nicht. Damit hat sich 
diese Frage auch erledigt.

> wo hast du die RTC Register definiert ? (ich lerne gerne von Profis)

Ich verstehe Deine Frage nicht. Ich greife mit Adressen von 0...6 drauf 
zu.

> Temperatur scheint im Code noch nicht gefragt werden zu können oder habe
> ich das übersehen?

Für mich ist die momentane Temperatur des RTC-Chips absolut 
uninteressant. Zudem ist die Temperatur-Messung noch sehr ungenau. Was 
willst Du damit? Per WLAN->Internet eine Mail schicken, wenns brennt? 
;-)

> Da die RTC DS1307 und die DS3231 die selbe Basisadresse haben und die
> Zeitregister identisch sind [...]

Nochmal, weil Du das schon mal behauptet hast: Das ist falsch!

Die Register sind NICHT identisch. Die Register der DS3231 sind 
identisch mit der DS1337, aber NICHT mit den Registern der DS1307. Bei 
der DS1307 ist das CTRL-Register in Adresse 7 und sieht vom Aufbau ganz 
anders aus als bei der DS1332, wo die Adresse 7 eine Alarmzeit 
speichert! Bei der DS3231 ist das CTRL-Register nämlich in Adresse 0.

Der Aufbau des CTRL- und des Status-Registers ist zudem komplett 
verschieden.

> stelle ich erst mal Vorhandensein fest, RTC
> an Adresse 0 lesen, RTC -> ja und dann den Typ fest, die DS1307 hat 56
> Byte Ram, also Versuch die letzte Adresse 0x3F zu lesen,

Ersteres zum Test mache ich auch, letzteres nicht. Laut Datenblatt 
liefert die DS3231 beim Lesen "hinter" den Adressen 0x00...0x12 einfach 
weitere Spiegelbilder der Adressen 0x00...0x12, rechnet also mit 
Modulo-Adressen. So ein Test, auf 0x3F zu lesen bringt nichts. Auch hier 
würde ich bei der DS3231 etwas lesen können.

[Joachim B. (jar)]

Frank M. schrieb:
> Nochmal, weil Du das schon mal behauptet hast: Das ist falsch!

NEIN

Frank M. schrieb:
> Ich verstehe Deine Frage nicht. Ich greife mit Adressen von 0...6 drauf
> zu.

dann schau ins Datenblatt und erkläre wo sich die Register von der 
DS1307 und der DS3231 von 0-6 unterscheiden sollen?

mein Code die Zeit auszulesen funktioniert mit beiden DS hier x-mal 
getestet, wieso kannst du behaupten das sei falsch?

Frank M. schrieb:
> Die Register der DS3231 sind
> identisch mit der DS1337, aber NICHT mit den Registern der DS1307.

Die Zeitregister der DS3231 und der DS1307 sind absolut identisch, von 
einer DS1337 habe ich nie geschrieben, kannst dich selber überzeugen, 
und nur durch Lesen der 0-6 wirst du nicht feststellen ob eine DS1307 
oder eine DS3231 verbaut ist.

Frank M. schrieb:
> Laut Datenblatt
> liefert die DS3231 beim Lesen "hinter" den Adressen 0x00...0x12 einfach
> weitere Spiegelbilder der Adressen 0x00...0x12, rechnet also mit
> Modulo-Adressen.

falsch, ich bekomme im Arduino Code mit Lesen von 0x3F an der DS3231 
einen Error: Wire.endTransmission()!= 0 und damit true -> somit gilt:

(Wire.endTransmission()) ? test_flags|=(1<<RTC_3231) : test_flags|=(1<<RTC_1307);

warum schreibst du nur immer so negativ? falsch, stimmt nicht......

[Frank M. (ukw) (Moderator)]

Joachim B. schrieb:
> dann schau ins Datenblatt und erkläre wo sich die Register von der
> DS1307 und der DS3231 von 0-6 unterscheiden sollen?

Du hattest geschrieben, dass alle Register (bis auf das SRAM) 
identisch sind. :-)
Von "Zeitregistern 0...6" war nie die Rede.

Aber fangen wir ruhig mit Register 0 an:

Register 0x00:
   DS1307: Oberstes Bit CH: Mit 1 stoppst Du die Uhr
   DS3231: Register 0x00: CH gibt es nicht

Übrigens: Im Auslieferungszustand einer DS1307 ist das CH gesetzt, also 
die Uhr gestoppt. Jedenfalls bei meiner DS1307, die ich in der 
klassischen 10x11-WordClock einsetze. Siehe auch Bemerkungen unten dazu. 
Bei der DS3231 stoppst Du die Uhr nicht in Register 0x00 mit CH, sondern 
im CTRL-Register, siehe unten.

CTRL-Register:

   DS1307: Ist Register 0x07
   DS3231: Ist Register 0x0E und (teilweise) Register 0x0F

Das CTRL-Register muss zwingend initialisiert werden, da im 
Auslieferungszustand die Werte undefiniert sind. Auszug aus dem 
Datenblatt der DS1307:

"Please note that the initial power on state of all registers is not 
defined.  Therefore it is important to enable the oscillator (CH bit=0) 
during initial configuration."

Das gilt nicht nur im Auslieferungszustand, das gilt auch für die 
Situation, dass keine Batterie angeflanscht war und Du die RTC nun 
wirklich erstmals wieder per Strom versorgst.

Das gilt natürlich auch für das CTRL-Register. Wie willst Du beide 
CTRL-Register gleich behandeln, wenn sie auf unterschiedlichen 
Positionen liegen und auch unterschiedlich aufgebaut sind? Einfach dran 
glauben, dass die (eher zufälligen) Werte passend sind?

> mein Code die Zeit auszulesen funktioniert mit beiden DS hier x-mal
> getestet, wieso kannst du behaupten das sei falsch?

Und wie initialisierst Du sie? Als ich damals den DS1307-Code schrieb 
für die klassische 10x11-WordClock, bin ich genau mit dem CH-Bit auf die 
Nase gefallen. Die Uhr lief im Auslieferungszustand nämlich gar nicht 
an.

> Die Zeitregister der DS3231 und der DS1307 sind absolut identisch, von
> einer DS1337 habe ich nie geschrieben, kannst dich selber überzeugen,
> und nur durch Lesen der 0-6 wirst du nicht feststellen ob eine DS1307
> oder eine DS3231 verbaut ist.

Jetzt schreibst Du "Zeitregister", vorher hast Du das aber von allen 
Registern behauptet ;-)

> falsch, ich bekomme im Arduino Code mit Lesen von 0x3F an der DS3231
> einen Error: Wire.endTransmission()!= 0 und damit true -> somit gilt:

Hm, habe ich mich da verlesen? Kann sein, ich suche nochmal nach der 
vermeintlichen Stelle. Aber da ich für die STM32-Version sowieso keine 
DS1307 vorgesehen habe, ists eh wurscht. Warum soll ich DS1307-Code 
dafür schreiben?

> warum schreibst du nur immer so negativ? falsch, stimmt nicht......

Beim Recherchieren im Internet stoße ich immer und immer wieder auf 
falsche Behauptungen, die ich erstmal glaube. Und genau dann falle ich 
bei der Umsetzung auf die Nase, weil ich der falschen Behauptung 
geglaubt habe. Das geht mir dann tierisch auf die Nerven.

Verstehst Du das? Es war nicht negativ und schon gar nicht persönlich 
gemeint. Aber Du vermittelst dem Leser, man könne DS1307 und DS1332 
absolut gleich behandeln. Das mag zwar für die "Zeitregister" stimmen, 
aber wenn sich dann wundert, warum die Uhr gar nicht läuft oder warum 
der SQW-Output 8kHz statt 1kHz ausgibt und stundenlang nach dem Fehler 
sucht, dann..... kann man schon einmal verzweifeln.

Joachim, das war nicht persönlich. Aber man sollte schon etwas genauer 
hinschauen. Dein Zurückrudern, dass Du nun plötzlich von "Zeitregistern" 
und nicht mehr "Registern" schreibst, zeigt mir, dass Du eigentlich 
längst verstanden hast.

Danke.

P.S.
Was hat die DS1307 eigentlich mit diesem Projekt zu tun? Wenn Du 
ATmega-Code dafür suchst: Im bisherigen 10x11er WordClock-Projekt wirst 
Du fündig ;-)

[Joachim B. (jar)]

Frank M. schrieb:
> Du hattest geschrieben, dass alle Register (bis auf das SRAM)
> identisch sind. :-)
> Von "Zeitregistern 0...6" war nie die Rede.

von alle hatte ich nie geschrieben, das geht nicht weil die DS1307 kein 
Temperaturregister und keine Alarmregister und die DS3231 kein RAM hat.

Frank M. schrieb:
> Register 0x00:
>    DS1307: Oberstes Bit CH: Mit 1 stoppst Du die Uhr
>    DS3231: Register 0x00: CH gibt es nicht

ist mir noch nicht aufgefallen und ich hatte damit noch kein Problem, 
aber gut wenn mehr als ein Augenpaar darauf schaut, deswegen machen wir 
das ja hier :-)

Frank M. schrieb:
> Das CTRL-Register muss zwingend initialisiert werden, da im
> Auslieferungszustand die Werte undefiniert sind.

auch das war nie ein Problem, ich bekam die Teile geliefert und konnte 
die gleich einstecken und sie liefen, wie gesagt für die reinen Zeit 
Routinen ist kein Unterschied in der SW zu merken.

Frank M. schrieb:
> Das gilt natürlich auch für das CTRL-Register. Wie willst Du beide
> CTRL-Register gleich behandeln, wenn sie auf unterschiedlichen
> Positionen liegen und auch unterschiedlich aufgebaut sind?

natürlich nicht, du zeigst es mir zum ersten Mal hier.

Frank M. schrieb:
> bin ich genau mit dem CH-Bit auf die
> Nase gefallen. Die Uhr lief im Auslieferungszustand nämlich gar nicht
> an.

hatte ich wohl Glück oder die RTCs DS1307 und DS3231 waren schon in 
China initialisiert und getestet, aber das kann ich ja nun nachholen und 
einbauen.

Frank M. schrieb:
> Hm, habe ich mich da verlesen? Kann sein, ich suche nochmal nach der
> vermeintlichen Stelle.

tu das ;-)

Frank M. schrieb:
> Beim Recherchieren im Internet stoße ich immer und immer wieder auf
> falsche Behauptungen, die ich erstmal glaube.

tröste dich das geht mir genauso und wie mich das ärgert........

Frank M. schrieb:
> Aber Du vermittelst dem
> Leser, man könne DS1307 und DS1332 absolut gleich behandeln.

Zahlendreher? DS1332 kenne ich nicht, deswegen auch die 
Missverständnisse.

Frank M. schrieb:
> Joachim, das war nicht persönlich. Aber man sollte schon etwas genauer
> hinschauen.

OK akzeptiert, das sollte dann für uns beide gelten.

Frank M. schrieb:
> Jetzt schreibst Du "Zeitregister", vorher hast Du aber von allen
> Registern behauptet ;-)

wo?

[Frank M. (ukw) (Moderator)]

Joachim B. schrieb:

> ist mir noch nicht aufgefallen und ich hatte damit noch kein Problem,
> aber gut wenn mehr als ein Augenpaar darauf schaut, deswegen machen wir
> das ja hier :-)

Nimm die DS1307 mal vom Batteriestrom, stecke sie dann nach ein paar 
Minuten wieder an die Stromversorgung und teste anschließend, ob sie 
noch tickt. Jedes zweite Mal tut sie das dann nicht mehr - im 
Durchschnitt :-)

> auch das war nie ein Problem, ich bekam die Teile geliefert und konnte
> die gleich einstecken und sie liefen, wie gesagt für die reinen Zeit
> Routinen ist kein Unterschied in der SW zu merken.

Ich bekam meine DS1307 von Reichelt ohne angeflanschte Batterie. Genau 
da muss man dann halt aufpassen.

> Frank M. schrieb:
>> Hm, habe ich mich da verlesen? Kann sein, ich suche nochmal nach der
>> vermeintlichen Stelle.
>
> tu das ;-)

Habe ich gerade. Unter der Überschrift "Address map" steht folgendes:

"During a multibyte access, when the address pointer reaches the end of 
the register space (12h), it wraps around to location 00h."

Das heisst, dass der Adresszähler nur wieder auf 00h zurückgestellt 
wird, wenn der Adress-Overflow innerhalb eines Multibyte-Zugriffs 
auftritt. Da habe ich tatsächlich zu oberflächlich gelesen. Die 
Situation, was passiert, wenn man den Zugriff direkt mit einer 
ungültigen Adresse (>0x12) beginnt, ist hier tatsächlich nicht 
beschrieben.

> Zahlendreher? DS1332 kenne ich nicht, deswegen auch die
> Missverständnisse.

Sorry, ja. DS3231 ist immer noch gemeint ;-)

> Frank M. schrieb:
>> Jetzt schreibst Du "Zeitregister", vorher hast Du aber von allen
>> Registern behauptet ;-)
>
> wo?

Gerade nochmal nach dem Posting gesucht. Es war Torsten und nicht Du, 
der das behauptete:

   Beitrag "Re: Minutengenaue 24 Stunden-Wortuhr - wer will mitbauen?"

"Ich habe noch 3 Stück mit AT24C32-EEPROM und DS1307 in der Bastelkiste,
die müssen erstmal verbraucht werden. Die sollten ja kompatibel sein,
also kein Problem."

Ich antwortete darauf mit:

"Ja, natürlich reicht die DS1307. Diese wird auch bereits im bestehenden
Word Clock-Projekt eingesetzt. Aber dass die DS3231 dazu kompatibel
ist, sehe ich auf den ersten Blick auf die Datenblätter nicht so."

Ich muss mich daher bei Dir entschuldigen. Torsten war's ;-)

[Joachim B. (jar)]

Frank M. schrieb:
> Ich muss mich daher bei Dir entschuldigen. Torsten war's ;-)

ne musst du nicht, ich irre selbst oft genug, aber gut das wir das 
ausgeräumt haben :-)

Frank M. schrieb:
> Ich antwortete darauf mit:
>
> "Ja, natürlich reicht die DS1307. Diese wird auch bereits im bestehenden
> Word Clock-Projekt eingesetzt. Aber dass die DS3231 dazu kompatibel
> ist, sehe ich auf den ersten Blick auf die Datenblätter nicht so."

für die Zeitregister 0-6 gilt das ja auch, vorbehaltlich der korrekten 
Initialisierung des Control Registers, aber das baue ich ein und dann 
passt es ja.

Frank M. schrieb:
> Das heisst, dass der Adresszähler nur wieder auf 00h zurückgestellt
> wird, wenn der Adress-Overflow innerhalb eines Multibyte-Zugriffs
> auftritt. .... Die
> Situation, was passiert, wenn man den Zugriff direkt mit einer
> ungültigen Adresse (>0x12) beginnt,

dann versucht man eben ein Schreiben im RAM mit Rücklesen und schaut ob 
der vorhanden ist optimal im Adress over flow wo man im DS3231 nicht 
schreiben kann

[Joachim B. (jar)]

Frank M. schrieb:
> Das CTRL-Register muss zwingend initialisiert werden, da im
> Auslieferungszustand die Werte undefiniert sind. Auszug aus dem
> Datenblatt der DS1307

meine DS3231 wurden ja ohne LiR2032 Akku geliefert, die DS1307 mit
zuerst hatte ich nur die DS1307 Routinen drin sogar mit start clock und 
stop clock am Control Register und ich wundere mich das das so schlecht 
funktoniert :-) jetzt ist es klar mit der unterschiedlichen Lage der 
CRTL Register.

Frank M. schrieb:
> Aber da ich für die STM32-Version sowieso keine
> DS1307 vorgesehen habe, ists eh wurscht. Warum soll ich DS1307-Code
> dafür schreiben?

weils nicht wehtut? wen störts, die paar Byte kann man opfern um beide 
nutzen zu können.

Frank M. schrieb:
> Das mag zwar für die "Zeitregister" stimmen,
> aber wenn sich dann wundert, warum die Uhr gar nicht läuft

komisch weil die DS3231 ohne Batterie geliefert wurde, etlich Wochen 
(ca. 6) auf dem Schiff und trotzdem lief sie obwohl ich das CRTL 
Register nicht richtig initialisiert hatte.

Frank M. schrieb:
> Nimm die DS1307 mal vom Batteriestrom,

nun ja, kann ich machen, aber wozu weil ich die nicht verwenden will, 
die DS3231 lief jedenfalls richtig los, ich habe noch mal DS3231 
nachgeordert aber diesmal gefragt ob die LiR2032 dabei sind, diese hier 
nachzukaufen kostet ein vielfaches der Module, dann nehme ich lieber die 
LiR2032 aus den DS1307 stecke die in die DS3231 und verschrotte die 
DS1307.

[Frank M. (ukw) (Moderator)]

Joachim B. schrieb:
> Frank M. schrieb:
>> Aber da ich für die STM32-Version sowieso keine
>> DS1307 vorgesehen habe, ists eh wurscht. Warum soll ich DS1307-Code
>> dafür schreiben?
>
> weils nicht wehtut? wen störts, die paar Byte kann man opfern um beide
> nutzen zu können.

Okay, ich überlege es mir. ;-)

> komisch weil die DS3231 ohne Batterie geliefert wurde, etlich Wochen
> (ca. 6) auf dem Schiff und trotzdem lief sie obwohl ich das CRTL
> Register nicht richtig initialisiert hatte.

Bei der DS3231 sind die Power-On-Werte für die Register wohldefiniert, 
siehe Datenblatt. Das geschilderte Problem passiert nur bei der DS1307.

> nun ja, kann ich machen, aber wozu weil ich die nicht verwenden will,
> die DS3231 lief jedenfalls richtig los, ich habe noch mal DS3231
> nachgeordert aber diesmal gefragt ob die LiR2032 dabei sind, diese hier
> nachzukaufen kostet ein vielfaches der Module, dann nehme ich lieber die
> LiR2032 aus den DS1307 stecke die in die DS3231 und verschrotte die
> DS1307.

Eben. Deshalb hadere ich noch mit der DS1307.

[Herbert P. (herb3472)]

@Joachim:

https://www.youtube.com/watch?v=NDwSrgfsiYQ

"Arduino Project: Real time clock (RTC) and temperature monitor using 
the DS3231 module"

Ist das bekannt und evetl. nützlich?

[Joachim B. (jar)]

Herbert P. schrieb:
> "Arduino Project: Real time clock (RTC) and temperature monitor using
> the DS3231 module"
>
> Ist das bekannt und evetl. nützlich?

muss ich gucken.....

[Torsten C. (torsten_c)]

Frank M. schrieb:
> Torsten C. schrieb:
>> Wie dringend ist meine finale Pin-Festlegung?
> Übehaupt nicht dringend. Solange Du Dich nicht festlegst, gibt's halt
> kein PCB als Shield ;-)

Ein schlechtes Gewissen habe ich durchaus. Ich brauche etwa 2 Wochen für 
die ESP8266-Funkschalter, die mir dazwischen gekommen sind. I²C für den 
TCS34725 könntest Du schon mal vorsehen, der Code folgt!

Wo ist der alternative Lichtsensor? Auf dem PCB oder per Pinheader 
angeschlossen?

Frank, setze mir lieber 'ne Frist, die wir evt. noch um ein paar Prozent 
strecken können, bevor es Stress gibt. Das Vermeiden des Streckens wäre 
dann mein Ziel. Im Moment bin ich terminlich ziellos.

[Frank M. (ukw) (Moderator)]

Es gibt von der STM32-Variante der Wclock24h-Software doch noch eine 
neue Version 0.9.1 vor der 1.0, denn ich hatte gestern abend 
festgestellt, dass bestimmt Speicherstellen des EEPROMs falsche Werte 
hatten.

Hier die korrigierte Version

  http://www.mikrocontroller.net/articles/WordClock24h#Download

mit folgenden Änderungen:

  - EEPROM-Hexdump im MCURSES-Monitor eingebaut
  - Zusätzliche Waitstates beim Beschreiben des EEPROMs

[Joachim B. (jar)]

Frank M. schrieb:
> mit folgenden Änderungen:
>
>   - EEPROM-Hexdump im MCURSES-Monitor eingebaut
>   - Zusätzliche Waitstates beim Beschreiben des EEPROMs

4 Byte für Timecode? -12 bis +12 wieso? reicht nicht ein Byte

4 Bit für bis 12

1 Bit für +-

[Torsten C. (torsten_c)]

Joachim B. schrieb:
> reicht nicht ein Byte

Bei 32-Bit-CPUs macht das i.d.R. keinen Unterschied.

[Frank M. (ukw) (Moderator)]

Joachim B. schrieb:
> 4 Byte für Timecode? -12 bis +12 wieso? reicht nicht ein Byte

Das EEPROM ist gigantische 4KB groß, ich benutze davon ja nur einen 
kleinen Teil :-)

Nein, mal im Ernst: Ich speichere die Timezone deshalb im Klartext ab, 
weil man sie dann im Hex-Dump direkt erkennen kann. Ausserdem verlasse 
ich mich nie darauf, ob beim jeweiligen Compiler chars tatsächlich auch 
negativ werden können. Solange viel Platz ist, nutze ich den auch. Für 
nicht benutzte Bytes gibts kein Geld zurück.

> 4 Bit für bis 12
>
> 1 Bit für +-

Das sind Peanuts. Die maximal 32 IRMP-Codes brauchen ein Vielfaches 
davon. Ich habe diese aber eben mit Attribute _packed_ versehen. Damit 
schrumpfen sie auf einen Bruchteil. Kommt mit der nächsten Version.

Torsten C. schrieb:
> Bei 32-Bit-CPUs macht das i.d.R. keinen Unterschied.

Ich nutze auch die Typen uint_fastXX_t sehr gern. Das heißt, der Code 
bleibt portabel und auch nutzbar für 8-Bit-µCs wie AVRs, läuft aber auf 
einem STM32 mit maximaler Geschwindigkeit. So habe ich festgestellt, 
dass zum Beispiel Schleifen mit uint32_t statt uint8_t als Zähler 
achtmal(!) schneller laufen. Daher habe ich zum Beispiel IRMP und 
MCURSES anlässlich dieses Projekts komplett auf fast-Typen 
umgestellt.

Wenn eine Variable aber nur einen maximalen Wertebereich von 0..255 hat, 
dann nutze ich nicht uint32_t, sondern uint_fast8_t. Damit läufts mit 
voller Geschwindigkeit auf 32-Bit-µCs, bleibt aber genügsam auf den 
8-Bit-AVRs.

Daten, die ich ins EEPROM schreibe, konvertiere ich aber vorher von 
uint_fast8_t nach uint8_t, damit der Platzverbrauch im Rahmen bleibt. 
Beim Lesen konvertiere ich sie natürlich wieder zurück.

Hier ein Beispiel für den Anzeigemodus:

uint_fast8_t        mode;           // ist global, aber auf STM32 32-Bit groß
...
...
    uint8_t         mode8;

    mode8 = mode;

    rtc = eeprom_write (EEPROM_DATA_OFFSET_MODE, &mode8, sizeof(mode8));

und umgekehrt:

    uint8_t         mode8;

    rtc = eeprom_read (EEPROM_DATA_OFFSET_MODE, &mode8, sizeof(mode8));

    mode = mode8;

Solche Bit-Sparereien, wie Joachim sie vorschlägt, mache ich aber erst, 
wenn es wirklich knapp werden sollte.

[Frank M. (ukw) (Moderator)]

Torsten C. schrieb:
> I²C für den TCS34725 könntest Du schon mal vorsehen, der Code folgt!

I²C wird sowieso schon genutzt. Da kannst Du Dich mit anflanschen.

> Wo ist der alternative Lichtsensor? Auf dem PCB oder per Pinheader
> angeschlossen?

Ich würde Pinheader vorschlagen, denn das PCB wird später im dunklen 
Bereich angebracht. Du solltest den Sensor schon entweder irgendwo am 
Rand der Uhr rausschauen lassen oder hinter einen unbenutzten Buchstaben 
klemmen.

> Frank, setze mir lieber 'ne Frist, die wir evt. noch um ein paar Prozent
> strecken können, bevor es Stress gibt. Das Vermeiden des Streckens wäre
> dann mein Ziel. Im Moment bin ich terminlich ziellos.

Bis Mitte Februar läuft eine WC11x10-Frontplatten-Sammelbestellung. Dann 
werde ich mal wieder bei der Druckerei einen größeren Stapel bestellen.

Ich versuche, für die Interessenten hier direkt einige WC18x16-Muster 
zum gleichen Preis von 38 EUR pro Stück mitzubestellen. Das muss ich 
zwar noch mit der Druckerei absprechen, aber ich denke, das sollte 
klappen. Daher wäre es nicht verkehrt, wenn ich zum gleichen Zeitpunkt 
auch die PCB-Bestellung machen könnte.

Wenn Du Dich also bis Mitte Februar entscheiden könntest, welche Pins Du 
noch auf dem Stecker haben möchtest, wäre das Klasse.

Wer sich an der 18x16-Frontplatten-Sammelbestellung beteiligen möchte, 
kann sich bei mir per PM melden.

[Frank M. (ukw) (Moderator)]

Joachim B. schrieb:
> 4 Byte für Timecode? -12 bis +12 wieso? reicht nicht ein Byte

Okay, ich habe jetzt noch ein paar Daten "enger" gepackt und komme jetzt 
auf folgende Größe:

      EEPROM Version    4 Bytes   ( 1 *  4)
      IRMP data       160 Bytes   (32 *  5)
      RGB brightness    3 Bytes   ( 3 *  1)
      Display mode      1 Byte    ( 1 *  1)
      Time server      16 Bytes   ( 1 * 16)
      Time zone         2 Bytes   ( 1 *  2)
      =====================================
      Sum             186 Bytes

Die Zeitzone speichere ich nun in 2 Bytes und nicht mehr als String:

   1. Byte = '+' oder '-'
   2. Byte = Numerischer Wert

Die Änderungen kommen in der nächsten Version 0.9.2.

Zufrieden? :-)

[Joachim B. (jar)]

Frank M. schrieb:
> Solche Bit-Sparereien, wie Joachim sie vorschlägt, mache ich aber erst,
> wenn es wirklich knapp werden sollte.

och wenn ich es gleich einbauen kann muss ich hinterher nicht ran.....

aber hast ja Recht, wozu habe ich mir einen Arduino mit 128kB flash und 
16kB Ram gebaut....

ich denke nur an Nachbauer die vielleicht einen fertigen Arduino m328p 
nehmen wollen.....

[Frank M. (ukw) (Moderator)]

Neues vom STM32-Projekt:

Android App kann nun die WordClock24h über WLAN steuern, nämlich:

 - Ein-/Ausschalten
 - Farben einstellen
 - Anzeigemodus einstellen

Siehe anhängendes Foto.

Das Projekt und die App lade ich morgen hoch.

[Frank M. (ukw) (Moderator)]

STM32 WordClock24-Software Version 1.0 steht zum Download zur Verfügung.

Download: WordClock24h

Neuerungen:

  - Test auf verschiedene Adressen des I2C-EEPROMs (A0..AE)
  - EEPROM-Speicherplatzverbrauch minimiert
  - RTC DS3231-Routinen auf DS1307 verallgemeinert
  - Network Listener (UDP) zum Fernsteuern der Uhr über WLAN
  - MCURSES-Monitor zeigt nun auch eingehende Netzverbindungen an
  - Android App zum Fernsteuern der Uhr (Ein/Aus, Farben, Anzeigemodus)

Die Android App kann dort ebenso heruntergeladen werden.

Die Dokumentation im Artikel wurde ebenso aktualisiert.

Viel Spaß!

Frank