Ассемблер (ASM) для AVR в вопросах и ответах

[С.Н.]

BOB51 писал(а):

....надо в самой IDE (и настройках используемой софтинки -аврдуде) копаться.

У меня получилось из программы на Lazarus шить и фьюзы и bootloader и прошивку с помощью скрытого запуска avrdude. Думаю и с EEPROM все также выйдет.
Если кому надо, могу скинуть строки командные. Только аккуратнее со фюьзами - "кирпичил" уже контроллер.

[КРАМ]

С.Н. писал(а):

Только аккуратнее со фюьзами - "кирпичил" уже контроллер.

Поэтому нужно работать с нормальными программаторами. Чтобы не кирпичить имущество. ПИККИТ4 позволяет сохранять доступ к чипу при любом раскладе.

Добавлено after 4 minutes 43 seconds:

С.Н. писал(а):

Думаю и с EEPROM все также выйдет.

На самом деле у меня есть простой выход. Можно на входе в код затестить ЕЕПРОМ на предмет "virginity" и принять решение по поводу его инициализации из кода дефолтными значениями.

[С.Н.]

КРАМ писал(а):

... ПИККИТ4 позволяет сохранять доступ к чипу при любом ....

Так ведь речь шла про AVR. Не понял я.

[КРАМ]

Просто вы не в курсе, что пиккит4 яаляется штатным программатором отладчиком для АВР. Ведь АВР сейчас является Микрочипом...

[С.Н.]

КРАМ писал(а):

Просто вы не в курсе, что пиккит4 яаляется штатным программатором отладчиком для АВР. Ведь АВР сейчас является Микрочипом...

Надо отметить, что на сайте продавца https://www.chipdip.ru/product/mplab-pi ... t-debugger нет упоминая ядра atmega, про которую шла речь. Ну хорошо, что у Вас есть такой PICKat.

[BOB51]

Пиккит4 поддерживает новые семейства АВРок - но там и протокол обмена другой. Да и достать их заметно заморочнее.
А вот касательно "старых" - там вполне любительские версии с прошивкой справлялись.
Другое дело, ежли использование "внутрисхемной отладки" жестко необходимо... Но то уж "на любителя" и полный конфликт с "импортозамещением".

[КРАМ]

Прикольно обсуждать неимпортнозамещенный чип и рвать на себе волосы по поводу происхождения программатора...
Вообще фиолетово.
Кстати, цена в чипедипе не является референсной. Так то он на Директе 60 баксов.

[akl]

КРАМ писал(а):

...не обнаружил в документации синтаксис инициализации ЕЕПРОМ в АСМ коде...

Директивой .ESEG типа

Код:

.ESEG
.DB 'П','р','о','б','а'

...Можно на входе в код затестить ЕЕПРОМ на предмет "virginity" и принять решение по поводу его инициализации из кода дефолтными значениями.

Имея дефолтные значения, можно пожертвовать 1 из минимум 100'000 циклов записи и запрограммировать fuse_bit EESAVE, чтобы каждый раз при стирании не давать программатору трогать еепром.

[КРАМ]

akl писал(а):

.ESEG

Это я уже обнаружил. Проблема переместилась в другую плоскость. .eseg транслируется не в .hex, а в .eep. И этот самый .eep непонятно куда девать в MPLABX. Автоматически он чип не прошивает. Инструмента для Студии у меня нет и неудобно переключаться между двумя тулчейнами только для EEPROM-а. Поэтому пока не разберусь, напишу проверку чистого EEPROM-а и его инициализацию в начале кода...
Ну и заодно переделал объявления переменных из .equ в нормальные

Код:

.dseg
   .org  0x0100
var: .byte 1


Теперь они видны в Watch при дебаге.

С.Н. писал(а):

Надо отметить, что на сайте продавца .... нет упоминая ядра atmega, про которую шла речь.

Это не самый лучший стиль - смотреть ТТХ товара у продавца на сайте.
https://cdn.sparkfun.com/assets/e/b/a/7/b/DS-15797.pdf

[КРАМ]

Милостивые государи и милостивые государыни! Спешу известить вас о том, что не без помощи технического сообщества обнаружил заветные два числа, которые являются адресным смещением еепрома и фьюзов.
Поэтому нативный доступ к eeprom-у и к фьюзам осуществляется в самом конце программного сегмента (cseg) посредством прибивания гвоздями директивы:

Код:

; инициализация EEPROM
   .org 0x810000
.db ..... байты последовательно по адресам EEPROM от нулевого адреса .....
; инициализация фьюзов
   .org 0x820000
.db ..... байты последовательно в порядке определенном inc-файлом примененного МК для фьюзов .....


[Gudd-Head]

Т.е. за один раз можно зашить память программ и фьюзы?

[КРАМ]

Да, можно.
Но есть один нюанс.
С одним org-ом по этим адресам нужно писать не более двух байт. Иначе линкер глючит.
Ну и ассемблер вываливает варнинги, что типа пытаешься определить область вне флеша. Но на это не нужно обращать внимание.

