Графопостроитель (осциллограф) 1 МГц

Взял бы stm32F303 Discovery, с компом работать через USB в режиме виртуального COM-порта, и легко решается такая задача. Зачем такие сложности.

Строить график можно на чем угодно, я использую свою наколеночную реализацию на Qt.

Тебе надо запускать на одноплатнике какую-то RTOS и/или использовать DMA для забирания данных с АЦП

На форуме OrangePI была тема про «чистый» режим (Гуглить OrangePi bare metal)

Хотя я рекомендую забить и поставить просто мощный STM32 четырехсотой серии. Там можно все, в том числе вытягивать до 10 МГц с внешнего АЦП.

я тебе вот что скажу. USB во первых бывает разных версий, и дешевые контроллеры обычно содержат ту, которая на частоте 12мгц работает. Во вторых, там еще и режимы разные есть. Самый быстрый это bulk transfer, но это для дисков сделано. А у тебя влёгкую может и изохронный режим стоять. вот это как раз похоже на «1000 сообщений в секунду» - это режим для usb-мышек и клавиатур с джойстиками.

это может быть UART, CAN не важно

Вообще-то важно. Если там у тебя скорость 19200, то ты никак не передашь больше.

Взял бы stm32F303 Discovery, с компом работать через USB в режиме виртуального COM-порта

я исхожу прежде всего из того, что сейчас есть в наличии т.е. Orange Pi. Работа с USB сейчас не принципиальна. USB использовался с ноутбуком. Сейчас же может быть два варианта схемы. Такая же как и была: CAN->Преобразователь CANtoUSB->забираем данные из USB. Но тут вопрос в драйверах под Linux для имеющегося преобразователя CANtoUSB, тут выбора нет. А драйвера такие думаю отсутствуют. Второй вариант: CAN->преобразователь CANtoUART на любом контроллере->забираем данные из UART. Преимущества данной схемы в том, что не нужны драйвера для UART и конечно скорость работы UART удовлетворяет. Как-то так. а в чем сложности ? интересная инженерная задача )) скажите, а какие проблемы с USB у Orange Pi ?

Тебе надо запускать на одноплатнике какую-то RTOS и/или использовать DMA для забирания данных с АЦП

На форуме OrangePI была тема про «чистый» режим (Гуглить OrangePi bare metal)

работа с АЦП в данной задаче не производится, данные передаются по интерфейсу CAN, далее преобразование. Объяснил в посте выше. С Уважением )

Тебе надо запускать на одноплатнике какую-то RTOS и/или использовать DMA для забирания данных с АЦП

На форуме OrangePI была тема про «чистый» режим (Гуглить OrangePi bare metal)

Не могу редактировать свои сообщения пришлось повторить.

Посоветуйте, какую RTOS ? Про «чистый» режим поинтересуюсь, спасибо.

Сложности в том, что используются преобразователи, еще внешний контроллер для uart. Имеется в виду, что этот преобразователь к аппаратному COM порту подключаться будет? Это же скорость ниже плинтуса, как передавать 1 Мгц в реальном времени тогда. А одна отладочная плата stm32 решает все проблемы, но конечно тут проблемы что ее надо приобрести.

USB во первых бывает разных версий

интересно на какой частоте может работать USB в Orange pi ? Но в любом случае я склоняюсь ко второй схеме без USB, т.к. скорее всего будут проблемы с дровами для преобразователя CANtoUSB. Прочитайте пост через два поста назад ) С Уважением )

Вообще-то важно. Если там у тебя скорость 19200, то ты никак не передашь больше.

Давайте уточню. Я имел ввиду частоту передачи сообщений в секунду, а не частоту работы UART. Объясню: т.е., например, UART я использую на частоте 937500 kbaud, а передавать в секунду могу любое количество сообщений, хоть одно.

Я имел ввиду частоту передачи сообщений в секунду, а не частоту работы UART

Ты же понимаешь, что первое не может быть больше второго? Какой размер сообщения?

Допустим тупо два float числа. Тогда максимальное количество 14648 в секунду. Что малость не дотягивает до вожделенного миллиона.

А что вы собираетесь делать с построенным графиком? Что-то мне кажется, если полностью ответить на этот вопрос, приоритеты могут измениться.

Сложности в том, что используются преобразователи, еще внешний контроллер для uart. Имеется в виду, что этот преобразователь к аппаратному COM порту подключаться будет? Это же скорость ниже плинтуса, как передавать 1 Мгц в реальном времени тогда.

