ясно. Със секции си става. Ама що пък трябва да е лесно, като може и да е сложно

Да указваш на ниво сорс адреси няма особен смисъл (какви ще ги върши линкера тогава) и не прави нещата лесни.

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

Всички комерсиални среди с които съм работил го правят това директно на ниво сорс - ръгаш location=нещо си и забравяш.... Какъв е проблема? Естествено тогава това чудо наречено линкер скрипт език започва да се обезмисля, а това би било кошмар за GNU гилдията. Сакън, как така няма да имат линкер скриптове

Всъщност 90% от потребителите на комерсиални среди, даже не знаят, че съществува такова животно като линкерски скрипт. Просто указват процесора на средата и почват да пишат

То това с линкерския скрипт нямаше да е толкова страшно ако имаше човешка документация. Ама документацията на ld е такава каша, че само човека който я е писал, може да намери вътре каквото му трябва

Цецо спри се. Плашиш хората. Нещата не са толкова лоши.
Щом като ламер като мене успя да намери документация, да я разбере и да си пише сам линкер скриптовете от нула не е такава каша.
Какво толкова сложно има в описването на една секция?

Цецо е прав за някои неща, ама няма как да стане... и хората не искат да става

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

Ако избереш някой комерсиален продукт ще имаш точните инструменти и #pragma location и т.н. Но тия неща ще бачкат само на това нещо, защото те са си НЕСТАНДАРТНИ. Утре ако тръгнеш на нещо друго и трбябва да преправяш всичко. Просто неща като location си зависят от таргета - дали ти е фон нойман, дали имаш предвид вирутална памет или физическа, страници, банки и т.н.
GCC идеологията е да се гони стандартизация и правят всичко възможно да ти стъжнят живота ако тръгнеш да излизаш от коловоза... Това е нормално щото едно нещо не е ли стандартизирано и всеки прави каквото си иска става манджа с грозде, а пък GCC-феновете по принцип са много и без друго забъркват големи манджи...

От друга страна GCC се развива предимнно от и за големи фирми, където хората си имат разделение на труда - един пише С и пише чисто С, друг прави мейкове и линкове.. Абе изобщо има много обесняния и логика защо всичко е така.

Все пак ако решиш да излезеш от коловоза можеш да го направиш - дефакто с GCC може всичко да направиш, стига да си достатъчно упорит
Въпорсът е че по принцип не е добра идея да разполагаш кдето ти падне разни неща... Буквално залагаш бомбички.

Ми в случая нищо опасно няма. Просто по изискване (незнам откъде дошло), версията на фирмуера трябва да се вижда като стринг в края на bin файла. Идеята е в пройзводството, при програмиране, лесно да се разпознава версията независимо от името на файла. В което има логика.

Както и да е - със секция номера минава.

Абе подходът със секции никак не е лош, замисли се само сорс кодът ти ще изглежда по един и същ начин, независимо дали проекта ти е за PIC или за някой многоядрен паралелен дзвер, дето идея си нямаш каква му е организацията на паметта.
Всъщност ти дори няма нужда да слагаш нищо в сорса ако е само версията. Mоже в мейка да си сложиш скрипт дето вика cvs, парсва резултата за да извлече ревизията, подава я като параметър на линкера и тоя добавя към края на фърмуера ти... Не че те го препоръчвам де, щото това са излишни сложнотии. Ама в крайна сметка ако е някаква традиция във фирмата - правите го веднъж и после го ползвате за всякакви проекти с GCC - почти *независимо* какъв професор ползвате...

Имам и аз едно питане, от спортна злоба:

Как, аджеба, да накарам тъпия линкер да сложи един масив на точно определено място във флаша (чипа беше някакъв по-елементарен STM, май 101-нещо си)?
С дефиниране на област от флаша и използване на секции не ще - слага го в рам-а



В крайна сметка в пристъп на ужас и безумие стана с това:

Става, само че не го слага на адреса, който съм сложил, а го отмества (вместо на 8007C00, го слага на 8007D0C). В случая върши работа, 'щото е в същия сегмент, но не е чисто. В крайна сметка "проектът" мина и замина, но това отместване не ми дава да спя спокойно все още...

Това всичкото е с GCC, "пакетирано" в най-гнусната среда на света (поне аз по-гнусна не съм виждал, може би съм се разлигавил с IAR) - Ride7, която "уж" е безплатна, само че може да дебъгва до 32к, за повече искат много кеш (и целия бой с GCC-то се обезсмисля, поне за мен), но това бяха пратили и с това трябваше да си блъскам главата...

