Писал себе и писал прошивку и вдруг в один прекрасный момент она начала собираться "криво" и откатить назад не получается. Всё пропало. Помогите, что я натворил то?
А именно кривость проявляется в следующем. если после сборки открыть и посмотреть листинг вокруг строки sei(); перед циклом майна. То там какие-то хаотические куски кода, на которых проц то делает переполнение то ребутится. В общем ведёт себя неадекватно, а в main.c этого кода нет. Точнее есть но не в этом месте.

Да вроде бы в этом куске кода GCC как обычно распихивает константы по регистрам перед запуском сурового алгоритма

PS: Makefile надо бы исправить: счастье что make сам догадывается что нет main.cpp, а есть main.c, и что оно C, и вовсе не C++

А можете дать результат сборки вашей? lss и hex...

Но всё же какой-то косяк...
К примеру вот такой lss получается:
От куда это он пытается вызвать функцию? Что за бред?

Вероятно, это косяк objdump

тогда это ещё косяк Proteus и ARVStudio ибо они в отладке на этот же адрес хотят перейти, да и на железе не работает.

Дык поделитесь тайной: версия компилятора и содержимое makefile
В lss от SysRq такого косяка ведь нет

Это не бред. Не забывайте, что PC имеет ограниченную разрядность. Для меги8 это 13 бит. И при прыжке назад присходит отбрасывание старших разрядов. Итого, для меги8 это будет прыжок на адрес 6F2 - 4080 = 0xfffff702 & 0x1FFFF = 0x1702. Прием очень полезный, ибо команда rjmp не позволяет дотянуться до этого адреса прыжком вперед.

Скачал. Собрал. Посмотрел. Описанного глюка не было. Полный отчет о make + lss в аттаче.Нажмите для просмотра прикрепленного файла


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

1) Вроде как именно для 8-килобайтных AVR-ок такое поведение задокумениторвано, у 90s8515 и прочих просто нет команды jump (ну, по описанию ) и такое применение rjmp/rcall для 8-килобайтных - единственный способ достать до всего адресного пространства
2) -mno-wrap

Это не вне пространства. Пространство памяти программ не безгранично, оно ограничено разрядностью счетчика команд и замкнуто в кольцо все той же разрядностью. Вас ведь не смущает, что таймер, досчитав до 0xFFFF переходит на 0? И SUBI Rx, lo8(-(const)) == Rx + const вас тоже не смущает.

Абсолютно аналогичный прием используется в ARM для доступа к контроллеру прерываний (лежит в конце памяти) из области векторов (лежит в начале памяти). Таким же образом высчитываются простейшие задержки на таймерах. Никакого криминала, чистая математика.

Спасибо за разъяснения. Будем продолжать учиться.

Было бы просто замечательно, если бы кто-то из глубоко вникших в AVR-GCC, посоветовал, как отключить (избежать, обойти) эту фичу с переходами "вне пространства адресов". в условиях недостатка средств отладка в протеусе - единственно возможный вариант, а он, зараза, не понимает, что ограничение разрядности аппаратно встроено в AVR, и не дает вести отладку... AVR Studio такую ситуацию отрабатывает верно, но вести в ней отладку проектов, завязанных на внешние сигналы, практически нереально

Я б выбрал для симуляции другой камень типа м168, чтоб разрешить jmp


Пользовался rjmp, представляя себе простую модель перехода +/- 2кслов с 13-разр РС. И никаких проблем, пока не увидел, что пишет objdump

Уважаемый Сергей Борщ!
Я прочитал в документации про опцию -mno-wrap - это, как я надеялся, и есть решение проблемы. НО! я так и не смог ею воспользоваться! не смотря на то, что вызов avr-gcc.exe --target-help подтверждает поддержку этой опции, компиляция всегда завершается ошибкой:
не будете ли вы так любезны пояснить, в чем мое заблуждение?

P.S. работаю с WinAVR 20091303

Вообще-то это ключ ассемблера, в мануалах он описан в binutils/as

-mmcu= пробрасывается из gcc всем вызываемым проходам, видать и этот тоже, хотя он нужен только ассемблеру, так что надо явно указать -Wa,-mno-wrap

Возможно, без этого ключа ассемблер форимрует такую запись в объектнике, что линкер после вычисления разности текущего адреса и адреса перехода игнорирует не влазящие в поле смещения в команде биты, если они все единички, т.е. если "сворачивание" проходит. А с этим ключом такого не делает и линкер ругается на превышение диапазона.
Я не разбирался, так как для меня эта тема не актуальна.

