Интересува ме каква е най-популярната организация на графичните LCD дисплеи? Искам да си направя библиотеката, която ще генерира изображението, да го прави в най-популярния формат, а после ако попадна на дисплей с друга организация - тогава да правя конвертиране...

Кой от показаните варианти е най-често срещан?

Доколкото се подразбира от въпроса става дума за малки екранчета с 1bpp...
Подробностите зависят както от конкретния контролер на дисплея, така и от проца дето ще го клати. Тоя сорт дисплейни контролери обикновено могат да флипват изображението по X и/или Y, така че ориентацията не е толкова важна. По-важни са командите с които му адресираш вътрешната му памет, защото не всички позволяват писане от произволно място и посока.
От друга страна пък ако ги клатиш по сериен интерфейс, често изискват 9-бит от които 8 са пиксели, ама ако ползваш DMA а и да не ползваш пак не винаги е удачно да вмъкваш допълнителен бит/байт. Така че може да се наложи твоят буфер да не точно както дисплейния. И още нещо за серийните, имай предвид че някои тъпанари не поддържат 9-бит SPI, не е зле да го провериш
И още нещо, което пак зависи от проца... Освен ако не е нещо допотопно 8-бит, то практически нямаш нужда да буферираш цял екран. Още повече, че не е нужно да опресняваш винаги целия екран. GUI-то обикновено следи обектите на екрана и техния Z-order. Когато нещо мръдне, само определяш каква е минималната област дето трябва да опреснеш. След това опресняването в зависимост от вида на дисплея може да цикли по редове или колони, т.е. колкото е един минимален трансфер. И за всели трансфер викаш засегнатите обекти да се изчертаят. Може да имаш две буферчета, така че докато пращаш единия, рендваш другия и така... Самото рендване също може да се портва според дисплея, така че да е оптимално.

Да - тези дисплеи са 1 bpp. Искам да си направя универсално рендване (независимо от дисплея и ориентацията), а когато изпращам данните към дисплея в единия случай (ориентацията ми съвпада с тази на вътрешния буфер на дисплея) да не конвертирам, а в другия случай да конвертирам. Тъпо ще е да си измисля някакъв мой формат и после винаги да правя някакви пренареждания!

И аз предпочитам с дисплея да се работи по SPI защото може да се ползва DMA в тоя случай, но не всички го имат...

