Comments 57
ЭльПсиКонгру!
Спасибо!
Жаль что пример выполнен не на микроконтроллере микроволновки.
Можете подсказать, на какие зарубежные ресурсы можно выложить эту статью?
Жаль что не про AI, тут бы название ироничнее было (речь о линии сюжета S;G 0)
Спасибо, очень интерестная работа.
Очень не хватает возможности вывода картинок и графиков.
Очень не хватает возможности вывода картинок и графиков.
а некоторые стоят больше, чем ваш проект целиком
Интересно, а сколько стоила разработка вашего проекта (взяв среднюю цену работы системного программиста в час по отрасли)?
Именно этой библиотеки? Ноль — я её писал для будущих своих коммерческих проектов в свободное от работы и учёбы время.
Плохо, что цена вашего свободного времени ноль :-/
Она совсем не нулевая, но только именно за эту библиотеку я денежной прибыли не получу.
Цена свободного времени — полученный опыт
Цена этого потраченного времени заложена в стоимость будущих работ.
Например, нейрохирург получает тысячи долларов за одну операцию, потому, что обучить его было очень дорого. И стоимость этого обучения заложена в стоимость операций им проводимых.
Здесь тоже самое.
Обучение делается «в кредит» будущей работы.
Например, нейрохирург получает тысячи долларов за одну операцию, потому, что обучить его было очень дорого. И стоимость этого обучения заложена в стоимость операций им проводимых.
Здесь тоже самое.
Обучение делается «в кредит» будущей работы.
Боюсь себе представить, сколько стоило написание вашего комментария.
:) 57 руб (потратил примерно 10 минут). И странно, что вопросы про рабочее время вызывают такую реакцию… Знать, чего ты стоишь ведь очень полезно в профессиональном плане.
Считать чужие потраченные деньги, либо время, бесполезно.
Если ты не банкир или «менеджер», фу.
И сильно противоречит духу опенсорса.
Если ты не банкир или «менеджер», фу.
И сильно противоречит духу опенсорса.
Наоборот, считать деньги очень полезно. В любом проекте есть экономическая составляющая (см. свой диплом), и трезвая оценка своих сил поможет даже с «бесплатными» проектами.
Ты же не будешь кодером до пенсии, рано или поздно будешь руководить (официально или нет) группой/отделом/компанией и будешь совмещать свои профессиональные обязанности с обязанностями «менеджера».
Опенсорс не мешает зарабатывать, скорее наоборот. :-)
Ты же не будешь кодером до пенсии, рано или поздно будешь руководить (официально или нет) группой/отделом/компанией и будешь совмещать свои профессиональные обязанности с обязанностями «менеджера».
Опенсорс не мешает зарабатывать, скорее наоборот. :-)
Ты же не будешь кодером до пенсии, рано или поздно будешь руководить (официально или нет) группой/отделом/компанией и будешь совмещать свои профессиональные обязанности с обязанностями «менеджера».А если дальше пойти?
Бросить наемную работу и заниматься любыми делами в свое удовольствие, в т.ч. теми что приносят доход.
И бросить мыслить категориями — сколько стоит погладить жену =)
А как вы это подсчитали? Если вы как программист оцениваете стоимость своих 10 минут в 57 рублей (что-то около 60 тысяч в месяц?), то это же вовсе не значит, что кто-то вам заплатил бы эти же деньги за написание комментариев на хабре. Почему вы думаете, что рыночная стоимость комментария тут 57 рублей?
Да и чёрт с ним. Вы с друзьями общаетесь с такими же мыслями? Не завидую им. И вообще, вашим близким.
Строго говоря, ваше время бесценно на столько же, насколько бесценна сама ваша жизнь. А если рассуждать вашей логикой, то можно просто взять, умножить вашу цену на потенциальный максимальный трудовой стаж. Судя по профилю, вам 42 года. До пенсии вам осталось что-то около 23 лет. За это время работая 8 часов по будням вы заработаете около 17 мруб. После этого будете получать ещё пенсию. В зависимости от того, сколько вы проживёте и сколько будете работать после выхода на пенсию, вы сможете получить ещё примерно столько же. И так, получается, что стоимость оставшейся вашей жизни будет составлять примерно 35 мруб. Теперь вы знаете «чего вы стоите в профессиональном плане». Наверное это действительно полезно. Да вот какая странность. Эта стоимость совершенно не учитывает, ни то, какой вы муж, ни то, какой вы отец, ни то, как любит вас собака, если она у вас есть. Хотя, с таким подходом, наверное у вас её нет. Ведь почесать её за ухом будет стоить для неё десять рублей. Вы же профессионал.
Ладно. К чему бы это я? К тому, что человек сделал нечто хорошее (библиотеку) и поделился этим со всеми. У него наверное просто есть какие-то другие меры своей ценности. В комментариях была указана стоимость его работы. И как мне кажется, она на несколько порядков выше вашей.
Да и чёрт с ним. Вы с друзьями общаетесь с такими же мыслями? Не завидую им. И вообще, вашим близким.
Строго говоря, ваше время бесценно на столько же, насколько бесценна сама ваша жизнь. А если рассуждать вашей логикой, то можно просто взять, умножить вашу цену на потенциальный максимальный трудовой стаж. Судя по профилю, вам 42 года. До пенсии вам осталось что-то около 23 лет. За это время работая 8 часов по будням вы заработаете около 17 мруб. После этого будете получать ещё пенсию. В зависимости от того, сколько вы проживёте и сколько будете работать после выхода на пенсию, вы сможете получить ещё примерно столько же. И так, получается, что стоимость оставшейся вашей жизни будет составлять примерно 35 мруб. Теперь вы знаете «чего вы стоите в профессиональном плане». Наверное это действительно полезно. Да вот какая странность. Эта стоимость совершенно не учитывает, ни то, какой вы муж, ни то, какой вы отец, ни то, как любит вас собака, если она у вас есть. Хотя, с таким подходом, наверное у вас её нет. Ведь почесать её за ухом будет стоить для неё десять рублей. Вы же профессионал.
Ладно. К чему бы это я? К тому, что человек сделал нечто хорошее (библиотеку) и поделился этим со всеми. У него наверное просто есть какие-то другие меры своей ценности. В комментариях была указана стоимость его работы. И как мне кажется, она на несколько порядков выше вашей.
посчитать то можно, проблема в том, что часто «в свободное от работы и учёбы время» посчитать затруднительно. Сегодня я работаю над проектом три часа, завтра один час, послезавтра ни одного. А в субботу пошел дождь, поэтому я остался дома и писал код весь день с перерывами на еду. В итоге трудозатраты можно оценить лишь косвенно по количеству строк.
Я спрашивал про метрики, про кол-во кода помноженную на среднюю ставку программиста способного написать такое системное ПО.
К сожалению не могу ответить на этот вопрос. Платят обычно за проект целиком, а не за строки кода.
Я сам прикинул :-) Получается примерно 22 000 строк (если считать весь код оригинальным), ~ 5 чел/лет, и если оценивать по скромным зарплатам в РФ, то около 5 млн. руб. Если за рубежом, то ~ $256 000.
При рабочем дне 6 часов, это получается одна строка в 24 минуты… Вдумчивое программирование :)
А откуда вы пять человеко-лет взяли? 22k строк при нормальной производительности в 100 строк в день (в предположении, что количество бойлерплейта там более-менее среднее, что для библиотеки такого рода на Си вполне вероятно) вполне укладывается в ~11-12 человеко-месяцев.
Не всё так просто, чем больше проект тем труднее идёт дописывание нового кода, медленнее тестирование, больше отладки. Программа же должна не только быть напечатана, но и заработать.
Судя по https://www.openhub.net/p/MakiseGUI основной объём был добавлен в интервале последних 3-4 месяцев. Ну и оценка в 100 строк на Си в день — это с учётом отладки.
Естественно производительность может быть меньше на порядок в более низкоуровневых кусках: со сложным flow на прерываниях, dma и прочими радостями, разбором сложных протоколов взаимодействия со сторонней аппаратурой (настройка того же fsmc).
Но такого рода библиотека (основная её часть) — обычная аппаратно-независимая работа с данными и простым буфером в памяти, так что оценка была сделана такая.
Не подумайте, что я обесцениваю работу SL_RU. Если дойдут руки попробовать, то я не поленюсь дополнить документацией и багфиксами.
Все зависит от стадии проекта
На начальной показатель высокий, потом низкий
Если весь проект 22к строк, то дорасти до 22 от 20 может быть те самые оставшиеся 4 года
На начальной показатель высокий, потом низкий
Если весь проект 22к строк, то дорасти до 22 от 20 может быть те самые оставшиеся 4 года
Как происходит отрисовка? Каждый раз перерисовываеться все или библиотека умеет определять необходимый регион перерисовки?
Каждый раз всё с нуля, да. Можно вручную поменять регион перерисовки.
Но в планах сделать автоматическое определение. Но это в планах — пока не особо нужно.
Но в планах сделать автоматическое определение. Но это в планах — пока не особо нужно.
Имхо это должно быть фичей с самым высоким приоритетом, иначе сколько-нибудь сложный интерфейс будет отнимать много времени у CPU(а это и быстрая разрядка батарей) и даже подтормаживать.
Насколько я понимаю поддержки полупрозрачных контролов нет пока, это сильно упрощает задачу по отрисовке только необходимых контролов.
Насколько я понимаю поддержки полупрозрачных контролов нет пока, это сильно упрощает задачу по отрисовке только необходимых контролов.
Да, это важная штука, но для моей задачки она пока не сильно требовалась, а времени на разработку ушло бы много.
Прозрачные цвет есть, а полупрозрачных нет. В стиле можно задать в любом месте MC_Transparent и тогда эта деталь(бэкграунд, обводка, шрифт и тп) просто не будет рисоваться — не будет тратить ресурсы.
Прозрачные цвет есть, а полупрозрачных нет. В стиле можно задать в любом месте MC_Transparent и тогда эта деталь(бэкграунд, обводка, шрифт и тп) просто не будет рисоваться — не будет тратить ресурсы.
Что за дискач на 3:20 последнего видео? Железная проблема?
Очень заинтересовался вашим проектом. В одном разрабатываемом устройстве нужен дисплей и делаем какое-то подобие GUI библиотеки, но пока там просто куча говнокода и из контроллов — кнопка. Правда, дисплей (как раз ili9340) подключен по SPI (увы) и полное обновление занимает кучу времени.
А кучу — это сколько? Для гуи ведь не нужны 24фпс, достаточно лишь чтобы действия были отзывчивыми. Но даже на stm32f103c8t6 на тактовой частоте 72мгц гуй работал очень даже прилично — был совершенно юзабелен.
Так-то есть лишь одно решение — обновлять лишь необходимые части. Но механизма для этого в библиотеке нет — только если делать вручную…
Так-то есть лишь одно решение — обновлять лишь необходимые части. Но механизма для этого в библиотеке нет — только если делать вручную…
У Вас как реализована работа с дисплеем? FSMC?
Я ошибся, у нас не SPI, а 8-битный 8080 интерфейс. Очистка экрана занимает… ну секунду и невооруженным взглядом видно, как он стирается строчка-за строчкой. Понятное дело, что каждый раз при переключении кнопки такое делать — неприемлимо.
DMA + SPI
Что-то жестоко — секунда 0_0
Вы на каком МК это делаете? Не эмулируете ли случаем 8080 на GPIO? На 8080 можно обновлять хоть на всех 60фпс дисплей, если использовать хардварный интерфейс с DMA…
Что-то жестоко — секунда 0_0
Вы на каком МК это делаете? Не эмулируете ли случаем 8080 на GPIO? На 8080 можно обновлять хоть на всех 60фпс дисплей, если использовать хардварный интерфейс с DMA…
STM32 F107VCT6. Была непонятная noname библиотека, в которой даже работа с GPIO была через странную абстракцию и было еще дольше. Переписал на чистый GPIO — стало несколько быстрее, но не сильно вникал в детали. Почему-то казалось, что у дисплея ограничение на тайминги при передаче.
Спасибо за наводку, попробую ускорить.
Чтобы делать полноценную сверхбыструю (средствами SPI DMA) перерисовку экрана для ILI9341, то нужно хранить кусок результата (самое простое — весь экран) в оперативной памяти.
У STM32F103C8T6 оперативки аж 20 килобайт, из которых нужно оставить для бизнес-логики и RTOS. На весь экран нужно куда больше ОЗУ.
Таким образом экранчик ILI9341 придется перерисовывать в 6-7 проходов. И код рендеринга изначально писать под фреймбуфер произвольного размера, меньшего размеру экрана
У STM32F103C8T6 оперативки аж 20 килобайт, из которых нужно оставить для бизнес-логики и RTOS. На весь экран нужно куда больше ОЗУ.
Таким образом экранчик ILI9341 придется перерисовывать в 6-7 проходов. И код рендеринга изначально писать под фреймбуфер произвольного размера, меньшего размеру экрана
Одного лишь названия библиотеки хватило, чтобы я обратил на нее свое внимание… Ну это все лирика. Временами на хабре появляются подобные статьи, где люди показывают нечто подобное. Но ваш уровень мне понравился больше. Честно, на код пока не смотрел, но демо понравилось, а так же стиль работы с GUI, похожий на библиотеку QT. Задам вам сейчас несколько «вопросов от новичка»:
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.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.1) Да, рассчитана. На самом деле библиотека и произошла, хоть и пройдя долгий путь развития, от прошлой библиотеки для 128х64 дислея. (кусок работы запечатлён тут. Там тоже были кнопочки и прочие элементы, ноо работа была с ними на совсем примитивном уровне.)
1.2) Да, отрисовка происходит за раз, поэтому можно сразу из системного буфера гнать данные на экран.
1.3) Не совсем понял этот вопрос… Первый буфер, в который рисуют всё методы отрисовки примитивов обязателен, а второй, используемый только драйвером — не. Например драйвер SDL его и не использует.
2.1) Драйвер лишь должен инициализировать дисплей и отправлять данные из первичного буфера на экран. Единственное дополнительное, что может потребоваться — преобразовывать цвета, если битность первичного буфера не совпадает с той, что необходима дисплею(например для экономии РАМы и тп). А так да, достаточно скормить дисплею данные с указателя.
2.2) ГУЙ рисует в свой буфер(в первичный) за один проход, который просто потом использует драйвер. Драйвер может скопировать его, а может и нет.
2.3) Конечно можно — всё сделано через структуры в которые можно тупо скопировать необходимые данные по указателю, но это будет значительно сложнее, чем написать просто функцию инициализации.
1.2) Да, отрисовка происходит за раз, поэтому можно сразу из системного буфера гнать данные на экран.
1.3) Не совсем понял этот вопрос… Первый буфер, в который рисуют всё методы отрисовки примитивов обязателен, а второй, используемый только драйвером — не. Например драйвер SDL его и не использует.
2.1) Драйвер лишь должен инициализировать дисплей и отправлять данные из первичного буфера на экран. Единственное дополнительное, что может потребоваться — преобразовывать цвета, если битность первичного буфера не совпадает с той, что необходима дисплею(например для экономии РАМы и тп). А так да, достаточно скормить дисплею данные с указателя.
2.2) ГУЙ рисует в свой буфер(в первичный) за один проход, который просто потом использует драйвер. Драйвер может скопировать его, а может и нет.
2.3) Конечно можно — всё сделано через структуры в которые можно тупо скопировать необходимые данные по указателю, но это будет значительно сложнее, чем написать просто функцию инициализации.
Планируете ли вы добавить в библиотеку такие объекты как: график (по точкам из массива), диаграммы (так же из массива), эквалайзер. Просто я планирую использовать последний в своем проекте. Посмотрев демо-видео конечно пришла очень страшная идея: сделать на каждую «палку» эквалайзера по вертикальному статус-бару, но 100 статус баров (для простого эквалайзера на OLED дисплее) — это очень страшно)))
Sign up to leave a comment.
MakiseGUI — бесплатная библиотека графического интерфейса для микроконтроллеров