Как обещал о проблеме не работающих прерываний в сабже, под ассемблер, в AtmelStudio 7.
Кжись докопался И так:
DrLithium писал(а):
Далее подумал PCINT не пашет, попробовал INT0 - аналогично. Подумал что таблица прерываний окривела - нет. В таблице меток в конце которой общий reti на случай срабатывания "левого" прерывания, обычно комментируются нужные прерывания, а метки с обработкой кидают после инициализации. Дак светодиод в списке по своим прерыванием (PCINT2:, если его не закомментить) загорается от PD7, а в копии (PCINT2:, если первую метку закомментить) под инициализацией - нет! Т.е. вектор перехода попадает на место!
Далее: Начитавшись форумов понял, что дело связано с бутлоадерами (сам с ними дело имел только косвенное, для ардуйни), т.к. смещение таблицы векторов прерываний напрямую зависит от размера БЛ.
Картина следующая: В таблицу векторов прерываний фокус попадает и даже переходит на обработчик, а вот вернуться на место по "reti" уже не в состоянии.
AVRStudio 6.2 у меня была поставлена, но вот 7-у пришлось ставить из-за того, что даже при наличии 1,4GB пака с нужностями, запустить 328PB в 6.2 так и не удалось. Решил добить таки это дело и посмотреть, как оно там живёт...
Как я понял нужно установить: partpack_ATmega328PB-trunk-6.2.9.zip... Но, "as-avr8-toolchain-msi-snapshot-trunk-6.2.1091-win32.any.x86.msi" из архива ставится, а "partpack_ATmega328PB-trunk-6.2.9.vsix" ни в какую! Последний можно равернуть WinRAR-ом и рассовать файлы в ручную по папкам 6-й студии...
При этом не забыв, что в "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR Assembler\Native\2.1.1175\avrassembler\supported-devices.xml" нужно объявить новый девайс: <device family="mega" header="m328PBdef.inc" line="AVR" name="ATmega328PB", по аналогии с "328P".
В проекте нужно подцепить: .include "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR Assembler\Native\2.1.1175\avrassembler\include\m328PBdef.inc" Вместо: .include "C:\Program Files (x86)\Atmel\Studio 7.0\7.0\packs\atmel\ATmega_DFP\1.6.364\avrasm\inc\m328PBdef.inc"
Теперь ясно откуда ноги растут! Не иначе как из волосатого... бутлоадера! Основная масса определений в файлах 15-го года и 20-го года почти совпадает! Разница лишь в секциях: DATA MEMORY DECLARATIONS и BOOTLOADER DECLARATIONS.
15-й год: Спойлер; ***** DATA MEMORY DECLARATIONS ***************************************** .equ FLASHSTART = 0x0000 ; Note: Word address .equ FLASHEND = 0x3FFF ; Note: Word address .equ FLASHPAGESIZE = 0x0080 ;
Случился, тут КЗ в аппрата. Страшного нет ни чего, легко чинится. Но... Родной стабилизатор +5-и выбивало, при подключении платы с 328PB, с сопротивление при замере ножек питания около 5кОм. Я не сразу понял где проблема. В очередной раз поставил 7805 на 1,5А с защитой. Аппарат заработал. Стал искать, что греется. Сам стабилизатор - естественно. Пошёл по обвязке, т.к. плата жила, мигали СД-ми и реагировала на кнопки, но что-то явно не работало. Нашёл не полностью открытые ключи на SMD-полевиках (таки было надо ставить). Замерил питание на них - мало. Оказалось питание просело аж до 3-х В! Тронул сам МК и четь не обжёгся! Какая-то часть внутри закорачивалась по портам, а ядро работало как ни в чём не бывало. Подобной живучести ещё не видел. Теперь знаю на чём буду собирать боеголовки устойчивые к космическому мусору!
_________________ Если в голове каша, значит ваш котелок варит!
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Ни как не мог понять что не так в коде, пока глаз не попал в это:
AtmelStudio 6.2, 328PB, просто следующая версия с чуть изменёнными include-ами. В обоих случаях происходил переход по "brne PC+2".
З.Ы. Ушёл пробовать в Microchip Studio 7... В 7-й так же.
Если вместо "PC+2" указать метку, размещённую ниже, то косяка не происходит! Т.е. значение переменной "State"(R14) не меняется.
Кжысь понял. Т.к. "jmp" может прыгать дальше чем "rjmp", то и тактов он занимает больше. И вероятно это меняется в зависимости от ситуации. Изменив "PC+2" на "PC+3" и добавив "nop" после "jmp"-а, фокус ушёл именно на "nop". Т.е. ранее получалось попадание во внутрь команды, но с точки зрения компилятора, ошибкой это не является!
З.З.Ы. Что-то ранее на подобные грабли не попадал...
_________________ Если в голове каша, значит ваш котелок варит!
Последний раз редактировалось DrLithium Сб июн 05, 2021 11:42:58, всего редактировалось 1 раз.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
DrLithium При попытках указывать адрес перехода "вручную" (а не по меткам) для начала хотя-бы со справочником команд не помешает ознакомиться (jmp - 4байта, rjmp - 2 байта). Такое "ручное вычисление" разве что в древние времена для работ по написанию программ совсем без компьютера для I8080/Z80/MCS51 делалось - на бумаге карандашиком да с последующей "ручной компиляцией" по кодирующим таблицам. И данный прием справедлив лишь для "чистого ассемблера" - там что пишу, то и откомпилируется. Если имеется Си или активна "оптимизация" компилятор сам выбирает какой наиболее удачный вариант из имеющегося набора команд выставить. Относительно заголовочных файлов - под ассемблер их нетрудно скорректировать и/или переписать самостоятельно согласно документации на кристалл. Под "чистым ассемблером" программа с самодельным файлом описания ресурсов (*.inc) скомпилируется даже в авр студии 4.19, но естественно симулятор работать уже не всегда будет.
При попытках указывать адрес перехода "вручную" (а не по меткам) для начала хотя-бы со справочником команд не помешает ознакомиться (jmp - 4байта, rjmp - 2 байта).
Я то давно знаком, а вы? Потому и нашёл проблему. А в след. раз, что б писать с уважением к остальным участникам форума, сначала слезьте с колокольни, а то на хамство тянет ваше изречение.
Остальной ваш флуд, уже не интересен. И вот это снимите от позора подальше, т.к. вы только, что сели в лужу.
Когда долго пишешь под тини, вернуться без проблем на мегу не получается. Кроме того - не бывает идеальных книг для изучения, где-то что-то будет дано так, что в последствие и вызовет подобные проблемы. Не решил бы - был бы мне позор, а с какими как вы, после подобного "стиля", общаться не хочется. Не зная о том, что я знаю и сколько мне лет, позволяете себе на форуме то, что в жизни в лицо, ни когда не сказали бы. Это удел "диванных теоретиков", а остальные ошибаются и исправляются.
Посему вам, как заявителю "себя на торон", загадка: почему в прерывании INT1 "clr Temp" глючит, "ldi Temp,0" - нет? Это в AtmelStudio 6.2.1563 SP2 при этом симуляция работает без проблем. А вот в железе глючит!
Я не стал гадать и понимать, мне просто некогда. Да пусть хоть в камне проблема - всё равно, но именно
Цитата:
Такое "ручное вычисление" разве что ...
и помогло. А вы же умный, всё на перёд знаете?
Ответ вообще не жду. Вы просто скучны со своим нравоучениями на ровном месте. Зануды - утомляют! Мотайте на ус!
_________________ Если в голове каша, значит ваш котелок варит!
... Посему вам, как заявителю "себя на торон", загадка: почему в прерывании INT1 "clr Temp" глючит, "ldi Temp,0" - нет? Это в AtmelStudio 6.2.1563 SP2 при этом симуляция работает без проблем. А вот в железе глючит!
...
Есть желание разобрать - выставляем полную схему устройства и полный исходник программы. Если программа изначально писалась на "чистом ассемблере" вполне можно проанализировать. Если имелись ввиду ассемблерные вставки в проекте написанном на Си - там я не советчик.
почему в прерывании INT1 "clr Temp" глючит, "ldi Temp,0" - нет? Это в AtmelStudio 6.2.1563 SP2 при этом симуляция работает без проблем. А вот в железе глючит!
что такое "глючит"? какое-то странное заявление. по поводу симулятора - я бы вообще сильно на него не полагался, там тоже полно всяких загадок.
а что касается CLR и LDI, так первая команда изменяет SREG, а вторая не изменяет. достаточно написать КРИВОЙ обработчик прерывания, и проблем можно огрести кучу. кстати, в симуляторе студии внешнее прерывание вы подаете ручками, а в железе оно подается само, и момент подачи вы предсказать не можете.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Есть желание разобрать - выставляем полную схему устройства и полный исходник программы. Если программа изначально писалась на "чистом ассемблере" вполне можно проанализировать. Если имелись ввиду ассемблерные вставки в проекте написанном на Си - там я не советчик.
Си со вставками, очень редко, но получалось...
Не выставлю ни схему, ни лишний код. Всё что нужно даю: СпойлерEXT_INT1: ; Датчик движения автостопа PUSH Temp ;PUSHF sbrs ST_NASK,5 ; если автостоп отключен rjmp EXT_INT1_exit ; сразу на выход ; иначе сбрасываем набежавшее у таймера 1A // clr Temp ; - глючит!! ldi Temp,0 ; - работает!! sts TCNT1H,Temp sts TCNT1L,Temp EXT_INT1_exit: ;POPF POP Temp reti
ARV писал(а):
что такое "глючит"? какое-то странное заявление. по поводу симулятора - я бы вообще сильно на него не полагался, там тоже полно всяких загадок.
Поведение не соответствует алгоритму. Если снять видео, то кроме факт глюка это новой информации не даст. Как раз в симуляторе всё работает исправно, глючит в железе. B понятно, что вызовов прерывания в симуляторе ручками в разы меньше, полностью не протестить. Лотерея...
ARV писал(а):
а что касается CLR и LDI, так первая команда изменяет SREG, а вторая не изменяет. достаточно написать КРИВОЙ обработчик прерывания, и проблем можно огрести кучу.
В какой-то момент вместо PUSHF/POPF (регистры + SREG) заменил на просто PUSH/POP. А да, то что изменяется SREG вместе с CLR, просто тупо не помнил. Но проблема легко локализована и залечена. == AVR Спасибо за помощь. Проблема была действительно в CLR. Только, что проверил вернув PUSHF/POPF. Поддался давлению, пошёл байты сокращать, лучше б вообще не заикался о своей писанине и не правил то, что работает.
Когда долго пишешь под тини, вернуться без проблем на мегу не получается.
Есть какие-то кардинальные отличия? Я понимаю, после AVR сесть за MSP или PIC, или ARM или ещё что.
Не в этом дело. PC+2 в тиньке ещё работает, а при переносе (копипасте) на мегу того же кода, получаем проблемы. Это просто надо каждую мелочь помнить. И ведь PC+2 это же из книг берётся. И когда пишешь с перерывами (иногда с большими), то знание типа - обязательное использование переходов на метки, для не наступления на грабли - улетучивается.
dgrett писал(а):
DrLithium, ну что ж Вы такой обидчивый? Потолерантнее будьте, пожалуйста.
Старюсь. Но нервы, увы, уже давно все потрачены. Обижать без причины ни кого не хочу, только в ответ могу. Просто подколки сыпятся как из рога изобилия, а я не робот.
_________________ Если в голове каша, значит ваш котелок варит!
"... Не выставлю ни схему, ни лишний код. Всё что нужно даю: ..." В сложном проекте помимо того, что концентрирует на себе внимание автора существует и множество "перекрестных нюансов". Если речь даже о "чистом ассемблере" - имеем еще приоритетность задействованных в программе прерываний. И, как указывал выше ARV, следим за содержимым SREG (и иных критичных регистров) чего в Вашем, DrLithium описании обработчика прерывания явно НЕ СОДЕРЖИТСЯ. В то же время относительно обработчика прерывания в виде ассемблерной вставки на Си дело обстоит несколько иначе... Касательно "длинных/коротких" команд перехода... Компилятор даже для ассемблера в рамках АВРстудио имеет достаточно опций, которые необходимо внимательно устанавливать. За 6ю версию не в курсе, но даже для 4.19 надо внимательно присмотреться: https://img.radiokot.ru/files/20529/2jsk2kbpli.png есть хитрое окошко Wrap relative Jmps - его предпочтительно оставить пустым окно "unsupported Instructions" установить маркер в графе ERROR - иначе ошибочная по мнению компилятора инструкция будет отмечена только предупреждением. И вероятнее всего пропущена автором при анализе. Компилятор весьма умный - для каждого МК имеется список разрешеных команд, соответствующий таковому в даташите на МК. Соответственно не разрешенные для малолапых команды переходов могут быть автоматически преобразованы в разрешенные "короткие". Ассемблер рекомендую использовать version 2(как на скриншоте). И как всегда делаем файл листинга для детального анализа.
Относительно "перепрыгов" с одного кристалла на другой... При наличии соответствующе подготовленной базы это не представляет особого затруднения. Тем более в рамках по факту всего одного семейства МК. Мне не так уж сложно "прыгать" между MCS51-AVR-PIC(среднемладшие) по заранее проработанным кристаллам под "чистым ассемблером" - единственно необходимо под такую методику заранее заготовки соответствующие сделать.
следим за содержимым SREG (и иных критичных регистров) чего в Вашем, DrLithium описании обработчика прерывания явно НЕ СОДЕРЖИТСЯ.
А это что?
DrLithium писал(а):
PUSHF/POPF (регистры + SREG) заменил на просто PUSH/POP
BOB51 писал(а):
При наличии соответствующе подготовленной базы это не представляет особого затруднения. Тем более в рамках по факту всего одного семейства МК.
Ни кто ни о каких трудностях и не заявлял. Было сказано, что поработав с одни семейством, глаз замыливается и работает инерция мышления. Нужно быть во истину бездельником с абсолютно пустой головой, что б помнить только о подобных тонкостях межсемейных переходов. К счастью, у меня проектов очень как много ждут своего завершения, т.е. есть чем заняться и голова просто забита. Наверное надо вспомнить факт, часть знаний, в виду их долгого неупотребления, просто атрофируются. Вы из школьного курса всё помните? Хотя бы формулу дискриминанта? Тота! Ч.т. не надо сваливать проблему в другое русло. Напоминаю: форум не что б хамить и мериться длиной стека. Форум, что б помогать и по возможности без дешёвых понтов.
BOB51 писал(а):
И как всегда делаем файл листинга для детального анализа.
Из железа? Каким образом? По USART-У его вываливать? М.б. вам стоит ещё раз внимательнее прочитать:
DrLithium писал(а):
...при этом симуляция работает без проблем. А вот в железе глючит!
При этом писал выше: в симуляторе надо в лотереею выиграть, что получить ровно тот же глюк. Локализация ошибки уже свершившийся факт! Есть смысл что-то выкладывать?
_________________ Если в голове каша, значит ваш котелок варит!
Последний раз редактировалось DrLithium Чт июн 24, 2021 01:00:04, всего редактировалось 1 раз.
PUSHF/POPF -это по меньшей мере вариант макроса, описания коего в предоставленном фрагменте нету. SREG за пределами "простого доступа" - там или IN/OUT или LD/ST со смещением -какой вариант в Вашем случае неизвестно. Листинг генерируется компилятором в отдельный файл - зачем его "из железа" доставать - то? Не путайте с технологиями отладки, имеющимися в современных кристаллах. И насчет "в симуляторе работает нормально" - Симулятор в лучшем случае корректно отрабатывает ядро и частично периферию (смотрим ограничения в документации на IDE). Касательно "накладок" сработки прерываний - это отдельная категория анализа "на наихудший возможный вариант "стечения обстоятельств"" - УВЫ для такого надо самому тесты придумывать по каждому вероятному "стечению обстоятельств". Если Вас разбор не интересует - ессно выкладывать проект нет смысла (как и задавать по нему вопросы к окружающим).
Этого минимального пояснения более чем достаточно для понимания того, что кладётся в стэк и после возвращается. Кроме того PUSHF/POPF - это вообще всем известный макрос с сайта easyelectronics.ru, содержимое которого каждый школьник знает. Спойлер.MACRO PUSHF PUSH R16 IN R16,SREG PUSH R16 .ENDM
.MACRO POPF POP R16 OUT SREG,R16 POP R16 .ENDM
BOB51 писал(а):
Листинг генерируется компилятором в отдельный файл - зачем его "из железа" доставать - то?
Это очевидно был сарказм. Ваша не внимательность к деталям его родила. Выше пояснил, что в этом нет нужды.
BOB51 писал(а):
И насчет "в симуляторе работает нормально"
Не утруждайте себя. Я отдаю себе отчёт в том, что и как там работает и иллюзий не питаю. Если пишу "работает нормально" - соответственно и надо понимать с поправкой на разумное кол-во прогонов цикла, доступных простому смертному. Я не в состоянии нанять 100 Индийцев для пальце-кликерного прогона в симуляторе. Вывод: надо понимать, что ошибка в симуляторе не выявлена из-за малого шанса и кол-ва прогонов.
DrLithium писал(а):
касательно "накладок" сработки прерываний - это отдельная категория анализа "на наихудший возможный вариант "стечения обстоятельств"" - УВЫ для такого надо самому тесты придумывать по каждому вероятному "стечению обстоятельств".
Именно симулятор и позволяет, в подобных случаях, менять значения переменных, что я с успехом и делаю, что б в реальные сроки выявить проблему.
BOB51 писал(а):
Если Вас разбор не интересует - ессно выкладывать проект нет смысла (как и задавать по нему вопросы к окружающим).
Бинго! Ни в каком варианте. Вот только, если крепко не засяду где-нить, тогда буду бить в колокола и слушаться как школьник, предоставив необходимый минимум данных!
_________________ Если в голове каша, значит ваш котелок варит!
Последний раз редактировалось DrLithium Ср июн 23, 2021 23:26:20, всего редактировалось 1 раз.
Я предпочитаю макросы самостоятельно писать. Тем более, что собственно макрос по сожранной памяти гораздо хуже подпрограмм - тут уже надо выбирать разумный компромисс между тем, что в макросе, и тем, что в указанной в нем подпрограмме. Отдельное замечание по работе с дебаггером - без специальных мер работа внутри макроса им не отслеживается - все, что там происходит проглатывается как одно действие. Так что вполне возможно пропустить определенные ошибки при отладке.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения