[elektro] cé típus

[Skandar Graun]

A pozícióhoz szükséges a long, 1 cm 95 impulzus és 20 m-t kell tudnia a
rendszernek. Innentől kezdve pedig célszerű ezt megtartani.
Nem valószínű, hogy kihasználnám, a sebesség 0-6000 között változhat max.
De lehet, hogy mégiscsak visszadegradálom, ha ezzel ilyen gond van.

Nézegettem a memóriafoglalást, igazság szerint nem csonkol... ezért is nem
értem.

Most teljesen cast nélküli a dolog, így is ott van a problémás rész.
Hétvége révén csak a jövő héten kerül sor a folytatásra, meglátom, mi sül
ki belőle.


2014. május 16. 17:00 hg12345 írta, <hg12345 at freemail.hu>:

> 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]
>
> -----------------------------------------
>           elektro[-flame|-etc]
>