Gast
#3204567
Hallo, ich erhalte über UART einen Unixtimestamp. Diesen möchte ich einen uint64 zuweisen. Wie kann ich das in C bewerkstelligen. Es wird Später auf einen AtMega32 laufen. Danke
Hallo Markus, deine Frage verursacht noch weitere Frage, * wie ist der TS kodiert ? * in welcher Reihenfolge wird er gesendet MSB -- LSB ? mach doch bitte deine Frage an einem Beispiel fest, dann wird es für uns einfacher. .
Gast
#3204593
> Wie kann ich das in C bewerkstelligen.
Was bekommst Du denn? Einen C-String? man atoll. Rohdaten in der
richtigen(tm) Endianness? man memcpy. Rohdaten in der falschen(tm)
Endianness oder anderweitig total verwurstet? man C/arrays.
Gast
#3204621
er gibt mir bei einen aufruf von atoll oder atoull: /test.c:97: undefined reference to `atoll' collect2: ld returned 1 exit status inculierte header dateien: #include <avr/io.h> #include <stdlib.h> #include <stdint.h> #include "test.h" #include <inttypes.h>
Gast
#3204625
µc sendet TIME zu einen Server Server Antwortet mit 1371314086 das lese ich in ein char array ein nun will ich die 1371314086 aber in einen uint64 haben
Markus schrieb: > er gibt mir bei einen aufruf von atoll oder atoull: > /test.c:97: undefined reference to `atoll' Das ist ein Linkerfehler. Sieh in der Dokumentation Deines C-Compilers nach, welche Library Du einbinden musst, damit atoll/atoull verwendet werden können.
Gast
#3205127
Hallo, leider liegt genau da mein Problem. ich nutze gcc und habe bisher nur was von der stdlib.h gelesen gcc rufe ich wie folgt auf: avr-gcc -g -Os -mmcu=atmega32 -DF_CPU=16000000UL -std=gnu99 -fshort-enums -MD -MP -MF .dep/test.elf.d -Wall -W -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wshadow -Wbad-function-cast -Winline -Wpointer-arith -Wsign-compare -Wunreachable-code -Wdisabled-optimization -Wcast-align -Wwrite-strings -Wnested-externs -Wundef -Wa,-adhlns=test.lst -DDEBUG -mmcu=atmega32 -o test.elf kann mir bitte wer helfen?
Markus schrieb: > ich nutze gcc und habe bisher nur was von der stdlib.h gelesen Das ist eine Headerdatei. Die interessiert den Linker nicht. In der Dokumentation Deines C-Compilers sollte bei der Beschreibung der Funktionen aber nicht nur dabeistehen, in welcher Headerdatei sie deklariert sind, sondern auch, in welcher Library die Implementierung zu finden ist. Gut, das erste kann man auch mit grep/findstr selbst herausfinden, das letztere mit objdump.
In den AVR-Tools mit AVR-LibC gibt es kein strtoull und auch kein atoull --> selber programmieren. Ist das char-Array denn ein String oder ist das schon das Binärformat des Stamps?
Johann L. schrieb: > In den AVR-Tools mit AVR-LibC gibt es kein strtoull und auch kein atoull > --> selber programmieren. Dann ist allerdings spannend, warum die Deklarationen davon in Headerdateien vorhanden sind, die Markus verwendet. Wo kommen die her?
Vielleicht wird die newlib verwendet?
Rufus Τ. Firefly schrieb: > Dann ist allerdings spannend, warum die Deklarationen davon in > Headerdateien vorhanden sind, die Markus verwendet. Woraus schließt du das? Ich wette die "implicite declaration"-Warnung hat er schlicht unterschlagen.
Nimm einfach uint32_t. Dein Gerät wird eh 2106 nicht mehr im Einsatz sein.
Stefan Ernst schrieb: > Ich wette die "implicite declaration"-Warnung hat er schlicht > unterschlagen. Da er eine konkrete Fehlermeldung aufgeführt hatte, war ich davon nicht ausgegangen, aber das kann natürlich auch der Fall sein. Warten wir eine Reaktion des Threadstarters ab.
Die Warnung sollte bereits vom Compiler kommen, die Fehlermeldung ist hingegen vom Linker.
Gast
#3205681
hallo, ich hoffe ihr steinigt mich nicht ;) ja ich hab die "implicite declaration"-Warnung unterschlagen. nun hab ich mir Peters Vorschlag zu Herzen genommen. danke an alle trotzdem irgendwo komisch das avr-gcc kein chararray in uint64 wandeln kann.
Das ist auch nicht Aufgabe des Compilers sondern der Bibliotheken ;-) Wenn es ein Dezimalstring ohne Leer- und Vorzeichen ist dann geht die Umwandlung mit
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
Ist ja nicht die Welt das.
Markus schrieb: > trotzdem irgendwo komisch das avr-gcc kein chararray in uint64 wandeln > kann. Was soll daran komisch sein? Auf 8-Bit-Systemen ist der Gebrauch von 64-Bit-Variablen eher ungewöhnlich; selbst bei 32-Bit-C-Compilern für PCs war das lange Zeit keine Selbstverständlichkeit (ältere Varianten von Microsofts C++-Compiler beispielsweise kannten keine 64-Bit-Datentypen, vom double mal abgesehen).
Der 8051 Assembler konnte ja nichtmal 32Bit rechnen. Da mußte man das Ausrechnen von Konstanten (Bautrate, Timerwerte usw.) noch richtig zu Fuß (Taschenrechner) machen und sie hart in den Quelltext reinschreiben.