Zusammenfügen von 2 mal 8 bit zu einem 16 bit Wert funktioniert nicht richtig

Beitrag "Aus 2x8Bit mach 1x16Bit"

Diesen Beitrag hatte ich bereits studiert auch einige andere zu dem 
Thema. (Beitrag "16 Bit Variable aus 2 8 Bit laden")
Leider klappt es nicht. Ich habe probeweise mal den cast weggelassen das 
funktionierte auch nicht.

Allerdings funktioniert das:

y=yupper*255+ylower;

Das KANN aber so nicht richtig sein. Wer von den Profis mag hier Licht 
ins Dunkel bringen?

Hallo Peter. Danke für den Hinweis. Allerdings verstehe ich ihn nicht. 
Magst Du das etwas genauer erläutern?

>Allerdings funktioniert das:
>
>y=yupper*255+ylower;


... es sollten eher 256 sein. y=yupper*256+ylower;

Jetzt bin ich baff!
@Peter: Das hat nicht geklappt!
@Zwoelf: Du hast recht und siehe da:

y=yupper*256+ylower;

macht den gleichen "Fehler" wie:

y=yupper<<8|ylower

Was läuft da über und warum?

Mach die Variablen unsigned:

1

unsigned char yupper = 0;

2

unsigned char ylower = 0;

und den Cast auf int16_t nach außen:

1

y = (int16_t) ((yupper << 8) | ylower);

In Deinem Fall könntest Du den Cast sogar weglassen, weil y ja schon 
int16_t ist.

upper muß signed sein, lower muß unsigned sein.
Ist upper auch unsigned, klappt es nur auf 16Bit-CPUs, nicht aber auf 
32Bittern.

Danke Fabian. Geht leider auch nicht :-(

Ich schätze mal, Dein Problem liegt wo anders. Du schreibst den Wert ja 
letztlich in das OCR1A-Register. Da machen negative Werte aber keinen 
Sinn. Vielleicht willst Du zuerst noch prüfen, ob der gelieferte Wert 
größer/gleich Null ist bzw. auf einen positiven Bereich skalieren?

Vielen Dank für die Hinweise ich glaube das Problem liegt tatsächlich 
ganz wo anders:

Zuallerst mal: Ich habe mich bislang nicht so sehr darum gekümmert ob 
etwas signed ist oder nicht da ich erstmal nur möchte das das IMU mit 
mir spricht und sobald es das tut erstmal nur eine Neignung nach Rechts 
betrachten möchte.

Mulitpliziere ich mit 255 passiert auch ungefähr was passieren soll. 
Kippe ich das IMU nach rechts habe ich einen Peak von 6-7 ms länge und 
nach links von 40-800µs.

Ich habe probeweise den Wert von y fix vorgegeben. Wenn es kleiner ist 
als 0x0037 "spinnt" der µC was aber meines Erachtens auch richtg ist.

Bei Multiplikation mit 256 und auch bei der shift konstruktion kann ich 
auf meine Oszi sehen wie 8 bit durchlaufen werden und bei kleiner als 
0x37 der Timer "spinnt"

Mir ist das ein Rätsel, vielleicht hilft diese Beschreibung des Problems 
mehr.

Ach so: Die 8 bit werden immer wieder durchlaufen bei einer konstanten 
Drehung des IMU

Peter Dannegger schrieb:
> upper muß signed sein, lower muß unsigned sein.
> Ist upper auch unsigned, klappt es nur auf 16Bit-CPUs, nicht aber auf
> 32Bittern.

Eher im Gegenteil:

1

int receive (void)        //Funktion um ein Zeichen vom UART zu empfangen

2

{

3

  while (!(UCSRA&(1<<RXC)))   //Die Schleife prüft ob das Empfangsbit gesetzt ist

4

  ;                // ist es nicht gesetzt passiert nix.

5

  return UDR;          //Empfangenes Zeichen wird zurückgegeben

6

}

7

8

int main (void)

9

{

10

  int yupper=0;

11

  unsigned int ylower=0;

12

  int y;

13

14

  // ...

15

  yupper=receive();  // Pitch "grösseres" Byte 

16

  ylower=receive();  // Pitch "kleineres" Byte

17

  y=(yupper<<8)|ylower;

18

  // ...

19

}

Das funktioniert nur auf 16-Bit-Plattformen, nicht auf 32 Bit.

Nach einer Weile des Nachdenkens:

"yupper" scheint immer 0 zu sein beim Shiften wie auch beim 
Multiplizieren mit 256. Bei Multiplikation mit 255 aber nicht. Was kann 
das sein?

Erklär doch mal, was das Programm überhaupt machen soll. Diese 
Statemaschine in der Timer-ISR mit Neuladen des OCR1A-Register sieht mir 
ziemlich suspekt aus ...

Also:
- Welchen Wertebereich liefert der Sensor (laut Datenblatt) bei welcher 
Position?
- Was soll bei welcher Position bzw. welchem Wert passieren?

Am besten wäre, wenn Du erstmal sicherstellst, was da überhaupt für 
Zahlen ankommen. Hast Du irgendeine Möglichkeit, die Zahl menschenlesbar 
auszugeben, z.b. über die TX-Leitung des UART?

Wenn nicht, dann mach das Programm erstmal so einfach wie möglich. 
Schreib den empfangenen Wert direkt in OCR1A und lass den Timer einen 
Pin toggeln. Auf dem Oszi kannst Du dann anhand der Frequenz auf den 
Wert schließen.

Hallo W.S.:

Das hier ALLE falsch liegen ist recht unwahrscheinlich auch wenn die 
Vorschläge, genau so wie deiner, nicht das gewünschte Ergebnis 
erbrachten.

Fabian:

Ich habe deinen Vorschlag umgesetzt im Ergebnis bleib alles beim Alten. 
Allerdings wurde die Fehlersuche vereinfacht da ich zumindest keine ISR 
hatte die rumspinnt.

Ich habe das Rätsel dennoch im Trial und Error Verfahren gelöst und 
bitte um Rat der Profis:

Ich habe versuchsweise die Optimierung , die auf -Os war ausgeschaltet 
und siehe da: "y=(int16_t)((yupper<<8)|ylower)" bring das gewünschte 
Ergebnis.

An die Profis: Wie muss/soll ich das in Zukunft machen? -Os habe ich nur 
benutzt

1) Weil vor einiger Zeit die Ansteuerung eines Displays ohne optimierung 
nicht ging

