Добрый день,

посоветуйте, пожалуйста, правильно ли я мыслю.

Есть ембеддед борда (Cyclone V SoC, 2ARM A9, 1GB RAM, 32GB SD, Yocto), на которой крутится мой софт. На внешний мир виден через гигабитный PoE. На данный момент софт управляется через stdin и отвечает через stdout + часто скидывает на SD карту файлы с результатами. На борде крутится мой софт, и если в командной строке что-то запустить, то софт дает сбои (не хватает процессорной мощности). То есть по умолчанию юзеру отдать доступ к руту или даже к юзеру можно только с сильными оговорками, что все может падать. Если только общаться по stdin/stdout - все работает надежно, так как внутри моего софта есть расстановка приоритетов по запросам.

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

Понятно надо и доку написать, чтоб юзерам понравилось. И надобно все еще в прошлом году.

Гуглил, но, так как не сильно в курсе, хочу посоветоваться, то ли нагуглил.

Вижу две возможности:

1. соединить мой процесс через сокет, написать текстовый интерфейс пользователя. Поднять минималистический веб сервер на С и дать юзеру возможность или дергать напрямую через сокеты мою программу или через самопально написанный С код, который отрабатывает все htmlные запросы. В этом случае мой сервер может при необходимости помолчать чуток, если процессор ужасно загружен расчетами.

2. поставить POCO, сделать интерфейс у своей программы в виде JSON, почитать и научиться как писать webapi и нарисовать на жаве клиента, который бы коммуницировался с моей бордой.

Вижу проблемы:

1. не портабельно, так как в будущем гуй будет разрастаться,

2. могу сам не осилить сделать хорошо, так как на жаве почти не писал и могу не почувствовать что будет правильно, а что нет. Отдать это на сторону пока финансово не осилю, хотя конечно же хотел бы.

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

Спасибо!

Я особо не в курсе но думаю coap или/и restful тебе нужен. Морды на жабе сегодня еще пишут ?

Дофига всяких готовых JS фреймворков для гуев сегодня существует.

Спасибо за ответ! На жабе или не на жабе - не знаю, сам морды последний раз писал только на Tcl/Tk и рендерил графики в OpenGL, но это было почти 20 лет назад. ИМХО, не факт, что это будет хорошо совместимо с современными платформами.

Мне надобно понять

1. правильно ли выносить морду на клиента,

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

3. если морду не выносить, то адекватный ли путь, что у меня в первом сообщении.

Спасибо!

но в кернелах бывает, что даже сам что-то дописываю

-----

К вебу это никаким боком. Ну кроме общего понимания программирования.

Поднять минималистический веб сервер на С

-----

Угу... правда какой из них минимальный и на чем написан Я не в курсе.

Если ты планируешь использовать Жабу на борде, то там есть веб-сервер,

дергать напрямую через сокеты мою программу

-----

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

работай из веб-сервера.

В любом случае веб-сервер, который будет не только отдавать, но и строить

ХТМЛный документ минимальным не будет. Самое простое под никсами -

какой-нибудь ПХП...

могу сам не осилить сделать хорошо

-----

Скорее всего так и будет - дизайнить не каждому дано.

Делай только техническую имплементацию, без марафета - работающую

уже можешь отдать дизайнеру - поправит он ХТМЛу...

По общему - перед тем как выберешь как это делать - ознакомься более

подробно с вебом - там достаточно своих нюансов и можешь изобретать

велосипед довольно долго...

Недостаток ресурсов - это конечно фигово. Придется постоянно извращаться.

Вопрос еще и в том сколько своих "ресурсов" можно/готовы потратить.

Начать вероятно можно с чего-то подобного:

https://github.com/cesanta/mongoose

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

вот еще нарыл

http://www.lighttpd.net/

http://www.acme.com/software/thttpd/

https://busybox.net/about.html

https://asciich.ch/wordpress/busybox-als-dynamscher-webser...

пишете скрипты/бинарники,дергаете через cgi и выдаете html.

