Микроконтролери и електроника
http://mcu-bg.com/mcu_site/

Еклипс въпроси
http://mcu-bg.com/mcu_site/viewtopic.php?f=3&t=8523
Страница 1 от 2

Автор:  Цецо [ Пон Фев 07, 2011 12:34 pm ]
Заглавие:  Еклипс въпроси

Абе имам от време на време следния проблем с еклипс:

Определен код ми го маркира че е "невалиден" и не желае да го дебъгва като хората. Обикновенно се случва когато имам #ifdef игрички с няколко вложени .h файлове. Иначе се компилира като хората, работи си, ама като тръгна да дебъгвам, се оказва че тоя код сивее - я не ще да слага точки на прекъсване вътре, я ги слага на съвсем други места.

Има ли команда да седне да си прегледа структурата на проекта и си опресни базата? "clean + Build all" не помага.

Автор:  miro_atc [ Пон Фев 07, 2011 12:46 pm ]
Заглавие: 

Първо виж дали всички h-файлове "се виждат" от Еклипса, ако трябва му задай ръчно инклудите в C/C+General->Paths and Symbols...

После виж дали "вижда" всички define-и. Ако на компилатора му ги задаваш в мейкфайл или като параметри то Еклипс няма как да знае това. Пак ръчно може да ги добавиш към symbols...

Добре е да провериш и настройките на скенера - C/C++ Build->Discovery Options...


A иначе специално за #ifdef то се вижда кои символи не обработва правилно. Маркираш съответния символ и с F3 виждаш къде го намеира или не намира Еклипса...

Автор:  fan [ Пон Фев 07, 2011 12:51 pm ]
Заглавие: 

Здравей! При мен се получава понякога подобни неща и го оправям периодично с десен бутон върху полето с номерата на редовете, Folding->Reset Structure. Забелязал съм, че това става ако използваш в програмата структура допустима за компилатора но различна от стандартната.

Автор:  Цецо [ Пон Фев 07, 2011 1:19 pm ]
Заглавие: 

Че не вижда #define -те е ясно. Като цъкам с F3 по макросите и ме гледат тъпо (т.е. нищо). Но интересното е че на два еднакви на вид проекта - се справя на единия с намирането, а на другия не.

Пак казвам проблема ми е с визуализацията в еклипса, проекта си се компилира правилно.

Явно не може да се ориентира в структурата на директориите. Аз не му включвам нищо в Path и Symbols, обикновенно след една компилация сам си открива всичко. Директориите ми се инклудват в мейкфайла, да, ама обикновенно Еклипса се оправяше, а сега неще.

Абе проблема е че се опитвам да портна ucGUI, а това чудо има сигурно няколко мегабайта сорсове и няколко хиляди файла оплетени в една идиотска мрежа от #define, #ifdef и прочие.... И на един проект беше станало като хората. А сега на следващия - не ми се получава и не мога да го дебъгна като хората. И не виждам разликата от къде иде мамка му.

Автор:  miro_atc [ Пон Фев 07, 2011 1:41 pm ]
Заглавие: 

Ясно де, разбрахме че визуализацията е проблема, въпросът е ти дали си наясно че компилацията няма нищо общо с визуализацията ;-)

Еклипса сам си се ориентира (може да ползва gcc за анализа ако му кажеш, но по подразбиране не го ползва). Виж да не си изключил сканирането и да не ти опреснява...

Значи много е просто - всички хедъри от проекта се парсват, освен това Еклипс се опитва да следи какви външни хедъри ползваш и ти ги слага в една #include папка в проекта.

Сега ако имаш хедър, който не е парснат виж къде е... дали е в проекта, ако не дали го е открило къде е, или ти трябва да го добавиш ръчно както ти описах по-горе (аз по принцип изключвам аутоматиките и си слагам ръчно пътищата, та да не стават сакътлъци...)

Автор:  Цецо [ Пон Фев 07, 2011 2:05 pm ]
Заглавие: 

Абе аз знам че ти е ясно, ама да поясня.

И на мен ми е ясно това което казваш. Или поне си мисля, че ми е ясно. Наслагах ги в Path и Symbols - пак дърво. :) Всъщност лъжа - те се бяха наслагали сами там, което показва, че еклипса се ориентира добре във дървото на проекта.

