atmega328pb

[parovoZZ]

не увеличивает,

так а почему тогда ресет, подтянутый внешним резистором, вдруг как-то будет влиять на общее энергопотребление?

для "новых" МК и рекомендации другие могут быть

например, какие? С конденсатором я уже озвучил - он вреден в ряде случаев.

Но ктото покупает в китае и там на модульках надёжнее и проще спор открыть если что.

я в принципе не понимаю, зачем что-то покупать на помойке, а потом дворникам что-то доказывать.

[DrLithium]

Как обещал о проблеме не работающих прерываний в сабже, под ассемблер, в AtmelStudio 7.

Кжись докопался И так:

Далее подумал 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 ;

.equ BOOTSECTION1START = 0x3F00 ; Note: Word address
.equ BOOTSECTION1END = 0x3FFF ; Note: Word address
.equ BOOTSECTION1PAGESIZE = 0x0080 ;

.equ BOOTSECTION2START = 0x3E00 ; Note: Word address
.equ BOOTSECTION2END = 0x3FFF ; Note: Word address
.equ BOOTSECTION2PAGESIZE = 0x0080 ;

.equ BOOTSECTION3START = 0x3C00 ; Note: Word address
.equ BOOTSECTION3END = 0x3FFF ; Note: Word address
.equ BOOTSECTION3PAGESIZE = 0x0080 ;

.equ BOOTSECTION4START = 0x3800 ; Note: Word address
.equ BOOTSECTION4END = 0x3FFF ; Note: Word address
.equ BOOTSECTION4PAGESIZE = 0x0080 ;

.equ IOEND = 0x00FF

.equ SRAM_START = 0x0100
.equ SRAM_SIZE = 2048
.equ RAMEND = 0x08FF

.equ E2END = 0x03FF
.equ EEPROMEND = 0x03FF
.equ EEADRBITS = 10

.equ XRAMEND = 0x0000

#pragma AVRPART MEMORY PROG_FLASH 32768
#pragma AVRPART MEMORY INT_SRAM SIZE 2048
#pragma AVRPART MEMORY INT_SRAM START_ADDR 0x100

#pragma AVRPART MEMORY EEPROM 1024

; ***** BOOTLOADER DECLARATIONS ******************************************
.equ PAGESIZE = 0x0080 ;

.equ FIRSTBOOTSTART = 0x7E00 ; Note: Word address
.equ FIRSTBOOTPAGESIZE = 0x0080 ;
.equ FIRSTBOOTEND = 0x0000 ; Note: Word address

.equ SECONDBOOTSTART = 0x7C00 ; Note: Word address
.equ SECONDBOOTPAGESIZE = 0x0080 ;
.equ SECONDBOOTEND = 0x0000 ; Note: Word address

.equ THIRDBOOTSTART = 0x7800 ; Note: Word address
.equ THIRDBOOTPAGESIZE = 0x0080 ;
.equ THIRDBOOTEND = 0x0000 ; Note: Word address

.equ FOURTHBOOTSTART = 0x7000 ; Note: Word address
.equ FOURTHBOOTPAGESIZE = 0x0080 ;
.equ FOURTHBOOTEND = 0x0000 ; Note: Word address

.equ SMALLBOOTSTART = FIRSTBOOTSTART ;
.equ LARGEBOOTSTART = FOURTHBOOTSTART ;

20-й год:

Спойлер

; ***** DATA MEMORY DECLARATIONS *****************************************
.equ FLASHSTART = 0x0000 ; Note: Word address
.equ FLASHEND = 0x3FFF ; Note: Word address
.equ FLASHPAGESIZE = 0x0040 ; Note: Size in words

.equ BOOTSECTION1START = 0x3F00 ; Note: Word address
.equ BOOTSECTION1END = 0x3FFF ; Note: Word address
.equ BOOTSECTION1PAGESIZE = 0x0040 ; Note: Size in words