потребуется только минимальный вэб-сервер который умеет cgi.

ну и ставите nice где вам удобно.

делал что то подобное на питоне - летало на ура, на 600 мгц одноядерном, у которого основная загрузка под 60% была.

кстати, можно тупо все через nice разрулить - дать вашему софту первоочередной приоритет, пользователю последний.

cbi-bin - назад в 90ые ?

Что у Вас как ОС на борде крутиться? Embedded Linux?

Если у Вас с ресурсами проблемы и веб-сервер может не взлететь, то может стоит подумать расширить свою программу простым TCP-сервером. Написать GUI-программку, на чём Вам вздумается, с реализацией TCP клиента и гонять даныые через TCP соединение.

в девяностых был перманентный недостаток ресурсов.

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

Огромное спасибо за советы!

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

Итак, на борде Yocto c 3-тим кернелом (пока не все под 4-тый компилится). Память 1ГБайт, скорость доступа примерно 1.3ГБ/с, два Cortex A9 600МГц (могу припаять 800МГц, но жаба душит и сильно разницы не будет, так как память будет на той же скорости).

Одно процессорное ядро забито (на сколько смог захачить линуксовый кернел) в реальном времени на моей софтине и имеет у себя в дедикейтед пол гига памятr.

На другом ядре можно делать почти что хочешь, но только с несколькими оговорками. Иногда (10-20%) оно нужно внутренним ресурсам.

Веб морда, что мне нужна - это морда для ЯМР спектрометра. Понятно надо строить графики, картинки, которые на этой же борде и вычисляются.

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

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

Собственно поэтому и ищу какое-то решение, чтоб однажды с портом связаться, и потом только самому (или через какую-то удобную библиотеку) общаться.

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

одновременно запустить два запроса

-----

Семафор не в сессию, а в аппликатион?

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

Для варианта 2 есть неожиданное предложение - сделать хотя бы на первое время десктопную морду на Origin-е с использованием все евойной немерянной мощи для визуализации, сейчас User Interface Module включен даже в обычную (не-Про версию), данные переправлять через какой-нибудь mySQL, что тоже весьма несложно программируется в OriginC. Займет какое-то время, но остов за неделю можно сделать железно при желании и упорстве, визуализацию можно клепать на LabTalk-е, это будут ооооочень компактненькие скриптики из нескольких строк (по опыту), все выводить на кнопки UIM, программизма минимум. Такие решения для _коммерческих_ люминесцентных спектрометров я уже встречал. Сам бы тоже мог сляпать, не бог весть какая сложность - собственно, я что-то похожее на работе и сляпал для визуализации данных технологического процесса, ибо плохо перевариваю Ексель (а у нас стандартная визуализация на нем).

Я даже встречал тройные системы - борда/встроенный линукс-сервер/внешний вендовый десктоп в одном флаконе на MALDI-TOF.

ЗЫ. Чуть не забыл. В последних версиях Origin розумеет ЕЩЕ И Python (в дополнение к LabTalk и OriginC). Тоже может оказаться полезным.

Могу предложить python + pyro.

На вашей борде запускается легковесный сервер pyro. По сути это прокси (не хттп-прокси), который предоставляет сетевой доступ к определенным классам/методам.

На клиенте пишется вполне обычная программа на питоне, которая прозрачно через этот прокси имеет доступ к ресурсам борды (как будто это были бы локальные классы/методы).

Дергаете что вам надо как вам надо.

Можно тупо через ssh команды дергать / читать вывод (python/paramiko).

Но от проблем с кэшем все это не спасет. Как насчет оптимизации вашего софта (neon)?

Ещё как вариант, может не заморачиваться Zynq-ом или Cyclone-ом и взять отдельно чип FPGA и чип ARM-процессора помошнее? Вы как c PL коммуницируете?

