State_Maschine

Loading thread data ...

Здравствуйте, Orlov!

Hе надоело еще идиотом прикидываться? Вам там что, заняться больше нечем?

Всего Вам Ольга

Reply to
Olga Nonova
Reply to
Alexander Zabairatsky

У пациента жестокий бред. Практически вся документация GNU написана понятным языком. В отличии от MSDN, например, где язык вроде и английский, но какой-то исключительно непонятный, и вообще "воды" много.

Reply to
Kirill Frolov

Где реальный проект?

У пациента белая горячка. Время там всегда, для каждой ветви, конечное и одинаковое. И очень даже предсказуемое. Можно по тактам посчитать в листинге...

Reply to
Kirill Frolov

Речь идёт не о времени switch-case, а о том, что оно всё в цикле, пока добежит до нужного автомата -- оборот в несколько десятков миллисекунд. Почему так долго -- а потому, что бесполезные проверки условий (и отнюдь не switch-CASE), которые никогда (почти) не выполняются. Например, проверки состоянийх других автоматов. Т.е. налицо отсутствие эффективного механизма взаимодействия между автоматами. Почему я и предлагаю организацию механизмов аналогичных используемым в типично планировщике многозадачной/многопоточной ОС. Т.е. проверку условий, например, заменить на сигнализацию семафором.

Reply to
Kirill Frolov
Reply to
Ruslan Mohniuc

Здравствуйте, Уважаемый Slav!

Fri Jul 07 2006 16:16, Slav Matveev wrote to Olga Nonova:

ON>> ... (см. мой пример хранения кода состояния в ON>> регистре порта вывода).

SM> хотелось бы взглянуть на реальный проект, где код состояние SM> хранится в регистре порта в/в, и как это можно перевести SM> на предложенный (*f)();

Для мелкоконтроллеров я этого еще не делала. Собственно и пытаюсь выяснить, как такое можно было бы заделать средствами С. Однако, для ПЛИСов реализация сабжа прямо на ножках выводв- это классика.

SM>>> что бы, например process->getstatus() вернул константу, SM>>> а не абстрактное 0x12345678.

ON>> Вы ведете речь о распределенных в сети процессах? Или, все-же о ON>> поцессах внутри одного девайса с одним микроконтроллером?

SM> Я веду речь о многозадачной среде.

В многозадачной среде надежней всего предавать сигналы от задачи к задаче средствами OS, например, семафорами, "ящиками" или очередями. Прямой доступ никто не делает.

ON>> В последнем случае, наиболее эхотажном, никто не запрещает ON>> передавать символьные имена функций и конечных автоматов между ON>> модулями обычной директивой extern.

SM> и линковать "на лету" ?

Зачем? Все происходит на этапе сборки проекта.

SM>>> работает через call и приводит к необходимости сохранять- SM>>> восстанавливать окружение.

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

SM> хоть с параметрами, хоть без них, но извольте SM> во-1 выделить место под локальные переменные, SM> во-2 сохранить регистры, используемые для локальных переменных SM> вызывающей функции.

Hет в сабже никаких локальных переменных, не нужны они. Или С-компилятор обязательно вставит? Hо, это уже претензии к авторам компилятора.

ON>> "do_something" не обсуждается, т.к. одинаково в любом случае.

Обсуждается время ветвления сабжа по состояниям. Сколько оно?

Всего Вам Хорошего Ольга

Reply to
Olga Nonova
Reply to
Dimmy Timchenko

Здравствуйте, Уважаемый Slav!

Fri Jul 07 2006 16:16, Slav Matveev wrote to Olga Nonova:

ON>> .... (см. мой пример хранения кода состояния в ON>> регистре порта вывода).

SM> хотелось бы взглянуть на реальный проект, где код состояние SM> хранится в регистре порта в/в, и как это можно перевести SM> на предложенный (*f)();

Вспомнила! Видела у Phillips-а пример решения конечного автомата для ихнего варианта I2C. Там статус-регистр I2C использовался напрямую в качестве младшего байта адреса ветвления. Старщий назначался принудительно в свободной странице кодов. Все это, естественно, на ассемблере (Metalink). Интересно, как бы такое же реализовать на С ?

Всего Вам Хорошего Ольга

Reply to
Olga Nonova

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

Reply to
Kirill Frolov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.