коллеги, давайте, наконец, напишем что-нибудь. )

[RXL]

http://lib.chipdip.ru/299/DOC000299269.pdf
Присмотрел IRLML6344. Низкое напряжение открытия. Очень малое сопротивление канала. Формат SOT-23 - для домашней сборки оптимум габаритов.
Довольно мощный транзистор - подойдет и на низкоточную и на силовую схему.

[Dale]

Посмотрел его данные. У него при напряжениях от 0.5 до 1.1 V ток стока 10 микроампер. То есть производитель считает, что при таком токе уже нельзя считать его полноценно запертым.

Низкое сопротивление у него нормируется начиная с 2.5 V на затворе, в самой первой таблице. А ток в 5 ампер обеспечивает и вовсе при 10 вольтах на затворе (третья таблица). На Fig. 3 хорошо видна отсечка примерно при 1.3 V, там передаточная кривая становится почти вертикальной.

Типичный представитель семейства транзисторов от International Rectifier для раскачки затвора от уровней ТТЛ, без дополнительных драйверов. Вольта им маловато для открытия (хотя и многовато для полноценного закрытия). Так, ни то ни се.

Я потому и заинтересовался так: думал, вдруг какие-то принципиально новые низковольтные МОП-транзисторы появились, а я их проворонил

P.S. Он, оказывается, еще и бессвинцовый, модный. За это сейчас дерут дополнительные деньги.

[RXL]

Надо по их каталогу порыться, посмотреть, что еще есть.
В принципе, 1 В - это много меньше, чем 3 В

Близкий к нему P-канальный - IRLML6402.

Я как-то раньше без полевиков жил и не тужил, а вот свяжешься с низковольтными (на мой взгляд это все ниже 4-х вольт) и мало потребляющими схемами и уже от полевиков никуда не денешься - у них и экономичность и меньше падение напряжения в канале, чем у насыщенного биполярного.


Добавлено через 3 минуты и 36 секунд:
В общем, понимаю, что цепочка из стабилитрона и полевика не катит. Наверно в данной роли все же биполярный лучше будет, только тут надо нагрузку на коллекторе рассчитывать - будет ли на 100 кОм работать...

Добавлено через 3 минуты и 29 секунд:
Транзистор я на глаз выбирал - из того, что попалось в поиске. Если взять на меньшее рабочее напряжение, там чувствительность в диапазоне 1В выше. Например, IRLML6244 (N) и IRLML6201 (P).

[Dale]

Насыщенные биполярные транзисторы не так уж страшны - напряжение порядка 0.4 вольт, при токе 2-3 ампера многие транзисторы обойдутся символическим радиатором или вовсе обойдутся без него.

100 кОм для нагрузки, конечно, многовато. При 5 вольтах ток получается 50 микроампер - на уровне утечки. Надо хотя бы на порядок поменьше.

[x77]

парни, а спутники на орбиту выводить это фиговина сможет? )

дверь открывается ключом. и закрывается ключом. это - ключевой момент. за что я и люблю электромеханику. остальное - это  баловство. и будет там напряжение, не будет, обрыв там цепи, не обрыв - это пофигу, собственно. давайте ограничимся минимально рабочим прототипом. соберем его на столе, подключим к компу, накидаем софт. и поглядим, как это все  живет. закладываться на отказоустойчивость сейчас смысла нет, ибо что бы не случилось - есть обычный механический ключ.

далее, готовый комплект дверного СКУДа стоит где-то в районе 5-6 тысяч, и включает в себя все. что я нарисовал на первой схеме. из этого считыватель, замок, БП - стоят минимум по косарю. БП даже подороже. т.е. на развлечения с контроллером можно потратить максимум 2 штуки, иначе все это проще тупо купить. поэтому давайте прикидывать по минимуму, без фанатизма.

[RXL]

Сможет, но не сразу. Сперва надо гигиенический сертификат получить.

БП, если иметь в виду не мою схему, а готовое изделие, стоит 66 рублей: http://www.proelectro.ru/prices/row_672191


Добавлено через 5 часов, 22 минуты и 58 секунд:
Multisim оказался давно знакомым Electronic Workbench. Даже глюки интерфейса сохранены и изредка симуляция сбоит (в старом - версии 2 или около - сбоило очень часто).

