Вход Наше всё Теги codebook 无线电组件 Поиск Опросы Закон Среда
25 июня

О смысле всего сущего 0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынок Объявления

Микроконтроллеры PLD, FPGA, DSP AVR PIC ARM, RISC-V Технологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты

Средства и методы разработки

378305 Топик полностью

Kota (02.01.2013 20:12, просмотров: 279) ответил Make_Pic на Хмм, если не жалко - выложи.

Присодиняюсь

Ответить

- в общем пока выкладываю как есть, "непричесаный" вариант. конструктивная критика приветствуется AVF(02.01.2013 21:20)
  - Тоже похожим надо заниматься. Первые впечатления. По моему 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)
        
        да с цветами там тоже не понятно. разрядность неодинаковая как бы. Может сразу предвидеть полный цвет на основании uint32 во всех основных функциях а не выводить по два uint16. А HAL себе как надо переделает. framer(04.01.2013 10:13 - 10:18)
        
        если 32 бита засада будет с размером bmp. если конвертировать на лету - тормозить будет. наверное цвет пока так оставлю, только уберу в драйвер - AVF(04.01.2013 15:12)
  - Для таких проектов хорошо бы иметь 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)
      - Может быть, но я сужу по себе - когда нужны были подобные зачатки GUI, то там не рылся, а будь подобный проект на сахаре, кто знает. - Vladimir Ljaschko(03.01.2013 12:30)
        
        То есть на сахаре достаточно страницы со ссылками на проекты участников, размещенные на github, sourceforge, etc. - SciFi(03.01.2013 13:18)
    - Вроде об этом уже гутарили, но Генерал пошлет в известные места ;) - Make_Pic(03.01.2013 09:51)
      - Для работы всё что угодно - General(03.01.2013 15:27)
        
        Я бы съехал репозиторием левых проектов на сахару, будь svn + файловый доступ + чесслово не грохнуть без предупреждения за месяц. - Vladimir Ljaschko(03.01.2013 16:56)
        
        Есть удобная assembla и другие, зачем лишние сущности городить. Надежность специализированных сервисов все же повыше будет. А вот мысль насчет возможности хранилища ссылок на сторонние репозитории с комментами имхо интересна. - Andreas(03.01.2013 21:19)
      - Ну, потроллить то можно? А то сахара сразу позиционируется как клуб для болтовни, а не настоящий форум настоящих разработчиков ;) - Vladimir Ljaschko(03.01.2013 10:00)
  - Спасибо, наверняка понадобится. - Kit(03.01.2013 02:01)
  - OK Thanks - Make_Pic(03.01.2013 00:58)