форума е за микроконтролери все пак, на пецето хич не ми пука кое на какъв адрес е, ама на микроконтролера ми пука.

Змийо, вземи се порови малко в нета - помага по някога!
http://support.code-red-tech.com/CodeRe ... serveFlash
http://www.stm32circle.com/forum/viewtopic.php?pid=4686

Да указваш на ниво сорс адреси няма особен смисъл ...[/b]

Не знам как си дефинирал uc8, но по принцип ти трябва "const uc8" ако искаш да го разположиш в read only секция...



В случая инициализираш указател, не разполагаш нищо никъде... Най-вероятно си направил някаква каша като на едно място декларираш масив, а на друго място указател със същото име.



Може да спиш спокойно

LD-то създава секциите на адрес на който му кажеш. Ако няма проблем със storage типа, компилатора разполага нещата в секцията която си указал. А пък "отместване" обикновено се получава, когато по невнимание сложиш повече от 1 обект в дадената секция. Винаги е добре да си пуснеш един листинг и да видиш какво къде е разположено...
Най-сигурният начин да сложиш даден обект на определен адрес е да направиш специална секция само за този обект, т.е. да не слагаш нищо друго в тая секция. Ако ще слагаш повече обекти в една секция може да ползваш сортиране (SORT() ) по име на секция/под-секция. Сортирането обикновено се ползва когато искаш нещо да се разполага след друго нещо, но трябва да внимаваш по какво точно ти е сортировката...

Миро, в това "дрВо" uc8 е тайпдефнат "const unsigned char". Предполагам, че бях омазал нещо фатално по скриптовете, че да го набие в рам-та, ама това вече е абсурд:

В момента работи с ей това простичко нещо - декларирам си буфера като uc8 без никакви атрибути (нормален неинициализиран стринг, който да набие във флаша - uc8 FlashBuffer[BUFSIZE];), и в скрипта (секцията на флаша) по най-дърварския начин му казвам "FlashBuffer = 0x08007C00;". Засега работи, само че и в map-а, и като дебъгвам, указателя за начало на масива не е на 0x08007C00, а на 0x08007D0C ?!?!?!
В момента ме устройва, защото го набива само в един сегмент (последният въф флаша), и съответно не се налага да трия два при промяна на данните. Проблемът, който ме дразни и затова казвам, че не е чисто, е, че в момента програмката е тъпа и миниатюрна - не стига и половина флаш; ама по принцип трябва сегментът, в който си пиша глупостите, да може да бъде защитен от ръгане на код (и каквото и да е други данни), а да може да си се ползва само за "глупостите". Това по "дърварския" начин не мога да направя.

А с това:

не съм съгласен - най-малкото е предпоставка за грешки.

Човеко, правиш някакви свободни съчинения...




uc8 FlashBuffer[BUFSIZE]; - това декларира масив, който трябва да бъде разположен в data секция. Компилаторът няма представа за флаш и "набиване" във флаш...

Грешките тук са много... първо декларираният обект НЕ Е const и затова линкерът трябва да го разположи в data, а тази секция си е с read+write атрибути и би било глупост да я слагаш във флаш...
Второ, нямаш указано нищо, така че линкерът може да разположи обекта където и да е било в дата секцията.




Това декларира символ. Символите имат само стойност, но те НЕ СЕ разполагат НИКЪДЕ. Просто стойност!
Няма никаква връзка между "символа" FlashBuffer със стойност 0x08007C00, който си декларирал в линкерския скрипт и "обекта" масив, който си декларирал в сорса... Всъщност има връзка - и двете са с еднакви имена, но иначе са си две съвсем различни неща...


То работи, ама май не както ти си мислиш

Сега ето ти тук документацията на линкера http://sourceware.org/binutils/docs-2.2 ... ssignments
Обърни внимание на точката Source Code Reference...



Правилният начин за това е да си направиш секция за глупости, която в линкер скрипта да укажеш къде се намира във флаша.... Гледай тая секция да не се бие със секцията ти за код (text) ли за константи (rodata). Линкерът няма да разположи код или други глупости в твоята SHIT секция, докато ти не му кажеш изрично... Това става по следния начин в сорса:




Има и алтернативен вариант - в линкерския скрипт да декларираш символа FlashBuffer, да му присвоиш като стойност началния адрес където искаш да е масива. Да се погрижиш това място да се заеме и евентуално да се инициализира с fill или нещо друго. А пък в сорса да ползваш това:

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