Объявлена переменная с ссылкой на функции класса:
class clAutomatic_Mode;
static void (clAutomatic_Mode::*mode_func)(void); // указатель на функцию обработчик
в теле программы присваиваю этой переменной адреса функций, например:
mode_func=&clAutomatic_Mode::HeatInit;
Но не понимаю как сделать вызов функции по адресу в переменной mode_func.
На mode_func(); - выдается ошибка:

Видимо не правильно объвляю. Но как сделать правильно?

В целом я делаю автомат состояний и переходы между состояниями решил организовать переписывая ссылку на функции - показалось удобным. Может есть какой-то более прямой способ для С++?

Смешение культур, какое-то. Если занялись ООП (надеюсь понимаете, что это не Организация Освобождения Палестины), то надо создать иерархию классов от одного общего предка с виртуальной функцией. Вот эти порожденные классы и будут реализацией состояний. Далее, некий менеджер (не тот, что в торговом зале) держит ссылку на конкретную реализацию состояния и вызывает его виртуальный метод. Состояние меняется - порождается новый объект и присваивается на эту ссылку.
class State
{
public:
State();
virtual int mode_func();
}
class State_A : public State
{
public:
State_A();
virtual int mode_func();
}
class State_B : public State
{
public:
State_B();
virtual int mode_func();
}

class State_Manager
{
public:
State_Manager();
..
protected:
State* m_state;
}
где - то в недрах менеджера порождаем первое состояние:
m_state = new State_A();
...
...
выполняем функцию состояния:
int nNewState = m_state->mode_func();

каким -либо образом проверяем результат, и, если есть новое состояние, то порождаем его вместо текущего:
if (nNewState)
{
if (m_state)
delete m_state;
switch(nNewState)
{
case STATE_A: m_state = new State_A(); break;
case STATE_B: m_state = new State_B(); break;
}
}

ну и наверх, опять выполнять функцию состояния.
Есть несколько книг по ООА и шаблонам проектирования, попробуйте их почитать, тренируйтесь на Visual C++, безотносительно контроллера, у него хороший отладчик.

есть отличный сайт, посвященный программированию AVR на высоком уровне (С). Все на русском языке и довольно подробно расписано. http://avr.h15.ru

Посмотрел ради интереса. Мда... Что тут сказать?.. Обратил внимание только на вещи, которые знаю достоверно. Сразу бросается в глаза, что в таблице, например,

AtmanAvr и WinAVR представлены как компиляторы С/С++, а тот же IAR скромненько так: "Платный компилятор ANSI C. Доступна демо-версия. AVR-компилятор, который, по мнению многих, генерирует лучший код". Это при том, что плюсовые фичи в EWAVR появились гораздо раньше, чем у avr-gcc.

А на другой старнице приводится сравнение эффективности компиляторов на простом тестовом примере - мигание светодиодами (через программную задержку). IAR там занимает последнее место - у него размер кода 413 байт! А на первом месте кто бы вы думали? Ни за что не догадаетесь - KEIL51 с результатом 136 байт. Как 51-й затесался в среду AVR, прямо загадка.

AVR-GCC скромно занимает второе почетное место с результатом 211 байт.

Тут мне стало интересно и я решил проверить, как оно на самом деле. Полез к себе, где у меня всякие тестовые штуки лежат и... обнаружил, что проектик с этим тестом там уже есть. И тут же вспонмил, что когда на этом форуме обсуждали тему эффектиности компиляторов, то этот пример и был предложен к рассмотрению.

Итак, IAR у меня показал при опциях оптимизации макс. по скорости 114 байт, при макс. по размеру - 106 байт. Смутно вспоминаю, что avr-gcc выдавал что-то тоже чуть больше сотни - побольше, чем IAR, но совсем не на много (что-то то ли 122 байта, то ли 118 байт). Ну уж никак не 211. Да и вообще сама цифра 211 выглядит очень подозрительно - как это размер кода у AVR может быть НЕЧЕТНЫМ числом - у него ж любой опкод - 16-битное слово. Т.е. размер кода всегда должен быть ЧЕТНЫМ числом. То же самое касается и IAR'а с его 413 (!) байтами. Впрочем, на фоне KEIL51 среди AVR это уже не так удивительно, даже в тему.

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

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

Я понял! Там приводился размер hex файлов! И взависимости от формата Motorola, Intel-S, Intel-E и т.п. получался такой размер, который кстати весьма справедливо может быть нечетным. IAR'у наверняка неповезло больше всех, т.к. афтар веселого теста вероятно сгенерил в отладочном формате d90

Уважаемые разработчики!
На вышеупомянутом сайте http://avr.h15.ru указано, что тест дёрнут с сайта http://atmanecl.com . Авторы проекта сами тестированием не занимались. Может, у кого-то есть результаты личных тестов производительности компиляторов или ссылки на оные в сети, буду благодарен, если вы о них сообщите.
IgorKossak -> русскоязычных ресурсов, посвященных программированию на С под AVR, не так уж много. Я могу насчитать меньше десяти. А насчет критики... Хотелось бы поконкретнее. Любая критика воспринимается адекватно и с благодарностью.