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

[Буратино]

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

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

[AlexandrY]

Как вы решали свои задачи, что можете посоветовать посмотреть-почитать? Спасибо!

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

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

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

[Make_Pic]

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

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

[zltigo]

И тогда ваши программы со старта уже будут весить под 100К и вы забудете слово "сложные"

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

[gte]

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

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

[Буратино]

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

[k155la3]

. . . .
в итоге, дешевле.
. . . .

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

. . . .
Как вы решали свои задачи, . . .

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

[AlexandrY]

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

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

нет, готовые RTOS меня не интересуют.

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

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

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

[Onkel]

.... Я работаю с 8ми битниками и задачи у меня в целом достаточно простые: обработать клавиатуру, аналоговые входы. поддержка цифровых интерфейсов и тп. Трудности возникли именно на этапе соединения всег.... Кароче не то.

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

[alexunder]

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

Как поэтично

[zltigo]

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

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

[яман-тау]

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

[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]

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

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

[alexunder]

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

автор работает с 8-битниками

[яман-тау]

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

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

[dm37]

Занимался как раз задачами автоматизации птичника (более 10 лет). Расскажу с чем мы столкнулись.
Как показала практика все системы должны быть распределёнными (как минимум допускать расширение), либо связаны по сети (диспетчеризация).
Готовые системы не устраивают не зависимо от производителя, должен быть индивидуальный подход.

Минусы использования ПЛК (тип не имеет значение):
1) ОЧЕНЬ дорого, особенно по нынешним ценам;
2) в качестве датчиков температуры использовали DS18B20 (DS18S20). Ни один нормальный ПЛК не поддерживает данный тип датчиков (городить что то по modbus не очень хороший вариант)
3) частично лицензионный софт
4) иногда быстродействие, как ни странно (например, при реализации фазоимпульсной модуляции)
5) модули для контроля входов 220V как правило с трудом выдерживают режим работы 24/7 (приходится опять городить что-то свое).

При разработке основная проблема была с нехваткой портов ввода/вывода, а также памяти (как RAM так Flash), как говорили уже здесь быстродействия вполне хватало (в ОСРВ потребности не было). В итоге даже начинал рассматривать вариант разработки своего ПЛК (хотели переделать ПЛК Delta, они дешевле и используют STM32 (правда среда разработки плохая, нет ST) либо сделать что-то своё аналогичное, платы можно заказать в Китае).

По поводу требований заказчиков - в итоге мы (заказчики) забрали разработку софта себе, а разработчик оборудования поставлял только железо. Вот так.
Скрипты не нужны, иначе вас заставят отвечать за ошибки в оборудовании (как вы собираетесь доказывать, что виноват скрипт, а не основной софт). Лучше создать железо и базовый софт и продать это всё заказчику, если у них есть кому сопровождать, пускай сами делают всё под себя, можете даже провести обучение. Если нет, поддержка у вас и ни в коем случае не давать дополнительных возможностей в виде скриптов (сломают). Помню как мы по несколько раз в неделю бегали в цех для восстановления параметров блока, пока начальник цеха не наказал их рублём за шаловливые ручки.

Речь в данной теме шла о софте: итог (моё мнение) - всё равно придётся плодить версии под каждого заказчика (заказчик всегда прав), единственно, что можно это попробовать решить за счёт конфигурации блока (недоступной заказчику). Правда я немного не понимаю почему у вас это сводится к изменению ПО, как правило оно тянет за собой и изменение аппаратной части.

[AlexandrY]

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

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

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

[яман-тау]

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

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

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

[dm37]

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

В своё время рассматривали Schneider Electric Modicon M340 (BMX XBP 1200 + BMXP342020 + ...)

[Огурцов]

автор работает с 8-битниками

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

[Буратино]

В этой теме речь не идет о пром контроллерах, армах или скриптовых движках. Это наверное и важно и интересно, но точно не мне и не сейчас.
Из конструктива в теме отмечу ссылки на ооп и ос. На сколько мне известно, то это огромные темы с массой интересного. Однако напоминаю, что у меня маленькие процы и в принципе простые задачи сложно взаимодействующие друг с другом.
Что из самого ценного взять и трансформировать в мир маленьких камней из ооп и ос? обьекты и задачи? семафоры? есть ли реализации на которые можно смотреть и наследовать?

[dm37]

С++ для микроконтроллеров.

в первую очередь эта статья
http://easyelectronics.ru/rabota-s-portami...erov-na-si.html
и примеры к ней
https://github.com/KonstantinChizhov/Mcucpp/tree/dev

Многие будут отсылать к книге Андрея Александреску "Современное проектирование на С++", но как то пока сложновато.

тоже в основном смотрю в этом направлении, пробую как раз для AVR (8 бит). Задача стоит иметь расход RAM (а потом и Flash) аналогичный применению с использованием Си.

Для себя сделал вывод, что для uC необходимо (желательно) использовать шаблоны классов со статическими членами, тогда вроде всё получается...

Сообщение отредактировал dm37 - Jan 4 2017, 19:53

[mantech]

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

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

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

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

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

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

[jcxz]

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

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

[mantech]

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

Как ни странно, но здесь есть доля истины. Только чтоб работать со скриптами, их должна выполнять какая-либо ось, в которой есть уже готовые модули работы с портами в\в интерфейсами, типа того далласа, который указал автор, и еще многое другое. Тогда, да, будет быстрое программирование и не надо винду ставить, сам делал такие ПЛК.

[dm37]

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

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

[mantech]

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

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

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

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

[AlexandrY]

В этой теме речь не идет о пром контроллерах, армах или скриптовых движках. Это наверное и важно и интересно, но точно не мне и не сейчас.
Из конструктива в теме отмечу ссылки на ооп и ос. На сколько мне известно, то это огромные темы с массой интересного. Однако напоминаю, что у меня маленькие процы и в принципе простые задачи сложно взаимодействующие друг с другом.
Что из самого ценного взять и трансформировать в мир маленьких камней из ооп и ос? обьекты и задачи? семафоры? есть ли реализации на которые можно смотреть и наследовать?

