[Вроде решено] Массив указателей на функции. Указатель на массив Опции

[demiurg1978]

Запутался. Честно скажу, с указателями я не всегда дружу. Помогите написать правильно. Нужно: есть массивы указателей на функцию. И переменные-состояния конечных автоматов, индексы для массивов.

CODE

//************************************************************************
//************************ Главный автомат *******************************
//************************************************************************

//========================================================================
STATE (PROC_DEVICE_INIT, proc_device_init)
STATE (PROC_DEVICE_WAIT_SWITCH_MODE, proc_device_wait_switch_mode)
STATE (PROC_DEVICE_MANUAL, proc_device_manual_mode)
STATE (PROC_DEVICE_AUTOMAT, proc_device_automat_mode)
STATE (PROC_DEVICE_EMERG_MODE, proc_device_emerg_mode)
//========================================================================

enum _proc_device
{
#define STATE(name, func) name,
#include "_proc_device.h"
#undef STATE

PROC_DEVICE_STATES,
};

//========================================================================
typedef void (*FUNC)(void);
//========================================================================

__flash FUNC proc_device_func [PROC_DEVICE_STATES] =
{
#define STATE(name, func) func,
#include "_proc_device.h"
#undef STATE
};

static u08 _proc_device;
static u08 _proc_device_slave;

void proc_device (void)
{
// proc_sens_pwr (SAVE_EEPROM_PARAMETERS); // !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

proc_device_func [_proc_device] (); // В данный момент работает так.
}

Мне нужна функция, у которой в качестве параметров proc_device_func и _proc_device.
Что-то вроде proc_fsm_func (proc_device_func, get_proc_device_state ())

Мои пробы выдают ошибки.

Сообщение отредактировал demiurg1978 - Jan 29 2017, 14:47

[Dog Pawlowa]

Определяем тип переменной PROCEDURE - указатель на функцию

Код

typedef void (*PROCEDURE)(void);

Пишем текст функций.

Код

void function1(void) { ... }
void function2(void) { ... }
void function3(void) { ... }

Определяем, сколько у нас функций в массиве.

Код

#define STATES 3

Создаем массив указателей на функции в программной памяти, что у нас, AVR..

Код

__flash const PROCEDURE function[STATES_QTY] = { function1, function2, function3 };

Все, в программе вызываем вызываем функцию, соответствующую номеру состояния state:

Код

function[state]();

Мне нужна функция, у которой в качестве параметров proc_device_func и _proc_device.
Что-то вроде proc_fsm_func (proc_device_func, get_proc_device_state ())

А зачем так сложно - в функцию передавать указатель на функцию? Чтобы вызвать? Ну так вызовите добавлением скобок.

[demiurg1978]

А зачем так сложно - в функцию передавать указатель на функцию? Чтобы вызвать? Ну так вызовите добавлением скобок.

Покажите, как.

[Dog Pawlowa]

Покажите, как.

Уже сделано! Функция вызывается по индексу в таблице:

Код

function[state]();

Что не устраивает?

[demiurg1978]

Все приведенные примеры по сути повторяют то, что написано в первом сообщении. Излишняя навороченность кода в том сообщении, по сути enum и массив, обвернутые в макросы. И вызов функции один в один как у вас.

Код

   proc_device_func [_proc_device] ();

[Dog Pawlowa]

Все приведенные примеры по сути повторяют то, что написано в первом сообщении. Излишняя навороченность кода в том сообщении, по сути enum и массив, обвернутые в макросы. И вызов функции один в один как у вас.

Правильно, макросы вредны, а все остальное - классика, которую использует каждый второй.
Что не устраивает то?

Вам то зачем дополнительная прослойка в виде функции, в которую будете передавать указатель на функцию?
Будьте проще, пишите как есть, все же работает.

[demiurg1978]

Вроде решил вопрос.

CODE

//========================================================================
typedef void (*FUNC)(void);
//========================================================================

void proc_fsm_func (FUNC __flash *ptr_func, u08 s);

void func_1 (void);
void func_2 (void);
void func_3 (void);
void func_4 (void);

extern FUNC __flash list_func [];
void __flash * get_list_func (void);

void func_1 (void)
{

}

void func_2 (void)
{

}

void func_3 (void)
{

}

void func_4 (void)
{

}

__flash FUNC list_func [4] =
{
func_1,
func_2,
func_3,
func_4,
};

void proc_fsm_func (FUNC __flash *ptr_func, u08 s)
{
ptr_func [s] ();
}

void __flash * get_list_func (void)
{
return list_func;
}

proc_fsm_func (get_list_func (), 2);

Задумка такая: что-то вроде ядра обработчика конечных автоматов. Можно было и так оставить, как сделано в первом сообщении. Для каждого автомата своя строка вызова функции по индексу.
А когда задумал ядро обработчика, тут и возникли трудности. Честно говоря, я еще думаю, стоит ли дальше работать над этим ядром и применять его в проектах.