Всъщност "оправих" го де. Много тъпо - значи в проблемния сорс код, просто включих на "първо" ниво файла с дефинициите "#include bla-bla.h". И естествено веднага сивотата изчезна. После го махнах и сивотата не се появи повече. Нещо ме гложди, че и предишния път така го "оправих". Сякаш еклипса по подразбиране не се сеща да гледа вложени един в друг include файлове, а зяпа само първия. Веднъж като открие даден символ обаче, запомяна в кой фаил е го следи. Не е проблем на директории, защото и първото ниво и последващите include файлове са в една и съща директория....

Автор:  setoy [ Пон Фев 07, 2011 2:57 pm ]
Заглавие: 

Десен бутон върху проекта -> Index -> Rebuild. По някой път захапва...

Автор:  Цецо [ Пет Фев 18, 2011 4:15 pm ]
Заглавие: 

Нов въпрос - в дебъг (Zylin ако има значение), прозорчето за памет, всеки път ми се отваря на 32 битови числа. В повечето случаи ми е удобно на байтове. Има ли начин да го запомни и да не досажда?

Автор:  relsys [ Пет Фев 18, 2011 5:17 pm ]
Заглавие:  LD Linker

А, за да не отварям нова тема, на LD Linker-a разбирате ли му?

Автор:  Цецо [ Пет Фев 18, 2011 6:41 pm ]
Заглавие:  Re: LD Linker

relsys написа:
А, за да не отварям нова тема, на LD Linker-a разбирате ли му?


miro е човека :) До колкото въобще някой може да каже че това нещо може да бъде разбрано :)

Автор:  ДедоБоре [ Пет Фев 18, 2011 7:52 pm ]
Заглавие: 

ти си излей мъката, пък може да се окаже, че някой му разбира.
ако не му разбира вероятно няма да се обади.

Автор:  relsys [ Съб Фев 19, 2011 1:51 pm ]
Заглавие: 

ДедоБоре написа:
ти си излей мъката, пък може да се окаже, че някой му разбира.
ако не му разбира вероятно няма да се обади.


Та значи......

Както знаете аз харесвам и предпочитам Pascal. (Тук моля да пропуснем темата: C vs. Pascal)... И една сутрин като се събудих, реших че французите дето направиха Pascal за ARM не може да са по - умни от нас, и се хванах да си билдна един компилатор. Дръпнах си FPC, изградих крос компилатор за ARM и тръгна. Подкарах и Lazarus като среда. По дефолт, поддържа само 2-3 чипа от серия LPC21xx. Направих поддръжка за LPC2468. Генерираните hex файлове работят. Проблем беше, че тъй като няма директива #pragma, а имам и външна памет - как да кажа коя променлива къде да отиде, но с това се справих като добавих в линкерския скрипт даден файл къде да се разположи. После взех един object file от колега, който инициализира таймер и експортва функция Delay, компилиран на IAR C. Декларирах прототипите, линкнах файла и го ползвам без проблем от Pascal.
Проблема е, че ако примерно в С кода някъде има използвано нещо от библиотеките на IAR (memcpy примерно), програмата се компилира, генерира се hex file, но не работи. Или да опитам да подкарам линкера на IAR?!?

Автор:  miro_atc [ Съб Фев 19, 2011 4:02 pm ]
Заглавие: 

Значи LD-то не се интересува какъв ти е компилатора, важното е да му дадеш обектни файлове и библиотеки в разбираем за него формат.

По принцип с LD ходи и набор от разни "стандартни" библиотеки като libc примерно. И те се ползват автоматично, освен ако не включиш опции като "-nostdlib".

Освен самите библиотеки има и стандартни хедъри, така че поне на Ц не е нужно да декларираш прототипите на стандартните функции, достатъчно е да инклуднеш само стандартния хедър. За Паскал-компилатор не знам, може и да трябва.

Така или иначе щом се компилира значи нямаш проблем с хедърите. А може и да имаш като декларациите ти не съответстват по тип/параметри с кода от библиотеките.
Щом се линква, значи че и намерило и код за всички функции дето викаш.

