Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: ATmega64 - Operand 1 out of range: 0x36?
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > MCS51, AVR, PIC, STM8, 8bit
jokolemene
Написал программу для ATmega64 на Си. Использовал IAR C. Всё нормально, всё работает. Теперь встала задача написать бутлоадер, чтобы грузить прошивку в проц удалённо. Решил писать на ассемблере. Выяснилось, что ассемблер IAR-а балдеет от русских комментариев - то повиснет, то какие-то другие глюки начинают происходить. Пришлось с IAR перейти на AVR Studio 4 и AVR Assembler. Теперь другая проблема - компилятор ругается на совершенно легальные команды типа "sbi tifr,icf1", что мол "Operand 1 out of range: 0x36". По доке на процессор видно, что адрес 0x36 попадает в область I/O этого проца и с включенным режимом совместимости с ATmega103 и с выключенным. Что за тема, не въеду? Как это победить?
V_G
Достаточно почитать хэлп на инструкцию SBI (поставить курсор на инструкцию и нажать F1). Она работает с адресами до 31 (0x1F)
rezident
Цитата(jokolemene @ May 6 2010, 12:12) *
Выяснилось, что ассемблер IAR-а балдеет от русских комментариев - то повиснет, то какие-то другие глюки начинают происходить.
Вовсе не от любого комментария на русском, а только от маленького кириллического символа "я", который в кодировке WIN-1251 имеет код конца файла (0xFF). Для компиляции в IAR уже готового исходника достаточно средствами реактора заменить маленькую "я" на большую "Я". Читаемость комментариев нисколько не ухудшиться, но ошибки, связанные с этим символом, пропадут.
zltigo
Цитата(rezident @ May 9 2010, 03:02) *
только от маленького кириллического символа "я", который в кодировке WIN-1251 имеет код конца файла (0xFF).

Это не конец файла - "конец" ^Z, т.е. 0x1A
Болезьнью 0xFF до сих пор болели текстовые редакторы, которым необходимо было в процессе редактирования иметь во внутреннем представлении редактируемого файла иметь виртуальные разделители. Для компиляторов это явный баг, видимо отрыжка unicode sad.gif.
Если не требуется вывод кирилицей в WIN кодировке, то лечится использованием нормальных редакторов поддерживающих разные кодировки и работа в "досовской" CP866. Кстати, нормальные редакторы можно попросить и менять 'я' на 'Я' при вводе. А еще можно не писать комментарии на русском smile.gif экономит время на переключении раскладок smile.gif.
SasaVitebsk
Могу ещё кое что добавить. smile.gif
У меня есть версия IAR 5.11, которая ни грамма не ругается, а прекрассно всё компилит. А вот версия 5.4 действительно не может пережить "я". Обратил внимание, что там какая-то локализация типа японской что-ли.

По бутлоадеру - обычно достаточно прописать на асме только узкие части. Я, например писал дешифрацию и crc. На остальном потери незначительны, зато поддерживать на Си легче.
rezident
Цитата(zltigo @ May 9 2010, 12:41) *
Это не конец файла - "конец" ^Z, т.е. 0x1A
Я имел в виду символ EOF, а не скан-код.
zltigo
Цитата(rezident @ May 9 2010, 20:02) *
Я имел в виду символ EOF

С этими еще проще - он по жизни int, посему с 0xFF не соотносится.
XVR
Цитата(zltigo @ May 9 2010, 21:21) *
С этими еще проще - он по жизни int, посему с 0xFF не соотносится.
К сожалению, у некоторых 'софтописателей' (язык не поворачивается назвать их програмистами) есть некоторое непонимание того факта, что char может быть по умолчанию знаковым (т.е. signed char), а буквы могут занимать и вторую половину ASCII таблицы. Так что 0xFF после расширения знака замечательно преобразуется в -1, каковая и является EOF.
jokolemene
Да, насчёт sbi я уже разобрался, help почитал. Так что спасибо за подсказку. Просто ни разу не писал на ассемблере для atmega. Раньше работал всё больше с пиками. Поэтому тут был несколько удивлён такими ограниченными командами, которые могут работать или только с частью регистров или с частью портов ввода/вывода или с малыми константами. Такие странные ограничения несколько напрягли.

И спасибо за подсказку насчёт IAR ассемблера. Правда сейчас я на него уже вряд-ли буду переходить, потому что бутлоадер уже в стадии отладки.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.