caxapa.ru :: Мой совет - не плоди автоматы и связи между ними, лучше добавь состояния в один автомат, чтобы все было прозрачно и понятно. Сообщения на дисплей должен выводить один автомат. И вообще, автомат - это костыль вместо ОС, чтобы иметь возможность

Vladimir Ljaschko (06.09.2011 09:30, просмотров: 560) ответил mazur на Может это частная проблема, может,я все не так делаю... Посидел, подумал, почитал. Получается решение моих проблем одно-общая для всех автоматов область памяти. Иначе чтение\запись всевозможных параметров раздует код. Перебрал все скачанные

Мой совет - не плоди автоматы и связи между ними, лучше добавь состояния в один автомат, чтобы все было прозрачно и понятно. Сообщения на дисплей должен выводить один автомат. И вообще, автомат - это костыль вместо ОС, чтобы иметь возможность прервать обслуживание одного процесса и дать время другим, какие там нахрен сообщения между автоматами, ты же ассемблерщик, используй как обычно глобальные переменные. Или это и есть "общая область памяти" - сложно продираться через придуманные термины.

Ответить

- При объединении автоматов число состояний обоих следует перемножить... в первом приближении. Дурная идея. На счёт костылей и подавно. Какая ОС позволит полсотни параллельных процессов? Если про PIC-контроллеры говорить. ОС с вытеснением нужна для fk0(137 знак., 06.09.2011 10:04)
  - :) пеши есчо - Vit(06.09.2011 11:22)
  - Ну не надо крайностей. У меня обычно 3-4-5 автоматов. Откуда 50? Разве что ничтожные сервисы типа отправки через циклический буфер автоматами называть. - Vladimir Ljaschko(06.09.2011 11:09)
    - А у меня около 100 в текущем проекте. Многие из них независимы и могут находиться в произвольном состоянии, когда другие находятся в своих произвольных состояниях. Потому и перемножаются (это верхний предел числа состояний, понятно). И даже по fk0(130 знак., 06.09.2011 11:58)
      - Если независимы, то и сообщения между ними не передаются, да? - Vladimir Ljaschko(06.09.2011 12:49)
        
        Но не каждый от каждого зависимы, и не настолько, чтоб мешать их логику между собой. - fk0(06.09.2011 12:52)
        
        ОК. Я не претендовал на абсолютную истину для случая независимости. Только вопрос - и что, полсотни действительно автоматов с переменной состояния и switch/case или functions[state]? - Vladimir Ljaschko(06.09.2011 13:13)
        
        switch/case и переменная состояния. Ближе к сотне скорей, точно посчитать сложно. А что поделать, какие альтернативы? Да, притормаживает в цикле, каждый раз дурную работу switch(S) делать. Есть проблемы с приоритетами (для этого, критичное, в fk0(1151 знак., 06.09.2011 14:49)
        
        По поводу: mazur(175 знак., 07.09.2011 09:56)
        
        Потому, что: 1) это мало что поменяет -- в каждом состоянии ещё условия проверяются. Ну даст экономию 20% -- легче? 2) Такой код трудно воспринимать и легко ошибиться. 3) контроллеры профессионального уровня (PIC) не имеют аппаратного стека и fk0(297 знак., 07.09.2011 11:13)
        
        По п.3 я имел ввиду подход, когда каждое состояние кодируется отдельной функцией (для проверки условий перехода), вызваемой по-указателю. "По индексу переменной состояния" -- эту оптимизацию компилятор умеет делать автоматически, для оператора fk0(216 знак., 07.09.2011 11:17)
        
        "Где бы можно было связать, в рантайме, сигналы и слоты, и таким образом полуать вызов функции, из планировщика, при возникновении сигнала. И чтоб приоритеты и, возможно, вытеснение..." Суть такая, есть события типа: "GPIO Chum_A(508 знак., 06.09.2011 17:40)
        
        " есть события " " на них назначены функции-обработчики" "очередь с приоритетом" : Система прерываний называецца ;) - Vladimir Ljaschko(06.09.2011 17:44)
        
        Ну да, фактически обработчик прерывания пихается в приоритетую очередь. А я не говорил об инновационном изобретении, уж больно на изложенные fk0 требования похоже. Да, в очередь можно встать и из user-кода. - Chum_A(06.09.2011 18:01 - 18:08)
        
        Альтернативы нет, но вопрос количества остается. А можно пример функциональности? Vladimir Ljaschko(552 знак., 06.09.2011 17:35)
        
        Когда одна задача поднимает другую задачу из IDLE, а сама уходит в IDLE - это тоже машина состояний? ЗЫ. Ещё припоминается nesos Finite State Machine OS. - Vit(06.09.2011 16:58)
