[elektro] C aritmetika értetlenség

[Skandar Graun]

huzo_1_pos = ((long*)&sbuffer[3])[0] & 0xFFFFFF

Ez lett az első bemásolt és működik.
Köszönöm. Valahol én is a castolásra gyanakodtam, csak nem volt konkrét
ötletem. A shiftelést próbáltam, ott ki is kergette belőle az adatot, ott
is castolni kell.
A uC pic18f8722, 40 megán járatva, a feladatra egyébként megfelelne... csak
a bájtonkénti eléréssel még nem vagyok teljesen rendben. A
generictypedefs.h ad rá megoldást, csak utána megint olyan hibaüzenetek
vannak, amikkel még nem küzdök.
Majd... :)


2013. december 26. 14:00 hg12345 írta, <hg12345 at freemail.hu>:

> Szia
>
> huzo_1_pos = 65536ul*sbuffer[5] + 256ul*buffer[4] + (unsigned long)
> sbuffer[3];
>
> Vagy a konstansokat "cast"-old vagy sbuffer elemeit,
> a probléma szerintem az, hogy a konstansok ha nem jelölöd akkor signed,
> így az automatikus cast-olás miatt az eredmény signed lesz, így jogos az
> előjel kiterjesztés....
> Sajnos ilyen esetben még az optimalizációtól is függhet tapasztalatom
> szerint ez eredmény :-(
>
> Ha nem akarsz előjel kiterjesztést, (szerintem ez a korrektebb)
> huzo_1_pos = sbuffer[5]<<16 | buffer[4]<<8  | sbuffer[3];
> ebben az esetben azt csinálja és pont úgy csinálja ahogy csinálnad
> ASM-ben, ilyenkor mindig a saját előjelét örökli az eszköz. Érdemes
> megnézni a fordítási eredményt, mert a lehet hogy a shiftelés elött
> cast-olni kell, mert ha ki shifteli az ábrázolási  tartományból akkor nulla
> lesz.
>
> de ennél sokkal egyszerűbb, csak tudni kell az endian irányt. (elvileg ez
> a legtömörebb....) ez ugyan az mint az előző...
> huzo_1_pos = ((long*)&sbuffer[3])[0]  & 0xFFFFFF
>
> az &0xFFFFFF helyett használható
> ((unsigned char*)&huzo_1_pos)[3]=0; is ez gyorsabb és tömörebb lehet mint
> a &0xFFFFFF :-)
>
> Azért ezek nem igazán fekszenek a kis uC-nek. :-)
>
> üdv
>
>
>
> Skandar Graun <sgraun at gmail.com> írta:
> >Sziasztok!
> >
> >Nem teljesen értem a problémát, ezért hozzátok fordulnék.
> >A kérdéses fordító C18
> >
> >Adott egy tömb,
> >unsigned char sbuffer[16];
> >Ebbe sorosan jönnek be az adatok.
> >Ebből csinálnék én egy long változót, nem akartam bűvészkedni az
> >unionokkal, structokkal.
> >
> >unsigned long huzo_1_pos;
> >
> >huzo_1_pos = 65536*sbuffer[5] + 256*sbuffer[4] + sbuffer[3];
> >
> >A probléma a következő:
> >A bejövő adat sor: 0x20, 0x7f, 0xff
> >
> >Erre a húzó_1_pos: 0xffff7f20
> >
> >Eddig jó (bár a legelső ff kissé furcsa)
> >De ha a bejövő adat: 0x2e; 0x82, 0xff
> >
> >Akkor a művelet végerdeménye: 0xfffe822e
> >
> >Olyan, mintha az alsó 16 bites adat legmagasabb bitjének 1 értéke esetén
> >egyet levonna a következő fél értékéből. Ezt elég stabilan tudja más
> >értékeknél is.
> >A kiíratás egyszerű:
> >
> >sprintf(data1,"%8lx",huzo_1_pos);
> >putsXLCD(data1,1);
> >
> >Valami aritmetikai nemtudommi az oka, csak nem értem, ennek köszönhetően
> >nem is tudom elhárítani. Tüneti kezelést meg nem akarok alkalmazni.
> >-----------------------------------------
> >          elektro[-flame|-etc]
> >
>
> -----------------------------------------
>           elektro[-flame|-etc]