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

[BOB51]

У каждого МК
СВОЯ
область адресов для спецданных.
Может напрямую читаться/записываться, а может и нет.
У ПИКов она оговорена заранее в документации.
У АВРок (по крайней мере "стандартных", до появления новых семейств) определено было только размещение сигнатуры типа МК и калибровки встроенного генератора.
И то похоже на вариант скрытого внутреннего "перепланирования" доступа к ячейкам.
Так что не факт, что области адресов, полученные опытным путем для одного кристалла совпадут с областями адресов другого.
А вот в новых моделях скорее всего микрочип сделает доработку с "приведением разметки" к единообразию.
Что лучше/хуже с точки зрения ситуации "случайного доступа" к тем спецячейкам - сказать сложно...
С одной стороны - все легкодоступно для прошивки, с другой - вопрос "нелегального доступа" к коду программы.
Ну и стоит туда же всякосторонние клоны отнести - там вопрос прошивки совсем уж "специфичен" при том, что система команд одинакова.


КРАМ
Меня удивило как это на крутого профи снизошла идея копаться в нестандартном (любительском) стиле использования компиляторов?
Это же отрицаемое Вами "ЛЮБИТЕЛЬСТВО"!
Да еще и такие грубости в общении...
ФЕЕЭЭЭ...

[КРАМ]

В каком месте грубости и что в предложенном любительского?
Кроме того, все без исключения АТмеги имеют идентичный протокол ISP.
Более того, все МК Атмела имеют в протоколе ISP возможность чтения всех областей флеша, еепрома, фьюзов, локов и ID чипа.
Нет никаких проблем для создания небольшой базы чипов в ПО и спокойно шить все области из одного хекса даже если есть отличия в адресах.

[BOB51]

Протокол то единый, да области размещения разные.
(у "сторонних производителей" не факт, что протокол загрузки такой же будет - там только единый формат файлов от компилятора сохраняется).
При таком подходе возможно удобен отдельный раздел в заголовке главного файла исходника с дополнительными участками, прописанными в *def.inc файлах каждого кристалла.
Как вариант - дополнение в софт-оболочке программатора, способное опознавать отдельную область *.hex файла, предназначенную для прошивки соответствующих участков ПЗУ.
Возможно и "совместное" дополнение - как в тексте исходника и *def.inc файле, так и в софте программатора.

Но тут уже "сила привычки" - или пользуемся тем, что уже имеется или весьма много менять придется (что не всем интересно).
Делать "с нуля" и доработку стандартного софта и самодельный программатор (железо и сопровождающий софт) самостоятельно - дело гиблое и ленивое (по себе знаю - та же котуинка на 51й ).
Однако... Ежли у кого получится - всегда все рады будут.

[КРАМ]

Области размещения тоже идентичные.
Протокол ISP не делает различий между чипами, заливая флеш, еепром и остальное совершенно идентично. Да и Мануал по ISP общий для всех.
Так что это не вопрос железа, а вопрос парсинга хекса.
Поскольку Старичок делал это железо, то мой тон отражает лишь удивление тем, что он не понимает о чем я пишу.
У меня сложилось впечатление, что его железо не парсит хекс, а лишь использует готовое ПО с имеющимся протоколом между ПО и железом.

[Starichok51]

Так что это не вопрос железа, а вопрос парсинга хекса.

именно то, что это вопрос железа.
парсингом хекса занимается ПО комповой программы, а не сам МК. поэтому я тебе задал этот вопрос: как МК решит, что 0х81 - это то же самое, что 0хС0? но ты на него не ответил.

У меня сложилось впечатление, что его железо не парсит хекс, а лишь использует готовое ПО с имеющимся протоколом между ПО и железом.

как уже сказал, парсит хекс ПО, а не железо. или ты думаешь, что ПО передает в МК хекс, а МК умеет его парсит? тогда ты заблуждаешься.
парсит ПО, а по интерфейсу ПО передает только команды в полном соответствии с протоколом, описанном в даташите.
ПО я тоже писал сам своё. и моё ПО работает через СОМ порт и через USART, а не через USB.
я сумел при тактовой частоте 8 МГц поднять скорость USART до 250000 бод, что позволило иметь скорость работы программатора ни чуть не меньше скорости по USB.
при сравнении с usbasp разницы с моим ПО я практически не заметил.

[КРАМ]

Starichok51 писал(а):

именно то, что это вопрос железа.
парсингом хекса занимается ПО комповой программы, а не сам МК.

