Генерация событий состояния машины в многопроцессорной архитектуре

Question

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

У нас есть DSP и Cortex-M3 вместе с общей памятью. DSP получает запросы от внешнего мира, и некоторые из этих запросов должны выполнять определенные функции тестирования беспроводной сети, которые могут быть выполнены только на CM3. DSP записывает в общую память, затем сигнализирует CM3 через прерывание. Общая память указывает, что запрос вместе с любыми необходимыми данными, необходимыми для выполнения запроса (канал для настройки, регистрация RF-чипа для чтения и т. Д.).

Мое предпочтение заключается в создании уникального идентификатора события для каждого запроса, который может произойти в прерывании. Затем, прежде чем покинуть прерывание, передайте событие в очередь событий конечного автомата, которая будет обрабатываться в потоке, посвященном активности RF.

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

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

Любые комментарии к лучшему подходу? Если это помогает, мы используем инфраструктуру QP от Miro Samek для реализации государственного аппарата.

EDIT: переехал Statechart в ftp://hiddenoaks.asuscomm.com/Statechart.bmp

Answer 1

Вот компромисс:

• пройти один идентификатор события (общая команда РФ) к государственной машине из прерывания
• создать action_function, что «разборы «общая память и возвращает определенную команду
• защитные RF_EVENT переходы в государственной карте с [parser_action_func() == RF_CMD_1] и т. д.

Генератор кода состояния должен быть достаточно умным, чтобы выполнить parser_action_func() только один раз за RF_EVENT. (Dunno, если структура QP - это умная).

Это имеет ту же семантику правильной формулировки вашего «уникального идентификатора события для каждого запроса» и позволяет избежать разбора разделяемой памяти в обработчике прерываний.

ДОПОЛНЕНИЕ

Разница в диаграмме состояний является N переходов помечены

----RF_EVT_CMD_1----> 
----RF_EVT_CMD_2----> 
     ... 
----RF_EVT_CMD_N----> 

Вер

----RF_EVT[cmd()==CMD_1]----> 
----RF_EVT[cmd()==CMD_2]----> 
     ... 
----RF_EVT[cmd()==CMD_N]----> 

, где cmd() является функцией синтаксического анализа действий.