Jump to content

    

__inline__

Участник
  • Content Count

    731
  • Joined

  • Last visited

Posts posted by __inline__


  1. 14 minutes ago, jcxz said:

    А разве такие когда-либо были в природе?

    Были, есть: OMAPL137BPTPH на 300+300 МГц (DSP + ARM)

    даташит omap137-ht.pdf, страница 201:

     

    omap.thumb.jpg.865c7fdc05563a3ff7efb97c705b821b.jpg

     

     

    6 minutes ago, _4afc_ said:

    У меня есть 16 штук модулей SOMOMAPL138-10-1602QHIR  в Питере, если что...

     

     Написал в личку.

     

    3 hours ago, HardEgor said:

    Их сняли с производства.

     

    Почему сняли? На сайте TI статус "active" (зелёный) : http://www.ti.com/product/OMAPL137-HT

  2. Мда...  А без этой бредятины OPMAP-L137 в QFP невозможно приобрести?   В BGA оно как-то не очень.

     

    Так. Теперь всё ясно. Открою секрет: остатки со складов не попадают под санкции ))) если на территории РФ.  Но это может для очень мелких и не очень знаменитых контор.  С Компелом и Электронщиком такое не прокатит.

  3. 29 minutes ago, mantech said:

    Вот почему я и писал про МК с нормальным, т.е. встроенным видеоконтроллером, в котором таких проблем нет в принципе, частоту клока для панели ставите какую угодно, а обновляете фреймбуфер с той частотой, которую надо, т.е. 60 Гц.

     

    Можно подумать, что МК со встроенным микроконтроллером устранит оптические недостатки матрицы LCD :)

     

    Тему закрываю по причинам:  флуд, недостаточная компетенция участников форума,  вопрос решён.

  4. 1 hour ago, murmur said:

    Хочется, знаете ли, цифровым способом регулировать.

     

    Мне тоже очень хочется многое. Только в отличие от вас, я не терроризирую форумчан дурацкими вопросами, а читаю соответствующую литературу.:big_boss:

    Здесь за вас никто не будет делать вашу работу. Берите в зубы буквари и статьи из интернета, даташиты микросхем, каталоги магазинов - и вперёд! :dirol:

     

  5. 3 hours ago, DASM said:

     

    " все дисплеи с белой пластмассовой каёмкой " пля, вы о чем вообще??? вы напокупали дисплейчиков по 5 баксов и всем тут льете, что они гавно? Какое совпадение. А может вы вообще просто хотите втюхивать свою балалайку за деньги? Вы не совета пришли просить, а полить все гавном, и ничего вам никто не скажет.  Совсем нормальные дисплеи с фуллхд и выше - все на MIPS DSI ,  и ваш древний говнодсп не потянет даже иконку батареи рисовать. Печально, вначале вы оказались интересным собеседником, но свалились в топики "пипл гляньте какую я гравицапу забабахал"

    Хорош порожняк гнать в тему!

     

    2 hours ago, mantech said:

     почему нельзя сделать постоянный FPS 120? 

    Потому что программа разрабатывалась под ПК где монитор 60 Гц.   При 120 FPS всё идёт быстро в 2 раза )))

  6. 14 hours ago, DASM said:

    вы рассазываете плный бред. Не надо гавно из арудин путать с качетвенными IPS/ и Или не выпускает панелей, они только делают чипы.

     

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

     

    Quote

    Вот в этом девайсе за 50 баксов отличный IPS экран,, проц не помню точно, но эмуляторы не тормозят ни сеги, ни денди, ни какие, их там много, не особо разбираюсь. И как-то они не кричали, что LCD  - гавно. Еще танцора того самого стоит вспомнить

     

    Это говно. Держал такой в руках,  в динамике картинки с артефактами.

     

    14 hours ago, Oymyacon said:

    Ну да, больше похоже на то, что человеку заняться больше не чем.

     

    Мне вот как раз есть чем заниматься. А вам с DASM'ом похоже, что нет. ))

     

    14 hours ago, mantech said:

    Че-т это больше похоже на крики олдфага:biggrin:  На смартфонах эти спрайтики прекрасно отрисовываются, бегают и прыгают, да и качество там 24 бита, а то, что используете допотопный параллельный интерфейс, вместо нормальных контроллеров с встроенной графикой - так может в этом дело?...

     

    И как интерфейс подключения влияет на качество картинки матрицы LCD? Бред написали.

     

    Провели эксперимент.  Показали движущиеся картинки с дисплея приставки SEGA MD Portable нескольким людям.  Всех всё устроило, а меня нет. Из замеченных мною недостатков были:

     

    1)  малые углы обзора

    2) белёсость чёрного

    3) смазывание пикселов на мозаичных(шахматных) элементах

    4) ненасыщенные цвета

    5) "золотой" оттенок изображения

    6) Полоски при движении

     

    Лишь только пару человек смог убедить в половине недостатков, остальным всё идёт.  Так что если быдло хавает дерьмо, почему я должен согласиться с тем что дисплеи IPS хороши?  Кота в мешке не собираюсь покупать. Всегда смотрю дисплеи в действии на телефонах - если устраивает - выковыриваю. И кстати, дисплей тоже с контроллером Ilitek !!! (надо же! и тут совпадение! )))  все дисплеи с белой пластмассовой каёмкой и удобопаяемым гибким шлейфом вместо разъёма - Г О В Н О  ! ! !

     

    Quote

    вместо нормальных контроллеров с встроенной графикой - так может в этом дело?...

     

    Что такое "нормальные контроллеры" ? Дайте определение. Есть ли такой инженерный термин вообще?  Есть параллельная шина, допускающая подключение дисплеев по ней. Особенно когда есть DMA и сопроцессоры.

     

    14 hours ago, Oymyacon said:

    Что у вас записано, меня не волнует. Оговорки тут не запрещено исправлять. А вот троллить и флудить - не рнкомендуется.

     

    Совершенно верно.   На повестку дня выношу затерянный в дебрях флуда актуальный вопрос:

     

    Quote

    Есть ли какой-нибудь способ сделать интервал процессинга программы равным 60 FPS (интервал 16,667 мс) при условии, что частота смены кадров 90 FPS (11,111 мс), при этом кадр отрисовывать с учётом ожидания по VSYNC ?   Я делал замером времени с помощью счётчика тактов CPU, да - в итоге процессинг был на 60 FPS, но изображение подёргивалось, так как 1 VSYNC пропускался.  Или второй вариант - когда ждал принудительно VSYNC, но FPS упал до 45 , так как 45 = 90 /2 .

     

    В итоге, пришлось повысить частоту смены кадров в 2 раза:  120 FPS, а процессинг программы - 60 FPS - это просто надо ждать 2 VSYNC'а.  При таком раскладе - картинка движется гладко и не дёргается и с частотой 60 FPS, хотя дисплей на 120.  Так как на 60 дисплей мерцает :)  Тоесть нашёл решение сделать процессинг 60 FPS при условии что дисплей имеет частоту обновления в целое число раз больше процессинга.    А вот как быть с дробными соотношениями?  Когда процессинг требует 60 кадров в секунду,  а дисплей предположим:  90 или 100 ? :)  При условии, что кадр должен рисоваться с VSYNC?

     

  7. 8 hours ago, murmur said:

    На всякий случай хочу поинтересоваться - там нет регулировочного входа, но неинвертирующий вход выведен наружу и подключен к bypass. Его ведь можно отсоединить от bypass, тупо подключить ко второму каналу ЦАП и заиметь счастье?

     

     

    Это как-то не стыкуется с вашим утверждением в первом посте:

     

    Quote

    3. Можно один канал.

     

    Зачем так извращенствовать?  Выход ЦАП через разделительный конденсатор 0,01 - 1 мкФ (неполярный) на вход этого УНЧ.  Нужна регулировочная громкость? - поставьте переменный резистор вместо Rf=20 кОм на схеме - через ОС будете управлять громкостью.  Делал так в своих поделках, отлично работает.

     

    Кстати.  Может будет интересно в плане схемотехники и позаимствования сорцов декодеров звука и вывод на ЦАП STM32. Мой проект nanoPlayer с открытыми исходниками:

     

    https://vrtp.ru/index.php?showtopic=29688

     

    Если что, печатные платы от него у меня ещё есть - для самостоятельной сборки. Пишите в личку.  Будет и видео и звук. ))

     

    image.jpeg.42662665bf4714413303649715aebcae.jpeg

     

    Схема:

     

     https://vrtp.ru/index.php?act=Attach&type=post&id=772221

     

    В действии:

     

     

  8. 15 minutes ago, Oymyacon said:

    А где Вы их покупаете? Разве их кто-то производит?

     

    У меня интересы чисто хоббийные: найти телек на местной барахолке не составляет никаких проблем - было бы желание! Это в назидание страждущим, кто думает что ЭЛТ умерли.  Не дождутся! ))

     

    Вот совсем недавно зарелизил игровую консоль BlackPrism Portable:

     

     

     

    Дисплей LCD в ней от телефона LG GX 500.  Смотрится красночно и ярко.  Не то что илитековские матрицы с которыми приходилось иметь дело:

     

     

     

    Дисплей поддерживает до 128 Гц кадровой развёртки и  возможно переключение между фреймовой инверсией и строчной.   Поставил первую, чтобы картинка была хорошей.

     

     

    Ну и отзыв ещё одного человека, кто подключил этот дисплей:

     

    http://arduino.ru/forum/apparatnye-voprosy/arduino-i-displei-ot-sotikov-mobilnykh-telefonov?page=53#comment-495611

     

    Это как раз тот случай, когда качество картинки меня удовлетворяет.  А полосы убираются удвоением частоты развёртки + включением фреймовой инверсии вместо строчной.

     

     

    Сейчас продумываю концепт десктопной версии - BlackPrism DeskTop.   И там будет видеовыход на ТВ.

     

  9. 12 minutes ago, HardEgor said:

    Я вам по секрету скажу - Ilitek выпускает чипы. А качество зависит от LCD-матрицы.

     

    Знаю. Но проследил такую закономерность: если чип от Ilitek, значит матрица - говно. Потому что китайцы. А они очень любят Ilitek ))

     

    Quote

    А что у ЭЛТ обратный ход луча уже отменили?

     

    С чего это вдруг? Активно используем для получения гладкого движения изображений!

     

    Что касается IPS, то :

    Quote

    Большое время отклика. В данном случае проблема полностью в подсветке: её светодиоды просто не успевают быстро срабатывать.

     

    На этом можно поставить крест: для моих целей не годится. Только для вывода статичных голых баб, как подметил DASM :)

  10. 7 minutes ago, DASM said:

    у них перемычками задается или как память работают, или таким вот макаром.

     

    Глянул дисплеи по приведенным вами ссылкам - они все на базе Ilitek'овского контроллера, а это - говно по определению.  Я уже вдоволь нажрался илитековского говна в ардуино-шилд-дисплеях:  не устроило качество картинки - под разными углами плохо показывает,  цвета белёсые, уровень чёрного хреновый и - те же полоски что в начале темы.   Дисплей от GX500  который использую намного лучше вышеозначенных.     Илитеком недоволен в плане оптики - качество изображения годится разве что для индикации в технических приборах.   Смотреть видео или играть в игры на таких дисплеях я бы не хотел и другим не рекомендую.

    Статья про IPS и AMOLED. https://www.iphones.ru/iNotes/amoled-protiv-ips-v-kraskah-primerah-i-testah-05-26-2019

     

    Quote

    у IPS достаточно много теоретических и фактических недостатков:

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

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

    Большое время отклика. В данном случае проблема полностью в подсветке: её светодиоды просто не успевают быстро срабатывать.

     

    В общем, дерьмо эти IPS....   ЭЛТ лучше будет!

  11. 4 minutes ago, DASM said:

    тот, что с бабой я подключаю по VSYNC HSYNC DPI интерфейсу, 60 кадров и есть.  AM3352 выводит (был STM32H7 ногодрыгом, но ногодрыг это 15 фпс всего на таком разрешении)

     

    Мне бы что-нибудь с шиной 8 или 16 бит как интерфейс SRAM

     

     

    P.S.   Проблему решил: оставил развёртку 120 Гц  + 2 VSYNC для процессинга 60 FPS.   Всё работает ниче не мерцает полоски ушли.  Я доволен, но пришлось немного попотеть  )))

  12. 4 minutes ago, DASM said:

    а разве нужно что либо еще, если есть голые бабы? ))

     

    Пирамида Маслоу... Жажда к творчеству.  Бабы её не заменяют. )))

     

     

    2 minutes ago, DASM said:

    что ему помешает?

     

    Ничто не помешает. Вылезет какой-нить артефакт типа смазывания картинки при движении или в полосках всё будет.   Ну и какова скорость обмена данными с таким дисплеем?  Мне надо не ниже 60 кадров в секунду отрисовывать на 400x240, при этом цвет не хуже 16 бит.

  13. 8 minutes ago, Oymyacon said:

    Не понимаю, что там в ЭЛТ осталось такого, ч то было бы лучше, чем у 4К или 5К IPS или OLED.

    Чёткость вообще никакая, тем более в динамике. Трубы были лучше ЖК только в начале века, потом все их прелести сошли на нет.

     

    Вы видать незнакомы с аркадными автоматами начала 80-хх - конца  90-х ))).   320x240 там не нужна чёткость, наоборот, небольшое размытие там даже на руку ибо квадраты не видны.

     

     

    3 minutes ago, DASM said:

    я их тоже штук десять взял уже. Все IPS. Могу посоветовать и попроще, чем вышеприведенный. Это смартфоновские практически экраны, все хоршо будет  с ними

     

    Сомневаюсь, что вы их взяли чтобы спрайты гонять. )))  На просмотре видео эффект не будет себя проявлять.  Только если будет скролл картинки по горизонтали

  14. 56 minutes ago, DASM said:

    Ставьте нормальный IPS и будет все хорошо 

     

     Ещё бы знать какой IPS окажется нормальным :)   Много дисплеев разных покупал,  оставался доволен только OLED'ами, так как они как-будто созданы для 2D-анимации.  Мне нужно, чтобы нарисованные на дисплее спрайты двигались плавно на +1 пиксел за 1 VSYNC.   При этом если спрайт начинает:  шлейфить, мазать, кривиться или мерцать вертикальными полосками (как в сообщении в шапке темы), то дисплей объявляю неподходящим для моих целей.

     

    А голых баб статичных выводить может каждый LCD, другое дело, что будет с картинкой, если её начать плавно крутить по горизонтали на +1 пиксел за 1 рефреш дисплея?

  15. Потестировал этот GCC, получил листинг.  Параллельность есть, но она слабенькая в отличие от TI CC.

    Команда:

    c6x-uclinux-g++ -S  -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -march=c674x -O3 -fomit-frame-pointer -ffast-math -fno-rtti -fno-exceptions -Dc6745 -DNDEBUG -c PPU16.cpp

    Код:

    #include <stdlib.h>
    
    #include "PPU16.h"
    
    #define VRAM_BUFFER 0xC0800000 /* Bank1 SDRAM            */
    
    #define VIDEO_CACHE 0x11800000 /* 240 x 400 pixel buffer */
    
    #define PRUSS_VideoBuffer (*(IO u32*)(PRU1_Data+0x0000))
    
    #define SROM16 (*(u16*)SROMOffset)
    #define VRAM16 (*(u16*)VRAMOffset)
    
    u8 *VRAMBuffer=(u8*)VRAM_BUFFER;
    
    const u8 *SROMBuffer; //SROM Buffer - Pointer
    
    u32 SPRITE_PITCH=2048; //Default Sprite Width: 1024 pixel
    
    #define _amem8(x) (*(x))
    #define _mem8(x) (*(x))
    
    void PPU16_ClearVRAM(u16 Color)
    {
     u64 c=Color|(Color<<16);
     c|=(c<<32);
     u64 * __restrict vb=(u64*)VRAMBuffer;
    // #pragma UNROLL(4)
     for(int i=0;i<(SCREEN_WIDTH*SCREEN_HEIGHT)>>2;i++)_amem8(&vb[i])=c;
    }
    
    void PPU16_OutOLED(void)
    {
     for(int y=0;y<(SCREEN_HEIGHT<<1);y+=8)
     {
      u64 * __restrict vc=(u64*)(VIDEO_CACHE+y);
      u64 * __restrict vb0=(u64*)&VRAMBuffer[((SCREEN_WIDTH-4)<<1)+(SCREEN_WIDTH*y)];
      u64 * __restrict vb1=vb0+(SCREEN_WIDTH>>2);
      u64 * __restrict vb2=vb1+(SCREEN_WIDTH>>2);
      u64 * __restrict vb3=vb2+(SCREEN_WIDTH>>2); 
    
      for(int x=0;x<(SCREEN_WIDTH>>2);x++)
      {
       _amem8(&vc[(3*(SCREEN_HEIGHT>>2))+(SCREEN_HEIGHT*x)])=((u64)((u16) _amem8(&vb0[-x])     ))|((u64)((u16) _amem8(&vb1[-x])     )<<16)|((u64)((u16) _amem8(&vb2[-x])     )<<32)|((u64)((u16) _amem8(&vb3[-x])     )<<48);
       _amem8(&vc[(2*(SCREEN_HEIGHT>>2))+(SCREEN_HEIGHT*x)])=((u64)((u16)(_amem8(&vb0[-x])>>16)))|((u64)((u16)(_amem8(&vb1[-x])>>16))<<16)|((u64)((u16)(_amem8(&vb2[-x])>>16))<<32)|((u64)((u16)(_amem8(&vb3[-x])>>16))<<48);
       _amem8(&vc[(1*(SCREEN_HEIGHT>>2))+(SCREEN_HEIGHT*x)])=((u64)((u16)(_amem8(&vb0[-x])>>32)))|((u64)((u16)(_amem8(&vb1[-x])>>32))<<16)|((u64)((u16)(_amem8(&vb2[-x])>>32))<<32)|((u64)((u16)(_amem8(&vb3[-x])>>32))<<48);
       _amem8(&vc[(0*(SCREEN_HEIGHT>>2))+(SCREEN_HEIGHT*x)])=((u64)((u16)(_amem8(&vb0[-x])>>48)))|((u64)((u16)(_amem8(&vb1[-x])>>48))<<16)|((u64)((u16)(_amem8(&vb2[-x])>>48))<<32)|((u64)((u16)(_amem8(&vb3[-x])>>48))<<48);
      }
     }
    }

     

    Даёт такой листинг:

    Spoiler
    
    	.file	"PPU16.cpp"
    	.c6xabi_attribute Tag_ABI_array_object_alignment, 0
    	.c6xabi_attribute Tag_ABI_array_object_align_expected, 0
    	.c6xabi_attribute Tag_ABI_stack_align_needed, 0
    	.c6xabi_attribute Tag_ABI_stack_align_preserved, 0
    	.c6xabi_attribute Tag_ABI_conformance, "1.0"
    .text;
    	.align	2
    	.global	PPU16_ClearVRAM
    	.type	PPU16_ClearVRAM, @function
    PPU16_ClearVRAM:
    		sub	.d2	B15, 8, B15
    		stw	.d2t2	B14, *+B15(8)
    		ldw	.d2t2	*+B14($DSBT_index(__c6xabi_DSBT_BASE)), B14
    	||	extu	.s1	A4, 16, 16, A6
    		mvk	.s1	24000, A0
    		shl	.s1	A6, 16, A7
    		mvc	.s2x	A0, ILC
    	||	or	.d1	A6, A7, A4
    		shr	.s1	A4, 31, A8
    		ldw	.d2t1	*+B14(VRAMBuffer), A3
    	||	or	.d1	A8, A4, A5
    		nop	4
    		sploop	2
    .L2:
    		stw	.d1t1	A4, *A3
    		stw	.d1t1	A5, *+A3(4)
    	||	add	.s1	8, A3, A3
    		spkernel	1, 0
    		ret	.s2	B3
    	||	ldw	.d2t2	*+B15(8), B14
    	||	add	.l2	8, B15, B15
    		nop	5
    	;; return occurs
    	.size	PPU16_ClearVRAM, .-PPU16_ClearVRAM
    	.align	2
    	.global	PPU16_OutOLED
    	.type	PPU16_OutOLED, @function
    PPU16_OutOLED:
    		sub	.d2	B15, 8, B15
    		stw	.d2t2	B14, *+B15(8)
    		ldw	.d2t2	*+B14($DSBT_index(__c6xabi_DSBT_BASE)), B14
    	||	mvk	.s1	1440, A24
    	||	mvk	.d1	0, A21
    	||	mvk	.l1	0, A26
    		mvk	.s1	960, A23
    		mvk	.s1	480, A22
    		mvklh	.s1	4480, A24
    		mvklh	.s1	4480, A23
    		ldw	.d2t1	*+B14(VRAMBuffer), A25
    	||	mvklh	.s1	4480, A22
    		mvklh	.s1	4480, A21
    		mvk	.s1	60, A2
    		nop	2
    		addk	.s1	792, A25
    .L8:
    		mvk	.s1	800, A7
    	||	sub	.d1	A2, 1, A2
    	||	mv	.l1	A26, A5
    		mvk	.s1	1600, A8
    	||	add	.d1	A25, A7, A4
    	||	mv	.l1	A25, A0
    		mvk	.s1	2400, A9
    	||	add	.d1	A25, A8, A3
    		add	.d1	A25, A9, A6
    	||	mvk	.s1	100, A1
    .L7:
    		ldhu	.d1t1	*A4, A19
    	||	add	.l1	A5, A24, A16
    	||	add	.s1	A5, A23, A27
    		ldhu	.d1t1	*A6, A17
    	||	add	.l1	A5, A22, A28
    	||	add	.s1	-1, A1, A1
    		ldhu	.d1t1	*A3, A18
    	||	add	.l1	A5, A21, A29
    	||	addk	.s1	1920, A5
    		ldhu	.d1t1	*A0, A20
    		nop	1
    		shl	.s1	A19, 16, A30
    		shl	.s1	A17, 16, A7
    		or	.d1	A7, A18, A8
    		or	.s1	A20, A30, A31
    	||	stw	.d1t1	A8, *+A16(4)
    		stw	.d1t1	A31, *A16
    		ldw	.d1t1	*A4, A9
    		ldw	.d1t1	*A3, A20
    		ldw	.d1t1	*A0, A18
    		ldw	.d1t1	*A6, A16
    		nop	1
    		clr	.s1	A9, 0, 15, A19
    		shru	.s1	A20, 16, A17
    		shru	.s1	A18, 16, A30
    		clr	.s1	A16, 0, 15, A7
    	||	or	.d1	A30, A19, A31
    		or	.s1	A7, A17, A8
    	||	stw	.d1t1	A31, *A27
    		stw	.d1t1	A8, *+A27(4)
    		ldhu	.d1t1	*+A4(4), A27
    		ldhu	.d1t1	*+A6(4), A9
    		ldhu	.d1t1	*+A3(4), A20
    		ldhu	.d1t1	*+A0(4), A18
    		nop	1
    		shl	.s1	A27, 16, A16
    		shl	.s1	A9, 16, A17
    		or	.d1	A17, A20, A30
    		or	.s1	A18, A16, A19
    	||	stw	.d1t1	A30, *+A28(4)
    		stw	.d1t1	A19, *A28
    		ldhu	.d1t1	*+A4(6), A28
    	||	add	.s1	-8, A4, A4
    		ldhu	.d1t1	*+A6(6), A8
    	||	add	.s1	-8, A6, A6
    		ldhu	.d1t1	*+A3(6), A31
    	||	add	.s1	-8, A3, A3
    		ldhu	.d1t1	*+A0(6), A7
    	||	add	.s1	-8, A0, A0
    	[A1]	b	.s1	.L7
    		shl	.s1	A28, 16, A27
    		shl	.s1	A8, 16, A18
    		or	.d1	A18, A31, A9
    		stw	.d1t1	A9, *+A29(4)
    	||	or	.s1	A7, A27, A20
    		stw	.d1t1	A20, *A29
    	;; condjump to .L7 occurs
    	[A2]	b	.s1	.L8
    	||	add	.d1	A26, 8, A26
    		addk	.s1	3200, A25
    		nop	4
    	;; condjump to .L8 occurs
    		ret	.s2	B3
    	||	ldw	.d2t2	*+B15(8), B14
    	||	add	.l2	8, B15, B15
    		nop	5
    	;; return occurs
    	.size	PPU16_OutOLED, .-PPU16_OutOLED
    	.global	VRAMBuffer
    	.section	.neardata,"aw",@progbits
    	.align	2
    	.type	VRAMBuffer, @object
    	.size	VRAMBuffer, 4
    VRAMBuffer:
    	.long	-1065353216
    	.global	SROMBuffer
    	.section	.bss,"aw",@nobits
    	.align	2
    	.type	SROMBuffer, @object
    	.size	SROMBuffer, 4
    SROMBuffer:
    	.zero	4
    	.global	SPRITE_PITCH
    	.section	.neardata
    	.align	2
    	.type	SPRITE_PITCH, @object
    	.size	SPRITE_PITCH, 4
    SPRITE_PITCH:
    	.long	2048
    	.ident	"GCC: (Sourcery CodeBench Lite 4.5-124) 4.5.1"

     

     

    Слабовато.   И _mem8, _amem8 не знает, пришлось задефайнить разыменовыванием указателей, что не совсем верно.

  16. 45 minutes ago, mantech said:

    Ну  вот так сразу-то рубить с плеча не надо... ЭЛТ на 50-60 Гц тоже моргали не хило, на даче такой телик еще стоит, так сразу заметно после того, как постоянно ЖК смотрю... На заре ЖК моников эти инверсии не использовались, так после дня статичной картинки можно было наблюдать такой очень заметный эффект "памяти" на панелях, приходилось менять картинку принудительно, или через недельку такой моник в мусорку только... На ЭЛТшках подобное тоже было, только на контрастных картинках.

    Помню, работал на ПК в начале 2000-х, был монитор ЭЛТ ViewSonic G55 с нативным разрешением 800x600 85 Гц. Хороший был монитор! Картинка чёткая, ничего не мерцало.  И самое главное - плавность движения была просто великолепная как на всех ЭЛТ мониторах!  LCD до такого далеко и сейчас.

     

    Что касается ТВ, то их кинескопы моргают ощутимо, если краем глаза смотреть. Стараюсь использовать NTSC вместо PAL где возможно. И там есть такой артефакт: при резких сменах яркости монотонных участков большой площади, происходит  "разбухание" фрагмента изображения - он мог слегка искривлять изображение или выходить за пределы кадра (неравномерность свечения люминофора)

     

    На счёт "эффекта памяти" в LCD в курсе. Был такой дисплей MTF-T022 (контроллер S6D0129)  - он мог отключать все эти инверсии,  картинка была превосходной. Но за это пришлось расплатиться тем, что если картинка оставалась долго неподвижной, то при смене картинки появлялся рельеф от старой и был какое-то время :)   Поэтому  приходится выбирать компромиссы: 

     

    1) либо полоски с низкой частотой обновления

    2) либо отсутствие полосок, но с мерцанием

    3) отсутствие полосок и повышенная частота обновления

    4) отсутствие полосок и эффект памяти (деградация) дисплея

    5) радикальный переход на ЭЛТ

     

    P.S. Ещё не родился на Земле тот глобал, который придумал бы LCD с превосходным качеством анимации картинки с точностью +1 пиксел ))

  17. Статья на русском: http://lcdtech.info/data/lcd.technologies.htm

     

    Quote

    6. Методы инверсии полярности (Polarity-inversion Driving Mode)

    Как уже было сказано, ЖК-ячейки нельзя надого «запирать» постоянным управляющим напряжением. Дело в том, что постоянный электрический потенциал вызывает взаимодействие ионов с материалом электродов, нарушающее упорядоченность расположения молекул ЖК-материала, и приводит к деградации ячейки. В связи с этим используются различные методы чередования знака полярности управляющего напряжения. Наиболее полный перечень методов инверсии приведен здесь www.techmind.org/lcd.

    6.1. Покадровая инверсия полярности

    Изменение полярности всех пикселей при отрисовке каждого кадра является наиболее простым в реализации. Основной недостаток этого метода — изображение начинает мерцать с частотой, равной половине частоты кадровой регенерации. То есть если дисплей отображает видеосигнал с кадровой частотой 60 Гц, то мерцание изображения будет раздражать наблюдателя, так как мерцание на частоте 30 Гц заметно почти каждому человеку. Важно, что если бы не было необходимости менять полярность управляющего напряжения ячеек, то воспроизводимое избражение было бы одинаково стабильно, не зависимо от кадровой частоты входного сигнала. Именно переход управляющего напряжения через «ноль» в противоложный знак и приводит к тому, что пиксель кратковренно изменяет свой цвет.

     

    Короче, делаю вывод, что со времён изобретения электронно-лучевой трубки, ничего лучшего человечество не придумало (для воспроизведения плавнодвижущихся объектов). Все эти LCD - фигня, по сравнению с ЭЛТ.

  18. Интересная статья про LCD на тему:  http://machineryequipmentonline.com/video-equipment/liquid-crystal-display-lcdpolarity-inversion/

    Перевод ключевых моментов:

     

    Quote

    Применение напряжения одинаковой (d.c.) полярности к ЖК-элементу приведет к гальванизации одного электрода, что приведет к так называемому ‘d.c. стресс, вызывающий ухудшение качества изображения. Чтобы предотвратить поляризацию (и быстрое постоянное повреждение) LC-материала, полярность напряжения элемента изменяется на противоположную, процесс, известный как инверсия полярности. Инверсия полярности может быть реализована тремя различными способами: инверсия кадра, линейная (или горизонтальная) инверсия и точечная инверсия (рисунок 11.14). Следует отметить, что инверсия строки включает в себя инверсию кадра, так как положительная линия в одном кадре становится отрицательной в следующем кадре и наоборот.

     

    Quote

    К сожалению, очень трудно получить одинаковое напряжение на элементе в обеих полярностях, поэтому яркость элемента изображения будет мерцать. Это мерцание наиболее заметно при инверсии кадров, в которой полярность всего экрана инвертируется один раз за каждый кадр, что приводит к мерцанию 25 Гц и 30 Гц для PAL и NTSC соответственно. Мерцание может быть уменьшено благодаря наличию полярности соседних линий с использованием инверсии линий, что устраняет мерцание. Лучшие результаты могут быть получены с точечной инверсией. Таким образом, мерцание можно сделать незаметным для большинства «естественных» изображений.

     

    Вот как оказывается! Инверсия кадра приводит мерцанию с частотой в 2 раза ниже частоты обновления.  Проще говоря, 60 кадров в секунду дисплея мерцают с частотой 30 Гц - отсюда противные ощущения при просмотре.   Поэтому только повышать частоту кадров до 120 Гц, чтобы мерцание было на 60 и незаметным.   Так как инверсии точек данный LCD не поддерживает,  а инверсия линий приводит к мерцающим полоскам при движении.   Дисплей снят с мобильника, где была портретная ориентация кадра и в пейзажный режим, да и ещё с плавной анимацией ихображения - не планировался в принципе )))

  19. Спасибо ответившим! :yes:

     

    Есть ли какой-нибудь способ сделать интервал процессинга программы равным 60 FPS (интервал 16,667 мс) при условии, что частота смены кадров 90 FPS (11,111 мс), при этом кадр отрисовывать с учётом ожидания по VSYNC ?   Я делал замером времени с помощью счётчика тактов CPU, да - в итоге процессинг был на 60 FPS, но изображение подёргивалось, так как 1 VSYNC пропускался.  Или второй вариант - когда ждал принудительно VSYNC, но FPS упал до 45 , так как 45 = 90 /2 .

     

    В итоге, пришлось повысить частоту смены кадров в 2 раза:  120 FPS, а процессинг программы - 60 FPS - это просто надо ждать 2 VSYNC'а.  При таком раскладе - картинка движется гладко и не дёргается и с частотой 60 FPS, хотя дисплей на 120.  Так как на 60 дисплей мерцает :)  Тоесть нашёл решение сделать процессинг 60 FPS при условии что дисплей имеет частоту обновления в целое число раз больше процессинга.    А вот как быть с дробными соотношениями?  Когда процессинг требует 60 кадров в секунду,  а дисплей предположим:  90 или 100 ? :)  При условии, что кадр должен рисоваться с VSYNC?

  20. 13 hours ago, GenaSPB said:

    В первом сообщении про мп3 ни слова...

    Цитата из первого сообщения:

    Quote

    Были мысли про МP3 кодеки из серии VS10xx. Но слышала, что там какие-то заморочки с тем, чта за использование MP3 кому-то что-то платить надо.

     

    11 hours ago, murmur said:

    Хорошо. Рассмотрим вопрос с другой стороны. Мне не нужно проигрывать мелодии, звуки будут короткие 1-3 секунды.

     А контроллер - STM32F7. В нем есть свободный ЦАП выход. Так может есть какая-нибудь библиотека которая распаковывает запакованный звук и выдает его на ЦАП.  Имею опыт работы со SPEEX  - но он ужимает с потерей качества. Отсюда 2 вопроса.

    1.Сильно ли загрузит распаковка и воспроизведение звука такой контроллер как STM32F7?

    2. Посоветуйте какое-нибудь софтовое решение.

    2)

    Есть несколько вариантов несложного сжатия:

     

    1) IMA ADPCM - сжатие 4:1 - из двух 16-битных семплов делает 1 байт. На слух даже звучит неплохо

     

    2) 2-битный ADPCM из G.726   (конкретно g726_16) - сжатие 8:1, но уже есть небльшие артефакты в виде легкого шума, но терпимо.

     

    3) кодек CELT с высокой скоростью кодирования-декодирования - сжатие 8:1 - 10:1.  Фрейм распаковывается около 0,6 секунд на 450 МГц (длина распакованного фрейма выставляется, битрейт регулируется, полоса частот тоже).  Версия 9 или 10.  Всё что выше - будет притормаживать из-за Опусных нововведений.   Качество не уступает MP3 на тех же битрейтах и более гибкий в настройках (битрейт, размер фреймов, частота дискретизации).

     

    4) Архиваторы (типа ZLIB)  или RLE-сжатие не рекомендую использовать для сжатия звука без потерь:  в лучшем случае будет сжатие в 1,5 раза, что ни о чём

     

    5) A-law, u-Law - сжатие 2:1, что хуже ADPCM

     

    Со всеми пятью лично игрался,  в сборке очень просты - как детские кубики. Достаточно отрассировать штатный MAKE в команды GCC и сделать порт на любую 32-битную архитектуру.

     

    1)

    Не загрузит практически, если выполнить ряд оптимизаций (в основном это касается кодека CELT в режиме плавающей точке) , для целочисленной реализации ничего оптимизировать не надо.

     

    Дуть можно в штатный 12-битовый ЦАП STM32.   12 бит использовались при проигрывании музыки с CD, меломаны терпели :)

     

    УНЧ можно взять LM4871 - 1 ватт на 8 Ом будет честно выдавать при питании от 3,3 V.   К тому же мостовой, а значит помех он не боится и минимум обвеса - без цепей Цобеля и больших разделительных конденсаторов.  Подключать сразу с выхода ЦАП STM.

     

    Quote

    Так может есть какая-нибудь библиотека которая распаковывает запакованный звук и выдает его на ЦАП.

     

    Нет таких библиотек (читай: готовых решений под ключ). Все библиотеки работают с буферами источника и приёмника - в первый кладём что пожать, со второго берём пожатое. Или наоборот при декодировании.  Дальше решаем сами что делать с данными.

  21. 4 minutes ago, rkit said:

    Аппаратные кодеками называют комбо ацп+цап+усилитель. Декодированием сжатого аудио они не занимаются, и микроконтроллер не разгрузят.

    Звучит обнадёживающе...

    Всегда считал, что аппаратный кодек - это чип, который жмёт при записи и разжимает при воспроизведении. Пусть даже со своим DSP ядром внутри.

    А программный кодек - софт-вариант прошивки в управляющем контроллере, который реализует сжатие-разжатие программно.

    Остальное - просто АЦП и ЦАП, но называть их кодеком - всё-равно что называть ракетой жестянку без реактивного двигателя.