mikrocontroller.net

Forum: Compiler & IDEs Wo finde ich wie Integer "aussehen"


Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich in jeder besseren Grundlagendokumentation, die
sich mit Computern und binärer Zahlendarstellung befasst.

Suche mal nach "Zweierkomplement", da findest du haufenweise
Erklärungen.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Simon Küppers (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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?

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

auf Seite 11 steht das Ausgabeformat doch beschreiben:

The output data format is straight binary for unipolar
conversions and two’s 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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon Küppers (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl heinz Buchegger (heinzi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.