У нас с тобой полное расхождение терминологии.
Давай я определю свою терминологию и тогда ты поймешь о чем я говорю.
При программировании МК, который я далее буду называть ТАРГЕТом, выстраивается цепочка из ТРЕХ компонентов: ПО->программатор->таргет.
Под железом я понимаю ПРОГРАММАТОР, а не таргет.
Так вот, парсингом может заниматься как ПО, так и ПРОГРАММАТОР. Естественно, что во втором варианте программатор должен из себя представлять не "пять проводков", а полноценное устройство под управлением СОБСТВЕННОГО микроконтроллера. Так делают все нормальные программаторы, включая упомянутый мной ранее PICkit4.
Но где ты будешь заменять 0x81 на 0xC0 - совершенно безразлично. Можно в ПО, а можно в программаторе. С точки зрения функциональности программатор предпочтительнее. Поэтому оный PICkit4 может шить все подряд, а так же являться дебаггером для кучи совершенно разных платформ МК.

BOB51 писал(а):

У каждого МК
СВОЯ
область адресов для спецданных.
Может напрямую читаться/записываться, а может и нет.
У ПИКов она оговорена заранее в документации.
У АВРок (по крайней мере "стандартных", до появления новых семейств) определено было только размещение сигнатуры типа МК и калибровки встроенного генератора.
И то похоже на вариант скрытого внутреннего "перепланирования" доступа к ячейкам.

Это категорически не так.
Достаточно открыть мануал по программированию Атмела и убедится в этом. Всё как у всех.
Область фьюзов может иметь виртуальные адреса, а может не иметь. Это совершенно безразлично. Программирование все равно имеет специальный протокол для каждой секции. Только сейчас отдельные МК с целью удешевления используют флеш идентичный программному для еепрома и фьюзов, в результате доступ к ним в некоторой степени унифицировался при самопрограммировании МК. Но и только.

Последний раз редактировалось КРАМ Вс окт 15, 2023 15:18:42, всего редактировалось 1 раз.

[Starichok51]

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

[КРАМ]

Starichok51 писал(а):

мне по херу, где ты будешь заменять 0xC0 на 0x81.

У тебя все нормально сегодня? Заменяется не 0xC0 на 0x81, а 0x81 на 0xC0...

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

Но где ты будешь заменять 0x81 на 0xC0 - совершенно безразлично. Можно в ПО, а можно в программаторе.

Читаем внимательно...

Starichok51 писал(а):

как таргет узнает, что 0x81 является эквивалентом 0xC0?

А таргет и не узнает. Ему вообще не нужно об этом знать. ПО или программатор заменят 0x81 на 0xC0. По моему я ясно об этом сказал.

[Starichok51]

По моему я ясно об этом сказал.

а по-моему, ты ясно имел в виду, что вместо 0xC0 можно отправить 0x81. лично я именно так тебя понял.
а на хера я стану заменять 0x81 на 0xC0? если я сразу могу послать 0xC0.
так зачем мозги пудрить этими адресами 0x81, 0x82 и тому подобное, а потом подменять эти адреса командами? если удобнее посылать соответствующие команды согласно протокола.

[КРАМ]

Starichok51 писал(а):

зачем мозги пудрить этими адресами 0x81, 0x82 и тому подобное, а потом подменять эти адреса командами? если удобнее посылать соответствующие команды согласно протокола.

Это феерично...
Старичок, ты меня конечно извини, но наверное стоит сначала ознакомиться с первым сообщением, которым я открыл обсуждаемый тут вопрос.
Задача состоит в том, чтобы не городить кучу файлов и методов прошивки МК, а просто прошить ОДИН ЕДИНСТВЕННЫЙ ХЕКС, в котором будут и программный код, и содержимое ЕЕПРОМа (опционально), и фьюзы, и лок-биты.
Для этого хекс должен содержать виртуальные адреса этих сегментов, патамушта, например, файл .eep имеет адресное смещение равное нулю и отличить его от программного хекса можно только по расширению файла и по раздельной загрузке. Это клинический идиотизм.
Если, например, в АРМах файлы бутлоадера и апликейшена отдельны, то у них имеются разные адреса загрузки и оба файла прошиваются в один прием.
Но в этом есть смысл, потому что бутлоадер один для всех проектов. А тут какая то непонятная нормальному человеку хрень.

Starichok51 писал(а):

а по-моему, ты ясно имел в виду, что вместо 0xC0 можно отправить 0x81. лично я именно так тебя понял.

Процитируй где я об этом писАл?
Я писал лишь то, что В ИСХОДНИКЕ можно обозначить виртуальный 24-разрядный адрес, который ассемблер и линкер приведут к единому хексу, который будет залит через PICkit4 в правильные области МК. И всё.

[Starichok51]

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

[Just_Fluffy]

КРАМ, Т.е. трансляцию адресов делает именно прошивальщик (PICKit4-железяка)? Не зависимо от того, что на ПК запущено? Или все же MPLABX разруливает виртуальные адреса в хексе и уже командует прошивальщику, чего слать в МК?

