Страница 579 из 628
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Чт янв 19, 2017 07:03:08
ARV
Z_h_e писал(а):Не влияет так не влияет, что 10 Ом, что 1000 кОм
ну давайте рассуждать... проводник - это индуктивность... свойство индуктивности - допускать "иголки" напряжений, т.е. всплески. эти всплески мы называем "помехами по питанию" - верно? ну или просто помехами. я не искажаю?
если мы подозрительный проводник соединяем резистором, т.е. компонентом, который так или иначе обеспечивает протекание тока, с цепью, где могут быть помехи - мы улучшаем или ухудшаем помехоустойчивость этой цепи? хоть 10 Ом, хоть 1000 кОм - по сравнению с отсутствием связи любое соединение может только в худшую сторону изменить ситуацию. так или не так?
что такое конденсатор? это компонент, свойством которого является противодействие иголкам напряжения. то есть если мы желаем обезопасить свою цепь от этих иголок, нам надо ставить конденсатор.
теперь про проводник-антенну. в антенне наводится переменная ЭДС - верно? резистор с одинаковым успехом проводит переменный ток и постоянный. конденсатор же только переменный. соединив антенну с землей через конденсатор мы пытаемся добиться, что наведенный переменный ток стечет в землю и не попадет в другие цепи. "заземление" ненужных сигналов - типичный способ борьбы с ними.
что не логично или противоречит физике в моих рассуждениях? не холивара ради, а истины для?
вывод: конденсатор для борьбы с помехами на болтающемся выводе сброса предпочтительнее, чем резистор.
Z_h_e писал(а):Оборванная цепь со впаянной кнопкой и не впаянной...
разве я не прав, разделяя вывод, торчащий из корпуса, к которому не подведена никакая дорожка (в моей терминологии - болтающийся вывод), и вывод, к которому подсоединена дорожка, временно ни с чем не соединенная? вы же сами называли это антенной! для меня вывод с антенной и без нее - разные вещи при рассмотрении помехоустойчивости, т.к. условия их работы отличаются. когда нам надо защитить МК от ложных сбросов, нам следует стремиться сохранить неизменный уровень на пине сброса при всяких непредвиденных изменениях "внешней среды", например, питающего напряжения. я точно не знаю, что там внутри кристалла AVR в цепи сброса, но там наверняка стоит компараор или триггер Шмидта, срабатывающий при определенном уровне напряжения. если по питанию пройдет скачок, то через встроенный в кристалл резистор (или внешний, рекомендованный вами) этот скачок неизбежно попадет на вход цепи сброса, и еще бабушка надвое сказала, как она отреагирует... если там триггер Шмидта - может, и никак (триггер реагирует на относительный уровень, т.е. при повышении питания триггера сдвигается и порог его срабатывания), а если компаратор, то может и сработать... и вот тут конденсатор - это единственное, что может как-то улучшить ситуацию, т.к. скачка на конденсаторе быть не должно при достаточной емкости.
вот такие пирожки...
FreshMan писал(а):а зачем тогда ставится внутренный резистор большого номинала ?
см. выше - для обеспечения работы схемы автоматического сброса при подаче питания. должен же тот самый триггер Шмидта или компаратор как-то узнать, что питание дошло до нормы? вот и соединяют его вход с питанием. а не напрямую - надо же и внешнюю цепь позволять... было бы глухое соединение - откуда взять внешний сброс?

Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Чт янв 19, 2017 07:42:42
Z_h_e
akl писал(а):Почему бы и нет. По мне, вполне нормальное решение, с учетом наличия модуля сброса в AVR
FreshMan писал(а):а зачем тогда ставится внутренный резистор большого номинала ?
подтягивали бы нору напрямую без резистора
Лично я понял, что
FreshMan говорит о внутреннем резисторе. А так да, смело можно и напрямую, только забыть о внутрисхемном программировании.
ARV, я разве где-то говорил что кондер это зло или не эффективен? Вы сказали:
"голый резистор никак не меняет помехозащищенность". Подключите к щупу осцилла провод "в воздухе", лучше подлиннее для наглядности. При том что у Вас уже будет подтяжка 1МОм и кондер пикушечка (вход осцилла). Отличный размах будет синусоиды. А потом подключите 1кОм между щупом и землей. Как Вы думаете, изменится картинка на осцилле от "голового резистора".
А про кнопку можно рассуждать только на конкретном устройстве. Примеры кнопки и разъема я привел для того, чтобы показать что дорожка RESET может быть и длинной и все.
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Чт янв 19, 2017 07:54:36
ARV
Z_h_e писал(а):А про кнопку можно рассуждать только на конкретном устройстве
про кноку я упоминал только в контексте отличия болтающегося в воздухе, т.е. ни к чему не подключенного, пина от пина с дорожкой. а в остальном я с вами согласен - лучше говорить о конкретных схемах. вход осциллографа - это ближе к сферическому коню в вакууме, чем вход сброса с кондером или резистором. про пин сброса я выше все, что думаю, рассказал, и в том контектсте резистор действительно ни к чему.
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Чт янв 19, 2017 08:02:16
КРАМ
ARV писал(а):и в том контектсте резистор действительно ни к чему.
Конденсатор с сигнального провода на общий имеет смысл лишь тогда, когда внутреннее сопротивление источника помехи много меньше емкостного сопротивления конденсатора.
В этом же смысле подтяжка работает ничуть не хуже. Дело лишь в номинале резистора.
На входах сброса у многих МК есть входной фильтр, что делает установку емкости практически не нужной.
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Пт янв 27, 2017 23:25:54
Пока_без_кота
Доброго времени суток. Уже не в первой книге по МК читаю, что сторожевой таймер при отладке желательно отключать, и включать уже только после завершения процесса отладки. А есть знакомый разработчик, который делает с точностью до наоборот, с самого начала отлаживаясь со включенным сторожевым таймером, и утверждая, что так лучше. Так как правильнее ?
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Сб янв 28, 2017 07:10:04
Zhuk72
WDT - это предохранитель от случайных зависаний, имеющий смысл на готовом устройстве, а не при разработке оного. В процессе написания кода и наладки, когда вставляются/удаляются строки/куски кода, время до сработки таймера может меняться и придётся сдвигать точки сброса. Тогда какой в этом смысл? Написал, отладил, а потом уже активируй и определи точки сброса. Это мое мнение.
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Сб янв 28, 2017 07:55:56
КРАМ
Непонятно о какой отладке вообще идет речь.
Потому как в режиме железного дебага вачдог В ПРИНЦИПЕ не может использоваться. Ибо он работает независимо от тактирования контроллера и тупо будет его ресетить на брекпойнтах.
Что до использования вачдога в окончательном релизе, то либо оный вачдог использован в алгоритме как неотъемлемая его часть (таймаут), либо он затыкает ошибки этого алгоритма. В доброкачественном коде, при отсутствии необходимости самого алгоритма в вачдоге, этот самый вачдог нахрен не нужен.
Более того, попытки заткнуть дыры программы вачдогом могут привести к ДРУГИМ дырам. То есть он не является универсальной таблеткой от багов.
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Сб янв 28, 2017 09:58:35
Пока_без_кота
Очень интересно получается. Потому что товарищ тот как раз пользуется "железным" отладчиком. Как у него тогда при включенном ватчдоге контроллер не ресетится я обязательно поинтересуюсь

