2012-06-30 2 views
1

Мне нужно написать драйвер низкого уровня для управления дисплеем tft для встроенного устройства. Устройство питается от PIC24, 64K RAM и около 128K программной памяти.Запись многоразовой графической библиотеки низкого уровня для emebedded устройства в ansi C

Я намерен написать общую графическую библиотеку, в которой я буду размещать все примитивные графические функции и драйвер для отправки команды и данных для отображения.

Графика lib использует драйвер для доступа к дисплею, но технология отображения может измениться, поэтому драйвер должен быть легко reimplementabile.

Каков наилучший способ написания многоразового кода в этом виде сценария?

-----------------   ---------------  
|     |  |    | 
|     |  |    | 
| GFX_LIB  | =====> | DRIVER  | ====> DISPLAY 
|     |  |    | 
|     |  |    | 
-----------------   -----/----\---- 
           / \ 
          /  \ 
         ---------- ---------- 
         |   | |   | 
         | TYPE A | | TYPE B | 
         |   | |   | 
         ---------- ---------- 

Подробнее

Это кусок кода моего GFX Lib

#include "Graphics.h" 

void gfx_Init(uint16_t width, uint16_t height, uint8_t rotation){ 
    gfx_displayWidth=width; 
    gfx_displayHeight=height; 
    gfx_rotation=rotation; 
    displayDriverInit(); 
} 

void gfx_setPixel(uint16_t x, uint16_t y, uint32_t color){ 
    displayDriverSendCommand(CHANGE_COORDINATE); 
    displayDriverSendData(x); 
    displayDriverSendData(y); 
    displayDriverSendCommand(SET_COLOR); 
    displayDriverSendData(color); 
} 

Это гипотетическая реализация моей графической библиотеки.

Теперь, если я сменю драйвер, я очень рад, если я смогу повторно использовать мою gfx lib и переписать только процедуры отображения драйверов. Какой лучший способ достичь этого?

спасибо.

+1

Что относительно OpenGL? или SDL? – IanNorton

+0

привет, это для встроенного устройства с picmicro – blow

ответ

1

Это зависит от того, какую функциональность предложит ваш драйвер.

Минимальный API может быть объявлен как это:

typedef void* gfx; 
typedef struct init_options { 
    int display_width, display_height; 
    //..etc.. 
}; 

gfx* gfx_init(init_options* opts); 
void gfx_free(gfx* gfx); 

// blit something onto sceeen 
void gfx_blit(gfx* gfx, void* buffer, int buf_w, int buf_h, int trg_x, int trg_y, int trg_w, int trg_h); 

// if you have double buffering (probably a good idea) 
void gfx_swap(gfx* gfx); 

инициализация, выключение, режим переключение и блиттинг пикселей на экране может быть все, что вам нужно. Возможно, вам также следует предоставить быструю процедуру SetPixel(). Все остальное может быть реализовано в какой-то библиотеке «GfxUtil», основанной на этом.

Выбор драйвера и реализация этого API могут быть обработаны путем простой ссылки на нужную библиотеку (где каждая библиотека содержит фактический драйвер, содержащий фактический код для blitting и т. Д.).

EDIT

Чтобы иметь некоторый динамически сменный код, драйвер может быть структурой с функциональными указателями на фактическую реализацию драйвера конкретного кода:

// common driver struct, used by gfx api 
typedef struct driver { 
    void (*init)(driver *driver, init_options*); 
    void (*setpixel)(driver *driver, int x, int y, color color); 
    //... 
}; 

// driver constructor 
driver* create_foo_driver() { 
    driver* d = malloc(sizeof(driver)); 
    memset(d,0,sizeof(driver)); 
    d->init = foo_init; 
    d->setpixel = foo_setpixel; 
    return d; 
} 

// some driver-specific code ... 
void foo_setpixel(driver *driver, int x, int y, color color) { 
    // actual implementation 
} 

// API code calling driver code 
void gfx_setpixel(gfx* gfx, int x, int y, color color) { 
    driver* driver = ((gfx_impl)gfx)->driver; // .. just an example 
    driver->setpixel(driver, x, y, color); 
} 
+0

Да! да, это очень похоже на мою gfx lib, теперь возникает вопрос: какой лучший способ ввести мой tft-драйвер для отправки команды и данных для отображения и оставить открытой возможность того, что технология отображения может измениться, и мне нужно переопределить драйвер? Мне не нужно (и не хочу) переопределять всю библиотеку gfx для каждого используемого вами дисплея. – blow

+0

@ blow: укажите более подробную информацию: – Frunsi

+0

ok wait a moment – blow

0

В зависимости от того, сколько памяти вы можете зарезервировать на своей платформе, вы можете использовать Cairo, который структурирован так же, как вы нарисовали в своем ASCII-искусстве. Он также реализован в C.

+0

привет, у меня всего 64k RAM и около 128k программной памяти, поэтому я могу написать простой драйвер для примитивной графической функции. – blow

+0

вы должны добавить эту информацию на свой вопрос, низкая спецификация, низкоуровневая графика - это отличный чайник рыбы – IanNorton

+0

хорошо, спасибо! – blow

1

Зачем изобретать велосипед? Используйте GD Graphics Library для создания изображения в буфере изображения дисплея. Или создайте изображение за пределами буфера изображения дисплея, а затем скопируйте данные пикселя после того, как вы закончите рендеринг.

Обратите внимание, что GD обычно используется для создания файлов изображений (которые затем загружаются браузером), но код рендеринга является независимым.

+0

привет, мне это не нужно. Благодарю. – blow

+0

Откуда вы знаете? –

+0

Мне нужно что-то вроде класса графики java, но для встроенного устройства с плохим исполнением. И я знаю, что горячий, чтобы написать мою примитивную функцию gfx, мне нужен только совет, как построить все для повторного использования ... Я новичок в C. – blow

0

Любой погуглить свой путь здесь следует обратить внимание на Adafruit's GFX library, а затем посмотреть, как их библиотеки используют для конкретных графических драйверов. Мой опыт связан с их ST7735 driver (который я портировал для работы на chipKIT's PIC32 и теперь получаю помощь от опытных разработчиков chipKIT). Идеальный пример графической среды C++/OOP, которую могут реализовать драйверы для конкретного оборудования.

Я удивлен, что этот вопрос не был закрыт для того, чтобы быть вне темы, как и любой другой вопрос «как я могу это сделать» в последнее время.