По моему суть вашей "сложности" недостаточно раскрыта.
Может вам просто нужно провести рефакторинг.
По сути переход на ООП это будет рефакторинг и больше ничего.

Может вы еще 20-и часов не провели со своим кодом.
Правило 20-и часов гласит, что спустя 20-ч изучения в течении 20 дней любой код становится простым.

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

А насколько сложные программы вам удается писать под Овен и на каком языке?
Там многофайловые проекты можно написать?

[zltigo]

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

Именно так. Есть ГОСТ 34.602-89
Когда речь идет о сколь нибудь сложных системах по другому нельзя, ибо заказчик в 99 случаях из 100 полный ноль в предметной области.

[dm37]

А насколько сложные программы вам удается писать под Овен и на каком языке? Там многофайловые проекты можно написать?

Тоже есть опыт использования продукции Овен, есть работающие проекты на ПЛК63, ПЛК100 + СП270. Отношение конечно плохое. ПЛК у Овен получились не очень. Что не понравилось:
- в ПЛК крепления верхней платы идёт (шло) на пластмассовых винтах, которые быстро ломались (после покупки сразу меняли на металлические). Элемент питания для RTC тоже сразу меняли (почти всегда были старые или не рабочие)
- если программировать через RS232, то постоянно терялась связь со средой разработки. Использовать переходники UBS-COM тоже не получалось (ПЛК критичны к уровням RS232), даже ноутбук со встроенным RS232 глючил, пришлось в цех тащить плату c COM-портами и вставлять в обычный ПК. Где то на форуме Овен говорили, что ПЛК110 лучше держат связь со средой разработки при отладке.
- панель оператора СП270. Конфигуратор (IDE) без предупреждений просто отказалась открывать проект, который создавался несколько дней. Как потом опытным путём выяснил - количество элементов отображения какого то типа (не помню уже какого) превысило 255. После этого проект умирал без предупреждений. Писал про этот глюк на форуме, но мне разработчики панели так ничего и не ответили.
- Теперь ПЛК63: в спецификации указан доступный пользователю объём RAM. Создал массив элементов с учётом данного размера, загружаю в ПЛК, ПЛК виснет. Хорошо есть комбинация из трёх пальцев, позволяющая вернуть ПЛК к жизни. В итоге выяснилось, что доступный объём меньше чем указано.

В общем ПЛК Овен работает, если у вас всё же хватит терпения довести проект до конца. У нас уже несколько лет работает и проблем вроде нет. Только СП270 всё же глючит при отображении (сейчас её вроде уже не выпускают). Среда разработки CodeSys 2.3, язык ST, многофайловые поддерживаются. Стандартное меню в ПЛК63 не использовал, сделал своё.

После мучений с Овен по возможности несложные проекты стали делать на ПЛК Delta (дешёвые ПЛК, которые применяются на производстве), правда среда разработки не поддерживала язык ST (не знаю как сейчас).

[k155la3]

. . . .
Что из самого ценного взять и трансформировать в мир маленьких камней из ооп и ос? обьекты и задачи? семафоры? есть ли реализации на которые можно смотреть и наследовать?

Как один из вариантов использования ООП для Вас.
(1) Если есть наработки для малых МК - можете рассмотреть возможность создания своего "компилятора".
Это на базе PC.
(2) В разрезе программирования МК. Если не использовали структуры - начинайте исползовать.
В структуры интегрируйте как данные, так и указатели на функции-обработчики этих данных.
Это можно делать на базе С - без плюсов. Эти структуры с разной инф. набирайте в массив.
Например, задача, которая решается элементарно таким способом - сложное меню.
Без единого switch-case и с одной "управляющей" функцией

"маленьких камней" - это как ?
Контроллер с Flash=32k + RAM=8k я маленьким я не считаю.
В контексте использования, например, scmRTOS это вполне достаточные ресурсы.
Вот когда Flash=1k + RAM=512 - это нечто Туда бы OS я и не думал, хотя есть и такие весчи.
Но это скорее не ОС а "планировщик" выполнения кода.

[Буратино]

Спасибо за ответы.

Немного почитал о ОС. Мне точно не нужно. У меня нет ничего такого в системах что подразумевало бы управление переключениями контекста\задач\потоков. В моих системах все устроено так, что контекст переключается автоматически когда основной бесконечный цикл ПО снова и снова проходит все задачи по кругу. Я управляю процессом и четко знаю что и как устроено и как работает. У меня нет ничего стороннего в системе (если не считать LUFA для работы с USB).
Я понимаю, что RTOS это то без чего нельзя представить себе мир контроллеров, но вполне себе пока проживет мир RTOS без меня.

Еще очень интересно попробовать идею с объектами. Сам ООП в моей работе вряд ли поможет. А вот объект с свойствами и методами наверное то что нужно. Если есть что то простое для мелких мк - поделитесь ссылками. Спс!

[k155la3]

. . .
Еще очень интересно попробовать идею с объектами. Сам ООП в моей работе вряд ли поможет. А вот объект с свойствами и методами наверное то что нужно. Если есть что то простое для мелких мк - поделитесь ссылками. Спс!

Берете туже scmRTOS.
ОНО сделано на C++. Смотрите исходник как да что. И разницы, какой контроллер - большой или малый, нет.
Просто для контроллера с очень малыми ресурсами - IMHO - использовать класы, наследование, вирт. функции итд итп - смысла не имеет.
А имеет смысл (то что я сказал выше) разработка своего специализированого компилятора.
Точнее пре-компилятора для компилятора С или ASM. Вот тут можете на PC "разгуляться" c ООП и всеми его возможностями.

[Буратино]

компилятора!? о_О

[k155la3]

компилятора!? о_О

Ну так Вы и так из своих "наработок", думаю, постоянно собираете код проекта.
Или каждый раз пишите все с нуля ? По сути - ЭТО - есть компияция вручную

[Огурцов]

В этой теме речь не идет о пром контроллерах, армах или скриптовых движках

тогда вариант один - делить задачу между несколькими камнями, в каждом иметь законченный софт, при необходимости новых фич - досыпать ещё камней, не трогая прежние