2) Weil in diesem Artikel 
http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung die 
Optimierung -Os empfohlen wird.

Was ist das korrekte Verfahren?

@Dummschwätzer:

Ist dein Alias Programm? Ich kann nämlich mit deiner Aussage nichts 
anfangen.

Ich bin in meinem C Buch noch nicht so weit fortgeschritten das ich 
wüsste was ein "union" ist.

Dummschwaetzer schrieb:
> nimmst du ein union!

Was hat das mit dem Problem zu tun?  Das bring bestenfalls neue Probleme 
(undefined behavior etc.)  Dies Forum ist voll mit Erklärungen und 
Hinweisen, warum.

Der Hase wird irgendwo da im Pfeffer liegen, wo die Daten für 'y' 
erzeugt werden (vermutlich hat das was mit receive(..) zu tun), so dass 
der Zugriff auf 'y' bei jeder eingeschalteten Optimierung wegoptimiert 
werden wird. Irgendwas vernalasst den Compiler anzunehmen, dass sich 
'ylower' und 'yupper' niemals ändern.

@Dummschwätzer:

-C von Helmut Erlenkötter

-Ich bin noch nicht mal im Kapitel 9 (Der Präprozessor) angekommen. Das 
union befindet sich im Kapitel 14 (Komplexe Datentypen) Es wird also 
noch ein weilchen dauern.

-Wer mag denn mir nun vorsagen was zu tun ist bis ich kapiert habe was 
die Optimierung genau bedeutet und macht?

Keine Optimierung?

Eine bestimmte Optimierung?

Oder egal, hauptsache es läuft, ausprobieren welche läuft?

Vielen Dank

Ach ja: Was dem einen pillepalla ist für den anderen schon recht 
kompliziert.

@holger: Ich hatte zwischendurch für yupper und ylower unsigned char 
genommen das hat aber auch nichts gebracht. Genau genommen sehe ich es 
in meinem Anfänger-leichtsinn ähnlich wie du: Da werden 8 bit 
ausgespuckt (UART) und ob die signed sind oder nicht ist erstmal völlig 
wurscht.

