Прошу совета.
Есть устройство с 7-дюймовым Tft, собранное на Stm32F4.
Поднят lwIp ( lan8720 ).
Всё потихоньку оживает.
Встаёт вопрос о web-морде для этого агрегата.
Идеальным было-бы повторить в web-интерфейсе наличные 3 ( сейчас ) экрана.
Реально-ли это ?
Про emwin vnc знаю ( пока не пробовал ).
Нет-ли других вариантов.
В веб-программировании пока слаб.
Спасибо.

имхо - надо двигаться в сторону одинаковости кода. т.е. проще сделать аля эмулятор вэб броузера(для тфт) с поддержкй минимального набора
html-ля и гнать его родненького туда и сюда. плюс ява скрипт как нить по минмуму замутить.

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

в вашем же случае - язык и правила описания команд - определен HTML и около вэбовские дела.

Если там не картины Пикассо, то более чем реально. Да и картины Пикассо через битмапы легко делаются.


Ну и что? Главное, чтобы просто в программировании был не слаб. Потому что это веб-программирование - фигня, и учится легко и непринуждённо, благо материала в инете навалом.

2 kolobok0.
Пришлось пару раз перечитать пока понял. Спасибо. В таком ракурсе не думал. Надо будет осмыслить.

2 scifi.
Картинки можно использовать и в web-сервере. Я пока не знаю как отдать событие указателя ( мыши ) из веб-страницы.
С чего начали-бы изучение ?

С гугла.

веб-броузер, даже простейший, будет заметно сложнее чем простейший веб-сервер.


Можно для начала взять учебник по HTML и поставить денвер в качестве песочницы.
Писать для начала можно и в блокноте.
Забудьте пока про джаваскрипт, PHP, MySQL и прочее, на STM всего этого у Вас не будет.
Только голый html, только CGI на стороне сервера, только хардкор!

Ну уж нет. Жабаскрипт - наше всё! К тому же он сидит в браузере, так что не надо пугать, что в СТМ его не будет.

Топикстартер хочет веб-страниц на 7-дюймовом экране.
Увы, наше всё у него появится только если он сам его напишет.

А откуда же ещё оно возьмётся? Волшебник в голубом вертолёте привезёт?

Вы предлагаете ради нескольких кнопок на экране реализовать интерпретатор джава-скрипта?
Для начала всё равно придётся сделать обработку html-ных FORM, INPUT и пр.
В этот момент выяснится, что возможностей FORM вполне достаточно для организации простого интерфейса без украшений.

Есть и альтернативный путь - в имеющийся уже (как я понял) интерфейс о трёх экранах встроить перекодировку в HTML для отдачи его наружу. А прилетающие от удалённого браузера запросы GET превращать внутри в эмуляцию ввода с кнопок или сенсорного экрана.

Прошу прощения ( видимо за провокацию ).
Это ( простенький web-сервер с CGI ) у меня есть.
Что меня пока смущает - разработка по сути 2-х вариантов интерфейса, на emWin и на HTML.
Ищу методы унификации этого дела.
Варианты которые вижу -
1. Vnc сервер. Не понимаю пока как встроить в web-сервер.
2. Вычитывать текущий экран из контроллера дисплея и отдавать в html-страницу картинкой.
3. Генерить html-страницы с использованием имеющихся картинок.
Собственно 3 вариант самый удобный. Вопрос в обработке событий мыши на стороне клиента и отдача серверу.
Аналог - если кто знает СПК от Овена, с их визуализациями.

Почему?


Зачем? Пустое это.

Довольно нудно отрисовывать одну и ту-же мнемосхему дважды.
А когда их несколько ? Хочется автоматической сихронизации интерфейсов.
Если это конечно возможно.

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


Это очень просто. Небольшой кусочек жабаскрипта (~20 строчек) на стороне клиента способен отлавливать события мыши и передавать серверу. Также он способен динамически обновлять картинку (ещё ~20 строчек).

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

Не смог нагуглить совсем уж то, что нужно. Но нашёл пример, где принципиальные моменты реализованы: тут.
Там делается перетаскивание мышью, поэтому много лишнего кода. Но можно разглядеть, как берутся координаты курсора и отправляются на сервер при помощи XMLHttpRequest. Там используется POST, но вам, наверное, будет удобнее GET (тоже с координатами клика), тогда в ответ на этот GET можно будет сразу получить указание от сервера, изменилась ли картинка на экране. Подменить картинку на веб-странице жабаскрипт тоже легко позволяет. Например, см. тут.
Вообще, жабаскрипт позволяет сделать практически всё, что угодно. Ну и со стороны сервера должна быть должная поддержка, естественно.

Судя по тому что uC/GUI вы упорно называете emWin оно у вас в виде скомпилированных либ.
Тогда что-то сделать трудно будет.
А так я экраны для uС/GUI проектирую в виде конфигурационных JSON файлов.
Понятно что и WEB броузер может принять тот же JSON файл и отрисовать такой же экран.
Более того в броузере можно отредактировать экран и сохранить его в дивайс с последующим воспроизведением на экране дивайса. Но это я не реализовывал.

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

А было всё так просто.
А теперь JavaScript и JSON.
В 40+ лет.
Насколько я понимаю emWin и uC/GUI суть одно и то-же. uC/GUI попадается ( старые версии ) в сорцах.
Дальше мало что понял. Значит есть куда развиваться.
Я использую emWin ( St или Keil, не суть ). Интерфейс генерю в их GUI_Builder ( привет Delphi ).
Пока не осознал как сюда прицепить JSON. Равно как XML или protobuf google.

