Сложные программы Опции

[Буратино]

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

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

[gte]

Занимаюсь созданием приборов с микроконтроллерным управлением. Ничего эдакого, как говорит ЛИ "автоматизация курятников".

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

[jcxz]

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

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

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

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

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

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

многочисленные switch/case, if/else как виноградные гроздья начали обрывать ствол программы под своей тяжестью. В итоге я тогда решил что уйду на RTOS... но проекты встали и дело заглохло.
С тех пор у меня сложилось устойчивое мнение, как только количество ветвей превышает 16 надо уходить на RTOS.

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

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

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

[яман-тау]

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

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

[jcxz]

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

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

[яман-тау]

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

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

[AlexandrY]

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

Может что нибудь предложить? Какой ПЛК самый лучший?

Тож в Австралии один "курятник" надо автоматизировать.

[яман-тау]

Может что нибудь предложить? Какой ПЛК самый лучший?

Тож в Австралии один "курятник" надо автоматизировать.

Последние 2 года в основном ставлю Овен ПЛК110-60 и ПЛК110-30. Самый лучший не подскажу, выбираю под конкретные задачи. По надежности одним из них считаю Simatic S-300. В принципе все хотелки Вам должен написать заказчик в техусловиях на проектирование АСУТП. Может у них Аллен Бредли или Омрон в почете, им виднее.

[mantech]

В принципе все хотелки Вам должен написать заказчик в техусловиях на проектирование АСУТП.

Повезло вам с заказчиками... У нас в основном "хочу что-то вот так, включать, чтобы само отключалось потом...", да чтоб картинки красивые, и сенсорные кнопочки с анимашками... Вот и пиши с этого техзадание...

5) модули для контроля входов 220V как правило с трудом выдерживают режим работы 24/7 (приходится опять городить что-то свое).

Если ПЛК не может работать в 24\7 - это плохой ПЛК, но чаще всего исполнитель не заботится о защите линий от бросков напряжения и т.п.

значит время таки пришло ?

Пришло к чему? Поставить винду на 8и битник??

[jcxz]

Повезло вам с заказчиками... У нас в основном "хочу что-то вот так, включать, чтобы само отключалось потом...", да чтоб картинки красивые, и сенсорные кнопочки с анимашками... Вот и пиши с этого техзадание...

...а после этого обычно оказывается, что "Вы всё неправильно сделали, и вообще я хотел другого. Вы виноваты. Переделывайте всё....".
Сколько занисаюсь разработкой - ТЗ всегда писали сами, заказчик только читал и говорил что ему не нравится. Хотя потом всё равно приходилось переделывать, так как оказывалось что "я хотел не такого, а с перламутровыми пуговицами...."

[mantech]

Сколько занисаюсь разработкой - ТЗ всегда писали сами, заказчик только читал и говорил что ему не нравится.

Да так и есть, к сожалению..

если исполнитель должен заботиться о защите линий по входам 220V, то я скорее выберу свой вариант преобразования из 220V в 24V (с защитой) и возьму обычный модуль дискретного ввода

Тоже неплохой вариант, вообще считаю, чем больше низковольтки, тем надежнее.