Как организовать структуру грфической библиотеки на C для микроконтроллера?
Суть в чем.
Пишу свой велосипед для устройства с монохромный графическим дисплеем.
Продумываю структуру графической библиотеки для дальнейшего ее использования на различных платформах.
Пока вижу это так:
0) Аппаратный уровень - функции, которые зависят от интерфейса дисплея и способа общения с ним микроконтроллера. На этом уровне пишу некую функцию send_byte() которая отправляет данные в физический порт дисплея.
1) Уровень драйвера дисплея - функции инициализации дисплея, функции очистки дисплея, функции заливки в дисплей массива данных, управления яркостью и тд Все эти функции так или иначе обращаются к send_byte() для работы с самим дисплеем
2) Уровень библиотеки "paint" - отрисовка данных во временный буфер (функции рисования примитивов типа точка, линия, квадрат, текст), функция обновления информации на дисплее из этого буфера.
3) Уровень библиотеки "effect" - эффекты анимации текста, анимация простой графики (сдвиг точки в пространстве, поворот линии и тд)
4) Уровень приложения - функции вывода даты, времени на дисплей используя все нижестоящие слои, функции вывода текста со скроллом, отрисовка пользовательской графики.
Сделал такое разбиение исходя из того, что каждый слой можно переделать под свои задачи. Например для переноса с одной архитектуры МК на другую - нужно исправить только слой 0.
При смене дисплея - только слой 1
При доработках анимации - трогаем только слой 3
При возникновении новых задач (например отрисовка элементов управления) - только слой 4
и тд.
Вопрос: Правильно ли я закладываюсь или что то упускаю?
PS Готовые библиотеки брать нельзя.
Все верно, но так же нужно понимать, что библиотека пишется под МК у которого очень ограниченная память. Может так случится что ваша мегакрутая библиотека займет всю память и будет жутко тормозить.
Может имеет смысл описать общий алгоритм работы каждого уровня и реализовывать это оптимизируя для каждого отдельно взятого МК и дисплея, на самом деле их не так много и не все они попадут к вам в руки
Ну, универсальную ее все равно не сделать, поэтому сделал такое разграничение по слоям, при смене МК но сохранении того же индикатора - нужно будет только переписать самый нижний уровень.
При смене дисплея на подобный но с другим типом подключения - переписываем слои 0,1
При смене типа дисплея: был 7 сегментный на 8 разрядов - стал монохромный с разрешением 128 х 64 точки - переписываем уровни 1,2
и тд.
Конечно, если у нас был 7 сегментный дисплей и мы вдруг решили заменить его на TFT панель 240 х 320 - то для полноценной работы придется поочередно переписать все модули. Но даже в такой замене, можно будет получить ЧБ графику, переписав лишь слои 1 и 2, так как слой 2 по сути занимается только расчетами в рисовании прямых, окружностей и пр, а взаимодействует с экраном только через буфер.
1. функции рисования кнопок, меню, радиобатонов, выпадающих списков и прочих сущностей где?
2. устройства ввода, указатели, курсоры где?
3. обработка событий от устройств ввода/эмуляции есть?
Это все уровень 4 и выше. Пока только интересует в правильном направлении иду или нет. Пока что стоит задача проработать структуру для дальнейшего повторного использования в различных проектах. Начиная от 7 сегментного дисплея (меняем слой 1 и 2) и до графических tft дисплеев (меняем слои 1 и 2 на соответствующие, дописываем эффекты в 3)
Если нужна работа с тачем - в слой 4 добавляем элементы GUI (списки, кнопки, меню и тд), дописываем слой 5 который получает данные с тач контроллера и привязывает их к координатам из слоя 4
iv_k: Пока что дисплей без тача, обычный монохромник, но в данной серии устройств могут быть различные дисплеи, поэтому хотелось бы заложить фундамент для того, чтобы потом можно было переписать 1 модуль, не трогая все остальное.
Логическая структура правильно заложена?
Простой
Простой
Простой
