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

Въпрос: Как мога да си гледам регистрите от периферията в дебъгера? Във всички среди които съм ползвал досега това става под някаква форма в Watch прозореца, ама тука в Variables такова животно няма как да навра. Предполагам защото не са ми дефинирани никъде като имена

Всъщност става - през глобален поинтер дефиниран за целта, ама това си е клизма, трябва да ровя всеки път datasheet-a да търся адреса. Няма ли по елегантен начин да се следят всички периферни регистри?

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

С две думи аз съм го избегнал проблема... Сега при теб зависи как ти са дефинирани регистрите. Ако са само define на адреси - лошо...

Ако ги имаш като структури е лесно. Примерно при Атмел хедърите пътво дефинират с typedef структурата на всяко периферно устройство с регистрите му и т.н. и накрая на файла има изнесени базови адреси на перифериите в тоя дух:



Ако имаш и ти подобно нещо на кортекса, може просто тоя хедър да си го държиш отворен и да ти е под ръка и като ти потрябва нещо примерно PIOA маркираш само реда му "(AT91PS_PIO)0xFFFFF400" с мишката, копираш го... и го плясваш в Еxpressions.
По подразбиране джама за expressions е скрит но надявам си не си забравил:

Имам такова. Всички регистри са ми дефинирани като:



Но прозореца expresions, нещо не ми работи като хората.

Значи когато вкарам вътре "PERIPH_BASE", "APB1PERIPH_BASE" или даже "(APB1PERIPH_BASE + 0x1400)" - работи. В момента в който пробвам "GPIOD_BASE" - ме заплюва с "Target request failed: mi_cmd_var_create: unable to create variable object.". Което е странно защото то е просто по вътрешен слой define. А да ми покаже директно "((GPIO_TypeDef *) GPIOD_BASE)" хич не си и мечтая

Всъщност сега виждам че не ми работи и прозореца memory. Тамън да не мога да ги видя никак

"((GPIO_TypeDef *) GPIOD_BASE)" трябва да е без скобки, т.е. "(GPIO_TypeDef *) GPIOD_BASE"

А за memory не ми се е случвало да не бачка... Всъщност в какъв смисъл не бачка - дава грешка или не дъмпва правилни стойности?

Ако се съмняваш във второто дай му "set debug remote 1" в конзолата и ще виждаш пакетите между gdb и gdbserver-a ... Ако данните в пакетите са кофти, оплачи се на segger... ако не ша търсим телефона на Папата

Все тая . Резултата е :

... каквото и да значи тая дивотия.



Това го проумях откъде идва, само дето нямам решение. Значи тъпия Memory View по подразбиране не изкарва просто съдържанието на даден адрес, а дъмпва паметта +- няколкостотин байта. Да ама адресното пространство има дупки. И така като пробвам да дъмпна първия адрес от рам, това говедо се опитва да захапе и малко преди това, и съответно сегерския сървър го наплюва, а той ми предава плюнката. Е да покаже нещо от сорта "XXXXX" да го еба .... И сега ако искам да дъмпна нещо близо до дпука, трябва да правя чудеса от сметки А така и не открих от къде да задам на тоя джам, колко пространство да дъмпва или пък да дъмпва само в +. Е това си е някаква пълна дивотия.

Сега имам нов проблем. Следния код:


Генерира това тъпо съобщение:


Най тъпото е че като махна последните двe const char..... декларации и се компилира без проблем. Какво е това FP? floatin point? И какъв му е проблема с две тъпи декларации?

Сори, днес нямаше как да ти отговоря...

Относно memory view & expresions това са неща дето нямат нищо общо с GNU и може би не подлежат на настройки - не знам...
При всички случаи ще ти е по-лесно да ги ползваш, ако се научиш да работиш с GDB и без тях
Имаш конзола и винаги като имаш някакви съмнения тествай първо там. Поне ще имаш някакви по-разбираеми отговори...




Това ти е израз, виж го в конзолата.. Команда та е "print израз", съкратено може "p израз", съответно "p/x ..." за hex "p/d" за dec "p/c" за char и т.н.
Дай няколко опита и ще разбереш какъв е проблема... Възможно е нещо да е оптимизирано или за някой символ/дефайн да няма дебъг информация.