Проверил схему: работает (я заменил первый транзистор на NPN). Но с диодами Шотки действительно все на порядок проще оказалось и, что интересно, просадка напряжения примерно такая же. Зато переходные процессы более ровные (с характеристикой заряда конденсатора).
Например, по даташиту диод BAT60A в диапазоне 50..250 мА имеет просадку 0.18..0.25 В, что вполне приемлемо.

[Dale]

с диодами Шотки действительно все на порядок проще оказалось и, что интересно, просадка напряжения примерно такая же.

Принцип KISS редко подводит. Главное - обеспечить, чтобы напряжение от сетевого блока питания было гарантированно немного выше, чем от батареи.

Переходные процессы должны быть близки к идеальным, ведь у барьера Шоттки хорошее быстродействие, выше, чем у p-n перехода. Я когда работал с высокими частотами, мы использовали только барьеры Шоттки на арсениде галлия.

[RXL]

БП, думаю, можно сделать на тех же 7805 - сетевой ток экономить незачем. При перепаде в 7-10 В в качестве радиатора будет достаточно медной площадки на плате площадью примерно 10 кв. см.

Добавлено через 1 день, 9 часов, 48 минут и 16 секунд:
Виртуально поэкспериментировал, почитал доки, инет. Думаю, что оптимальным для наших целей будет ATmega644P или PA.
Критерий выбора:

1. Питание в диапазоне 1.8..5.5 В.
2. Поддержка дополнительного "часового" кварца 32768 Гц для реализации RTC.
3. Режимы "пикопотребления" (в специальных спящих режимах потребление на уровне от 0.5 мкА до единиц мкА) для хранения настроек и работы RTC на время отсутствия сетевого питания.
4. Компаратор и АЦП для контроля за питанием, зарядом батареи и различной диагностики (по идее Очкарика).
5. RAM 2 кБ (если использовать сетевые протоколы, то памяти лучше иметь с запасом).
6. UART (кажется их там даже два) для сети на RS485.
7. Умеренное количество контактов (проще разводка платы).

Может и еще какие критерии будут - пока не припомню.


Добавлено через 16 минут и 14 секунд:
Почитал доки на протоколы для СКУД. Еще раз пересмотрел свое мнение.

Варианты сетевого интерфейса:
1. CAN;
2. RS232 (точка-точка);
3. RS485;
4. I2C (TTL или с драйвером RS485).

Варианты протоколов:
1. Нечто свое нестандартное;
2. CAN;
3. MODBUS;
4. I2C.
5. Что-то еще.

Вариант I2C по RS485 мне по прежнему интереснее, но более разумным видится использование RS485 и MODBUS, т.к. это один из наиболее распространенных стандартов для включения в сеть различных датчиков и СКУД-устройств. Недостаток данного выбора: работа только в режиме мастер/слейв (инициация запроса только мастером), в одном сегменте сети может быть только один мастер (нет системы контроля коллизий), жесткая адресация (длина 8 бит, раздаются заранее и мастер должен знать адреса всех датчиков). Плюс: протокол старый (70-е годы), простой и тупой (читай — однозначный и универсальный). Софта поддержки под него написано много, включая различные SDK, компоненты (а том числе для Delphi/BCB) и готовые библиотеки для ряда микроконтроллеров. Добавлю еще, что MODBUS работает также поверх TCP (вот тут мультимастер допустим) и допускает ветвление сети с использованием сегментов TCP/RS232/RS485 шлюзов между ними.

[Dale]

3. Режимы "пикопотребления" (в специальных спящих режимах потребление на уровне от 0.5 мкА до единиц мкА) для хранения настроек и работы RTC на время отсутствия сетевого питания.

Настройки можно еще хранить в EEPROM. А если добавить микросхему RTC с литиевой батарейкой, с пикопотреблениями вообще можно будет не заморачиваться.

5. RAM 2 кБ (если использовать сетевые протоколы, то памяти лучше иметь с запасом).

4К.

Может и еще какие критерии будут - пока не припомню.

Низкая цена. Не знаю, почем сейчас 644, но 1284 я полгода назад брал по 168 рублей (128К программной памяти, 16К ОЗУ).

[RXL]

Кратко о MODBUS.

Основная задача протокола — считывание и запись данных мастером со слейвов, как правило, в режиме циклического опроса.
Данные никак не специфицируются и их интерпретацией должен заниматься прикладной софт на мастере (или за мастером).
Все данные на слейве адресуемые (16 бит адреса для каждого типа данных).

