Torsten C. schrieb: > ein neuer "Film" macht ohne die o.g. Korrektueren keinen Sinn. Aber auffällige Bilder kann ich von der korrigierten Version erzeugen und per Mail schicken. Ich bin gerade dabei. Meine Freundin redet ja im "Ossi-Modus" und ich habe ihr das mal gezeigt: Man kann "Es ist zehn vor halb" sagen, aber sie meint, sie sagt eher "Es ist zwanzig nach". Das Wort MINUTEN lässt sie bei 5 und 10 Minuten wegn aber niemand sagt "ES IST EINS VOR HALB". Da sagt man "ES IST EINE MINUTE VOR HALB". Ich gebe das mal so weiter. Was meint Ihr? VG Torsten C. ➜ Für Neu-Eisteiger gibt es den Beitrag "WortUhr/WordClock: Minutengenau, 24h, RGB – Für Neu-Einsteiger"
Angehängte Dateien:
Angehängte Dateien:
-
HTML-Anchor.png
51 KB
Hmmm, Bilder bei Flickr sind doof. Viedeos bei Youtube sind doof. HTML-Seiten sind besser, aber man kann sie nur als ZIP-Datei ins Wiki packen. Als Datei-Anlage am Beitrag wird nur der HTML-Quelltext angezeigt. Eine bessere Idee als ein GitHub-Gist habe ich gerade nicht: Nun_zu_den_Auffälligkeiten Eine EINS fehlt: https://rawgit.com/TorstenC/1a59b9c73730eb8e144d/raw/28865a80765fb6dff38c5590b88726446b0dc2f3/WC24h_18x16_Test.html#M10T0101 Im Mode [11], also im Stunden-Modus [6] auch: https://rawgit.com/TorstenC/1a59b9c73730eb8e144d/raw/28865a80765fb6dff38c5590b88726446b0dc2f3/WC24h_18x16_Test.html#M11T0101 MINUTEn muss in der Einzahl sein: https://rawgit.com/TorstenC/1a59b9c73730eb8e144d/raw/28865a80765fb6dff38c5590b88726446b0dc2f3/WC24h_18x16_Test.html#M10T0529 "Es ist 12 Min. vor 1 Uhr" passt gar nicht: https://rawgit.com/TorstenC/1a59b9c73730eb8e144d/raw/28865a80765fb6dff38c5590b88726446b0dc2f3/WC24h_18x16_Test.html#M10T0048 ... (Ihr könnt auch selber mal nach Auffälligkeiten suchen). Zu dem Bild: Manchmal dauert es ein bisschen, aber der Browser sollte zu dem gemeinten Bild springen (lila Klingel). Wenn es eine neue .accdb gibt, mache ich ein Update der HTML-Seite. VG Torsten C. ➜ Thread-Artikel WordClock24h
Herbert P. schrieb: > Die korrigierten Dateien für die 16x16 Matrix sind im Wiki hochgeladen. Fehler beim Einlesen, die Wörder überschneiden sich uneindeutig: Bei Spalte 10, Reihe 05: S oder E beim Wort FÜNFZEHN? Bei Spalte 11, Reihe 05: I oder H beim Wort FÜNFZEHN? Bei Spalte 12, Reihe 05: E oder N beim Wort FÜNFZEHN? Bei Spalte 10, Reihe 05: S oder E beim Wort ZEHN? Bei Spalte 11, Reihe 05: I oder H beim Wort ZEHN? Bei Spalte 12, Reihe 05: E oder N beim Wort ZEHN? Bei Spalte 12, Reihe 05: E oder N beim Wort NEUN*? Bei Spalte 13, Reihe 05: B oder E beim Wort NEUN*? Bei Spalte 14, Reihe 05: E oder U beim Wort NEUN*? Bei Spalte 14, Reihe 05: E oder U beim Wort UND? Ich habe trochzem mal ein HTML zum review hochgeladen: https://rawgit.com/TorstenC/94bc7ebb091784a2a1ad/raw/8336164689154105dd82ba15e322a0d84fb44fea/WC24h_16x16_Test.html
Zur Info an alle ich habe auch den WordClock2 Screensaver weiterentwickelt und Herbert zur Verfügung gestellt. Er hat auch einen "Simulationsmodus" dann können die Minuten/Stunden und der Displaymodus mit Tastendruck verändert werden. Wenn von Herbert was neues kommt (nur für 18x16) baue ich es ein und werde diesen dann auch hier wieder hochladen. @Torsten C.: Ich mache dir keine Konkurrenz da dein C# Simulator und deine HTML-Seiten um einiges ausgefeilter sind ;-) Die Daten von Herberts Access Tabellen trage ich händisch in C-Arrays ein. Damit haben wir dann mehrere Tools zur Fehlerprüfung.
Hans H. schrieb: > Die Daten von Herberts Access Tabellen trage ich händisch in C-Arrays > ein. Konkurrenz belebt das Geschäft. ;-) Wie müssen die C-Arrays aussehen? Dann kann die der C-Code-Generator im C#-DMU auch gleich erzeugen. PS: Kann jemand die Steuer-Daten im XML-Format gebrauchen? Das ist ein Abfallprodukt vom C#-DMU, siehe Anlage. Soll ich die ins Wiki stellen? PS: Die Links zu den HTML-Seiten habe ich im Wiki ergänzt. Fass das anders soll, bitte ändern: http://www.mikrocontroller.net/wikisoftware/index.php?title=WordClock24h&diff=86019&oldid=86006 PPS: Ich habe diesen Bilderrahmen: http://www.braun-phototechnik.de/de/products/detail/~id.724/Digiframe-8000-SLT.html Der hat 800 x 600 Pixel und kann Bilderwechsel alle 3s, alle 5s, alle 15s alle 30s, alle 60s oder länger. Man könnte also pro Minute 20, 12, 10, 6, 5, 4, 3 oder 2 Modi im Wechsel darstellen. Ich würde nun Bitmaps für die Modi * ES IST HH UHR UND MM MINUTEN (24) * ES IST MM M. NACH (VIERTEL NACH, HALB, VIERTEL) HH UHR (12) NACHTS und * ES IST MM M. NACH (VIERTEL NACH, HALB, DREIVIERTEL) HH UHR (12) NACHTS erzeugen, also pro Minute 12 Bilder im 5-Sekunden-Abstand, reihum in den o.g. Modi. Jeder Modus kommt also vier mal pro Minute zur Anzeige, oder auch einmal 20 Sekunden am Stück oder zweimal 10 Sekunden am Stück. Zu den Farben: Entweder ich mache pro Modus eine Frarbe oder pro Wort. Das ist mir egal. Was meint Ihr? Bibt es weitere, davon abweichende Wünsche für eine Bilderrahmen-Version?
Guten Morgen, melde mich zurück :-) Torsten C. schrieb: > DAS IST EIN COOLES KERNTEAM, das sich um den >> Beitrag "Minutengenaue 24 Stunden-Wortuhr - wer will mitbauen?" > gebildet hat! Das kann ich nur unterstreichen! Ist schon klasse, was Ihr in der vergangenen Woche auf die Beine gestellt habt. > Frank M. schrieb: >> Das ist einfach ein zusammengewürfelter Haufen > > Das sehe zumindest ich - trotz oder gerade wegen der > Streitkultur (Wikipedia) - inzwischen ganz anders! Hast Du das bewusst oder versehentlich aus dem Zusammenhang gerissen? Bei dem "zusammengewürfelten Haufen" ging es um die - nun ja - ziemlich heterogene Hardware auf Joachims Foto und nicht um die Leute hier. Gruß, Frank
Frank M. schrieb: > Hast Du das bewusst oder versehentlich aus dem Zusammenhang gerissen? Versehentlich, ich hatte es falsch verstanden. Sorry, der Groschen ist gefallen. "heterogene Hardware" ist m.E. nicht so schlimm. Konkurrenz hilft, heraus zu finden, was sich wirklich bewährt.
Torsten C. schrieb: > Wie müssen die C-Arrays aussehen? Dann kann die der C-Code-Generator im > C#-DMU auch gleich erzeugen. Ein Vorschlag für die Arrays findet sich in der hochgeladenen tables.h - Datei. Der Code zum Verwenden der Tabellen ist in usage.cpp. Ich habe dabei die tbl_hour und tbl_minutes als mehrdimensionales Array aufgebaut, um eine direkte Indizierung zu ermöglichen. Der erste Index ist der Modus, wie in tbl_modes vorgegeben (dabei mit Null anfangen). Der zweite Index ist die aktuelle Stunde bei tbl_hour (0..24) oder die Minute bei tbl_minutes (0..59). Dann kommen die Indizes der "An"-Wortteile, wobei ich keinen Count mitführe sondern eine 0 das Ende kennzeichnet. Designentscheidungen: - auch für 12h-Modi geht tbl_hour von 0..24 - feste Arraygrößen für "An"-Indizes Überlegungen: Die Sequenzen der "An"-Indizes könnte man in einer langen Kette führen, und in tbl_hour und tbl_minutes dann nur einen Index darauf setzen. Spart Speicher aber Codegenerator aufwendiger. Wie mehrfach erwähnt könnte man fast redundante Tabellen (Minuten an oder aus) per Programm-Code machen (aber dabei auf Einzahl/Mehrzahl achten). Das als Vorschlag, vielleicht spart ja der nächste Wurf händisches Einpflegen.
Hans H. schrieb: > Ein Vorschlag für die Arrays findet sich in der hochgeladenen tables.h - > Datei. > Der Code zum Verwenden der Tabellen ist in usage.cpp. Also für den Screensaver lohnt sich m.E. keine weitere Optimierung mit "Indizes … in einer langen Kette" usw. Den Code habe ich verstanden, ein Export kann ich machen. Du schreibst > int minute_txt_first; // do we really need to separate the indices? Nein, der eine Index (!=0) wird beim C#-DMU bereits beim Einlesen der *.accdb-Tabellen in ein einzelnes Datenfeld geschrieben. Wenn Du bool onWords[WpCount] zurück bekommst: Woher weisst Du, welches Wort aus welchen LEDs besteht? Dafür muss es doch auch noch eine Array-Struktur geben, oder? Die ändert sich ja auch noch und könnte auch gleich erzeugt werden.
Torsten C. schrieb: > Die ändert sich ja auch noch und könnte auch gleich erzeugt werden. PS: Ich meine diesen Teil hier(XML^^):
1 | <Words> |
2 | <Word id="w43" txt="NACHTS" row="8" col="0" len="6" /> |
3 | <Word id="w44" txt="ACHT*" row="8" col="1" len="4" /> |
4 | <Word id="w45" txt="HALB*" row="8" col="6" len="4" /> |
5 | ... |
6 | <Word id="w41" txt="NACH" row="8" col="0" len="4" /> |
7 | <Word id="w42" txt="NACHT" row="8" col="0" len="5" /> |
8 | </Words> |
@Sergej: Das war übrigens auch mit dem "Ach?!…" im folgenden Beitrag gemeint, Du hast es richtig verstenden? Torsten C. schrieb: > Sergej Wind schrieb: >> 16x16 würde mir reichen, da wesentlich weniger Aufwand. Dafür ist ja >> quasi schon alles fertig. > Ach?! ... Wie ich gehört habe, arbeitet Herbert gerade an fieberhaft zwei neuen Versionen. Danach gibt's dann neue HTMLs und Bitmaps für den Bilderrahmen (erstmal einfarbig) und Code für den Screensaver. @ Hans H. (loetkolben): Willst Du für 16 x 16 auch die gleichen Arrays haben oder größere Arrays, die über (16x16) und (18x16) indiziert sind, also beide Varianten umfassen?
Weiß es hier eigentlich jemand, ob das neue Design als solches auch anerkannt wird? Oder ist es aus der Sicht des Gesetzes nur eine Kopie? Ich bin gerade dabei für die übliche Variante der Hardware (10x11 Matrix) ein ganz anderes Design zu kreiren. Dabei wird die Zeit in Spiel-Würfeln angezeigt. Das Design ist eigentlich schon fertig und angemeldet. Ich habe aber mal gehört, dass ich alleine durch die gleiche Anordnung der Symbole schon Probleme mit B&F bekommen kann. Sorry, für den nicht ganz passenden Beitrag. Aber ich will keine Probleme mit B&F, wenn ich für euch die Fronten mache.
Sergej Wind schrieb: > ich will keine Probleme mit B&F, wenn ich für euch die Fronten mache. Ich bin kein Jurist, aber ich schätze, selbst ein Anwalt könnte nur mutmaßen, wie im Zweifel ein Richter entscheiden würde und wundert sich ggf. auch über die Entscheidung und geht ggf. in die Revision. Ich sehe zwei Möglichkeiten: ❶ Keine schlafenden Hunde wecken und alles per PN abwickeln ❷ B&F fragen, ob die ein Problem damit haben. PS: Aber war das nicht nur ein Gebrauchsmusterschutz? Da reichen doch kleine Abweichungen, um den zu umgehen.
Gut, dann probieren wir es mal mit der ersten Variante. :-)
Torsten C. schrieb: > Sergej Wind schrieb: >> ich will keine Probleme mit B&F, wenn ich für euch die Fronten mache. > > Ich bin kein Jurist, aber ich schätze, selbst ein Anwalt könnte nur > mutmaßen, wie im Zweifel ein Richter entscheiden würde und wundert sich > ggf. auch über die Entscheidung und geht ggf. in die Revision. B&F hat ein Geschmacksmuster (neudeutsch "Design") seit 2009, wurde 2014 verlängert: https://register.dpma.de/DPMAregister/gsm/register?GSNR=402009000849-0002 Insgesamt sind es derer sogar drei: deutsch in schwarz und rot und englisch in schwarz. Wenn man sich das genauer anschaut, entspricht selbst dieses Design nicht mehr dem Stand, den B&F heute vermarktet. Denn B&F hat die Tricks für die Dreisprachigkeit ("dreiviertel") und das darauf zwingend notwendige Ineinanderschieben der Wörter erst durch die Word Clock von uns "gelernt" und dann selber von uns übernommen. Warum sie überhaupt dieses Jahr das Geschmacksmuster verlängert haben, wenn sie es selber nicht mehr nutzen, ist mir schleierhaft. Schließlich kostet das Geld (ein paar hundert Euro). > ❷ B&F fragen, ob die ein Problem damit haben. Eher musst Du die Rechtsanwaltskanzlei fragen, die in dem obigen Link angegeben ist. > PS: Aber war das nicht nur ein Gebrauchsmusterschutz? Da reichen doch > kleine Abweichungen, um den zu umgehen. Eben, so ist es. Eine 24h-Wortuhr mit 18x16 ist eine erhebliche Abweichung. Ausserdem verletzt Du bei privatem Gebrauch sowieso keine Rechte.
Torsten C. schrieb: > Also für den Screensaver lohnt sich m.E. keine weitere Optimierung mit > "Indizes … in einer langen Kette" usw. Klar, das war auch als Anregung für den uC-Code gedacht, wo Speicher immer knapp ist. > Wenn Du bool onWords[WpCount] zurück bekommst: Woher weisst Du, welches > Wort aus welchen LEDs besteht? Dafür muss es doch auch noch eine > Array-Struktur geben, oder? Die ändert sich ja auch noch und könnte auch > gleich erzeugt werden. Das war ein Überbleibsel der ersten Version, wo in dem bool-Array ja nur die Wortbestandteile ein/ausgeschaltet wurden. Ich habe alles jetzt in einer Funktion implementiert, sieher neuer Anhang "usage.cpp" Anbei auch neuer Anhang "display.h" für das Layout und die Tabellen WordPos->Row/Start/Count der eingeschalteten LEDs. Wenn Du möchtest kannst du diese Tabelle auch generieren. Ich habe hier das ganze gedoppelt, um zwischen Doppel-S und Groß-ß umschalten zu können. Das muß aber Dein Export nicht tun. mfg, Hans
Hans H. schrieb: > Wenn Du möchtest kannst du diese Tabelle auch generieren. Naja, "möchten" ist übertrieben. Aber im Gesamtprojekt macht es m.E. sinn, dass wir eine geschlossene Toolkette haben und nicht bei jedem Update überall Handarbeit dazwichen ist. Wenn ich das vom Zeitaufwand schaffe, mache ich das deshalb. > Ich habe hier > das ganze gedoppelt, um zwischen Doppel-S und Groß-ß umschalten zu > können. > Das muß aber Dein Export nicht tun. Wir versuchen uns ja auf eine gemeinsame Frontplatte zu einigen, und die wird wohl (leider?) mit SS statt ẞ sein. Aktuell ist die Zuordnung .accdb zu Matrix "eins zu eins". Daher kann ich ohne Mehraufwand die ẞ-Variante nur mit modifizierter .accdb erzeugen. Es gibt aber auch einen XML-Ex- und -Import. Damit könnte man auch ohne MS Office beliebige Varianten erzeugen, z.B. mit ẞ. Lange Rede kurzer Sinn: Ich erzeuge bei Bedarf zwei einzelne Varianten, jeweils nur mit display[1][DisplayY] und Du kannst die bei Bedarf von Hand zusammen kopieren. OK? > ... > WP_DREI3, > WP_FUENF2, ... In der Datenbank heißen die "DREI***" oder "FÜNF**". Aus Ü ein UE machen ist kein Problem. Aber wenn die Wörter in der Datenbank auch FÜNF2 statt FÜNF** heißen würden, könnte ich mir an dieser Stelle eine weitere Umwandlung sparen. Also wenn der Codegenerator fertig ist und in den Tabellen immer noch Sterne drin sind, muss ich halt konvertieren. :-( @Herbert: Oder kannst Du die Sterne durch Ziffern ersetzen?
Torsten C. schrieb: > Aktuell ist die Zuordnung .accdb zu Matrix "eins zu eins". Daher kann > ich ohne Mehraufwand die ẞ-Variante nur mit modifizierter .accdb > erzeugen. > > Es gibt aber auch einen XML-Ex- und -Import. Damit könnte man auch ohne > MS Office beliebige Varianten erzeugen, z.B. mit ẞ. > > Lange Rede kurzer Sinn: Ich erzeuge bei Bedarf zwei einzelne Varianten, > jeweils nur mit display[1][DisplayY] und Du kannst die bei Bedarf von > Hand zusammen kopieren. OK? OK, das reicht völlig aus. Wenn Herbert eine Variante in der Datenbank hat, kann man ja ohne großen Aufand die andere daraus machen. > @Herbert: Oder kannst Du die Sterne durch Ziffern ersetzen? Würde ich auch begrüßen. Torsten, bitte auch mit checken daß die Reihenfolge der Indizes beim Export in C-Arrays stimmt, wir haben ja dann nur noch direkte Indizierung. Ich mußte händisch ein paar Datensätze umsortieren um den ersten Wurf zu erhalten.
Hans H. schrieb: > daß die Reihenfolge der Indizes ... in C-Arrays stimmt Welche meinst Du genau? Bei den LEDs ist es ja egal in welcher Reihenfolge die an gehen, gehen ja alle gleichzeitig an. Aber die LED-Indizes meinst Du sicher nicht. display.h schrieb:
1 | enum DisplaySS { WithSS, WithoutSS, WithSSCount }; ... |
2 | static const WordIllu illumination[WithSSCount][WpCount]= { ... |
* lol * Hans H. schrieb: > - auch für 12h-Modi geht tbl_hour von 0..24 Wenn man immer und überall sowohl mittags als auch nachts "ZWÖLF UHR" sagt, also auch im 12-h-Mode nicht zwischen "NULL" und "ZWÖLF" unterscheidet, könnte man die Arrays verkürzen. Aber ich denke, das geht zur Not mit manueller Nacharbeit ohne Tool-Unterstützung. Da finde ich die Optimierung mit "Indizes … in einer langen Kette" persönlich spannender. Wie sind Eure Meinungen zu den Indizes in einer langen Kette? Egal ob ATMEGA oder STM32: Die Routinen zum "entschlüsseln" können ja identisch sein, also muss der Aufwand nur von dem getrieben werden, der voran prescht. ;-)
display.h / display.c tables.h / tables.c Eigentlich gehören in die .h nur die Deklarationen mit "extern" und die Daten (Initialisierung) gehören nicht in die .h sondern in eine .c. Zu den Bergriffen: http://www.c-howto.de/tutorial-variablen-deklaration.html Aber das kann eine "Glaubensfrage" werden. Für den Screensaver kann ich das ja so machen, wie Hans der Lötkolben es möchte. Aber wie soll der Code für die µCs aussehen? @Hans: Wärest Du ggf. mit einer Trennung auch einverstanden? Mir ist's fast egal, ich will nur eine Diskussion zu einem Zeitpunkt vermeiden, wenn ich eigentlich dachte, fertig zu sein. Wie seht Ihr das?
Torsten C. schrieb: > Hans H. schrieb: >> daß die Reihenfolge der Indizes ... in C-Arrays stimmt > > Welche meinst Du genau? Bei den LEDs ist es ja egal in welcher > Reihenfolge die an gehen, gehen ja alle gleichzeitig an. Aber die > LED-Indizes meinst Du sicher nicht. Nein, die nicht. Aber z.B. in table_minutes: 4 ES IST MM MINUTEN NACH 0 0 2 1 2 4 ES IST MM MINUTEN NACH 2 0 5 1 2 10 39 40 Du siehst hier fehlt Minute 1 in der Reihenfolge, die kommt als Datensatz irgendwann später. > > display.h schrieb: >
1 | > enum DisplaySS { WithSS, WithoutSS, WithSSCount }; ... |
2 | > static const WordIllu illumination[WithSSCount][WpCount]= { ... |
3 | >
|
> > * lol * Ist doch schön! > Da finde ich die Optimierung mit "Indizes … in einer langen Kette" > persönlich spannender. > > Wie sind Eure Meinungen zu den Indizes in einer langen Kette? > Man muß jedoch bedenken daß das Indexfeld auch Platz braucht (mindestens 2 bytes), lohnt also nur wenn mittlere Länge der Sequenzen um mehr als zwei kleiner ist als die Arraygröße. Da bin ich mir jetzt nicht mehr so sicher ob das überhaupt gegeben ist.
Torsten C. schrieb: > display.h / display.c > tables.h / tables.c > > Eigentlich gehören in die .h nur die Deklarationen mit "extern" und die > Daten (Initialisierung) gehören nicht in die .h sondern in eine .c. > @Hans: Wärest Du ggf. mit einer Trennung auch einverstanden? Ich benutze die zwei h Dateien nur in einer cpp, du kannst das gerne ändern. Wenn Du es gleich auf uC ausrichtest, kannst Du auch gleich die stdint-Datentypen nehmen. Aber ob/welche für alle uC-Typen passen kann eine Glaubensfrage werden ;-) Und ob meine structs C-kompatibel sind müsste dann auch noch geprüft werden.
Hans H. schrieb: > die kommt als Datensatz irgendwann später. Ach so, ist klar. Schau Dir mal die XML oben an, da ist auch alles durcheinander. Das wird natürlich sortiert. Sort() ist ja in c#.net nur eine einzige Anweisung. Daher nehme ich ja c#.net. ;-) Hans H. schrieb: > ... lohnt also nur wenn ... Falls ich derjenige bin "der voran prescht"˄˄, kann ich mir auch vorstellen, die Wortanfänge mit einem gesetzten MSBit im Wort-Index zu kennzeichnen. Dann kommt man ohne zusätzlichen Index aus. Man kann dann entweder jedes Mal durchzählen oder im RAM einen Index aufbauen. Und mehr als 127 Wörter werden es nie!
Welche Datentypen für welche uC-Typen passen usw. sind Kleinigkeiten. Dafür gibt's entweder 'ne ComboBox zur Auswahl oder es werden bei jedem Export einfach alle Varianten in unterschiedlichen Dateien erzeugt. Bei der Array-Initialisierung gibt es m.E. große Unterschiede. Viele Compiler mögen es nicht, wenn bei "Zuweisung in der Deklaration"˄˄ auch explizit die Array-Größen angegeben werden. Andere Compiler dagegen meckern, wenn bei int[][] die Längen unterschiedlich sind, was sie bei int[,] vielleicht akzeptieren. Da werde ich auch beide Varianten unterstützen müssen. Und für diese dämichen Havard-AVRs kommt auch noch ein "progmem" rein. Aber das hängt von der gcc-Toolkette ab. Da muss ich auf Eure Infos warten. Ich hatte das oben schon mal gefragt.
Torsten C. schrieb: > Falls ich derjenige bin "der voran prescht"˄˄, kann ich mir auch > vorstellen, die Wortanfänge mit einem gesetzten MSBit im Wort-Index zu > kennzeichnen. Dann kommt man ohne zusätzlichen Index aus. Man kann dann > entweder jedes Mal durchzählen oder im RAM einen Index aufbauen. Und > mehr als 127 Wörter werden es nie! Da ist der übliche Spagat zwischen Laufzeit, Komplexität, Speicherverbrauch ;-) Ich habe die Arrays so entworfen daß sie als Konstanten fürs Datensegment dienen und daß vor dem Zugriff keine dynamische Indizierung notwendig ist. mfg
Hans H. schrieb: > Spagat zwischen Laufzeit, Komplexität, Speicherverbrauch Komplexität ➜ Macht man nur einmal, also egal. Laufzeit ➜ Egal, da eh langsam. Und ein Sleep-Mode brauchen wir nicht, da die LEDs eh viel Strom ziehen. Oder baut jemand 'ne Variante, die mit Batterie betrieben werden soll? Speicherverbrauch ➜ Eigentlich ist genug Flash da. Aber falls man statt 15 Modi am Ende auf 25 oder 50 kommt, wäre das ein Argument. Da fällt mir das KISS-Prinzip ein: Also keine Indizes in einer Kette, OK. :-) alea iacta est.
Eine batterie-betriebene Variante wurde schon oft versucht. Im besten Fall müsste man die Batterien wöchentlich tauschen. Ein Sleep-Mode wäre evtl. nicht schlecht, wenn man einen DCF77-Empfänger verbauen möchte. Das Multiplexing stört den Empfang. Die anderen Uhren werden nachts in den Blank-Modus versetzt, um den Zeitstempel zu empfangen und die Uhr zu synchronisieren.
Sergej Wind schrieb: > Ein Sleep-Mode wäre evtl. nicht schlecht, ... > Die anderen Uhren werden nachts in den Blank-Modus versetzt, um den > Zeitstempel zu empfangen und die Uhr zu synchronisieren. OK, das war zwar mit der Laufzeit˄˄ nicht gemeint, aber ist trotzdem ein interessanter Hinweis. :-) Mit Sleep-Mode meine ich einen Low-Power-Standby-Mode, aus dem der µC nur per Interrupt aufwacht. Das ist für den DCF77-Empfang sicher nicht nötig. Bei langer Laufzeit wäre der µC halt länger nicht im Sleep-Mode als bei kurzer Laufzeit. Egal, hat sich erledigt, denn Batterien wöchentlich tauschen will keiner und "Indizes in einer Kette" machen wir auch nicht! :-)
Sergej Wind schrieb: > Eine batterie-betriebene Variante wurde schon oft versucht. Im besten > Fall müsste man die Batterien wöchentlich tauschen. sehe ich zwar nicht, dank RTC DS3231 die ich verbauen werde > Ein Sleep-Mode wäre evtl. nicht schlecht, wenn man einen DCF77-Empfänger > verbauen möchte. Das Multiplexing stört den Empfang. aber das ist kritisch, ich multiplexe zwar nicht, werde aber die Power der DCF77 an einen Port legen um die abschalten zu können und bei Bedarf neustarten.
Joachim B. schrieb: > Sergej Wind schrieb: >> Im besten >> Fall müsste man die Batterien wöchentlich tauschen. > sehe ich zwar nicht, dank RTC DS3231 die ich verbauen werde Ich denke, es ging um die ca. 20mA pro LED (außer im Blank-Modus) und nicht um den DCF-77-Empfänger.
Torsten C. schrieb: > Ich denke, es ging um die ca. 20mA pro LED (außer im Blank-Modus) und > nicht um den DCF-77-Empfänger. ??? und wo soll dein batteriebetriebener DCF Empfänger mit µA Stromaufnahme dazu führen? Sergej Wind schrieb: > Eine batterie-betriebene Variante wurde schon oft versucht. Im besten > Fall müsste man die Batterien wöchentlich tauschen. alternativ ginge ja ein powercap der aufgeladen wird und per Umschalter CD4053 auf laden / dcf speisen umgeschaltet wird ich denke es liegt aber an der Versorgung verseucht durch den MC mit Filterung muss das doch in den Griff zu bekommen sein und wenn ich einen DC/DC Wandler SIM1 0512 von 5 V auf 12V Wandler und einen Linaerregler zu 3,3V LE33 .... TO92 oder SMD mit einer langen LC Filterkette als PI oder T Filter.
Joachim B. schrieb: > ??? :-) Nochmal ganz von Vorn: Die LEDs brauchen Strom (außer im Blank-Bode). Daher wären bei einer Batterie-betriebenen Wortuhr die Batterien schnell leer. Also hat die Uhr ohnehin ein Netzteil und man braucht deshalb nicht die Zeit im Low-Power-Mode optimieren, da der Mehrverbrauch an Strom egal ist. Ja, diese RTC-Module haben 'ne Batterie. Aber es ging oben um die Laufzeit der Berechnung der LED-Ansteuerung, und die wäre im Blank-Mode eh inaktiv. Und wer will im Blank-Mode den Stecker vom Netzteil ziehen, damit nur die RTC aus einer Batterie versorgt wird?
Torsten C. schrieb: > ber es ging oben um die > Laufzeit der Berechnung der LED-Ansteuerung, und die wäre im Blank-Mode > eh inaktiv. > > Und wer will im Blank-Mode den Stecker vom Netzteil ziehen? verstehe ich nicht, aber egal, mein DCF77 Empfangsproblem wird gelöst oder nicht, entweder schaffe ich die Filterung oder ich mache es mit wlan NTP oder kombiniert........
Joachim B. schrieb: > verstehe ich nicht, aber egal Mir am Ende auch. Joachim B. schrieb: > mein DCF77 Empfangsproblem wird gelöst oder nicht Das wird gelöst! Joachim B. schrieb: > mit wlan NTP oder kombiniert Das ist nachher "Spielkram", den jeder machen kann, wie er will. Du kannst ja jederzeit den Blank-Mode aktivieren. Und wie Gesagt: Wenn man nur WS2811-Controller hat und keine LED-Matrix, gibt es wahrscheinleich gar kein EMV-Problem.
Torsten C. schrieb: > Wenn man > nur WS2811-Controller hat und keine LED-Matrix, gibt es wahrscheinleich > gar kein EMV-Problem. doch leider hier, der Empfang ist zu mies. In der Wohnung muss ich beim Batteriewechsel die eine Funktuhr am Fenster aufstellen und dann braucht es 3-5 Versuche mit reset auslösen bis sie sich synchronisiert.
Joachim B. schrieb: > doch leider hier, der Empfang ist zu mies. Grundsätzlich, also auch bei ausgeschalteten LEDs? Dann ist das ein Problem abseits der obigen Diskussion. Ich persönlich habe dafür eine ganz andere Lösung: Auf dem Dachboden ist ein DCF-77-Empfänger, und der verteilt per NRF24L01+ in Funk-Beacons auch gleich die Uhrzeit im ganzen Haus. Ggf. über Relais-Stationen in Lichtschaltern oder Funkschalt-Steckdosen. Es gibt viele DCF-77-Empfänger. Den von Pollin z.B. kannst Du vergessen. Aber dazu gäbe es ganz viele andere Threads im µC.net.
Torsten C. schrieb: > Den von Pollin z.B. kannst Du vergessen. kann ja noch mal den von C probieren.....
Oder den von ELV, den nehme ich. Der von C. war in meinem Fall gerade nicht lieferbar. Torsten C. schrieb: > Den von Pollin z.B. kannst Du vergessen: Torsten C. schrieb: > http://www.mikrocontroller.net/attachment/199441/P...
Torsten C. schrieb: > Oder den von ELV, meinst du den? Artikel-Nr.: 68-09 16 10 der sieht dem Pollin aber ähnlich hatte ich früher auch so in der Art mal sehen, kosten gleich viel wie bei Conrad.
Angehängte Dateien:
-
dcf77.png
240 KB
Joachim B. schrieb: > meinst du den? ja, da kommen bei mir 100x bessere Signale raus als bei dem Pollin-Teil. Die Auswahl ist groß, das ist noch nicht alles.
Torsten C. schrieb: > @Herbert: Oder kannst Du die Sterne durch Ziffern ersetzen? Ist schon passiert :-) Torsten C. schrieb: > Es gibt viele DCF-77-Empfänger. Den von Pollin z.B. kannst Du vergessen. > Aber dazu gäbe es ganz viele andere Threads im µC.net. Ach du Schei...benkleister! Hab' mir heute Nacht das Pollin-Teil bestellt :-( Ist das tatsächlich Mist?
Ich habe bis jetzt auch die Polin-Teile verbaut. Wenn die Matrix aus ist, tun sie das was sie sollen.
Thema Wortüberschneidungen: Weiter oben wurde beim "alten" Entwurf bemängelt, dass sich die Wörter überschneiden. Das ist beabsichtigt und auch beim neuen Entwurf so, da sich ansonsten die Texte nicht in der Matrix unterbringen lassen. Der neue 18x16 Entwurf, den ich gestern abend vorab an Torsten und Hans zur Erstellung eines Mock-Ups bzw. Screensavers gemailt habe, sollte hoffentlich feherlfrei funktionieren (ich habe mehrere Tage intensiv daran gearbeitet). Er enthält wieder das Wort "MITTERNACHT" und in diesem Zusammenhang - als "Spielerei" sozusagen - auch einen eigenständigen Betriebsmodus "COUNTDOUWN MM MINUTEN VOR MITTERNACHT", wobei von 59 auf 0 Minuten herunter gezählt wird. Dieser Modus könnte am 31.Dezember ab 23:00 (oder auch später) an Stelle des "normalen" Anzeigemodus zugeschaltet werden. Da ich keinen Platz mehr für das Wort "WIRD" hatte, lautet der Text "ES IST MM MINUTEN VOR MITTERNACHT" (lieber hätte ich als Text: "ES WIRD IN MM MINUTEN MITTERNACHT" gehabt, aber das ist sich platzmäßig leider nicht ausgegangen). Wesentlich wichtiger als diese Spielerei ist jedoch, dass die Frontplatte in der Mitte der untersten Zeile Platz für 4 LEDs enthält, die für diverse Anzeigen zur Verfügung stehen (DCF77-Synchronisation, Sekunden-Blinken, etc.). An dieser Position ließe sich evtl. auch eine 7-Segment-Anzeige etc. als Einstellhilfe für die Betriebsarten bzw. als Fernbedieunungs-Kontrolle oder Ähnliches einbauen (müsste im Normalbetrieb natürlich dunkel gesteuert werden). Ich habe die neuen Dateien noch nicht ins Wiki gestellt, weil ich mir dachte, ein Vorab-Test durch Torsten und Hans wäre zweckmäßig. Sollte aber jemand Bedarf an dieser zip-Datei haben, bitte ich um Nachricht per PN.
Sergej Wind schrieb: > Ich habe bis jetzt auch die Polin-Teile verbaut. Wenn die Matrix aus > ist, tun sie das was sie sollen. Eben. Es reicht vollkommen, 1x am Tag die Uhrzeit per DCF77 zu synchronisieren. Bei der bisherigen Word Clock ist die Zeit einstellbar, z.B. nachts um 3 Uhr. Desweiteren kann man bei der Word Clock einstellen, zu welchen Zeiten die Uhr abgeschaltet (d.h. Display dunkel) ist. Dann sind die Störungen, die durch die PWMs entstehen, weg und das DCF77-Modul arbeitet problemlos. Übertragen auf dieses Projekt heisst das, dass die WS28xx-Übertragung abgeschaltet wird. Wir sollten das also ähnlich machen. P.S. Interessant, welche Probleme/Aufgaben sich wiederholen. Man kann schon einiges von dem bisherigen Word Clock-Projekt lernen ;-)
Herbert P. schrieb: > Weiter oben wurde beim "alten" Entwurf bemängelt, dass sich die Wörter > überschneiden. Echt? Wo wurde denn das Problem gesehen? Herbert P. schrieb: > ich habe mehrere Tage intensiv daran gearbeitet Ein großes DANKE von mir! :-) Herbert P. schrieb: > Vorab-Test durch Torsten und Hans wäre zweckmäßig In meinen nächsten dafür verfügbaren 20 Minuten aktualisiere ich die HTML-Test-Seiten, also hoffentlich heute noch.
Herbert P. schrieb: > Mitte der untersten Zeile Platz für 4 LEDs enthält, > die für diverse Anzeigen zur Verfügung stehen sehr guter Vorschlag, unterstütz ich von Herzen, ich dachte zwar nur an 3, aber 4 tun auch nicht weh! DCF77sync, NTPsync, Sekunde, IRquitt wäre so meine Idee, auch als WS2811/12/b in jeder Farbe/Helligkeit möglich Abstand der Felder 16mm oder 32mm muss ja nicht am selben Port wie die Uhr hängen und wäre auch für die Matrixnutzer interessant.
Herbert, vielen Dank für Deine Mühe. Das zipfile ist angekommen. Ich würde gerne den C-Code-Generator von Torsten C. verwenden, mein Test beginnt sobald dieser fertig ist. Zum Thema Wortüberschneidungen: Das ist ja gerade das Witzige, ich sehe dabei auch kein Problem.
Hans H. schrieb: > Zum Thema Wortüberschneidungen: Das ist ja gerade das Witzige, > ich sehe dabei auch kein Problem. Sehe ich genauso: Je mehr augenscheinliches Chaos auf der Platte ist, desto besser ist der Aha-Effekt. Überschneidungen sollten daher überall da verwendet werden, wo es möglich ist. Ebenso sollten die Zahl-Wörter nicht unbedingt in aufsteigender Reihenfolge da stehen, sondern möglichst durcheinander - eventuell durch irreführende Füllbuchstaben getrennt.
Ich finde schon daß die Zahlwörter in aufsteigender Reihenfolge stehen sollten, denn die dann leuchtenden sollten ja "natürlich" von links nach rechts und von oben nach unten zu lesen sein, oder meinst Du etwas anderes? Zum Thema Füllzeichen: Ich würde begrüßen wenn damit statt stupide I zu nehmen ;-) versucht wird sinnvolle Wörter/Wortbestandteile zusammen mit den "Uhr"-Wörtern zu finden.
Hans H. schrieb: > Ich finde schon daß die Zahlwörter in aufsteigender Reihenfolge stehen > sollten, denn die dann leuchtenden sollten ja "natürlich" von links nach > rechts und von oben nach unten zu lesen sein, Ja, natürlich sollten die leuchtenden schon lesbar in der richtigen Reihenfolge stehen, klar. > oder meinst Du etwas anderes? Ja. Ein simples Beispiel: EINS ZWEI DREI Wenn diese exklusiv leuchten (also immer nur eines von den dreien), dann kann man auch schreiben: DREI EINS ZWEI Jetzt noch ineinanderschieben: DREINS ZWEI oder auch ZWEINS DREI dann noch Auffüllen mit Zeichen, die in die Irre führen, wenn das Gehirn versucht, daraus Wörter zu bilden (das versuchen wir automatisch!): AZWEINSUDREIH Zusammenfassung: Je chaotischer der NICHT-beleuchtete Teil aussieht, desto besser. Dann kristalisieren sich die Wörter erst beim Aufleuchten heraus.
Frank M. schrieb: > Jetzt noch ineinanderschieben: > > DREINS ZWEI > > oder auch > > ZWEINS DREI > > dann noch Auffüllen mit Zeichen, die in die Irre führen, wenn das Gehirn > versucht, daraus Wörter zu bilden (das versuchen wir automatisch!): > > AZWEINSUDREI super, gefällt mir sehr gut !
Hans H. schrieb: > Ich würde gerne den C-Code-Generator von Torsten C. verwenden, > mein Test beginnt sobald dieser fertig ist. Ob ich die HTMLs heute noch schaffe?! Ich muss nach Feierabend noch zum Arzt und heute Abebd wollte ich ja in die "Euse"˄˄. Mit dem C-Code-Export habe ich noch gar nicht angefangen. Ich nehme mir mal Samstag als Ziel-Termin vor. [... gelöscht] Hans H. schrieb: > Zum Thema Füllzeichen Zumindest das C#-Mockup setzt da wahlweise ein "#" oder ein schwarzes Feld ein. Da das Design damit nicht mehr grundsätzlich gefährdet ist, können wir das immer noch festleben, kurz bevor Frontplatten gefertigt werden. Hans H. schrieb: > wenn damit … versucht wird sinnvolle Wörter/Wortbestandteile > zusammen mit den "Uhr"-Wörtern zu finden. Es wäre toll, wenn das von irgendwem gemacht werden würde. Ja. * kopfschüttel *
Joachim B. schrieb: > sehr guter Vorschlag, unterstütz ich von Herzen, ich dachte zwar nur an > 3, aber 4 tun auch nicht weh! 4 wegen der Symmetrie, sollen ja alle LEDs schön in der Mitte Aufstellung nehmen ;-) Frank M. schrieb: > Sehe ich genauso: Je mehr augenscheinliches Chaos auf der Platte ist, > desto besser ist der Aha-Effekt. Überschneidungen sollten daher überall > da verwendet werden, wo es möglich ist. Ebenso sollten die Zahl-Wörter > nicht unbedingt in aufsteigender Reihenfolge da stehen, sondern > möglichst durcheinander - eventuell durch irreführende Füllbuchstaben > getrennt. Ich habe das auch so gesehen und mich bemüht, wenigstens ein wenig Chaos hineinzubringen. Aus Platzgründen und wegen der erforderlichen Reihenfolge bei der Zeitanzeige war das aber leider nur eingeschränkt möglich. Torsten C. schrieb: > Hans H. schrieb: >> wenn damit … versucht wird sinnvolle Wörter/Wortbestandteile >> zusammen mit den "Uhr"-Wörtern zu finden. > > Es wäre toll, wenn das von irgendwem gemacht werden würde. Ja. Im Arbeitsblatt "Textüberprüfung" der Excel-Datein WC24h18x16.xlsx sind die frei verfügbaren Kästchen weiß und ohne Buchstaben dargestellt. Aber sehr viele kreative Wörter lassen sich damit halt leider nicht bilden :-( Wenn Bedarf ist, stelle ich die zip-Datei mit den neuen Daten gerne jetzt schon in's Wiki.
Herbert P. schrieb: > Vorab-Test durch Torsten Ergebnis des Import ins C#-DMU: 49_SECH: Länge muss 4 sein 39_DREIVIERTEL: Start bei Spalte 7 statt 6 Die üblichen "Prüfmuster" sind aktualisiert: https://rawgit.com/TorstenC/1a59b9c73730eb8e144d/raw/WC24h_18x16_Test.html ► Sind die Formulierungen und Wort-Anordnungen wie gewünscht? ► Sind die Steuer-Tabellen fehlerfrei, oder sind falsche LEDs an? "ES IST EINS NACH EINS" im 12h-Mode finde ich immer noch doof. https://rawgit.com/TorstenC/1a59b9c73730eb8e144d/raw/WC24h_18x16_Test.html#M7T0101 Achtung: Immer etwas warten, bis der Browser zum Anker gesprungen ist, hier z.B. "#M7T0101" ➜ Mode 7 um 01:01 Uhr.
@Torsten: WOW! ist ja gewaltig, was Du da fabriziert hast! SUPER, GRATULIERE - und DANKE!!! Bin grad dabei, die Fehler zu editieren, die korrigierte Version geht noch heute Vormittag raus. Torsten C. schrieb: > "ES IST EINS NACH EINS" im 12h-Mode finde ich immer noch doof. Es gibt in verschiedenen Modi etliche Kombinationen, die wohl in dieser Form wenig bis gar nicht gebräuchlich sind. ich stelle mir daher vor, dass wir gemeinsam eine "Mischform" erarbeiten, die den tatsächlichen Gepflogenheiten besser entspricht.
Herbert P. schrieb: > ich stelle mir daher vor, > dass wir gemeinsam eine "Mischform" erarbeiten, die den tatsächlichen > Gepflogenheiten besser entspricht. Da das ohne Auswirkungen auf das Frontplatten-Layout geht: Guter Plan. :-) Herbert P. schrieb: > korrigierte Version geht noch heute Vormittag raus. Habe ich Dir gerade als Mail geschickt. Einen kleinen Fehler hatte ich heute früh noch gefunden. Auf der HTML-Test-Seite bei GitHub ist der bereits korrigiert. Herbert P. schrieb: > ist ja gewaltig, was Du da fabriziert hast Wenn man die Daten erstmal in ein Objektmodell aus IDictionarys und ILists gespeichert hat, ist der Rest mit C# ja Pipifax.
Angehängte Dateien:
-
wclock24-in-putty.png
7,2 KB
Moin zusammen, mich hat es in den Fingern gejuckt, mich endlich mal um die konkrete µC-Entwicklung zu kümmern. Ich habe mir deshalb gestern abend ein STM32F4-Discovery geschnappt und folgende Module zusammengestellt: - IRMP-Port auf STM32F4-Disco Das war ziemlich simpel, da IRMP bereits auf STM32 portiert wurde - MCURSES-Port auf STM32F4-Disco Damit haben wir während der Entwicklung einen ASCII-Monitor, welcher in einem Terminal (putty, xterm etc) läuft. Im Moment wird wird dort die WordClock-Front zusammen mit der Uhrzeit gezeigt, siehe Hardcopy. Auf dem Disco-Board muss lediglich ein Micro-USB-Kabel an den PC angeschlossen werden. Zusammen mit dem richtigen Treiber hat man dann einen virtuellen COM-Port. Es kann aber auch jeder freie UART auf dem Disco-Board verwendet werden. Das zusammengestellte Programm läuft im Moment unter Linux und auch direkt auf dem Disco-Board. Dafür habe ich die tables.h von Torsten verwendet. Allerdings musste ich da einiges an Windows-Spezifika durch portableren Code ersetzen, Ebenso habe ich einige C++-Eigenarten, die hier genutzt wurden, in reines C verwandelt. Die dargestellte Uhr schaltet alle 5 Sekunden auf die nächste Uhrzeit um. Mit bestimmten Tasten kann man dies aber beschleunigen: m: Minute inkrementieren M: Minute dekrementieren h: Stunde inkrementieren H: Stunde dekrementieren q: Programm verlassen (nur unter Linux) Geplant sind auch noch Tasten, um den Stunden- und Minuten-Anzeige-Modus zu ändern. @Torsten: Schau Dir mal bitte in der angehängten tables.h die Kommentare "// fm" an. Wäre schön, wenn Du diese bei der nächsten Version mit berücksichtigen würdest. Ich möchte das Projekt am liebsten auf einem SVN-Server einstellen, damit wir alle daran arbeiten können. Dazu könnten wir entweder den SVN-Server von µC.net verwenden oder einen privaten Internet-Server von mir. Da kann ich jedem Interessierten einen SVN-Account einrichten. Ich sehe da im wesentlichen folgende Module, die es zu entwickeln gibt: 1. Pflege der Wort-Tabellen (tables.h usw.) 2. Ansteuerung der WS2812-Stripes 3. Benutzer-Interaktion mittels IRMP (Anlernen, Farbe & Uhrzeit stellen usw.) 4. Debugging-Monitor mit MCURSES (insb. Display Front, Logging usw.) 5. I2C-Routinen zur Ansteuerung der DS3231 6. I2C-Routinen zur Ansteuerung eines I2C-EEPROMS (Speicherung der Einstellungen) 7. Anpassung der Helligkeit an die Umgebung mittels LDR 8. Anbindung von diversen DCF77-Modulen 9. Anbindung eines WLAN-Moduls ESP8266 10. Zugriff auf NTP-Server via WLAN Die Punkte 3 und 4 möchte ich gerne machen, da sowohl IRMP und MCURSES sowieso meine Kinder sind. I2C-Low-Level-Routinen für das Disco-Board habe ich auch schon fertig. Es fehlt nur noch die konkrete Anbindung an die RTC und das EEPROM. Diese habe ich schon für ATmegas gemacht - u.a. im Rahmen des bisherigen Word Clock-Projektes. Daher kann ich das auch übernehmen. Zur Realisierung habe ich mir: http://www.amazon.de/gp/product/B00K67X496 bestellt. Da ist RTC und EEPROM bereits drauf. Bleiben noch die Punkte 1, 2, 7, 8, 9, 10 und alles, was ich vergessen habe. Meinungen/Vorschläge dazu?
Frank M. schrieb: > Das zusammengestellte Programm läuft im Moment unter Linux und auch > direkt auf dem Disco-Board. Hammer! Aber geht natürlich auch. Frank M. schrieb: > Dafür habe ich die tables.h von Torsten verwendet. Die sind von Hans dem Lötkolben und Vorlage für meinen Code-Generator. Frank M. schrieb: > Wäre schön, wenn Du diese bei der nächsten Version mit > berücksichtigen würdest. Klar, mache ich. Frank M. schrieb: > Ich möchte das Projekt am liebsten auf einem SVN-Server einstellen, Warum nicht bei GitHub? Das funktioniert auch bei anderen Projekten im µC.net wuderbar.
Torsten C. schrieb: > Frank M. schrieb: >> Das zusammengestellte Programm läuft im Moment unter Linux und auch >> direkt auf dem Disco-Board. > > Hammer! Aber geht natürlich auch. Unter Linux kann ich schneller entwickeln, da brauche ich nicht zwischendurch zu flashen ;-) Aber sobald die Hardware-abhängige Programmierung ansteht, läufts natürlich nicht mehr direkt unter Linux. > Frank M. schrieb: >> Dafür habe ich die tables.h von Torsten verwendet. > > Die sind von Hans dem Lötkolben und Vorlage für meinen Code-Generator. Ahso. > Warum nicht bei GitHub? Das funktioniert auch bei anderen Projekten im > µC.net wuderbar. Meinetwegen auch bei GitHub. Ist mir schnuppe. Ich poste hier heute abend mal das komplette CoIDE-Projekt - oder besser: ich lege es als Zip-Datei im Artikel ab. Linux-Makefile füge ich auch hinzu. Es wäre klasse, wenn sich noch jemand für die offenen Punkte verantwortlich fühlen würde. Ist ja schließlich ein Gemeinschafts-Projekt ;-)
ich warte immer noch auf meine m1284p Platinen, hatte mit DIL mal einen Prototyp aufgebaut der noch nicht Aruino kompatibel läuft. 5x DCF77 von ELV sind bestellt weil die Pollin Teile schlecht laufen. Es soll ja für jeden Mitbauer was dabei sein :-)
Angehängte Dateien:
Neues Layout der 18x16 Matrix: Da mit dem ursprünglichen Layout der 18x16 Matrix manche Wortkombinationen nicht möglich waren, blieb mir nichts Anderes übrig, als noch einmal von vorne zu beginnen und das Design sowie die zu Grunde liegenden Tabellen völlig neu zu erarbeiten. Das neue Design habe ich heute in der aktuellen Version WC24h18x16_V2.zip hochgeladen. Neues Layout siehe Bild. Die hier verwendete Schrift ist die Humanist 777 Light. Sie ist etwas zarter als die Futura Light, welche wiederum zarter als die Arial ist. Ich könnte mir diese Schrift für die Acrylglas-Frontplatte gut vorstellen, für die Stahlfrontplatte ist sie mangels Stegen nicht geeignet. Hier ein paar Frontplattenfotos eines QlockTwo Nachbaus mit Acrylglas-Frontplatte, die mir sehr gut gefallen haben. Das Orange der nicht leuchtenden Buchstaben ist sicherlich auf eine orange Vordergrundbeleuchtung zurückzuführen, hat mich jedoch auf die Idee gebracht, ob es nicht schön anzuschauen wäre (sofern vom Stromverbrauch her vertretbar), wenn die Wörter der anzuzeigenden Uhrzeit weiß beleuchtet werden, während alle anderen Buchstaben orange oder in einem anderen Farbton leuchten: https://www.flickr.com/photos/ruudburger/sets/72157622708125775/ Für die Stahlfrontplatte gefällt mir der von B&F verwendete Schriftfont der Original QlockTwo sehr gut, leider habe ich ihn trotz intensiver Suche bisher nirgendwo gefunden. Hat vielleicht jemand einen Tipp? http://1.bp.blogspot.com/-MVCrnt6ox_Y/T0OXzcYnqzI/AAAAAAAAEpY/UahSRCdQnws/s1600/Qlocktwo-Stainless-Steel-screen.jpg Die beiden Bilder des neuen Frontplattenentwurfs sind identisch, ich habe sie irrtümlich 2 x hochgeladen, sorry...
Joachim B. schrieb: > 5x DCF77 von ELV sind bestellt ... > Es soll ja für jeden Mitbauer was dabei sein :-) Bestellst Du jetzt für andere mit? Ich habe hier auch noch viel Kram rumliegen. Falls davon was gebraucht wird, muss mur mal jemand was sagen. Frank M. schrieb: > ich lege es als Zip-Datei im Artikel ab http://www.clikezebra.com/de/kacke-t-shirt-women-black.html Wenn Du sowieso GitHub nehmen möchtest: Mach das doch gleich richtig. ;-) Frank M. schrieb: > für die offenen Punkte verantwortlich fühlen Haben da alle den Überblick? Ich nicht, sorry. Gibt es eine Offene-Punkte-Liste?
Torsten C. schrieb: > Bestellst Du jetzt für andere mit? eigentlich nicht, ich verbau das schon, aber wenn Engpässe bestehen sollten helfe ich zur Not aus
Torsten C. schrieb: > Joachim B. schrieb: >> 5x DCF77 von ELV sind bestellt ... >> Es soll ja für jeden Mitbauer was dabei sein :-) > > Bestellst Du jetzt für andere mit? Ich habe hier auch noch viel Kram > rumliegen. Falls davon was gebraucht wird, muss mur mal jemand was > sagen. Ich denke, wir sollten vielleicht einen Pool initiieren, in dem jeder seine Angebote und Überbestände einbringen kann.
Herbert P. schrieb: > Die beiden Bilder des neuen Frontplattenentwurfs ... haben unten Punkte und kein L. Wenn Du für "74_LED1" in Spalte [text_show] das Unicode-zeichen ● einbaust, dann wird das auch im c#-DMU-HTML-Generator richtig dargestellt. Für 75..77 gilt das Gleiche.
Angehängte Dateien:
-
20141116-_MG_6929.jpg
15 MB
Herbert P. schrieb: > Neues Layout der 18x16 Matrix: > > Hier ein paar Frontplattenfotos eines QlockTwo Nachbaus mit > Acrylglas-Frontplatte, die mir sehr gut gefallen haben. Das Orange der > nicht leuchtenden Buchstaben ist sicherlich auf eine orange > Vordergrundbeleuchtung zurückzuführen, hat mich jedoch auf die Idee > gebracht, ob es nicht schön anzuschauen wäre (sofern vom Stromverbrauch > her vertretbar), wenn die Wörter der anzuzeigenden Uhrzeit weiß > beleuchtet werden, während alle anderen Buchstaben orange oder in einem > anderen Farbton leuchten: Hier mal eine Front, bei der man die unbeleuchteten Buchstaben gut erkennt. Um die unbeleuchteten Buchstaben in einer anderen Farbe leuchten zu lassen, wäre eine einfache Kantenbeleuchtung denkbar. (Nur bei Acryl) Ich brobiere mal aus, ob es gut funktioniert.
Ok, hat sich schon erledigt. Das Kantenlicht kommt nicht weit genug in die Platte. :-)
Sergej Wind schrieb: > Hier mal eine Front, bei der man die unbeleuchteten Buchstaben gut > erkennt. 15 MB? Lass das bloß keinen Mod sehen ;-) Ein paar hundert KB hätten dafür auch gereicht.
Torsten C. schrieb: > Haben da alle den Überblick? Ich nicht, sorry. Gibt es eine > Offene-Punkte-Liste? Die habe ich doch heute morgen veröffentlicht: Beitrag "Re: Minutengenaue 24 Stunden-Wortuhr - wer will mitbauen?" (s. dort untere Hälfte, Punkte 1-10). Du hast sogar auf dieses Posting geantwortet... überlesen? ;-)
Frank M. schrieb: > Torsten C. schrieb: >> Gibt es eine Offene-Punkte-Liste? > Die habe ich doch heute morgen veröffentlicht: Ich war mir nicht sicher, ob das alles ist. Frank M. schrieb: > und alles, was ich vergessen habe. Fehlt noch was? Frank M. schrieb: > Bleiben noch die Punkte 1, 2, 7, 8, 9, 10 ❶ Pflege der Wort-Tabellen (tables.h usw.) ?! Die werden (hoffentlich ab Samstag) aus der .accdb purzeln. Zumindest die Ersten. Varianten gibt’s dann bei Bedarf auf Zuruf. Den CodeGenerator kann von mir aus auch jeder so verändern wie er mag. Wenn der Code einigermaßen lesbar ist, stelle ich das C#-DMU bei GitHub online. ❷ Ansteuerung der WS2812-Stripes Das geht beim STM32 am besten per DMU und SPI oder USART, der Code läuft bei mir seit zwei Wochen. Für die AVRs soll es Inline-Assembler geben. Für den MSP430 habe ich auch Inline-Assembler hier, aber der hat ja zu wenig RAM. ❺ I2C-Routinen zur Ansteuerung der DS3231 Der STM32 hat ein Batterie-Pin und eine RTC eingebaut ❼ Anpassung der Helligkeit an die Umgebung mittels LDR Ich würde lieber einen I²C Ambient-Light-Sensor nehmen. Ich habe hier einen auf ´ner Breakout-Platine. ❽ Anbindung von diversen DCF77-Modulen Gibt es dafür keine dieser berühmt-berüchtigten Arduino-Bibliotheken? ❾ Anbindung eines WLAN-Moduls ESP8266 Habe ich da, aber noch nicht ausprobiert → Wer will vorprechen? Wollen wir Rudi mal fragen? ❿ Zugriff auf NTP-Server via WLAN Nach ❾, falls das damit geht?
Torsten C. schrieb: > Wenn Du für "74_LED1" in Spalte [text_show] das Unicode-zeichen ● > einbaust, dann wird das auch im c#-DMU-HTML-Generator richtig > dargestellt. oki
Torsten C. schrieb: > Fehlt noch was? Das weiß ich ja noch nicht ;-) > ❶ Pflege der Wort-Tabellen (tables.h usw.) > > ?! Die werden (hoffentlich ab Samstag) aus der .accdb purzeln. Prima. Dann kümmerst Du Dich auch zukünftig darum? Es wird sicherlich auch weiterhin noch Änderungen geben. Herbert hat ja erst heute mittag wieder mal ein völlig neues Layout gepostet. > ❷ Ansteuerung der WS2812-Stripes > > Das geht beim STM32 am besten per DMU und SPI oder USART, der Code läuft > bei mir seit zwei Wochen. Ja, DMA wäre für das STM32F4-Disco das einfachste. Beispiel-Routinen gibt es zuhauf. Das sollte kein großes Problem sein. > Für die AVRs soll es Inline-Assembler geben. Ja, ätzend. Aus genau diesem Grunde bin ich auch nicht an einem AVR-Port interessiert. Während die LEDs gefüttert werden, kann der ATmega nichts anderes mehr machen... > Für den MSP430 habe ich auch Inline-Assembler hier, aber der hat ja zu > wenig RAM. Ich werde mich komplett auf das STM32F4-Discovery konzentrieren. Das Ding ist mit 16 EUR unschlagbar billig und hat alles in Hülle und Fülle. > ❺ I2C-Routinen zur Ansteuerung der DS3231 > > Der STM32 hat ein Batterie-Pin und eine RTC eingebaut Ja, weiß ich. Da muss dann aber zumindest eine Lötbrücke auf dem Board weggebrannt und eine Batterie angelötet werden. So genau ist die STM32-RTC aber auch nicht.... Bleibt immer noch das EEPROM-Problem. Okay, Uwe auf http://mikrocontroller.bplaced.net/ hat da zwar einen EEPROM-Simulator anzubieten, der das Flash nutzt. Aber erstmal lässt sich ein Flash nicht so oft beschreiben wie ein EEPROM und außerdem berichten einige User von Problemen damit. Ausserdem ist das Amazon-Dingens mit unter 2 EUR für RTC und EEPROM unschlagbar billig. Ich werde es auf jeden Fall damit realisieren. > ❼ Anpassung der Helligkeit an die Umgebung mittels LDR > > Ich würde lieber einen I²C Ambient-Light-Sensor nehmen. Ich habe hier > einen auf ´ner Breakout-Platine. Hört sich interessant an. Kenne ich nicht. Hast Du da mal eine lesenswerte Quelle? Okay, den Teil übernimmst Du auf jeden Fall ;-) > ❽ Anbindung von diversen DCF77-Modulen > > Gibt es dafür keine dieser berühmt-berüchtigten Arduino-Bibliotheken? Igitt. Seit wann laufen diese denn auf einem STM32? ;-) Für die Word Clock wurde ein recht allgemeines Modul programmiert, welches selbsttätig erkennt, ob das DCF-Modul high- oder low-aktiv ist und ob dieses bereits einen eigenen Pullup-/Pulldown-Widerstand eingebaut hat. Ich finde diese Vorgehensweise recht gut gelungen, da man damit eigentlich alle auf dem Markt zu findenden DCF-Module anbinden kann. Leider ist die Software jedoch recht empfindlich bei Störungen. Da müsste was dran gemacht werden. > ❾ Anbindung eines WLAN-Moduls ESP8266 > > Habe ich da, aber noch nicht ausprobiert → Wer will vorprechen? Wollen > wir Rudi mal fragen? Ich hatte auch mal vor zwei Monaten 5 Stück bestellt. Diese liegen bei mir seitdem zuhause rum. Bin noch nicht dazu gekommen, sie auszuprobieren. Rudi? Bitte nicht! Dann dreh' ich durch ;-) Eher mach ich das... oder wir beide zusammen. > ❿ Zugriff auf NTP-Server via WLAN > > Nach ❾, falls das damit geht? Jepp. Ich werde die Punkte heute abend mal zusammenfassend in den WordClock24h-Artikel einpflegen...
Torsten C. schrieb: > Frank M. schrieb: >> Torsten C. schrieb: >>> Gibt es eine Offene-Punkte-Liste? >> Die habe ich doch heute morgen veröffentlicht: > > Ich war mir nicht sicher, ob das alles ist. > > Frank M. schrieb: >> und alles, was ich vergessen habe. > > Fehlt noch was? nur der Vollständigkeit halber: die ganze Mechanik fehlt noch: - Gehäuse (sofern man nicht den 50x50 Ribba- Rahmen nehmen möchte); - Grundplatte für LED-Matrix inkl. Verkabelung - gefräste MDF-Platte zur optischen Abgrenzung der LEDs mit Neodym-Magneten zur Frontplattenbefestigung (sofern man keinen Ribba-Rahmen verwenden möchte) - Platzierung von Platinen, LDR, Buchse für PC-Anschluss, ggf. Lautsprecher; - Dimmbare, färbige Hintergrundbeleuchtung mit LED-Stripes? - Stromversorgung, Zuleitungen und Befestigung: Drahtseile zum Abhängen von der Decke? Netzteil in der Deckenbefestigung? - Verdrahtungsplan - Last, but not Least: Frontplatte
Frank M. schrieb: > Herbert hat ja erst heute mittag > wieder mal ein völlig neues Layout gepostet. Den folgenden Link muss ich nicht immer wieder posten, steht auch im Wiki, also hier das letzte Mal: https://rawgit.com/TorstenC/1a59b9c73730eb8e144d/raw/WC24h_18x16_Test.html Aktualisiert mit der Verson von heute Mittag. Ich versuche immer innerhalb weniger Stunden die HTML-Test-Seite zu aktualisieren.
Torsten C. schrieb: > Den folgenden Link muss ich nicht immer wieder posten, steht auch im > Wiki, also hier das letzte Mal: > > https://rawgit.com/TorstenC/1a59b9c73730eb8e144d/raw/WC24h_18x16_Test.html Ja, hatte ich auch schon heute morgen probiert. Und eben auch noch mal: Ergebnis: Firefox zieht sich ein paar GB Memory wegen der vielen Graphiken rein und muss dann nach 5 Minuten Wartezeit abgeschossen werden. Nach zwei bis drei dieser Versuche hat der FF dann alles geladen und ich werde von 1000enden von Bildern geradezu erschlagen. FF zieht dann fast 100% CPU, das Memory ist voll und ich kann nur noch stockend scrollen. Sorry, diese Seite ist nicht gerade hilfreich. > Aktualisiert mit der Verson von heute Mittag. Wo finde ich da die dazugehörende tables.h? Bitte NICHT auf diese Horror-Seite legen. > Ich versuche immer innerhalb weniger Stunden die HTML-Test-Seite zu > aktualisieren. Eine interaktive Seite wäre mir lieber, wo ich minuten-/stundenweise vor- und zurückblättern kann. Genau das macht die Software bereits auf dem STM32, die ich heute morgen vorgestellt habe.
Frank M. schrieb: > Ergebnis: Firefox zieht sich ein paar GB Memory wegen der vielen > Graphiken rein und muss dann nach 5 Minuten Wartezeit abgeschossen > werden. Nach zwei bis drei dieser Versuche hat der FF dann alles geladen > und ich werde von 1000enden von Bildern geradezu erschlagen. FF zieht > dann fast 100% CPU, das Memory ist voll und ich kann nur noch stockend > scrollen. > > Sorry, diese Seite ist nicht gerade hilfreich. Bei mir wirds schnell geladen und funktioniert anstandslos, CPU-Auslastung 23%, Memory insgesamt 5,4 GB belegt (lt. Taskmanager)
Herbert P. schrieb: > Bei mir wirds schnell geladen und funktioniert anstandslos, > CPU-Auslastung 23%, Memory insgesamt 5,4 GB belegt (lt. Taskmanager) Das glaub ich Dir schon, ich hab halt "nur" 4 GB RAM ;-) Aber Torsten könnte die Seite auch durchaus splitten auf mehrere Seiten, z.B. für jeden Mode eine extra Seite.
Angehängte Dateien:
Frank M. schrieb: > Aber Torsten könnte die Seite auch durchaus splitten auf mehrere Seiten, > z.B. für jeden Mode eine extra Seite. Sollte eigentlich möglich sein... Bin derzeit intensiv damit beschäftigt, Resourcen für die Frontplatten-Fertigung zu suchen. Hier einmal ein Virtual Reality Abbild einer WC24h mit rostiger Frontplatte... Ich habe dieses Photoshop-Modell als Anschauungsmuster gemacht, weil ich vielleicht die Möglichkeit habe, Stahlfrontplatten im Rahmen eines Lehr- und Lernprogramms in einer Lehrwerkstätte fertigen zu lassen ;-) Diese Möglichkeit könnte man auch anderswo in Betracht ziehen, sofern jemand Kontakte zur metallverarbeitenden Industrie hat....
Herbert P. schrieb: > Hier einmal ein Virtual Reality Abbild einer WC24h mit rostiger > Frontplatte... Sieht klasse aus! :-) BTW... wofür sind da eigentlich neuerdings die 4 Punkte unten? > Diese Möglichkeit könnte man auch anderswo in Betracht ziehen, sofern > jemand Kontakte zur metallverarbeitenden Industrie hat.... Habe ich leider nicht, sorry.
Frank M. schrieb: > BTW... wofür sind da eigentlich neuerdings die 4 Punkte unten? Herbert P. schrieb: > Wesentlich wichtiger als diese Spielerei ist jedoch, dass die > Frontplatte in der Mitte der untersten Zeile Platz für 4 LEDs enthält, > die für diverse Anzeigen zur Verfügung stehen (DCF77-Synchronisation, > Sekunden-Blinken, etc.) Joachim B. schrieb: > sehr guter Vorschlag, unterstütz ich von Herzen, ich dachte zwar nur an > 3, aber 4 tun auch nicht weh! > > DCF77sync, NTPsync, Sekunde, IRquitt wäre so meine Idee, auch als > WS2811/12/b in jeder Farbe/Helligkeit möglich
Herbert P. schrieb: > nur der Vollständigkeit halber: die ganze Mechanik fehlt noch: Ich habe Deine Punkte im Artikel WordClock24h unter der Überschrift "Mechanik" eingepflegt, ebenso die heute besprochenen "Software-Komponenten" unter dem gleichnamigen Titel.
Joachim B. schrieb: > Herbert P. schrieb: >> Wesentlich wichtiger als diese Spielerei ist jedoch, dass die >> Frontplatte in der Mitte der untersten Zeile Platz für 4 LEDs enthält, >> die für diverse Anzeigen zur Verfügung stehen (DCF77-Synchronisation, >> Sekunden-Blinken, etc.) Danke, gefällt mir :-)
Frank M. schrieb: > Ich habe Deine Punkte im Artikel WordClock24h unter der Überschrift > "Mechanik" eingepflegt, ebenso die heute besprochenen > "Software-Komponenten" unter dem gleichnamigen Titel. Danke! :-)
Frank M. schrieb: > Firefox zieht sich ein paar GB Memory wegen der vielen Graphiken rein Das muss eine andere Seite sein. Mach mal "Datei speichern unter": 2.34 MB (2458011 Bytes) Da findest Du kein einziges "…<img src=…" Oder was meinst Du mit Grafik? Frank M. schrieb: > ich hab halt "nur" 4 GB RAM Dein Fierfox kommt mit 4 GB RAM offenbar nicht klar, auch wenn die Seite nur Text und Tabellen enthält. Für Dich allein mache ich aber ganz sicher keine Sonderlocke. Vor allem nicht in diesem Ton! Frank M. schrieb: > diese Horror-Seite * Kopfschüttel *
Frank M. schrieb: > Eine interaktive Seite wäre mir lieber, wo ich minuten-/stundenweise > vor- und zurückblättern kann. Genau das macht die Software bereits auf > dem STM32, die ich heute morgen vorgestellt habe. Und das DMU in C#.net auch, aber unter Windows. Du kannst (wenn Du Dir wieder einen anderen Ton angewöhnt hast) gern das .exe oder den Sourcecode haben. Aber der läuft m.E. nicht auf Linux ;-) Im Ersnt: Das DMU in C#.net ist noch 'ne Baustelle. Wer es in diesem Zustand haben will, kann's bekommen. Am besten VS.net installieren und im Debugger laufen lassen, da z.B. Datei-Pfade noch "Hartkodiert" im Quelltext stehen und es z.B. noch keinen "Speichern unter" Dialog gibt. Und was meinst Du mit > Genau das macht die Software bereits auf dem STM32 Soll der STM32 jetzt das C#-DMU und den Code-Generator ersetzen?
Angehängte Dateien:
Um etwas von der harten Software-Realität abzulenken, stelle ich Euch wieder ein paar softe Hardware-Bildchen herein, damit Ihr Euch besser vorstellen könnt, wie "Das Ding" in den verschiedenen Versionen ausschauen wird.
Es ist erstaunlich, wie viele Downloads meine Bildchen schon zählen. So viele aktive Teilnehmer hat doch unser Thread gar nicht, oder doch?
@Herbert: Faustregel des Internets auf 1 Poster kommen 100 Lurker ;-) Ich finde viel mehr erstaunlich daß es trotz 6-15 MByte großen Bildern nicht zur uC-Net bekannten Diskussion kommt. Duck und weg.
Frank M. schrieb: > direkt auf dem Disco-Board. Dafür habe ich die tables.h von Torsten > verwendet. Allerdings musste ich da einiges an Windows-Spezifika durch > portableren Code ersetzen, Ebenso habe ich einige C++-Eigenarten, die > hier genutzt wurden, in reines C verwandelt. Habe es mir als "Schöpfer" der Tabellenstruktur ma angeschaut was Du geändert hast, ist in Ordnung. Wenn Torstens Programm diese Tabellen erzeugt kann ich die genauso verwenden. mfg
Torsten C. schrieb: > Frank M. schrieb: >> Firefox zieht sich ein paar GB Memory wegen der vielen Graphiken rein > > Das muss eine andere Seite sein. > > Mach mal "Datei speichern unter": > > 2.34 MB (2458011 Bytes) > > Da findest Du kein einziges "…<img src=…" Ja, das habe ich auch gemerkt. Ich kann Dir nur die Symptome schildern, mehr nicht. Warum der FF sich dabei so weghängt, weiß ich auch nicht. Sonst ist er aber immer sehr "geschmeidig". > Dein Fierfox kommt mit 4 GB RAM offenbar nicht klar, auch wenn die Seite > nur Text und Tabellen enthält. Für Dich allein mache ich aber ganz > sicher keine Sonderlocke. Vor allem nicht in diesem Ton! Sorry, mir erschließt sich einfach der Sinn der Seite nicht. Ich sehe da weder einen Generator noch irgendeinen Source oder wenigstens eine Tabelle. Ich sehe da nur hunderte von Frontplatten-Bildern - offenbar in jeder möglichen Konstellation. Tut mir leid, wenn Du etwas in den falschen Hals bekommen hast. Ich bitte um Entschuldigung. Vielleicht magst Du mir den Sinn der Seite ja erklären. Ich komme nicht dahinter. Torsten C. schrieb: > Und das DMU in C#.net auch, aber unter Windows. Du kannst (wenn Du Dir > wieder einen anderen Ton angewöhnt hast) gern das .exe oder den > Sourcecode haben. Aber der läuft m.E. nicht auf Linux ;-) Betriebssysteme sind mir egal. Ich fühle mich auf allen wohl ;-) Danke für das Angebot, die EXE benötige ich aber nicht. Ich will ja keine Codes generieren, sondern anwenden. Mit der passenden tables.h zeigt mir mein Disco-Board schon alles an. Ich kann mit den Tasten m/M minutenweise blättern, mit den Tasten h/H stundenweise. Ich habe also hier bereits eine Art "Daumenkino". Damit kann ich die Uhrzeit-Anzeige wesentlich effizienter auf Richtigkeit prüfen, denn ich sehe immer nur ein Bild und nicht ganz viele, die mich ablenken. Ich schaffe mit dieser Methode, ca. zwei Bilder pro Sekunde zu kontrollieren. Durch das Daumenkino sehe ich auch viel flüssiger, was sich da pro Minuten- bzw. Stundenwechsel ändert. Und dank IRMP kann ich nun auch schon die Uhrzeit per Fernbedienung stellen. :-) > Im Ersnt: Das DMU in C#.net ist noch 'ne Baustelle. Was heisst DMU? >> Genau das macht die Software bereits auf dem STM32 > > Soll der STM32 jetzt das C#-DMU und den Code-Generator ersetzen? Nein, er soll kein Code-Generator sein, er soll die Uhrzeit auf der Frontplatte anzeigen. Genau das macht er auch - im Moment jedoch nicht mit LEDs, sondern in einem ASCII-Terminal. Der Wechsel vom Terminal zu den LED-Stripes (die ich mir schon bestellt habe) ist dann nur noch ein klitzekleiner Schritt. Ich muss dann nur die Display-Routinen austauschen.
Hans H. schrieb: > Habe es mir als "Schöpfer" der Tabellenstruktur ma angeschaut was Du > geändert hast, ist in Ordnung. Prima, freut mich. > Wenn Torstens Programm diese Tabellen erzeugt kann ich die genauso > verwenden. Sobald die tables.h zur aktuellen Frontplatte vorliegt, werde ich das einbauen und dann auch das STM32F4-Disco-Projekt veröffentlichen. Im jetzigen Stadium macht das keinen Sinn, ich bennutze noch den Stand von Ende November, was Tabellen und Frontplatten-Design betrifft.
Anbei mal ein kleines AVI, was der STM32 bereits kann. Zeitsprünge sind im 1-Sekunden-Raster, ab und zu drücke ich mal eine Taste oder die IR-Fernbedienung, um mir andere Stunden anzuschauen.
Und hier noch ein Link, wo man online zusehen kann: telnet://uclock.de Sollte der Browser das nicht können (mein FF unter Win7 startet automatisch telnet als Shell-Extension), kann man es auch mit PuTTY ausprobieren, nämlich so: PuTTY starten, als Host uclock.de eintragen, telnet-Protokoll auswählen. Sollten die Umlaute nicht korrekt erscheinen, dann muss die Terminal-Emulation auf ISO8859-15 umgestellt werden. Das geht im PuTTY unter Window->Translation Unter Linux kann man auch einfach telnet uclock.de eingeben. Manipulation der Uhrzeit ist nicht erlaubt, man kann nur zusehen, wie sich diese im Sekundentakt ändert. IR-Fernbedienung geht natürlich auch nicht ;-) Viel Spaß, Frank
Hab mir grad Torstens rawgit-Simulation reingezogen. Ist für mich eine sehr praktische und übersichtliche Arbeitshilfe. Bei Modus 9 und 10 sind noch kleine Fehler drin (zum Teil Zahlwörter oben und unten vertauscht), werd ich ehest möglich korrigieren. Wenn es sich machen ließe, die verschiedenen Modi auf mehreren Seiten unterzubringen (wie das angeregt wurde), wäre das super :-) Insgesamt glaube ich, dass in der Praxis üblicherweise Mischformen der verschiedenen Modi verwendet werden (z.B. sagt auch bei uns wohl niemand "ES IST EINS NACH EINS" - wurde von Torsten kritisiert). Ich werde also versuchen, "lebensnahe" Mischformen zu definieren, die dem tatsächlichen Sprachgebrauch entsprechen. Franks Demo, was der STM32 schon kann, finde ich beeindruckend, hab's auf dem iPad mit einer Telnet App probiert (iPad = meine Workstation im Bett, wenn ich nicht schlafen kann). Bin schon auf die neue Version mit den neuen Tabellen gespannt :-) Wäre über Rückmeldungen zu meinen Photoshop-Bildchen dankbar, damit ich weiß, wie es designmäßig weitergehen soll.
Angehängte Dateien:
-
wclock24-in-html.png
13 KB
Hier noch die HTML-Version: http://uclock.de Man kann sich durch alle Stunden / Minuten klicken. Bin gespannt auf die neue tables.h :-)
Thema Lasercutting Stahlfrontplatte: Soll angeblich bei dieser Firma preisgünstig auch für kleine Stückzahlen und Einzelstücke möglich sein: http://www.geerscutting.com/laserzuschnitt-anwendungsbeispiele/ Heute hab' ich leider keine Zeit dafür, aber gleich Anfang kommender Woche werde ich ein Angebot einholen. Chemie zum Erzeugen von Edelrost: http://kdb-web.de/css/CORTENSTAHL/Cortenrostung.html Video: https://www.youtube.com/watch?v=su-7sBIfIpo Selbstverständlich kann man's auch mit Salzwasser und Essig, Salzsäure, Lötwasser, Flusssäure, Königswasser, im Garten mehrere Wochen (Monate?) Eingraben etc. probieren, aber man legt wahrscheinlich etliche leere Kilometer zurück und benötigt möglicherweise etliche misslungene Probestücke, bis der gewünschte Effekt erzielt ist. Auch mit der oben vorgestellten, professionellen Methode werden wir wohl ein wenig Lehrgeld zahlen müssen, soweit ich das beim Googeln in Erfahrung bringen konnte.
Thema Acrylglas-Frontplatte: Nach aktuellem Stand der Dinge stehen 3 Technologien zur Auswahl: 1. Mit Laserplotter geschnittene Vinylfolie zum Aufkaschieren auf Acrylglas oder auch "echtes" Glas. Vorteil: preisgünstige Einzelstück-Fertigung bei nahezu jeder Digitaldruck-Firma "um die Ecke" möglich. Nachteil: das Blasen- und Staubfreie Aufkaschieren der Folie ist nicht ganz einfach - um nicht zu sagen sehr schwierig. Es wird auch berichtet, dass sich die Folie bei rahmenloser Montage mittels Haftmagneten an den mechanisch stark beanspruchten Stellen (= bei den Haftmagneten) "nach einiger Zeit" (???) vom Untergrund ablöst. Angeblich altert die Folie auch relativ schnell, so dass (unbestätigten Gerüchten zu Folge) die zu erwartende Lebensdauer lediglich ca. 3 Jahre beträgt. 2. Einseitig mit lichtundurchlässigem Speziallack beschichtetes Acrylglas, bei dem die lichtdurchlässigen Stellen mittels Laser aus der Lackschicht herausgebrannt werden. Vorteil: Fertigung in kleinen Stückzahlen preisgünstig möglich. Die Lackschicht ist stabil und alterungsbeständig und löst sich auch bei mechanischer Beanspruchung (Haftmagnete) nicht vom Acrylglas ab. Zusatznutzen: die Acrylglas-Platten sind lasergeschnitten und haben daher glatte Ränder, die nicht nachbearbeitet (poliert) werden müssen. Nachteil: nach derzeitigem Wissensstand sind die Buchstaben im unbeleuchteten Zustand nahezu unsichtbar. 3. Acrylglas mit Siebdruck: die lichtundurchlässige Lackschicht wird im Siebdruckverfahren auf das Acrylglas gedruckt, wobei die lichtdurchlässigen Stellen beim Drucken ausgespart werden und blank bleiben. Dies ist zweifellos die professionellste Technolgie für diesen Anwendungszweck. Vorteil: ähnlich wie bei der unter Punkt 2.) beschriebenen Technologie gehen die verwendeten Speziallacke mit dem Trägermaterial eine unlösbare, dauerhafte Verbindung ein. Die auf diese Weise hergestellten Frontplatten sind so gut wie "ewig" haltbar (Acrylglas vergilbt auch nicht). Außerdem kann als zweite Lackschicht eine lichtdurchlässige Diffusorschicht aufgedruckt werden, wodurch das Anbringen einer ansonst erforderlichen Diffusorfolie entfällt. Nachteil: wegen der hohen Rüstkosten läßt sich dieses Verfahren erst ab einer Stückzahl von ca. 100 Stück kostengünstig einsetzen. ________ Speziell für das 2.Verfahren habe ich konkret eine aktuelle Anfrage, ob daran Interesse besteht, weil in Bälde auch Material für ein anderes Projekt eingekauft werden soll und ein gemeinsamer Einkauf unter Umständen die Kosten senken würde.
Herbert P. schrieb: > Speziell für das 2.Verfahren habe ich konkret eine aktuelle Anfrage, ob > daran Interesse besteht, weil in Bälde auch Material für ein anderes > Projekt eingekauft werden soll und ein gemeinsamer Einkauf unter > Umständen die Kosten senken würde. Ich bin weiterhin zuversichtlich, dass wir die 100 Frontplatten zusammenbekommen. Das sieht man schon an den vielen Downloads Deiner Bilder. Die meisten halten im Moment still, weil wir noch nichts richtig vorweisbares auf dem µC haben. Aber das wird sich wohl in Kürze ändern ;-) Ich bin trotzdem gespannt, welchen (Brutto-)Preis Du für die 2. Variante angeboten bekommst.
Herbert, mal eine Frage: Die nötigen Infos, welche LEDs wann wo angesprochen werden, sind in Deiner Access-DB? Ist es möglich, dass Du mir die exportierst/dumpst/irgendwas? Dann kann ich die tables.h auch selbst erstellen. Ich bin nämlich manchmal etwas ungeduldig ;-)
Frank M. schrieb: > Man kann sich durch alle Stunden / Minuten klicken. schau dir mal das an 00:01 ES IST NULL UHR EINS* 00:02 ES IST NULL UHR ZWEI* 00:03 ES IST NULL DREI* UHR ???
Joachim B. schrieb: > 00:03 > ES IST NULL DREI* UHR > > ??? Das sind Fehler in den alten Tabellen von Ende November. Dabei werden oft die Zahlen "ZWEI" und "DREI" zu weit oben, nämlich vor "UHR", verwendet. Herbert hat diese längst ausgemerzt bzw. durch die neue Version gestern ersetzt. Deshalb bin ich ja so scharf auf die neue tables.h! :-)
Frank M. schrieb: > Herbert, mal eine Frage: Die nötigen Infos, welche LEDs wann wo > angesprochen werden, sind in Deiner Access-DB? Ist es möglich, dass Du > mir die exportierst/dumpst/irgendwas? Dann kann ich die tables.h auch > selbst erstellen. Ich bin nämlich manchmal etwas ungeduldig ;-) Selbstverständlich gern, Frank! In welcher Form hättest Du sie denn gern? Excel-Datei? Wenn ja, in welcher Version? 2003 oder 2007/2010? Ich möchte nur vorher noch ein paar Fehler ausbessern, die mir heute früh bei Torstens Demo aufgefallen sind.
Herbert P. schrieb: > Selbstverständlich gern, Frank! In welcher Form hättest Du sie denn > gern? Excel-Datei? Wenn ja, in welcher Version? 2003 oder 2007/2010? Excel wäre passend. 2003 wäre vorzüglich :-) > Ich möchte nur vorher noch ein paar Fehler ausbessern, die mir heute > früh bei Torstens Demo aufgefallen sind. Solange kann ich noch warten ;-) Schon http://uclock.de/ angeschaut?
Hab soeben mein STM32 F4 Discovery ausgepackt, dabei ist mir aufgefallen, dass die Bauhöhe für unsere Zwecke suboptimal ist: mit den unten aufgelöteten Jumpern und Steckerleisten komme ich mit Flachband-Steckern auf eine erforderliche Gehäusehöhe (Innenmaß) von mindestens ca. 35 mm. Mit 3 mm Acrylglas-Front- und 16 mm MDF-Platte (Lochmaske) ergäbe das ca. 5,5 cm Abstand von Frontplatten-Vorderkante zu Wand :-((( Eine Möglichkeit: Steckerleisten und Jumper auf die Oberseite umlöten (unlustig wie Mäuse Melken!), die Tiefe würde sich dadurch um ca. 10 mm auf 4,5 cm verringern....
Vorabinfo @Torsten und alle, die schon mit der neuen accdb V2 arbeiten: in der tbl_hours gehört bei Betriebsart 5, 13 bis 19 Uhr die 58_ZEHN durch 25_ZEHN ersetzt.
Herbert P. schrieb: > Hab soeben mein STM32 F4 Discovery ausgepackt, dabei ist mir > aufgefallen, dass die Bauhöhe für unsere Zwecke suboptimal ist: mit den > unten aufgelöteten Jumpern und Steckerleisten komme ich mit > Flachband-Steckern auf eine erforderliche Gehäusehöhe (Innenmaß) von > mindestens ca. 35 mm. Mit 3 mm Acrylglas-Front- und 16 mm MDF-Platte > (Lochmaske) ergäbe das ca. 5,5 cm Abstand von Frontplatten-Vorderkante > zu Wand :-((( Die Frage ist, ob das Board überhaupt in die Uhr integriert werden muss. Du brauchst so und so ein Kabel. Ob das jetzt ein Stromkabel oder direkt ein Datenkabel zu den WS2812 ist, wäre noch zu überdenken. Ich jedenfalls habe mir schon überlegt, das Board komplett in eigenes (billiges Gehäuse) zu bauen und irgendwo verschwinden zu lassen. Dann könnte die Uhr ziemlich schmal werden :-) Um keine Probleme mit zu langen Datenleitungen zu haben, könnte man das notwendige Signal differentiell über einen RS485-Transceiver übertragen, also: DATA + +-------------------------+ Data ---- RS485 | | RS485 ----- Data +-------------------------+ DATA - Das kostet zwei RS485-Transceiver (kosten ein paar Cent) und kein bisschen Software, also insgesamt um die 2-3 EUR. Die Leitungen können dabei (fast) beliebig lang sein. Alternative wäre ein anderes Board oder sogar eine eigene Platine, wo wir dann auch direkt das Hühnerfutter (IR-Sensor, Helligkeitssensor, RTC, EEPROM) drauftun.
Frank M. schrieb: > Hier noch die HTML-Version: > > http://uclock.de Ich habe eben mal in die Logs geschaut und lach mich gerade weg: Der Google-Bot "crawlt" sich seit einer knappen halben Stunde durch sämtliche Uhrzeiten :-)))))
Frank M. schrieb: > Schon http://uclock.de/ angeschaut? Nett :-) Muss ich mir näher anschauen! Hast eine Mail mit den neuen Dateien bekommen!
Herbert P. schrieb: >> Schon http://uclock.de/ angeschaut? > > Nett :-) Muss ich mir näher anschauen! Das ist mehr als nur nett :-)))! Könntest Du da im Kopf noch eine Möglichkeit zur Betriebsarten-Auswahl vorsehen?
Frank M. schrieb: > Der Google-Bot "crawlt" sich seit einer knappen halben Stunde durch > sämtliche Uhrzeiten :-))))) ROFL Sollte man dem nicht doch vielleicht mit robots.txt einen Riegel vorschieben?
Frank M. schrieb: > Alternative wäre ein anderes Board oder sogar eine eigene Platine, wo > wir dann auch direkt das Hühnerfutter (IR-Sensor, Helligkeitssensor, > RTC, EEPROM) drauftun. Diese Variante würde ich bevorzugen, weil ich vorhabe, einige Exemplare auch an meine Kinder zu verschenken (Kinder klingt gut LOL, einer ist 38, der andere 36 - schade übrigens, dass ich sie für dieses Projekt (noch) nicht begeistern konnte, der eine ist Mechatronik-Dr., der andere Informatik-Dipl.Ing. - leider haben beide mit Mikrocontrollern zumindest derzeit niggs am Hut :-(
Herbert P. schrieb: > Das ist mehr als nur nett :-)))! Könntest Du da im Kopf noch eine > Möglichkeit zur Betriebsarten-Auswahl vorsehen? Habe ich ja vor. Wollte ich jetzt aber nicht mehr für die alte table-Version machen. Da kam nämlich einiges an Unsinn raus. ;-) Herbert P. schrieb: > Sollte man dem nicht doch vielleicht mit robots.txt einen Riegel > vorschieben? Nützt nichts mehr. Auf die robots.txt greift er wohl nur einmal am Anfang zu. Wenn keine existiert, legt er los. Es "kleben" im Moment sogar drei(!) Google-Bots auf der Seite. Sie sind bei den Uhrzeiten alle verschieden weit gekommen:
1 | crawl-66-249-69-211.googlebot.com - - [05/Dec/2014:12:24:55 +0100] "GET /?h=3&m=37 HTTP/1.1" 200 935 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 296 1207 |
2 | crawl-66-249-69-195.googlebot.com - - [05/Dec/2014:12:25:02 +0100] "GET /?h=8&m=28 HTTP/1.1" 200 932 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 296 1204 |
3 | crawl-66-249-69-227.googlebot.com - - [05/Dec/2014:12:25:10 +0100] "GET /?h=6&m=30 HTTP/1.1" 200 921 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 296 1193 |
4 | crawl-66-249-69-211.googlebot.com - - [05/Dec/2014:12:25:17 +0100] "GET /?h=5&m=39 HTTP/1.1" 200 941 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 296 1213 |
5 | crawl-66-249-69-211.googlebot.com - - [05/Dec/2014:12:25:24 +0100] "GET /?h=2&m=34 HTTP/1.1" 200 936 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 296 1207 |
6 | crawl-66-249-69-195.googlebot.com - - [05/Dec/2014:12:25:32 +0100] "GET /?h=6&m=40 HTTP/1.1" 200 921 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 296 1193 |
Bleibt mir nichts anderes übrig, als die 4 Links mal kurzzeitig rauszunehmen, damit sie sich lösen können. Dann kann ich die robots.txt hinlegen.
Frank M. schrieb: > Bleibt mir nichts anderes übrig, als die 4 Links mal kurzzeitig > rauszunehmen, damit sie sich lösen können. Dann kann ich die robots.txt > hinlegen. So, nach weiteren 10 Minuten haben sie bei der leeren Seite nun aufgegeben. Habe das Ding nun wieder aktiviert - mit robots.txt. @Herbert: Habe Dir per Mail geantwortet.
Die WC24h_18x16_V2 - Version von heute, 4.12.2014, ist als zip-Datei sowohl für Office 2003 als auch für Office 2007/2010 hochgeladen: [[http://www.mikrocontroller.net/articles/WordClock24h#Downloads]]
So, ich habe die neueste Version von Herbert in http://uclock.de/ eingebaut. Man kann nun auch den Anzeige-Modus einstellen. Das STM32F4-Programm werde ich daran anpassen. Aber ich habe da noch kleine Verständnisschwierigkeiten und weiß nicht, ob ich das alles richtig gemacht habe. @Herbert: Setzt sich der Modus X zusammen aus hour_txt = hour_mode und minute_txt_last = minute_mode ??? So habe ich es jedenfalls umgesetzt. Schien mir als einziges plausibel. Habe schon ein paar kleine Fehler entdeckt, hier ein Schnitzer: http://uclock.de/?x=0&h=0&m=4 Dann: in der Wort-Tabelle existiert word_ix = 4 und word_ix = 5 nicht. Da ist also eine Lücke. Ist das beabsichtigt? Wenn ich weitere Fehler finde, melde ich mich.
Ich dachte, Ihr lasst mir noch bis Samstag Zeit. https://gist.github.com/TorstenC/c45751a699af50fe9e64 Aber da sind noch Fehler drin. Ich bin dran ... Herbert P. schrieb: > WC24h_18x16_V2 - Version von heute, 4.12.2014 Beim nächsten Update nehme ich dann auch diese Version, der o.g. Link ist ein "Permalink" für die aktuellste Version. Diese ist in der zweiten Zeile erkennbar:
1 | //data from WC24h18x16_V2_20141204-1111, generator v0.1
|
Soll ich die "Horrorseite" noch updaten?
Torsten C. schrieb: > Soll ich die "Horrorseite" noch updaten? Eine automatisch generierte tables.h fände ich wesentlich interessanter. Ich musste mir heute die Tabellen aus Herberts MDB-Datei händisch herauskopieren und dann mit ein paar Editor-Makros behandeln. Das macht wenig Spaß. Deshalb möchte ich das möglichst nicht bei der nächsten Änderung wiederholen müssen. Aber vielleicht kannst Du mir noch einen Tipp geben: Wie kommt man von einem der 13 Modes auf die Werte für hour_mode und minute_mode? Was ich bisher probiert habe, erzeugt nur Unsinn. Im Moment habe ich es wieder auf hour_mode = minute_mode = 0 zurückgestellt.
Frank M. schrieb: > Habe schon ein paar kleine Fehler entdeckt, hier ein Schnitzer: > > http://uclock.de/?x=0&h=0&m=4 Und hier noch einer: http://uclock.de/?x=0&h=20&m=44 @Herbert: Diese beiden Wörter "ACHT" und "VIER" scheinen in Deinen Wort-Positions-Tabellen um 1 verrutscht zu sein. Dann kommst da "NACH" und "TVIE" raus. P.S. Der erste lässt sich im Moment nicht mehr nachvollziehen, weil ich die Mode-Umschaltung mangels Verständnis erstmal wieder abgeschaltet habe.
Frank M. schrieb: > Wie kommt man von einem der 13 Modes auf die Werte für hour_mode und > minute_mode? Über minute_txt (_first oder _last, je nachdem was !=0 ist) und hour_txt. Frank M. schrieb: > Eine automatisch generierte tables.h fände ich wesentlich interessanter. Manchmal nerven Deine Kommentare. Das war nicht die Frage.
Torsten C. schrieb: > Über minute_txt (_first oder _last, je nachdem was !=0 ist) und > hour_txt. Vielen Dank! Klappt. Ist nun in http://uclock.de/ eingebaut. > Manchmal nerven Deine Kommentare. Das war nicht die Frage. Doch! Du hast nach Prioritäten gefragt ;-) Aber gut: Ich werde zukünftig Deine Arbeit nicht mehr kommentieren. Ich schätze diese prinzipiell doch sehr. Ich persönlich sehe nur die Prioritäten - damit das Projekt vorankommt - woanders. Vielleicht kommt ja irgendwann eine automatisch generierte tables.txt. Das wäre echt Klasse!
Frank M. schrieb: > Frank M. schrieb: >> Habe schon ein paar kleine Fehler entdeckt, hier ein Schnitzer: >> >> http://uclock.de/?x=0&h=0&m=4 > > Und hier noch einer: > > http://uclock.de/?x=0&h=20&m=44 Und noch einer: http://uclock.de/?x=5&h=16&m=37 > @Herbert: Soll ich die Fehler besser im Artikel eintragen statt diese hier häppchenweise zu schreiben? P.S. Die Anzeigemodi sind echt super! Da kann man sich ein- und dieselbe Uhrzeit in einem Dutzend verschiedener Sprachen anschauen... :-)
Frank M. schrieb: > Soll ich die Fehler besser im Artikel eintragen statt diese hier > häppchenweise zu schreiben? Wenn sie sich auf die neueste Version von heute, 4.12.2014 beziehen, ruhig Häppchen. Sonst suchen wir nach Fehlern, die längst bekannt sind. Frank M. schrieb: > Was heisst DMU? http://de.wikipedia.org/wiki/Digital_Mock-Up Beispiel: http://uclock.de/?x=0&h=20&m=44 Frank M. schrieb: > Um keine Probleme mit zu langen Datenleitungen zu haben, könnte man das > notwendige Signal differentiell über einen RS485-Transceiver übertragen Das hat sich als nicht notwendig erwiesen, siehe Beitrag "WS2811/WS2812 aus der Ferne steuern + Stromversorgung" Frank M. schrieb: > Doch! Du hast nach Prioritäten gefragt ;-) Mit "auch noch" war "Ist das in Zukunft weiterhin gewünscht, oder braucht die keiner mehr?" gemeint. Da das nur zwei Mauscklicks sind (zumindest wenn alles in einer html-Datei ist), dauert die tables.h dadurch nicht merklich länger. Aber man kann es auch als Proiritäten-Frage interpretieren. Frank M. schrieb: > Ich werde zukünftig Deine Arbeit nicht mehr kommentieren. Passt schon. Ich bin noch nicht zu 'ner PN gekommen, die tables.h war wichtiger. ;-) Alles halb so schlimm.
Angehängte Dateien:
Hier einmal eine Vision davon, wie die Gehäuse-Rückseite ausschauen könnte: auf eine 16mm starke MDF-Platte, in die auf der Vorderseite trichterförmige Löcher gebohrt bzw. gefräst sind (Durchmesser 14mm vorne, 8mm hinten) und in die vorne 9 Neodym-Magnete mit Durchmesser 10mm zur Befestigung der Frontplatte eingelassen sind, ist rückwärts ein Rahmen aus eloxiertem Alu-U-Profil aus dem Baumarkt aufgeschraubt. Dieser Rahmen dient einerseits als Gehäuserahmen für die Elektronik und Verkabelung, andererseits auch als Träger für die Backlight-LEDs. Die Backlight-Stripes sind zum Schutz gegen Verschmutzung bzw. mechanische Beschädigung und zur besseren Lichtverteilung mit einem Milchglas-Streifen aus Kunststoff abgedeckt. Das Ganze lässt sich mit Billigmaterial aus dem Baumarkt und mit bescheidener Heimwerkerausrüstung realisieren.
Frank M. schrieb: > Soll ich die Fehler besser im Artikel eintragen statt diese hier > häppchenweise zu schreiben? Es passt schon hier, mit "Not in Dosen" tu ich mir leichter ;-) Auch Mail wäre eine Möglichkeit ;-) Frank M. schrieb: > P.S. > Die Anzeigemodi sind echt super! Da kann man sich ein- und dieselbe > Uhrzeit in einem Dutzend verschiedener Sprachen anschauen... :-) Thx for Compliment! Sie sind die Basis dafür, dass man einfach per Klick so gut wie jede (deutschsprachige) Anzeigeform realisieren kann, die sich mit dem Wörtern auf der Frontplatte darstellen lässt. Torsten C. schrieb: > Frank M. schrieb: >> Um keine Probleme mit zu langen Datenleitungen zu haben, könnte man das >> notwendige Signal differentiell über einen RS485-Transceiver übertragen > > Das hat sich als nicht notwendig erwiesen, siehe > Beitrag "WS2811/WS2812 aus der Ferne steuern + Stromversorgung" Schön langsam kommen wir in Technologie-Gefielde, die für einfache Gemüter wie mich (und andere Mit- und Nachbauer) nicht mehr nachvollziehbar sind. Was spricht dagegen, die Steuerelektronik im Gehäuse unterzubringen?
Herbert P. schrieb: > Hier einmal eine Vision davon, wie die Gehäuse-Rückseite ausschauen > könnte: Wie spitzfindige Geister sicherlich schon anhand verschiedener Ungereimtheiten bei den Dimensionen bemerkt haben, handelt es sich hierbei nicht um ein maßstabgetreues Modell, sondern "lediglich" um eine photorealistische Visualisierung mittels Photoshop.
Herbert P. schrieb: > nicht um ein maßstabgetreues Modell, sondern "lediglich" um eine > photorealistische Visualisierung Sieht trotzdem gut aus. :-) Ist das nicht aufwendig? Hat man das in der Zeit mit Photoshop nicht schon fast physikalisch fertig? Im Artikel WordClock24h steht: > Datei:WC24h16x16.zip 16x16 Matrix, MS Office 2007/2010-Dateien … > Datei:WC24h16x16 Office 2003.zip 16x16 Matrix, MS Office 2002/2003 … Brauchen wir die noch? Frage zu https://gist.github.com/TorstenC/c45751a699af50fe9e64
1 | // Beispiel: Jede Minute in einer Extra-Zeile mit "CodeLine.Add()"
|
2 | // Beispiel: Alles in einer Zeile mit "AppendCode()"
|
Was iat besser? Der Stand "1134_5.Dez.2014 CodeGen v0.3" ist nu soweit, dass ich erstmal keine augenscheinlichen Fehler sehe, die ein Compiler also besser findet als ich. Ich kümmere mich denn mal um "Schönheit": Kommentare schön untereinander und Zeilenunbrüche bei "Alles in einer Zeile mit AppendCode()". PS: Oder ist eine display.h dringender als eine verschönerte tables.h?
Frank M. schrieb: >> Frank M. schrieb: >>> Habe schon ein paar kleine Fehler entdeckt, hier ein Schnitzer: >>> >>> http://uclock.de/?x=0&h=0&m=4 >> >> Und hier noch einer: >> >> http://uclock.de/?x=0&h=20&m=44 Fehler in der Worttabelle tbl_words gefunden und bereinigt. Frank M. schrieb: > Und noch einer: > > http://uclock.de/?x=5&h=16&m=37 Fehler in der Tabelle tbl_hours gefunden und bereinigt. Soll ich die korrigierten Daten hochladen, oder noch ein wenig zuwarten, ob noch weitere Fehler auftreten?
Herbert P. schrieb: > Fehler in der Tabelle tbl_hours gefunden und bereinigt. Rein aus Interesse: Kann man die Fehler in der "HorrorSeite" auch erkennen? https://rawgit.com/TorstenC/1a59b9c73730eb8e144d/raw/WC24h_18x16_Test.html Ich frage, weil da gibt es ja nur eine Auswahl mit 60 Uhrzeiten pro Modus.
Wer Kritik am generierten Code hat, kann sich auch gern auf die entsprechende Code-Zeile im Generator beziehen: https://gist.github.com/TorstenC/aec0724be4afcd1d7545 Ich hoffe, der Code ist einigermaßen selbserklärend. Nur die eine Funktion mit verschiedenen Signaturen muss sicher erklärt werden:
1 | internal static CodeLine Add(CodeBlockItem Block, int Indent, String Code, String Comment) { |
2 | CodeLine NCL = new CodeLine(); |
3 | Block.indent += Indent; |
4 | NCL.indent = Block.indent; //... |
5 | Block.Add(NCL); |
6 | return NCL; |
7 | }
|
8 | internal static CodeLine Add(CodeBlockItem Block, String Code); |
9 | internal static CodeLine Add(CodeBlockItem Block, int Indent, String Code); |
10 | internal static CodeLine Add(CodeBlockItem Block, String Code, String Comment); |
Torsten C. schrieb: > Rein aus Interesse: Kann man die Fehler in der "HorrorSeite" auch > erkennen? > > https://rawgit.com/TorstenC/1a59b9c73730eb8e144d/raw/WC24h_18x16_Test.html > Ja sicher - ich hab bisher alle Fehler, die ich ausgemerzt habe, mit Deiner "Horrorseite" gefunden (und mit Deinen Tipps). Stand mir ja auch gar nichts anderes zur Verfügung. Bei mir funktioniert die "Horroseite" auch klaglos, sogar am iPad. Ich konnte heute Nacht schlecht schlafen und hab auf dem iPad mit Deiner Seite Fehler gesucht - die ich dann in der Früh beseitigt habe. Ich komm damit gut zurecht, es lässt sich damit auch sehr flott arbeiten, ohne Seitenumblättern. Aber wenn Frank damit Probleme hat, sehe ich das schon so, dass dem Rechnung zu tragen ist. Torsten C. schrieb: > Ich frage, weil da gibt es ja nur eine Auswahl mit 60 Uhrzeiten pro > Modus. So, wie Du das gemacht hast, ist es für die meisten Fälle völlig ausreichend. Ich hab ja unmöglich die Zeit, bei allen Modi 1440 Zustände durchzuklicken und zu kontrollieren. Bei 12 Modi (ohne Mitternachts-Countdown) wären das 17.280 Zustände - da wäre ich danach reif für das Irrenhaus. :-) Den Fehler mit der verschobenen Referenz von "52_VIER" in Zeile 9 der Matrix habe ich erst heute durch den Hinweis von Frank entdeckt. Lag daran, dass ich nach einer letzten, geringfügigen Änderung der Frontplatte vergessen hatte, die Änderung auch in den Tabellen durchzuführen. Kleine Ursache, große Wirkung. Richtig lauten die Referenzen in der tbl_words für die Matrix-Zeile 9: 51_ACHT 9 10 4 170 167 52_VIER 9 14 4 167 163 Den zweiten von Frank aufgezeigten Fehler ("ZEHN" an falscher Stelle - oben statt unten) hatte ich meines Wissens in der hochgeladenen accdb schon korrigiert, bedauerlicherweise aber nicht in der mdb, die Frank zur Verfügung stand. Bei Modus 5 der Tabelle tbl_hours war bei den Zahlen drei-zehn bis neun-zehn die falsche Zehner-Referenz eingetragen: fälschlicherweise 25_ZEHN anstatt richtig 58_ZEHN Das betrifft die Uhrzeiten von DREI_ZEHN UHR bis NEUN_ZEHN UHR
Trotz etlicher Downloads habe ich bisher noch keinerlei Rückmeldung zu meinen Bildern von diversen Design-Varianten und zum mechanischen Aufbau erhalten. Wäre für mich nicht uninteressant, was "man" darüber so denkt...
Torsten C. schrieb: > Ist das nicht aufwendig? Hat man das in der Zeit mit Photoshop nicht > schon fast physikalisch fertig? Gegenfrage: ist es nicht aufwendig, von Autos Tonmodelle und fotorealistische Darstellungen anzufertigen, bevor überhaupt ein erster Schraubendreher in die Hand genommen wurde? Ich bin eine Freund von Visualisierungen, weil sie nachher unnötigen Ärger ersparen können: "Ach, daran hatte ich nicht gedacht!" "Das habe ich mir aber gaaaaanz anders vorgestellt!" :-( Sicher hänge ich da jeweils einige Stunden dran, aber es ist wesentlich einfacher und weniger kostenintensiv (wenn ich meine Zeit nicht rechne), ein Photoshop-"Gemälde" zu korrigieren, als einen verhunzten Protoypen wegzuwerfen und von vorne wieder neu anzufangen.
Frank M. schrieb: > Linux und auch direkt auf dem Disco-Board Sorry wegen OT: Was benutzt Du dafür? FreeRTOS? NuttX? ...?
Torsten C. schrieb: > Im Artikel WordClock24h steht: >> Datei:WC24h16x16.zip 16x16 Matrix, MS Office 2007/2010-Dateien … >> Datei:WC24h16x16 Office 2003.zip 16x16 Matrix, MS Office 2002/2003 … > > Brauchen wir die noch? Die 16x16 Matrizen brauchen Joachim und ich noch - außer wir finden einen Abnehmer für die bereits gekauften 16 x 8 WS2812-RGB-LED-Matrizen mit Abstand 20mm x 20mm. Torsten C. schrieb: > Ich kümmere mich denn mal um "Schönheit": Kommentare schön untereinander > und Zeilenunbrüche bei "Alles in einer Zeile mit AppendCode()". Gegen "Schönheit" im Code und saubere Kommentare hatte ich noch nie was einzuwenden ;-)
Herbert P. schrieb: > Die 16x16 Matrizen brauchen Joachim und ich noch Klar, sorry, blöde Frage. Ich dachte, das waren die alten 18x16. Wer lesen kann ... Herbert P. schrieb: > Ich bin eine Freund von Visualisierungen, weil sie nachher unnötigen > Ärger ersparen können War auch keine Kritik, sehe ich auch so. Ich bräuchte dafür mit Photoshop halt 2-3 Tage, daher mein Erstaunen. Du kennst das Tool offenbar besser. Ich muss ich mich wohl mal näher damit beschäftigen. Herbert P. schrieb: > Wäre für mich nicht uninteressant, was "man" darüber so > denkt... Also an der Fräs-Variante habe ich kein Interesse und die andere nehme ich so, wie sie ist, um größeren Stückzahlen nicht im Wege zu stehen. Ich hätte lieber dickere Schrift (font-weight), aber nehme auch die dünne. Sieht echt gut aus, habe nix zu meckern!
Noch was zu den Visualisierungen: während ich die Bilder der Objekte mit Photoshop anfertige, spiele ich ja im Geiste schon die reale Fertigung durch: von den möglichen Konstruktionsvarianten bis zur (möglichst einfachen und kostengünstigen) Materialbeschaffung, von der Fertigung und den dafür erforderlichen Fertigkeiten, Werkzeugen und ggf. Fertigungsbetrieben bis zum Endprodukt. Dabei treten etliche Fragen auf, die einer Behandlung und Abklärung bedürfen, bevor es zu spät ist und das Ding als unrealisierbar halbfertig oder gar fertig und unbrauchbar im Müll landet.
Torsten C. schrieb: > Ich bräuchte dafür mit > Photoshop halt 2-3 Tage, daher mein Erstaunen. Du kennst das Tool > offenbar besser. Ich muss ich mich wohl mal näher damit beschäftigen. Ist ja auch gut so, dass wir unterschiedliche Schwerpunkte haben und dadurch ein breiteres Feld abdecken können.
Torsten C. schrieb: > Ich hätte lieber dickere Schrift (font-weight), aber nehme auch die > dünne. Dieses Thema wurde überhaupt noch nicht richtig angeschnitten, geschweige denn ausdiskutiert. Auf Seite 2 dieses Threads habe ich mehrere Schriftmuster vorgestellt, ich fände es gut, wenn jeder seine persönlichen Präferenzen deponieren würde.
Torsten C. schrieb: > Frank M. schrieb: >> Linux und auch direkt auf dem Disco-Board > > Sorry wegen OT: Was benutzt Du dafür? FreeRTOS? NuttX? ...? Ich benutze das von mir selbst programmierte MCURSES. Das ist angelehnt an die Unix-Curses- bzw. spätere Unix-/Linux-Ncurses-Lib, aber stark abgespeckt und auf µCs optimiert. Du kannst Dir ja mal den MCURSES-Artikel anschauen. MCURSES läuft bisher - AVR ATmega (auf fast allen mit UART) - Z80 (ja, kürzlich portiert, siehe Retro-Thread hier) - STM32 (auf allen 6 UARTS und direkt über USB als VCP) - Unix (über alle erdenklichen COM- und Netzwerk-Verbindungen) - Linux (dito) Im Artikel ist noch nicht die STM32-Version enthalten, da muss ich die Seite mal updaten. Das Schöne ist, dass man die Dokumentation zu den MCURSES-Funktionen auch online findet, da diese ja offizielle Bestandteile auf unixoiden Systemen ist. Du kannst also z.B. bei Google einfach: man clrtoeol eingeben, um alles über clrtoeol() zu erfahren. Je nachdem, wieviel Du an MCURSES-Funktionen benötigst, verbrätst Du zwischen 800 Byte und 4KB im Flash. Das Schöne ist, dass Du damit in C Programme schreiben kannst, die auf all den oben genannten Plattformen exakt gleich aussehen und auf all diesen exakt gleich ablaufen. Ich hätte daher das bisherige Programm auch auf einem ATmega kompilieren können ;-) Im Artikel findest Du auch ein Video, um zu verdeutlichen, was damit alles möglich ist.
Herbert P. schrieb: > Torsten C. schrieb: >> Ich hätte lieber dickere Schrift (font-weight), aber nehme auch die >> dünne. > > Dieses Thema wurde überhaupt noch nicht richtig angeschnitten, > geschweige denn ausdiskutiert. Auf Seite 2 dieses Threads habe ich > mehrere Schriftmuster vorgestellt, ich fände es gut, wenn jeder seine > persönlichen Präferenzen deponieren würde. Ich sehe das ähnlich wie Torsten. Als ich die letzte von Dir veröffentliche Schrift für Acrylglas sah, dachte ich mir: "Verdammt dünn, kommt da nicht zu wenig Licht durch"? Aber ich bin noch nicht dazu gekommen, das mal mit der bisherigen Word Clock-Frontplatte im Detail zu vergleichen. Aber ich glaube schon, dass die Schrift ruhig etwas dicker sein könnte.
@Herbert: Hier noch ein paar Fehler in den Tabellen. Ich bin jetzt nicht orientiert, ob Du diese anhand der bisherigen Meldungen gleich mit erledigt hast: http://uclock.de/?x=5&h=20&m=21 http://uclock.de/?x=6&h=23&m=31 http://uclock.de/?x=6&h=23&m=40 http://uclock.de/?x=8&h=8&m=17 Weitere Häppchen könnten folgen ;-)
Herbert P. schrieb: > 51_ACHT 9 10 4 170 167 > 52_VIER 9 14 4 167 163 > Modus 5 der Tabelle tbl_hours ... : > fälschlicherweise 25_ZEHN anstatt richtig 58_ZEHN > Das betrifft die Uhrzeiten von DREI_ZEHN UHR bis NEUN_ZEHN UHR Ist das alles? Ich kann das auch schnell bei mir fixen und den C-Code und die Horror-Seite neu hochladen. Herbert P. schrieb: > Soll ich die korrigierten Daten hochladen, oder noch ein wenig zuwarten, > ob noch weitere Fehler auftreten? Wegen mir nicht. Wenn denn alle erkennbaren Fehler raus sind, macht das sinn. Am besten weitere Änderungen an der .accdb hier posten.
Torsten C. schrieb: > Frank M. schrieb: >> Um keine Probleme mit zu langen Datenleitungen zu haben, könnte man das >> notwendige Signal differentiell über einen RS485-Transceiver übertragen > > Das hat sich als nicht notwendig erwiesen, siehe > Beitrag "WS2811/WS2812 aus der Ferne steuern + Stromversorgung" und was ist mit wlan? ich bin ja noch in Planung den esp8266 anzubinden, andere haben das längst geschafft und Code müsste verfügbar sein. andereseits ist IR ja vorgesehen und das in IR einzucoden wäre auch ne Option.
Frank M. schrieb: > http://uclock.de/?x=5&h=20&m=21 tbl_hours, mode 5, 20 Uhr Ist: 27_ZWANZIG Soll: 59_ZWANZIG > http://uclock.de/?x=6&h=23&m=31 tbl_minutes, mode 3: 31 Minuten minute_ix_2: IST: 10_EIN SOLL: 7_EINS > http://uclock.de/?x=6&h=23&m=40 tbl_minutes, mode 6: 40 Minuten minute_ix_2: IST: 58_ZEHN SOLL: 25_ZEHN > http://uclock.de/?x=8&h=8&m=17 tbl_minutes, mode 4: 13, 14, 16 bis 19 Minuten: minute_ix_2: IST: 58_ZEHN SOLL: 25_ZEHN Zusätzlich: tbl_minutes, mode 2: 40 Minuten: minute_ix_6: 36_NACH gehört gelöscht, ist schon in minute_ix_4 vorhanden
Angehängte Dateien:
-
simu_blackgrayyellow.jpg
260 KB -
simu_steel.jpg
740 KB -
configdialog.png
12 KB
Es gibt neues vom Bildschirmschoner mit Simulationsmode (aka Mockup). Anbei zwei Ausgaben und der Config-Dialog. Neu: - Font und Fontstil wählbar (Wunsch von Herbert) - Fontgröße in Grenzen anpaßbar (manche Fonts sehen etwas größer besser aus) - Farbe der ausgeschalteten Buchstaben kann auch anders als Farbe der angeschalteten sein - Hintergrundfarbe wählbar, optional Textur stattdessen Daten haben den Version 1 Stand Ich werde ihn dann wieder hochladen wenn eine halbwegs fehlerfreie tables.h und display.h vorliegen. Wenn jemand noch Ideen hat wo man freie schöne, kachelbare kleine Texturbitmaps herbekommt wäre ich dankbar dafür. Achso: Mein Windows sieht retro aus ;-) mfg
Joachim B. schrieb: > Torsten C. schrieb: >> Frank M. schrieb: >>> Um keine Probleme mit zu langen Datenleitungen zu haben, könnte man das >>> notwendige Signal differentiell über einen RS485-Transceiver übertragen >> >> Das hat sich als nicht notwendig erwiesen, siehe >> Beitrag "WS2811/WS2812 aus der Ferne steuern + Stromversorgung" Ich möchte eigentlich schon ein kompaktes Stand Alone Gerät haben und keine vernetzten Einzelkomponenten. Der Mikrocontroller samt "Hühnerfutter" hat locker Platz im Wordclock-Gehäuse.
Hans H. schrieb: > Wenn jemand noch Ideen hat wo man freie schöne, kachelbare kleine > Texturbitmaps herbekommt wäre ich dankbar dafür. Was meinst Du damit, bzw. was brauchst Du da? Sehen richtig nett aus, Deine Mock-Ups :-)
Herbert P. schrieb: > Ich möchte eigentlich schon ein kompaktes Stand Alone Gerät haben und > keine vernetzten Einzelkomponenten. Der Mikrocontroller samt > "Hühnerfutter" hat locker Platz im Wordclock-Gehäuse. wer hindert dich eine kleine Briefmarke als Modul auf die Platte zu stecken? größer ist das esp8266 nicht
Herbert P. schrieb: > Der Mikrocontroller samt > "Hühnerfutter" hat locker Platz im Wordclock-Gehäuse. Hat er auch. Es muss ja kein dickes Discovery sein. Sogar Linux würde wohl auf dem kleinen o.g. 4€-Modul aus China laufen.
Herbert P. schrieb: > Hans H. schrieb: >> Wenn jemand noch Ideen hat wo man freie schöne, kachelbare kleine >> Texturbitmaps herbekommt wäre ich dankbar dafür. > > Was meinst Du damit, bzw. was brauchst Du da? Das sind Bitmaps die Oberflächen darstellen wie Du sie bei deinem WC24h18x16_Modell_Rost.png für den rostigen Stahl verwendet hast, aber halt so maximal 300x300 groß und so designt daß man sie kacheln kann ohne daß man ein Kachelmuster sieht. Mir fehlt hier auch der richtige Fachbegriff dafür. > Sehen richtig nett aus, Deine Mock-Ups :-) Danke!
Herbert P. schrieb: > Ist: 27_ZWANZIG ... Gute Liste, :-) aktualisiere ich gleich. Hans H. schrieb: > Fontstil wählbar Will ich auch! Was ist mit den Fonts? Kann ich die per E-Mail haben? Hans H. schrieb: > optional Textur stattdessen Haben wir dafür eine Bitmap-Sammlung? Hans H. schrieb: > wenn eine halbwegs fehlerfreie tables.h und display.h vorliegen Fehler: Bitte PN oder Post. display.h: Habe jetzt "Code schön" priorisiert. Ich fange gleich an. Wie gesagt: Torsten C. schrieb: > Der Stand "1134_5.Dez.2014 CodeGen v0.3" ist nu soweit, dass ich erstmal > keine augenscheinlichen Fehler sehe, die ein Compiler also besser findet > als ich. > > Ich kümmere mich denn mal um "Schönheit": Kommentare schön untereinander > und Zeilenunbrüche bei "Alles in einer Zeile mit AppendCode()". > > Oder ist eine display.h dringender als eine verschönerte tables.h? PS @ Hans H.: Schau Dir mal bitte die Kommentare "Lötkolben?" an unter https://gist.github.com/TorstenC/aec0724be4afcd1d7545 OK? Ich kann auch zwei Varianten.
Torsten C. schrieb: > > Will ich auch! Was ist mit den Fonts? Kann ich die per E-Mail haben? Den Font kannst Du aus den installierten Fonts in Windows auswählen, ich habe keine extra Fonts installiert bei mir (außer was LibreOffice so mitbringt). > Hans H. schrieb: >> optional Textur stattdessen > > Haben wir dafür eine Bitmap-Sammlung? Das wäre mein Wunsch, ich werde diese jedoch komprimiert in die Exe einbauen, deshalb darf das nicht "ausarten" ;-) Siehe auch meine Antwort oben. > Torsten C. schrieb: >> Der Stand "1134_5.Dez.2014 CodeGen v0.3" ist nu soweit, dass ich erstmal >> keine augenscheinlichen Fehler sehe, die ein Compiler also besser findet >> als ich. >> >> Ich kümmere mich denn mal um "Schönheit": Kommentare schön untereinander >> und Zeilenunbrüche bei "Alles in einer Zeile mit AppendCode()". >> >> Oder ist eine display.h dringender als eine verschönerte tables.h? Ich nehm beides auch wenn es noch nicht so schön ist.
Hans H. schrieb: > Ich nehm beides auch wenn es noch nicht so schön ist. :-) Iss klar. Ist die tables.h so OK? display.h versuche ich heute noch. Ich musste Gerade Rommé spielen und habe nebenbei programmiert. Bin auch nur Dritter geworden. Hans H. schrieb: > aus den installierten Fonts in Windows auswählen Ach. Aber weiter oben im Thread ist von vielen Fonts die Rede, die zumindest bei mir nicht auf dem Rechner sind.
Torsten C. schrieb: > PS @ Hans H.: Schau Dir mal bitte die Kommentare "Lötkolben?" an unter > > https://gist.github.com/TorstenC/aec0724be4afcd1d7545 > Hallo hab ich mir angeschaut. Im Interesse des Aufwands wie ich UKW-Uwe schon schrieb, reicht mir die C-Style Codegenerierung. Meine paar Umwandlungen mach ich mit Typedefs oder händisch. Du kannst also die von dir auskommentierten Zeilen löschen. Etwas anderes ist mir aufgefallen das wäre schön wenn Du es nochmal checken kannst: Ich nahm an daß MaxHourWordsPlusOne ungleich MaxMinuteWordsPlusOne ist, und um in den Arrays Speicher zu sparen habe ich nicht beide gleich groß gemacht. Vielleicht kann Dein Codegenerator ja die Anzahl der maximal möglichen Worte pro Minutendarstellung und pro Stundendarstellung mit prüfen, und am Ende, meinetwegen auch nur als Kommentarzeile mit ausgeben. mfg
Hans H. schrieb: > Vielleicht kann Dein Codegenerator ja die Anzahl der maximal möglichen > Worte pro Minutendarstellung und pro Stundendarstellung mit prüfen Sollte er eigentlich tun:
1 | ...
|
2 | this.MinuteWordsMax = Math.Max(this.MinuteWordsMax, LenCount); ... |
3 | this.HourWordsMax = Math.Max(this.HourWordsMax, LenCount); ... |
4 | CodeLine.Add(Constants, "#define MaxHourWordsPlusOne " + (this.HourWordsMax + 1), ... |
5 | CodeLine.Add(Constants, "#define MaxMinuteWordsPlusOne " + (this.MinuteWordsMax + 1), ... |
Hans H. schrieb: > Das sind Bitmaps die Oberflächen darstellen wie Du sie bei deinem > WC24h18x16_Modell_Rost.png für den rostigen Stahl verwendet hast, aber > halt so maximal 300x300 groß und so designt daß man sie kacheln kann > ohne daß man ein Kachelmuster sieht. Dir fehlt nicht der richtige Fachbegriff dafür, ich wollte nur sicher gehen, dass ich Dich richtig verstanden habe. Du kannst die Rost- und auch die Edelstahl-Textur gerne von mir haben, aber mit dem Kacheln ist das so eine Sache bei Rost. Du würdest mit dem Ergebnis wohl nicht zufrieden sein. Die Texturen, die ich hier verwendet habe, sind "am Stück" und daher auch ein wenig größer als 300 x 300 (ich habe auch eine Printerauflösung von 300dpi verwendet und mir nicht die Mühe gemacht, die Dateien extra für's Web zu verkleinern - die Rost-Textur hat ca. 1,5 MB). Du kannst alle möglichen Texturen von mir haben, brauchst nur zu sagen, was Du benötigst. Allerdings sind die meisten nicht zum Kacheln geeignet - außer man will den Kacheleffekt bewusst einsetzen. Ich passe auch gerne die Auflösung an Deine Bedürfnisse an, das macht mir keine großen Umstände. Übrigens: fallweise kauf ich mir auch Texturen bei http://fotolia.de oder http://123rf.com (die Rost-Textur und die Edelstahl-Textur habe ich bei fotolia gekauft)
Torsten C. schrieb: > Will ich auch! Was ist mit den Fonts? Kann ich die per E-Mail haben? Lässt sich machen - auch Texturen.
Torsten C. schrieb: > Ach. Aber weiter oben im Thread ist von vielen Fonts die Rede, die > zumindest bei mir nicht auf dem Rechner sind. Fonts gerne von mir per Mail - aber bitte nur für privaten Gebrauch! "Sie wünschen - wir spielen!"
Herbert P. schrieb: > und mir nicht die > Mühe gemacht, die Dateien extra für's Web zu verkleinern Ich denke, verkleinern und komprimieren könne wie beide selbst. Herbert P. schrieb: > Du kannst die Rost- und auch die Edelstahl-Textur gerne von mir haben Für ein DMU würden genau die Texturen interessieren, die auch in Frage kommen. Mir persönlich reicht - wie gesagt - einfarbig, daher kann zumindest ich zur Auswahl der Texturen nix sagen.
Herbert P. schrieb: > Du kannst die Rost- und auch die Edelstahl-Textur gerne von mir haben, > aber mit dem Kacheln ist das so eine Sache bei Rost. Du würdest mit dem > Ergebnis wohl nicht zufrieden sein. Die Texturen, die ich hier verwendet > habe, sind "am Stück" und daher auch ein wenig größer als 300 x 300 (ich > habe auch eine Printerauflösung von 300dpi verwendet und mir nicht die > Mühe gemacht, die Dateien extra für's Web zu verkleinern - die > Rost-Textur hat ca. 1,5 MB). > > Du kannst alle möglichen Texturen von mir haben, brauchst nur zu sagen, > was Du benötigst. Allerdings sind die meisten nicht zum Kacheln geeignet > - außer man will den Kacheleffekt bewusst einsetzen. Ich passe auch > gerne die Auflösung an Deine Bedürfnisse an, das macht mir keine großen > Umstände. Hallo Herbert, danke für Dein Angebot. Ich habe gerade einen Faden in einem anderen Forum gefunden da sind ein paar interessante Links: http://www.amateurfilm-forum.de/digitale-videobearbeitung-post-production/3d-grafiken-und-animationen/7870-texturensammlung/ Die schaue ich erstmal durch, der Fachbegriff ist übrigens anreihbar ;-)
Torsten C. schrieb: > Für ein DMU würden genau die Texturen interessieren, die auch in Frage > kommen. Mir persönlich reicht - wie gesagt - einfarbig, daher kann > zumindest ich dazu nix sagen. Aber die Ansage ging ja auch nicht an > mich. Ich persönlich würde auch einfarbigen Hintergrund vorziehen. Ich hab die QlockTwo App auf dem iPad und auf dem Android-Handy laufen, haben einfarbigen Hintergrund ohne Schnickschnack (allerdings mehrere Farben wählbar), ist völlig ok so.
Herbert P. schrieb: > Ich persönlich würde auch einfarbigen Hintergrund vorziehen. Wenn keiner Texturen braucht, ist ja OK. Es ist nur ein Gedanke, wegen "Ich bin ein Freund von Visualisierungen" und dem Digital Mock-up. Das soll ja genau für "Visualisierungen" da sein.
Torsten C. schrieb: > Herbert P. schrieb: >> Ich persönlich würde auch einfarbigen Hintergrund vorziehen. > > Wenn keiner Texturen braucht, ist ja OK. Es ist nur ein Gedanke, wegen > "Ich bin ein Freund von Visualisierungen" und dem Digital Mock-up. Das > soll ja genau für "Visualisierungen" da sein. Ich finde einfarbigen Hintergrund auch sehr schön (Acrylglas-Frontplatte)
Herbert P. schrieb: > Ich finde einfarbigen Hintergrund auch sehr schön Zu "Texturen … die auch in Frage kommen": Aber Du propagierst doch selbst eine Metall-Version. Wenn die gebraucht wird, aber nicht für das DMU? Hmmm.
Torsten C. schrieb: > Zu "Texturen … die auch in Frage kommen": Aber Du propagierst doch > selbst eine Metall-Version. Wenn die gebraucht wird, aber nicht für das > DMU? Hmmm. Es wurde hier einmal der Bedarf nach einer Edelstahl-Version und auch und vor Allem nach einer rostigen Stahlversion angemeldet. Das betraf jedoch die "echte" Wortuhr. Die hier vorgestellten DMUs sehe ich eigentlich nur als Entwicklungstools, und dafür ist meines Erachtens ein neutraler (schwarzer) Hintergrund am besten geeignet. Aber wenn jemand sein DMU mit Texturen verschönern will, stehe ich ihm gerne hilfreich zur Seite. Ich habe auch die Frage nach Texturen (ebenso wie die nach Schriftenfonts) allgemein aufgefasst und nicht unbedingt bezogen auf die Wortuhr.
Herbert P. schrieb: > Es wurde hier einmal der Bedarf nach einer Edelstahl-Version und auch > und vor Allem nach einer rostigen Stahlversion angemeldet. ich war das und bin ja immer noch interssiert, bei mir wirds Edelstahl und für einen Freund rostiger Baustahl.
Thema Stahlfrontplatte:
nach meinen bisherigen Recherchen scheint die Firma Geers 24 GmbH
("Geerscutting") der beste Ansprechpartner für lasergeschnittene
Stahlfrontplatten zu sein. Leider kann ich von Österreich aus keinen
Account eröffnen, um einmal eine unverbindliche Anfrage abzusetzen, da
die Firma offensichtlich nur Kunden aus Deutschland bedient.
Nach meinen bisherigen Informationen bewegt sich der Preis für eine
lasergeschnittene Stahlfrontplatte 45 x 45 cm Cortenstahl 0,8 mm ab ca.
€ 50,- aufwärts (Einzelstücke bzw. Kleinserienfertigung, auch für
Privatpersonen). Rüstkosten wahrscheinlich extra, sollten sich aber mit
Vektorgrafik-Vorlage in Grenzen halten.
Würde sich eventuell jemand aus Deutschland opfern, mit den Abbildungen
von den Stahlfrontplatten, die ich hier hereingestellt habe, eine
Anfrage bei GeersCutting zu starten (Machbarkeit, Preis, Lieferzeit)?
Und auch nachzufragen, in welchem Dateiformat die Vorlage am besten zu
stellen wäre?
www.geerscutting.com/
Thema Stahlfrontplatte, Ergänzung: es geht bei GeersCutting derzeit nur um eine unverbindliche Anfrage, da ich parallel dazu vielleicht(!) die Möglichkeit habe, "Das Ding" bei einer Lehrwerkstätte in Österreich "kostenschonend" als Projektarbeit unterzubringen. Ich erhalte diesbezüglich voraussichtlich kommende Woche Bescheid.
Joachim B. schrieb: > ich war das und bin ja immer noch interssiert, bei mir wirds Edelstahl > und für einen Freund rostiger Baustahl. Welche Version möchtest Du mit Stahlfrontplatte realisieren? Die 16x16 Matrix oder die 18x16 Matrix? Wenn Du die 16x16 Matrix bevorzugst, könntest Du meine beiden 8x16 Matrizen haben. Was ich allerdings für die 16x16 Version grundsätzlich noch benötigen würde, wäre eine Überprüfung der Tabellen, denn da sind sicher noch Fehler auszumerzen.
Herbert P. schrieb: > Welche Version möchtest Du mit Stahlfrontplatte realisieren? Die 16x16 > Matrix oder die 18x16 Matrix? vorrangig 18 x 16 aber die 16 x 16 verbaue ich auch, sind ja gekauft, aber noch eine kaufe ich nicht weil ich die Idee mit der rechteckigen Matrix im quadratischen Design bestechender finde.
Joachim B. schrieb: > weil ich die Idee mit der rechteckigen > Matrix im quadratischen Design bestechender finde. Mir hat eigentlich der größere Buchstabenabstnd bei der 16 x 16 Matrix besser gefallen, allerdings sind die Kombinationsmöglichkeiten bei der 18 x 16 Matrix etwas umfangreicher ("morgens, mittags, abends, nachts,...")
Hans H. schrieb: > Ich werde ihn dann wieder hochladen wenn eine halbwegs fehlerfreie > tables.h und display.h vorliegen. Die Links für beide .h habe ich im Wiki ergänzt: http://www.mikrocontroller.net/articles/WordClock24h#Verifikation.2C_Validierung.2C_Code-Generator Herbert P. schrieb: > Korrigierte Dateien sind hochgeladen Darauf beziehen sich auch die .h: "Data from WC24h_18x16_V2_1134_5.Dez.2014" In display.h steht:
1 | // Von-Neumann-Variant, Data from WC24h_18x16_V2_1134_5.Dez.2014, CodeGen v0.4
|
Wenn der Code das erste mal fehlerfrei durch einen Compiler gelaufen ist, setze ich die Version auf 1.0 hoch. Herbert P. schrieb: > Was ich allerdings für die 16x16 Version grundsätzlich > noch benötigen würde, wäre eine Überprüfung der Tabellen, denn da sind > sicher noch Fehler auszumerzen. Herbert P. schrieb: > Ich konnte heute Nacht schlecht schlafen und hab auf dem iPad mit Deiner Seite > Fehler gesucht - die ich dann in der Früh beseitigt habe Schade um Deinen Schlaf, aber dann hat sich meine Arbeit gelohnt. ☺ Die 16x16-Horrorseite ist auf dem Stand 28. Nov.2014 16:07 Uhr.
Torsten C. schrieb: > Schade um Deinen Schlaf, aber dann hat sich meine Arbeit gelohnt. ☺ Die > 16x16-Horrorseite ist auf dem Stand 28. Nov.2014 16:07 Uhr. War nicht schade um meinen Schlaf - immer noch besser als Schäfchen zählen ;-)
Torsten C. schrieb: > Brauchen wir die noch? Was ist denn mit diesen hier (auf der Seite ganz unten)? http://www.mikrocontroller.net/articles/Kategorie:L%C3%B6schkandidaten Scheinbar wird das Thema "löschen" nicht so ernst genommen, siehe Beitrag "Löschungen im Wiki" Ich habe die trotzdem mal zu Löschkandidaten gemacht.
Torsten C. schrieb: > Scheinbar wird das Thema "löschen" nicht so ernst genommen, siehe > Beitrag "Löschungen im Wiki" > > Ich habe die trotzdem mal zu Löschkandidaten gemacht. Ich denke nicht, dass wir die noch benötigen. Sorry, ich kenn mich mit den Features des Forums noch nicht so gut aus :-( Danke für's Eintragen zum Löschen!
Angehängte Dateien:
Hier nun meine Vorstellung von der tragenden Konstruktion: sie besteht aus einer 45cm x 45cm 16mm starken MDF-Platte (im Baumarkt ca. 3 Euro), in die mittels 5mm Holzbohrer und aufgesetztem Versenker (Durchmesser 14mm) die Löcher für die LEDs gebohrt werden. Die Versenker weisen an der Vorderseite eine Schräge von 45° auf, wodurch sich eine Reflektorwirkung der Ausfräsungen ergibt. Leider gibt es keine 14mm Versenker für 8mm Bohrer, daher müssen die Löcher für die LEDs nachher noch auf 8mm aufgebohrt werden. Die Kanten der MDF-Platte werden entweder - wie auf dem Bild oben - mit Kantenumleimern versehen, oder man lackiert sie bei der Endlackierung mit. Am Rand sieht man die Vertiefungen für die 9 Neodym-Magnete zur Befestigung der Acryl-Frontplatte, welche an diesen Stellen magnetisierbare "Pflaster" aufgeklebt hat. Diese Befestigungsart ist für siebbedruckte Frontplatten (und wahrscheinlich auch für Stahlfrontplatten, sofern magnetisierbarer Stahl verwendet wird) optimal, bei aufkaschierter Vinyl-Folie muss man damit rechnen, dass sich durch die an diesen Stellen starke mechanische Beanspruchung die Folie im Lauf der Zeit vom Acrylglas löst. Finisierung der MDF-Platte: Ich stelle mir vor, dass die Platte mit Spritzfüller grundiert und weiß lackiert wird. Wenn jemand keinen Kompressor mit Farbspritzpistole hat: entsprechende Spraydosen (vorzugsweise nicht auf Wasser-, sondern auf Lösungsmittelbasis, damit die MDF-Platte nicht quillt!) gibt es im einschlägigen Farben-Fachhandel oder auch KFZ-Zubehör-Shop preiswert zu kaufen. Die Montage der LED-Stripes erfolgt vorzugsweise auf dünnen Alublech aus dem Baumarkt. Damit bei der Montage die Bauteile auf der Vorderseite der Stripes nicht beschädigt werden und trotzdem eine lichtdichte Abschirmung zu den benachbarten LED-Zellen hergestellt werden kann, stelle ich mir vor, dass man auf die Rückseite der MDF-Platte ein Raster aus dünnen, dauerelastischen Moosgummi-Streifen aufklebt, auf das dann die LED-Trägerplatte verspannungsfrei aufgesetzt und vorsichtig verschraubt wird. Durch die horizontal relativ engen Rasterabstände der LEDs von 16,67 mm sind mit handelsüblichen Versenkern leider keine größeren Ausnehmungen als mit 14mm Durchmesser möglich, der nächste handelsübliche Durchmesser wäre 16mm, und das ist zu groß, weil allzu dünne Stege zwischen den Kammern ausbrechen würden. Daraus ergibt sich, dass die Schriftgröße und Schriftart mit Bedacht gewählt werden muss, damit auch bei breiteren Buchstaben wie dem "W" eine Ausleuchtung bis in die Ecken des gesamten Buchstabens erfolgt. Eventuell muss man einzelne, zu kleine Kammern nacharbeiten. Da die Bearbeitung der MDF-Platte sehr zeitaufwändig und nervenaufreibend ist (288 Löcher Fräsen bzw. Bohren ist kein Kinderspiel!), wäre es zweckmäßig, die Platten von einer Firma fräsen und lackieren zu lassen. Wenn jemand diesbezüglich eine gute, preiswerte Quelle kennt, bitte melden!
Angehängte Dateien:
Schriftfont für Acryl-Frontplatte und dazupassende Bohrschablone : gestern wurden Bedenken geäußert, dass das von mir für die Acrylfrontplatte zuletzt vorgestellte Schriftmuster (Humanist 777 Light) nöglicherweise zu zart sein könnte, um den gewünschten Leuchteffekt der beleuchteten Wörter zu erzielen. Da diese Bedenken nicht von der Hand zu weisen sind, bin ich wieder zu der guten alten Standardschrift "Arial" zurückgekehrt und stelle hier ein Schriftmuster in Originalgröße 450mm x 450mm sowie eine dazupassende Bohr- und Frässchablone für 14mm Fräsungen zur Verfügung. Die passende Bohrschablone dazu ist ebenfalls im Originalmaß 450mm x 450mm und damit zu groß für einen DIN A4 Ausdruck. Man muss sie auf mehrere Blätter verteilen (es gibt Freeware-Programme, die das erledigen), und am besten kaschiert man sie dann mit einem wiederablösbaren Sprühkleber (Hobby-, Künstlermarkt) auf die MDF-Platte auf.
Herbert P. schrieb: > Hier nun meine Vorstellung von der tragenden Konstruktion: > > Da die Bearbeitung der MDF-Platte sehr zeitaufwändig und > nervenaufreibend ist (288 Löcher Fräsen bzw. Bohren ist kein > Kinderspiel!), wäre es zweckmäßig, die Platten von einer Firma fräsen > und lackieren zu lassen. Wenn jemand diesbezüglich eine gute, preiswerte > Quelle kennt, bitte melden! Ich kenne einen Fräser, der verlangt bei Einzellstücken 40€ pro Platte, nur fräsen. Wenn ihr viele braucht könnte es evtl. günstiger werden. Ich kann mal nachfragen, wenn ihr wollt!
Herbert P. schrieb: > Schriftfont für Acryl-Frontplatte und dazupassende Bohrschablone : > > gestern wurden Bedenken geäußert, dass das von mir für die > Acrylfrontplatte zuletzt vorgestellte Schriftmuster (Humanist 777 Light) > nöglicherweise zu zart sein könnte, um den gewünschten Leuchteffekt der > beleuchteten Wörter zu erzielen. > Ich werde euch mal auf einem Abfallstück verschiedene Schriften lasern, um die Ausleuchtung zu kontrollieren. Ich habe allerdings nur die standard Schriften.
Sergej Wind schrieb: > Ich werde euch mal auf einem Abfallstück verschiedene Schriften lasern, > um > die Ausleuchtung zu kontrollieren. > > Ich habe allerdings nur die standard Schriften. Klingt interessant:-) Wegen Fräser bitte deutsche Thread-Aktivisten fragen, für Östererich habe ich schon jemanden (hoffentlich).
Angehängte Dateien:
Zum Abschluss für heute noch ein "Foto" meines Lieblingsmodells - ein exquisites Stück mit hochglanzpolierter, echter Wurzelholz-Frontplatte. Ob sich das allerdings auch realisieren lässt, weiß ich noch nicht :-(
Herbert P. schrieb: > Zum Abschluss für heute noch ein "Foto" sieht gut aus, statt Uhr vormittags hätte ich aber morgens gewählt (finde ich harmonischer und die MB Bilder solltest du dir immer noch abgewöhnen, Server und Internetverschwendung und Lade- und damit Lebenszeit bei den Usern, besonders mobil
Joachim B. schrieb: > sieht gut aus, statt Uhr vormittags hätte ich aber morgens gewählt Sagt bei uns niemand, morgens hört bei uns um spätestens 9 Uhr auf :-) Joachim B. schrieb: > und die MB Bilder solltest du dir immer noch > abgewöhnen, Server und Internetverschwendung und Lade- und damit > Lebenszeit bei den Usern, besonders mobil Werde mir das zu Herzen nehmen. Die Texturen fressen soviel, aber das war ohnehin das letzte Modell.
Angehängte Dateien:
Herbert P. schrieb: > Werde mir das zu Herzen nehmen. Die Texturen fressen soviel, aber das > war ohnehin das letzte Modell. 1/16 Speicherplatz, sieht es schlechter aus?
du hast ja Recht, Joachim! Aber ich hatte die Grafiken ohnehin schon vom Originalformat auf 20x20 cm/300dpi zum Ausdrucken reduziert und hab mir - zugegebenermaßen nachlässigerweise - nicht auch noch die zusätzliche Mühe gemacht, sie noch einmal auf web-Auflösung mit 72 dpi zu bringen. Da die Resonanz auf die Grafiken bisher mehr negativ als positiv ausfiel (kein Kommentar ist auch ein Kommentar, die Anzahl der Rückmeldungen ging trotz relativ hoher ausgewiesener Downloadraten gegen Null), werde ich mir die Veröffentlichung derartiger Grafiken in Zukunft ohnehin tunlichst verkneifen. Insofern ist also eine ausführliche weitere Behandlung dieses Themas obsolet.
Herbert P. schrieb: > Da die Resonanz auf die Grafiken bisher mehr negativ als positiv ausfiel > (kein Kommentar ist auch ein Kommentar, die Anzahl der Rückmeldungen > ging trotz relativ hoher ausgewiesener Downloadraten gegen Null), och ich finde das ist der falsche Weg, die Bilder sind gut und nützlich was stört ist die Riesengröße, einmal normal speichern und einmal fürs Web platzoptimiert und gut ist, keine große Arbeit. Gute Rückmeldungen bekommt man eh seltener als Kritik!
Hat vielleicht jemand einen Tipp für mich, in welchem Dateiformat ich die Vektorgrafiken zum Lasern bzw. Fräsen der Schriften zur Verfügung stellen soll (mit CorelDraw11)? .svg,.plt zum Plotten? .dxf zum Fräsen und Laserschneiden? Welches Dateiformat wird üblicherweise als Vorlage für das Fräsen der MDF-Platte benötigt (ich habe nur SketchUp, kein AutoCAD)?
Herbert P. schrieb: > Da diese Bedenken nicht von der Hand zu weisen sind, bin ich wieder zu > der guten alten Standardschrift "Arial" zurückgekehrt und stelle hier > ein Schriftmuster in Originalgröße 450mm x 450mm sowie eine dazupassende > Bohr- und Frässchablone für 14mm Fräsungen zur Verfügung. Gefällt mir! Ich glaube, das ist der richtige Weg.
Torsten C. schrieb: > Hans H. schrieb: >> Ich werde ihn dann wieder hochladen wenn eine halbwegs fehlerfreie >> tables.h und display.h vorliegen. > > Die Links für beide .h habe ich im Wiki ergänzt: > > http://www.mikrocontroller.net/articles/WordClock24h#Verifikation.2C_Validierung.2C_Code-Generator Hallo Torsten, habe mir die tables.h und display.h von RawGit geholt und eingebaut. Es sind leider noch ein paar Fehler drin. { 08, 06, L"ES IST HH UHR UND MM MINUTEN (12)" }, wordclock2\tables.h(25): error C2041: illegal digit '8' for base '8' Lösung: überall 0z bitte mit < >z (LeerzeichenZahl) oder nur Zahl ersetzen static const struct uint8_t tbl_hours[HourModesCount][HourCount][MaxHourWordsPlusOne]= { wordclock2\tables.h(39): error C2649: 'uint8_t' : is not a 'struct' Lösung: struct hier entfallen lassen Ist falsch #define ModesCount 14 // count of different display modes Lösung: #define ModesCount 13 // count of different display modes Bei tbl_hours fehlt ein Modus, und bitte, bitte formatieren. Es sind nur 8 äußere Arrayelemente, aber 9 HourModes. Weiterhin würdest du allen einen Gefallen tun wenn tables.h und display.h als Ansi-Codepage 1252 in Git liegen. Die LED-Zeichen dann bitte mit \u25CF ausgeben, in den Kommentaren einfach DOT schreiben. Die aktuellen tables.h und display.h sind UTF-8 ohne Kennung womit die korrekte Erkennung der Kodierung vom Goodwill der beteiligten Programme abhängt ;-) Zu den Daten selbst, nach einer Korrektur der og. Compilefehler konnte ich noch keine vernünftige Ausgabe erzeugen, es muß noch weiter geforscht werden.
Hans H. schrieb: > Es sind leider noch ein paar Fehler drin. > > { 08, 06, L"ES IST HH UHR UND MM MINUTEN (12)" }, > wordclock2\tables.h(25): error C2041: illegal digit '8' for base '8' Ja, ich habe dasselbe Problem. Es gibt keine Oktalzahl 09. Bei führender 0 interpretiert der Compiler die Konstante als Oktalzahl. Deshalb müssen alle führenden Nullen weg.
Zwei weitere fehler in tables.h: Falsch:
1 | static const struct uint8_t tbl_hours[HourModesCount][HourCount][MaxHourWordsPlusOne]= { |
Richtig:
1 | static const uint8_t tbl_hours[HourModesCount][HourCount][MaxHourWordsPlusOne]= { |
Also hier muss "struct" weg. Falsch:
1 | static const MinuteDisplay tbl_minutes[MinuteModesCount][MinuteCount]= { |
Richtig:
1 | static const struct MinuteDisplay tbl_minutes[MinuteModesCount][MinuteCount]= { |
Hier muss "struct" eingefügt werden. Dank und Gruß, Frank
Ein paar Fehler in display.h Falsch:
1 | struct WordIllu { |
2 | word row; |
3 | word col; |
4 | word len; |
5 | };
|
Richtig:
1 | struct WordIllu { |
2 | uint16_t row; |
3 | uint16_t col; |
4 | uint16_t len; |
5 | };
|
Denn "word" gibts es nur unter Windows, sonst nirgendwo. [/c] Ausserdem: C-Identifier wie WP_18_FÜNF dürfen keine Umlaute enthalten. wchar gibt es nur unter Windows, aber nicht auf einem µC:
1 | static const wchar* display[1][DisplayY]= {{ // dummy-dimension for variant with capital ß |
Geändert in:
1 | static const char* display[1][DisplayY]= {{ // dummy-dimension for variant with capital ß |
Da ich sowohl unter Linux als auch auf dem STM32 eher ISO8859 einsetze. UTF8 macht das ganze auf einem µC ziemlich fett. Falsch:
1 | static const WordIllu illumination[1][WpCount]= {{ // dummy-dimension for variant with capital ß |
Richtig:
1 | static const struct WordIllu illumination[1][WpCount]= {{ // dummy-dimension for variant with capital ß |
Also das Keywword "struct" eingefügt.
Sorry + danke fürs testen. Das wichtigste ist korrigiert, V0.5 ist online.
Hans H. schrieb: > Weiterhin würdest du allen einen Gefallen tun wenn tables.h und > display.h als Ansi-Codepage 1252 in Git liegen. Ich habe überall gesucht und keine Möglichkeit gefunden, das bei Github einzustellen, aber erstmal muss ich das Ziel verstehen. Hans H. schrieb: > Die LED-Zeichen dann bitte mit \u25CF ausgeben Aber "wchar gibt es nur unter Windows, aber nicht auf einem µC:". Erstmal habe ich für die LEDs "?" eingesetzt. \u25CF ist für das Mock-up mit C# so in der .accdb. Eine grundsätzliche suchen-ersetzen-Regel für wchar-Angaben mit \u#### macht keinen Sinn, richtig? Vielleicht mache ich lieber eine spezielle Ersetzung des Punktes gegen "." in der Matrix und "DOT" in den Kommentaren? Frank M. schrieb: > C-Identifier wie WP_18_FÜNF dürfen keine Umlaute enthalten Das ist in der .accdb falsch. Die Spalte [text] enthielt früher mal Sterne, die sind zwar nun weg, aber die Umlaute sind noch da. Ich hoffe, ich habe vor dem Export mit V0.5 alle Umlaute in der Tabelle gefunden und ersetzt. @Hermann, kannst Du in [text] zukünftig z.B. "WP_18_FUENF" statt "WP_18_FÜNF" schreiben?
Torsten C. schrieb: > @Hermann, kannst Du in [text] zukünftig z.B. "WP_18_FUENF" statt > "WP_18_FÜNF" schreiben? Solltest Du mit "Hermann" mich gemeint haben: die Tabellen sind schon geändert, die Spalte "text" enthält keine Umlaute mehr. Ich hab aber die Datenbanken noch nicht hochgeladen, warte noch auf allfällige sonstige Änderungswünsche. Betreffen tut dies: 18_FUENF 24_ZWOELF 30_FUENFZIG 48_FUENF 62_ZWOELF 63_FUENFZIG 67_FRUEH
Frage: wieviel Speicherplatz verbraten die Tabellen letztendlich tatsächlich?
Herbert P. schrieb: > Solltest Du mit "Hermann" mich gemeint haben: die Tabellen sind schon > geändert, die Spalte "text" enthält keine Umlaute mehr. Ich hab aber die > Datenbanken noch nicht hochgeladen, warte noch auf allfällige sonstige > Änderungswünsche. Mein großer Wunsch wäre daß du die Bezeichner der Word-Positionen korrigierst, daß diese mit den wirklichen Indizes übereinstimmen: Index Name 1 WP_1_ES -> ok 2 WP_2_IST -> ok 4 WP_3_VIERTEL -> ok 5 WP_6_EIN -> falsch 6 WP_7_EINS -> falsch usw. Das würde dir sicher auch die Pflege/Fehlerkorrektur erleichtern. mfg
Torsten C. schrieb: >> Weiterhin würdest du allen einen Gefallen tun wenn tables.h und >> display.h als Ansi-Codepage 1252 in Git liegen. > > Ich habe überall gesucht und keine Möglichkeit gefunden, das bei Github > einzustellen, aber erstmal muss ich das Ziel verstehen. Das Ziel wäre daß manche Editoren/Differ besser damit klarkommen. Aber zur Not geht es auch so, Visual Studio hat keine Probleme mit UTF-8 ohne Kennung. > > Hans H. schrieb: >> Die LED-Zeichen dann bitte mit \u25CF ausgeben > > Aber "wchar gibt es nur unter Windows, aber nicht auf einem µC:". > > Erstmal habe ich für die LEDs "?" eingesetzt. \u25CF ist für das Mock-up > mit C# so in der .accdb. > > Eine grundsätzliche suchen-ersetzen-Regel für wchar-Angaben mit \u#### > macht keinen Sinn, richtig? > > Vielleicht mache ich lieber eine spezielle Ersetzung des Punktes gegen > "." in der Matrix und "DOT" in den Kommentaren? OK, da auf uC kein Unicode verwendet wird, ist es am besten den . statt dem \u#### Zeichen zu nehmen. Ansonsten ist die aktuelle Version von dir einwandfrei compilierbar. (Data from WC24h_18x16_V2_1134_5.Dez.2014, CodeGen v0.5) Es werden bei mir allerdings immer noch wirre Wortteile angeschaltet, muß ich weiter Fehler suchen ;-(
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.