На досуге появилась идея.
Можно ли реализовать следующую систему:

по COM-порту (для примера) в некий хост передаётся сигнал, далее происходит обработка сигнала по алгоритму ЦОС. И хост выдаёт в другой COM-порт уже обработанные данные.
При этом обработка должна идти в жёстком RealTime.

Как я это вижу: существует некая плата (скажем на ARM-контроллере), которая посылает в компьютер числа непрерывно(сигнал). Теперь самое интересное: компьютер под управлением QNX (альтернативы?) обрабатывает данные в соответствии с программой (MATLAB Simulink + C) и посылает данные в порт (или на коакую либо плату вывода).


Есть ли какие-нибудь источники по сабжу?
Ваши мнения, господа?

это что-то вроде автоматизированной системы технического контроля?
то есть примерно так:
с параллельного порта выдаю байт - далeе на плис - далее на устройство тестирования.
с устройства - на плис - и в параллельный порт (а тут уже анализируем что пришло и что должно было придти.)
итд.
собственно этим занимаюсь..

Незнаю... плис не хотел задействовать.

хочу посылать данные в ком-порт микроконтроллером (отсчёты сигнала лежат в ПЗУ). Далее принятые данные обрабатываются в компьютере и передаются по второму ком-порту уже обработанные данные. и всё это в реальном времени.

Хочу использовать QNX в компьютере и MATLAB Simulink для написания программы обработки данных.
(компьютер, обрабатывающий данные x86 совместимый)

Возможно ли такое в домашних условиях?

MATLAB умеет работать с COM портом на прямую..

Я думаю реально но!
что значит реал. тайм.
на какой частоте это все будет работать?
на практике оказалось что на процессоре 500mhz - я достиг частоты (то есть между командами выдать, принять с одного порта) примерно задержка в 2миллис.
т.е. до мгц ещё далеко.

TigerSHARC, если на MATLAB/Simulink, то посмотрите в сторону xPC Target сюда или сюда

Обработка осуществляется на процессоре бытового компьютера E2140 1.6Гц

Если просто под виндой работать - то это никакой не реалтайм.

Я вот рассматриваю вариант с QNX. Программа оиентировочно будет написана на MATLAB Simulink, она будет работать с двумя ком-портами.

Теперь про частоты дискретизации.

Планируется принимать данные с внешнего источника на пределе возможностей ком-порта (128 kb/s - стало быть частота выборок (16 битные данные) 8000 в секунду т.е. 8 кГц) Дело в том что микроконтроллер будет посылатьв компьютер подобие выборок с АЦП (эмуляция АЦП).

Время отклика? хмм... верхняя граница по расчётам 0.2 с. - не медленнее.
(т.е. за это время компьютер под управлением QNX и программы должен обработать блок данных из 0,2*8000 = 1600 выборок и выдать результат, а затем приступить к обработке следующего блока)



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

так вот в моём случае реалтайм система - это скажем обычный компьютер, но под управлением QNX, дабы обеспечить гарантированый отклик

Если использование нелицензионного софта не мучает вас ночами, то xPC это самое оно. На машине устанавливается ОС работающая в режиме жесткого реального времени, затем с другой машины на нее заливается программа получаемая нажатием кнопок Ctrl+B из симулинковой диаграммы. Минимальный квант времени в районе 1*10^-4 сек.

Нет. Вы создаете модель в Симулинке, затем "легким движением руки" переносите ее на PC-компьютер с ОС реального времени (которая поставляется вместе с xPC Target) и эта ваша модель на нем выполняется. "реальность" зависит от многих факторов, в числе которых: скорость PC, сложность модели. Также Вы можете заводить в эту модель сигналы с плат ввода/вывода (если такие есть) или по последовательным интерфейсам типа RS232 и модель будет их в реальном времени обрабатывать.
Из Ваших слов я не понял, что означает "моделируется сигнал на компьютере, затем переносится в реалтайм систему" ? В данном случае Вы можете заводить данные с "живого" железа, главное чтобы были соответствующие платы ввода/вывода.

Тем более, если Вы говорите: то Вам тем более стоит посмотреть в сторону xPC Target. Не думаю, что разобраться с xPC Target займет больше времени, чем освоение и прикручивание QNX к Вашей задаче. И 8кГц получить думаю вполне сможете (зависит от сложности Вашей обработки этого сигнала)

Это что-то новенькое! Интересно. Вместо QNX поставить xPCTarget это как?
Если знаете расскажите подробнее.
Вас послушать, так xPC это самое то! Буду читать Help матлаба... думаю там всё что надо есть.
Только по таким вещам как RealTime Workshop и С Compiler хелп какой-то "мутный" в матлабе...

Если вместе с xPCtarget поставляется ОС, то её тоже нужно освоить... интересно...

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

Там осваивать ничего не надо, все за Вас сделает Simulink с RealTime Workshop

