Forum: Projekte & Code Minutengenaue 24 Stunden-Wortuhr - wer will mitbauen?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Joachim B. (jar)


Lesenswert?

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.

: Bearbeitet durch User
von Herbert P. (herb3472)


Lesenswert?

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?

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

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.

von Herbert P. (herb3472)


Lesenswert?

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.

von Joachim B. (jar)


Lesenswert?

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.

: Bearbeitet durch User
von Herbert P. (herb3472)


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Herbert P. (herb3472)


Lesenswert?

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.

von Joachim B. (jar)


Lesenswert?

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)

von Charly B. (charly)


Lesenswert?

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

: Bearbeitet durch User
von Holger W. (holgerw)


Lesenswert?

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

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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:
1
// Konsens
2
extern void    uart3_init (uint32_t baudrate);
3
extern void    uart3_putc (uint8_t);         // noch nicht implementiert
4
extern uint8_t uart3_getc (void);            // noch nicht implementiert, blockiert ggf. CPU
5
extern uint8_t uart3_poll (uint8_t *);       // noch nicht implementiert
6
extern void    uart3_flush ();               // noch nicht implementiert, blockiert CPU bis TX-Puffer leer
7
extern int     uart3_read (char *, int);     // noch nicht implementiert, blockiert CPU bis genügend Zeichen empfangen
8
extern int     uart3_write (char *, int);    // noch nicht implementiert, kann auch \000 übertragen, warum keine void-Rückgabe?
9
10
// neu
11
extern int     uart3_write0 (const char *);  // überträgt 0-terminierten String
12
extern int     uart3_readAll (char *, int);  // liest alle Zeichen aus Puffer, maximal so viele wie angegeben
13
extern int     uart3_countRX();              // Anzahl der Zeichen im RX-Puffer
14
extern bool    uart3_newChar();              // true, wenn seit dem letzten Aufruf von newChar() mindestens ein weiteres Zeichen empfangen worden ist
15
extern int     uart3_FindLF();               // liefert die Position des ersten \n im Puffer zurück
Verbesserungsvorschläge sind willkommen.

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

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

weil wir laut denken?
störts dich denn?

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Charly B. (charly)


Lesenswert?

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

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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

: Bearbeitet durch User
von Holger W. (holgerw)


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

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.

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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
1
#ifdef _AVR_IOM2560_H_
2
// …
3
#ifdef _AVR_IOM328P_H_
4
// …
gemacht. Ging super!

… oder zumindest gemeinsame .h-Datei-Schnittstellen.

@Joachim: Wie siehst Du das?

@All: Wie seht Ihr das?

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


Lesenswert?

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
1
#if defined (STM32F4XXX)
2
   Hier STM32-F4-Code (Disco und Nucleo)
3
#elif defined (STM32F1XXX)
4
   Hier STM32-F1-Code (Deine China-Module)
5
#elif defined (__AVR_ATmega2560__)
6
   Hier ATmega-2560-Code
7
#else
8
   #error Unknown Target Controller
9
#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?

von Joachim B. (jar)


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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?

: Bearbeitet durch User
von Herbert P. (herb3472)


Lesenswert?

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?

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

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?

von Herbert P. (herb3472)


Lesenswert?

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

von Joachim B. (jar)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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?

von Herbert P. (herb3472)


Lesenswert?

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

von Herbert P. (herb3472)


Lesenswert?

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?

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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"

: Bearbeitet durch User
von Herbert P. (herb3472)


Lesenswert?

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

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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:
1
spi.SPI_Direction = SPI_Direction_2Lines_FullDuplex;

