Comments 56
Гуд. На AVR32/64 не портируется?
"Предположим под ваш дисплей драйвер уже написан порт LVGL и вам надо только интегрировать его в проект." — что-то не так с этим предложением
Если хочется поработать с ней на Rust, то есть проект LittlevGL bindings for Rust
В другом проекте использую H750, у него с оперативной памятью проблем нет, но флеша всего 128кб :)
Я в код библиотеки не лазил, но судя по документации и описанию от автора, библиотека умеет перерисовывать только изменившуюся часть картинки.
Очень понравился механизм файловых систем. Мне нужно было показывать картинку из SPI флеш и картинки создаваемые «на лету» из файлов на SD карте. При помощи файловых систем удалось решить достаточно просто и прозрачно.
Я в код библиотеки не лазил, но судя по документации и описанию от автора, библиотека умеет перерисовывать только изменившуюся часть картинки.
Если вам зачем-то понадобиться отрисовать весь экран заново, для этого достаточно вызвать lv_obj_invalidate(lv_scr_act()) или что-то вроде этого
if I’m not using a calendar on a 128x64 display I can disable it by setting LV_USE_CALENDAR to 0 and it won’t take up precious flash memory.
Можно выключать модули
этот код закрыт
речь шла именно об этом коде
Как все таки отстает программирование на микроконтроллерах от программирования для pc.
Прежде всего отстает технологически, то чем занимались в 90х на pc, только сейчас приходит в мк.
Если посмотреть на современные интерфейсы и как предлагают их программировать я же сколько человекочасов должен потратить, чтобы добиться минимума. С таким подходом у меня устройство устареет быстрее, чем я его а серию отправлю.
Но насчёт отставания вы правы, по крайней мере в культуре разработки софта разница очень заметна. Из моего опыта редкий программист встраиваемых систем пользуется системами контроля версий, например. А за всякие SOLID, паттерны и интерфейсы вообще можно хипстером-выпендрёжником прослыть. Хотя конечно может это мне просто не везёт так.
А за всякие SOLID, паттерны и интерфейсы вообще можно хипстером-выпендрёжником прослыть
А они часто и не нужны, если устройство однозадачное и код необновляемый и сопровождаемый одним человеком. Если что-то хитрое (сборочный робот или микроволновка с кучей рецептов), то вот тут-то приёмы, ориентированные на читаемость и расширяемость, и вылезают.
Это шутка была, к тому что Ваш комментарий удачно подтвердил мой тезис.
Конкретно на Ваш комментарий можно ответить так — не обязательно применять что-то просто потому что ты это знаешь, но важно знать чтобы иметь возможность понять когда надо применить и чтобы иметь возможность это сделать. Тут точно так-же как с инструментами для ручной работы — если у вас есть молоток, то не обязательно делать им вообще всё подряд — но вот когда нужно забить гвоздь то плохо когда молотка у вас нету. Но я серьёзно не вижу смысла продолжать спорить.
Почти никогда не выходит продуктивного разговора на эту тему, понимаете? Стоит хоть мельком упомянуть хоть что-то из теории программирования, наработанной за последние пару десятилетий — как в половине случаев собеседник-эмбеддер тут-же бросается доказывать что то, о чём ты упомянул, либо в принципе ерунда никчёмная, либо в его конкретном случае не нужно, либо конкретно ему не нужно, либо ещё десяток причин почему его это не должно касаться.
Зато потом приходится принимать на поддержку чужие проекты, где каждая версия ПО хранится в своём отдельном архиве с короткой запиской, в которой на память перечислены изменения в новой версии. Как позже выяснится, от последней версии прошивки исходников вообще нет, а автор уволился несколько лет назад.
Или проекты, где все *.с файлы кроме одного исключены из компиляции, и заинклужены (не заголовочники, а *.с файлы) в этот самый единственный, что фактически даёт один юнит компиляции длиной в 7+ тысяч строк. Ключевого слова static там принципиально нет, всё что не локальное у функции — то глобальное. Всё может обращаться ко всему. А переменная с говорящим названием TFM отвечает — очевидно же — за логику работы пищалки.
Конечно это всё полные случайности — на самом деле все всё делали хорошо, оно само плохо получилось. Никакое понимание какой-либо теории здесь бы не помогло, да.
А если серьёзно — на мой взгляд в таких спорах сильнее всего влияет недоверие к чужому опыту (в лучшем случае) и/или банальная лень (в худшем случае). Иногда ещё примешивается свойственное всем людям желание ощущать себя особенным, избранным, дивергентом, довакином, Бэтменом. Мол "Это хипстерам в их вебе паттерны нужны, они просто не знают что такое настоящее программирование — без права на ошибку и по локоть в хлорном железе. Нам, гордым и могучим эмбеддерам, вся эта детская возня ни к чему.". А приводимые в споре аргументы — просто рационализация.
В общем что я хочу сказать. Скромнее надо быть, и не чураться перенимать чужой опыт.
Другой вопрос про организацию работы: svn/гит это просто удобно, тесты полезны (несмотря на то, что в эмбедде часто разводит плату, пишет код и гоняет тесты один человек), а doxygen экономит время. Тут просто надо любить, уметь, практиковать.
Можете подсказать по области видимости виджетов?
Допустим, в одной функции я создаю метку с одним текстом. А в другой функции меняю её текст. У меня всё крашится при этом. Видимо, область видимости метки ограничена первой функцией, и вторая функция творит дичь в ОЗУ. Но как сделать правильно?
Интеграция в проект LVGL графической библиотеки для микроконтроллеров