mikrocontroller.net

Forum: Compiler & IDEs fehlende Rechenschritte in listfile aus C


Autor: Nicky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

bisher war Assembler meine bevorzugte Variante meine Controller zu 
programmieren. Seit einer Woche "quäle" (aller Anfang ist schwer) ich 
mich mit C (AVR Studio mit WINAVR) herum. Bisher klappte bis auf 
kleinere Anfangschwierigkeiten alles bestens.

Nun wollte ich eine Routine einfügen, doch komischer Weise werden in 
dieser Befehle übersprungen? Das verstehe ich nun überhaupt nicht. Eine 
Fehlermeldung kann ich nicht erkennen.

Hier mal das Fragment:
{
unsigned int i;

i= ((ucMaxUserPreset * 4) + ((event_chart[3] - 1) * 65) );
                              
 /*Wait for completion of previous write */
while(EECR & (1<<EEPE));

/* Set up address register */
EEAR   = i;
  
/* Start eeprom read by writing EERE */
EECR   |= (1<<EERE);

/*unsigned char j;
j  = EEDR;
j  = (~j);
j++;
j  = (j / 10);

SPDR = DISPL_NR_CODE[j];  */


SPDR  = DISPL_NR_CODE[(((~EEDR)+1)/10)];
}

In der letzten Zeile kommt nur Käse heraus, dort soll ein Byte aus dem 
EEProm geholtenwerden. Der Wert soll für die 10-er Stelle für eine 7 
Segmentanzeige berechnet und ausgegeben werden. In DISPL_NR_CODE steht 
lediglich die Codierung dafür, diese funktioniert auch in anderen 
Routinen bestens.
Da dies nun nicht funktioniert, habe ich versucht alles in 
Einzelschritten zu machen ( jetzt auskommentierter Teil über der SPDR  = 
- Anweisung) aber dort liesst er nur den Wert aus dem EEPROM, die 
Invertierung, das Increment und die Teilung werden übersprungen (sind im 
Assembler-File oder List-File auch nicht zu finden.

Kann mir hierzu mal jemand einen Tip geben? Ich weiss nicht mehr 
weiter!!!
Vorab schon einmal vielen Dank!!!

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

Bewertung
0 lesenswert
nicht lesenswert
Ist nicht nachvollziehbar.  Ich habe aus deinem copy&paste-Teil mal
ein Stück in sich compilierfähigen Code gebaut:
#include <avr/io.h>

void readeeprom(uint8_t i, uint8_t j)
{
 /*Wait for completion of previous write */
 while(EECR & (1<<EEPE));

 /* Set up address register */
 EEAR   = i;
  
 /* Start eeprom read by writing EERE */
 EECR   |= (1<<EERE);

 SPDR = j;  */


 SPDR  = (((~EEDR)+1)/10);
}

danach einen ATmega88 als Prozessor erraten und es durch den
Compiler geschickt.  Hier der generierte Assemblercode:
.global readeeprom
        .type   readeeprom, @function
readeeprom:
/* prologue: frame size=0 */
/* prologue end (size=0) */
.L3:
        sbic 63-0x20,1
        rjmp .L3
        clr r25
        out (65)+1-0x20,r25
        out 65-0x20,r24
        sbi 63-0x20,0
        in r24,64-0x20
        clr r25
        ldi r22,lo8(-10)
        ldi r23,hi8(-10)
        rcall __divmodhi4
        out 78-0x20,r22
/* epilogue: frame size=0 */
        ret
/* epilogue end (size=1) */

Die bitweise Negation und anschließende Addition entspricht einer
numerischen Negation.  Die hat der Compiler dadurch ersetzt, dass
er den Divisor der Division von 10 auf -10 geändert hat.  Aber die
Division selbst ist gut zu erkennen.

p.s.: <avr/eeprom.h> kennst du aber, ja?

http://www.nongnu.org/avr-libc/user-manual/group__...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tu dir selbst einen Gefallen und verwende die fertigen EEPROM Lese 
Funktionen. Jede Wette, dass der Optimizer einen Weg gefunden hat, dass 
sich EEDR seiner Meinung nach nicht verändert, von dort also j immer den 
gleichen Wert erhält und daher der Rest wegfallen kann. Irgendsowas in 
der Richtung

#include <avr/eeprom.h>

...

void foo()
{
  unsigned int i;
  unsigned char j;

  i = ((ucMaxUserPreset * 4) + ((event_chart[3] - 1) * 65) );

  j = eeprom_read_byte( i );

  SPDR = DISPL_NR_CODE[j];
}

Zumindest für gewisse Basisfunktionalität kriegst du vom WinAvr 
Unterstützung. Überflieg das Avr-Gcc-Tutorial um zumindest zu wissen, in 
welchen Bereichen du das Rad nicht neu erfinden musst.

Autor: Nicky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo und DANKE für die schnelle Antwort, aber so richig verstanden habe 
ich es trotzdem noch nicht, denn im restlichen Code greife ich wie 
beschrieben x mal mit lesen und schreiben so auf den EEprom zu und es 
klappt.

hmmm....

@Jörg Wunsch:
stimmt, es ist ein Mega88 "grübel" und <avr/eeprom.h> schau ich mir 
gleich an :-( obwohl der zugriff auf das eeprom super funktioniert. also 
die daten liesst er bestens aus, nur die wertewandlung dahinter macht 
mir sorgen.

@Karl heinz Buchegger
so einfach geht es leider bei mir nicht. bei mir ist der EEPROM-wert das 
invertierte von dem was ich benötige, einfach weil der eeprom 0xff ab 
werk ist, aber für mich als 0x00 zählt. demnach kann dort später einmal 
ein wert stehen, der invertiert dezimal z.B. 24 ergibt, dieser muss um 1 
erhöht werden und an dieser stelle die 2 für die 10-er stelle ergeben, 
in einem anderen fragment habeich das gleiche problem für die einer 
stelle also nicht i / 10 sondern i % 10 - bisher wie gesagt ging alles 
super - nur hier nicht mehr.


------
ich versteh auchnicht was der gute dort wegoptimieren will, und warum 
erst recht nicht, aber die optimierung ist tatsächlich an. ich glaube 
bis ich das verstehe, werdn noch ein paar wochen ins land gehen.

Autor: Nicky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

cih habe es jetzt so gelöst, er kann da scheinbar nichts weg optimieren, 
dafür brauch ich 2 register.

[c]

{
unsigned char j;
unsigned char k;

j  = EEDR;
k  = (~j);
j  = k +1;
k  = (j % 10);
SPDR  = DISPL_NR_CODE[k];
}

und schon bekomme ich das richtige angezeigt!

ich würde aber schon gern wissen, woran das liegt! vielleicht kann sich 
ja jemand erbarmen, denn mit meinen 2 C-Büchern und dem GCC Tutorial 
komm ich da nicht auf einen grünen Zweig.

VG

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

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mich erbarmt, und kann dein Problem nicht nachvollziehen,
wie ich oben schon schrieb.

Du musst also wohl oder übel mehr an Details rüberwachsen lassen,
insbesondere:

. eine compilierbare(!) minimale Version des Codes, der das Problem
  verursacht, und

. Informationen über deinen Compiler/deine Umgebung.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicky wrote:

> so einfach geht es leider bei mir nicht.

Doch, ist es.
Benutz einfach die eeprom_read_byte anstelle das du da selbst was 
erfindest. Zum Beispiel stört mich an deinem Beispiel, dass du zwar das 
Bit setzt um mit dem Lesen anzufangen, aber nicht abwartest, bis das 
EEPROM die Werte rausgesucht hat :-)

> bei mir ist der EEPROM-wert das

> stelle also nicht i / 10 sondern i % 10 - bisher wie gesagt ging alles
> super - nur hier nicht mehr.

Dann rechne eben den Wert aus dem EEPROM entsprechend um.

Autor: Nicky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Karl heinz Buchegger

genau das mache ich doch, die eeprom routine ist exact die aus dem 
datenblatt des mega88. das j = EEDR gibt mir auch den richtigen wert.

aber die 3 anweisungen zwischen j = EEDR und der ausgabe SPDR = .... die 
machen nichts, oder besser gesagt, die gibt es im assebler dann nicht 
mehr und beim single step im c-code sind die auch nur schmuck ohne 
wirkung. :-) also die eepromzurgriffe funktionieren. aber trotzdem lass 
ich mich gern belehren und mich auf optimaler lösungen führen. deshalb 
danke.