JSON не нужен. Голый жабаскрипт годится. У вас там кода выйдет на пару сотен строк, зачем какой-то JSON?

Может подскажете что лучше почитать по javascript.
Потому как web нужен. Но на всё ( python. java, php ) не хватит.
А делаю пока всё сам.

Ага, не нужен.
Испокон веков мультиплатформенность GUI создавалась с помощью языков разметки.

Можете конечно парсить HTML или XML.
Но придете все равно к JSON как языку разметки. Ибо проще не бывает.

А JavaScript в качестве разметки даже не смешно, а просто не понятно. Каким боком?

Не. Насколько я сейчас понимаю ( стадия 0.1 ), javascript встраивается в мою страницу, отдаётся клиенту и оттуда шлёт обработку событий указателя ( мыши или тача ).
Делал проект автоматизации котла на Овен СПК207. Там удобно. Локальная и веб визуализации совпадают. Думаю как сделать так-же. Там правда ресурсов поболе.

Дурацкий вопрос- где находится образ экрана в обсуждаемой системе? Потому что для 7 дюймового дисплея он во внутреннюю память STM32F4 не поместится. Если есть внешняя память то проблемы сделать копию экрана нет. А вот если копию прийдется вычитывать из памяти контроллера экрана- тут начинаются очень интересные грабли с шиной. Хотелось бы услышать от топикстартера боле подробное описание видеосистемы (тип контроллера, тип шины). Иначе советы по организации удаленного экрана немного безпредметны.

SSD1963 на этом по-моему. Надо глянуть, подзабыл уже. Внутренний буфер в наличии.
Собственно грабель пока ( если не требовать супер отдачи ) не вижу. Хотя пока не проверял.

Что за грабли? У меня были TFT экраны. Для мануалов делал скриншоты именно через веб. Особых проблем не заметил.


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


Нет, не подскажу.
Синтаксис очень похож на Си, поэтому начать просто. Возникает вопрос - лезешь в гугл и сразу находишь ответ. Как-то так.

Это не серьезный подход.
Глядя на крохотный скриншот TFT на экране нормального броузера публика будет в недоумении.
Да и напряг для STM32 будет выше предельного.
Сколько раз в сек собираетесь рефрешить скриншот при скролинге, например? Начнутся лаги, сбои и непопадания в нужную зону видгетов.

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

Я отказался в свое время от GUI_Builder. Он генерит С-и файлы, а их очень трудно парсить как файл разметки для броузера. Это тупиковый путь.
Стоит потратится, но сделать для uC/GUI парсер нормального файла разметки сделанного из представления в броузере. Кстати тогда и к определенному GUI не будет сильной привязки.

Дык я о том же. Но ТС оч. хочется именно так.


Нет. Хотя зависит от масштаба амбиций, наверное.


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

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

Драйвера шины LCD контроллеров очень слабые, pixel readback может не работать в условиях, когда прямая запись в контроллер работает нормально (емкости и длина шлейфа критичны). Если есть полна копия экрана в памяти- то pixel readback вообще не нужен. Отдельная проблема с аппартым курсором, его как то надо симулировать на веб-копии. С экранами с высокой динамикой, типа осциллографов вообще философию отображения на удаленном дисплее приходится менять. Хотя если картинка квазистатическая- этих проблем конечно нет.

2 khach - да, пока задач с высокой динамикой нет. Квазистатика ( автоматизация ). Всё это на плате. Вычитывает вроде без проблем ( тесты пока не гонял ).

2 aaarrr. Именно так я и планировал сделать.

2 scifi. Виджеты используются и будут использоваться.

2 AlexandrY. Очень интересно. Нет-ли примера такого подхода. Так я никогда не делал.

Вот Вам теоретический фундамент для предложенного AlexandrY решения.
https://ru.wikipedia.org/wiki/Model-View-Controller

Если коротко, то всё, что нагенерил GUI_Builder нужно разделить на три кучки, модель оставить как есть, представлений сделать два - для экрана и для браузера.
Контроллер придётся дополнительно поделить на два слоя, "бизнес-логика" не меняется, а вот получение сигналов от элементов управления делается в двух вариантах - (1) от кнопок или сенсорного экрана локально и (2) запросы от удалённого браузера.

PS. Я с этим GUI_Builder-ом дела почти не имел, поэтому сложность задачи деления на M, V и C не очень себе представляю. Возможно что некоторое "допиливание" в сторону бОльшей идейной похожести на html может упростить задачу.
PPS. Я сейчас тоже готовлюсь к неизбежному - сделать настройку, тестирование и управление девайсом через веб-интерфейс.
К счастью локального экрана нет. Пока упражняюсь в денвере.
Так вот, я обнаружил что необходимый минимум элементов управления уже 20 лет как есть в самом html и для создания простейшего интерфейса из нескольких полей ввода и пары кнопок ничего лишнего не требуется.

Да не запаривайтесь, это типичная ахинея PHP-шников используемая в их внутренней борьбе.

В данном случае вам следует знать, что uС/GUI это однозадачная, однопользовательская, статически линкуемая система.
Поэтому MVC здесь совершенно мимо.
Для представления в броузере uC/GUI не должно использоваться ни под каким видом.

Не клевещите на PHP-шников, они до таких высот абстракции обычно не долетают.

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