volani funkci z obsluhy preruseni LPC23xx
Ahoj, mam problem s volanim funkci z IRQ na LPC2364. Problem je nasledujici: 1. vlezu do preruseni 2. zavolam nekolik podfunkci xyz 3. zavolam funkci deb_led_on nebo deb_led_off nebo deb_led_change 4. vykonavam dal kod preruseni 5. vylezu z preruseni 6. skoncim v _undef procesoru Opakovatelnost je zhruba 90% zalezi na pridani nebo ubrani kodu. Mam vypozorovany, ze problematicka funkce je deb_led_xxx - jeji funkce je stupidne jendoducha, jen vola pomerne hodne dalsich funkci (do hloubky). Uz jsem to jednou resil s gcc3.4 - to jsem vyresil prechodem na gcc4.3 + zapnutim optimalizace (ne prilis idelani reseni). Nicmene ted se opet dostavam opet ke stejnemu problemu... Program je "stupidne" jednoduchy, takze nehrozi nedostatek RAM. Nemate nekdo tuseni v cem by mohl byt problem, pripadne kde mam asi hledat chybu? V priloze je map soubor me aplikace. Jirka Kubias -- =================================================== Bc. Jiri Kubias Czech Technical University in Prague Faculty of Electrical Engineering dept. of Control Engineering Karlovo namesti 13/E, 121 35 Prague Czech Republic web page: http://dce.felk.cvut.cz e-mail: jiri.kubias@gmail.com mobile: 777 974167 =================================================== ---
Je dostatecna hloubka stacku? (nemuze pretect?) O.Spinka
Ahoj, mam problem s volanim funkci z IRQ na LPC2364. Problem je nasledujici:
1. vlezu do preruseni 2. zavolam nekolik podfunkci xyz 3. zavolam funkci deb_led_on nebo deb_led_off nebo deb_led_change 4. vykonavam dal kod preruseni 5. vylezu z preruseni 6. skoncim v _undef procesoru
Opakovatelnost je zhruba 90% zalezi na pridani nebo ubrani kodu. Mam vypozorovany, ze problematicka funkce je deb_led_xxx - jeji funkce je stupidne jendoducha, jen vola pomerne hodne dalsich funkci (do hloubky).
Uz jsem to jednou resil s gcc3.4 - to jsem vyresil prechodem na gcc4.3 + zapnutim optimalizace (ne prilis idelani reseni). Nicmene ted se opet dostavam opet ke stejnemu problemu... Program je "stupidne" jednoduchy, takze nehrozi nedostatek RAM. Nemate nekdo tuseni v cem by mohl byt problem, pripadne kde mam asi hledat chybu? V priloze je map soubor me aplikace.
Jirka Kubias
-- =================================================== Bc. Jiri Kubias Czech Technical University in Prague Faculty of Electrical Engineering dept. of Control Engineering Karlovo namesti 13/E, 121 35 Prague Czech Republic
web page: http://dce.felk.cvut.cz e-mail: jiri.kubias@gmail.com mobile: 777 974167 ===================================================
---
---
(..) Opakovatelnost je zhruba 90% zalezi na pridani nebo ubrani kodu. Mam vypozorovany, ze problematicka funkce je deb_led_xxx - jeji funkce je stupidne jendoducha, jen vola pomerne hodne dalsich funkci (do hloubky).
Jo, taky bych rek, ze to bude zasobnikem. Otazka je, k cemu blikani LEDkama potrebuje n vnorenejch volani, ja vetsinou po LEDce vyzaduju, aby zdrzovala co nejmin, ono i to nastaveni portu na LPC je dost pomale samo o sobe. V preruseni toho volam taky radsi co nejmin, bejvaly doby, kdy jsem tam delal kravin spoustu, ale to jsem byval mlad a blb (ted uz jen b)). Zdar, MP ---
Coz pro beh aplikace je to jedno, ale hodi se to pri debugovani. Zvetsil jsem STACK_SIZE z 0x400 na 0x600 a vysledek je bezezmen. Jestli najdu nejaky LpcEurobot tak to na nem zkusim, abych vyloucil zavislost na HW. Jirka 2010/1/12 Robothron 1715 (sysless@pandora.cz) <pecam1@fel.cvut.cz>
(..) Opakovatelnost je zhruba 90% zalezi na pridani nebo ubrani kodu. Mam
vypozorovany, ze problematicka funkce je deb_led_xxx - jeji funkce je stupidne jendoducha, jen vola pomerne hodne dalsich funkci (do hloubky).
Jo, taky bych rek, ze to bude zasobnikem. Otazka je, k cemu blikani LEDkama potrebuje n vnorenejch volani, ja vetsinou po LEDce vyzaduju, aby zdrzovala co nejmin, ono i to nastaveni portu na LPC je dost pomale samo o sobe. V preruseni toho volam taky radsi co nejmin, bejvaly doby, kdy jsem tam delal kravin spoustu, ale to jsem byval mlad a blb (ted uz jen b)).
Zdar, MP
---
-- =================================================== Bc. Jiri Kubias Czech Technical University in Prague Faculty of Electrical Engineering dept. of Control Engineering Karlovo namesti 13/E, 121 35 Prague Czech Republic web page: http://dce.felk.cvut.cz e-mail: jiri.kubias@gmail.com mobile: 777 974167 =================================================== ---
On Tuesday 12 January 2010 23:27:28 jiri.kubias@gmail.com (sysless@pandora.cz) wrote:
Coz pro beh aplikace je to jedno, ale hodi se to pri debugovani. Zvetsil jsem STACK_SIZE z 0x400 na 0x600 a vysledek je bezezmen.
Jestli najdu nejaky LpcEurobot tak to na nem zkusim, abych vyloucil zavislost na HW.
Jirka
Zdravím, tahle změna ničemu nepomůže. IRQ má na klasickém ARMu (ne Cortex-M) vlastní zásobník. Ten je v sysless nastavený na velmi malou hodnotu (32 byte). Je potřeba zkusit změnit definici v sysless/arch/arm/mach-lpc21xx/libs/boot/startup.S .equ IRQ_Stack_Size, 0x00000020 Nebo je potřeba implementovat nested IRQ stack s uložením potřebných dat z registrů zpět do systémového zásobníku a přepnout po dobu běhu IRQ do systémového módu. Pak lze využít paměť alokovanou pro systém/aplikaci a i přijímat další IRQ. Ovšem návrat je dost komplikovaný znamená maskování IRQ restauraci registrů IRQ módu, přechod na IRQ mód a z něj návrat. Takže to má velký overhead. S pozdravem, Pavel Pisa e-mail: pisa@cmp.felk.cvut.cz www: http://cmp.felk.cvut.cz/~pisa university: http://dce.felk.cvut.cz/ company: http://www.pikron.com/ ---
On Tuesday 12 of January 2010 20:44:35 Robothron 1715 (sysless@pandora.cz) wrote:
(..) Opakovatelnost je zhruba 90% zalezi na pridani nebo ubrani kodu. Mam vypozorovany, ze problematicka funkce je deb_led_xxx - jeji funkce je stupidne jendoducha, jen vola pomerne hodne dalsich funkci (do hloubky).
Jo, taky bych rek, ze to bude zasobnikem. Otazka je, k cemu blikani LEDkama potrebuje n vnorenejch volani, ja vetsinou po LEDce vyzaduju, aby
Pokud si dobre vzpominam, jak jsem to implementoval tak je tam sice mnoho vnorenych volani, ale vsechno jsou inline funkce. Vnorena volani tam jsou kvuli prenostielnosti a cilem bylo aby se bliknuti ledkou prelozilo jako jedna jedina instrukce. Nevim jak gcc 4.x, ale u verze 3.x to ten prekladac pro ARM uplne nepochopil a tech instrukci tam bylo mnohem vic. Michal ---
Problem bude asi v tom, ze bez zapnute optimalizace se inline funkce neoptimalizujou takze se to porad vnoruje a dost hluboko. Zitra zkusim upravit stack a zkusim to. Jirka 2010/1/13 Michal Sojka (sysless@pandora.cz) <sojkam1@fel.cvut.cz>
On Tuesday 12 of January 2010 20:44:35 Robothron 1715 (sysless@pandora.cz) wrote:
(..) Opakovatelnost je zhruba 90% zalezi na pridani nebo ubrani kodu. Mam vypozorovany, ze problematicka funkce je deb_led_xxx - jeji funkce je stupidne jendoducha, jen vola pomerne hodne dalsich funkci (do hloubky).
Jo, taky bych rek, ze to bude zasobnikem. Otazka je, k cemu blikani LEDkama potrebuje n vnorenejch volani, ja vetsinou po LEDce vyzaduju, aby
Pokud si dobre vzpominam, jak jsem to implementoval tak je tam sice mnoho vnorenych volani, ale vsechno jsou inline funkce. Vnorena volani tam jsou kvuli prenostielnosti a cilem bylo aby se bliknuti ledkou prelozilo jako jedna jedina instrukce. Nevim jak gcc 4.x, ale u verze 3.x to ten prekladac pro ARM uplne nepochopil a tech instrukci tam bylo mnohem vic.
Michal
---
-- =================================================== Bc. Jiri Kubias Czech Technical University in Prague Faculty of Electrical Engineering dept. of Control Engineering Karlovo namesti 13/E, 121 35 Prague Czech Republic web page: http://dce.felk.cvut.cz e-mail: jiri.kubias@gmail.com mobile: 777 974167 =================================================== ---
participants (5)
-
jiri.kubias＠gmail.com (sysless＠pandora.cz) -
Michal Sojka (sysless＠pandora.cz) -
pisa＠cmp.felk.cvut.cz (sysless＠pandora.cz) -
Robothron 1715 (sysless＠pandora.cz) -
spinkao＠fel.cvut.cz (sysless＠pandora.cz)