Типы данных:
* Одиночный бит или битовые поля только для чтения.
* Одиночный бит или битовые поля с возможностью чтения и записи.
* 16-битные регистры только для чтения.
* 16-битные регистры с возможностью чтения и записи.
* Файлы и записи (1 байт - номер файла, 16 бит - номер записи, по 16 бит на запись).

Есть еще очередь регистров, но это не отдельное адресное пространство.

Имеет контроль целостности: биты четности в каждом байте (это обеспечивается на уровне UART) и контрольное число в конце пакета (CRC16 или LRC).
Размер пакета - до 256 байт. Это позволяет пересылать за раз до 2000 значений битового поля, до 125 16-битных регистров и сколько влезет в пакет записей из файлов (не более 123 записей или 246 байт).

Байты одного пакета имеют только один объединяющий признак — пауза между пересылкой байтов не превышает 1.5 символа (10..12 бит на символ: старт, данные, опционально четность, 1 или 2 стоповых бита). Задержка более 1.5 символов требует признать пакет испорченным. Пакеты разделяются паузой не менее 3.5 символов. Это не очень удобно, но реализуемо.

Имеется простая и удобная система ошибок. Любая функция может быть не реализована — достаточно на запрос выдать код ошибки 1. Аналогично контролируются адреса бит, регистров, файлов и записей.

Нам от протокола нужно лишь возможность прочесть несколько регистров и бит и аналогично записать. Данный протокол это реализует в полной мере.


Добавлено через 9 минут и 47 секунд:
Внешний RTC ничем не лучше встроенного. Тот же кварц, та же батарея (и к ней контроллер зарядки) и необходимость организовывать шину обмена. Читал даташиты. Там либо параллельная шина, либо последовательная (какая-то странная: похожа на SPI, но линия данных двунаправленная).

Склоняюсь к RTC на базе м/к. Контроллер в режиме малого потребления может протянуть несколько месяцев, а может быть и год, если только саморазряд LiPo не окажется выше потребностей м/к.

Плюс данного варианта: мы по прежнему можем регистрировать и накапливать события типа срабатывания датчика двери.

Цена в инете в розницу на 644PA в районе 160-170 руб.


Добавлено через 38 минут и 38 секунд:
Итак, ТЗ от простого потребителя: хочу замок с ключом, но чтобы его можно было открыть кнопкой изнутри или карточкой снаружи, чтобы можно было через комп мониторить и кликнув мышкой открыть дверь, чтобы карточки прописывать и удалять через считыватель или через комп.

Игорь, я точно описал?

[Dale]

последовательная (какая-то странная: похожа на SPI, но линия данных двунаправленная).

Не это? http://ru.wikipedia.org/wiki/1-Wire

[RXL]

Не, не оно. Эту бы я узнал сразу
Там две TTL линии - данные и синхра, но не I2C.
Дома пороюсь в истории браузера - покажу даташит, если интересно. Помню, что маркировка начиналась на DS - Dallas.

Да, бог с ней, с экзотикой...
Наугад те же DS: DS1307, I2C, батарея LIon 3V, 8 пинов.

Backup Supply Input for Any Standard 3V Lithium Cell or Other Energy Source. Battery voltage must be held between the minimum and maximum limits for proper operation. Diodes in series between the battery and the VBAT pin may prevent proper operation. If a backup supply is not required, VBAT must be grounded. The nominal power-fail trip point (VPF) voltage at which access to the RTC and user RAM is denied is set by the internal circuitry as 1.25 x VBAT nominal. A lithium battery with 48mAh or greater will back up the DS1307 for more than 10 years in the absence of power at +25°C.

Не верю! Батареи быстрее из строя выходят, чем они тут написали время хранения.


Добавлено через 27 минут и 34 секунды:

5. RAM 2 кБ (если использовать сетевые протоколы, то памяти лучше иметь с запасом).

4К.

Моя ошибка - запутался. Чипов много, параметров тоже и таблица у них организована неудобно - пока профильтруешь все, непременно запутаешься.

В принципе, т.к. передача полудуплексная и каждый запрос требует ответа, то достаточно буфера на один кадр - 256 байт. Ну и на прочее, думаю, не много памяти уйдет. Излишек пойдет на хранение лога непрочитанных событий.

[Dale]

