[an error occurred while processing this directive]
Практически все программы я строю именно на КА (+)
(«Телесистемы»: Конференция «Микроконтроллеры и их применение»)

миниатюрный аудио-видеорекордер mAVR

Отправлено SM 08 апреля 2006 г. 22:26
В ответ на: Кто применяет метод конечных автоматов для проектирования программ uC? (+) отправлено <font color=gray>NAUT</font> 08 апреля 2006 г. 21:51

Ваша задача очень красиво ложится на систему с КА и прерываниями.

Я бы примерно так реализовал:

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

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

USB - это КА даже по спецификации. Читаем ее, и видим, какие основные состояния у этого автомата. Что касается пересылки своих данных (не дескрипторов), так это зависит опять же от протокола. Я например реализовывал масс сторейдж на КА, получилось 2 автомата - один физического уровня, с состояниями навроде "ждем данных на передачу", "стартуем DMA-канал", "ждем завершения". И логический, протокольный, который на основе пришедшего из PC запроса входит в нужное состояние, там проходит в зависимости от запроса несколько подсостояний, обмениваясь с КА физического приема-передачи через семафоры/флаги и очереди. Точно также посторил работу с I2C (флешки). Аналогично можно сделать и любой другой интерфейс.

Шевеление ногами - вещь сугубо специфическая, советованию на подается. В каждом случае оно свое.

В общем основной цикл программы пишется как бесконечный из кучи CALL'ов на разные автоматы. Внутри каждый CALL реализуется как переход по таблице на текущее состояние. Можно перед этим проверит некий программный таймер, формирующий задержку перехода от состояния к состоянию (бывает полезно, в том же УСБ). Мое мнение - что такой способ построения программ с использованием КА оптимален. Критерий оптимальности - минимум ресурсов процессора при максимуме быстродействия.


Составить ответ  |||  Конференция  |||  Архив

Ответы


Отправка ответа

Имя (обязательно): 
Пароль: 
E-mail: 
NoIX ключ Запомнить

Тема (обязательно):
Сообщение:

Ссылка на URL: 
Название ссылки: 

URL изображения: 


Rambler's Top100 Рейтинг@Mail.ru
Перейти к списку ответов  |||  Конференция  |||  Архив  |||  Главная страница  |||  Содержание

E-mail: info@telesys.ru