Easyelectronics.ru

Электроника для всех
Текущее время: 24 сен 2020, 20:58

Часовой пояс: UTC + 5 часов



JLCPCB – Прототипы печатных плат за $2/5шт. два слоя. $5/5шт. четыре слоя
Крупнейший производитель печатных плат и прототипов. Более 600000 клиентов и свыше 10000 заказов в день!
Получите скидку на почтовую отправку при первом заказе в JLCPCB!

Начать новую тему Ответить на тему  [ Сообщений: 177 ]  На страницу 1, 2, 3, 4, 5 ... 8  След.
Автор Сообщение
 Заголовок сообщения: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 10 фев 2020, 12:53 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 505
Постепенно стремлюсь ваять свой небольшой то ли диспетчер задач, то ли планировщик для больших проектов на МК, т.к. захотелось порядка и формальности в применении всяких опросов флагов и конечных автоматов.
Собственно говоря, требуется совет от знающей публики касаемо конечных автоматов (нет, объяснять как работают КА мне не надо, совсем о другом вопрос).
Для пущей гибкости и избавления от нагромождения switch'ей предполагаю, что каждый КА будет состоять из таблицы переходов по событиям, реализованной в виде массива функций, где индекс массива - входное событие, функция - состояние. Обработчик автомата читает из внешнего буфера входной сигнал, выбирает по нему соответствующую функцию состояния и обрабатывает ее. Здесь все в принципе просто. Но проблема встает в следующей задаче.
Допустим, у меня есть в проекте два КА, работающих в жестком реальном времени, в обход вообще всяческих планировщиков и RTOS (если таковые есть), т.к. занимаются верчением мотора. Автомат с меньшим приоритетом крутится в прерывании таймера с частотой 1 кГц, автомат с большим приоритетом - с частотой 10 кГц. Сейчас они сделаны на switch'ах и стоят во главе угла программы, могут залезать куда им нужно, читать все глобальные объекты и переменные и на их основании определять, в какое состояние переходить. Если переводить их на вышеописанную схему с буфером событий и таблицей переходов, то формально, эти автоматы должны будут читать входные события только из своего буфера, в который уже другие источники событий (еще более приоритетные прерывания, команды из сети и т.д.) будут эти события класть в виде сообщений. Отсюда выходит, что для любого КА, вне зависимости от его приоритета, все события будут буферизованные. И, скажем, для вышеописанной ситуации с двумя КА с разными приоритетами может возникнуть ситуация, когда КА с более высоким приоритетом набросал событий в буфер КА с меньшим приоритетом, в т.ч. критических прерываний (скажем, аварийных событий, требующих экстренного стопа и перехода КА в соответствующее состояние), соответственно время реакции на критическое прерывание становится "плавающим" и зависит от его позиции в буфере событий, хотя автомат при этом будет переходить по своему графу переходов корректно. Думая, как разрешить данную ситуацию, пришел к трем способам реализации чтения буфера событий.

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

2. Сделать очередь с приоритетами. На бумаге выглядит красиво: если некая сущность хочет кинуть в буфер что-то критичное, она присваивает ему высокий приоритет, и в очередь с приоритетами оно будет уложено соответствующим образом. Сообразно с идеей, КА сперва прочтет самые критичные события (а там, если что-то катастрофическое было, то и вовсе сотрет весь буфер событий и отключит, скажем, питание стойки инвертора двигателя). На практике, честно говоря, я не особенно глубоко копал в реализации очередей приоритетов, но всюду написано, что алгоритма извлечения приоритетного элемента из очереди за O(1) не существует - максимум, за O(n log n). Видел одну реализацию очереди с приоритетом - там вроде бы как извлечение за константное время производится, но, во-первых, после этого обязательно производится пересортировка очереди, а во-вторых, при закидывание элемента в буфер, оный также сортируется согласно приоритету положенного элемента - естественно, за линейное время. В общем, непонятно мне немного с ними, если кто в теме, просветите, годится ли такой вариант.

