[elektro] cé típus

[Skandar Graun]

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