.equ BOOTSECTION2START = 0x3E00 ; Note: Word address
.equ BOOTSECTION2END = 0x3FFF ; Note: Word address
.equ BOOTSECTION2PAGESIZE = 0x0040 ; Note: Size in words

.equ BOOTSECTION3START = 0x3C00 ; Note: Word address
.equ BOOTSECTION3END = 0x3FFF ; Note: Word address
.equ BOOTSECTION3PAGESIZE = 0x0040 ; Note: Size in words

.equ BOOTSECTION4START = 0x3800 ; Note: Word address
.equ BOOTSECTION4END = 0x3FFF ; Note: Word address
.equ BOOTSECTION4PAGESIZE = 0x0040 ; Note: Size in words

.equ IOEND = 0x00FF

.equ SRAM_START = 0x0100
.equ SRAM_SIZE = 2048
.equ RAMEND = 0x08FF

.equ E2END = 0x03FF
.equ EEPROMEND = 0x03FF
.equ EEADRBITS = 10

.equ XRAMEND = 0x0000

#pragma AVRPART MEMORY PROG_FLASH 32768
#pragma AVRPART MEMORY INT_SRAM SIZE 2048
#pragma AVRPART MEMORY INT_SRAM START_ADDR 0x100

#pragma AVRPART MEMORY EEPROM 1024

; ***** BOOTLOADER DECLARATIONS ******************************************
.equ PAGESIZE = 0x0040 ; Note: Size in words

.equ FIRSTBOOTSTART = 0x3F00 ; Note: Word address
.equ FIRSTBOOTPAGESIZE = 0x0040 ; Note: Size in words
.equ FIRSTBOOTEND = 0x0000 ; Note: Word address

.equ SECONDBOOTSTART = 0x3E00 ; Note: Word address
.equ SECONDBOOTPAGESIZE = 0x0040 ; Note: Size in words
.equ SECONDBOOTEND = 0x0000 ; Note: Word address

.equ THIRDBOOTSTART = 0x3C00 ; Note: Word address
.equ THIRDBOOTPAGESIZE = 0x0040 ; Note: Size in words
.equ THIRDBOOTEND = 0x0000 ; Note: Word address

.equ FOURTHBOOTSTART = 0x3800 ; Note: Word address
.equ FOURTHBOOTPAGESIZE = 0x0040 ; Note: Size in words
.equ FOURTHBOOTEND = 0x0000 ; Note: Word address

.equ SMALLBOOTSTART = FIRSTBOOTSTART ;
.equ LARGEBOOTSTART = FOURTHBOOTSTART ;

З.Ы

parovoZZ писал(а):

Вы вообще платформу AVR как хорошо знаете?

- да так, слегка...

[slav0n]

знаем
10-21

[DrLithium]

Случился, тут КЗ в аппрата. Страшного нет ни чего, легко чинится. Но...
Родной стабилизатор +5-и выбивало, при подключении платы с 328PB, с сопротивление при замере ножек питания около 5кОм. Я не сразу понял где проблема. В очередной раз поставил 7805 на 1,5А с защитой. Аппарат заработал. Стал искать, что греется. Сам стабилизатор - естественно. Пошёл по обвязке, т.к. плата жила, мигали СД-ми и реагировала на кнопки, но что-то явно не работало. Нашёл не полностью открытые ключи на SMD-полевиках (таки было надо ставить). Замерил питание на них - мало. Оказалось питание просело аж до 3-х В! Тронул сам МК и четь не обжёгся! Какая-то часть внутри закорачивалась по портам, а ядро работало как ни в чём не бывало. Подобной живучести ещё не видел. Теперь знаю на чём буду собирать боеголовки устойчивые к космическому мусору!

[DrLithium]

Ни как не мог понять что не так в коде, пока глаз не попал в это:


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". Т.е. ранее получалось попадание во внутрь команды, но с точки зрения компилятора, ошибкой это не является!

З.З.Ы. Что-то ранее на подобные грабли не попадал...

[slav0n]

космический мусор вечен

[BOB51]

