Как правильно запоминать состояние выхода?
- Войдите на сайт для отправки комментариев
Вс, 29/04/2018 - 17:03
Добрый вечер, корифеи!
Возник вопрос: как правильно обращаться с состоянием выходов (вкл/выкл) - создать переменную, переворачивать её при каждом изменении состояния и обращаться к ней когда нужно проверить состояние выхода, или читать состояние выхода через DigitalRead() по мере необходимости? Оба варианта в скетче работают как от них ожидается, но подозреваю что у каждого метода есть свои подводные камни или особенности применения.
digitalRead() экономнее по памяти и надежней по проверке состояния. Кроме того, оно может исользоваться и для чтения состояния ноги даже под спец.функцией, в частности для целей диагностики. Для развестистого скетча, хранение состояния пина в памяти ещё и требует доказательства что программное управление нигде не "обшиблось" .. тестирование - наше фсё, но .. нафига платить больше? :)
Я тоже склоняюсь к реализации через digitalRead(), но в куче скетчей вижу реализацию через переменную - вот и пытаюсь понять чем это продиктовано.
Первое и самое важное не зацикливаться на выходах и их состояниях. Если на вывод подключено реле, то запоминать надо состояние реле а не вывода. Ведь на вывод может повешен расширителеть входов(выходов) . А значит надо запоминать уже не выход Ардуины, а состояние реле повешеного на расширитель. И наконец . Где-то на другом устройстве который подключен через шину к вашему устройству. И для управления им надо посылать команды ВКЛ/ВЫКЛ/ПРОЧИТАТЬ СОСТОЯНИЕ , которые разумеется длятся очень долго. Так что лучше дублировать записью в выделенную ячейку.
Вот возьмем светодиод подключенный Ардуине. Цель его информировать о работе программы. Вот оператор или кто-то там захотел визульно определять работу устройства. Горит/не горит == работает/не работает. А потом система расширилась и надо добавить еще одно, а лучше парочку, да ладно десяток. Но на один и тот же информационный диод. Выводов мало. Железо собрано. И что? Пусть третье состояние будет мигание, а четвертое быстрое мигание. Ну можно даже перейти на импульсы. Периодический один импульс, периодический два импульса. И как вы будете считывать с вывода эти мигания. А так отвели ячейку памяти о номере передачи внешней информации и теперь уже состояние вывода не колышет вас как программиста.
В этом случае все понятно и логично использование переменной, я рассматриваю совсем примитивный случай - на выходе одно устройство и у него может быть только одно состояние - вкл или выкл...
Ну тогда цифровой автомат на два состояния. И вот именно переменая отводится на запись состояния этого автомата и сосотяниям на выводе она не привязана. Скорее состояние на выводе это дублирование состояния автомата и ничего больше. То есть вопрос заданый в теме это перепутана причина и следствие.
Да и DigitalRead,DigitalWrite введены для новичков которые вообще далеки как от МК, так и программирования.
Новичок - это как раз про меня :) Если я правильно уловил вашу мысль, то отдельно по событию (например - нажатие кнопки) вертим переменную, и отдельно пишем обработку того, что нужно сделать если переменная приняла то или иное значение?
Возьмем цифрой автомат - 2 состояние ВКЛ и ВЫКЛ enum {sOFF, sON}; byte state;//<-- переменая состояния void stand(byte s) {// функция переключения state = s; switch (state) { case sOFF /*здесь реле выключаем*/ break; case sON /*здесь реле включаем*/ break; } } void run() { if (state == sOFF &&/*условие вкл*/)stand(sON); if (state == sON &&/*условие выкл*/)stand(sOFF); }ПС: http://arduino.ru/forum/programmirovanie/klassy-arduino-po-qwone-dlya-chainikov?page=5#comment-349125
В этом случае все понятно и логично использование переменной, я рассматриваю совсем примитивный случай - на выходе одно устройство и у него может быть только одно состояние - вкл или выкл...
А в совсем примитивном случае нет никакого резона экономить оперативную память.
Вот в этом и парадокс: в сложных случаях, когда может проявиться нехватка памяти, на состояние сигнала, подаваемого на устройство, желательно отвести переменную (хотя бы бит в битовом поле), а в простых случаях, когда в качестве переменной можно использовать сам порт, память как раз экономить смысла не имеет.
Пример чуть более сложный, зато наглядный: пусть у Вас не один светодиод, а целый дисплей 128х64 пикселя, подключаемый по протоколу I2C. Если хотите организовать на нем пиксельную графику, нужно копию экрана (а это целый килобайт) хранить в оперативной памяти. Потому как прочитать пиксель с самого дисплея невозможно.
Ни в сложном ни в простом случае переменная не требуется. Чтение пина проще и быстрее чем хранить состояние в памяти. Другое дело, что это не digitalRead(), который не знаю как щас, а раньше где-то видел ещё и меняет состояние пину, вырубая управление на нем.
Пример с дисплеем неверен. С него, да нельзя ничего прочитать и в этом смысле у него нет ни digitalRead() ни аппаратных средств чтения регистра напрямую. В этом случае альтернативы хранению копии в памяти тупо не существует.
Вопрос стоял конкретно о цифровых пинах. Дублировать их состояния в памяти - НЕ ТРЕБУЕТСЯ ни при каких условиях. Ни при прямом использовании ни при расширенном. Вариант работы с пинами регистра 595 - в указанное условие опять же не входит. Его ноги не являются пинами микроконтроллера.
Возьмем цифрой автомат - 2 состояние ВКЛ и ВЫКЛ enum {sOFF, sON}; byte state; // глобал 1 лишний байт void stand(byte s) { // параметр + 1 лишний байт стека + 2 операции push/pop state = s; // избыточное копирование в глобал +1операция switch (state) { case sOFF /*здесь реле выключаем*/ break; case sON /*здесь реле включаем*/ break; } } void run() { if (state == sOFF &&/*условие вкл*/)stand(sON); // избыточная передача параметра if (state == sON &&/*условие выкл*/)stand(sOFF); // аналогично. } // Вариант БЕЗ переменной #define pinState 13 #define stateOFF LOW #define stateON HIGH #define isOFF(cond) (digitalRead(pinState)==stateOFF && (cond)) #define isON(cond) (digitalRead(pinState)==stateON && (cond)) // или заменить на сложную функцию управления чем надо, кроме пина.. #define stand(s) (digitalWrite(pinState, (s))) void run() { if ( isOFF(/*условие вкл*/) ) stand(stateON); if ( isON(/*условие выкл*/) ) stand(stateOFF); }Собственно и фсё. И читаемость кода даже не пострадала. :)
Arhat109-2, возможно, Вы грамотный исполнитель, но общие вопросы Вам явно не даются.
Вопрос конкретно о цифровых пинах контроллера был исчерпан уже в первом (кстати - Вашем) ответе.
Дальше qwone повернул разговор уже в другую сторону (а что еще делать, если изначальная тема исчерпана?) - о том, что исполнительное устройство не обязано быть подключенным к пинам контроллера, цитирую: "на вывод может повешен расширителеть входов(выходов)", " Где-то на другом устройстве который подключен через шину к вашему устройству. И для управления им надо посылать команды ВКЛ/ВЫКЛ/ПРОЧИТАТЬ СОСТОЯНИЕ". И это логично: логика управления устройством не должна зависеть от того, к чему это устройство подключено, и допускает ли оно чтение данных. Поэтому (а также потому, что первоначальный вопрос исчерпан) такое расширение темы вполне интересно и логично.
В программировании нет "общих" вопросов. Есть задача (ТЗ) его и решаем. В данном случае есть первый пост - он и есть "ограничивающие рамки" решений:
Конкретно: что делать с управляемым ВЫХОДОМ .. точка. Никаких "переменных" выходу не требуется. То что дальше поешл флуд за прочие варианты - не комментировал даже. Моя реплика относилась исключительно к вопросу ТС-а "а почему?". Только поэтому. :)
Конечно же хранение копий состояний в памяти БЫВАЕТ необходимо, но не в этом случае. :)
В программировании нет "общих" вопросов. Есть задача (ТЗ) его и решаем.
Вот об этом я и говорю: если бы не было людей, занимающихся "общими" вопросами, люди до сих пор жили бы в пещерах и поддерживали там огонь (потому как самостоятельно добывать бы его не умели).
Кто-то выполняет существующее ТЗ, кто-то его ставит, а кто-то подготавливает почву для тех ТЗ, которые будут ставиться через год, десять или сто лет. И не видеть этого, минимум, - близоруко.
PS. Если вдруг представить, что "общие вопросы" вдруг перестали существовать в момент изобретения первого компьютера, то эти компьютеры до сих пор программировали исключительно в кодах, а было бы их... в точности по прогнозу - 5-6 (штук, на весь Мир, на все времена).
При открытии темы обычно любой ТС , как правило, "не в теме" даже задаваемого вопроса. Он же не лектор , от "только спросить". Так что тема и содежание в теме отличаются.
Причина не понимания в этой теме это перепутана причина и следствие. Что важнее ? Просто выводить, или выводить и хранить в переменной. Конечно в таком случает дублировать не надо.
Но у нас не вывод а цифровой автомат. И состяние этого автомата желательно хранить все же в переменной, а не где нибудь на выводах. Ну все же технологии подрасли и у нас объемы ОЗУ меряются тысячами, а не поштучно под роспись (Словно Сталин под Москвой поштучно танки распределял.Дефицит блин страшный. Да и обязательно с возвратом в прежнем состоянии ).
Теперь почему все же в памяти, а не выводах. Да потому что так быстрее. Где чаще всего расходуется такты процессора в цифровом автомате. Правильно. Проверить состояние автомата и дальше условие перехода. Вот именно это обязательно лучше оптимирировать. Потому что Проверить состояние автомата находящего на выводе все же значительно дольше, и при многократном повторе сожрет больше ресурсов процессора. Экономить все же лучше такты процессора, если этот участок кода идет чаще всего.
ПС: Экономить можно память и на выводе на LCD если хранить вывод на экран не в пикселях, а функциях вывода на экран.
ПС: Экономить можно память и на выводе на LCD если хранить вывод на экран не в пикселях, а функциях вывода на экран.
А это как?
Пришла команда обновить экран. Выделили из кучи памяти буфер, выполнили функцию вывода на экран в буфер, отправили пакет из буфера на дисплей. Вернули буфер в кучу обратно. Вот только для каждого экрана в меню писать свои фнкции. По функции занимают флеш память,а не память ОЗУ.
Выделили из кучи памяти буфер, выполнили функцию вывода на экран в буфер, отправили пакет из буфера на дисплей.
Не понял. "функция вывода на экран в буфр" - это что? Что она делает? Что и куда выводит? На экран или в буфер?
Ну я до конца этот вопрос не проработал. Пусть есть универсальный класс Stream - вывод на поток. потом создается тип указатель на функцию выводящую на поток typedef (*pViev)(Stream s); И потом создается пакет функций void vievScreen1(Steam s){}. void vievScreen2(Steam s){} void vievScreen3(Steam s){} void vievScreen4(Steam s){} . Разумеется внутри идут строки s.print() и другие.
Осталось подключить нужную функцию на вывод и все. Понятно что там еще непривычней программировать, и главное все согласовать. Но так можно апнуть свой скил программировать.
Можно конечно через Ардуиновский класс Print , но через класс Stream идеологически вернее.
Нет, давайте все-таки на конкретные вопросы:
1. Что значит "функция вывода на экран в буфер"? (ваш пост №17)
2. Что она делает?
3. Откуда она получает информацию?
4. Куда она ее выводит?
Теперь почему все же в памяти, а не выводах. Да потому что так быстрее. Где чаще всего расходуется такты процессора в цифровом автомате. Правильно. Проверить состояние автомата и дальше условие перехода. Вот именно это обязательно лучше оптимирировать. Потому что Проверить состояние автомата находящего на выводе все же значительно дольше, и при многократном повторе сожрет больше ресурсов процессора. Экономить все же лучше такты процессора, если этот участок кода идет чаще всего.
То есть разница между этими способами (проверяем состояние переменной или проверяем состояние вывода) в скорости обработки процессором? Если необходимость проверки состояния возникает редко - то особого криминала в чтении состояния вывода нет, но если его необходимо проверять в каждом loop(), то чтение переменной более предпочтительный вариант?
P.S. Про автоматы я видел Вашу ссылку - обязательно займусь изучением, пока двигаюсь от простого к сложному и пытаюсь понять базовые вещи.
Dinosaur, НЕТ. Скорость при хранении состояния пина в памяти и работы через память СНИЖАЕТСЯ также как и РАСТЕТ расход памяти. За дурь надо платить.
Перечитайте пост #12 и сравните ОБА варианта и сделайте правильный вывод: второй вариант как жрет меньше памяти так и по тактам процессора существенно шустрее. Остальное в конкретно вашем случае (цифровой пин) только флуд не имеющий никакого отношения к вашему вопросу.
Вот для ИНЫХ задач, оно да, может иметь смысл, но только для иных, о чем Вам тут и оправдываются их авторы. Кому-то НРАВИТСЯ решать задачу в общем виде, и пофиг, что для конкретно этой задачи решение не оптимально. Кто-то ПРИВЫК всё хранить в памяти, перейдя с "больших ЭВМ", где её много а управления как такового нет и им оно не доступно, да и нет ничего кроме ячеек памяти (задачи моделирования и ввод-вывод отображенный на память), кому-то просто НРАВИТСЯ решать все через классы и виртуальные функции, а в случае синдрома "обобщения" (это да - бывает такая болезнь у программистов) ещё и через темплейты .. на вкус и цвет у каждого свои карандаши.
Правильный ответ на Ваш вопрос дан в #1 с примером в #12. Далее можно только посоветовать посмотреть код digitalRead() на предмет его прямости работы с пином. Нельзя чтобы он авто- переводил пин из режима в режим как и digitalWrite(). Если это условие не выполняется, то digitalRead() надо заменить прямым чтением пинов через макросы io.h.
Архитектура пина (см. даташит, там есть его функциональная схема) такова, что специально заточена именно под такое решение задачи. Все остальное - по безграмотности или по болезни и только. :)
Вы путаете наличие и решения "общих вопросов" - теоретическая наука и создание "обощенных алгоритмов" (программ) на все случаи жизни. Так вот второе - неверно. Жизнь разнообразнее, занимательней и ширее чем Вы можете придумать даже в самом обобщенном полете своей фантазии.
Любая программа (и вопрос ТС из этой части) решает вполне конкретную задачу (ТЗ) или конкретный класс, набор классов задач (широта постановки ТЗ опять же). И ТОЛЬКО. Все остальное - есть деятельность ради деятельности без конечной цели достижения положительного результата т.е. ФЛУД.
Он и в виде алгоритмов присутствует в программах дофига где. И больше того, чем дальше тем агрессивнее отстаивают этот алго-флуд его безграмотные авторы, что уже давно не удивляет ни разу:
"Когда-то корабли были деревянные, зато люди - железные. Теперь корабли железные, а люди .. картонные". (с) Кемпбел, капитан "Катти Сарк", который с командой в 20-26, 13-14 летних пацанов штормовал на 15-и метровых волнах в проливе Маггелана не раз, имея мачты высотой 57 метров.
перефразирую: "Когда-то приходилось решать задачи в автокодах и учитывать все нюансы работы компьютера. Компы были мелкие и слабы, зато люди - гиганты. Теперь есть оптимизирующие компиляторы, авто-простроители алгоритмов по диаграммам состояний, мелкие процессоры с безразмерной памятью .. зато люди тупеют пропорционально".
Arhat109-2. То что жизнь разнообразнее это факт. Но если надо сделать эффективнее производство приходят к разделению на операции и конвееру. То есть к ограничению этого разнообразия. Опять же навязывание решать такие задачи через автомат это диктат над творчеством программиста. Тем более о ужас, записывать это состояние в память, потому что хранить это состояние на выводе экономит память.
Если мы говорим о разнообразии, то блин учебная школа это диктат взрослых на детьми, они блин суки не дают разнообразно развиваться детям в разных направлениях жизни. Но в итоге дети развиваются в сторону глупости. Ну да глупость это природа, и ее надо развивать. Но если конкретно. Если Вы хотите лучшего развития, то надо уметь себя ограничивать от всего разнообразия жизни, потому что развиваться в разных направлениях не даст конкретно достичь конкретных дальних целей.
Вот для этого и существует "общий вопрос". Он 1- отделяет себя от другого "общего" вопроса,или вопроса "конкретно" и наконец вопроса "не о чем". 2 - дает конкретное оптимальное решение, объсняя что другие решения тоже ничего но все же похуже и чем . 3- экономит время тем кто идет по следам. Учебник это и есть книга где описываются общие вопросы и их решения. А не муть о разнообразии жизни и надо учится у жизни, а не на основе накопленого кем-то опыта.
Почитайте что такое система реального времени. Так в ней всегда и регуляно надо проверять свое состояние и состояние среды и соответсвенно реагировать на это. А если не будете это регуляно делать, то будете запаздывать или тормозить. Если вы наблюдали устройство которые тормозили, то это потому что они не регулярно не проверяют состояние. Почему боряться против долгих delay() в программе. Потому что устройство в delay() выпадает из жизни.
То есть разница между этими способами (проверяем состояние переменной или проверяем состояние вывода) в скорости обработки процессором? Если необходимость проверки состояния возникает редко - то особого криминала в чтении состояния вывода нет, но если его необходимо проверять в каждом loop(), то чтение переменной более предпочтительный вариант?
Нет, вам пытаются объяснить, что в генерализованном решении нельзя понять, что однозначно выгоднее и это, скорее, вопрос привычки и веры. В каком-то конкретном, где необходимо выбирать между экономией памяти или тиков процессора, уже и начинается реализация какой-то стратегии.
Кому-то НРАВИТСЯ решать задачу в общем виде, и пофиг, что для конкретно этой задачи решение не оптимально.
Прежде, чем рассуждать об оптимальности, следовало бы озвучить ее критерии.
Рассмотрим такой случай: есть одна задача и два программиста, которые взялись за ее решение.
Первый программист затратил на решение задачи 2 месяца и добился того, что контроллер тратит на решение задачи 0.3% своих ресурсов.
Второй - работал 2 недели и написал программу, которая вдесятеро прожорливее программы, написанной первым программистом - здесь контроллер на решение той же задачи тратит 3% ресурсов.
Внешне поведение программ идентично (т.е. "снаружи" заметить между ними разницу невозможно), хотя внутри у одной контроллер простаивает 99.7% процентов времени, а у другой - 97%.
Спрашивается, в каком случае задача решена оптимальнее?
Спрашивается, в каком случае задача решена оптимальнее?
С точки зрения программиста - в первом. Он дольше получал зарплату ))
То есть разница между этими способами (проверяем состояние переменной или проверяем состояние вывода) в скорости обработки процессором? Если необходимость проверки состояния возникает редко - то особого криминала в чтении состояния вывода нет, но если его необходимо проверять в каждом loop(), то чтение переменной более предпочтительный вариант?
Dinosaur, Вы позиционируете себя как новичка, но при этом ставите интересные вопросы.
А их "интересность" связана в первую очередь с тем, что на них не существует однозначно7го правильного ответа.
И даже здесь можно выделить, минимум два аспекта:
1. О чем вообще идет речь.
Существует концепция Ардуино, которая подразумевает использование различных контроллеров через унифицированный интерфейс (а унификация здесьт может быть реализована исключительно с ущербом для производительности).
Среди используемых контроллеров часще всего встречаются контроллеры AVR, поэтому некоторые участники форума пишут "Ардуино", а продразумевают "AVR".
Так вот, для некоторых из Ваших вопросов варианты "Ардуино" и "AVR" дают диаметрально противоположные подходы к решению.
2. Случаи бывают разные.
В частности, бывают задачи ресурсоемкие, когда крайне желательно впихнуть задачу в наиболее компактный контроллер их тех, что может с ней справиться. И тогда во главу угла ставится эффективность кода.
А в большинстве случаев, наоборот, - программа нетребовательна к ресурсам и тогда в первую очередь интересна скорость разработки программы.
Т.е. не существует какой-то универсальной "эффективности", а в разных случаях под эффективностью разумно подразумевать совершанно разные подходы.
Но как вы думаете, кто напишет быстрее. Человек который к каждой задаче подходит творчески , или человек который ранее изучил этот общий вопрос и для которого написание программы это ... формальнось. Тем более надо изучать не только как писать автоматы , а и как совмещать код различных автоматов в одном МК.
Мы сейчас обсуждаем не квалификацию (или иные качества) программиста, а подход к задаче.
С моей точки зрения переход, скажем, от 4 линий управления к 40 быстрее выполнит тот, у кого изначально логика программы не была завязана на способ упрвления пинами.
andriano, qwone: Вы как раз занялись словоблудием в виде обсуждения сферических коней в вакууме и сопоставления какой из них лучше, а также как раз обсуждением квалификации программистов вместо ответа на конректный вопрос.
Не участвую. Без комментариев. Продолжайте флудить, запасся попкорном.
Ещё раз: перечитайте вопрос стартового поста и посмотрите насколько вдаль вы от него оторвались. :)
Скорость при хранении состояния пина в памяти и работы через память СНИЖАЕТСЯ также как и РАСТЕТ расход памяти.
Вы это проверяли? Не могу поверить, чтобы работа с внутреннеми переменными занимала больше времени, чем вызов функции, которая проверяет физическое состояние пина.
Проверить состояние пина в большинстве случаев это 1-2 команды процессора. Работа с глобалом это его загрузка в регистр (2 команды) + сравнение в лучшем случае, а то и выгрузка взад (+2 команды). Работа с глобало-параметром передаваемым в функции состояний это плюсом ещё загрузка-выгрузка параметра в стек. Работа внутри функции с глобало-локалом ещё плюсом .. и т.д. Как ни крути а 1 команда проца - всяко лучше. Да, и забудьте про "ардуркино" библиотеки. Они в последнее время стали значительно лучше но не настолько чтобы ими пользоваться. Это всего лишь ПРИМЕРЫ для ОБУЧЕНИЯ. и только. (*хотя находятся идиоты, что их пользуют на "режимных предприятиях" даже *)
:)
Да, и забудьте про "ардуркино" библиотеки.
Если так, то не знаю, но со стандартными функциями digitalRead, digitalWrite ваша теория не подтверждается. Использовать переменную немного быстрее.
Вы это проверяли? Не могу поверить, чтобы работа с внутреннеми переменными занимала больше времени, чем вызов функции, которая проверяет физическое состояние пина.
Если уж сравнивать, то сравнивать - сравнимое.
Почему Вы ничего не пишете о вызове функции для проверки внутренних переменных, но считаете, что состояние регистра нужно проверять именно функцией?
Что касасется AVR, то регистры и память расположены в общем адресном пространстве и работа с ними абсолютно идентична работе с памятью. Зато если мы работаем с памятью... то это никак не освобождает нас от обязанности писать нужное значение в регистр, т.е. в регистр - писать и так, и так (иначе на пинах ничего не изменится), а в память - писать дополнительно. Надеюсь, у Вас не возникает сомнений, что любая дополнительная работа занимает дополнительное время? Или Вы в это тоже не можете поверить?
PS. А вообще - чтобы спорить, нужно хоть что-то знать. Иначе доводы получаются просто анекдотичными. А в данном конкретном случае очень много тонких мест, которые обильно снабжают нас доводами как "за", так и "против".
Так что работа с переменной все же быстрее. Мне что выдержку из кода сюда выложить.
Выкладывайте.
Надеюсь, в процессе выкладывания Вы поймете, что запись_в_регистр + запись_в_память никак не может быть быстрее, чем только запись_в_регистр.
Почему Вы ничего не пишете о вызове функции для проверки внутренних переменных, но считаете, что состояние регистра нужно проверять именно функцией?
Потому что для проверки переменной не нужна функция, а digitalRead является штатной функцией для проверки пина.
Надеюсь, у Вас не возникает сомнений, что любая дополнительная работа занимает дополнительное время? Или Вы в это тоже не можете поверить?
Зачем мне верить? Я проверил: с переменной немного быстрей.
Потому что для проверки переменной не нужна функция, а digitalRead является штатной функцией для проверки пина.
"В огороде бузина, а в Киеве - дядька". Вы опять сравниваете несравнимое.
1. Для проверки переменной функция также не нужна.
2. Какое вообще имеет отношение наличие "штатной функции" к вопросу о том, что быстрее? А если бы "штатной функции" вообще не было бы, Ваш вывод был бы иным?
Надеюсь, у Вас не возникает сомнений, что любая дополнительная работа занимает дополнительное время? Или Вы в это тоже не можете поверить?
Зачем мне верить? Я проверил: с переменной немного быстрей.
Значит, неправильно проверяли (проверять - тоже надо уметь). И, кроме того, Вы явно не в ладах с математикой:
если "a > 0", то "a+b < b" никак не может быть верным (разумеется, для скаляров).
Это действие в происходит по моему способу реже.
Как это реже-чаще может зависеть от способа? Если в моей задаче состояние пина вообще читать не надо, все равно запись реже чтения?
Тут в лучшем случае - статистика.
А вот чтение из переменной все же быстрее чем из пина. На этом и выигрыш.
Для AVR чтение из пина и из переменной идентичны. Откуда выигрыш?
int digitalRead(uint8_t pin) { uint8_t timer = digitalPinToTimer(pin); uint8_t bit = digitalPinToBitMask(pin); uint8_t port = digitalPinToPort(pin); if (port == NOT_A_PIN) return LOW; // If the pin that support PWM output, we need to turn it off // before getting a digital reading. if (timer != NOT_ON_TIMER) turnOffPWM(timer); if (*portInputRegister(port) & bit) return HIGH; return LOW; }Вот и набежало из универсальности среды.
1. Для проверки переменной функция также не нужна.
2. Какое вообще имеет отношение наличие "штатной функции" к вопросу о том, что быстрее? А если бы "штатной функции" вообще не было бы, Ваш вывод был бы иным?
1. Что значит "также"? Я и говорю: для работы с переменной не нужна функция.
2. Ести бы, то не было бы предмета для разговора. Первоначально вопрос поставлен в рамках программирования arduino: использовать digitalRead, или переменную. Ясное дело, что оба решения хуже идеального, ну и что? При чем тут идеальное решение, и как его можно отнести к первому, или второму способу, если оно вообще другое?
Значит, неправильно проверяли (проверять - тоже надо уметь).
Элементарно проверял: 100000 раз меняем состояние пина.
С глобальной переменной:
Примерно 4100ms.
Теперь "оптимизируем" код:
И получаем 4300ms.
И, кроме того, Вы явно не в ладах с математикой:
если "a > 0", то "a+b < b" никак не может быть верным (разумеется, для скаляров).
А это еще зачем?
Какое отношение универсальность среды имеет времени чтения из порта?
Кстати, в какаой именно строке приведенного Вами исходника происходит чтение из порта?
Элементарно проверял: 100000 раз меняем состояние пина.
С глобальной переменной:
Примерно 4100ms.
Теперь "оптимизируем" код:
И получаем 4300ms.
У Вас каждый из приведенных фрагментов выполняется больше 40 мкс?
Вы явно что-то не то делаете. Завтра проверю, приведу результаты (точнее, не завтра, а сегодня вечером).
Какое отношение универсальность среды имеет времени чтения из порта?
Не знаю, возможно, никакого. Также как и марка автомобиля не влияет на удельное тепловыделение бензина, и на законы физики. Отсюда, вывод: все автомобили одинаковы, а их конструктивные отличия "не считаются", т.к. не затрагивают фундаментальных законов. Мы о чем говорили? О конкретных вариантах написания программы, или о законах электроники?
Кстати, в какаой именно строке приведенного Вами исходника происходит чтение из порта?
В единственной строке второго варианта:
Подписался
Нет. Чтение из переменной дольше чем чтение из пина. Чтение пина = обращеню к внутреннему регистру и составляет 1 такт. Чтение из переменной как миниум 2 такта - это только загрузка в регистр. Модификация состояния переменной - только внутри регистра и далее снова запись взад за 2 такта.
И это самый простой случай "глобальной переменной". Простой. Если мы имеем дело с элементом массива или ещё веселее - элементом структуры, выделенной динамически (объектом класса), то там все кучерявее примерно в 5-10 раз.
Память - крайне медленный и дорогой ресурс на риск-камнях. Любых.
У Вас каждый из приведенных фрагментов выполняется больше 40 мкс?
Вы явно что-то не то делаете.
Да, было чуток лишнего, но отличия были только в приведенных строках. Уберем лишнее, и отличия времени выполнения обозначаются еще более выпукло. Количество повторений увеличиваем до миллиона.
Вариант с переменной:
#define PIN 12 byte state = 0; // Можно объявить локально, но мы специально делаем неоптимально void setup() { pinMode(PIN, OUTPUT); Serial.begin(9600); for (long i=0; i<1000000; i++) { state = !state; digitalWrite(PIN, state); } Serial.println(millis()); } void loop() { }Результат: 3584ms.
Вариант с чтением пина:
#define PIN 12 void setup() { pinMode(PIN, OUTPUT); Serial.begin(9600); for (long i=0; i<1000000; i++) { digitalWrite(PIN, !digitalRead(PIN)); } Serial.println(millis()); } void loop() { }Результат: 5658ms.