[Drozd2]

Protothreads в помощь

[k155la3]

Protothreads в помощь

Начал почитать.
Это некое подобие "безтиковой" ОС, кажется они называются "кооперативные" ?
Чтоб запустить на MK достаточно откомпилировать, портирование не требуется ?

[haker_fox]

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

Простите, как вы решаете вопрос "порчи" памяти? Как вы отслеживаете, что например процесс №1 записал данные, выйдя за границы массива на два элемента? Используете ли вы MPU в Cortex-m3?

[AlexandrY]

Еще очень интересно попробовать идею с объектами. Сам ООП в моей работе вряд ли поможет. А вот объект с свойствами и методами наверное то что нужно. Если есть что то простое для мелких мк - поделитесь ссылками. Спс!

Рядышком напишите статические переменные и функции и сверху и снизу поставьте коментарии со скобками - вот вам и объект со свойствами.
Зачем платить писать больше если нет разницы?

C++ был придуман для коллективной разработки.
Если вы не используете оси и вообще стронние исходники и проекты, то плюсы вам точно не помогут.
Только лишним множеством имён загрузитесь, потеряете производительность.

Хотя может подсознательно вы и хотите уйти в простой, отвлечься от целевой задачи.

Простите, как вы решаете вопрос "порчи" памяти? Как вы отслеживаете, что например процесс №1 записал данные, выйдя за границы массива на два элемента? Используете ли вы MPU в Cortex-m3?

Cortex-M3 давно уже не использую.
Не понял связи ошибки памяти с фреймворками.

[syoma]

Буратино, я думаю, что ваша проблема в том, что у вас нет четко определенной архитектуры ПО. Под архитектурой я подразумеваю то, что ПО должно быть разделено на программные модули, которые взаимодействуют друг-с-другом через четко заданные интерфейсы. Данный подход позволил бы вам разбить сложную программу на несколько простых, которые гораздо легче разрабатывать и поддерживать, а также портировать на другое железо. Сделаете ли вы это с помощью ОС, скриптов или других методов - это уже ваш выбор.

Что касается архитектуры ПО для системы управления, то у меня сложилась следующая архитектура, которую я реализовал не в одном успешном проекте:
К основным модулям данной архитектуры относятся: I/O менеджер, управляющй процесс, менеджер коммуникаций, логгер.

Задачей I/O менеджера является абстрагирование железа от остального ПО. Т.е он должен преобразовывать сигналы, получаемые от физических интерфейсов во внутренние "виртуальные" сигналы, которые затем будут использоваться управляющим процессом и менеджером коммуникаций. Под сигналами я понимаю состояния входов, измерения, команды на включение чего либо, статусные сигналы и т.д. Т.е смысл I/O менеджера в том, чтобы остальному ПО было наплевать откуда появляется нужный сигнал и куда он уходит. Сегодня это может быть пин А, завтра пин B, а послезавтра пин на слейве в Modbus RTU или SPI - все это должно конфигурироваться на данном уровне и только на нем. Также тут можно делать простые действия над сигналами - инвертировать, масштабировать. Неплохой функцией является возможность "подменить" значение какого либо сигнала на свое во время исполнения программы, чтобы упростить отладку. I/O менеджер должен работать в жестком реальном времени, с теми же циклами, что и управляющий процесс, поэтому важно его оптимизировать, чтобы он не занимал много процессорного времени.

Управляющий процесс - это сердце вашей системы. Он исполняет все управляющие алгоритмы, которые нужны в данной задаче - автоматы состояний, алгоритмы управления теплицей, курятником, турбиной и пр. Благодаря I/O менеджеру все выходы и входы управляющего процесса будут внутренними переменными, следовательно вы легко сможете изменять свои алгоритмы без необходимости изменять весь проект. Также это значительно упрощает повторное использование алгоритмов и функций, так как они становятся аппаратно-независимыми. Еще раз, важно - никакой непосредственной связи с железом в управляющем процессе. Управляющий процесс опять же исполняется в реальном времени в связке с I/O менеджером. Возможно иметь несколько управлящих циклов, работющие в многозадачном шедулере - самые быстрые с временем исполнения <1мс - например для различных защит, основные 10-100мс - где исполняются основные алгоритмы, медленные 100мс-1с - выборы режимов работы.

Управлящий процесс и I/O менеджер - это два модуля, работающих в реальном времени. Менеджер коммуникаций - уже нет. Его задачей является предоставление доступа различным нереалтаймовым интерфейсам типа HMI, HTTP , файловой систеы к виртуальным переменным I/O менеджера. Это собственно Scada интерфейс.

Логгер - подсистема, взаимодействующая с I/O менеджером и служащая для постоянной записи изменеий всех или выборочных виртуальных сигналов в лог-файл для следующей диагностики.

Приведенная архитектура возможно слегка сумбурна, так как по определенным соображениям не могу привести картинки - спрашивайте, если что не понятно. Как ее реализовывать - это уже дело каждого. Например ПЛК реализуют почти все из этой архитектуры, но на МК возможно вы на чем-то сэкономите. В простых системах все можно сделать даже без ОС, но в более сложных она понадобится. В самых высокопроизводительных системах, как у нас, вообще используется мультипроцессорная архитектура, а I/O менеджер частично реализован на ПЛИС.
Для разработки и отладки управляющего процесса при использовании данной архитектуры идеально подходит т.н. Модельно-ориентированный подход, реализованный, например, на Matlab/Sumulink. Тогда вы сможете сконцентрироваться на решении задачи, а не ее программировании. А все остальное за вас сделает программа, включая генерацию кода.
I/O менеджер в простейшем случае будет представлять shared memory, где хранятся различные переменные. А к этой памяти уже обращаются и драйверы и управляющий процесс. В сложных системах со многими сигналами это уже будет что-то наподобии быстрой базы данных.
Конечно, 8-и битник для всего этого слегка слабоват, так как такая архитектура имеет серьезный оверхед, но начиная с простого АРМ 32-х битника она уже легко позволяет получать циклы в 10мс на сотне-другой I/O сигналов.