Для меня преобразователь не сложность. В принципе делается на раз на микроконтроллере PIC. Габаритов по сути никаких. Еще сразу стоит оговорить, может из сообщений выше было не понятно. Данный графопостроитель должен быть мобилен. Т.е. никаких стационарных PC и ноутбуков. График в планах выводить на 7"-дюймовый ЖК дисплей, ну или любой, попавшийся под руку, монитор через HDMI. Соответственно, подключаться к COM порту не будет. Максимальная скорость работы USART у микроконтроллера, например PIC, 937,5 kbaud, при частоте тактирования 30 МГц. Причем данная частота получается при использовании кварца 7500 КГц. В контроллере стоит схема-умножитель на 4. А при более высокочастотном кварце возможно использовать USART на 1875 kbaud (т.е.baudrate 1875000 Гц. Чуете ? ))))) ) . Думаю это у любого контроллера так. Стандарт все таки. Что уж там говорить про Orange Pi на ARMе. Т.е. делаем вывод, что вероятно USART в этом одноплатнике аппаратно сможет принимать на частоте, близкой к 1МГц. Вопрос в том, смогу ли я программно теперь обработать и построить точку на графике. И так в цикле. Принял, построил, принял, построил.

т.е.baudrate 1875000 Гц. Чуете ?

Конфигурация порта обычно описывается типа 8n1. Конкретно это означает 1 стартовый бит, 8 бит инфы, и 1 стоповый бит. Имееем эффективную скорость 80% или 1500000.

Далее. Тебе же не биты передавать? Явно какие-то значения. Допустим один байт на сообщение. Уже получается 187500.

Чуешь?

Ты же понимаешь, что первое не может быть больше второго?

Полностью согласен. Тогда уточним. При боудрэйте 937500 бит в секунду сколько можно передать байт информации ? В одном байте: один стартовый, 8 бит данных, один стоповый. Итого 10 бит. Делим 937500 / 10 получаем около 93,75 КГц. Что не дотягивает до 1 Мгц на один порядок. Ну да ладно )))) Пускай будет 93,75 КГц. Примем эту частоту как максимальную частоту сообщений в UART. Теперь нужно выяснить сколько байт максимум можно передать через USB в OrangePi Lite, а в перспективе Raspberry Pi 3.

А что вы собираетесь делать с построенным графиком? Что-то мне кажется, если полностью ответить на этот вопрос, приоритеты могут измениться.

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

Примем эту частоту как максимальную частоту сообщений в UART. Теперь нужно выяснить сколько байт максимум можно передать через USB в OrangePi Lite, а в перспективе Raspberry Pi 3.

Нет. Теперь тебе надо выяснить сколько байт занимает одно сообщение. И поделить на это число. Вот это и будет максимальная частота сообщений.

Формат сообщения есть?

Нет. Теперь тебе надо выяснить сколько байт занимает одно сообщение

Одно сообщение может занимать от 1 до 8 байт. Длина сообщения настраивается. Я пока принял длину в 1 байт. Понятно, что при 8 байтах, частота сообщений в 8 раз ниже. Но пока, буду исходить из одного байта в сообщении.

Какое АЦП и что за величину (в каких границах) меряет? Может удастся сжать поток.

Мужики, ну я же писал, нет АЦП. Данные прилетаю из сети CAN. Это уже никак не сжать. Частота данных, допустим длиной 1 байт, от 1кГц. Максимальную частоту данных я конечно очень загнул, сейчас только понял. Ну пускай максимум будет 10 кГц. В USART, работающий на 937500 Гц это вписывается с большим запасом. Можно, как посчитали выше, до 93,75 кГц (это частота данных, а не настройка USART). Вопрос то был не в тракте приема и как его упростить или реализовать. Сейчас для меня три главных вопроса, на которые я ищу ответ. Они в первом посте. Итого: примем, прием осуществляется по USART, настроенном на 937500 kbaud. Частота информации от 1 до 10 кГц (максимально возможная теоретически 93,75 кГц).

Все очень просто. Его необходимо смотреть на мониторе

1МГц отсчётов - «реальное время» - порядка 1000 обновлений в секунду - кто будет смотреть и на каком мониторе?

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

Если есть исходники от старой программы проще портануть её на freepascal + lazarus. Там и компоненты похожие есть (типа TAChart).

1МГц отсчётов - «реальное время» - порядка 1000 обновлений в секунду - кто будет смотреть и на каком мониторе?

