Hallo, im Moment beiße ich mir einen Zacken aus der Krone. Die Lösung ist bestimmt simple, ich finde aber keinen Lösungsweg. Hab schon gegoogled aber keinen brauchbaren Ansatz gefunden. Zum Problem: Ich habe mehrere unsigned long Werte die ich in einen i2c eeprom (24c512) speichern (loggen) möchte. Wie ich den 24c512 anspreche weiß ich. Ich brauche nur einen Tipp wie ich den unsigned long als C-Code in 4 einzelne byte zerlege. Beispiel: unsigned long = 265896 ergebniss: byte3 = 0x00 byte2 = 0x04 byte1 = 0xE0 byte0 = 0xA8 Hoffe mir kann einer einen Tipp geben und bedanke mich dafür schon mal !!
Stefan snkrde schrieb: > Zum Problem: > Ich habe mehrere unsigned long Werte die ich in einen i2c eeprom > (24c512) speichern (loggen) möchte. Wie ich den 24c512 anspreche weiß > ich. Ich brauche nur einen Tipp wie ich den unsigned long als C-Code in > 4 einzelne byte zerlege. Da in dieser Anwendung die Byte-Order wahrscheinlich keine Rolle spielen wird, da derselbe µC die Bytes wieder zurückliest, der sie auch geschrieben hat, warum dann nicht einfach so
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
Oder als union. Dürfte die effizienteste Möglichkeit sein.
Gast
#3150159
H.Joachim Seifert schrieb: > Oder als union. Dürfte die effizienteste Möglichkeit sein. Aber laut Standard undefiniert. Kommt ja nur alle drei Tage die Frage... Bits schieben!
Welchen Standard meinst du? In C/C++ ist union sehr wohl definiert. union ist aber Prozessor Abhängig und daher nicht portabel. Wenn dein Programm also nicht auf verschiedenen MC Typen (Pic, AVR, ARM, ...) laufen soll, ist es kein Problem. Grüsse
Gast
#3150199
Markus M. schrieb: > In C/C++ ist union sehr wohl definiert. Natürlich, aber dort wird kein Ergebnis garantiert wenn man Datentyp A schreibt und dann Datentyp B liest bzw. das Ergebnis ist implementation-defined. In der Bibel findet sich auf S. 214 "a member of a union may not be inspected unless the value of the union has been assigned using that same member". Die dort genannte Ausnahme zieht hier nicht.
@troll Am besten Du testest die Funktionsweise und entscheidest dich dann dafür oder dagegen. Der Lerneffekt ist unbezahlbar. Grüsse
Danke für Eurer Antworten ! Habe gerade bemerkt das mein Beitrag nicht im AVR-Thread gelandet ist. Gemeint war AVR-GCC. Der Code-Schnipsel von Karl-Heinz bringt mich warscheinlich weiter ! Danke :)
Gast
#3150290
Markus M. schrieb: > @troll > Am besten Du testest die Funktionsweise und entscheidest dich dann dafür > oder dagegen. Der Lerneffekt ist unbezahlbar. Ja ich weiss, es geht, aber wie gesagt.
Gast
#3150609
Markus M. schrieb: > @troll > Am besten Du testest die Funktionsweise und entscheidest dich dann dafür > oder dagegen. Der Lerneffekt ist unbezahlbar. troll hat da durchaus Recht. Man macht in C so einiges unbewußt, was eigentlich nicht definiert ist, aber jeder C-Compiler unterstützt es. Dann stolpert man eines Tages über so seltsame Dinge wie Aliasing und guckt erstmal dumm aus der Wäsche... http://en.wikipedia.org/wiki/Strict_aliasing#Conflicts_with_optimization
Stefan snkrde schrieb: > Der Code-Schnipsel von Karl-Heinz bringt mich warscheinlich weiter ! Der bringt dich ganz sicher weiter. Ansonsten liegts an dir. troll schrieb: > Natürlich, aber dort wird kein Ergebnis garantiert wenn man Datentyp A > schreibt und dann Datentyp B liest bzw. das Ergebnis ist > implementation-defined. Wo Troll recht hat hat er recht :-)
Udo Schmitt schrieb: > Stefan snkrde schrieb: >> Der Code-Schnipsel von Karl-Heinz bringt mich warscheinlich weiter ! > > Der bringt dich ganz sicher weiter. > Ansonsten liegts an dir. Gerade mal im Studio Simuliert ! JAAAAA, das war die Lösung.... DANKE :)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.