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

[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.
Как?

[jcxz]

нужно иметь инструмент, который принудительно переключает PC между "автоматами".
Такой инструмент называется RTOS.

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

Единственное что правда, так это то, что тело такого автомата будет похоже на задачу ОС с корпоративной многозадачностью.

[Dog Pawlowa]

тело такого автомата будет похоже на

Есть такая грубая поговорка - если девушка похожа на шлюху, и ведет себя, как шлюха, то она шлюха и есть.
Так и переключение автоматов