2К - это объем EEPROM. Тоже, кстати, полезная вещь - гарантированно допускает 100.000 циклов записи, лучше настройки хранить в ней, не полагаясь на батарейки. Компактный лог можно писать в нее же.

Для более подробного лога можно присобачить карточку SD - громадный объем при копеечной цене, и работать с ними достаточно просто.

[RXL]

Про лог.
Я прикинул, что если хранить в несжатом виде (время в BCD), то выходит 10 байт на запись типа

Код: (C)

struct event_record { // 10 bytes
    uint8_t year;
    uint8_t mon;
    uint8_t mday;
    uint8_t hour;
    uint8_t min;
    uint8_t sec;
    uint8_t event;
    uint8_t cardnr[3];
};

Если упаковать в unix timestamp, то получится 8 байт:

Код: (C)

struct event_record { // 8 bytes
    uint32_t timestamp;
    uint8_t event;
    uint8_t cardnr[3];
};

Еще можно упакованные биты использовать: потребуется 33 бита на BCD дату-время и 7 бит оставить для события - те же 8 байт.
Еще можно переменную длину записи иметь - ведь поле cardnr не в каждом событии нужно. Возможно еще на чем-то можно выиграть, если очень нужно. Но и 2 кБ EEPROM вполне достаточно для первых двух вариантов: если использовать данную память только для лога, это 204 или 256 записей при 10 и 8 байт на каждую. Если это квартирный замок, то на месяц его точно хватит, а то и на пол года. Когда место кончится можно перезаписывать старые события: если их так долго не считывали, то быстрее всего они были не нужны. Для неквартирного применения (да и квартирного тоже) у нас есть MODBUS, через которую управляющий контроллер или комп должны регулярно забирать наш лог.

SD - хорошая идея, но пусть сперва заказчик захочет такой наворот.
Вот на центральный контроллер, собирающий данные со всяких датчиков и прочих замков - милое дело.
Еще SD хорошо в плане базовых настроек контроллера типа скорости и четности порта, адреса контроллера, чтобы offline настроить и не связываться с дефолтовыми значениями.

[x77]

Итак, ТЗ от простого потребителя: хочу замок с ключом, но чтобы его можно было открыть кнопкой изнутри или карточкой снаружи, чтобы можно было через комп мониторить и кликнув мышкой открыть дверь, чтобы карточки прописывать и удалять через считыватель или через комп.

Игорь, я точно описал?

да. + геркон на дверь, но это мелочи.

структура события должна включать тип устройства (геркон, кнопка, замок, считыватель).

[Dale]

Кстати, вот еще:

6. UART (кажется их там даже два) для сети на RS485.

UART довольно легко приспособить для вывода сообщений Unity, а это дает возможность использовать TDD для разработки даже на самом нижнем уровне взаимодействия с железом. Я для этого на стендовом компьютере даже специально установил плату с COM-портом.

[RXL]

Результаты тестов выводит? А формат какой? Такой же текст, как в твоих статьях?


Игорь, заметано.

[Dale]

Результаты тестов выводит?

Да. Unity весь вывод делает через единственную функцию типа putchar() или что-то вроде. Если ее переопределить для вывода на UART, можно гонять модульные тесты прямо на МК.

А формат какой? Такой же текст, как в твоих статьях?

Один к одному.

Один UART можно пустить на связь, другой использовать как отладочно-тестовый ввод/вывод.

[RXL]

Однако! До чего техника дошла...

[Dale]

Парни из Atomic Objects пошли еще дальше.

У них есть стенд из PC с подключенным по USB лабораторным модулем, в котором есть цифровые и аналоговые порты, генераторы и прочие управляемые компьютером приборы. Этот стенд цепляется на разрабатываемую плату.

Нажатием одной кнопки запускается цикл тестирования. Сначала поочередно в МК грузятся и выполняются модульные тесты (если памяти мало, один большой тест не влазит, и его дробят на отдельные логические части). Результат идет через UART на персоналку, которая анализирует поток на последнюю строку, в которой бывает только PASS или FAIL. Персоналка заносит результат в общий протокол испытаний.

Если все модульные тесты прошли, наступает черед функциональных. Персоналка через стенд имитирует внешние события и оценивает правильность реакции на них.

Ну и в итоге запускается общий системный тест, где весь девайс имитирует бурную деятельность.

Допустим, в конце рабочего дня эта мутотень запускается по расписанию, а на следующее утро готов полный перечень обнаруженых дефектов и недоделок. И так каждый день.


