Нет это чётко описано в самом компиляторе Си и в книгах тоже. Поменяйте книгу.

Докажите. Можно от противного - достаточно доказать, что битовые поля не упоминаются в стандарте языка С.

Я не говорю, что ни в одной литературе не написано о битовых поолях.
Вы бы сами какую книгу порекомендовали по Си?

Сообщение отредактировал DiMonstr - Jan 25 2008, 14:10

Вы утверждали, что это "Эта фишка (и не только) уже самого компилятора зарытая". Т.е. снова, как и в начале ветки, во всем виноват компилятор а не ваше невежество.

Книга по С бывает одна: Керниган и Ритчи, "Язык программирования С". Второе (!) издание. Все остальные - ее толкования. Книга есть в интернете. Где искать - не подскажу, гугля в помощь.

Оптимизировал проект. Добавил ещё функций. Кое-что переписал. НО!!! Проблема осталась не смотря на все усилия!!! Хоть головой бейся о монитор с клавой, но программа в контроллере не запускается!!! Не знаю где капать! Весь инет перерыл. Подобного ни у кого не было! Что делать???

А может попробовать скомпилять проект в WinAVR? Да в принципе это последняя надежда А нееет, есть ещё вариант переписать код на асме....

Есть еще вариант, если, как Вы здесь утверждаете, виноват компилятор и дело
до main не доходит, если, как Вы опять же утверждаете, Вы знаете Асм,
ну дык кто Вам мешал все это время не заниматься болтовней, а просто взять листинг до main,
перенести его в студию и найти место где компилятор ошибся...
И радостно нам об этом сообщить.

Что то мне подсказывает, что "Если" получилось много, и часть из них Вы не осилили

Можно это утверждение игнорировать начисто - я бегло просмотрел этот код. Полный мрак, начиная с переопределенной точки входа прямо в main(), деклараций переменных в header-ах, конструкций switch( константа ), отсутсвие volatile, обилия кривых макросов, & и && - по барабану,.....
В приложении, то, что подправлено за 15 минут - наверное до main() дойдет, но дальше ....

Я с Вами согласен. Сам ужаснулся, когда начал с самого начала просматривать код. Вот версия проекта, которая более менее доведена до ума. Зацените
C Вашей прошивкой работоспособность кода я оценить не смогу. Для этой прошивки в хидере settings.h какие значения определены следующим именам:
#define IsCheckCRC
#define IsCheckRAM
#define IsCheckJUMP
#define IsCheckAnalogScheme
#define IsCheckBlock

Сообщение отредактировал DiMonstr - Feb 10 2008, 09:47

Хинт: уберите весь (да, весь, вообще весь) код, до которого не доходит исполнение, оставьте только то место, на котором исполнение затыкается. Попытайтесь локализовать место, на котором программа затыкается.

ЗЫ. switch от (CurrentDevice) т.е. от константы - категорически не труъ, как уже было выше замечено. Уберите.

Ещё, хотелось бы Ваших пояснений, относительно вот этого участка кода (возможно, здесь одна из ошибок):

Value = slow_crc16(Value,(unsigned char __flash *)0, (unsigned long)&__checksum); /* здесь передаётся в третьем параметре указатель */
Value = slow_crc16(Value,(unsigned char __flash *)&zero,2); /* а здесь целое */

Что вообще должно быть здесь выполнено ?

В том-то и дело, что я незнаю до какого адреса доходит выполнение программы. Я делал так, сразу после main() инициализировал USART интерфейс и atmega передавала в цикле байты на комп, пока не получит ответа. Теперь после прошивки я точно мог узнать работает код или нет. Так и сделал, отключив сначала все функции тестирования. Заработало. Затем начал экспериментировать разрешая выполнение тестов и снова прошивая. Ну и что Вы думаете? Выполнение программы, то доходило до команды посылки байта, то через раз ничего не работало, то работало стабильно. Получается прога затыкается перед функцией main() на стадии инициализации стека, озу и т.д. Верно?


Понял, сделаем.


Здесь производится подсчет CRC прошивки и сравнение с CRC, которая сохраняется в конец файла прошивки на стадии компиляции.


Этот код к проблеме не имеет отношения, без него такая же лажа. Он был взят из "апноутов".

Попутно ещё вопрос. Что происходит если программа переходит на адрес по которому лежит код команды 0xFFFF?
И чем лучше забивать свободное пространство памяти программ 0x0000, 0xFFFF или 0x1895

0xFFFF так же как NOP отрабатывается. Ничем забивать не надо. Если программа переходит по неправильному адресу, то выкидывать такую программу. Если такой переход вызван аппаратным сбоем - заводите собаку и лечите железо.

Как в IAR написать код, который будет выполняться перед вызовом основной функции main()? Компилятор располагает такими возможностями?

Да, но придется взглянуть на документацию __low_level_init(), либо просто вызвать из startup....