[elektro] cé típus

[hg12345]

A signed és unsigned erőteljesen más számítással dolgozik, ne keverd.
Ha mégis szükséges, akkor cast-olás előtt vizsgálni kell hogy elfér a helyén, mert a C nem támogatja az ilyen az átváltásokat, csak levágja.... ill. áttölti az aritmetikai figyelés a uC/uP tulajdonsága ha megírod, akkor kezeli (de ha jelzi a hibát mit érsz vele....?)  ha nem akkor olyan amilyen.
A másik ha már cast-olni kell, akkor célszerű mindig kiírni (magad megcsinálni) mert az automatikus cast nem megbízható, függ a fordító program verziójától, az optimalizáció szintjétől és hogy hány éves kapitány.



Skandar Graun <sgraun at gmail.com> írta:
>Csak a szabályozáshoz van szükségem előjelesre.
>A pozíciókhoz nincs.
>Bár igaz, a fele is elég a longnak a pozícióhoz, semmit nem jelent, ha
>signeddé teszem.
>
>
>2014. május 16. 14:37 hg12345 írta, <hg12345 at freemail.hu>:
>
>> Hi
>>
>> ha előjeles értékre van szükséged akkor mit akarsz az unsigned long-val?
>> ((( cast és mindenféle C-s trükkel bármilyen eredményt kihozhatsz, de ez
>> nem célszerű)))
>>
>> A tagokat egyenként helyesen cast-old, és úgy végez műveletet és az
>> eredményt tárold a megfelelő helyen.
>> Nem lesz gyors, de legalább tömör lesz a tárolás...
>> Hiba lista mit ír?
>> Ha így, se működik helyesen, akkor csak egy megoldás van újra írni az
>> aritmetikának ezt részét
>>
>>
>>
>> Skandar Graun <sgraun at gmail.com> írta:
>> >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]
>>
>> -----------------------------------------
>>           elektro[-flame|-etc]
>>
>-----------------------------------------
>          elektro[-flame|-etc]