Ich arbeite mit:
1
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.

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

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

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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:
1
int TagretPtr = 0;
2
uint8_t TempSrc;
3
union {
4
    uint32_t WordData;
5
    uint8_t BytesData[4];
6
} TempDst;
7
for (int index = 0; index < RGBBufferSize; ++index) {
8
    TempSrc = RGBBuffer.SingleBytes[index];
9
    TempDst.WordData = 0;
10
    for (int bitIndex = 0; bitIndex < 8; ++bitIndex) {
11
        TempDst.WordData <<= 4;
12
        if (TempSrc & 0x1) {
13
            TempDst.WordData |= 0b0000;
14
        } else {
15
            TempDst.WordData |= 0b1110;
16
        }
17
        TempSrc >>= 1;
18
        bitIndex += 1;
19
        TempDst.WordData <<= 4;
20
        if (TempSrc & 0x1) {
21
            TempDst.WordData |= 0b1000;
22
        } else {
23
            TempDst.WordData |= 0b1111;
24
        }
25
        TempSrc >>= 1;
26
    }
27
    FrameBufferRGB[TagretPtr++] = TempDst.BytesData[0];
28
    FrameBufferRGB[TagretPtr++] = TempDst.BytesData[1];
29
    FrameBufferRGB[TagretPtr++] = TempDst.BytesData[2];
30
    FrameBufferRGB[TagretPtr++] = TempDst.BytesData[3];
31
}

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

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.

von Torsten C. (torsten_c) Benutzerseite


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

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


Lesenswert?

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.

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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?

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


Lesenswert?

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.

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

Zum Thema "Code, der möglichst allgemein verwendbar sein soll":
1
/*------------------------------------------------
2
 * display clock time (LEDs & mcurses)
3
 *------------------------------------------------
4
 */
5
void dsp_clock (uint8_t mode, uint8_t hour, uint8_t minute, uint8_t second, uint8_t update_leds_only) {
6
    // …
7
    dsp_all_leds_off ();
8
    // …
9
}

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.

: Bearbeitet durch User
von Herbert P. (herb3472)


Lesenswert?

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.

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


Lesenswert?

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.

: Bearbeitet durch Moderator
von Joachim B. (jar)


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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!

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


Lesenswert?

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

: Bearbeitet durch Moderator
von Herbert P. (herb3472)


Lesenswert?

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

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

: Bearbeitet durch Moderator
von Torsten C. (torsten_c) Benutzerseite


Angehängte Dateien:

Lesenswert?

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:

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

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

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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

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.

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


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Torsten C. (torsten_c) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von Herbert P. (herb3472)


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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
1
DMA1_Channel4->CMAR = (uint32_t) (&(HUB08_MatrixData[HUB08_CurrentTimeslot][HUB08_DMA_Row].Blue))-1;

… und die Slave-SPIs mit
1
DMA1_Channel5->CMAR = (uint32_t) (&(HUB08_MatrixData[HUB08_CurrentTimeslot][HUB08_DMA_Row].Green));
2
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"?
1
/*-------------------------------------------------------------------------------------------------------------------------------------------
2
 * switch one LED on
3
 *-------------------------------------------------------------------------------------------------------------------------------------------
4
 */
5
void
6
dsp_led_on (uint8_t y, uint8_t x, uint8_t refresh)
7
{
8
    uint16_t    n;
9
    #ifdef HUB08_H
10
        n = y * WC_COLUMNS + x;
11
    #else                                                     // torsten_c: auskommentiert, da speziell für WS2812
12
        if (y & 0x01)                                         // odd row: count from right to left
13
        {
14
            n = y * WC_COLUMNS + (WC_COLUMNS - x);
15
        }
16
        else                                                  // even row: count from left to right
17
        {
18
            n = y * WC_COLUMNS + x;
19
        }
20
    #endif
21
                                                            
22
    led_state[n] |= TARGET_STATE;
23
}

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite



Lesenswert?

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

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


Lesenswert?

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.

von Herbert P. (herb3472)


Lesenswert?

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.

von Herbert P. (herb3472)


Lesenswert?

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.

von Herbert P. (herb3472)


Lesenswert?

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

von Herbert P. (herb3472)


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

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


Lesenswert?

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.