[jcxz]

Это некое подобие "безтиковой" ОС, кажется они называются "кооперативные" ?

Кооперативная многозадачность и "безтиковость" ОС перпендикулярны друг другу. Как тёплое/холодное и круглое/треугольное.

Сообщение отредактировал Herz - Jan 5 2017, 19:40

Причина редактирования: Нарушение п.2.1.г Правил

[Drozd2]

называются "кооперативные" ?
Чтоб запустить на MK достаточно откомпилировать, портирование не требуется ?

Точно. Стек протопотоков общий. Переполнение одно на всех. Отработка протопотоков асинхронная. Для 8-битников, на мой субъективный взгляд, очень удобно.

[haker_fox]

Cortex-M3 давно уже не использую.
Не понял связи ошибки памяти с фреймворками.

Связи нет никакой, скорее всего я озадачился размерами ваших программ))) Ну, а всё-таки, есть в том же kinetis что-то аппаратное, что позволяет вам как-то предохранять память от несанкционированного доступа? В "больших" камнях это решается MMU с вызываемыми исключениями...

Буратино, я думаю, что ваша проблема в том, что у вас нет четко определенной архитектуры ПО. Под архитектурой я подразумеваю то, что ПО должно быть разделено на программные модули, которые взаимодействуют друг-с-другом через четко заданные интерфейсы.

Мне нравится ваш подход. Наверно потому, что и я думаю в этом же направлении Уже давно нахожусь на пути создания минимального базиса (фреймворка), включающего в себя ОС (пока FreeRTOS), стек драйверов (high и low-уровни), отладочная текстовая консоль (использую обточенную CLI из FreeRTOS), адекватный менеджер памяти, позволяющую понять куда она ушла (спасибо уважаемому zltigo!). Логгер пока ещё не присобачивал.

[Буратино]

тогда вариант один - делить задачу между несколькими камнями, в каждом иметь законченный софт, при необходимости новых фич - досыпать ещё камней, не трогая прежние

Я с вариантами разберусь, а вы пож. не постите ерунду больше.

syoma, спасибо за текст. Не мое точно. Точнее все то что вы пишите в том или ином виде есть по умолчанию в любом проекте. И абстракция и манагер процессов и логер если нужно. Только все это в примитивной форме в достаточной для решения моих задач. Чего мне не хватает так это инструментов для реализации бизнес логики и меня не устраивает не только сложность с написанием ПО, но и самое главное сложности с его модификацией.

[jcxz]

Ну, а всё-таки, есть в том же kinetis что-то аппаратное, что позволяет вам как-то предохранять память от несанкционированного доступа? В "больших" камнях это решается MMU с вызываемыми исключениями...

"Что-то аппаратное" есть во всех Cortex-M - MPU. Использую MPU в всех своих проектах на Cortex-M обязательно. А почему собственно его не использовать?
Только предохранить какую-то конкретную переменную с помощью него конечно затруднительно. Зато при отладке MPU очень часто помогает.

[iosifk]

Буратино, я думаю, что ваша проблема в том,...

Вот это все было бы хорошо оформить в виде статьи!
Пусть она будет небольшая, но тем не менее...
Прямо так и начать: "В конференции шло обсуждение... И мое мнение таково..."
И к нам, в КиТ...
Что скажете?

[syoma]

Чего мне не хватает так это инструментов для реализации бизнес логики и меня не устраивает не только сложность с написанием ПО, но и самое главное сложности с его модификацией.

Что такое бизнес-логика?

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

[AlexandrY]

Вот это все было бы хорошо оформить в виде статьи!
...
И к нам, в КиТ...

Не статью писать надо, а в github.com постить.
Нынче так - или вы показываете свои сорсы на github-е или ваши слова про программирование малого стоят.
Когда говорят о такой запредельной абстракции как некий "I/O менеджер" исходники надо показывать в обязаловку.
Я не первый год в программировании, но у меня даже не идей что такое "I/O менеджер"

[ViKo]

Писать надо туда, где больше заработаешь.
А I/O менеджер и менеджер коммуникаций звучат слишком похоже.
У меня все время висит вопрос, как назвать, к примеру, файл низкоуровневых функций. Типа HAL. HAL называть не хочу. Драйвер пока зову.
А как разобьешь на файлы-папки, как назовешь, так и поплывешь-попрограммируешь.

[iosifk]

Не статью писать надо, а в github.com постить.

Да нет, у каждого издания свои читатели.
КиТ имеет тираж 6,5 тыс экз. И никто не мешает сначала напечатать статью, а потом размещать материалы еще где-то. Тем более, исходники можно выложить в сети и в статье на них ссылаться. потому как статьи - это пожизненно, а тексты из сети лет через 10 могут и удалить.
А для чего нужны статьи я написал в КиТ №11 за 14 год. Они нужны не для того, чтобы все знали о том как писать программы для... А для того, чтобы получать приличную зарплату.

[zltigo]

Нынче так - или вы показываете свои сорсы на github-е или ваши слова про программирование малого стоят.

Слова, слова по любому малого стоят, хоть напечатанные на "github-е" хоть нет. Стоит результат программирования.

Когда говорят о такой запредельной абстракции как некий "I/O менеджер" исходники надо показывать в обязаловку.

Запредельные и не очень абстракции много лучше описываются не на языке Cи, а на более высокоуровневых языках, например, русском .

[iosifk]

Слова, слова по любому малого стоят, хоть напечатанные на "github-е" хоть нет. Стоит результат программирования.

Вы не правы.
"результат программирования" - это товар. И инженерный опыт - это тоже товар. И его надо уметь продавать, ибо товар надо превратить в деньги... Для того, чтобы продавать нужны "слова"...
А разговор о том, что "слова по любому малого стоят" - смотрите на время, затрачиваемое на рекламу по телевизору. Как по Вашему это время, затрачиваемое на рекламу " по любому малого стоит"?

[Укушенный воблой]

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

