[AlexandrY 3]

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

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

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

По моему суть вашей "сложности" недостаточно раскрыта.

Может вам просто нужно провести рефакторинг.

По сути переход на ООП это будет рефакторинг и больше ничего.

 

Может вы еще 20-и часов не провели со своим кодом.

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

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

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

Там многофайловые проекты можно написать?

[zltigo 2]

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

Именно так. Есть ГОСТ 34.602-89

Когда речь идет о сколь нибудь сложных системах по другому нельзя, ибо заказчик в 99 случаях из 100 полный ноль в предметной области.

 

[dm37 0]

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

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

. . . .

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

Как один из вариантов использования ООП для Вас.

(1) Если есть наработки для малых МК - можете рассмотреть возможность создания своего "компилятора".

Это на базе PC.

(2) В разрезе программирования МК. Если не использовали структуры - начинайте исползовать.

В структуры интегрируйте как данные, так и указатели на функции-обработчики этих данных.

Это можно делать на базе С - без плюсов. Эти структуры с разной инф. набирайте в массив.

Например, задача, которая решается элементарно таким способом - сложное меню.

Без единого switch-case и с одной "управляющей" функцией :)

 

"маленьких камней" - это как ?

Контроллер с Flash=32k + RAM=8k я маленьким я не считаю.

В контексте использования, например, scmRTOS это вполне достаточные ресурсы.

Вот когда Flash=1k + RAM=512 - это нечто :) Туда бы OS я и не думал, хотя есть и такие весчи.

Но это скорее не ОС а "планировщик" выполнения кода.

 

 

[Буратино 0]

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

 

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

Я понимаю, что RTOS это то без чего нельзя представить себе мир контроллеров, но вполне себе пока проживет мир RTOS без меня.

 

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

[k155la3 27]

. . .

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

Берете туже scmRTOS.

ОНО сделано на C++. Смотрите исходник как да что. И разницы, какой контроллер - большой или малый, нет.

Просто для контроллера с очень малыми ресурсами - IMHO - использовать класы, наследование, вирт. функции итд итп - смысла не имеет.

А имеет смысл (то что я сказал выше) разработка своего специализированого компилятора.

Точнее пре-компилятора для компилятора С или ASM. Вот тут можете на PC "разгуляться" c ООП и всеми его возможностями.

[Буратино 0]

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

[k155la3 27]

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

Ну так Вы и так из своих "наработок", думаю, постоянно собираете код проекта.

Или каждый раз пишите все с нуля ? По сути - ЭТО - есть компияция вручную :)

 

 

[VCucumber 0]

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

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

 

[Drozd2 0]

Protothreads в помощь

[k155la3 27]

Protothreads в помощь

Начал почитать.

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

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

 

 

 

[haker_fox 61]

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

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

[AlexandrY 3]

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

 

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

Зачем платить писать больше если нет разницы?

 

C++ был придуман для коллективной разработки.

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

Только лишним множеством имён загрузитесь, потеряете производительность.

 

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

 

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

Cortex-M3 давно уже не использую.

Не понял связи ошибки памяти с фреймворками.

[syoma 1]

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

 

Что касается архитектуры ПО для системы управления, то у меня сложилась следующая архитектура, которую я реализовал не в одном успешном проекте:

К основным модулям данной архитектуры относятся: 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 242]

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

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

Изменено 5 января, 2017 пользователем Herz
Нарушение п.2.1.г Правил