[bureau 0]

В IARe при отладке сначала код грузится с этих файлов. Собственно говоря что это дает?

[sergeeff 1]

Наверное все-таки из cstartup.s. Идея проста - выполнить все подготовительные операции, необходимые для старта главного модуля задачи - main() или какого-либо иного. Что конкретно делает cstartup - зависит от процессора, конкретного распределения памяти (ROM, RAM). И прочего ...

 

А что из комментариев в cstartup.s неясно что он делает и зачем?

[bureau 0]

А болие подробней описание каким образом организовуются эти "подготовительные операции, необходимые для старта главного модуля задачи - main()" можно услышать?

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

[HARMHARM 0]

А болие подробней описание каким образом организовуются эти "подготовительные операции, необходимые для старта главного модуля задачи - main()" можно услышать?

Поиск рулит. Вкратце - для C нужно как минимум настроить стек. Для C++ еще всякое...

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

Из примеров производителя контроллера и производителя компилятора.

[uriy 5]

Обычно с компилятором бывают дефолтовые стартап файлы для контроллеров, которые он поддерживает. В Keil для ARM, например, есть даже подобие визарда для редактирования этого файла.

[rvk 0]

В IARe при отладке сначала код грузится с этих файлов. Собственно говоря что это дает?

 

IAR\процессор\src\lib\startup.s90 исходный код файла.

Все что он делает, это затирает нулем все переменные из сегмента DATAZ, и

инициализирует глобальные переменные теми значениями, которые указаны

в программе, плюс настраивает стек.

В любом случае все эти операции программисту пришлось бы делать.

Ничего такого сверхъестественного этот код не далает.

И по моему, на него внимание обращать нет смысла.

[sergeeff 1]

До поры до времени можно и не обращать, пока ваша задача не перешагнет некий default'овый порог сложности. И если не разобраться в том, что к чему в этом самом startup'e, в один "прекрасный" момент все грохнется, о чем свидетельствуют многочисленные "гласы вопиющего" на нашем форуме.

[rvk 0]

До поры до времени можно и не обращать, пока ваша задача не перешагнет некий default'овый порог сложности. И если не разобраться в том, что к чему в этом самом startup'e, в один "прекрасный" момент все грохнется, о чем свидетельствуют многочисленные "гласы вопиющего" на нашем форуме.

 

Может просветите, раз уж такие страхи нагоняете.

С другой стороны вот пример из инета http://en.mikrocontroller.net/topic/149982.

Суть в чем, человек пишет, с startup.s взятым из проекта от Atmel моя программа не работает, они все такие и сякие.

На что ему Martin Thomas отвечает, вообще то такие вопросы хорошо бы в IAR отправить, но раз

уж вы спросили, отвечаю, в вашем startup.s код загрузчика "закомментирован" (во как).

Вы говорит, по прежнему уверены, что это код Atmel:)

Изменено 8 января, 2009 пользователем rvk

[sergeeff 1]

Речь идет, к примеру, о размерах стеков для вашей задачи.

 

 

К тому же, приведенный вами пример, как раз демонстрирует тот факт, что человек не понимает как устроен startup для конкретного компилятора и от этого начинает рассылать письма с вопросами.

[rvk 0]

Да стек важная штука, и если его не хватит, мало не покажется, но он настраивается прямо в проекте.

Кто мешает настроить размер стека в опциях проекта, не залезая в startup.s.

Изменено 9 января, 2009 пользователем rvk

[sergeeff 1]

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

 

Тем не менее хорошим тоном считается, что вся необходимая soft и hard инициализация была выполнена до вызова main.

[rvk 0]

В чем смысл закладывать все в startup.s, если он запускается до main.

По другому поставлю вопрос. Какая разница, проинициализирована периферия в startup.s файле или в main.c

Изменено 9 января, 2009 пользователем rvk

[ek74 0]

По другому поставлю вопрос. Какая разница, проинициализирована периферия в startup.s файле или в main.c

 

А если Вы пишите на C++, и у Вас есть глобальные статические экземпляры некоторых классов (конструкторы таких объектов вызываются ДО main). И самое главное - эти объекты должны работать с железом. В этом случаи инициализация периферии в main будет как на бане гудок.

[rvk 0]

А если Вы пишите на C++, и у Вас есть глобальные статические экземпляры некоторых классов (конструкторы таких объектов вызываются ДО main). И самое главное - эти объекты должны работать с железом. В этом случаи инициализация периферии в main будет как на бане гудок.

 

Согласен конструкторы вызываются до main, но программу и сами конструкторы определяет программист в своем коде.

Думаю конструкторы пользователя инициализируются где угодно, только не в ассемблерном файле startup.s от производителя IAR.

Ведь топик стартер спрашивал о startup.s.

Ведь если startup.s хоть как то причастен к процедуре инициализации классов пользователя, тогда получается совершенно

тяжелая ситуация, мало написать программу на C++, так еще потом вручную редактировать откомпилированный файл.

Это больше похоже на борьбу с глюками среды программирования, чем на штатную работу с ней. Или я чего то не понимаю.

Изменено 9 января, 2009 пользователем rvk

[Сергей Борщ 143]

По другому поставлю вопрос. Какая разница, проинициализирована периферия в startup.s файле или в main.c

Бывает, что без этого вообще никак. Типичный пример - msp430. У него собака включена после сброса и настроена на 32768 тактов генератора. Если в программе много переменных, то в процессе их инициализации стартапом собака сработает. Приходится ее  затыкать  перед инициализацией.

 

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

 

Ведь если startup.s хоть как то причастен к процедуре инициализации классов пользователя,

Да, причастен. Именно оттуда и вызываются конструкторы статических объектов.

тогда получается совершенно тяжелая ситуация, мало написать программу на C++, так еще потом вручную редактировать откомпилированный файл.

Зачем? Компилятор складывает указатели на вызовы конструкторов в отдельный сегмент, линкер собирает их в таблицу, стартап проходит по таблице и тупо вызывает функции по указателю пока не наткнется на 0. Все. Более того, все это уже скомпилировано и лежит в библиотеке. Поэтому самый простой ответ - пока вы не знаете, зачем нужен startup.s - он вам не нужен. Готовый библиотечный подлинкуется автоматически.

 

P.S. Все почему-то пишут про cstartup.s, но никто не сказал ни слова про .mac

bureau: гляньте на вот такой пример его содержимого, возможно вам все станет ясно:

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 " ;
}

Изменено 9 января, 2009 пользователем Сергей Борщ