Мелкие вопросы по МК и ПЛИС.

ARV · Сообщение **ARV** » Чт янв 19, 2017 07:03:08

Z_h_e писал(а):Не влияет так не влияет, что 10 Ом, что 1000 кОм

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

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

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

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

что не логично или противоречит физике в моих рассуждениях? не холивара ради, а истины для?

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

Z_h_e писал(а):Оборванная цепь со впаянной кнопкой и не впаянной...

разве я не прав, разделяя вывод, торчащий из корпуса, к которому не подведена никакая дорожка (в моей терминологии - болтающийся вывод), и вывод, к которому подсоединена дорожка, временно ни с чем не соединенная? вы же сами называли это антенной! для меня вывод с антенной и без нее - разные вещи при рассмотрении помехоустойчивости, т.к. условия их работы отличаются. когда нам надо защитить МК от ложных сбросов, нам следует стремиться сохранить неизменный уровень на пине сброса при всяких непредвиденных изменениях "внешней среды", например, питающего напряжения. я точно не знаю, что там внутри кристалла AVR в цепи сброса, но там наверняка стоит компараор или триггер Шмидта, срабатывающий при определенном уровне напряжения. если по питанию пройдет скачок, то через встроенный в кристалл резистор (или внешний, рекомендованный вами) этот скачок неизбежно попадет на вход цепи сброса, и еще бабушка надвое сказала, как она отреагирует... если там триггер Шмидта - может, и никак (триггер реагирует на относительный уровень, т.е. при повышении питания триггера сдвигается и порог его срабатывания), а если компаратор, то может и сработать... и вот тут конденсатор - это единственное, что может как-то улучшить ситуацию, т.к. скачка на конденсаторе быть не должно при достаточной емкости.

вот такие пирожки...

FreshMan писал(а):а зачем тогда ставится внутренный резистор большого номинала ?

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

Реклама

Z_h_e

akl писал(а):Почему бы и нет. По мне, вполне нормальное решение, с учетом наличия модуля сброса в AVR

FreshMan писал(а):а зачем тогда ставится внутренный резистор большого номинала ?
подтягивали бы нору напрямую без резистора

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

ARV, я разве где-то говорил что кондер это зло или не эффективен? Вы сказали: "голый резистор никак не меняет помехозащищенность". Подключите к щупу осцилла провод "в воздухе", лучше подлиннее для наглядности. При том что у Вас уже будет подтяжка 1МОм и кондер пикушечка (вход осцилла). Отличный размах будет синусоиды. А потом подключите 1кОм между щупом и землей. Как Вы думаете, изменится картинка на осцилле от "голового резистора".

А про кнопку можно рассуждать только на конкретном устройстве. Примеры кнопки и разъема я привел для того, чтобы показать что дорожка RESET может быть и длинной и все.

Реклама

ARV · Сообщение **ARV** » Чт янв 19, 2017 07:54:36

Z_h_e писал(а):А про кнопку можно рассуждать только на конкретном устройстве

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

КРАМ

ARV писал(а):и в том контектсте резистор действительно ни к чему.

Конденсатор с сигнального провода на общий имеет смысл лишь тогда, когда внутреннее сопротивление источника помехи много меньше емкостного сопротивления конденсатора.
В этом же смысле подтяжка работает ничуть не хуже. Дело лишь в номинале резистора.
На входах сброса у многих МК есть входной фильтр, что делает установку емкости практически не нужной.

Реклама

Пока_без_кота

Доброго времени суток. Уже не в первой книге по МК читаю, что сторожевой таймер при отладке желательно отключать, и включать уже только после завершения процесса отладки. А есть знакомый разработчик, который делает с точностью до наоборот, с самого начала отлаживаясь со включенным сторожевым таймером, и утверждая, что так лучше. Так как правильнее ?

Реклама

Zhuk72

WDT - это предохранитель от случайных зависаний, имеющий смысл на готовом устройстве, а не при разработке оного. В процессе написания кода и наладки, когда вставляются/удаляются строки/куски кода, время до сработки таймера может меняться и придётся сдвигать точки сброса. Тогда какой в этом смысл? Написал, отладил, а потом уже активируй и определи точки сброса. Это мое мнение.

Реклама

КРАМ