това са вариантите
Срещат се по равно.
Има фри софтуерчета които правят това което искаш + font генератор. Например
- GUI на freescale
- lcd-image-converter (https://sourceforge.net/projects/lcd-image-converter/)
- notepad ++ е велика програма за работа с колони в текстови файлове - лесно си правиш таблици ако е необходимо корекция

Дано труда си заслужава защото монохромните дисплей са в края на дните си...... при цветните е ясно и просто

Няма такова животно...



Виж сега, ти като направиш някакво "универсално" рендване, то ще си е в някакъв формат (бил той твой или мой, тъп или умен). И после естествено ще е тъпо да правиш конверсия...

Направи си дисплейния контролер като класче с методчета за рендване на основни неща като draw_hline() draw_vline(), draw_text()... изобщо там каквито примитиви смяташ за нужни.
При включване на захранването си правиш детекция да видиш какъв екран са ти шибнали, създаваш съответното класче е това е...

Като бонус, няма да имаш никакви конверсии. Освен това рендването винаги ще ти е оптимално. Примерно чертаенето на линия ако съвпада се наредбата на дисплея, ще го правиш на ниво байтове. Демек при един дисплей ще е по един начин, при друг - по друг начин.

Щом е така - няма какво толкова да го умувам - ще го направя според първия дисплей който си поръчам за разработката.

Благодаря!

Още един въпрос - има ли някакъв друг формат, който трябва да предвидя?

Има безброй други формати. Дори мижавото дисплейче на поялника ми може да се конфигурира по няколко начина как да мапва екрана. В тоя смисъл точно за тоя тип дисплеи е много трудно да направиш нещо универсално. По-скоро си направи "модел" на функциите, които въпросната библиотека ще има, и от там надолу "драйвери" за всеки дисплей. Аз обикновено си правя RAM буфер на дисплея както ми е удобно, и после конвертирам при пращането. Обикновено овърхеда за изпращаето на RAM буфера към дисплея не е нещо велико. Най-често се налага просто да го пратиш на части, а дори да се наложи да конвертираш, конверсията е проста и рядко изисква велики ресурси на средномощен по днешните стандарти MCU. Друг е въпроса ако искаш да ползваш дребни и слаби 8 битови въшки, но пък за там универалните решения обикновено са свързани с доста компромиси или откъм функции, или откъм изпозвани ресурси в и без това оскъдните наличности.

За сега мисля да си направя буфера да е организиран по вариант 3 - тоест байтовете да са за вертикални ивици от по 8 пиксела като най-горния пиксел да съответства на бит 0. Ще си направя нещо като драйвер (макар и да нямам операционна система) специфичен за всеки вид дисплей, който ако се налага ще пренарежда битовете по време на опресняването на екрана. Разбира се ако контролера на дисплея го позволява ще пращам само зоната в която има промени. Ако не - всичко. Процесора ми ще е Cortex-М0 на колкото мегахерца успее да насмогне със задачките с които ще го натоваря...

Може да видиш нашия код (има линк в проекти и споделяне)...

Поддържаме EM6125, SPFD5414, ST7565, ST7735R... абе доста и са различни, т.е. може да сравняваш инициализации, рендване и т.н.

май не разбирате въпроса на DanielDimov
Това което предлагате с драйверите няма нищо общо с въпроса на питащия.

Той пита как да генерира таблиците с картинките (защото едва ли ще декодира jpg за да го пусне на монохрмен дисплей

DanielDimov още нещо трябва да предвидиш - монохрмоните дисплей обикновено имат команда да обръщат огледално образа но за разлика от цветните не винаги могат да го въртят на 90 градуса. Т.е. трябва да направиш от твоите 4 варианта още 8 ако искаш да завъртиш дисплея под 90 градуса.

Миро, вашите драйвери с какъв формат на данните във фреймбуфера работят - фиксиран или може да им се задава какъв е?

За въртенето - аз ще въртя на 90 градуса софтуерно така че това дали самия дисплей го поддържа няма да ме интересува. Най-важното ми е дисплея да поддържа SPI интерфейс първо за да не са необходими много пинове и второ за да мога да му пращам пакети данни с DMA!

Даниеле, нямам идея какво и как ще го правиш, затова ми е малко зор да давам акъли...

Но по принцип не е добре да правиш видим буфера видим нагоре към GUI-то. Казах ти, правиш си няколко функции за основните рендер примитиви - чертане на линии, текст и т.н.
Иначе казано за теб дисплея трябва да е нещо с определени размери и върху което може да чертаеш разни неща. Толкоз! Никакви буфери!
А вече на ниско ниво (да го наречем драйвер) работиш с точно определен дисплеен контролер, на който естествено си знаеш каква е организацията и какъв буфер ти трябва. Съответно си правиш рендването точно каквото ти трябва. Какви са тия въртения и глупости? Няма такива неща...
Примерно ако имаш два типа дисплеи - един нормален и един завъртян на 90 градуса, ще имаш два "драйвера" които като код много ще си приличат. Даже може и да не забележиш разликите, обаче ако се вгледаш в кода ще видиш че функцията за чертане хоризонтална линия на единия изглежда точно като функцията за чертане на вертикална линия на другия. При рендване на текст/каартинки е малко по-различно, но не е нещо фрапантно.
Просто винаги рендваш с функциите на конкретния дисплеи и те винаги ще правят каквото трябва по оптималния начин. И няма да се налага да правиш нито въртележки, нито конверсии след тях...

И другото дето ти казах - няма нужда да хабиш памет за цял екран. Още повече че на М0-та едва ли имаш излишна памет. Два реда (колони) са напълно достатъчни, даже и един става. Стига да не правиш големи простотии, рендването в общия случай е в пъти по-бързо от пращането. Аз на времето се притеснявах, даже и затова част от рендванията са ми на асемблер, но това се оказа грешка. Не се притеснявай, скоростта ти е ограничена единствено от SPI-а. И пак да повторя предупреждението за някои като STM32- НЕ поддържат 9-бит (с излючение на F3 май). Все пак може да го симулираш през USART стига да ти паснат пиновете. То май не всички дисплейчета искаха 9-бит, обаче ти препоръчвам да го предвидиш, щото дисплеите се сменят като политиците ни...

Аз и незнам останаха ли приложения, дето хем ще ти трябва диспей хем няма да ти трябва OS, USB и TCP/IP стекове.
Линукс.

да разбира се че останаха - медицински апарати в частност електрохирургия. Това се занимавам аз, други ще споделят за тяхната област.
Дисплеите са цветни но за ОС забрави, няма как да бъде сертифицирано....