Run-time библиотека Си++ вызывает конструкторы глобальных объектов ещё до начала выполнения функции main().
Хотелось бы, чтобы в этот момент необходимая периферия контроллера уже была проинициализирована, дабы код конструкторов не был ничем ограничен.
Но как это сделать в RealView? Никаких __low_level_init() я в руководстве компилятора не увидел...

ЗЫ: приятно обновился интерфейс форума

Вставьте вызов иеициализирующей функции в startup после инициализации стека. Все.

Ага, спасибо.
Я уже подумал про асмовый стартап. Можно, наверное, поставить BL прямо перед вызовом __main. Даже стёк инитить не надо - он грузится автоматически с нулевого адреса таблицы векторов.

А есть ли какие-то ограничения у такого способа? В смысле не лишкануть бы чего в подпрограмме пре-инициализации

На сайте atmel'a лежат свежие версии soft'a для sam процессоров (http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=11318&family_id=605). Там, например, есть проект basic-emac-uip-telnetd-project-at91sam9263-ek-keil, а в нем файл - board_cstartup_keil.s. Из него вызывается функция LowLevelInit() как раз до вызова main().

А можно привести здесь эти строки? А то качать 40 метров слишком накладно...

Типа Cortex-M3 ?

Ничего необычного нет.

А чем не устраивает main рассматривать как ту самую функцию настройки периферии, из нее уже запускать что-то еще.


Вам оно не пригодится. Между SAM'ом и Cortex'ом пропасть как раз в стартапе.


Конечно, можно. ;>

Для кортекса:


Сам же LowLevelInit объявите как void LowLevelInit(void) в любом .c файле.

Ага


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

Спасибо, так и поступлю.
Ещё вот интересно, для чего при переходе на __main юзать R0? А если просто B __main?

Если уверены, что сможете дотянуться до main 256*2 байтовым смещением, то можете.

До main хотя бы память должна ожить. Кроме того, тоскливо получается копировать/инициализировать эту память на медленных клоках, например.


А если __main далеко?

Лично я делаю так:

Вначале надо прописать ввод-вывод. Сколько гемора бывает из-за "неспешной" инициализации порта(ов),


потом - стек, типа low_level_init(), потом - секции, ремап и main()

Согласен, актуально для МК с кешем, внешним RAM, либо толстым Init RW сегментом.

В контексте кортекса, внешней шины часто вообще нет (оживлять нечего), а внутреннего RAM'a - с гулькин нос, поэтому и PLL настраивать до main'a ради инициализации пары KB переменных смысла особого нет.

Ну, еще для атмеловских SAM'ов, которые с 32kHz запускаются, тоже весьма актуально.


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

Угу, что правда, то правда.

Везде свой подход. Мне что-то подсказывает (соседние ветки), что проц, который использует автор топика стартует на нормальной частоте (явно больше 32kHz)
Иначе бы и не заикался на счет инициализации в main

Да у меня STM32. Стартует на внутреннем RC 8 МГц - вполне хватает, чтобы не слишком торопиться с PLL.
До этого был LM3S601, который я угробил, переназначив вывод житага на GPIO... есть ещё оказывается камни, которые убиваются софтовой ошибкой
Кстати, какая разница между внутренними RC генераторами этих контроллеров - с одной стороны 8 МГц +- 1%, с которого чип запускается после ресета.
С другой - 15 МГц +- 50%, запуск с которого невозможен, только после софтового переключения... на кой нужен такой генератор?
Видать, нет у Luminary индивидуальной калибровки... экономят-с...