Непонятно о какой отладке вообще идет речь.
Потому как в режиме железного дебага вачдог В ПРИНЦИПЕ не может использоваться. Ибо он работает независимо от тактирования контроллера и тупо будет его ресетить на брекпойнтах.
Что до использования вачдога в окончательном релизе, то либо оный вачдог использован в алгоритме как неотъемлемая его часть (таймаут), либо он затыкает ошибки этого алгоритма. В доброкачественном коде, при отсутствии необходимости самого алгоритма в вачдоге, этот самый вачдог нахрен не нужен.
Более того, попытки заткнуть дыры программы вачдогом могут привести к ДРУГИМ дырам. То есть он не является универсальной таблеткой от багов.

Пока_без_кота

Очень интересно получается. Потому что товарищ тот как раз пользуется "железным" отладчиком. Как у него тогда при включенном ватчдоге контроллер не ресетится я обязательно поинтересуюсь

А вообще я пока пользуюсь только отладкой в симуляторе, и в принципе только недавно начал пользоваться ватчдогом в силу простоты своих учебных проектов. И пока делаю это в точности как описал Zhuk72 - сперва пишу ВЕСЬ код, потом вставляю в нужные места сброс ватчдога. Значит пока и дальше буду так делать. Ватчдогом, помимо собственно подстраховки от зависаний, пользуюсь еще и как таймером пробуждения МК из состояния сна.

ARV · Сообщение **ARV** » Сб янв 28, 2017 10:03:42

Пока_без_кота писал(а):потом вставляю в нужные места сброс ватчдога.

самый цимес именно в местах ставки сброса

надеюсь, вы делаете это после проверки CRC критичных областей ОЗУ, проверки работы периферии, корректности полученных данных и сигналов на входах и выходах... а не просто в каждом цикле или, тем более, в обработчике таймера.

Пока_без_кота

ARV писал(а): ... надеюсь, вы делаете ...

К сожалению мой уровень пока гораздо ниже. Под спойлером можно увидеть, как я использую ватчдог насколько все плохо. (код под пик, с комментариями)

Спойлер

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

	list p=16f84
	include	p16f84.inc
	include	PIC16F84_master_control.h
	include	Soft_UART_Lib_use_Timer0.h
	include	Matrix_keyboard.h
	include	Macro.h
	include	Commands.h

#define	DEBUG			no;yes;
	
if (DEBUG)
	__config	_CP_OFF & _WDT_OFF & _PWRTE_ON & _XT_OSC
else
	__config	_CP_OFF & _WDT_ON & _PWRTE_ON & _XT_OSC
endif

	org	LAST_DEV_ADDR
	de	DEFAULT_LAST_DEV_ADDR

PIC16F84_Master_Control	udata_shr
w_temp			res	1
status_temp		res	1
command			res	1
flags			res	1
addr_temp		res	1
last_dev_addr	res	1

	extern	TX_byte,RX_byte,key_char
	extern	Init_UART,Soft_UART_ISR,Send_TX_byte,Get_RX_byte,Delay_1bit
	extern	Init_Matrix_Keyboard,Matrix_Keyboard_ISR,Release_Key,Anti_Debounce
	global	flags	
	global	End_Interrupt_Heandler
;======================
RESET_VECTOR	code	0h
	goto	Init
;======================
ISR				code	4h				; Вектор прерывания
Interrupt_Heandler
	push								; Сохраним контекст
	btfsc	INTCON,RBIF
	goto	Matrix_Keyboard_ISR			; Если было прерывание по изминению состояния RB7-RB4, переходим на соответствующий обработчик
	goto	Soft_UART_ISR				; Иначе переходим к обрабочику программного UART			
End_Interrupt_Heandler
	pop									; Восстановим контекст	
	retfie

Init
	movlw	b'11001'
	movwf	PORTA
	banksel	TRISA
	movlw	b'11000'
	movwf	TRISA
	banksel	PORTA
	call	Init_UART
	btfss	Registry_PIN				; Если установлен джампер регистрации новых модулей	
	goto	Reg_New_Modules				; Переходим в режим прописки новых модулей
	btfss	STATUS,NOT_TO				; Проверяем сброс по WD
	bsf		RED_LED						; Был сброс по WD, зажгем светодиод ошибки, скорее всего не было ответа от модуля
Main
	call	Init_Matrix_Keyboard
	clrf	flags
	Send_Value	00h						; Выдаем в сеть признак наличия мастера сети
