Кто на чем чаще пишет для AVR и не только?

[Peter_I]

И ещё вопрос: когда для avr-objcopy надо указывать tekhex?

Пётр.

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[Peter_I]

Ошибка где-то в программе. Я попробовал компилировать правильнее, такой последовательностью

#

rm -f lighting_c.o lighting_c.lst lighting_c.hex lighting_c.elf
avr-gcc -c -Wall -mmcu=atmega1284p -Wa,-warn,-als=lighting_c.lst,-mmcu=atmega1284p,"-o lighting_c.o" lighting_c.S
set stts = $?
/bin/echo "gcc status="$stts
if ( $stts == 0 ) then
avr-ld -o lighting_c.elf lighting_c.o
set stts = $?
/bin/echo "ld status="$stts
if ( $stts == 0 ) then
#avr-objcopy -j .text -j .data -O ihex lighting_c.elf lighting_c.hex
avr-objcopy -S -O ihex lighting_c.o lighting_c.hex
set stts = $?
/bin/echo "as status="$stts
endif
endif

и получил сообщение от avr-ld

gcc status=0
avr-ld: avr:51 architecture of input file `lighting_c.o' is incompatible with avr output
avr-ld: lighting_c.elf section `.text' will not fit in region `text'
avr-ld: region `text' overflowed by 53454 bytes

Пётр.

Изменено 31 марта, 2015 пользователем Peter_I

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[Peter_I]

Вроде бы надо вызов avr-ld делать так:

avr-ld -o lighting_c.elf -b binary lighting_c.o

при этом всё строится, но hex по-прежнему неправильный из-за ошибки в секции .text.

Если отказаться от части, начинающейся с

.org 0xF000

то создаётся hex-файл размером 1506.

Пётр.

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[Peter_I]

Ещё вот возник вопрос: в программе для ATmega1284 адреса векторов прерывания должны быть кратны 2 или 4?

У него FLASH - 128K. Я заметил, что команда jmp отбирает 4 байта памяти.

Пётр.

[donec]

.

[mail_robot]

тема из "кто на чем пишет" превратилась в - пофик кто на чем пишет, надо на асме )

[Peter_I]

Эту таблицу, я, конечно, видел, но, как я понял из iom1284p.h, в байтах вектор прерываний занимает (35 * 4),

т.е. 4 байта на каждый jmp. М.б., это адреса в словах?

И почему-то у меня avr-ld считает, судя по map-файлу, что размер .data - 65440, а размер .text - 8192, хотя это SRAM имеет размер 8K.

Пётр.

[Peter_I]

Ещё есть различия. Если avr-gcc сам вызывает линковщик и строит elf,

либо он создаёт o-файл и я сам вызываю avr-ld с подключением того, что ему надо.

В 1-м случае размер text в map-файле правильный - 0x20000, а во 2-м почему-то 0x2000,

а длина data в в 1-м случае0xff00, а во 2-м - 0xffa0.

Если же в 1-м случае через avr-gcc передать линковшику -Tmem_def, он ниже,

то длина data становится равной указанному - 0x2000, т.е. 8KB, но hex остаётся неправильной длины,

а во 2-м, когда -Tmem_def указывается непосредственно как опция avr-ld,

происходит его крах.

MEMORY
{
text (xr) : ORIGIN = 0x0000000000000000, LENGTH = 0x0000000000020000
data (rw !x) : ORIGIN = 0x0000000000800100, LENGTH = 0x0000000000002000
eeprom (rw !x) : ORIGIN = 0x0000000000810000, LENGTH = 0x0000000000010000
fuse (rw !x) : ORIGIN = 0x0000000000820000, LENGTH = 0x0000000000000400
lock (rw !x) : ORIGIN = 0x0000000000830000, LENGTH = 0x0000000000000400
signature (rw !x) : ORIGIN = 0x0000000000840000, LENGTH = 0x0000000000000400
user_signatures (rw !x) : ORIGIN = 0x0000000000850000, LENGTH = 0x0000000000000400
}

Пётр.

Изменено 1 апреля, 2015 пользователем Peter_I

[Геннадий]

Эту таблицу, я, конечно, видел...

Команда jmp занимает 4 байта(2 слова). Размер адреса памяти программ 1 слово. Поэтому, когда получаете адрес массива из области памяти программ, его надо умножать на 2. Например, ldi zl,low(имя<<1).

[Peter_I]

Эту таблицу, я, конечно, видел...

Команда jmp занимает 4 байта(2 слова). Размер адреса памяти программ 1 слово. Поэтому, когда получаете адрес массива из области памяти программ, его надо умножать на 2. Например, ldi zl,low(имя<<1).

Да, я так и предполагал.

Осталось последнее - добиться, чтобы при отведении места под bootloader, а он занимает старшие килобайты FLASH,

hex строился правильного размера, а не в полтора раза больше. Т.е. он начинается с адреса 0xF000, если адрес в словах

то это и есть начало последних 8K из 128K, а hex получается 171K, а не 120K. пока не понял, где у меня ошибка.

Пётр.

Кстати, насчёт умножения на 2 и в книге сказано, но у меня вместо low() и ligh() - lo8() и hi8().

Изменено 1 апреля, 2015 пользователем Peter_I

[Геннадий]

Посмотрите структуру hex. Там много избыточной информации (адреса, кс). Преобразуйте его в bin, тогда увидите истинный размер. Сейчас Вы делаете две таблицы векторов прерываний. Зачем?

[Peter_I]

Посмотрите структуру hex. Там много избыточной информации (адреса, кс). Преобразуйте его в bin, тогда увидите истинный размер. Сейчас Вы делаете две таблицы векторов прерываний. Зачем?

Как я понял из описания процессора, если запрограммирован BOOTRST, то по сбросу управление передастся на адрес 0xF000,

поэтому там и должны находится и переход на загрузчик и далее вектор прерываний. Когда bootloader закончит работу, он передаёт

управления на адрес 0, там, как обычно, находится переход на собственно программу и за ним - рабочий вектор прерываний,

перенести указатель на который должен тоже bootloader. В описании именно так и с примером.

Посмотреть hex я бы и сам хотел, но мне до сих пор никогда не приходилось этого делать.

Я не знаю, есть ли специальная программа для его просмотра или как преобразовать его в bin.

Вообще там область между концом программы и bootloader просто заполняется нулями.

Пётр.

[Alex]

Intel HEX

Это просто текстовый файл.

[Alexeyslav]

Странно, пытаешься написать программу для контроллера а не знаешь как открыть любой файл на просмотр... может, еще и MS-DOS не застал? и файлы *.DBF?

[Peter_I]

Intel HEX

Это просто текстовый файл.

Так-то я его смотрел во viewer'e, но формата не знал, хотя адреса там ясно видны.

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

Пётр.

Странно, пытаешься написать программу для контроллера а не знаешь как открыть любой файл на просмотр... может, еще и MS-DOS не застал? и файлы *.DBF?

DOS застал, но не помню, чтобы мне приходилось работать с файлами *.dbf. Вообще я с базами данных дела не имел.

Мне приходилось делать небольшие программы на ассемблере для IBM PC и для PIC,

но ещё ни разу не требовалось просматривать прошивку.

Пётр.

Изменено 1 апреля, 2015 пользователем Peter_I

[Alex]

Пётр, прошивка для МК - это далеко не исполняемый файл, как .exe на PC. Не путайте.

.hex - это обычный текстовый файл, в котором хранятся данные в текстовом представлении. Естественно, объём такого файла будет в разы больше объёма самих данных.

[Peter_I]

Пётр, прошивка для МК - это далеко не исполняемый файл, как .exe на PC. Не путайте.

.hex - это обычный текстовый файл, в котором хранятся данные в текстовом представлении. Естественно, объём такого файла будет в разы больше объёма самих данных.

Несколько лет назад мне приходилось иметь дело с программой для AVR, написанной на C другим человеком.

Когда мне приходилось записывать получившийся hex в микроконтролер, то, насколько я помню, там требовалось,

чтобы он был не больше размера FLASH. Опять же я не интересовался, как именно hex записывается в МК,

но по работе avreal у меня сложилось впечатление, что один к одному. Она может также и считать прошивку

из МК и результат совпадал с ранее зашитым hex. Это был atmega168.

А в данном случае hex получился больше FLASH.

Пётр.

[Alex]

Возможно, там был какой-нибудь бинарный файл (что-то типа .bin). Тогда объём будет совпадать, т.к. данные хранятся в явном виде.

[Peter_I]

Возможно, там был какой-нибудь бинарный файл (что-то типа .bin). Тогда объём будет совпадать, т.к. данные хранятся в явном виде.

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

Но мне сейчас подтвердили, что это bin записывается как есть, а из hex при записи в МК команды извлекаются.

Действительно, не записывать же в него двоеточия.

Пётр.

Изменено 2 апреля, 2015 пользователем Peter_I

[Peter_I]

Здравствуйте!

Возник дополнительный вопрос.

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

и я попытался avr-gcc вызывать только для компиляции, с опцией "-c", а потом самому вызывать avr-ld

и это у меня не получилось.

Во-первых, в map-файле размер сегмента .text оказывается 0x2000,

а не 0x20000, как должно быть и как получается, когда avr-gcc сам строит elf.

Во-вторых, avr-ld при этом не извлекает .text из объектного файла, т.е. собственно программы нет в elf,

а "avr-objcopy -t .text" даёт пустой hex, только с конечной строкой.

В-третьих, при указании опции -Tmem_def, где mem_def - это файл с описанием распределения памяти,

с avr-ld происходит segmentation fault, а когда всё делает avr-gcc и передаёт эту опцию линковщику через Wl,

он её принимает. При этом оказалось, что она должна идти после -Map=<map-file>, а иначе тоже происходит крах.

Ниже приведён маленький скрипт на tcsh, в котором я сам вызываю avr-ld, а за ним mem_def.

Образец mem_def я взял из программы, написанной другим человеком и приспособил к своим условиям.

Не скажете ли, что не так в скрипте? Там надо смотреть две строки после #crtm1284p.o only.

#

set flnm = $1
rm -f ${flnm}.o ${flnm}.lst ${flnm}.hex ${flnm}.elf ${flnm}.map
avr-gcc -c -o ${flnm}.o -Wall -mmcu=atmega1284p -Wa,-warn,-als=${flnm}.lst,-mmcu=atmega1284p,"-o ${flnm}.o" ${flnm}.S
#avr-gcc -c -o ${flnm}.o -Wall -mmcu=atmega1284p -Wa,-warn,-als=${flnm}.lst,-mmcu=atmega1284p ${flnm}.S
set stts = $?
/bin/echo "as status="$stts

#crtm1284p.o only
#avr-ld -r -S -o ${flnm}.elf -Map=${flnm}.map -Tmem_def -b binary /usr/lib/avr/lib/avr51/crtm1284p.o -b binary ${flnm}.o
avr-ld -r -S -Map=${flnm}.map -o ${flnm}.elf -b binary /usr/lib/avr/lib/avr51/crtm1284p.o -b binary ${flnm}.o

#crtm1284p.o and libgcc.a
#avr-ld -r -S -Map=${flnm}.map -Tmem_def -L /usr/lib/gcc/avr/4.8.2/avr51 -b binary -lgcc -L /usr/lib/avr/lib/avr51 -b binary -lc -lm -o ${flnm}.elf -b binary /usr/lib/avr/lib/avr51/crtm1284p.o -b binary ${flnm}.o
#avr-ld -r -S -Map=${flnm}.map -L /usr/lib/gcc/avr/4.8.2/avr51 -b binary -lgcc -L /usr/lib/avr/lib/avr51 -b binary -lc -lm -o ${flnm}.elf -b binary /usr/lib/avr/lib/avr51/crtm1284p.o -b binary ${flnm}.o

#crtm1284p.o, libgcc.a, libc.a, libm.a
#avr-ld -r -S -L -Map=${flnm}.map -Tmem_def /usr/lib/gcc/avr/4.8.2/avr51 -b binary -lgcc -o ${flnm}.elf -b binary /usr/lib/avr/lib/avr51/crtm1284p.o -b binary ${flnm}.o
#avr-ld -r -S -L -Map=${flnm}.map /usr/lib/gcc/avr/4.8.2/avr51 -L /usr/lib/avr/lib/avr51  --start-group -b binary -lgcc -b binary -lc -lm --end-group -o ${flnm}.elf -b binary /usr/lib/avr/lib/avr51/crtm1284p.o -b binary ${flnm}.o
set stts = $?
/bin/echo "ld status="$stts
if ( $stts == 0 ) then
avr-objcopy -j .text -O ihex ${flnm}.elf ${flnm}.hex
set stts = $?
/bin/echo "objcopy status="$stts
endif

mem_def:

MEMORY
{
 text (xr) :						   ORIGIN = 0x0000000000000000, LENGTH = 0x0000000000020000
 data (rw !x) :					    ORIGIN = 0x0000000000800100, LENGTH =  0x0000000000002000
 eeprom (rw !x) :					  ORIGIN = 0x0000000000810000, LENGTH = 0x0000000000010000
 fuse (rw !x) :					    ORIGIN = 0x0000000000820000, LENGTH = 0x0000000000000400
 lock (rw !x) :					    ORIGIN = 0x0000000000830000, LENGTH =  0x0000000000000400
 signature (rw !x) :		   ORIGIN = 0x0000000000840000, LENGTH =  0x0000000000000400
 user_signatures (rw !x) : ORIGIN = 0x0000000000850000, LENGTH = 0x0000000000000400
}

Пётр.

[demiurg1978]

С МК AVR начал работать в 2007 году. Писал только на асме и был ярым его поклонником. Но когда начал делать проекты с многоуровневым меню, понял что пора переходить на си. В этот момент я отложил все проекты, пока более-менее не освоил си. С тех пор все мои проекты на си. Многие проекты на асме перенес на си. На асме писал примеры для форумов, и пару-тройку раз писал простенькие тестовые программки, когда срочно нужно было кое-что проверить. Ни одного проекта на асме не было написано с тех пор как перешел на си.

[trengtor]

mikroPascal

[mail_robot]

Си как таковой уже давно стал лишь оболочкой в серьезных проектах. Говорить о нем как о чистом языке уже врятли будет уместным. Асм так же уже давно стал нишевым.

Так что чистого пречистого языка уже не встретить наверное

[vr1]

си + вставки асм в специфических местах

[madtux]

угу, я тоже на паскале. Вполне себе. Удобно. Если чего, можно ассемблерную вставку.