С 1МГц данных загнул. Давайте возьмем 10 кГц. Монитор конечно же обновлять с такой частотой не нужно. За одно обновление можно выводить несколько принятых точек. При частоте обновления 25 кадров в секунду делим 10кГц на 25 получаем 0,4 кГц т.е. необходимо за одно обновление строить 400 новых точек. Далее вы можете этот график масштабировать и смотреть точку в любой момент времени.

Если есть исходники от старой программы проще портануть её на freepascal + lazarus. Там и компоненты похожие есть (типа TAChart).

За связку спасибо freepascal + lazarus. Посмотрю в этом направлении (хотя что это, пока не знаю))) ). Программу буду писать с нуля, т.к. прежний вариант писал в файл и строил после окончания процесса приема, а не в реальном масштабе времени. Программа сама по себе не сложная, чего там хитрого, принять посылку и отобразить. Алгоритм - проще некуда. Это не проблема. Мне сейчас интересны базовые вещи. В чем писать. Какую Unix/Linux систему поставить для этой задачи на OrangePi. Мои вопросы в первом посте. С Уважением )))

Что то это всё мне напоминает...Такое ощущение что изобретается очередной велосипед. Очень похоже на съем показаний приборов контроля качества электроэнергии. Там всё уже построено. Правда с частотой обработки сигнала не интересовался. Всегда можно аппроксимировать.

Очень похоже на съем показаний приборов

О каких приборах конкретно речь ? Если все построено, то нужно посмотреть как. Сомнительно, что там Linux. Измерять ток и напряжение, считать и отображать на какой то индикатор можно и без операционной системы. Мне нужна гибкая работа с графиком.

Если протокол стандартный, то любая scada всё что нужно делает: получает данные, показывает графики, хранит архивы.

Что то мне лениво смотреть модели анализаторов. Ты сначала в голове сформулируй для себя ТЗ нормальное.Замечание - линукс как то не шибко тянет на real-time operating system. И цифровой осциллограф не будет смотреться на OrangePi как он не смотрится на программках для Андроид.

Ты сначала в голове сформулируй для себя ТЗ нормальное.

Выше все сформулировано достаточно понятно.

Если протокол стандартный, то любая scada всё что нужно делает: получает данные, показывает графики, хранит архивы.

Тоже прочитал о существовании SCADA под Linux. В принципе как вариант. Надо посмотреть в этом направлении.

в вашем случае данные лучше сразу передавать через ethernet в rrdtool или timeseries db.

а так тема - жесть. Ощущение, что ТС видел осциллограф только на картинке в учебнике физики, а вся «разработка» вдется вокруг некоего поделия на делфи.

Кстати, у OrangePi нет ADC, USB OTG - не смущает?;)

При частоте обновления 25 кадров в секунду делим 10кГц на 25 получаем 0,4 кГц т.е. необходимо за одно обновление строить 400 новых точек

Не совсем так. Зависит от того, за какой промежуток нужно показывать график. Если за 1 сек, то показывать 10к отсчётов не имеет никакого смысла (просто нет мониторов с таким разрешением). Поэтому всё равно нужно усреднять отсчёты, чтобы поместить график в заданное окно. Например при ширине окна в 1000 пикселей и интервале показа 1 сек каждая точка будет «усреднением» от 10 отсчётов и т.о. в каждом новом кадре требуется добавлять не 400, а только 40 новых точек.

Далее вы можете этот график масштабировать и смотреть точку в любой момент времени

Можете, но это будет в десятки раз медленнее, если бы ты заранее прорядил данные под нужный масштаб. И чем мельче масштаб тем хуже будет. Например если в примере выше взять интервал в 10 сек, то твой график будет пытаться отрисовать 100к точек, вместо 1к.

Ну а кроме того при масштабировании графика компонентом отрисовки невозможно контролировать алгоритм «усреднения». Иногда полезно рисовать столбики min/max, иногда среднее, а иногда среднеквадратичное.

с частотой 1 Мгц и тут же выводить, непрерывно строя график

Некоторые предшествующие ораторы безуспешно пытаются донести до вас следующую мысль: Ваша задача состоит из двух совершенно разных частей, которые вы зачем-то пытаетесь совместить в одну. Прием данных с частотой накопления 1мгц, их обработка и складирование - это одна часть. Вывод на UI - это совершенно другая задача. У вас, судя по описанию, нет автоматики, а есть оператор. Поэтому нет никакой необходимости выводить точки на экран не то что в риалтайме, а даже со скоростью развертки (25 гц). Понимаете? Это человек, скорость изменения данных на экране чаще, чем в полсекунды не имеет смысла. Поэтому ваша задача решится гораздо проще, если вы вынесете интегрированную обработку и индикацию за рамки скоростных ограничений.

