Требуется разработать измеритель.
Аппаратная база: МК + внешний АЦП + дисплей
Задачи, которые нужно обрабатывать в программе:
1) принимать данные с АЦП через SPI по внешнему прерыванию и записывать в кольцевой буфер (частота дискретизации порядка 25кГц)
2) каждые 10 мс. производить обработку блока данных с АЦП по некоторому алгоритму;
3) усреднять данные полученные в п.2 каждые 3 секунды
4) записывать данные, полученные в п.3 на SD-карту (история)
5) обрабатывать запросы через Ethernet (задать время внутренних часов, считать данные с SD-карты, задать калибровочные коэффициенты для АЦП и пр.)
6) обновлять данные на дисплее каждые 3 секунды

Встал вопрос: как организовать программу?
вариант, который приходит на ум:
1)Суперлуп. В основном цикле которого производится опрос флагов( таких как "накопился буфер с АЦП" и пр.). Здесь так же работают прерывания: от АЦП - ложим отсчёт в буфер; от порта Ethernet - обрабатываем сообщения; от таймера - прошло 3 секунды и пора делать усреднение результатов.
2) По прерываниям от таймера делать переключение задач (каруселька)
Что лучше в данном случае и что ещё можно применить?

просто я "панически" боюсь таких терминов как "синхронизация потоков", "мьютексы", "семафоры" и прочее...

Ответ на этот вопрос зависит от МК, который будет в изделии, так как допустим АВР на 8 МГц это одно, а какой-нибудь CortexM на 80 МГц - это совсем другое.


Зачем такое вообще применять? Или есть готовое-освоенное?

Сложность скорее представляет Ethernet и SD-карта, если оно не использовалось ранее.

планирую использовать что-нибудь из AT91 серии. Для Ethernet есть проект uip для sd-карты тоже есть библиотека.
Для AT91 есть большой соблазн использовать Linux, но я ума не приложу как сделать обработку каждые 10мс. Есть драйвера под Linux для АЦП c с реализоваными кольцевыми буферами(та же подсистема IIO от AD). Но какой механизм применить под Linux, чтобы каждые 10мс обрабатывался блок накопленных отсчётов, и каждый раз это происходило непрерывно во времени.

Но, возможно, Linux тут совсем не подходит.

Может линукс и неподходит, но есть куча вытесняющих ОСей под AT91 - выбрать есть из чего. И с 10 мс проблем наверняка не возникнет. И если Ethernet и SD реализованы, то дело за малым - начать да кончить.

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

А сработает ли суперлуп как я писал выше?
Опыта работы с ОС кроме Linux нет. Но в Linux не знаю как осуществить обработку данных с АЦП каждые 10 мс? поиожет бюольшой кольцевой буфер?



Я дкмал суперлуп с опросом флагов избавлен от таких сложностей.

Если не хотите стандартную rtos, то можете сделать в виде суперлупа, в котором будут поочередно вызываться функции(конечные автоматы) из кольцевого буфера "задач". Это очень полезно, т.к. в конце пути осознаете целесообразность делать следующий проект на какой-нибудь ртос.


А все эти слова придуманы, чтобы разделять общие данные. Например в Вашем случаи история на sd-карте может запрашиваться по эзернету, когда вы в неё пишите. Кстати синхронизацию потоков Вы делаете постоянно, когда есть данные, которые используются и в прерывание, и в основной программе.

А если реализация будет в виде суперлупа, в котором будут поочерёдно вызываться функции(конечные автоматы) как вы рекомендовали, что будет когда в момент записи на SD-карту происходит запрос по Ethernet? запрос будет просто ждать своей очереди?

можно использовать poll в юзерспейс, при известной частоте дискретизации заранее известно сколько измерений нужно для 10 мс, задать буфер на 20 мс - процесс автоматически будет активирован когда данные готовы для обработки.

Linux тут явно не конкурентное решение. Да и AT91 прошлый век.

Специально для таких задач разработаны двух-ядерные микроконтроллеры вроде: LPC4350

На основном ядре работают стеки TCP/IP, GUI, файловая система, отладочные мониторы и т.д.
На вспомогательном ведется цифровая пред-обработка данных, например фильтрация, поиск экстремумов, интегрирование и т.д.

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

Кстати о RTOS, перечисленными вами вещами как: "синхронизация потоков", "мьютексы", "семафоры" практически не пользуюсь.
Это знаете ли, пережитки больших осей, где каждая задача как черный ящик для программиста.
В малых осях можно напрямую читать и писать переменные разных задач не применяя никаких объектов синхронизации, просто зная кто еще, как и когда к ним обращается.
А сделать это в обозримых сорсах не представляет проблем. И надежность в целом повысится, так как чем меньше сервисов используете тем меньше проблем оси получаете в виде инверсии приоритетов и взаимных блокировок.
Единственно что действительно понадобится это сервисы очередей и событий. И практически все!

Вообщем берите vxWorks и не пожалеете. Там будет все : мультихостовый TCP/IP, FTP клиент/сервер, клиент NTP, реентерабельную FS и т.д.
Или RL ARM. Сразу готовое на LPC4350 получите.
Найдете на ftp.