если его передать ассемблеру явно -Wa,-mno-wrap - вообще никаких изменений не наблюдается - код получается 100% прежним. судя по всему, no-wrap понимается как использование "медленных" инструкций "дальних" переходов JMP/CALL, которые в меге8 не присутствуют... но ведь цепочка коротких RJMP вкупе с одним RCALL ничем не хуже! я надеюсь, что это действительно так... хотя вот здесь, похоже, над такой идеей посмеиваются... (извините за мой промптовый английский)

Да, действительно, объектники совпадают побитово.

Это всё-таки ключ ассемблера, с одной стороны, а он в генерации кода "от себя" не замечен. С другой - для объектов из разных модулей вообще неизвестно кто кроме линкера (но у него этого *) ключа нет) и как должен промежуточные переходы вставлять.


*) при том, что мне эта тема малоинтересна :-) в попытках что-то понять обнаружил у линкера интересный ключ:
Т.е. когда он при --relax заменяет jump -> rjmp, call -> rcall - разрешить ему делать сворачивание по заданному модулю.

В аврстудии при настройке avrasm есть аналогичный параметр, но менее гибкий (только на 4к), насколько это позволено в инструкции rjmp/rcall

ARV, а Proteus версии у вас какой? Пробегавший мимо 7.4 SP3 Build 6792 нормально съел *.hex с:

Т.е. "rjmp .-2696" его нисколько не смутил, простенькая программа работала.
Однако, если я увеличивал размер кода nop'ами (вставлял nop до rjmp), то в какой-то момент он переставал запускать симуляцию, и при этом ошибку не выдавал в чем дело (в логе 10 штук ОК и на инициализации МК полный превед...)

протеус у меня точно такой же.
я активно применяю возможности форматированного ввода-вывода, а это однозначно прибавляет до 2-3К кода, поэтому порой буквально один новый оператор в программе приводит к тому, что вход в main оказывается "далеко" от кода инициализации (секции .init*), avr-gcc генерирует "хитрые" переходы, которые протеус отвергает. я понимаю, что виноват протеус, но, блин, надо же как-то выкрутиться... теоретически можно как-то поколдовать скриптами линкера, изменив порядок следования модулей, но ведь это решение не универсальное...

off: протеус - как наркотик: один вред, а подсаживает с первой пробы, всерьез и надолго

О чем Вы поете? Оно ж пишет rjmp в байтах, а не в словах! А нам, чтобы добиться глюка, надо получить адрес > 4096 байт. В противном случае вообще ни один rjmp не работал бы.

с -mno-wrap вообще странность какая-то... вот сейчас выбрал target Atmega32, в которой имеются и RJMP и JMP. по умолчанию всюду используются трехсловные JMP. куда опцию -mno-wrap не лепил - и в командную строку avr-gcc, и непосредственно ассемблеру передавал через -Wa - ноль эффекта! результаты 100% одинаковые всегда.
-relax успешно заменяет JMP на RJMP, оставляя при этом одно слово пустым, т.е. скорость исполнения возрастает...

кстати, глюка-то в GCC и нет - выше было рассказано, как оно работает... это протеусу не нравится, когда с адреса, скажем, 0x100 происходит RJMP .-2000... протеус уверен, что в результате попадем в точку где-то дааааалеко за имеющимися 8 или 32К... т.е. не учитывает аппаратное маскирование старших битов PC...

Это в векторах, там по другому нельзя. А в остальном коде можно команды сдвинуть и размер прошивки уменьшается.

... Народ !!! У меня еще прикольнее...

Понадобилось мне написать код для маленького и простого 2313... 2 кб...

Я обычно как делаю : в процессе отладки когда памяти становится "мало-мало" беру *.lss файл и
оптимизирую код уже сам - в ручную...

Последняя версия, то биш 20090313 сжал мне в 900 байт...

20080610 более старый в 950 байт...

а самый старый 20070525 сжал и "дал" самый с моей точки зрения хороший и грамотный код в 760 байт.
Работоспособный ! Отлично оптимизированный. и *.lss файл ровный без "глюков"... а самый последний
20090313 наворочал и код кривой, и коментарии не в попад...
Мне вот интересно стало, это что ? Типа как с "виндой" что-ли много памяти - Атмеги64 и 128-е и дальше
разжижают мозги создателям компиляторов ?