Можно потом для этого всего год сгенерить сишный для DSP-процессора?

Для чего "всего этого" ? Вообще код сишный генерить для DSP-процессора Simulink давно уже умеет. И вот уже года 3 HDL для ПЛИС.

Неадекватное восприятие однако реальности.
Как вы себе представляете перенос проекта из MATLAB-а в QNX?
dll-ку или exe-шник думаете скопировать?
Вариант у вас только один только - получить из matlab-а полные исходники вашего проекта с заглушками для уровня абстракции от хардваре.
Тут проблемы во всем.
Во первых исходники всего в матлабе получить невозможно есть только подмножество примитивных алгоритмов для которых можно получить исходники.
Во вторых уровень абстракции хардваре в QNX кардинально отличается от уровня абстракции под Windows.
Значит кардинально придется перепахивать те немногие добытые тексты.
Далее придется их запускать заново откомпилированные на QNX и заново делать профайлинг. При этом не забыть что работаете совершенно на другом уровне хардваре с неизвестным быстродействием.
Никакие фичи риалтайма QNX здесь не помогут поскольку в модели MATLAB их использование не предусмотрено.
Т.е. QNX будет работать по отношению к модели точно так же как Windows XP если не хуже поскольку драйвера MATLAB-а под Win XP все таки оптимизируют, а такой операционки как QNX MATLAB не знает.

Я бы помотрел на LabView с пакетом для embedded. Там среда сразу компилит под ARM и может делать профайлинг на целевой платформе.
Поскольку весь софт для вас черный ящик то единственным гарантом риалтайма является не чудесная операционка, а результаты профайлинга и ничего больше.

Автор, если вопрос еще актуален:

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

Обработку данных в реальном времени можно производить и в совсем классическом Linux и даже в Windows, главное, чтобы скорость выполнения одной итерации была намного больше скорости обновления данных (или получения новых данных в вашем случае). Если это условие не выполняется то никакая ОСРВ не поможет получить гарантированный отклик.

Чтобы заставить модель, разработанную в симулинке в работать в реальном времени нужно обеспечить заданную частоту итерации.
То есть если у вас в модели задан timestep=125e-6 (8000 Гц) то в приложении функция blabla_x86_step(0) и должна вызываться 8000 раз в секунду. Делается это достаточно просто с использованием высокоточного таймера (QueryPerformanceCounter - win, gettimeofday - linux). 8кГц слишком небольшая частота чтобы привлекать QNX.

Попробуйте в приложении измерить время одной итерации, оно должно быть меньше 125 мкс. Не забудьте учесть погрешность его определения (для Linux ~5%) а также относительное отклонение, так как это не ОСРВ (5-15%). Если рабочий цикл (функция step и обмен данными) уложится в 80-90 мкс система будет работать.
Перед началом обработки не забудьте накопить некоторый объем исходных данных в несколько отсчетов, т.к. чтение из ком-порта при пустом буфере займет время, а чтение при наличии данных составляет несколько мкс (копирование производится уже из памяти входящего FIFO).

Все остальное зависит от вас.

Здесь же упоминали о xPC и ОСРВ входящую в её состав. Якобы матлаб сам решил эту проблему за нас.
ну да ладно.

Вы говоите о возможности функционирования в реальном времени. В Windows это теоретически невозможно. Так как может возникунть какое-либо событие способное вызвать задержку.

AlexandrY, если это вопрос ко мне, то я нигде и не предлагал переносить проект из MATLAB в QNX. Топикстартер озвучил задачу, я ему предложил в качестве ее решения использовать xPC Target. Вы, видимо, человек знающий QNX, скажите, какое минимальное времена отклика можно получить на этой ОС ? Насколько сложно под нее программировать, по сравнению например с Linux с "патчами" для реального времени ?

Стоит отчетливо понимать, что xPC Target с ее ОСРВ это не панацея и не готовое решение для каких-либо серьезных промышленных задач (ну например управление АЭС). Это система для быстрого прототипирования и тестирования в условиях, приближенных к боевым. Если для решения Вашей конкретной задачи не нужны микросекунды, то xPC Target вполне себя оправдывает хотя бы даже если оценить сложность создания этого тестового окружения.


Опять же, все зависит того, какое время отклика Вам нужно. Я видел как модель Simulink'a исполняемая в винде управляла системой магнитов для управления левитацией металлического шарика в воздухе. Они там использовали это решение

Но в Виндовс по сути вообще может не наступить отклика. Это из теории всё.

Если операционная система не "реального времени", то отклик в лучшем случае непредсказуем.


P.S. не подскажете где про линукс и патчи почитать?

Ну вот что матлабовцы пишут:

Real-Time Kernel

Real-Time Windows Target software uses a small real-time kernel to ensure that the real-time application runs in real time. The real-time kernel runs at CPU ring zero (privileged or kernel mode) and uses the built-in PC clock as its primary source of time:

