__low_level_init (void), Объясните пожалуйста Опции

[condor]

Для чего стоит использовать функцию __low_level_init?
В EW430_CompilerReference.pdf я нашел такое:
Customizing system initialization
It is likely that you need to customize the code for system initialization. For example,
your application might need to initialize memory-mapped peripheral units, or omit the
default initialization of data segments performed by cstartup.
You can do this by providing a customized version of the routine __low_level_init,
which is called from cmain before the data segments are initialized. Avoid modifying
the cstartup file directly.

Судя из этого, всю периферию надо инициализировать в __low_level_init.
Объясните, плз, правильно ли я понял?

[Danilov]

Пример, когда вам вроде бы не хочеться использовать __low_level_init, но придется
http://electronix.ru/forum/index.php?showtopic=4298

Проблема оказалась именно в инициализации большого блока памяти.
Во время которой сработал watchdog.

[rezident]

Пример, когда вам вроде бы не хочеться использовать __low_level_init, но придется
http://electronix.ru/forum/index.php?showtopic=4298

Проблема оказалась именно в инициализации большого блока памяти.
Во время которой сработал watchdog.

В той ветке не было подтверждения, что причиной подвисания был WDT. У вас у самого были реальные случаи срабатывания WDT при инициализации памяти? По моим грубым прикидкам получается, что инициализация даже 10кБайт занимает времени меньше (примерно на 20%) периода срабатывания WDT при его настройках и тактировании по умолчанию (то бишь после PUC или POR).

Сообщение отредактировал rezident - Aug 21 2006, 16:06

[Kurt]

В той ветке не было подтверждения, что причиной подвисания был WDT. У вас у самого были реальные случаи срабатывания WDT при инициализации памяти? По моим грубым прикидкам получается, что инициализация даже 10кБайт занимает времени меньше (примерно на 20%) периода срабатывания WDT при его настройках и тактировании по умолчанию (то бишь после PUC или POR).

Вот запустил в симуляторе программу для 1611. Поставил точку останову на main(). По бряку имеем 77842 cycles (при этом это не С++, т.е. без вызова конструкторов глобальных объектов). Таким образом, получается 77842 * 800kHz = ~97мс. Учитывая дефолтные ~32мс для watchdog, гарантированно имеем PUC, если не настроим/отключим тактирование/ватчдог в __low_level_init

[rezident]

В той ветке не было подтверждения, что причиной подвисания был WDT. У вас у самого были реальные случаи срабатывания WDT при инициализации памяти? По моим грубым прикидкам получается, что инициализация даже 10кБайт занимает времени меньше (примерно на 20%) периода срабатывания WDT при его настройках и тактировании по умолчанию (то бишь после PUC или POR).

Вот запустил в симуляторе программу для 1611. Поставил точку останову на main(). По бряку имеем 77842 cycles (при этом это не С++, т.е. без вызова конструкторов глобальных объектов). Таким образом, получается 77842 * 800kHz = ~97мс. Учитывая дефолтные ~32мс для watchdog, гарантированно имеем PUC, если не настроим/отключим тактирование/ватчдог в __low_level_init

ОК. Спасибо. Буду иметь в виду.

[Danilov]

>>В той ветке не было подтверждения, что причиной подвисания был WDT. У вас у самого были реальные случаи срабатывания WDT при инициализации памяти?

На уроке:
- Гоги, докажи теорему.
- МАМОЙ КЛЯНУС!

Если бы не было, я бы об этой функции тоже ничего не знал, не нужна была бы она нам.
Самое неприятное тут что пока программа относительно небольшая, то все ОК, но в один прекрасный день когда ты ее полгода уже пишешь и все железо отлажено, а все порты давно
корректно проинциализированы это случаештся и ты сидишь и думаешь "А ГДЕ ГРАБЛИ ТО?"
ну добавил очередную глобальную или статическую переменную и БАЦ (вернее PUC) - висим, убрал и опять работает.

Где точная граница мы выяснять не стали, (тем более что зависит от версии библиотеки)
но у меня это МЕНЕЕ половины RAM на MSP430F169.

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