3. Развязать события из буфера и входные сигналы самого КА. Каждое состояние КА делить на две функции - одна читает буфер целиком, смотрит, чего в него наложено, согласно с прочитанными событиями меняет состояние, затем вызывается вторая функция, которая реализует требуемую логику. В следующий вызов ситуация повторяется, но уже в новом состоянии. Получается идеальный автомат Мили, прям как по учебнику - с множеством функций переходов и функций выходов. Естественно, время реакции определяется тем, насколько быстро выполнятся по очереди функция переходов и функция выходов, все детерминированно и предсказуемо на этапе говнокодинга написания алгоритма.

Извиняюсь, если все слишком сумбурно - пытался кашу в голове сформулировать как мог. Задача сама по себе несложная, но все-таки требовался совет по поводу того, какой из вышеописанных вариантов реализовать лучше с оглядкой на МК (не только жирные STM32, но также и более мелкие MSP430, к примеру).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 10 фев 2020, 13:15 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Извиняюсь, всё не прочитал.
По поводу "жесткого времени". Это обычные высокоприоритетные (или не очень высоко-) прерывания с выполнением в самом прерывании. Причем, чтобы не пропустить другое событие, приоритет текущего прерывания можно понизить прямо в прерывании, а перед выходом - вернуть обратно.
Все эти "свитчи" в прерываниях, они только удлиняют работу.
Причем, есть вариант (и я сам не раз так делал), когда вся "жестковременная" работа реализована чисто на прерываниях. А в main висит какая-нить графика или вообще ничего нет кроме wfi.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 10 фев 2020, 13:22 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 505
Ну про выполнения в прерывании я-то как раз знаю и так и делаю для ответственных вещей.
А от свитчей хочу избавиться. Но в основе все-таки лежат конечные автоматы, и от них избавляться я не планирую. Соответственно, под автоматы тогда заместо свитчей надо массивы указателей на функции. А с ними и приходит вышеописанная проблема.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 10 фев 2020, 15:02 
Старожил

Зарегистрирован: 08 июл 2013, 17:00
Сообщения: 692
Это смотрел?

https://www.boost.org/doc/libs/1_64_0/libs/msm/doc/HTML/index.html


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 10 фев 2020, 15:08 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 505
Нет не смотрел - просто потому, что boost вроде как ориентирован на ПК и ситуации, где ОЗУ и процессорного времени куры не клюют. Вроде бы даже в сети его критикуют за неважнецкое быстродействие.
Впрочем,почитаю на досуге, может рациональное зерно и найду.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 10 фев 2020, 15:14 
Старожил

Зарегистрирован: 08 июл 2013, 17:00
Сообщения: 692
Вроде...
Пока не попробуешь- не узнаешь. Тем не менее, есть от чего танцевать.

Цитата:
Executable size

There are some worries that MSM generates huge code. Is it true? The 2 compilers I tested disagree with this claim. On VC9, the test state machines used in the performance section produce executables of 14kB (for simple and eUML) and 21kB (for the composite). This includes the test code and iostreams. By comparison, an empty executable with iostreams generated by VC9 has a size of 7kB. Boost.Statechart generates executables of 43kB and 54kB. As a bonus, eUML comes for “free” in terms of executable size. You even get a speed gain. With g++ 4.3, it strongly depends on the compiler options (much more than VC). A good size state machine with –O3 can generate an executable of 600kB, and with eUML you can get to 1.5MB. Trying with –Os –s I come down to 18kB and 30kB for the test state machines, while eUML will go down to 1MB (which is still big), so in this case eUML does not come for free.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 11 фев 2020, 00:46 
Старожил
Аватара пользователя

Зарегистрирован: 28 янв 2010, 20:18
Сообщения: 591
То есть сейчас вместо очереди кучка переменных и какая-то логика выбора приоритетного события из них? Это нужно переделать на очередь и понятную всем логику приоритизации?

Может N очередей и N КА по приоритетам? Сортировка сообщений какое-то такое решение, не жесткое.

Я обхожусь одной переменной, запрос к КА. Слать их быстрее чем может обработать КА смысла нет, соответсвенно нет смысла и в очереди. Приоритет бывает только тот который определяется графом переходов. То есть есть например, запрос halt, который любое состояние переводит в цепочку останова. Другие запросы могут игнорироваться до завершения обработки уже начатого, очереди нет, просто отбрасывается.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 11 фев 2020, 10:47 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 505
Логично. Собственно, почти тоже самое, что я и описал в третьем варианте. По сути, очередь можно в битовое поле преобразовать, одно событие - один бит. В каждом состоянии читаются биты и определяется переход по графу.
Наверное, так будет лучше всего, и дает гарантию и по времени реакции, и по переходу по состояниям.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 18 фев 2020, 22:59 
Старожил