[Starichok51]

КРАМ, это для каких МК такие длинные адреса?
например, в АТмега8 я не могу задать трехбайтовый адрес.

[КРАМ]

Я нынче говорю про ATmega165.
Старичок, я вроде бы достаточно понятно выразился про адрес.
Этот адрес в ЛЮБОМ AVR лежит вне адресного пространства cseg, однако хоть и с варнингами и некоторыми выше обозначенными нюансами, позволяет поместить константы в еепром, фьюзы и даже локбиты.

[Starichok51]

выразился ты понятно, но про ЛЮБОЙ AVR я не могу с тобой согласиться. я же сказал, что в АТмега8 нет возможности при программировании задать трехбайтовый адрес.
при программировании для АТмега8 можно отправить только 2 байта адреса.
да, в AVR с большим размером флеши есть команда отправки старшего байта адреса. но у "младших" МК такой возможности нет.
посмотрел сейчас даташит на ATmega165, я там тоже не увидел при программировании отправки третьего байта адреса.
может, ты лишних 2 нуля приписал к указанным адресам? и там всего по 2 байта (0x8100 и 0x8200)?

[КРАМ]

Starichok51 писал(а):

может, ты лишних 2 нуля приписал к указанным адресам? и там всего по 2 байта (0x8100 и 0x8200)?

Так, Старичок, внимательно и по слогам. Я НЕ ОШИБСЯ.
Скрин я показал.
Можешь повторить сам.
Указанные адреса НЕ ВХОДЯТ в адресное пространство флеша. Это виртуальные адреса еепрома (0х810000), фьюзов (0х820000) и локбитов (0х830000).
ЗЫ. Что характерно, при открывании окна фьюзов в MPLABX этот виртуальный адрес ПРЯМО ОТОБРАЖАЕТСЯ:

ЗЗЫ. И все это придумал не совсем я.
Началось все с того, что один товарищ придумал править хекс, дописывая туда еепром из eep-файла с адресным смещением 81, а фьюзы с адресным смещением 82.
Я всего лишь развил эту мысль резонно предположив, что avrasm2 съест это адресное поле. И он его съел.
А мои нынешние игрища с живым ATmega165P лишь подтвердили действия симулятора. С этим нынче и работаю.
К процедуре программирования эти адреса не имеют отношения. Просто PICki4 и другие программаторы Микрочипа при прошивке интерпретируют виртуальные адреса в требуемую диаграмму согласно мануалу на программирование. Но так работают все программаторы всех фирм.

[Starichok51]

интересное кино...
я MPLABX не пользуюсь. может, поэтому для меня это не доступно.
ну, хорошо, MPLABX показывает эти виртуальные адреса.
показ показом. но я говорю про программирование.
при программировании можно отправить только 2 байта адреса.
я себе сделал собственные разработки и последовательного программирования (по SPI) и параллельного программирования. и я точно знаю, что есть возможность отправить только 2 байта адреса. и хоть USBasp, хоть MPLABX - 3 байта адреса они не отправят.
только у МК, у которых больше 128 кБ (более 64 к адресов) флеши, есть отправка старшего (третьего) байта адреса.

[КРАМ]

Starichok51 писал(а):

MPLABX - 3 байта адреса они не отправят.

Ты в состоянии прошить ЕЕПРОМ?
А фьюзы?
А лок-биты?
Ты в состоянии написать код для программатора, который интерпретирует адрес из хекса 0х810000 как необходимость прошить нулевой байт еепрома ТОЙ ДИАГРАММОЙ, которая для этого нужна?
С какого перепуга ты решил, что еепром нужно прошивать так же, как и флеш лишь на том основании, что еепрому назначили виртуальный адрес в хексе?

PS. Напомню.
Четыре байта посылаемые при программировании в чип начинаются байтом команды.
0х60 - программирование младшего байта флеша
0х68 - программирование старшего байта флеша
0хС0 - программирование байта EEPROM
Что мешает интерпретировать смещение адреса (верхний адрес) 0х81 как команду 0хС0 при программировании?

[Starichok51]

тебе и мне ничего не мешает интерпретировать, как мы пожелаем.
но для меня это непонятно, как МК решит, что 0х81 - это то же самое, что 0хС0.

[КРАМ]

Starichok51 писал(а):

но для меня это непонятно, как МК решит, что 0х81 - это то же самое, что 0хС0.

А причем тут МК?
МК не потребляет хекс-файл по ISP интерфейсу. Ему вообще непонятен ASCII текст, которым написан хекс.
Между МК и хексом находятся две сущности - оболочка программатора в виде ПО на компьютере и сам железный программатор, который формирует протокол обмена физического уровня в том числе.
Реализовать парсинг хекса можно и в оболочке и контроллере программатора.
Что тут непонятного?