[elektro] C aritmetika értetlenség

[Skandar Graun]

De, egyszerűbb... lesz. Csak itt most időhiányból fakadóan egy előzőleg
elkészült panel újrahasznosítása folyik.


2013. december 26. 19:54 hg12345 írta, <hg12345 at freemail.hu>:

> Hi
> nem egyszerűbb egy akármilyen hasonló kódméretű 32 bites egység, ott
> ezeket sokkal korrektebben kezelei
>
> Skandar Graun <sgraun at gmail.com> írta:
> >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]
> >-----------------------------------------
> >          elektro[-flame|-etc]
> >
>
> -----------------------------------------
>           elektro[-flame|-etc]
>