singlskv 0 11 февраля, 2008 Опубликовано 11 февраля, 2008 · Жалоба Можно это утверждение игнорировать начисто - я бегло просмотрел этот код. Полный мрак, начиная с переопределенной точки входа прямо в main(), деклараций переменных в header-ах, Нда..., Вы меня заинтриговали и я тоже глянул на код... Переопределение main это фигня, если автор точно знает что делает, декларация переменных в хедерах...., ну сам иногда пользуюсь, иногда это удобнее и правильнее...(в соответствующем контексте конечно...) Но примерно 30-50 вызовов функции EEPROM_write_byte, половина из которых вызывается из прерываний... :07: Эта прога не заживет никогда, хотя автар будет еще долго утверждать что по частям у него все работало... АМИНЬ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DiMonstr 0 11 февраля, 2008 Опубликовано 11 февраля, 2008 · Жалоба Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bzx 0 11 февраля, 2008 Опубликовано 11 февраля, 2008 · Жалоба Спасибо. Надеюсь Вас тут убелили, что не стоит делать хитроумные проверки в виде счётчика переходов до основной точки входа и, тем более, хаять компилятор... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DiMonstr 0 12 февраля, 2008 Опубликовано 12 февраля, 2008 · Жалоба Надеюсь Вас тут убелили, что не стоит делать хитроумные проверки в виде счётчика переходов до основной точки входа и, тем более, хаять компилятор... А вот и нет, не убедили. Я не понимаю почему не стоит делать проверки джампов до main(). Как раз там её и целесообразней сделать, чтобы ещё до начала фунциклирования кода выявить ошибку. Я не вижу в этом ничего криминального! В любых системах, перед её запуском производится тестирование оборудования. ...Но примерно 30-50 вызовов функции EEPROM_write_byte, половина из которых вызывается из прерываний... :07: Эта прога не заживет никогда, хотя автар будет еще долго утверждать что по частям у него все работало... АМИНЬ... А в чем собственно проблема? И причем тут вызов EEPROM_write_byte. Да хоть 100 раз я вызову - коренным образом это ничего не изменит. Во-первых, я их использую для отладки. Во-вторых, вызов функции записи в eeprom из прерываний для меня не критичен. В-третьих, на ход выполнения кода это тоже никак не влияет, иначе зачем тогда eeprom? Что Вы этим хотели сказать? Конкретизируйте пожалуйста. :smile3009: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
singlskv 0 12 февраля, 2008 Опубликовано 12 февраля, 2008 · Жалоба Во-первых, я их использую для отладки. Во-вторых, вызов функции записи в eeprom из прерываний для меня не критичен. В-третьих, на ход выполнения кода это тоже никак не влияет, иначе зачем тогда eeprom?Если для Вас не критично что из-за вызова функции записи в EEPROM, прерывание может зависнуть в этом месте примерно на 3,5миллисекунды , и будут пропущены другие прерывания, тогда не вопрос, тогда у Вас все в порядке... :07: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
forever failure 0 13 февраля, 2008 Опубликовано 13 февраля, 2008 (изменено) · Жалоба Кстати, кто-нить смотрел 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 13 февраля, 2008 Опубликовано 13 февраля, 2008 · Жалоба Я не понимаю почему не стоит делать проверки джампов до main() Потому что Си программа стартует с main(), а все что вы понаписали до функции main() это только определения функций, т.е. код , который может быть вызван, только из функции main() или из прерываний, которые инициализируются и разрешаются опять же из функции main(). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DiMonstr 0 13 февраля, 2008 Опубликовано 13 февраля, 2008 · Жалоба Кстати, кто-нить смотрел 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 13 февраля, 2008 Опубликовано 13 февраля, 2008 · Жалоба Или в результате компиляции рождается битая прошивка. А иначе как такое можно объяснить???!!! Что на это скажете?! Откуда у Вас такая неуёмная страсть к мазохизму? Вам уже десятка два людей прямо говорят, перестаньте страдать фигнёй. Годика 2-3 непрерывно попишите чего-нибудь попроще на чистом C, тогда, возможно, и самостоятельно разберётесь что к чему и без посторонней помощи, которую Вы не хотите слышать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
forever failure 0 14 февраля, 2008 Опубликовано 14 февраля, 2008 · Жалоба Прогнать в симуляторе АВР студии полученный код не пробовали ? Прямо по шагам по ассемблерным инструкциям, откуда стартует, куда доходит, куда не доходит. Не обломайтесь, прогоните, многое станет ясно. Еще вариант - сделать полный дизассемблерный листинг прошивки. 8к кода - это не очень много, что бы найти в нём ошибку за достаточно короткое время. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DiMonstr 0 14 февраля, 2008 Опубликовано 14 февраля, 2008 · Жалоба Прогонял я код и в AVR Studio и в IARовском отладчике. Правда в IAR я дебаггера так и не заставил шагать с 0x00 адреса. Всегда он начинает с main(). Ну да ладно... В общем в студии всё чисто, без криминала. Всё работает. Откуда у Вас такая неуёмная страсть к мазохизму? Вам уже десятка два людей прямо говорят, перестаньте страдать фигнёй. Годика 2-3 непрерывно попишите чего-нибудь попроще на чистом C, тогда, возможно, и самостоятельно разберётесь что к чему и без посторонней помощи, которую Вы не хотите слышать. Да и так уже почти год пишу на Си. Начинал с камешка AT90USB. Таких проблем там не было, а те что были разрулил. Это второй проект, причем на самом простом контроллере из AVR. И такая засада получилась... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 14 февраля, 2008 Опубликовано 14 февраля, 2008 · Жалоба Прогонял я код и в AVR Studio и в IARовском отладчике. Правда в IAR я дебаггера так и не заставил шагать с 0x00 адреса. Всегда он начинает с main(). Project->Options->Debugger->Setup снять галочку Run to main. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 140 14 февраля, 2008 Опубликовано 14 февраля, 2008 · Жалоба Да и так уже почти год пишу на Си.Тогда вернитесь к истокам. Создайте новый проект, напишите в нем моргалку светодиодом из четырех команд и вылизывая железо добейтесь ее устойчивой работы. Если даже такая простая программа работать не будет - надо менять или железо или профессию. Вы питание и землю на все ножки питания/земли процессора подали или только на одну пару? Потом постепенно добавите кусочки из своего нынешнего проекта. Проверять команды перехода - полная фигня. Что вы будете делать, если тест покажет ошибку? Будете крутиться в замкнутом цикле? Но какой командой вы цикл организуете, ведь переходы-то не работают! Запрещать переходить в main тоже не нужно - если переходы не работают, вы туда просто не попадете по XCALL main, ведь переходы-то не работают. Менять cstartup для выполнения кода перед main не нужно - почитайте про функцию __low_level_init() в IAR и секции .initX в avr-gcc. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 27 3 марта, 2008 Опубликовано 3 марта, 2008 · Жалоба Первое, что нужно сделать - посмотреть в листинг и убедиться, что компилятор понял вас правильно. Это понятно, что компилятор обвинить проще простого. У меня подобное поведение наблюдалось однажды, когда ошибочно был установлен фуз BRST. А у студента - когда подтяжка ресета вместо питания была подключена к одному из портов. Он порт настраивает на вывод - контроллер ресетится. В общем есть предложение поспорить на ящик пива, что компилятор снова не при чем, а виноваты недостаток знаний и опыта. А я часто сталкиваюсь с глюками ИАРа под МСП. В основном они однообразны и заключаются в непереходе по условию if, когда вроде бы всё очевидно. Я точно не помню, но было что-то типа такого: char i; ... if (i) do something else dо other Так вот, условие никогда не выполнялось, хотя i было явно не ноль. И так продолжалось до тех пор, пока я не переопределил условие типа i==0 или что-то типа этого, точно уже не помню. И случай не единичный. Но ничего , привык. Правда, теперь вот на mspgcc надо переходить, а он вообще не хочет работать (в смысле код) Хотя согласен, чаще всего ошибки в собственном коде. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SapegoAL 0 3 марта, 2008 Опубликовано 3 марта, 2008 · Жалоба А я часто сталкиваюсь с глюками ИАРа под МСП. В основном они однообразны и заключаются в непереходе по условию if, когда вроде бы всё очевидно. Как правило причину уже озвучивали, - volatile. Компилятор просто видит, что вы не делали никаких операций и выбрасывает условие (оптимизирует) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться