[elektro] keil mdk rejtelmek

[uprogc]

Ha c filet csinalsz hozza kell adni a projekthez a keilben add existing
vagy vmi hasonlo. Nem tartom eszben...

On Sunday, February 9, 2020, uprogc <uprogc at gmail.com> wrote:

> En ugy szoktam hogy beken hagyom azt amit generalt, legalabbis az elejen.
> Csinalsz kulon c vagy h filet, beincludolod a main.c be es mehet a sajat
> dolog. A cube meg szokta jegyezni a projekt utvonalat, es mar ketszer
> emiatt rageneralt, torolt fileokat, hiaba nyitottam meg direkt egy masik
> projektet ! Szerencsere mindig van mentes amihez nem nyulunk. Ezt azoknak
> irom akik nem ismerik ezt a talalmanyt.
>
> On Sunday, February 9, 2020, Skandar Graun <sgraun at gmail.com> wrote:
>
>> Teljesen tisztában vagyok azzal, hogy a C -t nem művelem felsőfokon.
>> Sőt...
>> De eddig, ha valahol deklaráltam egy változót ugyanúgy, ahogy a
>> példaprogramok változói voltak deklarálva, működött.
>> Van stdbool.h file, ott deklarálja a változótípust.
>> Valamint az zavar, amit te is írtál, hogy gőzöm nincs, mit hogy neveznek.
>> Lehet, hogy elmaradott vagyok, de valóban szeretem én körbenézni, mit és
>> hogyan inicializálok, kezelek.
>> Oké, itt már vannak nagybonyolultságú perifériák, de azon a hídon majd
>> akkor megyek át... ugyanúgy, mint egy IP stack esetén.
>> De most elsőre egy ledet szeretnék villogtatni megszakításból.
>> És ennek a HAL-nak köszönhetően egy kvázi üres main.c behoz 83 include
>> filét.
>> És ha a main.h-ban deklarálok egy változót (ahogy hozzászoktam) akkor
>> dupla
>> deklarációkkal leáll, hiába van benne az ifdef...
>> Amit írtál, az pont így van a programomban is... meg mellette még néhány
>> változó, amit a Cube deklarált.
>> Csak nem megy.
>>
>> hg12345 <hg12345 at freemail.hu> ezt írta (időpont: 2020. febr. 9., V,
>> 10:57):
>>
>> > Hi!
>> >
>> > bocs, de amít írsz az alapvető "C" programozási rutin probléma.
>> >
>> > bool típusú TYPEDEF van definiáltad  a fordítási egységben ?... amúgy a
>> > C-ben ilyen típus nincs!
>> >
>> > Ami van az "true" és "false" de ez bármire jó, és a típusa megegyezik az
>> > alap változó típussal  "int" ez esetben 32bit.
>> > Ha alaposan átnézed a HAL deklarációkat, találsz egy halom #define-t
>> > amivel mindenféle néven ezeket más néven defiálják :-( SUCCESS, ERROR
>> SET,
>> > RESET.....)
>> >
>> > Nem szokták minden fordítási egységben újra és újra extern-ként
>> definálni
>> > ezeket, mert követhetetlen lesz a javítás után a hiba halmaz.
>> >
>> > Erre valók a header file-k.....
>> >
>> > akármi.h:
>> >
>> > #ifndef __AKARMI_H__       ///többszörös meghívás kikerülése
>> > #define  __AKARMI_H__
>> >
>> > #include .... ami kell // mert sok hibát fog jelezi a KEIL környezet....
>> >
>> > extern DMA_HandleTypeDef hdma_adc1;
>> > extern TIM_HandleTypeDef htim1;
>> >
>> > #endif /*__AKARMI_H__*/
>> >
>> > Ezt a filet, #include-val hozzá csatolod a fordítási egységedhez
>> >
>> > Ha mindenhol megcsinálod a gyári deklarációt, az csak a fordítási
>> > egységben lesz érvényes (lokális) ha nincs hozzá  extern, akkor fordító
>> > programtól függ, de veheti static-nak is. Ami azt jelenti hogy kétszer
>> vagy
>> > többször van lefoglalva  a változó, és fordítási egységenként más mást
>> > használ.
>> >
>> > Töltsd le a netről : http://lidi.uw.hu/krc/index.html ezt a könyvet sok
>> > helyen elérhető, és olvasd át.
>> > Sokat fog segíteni!
>> >
>> >
>> >
>> > -------- Eredeti levél --------
>> > Feladó: Skandar Graun < sgraun at gmail.com (Link -> mailto:
>> sgraun at gmail.com)
>> > >
>> > Dátum: 2020 február 8 09:07:26
>> > Tárgy: Re: [elektro] keil mdk rejtelmek
>> > Címzett: elektro at centralnet.hu (Link -> mailto:elektro at centralnet.hu)
>> > Megcsináltam az alap IT kezelő filében az extern bool formátumú
>> > deklarációt.
>> > Megcsináltam a main filében a normál bool deklarációt.
>> > Mellette mindkét filében ott vigyorgott a gyári deklaráció...
>> > It kezelő file:
>> > /* External variables
>> > --------------------------------------------------------*/
>> > extern DMA_HandleTypeDef hdma_adc1;
>> > extern TIM_HandleTypeDef htim1;
>> > /* USER CODE BEGIN EV */
>> > extern bool tim_1_it;
>> > /* USER CODE END EV */
>> > main.c:
>> > /* Private variables
>> > ---------------------------------------------------------*/
>> > unsigned int cnt;
>> > bool tim_1_it;
>> > ADC_HandleTypeDef hadc1;
>> > DMA_HandleTypeDef hdma_adc1;
>> > TIM_HandleTypeDef htim1;
>> > UART_HandleTypeDef huart1;
>> > UART_HandleTypeDef huart3;
>> > /* USER CODE BEGIN PV */
>> > Az általam létrehozott változó a tim_1_it boolean típus.
>> > Egyrészt nem működik, tehát hiába setelem be a megszakításban, a
>> main-ban
>> > nem látom.
>> > Másrészt ha átállítottam a megszakítás filében char-ra, nem dobott rá
>> > hibát, de még warningot sem.
>> > hg12345 <hg12345 at freemail.hu> ezt írta (időpont: 2020. febr. 7., P,
>> 9:13):
>> > > Szia
>> > >
>> > > szerintem ennek nem sok köze van a KEIL-hez.
>> > >
>> > > Elvileg ha függvényt vagy változót akarsz máshol használni mint az
>> adott
>> > > fordítási egységben, akkor #include kell elő definicióval függvény
>> > > esetében, vagy változó esetén external ezt a az include-t befordított
>> > abba
>> > > a fordítási egységbe ahol szeretnéd használni és elérhető válik.
>> > >
>> > > A keil fordító azért nem ennyire finnyás, mert enélkül is kezeli, de
>> dob
>> > > warning-t.
>> > >
>> > > A másik, a HAL-ban előszeretettel #define helyettesítik az IT nevét
>> másra
>> > > és így írják meg az IT függvényt. A keil és legtöbb keret programram
>> az
>> > > IT-ket weak prefixel még a starup fileban definiálják ami egy B . asm
>> > > utasítást hajt végre ami egy végtelen ciklus. Így a nem definiált de
>> > > véletlenűl becsapó IT végtelen ciklusra fut, más hibát nem csinál és
>> > majd a
>> > > program felépítésétől függően valami történik.
>> > >
>> > > (((Amúgy a HAL jó is meg rossz is, sajnos rettentő lassú és amit nem
>> > > tudott megírni a HAL programozó azt már csak kínszenvedés... ugyan a
>> HAL
>> > > kezelés saját kézbe vehető, mert a HAL konfigban ez meghatározható, de
>> > > sajnos globálisan... Vagyis ha elfogadod és használnád az egyis pl.:
>> > > USART-ban de a másikhoz nem jó, akkor bizony borul a bili mert vagy
>> mindk
>> > > kettőben használod, vagy egyikbe se.... A másik baja, nem igaz hogy HW
>> > > elkell fedni a programozó elől, ha tényleg jót szeretnél csinálni,
>> akkor
>> > HW
>> > > is ismerni kell meg HAL gondolkodás módját, ez min. 2x annyi
>> meló....)))
>> > >
>> > > Ha valamit nem találsz a keil-ben, akkor teljes fordítási egységre
>> > > kereséssel kidobja hol van ilyen, persze ehhez az kell kell, hogy jól
>> > > legyen beállítva a könyvtár struktura.
>> > >
>> > > üdv
>> > >
>> > > -------- Eredeti levél --------
>> > > Feladó: Skandar Graun < sgraun at gmail.com (Link -> mailto:
>> > sgraun at gmail.com)
>> > > >
>> > > Dátum: 2020 február 6 21:02:08
>> > > Tárgy: [elektro] keil mdk rejtelmek
>> > > Címzett: elektro at centralnet.hu (Link -> mailto:elektro at centralnet.hu)
>> > > Sziasztok!
>> > > Beleakadtam egy problémába, szerintme a hozzáértőknek két perc, én meg
>> > > keresgélek fél napja.
>> > > Keil ARM SDK
>> > > Létrehoztam egy projectet, STM32CUBE segítségével.
>> > > Led már villog, szóval valami történik. :D
>> > > Valahol egy eldugott filében van az IRQ kezelés, ahol lehet beírni
>> user
>> > > kódokat, meg minden finomságot.
>> > > Viszont én szeretném az ott levő változókat a main.c-ben is használni.
>> > > Na, itt akadtam el, mert nem jövök rá, milyen attribútumok kellenének.
>> > > Ha jól sejtem, az extern kéne, de nem látják egymást. A keresések meg
>> > mind
>> > > ezt ajálnják.
>> > > Le is fordul vele, csak nem megy.
>> > > Amúgy van egy HAL_TIM_IRQhandler nevű cucc is, ami megintcsak ilyesmi
>> > > lenne, de annak meg nem találom a deklarációját... szóval ott sem
>> tudok
>> > > csinálni értelmes dolgot.
>> > > Tudtok ajánlani valami használható ötletet?
>> > > -----------------------------------------
>> > > elektro[-flame|-etc]
>> > > -----------------------------------------
>> > > elektro[-flame|-etc]
>> > -----------------------------------------
>> > elektro[-flame|-etc]
>> > -----------------------------------------
>> >           elektro[-flame|-etc]
>> -----------------------------------------
>>           elektro[-flame|-etc]
>
>