Всем привет!

В keil есть возможность нажав на файл исходников правой кнопкой и выбрав options, для Cortex процов задать регионы для секций Code/Const, Zero Init Data, Other Data

по умолчанию стоит default. И я был уверен что это для Code/Const - flash, а для остальных RAM. Так вот поглядел я карту памяти после компиляции и с удивлением обнаружил что достаточно большая часть функций размещены в RAM. Но не все, то есть получается что у кейла есть какая-то стратегия размещения функций? Кто нибудь, что нибудь знает про это?

Еще я обнаружил что кеил понаделал thumb код, хотя я думал по умолчанию будет ARM код, и только при желании оптимизации он будет что-то крутить. Или после появления thumb2 стало уже не можно пользоваться ARM кодом? Я понимаю что с точки зрения флеш ускорителей которые читают за 5 тактов проца 128 бит, лучше прочитать ~8 thumb инструкций (примерно потому что в thumb2 они бывают и 32 битные) чем 4 ARM инструкции, для этого преимущество отдано thumb коду?

Маэстро, если речь идет о Cortex, то только Thumb-2. Даже если и 32разрядные всё равно Thumb. Никаких ARM.

Вот блин... всегда читал строчку из манула

считая что типа второй тумб вместо первого, и считал что это в добавок. И что-то даже не поглядел что АРМ набора вообще больше нету...
С этим разобрались, спасибо.

А про стратегию функций кейла кто знает где глянуть?

Нету никакой стратегии. С настройками по умолчанию все функции идут в флеш. Ну а если начинаете что-то крутить - это уже на вашей совести.

А если не крутил, а половина функций на файлах которых стоит Code/Const - default оказались в РАМе, то что делать?

есть файл у которого ZI о other стоят в рам перенести, но код в дефолте, а функции из него все равно в РАМ попмали...

Какая то видать стратегия есть, причем в некоторых файлах часть функций во флеше осталась, а часть в РАМе.

MAP-файл - в студию!

И .scat тоже

и тип процессора.

Lpc1768, scart по умолчанию, то есть какой кеил сам генерит. Мар сейчас не могу, но по нему фугкции лежат в раме с 2000... Ажреса.

Все равно приложите, иначе концов не найти.

вот такое вот... FIFOModule в свойствах стоит запихать его в RAM и он там.



а вот для MyMAC - это езернетныймодуль, для него Code/Const стоит в дефолт, только данные и ZI в рам, а он тоже почему то хором попал в РАМ



я вижу что в скатере все его секции туда запхались, но вопрос какого лешего? Скатер генерится самим кейлом, то есть я его в папке открыл, в среде к нему даже доступа нет. Вот такие чудеса...

Вот поэтому и не стоит программировать "галочками" - чудес меньше будет.

Предлагаете читать мануалы? Мануалы придумал трус!

Читать даже не предлагаю, но открыть и сделать Ctrl-F всегда можно.

Я только За, но многим удобнее галочками (не один же я работаю на проектом)... Справедливости ради надо заметить что хуже работать не стало , то есть функциональность сохранилась...


Вы тут ни разу неправы. Если у вас среда типа какоса или IAR, то там есть явно представленный скатер файл, который заполняется руками или генерится визардом. А если у вас keil, то править руками скатер файл - это бороться с ветряными мельницами, он же будет его подменять. Да там действительно можно снять кучу галочек и перейти на полностью ручное управление, но изначально в галочной системе есть какой-то workflow который можно, а современных реалиях и нужно использовать, потому что сокращает время.

Так что наезд в данном случае не принимается, мануалы тут не причем.


вы тоже не правы, потом что в мануале то как раз про галочки расписано как должно быть, а по факту получается иначе. Может в кейле есть еще какие-то способы дать указания разметке, про которые я не знаю....

Но великие читатели мануалов могут снизайти и указать ничтожному где про это написано...

Ну как же? Вы же уже сказали, что

Вот и ищите среди них любителя тыкать в галочки


ЕМНИП, у кейла файл проекта (где хранятся эти галочки) пишется открытым текстом. Полистайте, может быть увидете, где именно галки спрятались.

Давайте перестанем пытаться меня поддеть и сосредоточимся на тексте

есть в проекте 2 файла.
1. стоят галочки разместить в RAM: code, ZI, Other
2. стоят галочки разместить в RAM: ZI, Other

по какой-то причине для обоих файлов секция text попала в RAM, вот меня и интересует что на это могло повлиять. То есть может быть если функции первого файла стоят в раме, и вызывают функции второго файла, это как-бы тоже переносит их в RAM. Может есть какие-то стратегии оптимизации, которые функции какого-то размера или частоты использования переносят в RAM. Или переменные перенесенные в RAM и используемые в функциях тоже их с собой потянули (хотя константы вроде как идут в первой секции, а осnальные и так обычно в RAM)

Вот каким вопросом задаюсь я, а не тем почему галочка появилась...

Раньше отключалось легко и непринужденно, одной галочкой

Ничего не сокращает - десяток строк проще руками написать.


В Вашем случае все сделано в соответствии со скаттером. Соответственно, никакие стратегии оптимизации ни при чем совершенно.

не о том разговор..

В общем заключаю что это скорее баг чем фича. То есть должно было работать так, а получилось иначе, и никакой магии... ну и ладно, обычная ошибка....

интересно для LPC1768 есть выигрыш от запуска функций из ARM, он же 100 МГц, а читает за 5 тактов чуть ли не 8 инструкций, и имеет несколько блоков для сохранения считанного...