Зачем козе баян не борде _сервер_? Любая функция на борде, кроме низкоуровневой обработки данных с контроллеров, пересылкой оных серверу и управления железом - это _гарантированное_ зло, ИМХО. Рано или поздно. Есть клиентский десктоп с избытком вычмощности - на него нужно пендюрить и сервер БД, и визуализацию. Вопрос лишь во временных издержках на освоение инструмента для создания интерфейса и на создание оного - по совокупности. ИМХО, никакие "обычные" языки с их разнообразными фреймворками и библиотеками по этому параметру не сравнятся с готовой средой для визуализации/обработки данных с поддержкой развитых скриптовых языков.

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

А отчего требуется всё "залить" на один борд? Может ему лучше сделать "удобный " для вычислений интерфейс обмена данными, чтобы и пользователь мог лепить что ему надо сам.

А веб морду уже как дополнение продавать на другой плате. Может их даже и в одну коробку засунуть.

Без сервера не обойтись

Мы же как-то обходимся. Точнее, сервер - на десктопе. Вместе с управляющим софтом. Борда нужна для автономности работы установки - данные (минимальные, порядка 2-5 кбайт) передаются борде перед стартом, если зависнет десктоп с интерфейсом управления, то на технологический процесс это не повлияет. Скармливать данные борде можно и после старта при необходимости изменить параметры процесса. Повторю - на борде нет НИКАКИХ серверов в принципе.

Надеюсь, мы говорим о сервере в разрезе клиент-сервер, а не сервер бд.

Я говорил о БД. Но клиент-сервер с сервером на борде - это, ИМХО, еще хуже. Потребует больше вычресурсов для обработки данных. Ить, не тупой же съем с датчика. Всякие фурье-шмурье, как я понимаю, потребуются.

Поэтому я голосую за прокси- который лишь предоставляет прозрачный сетевой доступ к определенным ресурсам.

Каким именно ресурсам-то? Данные как будут храниться? И какие данные? Одно дело - готовый спектр низкого разрешения, другое - raw data. Чем это лучше, чем скидывание данных на сервер БД на десктопе с их последующей обработкой и визуализацией там же? Ведь железобетонное же решение, в конечном итоге все равно только оно и будет реализовано. Поэтому сейчас дешевле купить дорогой, но быстрый в освоении инструмент, обеспечивающий быструю разработку, чтобы склепать интерфейс на первое время. А потом можно постепенно наворачивать все, что угодно. Дохлую борду надо оставить в покое.

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

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

Меня очень интересует как вы скармливаете данные борде принципиально безо всякого сервера.

Так же, как и любому ПЛК (он же PLC). Все серверы находятся на внешних компах. Весьма надежная система.

Я просто представляю, что нужно юзеру такого спектрометра - он захочет скроллить спектры, автоматически распознавать и обсчитывать пики нелинейной аппроксимацией, интегрировать/дифференцировать, масштабировать, экспортировать/импортировать, не исключено - производить некое распознавание по готовым библиотекам спектров. Реализовывать это на борде, постоянно натыкаясь на всевозможные ограничения и "подводные камни" из-за конкуренции за выч.ресурсы, ИМХО, совершенно неоправданно. Борда нужна только для передачи данных. Все остальное должен делать масштабируемый софт с легко расширяемым функционалом на десктопе с избыточной выч.мощностью. Я лично могу вполне сляпать такую "морду" с помощью вышеуказанного софта (OriginLab Origin) за короткий срок. Стоимость единичной лицензии Origin - порядка 1.5 к€, его же в Pro-версии - 2.5k€. Ну, плюс, работа. А главное - в него можно практически моментально запердолить ЛЮБУЮ обработку данных, включая сложную статистику и DSP.

Во-первых всем огромное спасибо за советы!!!

Пока прокомментирую пока, почему не отдельно FPGA + Arm, а взят Cyclone SoC.

Я сильно жмочу габариты (внутренняя допустимая ширина платы 22мм), и в эти габариты надо вписать достаточно мощный процессор и обязательно плиску, если забить на эти габариты, то отвалится один предзаказ на 1000+ экземпляров, что не хотелось бы допустить.

