AVReAl update — 1.28r8
Вийшла нова версія програматора avreal — v1.28r8 (Sat 2011-08-13).
- Додано підтримку двійкового формату файлів (raw binary).
Формат задається префіксом :bin: в імені файлу. - Змінено поведінку ключа -r.
При використанні ключа з модифікатором -r+ у вихідний файл записується весь вміст відповідного регіону пам’яті мікроконтролера, тобто поведінка відповідає «старій» поведінці ключа.
Без модифікатора, у формі -r, у вихідний файл формату :ihex: не записуються рядки, які в полі даних мають лише байти FF. У файли формату :bin: не записується «хвіст», що складається лише з FF.
українська
english
Ще виникло питання – як стерти EEPROM при програмуванні в 128-й атмезі. Окремий запуск програми з встановленням -feesv=0 результату не дає:
-feesv=0 — це зовсім інше. Це фьюз заборони стирати EEPROM при стиранні мікросхеми по -e
При записаному eesv по команді стирання кристалу внутрішній автомат зітре лише флеш.
Щоб по -e стиралася пам’ять EEPROM, треба записати -feesv=1. При наступних запусках avreal -e стиратиметься і EEPROM.
Все працює, дякую за підказку.
Хе. Ще б додати підтримку формату elf.
І ти туди ж 🙂
Та я давно розумію, що підтримка elf «дуже бажана». З тих пір, як додали стандартизований спосіб записати в нього fuses.
Будемо вважати, що перший крок зроблено.
Ну, там запропонували викликати враппер який викликає objcopy, а потім avreal. Ця ідея і так у повітрі. В принципі під юніксом зазвичай можна покладатися і на наявність objcopy, і на наявність libbfd.
А можна лінку на стандартний спосіб тримання фузів у ELF ?
В першому повідомленні там шукають програматор з підтримкою ELF.
Стандартний спосіб — розміщення певної проініціалізованої структури у зарані визначеній секції .fuse
Користуватсия через включення avr/fuse.h
BootLockBits живуть в одному байті з LockBits і тому потрапляють в іншу секцію, .lock. І живуть в avr/lock.h
В лінкерних скриптах секції прибито на фіксовані адреси.
Тому можна було б викидати їх у hex-файл без зміни адреси, як то робиться для секції .eeprom, і брати програматором з тих верхніх адрес.
Не можу прошити бінарнік, строка – avreal32.exe +mega128 -p1 -aa -o3.686MHZ -e -w -c :bin:load.bin, результат(скорочено) – …Device erased Device connected, mega128|mega128A detected Fuses .. Programming CODE memory ….. done(!)(295ms) Total time 0,75s Reset pin released Adapter disabled… Як видно з виведеного результату роботи програми запис даних відбувається, але чомусь тільки невеликої частини.
Дивно. А якщо прочитати тепер у вихідний :bin:-файл?
Я вдома на mega168 перевіряв, зараз спробую на mega128, але там принципової різниці немає, бо зміни у програмі були лише в частині завантаження файлу з диска. Далі процедури запису отримують дані не знаючи, звідки вони.
Пробував заливати туж прошивку в hex – все в нормі.
Щойно оце повернувся з наради і спробував зашити великий (більше 100К) файл в mega128. У мене був hex-файл з випадковими даними, згенерований srecord-ом. Я трохи повирізав, щоб були дірки і обрізав хвіст, щоб перевіряти -r/-r+.
Тим же srec-cat-ом перегнав в bin, записав bin, верифікацію зробив з hex — співпало.
Прочитав окремо в bin в інший файли, він побайтно співпав з початковим.
«Тю, зараза». Вишліть мені на пошту bin та hex файли, я спробую їх позаливати.
Конвертую цією програмкою http://www.blog-cub.pp.ua/программа-конвертация-hex-в-bin, може то справа в ній(хоча Uniprog шиє нормально). Спробую ще залити неконвертовані нею bin-файли, але то вже десь аж після завтра.
А все ж таки вишліть мені прошивки — обидві, і hex, і ту конвертовану. На ту адресу, яку avreal виводить на екран.
Наче й не повинно від самих даних нічого залежати, але…
Цікаво ж і розібратися.
Фальшива тривога, проблема виявилася не в програмі, а в операційній системі. Для зручності заливки програм я створив ВАТ файл, який б шукав файл з певним розширенням в певній папці, копіював його в іншу папку, перейменовував і прошивав. Ось частина:
if exist …\need_to_load\*.hex (copy …\need_to_load\*.hex …\load\load.hex
…\AVReal\avreal32.exe +mega128 -p1 -aa -o3.686MHZ -e -w -c …\load\load.hex)
if exist …\need_to_load\*.bin (copy …\need_to_load\*.bin …\load\load.bin
…\AVReal\avreal32.exe +mega128 -p1 -aa -o3.686MHZ -e -w -c :bin:…\load\load.bin)
…-повний шлях до файлу.
Так от, для правильного копіювання необхідно було задати папаметр /B. Без нього система копіювала бінарнік – тільки 127 байт, а в hex додавала в кінець файлу один лишній симлол(байт)(на роботу програми не впливало).
if exist …\need_to_load\*.hex(bin) (copy …\need_to_load\*.hex(bin) /B …\load\load.hex(bin) /B
…\AVReal\avreal32.exe +mega128 -p1 -aa -o3.686MHZ -e -w -c (:bin:)…\load\load.hex(bin))
P.S. Без 100 грам не розберешся…
Символ Control-Z в багатьох системах здавна означав кінець текстового файлу.
В текстовому режимі копіювання COPY його додає в кінці, якщо його не було, та копіює по нього, якщо він є, все далі ігнорує.
Ну і добре, що все знайшлося.