За упоминание Лема, спасибо! Приятно видеть!
Предлагаю для конструктивного обсуждения определиться:
Жизнь — это…
Интеллект — это…
Самосознание — это…
Без оспаривания определений, просто что-бы зафиксировать ( а то это тема отдельного холивара)
Я больше к самосознанию апеллирую, но с вами согласен жизнь не равно интеллект.
Но в качестве своего аргумента могу привести известное высказывание: «Я мыслю — значит существую»
в догонку вопрос, как относится к ИИ (если его создадут)? Основных признаков жизни кроме самосознания ОНО иметь не будет (как минимум не будет размножаться и иметь клеточной структуры — в классическом понимании ИИ как суперкомпьютера). Можно ли назвать живым что-либо обладающее самосознанием, но не демонстрирующее признаков жизни (генетическая информация, размножение, питание, движение, прогресс/регресс, эволюция? )?
А где в комменте про углерод хоть слово написано. Вполне можно вписать в эту концепцию и силиконовую жизнь… на базе силикатов (хоть это и невозможно на сегодняшнем уровне понимания химии — кремний не способен образовывать столь большее разнообразие соединений как углерод и менять свою валентность в зависимости от...)
если начнут двигаться и дырки, то ток будет в 2 раза (ну почти) больше… называется это электрон-дырочная проводимость. На сколько я помню это относится к полупроводникам, а ток в растворе обусловлен движением ионов… ну если назвать катионы — дырками а анионы — электронами, тогда да.
Насколько я знаю в криминалистике отпечаток анализируется по 16 (? может больше) параметрам. Эти параметры являются расстояниями между особыми точками на рисунке отпечатка, и некоторые довольно специфичные, локализованные и уникальные формы. Именно эти числовые параметры и хранятся в базе для сличения отпечатка со сканера, никто не сравнивает картинки — картинки не показательны. Грязь порезы и т.п. не могут изменить эти параметры.
По проблеме отрезанного пальца, большинство нормальных сканеров регистрируют «сердцебиение» приложенного пальца (делается это оптическим методом: «на просвет» или «на отражение» этого достаточно для различения жив/мертв, палец/макет).
Если же просто опрашивать кнопки со строго заданным интервалом
За время опроса первой кнопки, вторая перешла в состояние отжато из-за дребезга, вы прочитали отжато. А юзер пальцем ожесточенно тыкает и краснеть начинает. Что будете делать?
делаем XOR с предыдущим значением и у нас есть вся необходимая информация для решения — какой датчик изменил своё состояние и в какую сторону.
Предыдущее значение: 010010
Текущее значение:101101
Результат XOR:111111
Подскажите по результату что и в какую сторону поменялось?
Процессы протекающие в электрических цепях подчиняются не логике, а законам Киргофа и уравнениям Максвелла (хотя да они логичны)
По опыту, гараздо проще обрабатывать отдельные абсолютно независимые входы (пусть даже и 6), чем разруливать колизии матричного исполнения (да и любого другого способа расширения количества подключаемых элементов сдвиговые регистры аля 74НС595, мультиплексоры и т.п.).
И у вас есть одна неточность: комбинации в данном примере не любые. Как было выяснено ранее если датчик сработал, его повторное срабатывание произойдет через значительный промежуток времени (в бытовых условиях, обусловлено ограниченной скоростью истекания воды из труб) достаточный для обработки сигналов других датчиков.
Но да, я с вами согласен обработать массив асинхронных величин на приеме требует некоторого умения и внимания к этой проблеме. Любая подобная система будет иметь ограничение разрешающей способности на уровне нескольких периодов тактового сигнала. В данном случае это не критично, так как датчик находится в состоянии замкнуто довольно продолжительный промежуток времени (даже с учетом дребезга) и обработать его значение не составляет большого труда (ну захватится его значение не на первом периоде дребезга а на втором, третьем или когда он выйдет на стабильный уровень) ведь в данной системе не предъявляются требования к определению точного времени срабатывания, главное их не пропускать, а это проще.
Алгоритм приема этих сигналов не будет иметь особых отличий при исполнении в прерывании или основном цикле программы. Описанные проблемы будут возникать как в первом так и во втором случае и придется принимать меры к их устранению. Применение прерываний и таймеров в данной задаче позволяет высвободить время на обработку и более жесткий контроль за отсутствием пропусков. Я предпочитаю стиль программирования контроллеров такой, в котором при наличии Hardware реализации той или иной возможности я отдаю предпочтение Hardware а не программной реализации. Обычно это немного снижает гибкость но значительно повышает надежность, скорость обработки, снижает размер использованного ОЗУ и памяти программ, (Имею ввиду что использую таймеры вместо delay, блок SPI вместо его программной реализации, и т.п.) что в тематике контроллеров является более критичным.
5-10 строк включая объявление переменных и работу с таймером.
нет, ну чем хуже просто считать все входы разом и потом их обрабатывать побитно, через сдвиг в цикле? Если вдруг состояние изменится после считывания — обработано будет в следующей итерации.
А я что говорил что оно не так работает? Это и есть основная идея работы, только при срабатывании PCINTx все собирается в нужном регистре с нужными флагами и в нужное время. Куда проще в обработке и в итоге в надежности и отсутствии пропусков…
На данный момент это работает в серийном изделии, код который разруливает описанные вами проблемы не сложен. Проблем не испытываем в том числе с дребезгом.
Каждая нога обрабатывается отдельно, антидребезг на каждую ногу инициируется отдельно. Также обрабатываются комбинации ножек. Задействованы 8 ног, код писался «нативно» (без дурилок и РТОС) на С.
Уж не хотите ли вы сказать, что конструкция
for (int i=0; i<6; i++) {
boolean changed = CounterBouncer[i].update();
if ( changed ) {
int value = CounterBouncer[i].read();
// Если значение датчика стало ЗАМКНУТО
if ( value == LOW) {
//Serial.println(CounterPin[i]);
sprintf(request, "GET /input.pl?object=%s HTTP/1.0", CounterName[i]); // Формируем ссылку запроса, куда вставляем имя счетчика
sendHTTPRequest(); // Отправляем HTTP запрос
}
}
}
работает лучше, с учетом отправки НТТР запроса между проверками состояния ножек, а это как вы говорили ранее должна быть «атомарная операция». Представляете что случится если счетчики сработают через один с интервалом в 5-10 мкс?
да ладно, у меги одно прерывание? ОДНО? когда вы даташит смотрели последний раз?
Ой прерывание чуть не на каждой ножке. 6 штук уж точно найдется.И да PCINT можно отработать с точностью до 1 нс. Так как выставляться они будут асинхронно.
Для примера рассмотрите задачу обработки нажатия кнопок на клавиатуре. Я хочу видеть человека, который сможет клацать по кнопкам со скорость <100-150 мс на нажатие (это что-то около 600 символов в минуту). Помнится раньше были часы в виде пейджера, так вот мы пробовали нажать две рядом стоящие кнопки (стар таймера и сто) с максимальной скоростью. Быстрее чем 200 мс никто не смог, а если жать одну два раза — то все 500-700 мс.
Кстати по алгоритму выше легко реализуется опция постоянного инкремента при зажатой кнопкой. В одну строку.
Предлагаю для конструктивного обсуждения определиться:
Жизнь — это…
Интеллект — это…
Самосознание — это…
Без оспаривания определений, просто что-бы зафиксировать ( а то это тема отдельного холивара)
Но в качестве своего аргумента могу привести известное высказывание: «Я мыслю — значит существую»
dbe680e6d1a8b1a9d7cc9b60f83d1243
51e40f1e948b657554f878d3b6c06133
По проблеме отрезанного пальца, большинство нормальных сканеров регистрируют «сердцебиение» приложенного пальца (делается это оптическим методом: «на просвет» или «на отражение» этого достаточно для различения жив/мертв, палец/макет).
За время опроса первой кнопки, вторая перешла в состояние отжато из-за дребезга, вы прочитали отжато. А юзер пальцем ожесточенно тыкает и краснеть начинает. Что будете делать?
Предыдущее значение: 010010
Текущее значение:101101
Результат XOR:111111
Подскажите по результату что и в какую сторону поменялось?
Процессы протекающие в электрических цепях подчиняются не логике, а законам Киргофа и уравнениям Максвелла (хотя да они логичны)
И у вас есть одна неточность: комбинации в данном примере не любые. Как было выяснено ранее если датчик сработал, его повторное срабатывание произойдет через значительный промежуток времени (в бытовых условиях, обусловлено ограниченной скоростью истекания воды из труб) достаточный для обработки сигналов других датчиков.
Но да, я с вами согласен обработать массив асинхронных величин на приеме требует некоторого умения и внимания к этой проблеме. Любая подобная система будет иметь ограничение разрешающей способности на уровне нескольких периодов тактового сигнала. В данном случае это не критично, так как датчик находится в состоянии замкнуто довольно продолжительный промежуток времени (даже с учетом дребезга) и обработать его значение не составляет большого труда (ну захватится его значение не на первом периоде дребезга а на втором, третьем или когда он выйдет на стабильный уровень) ведь в данной системе не предъявляются требования к определению точного времени срабатывания, главное их не пропускать, а это проще.
Алгоритм приема этих сигналов не будет иметь особых отличий при исполнении в прерывании или основном цикле программы. Описанные проблемы будут возникать как в первом так и во втором случае и придется принимать меры к их устранению. Применение прерываний и таймеров в данной задаче позволяет высвободить время на обработку и более жесткий контроль за отсутствием пропусков. Я предпочитаю стиль программирования контроллеров такой, в котором при наличии Hardware реализации той или иной возможности я отдаю предпочтение Hardware а не программной реализации. Обычно это немного снижает гибкость но значительно повышает надежность, скорость обработки, снижает размер использованного ОЗУ и памяти программ, (Имею ввиду что использую таймеры вместо delay, блок SPI вместо его программной реализации, и т.п.) что в тематике контроллеров является более критичным.
А я что говорил что оно не так работает? Это и есть основная идея работы, только при срабатывании PCINTx все собирается в нужном регистре с нужными флагами и в нужное время. Куда проще в обработке и в итоге в надежности и отсутствии пропусков…
Каждая нога обрабатывается отдельно, антидребезг на каждую ногу инициируется отдельно. Также обрабатываются комбинации ножек. Задействованы 8 ног, код писался «нативно» (без дурилок и РТОС) на С.
Уж не хотите ли вы сказать, что конструкция
работает лучше, с учетом отправки НТТР запроса между проверками состояния ножек, а это как вы говорили ранее должна быть «атомарная операция». Представляете что случится если счетчики сработают через один с интервалом в 5-10 мкс?
Ой прерывание чуть не на каждой ножке. 6 штук уж точно найдется.И да PCINT можно отработать с точностью до 1 нс. Так как выставляться они будут асинхронно.
Кстати по алгоритму выше легко реализуется опция постоянного инкремента при зажатой кнопкой. В одну строку.