Не смог нагуглить совсем уж то, что нужно. Но нашёл пример, где принципиальные моменты реализованы: тут.
Там делается перетаскивание мышью, поэтому много лишнего кода. Но можно разглядеть, как берутся координаты курсора и отправляются на сервер при помощи 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 на этом по-моему. Надо глянуть, подзабыл уже. Внутренний буфер в наличии.
Собственно грабель пока ( если не требовать супер отдачи ) не вижу. Хотя пока не проверял.

Сообщение отредактировал 1234Alex - Feb 28 2015, 22:37

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


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


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

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

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

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

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


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


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

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

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

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

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

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

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