Перенес флуд из темы сюда: https://forum.shelek.ru/index.php/topic,9854.msg265627.html#msg265627
Фотографию тоже, чтобы не отделять от обсуждения блондинки.

Добавлено через 4 часа, 22 минуты и 7 секунд:
У меня на подходе статья по TDD для встроенных систем. Мне кажется, будет интереснее предыдущих. Предлагаю вернуться к вопросу сразу после ее публикации, поскольку она непосредственно относится к теме.

Добавлено через 1 день, 21 час, 46 минут и 38 секунд:
Вот, кстати, еще в копилку проекта:

http://readyset.tigris.org/nonav/templates/index.html
http://readyset.tigris.org/nonav/templates/proposal.html

Все забывал запостить. Уж очень мне этот ReadySET нравится, логичная штуковина. А то мы уже в характеристики транзисторов углубились, оставив позади большие белые пятна.

[RXL]

Честно говоря, не представляю, как можно разрабатывать программную часть, не зная, с каким железом придется работать. Конечно, детально описывать ее на первых порах не обязательно. Впрочем, это все мои привычки - не знаю, как это в серьезных конторах делается.

Добавлено через 36 минут и 22 секунды:

Итак, ТЗ от простого потребителя: хочу замок с ключом, но чтобы его можно было открыть кнопкой изнутри или карточкой снаружи, чтобы можно было через комп мониторить и кликнув мышкой открыть дверь, чтобы карточки прописывать и удалять через считыватель или через комп.

да. + геркон на дверь, но это мелочи.

структура события должна включать тип устройства (геркон, кнопка, замок, считыватель).

Итак, попробую перевести требования потребителя на более технический язык.

Устройство должно содержать:
1. Микроконтроллер.
2. Узел управления электромеханическим замком.
3. Датчик двери - открыта/закрыта.
4. Кнопку разблокировки замка изнутри.
5. Устройство идентификации снаружи.
6. Сетевой интерфейс для связи с устройством (контроллером или компьютером) для мониторинга, диагностики, сбора лога событий и дистанционной разблокировки замка.
7. Блок питания замка.
8. Блок питания устройства с резервированием (время резервирования уточним позже).

9. От других потребителей поступило второстепенное требование - реализовать диагностику соленоида замка. Это можно напоследок оставить.

Такая вот схема.

Если я чего-нибудь не то делаю, где-нибудь ошибся или что-нибудь забыл — сразу пишите, чтоб не тратить силы на развитие ошибки.

[Ochkarik]

забыл самое важное... ЛАМПОЧКУ!)
и не совсем понял смысл двух блоков питания?
аккумулятор - к нему неплохо бы измерение напряжения для контроля заряда, и собственно зарядное устройство.
кстати, а чего там аккумулятору вообще делать, при отсутствии питания соленоида? зажигать лампочку "воспользуйтесь ключиком", или что то в памяти хранить? или все таки соленоид тоже подключен?

[RXL]

Два блока - это условно, для абстракции. Замок питается от переменного тока 12 В (может и до 24 В), а прочая схемотехника - типично от 5 В (часть может на пониженном работать - до 3 В). Физически, у них может быть общий сетевой трансформатор. Даже оптимальнее было бы иметь раздельные вторичные обмотки, т.к. "срезать" 12-17 В после выпрямления и фильтрации до 5 В - довольно приличное тепловыделение - лучше было бы иметь одну обмотку на ~12 В и одну на ~7-8 В. С раздельными обмотками не нужна и дополнительная гальваническая развязка для управления замком.

Индикацию я не включил в список - думаю, мы ее потом добавим. Можно и световую, и звуковую.

[Dale]

Честно говоря, не представляю, как можно разрабатывать программную часть, не зная, с каким железом придется работать.

Через механизм абстракций и тонкую прослойку HAL.

Например, наш HAL включает абстрактный класс Lock для работы с замком. У него есть метод для открытия Lock_open, который для отладочной версии на PC выводит на экран "замок открыт" или, скажем, зажигает на клавиатуре лампочку Scroll Lock, а для рабочей версии на МК выдает импульс на заданную ногу заданного порта. Подстановка нужной реализации происходит во время линковки. Остальная часть программы пользуется абстрактным интерфейсом и не имеет понятия о его реализации.

Замок питается от переменного тока 12 В