На самом деле "многочисленные IF/ELSE (SWITCH/CASE)" - это фундаментальная проблема программирования которая пока никак не решена. Даже в том же пресловутом ООП.
А ведь эти "IF/ELSE (SWITCH/CASE)" - есть ГЛАВНАЯ причина трудно модифицируемости программы и появления трудно отслеживаемых ошибок, возникающих при внесении изменений в программу.

Но пока что универсальной пилюли (программирование без if..then..else) не изобрели.
Хотя отдельные попытки предпринимаются.

[ViKo]

Но пока что универсальной пилюли (программирование без if..then..else) не изобрели.
Хотя отдельные попытки предпринимаются.

Массив указателей на функции, например.

[Укушенный воблой]

Массив указателей на функции, например.

Коллега уже хорошо сказал про такие "рецепты":

Рецепт из серии - если у Вас болит зуб - прищемите палец дверью...

Т.е. Вы хотите спрятать логику (закодировав её в номерах функций), чтобы программу стала еще более не понятной и запутанной.
Это по Вашему хорошее решение?
Типа "болит голова - ампутируем голову"?

Сообщение отредактировал Укушенный воблой - Jan 6 2017, 09:40

[syoma]

А I/O менеджер и менеджер коммуникаций звучат слишком похоже.

Фундаментальное отличие между ними в том, что I/O менеджер работает в реальном времени и взаимодействует с физическим железом. Причем делать он это может как напрямую - через драйверы HAL, так и через последовательные интерфейсы - CAN, SPI,RSXXX и пр. В одном проекте у нас вообще используется EtherCAT мастер с временем опроса в 100мкс.

Контроллер коммуникаций наоборот, работает не в реальном времени. Например он может работать под обычной операционкой. Его задачей является связь со всеми остальными интерфейсами, которым не нужно реальное время. Например все Ethernet коммуникации типа веб-серверов, ФТП и пр. Обработка клавиатуры, дисплея.

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

[ViKo]

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

Я думаю, вы неверно цитируете коллегу по данному поводу.
Массив упорядочивает реагирование на внешние сигналы.
Например, у меня так сделана работа с панелью управления прибором.
Функции имеют названия, соответствующие органам управления. А указатели на них упорядочены в массиве, согласно номеру кнопки на панели. Причем, в массиве есть указатели даже на несуществующие номера кнопок. На пустые функции. А когда понадобилось, добавляю.

[AlexandrY]

о I/O менеджер работает в реальном времени и взаимодействует с физическим железом.... у нас вообще используется EtherCAT мастер с временем опроса в 100мкс.

EtherCAT это и есть коммуникация. А "I/O менеджер" это, как понимаю, у вас простой маппер.
Все надо называть своими словами.

Не, без сорсов вы только зря тратите время на объяснения.

[Укушенный воблой]

В одном проекте у нас вообще используется EtherCAT

Расскажите про EtherCAT

А то мы в Москве перебрали СОТНИ организаций но так не нашли ни одного толкового спеца по этер кату.

Скажите название Вашей организации?

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

Это не универсальное решение и при том очень простой задачи. Это очередные "костыли".
От фундаментальной проблемы (наличие огромного числа "if..then..else" в сложных программах) это не помогает избавиться

Сообщение отредактировал Укушенный воблой - Jan 6 2017, 11:43

[dm37]

"Буратино", всё таки предложу ещё раз посмотреть книжку Андрей Александреску "Современное проектирование на C++" и всё что с ней связано (у людей уже есть наработки в этой области - приводил выше),
Прочитайте стр.17 (предисловие) - написано прямо то что вы хотите.
книга

[ViKo]

Это не универсальное решение и при том очень простой задачи. Это очередные "костыли".
От фундаментальной проблемы (наличие огромного числа "if..then..else" в сложных программах) это не помогает избавиться

Универсальных решений не бывает. Я показал один из примеров. Условных выполнений у меня хватает, но я не вижу это проблемой. Вопрос выбора есть всегда, иначе и программировать ничего не придется. То, что вы называете фундаментальной проблемой, на самом деле - реальность мироздания. "Щелкни кобылу в нос..." (с)

[aiwa]

Т.е. Вы хотите спрятать логику (закодировав её в номерах функций), чтобы программу стала еще более не понятной и запутанной.
Это по Вашему хорошее решение?

Совершенно наоборот: кодирование логики в номерах функций в случае, когда switch/case-реализация становится запутанной хотя бы из-за ее размера.
Недостатки лишь в издержках на вызов функций.

[haker_fox]

"Что-то аппаратное" есть во всех Cortex-M - MPU. Использую MPU в всех своих проектах на Cortex-M обязательно. А почему собственно его не использовать?
Только предохранить какую-то конкретную переменную с помощью него конечно затруднительно. Зато при отладке MPU очень часто помогает.

Я думал, может в kinetis что-то "сбоку" прикрутили, дополнительно. А вы MPU используете "сами" или в составе тойже FreeRTOS?

"Что-то аппаратное" есть во всех Cortex-M - MPU

В M0 нету

[HardEgor]

А для чего нужны статьи я написал в КиТ №11 за 14 год. Они нужны не для того, чтобы все знали о том как писать программы для... А для того, чтобы получать приличную зарплату.

Упс, интересно как мне повысят зарплату за статьи?
Но прочесть не получится: "Статьи последних номеров доступны только в печатном варианте. Вы можете приобрести свежие номера журнала «Компоненты и технологии» в свободной продаже или заказать в редакции. Извините за доставленные неудобства."

[Укушенный воблой]

Универсальных решений не бывает. Я показал один из примеров.

Я и сказал. "Очередной костыль", а не решение

Условных выполнений у меня хватает, но я не вижу это проблемой.

"А слона-то он и не заметил"©
Т.е. ФУНДАМЕНТАЛЬНУЮ проблему программирования Вы просто не заметили.
вы молодец.

Вопрос выбора есть всегда, иначе и программировать ничего не придется. То, что вы называете фундаментальной проблемой, на самом деле - реальность мироздания. "Щелкни кобылу в нос..." (с)