Причем на плиске мне надобно хотя бы под сотню 18битных умножителей на 200МГц+ такте, а на процессоре хотя бы с пол гигафлопса вычислительной мощности и весь пакет лапаков, бласов и фурьей (остальное свое, в крайнем случае могу и свое фурье взять) и очень важна маленькая латентность по коммуникации плиска-процессор, то есть надо за 100микросекунд получить с плиски данные, обработать, и послать назад. Ниосы внутри плиски не осилят, проверено. Пока я не видел покупных борд, кто бы вписал хоть в такие габариты DDR2 + ARM + FPGA.

Реально на данный момент не знаю другого решения. Сам разводку (последнюю, которая заработала) делал 2 месяца, базируясь уже на своих же наработках, которые были примерно в 15 разных предыдущих прототипах.

Склоняюсь, чтобы не пускать юзера вовнутрь оставив это только на свой софт, и только выбрать внешний безгеморный способ обработки гуя, понимая, что минималистичекую версию сего гую придется написать самому, но я их практически не писал (кроме tcltk в прошлом веке).

минималистичекую версию сего гую придется написать самому

Это проблема только на конкретный момент времени. По сравнению с той системой которую Вы уже создали - это просто детский сад.

Просто одному человеку не охватить всего. Но думаю, в этом вопросе мы сможем вам помочь.

> Я просто представляю, что нужно юзеру такого спектрометра - он захочет скроллить спектры, автоматически распознавать и обсчитывать пики нелинейной аппроксимацией

с одной стороны - Вы правы, но есть еще важный ньюанс.

Ключевая идея (или одна из них) - это тензорная аппроксимация спектров (построение спектров веществ в отсутствии базы данных и референсных спектров), причем выносить это дело на внешний мир - гарантия повесится с поддержкой всех возможных архитектур. Поэтому процессор для численных расчетов в общем-то внутри не совсем жмотский, если учитывать, что часть вычислений выносится внутрь плиски через OpenCL и там на раз считаются. В 2006 для этих задач я пользовал суперкомпьютеры, сейчас я умудрился это засунуть в балалайку с 20 ваттным потреблением.

А представьте как бы меня материли бы юзеры, если после покупки моей аппаратуры я буду простить их иметь у себя десктопе ворох графических карт и очень специализированного софта, или суперкомпьютер под рукой?

Я не зря внутрь 32 или 64ГБ флеша ставлю, чтоб исходные спектры до обработки сидели внутри, и юзер мог дообработать все именно так, как надо, но только на моем железе и с хорошо вылизанной под это численной оптимизацией.

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

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

с поддержкой всех возможных архитектур

Не надо всех. Все производители спектрометров - по крайней мере, мне лично исключения неизвестны, хотя могу допустить - продают прибор с компом, который гарантированно поддерживает требуемое железо (в виде спец-граф.карт или спец-контроллеров). Я могу понять, когда на борду заведены вылизанные алгоритмы матричных вычислений, если мощи хватает. Но от других операций борду, ИМХО, надо максимально освобождать. Если предполагается передача только обработанного спектра, то, видимо, можно обойтись и без SQL-сервера, но с ним мне было бы как-то проще. Если же идея состоит в продаже прибора за минимальные бабки без внешнего компа (предполагается, что комп подходящей мощности у клиента найдется), то это дополнительное условие меняет подход радикально. Тем не менее, вариант с Origin однозначно будет наименее затратным по времени и усилиям в обоих случаях.

разпознавалка спектров по базе данных тоже внутри сидит

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

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

да, когда спектрометр стоит от 200К, то такое барство можно позволить, а если спектрометр 1К стоит?

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

> Про распознавалку, что внутрь спектрометра засовывается.

> И это, имхо, глубоко неправильно.

эххх, не словили Вы ключевую фишку моей разработки.

