State_Maschine

Awtory idioty, и любой спор с вами бессмысленен. Фиксированное время не заключается в подсчёте тактов.

Нужны. Кто бы ткнул в соответствующее место стандартам, где говорится об использовании ANSI, EBCDIC и прочих, и какое отношение к этому имеет CP866. UTF-7 как вариант, только как и в любой /многобайтовой/ кодировке там символьные константы вообще работать не будут...

Кто программировал вообще знают, что в языке C[++] есть понятие типа данных и перечислимых целых (enum). В крайнем случае -- макросы.

Бред. В switch выбирается /состояние/. Как оно соотносится с регистром порта в пике -- не представляю.

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

Thu Jul 06 2006 11:26, Alexandr Torres wrote to Olga Nonova:

ON>> Извольте. Кто программировал ПЛИСы знают, что состояния State_Machine

AT> Мы не обсуждаем ПЛИСы и AHDL/VHDL, мы обсуждем микроконтроллеры и C/Asm.

"Было бы бо-ольшой ошибкой так думать" (с). Да, ДHК все-же видимо Вас серьезно беспокоит. Пунктик, одним словом.

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

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

Thu Jul 06 2006 12:37, Kirill Frolov wrote to Olga Nonova:

KF> Awtory idioty, и любой спор с вами бессмысленен. Фиксированное время KF> не заключается в подсчёте тактов.

Слив засчитан.

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

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

Thu Jul 06 2006 12:40, Kirill Frolov wrote to Olga Nonova:

KF> Кто программировал вообще знают, что в языке C[++] есть понятие типа KF> данных и перечислимых целых (enum). В крайнем случае -- макросы.

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

KF> Бред. В switch выбирается /состояние/. Как оно соотносится с регистром KF> порта в пике -- не представляю.

Вы не можете себе представить, как порт вывода управляет ножками ПИКа и одновременно же хранит код СОСТОЯHИЯ конечного автомата? Довольно странно для участника эхотага.

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

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Olga Nonova! You wrote in conference fido7.ru.embedded to Kirill Frolov on Thu, 6 Jul 2006 09:33:16

KF>> Кто программировал вообще знают, что в языке C[++] есть KF>> понятие типа данных и перечислимых целых (enum). В крайнем KF>> случае -- макросы.

ON> Hе надо строить из себя ментора-всезнайку. Попробуйте, лучше ON> компильнуть приведенный пример и посмотрите, как прекрасно ON> будет все работать.

У меня в большинстве программ есть конечные автоматы, построенные как раз на switch-case конструкции. И все прекрасно работает уже много лет на самых разных кристаллах.

KF>> Бред. В switch выбирается /состояние/. Как оно соотносится KF>> с регистром порта в пике -- не представляю.

ON> Вы не можете себе представить, как порт вывода управляет ON> ножками ПИКа и одновременно же хранит код СОСТОЯHИЯ конечного ON> автомата? Довольно странно для участника эхотага.

Для участнега, вроде вашего безграмотного коллективчега это абсолютно нормально. Для тех, кто реально занимается embedded (да и просто программированием) ваши предположения просто выглядят дико. Если в каком-то одном на тысячу или 10 тысяч случаев такое нужно, можно для этого случая подумать над оптимальным решением. Последний раз, когда я использовал ножки PIC'а как порт был когда я подключал к нему семисегментый индикатор, но выводилось туда вовсе не стостояние конечного автомата, и делалось это по таблице на 16 значений.

dima

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

Thu Jul 06 2006 12:58, Slav Matveev wrote to Olga Nonova:

SM> нужны. я пробовал. два раза. с числами и с литерами (что, собственно SM> то же самое, только в профиль). SM> два сравнения: на минимальную константу и на максимальную, SM> дальше переход по таблице. Таблица, правда, получается дюже SM> "прореженная".

Вот-вот, уже чувствуете "накладные расходы" переходов по таблице.

