Комментарии 22
Есть ли способ отлаживать GUI код графики прямо на LapTop(е) при этом не меняя язык программирования Си? Ответ: да.
Если использовать lvgl, можно вообще его и на компьютере запустить:
https://docs.lvgl.io/latest/en/html/get-started/pc-simulator.html
SDL и Skia тоже можно было бы рассмотреть в качестве вариантов, которые позволяют рисовать простые элементы без углубления в opengl/directx/и т.д.
Если вы все равно генерируете файл, то почему сразу не генерировать .bmp? Формат у него довольно простой формат, прямо в википедии описан. Так исключается лишний шаг в виде запуска graphviz.
Еще несколько лет назад можно было бы вообще использовать XBM, но в последнее время его выпиливают из браузеров.
я бы наверно вообще генерировал файл с 0 и 1, а уже рисовал его чем-то другим - все равно вон у него идет вызов
sprintf(CmdCommand, "start /B dot.exe -Kneato -Tpng %s -o %s", FileNameGv,FileNamePng);
res = win_cmd_run(CmdCommand);
или даже еще проще - генерировал HTML, а в нем body с одной table (и там воттакенные пыксели в ячейках).
и все - не нужно никаких промежуточных программ
Если вы все равно генерируете файл, то почему сразу не генерировать .bmp?
Сгенерировать текстовый файл graphviz проще (4 строчки кода ) чем бинарный *.bmp.
так-то заголовок не самый сложный, только разрешение по горизонтали должно быть кратно 4, чтобы без padding. вроде бы так:
int s = 54+w*h*3;
char header[54] = {'B', 'M', s, s>>8, s>>16, s>>24, 0, 0, 0, 0, 54, 0, 0, 0, 40, 0, 0, 0, w, w>>8, w>>16, w>>24, h, h>>8, h>>16, h>>24, 1, 0, 24, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}; дальше w*h*3 байт данных пикселей
а можно через popen открыть gnuplot, сказать ему
fprintf(f, "set view map\n");
fprintf(f, "splot '-' matrix with image\n");
потом данные и e\ne\n в конце
вылезет окошко с пикселями https://gnuplot.sourceforge.net/demo/heatmaps.html
на Си надо сразу генерировать .svg
Это долго, приходится ожидать окончания процесса компиляции потом окончания процесса пере прошивки, чтобы наконец увидеть результат.
Хм. У вас есть предложение как это можно сделать без ожидания процесса компиляции? Если нет, то зачем упоминать компиляцию?
Если внесли изменение в DashBoard для экрана SSD1306 в прошивке, то её по любому надо пере собирать и затем заливать на target. А это 3,5 + 2 = 5.5 минут.
Поставили пробел в коде, а код вступает в бой только через 6 минут.
А в вашем решении без заливки на target какие тайминги и на что?
У меня ядро линукса пересобирается секунд за 30, если я пробел в драйвере ставлю. И то, основное время оно перелинковывается по три раза. Zephyr RTOS естественно пересобирается еще быстрее. В обоих случаях это инкрементальная сборка, конечно же. Зачем каждый раз компилировать то что не менялось?
Ничего не понял. Это потом и в "боевом" микроконтроллере будет генерироваться код .gv? Или он только в симуляции и фактически заменяет какой-нибудь фотошоп, в котором редактируется компоновка экрана? А если так, то о какой отладке вообще идет речь, если потом все равно надо будет все переписывать и отлаживать на реальном микроконтроллере?
Это потом и в "боевом" микроконтроллере будет генерироваться код .gv?
нет.
Или он только в симуляции и фактически заменяет какой-нибудь фотошоп, в котором редактируется компоновка экрана?
да
А если так, то о какой отладке вообще идет речь, если потом все равно надо будет все переписывать и отлаживать на реальном микроконтроллере?
Смысл в том чтобы ускорить разработку сложной графики
Каким образом ее можно будет ускорить, если в симуляции использовать совершенно другую - абстрактную - библиотеку, после чего для контроллера переписывать все заново с совершенно иным принципом отрисовки?
Должен быть одинаковый Low Level API как у стимулятора так и у прошивки.
Вот именно. Симулятор - это такая штука, которая симулирует поведение чего-либо. То есть "Симулятор Графического Монохромного Дисплея" должен повторять поведение реального дисплея - работать с теми же командами, так же на них реагировать. Но я пока не встречал дисплеев, которые могут закрашивать области командой fprintf(...).
так всё равно ж оно обернуто в пару каких-нибудь функций вроде put_pixel и swap_buffer для тех кто выше.
а будет там внутри fprintf, просто запись в буфер или прямо в дисплей висящий на внешней шине и отмапленный в общее адресное пространство, или вообще вызов egavga.bgi :)) не столь принципиально.
Совершенно необязательно, это самый примитивный и медленный вариант. Там может быть формирование промежуточного буфера в формате дисплея с последующей его отправкой через DMA. Там может использоваться оконная функция дисплея. Там может использоваться вращение координатной системы дисплея. И тогда вся вот эта "симуляция" теряет все остатки своего смысла
Но даже если все рисуется каким-нить PutPixel - все равно это не симулятор дисплея. Симулятором это было бы если бы прошивка полностью повторяла работу с реальным дисплеем, но выдавала сигналы и данные не на реальный дисплей, а, например, на компьютер через UART или в USB, где программа симулятора дисплея эмулировала бы реакцию дисплея на полученные данные и сигналы. Ну или если Вы хотите отлаживать прошивку прямо на компе - то выдача сигналов и данных в какой-нибудь API симулятора.
А в описанном Вами подходе вообще все бессмысленно. Проще уж прицепить любую графическую библиотеку и рисовать прямо на экране, а не городить вот это всё через тридцать три колена.
Симулятор Графического Монохромного Дисплея на Graphviz