Wait_Command							; Первая нажатая кнопка - это команда
	bcf		YELLOW_LED					; Гасим Желтый
	clrwdt
	sleep
	nop
	btfss	Yes_Press					; Если не было нажатия, крутимся в цикле
	goto	Wait_Command
	bcf		INTCON,RBIE					; Запрещаем повторные прерывания по дребезгу
	ZUMER_ON							; Озвучим нажатие
	Anti_Debounce_macro
	movfw	key_char	
	movwf	command
	swapf	command,f					; начинаем формировать команду для передачи - переместим собстевенно команду в старшую тетраду
	bcf		Yes_Press					
	bcf		INTCON,RBIF					; Сбросим флаг возможно прошедшего прерывания от клавиатуры
	bsf		INTCON,RBIE					; Закончили преварительное формирование команды (пока без адреса), разрешаем прерывание клавиатуры (ждем 2 нажатия кнопки для формирования адреса модуля)
	ZUMER_OFF
	clrwdt
	sleep
Wait_Num_of_Module						; Вторая нажатая кнопка - это номер модуля
;	clrwdt								; Специально не будем сбрасывать WD, чтобы случае ошибочного нажатия 1 раз выйти из этого цикла по сбросу
	btfss	Yes_Press					; Если не было нажатия, крутимся в цикле
	goto	Wait_Num_of_Module
	bcf		INTCON,RBIE					; Запрещаем повторные прерывания по дребезгу
	ZUMER_ON							; Озвучиваем нажатие
	Anti_Debounce_macro
	movfw	key_char					; Сформируем номер модуля
	iorwf	command						; И наложим маской на команду, получая в переменной command номер модуля (младшая тетрада) и собственно команда (старшая тетрада)
	bcf		INTCON,RBIF					; Сбросим флаг возможно прошедшего прерывания от клавиатуры, после отправки команды будут автоматичски разрешены все прерывания
	bsf		INTCON,RBIE
	Send_Byte	command					; Отправляем скомпонированную команду в сеть		
	bcf		Yes_Press					; Обработали нажатие, сбросим флаг
	ZUMER_OFF
if	(USE_DOUBLE_REQEST)
	movfw	key_char					; Берем последнюю нажатую кнопку
	btfsc	STATUS,Z					; Если пакет широковещательный (адрес 0) - просто шлем команду 2 раз						
	goto	Send_without_repeat
	bsf		YELLOW_LED					; Зажигаем Желтый
	Get_Byte							; Принимаем ответ (зациклимся в ожидании, если ответ не прийдет в течении 2.3 сек, произойдет сброс МК)
	movfw	command						; Берем отправленную команду
	andlw	b'00001111'					; Сами формируем ожидаемый первый ответ на эту команду
	subwf	RX_byte,w					; Сравниваем с полученным ответом	
	btfss	STATUS,Z
	goto	Error_Section				; Не равны, ошибка
	Send_Byte	command					; Равны, повторно отправляем команду в сеть	
else
	movfw	key_char					; Берем последнюю нажатую кнопку
	btfsc	STATUS,Z					; Если пакет широковещательный (адрес 0) - пропускаем прием ответа						
	goto	Send_without_repeat_2
	bsf		YELLOW_LED					; Зажигаем Желтый
endif
	Get_Byte							; Принимаем ответ (зациклимся в ожидании, если ответ не прийдет в течении 2.3 сек, произойдет сброс МК)
	movfw	command						; Берем отправленную команду
	subwf	RX_byte,w					; Сравниваем с полученой командой	
	btfss	STATUS,Z
	goto	Error_Section				; Не равны, ошибка
Send_without_repeat_2
	bcf		RED_LED						; Гасим светодиод ошибки	
	goto	Wait_Command				; Команда выполнена, зациклимся

Error_Section
	bsf		RED_LED						; Зажгем светодиод ошибки (команда не была выполнена)
	goto	Wait_Command

if	(USE_DOUBLE_REQEST)
Send_without_repeat
	call	Delay_1bit					; Дадим модулю время разобрать первую копию команды	
	Send_Byte	command
	goto	Send_without_repeat_2
endif		

Reg_New_Modules
	bsf		YELLOW_LED
	call	Read_LAST_DEV_ADDR			; Считаем адрес последнего приписанного модуля в addr_temp
Loop_Registration
	incf	addr_temp					; Берем следующий адрес для записи
	movlw	0Fh							; Возможно это 15 адрес ? (достигли предела модулей)
	subwf	addr_temp,w
	btfsc	STATUS,Z
	goto	No_More_Modules	
