DogPawlowa

А потом ? - искать по окну дизассемблера? Не выглядит особенно удобным по сравнению со значением из enum.

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

Да, у меня тоже такое есть, имя состояния выводится после времени установки. Но тут то просто - процесс медленный, все выводится в реальном масштабе времени. С быстрыми автоматами буферизация данных становится сама по себе непростой задачей. {27.01.17-08:09:46} "Filling" Time Water A B >Cycle A c0 p0 w0 f11 4 4 A:1/6945525 B:0/0 >F reduced A factor10 prod714 14 4 A:2/2310679 B:0/0 {27.01.17-08:09:48} "Discharge finished" Post pulses=4 W.counter: a/r/s/n 4/899/0/4; W. volume: r/a=3979400/4752; ConcA pulses r/a: 28/2 vol: r/a=20600/1428 ConcB pulses r/a: 0/0 vol: r/a=0/0 S. volume: r/a=4000000/6180; 16 4 A:2/2310679 B:0/0 Num Date Time Liter A% B% Err 0240:27.01.17-08:09-000.0-23.106-0.000-15 {27.01.17-08:09:49} "Error" 15 Low water pressure {27.01.17-08:09:56} "Error-2" {27.01.17-08:09:57} "Waiting" Stagnation 283572 0,5% |0,5% 0,5% |0,5% A:4,0l|A+B:1,5l |B:1,5l {27.01.17-08:09:58} "Filling"

Если Вы откажетесь от любимой консоли, то будете в отладчике смотреть состояние по осмысленному наименованию одной строкой из enum ;) Кстати, расскажите подробнее про отладку - как то происходит? Вот как быстро понять текущее состояние автомата?

>> Покажите как Вы с помощью этого макроса реализуете условное изменение состояния автомата? А цикл? А как Вы со своей функцией реализуете условное изменение состояния автомата? - Никак. Вы хотели линейности кода - вот оно. >> Ну да, а изменение значения переменной-состояния автомата где? >> А если эта переменная меняется условно, в зависимости от результата выполнения предыдущего состояния автомата? Так еще проще, чем у Вас - присвоил новое значение и вышел. Естественное структурирование автомата. А у Вас - if (..) goto ? >>В N-й раз уже говорю, но похоже не доходит :(( - Мой метод оптимален для сложных автоматов, Вы в автоподпись добавьте - крут, как яйца ;) >> с большим числом состояний "Большим" - это сколько? У меня сотни - без проблем. >> условными переходами между состояниями, циклическим выполнением каких-то шагов автомата 1. Бывают автоматы без условных переходов и циклического выполнения? 2. Вот не знал, что есть проблемы реализовать переходы (условные и безусловные) и циклы с массивами функций. >>общих последовательностей шагов (которые моим методом оформляются в простые функции). Вы наверное и сами функции изобрели? ;) Общие последовательности шагов реализуются добавлением одной переменной, которая указывает куда выйти после окончания последовательности, она есть и в Вашей реализации. >> Это почему это сохранение/восстановление контекста одно на всех? Разве в соглашениях вызова функций для AVR сохранение контекста делает вызывающий функцию, >>а не сама функция? В любом случае - разница даже в десятки байт - ни о чём, смысла нет обсуждать. Да, тут я погорячился, восстановление контекста одно на всех, а вот сохранение конечно раздельное. >> А переменные, которые Ваши состояния автомата используют их нет? Без переменных? В моём случае - они хранятся в регистрах и сохраняются/восстанавливаются одним и тем же кодом, >> а у Вас - для каждого состояния придётся их на входе в каждое состояние заново читать, а после - записывать. А у Вас этой записи нет?! А в стек и обратно Вы переменные не гоняете? ;) Мои переменные лежат там спокойно и работа с ними идет, когда нужно, а Вы туда-сюда, туда-сюда. Я же написал уже, что у меня запись и восстановление оптимизированы по месту, а у Вас всегда пишутся и читаются все регистры, которые задействованы во всей функции поддержки автомата. А Вы не поняли и недостаток пытаетесь выдать за достоинство. >> Если уж Вас так волнует количество байт кода, то как раз мой вариант в любом случае будет короче. >> Попробуйте на практике реализовать для автомата хотя бы с десятком состояний. Это называется "на слабо" :) Да, наверное есть случаи, когда Ваш метод имеет смысл. Спасибо, я попробую. >>Всё уже было. Если Вы не поняли - очевидно рано ещё, со временем может поймёте. >>Но некоторые товарищи погрязли в однобайтном мирке, похоже никогда не видели исходников размером хотя-бы несколько сотен строк и похоже объяснять что-то бесполезно.... Спасибо, что снизошли!

