Помогите написать алгоритм для кнопки.
- Войдите на сайт для отправки комментариев
Пнд, 22/01/2018 - 22:23
Задача такая:
При нажатии кнопки (например на 8 пине) необходимо выдать на пин (например 9) напряжение в течении 5 секунд после чего убрать напряжение. Алгоритм без использования delay.
#18
задача понятная, так чем помочь то ? сделать за вас ?
#18
ща у чела инфаркт будет ))
Задача такая:
При нажатии кнопки (например на 8 пине) необходимо выдать на пин (например 9) напряжение в течении 5 секунд после чего убрать напряжение. Алгоритм без использования delay.
я сам новичек, но вот какраз только щас и закончил с кнопками
для вашей задачи всё просто
1) при нажатии кнопки
а) подаете на 9й пин напряжение )
б) запускаете таймер на основе millis()
2) как только он натикал 5 секунд (5000мс) - снимаете с 9й пин напряжение )
ELITE, еслм не сложно можно пример для ознакомления
#18
Человек же ясно написал - 5 секунд! А Вы даёте пример на 2 секунды! Он что, переделывать должен? Совсем, блин, гуру распустились! :)
лучше (ИМХО) параллельно кнопке поставить конденсатор на 100-500нф - никакого дребезга не будет, и никаких усложнений кода //я себе именно так и сделал
также ЗАБУДЬТЕ вы о дефайнах!! - это зло дебага!
ну и мой вариант кода
делает тоже самое, и весит поменьше:
также ЗАБУДЬТЕ вы о дефайнах!! - это зло дебага!
define - фактически автозамена текста в коде
что будет есть например написать #define setup 12345 ??
правильно - ошибка, при этом компилатор не укажет место ошибки
а если будет код на пару тысяч строк и гдето случайно будет использована переменная по имени совпавшая с дефайном?? - так можно очень легко получить огромную головную боль в поиске этой ошибки!
а если это не критическая для компиляции ошибка? - то она может вылезти в процессе работы устройства, при этом не сразу и рандомно
ну и самое важное - использовать дефайн никак не выгоднее констунты - расурсы они занимают одинаково, размер кода не меняется, нагрузка тоже
но вот только конструнта, как и другие переменные, в случае ошибок - компилятор сразу укажет где и что не так!
----------
по коду - защита от множественного срабатывания - это имеется ввиду, что при нажатой кнопке будет зафиксированно единственное нажатие, не зависимо от кол-ва циклов проверки состояния её - тоесть зафиксирован факт нажатия
а защита от дребезга - как уже сказал - конденсатор || кнопке решает всё лучше всякого кода
100нф дают примерно 5-10мс задержку, что полностью избавляет от всех эффектов дребезга контактов, но при этом вполне позволяет фиксироваю даже очень быстрые повторные нажатия (человеком) - порядка 100 нажатий в секунду - это весьма большой запас!
а если будет код на пару тысяч строк и гдето случайно будет использована переменная по имени совпавшая с дефайном?? - так можно очень легко получить огромную головную боль в поиске этой ошибки!
Для предотвращения этого есть простые правила - хорошим тоном является использовать в именах дефайнов только прописные (большие) буквы, а в переменных, именах функций и тп - строчные(маленькие) или смесь из прописных и строчных.
А вот тут вы резко ошибаетесь. Дефайн, как вы верно отметили - макроподстановка. поэтому не занимает места в оперативной памяти.
по коду - защита от множественного срабатывания - это имеется ввиду, что при нажатой кнопке будет зафиксированно единственное нажатие, не зависимо от кол-ва циклов проверки состояния её
защита от множественного нажатия обычно предполагает, что независимо от числа нажатий цикл отсчета времени запустится только один раз. В вашем коде при каждом нажатии и отпускании кнопки отсчет времени стартует заново, даже если предыдущий интервал еще не закончен.
защита от множественного нажатия обычно предполагает, что независимо от числа нажатий цикл отсчета времени запустится только один раз. В вашем коде при каждом нажатии и отпускании кнопки отсчет времени стартует заново, даже если предыдущий интервал еще не закончен.
я в этом коде подразумеваю, что при проверке кнопки , если она остается нажата (а мк успеет проверить это много десятков раз даже при коротком нажатии) - будет воспринято что было единственное нажатие, а не нажатие кнопки при каждом проходе цикла - это актуально, если надо считать число нажатий например - хотя в задачи ТС это изличше и можно тоже удалить, код станет еще меньше
ну тоже есть часть сути - но тут надо ТС, дабы он ответил, надо ему дожидаться окончания и выключения или нужна возможность продления до окончания таймера....
да и это решается просто перестановкой местами условий, даже код не меняется )
А вот тут вы резко ошибаетесь. Дефайн, как вы верно отметили - макроподстановка. поэтому не занимает места в оперативной памяти.
Если в дефайне строка и он использован в нескольких местах, то в них будет совершенно справедливо откопированна эта строка. Если же используется переменная, то можно обойтись расходом памяти в размере указателя. Ну, и когда константы в переменных, компилятор хотя бы их тип проверяет.
Но я не против дефайнов. Для условной компиляции они - единственное спасение.
b707, всё хорошо в меру. Я вот тоже с дефайнами ужиться не могу,
http://arduino.ru/forum/programmirovanie/etyudy-dlya-nachinayushchikh-pamyat-1-chto-i-kak-ne-nado-delat?page=3#comment-336280
предпочитаю static const или просто const. Компилятор, зачастую, оптимизирует эту const до простой подстановки. А всё зло дефайнов можно только для условной компиляции использовать. В остальном - нуихнах...
ПыСы. Вот. и sadman то же говорит.
кстати да, в примерах и описании именно для ардуины - компилятор так и делает, поэтому и нет лишнего расхода памяти на константы по сравнению с дефайнами
по дефайнам и константам
простой пример (часть кода) - далее в коде программы они вызываются также 4 раза (по 1 разу каждая)
Ну хорошо, по расходу оперативки вы меня убедили. Однако я продолжу (с вашего позволения :) использовать дефайны в своих программах.
Дефайны удобны не только для условной компиляции, но и для замены длинных конструкций короткими, типа
#define PGM_CHR (const __FlashStringHelper *)
На мой взгляд, и константы удобнее использовать в виде дефайнов - читабельность кода увеливается.
... и как удивительно, но что дефайн что константа инт (1 байт) что лонг (4 байта) - никак не отличаются в итоге....
Надо же, даже размер кода не увеличивается.... Тут уж без комментариев.
А ежели ему сунуть #pragma GCC optimize ("O0") ?
Надо же, даже размер кода не увеличивается.... Тут уж без комментариев.
ну ежели компилятор подставляет в код вместо константы ее значение, то это, по сути, дефайн и есть. Так что выходит, использовать константы или дефайны - дело вкуса.
На стороне констант - проверка типа переменной и варнинги о потенциальных ошибках. На стороне дефайна - лучшая структурированность и читабельность кода, поскольку дефайны не сливаются с прочими константами и переменными, что позволяет выделить в коде важные для работы настройки.
дефайны не дефайны, щас ТС испугается и убежит от таких страшных слов. ЗЫ. Зато в моем коде конденсатор не нужен на кнопку)
щас ТС испугается и убежит
"Слушай, говорит, кто он такой этот потерпевший? Куда он пошел? Я его, говорит, первый раз вижу." (с)
Задача такая:
При нажатии кнопки (например на 8 пине) необходимо выдать на пин (например 9) напряжение в течении 5 секунд после чего убрать напряжение. Алгоритм без использования delay.
Отчего же не помочь. Тем более в этом году еще не помогал.
Удачно сдать как Си выучите не зазнавайтесь, на форум заглядывайте, тоже уому поможете.
Зато в моем коде конденсатор не нужен на кнопку)
аппаратные решения всегда надежнее программных
и да, у вас есть убиственная delay! еще до кучи
Зато в моем коде конденсатор не нужен на кнопку)
аппаратные решения всегда надежнее программных
Да ну! Ща перепаяю вот высохший электролит, и пойду высохший код искать.
Зато в моем коде конденсатор не нужен на кнопку)
аппаратные решения всегда надежнее программных
Да ну! Ща перепаяю вот высохший электролит, и пойду высохший код искать.
какие электролиты?! - кнопке нужен (и достаточен) обычный керамический кондер размером со спичечную головку... а они практически вечные, даже если он начнет терять емкость лет через 15 - он будет работать не хуже .... а лет через 50-70 маловероятно, что изделие еще будет актуально и работоспособно..., кнопки явно сотрутся в пыль за такой срок... а вот кондер наверняка будет спокойно жить...
Удачно сдать
Садист! :)
Вы же писали "всегда надежнее" вот и обсуждаю что хочу. Код надежность не теряет. Потому представления из категории "механика надежней электроники" оставте в прошлом веке им там самое место.
Надо же, даже размер кода не увеличивается.... Тут уж без комментариев.
ну ежели компилятор подставляет в код вместо константы ее значение, то это, по сути, дефайн и есть. Так что выходит, использовать константы или дефайны - дело вкуса.
Этот коммент не Вам, а Илите. У него, что с int, что с long код одного размера, что говорит о том, что компилятор потёр всё ненужное. Иначе с long кода бы было больше, грузить в регистры int несколько короче чем long.
Я вот про это говорил.
1
const
int
interval1 = 100;
// таймер 1 - счетчик для секундомера
2
const
int
interval2 = 50;
// таймер 2 - обновление экрана
3
const
int
interval3 = 500;
// таймер 3 - для тахометра
4
const
int
interval4 = 100;
// таймер 4 - таймер кнопок
расечатать?
1
const
long
interval1 = 100;
// таймер 1 - счетчик для секундомера
2
const
long
interval2 = 50;
// таймер 2 - обновление экрана
3
const
long
interval3 = 500;
// таймер 3 - для тахометра
4
const
long
interval4 = 100;
// таймер 4 - таймер кнопок
Удачно сдать
Садист! :)
))) Ни одно доброе дело не останится безнаказаным!
аппаратные решения всегда надежнее программных
Да, неужели? Так-таки и всегда?
и да, у вас есть убиственная delay! еще до кучи
все правда, только ТСу я думаю это не помешает. А проверить легче. Нужна только дуня.
Этот коммент не Вам, а Илите. У него, что с int, что с long код одного размера, что говорит о том, что компилятор потёр всё ненужное. Иначе с long кода бы было больше, грузить в регистры int несколько короче чем long.
все понятно. Константы обьявлены, но в коде, видимо, не используются. Подтасовочка :)
У кого Ардуино под рукой - проверьте код Илиты с реальным использованием констант...
аппаратные решения всегда надежнее программных
Да, неужели? Так-таки и всегда?
что будет, если гипотетически рядом с устройством взорвать атомную бомбу, которая не уничтожит его материально (сключаем температуру и ударное воздействие)
кнопку как была включена - так и останется включена
а вот программа может и словить сбой изза жесткого излучения и мощных магнитных полей - ведь всё крутится в памяти - а достаточно протону пробить ячейки - неизвестно что в ней останется при считывании - а значит и надежность ниже
Да, программно можно сделать коррекцию ошибок и обход аппаратных поломок, но это уже иные системы, а прямоаналогичные аппаратные будут всегда надежней прогреммнях
//и да, давайте не будем топить урановый лом в ванне с ртутью ®
вот весь код моей поделки (ну что на сегодня навоял)
и да, у меня библиотека изменена немного
LedControl.cpp
LedControl.h
если гипотетически рядом с устройством взорвать атомную бомбу, которая не уничтожит его материально (сключаем температуру и ударное воздействие)
простой, доступный, повседневный пример :)
Хватит демагогию разводить. Как кондеры из строя выходят без ядерного взрыва хороше известно, если ума не хватает без довесок код писать - Ваша проблема.
вот весь код моей поделки (ну что на сегодня навоял)
позвольте вас спросить, как художник художника :) чем отличаются эти строки? (123 -124)
Судя по строчкам 205-220, пользоваться циклами вы так и не научились...
вот весь код моей поделки (ну что на сегодня навоял)
позвольте вас спросить, как художник художника :) чем отличаются эти строки? (123 -124)
Судя по строчкам 205-220, пользоваться циклами вы так и не научились...
по 123 -124 - это для наглядности, код в процессе написания и нет четкого ТЗ - поэтому меняется по 5 раз на дню...
как будет боле-менее законченый алгоритм работы устройства - тогда буду уже оптимизировать
а по 205-220 - я чтото не придумал как сюда запихать цикл с учетом изменений на некоторых итерациях
размер кода с циклом будет практически идентичен текущему (немного меньше) - но для наглядности пока разрабатываю мне было удобнее без цикла это оставить
---
а вообще у меня пока нет вопросов по моему коду - давайте не отклонятся всёже от темы ТС :)
а свой код я выложу позже с просьбой оценить и подсказать по оптимизации, когда он будет близок к релизной версии
int занимает 2 байта (char размером в 1 байт).
Большое количество дефайнов в скетче можно посмотреть здесь: http://arduino.ru/forum/proekty/transistor-tester-arduino
да по дефейнаи много статей - но на цвет... как говорится...
что будет, если гипотетически рядом с устройством взорвать атомную бомбу, которая не уничтожит его материально (сключаем температуру и ударное воздействие)
кнопку как была включена - так и останется включена
а вот программа может и словить сбой изза жесткого излучения и мощных магнитных полей - ведь всё крутится в памяти - а достаточно протону пробить ячейки - неизвестно что в ней останется при считывании - а значит и надежность ниже
И какой толк в нажатой кнопке, если программа это нажатие не сможет обработать?
P.S. (юмор) Инструкция-приказ: солдат, попавший в эпицентр ядерного взрыва, должен держать автомат на вытянутых руках, чтобы расплавленный металл не капал на казённые сапоги.
аппаратные решения всегда надежнее программных
Арифмометр и счёты возможно надёжнее, но присутствующие на данном форуме почему-то предпочитают компьютеры с программным обеспечением.
также ЗАБУДЬТЕ вы о дефайнах!! - это зло дебага!
Похоже на предупреждение ребёнку: "Не трогай нож - порежешься!"
Каждый инструмент (define в частности) требует правильного применения. При безграмотном программировании можно и с константами накуролесить.
В то время, как космические корабли бороздят просторы большого театра ....
а вот программа может и словить сбой изза жесткого излучения и мощных магнитных полей - ведь всё крутится в памяти - а достаточно протону пробить ячейки - неизвестно что в ней останется при считывании - а значит и надежность ниже
Жесткое излучение - воздействие на аппаратуру, а не на программу. И, кстати, для защитты тоже применяются аппаратные средства, а не программные.
Кстати, если бы Вы употребляли полные термины (аппаратный сбой) вместо кратких (сбой), это было бы понятно с самого начала.
Конечно было бы понятно, но так зафлудить тему бы не получилось.
Сегодня коллега попросил подсказать ему как примерно такой же код набросать.
Получилось так.
boolean LastState=0;
boolean knopka= 0;
boolean led=0;
int x=0;
unsigned long LastTime=0;
void setup(){
Serial.begin(9600);
pinMode(3,0x2);
pinMode(13,0x1);
}
void loop(){
knopka=!digitalRead(3);
if(knopka!=LastState&&knopka==1){delay(10);led=!led;x++;
LastState=knopka;
}
if(knopka!=LastState&&knopka==0){delay(10);LastState=0;}
digitalWrite(13,led);
if(digitalRead(3)==0){if(millis()-LastTime>=3000){Serial.println(x);LastTime=millis();}}
else{LastTime=millis();}
}
Включаем и выключаем диод одной кнопкой, при удерживании кнопки долее 3 секунд выводим в монитор количество нажатий.
Шото у препода фантазии никакой.