€ Jörg Wunsch
ich bastle gerade an einer version, die sich auf das nötigste beschränkt 
und hoffe das dort dann der fehler auch auftritt - kann aber noch ein 
wenig dauern, denn der µC ist breits mit 50% voll und das muss ich ja 
nicht alles mitschicken.

Zu compiler und umgebung:

WinXP, AVR Studio 4.16 build 628 mit WinAVR vom 05.12.2008! controller 
ist ein mega88, clock 20Mhz, Optimierungseinstellung -0s

der rest folgt später!

Autor: Nicky (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, weiter kürzen geht kaum noch, sonst wird es zu undurchsichtig denke 
ich, wird es so schon sein, denn ich lerne noch, also immer ran mit den 
verbesserungsvorschlägen. der fehler tritt in "displ_mux.c" auf, der 
bereicht mit den 3 varianten ist markiert und auch das verhalten steht 
dabei.

ausserdem so ist es in C:
unsigned char j;

j  = EEDR;    // <--- funktioniert
              
j  = (~j);    // berechnung erfolgt nicht
j  = j +1;    // berechnung erfolgt nicht
j  = (j % 10);  // berechnung erfolgt nicht
              
SPDR  = DISPL_NR_CODE[j];  // <--- funktioniert


und dies wird daraus im Disassembler:
165:                    EEAR   = i;
+000000F6:   BD92        OUT       0x22,R25       Out to I/O location
+000000F7:   BD81        OUT       0x21,R24       Out to I/O location
168:                    EECR   |= (1<<EERE);
+000000F8:   9AF8        SBI       0x1F,0         Set bit in I/O register
199:
  j  = EEDR;    // <--- funktioniert
+000000F9:   B580        IN        R24,0x20       In from I/O location
207:
  SPDR  = DISPL_NR_CODE[j];  // <--- funktioniert
+000000FA:   9581        NEG       R24            Two's complement
+000000FB:   E06A        LDI       R22,0x0A       Load immediate
+000000FC:   D1D6        RCALL     PC+0x01D7      Relative call subroutine
+000000FD:   01FE        MOVW      R30,R28        Copy register pair
+000000FE:   0FE9        ADD       R30,R25        Add without carry


und s wie ich das sehe, sind die 3 Anweisungen zwischen
j = EEDR; und SPDR = .....   nicht wirklich vorhanden.

die kurzform als einzeilige anweisung verhält sich gleich!
die lange forn mit j und k variablen funktioniert!

Ich bin ein wenig gespannt, was ich dort versaut habe!?

VG

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicky wrote:

> und s wie ich das sehe, sind die 3 Anweisungen zwischen
> j = EEDR; und SPDR = .....   nicht wirklich vorhanden.

Sie sind nur als Kommentar nicht vorhanden (weil der Disassembler die 
Zuordnung wohl nicht hin bekommt). Als Assembler-Code sind sie da.

j  = (~j);
j  = j +1;
 wird zusammen zu
+000000FA:   9581        NEG       R24            Two's complement

und
j  = (j % 10);
wird zu
+000000FB:   E06A        LDI       R22,0x0A       Load immediate
+000000FC:   D1D6        RCALL     PC+0x01D7      Relative call subroutine

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch was:
Wenn ich mir deine Postings so anschaue, dann ist es mal "/10" und mal 
"%10". Könnte das vielleicht der Grund sein, warum es mal geht und mal 
nicht? ;-)

