[elektro] cé típus
Skandar Graun
sgraun at gmail.com
Thu May 22 07:52:55 CEST 2014
Köszönöm.
Az union szerintem egy copy-paste maradék és mivel működött, nem bolygattam.
De annyit belekavart, hogy a C könyves példa nem működött. :D
Ezért írtam ide.
Átírás következik. :D
Hiába na, az empirikus megismerés hibái a szoftverfejlesztés során. :)
2014. május 22. 7:39 hg12345 írta, <hg12345 at freemail.hu>:
> Szia,
>
> természetesen nem működik.
>
> Két lehetőség van:
> adj nevet a stukturának a terület foglalás mellett
>
> struct name_struct { //ez a struct neve azzel már lehet hivatkozni a
> késöbbi változó definiálásánál
> unsigned B0 : 1;
> unsigned B1 : 1;
> unsigned B2 : 1;
> unsigned B3 : 1;
> unsigned B4 : 1;
> unsigned B5 : 1;
> unsigned B6 : 1;
> unsigned B7 : 1;
> } fogalas_struct; //ez a struct változó neve
>
> typedef union huzo_record
> {
> struct
> {
> long huzo_cel;
> unsigned int serpos;
> unsigned char serstat;
> unsigned char addr_bovit;
> unsigned char huzo_tocnt;
> struct name_struct h_stat;
> struct name_struct h_stat_1;
> };
> }huzo_record;
>
> Egyébbként amit itt leírtál annak semmi értelme nincs! Ebben a union-ban
> csak egy dekraláció van, teljesen értelmetlen... a union-nak az az értelme,
> hogy hogy ugyan arra tár területre lehet más-más formában hivatkozni....
> pl.: Egy uint16_t alsó és felső byte-t tudod így kezelni.. Ráadásul a
> typedef csak egy új tipust hoz létre de hozzá tartozó változót nem!
> Célszerű a typedef tipus neveket megkülönböztetni XXXXX_t szoktak, hogy
> tudjad ez nem az.
>
> A második megoldás:
>
>
> typedef struct name_struct { //ez a struct neve azzel már lehet
> hivatkozni a késöbbi változó definiálásánál
> unsigned B0 : 1;
> unsigned B1 : 1;
> unsigned B2 : 1;
> unsigned B3 : 1;
> unsigned B4 : 1;
> unsigned B5 : 1;
> unsigned B6 : 1;
> unsigned B7 : 1;
> } bitenkent_t; // !!! ez egy új típus és nem változó!!!!!
>
> alkalmazása:
>
> typedef union huzo_record
> {
> struct
> {
> long huzo_cel;
> unsigned int serpos;
> unsigned char serstat;
> unsigned char addr_bovit;
> unsigned char huzo_tocnt;
> bitenkent_t h_stat;
> bitenkent_t h_stat_1;
> };
> }huzo_record;
>
> De maga a union megadás kicsit érthetetlen, továbbra is.
>
> Amit leírtam az minden C könyv első 40 oldalán megtalálható, talán jobban
> leírva is.
> Szóval ne keverd típus meghatározást, a struktura és union neveket és a
> változókat.
> Igazság szerint ezeken kivül szinte semmi nincs a C-ben
>
>
>
>
>
> Skandar Graun <sgraun at gmail.com> írta:
> >Sziasztok!
> >
> >Meglett, a bemenő érték egy rossz pointer miatt a tesztkiolvasás és a
> >felhasználás között megváltozott. :D
> >Szóval megint az user volt a hülye... :D
> >
> >Azonban most jött a következő kérdés.
> >Bit mező struktúrában.
> >Van egy bit struktúrám.
> >struct {
> >unsigned B0 : 1;
> >unsigned B1 : 1;
> >unsigned B2 : 1;
> >unsigned B3 : 1;
> >unsigned B4 : 1;
> >unsigned B5 : 1;
> >unsigned B6 : 1;
> >unsigned B7 : 1;
> >} huzo_stat,
> >
> >Ezt szeretném betenni egy másik unionba...
> >
> >typedef union huzo_record
> >{
> >struct
> >{
> > long huzo_cel;
> >unsigned int serpos;
> >unsigned char serstat;
> >unsigned char addr_bovit;
> >unsigned char huzo_tocnt;
> >struct huzo_stat h_stat;
> >struct huzo_stat h_stat_1;
> >
> >};
> >}huzo_record;
> >
> >de erre a szintaktikára aszondja nekem a fordító:
> >
> >Error [1165] reference to incomplete tag 'huzo_stat'
> >
> >Tudom, hogy itt én vagyok a tudatlan, de nem találok megoldást rá.
> >
> >Ráadásul találtam olyan példafórumot, ahol azt írták, nem is műxik ez a
> >megoldás.
> >
> >
> >
> >
> >2014. május 16. 16:54 hg12345 írta, <hg12345 at freemail.hu>:
> >
> >> Egy futás kódú (bennfoglalt) PID megírható long nélkül is, nehezen
> hihető,
> >> hogy 1/30000 pontossággal kell szabályozni, ha igen akkor sikerül :-)
> >> (tapasztalatból tudom....)
> >>
> >> 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]
> >>
> >-----------------------------------------
> > elektro[-flame|-etc]
>
> -----------------------------------------
> elektro[-flame|-etc]
>
More information about the Elektro
mailing list