[singlskv 0]

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

Нда..., Вы меня заинтриговали и я тоже глянул на код...

Переопределение main это фигня, если автор точно знает что делает,

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

и правильнее...(в соответствующем контексте конечно...)

 

Но примерно 30-50 вызовов функции EEPROM_write_byte, половина из которых

вызывается из прерываний... :07:

 

Эта прога не заживет никогда, хотя автар будет еще долго утверждать что по частям

у него все работало... АМИНЬ...

[DiMonstr 0]

Спасибо.

[bzx 0]

Спасибо.

Надеюсь Вас тут убелили, что не стоит делать хитроумные проверки в виде счётчика переходов до основной точки входа и, тем более, хаять компилятор...

[DiMonstr 0]

Надеюсь Вас тут убелили, что не стоит делать хитроумные проверки в виде счётчика переходов до основной точки входа и, тем более, хаять компилятор...

А вот и нет, не убедили. Я не понимаю почему не стоит делать проверки джампов до main(). Как раз там её и целесообразней сделать, чтобы ещё до начала фунциклирования кода выявить ошибку. Я не вижу в этом ничего криминального! В любых системах, перед её запуском производится тестирование оборудования.

 

...Но примерно 30-50 вызовов функции EEPROM_write_byte, половина из которых

вызывается из прерываний... :07:

Эта прога не заживет никогда, хотя автар будет еще долго утверждать что по частям

у него все работало... АМИНЬ...

А в чем собственно проблема? И причем тут вызов EEPROM_write_byte. Да хоть 100 раз я вызову - коренным образом это ничего не изменит. Во-первых, я их использую для отладки. Во-вторых, вызов функции записи в eeprom из прерываний для меня не критичен. В-третьих, на ход выполнения кода это тоже никак не влияет, иначе зачем тогда eeprom? Что Вы этим хотели сказать? Конкретизируйте пожалуйста. :smile3009:

[singlskv 0]

Во-первых, я их использую для отладки. Во-вторых, вызов функции записи в eeprom из прерываний для меня не критичен. В-третьих, на ход выполнения кода это тоже никак не влияет, иначе зачем тогда eeprom?

Если для Вас не критично что из-за вызова функции записи в EEPROM,

прерывание может зависнуть в этом месте примерно на 3,5миллисекунды , и будут пропущены

другие прерывания, тогда не вопрос, тогда у Вас все в порядке... :07:

[forever failure 0]

Кстати, кто-нить смотрел checkjump.asm ? Особенно вот такое место впечатлило :

TESTJMP_SUCCESS_BRID:

INC R17

;//////////////////////////////////////////////////////////////////////////

;// Формируем адрес перехода исходя из результатов тестов

// SHL ecx, 1

// ADD R17, offset TESTJMP_FINISH;

;//////////////////////////////////////////////////////////////////////////

;// Переход в зависимости от результата

// JMP R17

;//////////////////////////////////////////////////////////////////////////

;// Програмные ловушки

TESTJMP_FINISH:

TESTJMP_FINISH_COMPLETE:

END

/*кгхм.... ну и куда дальше пошло исполнение ?

прим. мое, f. f. */

 

Автор, если серьёзно хотите что-то продолжить, у вас есть два выбора:

1. Внимать советам более опытных участников форума и не упираться рогами в духе

"а я вот хочу так и всё".

2. Продолжить самостоятельно заниматься этим сумеречным умопомрачением, но уже не задавать вопросы "почему у меня не заводится, наверно компилятор кривой ?"

 

[плохой вариант удалён]

Изменено 13 февраля, 2008 пользователем IgorKossak

[GDI 0]

Я не понимаю почему не стоит делать проверки джампов до main()

Потому что Си программа стартует с main(), а все что вы понаписали до функции main() это только определения функций, т.е. код , который может быть вызван, только из функции main() или из прерываний, которые инициализируются и разрешаются опять же из функции main().

[DiMonstr 0]

Кстати, кто-нить смотрел checkjump.asm ? Особенно вот такое место впечатлило...

Да этот тест ещё не дописан уважаемый!!! Не пугайтесь так. Приведенная Вами часть кода пока в разработке.

 

 

Потому что Си программа стартует с main(), а все что вы понаписали до функции main() это только определения функций, т.е. код , который может быть вызван, только из функции main() или из прерываний, которые инициализируются и разрешаются опять же из функции main().

А здесь я с Вами в корне не согласен! Как тут уже упоминалось, можно прицепить файл cstartup.s90 и написать код в нем. Вызов main() функции производиться из этого файла строкой:

?cstartup_call_main:
    XCALL   main

Здесь я и продумываю разместить свои тесты, т.е. до инициализации стека и массивов данных.

 

Сегодня я провел такой эксперимент с прошивкой которая не запускается в атмеге.

Вставил в этот файл свой код, который пару раз дергает один из выводов порта.

Подключил к ноге анализатор и зашил прошивку.

Код вставил сюда:

;----------------------------------------------------------------------------
; Set up the CSTACK and RSTACK pointers.
;----------------------------------------------------------------------------
    RSEG    CODE:CODE:NOROOT(1)