в вашем случае данные лучше сразу передавать через ethernet в rrdtool или timeseries db.

С точки зрения удобства дальнейшей программной обработки, может и лучше через ethernet, но городить преобразователь CAN -> ethernet не лучшая затея. Да и использовать ethernet там где его функциональное применение ну совсем не обоснованно, это точно жесть.

Ощущение, что ТС видел осциллограф только на картинке в учебнике физики,

Если ТС это я, то не поверишь, осциллографы видел, и поныне пользуюсь, да такие которые вам думаю и не снились.

а вся «разработка» ведется вокруг некоего поделия на делфи.

Ни некоего поделия на Delphi, а работающей программы, позволяющей удобно анализировать записанный с частотой 1000 Гц процесс в графической форме. Не хватает только построения в режиме реального времени.

а так тема - жесть.

не знаю что для вас жесть. Если смущает слово осциллограф, назовите это графопостроитель т.к. действительно к осциллографу это не имеет никакого отношения (тему уже не изменить), аналоговые сигналы не обрабатываются. Принимать байты информации по интерфейсу и отображать на двумерном графике для вас это жесть ?

Кстати, у OrangePi нет ADC, USB OTG - не смущает?;)

А то что я уже пол темы пишу про интерфейс UART, какбэ намекая что USB не очень интересен и третий раз про то, что ADC Я НЕ ИСПОЛЬЗУЮ и все данные прилетают по интерфейсу не смущает ? ;)

то показывать 10к отсчётов не имеет никакого смысла

на данный момент строится график 1000 Гц. Правда из заранее сохраненного массива, а не в режиме реал. Так вот, вы не правы, для меня не имеет значения разрешение монитора, т.к. этот самый монитор не является хранилищем данных и не нужно зацикливаться на пикселях. Данные можно хранить в массиве, в файле и т.д. и отображать их по мере масштабирования, как в прочем сейчас и реализовано. Для меня имеет смысл каждое значение, т.к. необходимо наблюдать быстро протекающие процессы.

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

Хуже не будет. Масштабированием вы просто указываете какую часть данных (например из массива) отобразить на экране. Да возможно есть минимальный программный шаг точек, в том компоненте, в котором будет производится построение. Вот это и будет ограничением. На данный момент, повторюсь, 1000 точек за секунду TChart в делфи отображает не задумываясь. И масштабирует без проблем.

Ну а кроме того при масштабировании графика компонентом отрисовки невозможно контролировать алгоритм «усреднения»

А ни не нужно ничего контролировать компонентом отрисовки. Если что-то нужно, считаем программно, потом перерисовываем.

Некоторые предшествующие ораторы безуспешно пытаются донести до вас следующую мысль: Ваша задача состоит из двух совершенно разных частей, которые вы зачем-то пытаетесь совместить в одну. Прием данных с частотой накопления 1мгц, их обработка и складирование - это одна часть. Вывод на UI - это совершенно другая задача.

Полностью согласен, а по другому и не решается. Но складирование гораздо быстрее приема, поэтому складывать куда-то можно сразу после приема очередного байта, после складирования - отображение. И так по циклу. 1 МГц это я загнул конечно. Это максимальный битрейт CAN. Частота байт информации до нескольких кГц, ну скажем до 10. Это с большим запасом.

Поэтому нет никакой необходимости выводить точки на экран не то что в риалтайме, а даже со скоростью развертки (25 гц). Понимаете?

Какбы объяснить ? )) Отображать нужно ровно столько сколько можно увидеть. Это я согласен. НО ! Потом, когда процесс остановлен, график можно увеличить и посмотреть то, что не было видно. Например, растянуть до 1 миллисекунды. Понимаете ? ) Т.е. человеку сразу наблюдать столько точек и стакой скоростью не нужно, но нужно потом, когда разбор полетов происходит.

Поэтому ваша задача решится гораздо проще, если вы вынесете интегрированную обработку и индикацию за рамки скоростных ограничений.

Я и не спорю, выводить на дисплей можно сначала грубо, а все писать в массив или файл. Так в принципе и пришлось бы делать.

Но я опять же хотел от вас услышать какие мне лучше использовать инструменты для этих вещей. Вот предложили как вариант freepascal + lazarus. SCADA я уже отмел, так как её мощные возможности считаю здесь излишними.

SCADA я уже отмел, так как её мощные возможности считаю здесь излишними.

Ощущение как будто тебе результат не нужен. Создаёшь видимость деятельности? Тогда схема такая: конвертор can, блок с памятью для записи архивов, управляющий блок, интерфейсный блок.