Ну почему не конкурентное? Вот это девайс http://mirmsk.ru/uake_analizator_kachestva_elektroen (как раз обрабатывает данные на частоте сотен кГц) работает под управлением Linux.
Среди AT91 сейчас есть камни с 400мГц частотой ядра и DDR-памятью.

А vxWorks всё-таки не бесплатное решение.

Функции этого дивайса может выполнить чип за 10$ -
http://www.analog.com/en/analog-to-digital...roducts/product.

О какой тут конкурентоспособности вообще речь???

Я рекомендую повнимательнее взглянуть на функционал девайса(анализатор качества) и микросхемы, ссылку на описание которой вы дали. ADE7880 - всего лишь счётчик электроэнергии.
Анализатор же позволяет записать сигнал (функция самописца). Позволяет анализировать сигнал в течении одного периода, что даёт возможность оперативно зафиксировать провал или перенапряжение, а не просто посчитать действующее значение и мощность.
Сравните цены к примеру на Satec PM175 и простой счётчик (на базе ADE).

Прошу не относится к вопросу поверхностно.

Человек просто далекий от энергетики - для него счетчик ЭЭ это предел мечтаний



в общем немного из того что есть в Linux но похуже и за деньги.

Как раз такой Satec я разбирал. Там внутри стоял довольно убогий по сегодняшним меркам 16-и битный микроконтроллер. Естественно там линукс рядом не лежал.
Да, одна микросхема от AD еще не все делает, к ней достаточно прикрутить STM32 за пару баксов и тогда будет полное удовольствие.

Посмотрите сколько стоят анализаторы удовлетворяющие IEC 61000-4-30 Class A и идите ближе к лесу со своими советами

Посмотрел как реализуется событийная (набор конечных автоматов вызываемых из кольцевого буфера). Впринципе не сложно.
Только вот что будет если например при записи на SD карту, произоёдет запрос по Ethernet на чтение из SD-карты?
Иними словами, чем в итоге отличается такой метод от ОСРВ? скорость пострадает? так как придётся ждать, пока произойдёт вызов соответствующей функции из кольцевого буфера?


И что тогда она будет уметь? Разве что выводить данные на дисплей и общаться с внешним миром. ADE7880 хоть и хорошее решение, но она суть чёрный ящик, который просто выдаёт вычисленные значения. А если я хочу THD тока узнать до 40-й гармоники? тут хоть STM62 ставь, но если ADE7880 этого не умеет - то не умеет.



простите, откуда вы взяли этот текст:
Each ring buffer typically has an event chrdev (similar to the more general ones above) to pass on
events such as buffer 50% full and an access chrdev via which the raw data it self may be read back.

http://wiki.analog.com/software/linux/docs...iio?force_rev=1

Думаю нам стоит извинится перед пользователем AlexandrY. ADE7880 - измеряет в соответствии с IEC 61000-4-7 Class I. Я был очень удивлён, когда увидел что умеет эта микросхемка.
Для меня это настоящий прорыв. Что поделать - прогресс.

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

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

Хотя с микросхемами от AD я работал и знаю, что они и сырые сэмплы всегда могли выдавать.
С другой стороны вот буквально на днях анонсирован STM32F3 на Cortex-M4 с 3-х канальным 16-и битным прецизионным ADC.
Так что тему дорогих анализаторов прочно убили.

Но мы что-то отвлеклись от начальной темы.

Чтобы работало суперкольцо надо как минимум:
-программные модули типа файловой системы или сетевого стека не должны использовать программных циклов ожидания внутри себя, т.е. полинга
-программные модули не должны требовать детерминированных периодических вызовов своих функций (скажем для ведения внутренних таймеров)

По сути все исходники надо прошерстить чтобы убедиться в выполнении этих критериев.

RTOS позволяет этого не делать. Собственно в этом ее гигантское преимущество.
Линукс тож как бы это же самое предоставляет, но накладных расходов просто больше.

Как то с памятью у них бедно, STM32F303VC ...

Но Linux для меня как-то роднее и проще. Опишу большой плюс Linux из практики:
нужно было реализовать протокол связи стандартный, исходники которого в сети не встретишь. Но волей случая нашел в сети Perl-библиотеку.
и теперь один процесс просто пишет измеренные данные в файл, а второй процесс (назовем его шлюз) - читает данные из файла и шлет по протоколу в сеть.
Всё просто и быстро.

Но, конечно есть и минусы: я использую мощный процессор и большую(64 Мбайт) sdram, что , ясное дело, недёшево в сравнении с тем же stm32F207(для примера)

Вот так и появляются 'супер надежные' системы типа Therac-25. Никаких объектов синхронизации, своя собственная небольшая ОСРВ, свои задачи (всего 3 штуки), все знают что и где пишется. Результат - 8 трупов

