Как обещал о проблеме не работающих прерываний в сабже, под ассемблер, в 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 раз.
Я предпочитаю макросы самостоятельно писать. Тем более, что собственно макрос по сожранной памяти гораздо хуже подпрограмм - тут уже надо выбирать разумный компромисс между тем, что в макросе, и тем, что в указанной в нем подпрограмме. Отдельное замечание по работе с дебаггером - без специальных мер работа внутри макроса им не отслеживается - все, что там происходит проглатывается как одно действие. Так что вполне возможно пропустить определенные ошибки при отладке.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 54
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения