AVF (02.01.2013 21:20, просмотров: 268) ответил Kota на Присодиняюсь-
- Тоже похожим надо заниматься. Первые впечатления. По моему HAL немного должен быть по другому. HAL - ничего не должен знать о рисовании линий, знаков кругов итд. HAL - должен обслужить железо и иметь узкий интерфейс для GUI например putPixel , framer(900 знак., 03.01.2013 12:16)
- да, HAL оптимизирован на максимальное быстродействие с конкретным драйвером, он не очень удобен (18битный цвет), работа только в окнах, всегда автоинкремент, зато получаю гарантию качества на небольших партиях. там правда еще мусор от ST-шной GUI, AVF(367 знак., 03.01.2013 13:18)
- Эмулятор типа того. Бинарник в Debug. Проект подготовлен для MinGW. Что изменил. Из lcdHAL.c сделал 3 файла guiCore.c и реализация HAL для форточек win_lcdHAL и для реального устройства real_lcdHAL (не проверял нет платформы). В guiCore.c вынес framer(613 знак., 04.01.2013 00:20, ссылка)
- мысль понял, но по моему надо сделать немного по другому (вложено). тоже разделил - вариант неокончательный, с цветами криво получается, не пойму куда их лучше засунуть - в HAL или в драйвер. AVF(201 знак., 04.01.2013 09:29)
- хотя цвета тоже надо на нижний уровень убирать, т.к. он может быть от 8 до 24 бит - AVF(04.01.2013 09:37)
- мысль понял, но по моему надо сделать немного по другому (вложено). тоже разделил - вариант неокончательный, с цветами криво получается, не пойму куда их лучше засунуть - в HAL или в драйвер. AVF(201 знак., 04.01.2013 09:29)
- Эмулятор типа того. Бинарник в Debug. Проект подготовлен для MinGW. Что изменил. Из lcdHAL.c сделал 3 файла guiCore.c и реализация HAL для форточек win_lcdHAL и для реального устройства real_lcdHAL (не проверял нет платформы). В guiCore.c вынес framer(613 знак., 04.01.2013 00:20, ссылка)
- да, HAL оптимизирован на максимальное быстродействие с конкретным драйвером, он не очень удобен (18битный цвет), работа только в окнах, всегда автоинкремент, зато получаю гарантию качества на небольших партиях. там правда еще мусор от ST-шной GUI, AVF(367 знак., 03.01.2013 13:18)
- Для таких проектов хорошо бы иметь svn на сервере, не так ли, Генерал? - Vladimir Ljaschko(03.01.2013 08:41)
- Так а в чем проблема осилить githab или google code? Вероятность того, что там кто-то присоединиться к проекту в разы выше чем если разместить проект на сахаре - Alex B.(03.01.2013 11:55)
- что лучше github или google code? - AVF(03.01.2013 13:34)
- github моднее - Alex B.(03.01.2013 14:04)
- осваиваю. завтра выложу там - AVF(03.01.2013 15:45)
- github моднее - Alex B.(03.01.2013 14:04)
- Может быть, но я сужу по себе - когда нужны были подобные зачатки GUI, то там не рылся, а будь подобный проект на сахаре, кто знает. - Vladimir Ljaschko(03.01.2013 12:30)
- что лучше github или google code? - AVF(03.01.2013 13:34)
- Вроде об этом уже гутарили, но Генерал пошлет в известные места ;) - Make_Pic(03.01.2013 09:51)
- Для работы всё что угодно - General(03.01.2013 15:27)
- Я бы съехал репозиторием левых проектов на сахару, будь svn + файловый доступ + чесслово не грохнуть без предупреждения за месяц. - Vladimir Ljaschko(03.01.2013 16:56)
- Ну, потроллить то можно? А то сахара сразу позиционируется как клуб для болтовни, а не настоящий форум настоящих разработчиков ;) - Vladimir Ljaschko(03.01.2013 10:00)
- Для работы всё что угодно - General(03.01.2013 15:27)
- Так а в чем проблема осилить githab или google code? Вероятность того, что там кто-то присоединиться к проекту в разы выше чем если разместить проект на сахаре - Alex B.(03.01.2013 11:55)
- Спасибо, наверняка понадобится. - Kit(03.01.2013 02:01)
- OK Thanks - Make_Pic(03.01.2013 00:58)
- Тоже похожим надо заниматься. Первые впечатления. По моему HAL немного должен быть по другому. HAL - ничего не должен знать о рисовании линий, знаков кругов итд. HAL - должен обслужить железо и иметь узкий интерфейс для GUI например putPixel , framer(900 знак., 03.01.2013 12:16)