@Patrick: Die Funktion receive kannst Du Dir gerne in der Codeansicht in 
meinem ersten Posting ansehen. Ich persönlich wüsste nicht wo da jetzt 
ein Problem sein sollte? Ich habe spasseshalber mal andere Optimierungen 
ausprobiert und bei manchen lief es und bei anderen nicht (Hab es nicht 
mehr so genau im Kopf)

Vielleicht hilft der nochmalige Hinweis: "yupper*255" brachte das 
gewünschte Ergebnis, "yupper<<8" nicht (Bei optimierung -Os)

Es läuft ja jetzt ohne Optimierung. Es bleibt die Frage: Wie gehe ich 
damit in Zukunft um?

@Holger: Alles klar! Ich werde das ausprobieren. Unsere Posts hatten 
sich überschnitten!

Ich muss gestehen: ich habe gerade erst in das im Eingangspost 
angehängte Sourcefile geguckt:

Du darfst natürlich nur Zuweisungen mit receive() machen, wenn Du 
tatsächlich Daten empfangen hast. Ansonsten passiert nämlich nicht 
'nichts' (wie in dem Kommentar erklärt), sondern 'return UDR;' gibt "0" 
zurück.

Quatsch! Falsch gelesen...

@Holger:

Ich hab das jetzt genau so gemacht wie Du es vorgeschlagen hast. Leider 
klappt das nicht.

Und zwar sind jetzt yupper, ylower, und receive() uint8_t.

Dies:

y = (int16_t)(((uint16_t)yupper << 8) + ylower);

läuft nur bei ausgeschalteter Optimierung.

Dies:

y=(int16_t)((yupper<<8)|ylower);

läuft bei -O0, -O2, -O3 aber nicht bei -O1 und -Os

Ich habe jetzt nochmal zum Ausprobieren yupper,ylower und receive() als 
int deklariert.

Jetzt laufen beide Varianten also:

y=(int16_t)((yupper<<8)|ylower);
und
y = (int16_t)(((uint16_t)yupper << 8) + ylower);

mit: -O0 -O2 und -O3

Aber nicht mit: -O1 und -Os

Ich habe den Eindruck das das Deklarieren der Variablen als signed oder 
unsigned hier nicht die Wurzel des Übels ist.

holger schrieb:
> Wieso muss y dann ein int16_t sein?

Weil sein Sensor einen signed-Wert liefert, siehe allerersten Satz im 
ersten Post:
> Ich habe hier ein IMU was laut Datenblatt dies ausspuckt: "16-bit 2's
> complement integers"

@Attila: Poste mal den aktuellen Code.

Weil ich mit y noch weiterrechne was übrigens auch sehr gut klappt.

Ich habe es grade ausprobiert. Alles uint_8 repektive u_int16t. Es 
klappt nicht.Bei -Os. Ohne Optimierung läuft es. Einziger Unterschied 
ist das die Rechnung mit y nicht mehr so ist wie gewünscht. 
(Logischerweise)

Bei welchem AVR ist eigentlich OCR1A & OCR1B 16Bit breit? Sicher, dass 
das stimmt? Das würde jedenfalls erklären weshalb die Multiplikation mit 
255 zu gehen scheint, aber mit 256 nicht (niederwertiges Byte ist da 
immer 0)

Es ist ein Atmega8. Ich fahre ein Modelbauservo an (daher y+14300 ergibt 
ungefähr 1,5 ms Mittelstellung des Servos) Sieht recht hübsch aus! Anbei 
wie gewünscht der aktuelle Code

Beim Atmega8, sind OCR1A&OCR1B 8Bit, dein Fehler liegt also an einer 
ganz anderen Stelle

Seite 76 das Atmega8 Datenblatts, Zitat:

"The 16-bit Timer/Counter unit allows accurate program execution timing 
(event management),
wave generation, and signal timing measurement. The main features are:
• True 16-bit Design (i.e., allows 16-bit PWM)"

Ausserdem läuft es ja ohne Optimierung ich kann mir die 16bit Auflösung 
sogar auf dem Oszi anschauen.

Der Vollständigkeit halber, Seite 79:

"The TCNT1, OCR1A/B, and ICR1 are 16-bit registers......."

Ach so Fabian, Du fragtest auch mal nach dem Sensor. Es ist ein CHR6-dm.

hab wohl A/B mit L/H verwechselt...

@Maik: Ach so! Ich war schon etwas verunsichert jetzt. Naja, sowas 
pasiert!

