Deutsch
Germany.ruФорумы → Архив Досок→ Программирование

Вебморда + простой сетевой интерфейс на слабенькой борде

649  1 2 3 все
  ilghiz знакомое лицо20.05.18 22:26
20.05.18 22:26 

Добрый день,


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


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


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


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


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


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

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

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


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

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

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


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


Спасибо!

#1 
BSDLamer Хвостатый Carpal Tunnel20.05.18 23:49
BSDLamer
NEW 20.05.18 23:49 
в ответ ilghiz 20.05.18 22:26

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

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

0001, 0010, 0011, 0100, 0101, вышел зайчег погулядь
#2 
  ilghiz знакомое лицо21.05.18 09:58
NEW 21.05.18 09:58 
в ответ BSDLamer 20.05.18 23:49

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


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

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

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

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


Спасибо!

#3 
Murr патриот21.05.18 10:12
Murr
NEW 21.05.18 10:12 
в ответ ilghiz 20.05.18 22:26

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

-----

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


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

-----

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

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



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

-----

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

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

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

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

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



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

-----

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

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

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



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

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

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

#4 
AlexNek патриот21.05.18 13:04
AlexNek
NEW 21.05.18 13:04 
в ответ ilghiz 20.05.18 22:26, Последний раз изменено 22.05.18 00:00 (AlexNek)

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

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

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

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...


#5 
samowar прохожий21.05.18 13:15
NEW 21.05.18 13:15 
в ответ ilghiz 20.05.18 22:26

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

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

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

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


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

#6 
BSDLamer Хвостатый Carpal Tunnel21.05.18 21:15
BSDLamer
NEW 21.05.18 21:15 
в ответ samowar 21.05.18 13:15

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

0001, 0010, 0011, 0100, 0101, вышел зайчег погулядь
#7 
Wanderer_ посетитель21.05.18 22:01
NEW 21.05.18 22:01 
в ответ ilghiz 20.05.18 22:26

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


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

#8 
here_and_now коренной житель21.05.18 22:01
here_and_now
NEW 21.05.18 22:01 
в ответ BSDLamer 21.05.18 21:15

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

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

#9 
  ilghiz знакомое лицо29.05.18 19:17
NEW 29.05.18 19:17 
в ответ AlexNek 21.05.18 13:04, Последний раз изменено 31.05.18 14:52 (ilghiz)

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


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


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

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


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


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


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


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


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


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


#10 
Murr патриот29.05.18 19:26
Murr
NEW 29.05.18 19:26 
в ответ ilghiz 29.05.18 19:17

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

-----

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

#11 
Bigfoot коренной житель29.05.18 21:06
Bigfoot
NEW 29.05.18 21:06 
в ответ ilghiz 20.05.18 22:26, Последний раз изменено 29.05.18 21:18 (Bigfoot)

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

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

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


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

Oh gravity, thou art a heartless bitch! (c) Dr.Cooper
#12 
samowar гость29.05.18 21:33
NEW 29.05.18 21:33 
в ответ ilghiz 29.05.18 19:17

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

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

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

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


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


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

#13 
Wanderer_ посетитель29.05.18 22:00
NEW 29.05.18 22:00 
в ответ ilghiz 29.05.18 19:17

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

#14 
Bigfoot коренной житель29.05.18 22:05
Bigfoot
NEW 29.05.18 22:05 
в ответ samowar 29.05.18 21:33

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

Oh gravity, thou art a heartless bitch! (c) Dr.Cooper
#15 
samowar гость29.05.18 22:35
NEW 29.05.18 22:35 
в ответ Bigfoot 29.05.18 22:05, Последний раз изменено 29.05.18 22:36 (samowar)

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


#16 
AlexNek патриот29.05.18 22:42
AlexNek
NEW 29.05.18 22:42 
в ответ ilghiz 29.05.18 19:17

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

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

#17 
Bigfoot коренной житель29.05.18 22:57
Bigfoot
NEW 29.05.18 22:57 
в ответ samowar 29.05.18 22:35
Без сервера не обойтись

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

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

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

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

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

Oh gravity, thou art a heartless bitch! (c) Dr.Cooper
#18 
samowar гость30.05.18 06:56
NEW 30.05.18 06:56 
в ответ Bigfoot 29.05.18 22:57

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

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

#19 
Bigfoot коренной житель30.05.18 09:13
Bigfoot
NEW 30.05.18 09:13 
в ответ samowar 30.05.18 06:56
Меня очень интересует как вы скармливаете данные борде принципиально безо всякого сервера.

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

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

Oh gravity, thou art a heartless bitch! (c) Dr.Cooper
#20 
1 2 3 все