[elektro] C - memset

elight elight at gmail.hu
Thu Feb 4 09:25:46 CET 2016 

Köszi

megnézegetem...
Egyébként a MikroeC-hez már megszenvedtem
pont az FTDI-ssel. Éppen azt írogattam át.
De nem obj , csak sima C lib szerűen.

Szóval, bass! Már megint dodozni kell vele!

Az enyém megoldás sem portábilis.
Az ArM-os honosításnál meg tényleg
jó lenne már a HAL, meg az objektumos szemlélet..

Azért találtam, igaz  másfajta kijelzőre egy kis mini GUI-t.
Szerintem ezt is érdemes lehet nézegetni, esetleg bővítgetni..
Már majdnem olyan, csak át kellene
értelmezni az FTDI-hez, hiszen
a függvényi  sokmindent jobban (hw) egyszerűbben
támogatnak.

Ja a link le nem maradjon! :-)
  http://mikrocontroller.bplaced.net/wordpress/?page_id=4723

Tegnap bele is feküdtem jókicsit..
Minden példa CooCox, és mindegyik elsőre
csont nélkül futott. Javarész a displayosakat
próbáltam a disco429-en.

Valami ilyesmiért :'( tegnap, de már nem igazán kell! :-D

Üdv István

2016-02-03 17:45 keltezéssel, Moravcsik Szilard írta:
> 2016.02.03. 15:42 keltezéssel, elight írta:
>> esetleg tudsz egy jó (bevált) C++ libet hozzá M4-re Coocox alá?
>> Persze ami publikus
>>       és csak szigorúan tanulmányozási célzattal! :-)
>> Valahogy a FTDI-set nem karódzik átbütykölni..
>>
> Én is elborzadtam, mit tudtak összehozni az FTDI-sek!
> Ezért anno egy bizonyos Guillaume Smolders-től vettem át a forrásokat,
> innen:
>
> https://github.com/guillaumesmo/FT800
>
> Ezt aztán átdolgoztam 8 bites AVR-re és az általam használt és nagyon
> szeretett, stabil CodeVisionAVR libekre. Szóval a kód egy kis része
> abszolút nem hordozható, HAL-ról még csak nem is hallott. :)
> ARM-okra nincs még átírva (de legkésőbb tavasszal meglesz! :)).
>
> Library függő az spi és pár I/O bit használata, a többi már lib.
> független. Illetve van még egy #define/#undef FT_81X_ENABLE feltételes
> fordításvezérlő definíció, ezzel tudod megadni, hogy sima FT80x vagy az
> újabb FT81x chipre fordítod-e?
>
> Ha így is érdekel, nagyon szívesen elküldöm.
> De küzdened kell vele, hogy ARM mikroC alatt is fusson!
>
> Üdv:
> Szilárd
>
>> 2016-02-03 15:20 keltezéssel, Moravcsik Szilard írta:
>>> Kb. erről írtál jan. 26-án:
>>>
>>> "/.../ sok múlik a változók illesztésen, ha nem állítsz be mást akkor
>>> ALIGN 4 illesztéssel dolgozik, és minden változó még char is regiszter
>>> méreten tárolódik. Vagyis, a konstansok és konstanssal feltöltött
>>> változók is akár 4x helyet igényelhetnek. Kivétel ez alól a tömb. Ha
>>> tömörségre kell menni akkor érdemes ahol lehet kisebb illesztéssel
>>> dolgozni ALIGN 2 vagy __packed elő/utó tagot használni.
>>> "
>>>
>>> Akkor pont az ARM Cortex-M0 memória kapacitásról volt szó.
>>>
>>> Megjegyzem, az FTDI FT8xx display vezérlő IC is pont ALIGN4-et használ
>>> mindenhol, kötelező érvénnyel. Az elején jól meg is szívtam, ha nem
>>> megfelelő címen kezdtem el beírni a display utasításokat. Rejtélyes
>>> képernyő zavarok léptek elő, a hajam meg szálanként őszült, mert egy
>>> darabig el sem tudtam képzelni, mi a bánat lehet a gond... :)
>>>
>>> Üdv:
>>> Szilárd
>>>
>>> 2016.02.03. 14:51 keltezéssel, hg12345 írta:
>>>> Hi,
>>>> csak annyit jelent, hogy szorosan pakolja a változókat.
>>>>
>>>> Normál esetben regiszter határra teszi a változókat, ez egy 32 bites eszköznél 4 byte (align 4),így gyorsabb a beolvasás, és nem kell beolvasáskor előjel kiterjesztést csinálni, vagyis gyorsabb a program futása.
>>>>
>>>> PACKED esetén pontosan egymás után szorosan, helyezi el a memóriában a változót, de ez esetben felhasználáskor (mem->reg) esetén ki egészíti 32 bitre, előjel szerint vagy nullával tölti unsigned esetben. Ugyan erre van speciális beolvasó és kiíró parancs ARM M6V és M7V utasítás készletben de még így is lassabb a futási ideje.
>>>>
>>>> Használat?! Gyakorlat teszi a mestert.
>>>>
>>>> Ha nagy struktrurákkal vagy struktura tömbökkel dolgozol ilyen esetben elég jelentős memória területet lehet felszabadítani jól irányzott __packed-vel.
>>>>
>>>> pl.:
>>>>
>>>> typedef struct { int32_t counter ;
>>>>                            uint8_t semafor; } proba_t ;
>>>>
>>>> proba_t parray[1000];
>>>>
>>>> a fenti esetben proba_t 8 byte-nyi helyet foglal, és a teljes tömb 8000byte lesz.
>>>>
>>>> ha kicseréled  __packed uin8_t  a definíciót akkor ez egyből csak 5000byte lesz.
>>>>
>>>> Amúgy nem biztos hogy C szintem ezeket az értékeket kapod, de fordítás esetén a memória foglalásban látszik, &parray[999]-parray két pointer különbsége már tényleg a valós méretet adja.
>>>>
>>>> Továbbiakban ha változóid inicializáláskor értéket kapnak, akkor nem csak RAM-ban spórolsz, hanem kisebb lesz az inicializálás terület nagysága a FLASH-ben is. A ZERO inicializálásnál ez nem számít.
>>>>
>>>>
>>>>
>>>>
>>>> elight <elight at gmail.hu> írta:
>>>>> Szia
>>>>>
>>>>> Elöljáróban,
>>>>>      ennek még nem néztem utána
>>>>> de GCC nél nekem is már bökte a listában a szemem
>>>>>
>>>>> __attribute__((packed))
>>>>>
>>>>> ez alatt pontosan mit is kellene értenem,
>>>>> hogyan is működik? Vagyis mikor illik használni?
>>>>>
>>>>> Üdv István
>>>>>
>>>>>
>>>>>
>>>>> 2016-02-03 14:19 keltezéssel, Moravcsik Szilard írta:
>>>>>> 2016.02.03. 13:26 keltezéssel, uprogc . írta:
>>>>>>> Sziasztok,
>>>>>>>
>>>>>>> ( STM32, gcc )
>>>>>>>
>>>>>>> Van egy strukturam, amelyben van egy 32 bites es ket 8 bites valtozo.
>>>>>>> Ennek a merete 6 byte.
>>>>>>>
>>>>>>> Ha memset() eseten a struktura meretet sizeof(tipus)-al megadom, akkor
>>>>>>> rendben van, ha viszont konstans 6 ertekkel adom meg a meretet, akkor az
>>>>>>> elso byteot nem allitja be a memset :)
>>>>>>>
>>>>>>> Ez mi ?
>>>>>>>
>>>>>> Sziasztok!
>>>>>>
>>>>>> Érdekelt, kipróbáltam (EmBlocks bare-metal-gcc), amíg a friss kávémat
>>>>>> kortyolgattam:
>>>>>>
>>>>>> /* A struktúrám típusa: */
>>>>>> typedef struct{
>>>>>>         uint32_t tag32;
>>>>>>         uint8_t tag8_1;
>>>>>>         uint8_t tag8_2;
>>>>>> } __attribute__((packed)) TEST_t;
>>>>>>
>>>>>> /* A kód: */
>>>>>> int main(void){
>>>>>> TEST_t test;
>>>>>> uint8_t len;
>>>>>>
>>>>>>         len = sizeof(TEST_t);	/* 6 byte lett a pakolás után */
>>>>>>
>>>>>>         memset(&test, 0, 6);
>>>>>>
>>>>>>         test.tag32  = 0x12345678;
>>>>>>         test.tag8_1 = 0x55;
>>>>>>         test.tag8_2 = 0xAA;
>>>>>>
>>>>>>         memset(&test, 0xFF, 6);
>>>>>>
>>>>>>         return 0;
>>>>>> }
>>>>>>
>>>>>> Nálam rendben megcsinálta azt, amit vártam tőle. Először memset()-tel
>>>>>> feltöltöttem 0-kkal, azután egyenként értékekkel, a végén meg
>>>>>> memset()-tel az egészet 0xFF-fel.
>>>>>>
>>>>>> Persze az __attribute__((packed)) attribútum nélkül 8 byte méretű lett
>>>>>> volna.
>>>>>>
>>>>>> Üdv:
>>>>>> Szilárd
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> A levél vírus, és rosszindulatú kód mentes, mert az avast! Antivirus védelme ellenőrizte azt.
>>>>>> https://www.avast.com/antivirus
>>>>>>
>>>>>> -----------------------------------------
>>>>>>                elektro[-flame|-etc]
>>>>>>
>>>>> -----------------------------------------
>>>>>              elektro[-flame|-etc]
>>>>>
>>>> -----------------------------------------
>>>>               elektro[-flame|-etc]
>>>>
>>> ---
>>> A levél vírus, és rosszindulatú kód mentes, mert az avast! Antivirus védelme ellenőrizte azt.
>>> https://www.avast.com/antivirus
>>>
>>> -----------------------------------------
>>>              elektro[-flame|-etc]
>>>
>> -----------------------------------------
>>             elektro[-flame|-etc]
>>
>
> ---
> A levél vírus, és rosszindulatú kód mentes, mert az avast! Antivirus védelme ellenőrizte azt.
> https://www.avast.com/antivirus
>
> -----------------------------------------
>            elektro[-flame|-etc]
>

More information about the Elektro mailing list