[elektro] C aritmetika értetlenség

[Skandar Graun]

Ja, még mielőtt elfelejtem: Köszönöm.


2013. december 26. 18:36 Skandar Graun írta, <sgraun at gmail.com>:

> 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]
>
>
>