: Bearbeitet durch Moderator
von Herbert P. (herb3472)


Lesenswert?

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!"

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Herbert P. (herb3472)


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Herbert P. (herb3472)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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?

: Bearbeitet durch User
von Herbert P. (herb3472)


Lesenswert?

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!

: Bearbeitet durch User
von Herbert P. (herb3472)


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

von Joachim B. (jar)


Lesenswert?

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.
1
#include "FastLED.h"
2
3
// How many leds in your strip?
4
#define NUM_LEDS 6
5
6
// For led chips like Neopixels, which have a data line, ground, and power, you just
7
// need to define DATA_PIN.  For led chipsets that are SPI based (four wires - data, clock,
8
// ground, and power), like the LPD8806 define both DATA_PIN and CLOCK_PIN
9
#define DATA_PIN 3
10
//#define CLOCK_PIN 13
11
12
// Define the array of leds
13
CRGB leds[NUM_LEDS];
14
15
void setup() { 
16
      // Uncomment/edit one of the following lines for your leds arrangement.
17
      // FastLED.addLeds<TM1803, DATA_PIN, RGB>(leds, NUM_LEDS);
18
      // FastLED.addLeds<TM1804, DATA_PIN, RGB>(leds, NUM_LEDS);
19
      // FastLED.addLeds<TM1809, DATA_PIN, RGB>(leds, NUM_LEDS);
20
      // FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);
21
      // FastLED.addLeds<WS2812, DATA_PIN, RGB>(leds, NUM_LEDS);
22
      // FastLED.addLeds<WS2812B, DATA_PIN, RGB>(leds, NUM_LEDS);
23
24
// statt FastLED.addLeds<NEOPIXEL, DATA_PIN, RGB>(leds, NUM_LEDS);
25
26
FastLED.addLeds<NEOPIXEL, DATA_PIN, GRB>(leds, NUM_LEDS); // braucht der WS2812b
27
      // FastLED.addLeds<UCS1903, DATA_PIN, RGB>(leds, NUM_LEDS);
28
29
      // FastLED.addLeds<WS2801, RGB>(leds, NUM_LEDS);
30
      // FastLED.addLeds<SM16716, RGB>(leds, NUM_LEDS);
31
      // FastLED.addLeds<LPD8806, RGB>(leds, NUM_LEDS);
32
33
      // FastLED.addLeds<WS2801, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
34
      // FastLED.addLeds<SM16716, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
35
      // FastLED.addLeds<LPD8806, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
36
}
37
38
void loop() { 
39
  // Turn the LED on, then pause
40
  leds[0] = CRGB::Red;
41
  FastLED.show();
42
  delay(500);
43
  // Now turn the LED off, then pause
44
  leds[0] = CRGB::Black;
45
  FastLED.show();
46
  delay(500);

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Joachim B. (jar)


Lesenswert?

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

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

: Bearbeitet durch Moderator
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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?

: Bearbeitet durch Moderator
von Herbert P. (herb3472)


Lesenswert?

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.

: Bearbeitet durch User
von Herbert P. (herb3472)


Lesenswert?

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

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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

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


Lesenswert?

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.

: Bearbeitet durch Moderator
von Joachim B. (jar)


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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?

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


Lesenswert?

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.

: Bearbeitet durch Moderator
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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

: Bearbeitet durch User
von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

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 ?

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

von Joachim B. (jar)


Lesenswert?

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?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
1
#undef F_CPU
2
#define F_CPU 16000000L

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

: Bearbeitet durch Moderator
von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

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,
1
#if defined(__AVR_ATmega1284P__)
2
// hier die für den m1284p modifizierten bit bang routinen
3
#else
4
// hier die vorigen bit bang routinen
5
#endif

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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

von Joachim B. (jar)


Lesenswert?

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

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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
1
for(register uint32_t i = 7; i > 0; i--) {
2
    SET2_HI; delaycycles<3>(); SET2_HI2;
3
    delaycycles<T1 - 6>(); // 6 cycles - 1/1 store, 1/1 test, 1/1 if, 1/1 port lookup
4
    if(b & 0x80) { SET2_HI; } else { SET2_LO; }
5
    if(c & 0x80) { SET2_HI2; } else { SET2_LO2; }
6
    b <<= 1; c <<=1;
7
    delaycycles<T2 - 8>(); // 3 cycles, 1/1 store, 1/1 store/skip, 1/1 shift , 1/1 port lookup
8
    SET2_LO; SET2_LO2;
9
    delaycycles<T3 - 6>(); // 4 cycles, 1/1 store, 1 sub, 1 branch backwards, 1/1 port lookup
10
}
11
// extra delay because branch is faster falling through
12
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
1
#if defined(__AVR_ATmega1284P__)
2
// hier die für den m1284p modifizierten bit bang routinen
3
#else
4
// hier die vorigen bit bang routinen
5
#endif

von Joachim B. (jar)


Lesenswert?

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

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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?

von Joachim B. (jar)


Lesenswert?

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.

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> nur wie modifiziere ich passend?
1
#define NOP __asm__ __volatile__ ("cp r0,r0\n");
2
#define NOP2 __asm__ __volatile__ ("rjmp .+0");
3
4
template<> __attribute__((always_inline)) inline void delaycycles<-6>() {}
5
template<> __attribute__((always_inline)) inline void delaycycles<-5>() {}
6
template<> __attribute__((always_inline)) inline void delaycycles<-4>() {}
7
template<> __attribute__((always_inline)) inline void delaycycles<-3>() {}
8
template<> __attribute__((always_inline)) inline void delaycycles<-2>() {}
9
template<> __attribute__((always_inline)) inline void delaycycles<-1>() {}
10
template<> __attribute__((always_inline)) inline void delaycycles<0>() {}
11
template<> __attribute__((always_inline)) inline void delaycycles<1>() {NOP;}
12
template<> __attribute__((always_inline)) inline void delaycycles<2>() {NOP2;}
13
template<> __attribute__((always_inline)) inline void delaycycles<3>() {NOP;NOP2;}
14
template<> __attribute__((always_inline)) inline void delaycycles<4>() {NOP2;NOP2;}
15
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:
1
SET2_HI; delaycycles<3>(); SET2_HI2;
2
delaycycles<T1 - 6>();
3
delaycycles<T2 - 8>();
4
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.

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


Lesenswert?

Torsten C. schrieb:
1
> 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.

von Joachim B. (jar)


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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?

von Joachim B. (jar)


Lesenswert?

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!

: Bearbeitet durch User
von Herbert P. (herb3472)


Lesenswert?

Einfach einmal was zur Aufheiterung:

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

Wünsche Euch noch einen schönen Abend!

von Torsten C. (torsten_c) Benutzerseite


Angehängte Dateien:

Lesenswert?

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:
1
dma.DMA_PeripheralBaseAddr = (uint32_t) &(GPIOB->ODR);

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

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


Lesenswert?

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

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

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?

: Bearbeitet durch Moderator
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

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


Lesenswert?

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.

: Bearbeitet durch Moderator
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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:
1
+-------------------------+-------------------------+-------------------------+
2
| Device                  | STM32F4 Discovery       | STM32F4x1 Nucleo        |
3
+-------------------------+-------------------------+-------------------------+
4
| User button             | GPIO:   PA0             | GPIO:   PC13            |
5
| Green LED               | GPIO:   PD12            | GPIO:   PA5             |
6
+-------------------------+-------------------------+-------------------------+
7
| TSOP38238 (IRMP)        | GPIO:   PC14            | GPIO:   PC10            |
8
| DCF77                   | GPIO:   PC15            | GPIO:   PC11            |
9
| MCURSES terminal (USB)  | USB:    OTG             | USART2: TX=PA2  RX=PA3  |
10
| ESP8266                 | USART2: TX=PA2  RX=PA3  | USART6: TX=PA11 RX=PA12 |
11
| I2C DS3231 & EEPROM     | I2C3:   SCL=PA8 SDA=PC9 | I2C3:   SCL=PA8 SDA=PC9 |
12
| WS2812                  | DMA1:   PC6             | DMA1:   PC6             |
13
+-------------------------+-------------------------+-------------------------+

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.
1
+-------------------------+-------------------------+-------------------------+
2
| Device                  | STM32F4 Discovery       | STM32F4x1 Nucleo        |
3
+-------------------------+-------------------------+-------------------------+
4
| HUB-75-Interface        |                         | R1: PC0                 |
5
|                         |                         | G1: PC1                 |
6
|                         |                         | B1: PC2                 |
7
|                         |                         | R2: PC3                 |
8
|                         |                         | G2: PC4                 |
9
|                         |                         | B2: PC5                 |
10
|                         |                         | Ck: PC6 (TIM3_CH1)      |
11
|                         |                         | LE: PC7                 |
12
|                         |                         | OE: ??  (TIM*_CH*)      |
13
|                         |                         | A: ??                   |
14
|                         |                         | B: ??                   |
15
|                         |                         | C: ??                   |
16
+-------------------------+-------------------------+-------------------------+

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.

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


Angehängte Dateien:

Lesenswert?

Torsten C. schrieb:
> Zur Pin-Belegung:
1
+-------------------------+-------------------------+-------------------------+
2
| ESP8266                 | USART2: TX=PA2  RX=PA3  | USART6: TX=PA11 RX=PA12 |
3
+-------------------------+-------------------------+-------------------------+


Nur zur Info:
Diese Zeile habe ich für Version 0.9 mittlerweile erweitert:
1
+-------------------------+---------------------------+---------------------------+
2
| Device                  | STM32F4 Discovery         | STM32F4x1 Nucleo          |
3
+-------------------------+---------------------------+---------------------------+
4
| ESP8266 USART           | USART2: TX=PA2  RX=PA3    | USART6: TX=PA11 RX=PA12   |
5
| ESP8266 GPIO            | GPIO:   RST=PC5 CH_PD=PC4 | GPIO:   RST=PA7 CH_PD=PA6 |
6
+-------------------------+---------------------------+---------------------------+

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.

: Bearbeitet durch Moderator
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

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


Angehängte Dateien:

Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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"

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

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.

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


Lesenswert?

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

von Joachim B. (jar)


Lesenswert?

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.

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


Lesenswert?

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

: Bearbeitet durch Moderator
von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

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

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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)

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

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.

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