А това, че не работи може да е резултат от:
1) грешна декларация. Примерно ти си декларирал функцията с един набор параметри, а тя реално е с различен брой/подредба или тип параметри. За съжаление линкера не хваща такива грешки, той гледа само имената да съответстват. То затова и Ц++ декорира имената...
2) Грешна calling конвенция. Доколкото си спомням Паскал имаше собствена конвенция за някои неща, различна от Ц/Ц++. Освен това самият АРМ има няколко конвеции (EABI, non-EABI)
3) Не бих се изненадал и ако има различия в това що е то обектен файл между IAR и GCC...

Въпросът е как да разбереш какъв е проблема... Сещам се за два варианта:
1) Да генерираш детайлни листинги и да видиш какви ги е надробило.
2) Да вземеш и да го дебъгнеш и пак да видиш какви ги е надробило.
А има и 3-и вариант - да се бориш с IAR-кия линкер...

Автор:  relsys [ Пон Фев 21, 2011 11:59 am ]
Заглавие: 

Ето това е линкерският ми скрипт:

Код:
ENTRY(_START)
MEMORY
{
    flash : ORIGIN = 0, LENGTH = 512K
    ram : ORIGIN = 0x40000000, LENGTH = 64K
[b]
    EIRam : ORIGIN = 0x80000000, LENGTH = 2M
[/b]
}
_stack_top = 0x4000FFFC;
SECTIONS
{
[b]
    ei_ram 0x80000000 :
    {
    definitions.o
    eir_*
    } >EIRam
[/b]
     .text :
    {
    *(.init, .init.*)
    *(.text, .text.*)
    *(.strings)
    *(.rodata, .rodata.*)
    *(.comment)
    _etext = .;
    } >flash
    .data :
    {
    _data = .;
    *(.data, .data.*)
    KEEP (*(.fpc .fpc.n_version .fpc.n_links))
    _edata = .;
    } >ram AT >flash
    .bss :
    {
    _bss_start = .;
    *(.bss, .bss.*)
    *(COMMON)
    } >ram
. = ALIGN(4);
_bss_end = . ;
[b]
    api_r :
    {
    timer.o
    } >flash
[/b]
}
_end = .;


Секциите [Bold] съм ги добавял аз. Може ли малко по детайлно обяснение, какво точно прави линкера и защо като преместя секция 'api_r' в на1алото на срипта и се сбозва работата?

Автор:  miro_atc [ Пон Фев 21, 2011 12:46 pm ]
Заглавие: 

relsys написа:
защо като преместя секция 'api_r' в на1алото на срипта и се сбозва работата?


Аз няма как да ти кажа защо се сбозва... но ти сам много лесно може да го разбереш защо ;-)

Когато компилатора генерира обектните файлове, той указва коя променлива/обект в коя секция да бъде разположен. За линкера това са т.н. "входни секции".

Сега в линкерския скрипт ти в "SECTIONS { ... }" дефинираш "изходните секции" както и правила коя входна секция в коя изходна искаш да отиде.

В случая ти правиш много странни неща, дето аз бих избегнал да правя. Примерно в изходна секция пляскаш директно обектен файл, а от къде си сигурен, че всичко от тоя обектен файл трябва да е само в една изходна секция? Утре ще сложиш променлива или нещо в сорса и ще се чудиш що не работи...

Освен това както си го направил редът има значение! Най-вероятно твоят timer.o съдържа код, т.е. функции, които по принцип компилатора слага в .text. Може да имаш статични променливи, които по подразбиране са в .bss, инициализации в .rodata и т.н. и т.н.
Сега както е написан скирпта като почне да се линква timer.o първо ще се срещнат правилата за .text, .bss и т.н. и което пасне на тези правила ще се разположи в съответните изходни секции. И когато стигне до края - в api_r имаш правило да сложи "всичко" от timer.o. Но под всичко, разбирай всичко което е останало нелинкнато от горните правила.

Ако изместиш обаче тая api_r в началото, тогава ще започне със "всичко" а то наистина в началото е "всичко" и всичко от timer.o ще се пльосне във флаша... Ако така го искаш няма проблем ;-) Въпросът е че аз нямам идея нито какво искаш, нито какво се получава... Гледаш листингите и проверяваш, функциите там където ги искаш ли са, променливите на място ли са, инициализации и т.н.

И по възможност избягвай директно да упоменаваш цели файлове. Работи само с правила коя входна секция в коя изходна да отива...

Страница 1 от 2 Часовете са според зоната UTC + 2 часа [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/