На самом деле есть методы которые сокращают число IF-ов в программе, которые программист ЛИЧНО, "ручками" должен написать.
Взять к примеру повяление ЯВУ в коце 40-х годов прошлого века.
Если посмотреть число IF-ов в СИ программе и сгенерированном из неё машинном коде, то можно заметить, что число IF-ов при переходе от разработки программы в машинных кодах к разработке на ЯВУ число IF-ов сократилось как минимум на порядок.
За счет чего?
За счет того.
Что компилятор БОЛЬШИНСТВО IF-ов генерит автоматически освобождая от этой тупой работы программиста.

Т.е. чем выше уровень языка - тем меньше IF-ов нужно писать программисту для решения одной и той же достаточно сложной задачи.

[zltigo]

Недостатки лишь в издержках на вызов функций.

Для этого функции инлайнятся, и/или макросы использовать. Причем макросы использовать по любому очень широко заменяя ими даже одиночные строчки и давая им осмысленные названия. Размеры switch уменьшаются, читабельность увеличивается. Из самого switch естественным образом выделяется большая функция изменения состояния автомата. В этой функции и отладка и все необходимые действия и установки по переходу В определенное состояние автомата. Количество обозреваемых строк уменьшается и увеличивается глобальная читабельность.

[syoma]

EtherCAT это и есть коммуникация. А "I/O менеджер" это, как понимаю, у вас простой маппер.
Все надо называть своими словами.
Не, без сорсов вы только зря тратите время на объяснения.

AlexandrY, сорцы высокопроизводительной системы с EtherCAT, VxWorks и прочими плюшками я выкладывать не собираюсь, так как это ни как ни опенсоурс. Только могу сказать, что это работает, хотите верьте, хотите нет.
EtherCAT отличается от остальных коммуникаций тем, что работает в real-time, поэтому он и часть I/O Менеджера, и не входит в менеджер коммуникаций. Ему также выделяется отдельный Ethernet порт, в то время как менеджер коммуникаций может реализовать различные протоколы на одном и том же порте. Раньше мы вместо EtherCAT использовали Profibus.

[iosifk]

Упс, интересно как мне повысят зарплату за статьи?
Но прочесть не получится: "Статьи последних номеров доступны только в печатном варианте. Вы можете приобрести свежие номера журнала «Компоненты и технологии» в свободной продаже или заказать в редакции. Извините за доставленные неудобства."

Так за 2014 год же доступно все... И там все написано...
Или могу по скайпу перебросить...

[jcxz]

Я думал, может в kinetis что-то "сбоку" прикрутили, дополнительно. А вы MPU используете "сами" или в составе тойже FreeRTOS?

"сами"

В M0 нету

Значит от M3 и выше.

[AlexandrY]

AlexandrY, сорцы высокопроизводительной системы с EtherCAT, VxWorks и прочими плюшками я выкладывать не собираюсь,...

VxWorks есть в наших закромах, так что можете не выклывать раз такой жадный.

А вот менеджер если он весь такой абстрактный и платформенно независимый могли бы выложить.
Или хотя бы назвать его метрики типа количества строк, функций, модулей, файлов и проч.

Но боюсь нет у вас никакого "менеджера", а есть набор функций и промежуточного софта, то что я назвал фреймворком.
VxWorks вы уже назвали, там есть и файловая и TCP стек и USB и проч. Стоит это добро дикие деньги.

Так что ваша "архитектура" совершенно не вписывается в контекст темы

[Огурцов]

Я с вариантами разберусь,

вы уж разберитесь сначала

а вы пож. не постите ерунду больше.

ерунда == писать под восьмибитники

[desh]

Чего мне не хватает так это инструментов для реализации бизнес логики и меня не устраивает не только сложность с написанием ПО, но и самое главное сложности с его модификацией.

Присмотритесь

[syoma]

Присмотритесь

Ну зачем так сразу мордой об асфальт? Современным аналогичным инструментом такого вполне являются UML и Matlab/Simulink.
Но ТС так и не сказал, что такое "бизнес-логика" в его программах. А без этого сложно советовать какие-либо инструменты.

[Guest_TSerg_*]

Сложные программы..
Угу, посмотрел бы я на любителей MCU после того как их ознакомили с современными БИУС.

[BackEnd]

Угу, посмотрел бы я на любителей MCU после того как их ознакомили с современными БИУС.

Ну ознакомились бы, перестали б в цирке смеяться. Делов-то, не они первые, не они последние...

[Буратино]

Огурцов, не хамите. Я в этом деле первый после Бога и шансов у Вас ноль в данной плоскости общаться.
Что касается 8ми битников, то для меня этот вопрос на столько же очевиден как и для всех остальных в этой теме. Не нужно открывать глаза на истину, о которой уже всем известно. Однако, во-первых мои задачи с легкостью размещаются в рамках 8ми битников, а во-вторых куда собственно денутся все проблемы о которых я пишу при переходе на кортекс? И еще раз персонально для Вас: я ничего не имею против кортекс и понимаю что это неотъемлемый атрибут современного мира контроллеров. Но не нужно ими тыкать. Это совершенно иной уровень задач: стеки протоколов, ОС, экраны, сложные вычисления.

Что касается данной темы, то я думаю, что максимум для 8ми битника (в моем случае) это:
1. Разбивка кода на части с разделением функциональности в отдельных с файлах.
2. Структуры массивы и указатели
3. Подсистема таймеров. Это когда я могу дать некое имя виртуальному таймеру и работать с этим таймером. Стартовать, проверять значение, сбрасывать. Таких таймеров может быть столько сколько необходимо. ТИк - одна миллисекунда.
4. Подсистема сообщений. Это когда я могу отправить сообщение от одной части ПО к другой. Сообщение может быть "персональное" либо широковещательное.
5. Объекты. Эти программные конструкции которые поддерживают все вышеперечисленное и помогают перейти на несколько более высокий уровень абстракции. Объекты взаимодействуют с окружением используя методы и свойства.

[BackEnd]

Смотрю в сторону объектно ориентированных принципов построения ПО

Про ООП думаю так: https://electronix.ru/forum/index.php?showt...p;#entry1445527

а также подумываю над идеями из теории ОС

