State machine, Приведите примеры реализации Опции

[sat]

Где можно почитать по теме/посмотреть примеры на С, асме

[Diz]

Интересно, а как сделать с набором параллельно работающих конечных автоматов (без RTOS) долго работающую задачу, требующую активного участия процессора ? Например, работу с FAT (сектор может читаться значительное время) или рендеринг экрана для UI (тоже небыстро). Разбивать на отдельные этапы некрасиво и неудобно, а иначе задача будет блокировать другие на долгое время.

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

[defunct]

Интересно, а как сделать с набором параллельно работающих конечных автоматов (без RTOS) долго работающую задачу, требующую активного участия процессора ? Например, работу с FAT (сектор может читаться значительное время) или рендеринг экрана для UI (тоже небыстро). Разбивать на отдельные этапы некрасиво и неудобно, а иначе задача будет блокировать другие на долгое время.

.....
С FAT пример неудачен. Сектор то читается драйверком SPI, и пока он читается задача отдыхает (не требует активного участия CPU).

Рендеринг экрана - подходящий пример. Посмотрим по аналогии. Есть Borland'овский VCL, где вся графика обслуживается исключительно в основном потоке приложения, и при запуске какой-то длительной задачки в том же основном потоке прорисовка приложения намертво тормозится. Чтобы пользователь не подумал, что программа зависла, можно и нужно было либо стартовать доп поток, либо, что значительно проще - иногда вызвать функцию:

Application->ProcessMessages();

Вот так же можно поступить и тут. Что мешает реализовать некую функцию yield / idle - которую любой затяжной процесс сможет вызвать сам, чтобы дать поработать всем остальным процессам? Для того чтобы такую функцию можно было реализовать, необходимо чтобы был список задач(автоматов) с возможностью модификации в Run-Time (чтобы процесс вызывающий эту функцию мог быть удален из списка процессов на время своего испонения). Сосбно вот:

CODE

typedef void (* p_cb)(void);

#define COUNT(arr) (sizeof(arr) / sizeof((arr)[0]))

p_cb list[4];

void add_task( p_cb Callback)
{
for(int i = 0; i < COUNT(list); i++)
if (!list[ i ])
{
list[ i ] = Callback;
break;
}
}

void idle(void)
{
for(int i = 0; i < COUNT(list); i++)
if (list[ i ])
{
p_cb cb = list[ i ];
list[ i ] = NULL;
cb();
list[ i ] = cb;
}
}

void foo_1(void)
{
}

void foo_2(void)
{
}

// это долгий процесс делающий рендеринг
void foo_long(void)
{
volatile unsigned long x = -1UL;
while( x--)
{
// ... do complex stuff

if ( (x & 0xFF) == 0 ) // 255 iterations passed
{
// дадим поработать другим задачам
idle();
}
}
}

void main(void)
{
add_task( foo_1 );
add_task( foo_2 );
add_task( foo_long );

for(;;)
idle();
}

Да, большие готовые библиотеки лишают автоматы всяческих преимуществ...
Однако тупик с автоматами...

Раскидать idle()'ов по ключевым точкам и автоматы получают вторую жизнь.

Причина редактирования: Уменьшение видимого размера цитаты исходника.