Измеритель, как организовать программу? Опции

[Zelepuk]

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

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

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

[Lotor]

Встал вопрос: как организовать программу?

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

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

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

[Zelepuk]

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


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

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

[Lotor]

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

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

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

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

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

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

[Zelepuk]

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

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

[Lotor]

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

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