|
Моделирование/макетирование RealTime, интересно узнать |
|
|
|
Dec 19 2010, 15:21
|
Знающий
   
Группа: Свой
Сообщений: 688
Регистрация: 4-09-09
Пользователь №: 52 195

|
Цитата(SeriouSerg @ Dec 19 2010, 21:06)  Автор, если вопрос еще актуален:
делал что то подобное - прием данных по последовательному порту, обработка, выдача по 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 это теоретически невозможно. Так как может возникунть какое-либо событие способное вызвать задержку.
|
|
|
|
|
Dec 19 2010, 16:58
|
Частый гость
 
Группа: Свой
Сообщений: 166
Регистрация: 7-09-05
Из: Москва
Пользователь №: 8 340

|
Цитата(AlexandrY @ Dec 19 2010, 15:17)  Неадекватное восприятие однако реальности. Как вы себе представляете перенос проекта из MATLAB-а в QNX? AlexandrY, если это вопрос ко мне, то я нигде и не предлагал переносить проект из MATLAB в QNX. Топикстартер озвучил задачу, я ему предложил в качестве ее решения использовать xPC Target. Вы, видимо, человек знающий QNX, скажите, какое минимальное времена отклика можно получить на этой ОС ? Насколько сложно под нее программировать, по сравнению например с Linux с "патчами" для реального времени ? Стоит отчетливо понимать, что xPC Target с ее ОСРВ это не панацея и не готовое решение для каких-либо серьезных промышленных задач (ну например управление АЭС). Это система для быстрого прототипирования и тестирования в условиях, приближенных к боевым. Если для решения Вашей конкретной задачи не нужны микросекунды, то xPC Target вполне себя оправдывает хотя бы даже если оценить сложность создания этого тестового окружения. Цитата Вы говоите о возможности функционирования в реальном времени. В Windows это теоретически невозможно. Так как может возникунть какое-либо событие способное вызвать задержку. Опять же, все зависит того, какое время отклика Вам нужно. Я видел как модель Simulink'a исполняемая в винде управляла системой магнитов для управления левитацией металлического шарика в воздухе. Они там использовали это решение
|
|
|
|
|
Dec 19 2010, 18:44
|
Частый гость
 
Группа: Свой
Сообщений: 166
Регистрация: 7-09-05
Из: Москва
Пользователь №: 8 340

|
Ну вот что матлабовцы пишут: 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. Цитата P.S. не подскажете где про линукс и патчи почитать? ээ нет, тут я Вам совсем не советчик. Просто давным давно интересно было, читал, но жизнь пошла по пути проектирования ПЛИС, там это знать не надо
|
|
|
|
|
Dec 20 2010, 02:22
|
Знающий
   
Группа: Свой
Сообщений: 688
Регистрация: 4-09-09
Пользователь №: 52 195

|
Как я понял у этой системы (xPC Target http://sl-matlab.ru/services/products/deta...497&list=c) полоса пропускания 5кГц. Для начала пойдёт конечно. Но если хочется большего? Скажем частота дискретизации сигнала 100кГц и выборки поступают по более скоросному инерфейсу нежели COM-порт.
|
|
|
|
|
Dec 20 2010, 09:46
|
Частый гость
 
Группа: Свой
Сообщений: 166
Регистрация: 7-09-05
Из: Москва
Пользователь №: 8 340

|
TigerSHARC, прочитайте это, многие вопросы отпадут.
|
|
|
|
|
Dec 20 2010, 10:24
|

Местный
  
Группа: Свой
Сообщений: 214
Регистрация: 6-06-05
Из: г. Таганрог
Пользователь №: 5 759

|
Цитата(TigerSHARC @ Dec 19 2010, 21:21)  Здесь же упоминали о xPC и ОСРВ входящую в её состав. Якобы матлаб сам решил эту проблему за нас. ну да ладно.
Вы говоите о возможности функционирования в реальном времени. В Windows это теоретически невозможно. Так как может возникунть какое-либо событие способное вызвать задержку. тогда отдельное устройство без ОС, которое будет заниматься только обработкой одного процесса. Следуя вашей логике функционирование в реальном времени будет невозможно ни в Linux ни в QNX, т.к. там тоже может возникнуть (и возникают) события, которые могут приостановить ваш процесс. Разница лишь в том, что Linux с Win приостановит его на n+d задержку, где d будет меняться в диапазоне, а QNX приостановит на n задержку. Функционирование будет таким, каким вы его сделаете. Люди даже синхронное управление осями станков с ЧПУ делают от х86 без дополнительных контроллеров и QNX, а вы говорите невозможно... Все возможно, если захотеть. Впрочем, делайте как знаете.
|
|
|
|
|
Dec 20 2010, 11:00
|
Знающий
   
Группа: Свой
Сообщений: 688
Регистрация: 4-09-09
Пользователь №: 52 195

|
Цитата(SeriouSerg @ Dec 20 2010, 16:24)  тогда отдельное устройство без ОС, которое будет заниматься только обработкой одного процесса.
Следуя вашей логике функционирование в реальном времени будет невозможно ни в Linux ни в QNX, т.к. там тоже может возникнуть (и возникают) события, которые могут приостановить ваш процесс. Разница лишь в том, что Linux с Win приостановит его на n+d задержку, где d будет меняться в диапазоне, а QNX приостановит на n задержку.
Функционирование будет таким, каким вы его сделаете. Люди даже синхронное управление осями станков с ЧПУ делают от х86 без дополнительных контроллеров и QNX, а вы говорите невозможно...
Все возможно, если захотеть. Впрочем, делайте как знаете. Я всего лишь прочитал несколько статей по ОСРВ вот и всё.
|
|
|
|
|
Jan 12 2011, 16:50
|
Частый гость
 
Группа: Свой
Сообщений: 89
Регистрация: 30-12-04
Из: Санкт-Петербург
Пользователь №: 1 754

|
Пакет 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 Цитата(TigerSHARC @ Dec 20 2010, 08:22)  Скажем частота дискретизации сигнала 100кГц и выборки поступают по более скоросному инерфейсу нежели COM-порт. А вы случаем не путаете Real-Time с потоковой обработкой высокоскоростных каналов? Для чего же Вам нужен контур управления на 100 кГц? ЗЫ - между значением и размерностью нужно ставить пробел - инженерная грамота--- AlexOr
|
|
|
|
|
Jan 13 2011, 12:19
|
Частый гость
 
Группа: Свой
Сообщений: 89
Регистрация: 30-12-04
Из: Санкт-Петербург
Пользователь №: 1 754

|
Цитата(TigerSHARC @ Jan 13 2011, 14:00)  Система подразумевает, что АЦП по 10 каналам оцифровывает данные с частотой 100 кГц (максимум) на канал. Затем система обрабатывает данные в реальном времени и принимает решение (отключение нагрузки к примеру). Решение должно быть принято, пока новый блок данных не пришёл. Кажды новый блок накапливаются в течении скажем 0,5 сек. Тогда допустима летентность 0,5 c минус время обработки. Например время обработки 0,1 с, значит латентность допустима до 0,4 с. Это очень скромное требование для Real-time. --- AlexOr
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|