работа с SRAM, AT91SAM7X Опции

[Sergei_K]

Собственно, хотелось бы работать со встроенной оперативкой SRAM для повышения производительности МК, и в связи с этим возникли вопросы..

Как я понял при прочтении даташита, по дефолту SRAM расположена в области 0x0020 0000 - 0x002F FFFF, а после ремэпа к ней можно обращаться по адресу 0x0..

Так вот.. при прошивке МК через самбу мы можем закинуть программу в SRAM, однако как дать понять МК, что он должен грузиться из памяти по адресу 0x0020 0000? В случае выполнения проги с флеш достаточно было выполнить скрипт загружаться из флеш.. для SRAM же такого скрипта нет..

Если же ремэпить, то не совсем понятна последовательность действий: нужно ли ремэпить прямо в основной программе и записывать ее в флеш.. или на флеш записать программу с ремэпом, а в SRAM кидать основную программу?

[Leen]

если я правильно понимаю, sct-файл создается при компиляции и включает в себя информацию, прописанную заранее в разделе Project/Options for target '...'/Target или Project/Options for target '...'/Linker.

Только, если не используется внешний scatter-файл. Мне показалось удобным сначала собрать проект "по-дефолтовому", а затем растиражировать и подправить scatter-файл для всех необходимых целей (у меня это отладка из рамы и прошивка во флеш - соответственно, разные диапазоны и длины областей ro и rw). А потом эти файлы начали кочевать из проекта в проект, иногда изменяя имя

Также при компиляции создается hex-файл, который мы затем шьем в МК..

Ну, это если нам надо хекс. Я пока обходился без него, прошивая из объектника с помощью кейла и рди. И, кстати, при компиляции з каждого исходника сооздается свой объектник, при линковке все объектные файлы сводятся в один объектный файл (он уже исполняемый, хотя содержит еще и немало мусора - для отладки, но тут я еще не силен - не дорос до тонкостей объектных файлов), а хекс получается сторонней утилитой, в случае кейла это $KEIL\ARM\BIN30\fromelf.exe.

Так вот собственно и непонятно: каким образом, в случае если мы вручную изменим sct-файл, это отразится на выходном hex-файле? Другими словами, что изменится в данной ситуации для МК?

Для МК изменятся числа, соответствующие адресам функций и переменных, - все имена переводятся в адреса. Так же, если, к примеру, стартап слинкован во флеш, а какой-нибудь файл - в озу, то (в районе _user_initial_stackheap) добавится копирование функций из флеша в озу (чтобы все работало). И если мы просто изменим файл, кейл не обидится и перезапишет его Файл ему еще и скормить надо не забыть.

Такой же вопрос с ini-файлом... Ведь конечный продукт - это hex-файл, тогда хотелось бы узнать подробней, что нужно сделать, чтобы информация об измененных sct и ini файлах добавилась в hex..

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