DrLithium
При попытках указывать адрес перехода "вручную" (а не по меткам) для начала хотя-бы со справочником команд не помешает ознакомиться (jmp - 4байта, rjmp - 2 байта).
Такое "ручное вычисление" разве что в древние времена для работ по написанию программ совсем без компьютера для I8080/Z80/MCS51 делалось - на бумаге карандашиком да с последующей "ручной компиляцией" по кодирующим таблицам.
И данный прием справедлив лишь для "чистого ассемблера" - там что пишу, то и откомпилируется.
Если имеется Си или активна "оптимизация" компилятор сам выбирает какой наиболее удачный вариант из имеющегося набора команд выставить.
Относительно заголовочных файлов - под ассемблер их нетрудно скорректировать и/или переписать самостоятельно согласно документации на кристалл.
Под "чистым ассемблером" программа с самодельным файлом описания ресурсов (*.inc) скомпилируется даже в авр студии 4.19, но естественно симулятор работать уже не всегда будет.

[DrLithium]

BOB51

При попытках указывать адрес перехода "вручную" (а не по меткам) для начала хотя-бы со справочником команд не помешает ознакомиться (jmp - 4байта, rjmp - 2 байта).

Я то давно знаком, а вы?

Потому и нашёл проблему. А в след. раз, что б писать с уважением к остальным участникам форума, сначала слезьте с колокольни, а то на хамство тянет ваше изречение.

Остальной ваш флуд, уже не интересен. И вот это снимите от позора подальше, т.к. вы только, что сели в лужу.

Когда долго пишешь под тини, вернуться без проблем на мегу не получается. Кроме того - не бывает идеальных книг для изучения, где-то что-то будет дано так, что в последствие и вызовет подобные проблемы. Не решил бы - был бы мне позор, а с какими как вы, после подобного "стиля", общаться не хочется. Не зная о том, что я знаю и сколько мне лет, позволяете себе на форуме то, что в жизни в лицо, ни когда не сказали бы. Это удел "диванных теоретиков", а остальные ошибаются и исправляются.

Посему вам, как заявителю "себя на торон", загадка: почему в прерывании INT1 "clr Temp" глючит, "ldi Temp,0" - нет? Это в AtmelStudio 6.2.1563 SP2 при этом симуляция работает без проблем. А вот в железе глючит!

Я не стал гадать и понимать, мне просто некогда. Да пусть хоть в камне проблема - всё равно, но именно

Такое "ручное вычисление" разве что ...

и помогло. А вы же умный, всё на перёд знаете?

Ответ вообще не жду. Вы просто скучны со своим нравоучениями на ровном месте. Зануды - утомляют! Мотайте на ус!

[BOB51]

DrLithium писал(а):

...
Посему вам, как заявителю "себя на торон", загадка: почему в прерывании INT1 "clr Temp" глючит, "ldi Temp,0" - нет? Это в AtmelStudio 6.2.1563 SP2 при этом симуляция работает без проблем. А вот в железе глючит!

...

Есть желание разобрать - выставляем полную схему устройства и полный исходник программы.
Если программа изначально писалась на "чистом ассемблере" вполне можно проанализировать.
Если имелись ввиду ассемблерные вставки в проекте написанном на Си - там я не советчик.

[ARV]

почему в прерывании INT1 "clr Temp" глючит, "ldi Temp,0" - нет? Это в AtmelStudio 6.2.1563 SP2 при этом симуляция работает без проблем. А вот в железе глючит!

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

а что касается CLR и LDI, так первая команда изменяет SREG, а вторая не изменяет. достаточно написать КРИВОЙ обработчик прерывания, и проблем можно огрести кучу. кстати, в симуляторе студии внешнее прерывание вы подаете ручками, а в железе оно подается само, и момент подачи вы предсказать не можете.

[parovoZZ]

Когда долго пишешь под тини, вернуться без проблем на мегу не получается.

Есть какие-то кардинальные отличия?
Я понимаю, после AVR сесть за MSP или PIC, или ARM или ещё что.