Autor: Nicky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan Ernst,

nein, das ich mal / und mal % liegt daran, das ich die gleiche abfolge 
in 2 routinen haben, einmal die 10-stelle und einmal die 1-er stelle 
eines 7 segment display, demnach einmal / 10 und einmal rest (modulo). 
aber trotzdem danke für deine mühe!

hmm, du meinst also im disassembler werden die zuordnungen durcheinander 
gehauen? aber nichts desto trotz kam trotzdem müll bei der berechnung 
heraus - ich hab es ja auch auf dem display sehen können und im single 
step in C werden die zeilen auch gnadenlos übersprungen.

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

Bewertung
0 lesenswert
nicht lesenswert
Nicky wrote:

> genau das mache ich doch, die eeprom routine ist exact die aus dem
> datenblatt des mega88.

Karl Heinz hatte dir allerdings (genau wie ich schon weiter oben)
nahe gelegt, dass du stattdessen die Routinen aus der avr-libc
(aus <avr/eeprom.h>) benutzt.

Ansonsten hast du 1.) nach wie vor noch kein compilierbares
Beispiel geliefert (ich möchte mir gern den Assemblercode angucken,
den mein Compiler draus macht, nicht den blöden Disassembler vom
AVR Studio mit seinen unsinnigen Kommentaren und fehlenden symbolischen
Adressen), zweitens hat dein Disassembler-Listing aber trotzdem
gezeigt, dass beide Rechenoperationen da sind -- auch wenn der
Compiler die Rechnung anders gelöst hat als du.

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

