Bitshift funktioniert auf AVR nicht - warum?

Du musst rechts vom Gleichheitszeichen casten....

>mithilfe des UART - die folgenden Variablenwerte
>auf dem µC:
>
>Variable: 29847

Zeig mal die Zeile wo du die Variable per UART ausgiebst.

Rufus Τ. F. schrieb:
> Der fehlende cast für i2cdata[0] dürfte das Problem sein.

sicher?

Bei Addition und Multiplikation wird doch auch immer mit dem größte 
Datentype der beiden werte gerechnet. Warum sollte da bei | anders sein?

Ich vermute, das die Variable falsch ausgeben wird.

Markus schrieb:
> Du musst rechts vom Gleichheitszeichen casten....
Was genau meinst Du damit?

Rufus Τ. F. schrieb:
> Der fehlende cast für i2cdata[0] dürfte das Problem sein.
Das hat leider nicht zum Erfolg geführt. Immer noch dieselbe Ausgabe.

holger schrieb:
> Zeig mal die Zeile wo du die Variable per UART ausgiebst.

1

char String[10];

2

itoa(Variable, String, 10);

3

uart_puts("Variable: ");

4

uart_puts(String);

>Ich vermute, das die Variable falsch ausgeben wird.

Ich auch. %ld statt %d;)

Aaaaaahhhhh, danke für den Denkanstoß!

Es muss natürlich LTOA in der Ausgabe sein und nicht ITOA...

Vielen Dank für die schnelle Hilfe, und das Entfernen des Brettes vor 
meinem Kopf. :-)

LG
Sebastian

Hallo Sebastian,

bin bei embedded C nicht so ganz zu Hause, deswegen weiß ich nicht ob 
die Entwicklungsumgebung Unions kennt,aber wenn es geht, dann würde ich 
ein Union bilden mit i2cdata[4] und int32_t Variable. Setzt man erst den 
i2cdata[4] Array und liest man die int32_t Variable aus dann hat man 
gleich den Wert ohne Schiebereien. Natürlich muss man dazu 
berücksichtigen ob little Endian oder big Endian Darstellung.

Karoly Ozvald schrieb:
> bin bei embedded C nicht so ganz zu Hause, deswegen weiß ich nicht ob
> die Entwicklungsumgebung Unions kennt,aber wenn es geht, dann würde ich
> ein Union bilden mit i2cdata[4] und int32_t Variable. Setzt man erst den
> i2cdata[4] Array und liest man die int32_t Variable aus dann hat man
> gleich den Wert ohne Schiebereien.
der schieben wird eh wegoptimiert.

> Natürlich muss man dazu
> berücksichtigen ob little Endian oder big Endian Darstellung.
und das es nicht zulässig ist unions so zu missbrauchen.

So wie er es gemacht hat es richtig.

Peter II schrieb:
> und das es nicht zulässig ist unions so zu missbrauchen.

Wieso ist das ein "Missbrauch"?

Karoly Ozvald schrieb:
> Wieso ist das ein "Missbrauch"?

weil man bei einer Union nur den Datentype lesen darf, den man 
geschrieben hat. Das es meist auch so funktionierst ist nicht durch den 
Standard abgedeckt.

type punning ist in (explizit) C erlaubt. Wobei die Frage ist, ob das 
passiert, was man erwartet. Das ist meistens nur dann der Fall, den 
zu/von einem char-Array gewandelt wird.

In C++ ist das des des nicht-aktiven Members UB!

Scott Meyers schrieb:
> type punning ist in (explizit) C erlaubt. Wobei die Frage ist, ob
> das
> passiert, was man erwartet. Das ist meistens nur dann der Fall, den
> zu/von einem char-Array gewandelt wird.
>
> In C++ ist das des des nicht-aktiven Members UB!

Typo: In C++ ist das Lesen des nicht-aktiven Members UB!

Peter II schrieb:
> weil man bei einer Union nur den Datentype lesen darf, den man
> geschrieben hat

Das weicht jetzt vom ursprünglichen Thema ab, aber:
Wenn es so ist wie du geschrieben hast, dann wozu eine Union, wenn ich 
auf die andere Variable nicht einmal lesend zugreifen darf? Union 
verwendet man wenn man auf einen Speicherbereich auf unterschiedliche 
Weise zugreifen möchte.

Die vielleicht einzige sinnvolle Anwendung einer Union ist die implizite 
Typumwandlung, und ist vielleicht ungewöhnlich aber ich sehe das nicht 
außerhalb vom C Standard, schließlich ist die Union nicht meine 
Erfindung.

Scott Meyers schrieb:
> In C++ ist das des des nicht-aktiven Members UB!

Das stimmt nicht so wirklich ... zumindest nicht allgemein für alle 
unions bzw. alle Zugriffe.
Aus dem c++17 draft (N4687 §12.2.24)

1

In a standard-layout union with an active member (12.3) of struct type T1,

2

it is permitted to read a non-static data member m of another union member of

3

struct type T2 provided m is part of the common initial sequence of T1 and T2;

4

the behavior is as if the corresponding member of T1 were nominated.

5

