не убедили. Вы привели пример плохой реализации алгоритма. Смена режима может быть прописана в коде самой функции задачи, ну вроде "если режим 1 выполняй если режим 2 на выход". А пример ваш не свидетельсвует о негодности алгоритма. На любом автомобиле можно въехать в стену - это не свидетельства плохого качества автомобиля.

Сообщение отредактировал Onkel - Aug 21 2015, 07:59

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

Сообщение отредактировал demiurg1978 - Aug 21 2015, 08:08

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

Сообщение отредактировал Onkel - Aug 21 2015, 08:15

Не торопитесь. Давайте продуктивно обсудим.

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

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

Сообщение отредактировал demiurg1978 - Aug 21 2015, 08:27

1 моргать - ну примерно моргать, но посложнее- у меня шим светодиодный, прерывание по таймеру смотрит - включить, выключить, или ничего не делать, сравнивает текущую переменную (счетчик) с установкой шим (0-255), если счетчик <установки - включате, иначе- выключает. Меняем режим - меняем установку шим, приходит время обработать , вызывается прерывание по таймеру - а у нас установка шим стоит какая надо для этого режима. Так и работают 8 канальные шимы, 8же (2х4 фазные обмотки) контроллеры шаговых 4хфазных униполярных двигателей. В вашем примере - раз в секунду вызываем функцию "моргать светодиодом", а в функции этой есть свич (например) по переменной "режим".
2 похожая задача - управление шаговым двигателем с концевиками. Данные с концевиков обрабатываются раз в миллисекунду (по главному таймеру прерывание ), вызывается по другому таймеру периодически (собственно период есть период переключения обмоток шаговиков) функция управления выходами подачи напряжения на шаговики, если переменная "концевик начало" или "концевик конец" единица то прокрутку (шаг шаговика) в "ненужную" сторону не делаем. Теперь , если у нас сработал концевик "конец по часовой", мы можем хоть тысячу раз командовать "100 шагов по часовой" - шаговики по часовой не повернутся. Собственно как я и писал - параметр "номер режима" обрабатывается и внутри функции.

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

Сообщение отредактировал Onkel - Aug 21 2015, 09:19

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

Ладно, закончен спор, так закончен. В данном случае всего лишь дело вкуса, не более. О целесообразности и речи нет.

диспетчер расставляет задачи по приоритетности и вызывает соотвутствующие функции. Если на очереди задачи 1 4 6, то он сначала вызывает функцию задачи с наивысшим приоритетом и т.д. Собственно да, дело вкуса- но речь идет именно о мини - операционке, и если я хочу симисторный диммер переделать в светодиодный диммер, мне нужно будет поменять лишь одну функцию, не затрагивая прием / передачу по uart, анализ входов и т.д., то же самое если нужен контроллер шаговых двигателей - в готовой программе меняем лишь одну функцию. Я когда задумал серию периферийных модулей для своих задач ( 8 реле, 8 входов, 8 светодиодных светильников, 8 симисторов, ...8 датчиков температуры/8 реле, смс.. ...) сначала разработал скелет - как раз ту операционку, которой вы приписали дамокловость меча, а потом уже писал функции под конкретные модули. А пришел я к этой "операционке" как раз потому, что начал запутываться в "условиях, свичах или индексных переходах по переменной состояния"....

пы сы что- то не могу из ящика, дублирую тут
не, самописанный. Идея очень простая
- 8 функций, например
прием и обработка байта уарт
отправка 8 байт через уарт
посылка данных на дисплей
...
8 - потому что 8 бит в char переменной zadania, диспетчер (он только и есть в теле, все остальное - в функциях и программах обработки прерываний по таймерам) постоянно крутиться в main(), вычисляет задачу из переменной zadania с максимальным приоритетом (это нетрудно - чем выше бит выставлен в 1 - тем приоритетнее задача) и вызывает соотв. функцию. Чтобы задачи с малым приоритетом не завешивали, все функции написаны так, что они за вызов делают (возможно) не всю работу, занимая не больше отведенного им времени, и возвращают управление диспетчеру, не выставляя свой бит в нуль - если функция не завершила работу. Если более высокоприоритетных задач не появилось, то менее приоритетные задачи продолжают, пока не сделают что нужно и не выставят свой бит в 0. Ну а биты функций выставляет либо таймер(это для ацп, актуализации реле/мосфитов (выходов мк), либо прерывание по получению байта uart, либо прерывание внешнего прерывания. Вот так они и крутятся, не мешая друг другу, в полном соответсвии с оригинальной идеей. Сам я ее читал не на сайте, а в журнале хакер (бумажном) году так еще в 2006-2007, соответсвенно потом его посеял и делал по памяти. Но потом, по прочтении ряда книжек по эмбеддингу оказалось, что все не противоречит и высокой науке тоже.

Мои правила написания программ:

Весь набор правил подчиняется главному условию - псевдопараллельность процессов. Каждый процесс при каждой итерации выполняет часть кода.

Модульность. Стараемся делать все модули самостоятельными.

Никаких долгих циклов.

Разбиение функций на подзадачи. Стремимся к тому, чтобы все модули быстро выполняли свой код. Вход в функцию, выполнение кода, выход. Проверка условий, выполнение кода, выход. Разбиение на подзадачи осуществляется флагами, условиями, состояниями конечных автоматов.

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

Программные таймеры. Я перелопатил таймерную службу взятую у ди хальта. И перенес ее в основной цикл. Настриваем аппаратный таймер на 1 мс, если кварц на 8 или 16 МГц. Или 10 мс, если кварц для uart. В прерывании выставляется флаг. В службе проверяется флаг. если флаг установлен, сброс и перебор очереди программный таймеров. Структура таймера - статус, 16-битный счетчик.

Итерация основного цикла должна с запасом впаковаться в тик системного таймера. То есть, 1 мс или 10 мс.

Проекты при таком подходе создаются как конструктор из кирпичиков модулей.

Нет затрат на перебор диспетчером задач. Установку задач в очередь, удаление задач из очереди.

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

Основной цикл этого проекта:


Сообщение отредактировал demiurg1978 - Aug 21 2015, 14:44

Конечно от конкретной задачи таймера это делеко, но понять вообще в каком ключе нужно мыслить, разрабатывая рахитектуру помогают книги
1. Совершенный код(макконнелл)
2. Паттерны проектирования(банда четверых) http://www.ozon.ru/context/detail/id/2457392/

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

вряд ли эти книги будут полезны в работе с мелкими мк. По мелким мк есть свои книги.

Подскажите какие именно книги по мелким МК ?

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

Знакомое сочетание. easyelectronics.ru?

Я понял,спасибо!