Планируется разработка измерительного прибора, принимающего данные от АЦП в прерывании, складывающего данные в буфер и обрабатывающего данные пос ложному алгоритму.
Дело в том что нужно часто давать сигналы готовности данных на разных ступенях алгоритма. Использовать флаги - глобальные переменные неудобно (их будет слишком много).
Сообщить, какие "более красивые подходы" для этого используются.
например на микрокотнтроллере можно использовать ОСРВ и ее средства взаимодействия между задачами, а как быть когда нужно сделать демо-проект на PC (для последующего переноса на МК)?

Например есть такая задача:
1)АЦП складывает данные непрерывно в кольцевой буфер
2) Раз в миллисекунду данные из буфера обрабатываются результат сохраняется в переменную.
3) после 10й итерации по пункту 2 (т.е. раз в 10 миллисекунд) нужно делать усреднение данных

У меня сейчас в функции, которая реализует п.2 просто есть счетчик итераций в виде переменной. Я опрашиваю эту переменную, и, как только она равна 10 - запускаю функию, реализующую п.3
Все это выглядит ужасно в бесконечном цикле.

Подскажите, как сделать грамотно.

Сообщение отредактировал Zelepuk - Mar 31 2017, 08:00

Я понял так, программа делает то, что от нее требуется. Кому какое дело, как она устроена? Кроме разработчика,желающего сделать красиво. Так и сделайте, как считаете. Сравните. Переделайте еще 5 раз. Нормальный процесс.

Эт понятно. мне интересно как можно считать. На уме был только суперлуп... но есть понимание что тогда прога будет изобиловать глобальными переменными.
Я про подходы говорю. Интересно как можно сделать. Вот статья в тему интересная: https://habrahabr.ru/post/148805/

Я вот например хочу сделать на FreeRTOS, но как тогда удобно сделать чтобы проект запустился и на PC. На PC запускаю для демонстрационных целей.

В ISR, который пишет данные в буфер, смотреть сколько данных накопилось в буфере, и если их больше чем сколько-то - посылать сообщение в майл-бокс.
А под ОС есть задача, которая ждёт на этом мэйл-боксе, и получив сообщение, запускается, читает и обрабатывает данные из буфера, до его опустошения. Потом снова идёт на ожидание мэйл-бокса. Это классический подход к реализации задач обработки событий под ОС. И в том числе цикл обработки сообщений винды (основной рабочий цикл любой GUI-программы) так работает.
И все задачи работающие с данными из периферии (или генерящие туда данные) у меня так построены.

FreeRTOS не лучший выбор. Я бы рекомендовал Micrium OS
Гораздо быстрее, понятнее и компактнее чем FreeRTOS. Там кстати очень ценная фишка для риалтайма появилась - работа сервисов без запрещения прерываний.

Глобальные флаги не так плохи как кажется.
Когда у вас появится больше 5-и источников прерываний по 1 мс и около десятка задач, просто чтобы поддерживать все необходимые интерфейсы как вот здесь:

и когда использование процессора подойдет к 80%, то вы быстро поймете, что стоит вместо сервисов RTOS использовать глобальные флаги или иначе потеряете реальное время.

Хороший способ - это критичные прерывания сделать прерываниями ядра, и чтобы они выставляли глобальные флаги и софтварно прерывания с сервисами RTOS.
Это очень эффективный способ прореживания прерываний PendSV и укорачивания времени выполнения остальных прерываний.

Но на PC вы это не перенесете, это все очень архитектурно привязано к железу.
Риалтайм в принципе не отладить на PC.

Поддерживаю!