Сообщение отредактировал demiurg1978 - Jan 29 2017, 17:29

[Dog Pawlowa]

Для каждого автомата своя строка вызова функции по индексу.

Это реализуется очень просто - одним массивом всех функций, но группы индексов массива для каждого автомата не должны перекрываться.
Например, первые 6 функций - автомат А, следующие 19 функций автомат B, и еще 9 функций автомата C.
тогда если массив называется f, обработка всех автоматов будет выглядеть так:

Код

f[stateA]();
f[stateB]();
f[stateC]();

Я так делал один раз в очень специфическом проекте.

[psL]

Например, первые 6 функций - автомат А, следующие 19 функций автомат B, и еще 9 функций автомата C.
Я так делал один раз в очень специфическом проекте.

Допустим нужно добавить еще несколько состояний в автомат A, что делать? Менять условия всякий раз?
Насколько понимаю, ТС разбивает весь код на задачи и у каждой задачи - свой автомат состояний. Т.е. при переключении на соответствующую задачу должен подключаться соответствующий автомат состояния.
В принципе, очень типичная задача. Ничего специфического. Даже тема была https://electronix.ru/forum/index.php?showt...=136908&hl=

[Dog Pawlowa]

Менять условия всякий раз?

Дифайны и енумы уже отменили?

[psL]

Дифайны и енумы уже отменили?

Нет. Просто реализация, исходя из ваших рекомендаций, у ТС получится до безобразия кривой: один глобальный массив со всеми вытекающими. И все это только потому, что указатель на массив функций не осислили)

[Dog Pawlowa]

Просто реализация, исходя из ваших рекомендаций, у ТС получится до безобразия кривой: один глобальный массив со всеми вытекающими.

А что там такое вытекает? Инициализация переменных состояния? Для Вас это тоже проблема?

[demiurg1978]

Если конечный автомат сделан по индексному переходу, то не инициализированная переменная-состояние может наделать делов. Именно поэтому хорош способ, когда нулевое состояние - инициализация всего и вся. Тем более что такой способ бесплатен. ОЗУ инициализировано нулями.
Но если switch-case и состояний много, то код становится трудночитаемым. Опять же, switch-case нагляден. Индексный вызов функций - это блудить и искать нужную функцию. Но в этом случае можно частично облегчить задачу. Например, в одном месте вывести названия состояний и соответствующие названиям функции.
Пример:

Код

//************************************************************************
//************************ Главный автомат *******************************
//************************************************************************

//========================================================================
STATE (PROC_DEVICE_INIT,             proc_device_init)
STATE (PROC_DEVICE_WAIT_SWITCH_MODE, proc_device_wait_switch_mode)
STATE (PROC_DEVICE_MANUAL,           proc_device_manual_mode)
STATE (PROC_DEVICE_AUTOMAT,          proc_device_automat_mode)
STATE (PROC_DEVICE_EMERG_MODE,       proc_device_emerg_mode)
//========================================================================

Сообщение отредактировал demiurg1978 - Jan 29 2017, 19:11

[jcxz]

Но если switch-case и состояний много, то код становится трудночитаемым. Опять же, switch-case нагляден. Индексный вызов функций - это блудить и искать нужную функцию. Но в этом случае можно частично облегчить задачу. Например, в одном месте вывести названия состояний и соответствующие названиям функции.

Есть гораздо более наглядные способы организации автоматов состояний чем switch/case или туева хуча функций.
Например - переключение стека, когда значениями автомата состояний становятся значения PC (или как там в AVR называется счётчик команд?) И код автомата выглядит совершенно линейным и простым.

Дифайны и енумы уже отменили?

Нет. PC - вот лучшее место для хранения состояния автомата состояния!

[Dog Pawlowa]

Нет. PC - вот лучшее место для хранения состояния автомата состояния!

Как же, давайте пихать RTOS во все дыры.
А даже впихнем - все равно куски кода нужно как-то комментировать, можно сказать, что case - это комментарий

[jcxz]

Как же, давайте пихать RTOS во все дыры.

Причём тут RTOS?? Где Вы её узрели в моём сообщении?

[Dog Pawlowa]

Где Вы её узрели в моём сообщении?

вот:

PC - вот лучшее место для хранения состояния автомата состояния!

Самый лучший автомат состояния - это последовательное выполнение команд, тогда состояние однозначно отражается местом в коде. Полностью согласен.
К сожалению, это возможно только для простейших устройств (один автомат), чтобы сделать то же самое для более сложных устройств (больше одного автомата) и сохранить привязку автомата к PC, нужно иметь инструмент, который принудительно переключает PC между "автоматами".
Такой инструмент называется RTOS.
Как?