Timer interrupt — The kernel intercepts the interrupt from the PC clock before the Windows® operating system receives it. The kernel then uses the interrupt to trigger the execution of the compiled model. As a result, the kernel is able to give the real-time application the highest priority available.

The kernel is provided as a kernel-mode driver. To achieve precise sampling, the kernel reprograms the PC clock to a higher frequency. Because the PC clock is also the primary source of time for the Windows operating system, the kernel sends a timer interrupt to the operating system at the original interrupt rate.

Scheduler — The timer interrupt clocks a simple scheduler that runs the executable. The number of tasks is equal to the number of sampling periods in the model with multitasking mode. With single-tasking mode, there is only one task. The maximum number of tasks is 32, and faster tasks have higher priorities than slower tasks. For example, a faster task can interrupt a slower task.

During execution, the executable stores data in buffers. Later, the data in these buffers is retrieved by the Scope block. The scheduling, data storing, data transferring, and running the executable all run at CPU ring zero.

Communication with hardware — The kernel interfaces and communicates with I/O hardware using I/O driver blocks, and it checks for proper installation of the I/O board. If the board has been properly installed, the drivers allow your real-time application to run.

You can choose to have a driver block use values equal to voltage, normalize values from 0 to +1, normalize values from -1 to +1, or use the raw integer values from the A/D or D/A conversion press. Drivers also run at CPU ring zero.

Simulink external mode — Communication between Simulink software and the real-time application is through the Simulink external mode interface module. This module talks directly to the real-time kernel, and is used to start the real-time application, change parameters, and retrieve scope data.


ээ нет, тут я Вам совсем не советчик. Просто давным давно интересно было, читал, но жизнь пошла по пути проектирования ПЛИС, там это знать не надо

Как я понял у этой системы (xPC Target http://sl-matlab.ru/services/products/deta...497&list=c) полоса пропускания 5кГц. Для начала пойдёт конечно. Но если хочется большего?

Скажем частота дискретизации сигнала 100кГц и выборки поступают по более скоросному инерфейсу нежели COM-порт.

Из всего, что прочитал по xPC Target не понятно какая операционка должна стоять на target PC(компьютер где будет реализован алгоритм).

В графе операционная систма написано: None(!). а дальше говорится что xPC Target не оказывает никакого влияния на установленную операционную систему. Так же говорится что таргет писи(исполняющий комп) будет загружать xPC Target с внешнего источника и никакая установка не требуется.

Так не понятна нужна операционка или нет...

TigerSHARC, прочитайте это, многие вопросы отпадут.

тогда отдельное устройство без ОС, которое будет заниматься только обработкой одного процесса.

Следуя вашей логике функционирование в реальном времени будет невозможно ни в Linux ни в QNX, т.к. там тоже может возникнуть (и возникают) события, которые могут приостановить ваш процесс. Разница лишь в том, что Linux с Win приостановит его на n+d задержку, где d будет меняться в диапазоне, а QNX приостановит на n задержку.

Функционирование будет таким, каким вы его сделаете. Люди даже синхронное управление осями станков с ЧПУ делают от х86 без дополнительных контроллеров и QNX, а вы говорите невозможно...

Все возможно, если захотеть. Впрочем, делайте как знаете.

Я всего лишь прочитал несколько статей по ОСРВ вот и всё.

Пакет XPC Target это хорошо, но не надо забывать, что есть пакет Real-Time Windows Target, который как раз не требует второго компьютера и дает под виндой задержку не более 30 мкс.
Проверял на прототипах с платами Advantech PCI-1716, PCI-1713 при частоте дискретизации 10 кГц.
Комп - обычный пень на 2 ГГц.

Но это для прототипов, а для реализации RTX for Windows от intervalzero.com
Задержка не более 3 мкс при выделенном ядре от двухядерного проца.

Кстати на форуме по QNX http://qnx.org.ru/forum/ можете почитать, как некоторые QNX программеры пробовали RTX for Windows. QNX местами отдыхает.

----
AlexOr



А вы случаем не путаете Real-Time с потоковой обработкой высокоскоростных каналов?

Для чего же Вам нужен контур управления на 100 кГц?
ЗЫ - между значением и размерностью нужно ставить пробел - инженерная грамота

---
AlexOr

Система подразумевает, что АЦП по 10 каналам оцифровывает данные с частотой 100 кГц (максимум) на канал. Затем система обрабатывает данные в реальном времени и принимает решение (отключение нагрузки к примеру). Решение должно быть принято, пока новый блок данных не пришёл. Кажды новый блок накапливаются в течении скажем 0,5 сек.

Тогда допустима летентность 0,5 c минус время обработки. Например время обработки 0,1 с, значит латентность допустима до 0,4 с.
Это очень скромное требование для Real-time.

---
AlexOr