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

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

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

[Zhuk72]

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

[КРАМ]

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

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

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

[ARV]

потом вставляю в нужные места сброс ватчдога.

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

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

... надеюсь, вы делаете ...

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

Спойлер

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

   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]

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

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

[ARV]

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);

[Аlex]

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

[San40]

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

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

[Аlex]

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

[San40]

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

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


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

[hosturik]

А подскажите новичку, правильно ли сбрасывать WDT в основном цикле. Контроллер ATmega. Устройство - регулятор температуры.
Не хотелось бы чтобы при зависании температура вышла за пределы.
Устройство хорошо работает и так, но хочется перестраховаться, мало ли какая помеха проскочит.

Как я понимаю, если программа зависает в каком то цикле, основной цикл не срабатывает и соответственно Watchdog не сбрасывается.
Почти вся логика программы находится в обработчиках прерываний. В основном цикле только вывод на дисплей.
По крайней мере, при тестах, если вставить где то вечный цикл, то происходит бесконечный рестарт МК. Значит все правильно?

[Z_h_e]

Не хотелось бы чтобы при зависании температура вышла за пределы.

При таких опасениях, лучше поставте какое-нибудь термореле, можно таблетку биметаллическую, которое отключает все при аварийной температуре.

[ARV]

А подскажите новичку, правильно ли сбрасывать WDT в основном цикле. Контроллер ATmega. Устройство - регулятор температуры.
Не хотелось бы чтобы при зависании температура вышла за пределы.

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

паранойя - этовсёпожирающая страсть начав параноить однажды, уже не остановитесь.

[aam]

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