Hallo,
ist zwar ein Thema für den ARM aber glaube für PC ist das ähnlich oder
gleich.
Ich habe für meine Wetterstation eine Anzahl Zahlen, die Wetterzustände
ausdrücken. Diese werden vom Provider der Wetterinfo geliefert
200, 202, 203..... 500,501, 502, 510..... usw.
Abhängig von dieser Info werden LED gesetzt. Also für 202 wird zb
13,14,15 gesetzt, mal sind es 2, mal 3 oder 4.
Die Tabelle steht hier, entspricht der internationalen Darstellung:
https://openweathermap.org/weather-conditions
Ich habe nun
typedef struct {
char led[5];
+ggf. weitere Vars
} led_t;
led_t wettercond[30];
In wettercond müssen 30 Zahlen rein aus den Tabellen des Dienstes und in
den Struct muss zu jeder Zahl die Info stehen, welche LED dazu gehören.
Gibt es da was Kluges, das ohne ein händisches Füllen in einer Routine
zu machen? Wäre quasi sowas: 200,6,7,201,3,4,5,205,1,2,210,.... wobei
die kleinen Zahlen immer die LED Nummern sind und die 3stelligen das
Wetter.
Gruss,
Christian
Ich nehme an es gibt keinen naheliegenden, mathematischen Zusammenhang
zwischen den Wettercodes und den LEDs, also wie soll das gehen?
Den Zusammenhang kennst ja nur du, also musst du den auch in Code
ausdrücken
jemand schrieb:> Den Zusammenhang kennst ja nur du, also musst du den auch in Code> ausdrücken
Ja, deswegen ja. Nur wie kriege ich die vielen Zahlen effizient da rein?
Da sich das Array vermutlich nicht ändert packe noch ein "const" dran.
Bei Mikrocontrollern packt der Compiler das dann in den Flash (spart
RAM), bei PC-Betriebssystemen (typischerweise) in eine Section die man
nicht versehentlich überschreiben kann.
Rufus Τ. F. schrieb:> Christian J. schrieb:>> Ist das so von der Syntax richtig?>> Wenn es C99 oder neuer sein soll.>> In C89 sähe das so aus:> led_t wcond[60] => { 800, { LED_GRN } } ,> { 801, { LED_GRN, LED_GLB_1 } } ,> { 802, { LED_GLB_1 } } ,> { 803, { LED_GLB_1, LED_GLB_1 } } ,> { 701, { LED_GLB_1, LED_GLB_1, LED_GLB_1 } } ,> { 741, { LED_GLB_1, LED_GLB_1, LED_GLB_1 } } ,>> etc.
Ok, die . Schreibweise ist nicht möglich? Meine das schonmal geseehn zu
haben, ist für mich etwas übersichtlicher. C99 ist eingestellt.
Siehe
https://stackoverflow.com/questions/18921559/initializing-array-of-structures
Christian J. schrieb:> Ok, die . Schreibweise ist nicht möglich?
Doch doch, ab c99 schon, und das gibts sowieso überall. Ich würde da
aber nicht jeden Index einzeln angeben, das wird schnell unübersichtlich
Ungetestet:
1
led_twcond[60]={// Die geschweifte Klammer nicht vergessen!
Bei der vorliegenden Struktur kann man aber auch die C89-Schreibweise
verwenden. Die Schreibweise, bei der einzelne Strukturelemente benannt
werden, ist erst dann zwingend erforderlich, wenn man nicht alle
aufeinanderfolgenden Elemente initialisieren will, sondern Lücken
dazwischen lässt.
1
typedefstruct
2
{
3
intx;
4
inty;
5
intz;
6
char*s;
7
inta;
8
}test_t;
9
10
test_ttest[]=
11
{
12
{1,2,3,"huhu",4},// alle elemente
13
{1,2,3},// nur die ersten drei
14
...
Möchte man aber nur das dritte Element initialisieren, muss man in C89
die beiden davorliegenden trotzdem (mit 0) initialisieren.
Erst in diesem Fall bringt die "Punkt-Schreibweise" von C99 einen
Vorteil:
1
{0,0,5},// c89: z initialisieren
2
3
{.z=5},// c99: z initialisieren
Im vorliegenden Fall aber ist die "Punkt-Schreibweise" nur mehr
Tipparbeit, ohne daß die Übersichtlichkeit dadurch verstärkt wird.
Rufus Τ. F. schrieb:> Im vorliegenden Fall aber ist die "Punkt-Schreibweise" nur mehr> Tipparbeit, ohne daß die Übersichtlichkeit dadurch verstärkt wird.
Sie hat aber den Vorteil dass wenn man hinterher die Struktur nochmal
ändert man sofort merkt an welchen Stellen des Initializers man
vergessen hat das ebenfalls anzupassen (oder wenn man Glück hat gar
nicht erst anpassen muss). Die Punkt-Schreibweise ist robuster.
Ok, ich hoffe mal, dass die Tipparbeit nicht umsonst war.....
Danke für die Hinweise, finde es inzwischen auch übersichtlicher ohne
die .led Schreibweise. Es scheint zudem nichts zu geben, was die Cracks
hier nicht wissen :-)
Die CPU wird dann da durch turnen und sich heraussuchen, was zutrifft.
Über den MC23017 wird dann blinken und leuchten. Das Blinken muss ich
mir aber noch überlegen, wie das gehen soll. In einem alten Projekt war
jede LED ein Bit im bit-bandind Bereich, da war das easy. Hier hängen
sie am MCP 23017 dran.
Bernd K. schrieb:> Sie hat aber den Vorteil dass wenn man hinterher die Struktur nochmal> ändert man sofort merkt an welchen Stellen des Initializers man> vergessen hat das ebenfalls anzupassen
Ja.
Wenn man allerdings mal in die Verlegenheit kommt, den Code einem
C++-Compiler vorzuwerfen, gibts Probleme - denn in C++ gibt es keine
"designated initializers".
Rufus Τ. F. schrieb:> Bernd K. schrieb:>> Sie hat aber den Vorteil dass wenn man hinterher die Struktur nochmal>> ändert man sofort merkt an welchen Stellen des Initializers man>> vergessen hat das ebenfalls anzupassen>> Ja.>> Wenn man allerdings mal in die Verlegenheit kommt, den Code einem> C++-Compiler vorzuwerfen, gibts Probleme - denn in C++ gibt es keine> "designated initializers".
Ab gcc-8 bzw. dann auch c++20 bzw. c++2a nicht mehr.
Rufus Τ. F. schrieb:> Ein Paar?>> Eine. Mit einem Semikolon dahinter.
Zwei. Eine öffnende und eine schließende (und das Semikolon dahinter
natürllich).
Deshalb hab ich ja extra auf den Post von DPA verwiesen, da steht ein
entsprechender Kommentar im Source:
Rufus Τ. F. schrieb:> Wenn man allerdings mal in die Verlegenheit kommt, den Code einem> C++-Compiler vorzuwerfen, gibts Probleme
Und warum sollte man das tun? Den C Code als C Code übersetzen, den C++
code als C++ Code, den Rust Code als Rust Code, etc. Die Object Files
kann man dann immer noch zusammen linken, und mit den C Symbolen kommen
fast alle Sprachen zurecht, wenn man es angibt (extern "C").
main.h:72: error: expected unqualified-id before '{' token
{ 801, { LED_GRN, LED_GLB_1 } }, /* few clouds */
^
exit status 1
expected unqualified-id before '{' token
Mecker, mecker..... irgendwas mag er nicht. Klammern? Was fehlt denn da
noch? Ok, Semikolon unten, aber sonst?
Ah ok, Groschen gefallen, läuft durch :-) Bisschen zu viel Klammern....
