Доброго времени! Всех с НГ!

Занимаюсь созданием приборов с микроконтроллерным управлением. Ничего эдакого, как говорит ЛИ "автоматизация курятников". Из последнего у меня получилось 32К на Си. Освоил и пользуюсь методами из теории конечных автоматов. Сообщения, таймеры много канальные программные.
Однако новые требования заказчиков, косяки в архитектуре ПО и некоторые другие факторы вынуждали меня что то править, что то и вовсе переписывать. Это вылилось в трудно модифицируемую систему с костылями и тп хренью.
С нового года я работаю над еще более сложным прибором и понимаю, что так как было делать нельзя. Смотрю в сторону объектно ориентированных принципов построения ПО, а также подумываю над идеями из теории ОС.
Как вы решали свои задачи, что можете посоветовать посмотреть-почитать? Спасибо!

Посмотрите как делают моргание на светодиодах.
Вот тут например - https://geektimes.ru/post/284248/

Там на одном микроконтроллере программа занимает 160К и на втором 130K
Зато сделано за день.

Вся фишка во фреймворке. Вы просто еще не собрали свой фреймворк. Туда должны входить RTOS (лучше несколько), несколько файловых систем, движки отладочных мониторов, коммуникационные стеки и проч.
И тогда ваши программы со старта уже будут весить под 100К и вы забудете слово "сложные"

Ужасссс!
Не в тему - Александр, меня удивляет ваше увлечение или осмысленное использование Freescale - овских (NXP) контроллеров серии Kinetis - мало кто их использует в наших краях, я то же к ним не равнодушен (работал до этого с MC68332) и хочу заложить в свою конструкцию. Много ли ерратовских косяков и других проблем возникает на пути их юзанья? Это касаемо серий K66 K20 K02?

Рецепт из серии - если у Вас болит зуб - прищемите палец дверью... Удивляет, что Вы еще почему-то до сих пор с микроконтроллерами возитесь и разными RTOS. Пора уже все задачи решать с помощью IBMPC и Линукса .

Автоматизация курятников гораздо легче (и разумнее) делается с использованием промышленных контроллеров и соответствующего программного обеспечения. Так легче и, в итоге, дешевле. Можно учитывать особенности каждого курятника и новые требования заказчиков. Кроме того, заказчику легче эксплуатировать такие системы. Например что то модифицировать в будущем или заменить датчик на другой, добавить что-то новое.

нет, готовые RTOS меня не интересуют. Я работаю с 8ми битниками и задачи у меня в целом достаточно простые: обработать клавиатуру, аналоговые входы. поддержка цифровых интерфейсов и тп. Трудности возникли именно на этапе соединения всего этого зоопарка в единое целое. Быстродействия, памяти мне всегда хватает. Сейчас я подошел к пределу своих возможностей в так сказать в функциональных ресурсах своего подхода к написанию ПО.
Ну например: в устройстве есть некий цифровой выход, который должен уметь быть включенным на x секунд в диапазоне от 0 до 120. При этом выход может быть сконфигурирован как инверсным так и без инверсии. Также выход должен уметь работать циклами включен на y сек, выключен на z секунд. Естественно работа этого выхода связана с другими узлами и логикой системы Так например работа выхода может быть прервана на w секунд, а после продолжена.
Согласен ничего такого в этом выходе нет, но что если приходит заказчик и говорит: хочу чтоб этот выход включался только если темное время суток, а если светлое время суток то хочу чтоб включался другой выход с другими x,y,z,w
Я это реализую, но выглядит это стремно: глобальные переменные, флаги, общие в целом куски ПО. Кароче не то.

Сильно сомневаюсь, что задача типа условного ногодрыга решается дешевле с помощью покупного PLC или даже недо-PLC типа Siemens LOGO
Бывает сильно по-разному. Иногда - да. Экономия времени. Удобство разработки "на всем готовом".
Иногда нет. Особенно что изготовители PLC постоянно стимулируют "докупать" железо, драйвера, лицензии, модули, интерфейсы и прочея и всякая за дорого.
Хотя если учесть, что самый дорогой ресурс - время, то согласен.

1. C
2. там где надо - использовать модули ASM в составе проекта на С
3. Для больших проектов сильно упрощает наличие RTOS.
Посмотрите scmRTOS.
4. Использование ООП (C++) - позволяет на порядок увеличить "читабельность", простоту и упоряченность своего кода.
Естественно - если пишется в "трезвом рассудке и здравом уме"
5. Как тут советовали. Свои наработки "перепакуйте" в модули и/или библиотеки.
Если есть смысл - перепишите с использованием объектов на C++.
6. Для ведения разработки сильно упрощает жизнь системы версирования проектов.
Я пользую SVN. (база данных разработки, с возможностью, например, отката на "позпрошлый понедельник")

Kinetis обсуждаем здесь - https://electronix.ru/forum/index.php?showt...=0#entry1472241
Я создал специально тему.



Напрасно не интересуетесь RTOS, в той гирлянде на светодиодах применяются автоматы состояний сложнее ваших. Причем автомат состояний на каждый светодиод свой.

Но вижу вы уже на пороге создания велосипеда под названием скриптовый движок.
Только скрипты позволяют пока клиент рассказывает о своей хотелке реализовать ее в это же время.

я сразу же как начал работу с мк делал по рецепту многоуважаемого DiHalt тут AVR. Учебный курс. Операционная система. Введение.
Очень рекомендую. Ну а дальше по желанию любые учебники по написанию embedded кода с семафорами, пайплайнами и прочими прелестями.. Но имхо для 8 битников и DiHalt 'а освоить достаточно будет.

Как поэтично

RTOS для описанной Вами ситуации дело десятое. Это просто один из возможных инструментов. Причем не универсально-эффективный и НЕ способный заменить собой все технологии.

Если проектируемая система единична зачем городить на МК, если есть ПЛК как предлагали выше. Масштабировать, сенсорную панель прикрутить или на верхний уровень АСУТП завести намного легче.

.... и отказаться в результате от услуг разработчика.
Заказчику не должно быть что-то легко переделать самостоятельно в устройстве, иначе у него может возникнуть крамольная мысль "а нафига я столько плачу этому разработчику? эта работа столько не стОит! Я и сам это могу"


Ну если так часто ходят заказчики с такими тривиальными задачами (и у каждого она немного отличается от другого), то у Вас наверное неправильно составлено ТЗ. И вообще - решение задачи архитектурно сделано неверно.
Усложните себе задачу - поставьте её по-нормальному:
1.Реализовать в устройстве поддержку выполнения скриптов (записанных в любом формате, хоть соответствующем некоему стандарту, хоть доморощенном).
2.Реализовать некий необходимый пользовательский функционал со скриптовым доступом (вкл/выкл ноги, послать пакет в порт, задать паузу, установить таймер и т.п.).
3.Привязать выполнение скриптов к событиям от периферии.
4.Дать возможность пользователю редактировать и запускать скрипты на Вашем устройстве.
Всё! С этого места можете спокойно плевать в потолок, попивая пиво и посылая пользователей читать мануал на скрипты.



О, блин! Уже посоветовали....


Дело тут не в RTOS, а в стиле написания. Наличие RTOS тут равнобедренно.


... но как только окажется что чего-то не хватает в функционале этого ПЛК, то уже никак не объедешь. МК - более гибкий подход.

Например чего?

си шарп и микрофреймворк