Полный многомерный спектр (NOESY + HSQC + HMBC) для 200Да молекул на моих магнитах надо снимать пару месяцев. Но если есть база, и сам кусок спектра снимается за секунду, то можно одновременно залудить разсопзанавлку, и принять решение что снимать дальне. Дальше делаем мой неравномерный семплинг, и вуаля, спектр заматчился по базе данных за несколько минут.

Поймите, юзеры, которые покупают за 1-2К спектрометр, еще отличить NMR(ядерный магнитный резонанс) от NIR (ближний ИК спектр) не могут. Если им дать по башке многомерным NOESY + HSQC + HMBC они меня сразу пошлют куда подальше, а если они в удобном виде получат список веществ, а продвинутые юзеры смогут залезть и посмотреть детали самого спектра, то все на это и западут сразу.

Но вот комп для обработки будет как часы с двумя чемоданами батареек - все юзеры будут материться.

Как я ее мог словить, если я впервые слышу о non-uniform (?) sampling в Вашей разработке? Я не телепат. Если речь об 1-2К за прибор, то тогда ситуация понятна. Тем не менее, комп для визуализации будет все одно нужен. В общем, если бы сразу были озвучены ВСЕ принципиальные ограничения (цена, некомплектация компом, распознавание в ходе обработки raw data,...), то я бы ничего не советовал. Не знаю приемлемых средств разработки для такой комбинации. С учетом того, что юзеру все одно понадобится комп для взаимодействия с прибором, можно поставить условие, что комп должен работать либо под виндой, либо под OS X - тогда можно продавать с "мордой" на Origin-е, ибо предусмотрена OEM-версия. Правда, цены на нее не знаю.

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

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

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

> Как я ее мог словить, если я впервые слышу о non-uniform (?) sampling в Вашей разработке?

другие как-то сразу словили фишку http://bnw.im/p/02KGJF а вы мне даже на anchem.ru форуме много букв написали, странно как-то что тогда не поняли, я там это детально разжевывал

> Тем не менее, комп для визуализации будет все одно нужен

правильно, только те, кто будут пользовать версию за 1-2К - будут в первую очередь ожидать простого и понятного интерфейса, и такой человек не только про триплеты и мультиплеты, он вообще про ЯМР скорей всего до этого только краем уха слышал. И те, кто будут трактовать сами спектры - могут купить продвинутую настольную версию или таки скачать с моего агрегата FID и сами потрахаться в их любимом софте как им хочется, а те, кому надобно ехать - будут хотеть практически текстовую информацию - сколько чего найдено, с какой вероятностью закореллировано, ну может пару каких-то простеньких графиков для наглядности.

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

те, кто будут пользовать версию за 1-2К - будут в первую очередь ожидать простого и понятного интерфейса

Этого будут ожидать ВСЕ.

и такой человек не только про триплеты и мультиплеты, он вообще про ЯМР скорей всего до этого только краем уха слышал

Сомневаюсь. Наоборот, это будут брать наиболее продвинутые - те, кто хорошо понимает, в чем там фишка. По крайней мере, я знаю оооочень неплохих органиков-синтетиков, глубоко знающих ЯМР, работавших на всяких крутых многомегагерцовых "брукерах" которые с удовольствием взяли бы себе в лабу такой прибор.

и виндовые программы - рука не поднимается в своем продукте пользовать

Тогда страдайте. Мазохизм недешев и времязатратен.

> Наоборот, это будут брать наиболее продвинутые

пока у меня полностью противоположный опыт общения с потенциальными заказчиками

> Тогда страдайте. Мазохизм недешев и времязатратен.

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

Ладно, от темы отвлеклись сильно.

Вопрос к знающим, скажите, пожалуйста, что будет быстрее:

1. прочитать и разобраться в жаваскрипте и css и на нем нарисовать простого клиента, который в стандарте JSONа общается,

2. нарисовать напрямую свой парсер дюжины http запросов?

Достоинства: 2 - точно сам осилю и косяков и тормозов точно не будет.

Если первое, дайте, пожалуйста, простую и понятную книгу для чайников.