Bewertung
0 lesenswert
nicht lesenswert
Nicky wrote:

> aber nichts desto trotz kam trotzdem müll bei der berechnung
> heraus

Dann solltest du wohl als nächstes erst einmal überdenken, ob denn
dein Algorithmus überhaupt hinhaut...

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicky wrote:

> und im single
> step in C werden die zeilen auch gnadenlos übersprungen.

Ja, logisch, weil, wie gesagt, der Disassembler den C-Code nicht dem 
Assembler-Code zuordnen kann.

> aber nichts desto trotz kam trotzdem müll bei der berechnung
> heraus - ich hab es ja auch auf dem display sehen können

Der Assembler-Code entspricht jedenfalls deinen C-Vorgaben.

Autor: Nicky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg Wunsch

ich hab ja eine losung, mit 2 variablen geht es ja, nur würde mich 
interessieen, warum es nicht mit einer klappt - ist halt reines 
interesse, und vielleicht gibt es einen guten grund. mit j und k ist ja 
alles prima, ich hatte mich nur dran gewöhnt, alles in eine anweisung zu 
packen. im endeffekt ändert sich ja an der abarbeitung nicht wirklich 
viel - denn diese routine wird nur bei einem tastendruck durchlaufen und 
nicht ständig.

aber aus fehlern lernt man - und wenn es einer ist, wüsste ich schon 
gern wo er steckt.

trotzdem allen vielen dank!

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicky wrote:

> ich hab ja eine losung, mit 2 variablen geht es ja, nur würde mich
> interessieen, warum es nicht mit einer klappt - ist halt reines
> interesse, und vielleicht gibt es einen guten grund. mit j und k ist ja
> alles prima, ich hatte mich nur dran gewöhnt, alles in eine anweisung zu
> packen. im endeffekt ändert sich ja an der abarbeitung nicht wirklich
> viel - denn diese routine wird nur bei einem tastendruck durchlaufen und
> nicht ständig.

Alles in eine Anweiung zu packen ist kein Problem, und oben seh ich 
nirgends einen falschen Code.

> aber aus fehlern lernt man - und wenn es einer ist, wüsste ich schon
> gern wo er steckt.

Hier würde ein kleiner Testfall helfen, d.h. ein Stück Code, der sich 
ohne Compiler-Fehler compilieren lässt.

Bei deinem obigen Code kommt zB ein
foo.c: In function 'foo':
foo.c:12: error: 'DISPL_NR_CODE' undeclared (first use in this function)
nachdem man das ganze in ne Funktion gepackt hat.

Geht man von folgenden Testfällen aus
#include <avr/io.h>

extern unsigned char DISPL_NR_CODE[];

void foo1 ()
{
    unsigned char j;
    unsigned char k;

    j  = EEDR;
    k  = (~j);
    j  = k +1;
    k  = (j % 10);
    SPDR  = DISPL_NR_CODE[k];
}

void foo2 ()
{
    SPDR  = DISPL_NR_CODE[((~EEDR)+1) % 10];
}

dann ergibt sich i.W. folgendes Kompilat (mit -S)
foo1:
  in r24,64-32
  neg r24
  ldi r22,lo8(10)
  rcall __udivmodqi4
  ldi r30,lo8(DISPL_NR_CODE)
  ldi r31,hi8(DISPL_NR_CODE)
  add r30,r25
  adc r31,__zero_reg__
  ld r24,Z
  out 78-32,r24
  ret

foo2:
  in r24,64-32
  ldi r25,lo8(0)
  com r25
  neg r24
  sbci r25,lo8(-1)
  ldi r22,lo8(10)
  ldi r23,hi8(10)
  rcall __divmodhi4
  movw r30,r24
  subi r30,lo8(-(DISPL_NR_CODE))
  sbci r31,hi8(-(DISPL_NR_CODE))
  ld r24,Z
  out 78-32,r24
  ret