Ако искаш да разглеждаш памет командата е "x" пак с наклонена формат - (‘x’, ‘d’, ‘u’, ‘o’, ‘t’, ‘a’, ‘c’, ‘f’), and in addition ‘s’ (for null-terminated strings) and ‘i’ (for machine instructions).

Друго полезно нещо е ако имаш израз който дава един обект, структура и т.н, може да използваш "повторение", то става малко различно при p и х. Примерно нека имаме 5 char-a на адрес 0x200000 съответно командите са:

p/c *(char*)0x200000@5
x/5c (char*)0x200000

Примерът е char, но може да е всякакъв елемет/израз както са твойте GPIO_TypeDef...
А... имаш и printf със стандартните format specifier-и...

Може да си направиш цели процедури дето разпечатват всичко което ти трябва и да си ги сложиш в define и да ги викаш с 2-3 клавиша... Но идеята беше, че като поработиш 1-2 часа с конзолата ще свикнеш с изразите и с GDB. И после ще ти е по-лесно с expression джама - ако не друг ще знаеш дали джама има бъг или ти въвеждаш грешни неща




Това е floating point - http://dev.emcelettronica.com/select-so ... controller
сигурно има и по-добри описания... но вероятно проблемът ти няма нищо общо с математиката.... Ти доколкото разбирам ползваш memcpy или нещо подобно и то решава че трябва да линкне стандартни библиотеки...
Сега... библеотеките при GNU са компилирани обектни файлове натъпкани в разни a-файлове. Като стандартните библитеки са прекомпилирани в няколко формата за ARM, THUMB и т.н. каквото са преценили. По принцип линкера си решава какво да ползва, но работата е там, че ти май ползваш yagarto а той немеца казва че не отговаря за cortex...
Та много вероятно ти се опитваш да линкнеш библиотека компилирана като за ARM7 и става боза...