[ Example:

6

struct T1 { int a, b; };

7

struct T2 { int c; double d; };

8

union U { T1 t1; T2 t2; };

9

int f() {

10

U u = { { 1, 2 } }; // active member is t1

11

return u.t2.c; // OK, as if u.t1.a were nominated

12

}

13

— end example ]

> Offensichtlich verhält sich itoa() in der avr-lib anders als
> in der Libary für Windows.

Weil unter Windows ein int 32bit ist und unter AVR nur 16bit.

Bei Assembler kann man höchstens den Fehler machen, dass man nicht

lsl
rol

schreibt, sondern als Anfängerfehler

lsl
lsl

Ich glaube das wars mit Fehlerquellen.

Wenn man das mal im Hinterkopf hat und dann sich die Beiträge hier über 
mir durchliest, muss man sich ja schon an den Kopf fassen, was man alles 
wissen muss, nur um in C ein Shifting korrekt auszuführen.

Timmy schrieb:
> Bei Assembler kann man höchstens den Fehler machen, dass man nicht
>
> lsl
> rol
>
> schreibt, sondern als Anfängerfehler
>
> lsl
> lsl

Das passiert aber nur, wenn man sich nie mit den dahinter stehenden 
Abläufen in den Registern beschäftigt, sondern blind irgendwelche 
Befehle eintippt.

mh schrieb:
> Scott Meyers schrieb:
>> In C++ ist das des des nicht-aktiven Members UB!
>
> Das stimmt nicht so wirklich ... zumindest nicht allgemein für alle
> unions bzw. alle Zugriffe.
> Aus dem c++17 draft (N4687 §12.2.24)
...
> [ Example:
> struct T1 { int a, b; };
> struct T2 { int c; double d; };
> union U { T1 t1; T2 t2; };
> int f() {
> U u = { { 1, 2 } }; // active member is t1
> return u.t2.c; // OK, as if u.t1.a were nominated
> }
> — end example ]

Das stimmt zwar, aber dabei geht es um die "common inital sequence". In 
dem Beispiel "wandelt" man also das int member a in das int member c. 
Und das ist nicht das, was hier ursprünglich mal angedacht war und 
allgemein als "type punning" bezeichnet wird. Um das zu erreichen, müßte 
man ausserhalb der common initial sequence zugreifen, und das ist eben 
in C++ UB.

Carl D. schrieb:
> Echt?
> Der Fehler lag aber in der Benutzung von itoa() statt ltoa().
> Wie schreibt man die beiden nochmal in Assembler?

Ganz einfach. Für 16 bit Werte schreibt man

rcall bin16dec

und für 32 Bit Werte schreibt man

rcall bin32dec

es gibt noch

rcall bin64dec

aber so hohe Zahlen habe ich auf dem AVR noch nie benötigt. Steht alles 
in der Doku.

Genauso wenig wie ein itoa(). Aber hier ging es letztendlich auch um 
Diskussionen über Speicherverbrauch, wo dann die Raterei losging, wie es 
C intern wohl umsetzt und wenn ich dann mir sowieso das ASM Listing 
ausgeben lasse, also eh wieder letztendlich bei Assembler gelandet bin, 
warum dann nicht gleich da bleiben?

Aber es stimmt schon, dass es wirklich hilfreich gewesen wäre, wenn es 
sowas wie eine grosse Lib für den AVR gäbe, wo all die schönen Sachen, 
die C bietet, schon mit drin sind. Bei C ist es ja auch nur eine Lib. 
Wie gesagt bietet itoa() kein Prozessor direkt an.

Du verfällst in Verallgemeinerungen. Wenn der eigene Job ist, eher 
kleine Aufgaben zu bewältigen, wie Motorsteuerungen oder 
Sicherheitsschaltungen, wo Einfachheit geradezu vorgeschrieben ist, da 
ist Assembler einfach die bessere Wahl, eben weil es keine bösen 
Überraschungen gibt, weil man genau weiss, was passiert.

Für Programme wie
IF spicmd == "open"
AND PinX == HIGH
AND adcvalue > 500
AND PinY == LOW
THEN PinY = LOW

braucht man kein C. Ich würde aber auch kein neues Mobile OS in 
Assembler schreiben wollen und auch keine Assemblerprogramme für einen 
normalen PC, weil es einfach sinnfrei ist.

Timmy schrieb:
> Wenn der eigene Job ist, eher
> kleine Aufgaben zu bewältigen, wie Motorsteuerungen oder
> Sicherheitsschaltungen, wo Einfachheit geradezu vorgeschrieben ist, da
> ist Assembler einfach die bessere Wahl, eben weil es keine bösen
> Überraschungen gibt, weil man genau weiss, was passiert.

Es sei denn man hat irgendwo ein "pop" vergessen, dann viel Spaß beim 
Suchen. Das passiert in C eher nicht. Motorsteuerungen wie z.B. bei 
PKW-Steuergeräten oder große Synchronmaschinen werden hauptsächlich in 
Matlab und C geschrieben. Kein Hersteller würde sich bei so einem 
Produkt mithilfe von Assembler auf eine einzige Prozessor-Architektur 
festnageln.

Btw, wenn man mit -Wconversion kompilieren würde, hätte es bei "itoa" 
eine Warnung gegeben.