Ну не компиляторов а в основном одного компилятора, да и его создателей особо и не найдешь - абстрактному среднему писателю GCC лишь-бы непрерывно монстреющий Linux собирался и более ничего особо не надо .

1) winavr он же GCC, перешёл с версии 3.xxx на версию 4.xxx
2) GCC имеет свой цикл разработки. существуют 2 основных ветки:
а) текущий релиз. в нём архитектуру не меняют, только правят баги и делают небольшие косметические правки. понятно, что со временем эта версия вылизывается практически до идеала. однако т.к. заложенные подходы в компилятор являются немного устаревшими принципиально новые вещи в этой ветке не реализуются.
б) ветка разработки, в неё добавляют самые последние технологии компиляторостроения, закладывается достаточно большой запас прочности и потенциал для развития, учитываются современные технологии процессоров и.т.п. Однако т.к. эта ветка самая "свежая", когда она становится "текущим релизом" в ней есть места, которые на практике надо дорабатывать. С временем она раскрывает весь свой потенциал, пока разрабатывают уже новые подходы и т.д.
3) приоритеты в новых компиляторах немного меняются. например в современных контроллерах много флеша, поэтому размер кода обычно не так критичен как скорость выполнения, более линейных код.
4) мега8 стоит практически столько-же как и т2313, а может уже и меньше. а возможностей гораздо больше.

Плюс дофига. Меня тут уже тыкали носом в "жрите что дают"

Желание пользовать гнуся от этого совсем не прибавилось. Разочарования - добавилось.

Блин, у меня теперь еще интересней проблема !

На работе, где стоит старый 20070525 все работает как часы...

А вот дома, притом и на "стационарном" компе и на "буке" 20090313...

Решил новый "наганть" и поставить старый, дык он собака где-то прописался и старый (е) у меня их около
5 сортов разных лет - не хотят работать. Весь реестр вычистил, НУ ВСЕ высистил, что можно - балда !
Вещает :
> "make.exe" all
AllocationBase 0x0, BaseAddress 0x71590000, RegionSize 0x3C0000, State 0x10000
C:\WinAVR-20070525\utils\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 487
AllocationBase 0x0, BaseAddress 0x71590000, RegionSize 0x3C0000, State 0x10000
C:\WinAVR-20070525\utils\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 487

-------- begin --------
avr-gcc (GCC) 4.1.2 (WinAVR 20070525)
Copyright © 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

AllocationBase 0x0, BaseAddress 0x71590000, RegionSize 0x3C0000, State 0x10000
C:\WinAVR-20070525\utils\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 487
make.exe: *** [sizebefore] Error 1

> Process Exit Code: 2
> Time Taken: 00:01

Блин ! Да что-же это такое !!! И на буке таже песня ! Новый ставишь - все работает. Любого из старичков -
пишет (см. верх) . Раньше не было такого никогда. Может знает кто - где он помимо реестра следы остав-
ляет ? Пытался искать в SYSTEM32 и прочих "отсеках" - куда там, у меня винда стоит 3-тий год, распухла
до 12 гектар... сносить проблемматично. Че делать ?

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

раньше, например, когда писалось PORTB |= _BV(PB1); компилятор всегда генерировал код с обращением к ячейке памяти по соответствующему адресу, т.е. делал минимум 3 команды: LDS, ORI и STS. это было очень хорошо (с одной стороны), так как легко позволяло обращаться к порту по указателю, но по скорости SBI все-же гораздо лучше. и вот в последней версии заметил, что теперь генерируется именно SBI! причем при обращении через указатель получается "старый" вариант - ведь лучше же стало, а?! хотя странности присутствуют все равно в коде

Первый WinAVR, с которым я начал серьезно работать - 20071221 уже без проблем делал sbi/cbi/sbic
Вы какой именно "старый" имеете ввиду - GCC 3 ?

WinAVR-20060421 (gcc 3.4.6)
-Os -S -mmcu=atmega8

Более древних на работе нет, но что-от мне вспоминается, что это только с gcc 2.95 такое было, а с перехода на 3.х я уже вместо макросов inb, outb, sbi да cbi стал писать обычное =, |= да &=~
Точнее, с момента полного перехода, кода 2.95 уже был снесён на всех компах.

Поиск в гугле по сообщению об ошибке очень помогает в таких случаях.

