Посмотрите сколько стоят анализаторы удовлетворяющие 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.



Сообщение отредактировал Zelepuk - Jun 30 2012, 17:10

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 раздел про отличия потоков и процессов. Как ни назови, задача - это по сути и есть поток, хотя правильнее сказать процесс.