Посмотрел библиотеки.
По моему субъективному мнению - это просто диспетчер задач. Выполнение плат в назначенное им время. Годится для роботов не быстрых и простых алгоритмов. Ветвлений не увидел, прерывания не используются, всё выполняется по очереди, если время пришло.
Использование данного подхода неминуемо должно привести к реальной оценке времени выполнения того или иного участка проекта. Иначе, если время превысится, генератор из указанной темы начнёт выдавать другие интервалы времени. Возможно, не только он...
Заявление о тормознутости нашей проги - бред. Во всяком случае подход в проге и в указанной теме абсолютно разный: если не пользуем выполнения плат по условию - выполнится всё, иначе - быстрее.
Написать на первой плате подобный диспетчер можно и штатными блоками.
Касательно миграции между платформами - вопрос совсем не однозначный. Основной - зачем???
Ответ, внятный, так и не озвучен.
Когда Вы проверяете условие, изменилось или нет, Вы должны или держать переменную со старым статусом, или считать состояние регистра.
У Вас:
Код: Выделить всё
//--------------------БЛОК ЗАПИСИ НА ПИН ДИСКРЕТНОГО СИГНАЛА --------------------
if(!id.init) {id.dOutInv= ИНВЕРСИЯ ВЫХОДА ; id.dOutAll= РАЗРЕШЕНИЕ ВЫВОДА В КАЖДОМ ЦИКЛЕ ;} RT_HW_Board.pinDigitalWriteID(id, pin, val);Если Автор починит работу с дефайнами, тогда нормально заработает препроцессор - наступит кайф, просто кайф. А Пока пишем свои хедеры...
Отправлено спустя 6 минут 54 секунды:
Дисплей.
Да, в программе он не очень удачно сделан в формате загрузки основного цикла и прочего.
Более чем уверен, что в случаях, когда это необходимо, народ пользует свои блоки, написанные под разные задачи - статическая или динамическая индикации с количеством выделенных символов и установкой позиции на экране, выравниванием влево или вправо. Всё. Выплюнули при необходимости изменённое значение в нужное место - ждём команды.
По стрингам, переменным, в дисплее - одна для всего. Да и progmem никто не отменял для влажности, температур и т.п.
.
.