Step_0
	Send_Value	0Fh						; Отсылаем команду опроса 15 модуля
	Get_Byte							; Ждем ответа в течении 2.3 сек, потом сброс МК, переинициализация контроллера и повторное попадание в эту ветку
	movlw	0Fh							; Ответ получен. Сравним отправленую команду с полученной
	subwf	RX_byte,w
	btfss	STATUS,Z	
	goto	Step_0						; Не иденитичны, повторная отправка
Step_1
	Send_Value	0FFh					; Идентичны модуль с номером 15 находиться в сети, начинаем процедуру смены адреса
	Get_Byte							; Ждем ответа в течении 2.3 сек, потом сброс МК, переинициализация контроллера и повторное попадание в эту ветку
	movlw	0Fh							; Ответ получен. Сравним ответ с образцом - командой опроса
	subwf	RX_byte,w
	btfss	STATUS,Z	
	goto	Step_1						; Не иденитичны, повторная отправка
Step_2
	Send_Value	0FFh					; Идентичны модуль с номером 15 готов к смене адреса, продолжаем процедуру смены адреса
	Get_Byte							; Ждем ответа в течении 2.3 сек, потом сброс МК, переинициализация контроллера и повторное попадание в эту ветку
	movlw	0FFh						; Ответ получен. Сравним отправленую команду с полученной
	subwf	RX_byte,w
	btfss	STATUS,Z	
	goto	Step_1						; Не иденитичны, повторная отправка первый раз	
Step_3
	swapf	addr_temp,w					; Перемещаем новый адрес в старшую тетраду
	iorlw	0Fh							; Накладываем маску адреса 15
	movwf	command						; Запоминаем полученную команду
	Send_Byte	command					; И отправляем
	Get_Byte							; Ждем ответа в течении 2.3 сек, потом сброс МК, переинициализация контроллера и повторное попадание в эту ветку 
	movfw	command						; Ответ получен. Сравним ответ с образцом - отправленой командой
	subwf	RX_byte,w
	btfss	STATUS,Z	
	goto	Step_0						; Не иденитичны, начинаем процедуру смены адреса заново
Step_4
	Send_Byte	command					; Повторно отправляем новый адрес
	Get_Byte							; Ждем ответа в течении 2.3 сек, потом сброс МК, переинициализация контроллера и повторное попадание в эту ветку 
	movfw	addr_temp					; Ответ получен. Сравним ответ с образцом - командой опроса нового адреса (совпадает с адресом)
	subwf	RX_byte,w
	btfss	STATUS,Z	
	goto	Step_0						; Не иденитичны, начинаем процедуру смены адреса заново
Step_5
	ZUMER_ON							; Пикнем зумером в знак того, что происходит запись нового адреса в EEPROM модуля
	movfw	addr_temp
	call	Write_LAST_DEV_ADDR			; Запомним последний приписанный адрес в EEPROM
	ZUMER_OFF
	goto	Loop_Registration			; Процедура приписки закончена успешно, ждем подключения следующего модуля

No_More_Modules							; Мы достигли максимального количества приписанных модулей
	clrf	addr_temp					; Обнуляем количество приписанных модулей
	movfw	addr_temp
	call	Write_LAST_DEV_ADDR			; И записываем 0 в соответствующую ячейку EEPROM
	clrwdt								
	sleep
	nop
	btfss	Registry_PIN				; Ожидаем снятия джемпера приписки модулей
	goto	$-3
	goto	Main

Z_h_e

ARV писал(а): надеюсь, вы делаете это после проверки CRC критичных областей ОЗУ, проверки работы периферии, корректности полученных данных и сигналов на входах и выходах...

Если программа может сама себя корректно проверить, то смысла в WDT нет совсем, разве что его использовать как источник сброса. А вот если МК завис где-то, например из-за сбоя питания или внешней помехи, то WDT может с определенной вероятностью помочь.
З.Ы. В некоторых МК WDT может работать в оконном режиме. В таких МК сброс произойдет не только при переполнении счетчика, но при преждевременном сбросе WDT.

ARV · Сообщение **ARV** » Вс янв 29, 2017 11:36:08

Z_h_e писал(а):WDT может с определенной вероятностью помочь

