Hey, Kurze Frage: Wo finde ich denn ne Quelle, wo steht, wie ein INT (Beziehungsweise alle Datentypen) im RAM oder sonstwo abgelegt werden und wie signed_ Vals und _unsigned Vals aussehen
Eigentlich in jeder besseren Grundlagendokumentation, die sich mit Computern und binärer Zahlendarstellung befasst. Suche mal nach "Zweierkomplement", da findest du haufenweise Erklärungen.
trifft das denn auch bei der avr-libc zu? (Also speziell das mit unsigned/signed) werten? Dann guck ich doch gleich mal in mein C Buch.
Ja klar. Dachtest du, der AVR erfindet das Rad neu? Das hängt übrigens nicht von der Bibliothek ab, sondern vom Prozessor. Mit C hat es auch nicht unbedingt was zu tun, insofern ist das C-Buch u. U. ungeeignet als Nachschlagewerk (weil C sich natürlich möglichst komplett aus solchen Dingen wie einer internen Zahlendarstellung raushalten möchte).
Ich vermute mal, Simon meint die Byteorder. Die ist bei 8-Bittern nicht definiert und daher compilerabhängig. Wenn ich einen Int in Bytes zerlege bzw. umgekehrt, mache ich das daher lieber compilerunabhängig, also mit Schiften und Undieren. Bzw. wenn verschiedene 16- oder 32-Bitter kommunizieren, ist das auch immer wieder ein Problem. Ein Kollege ist gerade dabei, einen Ethernettreiber auf den ARM zu portieren. Der 8051 (Keil C51) hatte die richtige Byteorder, der ARM hat leider die falsche und benötigt außerdem ein Alignment. Peter
@Peter Dannegger: > Ein Kollege ist gerade dabei, einen Ethernettreiber auf den ARM > zu portieren. Der 8051 (Keil C51) hatte die richtige Byteorder, > der ARM hat leider die falsche und benötigt außerdem ein Alignment. Erzähle Deinem Kollegen, dass htons(), htonl(), ntohl() und ntohs() schon erfunden sind.
Ich glaube Peter versteht mich. Im C Buch habe ich nichts dazu gefunden (Ist halt nur ein Anfänger C Buch), aber wenn ich was gefunden hätte, hätte es also nicht zwangsläufig für den AVR gelten müssen? Denn was ich wissen will ist folgendes: Wenn ich jetzt 2 bytes von einem bipolaren ADC bekomme (Also der + und - messen kann, wo das höchste Bit das Vorzeichen bit ist), kann ich einfach den Wert als INT einlesen und habe dann automatisch die richtige Zahl oder muss ich noch dies oder das machen... Und genau dafür, benötige ich die Information, wo beim AVR-C bzw beim Integer jetzt genau das Vorzeichen Bit steht, wie -32767 aussieht und +32767 und wie die 0 gilt. Und außerdem, wie die Zahlen dazwischen aussehen.
> Denn was ich wissen will ist folgendes: Nun, wie du eben siehst, ist es immer sinnvoll, genau das zu fragen, was man wissen will, statt den Befragten einen Teil der Information vorzuenthalten, weil man ,,vordenken'' will. > Wenn ich jetzt 2 bytes von einem bipolaren ADC bekomme (Also der + > und - messen kann, wo das höchste Bit das Vorzeichen bit ist), kann > ich einfach den Wert als INT einlesen und habe dann automatisch die > richtige Zahl oder muss ich noch dies oder das machen... Das ist exakt das int16_t-Format praktisch aller heute gängiger Architekturen, einschließlich des AVR.
>>Das ist exakt das int16_t-Format praktisch aller heute gängiger Architekturen, einschließlich des AVR. Bist du dir sicher ? Würde ich lieber nicht so pauschalisieren. Der positive Bereich des 16Bit AD Wandler erstreckt sich von 0b0000 0000 0000 0000 bis 0b0111 1111 1111 1111 (0 bis +32767) und der negative Bereich erstreckt sich über 0b0000 0000 0000 0000 bis 0b1000 0000 0000 0000 (0 bis -32767) zu finden: http://pdfserv.maxim-ic.com/en/ds/MAX1142-MAX1143.pdf Seite 17... Ich glaub nicht dass das aufm µC auch so ist, kann mich aber auch irren, da ich noch keine Infos erhalten habe. Ich denke auf dem µC ist es so: 0b0000 0000 0000 0000 bis 0b0111 1111 1111 1111 (0 bis +32767) 0b0000 0000 0000 0000 bis 0b1111 1111 1111 1111 (0 bis -32768) Oder?
Hi auf Seite 11 steht das Ausgabeformat doch beschreiben: The output data format is straight binary for unipolar conversions and twos complement in bipolar mode. Und das ist genau die Zahlendarstellung für Integerzahlen wie es beinahe jedes µC-Rechenwerk dieser Welt verwendet. Alles andere wäre auch nicht besonders clever vom Hersteller des ADC. Matthias
Wenn Du den internen ADC liest, dann weiß der Compiler, wie er das machen muß. Einen externen ADC kann er aber nicht kennen, da mache ich es immer byteorderunabhängig: int val = ((int)ADCHI<<8) | ADCLO; Peter
Arghs, Ihr habt ja beide Recht. Ich weiß auch wie das Format vom ADC aussieht. Ich möchte aber gerne wissen, wie der Integertyp im µC "aussieht", damit ich erkennen kann ob irgndeine Anpassung notwendig ist. Und das ist das, was ich wissen will. Wenn das aber anscheinend in (fast) jedem C-Compiler gleich ist, dann ist das schonmal gut. Und da ich jetzt weiß, dass dass das Format des ADCs gleich dem signed Integer Format (also im bipo mode) ist, kann ich ja beruhigt schlafengehen ;) @Peter: Dachte ich auch so, beide Bytes einlesen, dass eine ins lowbyte packen, das andere zu int casten, shiften und dann ins highbyte packen. Wenn ich also jetzt itoa anwende auf diese signed integer zahl, dann bekomme ich automatisch den richtigen +/- Wert zurück (Als String) ? Aber gut, dass ich über viele Umwege noch an diese Info gekommen bin. Eigentlich hättemir ja auch eine Seite o.ä. gereicht, wo das aufgezeichnet ist mit dem signed/unsigned. Hatte erst versucht zu googlen, bin aber gescheitert und das war der Grund, dass ich hier gefragt habe. Dankee
Wenn du mit Bytes hantierst, dann ist es immer gut, wenn Du das nicht signed machst, sondern unsigned! Erst das Ergebnis, nachdem die Bytes zusammengesetzt wurden ist dann signed.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.