Зависит от требований к изделию. В определенных случаях ОС и ее элементы хороши, в других это может вредить делу. Где целесообразно, там применял ОС-образные подходы для МК и ПЛИС.

Что касается данной темы, то я думаю, что максимум для 8ми битника это:
1. Разбивка кода на части с разделением функциональности в отдельных с файлах.
2. Структуры массивы и указатели
3. Подсистема таймеров. Это когда я могу дать некое имя виртуальному таймеру и работать с этим таймером. Стартовать, проверять значение, сбрасывать. Таких таймеров может быть столько сколько необходимо. ТИк - одна миллисекунда.
4. Подсистема сообщений. Это когда я могу отправить сообщение от одной части ПО к другой. Сообщение может быть "персональное" либо широковещательное.
5. Объекты. Эти программные конструкции состоят из всего вышеперечисленного и помогают перейти на несколько более высокий уровень абстракции. Объекты взаимодействуют с окружением используя методы и свойства.

Пункты 1 и 2 для меня инвариантны относительно выбранного МК. Об организационно-технологических пунктах 3-5 я бы думал после изучения ТЗ на конкретное изделие.

Сообщение отредактировал BackEnd - Jan 8 2017, 08:59

[syoma]

А вот менеджер если он весь такой абстрактный и платформенно независимый могли бы выложить.
Или хотя бы назвать его метрики типа количества строк, функций, модулей, файлов и проч.
Но боюсь нет у вас никакого "менеджера", а есть набор функций и промежуточного софта, то что я назвал фреймворком.
VxWorks вы уже назвали, там есть и файловая и TCP стек и USB и проч. Стоит это добро дикие деньги.
Так что ваша "архитектура" совершенно не вписывается в контекст темы

Вы понимаете вообще разницу между архитектурой и реализацией? Я привел I/O менеджер как некую абстракцию - часть ПО системы управления. Как он будет реализован на практике в конкретной платформе - зависит от множества факторов и я специально этого не касался. Примеры I/O менеджеров для различных систем управления:

8-и битный контроллер - да, обыкновенный маппер с дефайнами и функциями

Система с RTOS, как у меня - описал выше

Промышленный ПЛК - смотри Codesys и МЭК 61131-3 - там есть свой I/O менеджер.

Контроллер управления умным домом - вам непонятный OpenHAB.

І/O менеджер как раз очень платформозависимый, но на уровне архитектуры- абстракции он служит для выполнения одних и тех-же задач, что доя 8-и, что для 64-х битника

Что касается данной темы, то я думаю, что максимум для 8ми битника (в моем случае) это:
1. Разбивка кода на части с разделением функциональности в отдельных с файлах.
2. Структуры массивы и указатели
3. Подсистема таймеров. Это когда я могу дать некое имя виртуальному таймеру и работать с этим таймером. Стартовать, проверять значение, сбрасывать. Таких таймеров может быть столько сколько необходимо. ТИк - одна миллисекунда.
4. Подсистема сообщений. Это когда я могу отправить сообщение от одной части ПО к другой. Сообщение может быть "персональное" либо широковещательное.
5. Объекты. Эти программные конструкции которые поддерживают все вышеперечисленное и помогают перейти на несколько более высокий уровень абстракции. Объекты взаимодействуют с окружением используя методы и свойства.

Это нужно для вашей "бизнес-логики"? Что же это за штука такая? Ну дайте понять где нужно давать имена таймерам и широковещательные сообщения. Напоминает автоматы состояний.

[Огурцов]

Огурцов, не хамите.

не говорите, что мне делать и я не укажу вам путь

Я в этом деле первый после Бога

каким образом, если вы даже не врубаетесь, что это позволяет не напрягаясь реализовать:

1. Разбивка кода на части с разделением функциональности в отдельных с файлах.
2. Структуры массивы и указатели
3. Подсистема таймеров. Это когда я могу дать некое имя виртуальному таймеру и работать с этим таймером. Стартовать, проверять значение, сбрасывать. Таких таймеров может быть столько сколько необходимо. ТИк - одна миллисекунда.
4. Подсистема сообщений. Это когда я могу отправить сообщение от одной части ПО к другой. Сообщение может быть "персональное" либо широковещательное.
5. Объекты. Эти программные конструкции которые поддерживают все вышеперечисленное и помогают перейти на несколько более высокий уровень абстракции. Объекты взаимодействуют с окружением используя методы и свойства.

[agregat]

Ну ознакомились бы, перестали б в цирке смеяться. Делов-то, не они первые, не они последние...

Я может не в той оборонке работал, такое впечатление...

А автору советую взять AT91SAM7 установить на него операционку и тупо делать все дизайны под RTOS. Все проблемы потихоньку рассосутся сами собой.

[syoma]

Я может не в той оборонке работал, такое впечатление...

Может он имел ввиду зарубежные современные БИУС?

[-SANYCH-]

А автору советую взять AT91SAM7 установить на него операционку и тупо делать все дизайны под RTOS. Все проблемы потихоньку рассосутся сами собой.

Под RTOS еще нужно уметь писать. Можно такое намудрить что потом не отладишь.
Как на меня так совет абсолютно не имеет смысла (в плане понимания построения программы).
RTOS ускоряет и облегчает разработку, но главное это понимание как и где его использовать.

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

Если у кого есть примеры, или ссылки поделитесь плиз

Приведите примеры где это все инициализировать (например массивы указателей )как его использовать (только живой код с примером кратким, но достаточным для понимания).

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

[AlexandrY]

Приведите примеры где это все инициализировать (например массивы указателей )как его использовать (только живой код с примером кратким, но достаточным для понимания).

Эт вы просите разжёванный и положенный в рот учебный материал, а не живой код.

Живой код я показал в первом же ответе в этой ветке.
Вот еще раз ссылка на него

Там есть и RTOS, и как делается мапинг сигналов получаемых по сети CAN c массивами указателей и как сделать 100 машин состояний работающих по скриптам с тактом в 5 мс.
И как при этом управлять устройставми с тактом в 62 мкс. И одновременно осциллографировать сигналы на PC по HS USB и писать в лог на SD карту и т.д. и т.п.