В комплекте WinAVR идет какая-то очень древняя версия утилит из msys, которую очень любит Eric Weddington. И вместе с этим набором из версии в версию WinAVR кочуют и все болячки той версии msys. На мои призывы к автору обновить эти утилиты был дан ответ - "у них нет нормального инсталятора, мне лень".



Сходите на сайт mingw32/msys и скачайте там самые свежие версии всех этих утилит. После чего используйте их со всеми версиями WinAVR, а идущие в комплекте забудьте как страшный сон.

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

и все-таки, почему никто из гуру не ответит на вопрос: как заставить работать опцию -mno-wrap? она не опознается как "родная", если передавать ее просто в командной строке avr-gcc и не производит никакого эффекта, если передать ее ассемблеру! а очень нужно избавиться от rjmp в проекте на atmega32.

Уважаемый Сергей ! Я даже не знаю как Вас благодарить...

Самое интересное, что на "стационарном" компе и на "буке" были совершенно разные "занозы" !!!
1) Ноутбук я победил сам. Почти пол дня ковырялся ! Причиной "глюка" был Антивирус Касперского.
почти всю ночь и пол дня я читал описание на WinAVR и понял суть проблемы, файл sh.exe из utils\bin
работает с операционной системой, единственное, что могло этому обмену помешать, это "проактивн-
ая защита Касперского". До его установки все было гуд. Я внес sh.exe в доверенную зону - и все за-
работало !!!
2) С "стационарным" компом такие выкрутасы не прошли. Я затужил. Работа горит а главный мой комп
что-то вроде "осьминога" напичкан всеми примочками для отладки "в железе". Он важнее чем "бук"
Зашел по вашей ссылке, почитал и уже собирался вникать в Линукс и прочие дела, кстати про "палки
в колеса со стороны антивирусов, там тоже есть". Хотел было уже качать 500 метровый GNU pack...
Но заглянул на крошечную ссылку, http://www.madwizard.org/electronics/articles/winavrvista Я
сначала пролетел, у меня то XP ! Там нашлось лекарство, и очень простое !
Качаем 300 сот килограммовый msys-rebased.zip и перезаписываем его в utils\bin , там это по мое-
му единственная DLL-ка ms-1.0 dll И все ! Земля опять завертелась !!!

Жму руку как ПРОФЕССИОНАЛУ, заходящему сюда не "флудить" а помогать словом и делом !!!

А я столкнулся с таким глюком: есть бутлоадер с эмуляцией STK500. Пишу через него - пишется нормально. Читаю - бывают ошибки, по адресу 0x4000 ошибок нет. Читаю ISP программатором - тех ошибок что показывал бутлоадер нет, по адресу 0x4000 лежит слово FFFF. Вроде помогла такая штука:
Было:Стало:
Пробовал каждый раз на разных файлах, поэтому "вроде"...

Вот ЭТО написано человеком который поленился прочитать документацию:



Это баг не в комптляторе, это баг в коде.

Анатолий.

Код не мой. Return взят из какого-то файла скачанного из ветки в этом форуме. Но этот код к вышеописанной проблеме отношения не имеет.

Если readBits вызывается как функция то проблем не возникнет, так как регистры
r24, r25, r30 и r31 являются CALL_USED регистрами и в коде вызывающей
функции предполагаться что они не содержат те значения, что были в них перед
вызовом readBit. Когда же код этой функции инлайнится то могут возникнуть
проблемы, так как регистры r24, r25, r30 и r31 искажаются в ассемблерной
вставке, но компилятор об этом не предупрежден. Может генерироваться код
записывающий информацию в эти регистры до ассемблерной вставки и использующий
эту информацию после, не смотря на то что она искажена. Регистры r24, r25,
r30 и r31 должны быть добавлены в clobber list.

Анатолий.

Она вообще не вызывается если не давать команды CMD_READ_FUSE_ISP или CMD_READ_LOCK_ISP. Чтение локов и фузов действительно не работает, но оно меня толком и не интересует.

Логично, логично. Лажа с моей стороны имеет место быть

Proteus, кажется (может я не нашел?), и правда битность PC не учитывает:

Как временное решение (ежели без Proteus'а вообще никак) - делать патч (маскировать лишние биты).

Заинтересовался... Единственное, что делает новый код - он на три команды короче.

Там есть несколько таких мест. Одно из них обработчик команды CMD_LOAD_ADDRESS.
Было:Стало:Возможно проблема в нем. В этом коде отличий побольше. Новый даже длиннее на 3 команды.