Это предположение или факт из даташитов замка? У меня знакомый занимался домофонами в подъездах, у него замки были на постоянном токе. По сути замок - это электромагнит, у его обмотки приличная индуктивность, а значит, сопротивление для переменного тока будет значительным. Да и перемагничивание сердечника - это потери и нагрев, нужно заморачиваться со специальными материалами; на постоянном токе этого не требуется.

[RXL]

Насчет HAL не подумал. Жара, видимо, повлияла и стереотипы.
Тем не менее, ознакомиться с функционалом стоит. Например, разве не полезно знать, что драйвер 485 имеет раздельное управление приемом и передачей?


Напряжение ~12 В - факт. Рылся в замках, предлагаемых в инете, и их инструкциях. Типично 12 В и, опционально, с "бустером" на 24 В.
Замечу, что максимум что прилагается - инструкция - никаких "даташитов". Это же не компонент для разработчика, а готовая деталь конструктора для сборки. Только в одной инструкции нашел чертеж механизма с кратким описанием, да и то он был дан для настройки защелки замка на "левую/правую" дверь. Подробности работы, видимо, придется выяснять в магазине замков. В работе механизма одно точно известно: подано питание - электромагнит притягивает якорь.

Включение электромагнита происходит на несколько секунд - видимо тепловой инерции обмотки достаточно, чтобы не было перегрева. Большие токи - следствие необходимости в быстродействии и силе привода. Магнитопровод, обычно, набирают из пластин и сплошные накладки для большей прочности используют только в местах механического контакта.
От переменного тока, как раз, нагрев будет меньше именно из-за индуктивного характера нагрузки. Даже производителем (конкретного замка, по которому я нашел максимум информации) декларируется ток удержания 3.1 А при омическом сопротивлении 3 Ом, что на постоянном токе того же напряжения дало бы 4 А.

В инете рассказывается как про питание переменным, так и постоянным током. Да уж...
Вообще, надо на консульт в магазин сходить. Интернет все же не тот источник.

[Dale]

разве не полезно знать, что драйвер 485 имеет раздельное управление приемом и передачей?

Разработчику уровня MAC, безусловно, это знать необходимо. Клиентам протокола, пожалуй, и ни к чему. Не заморачивались же клиенты коаксиальных плат Ethernet тем, что они полудуплексные (да и по витой паре не всегда используется полный дуплекс). То есть это знание тоже локализуется в узкой области.

Самое главное - правильно выделить уровни абстракции. При этом более 90% кода можно написать и отладить на PC, даже не имея целевого железа. Я именно поэтому и выбрал GCC, хотя у него есть конкуренты посильнее, но заточенные под одну платформу.

[Ochkarik]

RXL, когда падение и  токи на регуляторе большие - на работе обычно ставим DC-DC преобразователи. это одна микросхема с внешней индуктивностью и емкостью. фактически ШИМ стабилизатор. КПД высокий. радиатор - достаточно термалпада на плате.

[RXL]

В копилку: описание протокола 1-Wire с таймингами: http://microsin.ru/content/view/508/44/

Добавлено через 10 часов, 52 минуты и 56 секунд:
Насчет замков я тут еще порылся. Те параметры, которые я ранее упоминал (~12 В, 3.1 А) - какой-то "уникальный" замок. Почитал параметры с десяток других: питаются стабилизированным 12 В и кушают обычно 0.6-0.8 А.


Я вот думаю о применимости protothreads в обработчиках прерываний. Все таки линейное описание действительно удобнее автоматного, хотя и не дает других преимуществ. По моему, при должной умеренности, тут нет проблем с применением. Главное - минимизация времени исполнения.

[Dale]

Я вот думаю о применимости protothreads в обработчиках прерываний.

Не продумывал в деталях, но на интуитивном уровне мне кажется, что это плохая идея. У протопотоков свой синхронный планировщик, а механизм прерываний работает асинхронно, переключая потоки не в точках синхронизации, а где угодно. Опять же, блокировка может продлиться произвольное время, а с реентерабельностью у протопотоков дело плохо. Если событие повторится во время обработки предыдущего, будут проблемы.

Я думаю, нужно использовать паттерн MCH, а Проводники выполнять в потоках.

[RXL]

В данном случае я имел в виду не сопрограммы, а конечный автомат. Ведь protothreads позволяет записать алгоритм автомата в более линейной форме.