Хотите, я повангую, чем все закончися? Тем, что глючноватым, неудобным и плохо расширяемым минималистическим интерфейсом Вы отпугнете клиентуру. «Чайники», кстати, часто более требовательны к качеству интерфейса, чем «продвинутые». В общем, я плохо понимаю, на какую нишу рынка Вы ориентируетесь, и помочь я Вам боле ничем не могу. Засим откланиваюсь.

ЗЫ. ОРИДЖИН.

> ЗЫ. ОРИДЖИН

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

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

Поэтому для своего случая я рассматриваю только варианты, которые будут поддерживаться на ВСЕХ распространенных системах. Я достаточно наогребал от поставщиков научного оборудования гемора по несовместимости. Мой аппарат должен быть совместимым со всем железом. Это желание моих клиентов, а значит, и мое обязательство. Точка.

JSON - это ХМЛ/CSV овер НТТП.

Выигрышь будет в обьеме перегоняемых данных и потенциальной асинхронности.

А в обьеме реализации - ой... особенно, если что-то самопальное.

Парсер протокола самому писать не рекомендую - есть их уже на все случаи.

Просто посмотри что из реализаций способно у тебя работать и сколько ресурсов надо.

Сильно меньше, чем есть написанное, можно сделать только обрезав функциональнось,

от чего ты сам потом будешь плеваться.

Тебе, кстати, давали очень правильный совет - не засовывай все на борду.

На борде тебе нужно самое необходимое:

- сообщить борде что именно от нее ожидается

- снять голые данные - это 100% нужно тем кто будет копать сам

- снять какие-то промежуточные данные

- снять обработанные данные, посчитав что ты там хочешь/можешь посчитать

- загрузить и обсчитать внешние данные - если выч.мощности хватает

Вроде все.

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

Уходя-уходи, конечно, но уж очень насмешило:

Ориджин не пользуют в большинстве систем и он имеет очень нишевую аудиторию

Ну, тогда весь R&D - это очень нишевая аудитория. Да и ощутимая часть индустрии, пожалуй, тоже... Бугога.

> Уходя-уходи, конечно, но уж очень насмешило:

а что, мы на ты уже? Уходите, вы же пообещали. Кроме непутевого флейма вы в мои топики, к сожалению, ничего не привносите.

А вот это уже наглое вранье и свинская неблагодарность. Идите лесом. Авось, бог подаст.

> А вот это уже наглое вранье и свинская неблагодарность. Идите лесом. Авось, бог подаст.

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

1. прочитать и разобраться в жаваскрипте и css и на нем нарисовать простого клиента, который в стандарте JSONа общается,
2. нарисовать напрямую свой парсер дюжины http запросов?

Если у Вас нет необходимости использовать сложные формуляры и нужно поддерживать соединение только с одним пользователем, я бы выбрал второе.

И ещё один момент. Я как понимаю Вы используете Embrdded Linux на ARM-е. Может стоит посмотреть в сторону RTOS, где RTOS не так тежеловестна и вы можете управлять так же ресурсами и процессами.

Благо Cyclone в отличии от Zynq предлагает больший список поддерживаемых OS and RTOS.

P.S. Ребята не ругайтесь, ведь на "пустом месте" спорите.

Спасибо, Wanderer_ за добрые слова и советы!

> Если у Вас нет необходимости использовать сложные формуляры и нужно поддерживать соединение только с одним пользователем, я бы выбрал второе.

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

RTOS очень хотелось бы использовать, но есть одна заморочка. мне надо редко, но надобно, перекомпиллировать гнутым компиллером часть софтвера, который внутри эмбеддед платформы работает. Да и софт сам по себе очень развесистый, что есть .so которые подгружаются по мере необходимости. То есть внутренний объем без динамических библиотек будет ужасающим, а без встроенного компиллера - не реализуемым. Обычный юзер не будет использовать ту часть когда, что дергает компиллер, но продвинутый - точно будет. Понятно это можно через свой хостинг можно организовать, но вроде бы не правильно.