Перенести можно, если разделить на middle-ware и собственно low level IO с периферией.
Сам делал и отлаживал так когда сложный драйвер. Из железа ему нужен был только IO с UART.
Так что нижний уровень драйвера на МК - это был IO в/из кольцевых буферов в ISR-ах, а на PC - в те же самые буфера в/из файловых функций WinAPI + система сообщений к задаче обработке - мэйл-боксы под Микриум, и соотв. средства синхронизации под винду. Основной код драйвера - выполнялся в виде задачи обработки событий, которая была общая для Win и для Микриум. Очень удобно было отлаживать. Там 95% всего объёма составляло это middle-ware.
Да собственно так же организована FatFS. Её тоже можно выполнять под любой ОС хоть под виндой. Написав простую low level IO прослойку.

Эх, была бы она бесплатная, хотя бы как раньше, купил книгу и используй как хочешь. Хотя после того как micrium был куплен Silicon Labs может и бесплатно уже распространяется?

2 ТС - какой у вас целевой процессор и ресурсы? Если они позволяют развернуться с RTOS и всем, что к ней прилагается (в самом общем смысле), то можно взять что нибудь, что работает и под РС тоже (eCos непример) и написать на ней. Получите то, что хотите - и РС для отладки и МК в качестве конечной цели.
Если же с ресурсвми на МК не густо, то перенос чего либо с РС на МК дело непростое - проще сделать слой совместимости и писать поверх него (как вам тут уже советовали). Но это дополнительная работа (и может быть очень не малая )

Есть промежуточный подход - выделить из задачи блоки, напрямую не зависищие от аппаратуры, написать их отдельными модулями и сделать для них unit тесты (для отладки)
Тогда большую (или меньшую, если не повезет ) часть можно будет отладить на РС, но собирать это все в кучу придется на МК (и run time взаимодествие между модулями тоже придется делать на МК)

Micrium OS с самого рождения имела порт по Windows.
А нынче у нее под Windows выполняется всё: файловая, сетевые стеки, GUI, USB
Весь список виден в Micrium Platform Builder.

Но риалтайм ( т.е. как быстро обрабатываются задачи и прерывания и как расходуются ресурсы процессора) это отладить не помогает.

На PC я отлаживаю исключительно сторонние программные модули с неизвестным потреблением памяти.
Все остальное не оправдано, поскольку такие IDE как IAR с SWD компилируют и загружают на целевую платформу почти с такой же скоростью как и в Visual Studio под Windows

Это да, но под виндой лучше дело с логгированием и сохранением разных отладочных данных (есть файловая система для этого). И это сохранение практически не влияет на работу отлаживаемого кода.

Бесплатная то она бесплатная, но мне только через 2 месяца пришел ответ типа извините мы были перегружены запросами, хотим продолжить общение.
И на очередной запрос опять зависли.


RTT через SWD логгирует с той же скоростью и также может писать в файлы.
Но главное эти логи можно оставить в релизной версии.
Т.е. сорсы не приходится править и захламлять условными препроцессорными директивами.

Кстати вот как я тестировал FatFS на целевой платформе - https://geektimes.ru/post/274416/
Ну зачем мне там нужно было бы делать это на PC?

Вот вопрос как это делается, где почитать/посмотреть/скачать пример этого...


Собственно на PC не нужно отлаживать реалтайм, на PC нужно показать как все это работает. Например вместо считывания данных в прерывании считывать данные из файла.
Вопрос только как именно это сделать, если на мк есть прерывание и функциа типа ISR_ADC(), то на PC(в консольном приложении) как имитировать периодический вызов функции чтения из файла?

В Micrium OS есть эмулятор контроллера прерываний.
Задаете там через специальные функции интервал срабатывания и указываете callback функции для обработки прерываний.
В тех функциях стандартно пользуетесь API Windows для чтение из файлов сервисами RTOS для передачи флагов. И все.

Micrium платный. да еще за IAR платить надо.

Проще тогда наверное Keil с его ОС использовать. Хоть только за Keil платить придется...

Сообщение отредактировал Zelepuk - Mar 31 2017, 13:03

Что делается? Я вроде описал всё. Документация по конкретным функциям есть в исходниках uCOS.