Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Порт для Atmel ARM (IAR)
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > scmRTOS
gladov
Принимайте в свои ряды smile.gif
Почитал про scmRTOS и она мне очень понравилась, начал изучать. Раньше сидел на uCos, но она достаточно монстрообразная, да и С++ хочется, ибо на нем есть уже куча своих библиотек.
В принципе, оно завелось и заработало, только не понятно, зачем нужно выносить инициализацию PLL, системного таймера и проч. в __low_level_init()? Там же имхо нет ничего критичного, что надо было бы обязательно выполнить до инициализации аппаратных стеков и переменных? Для пробы перенес весь код из __low_level_init() в обычную функцию main(), в самое начало. А именно, PLL, прерывания вообще (это уже свое собственное), системный таймер, прерывание смены контекста. Все работает нормально. Где скрытый смысл "влезать" в процесс инициализации камня?
MrYuran
Смысл наверно в том, чтобы отделить платформозависимую инициализацию от общей унифицированной программы
gladov
Цитата(MrYuran @ Feb 25 2009, 10:22) *
Смысл наверно в том, чтобы отделить платформозависимую инициализацию от общей унифицированной программы


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

ИМХО __low_level_init() нужно менять, если мы хотим повлиять на инициализацию глобальных переменных, стеков и т.п. Возможно, именно это иногда и применялось авторами данной ОС. Вот я и задаю вопрос их опыту: когда может понадобиться ранняя инициализация?
_Pasha
Может, скажу очень недалекую вещь, но пользовался low_level_init() только для того, чтобы было меньше букафф для программирования вышеозначенной периферии на С вместо асма
sergeeff
Как-то на форуме этот вопрос уже поднимался. Принято, что к моменту вызова main() система была полностью инициализирована, как hardware, так и software.
_Pasha
Цитата(sergeeff @ Feb 25 2009, 10:48) *
Принято, что к моменту вызова main() система была полностью инициализирована, как hardware, так и software.


Оно и понятно - main() может быть и осевым.
Только для софтового инита еще рановато -он должен вызываться прямо перед main()
Сергей Борщ
Цитата(gladov @ Feb 25 2009, 09:16) *
Где скрытый смысл "влезать" в процесс инициализации камня?
Во-первых, на момент вызова __low_level_init() стеки уже проинициализированы.

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

В-третьих, __low_level_init() выполняется до вызова конструкторов статических объектов. Часто статические объекты описывают некие внешние устройства и очень удобно разместить в конструкторе инициализацию этого внешнего устройства. И к моменту вызова инициализации, скажем, spi_flash, набортный SPI уже должен быть настроен. spi_flash может быть унаследован от spi, но проводить инициализацию интерфейса в конструкторе spi некорректно, ибо от него могут быть унаследованы другие устройства и тогда инициализация будет выполнена несколько раз.
gladov
Цитата(Сергей Борщ @ Feb 25 2009, 11:05) *
__low_level_init() выполняется до вызова конструкторов статических объектов.


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

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