[elektro] cé típus

[Skandar Graun]

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