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

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

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

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

Тоже есть опыт использования продукции Овен, есть работающие проекты на ПЛК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 (не знаю как сейчас).

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

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

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

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

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

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

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

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

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

Protothreads в помощь

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

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

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

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

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


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

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

Что касается архитектуры ПО для системы управления, то у меня сложилась следующая архитектура, которую я реализовал не в одном успешном проекте:
К основным модулям данной архитектуры относятся: 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 сигналов.

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

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