Мало того, что данный подход требует синхронизации датчиков, так он еще будет конфликтовать с парадигмой мультизадачности. С точки зрения мультизадачности, опрос датчика, показания которого принимают только значения 0/1 не нужен, так как достаточно обработать прерывание по переднему или заднему фронту. То же самое относится и датчику, передающему информацию путем длительности одного или нескольких импульсов. А уж по прерыванию, раз мы получаем его от порта, а не от пина, у нас нет иного варианта, кроме как считывать весь порт и проверять все пины, для которых разрешено прерывание.
Я вообще-то уже описывал свой подход выше. По прерыванию фиксируем передний и/или задний фронт на порту. Для каждого пина, состояние которого изменилось, формируем сообщение с маркером времени в кольцевом буфере сообщений. При необходимости, можно иметь два кольцевых буфера - высокоприоритетный и низкоприоритетный. То бишь:ARV писал(а):но хочется ознакомиться с иными подходами и мнениями
4. Опрос датчиков не производится. События от датчиков фиксируются по прерыванию, и обрабатываются фоновым процессом в порядке их поступления (FIFO).
Отдельная история с устранением дребезга. С одной стороны, минимальное устранение дребезга при обработке по прерыванию уже есть, так как сначала смена уровня вызывает прерывание, а потом в прерывании мы повторно считываем уровень, для того, чтобы понять, на каких пинах прерывание возникло. С другой стороны, логика устранения дребезга может потребовать дополнительных чтений из порта.
Тут я вижу два пути решения:
1. Устранять дребезг аппаратным путем, благо NE555 стоит очень дешево (от 1 рубля).
2. В прерывании по таймеру предусмотреть вызов обработчика прерывания порта (можно и отдельной функцией оформить) при необходимости повторного чтения данных с порта.
так же дополнительно потребуется 72 байта промежуточного буфера для приема всех битов... ну и потом разбирательства с этими байтами, конвертирование их в нормальные байты SCRATCHPAD-данных датчика, вычисление CRC и т.п. обработка.