Или си намери тулчейн дето да знаеш че е за твоя куртекс... или си изтегли сорсовете на библеотечките (от yagarto.de или http://www.sourceware.org/newlib/ ) и си ги прекомпилирай...
Имаш два варианта - да си ги компилираш до библиотеки пак и да ги зададеш като "стандартни"... но това може би ще те затрудни (то и мен може би ще ме измъчи) или просто си вкараш сорсовете в проекта и си изключи вскякави стандартни библиотеки та да ти е мирна главата....

Сори Цецо, ама ти наистина се набутваш в най-големите говна... Трябваше да изчакаш някой да подкара някаква среда за Кортекс. Аз като казвах че GNU работи, имах предвид АРМ7, тама наистина благодарение най-вече на човека-yagarto нещата са поносими....

Както казах аз съм талант в набутването в говната. По принцип е много куцо да копаш из неорана нива, спор няма. Ама като има някой като теб да пусне някоя сламка, нещата минават по-леко. Ей тъй идеята, щото понякога като закопам като прасе в кал.... и пълен блокаж. Аз рових из нета, ама не успях да открия читаво обяснение на проблема с плаващата запетая. Докато от твойто стават ясни някой неща..... ама някой. Щото и Кортекса и АРМ7TDMI (повечето) нямат FPU. Така че що гърми... незнам. Поне от съобщението излиза, че библиотеките са компилирани за HFPU, докато мойто GCC компилира с SFPU. Ако се вярва на онова описание, по добре е всичко да е на HFPU, пък то като изтряска ексепшън заради непозната инструкция, щяло да прихване и да я иземулира (малко ми е чудно как ще стане, ама айде.) То това хубаво, ама що мойто GCC ще компилра на SFPU, като аз не съм му казвал такива неща? И що ще се дъни баш на кортекса, като по отношение на FPU - то, там големи разлики няма.... т.е. няма FPU де. Така че поне според това описание, проблема при мен е в GCC-то, а не в библиотеката, щото линкера казва че тя е правена за HFPU. Няма да се учудя ако такъв код гръмне и на ARM7TDMI с тоя тулчеин.

Отделно пък зачии му е да линква библиотеки говедото, идея си нямам. По принцип в моя код засега не викам нищо от стандартните. Абсолютно нищо. Откъде реши че му трябва memcpy....идея си нямам. Това са константни низове, трябва да са си директно във флеша. Не се опитвам да ги местя. Ама явно той си е наумил нещо. Като ги декларирам в един цял масив (а не 4 отделни) - не гърми. Като коментирам 2 от 4те - пак минава. Свинщина. Уф въобще не ми се дизасемблира .

Принципно има тулчеин който компилира тоя код без грешка - Code Sourcery. При това с същия makefile, т.е. викам го със същите опции. Т.е. това gcc и библиотеките явно тръгват с еднакъв FP, какъвто и да е той. Ама gcc-то е малко по старо и кода от 14К стана на 16К. А съм още на първоначалната инициализация . Това без никакви оптимизации де. Ама явно ще мина на него засега, защото не ми се компилира тулчеин, това ще ми утепа още няколко дена.

Относно отпечатването на разни променливи - не бачка и в GDB. Дефакто това което работи в expresion, работи и в конзолата, което не ще там, не ще и в конзолата. В което има логика де

Вероятно наистина ми липсва дебъг информация. Защото и като ида с курсора върху някоя от тия структури (с регистрите) и отдолу в конзолата се появява например "No symbol "DMA1_Channel5" in current context". Какъв е случая с тая дебъг информация, къде и как се включва?

Иначе имам много да черпя. Помагаш ми много. Във всеки случай доказах още веднъж на себе си, че за да се занимава човек с GNU трябва да разполага с адски много свободно време. Апропо, едва ли е само заради кортекса. Мога да се хвана на бас, че и с Aтмелски ARM7TDMI, ще ти изкарам на повърхността неща, които никога не ти е хрумвало, че може да изскочат. Както казах - абсолютен талант съм в областта - доказъл съм го.

Просто си намери библеотеки като за твоя таргет. Нормално е да се омотава като линкваш неща компилирани за различни цели. То пак по-добре че по време на линкване гърми, щото по време на изпълнение ще е оше по-гадно
Имай предвид че при GNU се ползва едно ядро на С компилатор дето е универсално, затова много неща не са част от компилатора. Примерно нямаш деление и като напишеш "int a = b/10;" то няма да ти вкара код за деление, а код който извиква udiv(). Съответно ти трябва да предоставиш някаква имплементация на подобни стандартни функции...
Уж за улеснение, е направено да има стандартни библиотеки към тулчейна така че обикновения потребител да не му се налага нито да пише стандартни функции, нито да ги задава като библеотеки.
Да ама не... При теб това "улеснение" носи само ядове....

Сега единия вариант е ако може да вземеш вече компилираните библиотеки от Sourcery-то и да подмениш тия от yagarto. Но се притеснявам, че няма да е толкова просто и пак ще нагазиш в неорана нива...
Може би по-чисто е да разкараш ягартото като включиш "-nostdlib", така линкера ще почне на чисто и ще линква неща само дето ти изрично си казал. Съответно няма да намери стандартните функции и затова ще трябва да му дадеш "-l library" за всяка от сорсери библеотечките... Преди това може да потърсиш как се включваше дебъг режима на линкера - правел съм го, но сега не сещам. Идеята е да видиш какво и как ползва сега по подразбиране, преди да си го изключил и после същите неща да ги преправиш на новите библиотечки...


Първо по време на компилиране трябва да включиш съответните опции, за да може дебъг информацията от *.с файловете да влезе в *.о т.е. обектните файлове.
То има много флагове според зависи какво и как компилираш. Аз не съм задълбавал щото то общо взето си бълва при мен необходимата информация по подразбиране...
Изезват ми само наистина оптимизирани променливи, но те не са чак толкова много въпреки че работя на максимална оптимизация - винаги...

Вероятно проблемът при теб е на втората стъпка, т.е. по време на линкване когато от *.о+*.а се прави elf-файла (ако си на елф, щото има и други варианти). Тук нещата зависят и от линкерския скрипт, защото за дебъг символите и разните там дебъг информации линкера прави разни специални секции.
Аз честно казано така и не разбрах какво и кога се генерира, а пък като описваш секциите трябва да вкараш правила "това тук..." "това тук..." и ако нещо не му намери място не го слага в ELF-а. Пък дебъгера основно от там си дърпа информация....
Може би трябва да намериш някой който ги разбира повече от мен нещата... Аз съм ги "нацелвал" като сравнявам множество линкерски скриптове. Щото не намерих подробна информация за секциите.... Примерно rodata е за константи, обаче що трябва веднъж да му слагам *(.rodata) и втори път *(.rodata*) ебали му мамата...
Ако знаех как компилатора именува символите и секциите щях да знам как трябва да се напише и линкерския скрипт правилно, ама...

Прикачвам ти моя скрипт, виж там rodata, linkonce, glue и т.н.

Е това GNU направо ме хвърля му музиката. Ебати ташака. Задълбах малко повече на проблема с тъпото съобщение на линкера за FP. Значи следния код:

се компилира нормално.

Но ако заменя последния байт на последния масив с 0x00 - избива онова тъпанарско съобщение. Майката си трака.

Що си губиш времето

Ползваш нещо на което изрично е написано "не става за Cortex", а ти се опитваш да го подкараш въпреки всичко....

Аaaaa зарязвам го Минавам на CodeSourcery, да видим там какви изненади ще има. Ето една дето я хванах само със случаен поглед след 3 мин работа:

Простичкото DMA1_Channel5->CNDTR = 3;

се компилира като:

CS:
0x0800069e <InitDAC+22>: movw r3, #88 ; 0x58
0x080006a2 <InitDAC+26>: movt r3, #16386 ; 0x4002
0x080006a6 <InitDAC+30>: mov.w r2, #3 ; 0x3
0x080006aa <InitDAC+34>: str r2, [r3, #4]

yagarto:

0x080005ca <InitDAC+10>: ldr r2, [pc, #296] (0x80006f4 <InitDAC+308>)
0x080005cc <InitDAC+12>: mov.w r3, #3 ; 0x3
0x080005d0 <InitDAC+16>: str r3, [r2, #4]

:):) без оптимизации естествено Първото изглежда като написано от класически пикоборец



Какво говориш бе човек. Още на О1- кода става пълен с черни дупки - влизаш тук, излизаш там..... мамата си трака.

На -Os става още по-весело, премахва функции, unroll-ва цикли и като код може изобщо да не прилича на това което очакваш

Но аз не му давам много талаш, пиша кода достатъчно стегнат и то няма какво толкова да оптимизира...
Както може да забелеш от горните ти примери АРМ му куца работата с паметта. Груба грешка е да бачкаш с глобални променливи. Сам виждаш - за да сетне една променлива с константа 3, CS-то ти е нашматкало 2 четирибайтови инструкци + 2 двубайтове. Общо 12 байта код, който ще се изпълни за 5 клока. При ягарто пък имаш 3 двубайтови инструлции + 4 байта константа, общо 10 байта и се изпълнява за 6 клока... А пък ако беше ARM-моде ягартото щеше да е 16 байта
Като за "конктролер" е просто ужасно зле, ако за да сетнеш една променлива с еднобайтова константа ти трябва 16 байта код и 6 клока

За щастие ако правиш нещата правилно не се стига до подобни изцепки... Избягвай глобални променливи, особено единични такива. Ако имаш някакви глобални данни, първо ги групираш в една структура и подаваш указател към нея на всички функции дето им трябват някакви данни. АРМ работи читаво с указатели.
Другото е да се съобразяваш с calling конвенцията и до 4 параметъра на функция е ОК, още по-добре е да са по-малко... Освен ако не правиш static функции - тогава GCC заебава конвенцията и може да ти оптимизира параметрите....
Самите функции е желателно да не са прекалено сложни и да боравят с не повече от 5-6 променливи и параметри в рамките на един контекст. Тогава всичко минава на регистри като включиш оптимизация и да сетнеш променлива с 3 става 1 инструкция от 2 байта код и се изпълнява за 1 клок.... Бих казал, че има "малка" разлика между глобална и локална променлива
Дори и да са глобални данни, т.е. промнливата ти да е елемент от структура, ако си бачкаш с указатели имаш 2 инструкции по 2 байта, общо 4 байта код, който се изпълнява за 3 клока... Пак не е толкова зле

Да това го установих още навремето когато за първи път пипнах ARM7TDMI. Тогава направо бях втрещен. Все пак на един смешен PIC писането в РАМ отнема един клок , докато на "мощния" ARМ направо си е цяла пиеса Определено работата с паметта им е слабо място. Все още имам проблеми да портна код който с лекота е летял на пик, за АРМ при 5 пъти по бърз клок

Ама приел съм го за даденост. Апропо - въпросната глобална променлива в примера е част от структура. В интерес на истината при О2 (по нагоре не съм пробвал), компилатора прави доста хитрини за да я докопа. Друг е въпроса, че веднага изгърмя, защото кода в тази функция стана по-бърз, а това се съчета с една неприятна "особенност" в SPI на контролера който ползвам

Но определено мога да кажа, че качествата на компилатора са от определящо значение при работа с АРМ. При "нормалните" контролери, компилатора не може да помогне кой знае колко за оптимизации. Докато тук, полето за изява е безгранично.

От тая гледна точка се чудя, дали GCC е добър избор, ако пренебрегнем комерсиалната страна. Все пак едва ли тимът разработващ GreenHills или IAR може да бъде сравняван с GNU ентусиастите, още повече че по конкретния порт едва ли работят кой знае колко много хора, при това мотивирано (срещу долари).

Като ми остане повече време, ще пробвам да сравня IAR и GCC да видим кой-какво..... От друга страна Rowley и Keil имат среди върху GCC, но не знам дали е сурово или е "пипнато". Всъщност сега гледам че последния Rowley работи със сурови GCC и Binutils и математики. Но имат собствен runtime - което е и май най-ценното. Предполагам че не дават сорс кода като купиш лиценз

Сравняваш ябълки с круши...
С GreenHills не мога да сравня, защото не познавам техния компилатор... Но ги познавам като фирма щото известно време ги лъгах че ще им ставам клиент за дебъгерите и емулаторите им. Мога да кажа че не са ми по джоба, защото при демонстрациите и при приказките с тях направо ми скриха топките. Хората са наясно какво правят, как го правят и защо го правят. С две думи много добри професионалисти. Не мога да ги сравнявам с GNU изобщо.

За IAR знаеш... мнението ми е отваратилно за тях. И продуктите им са дърво и като хора са пълни аматьори по-голямата част от екипа им. Пълна противоположност на Greenhills.

За GNU нещата са дълбоки. Не си прав че се прави от "ентусиасти" обаче... Има и такива, но някои от инструментите при GNU се разработват с яко финансиране и от много добри специалисти. Лошото е, че GNU е и ще си остане съвкупност от много инструменти и само един да е кофти, ти ще намразиш всички щото няма да можеш да си свършиш работата.

КОнкретно за компилатора... В GNU предполагам знаеш че има фронт енд за езици и лексиката е универсална. В това число и част от опимизациите които са на високо ниво. Ползва се стандартен анализ на алгоритмите на твоя код и то същият сериозен анализ както и когато компилираш примерно Linux. Така че за оптимизациите от високо ниво може да се каже че са повече от добре направени. При IAR примерно подобни неща направо липсват - няма ги...
Друг е въпросът че бак-енда за ARM не е толкова добре направен. Особено ако го говорим за Thumb режим там вместо да оптимизра на места вкарва глупости... Изглежда направо смешно - на високо ниво разбива и оптимизира алгоритъма, а пък на ниско елементарните неща ги осира...
Ако се оправи бак-енда ще дава много по-добри резултати от IAR, но и така не бих казал че е по-зле. Ако гледаш твърденията на IAR ще ти кажат че правят по-добър код, но това се получава само за прости функции където алгоритъма няма как да се оптимизира.
Иначе за runtimе-а или стандартните библеотеки няма какво да говорим. Гледал съм IAR-ските сорсове и си личи че те просто са пипнати като за малък контролер. Докато ти ползваш newlib дето е универсален и почти изцяло С-код. Аз затова не ползвам нищо от библиотеките, всичко съм си го напраскал директно на асемблер.
Но тук въпросът е какво гониш... ако толкова искаш да имаш най-бързите и най-прости библиотечки ще ти дам моите. Гаранция че са по-добри от IAR-ките и то на места в пъти...
Но ако искаш универсална библеотека, стандартните на GNU са си стандартни... знаеш че какъвто и професор да сложиш утре пак ще може да ползваш същата библеотека, а не като мен да се чудиш къде да си завреш асемблера