Принимайте в свои ряды
Почитал про scmRTOS и она мне очень понравилась, начал изучать. Раньше сидел на uCos, но она достаточно монстрообразная, да и С++ хочется, ибо на нем есть уже куча своих библиотек.
В принципе, оно завелось и заработало, только не понятно, зачем нужно выносить инициализацию PLL, системного таймера и проч. в __low_level_init()? Там же имхо нет ничего критичного, что надо было бы обязательно выполнить до инициализации аппаратных стеков и переменных? Для пробы перенес весь код из __low_level_init() в обычную функцию main(), в самое начало. А именно, PLL, прерывания вообще (это уже свое собственное), системный таймер, прерывание смены контекста. Все работает нормально. Где скрытый смысл "влезать" в процесс инициализации камня?

Смысл наверно в том, чтобы отделить платформозависимую инициализацию от общей унифицированной программы

Сомневаюсь, что именно в этом. Что значит "отделить"? К примеру, программа использует несколько пинов для управления светодиодами. Безусловно, порт надо проинициализировать. Это будет "платформозависимая инициализация" или "общая унифицированная программа"?
Это я к тому, что "основная" прогрмма все равно делает инициализацию себя. Ведь ее никто в __low_level_init() или в cstartup.s не сует. Можно конечно, но зачем писать лишние буквы вроде указания сегмента ICODE и проч., если можно просто вместо
void main()
{
OS::Run();
}
написать
void main()
{
SystemInit();
OS::Run();
}

ИМХО __low_level_init() нужно менять, если мы хотим повлиять на инициализацию глобальных переменных, стеков и т.п. Возможно, именно это иногда и применялось авторами данной ОС. Вот я и задаю вопрос их опыту: когда может понадобиться ранняя инициализация?

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

Как-то на форуме этот вопрос уже поднимался. Принято, что к моменту вызова main() система была полностью инициализирована, как hardware, так и software.

Оно и понятно - main() может быть и осевым.
Только для софтового инита еще рановато -он должен вызываться прямо перед main()

Во-первых, на момент вызова __low_level_init() стеки уже проинициализированы.

Во-вторых, если мы разгоним PLL до иницииализации переменных, инициализация пойдет быстрее. AT91SAM7, например, стартует на ~32КГц.

В-третьих, __low_level_init() выполняется до вызова конструкторов статических объектов. Часто статические объекты описывают некие внешние устройства и очень удобно разместить в конструкторе инициализацию этого внешнего устройства. И к моменту вызова инициализации, скажем, spi_flash, набортный SPI уже должен быть настроен. spi_flash может быть унаследован от spi, но проводить инициализацию интерфейса в конструкторе spi некорректно, ибо от него могут быть унаследованы другие устройства и тогда инициализация будет выполнена несколько раз.

Спасибо. Именно об этой причине я и не подумал.

А ещё можно разместить переменные во внешней динамической памяти. Но при старте процессора контроллер DRAM ещё не работает поэтому иинициализация/обнуление переменных не сработает. Чтобы всё было пучком нужно в __low_level_init разместить инициализацию контроллера DRAM.

Ещё одно заманчивое предложение - разместить в DRAM стеки. Но с этим нужно осторожно. Текущий стек процедуры __low_level_init (стек System) может и не удастся там разместить (хотя если процедуру писать на асме, то можно рискнуть), а вот другие стеки вполне можно в DRAMе держать. Только с разрешением прерываний в __low_level_init поосторожней до инициализации DRAM.

Сообщение отредактировал GetSmart - Mar 1 2009, 06:19