[Martian]

Тогда в памяти программатора должно быть что-то "разруленное", для автономного программирования серии микроконтроллеров. Честно говоря, я хоть и наблюдал за обсуждением, но так и не понял особой разницы и преимуществ, в зависимости от того, где что происходит.
Вот если бы в программатор можно было воткнуть флэшку, с которой он считал бы обычный текстовый файл с прошивкой, и сам бы там всё необходимое проделал бы - тогда понятно... Но если он всё равно подключается к компьютеру, то можно ведь как у CY - только интерфейс USB, подгрузка дескрипторов, а дальше что с хоста придёт - тем и станет...

[Dismas]

Martian писал(а):

...Вот если бы в программатор можно было воткнуть флэшку...

В PICkit4 именно так и есть.
В среде разработки создаётся проект, выбирается “Programmer To Go PICkit3/PICkit4”.
Далее программа создаст HEX-файл и загрузит его на SD-карту, а сам программатор перейдет в автономный режим.
(В случае с PICkit3 данные сохраняются на встроенной памяти EEPROM).

[Martian]

Да, прочитал, есть SD-слот. Круто! Так-то и на моём клоне PICkit2 можно сохранять, и еепромки там в кроватях, но это дико неудобно, если вариантов несколько.
Чтож, пожалуй, надо купить четвёртого.

[AQ29]

Gudd-Head писал(а):

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

Неужели сейчас проблема всё запрограммировать за один клик?
Давно пользуюсь программатором, в котором можно поставить галочки необходимых действий (стирание, программирование FLASH, EEPROM, FUSE, проверка и т.д.), всё будет выполняться за один раз, не надо никаких виртуальных секретных адресов.

BOB51 писал(а):

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

Отладка в реальном времени очень удобна и является основной.

[Gudd-Head]

AQ29 писал(а):

Давно пользуюсь программатором, в котором можно поставить галочки необходимых действий (стирание, программирование FLASH, EEPROM, FUSE, проверка и т.д.), всё будет выполняться за один раз, не надо никаких виртуальных секретных адресов.

А теперь представьте, что вы делаете не разово для себя, а массово. Вы написали инструкцию по проверке (прозвонке) плат и инструкцию по программированию, чтобы любой дурак смог это сделать. Если следовать ей — то всё ОК. А если нет — то приносить вам платы на разбор.
И вот вам приносят кучу плат, потому что тупой исполнитель иногда "поставил галочку" тупо НЕ ТУДА.
Как вам?

[Jack_A]

В соревновании между программистами, создающими всё более умные программы, и природой, создающей всё более тупых юзеров, природа побеждает со значительным отрывом.

©
И не только касаемо программистов.
Законы Мерфи
-Если что-то может быть сделано неправильно - оно будет сделано неправильно.
-Даже если сделать неправильно невозможно - оно всё равно будет сделано неправильно.

[AQ29]

Gudd-Head писал(а):

AQ29 писал(а):

Давно пользуюсь программатором, в котором можно поставить галочки необходимых действий (стирание, программирование FLASH, EEPROM, FUSE, проверка и т.д.), всё будет выполняться за один раз, не надо никаких виртуальных секретных адресов.

А теперь представьте, что вы делаете не разово для себя, а массово. Вы написали инструкцию по проверке (прозвонке) плат и инструкцию по программированию, чтобы любой дурак смог это сделать. Если следовать ей — то всё ОК. А если нет — то приносить вам платы на разбор.
И вот вам приносят кучу плат, потому что тупой исполнитель иногда "поставил галочку" тупо НЕ ТУДА.
Как вам?

Это нереальная ситуация.
Исполнителю не надо галочки ставить.
В программаторе есть опция – сохранить все настройки программатора в файл. Файл лучше хранить в директории данного проекта. Настройщику понадобится только один клик на нужном файле, главное, не перепутать файл. Даже если перепутает, скорее всего, ничего страшного. Если в настройках другой тип МК, программатор заругается.
При постоянной работе с одним проектом ещё проще, можно включить опцию, при которой данный файл будет загружаться автоматически по умолчанию при запуске программы.
Вообще-то программатор предназначен для разработчика. Есть функции отладки в реальном времени (просмотр переменных, измерение времени процесса), может работать с двумя МК без каких-либо переключений.
Но программатор очень старый, давно пора более современные опции.

[Just_Fluffy]

AQ29, В случае нормальной IDE вообще не нужно держать отдельную программу для программатора.
И прямо из IDE жмется одна кнопка и в МК улетает все, и фьюзы, и еепром, и прошивка.
И не нужно отдельно настраивать и сохранять в файл.
Просто одно нажатие прямо из IDE.
И как раз для таких случаев и придумана трансляция адресов в разные типы памяти МК.