[elektro] cé típus
hg12345
hg12345 at freemail.hu
Thu May 22 12:01:02 CEST 2014
Fordítási opció LARGE vagy valami hasonló?
Ugyan ilyenkor lassabban kezeli a mert állandóan címet számol, de hátha müködik.
Egy másik lehetőség
A 7db nagy változó egységedet akárhova leteszed, majd egy pointer tömbbel hivatkozol rá, ez
a kezelés csak annyiban változik p-> struktura elem lesz..... ez elfed és ápol mindent....
Skandar Graun <sgraun at gmail.com> írta:
>Bejött... pakolódik össze a rekord. :)
>Viszont hozta a következő problémát.
>A rekordhossz kezdi elérni a 70-80 bájt méretet.
>Ezekből a rekordokból van jelenleg hét.
>Ami jóval több, mint 256 bájt. (és még bővítenem kell.)
>A C18 meg alapból nem szereti a nagyobb bankméretet.
>Találtam linker script módosításos eljárást, de kíváncsi lennék, van-e
>könnyebben átlátható megoldás?
>
>
>2014. május 22. 7:52 Skandar Graun írta, <sgraun at gmail.com>:
>
>> 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]
>>>
>>
>>
>-----------------------------------------
> elektro[-flame|-etc]
More information about the Elektro
mailing list