Comments 57
Очень не хватает возможности вывода картинок и графиков.
а некоторые стоят больше, чем ваш проект целиком
Интересно, а сколько стоила разработка вашего проекта (взяв среднюю цену работы системного программиста в час по отрасли)?
Например, нейрохирург получает тысячи долларов за одну операцию, потому, что обучить его было очень дорого. И стоимость этого обучения заложена в стоимость операций им проводимых.
Здесь тоже самое.
Обучение делается «в кредит» будущей работы.
Боюсь себе представить, сколько стоило написание вашего комментария.
Если ты не банкир или «менеджер», фу.
И сильно противоречит духу опенсорса.
Ты же не будешь кодером до пенсии, рано или поздно будешь руководить (официально или нет) группой/отделом/компанией и будешь совмещать свои профессиональные обязанности с обязанностями «менеджера».
Опенсорс не мешает зарабатывать, скорее наоборот. :-)
Ты же не будешь кодером до пенсии, рано или поздно будешь руководить (официально или нет) группой/отделом/компанией и будешь совмещать свои профессиональные обязанности с обязанностями «менеджера».А если дальше пойти?
Бросить наемную работу и заниматься любыми делами в свое удовольствие, в т.ч. теми что приносят доход.
И бросить мыслить категориями — сколько стоит погладить жену =)
Да и чёрт с ним. Вы с друзьями общаетесь с такими же мыслями? Не завидую им. И вообще, вашим близким.
Строго говоря, ваше время бесценно на столько же, насколько бесценна сама ваша жизнь. А если рассуждать вашей логикой, то можно просто взять, умножить вашу цену на потенциальный максимальный трудовой стаж. Судя по профилю, вам 42 года. До пенсии вам осталось что-то около 23 лет. За это время работая 8 часов по будням вы заработаете около 17 мруб. После этого будете получать ещё пенсию. В зависимости от того, сколько вы проживёте и сколько будете работать после выхода на пенсию, вы сможете получить ещё примерно столько же. И так, получается, что стоимость оставшейся вашей жизни будет составлять примерно 35 мруб. Теперь вы знаете «чего вы стоите в профессиональном плане». Наверное это действительно полезно. Да вот какая странность. Эта стоимость совершенно не учитывает, ни то, какой вы муж, ни то, какой вы отец, ни то, как любит вас собака, если она у вас есть. Хотя, с таким подходом, наверное у вас её нет. Ведь почесать её за ухом будет стоить для неё десять рублей. Вы же профессионал.
Ладно. К чему бы это я? К тому, что человек сделал нечто хорошее (библиотеку) и поделился этим со всеми. У него наверное просто есть какие-то другие меры своей ценности. В комментариях была указана стоимость его работы. И как мне кажется, она на несколько порядков выше вашей.
А откуда вы пять человеко-лет взяли? 22k строк при нормальной производительности в 100 строк в день (в предположении, что количество бойлерплейта там более-менее среднее, что для библиотеки такого рода на Си вполне вероятно) вполне укладывается в ~11-12 человеко-месяцев.
Судя по https://www.openhub.net/p/MakiseGUI основной объём был добавлен в интервале последних 3-4 месяцев. Ну и оценка в 100 строк на Си в день — это с учётом отладки.
Естественно производительность может быть меньше на порядок в более низкоуровневых кусках: со сложным flow на прерываниях, dma и прочими радостями, разбором сложных протоколов взаимодействия со сторонней аппаратурой (настройка того же fsmc).
Но такого рода библиотека (основная её часть) — обычная аппаратно-независимая работа с данными и простым буфером в памяти, так что оценка была сделана такая.
Не подумайте, что я обесцениваю работу SL_RU. Если дойдут руки попробовать, то я не поленюсь дополнить документацией и багфиксами.
На начальной показатель высокий, потом низкий
Если весь проект 22к строк, то дорасти до 22 от 20 может быть те самые оставшиеся 4 года
Но в планах сделать автоматическое определение. Но это в планах — пока не особо нужно.
Насколько я понимаю поддержки полупрозрачных контролов нет пока, это сильно упрощает задачу по отрисовке только необходимых контролов.
Прозрачные цвет есть, а полупрозрачных нет. В стиле можно задать в любом месте MC_Transparent и тогда эта деталь(бэкграунд, обводка, шрифт и тп) просто не будет рисоваться — не будет тратить ресурсы.
Очень заинтересовался вашим проектом. В одном разрабатываемом устройстве нужен дисплей и делаем какое-то подобие GUI библиотеки, но пока там просто куча говнокода и из контроллов — кнопка. Правда, дисплей (как раз ili9340) подключен по SPI (увы) и полное обновление занимает кучу времени.
Так-то есть лишь одно решение — обновлять лишь необходимые части. Но механизма для этого в библиотеке нет — только если делать вручную…
У Вас как реализована работа с дисплеем? FSMC?
Я ошибся, у нас не SPI, а 8-битный 8080 интерфейс. Очистка экрана занимает… ну секунду и невооруженным взглядом видно, как он стирается строчка-за строчкой. Понятное дело, что каждый раз при переключении кнопки такое делать — неприемлимо.
Что-то жестоко — секунда 0_0
Вы на каком МК это делаете? Не эмулируете ли случаем 8080 на GPIO? На 8080 можно обновлять хоть на всех 60фпс дисплей, если использовать хардварный интерфейс с DMA…
STM32 F107VCT6. Была непонятная noname библиотека, в которой даже работа с GPIO была через странную абстракцию и было еще дольше. Переписал на чистый GPIO — стало несколько быстрее, но не сильно вникал в детали. Почему-то казалось, что у дисплея ограничение на тайминги при передаче.
Спасибо за наводку, попробую ускорить.
У STM32F103C8T6 оперативки аж 20 килобайт, из которых нужно оставить для бизнес-логики и RTOS. На весь экран нужно куда больше ОЗУ.
Таким образом экранчик ILI9341 придется перерисовывать в 6-7 проходов. И код рендеринга изначально писать под фреймбуфер произвольного размера, меньшего размеру экрана
1.1 Рассчитана ли библиотека на монохромные экраны? Например, часто применяемые 128x64.
1.2 Имеется ли возможность рисования без буфера для монохромных экранов (в случае их поддержки)?
1.3 Имеется ли возможность выбора между отрисовкой с использование буфера и без него для монохромных экранов (в случае их поддержки)?
2.1 Какого рода требуется драйвер для цветного дисплея? Имеется ввиду, библиотеке рисования просто требуется поставить указатель на нужный пиксель строки/столбца LCD и после передать N пакетов, содержащих в себе цвета пикселей (массив цветов пикселей) из буфера, или будет требоваться по пиксельное обращение к буферу экрана?
2.2 В дополнение к предыдущему вопросу: отрисовка идет сразу готовой сформированной (или формирующийся динамически между передачами) картинки (драйвер просто копирует из буфера мк в буфер LCD) или же отрисовка идет по-элементно: сначала прямоугольник кнопки, потом внутри него текст и т.д.
2.3 Есть ли возможность создать const связанный список на этапе компиляции, а потом просто подставлять нужный список для отрисовки? Например, у меня 3 меню, все положения и т.д. заранее известны. Меняются только значения и такст. Я могу сделать const связанный список, который будет содержать указатели на изменяемые данные (которые будут динамически обновляться при каждой перерисовке)?
Чтобы было более понятно: очень много модулей мк в моих проектах (на CPP), работают на constexpr. Например. При условии, что GPIO никогда не меняют своих настроек в процессе работы (1 линия — 1 режим работы), я использую constexpr функции, которым скармливаю конфигурации каждого вывода, а на выходе получаю просто массив uint32_t переменных, которые в реальном времени (времени выполнения) копирую в выбранные GPIO.
Возможно ли нечто подобное в вашей библиотеке? Например, создаю объект (или структуру) описания одного окна, потом, если нужно, добавляю в него ссылки на другие окна, все это во время компиляции вычисляется и создается const структуры, которыми потом будет оперировать библиотека в реальном времени.
1.2) Да, отрисовка происходит за раз, поэтому можно сразу из системного буфера гнать данные на экран.
1.3) Не совсем понял этот вопрос… Первый буфер, в который рисуют всё методы отрисовки примитивов обязателен, а второй, используемый только драйвером — не. Например драйвер SDL его и не использует.
2.1) Драйвер лишь должен инициализировать дисплей и отправлять данные из первичного буфера на экран. Единственное дополнительное, что может потребоваться — преобразовывать цвета, если битность первичного буфера не совпадает с той, что необходима дисплею(например для экономии РАМы и тп). А так да, достаточно скормить дисплею данные с указателя.
2.2) ГУЙ рисует в свой буфер(в первичный) за один проход, который просто потом использует драйвер. Драйвер может скопировать его, а может и нет.
2.3) Конечно можно — всё сделано через структуры в которые можно тупо скопировать необходимые данные по указателю, но это будет значительно сложнее, чем написать просто функцию инициализации.
MakiseGUI — бесплатная библиотека графического интерфейса для микроконтроллеров