> Torsten C. schrieb:
>> BTW: Interessiert der Android-Kram, …?
> also ich finde Arduino Kram toll weil viele damit was anfangen können.

1
enum Magnitude {
2
    Mag_little,
3
    Mag_medium,
4
    Mag_big
5
};
6
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.

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


Lesenswert?

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.

von Joachim B. (jar)


Lesenswert?

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.

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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€:
1
protected BitSet getOnOffFromTime(int hour, int minute) {
2
    BitSet result = this.minuteWords[this.currentMode][minute];
3
    if (this.hourOffsets[this.currentMode][minute]) hour += 1;
4
    result.or(this.hourWords[this.currentMode][hour]);
5
    return result;
6
}

Ohne BitSets sähe das anders aus.

Ich will hier niemanden bekehren! Das ist nur mal zum Nachdenken.

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

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

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

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)
1
//#define AGING_OFFSET    16 // 10H SIGN DATA DATA DATA DATA DATA DATA DATA Aging Offset
2
#define MSB_TEMP    17 // 11H SIGN DATA DATA DATA DATA DATA DATA DATA MSB of Temp
3
#define LSB_TEMP    18 // 12H DATA DATA 0 0 0 0 0 0 LSB of Temp
4
#define DS1307_ID               0x68
5
6
#if defined(ARDUINO) && ARDUINO >= 100 // ist nicht von mir sieht falsch aus weil wenn nicht ARDUINO wieso ELSE?
7
  #define printIIC(args) Wire.write((uint8_t)args)