А вообще я пока пользуюсь только отладкой в симуляторе, и в принципе только недавно начал пользоваться ватчдогом в силу простоты своих учебных проектов. И пока делаю это в точности как описал Zhuk72 - сперва пишу ВЕСЬ код, потом вставляю в нужные места сброс ватчдога. Значит пока и дальше буду так делать. Ватчдогом, помимо собственно подстраховки от зависаний, пользуюсь еще и как таймером пробуждения МК из состояния сна.
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Сб янв 28, 2017 10:03:42
ARV
Пока_без_кота писал(а):потом вставляю в нужные места сброс ватчдога.
самый цимес именно в местах ставки сброса

надеюсь, вы делаете это после проверки CRC критичных областей ОЗУ, проверки работы периферии, корректности полученных данных и сигналов на входах и выходах... а не просто в каждом цикле или, тем более, в обработчике таймера.
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Сб янв 28, 2017 10:40:02
Пока_без_кота
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
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Вс янв 29, 2017 11:19:18
Z_h_e
ARV писал(а): надеюсь, вы делаете это после проверки CRC критичных областей ОЗУ, проверки работы периферии, корректности полученных данных и сигналов на входах и выходах...
Если программа может сама себя корректно проверить, то смысла в WDT нет совсем, разве что его использовать как источник сброса. А вот если МК завис где-то, например из-за сбоя питания или внешней помехи, то WDT может с определенной вероятностью помочь.
З.Ы. В некоторых МК WDT может работать в оконном режиме. В таких МК сброс произойдет не только при переполнении счетчика, но при преждевременном сбросе WDT.
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Вс янв 29, 2017 11:36:08
ARV
Z_h_e писал(а):WDT может с определенной вероятностью помочь
речь ведь о том, когда и где СБРАСЫВАТЬ WDT. например, мы ждем импульса с внешней периферии, опрашивая в цикле пин. условие выхода из цикла - нужный уровень на пине. так вот, было бы грубой ошибкой сбрасывать WDT внутри этого цикла ожидания - так ведь? потому что если это делать, то при проблемах ВНЕ цикла (например, при проблеме в периферии) мы никогда не выйдем из цикла, и при этом WDT не поможет, т.к. сбрасывается нами же. аналогичная проблема со сбросом WDT тупо по прерыванию таймера - где бы и по какой причине не зависла программа, если таймер продолжает работать, мы никогда не "развиснем".
если это понимать - использование WDT становится более осмысленным, но и существенно более сложным.
более-менее правильный алгоритм сброса WDT должен быть таким: периодически следует проверять состояние критических объектов программы и сбрасывать WDT только в том случае, если состояние этих объектов не выходит из разрешенных диапазонов. например, мы рассчитываем, что какое-то прерывание должно срабатывать каждую секунду. в обработчике этого прерывания мы ставим флаг-признак срабатывания, а по таймеру каждые 1,5 секунды этот флаг сбрасываем. при опросе смотрим, меняется ли состояние этого флага? если он всегда имеет одно и то же значение - это очень нехороший признак и лучше WDT не сбрасывать - пусть система ресетнится. а если флаг периодически свое значение меняет, значит, и внешнее прерывание возникает, и таймер не завис - можно WDT и сбросить.
как-то так... пример с флагом не самый удачный, но все-таки суть отражает.
лично мой опыт говорит, что при попытке повысить надежность своей разработки путем использования WDT,
многократно возрастает сложность алгоритмов в программе. и порой возникает состояние полной безнадеги, т.к. приходит параноидальное ощущение невозможности предусмотреть контроль всего...
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Вс янв 29, 2017 11:50:58
oleg110592
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Вс янв 29, 2017 12:53:24
Z_h_e
ARV, Вы по-моему не поняли, что я имел сказать. Попробую еще раз.
1.
Допустим Ваша программа с определенной периодичностью, по некоторым признакам тестирует себя. Нужен тут WDT как таковой? Нет. Программа определила сама что что-то тут не так и дальше должна повести себя в зависимости от заложенного алгоритма. Конечно в основном это сброс. Сбросить себя можно по разному, можно дернуть себя за Резет, в некоторых случаях можно запустить программу с начала без сброса (хотя я бы не стал так делать), в каких то МК наверное можно вызвать какое-то исключение приводящее к сбросу. Ну или самое простое это сброс по WDT. При том, что генератор WDT до нужного момента и не работать, например в целях энергосбережения.
2.
А вот назначение самого WDT - это сброс, если МК не выполнил определенный код в определенное время, т.е. завис. Что это за определенный код, зависит от программы и конечно тут тоже стоит хорошо все обдумать. Само собой тут его генератор обязан быть включенным всегда.
Резюмирую:
- п.1 и п.2 разные вещи, но ради одной цели.
- п.1 и п.2 могут присутствовать в коде как одновременно, так и только один из них или совсем без них. Например, грамотное использование только WDT тоже дает вероятность восстановления работы, без усложнения и увеличения кода. Т.е. использование WDT не обязывает усложнять алгоритм и тоже может быть полезным.
- совсем не обязательно проверять целостность программы перед сбросом WDT (хотя так наверное удобнее), это может проводится в разное время и в разных участках кода.
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Вс янв 29, 2017 15:59:21
КРАМ
Вообще нигде не использую WDT для защиты от зацикливания. Но иногда использую для целей алгоритма. Так в одном из устройств WDT охраняет часы работающие от внешнего часового кварца, где сами часы предназначены для отсчета времени активации устройства. Если какой нибудь злоумышленник пожелает сделать устройство своим, по завершении времени активации устройство перестанет выполнять свои функции.
В этом применении WDT сбрасывается в прерывании по часам (раз в 2 секунды).
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Пн янв 30, 2017 16:04:23
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);
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Пн янв 30, 2017 16:07:16
Аlex
А оно работает ? Почему сомнения в неправильности ?
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Пн янв 30, 2017 16:13:48
San40
Аlex писал(а):А оно работает ? Почему сомнения в неправильности ?
нет, компилятор arduino ide ругается 'GPIO_SetBits' was not declared in this scope. хотя stm32 в него установлена
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Пн янв 30, 2017 16:20:09
Аlex
В ардуине же свои функции для работы с портами.
Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Пн янв 30, 2017 16:23:18
San40
Аlex писал(а):В ардуине же свои функции для работы с портами.
digitalWrite слишком долгая, 2 мкС, мне нужно быстрее. на PORTB = (1 << 7); тоже ругается
А переходить полностью на правильное программирование я еще не готов, но стремлюсь к этому
Нашёл, gpio_write(read)_bit(GPIOx, pin, value)