- Я и не плодю или пложу... В общем, не коллекционирую автоматы. Где достаточно флагов, там на них и работаю. - mazur(06.09.2011 09:43)
  - Значит я не понимаю исходного вопроса. И вряд ли кто другой понимает. - Vladimir Ljaschko(06.09.2011 09:54)
  - Автомат - это алгоритм перехода из одного состояния в другое на основе входных сообщений. Таким образом приём сообщений от периферии или от другого автомата принципиально ничем не отличаются. Если же ты говоришь об автомате, а =AlexD=(82 знак., 06.09.2011 09:47)
    - Для меня подпрограмма работающая на состояниях-автомат. А подпрограмма на флагах-просто подпрограмма. - mazur(06.09.2011 09:50)
      - Флаги -- это такой плохой способ представления того же автомата. А когда ты говоришь об автомате -- там состояние явно выделено в одну переменную, вместо того, чтобы быть размазанным по десятку флагов (которые, в итоге, могут кодировать состояний fk0(273 знак., 06.09.2011 10:09)
        
        Вроде сформулировал, по поводу использования флагов. Я не знаю, почему ты такой противник флагов. Если нет флагов, то задачи размазываются на множество состояний. Также в одном состоянии нельзя сделать сразу несколько действий, что как раз mazur(1007 знак., 18.09.2011 09:36 - 09:39)
        
        в одном состоянии нельзя сделать сразу несколько действий Вложенные автоматы отменили? - Vit(18.09.2011 10:31)
        
        Неудачный пример - второй вариант лучше. Нет идиотских флагов, которые нужно устанавливать сбрасывать, а главное - помнить :) - Vladimir Ljaschko(18.09.2011 10:00)
        
        А по мне первый вариант лучше. Если есть однотипные действия, вот и пусть в одном месте эти действия выполняются по флагам, чем бесконечно плодить куски кода с нужным порядком действий. - mazur(19.09.2011 10:23)
        
        Я другого не понимаю. Флаги это какие-то условия, так? Почему не проверять сами условия? - Скрипач(18.09.2011 10:13)
        
        Хороший вопрос, если речь идет о локальных флагах. Видимо, все-таки предполагается некоторая обработка этих условий, или флаги внешние. - Vladimir Ljaschko(18.09.2011 11:02)
        
        Для внешних тем более. Слишком велик соблазн "не угадать" с соотношением генерации и опроса :) - Скрипач(18.09.2011 11:22)
        
        Хм... Вот и наверное, ответ. Обжегся раз и крепко-нуевонах!!! :))) - mazur(18.09.2011 17:34)
        
        Еще раз спрашиваю: зачем вам гибкость? - Скрипач(18.09.2011 21:42)
        
        Забыл добавить. Флаги многократно увеличивают скорость работы любого автомата. Или быстренько проверить локальный флаг, или отправить\принять\обработать событие\сообщение. Ты же сам сетовал, что проц тупит, пока все автоматы провернет. Где mazur(263 знак., 18.09.2011 09:51)
        
        А зачем тебе гибкость? - Скрипач(18.09.2011 09:47)
        
        Кажется насчет флагов уже была дискуссия. Я тебе попозже напишу, почему я не использую только состояния. Сейчас еще не до конца сформулировал. - mazur(06.09.2011 10:14)

Микроконтроллеры AVR