[dgrett]

DrLithium, ну что ж Вы такой обидчивый? Потолерантнее будьте, пожалуйста.

[DrLithium]

BOB51 писал(а):

Есть желание разобрать - выставляем полную схему устройства и полный исходник программы.
Если программа изначально писалась на "чистом ассемблере" вполне можно проанализировать.
Если имелись ввиду ассемблерные вставки в проекте написанном на Си - там я не советчик.

Си со вставками, очень редко, но получалось...

Не выставлю ни схему, ни лишний код. Всё что нужно даю:

Спойлер

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

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

Поведение не соответствует алгоритму. Если снять видео, то кроме факт глюка это новой информации не даст. Как раз в симуляторе всё работает исправно, глючит в железе. B понятно, что вызовов прерывания в симуляторе ручками в разы меньше, полностью не протестить. Лотерея...

а что касается CLR и LDI, так первая команда изменяет SREG, а вторая не изменяет. достаточно написать КРИВОЙ обработчик прерывания, и проблем можно огрести кучу.

В какой-то момент вместо PUSHF/POPF (регистры + SREG) заменил на просто PUSH/POP. А да, то что изменяется SREG вместе с CLR, просто тупо не помнил. Но проблема легко локализована и залечена.
==
AVR Спасибо за помощь. Проблема была действительно в CLR. Только, что проверил вернув PUSHF/POPF. Поддался давлению, пошёл байты сокращать, лучше б вообще не заикался о своей писанине и не правил то, что работает.

parovoZZ писал(а):

Когда долго пишешь под тини, вернуться без проблем на мегу не получается.

Есть какие-то кардинальные отличия?
Я понимаю, после AVR сесть за MSP или PIC, или ARM или ещё что.

Не в этом дело. PC+2 в тиньке ещё работает, а при переносе (копипасте) на мегу того же кода, получаем проблемы. Это просто надо каждую мелочь помнить. И ведь PC+2 это же из книг берётся. И когда пишешь с перерывами (иногда с большими), то знание типа - обязательное использование переходов на метки, для не наступления на грабли - улетучивается.

DrLithium, ну что ж Вы такой обидчивый? Потолерантнее будьте, пожалуйста.

Старюсь. Но нервы, увы, уже давно все потрачены. Обижать без причины ни кого не хочу, только в ответ могу. Просто подколки сыпятся как из рога изобилия, а я не робот.

[dgrett]

Да тут юнцов не так и много. К кому-то импотенция с мудростью приходит, к кому-то без.

[BOB51]

"...
Не выставлю ни схему, ни лишний код. Всё что нужно даю:
..."
В сложном проекте помимо того, что концентрирует на себе внимание автора существует и множество "перекрестных нюансов".
Если речь даже о "чистом ассемблере" - имеем еще приоритетность задействованных в программе прерываний.
И, как указывал выше 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(среднемладшие) по заранее проработанным кристаллам под "чистым ассемблером" - единственно необходимо под такую методику заранее заготовки соответствующие сделать.

[DrLithium]

следим за содержимым SREG (и иных критичных регистров) чего в Вашем, DrLithium описании обработчика прерывания явно НЕ СОДЕРЖИТСЯ.

А это что?

PUSHF/POPF (регистры + SREG) заменил на просто PUSH/POP

При наличии соответствующе подготовленной базы это не представляет особого затруднения.
Тем более в рамках по факту всего одного семейства МК.

Ни кто ни о каких трудностях и не заявлял. Было сказано, что поработав с одни семейством, глаз замыливается и работает инерция мышления. Нужно быть во истину бездельником с абсолютно пустой головой, что б помнить только о подобных тонкостях межсемейных переходов. К счастью, у меня проектов очень как много ждут своего завершения, т.е. есть чем заняться и голова просто забита. Наверное надо вспомнить факт, часть знаний, в виду их долгого неупотребления, просто атрофируются. Вы из школьного курса всё помните? Хотя бы формулу дискриминанта? Тота! Ч.т. не надо сваливать проблему в другое русло. Напоминаю: форум не что б хамить и мериться длиной стека. Форум, что б помогать и по возможности без дешёвых понтов.

