[elektro] keil mdk rejtelmek

uprogc uprogc at gmail.com
Sun Feb 9 14:16:13 CET 2020


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]


More information about the Elektro mailing list