Die zweite Version unterscheidet sich von der ersten durch einen 
(impliziten) Cast aufgrund des C Sprachstandards. Vielleicht liegt darin 
ein Problem, daß einmal mit 8 Bit gerechnet wird und einmal mit 16 Bit?

Optionen waren:
 ;  GNU C (WinAVR 20090313) version 4.3.2 (avr)
 ;   compiled by GNU C version 3.4.5 (mingw-vista special r3), GMP version 4.2.3, MPFR version 2.4.0.
 ;  GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32702
 ;  options passed:  -fpreprocessed foo.i -mmcu=atmega88 -Os 
 ;  -std=gnu99 -fverbose-asm -fpack-struct -fno-reorder-functions
 ;  -fno-builtin -fno-keep-inline-functions -fno-common
 ;  -fno-inline-small-functions -fno-tree-scev-cprop

Johann

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicky wrote:
> @ Karl heinz Buchegger
>
> genau das mache ich doch,

Wo machst du das?

Dein Code in Pseudocode

    Warte bis das EEPROM eine mglw. vorhergehende Operation
    abgeschlossen hat

    Stell die Adresse ein

    Gib den Lesebefehl

    Hol den Wert aus dem EEDR Register


Wo wartest du nach dem geben des Lesebefehls, das der angeforderte Wert 
tatsächlich im EEDR Register angekommen ist?

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

> Wo wartest du nach dem geben des Lesebefehls, das der angeforderte Wert
> tatsächlich im EEDR Register angekommen ist?

Man muss nicht warten.

Datenblatt:
The EEPROM Read Enable Signal EERE is the read strobe to the EEPROM.
When the correct address is set up in the EEAR Register, the EERE bit
must be written to a logic one to trigger the EEPROM read.
The EEPROM read access takes one instruction, and the requested data is
available immediately. When the EEPROM is read, the CPU is halted for four
cycles before the next instruction is executed.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Ernst wrote:
> Karl heinz Buchegger wrote:
>
>> Wo wartest du nach dem geben des Lesebefehls, das der angeforderte Wert
>> tatsächlich im EEDR Register angekommen ist?
>
> Man muss nicht warten.

Ehrlich?

[Datenblatt rauskram, Tutorial rauskram]

tatsächlich!

Bin schon still. War ein Fehler meinerseits.

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

Bewertung
0 lesenswert
nicht lesenswert
Johann L. wrote:

> Die zweite Version unterscheidet sich von der ersten durch einen
> (impliziten) Cast aufgrund des C Sprachstandards. Vielleicht liegt darin
> ein Problem, daß einmal mit 8 Bit gerechnet wird und einmal mit 16 Bit?

Ja, den Eindruck habe ich mittlerweile auch.

Wenn ich den Ausdruck
(((~EEDR)+1)/10)

umschreibe in
((uint8_t)((~EEDR)+1)/10)

dann bekomme ich den exakt gleichen Assemblercode wie für die Variante
mit den zwei zusätzlichen Variablen.  Die Benutzung der Zwischen-
variablen wirkt wie ein typecast auf (uint8_t) für die einzelnen
Teilschritte.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Johann L. wrote:
>
>> Die zweite Version unterscheidet sich von der ersten durch einen
>> (impliziten) Cast aufgrund des C Sprachstandards. Vielleicht liegt darin
>> ein Problem, daß einmal mit 8 Bit gerechnet wird und einmal mit 16 Bit?
>
> Ja, den Eindruck habe ich mittlerweile auch.

Möglicherweise wegen des sign-extend? Damit landen Zwischenwerte > 127 
im Nirvana...

Johann

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... (impliziten) Cast ... sign-extend ...

Ich möchte bei diesen Überlegungen nur zu bedenken geben, dass der 
Mehrzeiler mit einer Variablen ja angeblich auch nicht funktionieren 
soll.

Autor: Nicky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Karl heinz Buchegger Datum: 16.03.2009 21:27

------------------------------------------------------------------------ 
--------
Nicky wrote:
> @ Karl heinz Buchegger
>
> genau das mache ich doch,


>@ Karl heinz Buchegger
>Wo machst du das?

>Dein Code in Pseudocode

