на реальных задачах это особой роли не играет потому, что 99,(9) процентов времени в системе остаются типовые задержки в районе 10 мс.
Словосочетание "реальные задачи" весьма расплывчато. 99,(9) процентов у вас не выйдет. В вашем коде читаются последовательно три датчика. 300 мс. опрашивать датчики, на мой взгляд это уже перебор даже без требований жесткого реалтайма. За такое время можно прозевать кучу важных событий.
Просто скачайте дистрибутив и ознакомьтесь с его работой.
Скачал дистрибутив. Ознакомиться с работой не смог, но код поглядел. Моё впечатление схоже с приведенными выше — типичный Arduino-style. Вы реализуете кооперативную многозадачность, при этом выполняете блокирующие операции на непотребное время. Приводите как пример Mega Server работающий годами, но код содержит явные ошибки (Да-да, обращение за границу массива в модуле electro_pm.ino). У gcc есть опции -Wall и -Werror, поклонники Arduino о них не знают? Работа годами — это из разряда чуда, а не умелого применения.
После этого трудно не согласиться с Олегом Артомоновым, что студентам профильных ВУЗов стоит держаться подальше от Arduino, пока они не изучат основы на базе более зрелых RTOS. Arduino идеально для всяких простых "скетчей" и имеет свою целевую аудиторию, но в ВУЗе для будующих профессионалов в данной области — это как программирование на соответсвующих специальностях изучать используя Лого Миры с черепашкой.
А таймер на миллисекундном счетчике для интервалов в 500 мксек не годится никакой.
Да, мой пример в данном случае некорректен. Но с использованием готовой библиотеки Arduino для этого датчика и Mega Server, даже 50 мс. для других задач не получить.
Мигание пятью светодиодами в означенных им режимах это абсолютно тривиальная задача для Arduino, а для Arduino Mega Server это вообще не задача, а сущее недоразумение — его штатными средствами организуется многозадачность, которая легко управляет сотнями различных сущностей (светодиодов, сервоприводов, шаговых моторов и т. д.) в реальном времени.
Но ведь по коду видно, что не удастся легко управлять сотнями различных сущностей. Архитектура вашего Mega Server — event-loop, что конечно весьма распространено от различных библиотек и ОС для MCU, так и до сервисов на базе libevent и т. д. Только непременным атрибутом такого подхода является асинхронный ввод/вывод, отсутствие блокировок и интенсивных вычисления. И вот тут Arduino и как аппаратная платформа, так и програмная только вставляет палки в колёса. У ATmega нет ни DMA, ни нормально FIFO для периферии. Заглянешь в библиотеку с реализацией 1-wire — две задержки на 500 и 400 мкс. Вот и выходит, что с вашей библиотекой софтовых таймеров не поморгаешь светодиодом на 1 кГц в параллель с обработкой данных от сенсора температуры. А уж про сотни сущностей и говорить не приходится.
А я поддержу автора. Нормальная лекция. В тысячу раз пережеванный «Hello world» с использованием SPl, HAL и т. д., как раз и не нужен.
Выбор RIOT OS может и не очевидный, но правильный в плане того, что это нормальная ОС. На её примере хоть научатся использовать нормальные абстракции.
Отказ от IDE тоже поддерживаю. Любой нормальный сишник сначала должен понимать этапы сборки и сборочные средства типа make, cmake и т.д Дальше пусть уже натсраивает IDE по вкусу.
GPIOA->MODER &= ~(0b11 << (pin_num*2));
Бинарных литералов нет в стандарте Си, плохому лучше не учить.
Все это вместе с прогонкой тестовых примеров заняло у меня порядка получаса. Интересно, сколько пришлось бы возиться без применения обертки protothreads?
Час, при наличии другой обертки?
Я не отношу себя к противникам protothreads. т.к. читал статьи Адама. Он вполне обосновано утверждает, что protothreads понятны и прозрачны, т.к. код подобен использованию RTOS с вытесняющей многозадачностью и т. п.
Но зачем всё оборачивать в макросы? Например, STATUS — это делает код только хуже.
"Традиционно" для Си функции действия add, get, write_ и т. д. должны возвращать отрицательный код ошибки, 0 или положительное значение в случае успеха. А функции предиката аналог bool — 0 и 1.
В данном примере CheckModemConnection() из названия должна возвращать 0 — всё ок или отрицательный код ошибки. Поэтому лучше её было бы назвать как-то так: isModemConnectionChanged(), тогда сразу бы было ясно, что она "Возвращает 1, если параметры, связанные с модемным соединением изменились, и 0, если нет.".
Слово традиционно я намеренно заключил в кавычки, т.к. если говорить о традициях, то язык Си неразрывно связан с историей Unix. Поэтому приверженцам традиций лучше следовать Linux kernel code style — пункт 16, либо KNF.
Когда-то тоже занимался подобным "украшательством" вывода в UART на самом MCU, чтобы проще было отлаживать. Затем просто стандартиризировал отладочный вывод и отказался от использования стандартных терминалов в пользу скриптов на Python + модуль Serial — гибкости нет придела.
Конечно, поэтому никто и не отменял универсальные IAR, KEIL, туже VS + gcc + gdb. А привязанные к производителю IDE я предпочитаю выкидывать на мороз сразу после ознакомления с примерами.
Плюсы 1 и 2 это скорее для новичков желающих освоить новый микроконтроллер. С ростом опыта и накопления наработок появляются красивые заготовки, а студии выкидываются.
Тут стоит понимать их заявления как чисто маркетинговые. На практике всё зависит от множества факторов, прежде всего от частоты выхода в эфир. Поэтому, при определённых обстоятельствах для любых типов устройств. Конечные устройства в сети синхронизируются по специальному сигналу от сервера.
Второй момент. Они предполагают, что шлюзы будут принадлежать крупным операторам, соответственно это сложные и дорогие устройства, где возможна установка многоканальных приёмников для разных частотных диапазонов.
Еще интересной особенностью LoRa модуляции является возможность выделения сигнала в одном канале для разных SF (spreading factor). Например, так у них устроен референсный шлюз sx1301, который состоит из универсального приёмопередатчика sx1257 + FPGA с реализацией 10 параллельных демодуляторов.
Поработал с esp8266 — «идеальная штука» заканчивается сразу на цене. А потом начинается кривая документация, кривой SDK, отсутствие нормальной поддержки, зависоны и т. д. И тут уже цена не кажется такой замечательной, т.к. трудозатраты существенно увеличиваются.
Невнимательно поглядел, там таки команда сразу всем датчикам по шине выдаётся.
Словосочетание "реальные задачи" весьма расплывчато. 99,(9) процентов у вас не выйдет. В вашем коде читаются последовательно три датчика. 300 мс. опрашивать датчики, на мой взгляд это уже перебор даже без требований жесткого реалтайма. За такое время можно прозевать кучу важных событий.
Скачал дистрибутив. Ознакомиться с работой не смог, но код поглядел. Моё впечатление схоже с приведенными выше — типичный Arduino-style. Вы реализуете кооперативную многозадачность, при этом выполняете блокирующие операции на непотребное время. Приводите как пример Mega Server работающий годами, но код содержит явные ошибки (Да-да, обращение за границу массива в модуле electro_pm.ino). У gcc есть опции -Wall и -Werror, поклонники Arduino о них не знают? Работа годами — это из разряда чуда, а не умелого применения.
После этого трудно не согласиться с Олегом Артомоновым, что студентам профильных ВУЗов стоит держаться подальше от Arduino, пока они не изучат основы на базе более зрелых RTOS. Arduino идеально для всяких простых "скетчей" и имеет свою целевую аудиторию, но в ВУЗе для будующих профессионалов в данной области — это как программирование на соответсвующих специальностях изучать используя Лого Миры с черепашкой.
Да, мой пример в данном случае некорректен. Но с использованием готовой библиотеки Arduino для этого датчика и Mega Server, даже 50 мс. для других задач не получить.
Но ведь по коду видно, что не удастся легко управлять сотнями различных сущностей. Архитектура вашего Mega Server — event-loop, что конечно весьма распространено от различных библиотек и ОС для MCU, так и до сервисов на базе libevent и т. д. Только непременным атрибутом такого подхода является асинхронный ввод/вывод, отсутствие блокировок и интенсивных вычисления. И вот тут Arduino и как аппаратная платформа, так и програмная только вставляет палки в колёса. У ATmega нет ни DMA, ни нормально FIFO для периферии. Заглянешь в библиотеку с реализацией 1-wire — две задержки на 500 и 400 мкс. Вот и выходит, что с вашей библиотекой софтовых таймеров не поморгаешь светодиодом на 1 кГц в параллель с обработкой данных от сенсора температуры. А уж про сотни сущностей и говорить не приходится.
Выбор RIOT OS может и не очевидный, но правильный в плане того, что это нормальная ОС. На её примере хоть научатся использовать нормальные абстракции.
Отказ от IDE тоже поддерживаю. Любой нормальный сишник сначала должен понимать этапы сборки и сборочные средства типа make, cmake и т.д Дальше пусть уже натсраивает IDE по вкусу.
Бинарных литералов нет в стандарте Си, плохому лучше не учить.
Час, при наличии другой обертки?
Я не отношу себя к противникам protothreads. т.к. читал статьи Адама. Он вполне обосновано утверждает, что protothreads понятны и прозрачны, т.к. код подобен использованию RTOS с вытесняющей многозадачностью и т. п.
Но зачем всё оборачивать в макросы? Например, STATUS — это делает код только хуже.
Разрешите поинтересоваться, это какие же подходы используются при разработке для малых микроконтроллеров, что указанные автором подходы не приенимы?
"Традиционно" для Си функции действия add, get, write_ и т. д. должны возвращать отрицательный код ошибки, 0 или положительное значение в случае успеха. А функции предиката аналог bool — 0 и 1.
В данном примере CheckModemConnection() из названия должна возвращать 0 — всё ок или отрицательный код ошибки. Поэтому лучше её было бы назвать как-то так: isModemConnectionChanged(), тогда сразу бы было ясно, что она "Возвращает 1, если параметры, связанные с модемным соединением изменились, и 0, если нет.".
Слово традиционно я намеренно заключил в кавычки, т.к. если говорить о традициях, то язык Си неразрывно связан с историей Unix. Поэтому приверженцам традиций лучше следовать Linux kernel code style — пункт 16, либо KNF.
Когда-то тоже занимался подобным "украшательством" вывода в UART на самом MCU, чтобы проще было отлаживать. Затем просто стандартиризировал отладочный вывод и отказался от использования стандартных терминалов в пользу скриптов на Python + модуль Serial — гибкости нет придела.
А у TI интресным решением является СС1350, там Cortex-M3 и поддержка как BLE, так и 868 МГц. TI-RTOS легко выкидыватется на мороз.
Тут стоит понимать их заявления как чисто маркетинговые. На практике всё зависит от множества факторов, прежде всего от частоты выхода в эфир. Поэтому, при определённых обстоятельствах для любых типов устройств. Конечные устройства в сети синхронизируются по специальному сигналу от сервера.
Второй момент. Они предполагают, что шлюзы будут принадлежать крупным операторам, соответственно это сложные и дорогие устройства, где возможна установка многоканальных приёмников для разных частотных диапазонов.
Еще интересной особенностью LoRa модуляции является возможность выделения сигнала в одном канале для разных SF (spreading factor). Например, так у них устроен референсный шлюз sx1301, который состоит из универсального приёмопередатчика sx1257 + FPGA с реализацией 10 параллельных демодуляторов.
Да конечно, это они ещё код ведущих мировых производителей встраиваемых решений не видели.