Bei Deinem letzten Code sehe ich jetzt keine Fehlerquellen mehr. Solange 
die Werte des Sensors zwischen -14300 und 18467 liegen, sollte es keine 
ungewöhnlichen Sprünge/Überläufe geben.

Welche Compilerversion benutzt Du denn? Vor ein paar Wochen gabs mal ein 
ähnliches Thema, da war es letztlich ein Fehler im avr-gcc aus 
AVR-Studio 5.

Ok auf die Gefahr hin dass ich hier geschlachtet werde: Wo kann ich beim 
Studio5 ersehen welche Compilerversion ich habe?

Im Studio 6 steht es unter Help -> About Atmel Studio und da im Dropdown 
AVRGCC. Aber der Hinweis auf Studio 5 reicht eigentlich schon. Versuchs 
mal mit Studio 6 oder zumindest der aktuellen Version der Toolchain.

Ok, auch wenn das etwas off topic ist jetzt: Unterstützt das Studio 6 
denn das STK500?

Mein AVRGCC hat die Version 3.3.1.27 wie ich anhand deiner Anleitung 
herausfinden konnte.

Attila Ciftci schrieb:
> Ok, auch wenn das etwas off topic ist jetzt: Unterstützt das Studio 6
> denn das STK500?

Sollte gehen.

> Mein AVRGCC hat die Version 3.3.1.27 wie ich anhand deiner Anleitung
> herausfinden konnte.

Das dürfte das Problem sein. Siehe hier:
Beitrag "Umwandlung von zwei uint8_t in uint16_t erzeugt falschen Code?"

Ach ja, weil ich gerade gelesen habe, dass Du einen Modellbauservo 
ansteuerst: Das geht mit dem 16-Bit-Timer ganz ohne Interrupt. Du musst 
einfach den Top-Wert so einstellen, dass die Periode 20 ms beträgt. Dann 
reicht es, in das Compare-Register 1/20 bis 1/10 des Top-Werts als 
Duty-Cycle reinzuschreiben. Von der Auflösung her sollte das dank 16 Bit 
genau genug für einen Servo sein.

Oh wow! Jetzt wird mir einiges klar. Ich wäre allerdings nie darauf 
gekommen nach so einem Fehler im Forum zu suchen. Wie soll man denn auf 
so etwas kommen?

Ich lade mir mal das Studio 6 runter.

Klar im Moment läuft es ja auch ohne interrupt. Die state maschine in 
meiner ISR soll aber bis zu 7 Servos steuern. Irgendwann. Mal sehen. Auf 
jeden Fall:

Vielen Dank für die Hilfe!!!

Der mögliche Fehler hat die Nummer PR46779.

Er ist behoben in 4.5.4, 4.6.2 und neueren Versionen.  Und das ist die 
GCC-Version, nicht die "Atmel-Version".

Die GCC-Version wird angezeigt mit

avr-gcc --version

Dummschwaetzer schrieb:
> Welches C-Buch? In der Regel im Kapitel Strukturen, unions,
> Aufzählungen. Siehe auch Register oder Inhaltsverzeichnis des Buches.

Dummschwaetzer schrieb:
> Helmut Herold: C Compakt Referenz
> ISBN 3-8273-1480-1, 1.Auflage 1999
> Kapitel 2.41 auf Seite 122, für dich interessant: 2.41.2 Overlay-Technik
> ... Seite 124f

Wenn das wirklich meint: Byte-Komponenten setzen und lesen einer 16-Bit 
Variablen aus der Union, dann entsorg das Buch zum Altpapier.

Der C-Standard sichert nur zu, die zuletzt geschriebene Komponente einer 
Union auch wieder auszulesen. Alle anderen Komponente der Union erhalten 
durch Zuweisung undefinierte Werte (mit Ausnahme eines ersten, allen 
Komponenten gemeinsamen Elements, i.d.R Verwendnet zur Identifikation 
des Union-Inhalts).

Konkret: In

1

unsigned compose (char a, char b)

2

{

3

    union

4

    {

5

        char byte[2];

6

        unsigned word;

7

    } u;

8

9

    u.byte[0] = a;

10

    u.byte[1] = b;

11

12

    return u.word;

13

}

Wird die Komponente .word nie geschrieben. Ein Konformer Compiler darf 
das also genau so übersetzen wie:

1

unsigned compose (char a, char b)

2

{

3

    unsigned word;

4

5

    return word;

6

}