Я не рекомендовал, я лишь сказал, что можно сделать так. И что это будет даже полезно - поймете необходимость в следующей разработке использовать ртос.
На счет одновременного доступа к sd-карте - тут уже Вам решать. =) Определитесь что вы хотите получать по езернету - историю нескольких последних измерений или целиком все файлы, имеющиеся на карточке. Определитесь, как именно Вы будете писать историю, учитывая, что при fat32 больше 4 Гб файлы быть не могут.


Вы читали задачи, которые требуются решить автору? Микроконтроллеры с 2мя ядрами - это, конечно, хорошо. Но надо не терять связь с реальностью. =)

Довольно интересное суждение, Therac-25 уже привели. Но если прочитать первое и последнее предложение, то выходит несколько противоречиво. Ведь события и очереди - это объекты синхронизации потоков.

Желательно получать все файлы. 4Гб - думаю что этого хватить для всей системы (Linux) + одна папочка (куда надо писать и откуда надо читать информацию). В папке будут короткие фалы осциллограмм(сырые отсчёты с АЦП), записываемые туда непериодичеки, а так же периодическая информация, обновляемая каждые 3 секунды.

А периодическая информация будет дописываться в один большой файл?
У меня, например, была задача писать видео на sd карту и одновременно его отдавать по езернету, а вот отдавать все файлы по сети мне надо было при отсутствующей записи на sd.
У Вас же постоянно идет запись, но не очень интенсивно. Так что, например, просто при каждой дозаписи в файл закрывайте его, чтобы при необходимости другая задача (конечный автомат) могла выкачать часть файла в ОЗУ, из которого эзернет будет кушать.
И обязательно прикиньте необходимую скорость для записи - у sd карты есть документированная задержка независящая от класса карты. Чтобы добиться высокой скорости записи приходится применять буферизацию. Тема на этом форуме поднималась часто.

Что-то реальность вас не слушается.
LPC43xx уже продается, я уже не говорю о всяких OMAP-ах с 5-ю разными ядрами на борту.
Или вы о чем?



Могу припомнить, что приемы межзадачного обмена без сервисов синхронизации в современных ARM-ах введены на аппаратном уровне.
Если цепляться к терминологии, то в малых RTOS нет потоков, а есть только задачи.

Я автора скорее бы предостерег от использования SD карт как надежных решений для записи большого количества файлов.
Ибо FAT системы начинают сильно тормозить и сбоить когда количество существующих или стертых файлов переваливает тысячу.

Есть большие сомнения в целесообразности "запихивания" всех перечисленных задач в один МК. Даже если он двухядерный.
На мой взгляд, связка из двух МК здесь предпочтительнее. Первый МК занимается задачами 1-2 (или 1-3), второй МК - задачами 3-6 (или 4-6).
Каждый занимается своим делом и не мешает другому. Объем передаваемых между ними данных будет не особо велик.
Если пойти дальше в этом направлении, то стоит заменить второй МК на ПК. Тогда задача совсем упрощается.

Я об избыточности предлагаемой Вами элементной базы на данную конкретную задачу. Не буду спорить на тему целесообразности "мигания светодиодом на linux", но у меня аналогичная с автором топика задача + lcd, +прием потока в 2 МБайта/с ложилась хорошо на один arm7.
А к lpc43 я и сам приглядываюсь, но это на проекты, где нужно действительно сложную математику выполнять.

Ох, слишком высокие материи пошли. Я почитал в той же wiki раздел про отличия потоков и процессов. Как ни назови, задача - это по сути и есть поток, хотя правильнее сказать процесс.

Элементная база может быть избыточна для функциональности даже спорить не буду.
Но суть проблемы не в функциональности, а в надежности и скорости разработки.
Появление таких процессоров как LPC43xx или Vibrid кое что означает.
Разработчики этих решений в первых же строках указывают, что это драматически упрощает разработку!
Как вы думаете за счет чего?
Явно проще программировать не становится и ошибок меньше не станет... Так в чем же дело, откуда такой тренд? ...

А задачи не надо никак обзывать, они уже названы.
А перенос на задачи RTOS представлений из GPOS только запутывает суть дела.
Ибо в задачах RTOS тоже наблюдается отдельное понятие потоков, только это совсем не те потоки.

Вы явно уходите в высокие материи и термины, а я туда не хочу.

Я обратил внимание на непоследовательность Ваших суждений. На первой странице Вы красочно описали, что не используете объекты синхронизации, что пишите переменные на прямую, зная когда к ним обращаться. Но в конце вдруг заметили необходимость сервисов очередей и событий. А ведь они и есть объекты синхронизации, которые преданы Вами анафеме. И совершенно не важно, что объекты синхронизации я обозвал средствами синхронизации потоков. Ведь понятно о чем идет речь.

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

Хотя может быть семафоры оставлю. Пусть живут.
Дело в том, что семафоры чаще используются в реентерабельном middleware и драйверах.
Но вы это часто получаете готовым.
Реализуя же собственное приложение, чаще делаются единичные экземпляры задач с взаимодействием многие к одному.
И тут семафоры редко нужны.

мне сейчас как раз нужно реализовать нечто подобное. Где можно посмотреть пример использования poll?