SM> А ваша схема не очень хорошо будет работать когда состояния SM> надо будет куда-либо передавать или принимать, например. SM> Адрес функции в этом случае не самая лучшая константа, по-моему.

Чем плоха? Она в тексте программы точно такой же имеет всем понятное символическое имя. Програмисту даже не нужно знать, какой конкретно это будет физический адрес. Зато, еще раз повторяю, -1. нет никаких ограничений на тип выражения при switch, да и самого switch - тоже нет. -2.работает с максимальной скоростью ветвления через indirect jmp-ы, -3. никаких переборов case-ов, а значит - фиксированное время на ветвление по состояниям, что очень важно, например, для генерации временной последовательности кодов.

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

Мне это не интересно zanimatxsq perekompilqciej wsqkoj =u[i, тем более в дребезжаем регистре. У меня есть свои примеры. Работающие плохо. Я даже знаюгде и почему. А вы даже не понимаете о чёмм говорите.

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

"В тексте программы". Автомат существует и за пределами текста программы.

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

Thu Jul 06 2006 23:56, Kirill Frolov wrote to Olga Nonova:

KF> "В тексте программы". Автомат существует и за пределами текста KF> программы.

Эк, куда замахнулись! Сначала освойте хранение кода состояния непосредственно в регистре порта вывода, а потом и за более серьезные вещи можно будет браться.

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

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

Thu Jul 06 2006 19:41, Nicolas Minakov wrote to Olga Nonova:

NM> Посмотрел, интнересный камень. NM> А где найти GCC под MCF5270? Мне желательно под cygwin.

Бесплатно можно взять там-же, где лежат все GNU компиляторы. Однако, замучаешься настраивать опции и make-файлы, продираясь через завалы мысли авторов GNU. Я поступила проще- купила уже подготовленный GNU-пакет разработки для cygwin у фирмы NetBurner. Там все делается автоматом, кроме управления встроенной периферией кристалла.

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

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

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

ON>> Вот-вот, уже чувствуете "накладные расходы" переходов по таблице.

SM> Вам шашечки или ехать?

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

SM>>> А ваша схема не очень хорошо будет работать когда состояния SM>>> надо будет куда-либо передавать или принимать, например. SM>>> Адрес функции в этом случае не самая лучшая константа, SM>>> по-моему.

ON>> Чем плоха? Она в тексте программы точно такой же имеет всем понятное ON>> символическое имя. Програмисту даже не нужно знать, какой конкретно ON>> это будет физический адрес.

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

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

ON>> Зато, еще раз повторяю, -1. нет никаких ON>> ограничений на тип выражения при switch,

SM> А много-ли у вас таких типов?

В конечном счете один- целое. Hо! Оно не из ряда 0,1,2...

ON>> да и самого switch - тоже нет. -2.работает с максимальной скоростью ON>> ветвления через indirect jmp-ы,

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

Обращаю внимание- происходит вызов процедур без параметров, которые также ничего не возвращают. Приличный компилятор поймет, что "сохранять- восстанавливать окружение"- излишнее занятие. Hапример, С-компилятор IAR для AVR в этом случае просто вставляет ОДHУ команду icall. Правда проигрыш в скорости по сранению с ijmp все-же есть за счет ret из подпрограммы состояния. Hо если родить макрос ветвления с использованием ассемблерного текста, в котором будет именно indirect jmp, то быстрее уже ничего не придумаешь.

SM> табличный jmp на соответствуюие case'ы ничего не сохраняет, SM> а do_something легко описывается как inline.

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

ON>> -3. никаких переборов case-ов, а значит - фиксированное время ON>> на ветвление по состояниям, что очень важно, например, для генерации ON>> временной последовательности кодов.

SM> Ветвление вы все равно получите, если только у вас SM> не последовательный перебор состояний от начального SM> к конечному.

Ветвление конечно получу, но оно будет занимать всегда фиксированное время. В отличие от switch-case-break с непредсказуемым по времени перебором, когда case-ы отнюдь не 0,1,2...

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