Зарегистрирован: 25 фев 2011, 18:45
Сообщения: 3685
Откуда: Новосибирск
У нас ночь. Накидаю наброски, скелет. Завтра на свежую голову посмотрю на продолжение темы.
1 - Реакция системы. Это самый главный критерий, который будет определять концепцию проекта в целом. Пример, вы делаете что-то, и там есть пресс, прессформы. Делай что хочешь, но твоя система должна своевременно отреагировать на нажатие аварийной кнопки или срабатывание датчика. Иначе оператору из-за твоего перфекционизма, красивостей (смотрите какую крутую систему я замутил, диспетчеры, ртос, свои свистоперделки), оттяпает конечность. Конечно, в данном случае это комплексное решение проблемы. Аварийная кнопка должна и физически разорвать электрическую цепь, но и твоя система должна вовремя отреагировать. Мало ли. Кнопка как-либо неисправна, контакты залипли. Также тут учитываем, что электромагнитные клапаны имеют свои характеристики, время срабатывания, время отключения. У пневмо и гидро распределителей тоже свои времянки. И это дает нам уже десятки миллисекунд. То есть, твоя система должна отреагировать, скажем, за 10 мс на нажатие аварийной кнопки.
2 - Картинка. В ней уже достаточно информации на эту ночь. И картинка популярно объясняет, что ты должен сделать, если нажали на аварийную кнопку.
Вложение:
164p1.png
164p1.png [ 15.01 Кб | Просмотров: 1564 ]

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 18 фев 2020, 23:12 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Айм-сорри, но когда разговор идет о том, что "оттяпает конечность", то аварийные кнопки заводятся не через какой-то там микроконтроллер, а стоят непосредственно в управляемой цепи. Кнопка, если она действительно аварийная, а не просто "стоп", она не должна зависеть от программы микроконтроллера.
А время торможения приводов - это уж извините, от кнопки на зависит. Не лезьте в опасные зоны, ограждайте их. Вон, например гильотина для рубания листового металла, так у нее педаль и две кнопки по разным сторонам. Цепь запуска собирается только при нажатии одновременно этих трех элементов. Двумя руками и ногой - это гарантирует, что руки оператора убраны.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 18 фев 2020, 23:22 
Старожил

Зарегистрирован: 25 фев 2011, 18:45
Сообщения: 3685
Откуда: Новосибирск
Где у меня написано, что аварийная кнопка заведёна через микроконтроллер? Я написал сразу, что решается комплексно. ФИЗИЧЕСКИ разрывает электрическую цепь. Это первично. Так что не докапывайтесь по пустякам. Или остановимся на том, что вы хотели просто уточнить? Для меня то, что вы написали, это аксиома. Предлагаю заострить внимание на вопросах автора топика.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 18 фев 2020, 23:33 
Старожил

Зарегистрирован: 16 окт 2013, 01:27
Сообщения: 1554
BusMaster писал(а):
Айм-сорри, но когда разговор идет о том, что "оттяпает конечность", то аварийные кнопки заводятся не через какой-то там микроконтроллер, а стоят непосредственно в управляемой цепи. Кнопка, если она действительно аварийная, а не просто "стоп", она не должна зависеть от программы микроконтроллера.
А время торможения приводов - это уж извините, от кнопки на зависит. Не лезьте в опасные зоны, ограждайте их. Вон, например гильотина для рубания листового металла, так у нее педаль и две кнопки по разным сторонам. Цепь запуска собирается только при нажатии одновременно этих трех элементов. Двумя руками и ногой - это гарантирует, что руки оператора убраны.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 18 фев 2020, 23:55 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Ха. А я на всю жизнь запомнил, как в детстве был у отца на заводе, и в цеху стоял этот самый гильотинный станок, у которого какой-то умник выбросил из цепи эти две кнопки. Ну а мне дали обрезки листов и показали как резать их на гильотине. А у гильотины перед ножом опускается прижимная плита. Ну я резал-резал, лист маленький стал, сунул я его под нож, хотел было уже педаль нажать, да передумал, повернул другой, более длинной стороной и нажал педаль. А если бы не передумал - прижимная плита бы бабахнула мне прямо по пальцам.
Так что кнопки кнопками, а "русский пофигизм и рационализаторство" своё гиблое дело всегда могут сделать :)))

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 19 фев 2020, 00:12 
Старожил