>    Warte bis das EEPROM eine mglw. vorhergehende Operation
>    abgeschlossen hat
/* Wait for completion of previous write */
while(EECR & (1<<EEPE));

>    Stell die Adresse ein
/* Set up address register */
EEAR = i;


>    Gib den Lesebefehl
/* Start eeprom read by writing EERE */
EECR |= (1<<EERE);

>    Hol den Wert aus dem EEDR Register
j  = EEDR;

>Wo wartest du nach dem geben des Lesebefehls, das der angeforderte Wert
>tatsächlich im EEDR Register angekommen ist?

Der Wert steht nach
 EECR |= (1<<EERE); 
 nach 4 Takten im EEDR, im Disassembler dauert es auch tasächlich so 
lange, bis er die folgenden Schritte durchführt.

> Auszug aus dem Datenblatt des Mega88 Seite 18:
When the EEPROM is read, the CPU is halted for four clock cycles before 
the next instruction is
executed.

Zumal ich noch einmal betonen möchte, es wird der richtige Wert 
ausgelesen!!! und dies x-fach auch in anderen Abschnitten nach gleichem 
Schema. Es mag vielleicht nicht sonderlich Schick sein, o.k. und ich 
gelobe mich zu bessern, wenn ich verstanden habe warum. Aber das EEprom 
lesen und schreiben macht mir keinerlei sorgen.

Autor: Nicky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Johann L. , @ Jörg Wunsch & @Stefan Ernst

>impliziter Cast ???


Cast-Operator habe ich schonmal gehört. hmmm
ok, ich werd mal schauen was ich dazu finde --> momentan versteh ich nur 
bahnhof.

Danke euch allen!

Autor: Nicky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
impliziter Cast?

typumwandlung während der berechnung - hab ich es richtig?

wenn ja nur wo und warum?

ich lese aus dem eeprom

>0xFF

da dies bei mir 0 entspricht --> complement bilden, aber dabei sollte 
unsingned char doch auch dies bleiben?

jetzt sollte also aus 0xFF

>0x00 -> geworden sein

dann 0x00 + 1 weil ich den folgenden Step benötige dort sehe ich 
eigentlich auch keinen Grund für eine typumwandlung.

>0x01

und davon bilde ich division durch 10 und im andere Teil rest von der 
Division

-> also
/10
 = 0
-->
%10
 = 1

da ich j als unsigned char und nicht als signed verwende - versteh ich 
also nicht, wo da eine typumwandlung stattfinden soll.

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

Bewertung
0 lesenswert
nicht lesenswert
Nicky wrote:

> ich lese aus dem eeprom
>
>>0xFF
>
> da dies bei mir 0 entspricht

Nun, es ist aber hier 255, d. h. durch die Umwandlung nach Typ
int (die implizit durch C vorgegeben ist), wird daraus ein 0x00FF.

Das negierst du bitweise, also 0xFF00.  Danach addierst du 1, also
0xFF01.  Das ist das Bitmuster der Zahl -255.  Die teilst du durch
10, das ergibt eine -25, oder 0xFFE7.  Davon nimmst du das untere
Byte, also 0xE7, oder 231, wenn man es als uint8_t betrachtet.

Was du dagegen willst ist, dass aus der 0xFF eine 0x00 wird, zu
dieser 1 addiert (=> 0x01), und durch 10 dividiert, ergibt 0.

> da ich j als unsigned char und nicht als signed verwende - versteh ich
> also nicht, wo da eine typumwandlung stattfinden soll.

Weil C immer wenigstens im Bereich `int' rechnet.

Den Typecast, den du brauchst, habe ich dir oben schon gezeigt:

Beitrag "Re: fehlende Rechenschritte in listfile aus C"

Autor: Nicky C. (nicky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> Weil C immer wenigstens im Bereich `int' rechnet.

Na das ist doch eine Aussage - die verstehe sogar ich und verstehe dann 
auch, warum da Käse herauskommen muss! Ich wusste dies nicht und werd es 
gleich mal ausprobieren. Ich wollte zwar
#include <stdint.h>

nicht verwenden, aber dann werde ich mal einiges ändern.

Ich hoffe es funktioniert dann und bedanke mich für die Erklärung und 
eure Mühen!

Ich hoffe ich kann mich mal wieder revanchieren, zwar sicher nicht in 
naher Zukunft bei GCC aber viellecht im Elektronikteil.

VG

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.