Поправьте, пожалуйста, про RTOS + .so и gcc если я не прав и что-то прохлопал.

Еще вопрос на тему, не пинайте сильно...

Есть свой веками отточенный на пользователях ЯМР аппаратов 2D и 3D-контурплот, который выдает в OpenGL или EPS. Картинки получаются для них информативные, генерация шустро работает. Скажите, пожалуйста, в каком формате их можно/правильно передать по вебу или какой формат взять правильнее вместо EPS, но чтоб сильно не вешаться по конвертации? То есть какой векторный формат по вебу хорошо ходит? То есть у меня не гугл-мапс конечно, но 3D-контур плот. Пример постскрипта в аттаче.

Прикреплённые файлы

RTOSочень хотелось бы использовать, но есть одна заморочка. мне надо редко, но надобно, перекомпиллировать гнутым компиллером часть софтвера, который внутри эмбеддед платформы работает.

Да, тут RTOS скорей всего может не подойти.

Скажите, пожалуйста, в каком формате их можно/правильно передать по вебу или какой формат взять правильнее вместо EPS, но чтоб сильно не вешаться по конвертации? То есть какой векторный формат по вебу хорошо ходит?

Я тут не специалист, но на сколько я знаю, по Вебу в основном передают пиксельную графику в формате jpeg или png.

> Я тут не специалист, но на сколько я знаю, по Вебу в основном передают пиксельную графику в формате jpeg или png.

ага, верно, спасибо! Как раз уже именно так и сделал, то есть пишу пикселы, и libpng конвертирую в png, которую и отображаю. Хотел вначале рисовать через canvas в жаве, но получалось не красиво и достаточно громоздко.

но если требуется вектор, то по идее - SVG

https://www.w3.org/2010/09/svg_browser.php

Не по теме вопрос, просто интересно как вы работу PL(programmable logic) и PS (processing system) между собой организовали. Как организовали управление AXI шиной? На PL тоже считаете, благо там DSP Slice есть, или только сигналы с датчиков обрабатываете?

Успехов

> Не по теме вопрос, просто интересно как вы работу PL(programmable logic) и PS (processing system) между собой организовали. На PL тоже считаете?

у меня там два куска кода в плиске. Первый - получает данные с АЦПшки (16 LVDS на 160МГц на оба фронта) и делает некоторые махинации с этими данными, которые на обычном процессоре бы стоили бы порядка десятков гигафлопсов, на выход выбрасывая немного сотни КБайт/с нужных данных на процессор и с процессора получая насчитанные коэффициенты для дальнейшей предобработки.

На это забито 2/3 всех умножителей и большая часть блочной памяти.

Одновременно с этим мне надобно выполнять довольно простые, но вычислительно очень затратные операции, похожие на умножение матриц и Фурье (то есть данных много меньше, чем вычислений). Тут все просто - процессор сыпет данные на плиску и последняя делает эти операции, отсылая назад результат. Для простоты исполнения оба блока засинхронизованы. То есть грубо говоря, если процессору вторая часть не нужна, то все равно на нее нули сыпятся.

То есть на PL примерно 3х10^9 пар синусов и косинусов в секунду (120 умножителей) и где-то около 2x10^10 операций (оставшиеся 50 умножителей) с фиксированной точкой (18 битные умножения и под 50 битные сложения) в секунду выполняется, на PS около 200-500МФлопсов на двойной точности и трафика между ними около 50МБайт.

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

Греется конечно оно все, но всяко обычный процессор на этой задаче не смог бы уложится в 10 ватт, которые потребляет у меня ADC+PL+PS+LPDDR2 и с десяток их DC-DC, ибо эквивалентная задача под сотню гигафлопсов требует, а в 2000-2003 схожую задачу я гонял на хороших в то время суперкомпьютерах :)

Спасибо, очень интересно.

Я смотрю сейчас в сторону Zynq-a. Купил Zybo board, буду осваивать.