Данные циклически пишутся в память блока памяти. ПК запрашивает через интерфейсный блок усреднённые записи за период: последние или указанный. Интерфейсный передаёт управляющему. Тот архивному. Так же управляющий принимает данные из can и передаёт архивному. Когда архивный насчитал средние он отдаёт управляющему и тот передаёт через интерфейсный в ПК.

Лет пять можно неспешно пилить.

Лет пять можно неспешно пилить.

За эти деньги можно Tektronix dpo7254C купить. И даже не один. А еще лучше 7354. Вот тебе всё что душе пожелаешь и цифровые входы разных интерфейсов, и сетевые выходы, и накопление в память с ох.... какой частотой, и работа с графикой, и полоса 3,5ГГц, не говоря уже об АЦП. И голову ломать не надо.;-))

Создаёшь видимость деятельности?
Лет пять можно неспешно пилить.

Вообще не в тему. Ваша схема не подходит, т.к. необходимо в процессе работы подстраивать некоторые характеристики и наблюдать результат в реале. Иначе бы это все не затевалось. И если ваша цель порезче ответить, то можно и без ваших советов обойтись. Общую структуру приема и отображения я описал, она меняться не будет и вам думать об этом не нужно. Мне важно программное обеспечение и операционка для этой задачи. По технике разберусь. Если есть чего посоветовать, то пожалуйста, а иначе не сотрясайте эфир.

За эти деньги можно ....

Вот именно. Поэтому лучше посоветуйте куда копать в плане операционки и среды разработки под Linux.

выводить на дисплей можно сначала грубо

Нет. Ничего не надо выводить «сначала». Пишите все в файлы. Пусть одна часть железа/софта занимается только этим. Накапливает данные в требуемом количестве и обновляет их. Другая часть должна иметь доступ на чтение к этим файлам и заниматься только выборкой и выводом на экран по задаваемым вами формулам.

какие мне лучше использовать инструменты для этих вещей

Любые, которыми вам удобно пользоваться. Обе этих задачи по отдельности элементарны, скорость считывания с портов/записи в файл 1мгц реализуема почти на любом железе и любом протоколе, вплоть до lpt. и не требуют никаких специальных средств разработки, помимо тех, к которым вы привыкли. Не собираетесь же вы для этого специально для такой задачи осваивать что-то новое?

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

Вообще не в тему. Ваша схема не подходит, т.к. необходимо в процессе работы подстраивать некоторые характеристики и наблюдать результат в реале.

Вы зря ругаетесь, аноним дело говорит и блок-схему обрисовал приемлемую. А у вас нет понятия «реал». Там, где сидит оператор и жмет на кнопки - может быть только ретроспективный анализ собранного массива одномегагерцовых данных

в плане операционки

QNX - но есть большой минус.В основном не свободная. Тогда FreeRTOS... и на худой конец Windows CE.

А если вам нужно не просто сделать, а обосновать многомилионный проект

Чисто моя инициатива, никак не отражающаяся на моей зарплате, в сроки месяца два ... три.

Пишите все в файлы. Пусть одна часть железа/софта занимается только этим. Накапливает данные в требуемом количестве и обновляет их. Другая часть должна иметь доступ на чтение к этим файлам и заниматься только выборкой и выводом на экран по задаваемым вами формулам.

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

Вы зря ругаетесь

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

QNX - но есть большой минус.В основном не свободная. Тогда FreeRTOS...

О QNX слышал, про freeRTOS тоже встречал информацию. Рассмотрю. Спасибо. Windows CE отдыхает )))))

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

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

о создании видимости работы, пяти годах и миллионах ...

так уж вы странно сформулировали задачу, поэтому и предположения такие

регулировать и видеть результат регулирования.

Сейчас ещё окажется что управляется какой-нибудь механический процесс типа реле или даже сервопривода. И миллион плавно перетекает в 1-2 отсчёта в секунду.

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

О QNX слышал, про freeRTOS тоже встречал информацию. Рассмотрю. Спасибо. Windows CE отдыхает )))))

Ваша инициатива и срок три месяца? :) И вы об этом всем только слышали? Не морочьте себе и людям голову, делайте на том, что умеете. Блок-схему вам обрисовали, логику тоже. Это у вас единственно возможный вариант.

об диспетчерской службе энергетиков

нет, к энергетике отношения не имеет и некоторое запаздывание в наблюдении допустимо - десятки и даже, наверно, сотни миллисекунд.

Если scada тебе не годится, может тогда потыкать gnuradio?