8
  #define readIIC() Wire.read()
9
#else
10
  #define printIIC(args) Wire.send(args)
11
  #define readIIC() Wire.receive()
12
#endif
13
14
15
char *temperatur_str_rtc(BYTE offset) // BYTE auf neudeutsch int8_t
16
{ static double _rtc_temp=0.0;
17
  static char _rtc_temp_str[5]={0};
18
  char s[6]={0};
19
  char *komma;
20
  WORD __temp=0; // WORD auf neudeutsch int16_t
21
22
#if (ARDUINO>0)
23
#if (ARDUINO <  100)
24
  /*__temp = Wire.receive();*/ ####error
25
#else                 
26
  if(test_flags&(1<<RTC_3231)) 
27
  {
28
    Wire.beginTransmission(DS1307_ID);
29
    printIIC(MSB_TEMP);
30
    Wire.endTransmission(); // ggffs. var _error einfügen -> _error = Wire.endTransmission();
31
    Wire.requestFrom( ( DS1307_ID ), 2);       // request secs, min, hour, dow, day, month, year
32
    __temp = (readIIC() & 0x00ff);       
33
    __temp <<= 8;      
34
    __temp |= (readIIC() & 0x00ff);              
35
  }
36
#endif
37
#else
38
  i2c_start_wait(DS3231+I2C_WRITE);  // set device address and write mode
39
  i2c_write(MSB_TEMP);
40
  i2c_rep_start(DS3231+I2C_READ);     // set device address and read mode
41
  __temp=i2c_readAck();
42
  __temp<<=8;
43
  __temp|=i2c_readNak();
44
  i2c_stop();
45
#endif
46
  __temp>>=6;
47
48
  (__temp>511) ? strcpy(_rtc_temp_str, "-") : strcpy(_rtc_temp_str, " ");
49
  (__temp>511) ? __temp-=1024 : __temp+=0;
50
  _rtc_temp=__temp*2.5;
51
  strcat(_rtc_temp_str, insert_char( trimm_string(' ',itoa( (UWORD)( _rtc_temp+(offset*10)),  s, 10), 3 ), ',', 2));
52
  komma=strstr(_rtc_temp_str, ",");
53
  komma--;
54
  if(*komma==' ')
55
    *komma='0';
56
  return _rtc_temp_str;
57
}

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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?
1
  (__temp>511) ? strcpy(_rtc_temp_str, "-") : strcpy(_rtc_temp_str, " ");