И как всегда делаем файл листинга для детального анализа.

Из железа? Каким образом? По USART-У его вываливать? М.б. вам стоит ещё раз внимательнее прочитать:

...при этом симуляция работает без проблем. А вот в железе глючит!

При этом писал выше: в симуляторе надо в лотереею выиграть, что получить ровно тот же глюк. Локализация ошибки уже свершившийся факт! Есть смысл что-то выкладывать?

[BOB51]

PUSHF/POPF -это по меньшей мере вариант макроса, описания коего в предоставленном фрагменте нету.
SREG за пределами "простого доступа" - там или IN/OUT или LD/ST со смещением -какой вариант в Вашем случае неизвестно.
Листинг генерируется компилятором в отдельный файл - зачем его "из железа" доставать - то?
Не путайте с технологиями отладки, имеющимися в современных кристаллах.
И насчет "в симуляторе работает нормально" - Симулятор в лучшем случае корректно отрабатывает ядро и частично периферию (смотрим ограничения в документации на IDE).
Касательно "накладок" сработки прерываний - это отдельная категория анализа "на наихудший возможный вариант "стечения обстоятельств"" - УВЫ для такого надо самому тесты придумывать по каждому вероятному "стечению обстоятельств".
Если Вас разбор не интересует - ессно выкладывать проект нет смысла (как и задавать по нему вопросы к окружающим).

[DrLithium]

(регистры + SREG)

Этого минимального пояснения более чем достаточно для понимания того, что кладётся в стэк и после возвращается. Кроме того PUSHF/POPF - это вообще всем известный макрос с сайта easyelectronics.ru, содержимое которого каждый школьник знает.

Спойлер

.MACRO PUSHF
PUSH R16
IN R16,SREG
PUSH R16
.ENDM


.MACRO POPF
POP R16
OUT SREG,R16
POP R16
.ENDM

Листинг генерируется компилятором в отдельный файл - зачем его "из железа" доставать - то?

Это очевидно был сарказм. Ваша не внимательность к деталям его родила. Выше пояснил, что в этом нет нужды.

И насчет "в симуляторе работает нормально"

Не утруждайте себя. Я отдаю себе отчёт в том, что и как там работает и иллюзий не питаю. Если пишу "работает нормально" - соответственно и надо понимать с поправкой на разумное кол-во прогонов цикла, доступных простому смертному. Я не в состоянии нанять 100 Индийцев для пальце-кликерного прогона в симуляторе. Вывод: надо понимать, что ошибка в симуляторе не выявлена из-за малого шанса и кол-ва прогонов.

касательно "накладок" сработки прерываний - это отдельная категория анализа "на наихудший возможный вариант "стечения обстоятельств"" - УВЫ для такого надо самому тесты придумывать по каждому вероятному "стечению обстоятельств".

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

Если Вас разбор не интересует - ессно выкладывать проект нет смысла (как и задавать по нему вопросы к окружающим).

Бинго! Ни в каком варианте. Вот только, если крепко не засяду где-нить, тогда буду бить в колокола и слушаться как школьник, предоставив необходимый минимум данных!

[BOB51]

Я предпочитаю макросы самостоятельно писать.
Тем более, что собственно макрос по сожранной памяти гораздо хуже подпрограмм - тут уже надо выбирать разумный компромисс между тем, что в макросе, и тем, что в указанной в нем подпрограмме.
Отдельное замечание по работе с дебаггером - без специальных мер работа внутри макроса им не отслеживается - все, что там происходит проглатывается как одно действие. Так что вполне возможно пропустить определенные ошибки при отладке.

[dgrett]

{dgrett писал(а):
И как всегда делаем файл листинга для детального анализа.}
Это когда ж я такое написал?