Но что-то никто не форкает эти исходники для изучения, а смотрело всего пару человек.
На самом деле чей либо код никого не интересует

А учебный материал стоит дорого. Потому и тех. поддержка RTOS стоит дороже самих RTOS.
Я конечно не имею в виду здесь малофункциональные экзерсисы типа ScmRTOS

[Буратино]

Огурцов, сори, но Вы не в теме. Просто не понимаете, что я пишу и о чем. Первый после Бога я в смысле навыков хамить! А вот что касается контроллеров то обратите внимание где создана тема и что в ней обсуждается.

еще раз: RTOS это не эта тема. Нужна ОС там где люди работают в том числе с чужими стеками протоколов, с чужими программами и модулями. Вот представьте себе: вам нужен езернет, усб, доступ к файлам на карте памяти и работа с сенсорным экраном. Естественно вы возьмете готовые либы, но кто знает как все это внутри устроено!? А работать то должно все вместе Вот тут то и приходит на помощь ОС. Проц занимается последовательно задачами ,ну естесна с приоритетами и прочими фишками. Мне не нужно и не интересно. Пока. Дальше видно будет.
ООП тош интересно. ОЧень, но опять же не здесь и не сейчас.

Я говорю о другом.

[Укушенный воблой]

меня не устраивает не только сложность с написанием ПО, но и самое главное сложности с его модификацией.

Вам же сказали, что ФУНДАМЕНТАЛЬНАЯ проблема программирования (наличие большего числа "IF...THEN...ELSE" в разных вариациях и формах) пока что не решена.
Отсюда код ТРУДНО модифицируемый. Отсюда баги при модификации.

Нужен инструмент который будет контролировать ЦЕЛОСТНОСТЬ "бизнес-логики" при изменениях программы и синхронность+законченность этих изменений в разных взаимосвязанных частях программы.

Но он пока не изобретен.
Так что если Вам удасться его изобрести - Вы будете первым в мире.

Сообщение отредактировал Укушенный воблой - Jan 8 2017, 13:29

[SlavaV]

Буратино,

лично моё мнение, все Ваши проблемы решаются знанием основ системотехники (умением в принципе разрабатывать), а в частности ООП.

Второе Вы считаете, что Вам достаточно 8-ми битников, тогда я Вам завидую, Вы трудитесь в неконкурентной среде.
Поясню: стоимость разработки складывается из элементов (здесь все производители постарались и M0 стоит дешевле вашего 8-ми битника) и времени разработки (что позволяют современные IDE для современных контроллеров Вам уже тоже говорили).

[Огурцов]

Вам же сказали, что ФУНДАМЕНТАЛЬНАЯ проблема программирования (наличие большего числа "IF...THEN...ELSE" в разных вариациях и формах) пока что не решена.

ещё раз: выносите каждый then/else в свой камень
это позволяет реализовать задачу один раз и больше к ней не возвращаться

Но он пока не изобретен.

от чего же ? бизнес-логика должна быть вынесена и скрипты уже называли

[Буратино]

Буратино,
лично моё мнение, все Ваши проблемы решаются знанием основ системотехники (умением в принципе разрабатывать), а в частности ООП.

Вот видите, Вы все обо мне знаете: И где я работаю, и чего мне не хватает. Не понял только одного: по теме то есть что сказать? )
В сотый раз: все супер с кортексами, но мне пока хватает классики. И снова подчеркиваю, что никуда вопросы которые меня лично волнуют не денутся при переходе не только на картекс но и на большого брата. А ООП это вообще отдельная тема, сомневаюсь что тут много людей способных пусть даш себе растолковать накой оно им нужно в мире мк.

[SlavaV]

У Вас название темы "Сложные программы"

назовите пожалуйста единственную причину появления ООП

PS Всё, что я написал относиться к вашей теме непосредственно.

[gerber]

Нужен инструмент который будет контролировать ЦЕЛОСТНОСТЬ "бизнес-логики" при изменениях программы и синхронность+законченность этих изменений в разных взаимосвязанных частях программы.

Но он пока не изобретен.
Так что если Вам удасться его изобрести - Вы будете первым в мире.

Почитайте что-нибудь про юнит-тесты.

[Укушенный воблой]

А вообще, ИМХО, топикстартер просто не специалист в программировании отсюда программирование ему кажется таким сложным. Поэтому решение для него - просто нанять толкового программиста и не заниматься не своим делом.

Я вообще не понимаю: какие могут быть сложности в "ногодрыганье" к которому сводится программирование МК?
В то время как написание даже простейшего парсера - на порядок более сложная для "железячника" задача. А для программиста "раз плюнуть".

Поэтому повторюсь: наймите программиста.

[Буратино]

детский сад.

[HardEgor]

еще раз: RTOS это не эта тема. Нужна ОС там где люди работают в том числе с чужими стеками протоколов, с чужими программами и модулями.

Вы несколько путаете следствие и причину - ОС нужна для разделения ресурсов несколькими задачами. А также она дает единый интерфейс задачам, что позволяет абстрагироваться от реализации ресурсов, что как следствие создает удобство при использовании чужих модулей/программ. Но не наоборот Так-то чужие модули/программы отлично работают и без ОС.

Я так и не увидел в чем ваши сложности, если не получается выразить словами, то приведите примеры кода.
У меня сложилось впечатление, что все ваши программы это один большой main.c и вам надоело переписывать его каждый раз заново, вот и спрашиваете как упростить написание....

[aiwa]

Естественно вы возьмете готовые либы, но кто знает как все это внутри устроено!?

Можно выбрать либы с открытыми исходникми, чтобы знать как внутри устроено.

Вот тут то и приходит на помощь ОС. Проц занимается последовательно задачами ,ну естесна с приоритетами и прочими фишками. Мне не нужно и не интересно.

Аналогично: взять операционку с открытими исходниками и лезвие Оккамы. И оставить лишь то, что интересно.

[Эдди]

Как по мне, так ртось как раз и надо бритвой Оккама вырезать!

[Guest_TSerg_*]

Для меня и Windows NT - тоже RTOS.