2
  (__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.

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.
1
/*
2
 *  Ein-/Ausblenden
3
 *  ===============
4
 *  Jeder Buchstabe kann langsam ein- oder ausgeblendet werden
5
 *  - durch einen Mode-Wechsel (z.B. per Fernbedienung) oder
6
 *  - durch einen Uhrzeit-Wechsel.
7
 *  Tritt eines dieser Ereignisse während eines laufenden Umblend-Vorgangs
8
 *  ein, wird der laufende Umblend-Vorgang unterbrochen und vom aktuellen
9
 *  RGB-Wert in einem neu gestarteten Umblend-Vorgang zum neuen Ziel-
10
 *  wert umgeblendet, damit alle Umblend-Vorgänge gleichzeitig enden
11
 *  und damit es keine Sprünge gibt.
12
 *
13
 *  Beim Einblenden wird immer zu einer globalen Ziel-Helligkeit umgebeblendet:
14
 *
15
 *  Helligkeit
16
 *  ==========
17
 *  Es gibt einen globalen Helligkeitswert. Damit das Einstellen nicht
18
 *  träge wirkt, wird die Helligkeit sofort (ohne zusätzlichen Umblend-Effekt)
19
 *  angepasst.
20
 *  Da sich die globale Helligkeit sofort auswirkt, gibt es keinen Konflikt mit
21
 *  einem ggf. aktiven Umblend-Vorgang.
22
 *  Helligkeits-Sprünge werden ggf. durch die Bedienung verhindert, z.B. durch kleine
23
 *  Schritte, oder durch einen Tiefpass am Helligkeitssensor.
24
 *
25
 *  Farben
26
 *  ======
27
 *  Die Buchstaben-Farben können auf verschiedene Arten individuell durch die Applikation
28
 *  festgelegt werden (Skinning), z.B.:
29
 *  - Alle aktiven Buchstaben haben die gleiche Farbe.
30
 *  - Jeder Buchstabe bekommt eine individuelle Farbe.
31
 *  - Jedes Wort bekommt eine individuelle Farbe,
32
 *  - Die Buchstaben-Farben werden durch ein Hintergrund-Bild festgelegt,
33
 *    z.B. durch einen animierten Farbverlauf
34
 *  - Ein "Hintergrund-Bild" hat bei "Screen-Modules" 32 x 32 Pixel, bei WS2812-LEDs
35
 *    hat es 18x16 oder 16x16 Pixel.
36
 *  Die Farben oder Hintergrundbilder können vom "Skin" z.B.
37
 *  - nach Zufall oder
38
 *  - nach einem abgerollten Farbkreis,
39
 *  - nach Tageszeit oder
40
 *  - nach Modus (Ossi-/Wessi-/...),
41
 *  oder aus einer Kombination davon festgelegt werden.
42
 */

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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:
1
enum HourMode {
2
HM_1,  // 0 = Mode  1: "HH (12) (ZWÖLF)"
3
HM_2,  // 1 = Mode  2: "HH (12) - (MITTERNACHT, ZWÖLF)"
4
HM_3,  // 2 = Mode  3: "HH UHR (12) (NULL UHR, ZWÖLF UHR)"
5
HM_4,  // 3 = Mode  4: "HH UHR (12) NACHTS"
6
HM_5,  // 4 = Mode  5: "HH UHR (24)"
7
HM_6,  // 5 = Mode  6: "ES IST HH UHR (12)"
8
HM_7,  // 6 = Mode  7: "ES IST HH UHR (24)"
9
HM_24, // 7 = Mode 24: "MITTERNACHT"
10
HOUR_MODES_COUNT // Number of HourModes
11
};
12
 
13
enum MinuteMode {
14
MM_1,  // 0 = Mode  1: "ES IST MM NACH"
15
MM_2,  // 1 = Mode  2: "ES IST MM MINUTEN NACH"
16
MM_3,  // 2 = Mode  3: "ES IST MM MINUTEN NACH (VIERTEL NACH, HALB, VIERTEL VOR) - OSSI"
17
MM_4,  // 3 = Mode  4: "ES IST MM MINUTEN NACH (VIERTEL NACH, HALB, DREIVIERTEL) - OESI"
18
MM_5,  // 4 = Mode  5: "ES IST MM MINUTEN NACH (VIERTEL, HALB, DREIVIERTEL) - RHEIN/ RUHR"
19
MM_6,  // 5 = Mode  6: "ES IST MM MINUTEN NACH (VIERTEL NACH, HALB, DREIVIERTEL) - SCHWABEN"
20
MM_10, // 6 = Mode 10: "MM"
21
MM_11, // 7 = Mode 11: "UND MM MINUTEN"
22
MM_12, // 8 = Mode 12: "ES IST MM MINUTEN VOR"
23
MM_7,  // 9 = Mode  7: "ES IST MM MINUTEN NACH (VIERTEL, HALB,DREIVIERTEL) - WESSI"
24
MINUTE_MODES_COUNT // Number of MinuteModes
25
};

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/

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

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.

von Herbert P. (herb3472)


Lesenswert?

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?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

von Joachim B. (jar)


Lesenswert?

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.

: Bearbeitet durch User
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?