тогда возникает вопрос почему скатер сделан не согласно настройкам...

Это или глюк среды, или где-то среди галочек что-то осталось незамеченным.

удивитесь, наверное, но и по сей день ничего не поменялось
Нажмите для просмотра прикрепленного файла
я уже давно отключаю автоскаттер и сам указываю, что где хранить, если это мне нужно

ну а смысл тогда кейла если все по отключать и руками вбивать?

У кейла хороший отладчик.
А вообще, если какая-то свистелка-перделка к нему прикручена, ей совсем не обязательно пользоваться.

Но также не обязательно отказываться, если она мелодично свистит) В 90% случаев она работает как надо, будет посвистывать...

ровно также отладку в порт никто не отменял)

это дает точное знание о том, где что будет лежать. Даже в этом топике пришлось перелопатить кучу всего, в результате придти к тому же скаттеру.
Кстати, описание именно его лежит в одном документе с линкером на инфоцентре арма, а не галочек кейла, странно - почему?

Всегда ли оно надо знать? Вот мне это интересно в моем проекте, но не критично, что в РАМ что во флэш он работает штатно. И я думаю еще с десяток такого рода проектов можно сделать. Иногда это нужно, там можно и руками, а иногда нет, там на автомате быстро прокатит.



Ага а библиотеки HAL от кейла несмотря на свою кривость завоевывают все больше популярность. Так же уверен вы пользуетесь виндусом, а не командной строкой доса?

Я сам сторонник того что надо прописывать биты в регистры а не тыкать галочки в среде, но иногда это здорово сокращает время "на быстренько попробовать", так чего бы не овладеть данной функцией? Что вы потеряете если будете знать больше путей? Вот я теперь знаю, что данная часть не совершенна, и за ней надо следить, но если не парит можно пользоваться.



Знание о том что скатер засунул функции в РАМ не дает ответа на вопрос какого черта в скатере появилось задание так сделать, так что это не аргумент.

Не знаю как для других, а для меня скрипт линкера является неотъемлемой частью исходных текстов проекта. Его можно один раз сгенерировать средой, но затем содержимое лучше зафиксировать и править только руками. Автоматы хороши только для быстрого старта в незнакомом окружении.

+
генерится скрипт, отключается галка, чтобы кейл его не портил каждый раз, и включается в svn
кейловыми галками тоже не все так гладко, он включает весь модуль целиком в область, а если мне это не нужно?

Ну может вы и правы. Тем более что за время жизни проекта этот скрипт редко меняется, в целом если жмет и руками лень, можно опять же кейлом перегенерить.

Спасибо всем участникам беседы.

А вот мне тут подумалось. Кроме того что сказать линкеру разместить функцию в RAM, надо же еще где-то написать копирование данных из адреса флеш, в тот адрес где разместили функцию. Сама же она туда не перелезет. В технологии галочек за этим кеил следит, чего то теперь мне эта технология стала казаться опасной...

Так собственно линкер это и делает.

у кортексов встроена функция переброски памяти?

Линкер создаст таблицы и подцепит необходимое.

А в какой момент будет копирование? до ресета что ли?

Не знаю как делает Кейл (а вам влом посмотреть листинг?), я копирую заодно с инициализированными переменными.

До перехода на main(). Поинтересуйтесь, например, содержимым InRoot$$Sections.

В IAR я тоже все руками делал, правда для 7 арма, а тут кортекс и с кейлом разленился.


Поглядел что на векторе ресета инициализация клоков и переход в маин. 2 функции вызываются одна за другой.



я не против того что и как по секциям линкером распределено, но когда питание выключено оно все во флэшке, а потом должно в рам перелезть, и вот в какой момент что-то я в замешательстве.

UPD.
отгадка в том что __main - это не main? ну да там же и все копировщики и инициализаторы вызываются, но текст их не доступен... означает ли что если я делаю файл для линкера руками, то я должен и руками все эти копировщики поправить, а то беда может быть.

Не надо ничего руками трогать, оно и так хорошо работает. Линкер создаёт специальные символы, по которым этот __main() инициализирует RAM.
Помнится, в скаттер-файле можно легко ошибиться - всё собирается, но этот __main() копирует данные вечно.

PS почти всегда пользовался автоматическим scatter'ом. Максимум, что мне надо было - "откусить" кусочек flash под загрузчик, это галками сделать легко.
Для более сложной конфигурации (вспомнить бы, зачем мне потребовалось раскидывать функции по RAM, да ещё с жёстко заданными адресами..) пришлось изрядно почитать, и заработало оно не сразу.

Именно так: __main и main - это разные вещи.


Нет, все сделает линкер.


Ошибиться и в программе можно, но какой же это аргумент?

Структура у скаттера очень простая и наглядная. Возможные "хотелки" на раз находятся в документации.

линкер он кому принадлежит? Это же часть кейла? то есть у другой среды он может быть реализован иначе? Или же он как-то стандартизован на уровне ARM?

Линкер является частью RVCT, т.е. относится не только к Кейлу, но и к прочей продукции ARM.
У IAR, GNU, GreenHills и прочих решения свои, но общие принципы одинаковые.

То есть на самом деле стандартизован на уровне ARM...

спасибо за пояснения...

почему недоступен? отладчиком все прекрасно видно
ничего править руками не нужно. Как в скаттере расписано, так линкер сам и соберет в нужных областях. Что нужно - проинициализирует, что нужно - скопирует
а так оно да, __main != main, после как раз восстановления областей на своих местах управление передается на main()