речь ведь о том, когда и где СБРАСЫВАТЬ WDT. например, мы ждем импульса с внешней периферии, опрашивая в цикле пин. условие выхода из цикла - нужный уровень на пине. так вот, было бы грубой ошибкой сбрасывать WDT внутри этого цикла ожидания - так ведь? потому что если это делать, то при проблемах ВНЕ цикла (например, при проблеме в периферии) мы никогда не выйдем из цикла, и при этом WDT не поможет, т.к. сбрасывается нами же. аналогичная проблема со сбросом WDT тупо по прерыванию таймера - где бы и по какой причине не зависла программа, если таймер продолжает работать, мы никогда не "развиснем".

если это понимать - использование WDT становится более осмысленным, но и существенно более сложным.

более-менее правильный алгоритм сброса WDT должен быть таким: периодически следует проверять состояние критических объектов программы и сбрасывать WDT только в том случае, если состояние этих объектов не выходит из разрешенных диапазонов. например, мы рассчитываем, что какое-то прерывание должно срабатывать каждую секунду. в обработчике этого прерывания мы ставим флаг-признак срабатывания, а по таймеру каждые 1,5 секунды этот флаг сбрасываем. при опросе смотрим, меняется ли состояние этого флага? если он всегда имеет одно и то же значение - это очень нехороший признак и лучше WDT не сбрасывать - пусть система ресетнится. а если флаг периодически свое значение меняет, значит, и внешнее прерывание возникает, и таймер не завис - можно WDT и сбросить.

как-то так... пример с флагом не самый удачный, но все-таки суть отражает.

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

oleg110592

добавлю имхо полезную ссылочку о WDT:
http://www.pic24.ru/doku.php/osa/articles/wdt

Z_h_e

ARV, Вы по-моему не поняли, что я имел сказать. Попробую еще раз.

1.
Допустим Ваша программа с определенной периодичностью, по некоторым признакам тестирует себя. Нужен тут WDT как таковой? Нет. Программа определила сама что что-то тут не так и дальше должна повести себя в зависимости от заложенного алгоритма. Конечно в основном это сброс. Сбросить себя можно по разному, можно дернуть себя за Резет, в некоторых случаях можно запустить программу с начала без сброса (хотя я бы не стал так делать), в каких то МК наверное можно вызвать какое-то исключение приводящее к сбросу. Ну или самое простое это сброс по WDT. При том, что генератор WDT до нужного момента и не работать, например в целях энергосбережения.

2.
А вот назначение самого WDT - это сброс, если МК не выполнил определенный код в определенное время, т.е. завис. Что это за определенный код, зависит от программы и конечно тут тоже стоит хорошо все обдумать. Само собой тут его генератор обязан быть включенным всегда.

Резюмирую:
- п.1 и п.2 разные вещи, но ради одной цели.
- п.1 и п.2 могут присутствовать в коде как одновременно, так и только один из них или совсем без них. Например, грамотное использование только WDT тоже дает вероятность восстановления работы, без усложнения и увеличения кода. Т.е. использование WDT не обязывает усложнять алгоритм и тоже может быть полезным.
- совсем не обязательно проверять целостность программы перед сбросом WDT (хотя так наверное удобнее), это может проводится в разное время и в разных участках кода.

КРАМ

Вообще нигде не использую WDT для защиты от зацикливания. Но иногда использую для целей алгоритма. Так в одном из устройств WDT охраняет часы работающие от внешнего часового кварца, где сами часы предназначены для отсчета времени активации устройства. Если какой нибудь злоумышленник пожелает сделать устройство своим, по завершении времени активации устройство перестанет выполнять свои функции.

В этом применении WDT сбрасывается в прерывании по часам (раз в 2 секунды).

San40

Подскажите пожалуйста, я все правильно переписал с AVR на ARM ?

Было для AVR:
#define data1 6
PORTB = ((yoztx & (1 << i)) << data1);

Переписал для ARM:
#define data1 GPIO_Pin_6
if (yoztx & (1 << i)) GPIO_SetBits(GPIOB, data1);
else GPIO_ResetBits(GPIOB, data1);

А оно работает ? Почему сомнения в неправильности ?

San40

Аlex писал(а):А оно работает ? Почему сомнения в неправильности ?

нет, компилятор arduino ide ругается 'GPIO_SetBits' was not declared in this scope. хотя stm32 в него установлена

В ардуине же свои функции для работы с портами.

San40

Аlex писал(а):В ардуине же свои функции для работы с портами.

digitalWrite слишком долгая, 2 мкС, мне нужно быстрее. на PORTB = (1 << 7); тоже ругается

А переходить полностью на правильное программирование я еще не готов, но стремлюсь к этому

Нашёл, gpio_write(read)_bit(GPIOx, pin, value)