Зарегистрирован: 25 фев 2011, 18:45
Сообщения: 3685
Откуда: Новосибирск
Зря, я затронул именно аварийную кнопку... Это чревато раздутием темы. Аварийные случаи разные. Решения тоже разные. Полное отключение. Частичное отключение. В этом случае система реагирует. Например, тем что на своём уровне отключает исполнительные механизмы. Индикация и все такое прочее. Остановимся на этом. Примеров можно привести кучу. Думаю, меня поняли, что я хотел сказать, когда упомянул "реакция системы".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 19 фев 2020, 00:49 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Да бох с ней, с этой кнопкой и с реакцией системы.
По теме вопроса - есть такая штука, как теория автоматного программирования. И вот эта самая фигня и содержит тему вопроса. Почему конечный автомат назван именно "конечным"? Не потому, что он в конце, а потому что это автомат, который, в отличие от абстрактного автомата, имеет конечное число состояний. И вообще, если углубляться в теорию, то там будет шибко много заумных понятий, таких как "детерменированный конечный автомат" и прочие. Графически конечный автомат изображается не в виде "черного ящика", а в виде схемы переходов и состояний.
На практике в программном коде переходы записываются чаще всего в виде оператора switch. Можно так же и if-else или вообще в виде непосредственной таблицы. А состояния - это переменная в switch, if или индекс таблицы.
И в коде, проверка флага if(flag) { ....} тоже является частью конечного автомата и графически будет рисоваться в виде первого кружочка и двух стрелочек от него. Одна стрелочка ведет к проверке следующего флага, а вторая стрелочка ведет ко всяким switch или другим if-else.
Вот и всё, что вобщем то нужно знать о конечных автоматах на уровне кодописательства.
Прерывание по событию не входит в графическое представление конечного автомата, потому что прерывание асинхронно и нигде никаким состоянием не отображается - его нельзя включить ни в одну ветвь, оно может произойти в любом месте, а может и не произойти. На то оно и прерывание.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 19 фев 2020, 09:42 
Старожил

Зарегистрирован: 25 фев 2011, 18:45
Сообщения: 3685
Откуда: Новосибирск
Пока это. Цикл статей Татарчевского.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 19 фев 2020, 10:00 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 505
Я вроде бы в самом начале написал, что знаю сам, что такое КА и умею пользоваться. И физической аварийной кнопкой тоже умею пользоваться и знаю, куда лепить. В конце концов, при моем непосредственном участии в разработке уж несколько систем управления приводами сделано - и ничего, все работает, все было испытано и принято. Не понимаю, к чему эти поучения начались. Я задал вопрос - я ответ на него получил, не вижу никакого смысла поднимать тред из небытия. Лучше б кто поднял тред про cic-дециматор, с которым я пока ничего не решил, и баг так и остался.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 19 фев 2020, 10:53 
Старожил