?SETUP_STACK:
    SBI 0x11, 4
    SBI 0x12, 4    
    CBI 0x12, 4
    SBI 0x12, 4    
    CBI 0x12, 4    
   ;; Return address stack (RSTACK)
    LDI R16,LOW(SFE(RSTACK)-1)
    OUT 0x3D,R16

После запуска стало ясно, что выполнение программы даже до этого участка не доходит!!!

Изменений сигнала на выводе порта не происходит!

 

Выходит дело, что переход с нулевого адреса выполняется не по адресу PC+0x00F9:

@00000000: __program_start
---- cstartup.s90 ---------------------------------------------------------------------------------
26:           XJMP    ?C_STARTUP
+00000000:   C0F8        RJMP    PC+0x00F9        Relative jump
@00000001: ??INTVEC 2

 

Или в результате компиляции рождается битая прошивка.

А иначе как такое можно объяснить???!!!

 

Что на это скажете?!

[bzx 0]

Или в результате компиляции рождается битая прошивка.

А иначе как такое можно объяснить???!!!

Что на это скажете?!

Откуда у Вас такая неуёмная страсть к мазохизму? Вам уже десятка два людей прямо говорят, перестаньте страдать фигнёй. Годика 2-3 непрерывно попишите чего-нибудь попроще на чистом C, тогда, возможно, и самостоятельно разберётесь что к чему и без посторонней помощи, которую Вы не хотите слышать.

[forever failure 0]

Прогнать в симуляторе АВР студии полученный код не пробовали ? Прямо по шагам по ассемблерным инструкциям, откуда стартует, куда доходит, куда не доходит. Не обломайтесь, прогоните, многое станет ясно. Еще вариант - сделать полный дизассемблерный листинг прошивки. 8к кода - это не очень много, что бы найти в нём ошибку за достаточно короткое время.

[DiMonstr 0]

Прогонял я код и в AVR Studio и в IARовском отладчике. Правда в IAR я дебаггера так и не заставил шагать с 0x00 адреса. Всегда он начинает с main(). Ну да ладно...

В общем в студии всё чисто, без криминала. Всё работает.

 

 

Откуда у Вас такая неуёмная страсть к мазохизму? Вам уже десятка два людей прямо говорят, перестаньте страдать фигнёй. Годика 2-3 непрерывно попишите чего-нибудь попроще на чистом C, тогда, возможно, и самостоятельно разберётесь что к чему и без посторонней помощи, которую Вы не хотите слышать.

Да и так уже почти год пишу на Си. Начинал с камешка AT90USB. Таких проблем там не было, а те что были разрулил. Это второй проект, причем на самом простом контроллере из AVR. И такая засада получилась...

[IgorKossak 0]

Прогонял я код и в AVR Studio и в IARовском отладчике. Правда в IAR я дебаггера так и не заставил шагать с 0x00 адреса. Всегда он начинает с main().

Project->Options->Debugger->Setup снять галочку Run to main.

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

Да и так уже почти год пишу на Си.

Тогда вернитесь к истокам. Создайте новый проект, напишите в нем моргалку светодиодом из четырех команд и вылизывая железо добейтесь ее устойчивой работы. Если даже такая простая программа работать не будет - надо менять или железо или профессию. Вы питание и землю на все ножки питания/земли процессора подали или только на одну пару?

Потом постепенно добавите кусочки из своего нынешнего проекта. Проверять команды перехода - полная фигня. Что вы будете делать, если тест покажет ошибку? Будете крутиться в замкнутом цикле? Но какой командой вы цикл организуете, ведь переходы-то не работают! Запрещать переходить в main тоже не нужно - если переходы не работают, вы туда просто не попадете по XCALL main, ведь переходы-то не работают.

 

Менять cstartup для выполнения кода перед main не нужно - почитайте про функцию __low_level_init() в IAR и секции .initX в avr-gcc.

[MrYuran 21]

Первое, что нужно сделать - посмотреть в листинг и убедиться, что компилятор понял вас правильно.

Это понятно, что компилятор обвинить проще простого. У меня подобное поведение наблюдалось однажды, когда ошибочно был установлен фуз BRST. А у студента - когда подтяжка ресета вместо питания была подключена к одному из портов. Он порт настраивает на вывод - контроллер ресетится.

 

В общем есть предложение поспорить на ящик пива, что компилятор снова не при чем, а виноваты недостаток знаний и опыта.

 

А я часто сталкиваюсь с глюками ИАРа под МСП. В основном они однообразны и заключаются в непереходе по условию if, когда вроде бы всё очевидно.

Я точно не помню, но было что-то типа такого:

 

char i;

...

if (i) do something

else dо other

 

Так вот, условие никогда не выполнялось, хотя i было явно не ноль.

И так продолжалось до тех пор, пока я не переопределил условие типа i==0 или что-то типа этого, точно уже не помню.

 

И случай не единичный. Но ничего , привык. Правда, теперь вот на mspgcc надо переходить, а он вообще не хочет работать (в смысле код)

 

Хотя согласен, чаще всего ошибки в собственном коде.

[SapegoAL 0]

А я часто сталкиваюсь с глюками ИАРа под МСП. В основном они однообразны и заключаются в непереходе по условию if, когда вроде бы всё очевидно.

Как правило причину уже озвучивали, - volatile. Компилятор просто видит, что вы не делали никаких операций и выбрасывает условие (оптимизирует)