Банальный макрос #define SwitchStack(N) } void Step##N##() { делает то же самое "улучшение" читаемости и удобство. Все равно место вызова Вашей функции не берется с потолка. Немало, тут я полностью согласен. Но вызов функции по индексу - это один раз на всю программу, преамбула/постамбула тоже одни на всех. Ваш вызов функции против моего вызова функции. Ваше переключение контекста гарантированно дольше, так как должно покрыть все используемые всей функцией регистры, мое переключение (вызов-возврат) в среднем короче, потому что адаптировано к конкретному куску кода, выделенному в отдельную функцию. Еще что-то есть? ;)

Слово "реактор" немного пугает :) Автор, Вы пытаетесь охватить слишком большой объем работы, и цель по прежнему непонятна. Если обучение, ставьте менее глобальные планы. Какой еще резонанс, если из описания следует возможность изменения частоты минимум в два раза?

Оптимизацию включать пробовали? ;) Еще лет 10 назад тот ИАР для того же AVR при оптимизации заменял switch-case на массив функций. Теперь сравниваем вызов функции по индексу, который используется автором, с Вашей системой. Выход из функции и вызов ее опять (или вызов следующей при смене состояния) = восстановить регистры, а затем их сохранить. Ваш вариант = сохранить регистры, а потом восстановить их опять. Разница - да, она есть, и заключается вот в чем - в одном случае человек в поезде лицом в направлении движения, а в другом - спиной в направлении движения. А поезд тот же, и везет точно так же. Нету разницы! Экономии программной памяти в огромном количестве - нет! Увеличения быстродействия - нет! (потому что восстановление/сохранение контекста не оптимизировано). Может вызов функции по индексу и требует пары лишних байт, зато позволяет легко организовать иерархию автоматов.

Немного спорно. А при наличии нескольких задач-автоматов SwitchStack() перестает быть симметричной.

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

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

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

ОЗУ будет инициализировано тем, что скажет программист: int this_variable_is_not_zero=1;

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

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

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

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

Уже сделано! Функция вызывается по индексу в таблице: function[state](); Что не устраивает?

Определяем тип переменной 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](); А зачем так сложно - в функцию передавать указатель на функцию? Чтобы вызвать? Ну так вызовите добавлением скобок.

Опять г...о по трубам.

Загадочный английский язык, варианты перевода какие? "всегда без ожидания", "без ожидания всегда" А если чтение-модификация-запись, то шине и периферии оклематься надо. Ну пишут же напрямую - скорость по APB снижена для экономии потребления.

Не могу похвастаться хорошим знанием ARM, но рассчитывать, что даже при коэффициенте деления = 1 мост между шинами работает без задержек, выглядит чрезмерно оптимистичным. Периферия медленная, мост вставляет циклы ожидания. Все должно быть описано в AMBA. Сам сейчас шлюз клепаю - ну просто живой пример, хотя совершенно в другой области. >> меряю все цифровым осциллографом, ножкой для этого и дергаю Вы не имеете возможности оценить задержки моста, поэтому стоит почитать документацию http://infocenter.arm.com/help/index.jsp?t...ch04s01s04.html

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

Я разработчик приборов для получения гигиенических растворов путем смешивания воды и концентрата с достаточно хорошей точностью. Была версия прибора для питательных растворов для цветов. Измерение проводимости есть, измерения pH нет. Если к моему прибору подключить внешний pH-метр, и подправить алгоритм, то прибор практически готов. Пишите в личку, если интересно.

Надуманная постановка задачи. Нужно привести все записи к более удобоваримому виду, и затолкать их в один или несколько циклических буферов.