Зарегистрирован: 25 фев 2011, 18:45
Сообщения: 3685
Откуда: Новосибирск
10.02.2020. Я бы не сказал что это небытие. И вы не написали явно, что тема решена. Тем не менее, я считаю, что ваши проблемы не решены. Про входы я уже сказал. У конечного автомата входом может служить что угодно, если это вход важен. В каком виде, это уже другой вопрос. Имеет смысл важность входов. Приоритет. Но под приоритетом в данной теме я понимаю именно важность.
Буфер сообщений. Неплохо. Но можно опоздать если у сообщений не будет важности. Не приоритет. А что именно обрабатывать, чтобы не упустить важное. Не опоздать.
Теперь вопрос определения. Что считать сообщениями. Что угодно. Это может быть очередь сообщений. Это может быть событие. Событие вообще по сути бинарно. Оно либо есть, либо его нет.
Как реализовано у меня. У меня входы автомата все, что что важно и в необходимом для текущего состояния автомата порядке.
Сообщения я вообще обозвал событиями. И они у меня не как очередь а как массив. Это даёт возможность опросить только те события, которые нужны в текущем состоянии и в нужном мне порядке.
Идем дальше. Вам правильно уже указали, автоматы в прерывании это неправильное решение. Прерывания должны быть максимально короткими и быстрыми. И ваша реализация конечные автоматы в прерывании не верна.
Не нужны диспетчеры, ртос, и так далее. Конечный автомат это уже диспетчер. Конечные автоматы могут менять других автоматов.
В моих проектах один из процессов главный автомат. Который и задаёт общий целевой алгоритм работы. Все остальные автоматы подчинённые.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 19 фев 2020, 11:42 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 505
А пид-регуляторы для сервоприводов и обновление скважности инвертора тоже посоветуете не делать в прерывании? А так, сначала получить сигнал с энкодера, потом выйти в общий цикл, пробурлиться там с другими задачами, и затем только посчитать новое задание на двигатель?

Это общепринятая практика - управление приводом в прерывании, особенно на частоте 10 кГц. И делается это не на атмеге, а на контроллере, которому это под силу. И автомат там тоже есть - состоит всего из трех состояний: стоп, работа и сервисный режим. И входы у него тоже есть - сигналы аварий и показания датчиков из бругих программных модулей. И от того, что он сделан в прерывании, он не перестает быть автоматом.

В общем, не вижу никакого смысла продолжать бесплодный спор, для себя решение уже знаю,буду отлаживать, испытывать - все как всегда.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 19 фев 2020, 11:47 
Старожил

Зарегистрирован: 25 фев 2011, 18:45
Сообщения: 3685
Откуда: Новосибирск
Разговор о конечных автоматах не бесплодный. Это обширная тема, достойная обсуждения. Я более чем уверен, что вы ещё вернётесь. Не обязательно в эту тему. Но на тему конечных автоматов точно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 19 фев 2020, 12:26 
Старожил

Зарегистрирован: 16 авг 2012, 23:27
Сообщения: 2094
Откуда: Москва
sdv_cyborg писал(а):
Это общепринятая практика - управление приводом в прерывании, особенно на частоте 10 кГц. И делается это не на атмеге, а на контроллере, которому это под силу.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 19 фев 2020, 12:37 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 505
Ну там, наверное, частота дискретизации контура управления ниже просто. Ну и еще множество нюансов может быть, как то отсутствие контура тока и т.д.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 19 фев 2020, 12:44 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Походу, кого-то пробило на философствования. Обычно, философствуют после пятой-седьмой принятой "поправки".
Тогда уж философствуйте как подобает - с математическими формулами, абстрактно. Про недетерминированность эквивалентного детерменированного автомата, про машину Тьюринга. А то толчете воду в ступе.

Ребята, чтобы философствовать на тему темы, надо вначале эту тему изучить по теме. Почитайте теорию автоматного программирования. И если после этого еще будете способны тут внятно чето писать, тогда вот и милости просим. А пока - все эти философствования про "switch-технологии" - эт так, просто "для поговорить".
На уровне чисто кодописания вся эта теория сводится к <уже написал раньше>. Остальное - это теория на уровне математических формул и графов переходов. Внешние прерывания вообще никак не относятся к конечным автоматам по причине <уже написал ранее>.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 19 фев 2020, 13:11 
Старожил

Зарегистрирован: 25 фев 2011, 18:45
Сообщения: 3685
Откуда: Новосибирск
BusMaster писал(а):
...
Если думать про диспетчер КА, то это будет еще один КА, поверх остальных. По крайней мере, реализация на практике, как я думаю, должна выглядеть так.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Диспетчер КА - размышлизмы.
СообщениеДобавлено: 19 фев 2020, 13:15 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Не знаю, как в вашей деревнее, а в нашем селе так с этим всё ясно. Мы мужики простые, мы не любим много пустых слов пускать, мы лучше без лишних слов сделаем. Пока одни рассуждают, другие уже -дцать раз сделали.
Хотя, балаболить впустую щас модно стало. Все только и делают, что "сидим без Дим".


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 177 ]  На страницу 1, 2, 3, 4, 5 ... 8  След.


Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB