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 индивидуальной калибровки... экономят-с...

Не полагайся на порядок вызовов конструкторов, инициализаторов периферии и тд - легко словить грабли в дальнейшем.

У меня все сервисы имеют три стадии инициализации:

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

2) Стадия Init - здесь уже налаживаются связи между классами (к этому моменту все необходимые объекты уже созданы)

3) Стадия Run - запускается таски, разрешаются прерывания от периферии и тд - в общем, нормальная работа приложения

объекты глобальные, соответственно создаются до main. А в main я уже вызываю init и run.

Суть в чем - не полагайся, что кто-то что-то сделал заранее

Понятно, спасибо!
Хотя не всегда объект может иметь свою собственную периферию - в случае её совместного использования невозможно ввести полную инициализацию внутрь одного класса.

Это уже следующий шаг . Тут уже соблюдаю правило - на каждую периферию - свой объект (можно назвать драйвером).
Те работа всех объектов с УАРТом идет не напрямую, а через объект - драйвер УАРТ.
Или работа с езернетом - получен кадр - сервис-драйвер езернета отправляет его всем желающим (фактически в моем Enviromnet это выглядит как broadcast пакет. Чем-то идеология на CANbus похожа )

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

Да, синхронизация - дело хитрое.
Вот, к примеру думал тут недавно над одной задачкой...

В общем, есть два канала SPI. И три объекта, "висящие" на них.
Первый - цветной ЖКИ, скорость 12 Мбит, огромные объёмы данных, способен занять канал на длительное время. Самый низкий приоритет.
Второй - диск на флешке. Скорость высокая, но пакеты небольшие - сектора по несколько сот/тысяч байт. Средний приоритет.
И третий - к примеру - декодер МП3 (или ЦАП) или другой девайс с относительно маленьким каналом, но требующий быстрой реакции на запрос.

Как их уместить на одном/двух каналах SPI, чтобы не умереть от геморроя с разделением ресурсов?

Два варианта:

A) ЖКИ транзакцию прервать никак нельзя:
SPI1 - ЦАП и FS. (в худшем случае ЦАПу придется дождаться завершения передачи текущего сектора FS, но скорость FS выская поэтому ждать не долго).
SPI2 - ЖКИ.
Приоритет ЦАПа сделать более высоким чем приоритет FS.

Б) ЖКИ транзакцию прервать без потерь можно.
SPI1 - FS
SPI2 - ЦАП и ЖКИ
обмен с ЖКИ моментально прерывается процессом обслуживающим ЦАП, и возобновляется после.



FS и ЖКИ я бы старался не цеплять на один интерфейс, во-первых чтобы скорость SPI не переключать (SPI флеш может и на 25Mhz и выше свистеть), ну и чтобы снизить нагрузку на интерфейс, т.к. потоки данных (по суммарному объему) сравнимые.

Я бы сделал так: два объекта драйвера - ClSPI_Driver<SPI0> и ClSPI_Driver<SPI1>. Следующий шаг - выяснить, необходима ли атомарность передачи больших объемов к ЖКИ (те можно ли бить данные на мелкие пакеты). Если можно передавать только здоровыми кусками (соответственно, остальные девайсы на SPI будут курить бабмбук в это время, что недопустимо), то под ЖКИ придется выделять отдельный канал SPI. А остальные девайсы повесил бы на второй SPI.

Разделение приоритетов передачи данных на одном порту:
Создаешь в драйвере очереди запросов с различными приоритетами. И драйвер, закончив очередную транзакцию начинает проверять очереди и высылать данные в порядке порядке приоритетов. Те пока не высланы данные для декодера (real-time приоритет), не трогать данные для флешки - low-prioritet для этого канала.


Те в общем, механизм был бы такой - ЖКИ единолично работает со своим SPI + канал DMA (драйвер<1>). На втором канале драйвер<2> выгребает данные из low-priority очереди (для флешки). А отдельный таск (или обработчик таймера) периодически подкидывает драйверу<2> блоки данных для декодера, который он отправляет за время не худшее, чем максимальный_объем_пакета_для_флешки / скорость_SPI + время реакции драйвера.

В общем, как-то так

Спасибо большое! Буду руководствоваться вашими советами, когда, наконец, руки до этого проекта дойдут.
Вы мне очень помогли