Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Зачем нужны *.mac и csturtup.s файлы
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
bureau
В IARe при отладке сначала код грузится с этих файлов. Собственно говоря что это дает?
sergeeff
Наверное все-таки из cstartup.s. Идея проста - выполнить все подготовительные операции, необходимые для старта главного модуля задачи - main() или какого-либо иного. Что конкретно делает cstartup - зависит от процессора, конкретного распределения памяти (ROM, RAM). И прочего ...

А что из комментариев в cstartup.s неясно что он делает и зачем?
bureau
А болие подробней описание каким образом организовуются эти "подготовительные операции, необходимые для старта главного модуля задачи - main()" можно услышать?
Вот например создаю я абсолютно с нуля новый проект. Передо мной только компилятор и датасшит на камень. Откуда мне брать информацию про создание startup кода?
HARMHARM
Цитата(bureau @ Jan 2 2009, 21:37) *
А болие подробней описание каким образом организовуются эти "подготовительные операции, необходимые для старта главного модуля задачи - main()" можно услышать?

Поиск рулит. Вкратце - для C нужно как минимум настроить стек. Для C++ еще всякое...
Цитата
Вот например создаю я абсолютно с нуля новый проект. Передо мной только компилятор и датасшит на камень. Откуда мне брать информацию про создание startup кода?

Из примеров производителя контроллера и производителя компилятора.
uriy
Обычно с компилятором бывают дефолтовые стартап файлы для контроллеров, которые он поддерживает. В Keil для ARM, например, есть даже подобие визарда для редактирования этого файла.
rvk
Цитата(bureau @ Dec 30 2008, 00:27) *
В IARe при отладке сначала код грузится с этих файлов. Собственно говоря что это дает?


IAR\процессор\src\lib\startup.s90 исходный код файла.
Все что он делает, это затирает нулем все переменные из сегмента DATAZ, и
инициализирует глобальные переменные теми значениями, которые указаны
в программе, плюс настраивает стек.
В любом случае все эти операции программисту пришлось бы делать.
Ничего такого сверхъестественного этот код не далает.
И по моему, на него внимание обращать нет смысла.
sergeeff
До поры до времени можно и не обращать, пока ваша задача не перешагнет некий default'овый порог сложности. И если не разобраться в том, что к чему в этом самом startup'e, в один "прекрасный" момент все грохнется, о чем свидетельствуют многочисленные "гласы вопиющего" на нашем форуме.
rvk
Цитата(sergeeff @ Jan 8 2009, 21:09) *
До поры до времени можно и не обращать, пока ваша задача не перешагнет некий default'овый порог сложности. И если не разобраться в том, что к чему в этом самом startup'e, в один "прекрасный" момент все грохнется, о чем свидетельствуют многочисленные "гласы вопиющего" на нашем форуме.


Может просветите, раз уж такие страхи нагоняете.
С другой стороны вот пример из инета http://en.mikrocontroller.net/topic/149982.
Суть в чем, человек пишет, с startup.s взятым из проекта от Atmel моя программа не работает, они все такие и сякие.
На что ему Martin Thomas отвечает, вообще то такие вопросы хорошо бы в IAR отправить, но раз
уж вы спросили, отвечаю, в вашем startup.s код загрузчика "закомментирован" (во как).
Вы говорит, по прежнему уверены, что это код Atmel:)
sergeeff
Речь идет, к примеру, о размерах стеков для вашей задачи.


К тому же, приведенный вами пример, как раз демонстрирует тот факт, что человек не понимает как устроен startup для конкретного компилятора и от этого начинает рассылать письма с вопросами.
rvk
Да стек важная штука, и если его не хватит, мало не покажется, но он настраивается прямо в проекте.
Кто мешает настроить размер стека в опциях проекта, не залезая в startup.s.
sergeeff
Вы задаете вопросы безотносительно какого-то конкретного процессора, задачи (C или C++), конфигурации системы, использования динамической паняти и пр. И хотите получить ответ на какой вопрос? Если что-то устанавливается в проекте и вас больше ничего не интересует, т.е. тех настроек, которые реализованы в стандартном startup'e достаточно, ну и отлично. Пишите свой проект на здоровье.

Тем не менее хорошим тоном считается, что вся необходимая soft и hard инициализация была выполнена до вызова main.
rvk
В чем смысл закладывать все в startup.s, если он запускается до main.
По другому поставлю вопрос. Какая разница, проинициализирована периферия в startup.s файле или в main.c
ek74
Цитата(rvk @ Jan 9 2009, 11:58) *
По другому поставлю вопрос. Какая разница, проинициализирована периферия в startup.s файле или в main.c


А если Вы пишите на C++, и у Вас есть глобальные статические экземпляры некоторых классов (конструкторы таких объектов вызываются ДО main). И самое главное - эти объекты должны работать с железом. В этом случаи инициализация периферии в main будет как на бане гудок.
rvk
Цитата(ek74 @ Jan 9 2009, 12:36) *
А если Вы пишите на C++, и у Вас есть глобальные статические экземпляры некоторых классов (конструкторы таких объектов вызываются ДО main). И самое главное - эти объекты должны работать с железом. В этом случаи инициализация периферии в main будет как на бане гудок.


