[elektro] cé típus

Topybear topybear at gmail.com
Fri May 16 10:48:03 CEST 2014


Ha beleférsz az értéktartományba... :)

Topy


Skandar Graun <sgraun at gmail.com> írta (2014. május 16. 10:36):
> Jogos... kicsit meg is zavart, más szempontból.
>
> Átállítottam a célt és a post unsigned long-ra.
> Jelenleg a cél 0x6f54
> A pos 0x5aeb
> A különbségük 0x1469
> A kijelzés 0x005f1469
>
> Átcsordítottam... a kijelzés 0x005eff8b lett.
> Ha két unsigned long-ot kivonok egymásból, akkor a signed long végeredmény
> jó lesz, nem?
>
>
>
> 2014. május 16. 10:20 Topybear írta, <topybear at gmail.com>:
>
>> E szerint a doksi szerint a PIC C18-ra is igaz, hogy a signed int
>> -32768 - 32767.
>>
>>
>> https://www.sonoma.edu/users/f/farahman/sonoma/courses/es310/lectures/c_prog.pdf
>>
>>
>> Topy
>>
>> Topybear <topybear at gmail.com> írta (2014. május 16. 10:15):
>> > Az int alapból signed szokott lenni és jellemzően -32768-32767 az
>> > értéktartomány. Az a 38000 negatív számba fordul ebben az esetben.
>> >
>> > Topy
>> >
>> > Skandar Graun <sgraun at gmail.com> írta (2014. május 16. 9:52):
>> >> pos = 9500 (0x251c)
>> >> cel = 38000 (0x9470)
>> >>
>> >>
>> >>
>> >> Amit írsz, azt elfogadom, csak a problémám pont az, hogy ebből a
>> kettőből
>> >> 0x6f54-nek kéne kijönni, bármilyen cast esetén... ehelyett 0x5f6f54
>> jött ki.
>> >> Ahogy mozog a pos, közelíti a célt, az 5f érték nem változik,
>> >> átbillenésnél, ahol a pos nagyobb lesz, mint a cél, 0x5ffff6-ra
>> változik...
>> >> nem pedig negatívra.
>> >>
>> >>
>> >> 2014. május 16. 9:43 SZIGETI Szabolcs írta, <szigiszabolcs at gmail.com>:
>> >>
>> >>> Hali!
>> >>>
>> >>> Hogy az utolsó miért nem működik, az egy jó kérdés, de megjegyzés az
>> előtte
>> >>> lévő példákhoz.
>> >>>
>> >>> Ha két int-tel végzel művelet, akkor az eredmény int lesz, minden
>> esetleges
>> >>> alul-, túlcsordulással és csonkolással. Ezt hiába rakod long-ba, nem
>> segít.
>> >>> Arra kell kényszeríteni a C fordítót, hogy eleve longokkal végezzen
>> >>> műveletet. Tehát arra vigyázz, hogy ne a kifejezés eredményét, hanem a
>> >>> tago(ka)t castold.
>> >>>
>> >>> Analóg módon a
>> >>>
>> >>> double a;
>> >>> int x=5;
>> >>> int y=2;
>> >>>
>> >>> esetében az
>> >>> a=x/y esetén a értéke 2.0 lesz, a=(double)(x/y) szintén,
>> >>> a=(double)x/y viszont a helyes 2.5 értéket fogja adni, mert nem int,
>> hanem
>> >>> float osztást fog alkalmazni.
>> >>>
>> >>> Én megnézném, hogy milyen assembly-t generál a fordító, abból
>> eldönthető,
>> >>> hogy jó-e vagy sem. Milyen konkrét értékre kaptad ezt?
>> >>>
>> >>> Szabolcs
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> 2014. május 16. 8:12 Skandar Graun írta, <sgraun at gmail.com>:
>> >>>
>> >>> > Sziasztok!
>> >>> >
>> >>> > PIC C18
>> >>> >
>> >>> > int     h1_prop_err;
>> >>> > int     huzo_1_cel;
>> >>> > int      huzo_1_pos;
>> >>> >
>> >>> > huzo_1_pos = 100;
>> >>> > huzo_1_cel = 400;
>> >>> >
>> >>> > h1_prop_err = huzo_1_cel - huzo_1_pos;
>> >>> >
>> >>> > így jó.
>> >>> >
>> >>> > De ha:
>> >>> >
>> >>> > long     h1_prop_err;
>> >>> > int     huzo_1_cel;
>> >>> > int      huzo_1_pos;
>> >>> >
>> >>> > h1_prop_err = huzo_1_cel - huzo_1_pos;
>> >>> >
>> >>> > akkor nem jó, a long változó második byte-jába bejön egy 0x5f érték
>> >>> >
>> >>> > ha:
>> >>> >
>> >>> > long     h1_prop_err;
>> >>> > int     huzo_1_cel;
>> >>> > int      huzo_1_pos;
>> >>> >
>> >>> > h1_prop_err = (long)(huzo_1_cel - huzo_1_pos);
>> >>> >
>> >>> > akkor is.
>> >>> >
>> >>> > ha:
>> >>> >
>> >>> > long     h1_prop_err;
>> >>> > int     huzo_1_cel;
>> >>> > int      huzo_1_pos;
>> >>> >
>> >>> > h1_prop_err = ((long)huzo_1_cel - (long)huzo_1_pos);
>> >>> >
>> >>> > akkor is.
>> >>> >
>> >>> > Ha kimaszkolom &0x0ffff-el, akkor eltűnik, de akkor nem tudom
>> kezelni a
>> >>> > negatív számokat.
>> >>> >
>> >>> > Mi nem jó?
>> >>> > -----------------------------------------
>> >>> >           elektro[-flame|-etc]
>> >>> -----------------------------------------
>> >>>           elektro[-flame|-etc]
>> >>>
>> >> -----------------------------------------
>> >>           elektro[-flame|-etc]
>>
>> -----------------------------------------
>>           elektro[-flame|-etc]
>>
> -----------------------------------------
>           elektro[-flame|-etc]



More information about the Elektro mailing list