Пробема с прерываниями

dr.doc

По дизассемблеру выполняются следующие действия на векторах:
ISR(PCINT0_vect) { - выполняет PORTB = (1<<PB0|1<<PB6) (если правильно записал на Си - PB0 и PB6 в 1)
ISR(PCINT1_vect) { - выполняет PORTB ^= (1<<PB6) (инверсия вывода PORTB,6. Причем читается почему-то PORTB а не PINB)
ISR(INT0_vect) { - выполняет PORTB ^= (1<<PB6) (инверсия вывода PORTB,6. Причем читается почему-то PORTB а не PINB)

Реклама

vk_31

dr.doc писал(а):По дизассемблеру выполняются следующие действия на векторах:
ISR(PCINT0_vect) { - выполняет PORTB = (1<<PB0|1<<PB6) (если правильно записал на Си - PB0 и PB6 в 1)
ISR(PCINT1_vect) { - выполняет PORTB ^= (1<<PB6) (инверсия вывода PORTB,6. Причем читается почему-то PORTB а не PINB)
ISR(INT0_vect) { - выполняет PORTB ^= (1<<PB6) (инверсия вывода PORTB,6. Причем читается почему-то PORTB а не PINB)

Т.е. по коду все ок? Получается проблема в железе?

Реклама

dr.doc

А как мое описание, согласуется с кодом?

ISR(PCINT0_vect) { - выполняет PORTB = (1<<PB0|1<<PB6) (если правильно записал на Си - PB0 и PB6 в 1)

ISR(PCINT0_vect) {
PORTB ^= (1<<PB6); // Инвертировать PB6
PORTB ^= (1<<PB0); // ИнвертироватьPB0
}

vk_31

Согласуется. В коде (в последней его версии, с которой выполнен дизассемблер) по вектору прерывания PCINT0 выполняется установка единицы на порты PB0 и PB6, а по PCINT1 и INT0 выполняется инверсия порта PB6

Реклама

dr.doc

По дизассемблеру Atmel Studio также не записывает биты PCIF1,0 в регистре EIMSK командой out. Работают только битовые операции типа
sbi EIMSK,PCIE0 ; Установить бит PCIE0 в регистре EIMSK в 1.
sbi EIMSK,PCIE1 ; -//-

На сколько я знаю, на Си это выглядит примерно так: EIMSK |= (1<<PCIE1|1<<PCIE0);
https://youtu.be/w1HNpunVA_o
https://youtu.be/Gm7REntkcYg

Реклама

vk_31

dr.doc писал(а):По дизассемблеру Atmel Studio также не записывает биты PCIF1,0 в регистре EIMSK командой out. Работают только битовые операции типа
sbi EIMSK,PCIE0 ; Установить бит PCIE0 в регистре EIMSK в 1.
sbi EIMSK,PCIE1 ; -//-

А как должно быть в идеале и в чем разница между sbi и out кроме увеличения строк кода?

Реклама

dr.doc

sbi - команда прямого доступа к портам. Она не изменяет флаги регистра SREG и устанавливает бит порта в 1.
out - отправляет содержимое регистра РОН (например r16, r31...) в порт ввода/вывода. Аналогична команде sts, только работает с меньшей разрядностью адресов. В старших моделях контроллеров с богатой периферией чаще встречается sts а в младшей - ATtiny ее можешь и не встретить вовсе.
Из практики, хотя и написано, что sbi действует в тех же пределах, что и out не всегда пишется в регистр настройки периферии нужное значение. Приходится изгаляться. Попробуйте предложенный ранее вариант, мне стало очень интересно.

akl · Сообщение **akl** » Пн ноя 28, 2016 06:29:50

dr.doc писал(а):Из практики, хотя и написано, что sbi действует в тех же пределах, что и out не всегда пишется в регистр настройки периферии нужное значение.

Замечу, команды SBI и CBI работают в пределах 0...1F, а команды IN и OUT - 0...3F. По приведенному коду, не понятен переход на хидер, да ещё по CALL. Загрузил в студию 4.19 такой код. Прерывания PCINT выполняются. В архиве есть и .hex, естественно, для железа он мало подходит, но реакцию на нажатие/отпускание кнопок показать может. FUSE-бит BOOTRST должен быть в 1, т.е. не запрограммирован.

Спойлер

Код: Выделить всё

	.INCLUDE "m169def.inc"

	.CSEG

	.ORG	0x0000
RESET:
	RJMP START ; Reset Handler
	.ORG	$04
ISR_PCINT0:
	IN	R21,PINE
	ANDI	R21,0b01001000
	EOR	R21,R22

	SBRC	R21,6
	SBI	PINB,6
	SBRC	R21,3
	SBI	PINB,0

	IN	R22,PINE
	ANDI	R22,0b01001000

	RETI
;*************************************************
;*************************************************
;*************************************************
START:
	LDI	ZH,HIGH(RAMEND)
	LDI	ZL,LOW(RAMEND)
	OUT	SPH,ZH
	OUT	SPL,ZL
	
	LDI	R16,1<<6|1<<0
	OUT	DDRB,R16

	LDI	R16,1<<6|1<<3
	OUT	PORTE,R16

	IN	R22,PINE
	ANDI	R22,0b01001000

	LDI	R16,1<<PCINT6|1<<PCINT3
	STS	PCMSK0,R16

;	LDI	R16,1<<PCIE0
;	OUT	EIMSK,R16
;	OUT	EIFR,R16		; выполняется аналогично 2-м нижеследующим командам
	SBI	EIMSK,PCIE0
	SBI	EIFR,PCIF0

	SEI

	RJMP	PC

.EXIT

TEST_M169.rar: (1.92 КБ) 148 скачиваний

Vov123

vk_31 писал(а): склоняюсь с тому, что есть ошибки в разводке платы (хоть и не понимаю как это может быть связано), т.к. прерывания на макетке с тем же камнем и фьюзами работают...

vk_31

akl, залил Вашу прошивку - по нажатию на PE6 загорается или гаснет светодиод на PB6, а на PB0 реакции нет. При нажатии на PE3 ничего не происходит. Если я правильно понял Ваш код, то обрабатывается только опрос кнопок в цикле?
Vov123, Вы тоже думаете дело в этом? Я выкладывал плату, взглягите если не сложно. А камень из другой партии из Китая. Был у меня регулятор теплого пола с неисправным МК atmega169pa-au, я его заменил и использовал как макетку из-за наличия LCD. Позже написал прошивку и развел свою плату. На макетке и на моем устройстве порты E задействованы как входы, а порты B как выходы. МК был заказан позже, но такой же как на макетке atmega169pa-au, а в итоге прерывания PCINT не срабатывают. Вот и не знаю куда копать, причем прерывания INT0 и прерывания по таймеру работают.

akl · Сообщение **akl** » Пн ноя 28, 2016 08:39:40

vk_31 писал(а):по нажатию на PE6 загорается или гаснет светодиод на PB6, а на PB0 реакции нет. При нажатии на PE3 ничего не происходит. Если я правильно понял Ваш код, то обрабатывается только опрос кнопок в цикле?

Да, задействована реакция на кнопки по PCINT6 и PCINT3. Прогресс, хоть какой-то!

12:05
Посмотрел плату. Можно попробовать позамыкать перемычкой вместо кнопки и контакта энкодера. Из опыта, не следует полностью доверять встроенной подтяжке. Контакт, подтянутый резистором 1к работает гораздо лучше.

vk_31

akl писал(а):Можно попробовать позамыкать перемычкой вместо кнопки и контакта энкодера. Из опыта, не следует полностью доверять встроенной подтяжке. Контакт, подтянутый резистором 1к работает гораздо лучше.

Пробовал устанавливать маску прерываний на все пины порта E и замыкать их перемычкой - прерывания не срабатывали, а по опросу в цикле пина PE6 реакция есть. Попробую сегодня подпаять резистор и повторить эксперимент.
Не силен в архитектуре МК, может питание неправильно развел и при обработке PCINT не срабатывает "исключающее ИЛИ" или еще что-то мешает логике работать?

Vov123

Может попробовать сделать по этим правилам http://chipenable.ru/index.php/item/13 ?

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

vk_31

Vov123 писал(а):Может он у Вас из-за большой нагруженности на плате проседает по питанию и в момент нажатия кнопки происходит рестарт.

Было бы заметно, светодиод бы гас (он зажигается при опросе кнопки в цикле), но не происходит этого. Вообще никакой реакции по прерыванию(

Vov123 писал(а):Может попробовать сделать по этим правилам http://chipenable.ru/index.php/item/13?

Попробую вечером подтянуть резистором и отключить подтяжки.

Добавлено after 6 hours 7 minutes 7 seconds:
Подтянул резисторами порты - ситуация не изменилась. Замыкание портов на землю и на питание тоже не дали результатов

vk_31

Спасибо всем за помощь! Все оказалось как обычно просто: существует какая-то разница между контроллерами atmega169pa-au толи в версиях, то ли просто у меня маркировка неправильная стояла. В общем даташит МК atmega169p(v) отличается от atmega169pa. Пока что я нашел различия в бите, EIMSK, а именно: в разных версиях биты включения прерываний (PCIE0, PCIE1) имеют разное значения. Так в обычной версии это 6, 7 биты регистра, а в версии для atmega169pa - 4, 5. Видимо в первый раз мне повезло (или скорее нет), т.к. все заработало на макетке с установленным atmega169pa-au и я оставил в Makefile MCU=atmega169. Вот поэтому и подключались другие заголовочные файлы, а с другим МК с такой же маркировкой не прокатило(
Если кто знает какая разница между МК, напишите пожалуйста. На маркировке МК есть 4 цифры: на первом МК (который работал с заголовками от atmega169) 1413, на втором (который заработал с заголовками от atmega169pa) 1545. Я так понимаю это год и неделя выпуска
Еще раз всем спасибо!

Vov123

Вероятно неплохо в будущем проверять на другом компиляторе, к примеру, на CVAVR?

akl · Сообщение **akl** » Ср ноя 30, 2016 09:56:27

vk_31 писал(а):Если кто знает какая разница между МК, напишите пожалуйста.

Мда. Я не захотел качать DS на 169а (уж больно много весит), вот и пролетел. А разница есть

COMP_169P_169A.PNG: (35.88 КБ) 338 скачиваний

vk_31

Vov123 писал(а):Вероятно неплохо в будущем проверять на другом компиляторе, к примеру, на CVAVR?

Скорее всего не поможет. Разница же была в #define PCIE, а значит компилироваться будет в любом случае.

Vov123

Ну вот у меня есть версия 3.12, там для проца atmega169p EIMSK->PCIE0 = 6, а для проца atmega169pa отсылает к библе "mega329p_bits.h", там EIMSK->PCIE0 = 4.
Так что вероятно, если правильно выбран проц, то работало бы правильно.

Или неправильно Вас понял?

vk_31

Vov123 писал(а):Ну вот у меня есть версия 3.12, там для проца atmega169p EIMSK->PCIE0 = 6, а для проца atmega169pa отсылает к библе "mega329p_bits.h", там EIMSK->PCIE0 = 4.
Так что вероятно, если правильно выбран проц, то работало бы правильно.

Или неправильно Вас понял?

Да, вы все верно говорите. Ошибка была полностью моя. Я с библиотекой для atmega169 (не atmega169pa) скомпилировал прошивку и прошил МК atmega169pa-au на моей макетной плате и все работало. И сейчас на макетке работает с этой библиотекой. А уже на готовом устройстве с таким же МК atmega169pa-au прерывания уже не работали, хотя все остальное завелась. Вот и начал выяснять в чем проблема. Если бы с самого начала на макетке не было бы прерываний, или чего еще не работало то я бы поступил по другому. Итог: два одинаковых МК из Китая с разными установками битов в регистре EIMSK, вот и заказывай потом в Китае...

Добавлено after 6 minutes 52 seconds:

Vov123 писал(а): Так что вероятно, если правильно выбран проц, то работало бы правильно.

В моем случае к сожалению это не так. Если бы я с самого начала выбрал правильную библиотеку, то в МК на моей макетке так же не удалось настроить прерывания, т.к. для него нужна "неправильная" библиотека.
Вот только интересно Китай ли продает неправильно маркированные чипы или же производитель позже изменил биты в регистре? Я пока не выяснял.