@asasl, по спецификации STM32 поддерживает HalfDuplex - т. е. как минимум сигнализация о коллизии во время передачи фрейма приложению придет.
Исходники CSMA/CD выложить не проблема. У меня, кстати, проект под ОС работает. Я последние лет 10 обычно пользуюсь самодельной кооперативной ОС. Только CSMA/CD - это настолько малая и простая часть проекта, что я не очень понимаю, зачем это вам. Я не против и весь проект на Гитхаб вывалить, несмотря на его сырость. Но с документацией будут проблемы: пока что у меня есть только заметки "для внутреннего пользования", которые продолжают меняться на ходу.
Скооперироваться и делать проект УД совместно, с "чистого листа". Я неплохой электронщик, программист (С, Python). Делаю УД скорее для хобби, т. к. то же освещение УД давно бы поставил, например, на Helvar (имею возможность привозить за 50% цены). Есть еще один человек в команде, но он больше специалист в Веб-приложениях. Рекомендую doxygen, генерит документацию прямо из правильно размеченных комментариев...
У нас есть поддержка Ethernet, на чипе ENC28J60. Работает MQTT-SN over UDP. Используются и броадкасты для поиска сервера и DHCP. Как тут правильно заметили решение довольно прожорливое и требует отдельного порта на свитче. Поэтому чаще всего ставится как гейт на другой PHY, например радиоканал или если нужна скорость и надёжность. Из серьёзных плюсов: нет привязки к конкретному компьютеру, при отключении основного компьютера сервер запускается на любом другом и всё продолжает работать.
Начнем с того, что будет сложно менять по ходу реализации проекта, т. е. с архитектуры системы. Причем серверную часть обсудим, но оставим на потом, например, для начала можно написать только мост для OpenHAB плюс конфигуратор и загрузчик модулей. Затем распределим примерно обязанности, что у кого лучше получается/нравится.
Архитектура, на мой взгляд, довольно тривиальна: - Локальная шина (HBus), количество узлов до 100 (ограничение в основном из-за тока потребления, суммарная нагрузка не более 1А) - Опциональный мост HBus-HBus с гальванической развязкой - Шлюз HBus-USB (впоследствии HBus-Ethernet и HBus-WiFi). Шлюз+PC нужны прежде всего для конфигурирования узлов, после этого система на HBus должна быть работоспособна "в автономном режиме", без шлюза и без РС. - Шлюз может присутствовать постоянно и обеспечивать связку с ПО верхнего уровня (OpenHUB, Majordomo, и т. д), исполняемом на PC (десктопе, или Распбери Пи, и т. п. - на чем угодно, не имеет принципиального значения)
А скрипты как загружать? Аsal так красиво расписал про HAL для любых устройст, а теперь самого вкусного лишают. Да и не забудьте про радиоканал, а то после перестановки мебели приходится волосы рвать всю разводку переделывать.
Написать bootloader по HBus. В любом случае это обязательное условие иметь возможность удаленной загрузки.
Радиоканал, конечно, тоже нужен. Однако радиоканал подразумевает полное отсутствие проводов, то есть, батарейное питание. Следовательно, надо вовремя обнаружить и заменить севшую батарейку. При этом менять батарейки желательно как можно реже, иначе это сильно раздражает. Например, если у меня 10 устройств, которые работают от батарейки год. Значит, в среднем примерно раз в месяц мне придется менять батарейку. Это уже близко к пределу терпимости. А много ли это, 10 устройств в доме? Для автоматизации дома это очень мало. Поэтому радиоканал нужен как дополнение к основному, проводному интерфейсу. Кстати, в Thread никто не вникал, что они сделали?
Частенько бывает, что 220 В есть в наличии, а подвести шину не представляется возможным. В этом случае полезным будет наличие радиоканала. Видимо оконечное устройство с батарейным питанием спит большую часть времени, пробуждая приемник раз в 100 ms. Здесь такая латентность и указана Thread_Technical_Overview.pdf В принципе для домашней автоматизации все что меньше 200-300 ms устраивает.
В этом случае логично использовать WiFi, скажем, ESP8266. Например, или сделать минимальную локальную сеть HBus с шлюзом HBus-WiFi, или сделать ноду на ESP8266. Сомневаюсь, поскольку при этом время жизни батарейки будет ничтожным. БТ Смарт пробуждает приемник раз в секунду, тогда время жизни батарейки приемлемое, правда задержки при установлении связи могут быть до 18 секунд. Наиболее вероятно, что, как и в Зигби, устройство с батарейным питанием спит до тех пор, пока не захочет что-то передать, то ли по таймеру, то ли по внешнему воздействию. Это по сути односторонняя связь, батарейные устройства могут только вещать.
Честно скажу, что сам не испытывал сию железку. Но очень много негатива в реальных испытаниях, особенно когда в радиовидимости с десяток Wi-Fi рутеров: на трех метрах работает, на пяти уже "вянет". Видимо несовершенен радиотракт, похоже, учитывая копеечную цену. Думаю лучше подойдут не wi-fi трансиверы, коих напложено много и много хороших отзывов. В таких устройствах батарейки хватает на годы. Интересна именно двухсторонняя связь.