Согласен конструкторы вызываются до main, но программу и сами конструкторы определяет программист в своем коде.
Думаю конструкторы пользователя инициализируются где угодно, только не в ассемблерном файле startup.s от производителя IAR.
Ведь топик стартер спрашивал о startup.s.
Ведь если startup.s хоть как то причастен к процедуре инициализации классов пользователя, тогда получается совершенно
тяжелая ситуация, мало написать программу на C++, так еще потом вручную редактировать откомпилированный файл.
Это больше похоже на борьбу с глюками среды программирования, чем на штатную работу с ней. Или я чего то не понимаю.
Сергей Борщ
Цитата(rvk @ Jan 9 2009, 10:58) *
По другому поставлю вопрос. Какая разница, проинициализирована периферия в startup.s файле или в main.c
Бывает, что без этого вообще никак. Типичный пример - msp430. У него собака включена после сброса и настроена на 32768 тактов генератора. Если в программе много переменных, то в процессе их инициализации стартапом собака сработает. Приходится ее  затыкать  перед инициализацией.

Еще один случай - загрузчик. Сразу после старта процессор разгоняется, быстро происходят нужные проверки и если все хорошо - управление сразу передается на точку старта приложения. До инициализации переменных загрузчика или, тем более, main() загрузчика управление в таких случаях не доходит вообще.

Цитата(rvk @ Jan 9 2009, 11:50) *
Ведь если startup.s хоть как то причастен к процедуре инициализации классов пользователя,
Да, причастен. Именно оттуда и вызываются конструкторы статических объектов.
Цитата(rvk @ Jan 9 2009, 11:50) *
тогда получается совершенно тяжелая ситуация, мало написать программу на C++, так еще потом вручную редактировать откомпилированный файл.
Зачем? Компилятор складывает указатели на вызовы конструкторов в отдельный сегмент, линкер собирает их в таблицу, стартап проходит по таблице и тупо вызывает функции по указателю пока не наткнется на 0. Все. Более того, все это уже скомпилировано и лежит в библиотеке. Поэтому самый простой ответ - пока вы не знаете, зачем нужен startup.s - он вам не нужен. Готовый библиотечный подлинкуется автоматически.

P.S. Все почему-то пишут про cstartup.s, но никто не сказал ни слова про .mac
bureau: гляньте на вот такой пример его содержимого, возможно вам все станет ясно:
CODE

execUserPreload()
{
Reset();
Remap_FLASH();
__writeMemory32(0xD3,0x98,"Register"); // CPSR = SVC mode, ARM, IRQ, FIQ disabled
}

execUserReset()
{
Reset();

Remap_FLASH();

__writeMemory32(0xD3,0x98,"Register"); // CPSR = SVC mode, ARM, IRQ, FIQ disabled
__writeMemory32(0x00000000,0xB4,"Register");
}

__var tmp;
Remap_FLASH()
{
tmp = __readMemory32(0x00200000, "Memory"); // read from RAM area
__writeMemory32(~tmp, 0x00200000, "Memory"); // alter RAM area
if( ~tmp == __readMemory32(0x00000000, "Memory") ) // check if altering mirrored to remap area
{
__writeMemory32(0x00000001, 0xFFFFFF00,"Memory");
}
__writeMemory32(tmp, 0x00200000 ,"Memory"); // restore RAM data
__message " remap " ;
}


Reset()
{
__writeMemory32(0xA5000004, 0xFFFFFD00, "Memory"); // reset the peripherals
if( __driverType("jlink") )
{
__sleep(1000000); // wait
__emulatorSpeed(32000); // set JTAG speed ~ slow clock
}
__writeMemory32(0x00000001, 0xFFFFFC20,"Memory"); // OSC enable, no timeout

while (! (__readMemory32(0xFFFFFC68, "Memory") & (1 << 0)) ); // wait until MOSCS

// Assuming 18.432 MHz osc
__writeMemory32(0x00190605, 0xFFFFFC2C,"Memory"); // *26/5 set LOCK after 6 SCLK

__writeMemory32(0x00000004, 0xFFFFFC30,"Memory"); // PRES = 2
while (! (__readMemory32(0xFFFFFC68, "Memory") & (1 << 3)) ); // wait untli MCKRDY

__writeMemory32(0x00000007, 0xFFFFFC30,"Memory"); // MCK = PLLCK / 2
while (! (__readMemory32(0xFFFFFC68, "Memory") & (1 << 3)) ); // wait untli MCKRDY

if( __driverType("jlink") )
{
__emulatorSpeed(0); // auto-detect new JTAG speed
__sleep(1000000); // wait
}
__message " MCK ready " ;
}
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.