Easyelectronics.ru

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

есть экран zx spectrum, по горизонтали он состоит из 3х областей:
1. информация о графической части изображения, фактически о пикселах (побитно в байте, горизонтально, 1 - вывести цвет пиксела, 0 - вывести цвет фона)
2. информация о цветах пикселов\фона для каждого байта графики, то есть по горизонтали на 8 точек байта графики один байт цвета
3. по бокам идет бордер, одноцветный, без графики

задумался я сделать генерацию видео сигнала на stm32f4

первая мысля:

частота 112 мгц (иначе не попадает spi в 7 мгц)

запускаем таймер, скорее всего Timer_2
делитель 7168-1, частота такта 7 мгц, пересчет 448-1 значений
это как раз стандартная строка в такте zx spectrum
в эту строку нужно передать изображение с цветом и синхронизацию с бордером

сначала выводим изображение с цветом, для этого запускается оба DMA
1. вывод информации о цвете, для этого по TIMER1 - DMA2 -GPIO(8 бит) - выводим атрибуты (делитель 12*8, частота такта 0,875 мгц, пересчет 32-1 значение, остановка по завершению)
2. вывод информации о пикселах, тут вижу 2 варианта:
а) DMA1 - SPI2 ( делитель 4, частота 7 мгц, по 16 бит) -32 байта (16 слов), запрос в DMA1 от SPI2
б) TIMER_3 - DMA1 - SPI2 - запрос в DMA1 от TIMER_3, остановка по завершению передачи 1 лишнего байта (32+1 байта)

после 256 тактов (как раз будут выведены 32 байта цвета на 256 бит изображения) строки

потом сразу идет вывод бордера и синхронизации
для этого думаю использовать TIMER_1 (или TIMER_8) - DMA2 - GPIO, делитель 7168-1, частота такта 7 мгц, пересчет 192 значения (+8, см ниже)
биты примерно так распределить:
0 - бит синхронизации (при лог.0 - уровень синхронизации видеосигнала)
1 - бит вывода бордера (сам цвет бордера браться будет с другого порта: 3 бита цвета)
2 - бит вывода изображения (для первого этапа - вывода изображения)

в DMA2 подсовываем 192 байта где будут идти необходимые уровни

все сигналы с портов:
- цвет бордера
- цвет пиксела\фона
- бит бордера
- бит изображения
внешней схемой приводятся к единым SYNC + RGB - в принципе схема аналогична тому же Ленинграду\Пентагону - 2 шт кп11, да немного логики.

Вот такая вот идея...

дальше начинаются вопросы:
1. по настройкам TIMERов вижу, что есть сигнал TRIG, по которому можно запустить TIMER3 и TIMER1 для генерации изображения
я понял что сигнал TRIG только один у счетчика, как его сформировать для второго счетчика я пока не понимаю

есть мысль, но не знаю работает ли так логика, у TIMER_3 при завершении передачи последнего байта сгенерить свой тригер который уже и брать для TIMER_8 + DMA2 (это как раз вариант 2 при генерации пикселов)

общая логика примерно такая:

TIMER_2 CNT=0; TRIG=1; режим одиночного счета

Запуск по TIMER_2 TRIG:
TIMER_1 СNT=0; режим одиночного счета
TIMER1 - DMA2 -GPIO(8 бит) - выводим атрибуты (делитель 12*8, частота такта 0,875 мгц, пересчет 32-1 значение, остановка по завершению)
и параллельно
TIMER_3 CNT=0; режим одиночного счета, OC1 pulse=248, OC1->TRIG
TIMER_3 - DMA1 - SPI2 - запрос в DMA1 от TIMER_3, остановка по завершению передачи (32 байта)

запуск по TIMER_3 TRIG:
TIMER_8 CNT=0; режим одиночного счета
TIMER_8 - DMA2 - GPIO

Потом нужен какой то перезапуск для новой строки, наверное по прерыванию или по тригеру TIMER_8 запускать опять TIMER_2 (только не понятно можно ли так циклить таймеры
ну одновременно по прерыванию считать строки чтобы прогружать настройки DMA ну и таймеров в конце кадра

в файле некоторые расчеты сделал для удобства (в принципе ничего нового)

вопрос именно в возможности программирования такой связки таймеров и дма...

кто то может оценить выполнимость задачи или нужно другое решение ?
цель - как можно сильнее снизить нагрузку на stm32 чтобы оставалось время на обслуживание z80

Слишком сложно, выводить нужно только цвет(и синхросигналы), но проблема в том, что DMA будет гнать данные в порт неравномерно, по крайней мере этой равномерности достаточно тяжело добиться. Любое обращение к той же памяти или порту, выполнение атомарной операции и т.д. будет DMA слегка подтормаживать и на экране получится лесенка. Вполне возможно при формировании композитного сигнала это будет не особо заметно, но если делать вывод на VGA, то там несколько тактов уже визуально могут увеличить пиксель в полтора раза... Самое простое решение я вижу в установке триггера, а таймер пинающий DMA будет на другом канале формировать строб с необходимой задержкой. В принципе можно попробовать и на одном мк сделать: подготавливаем данные в SRAM1, быстро копируем в SRAM2, оттуда DMA выводит в порт, в это время CPU работает только с SRAM1 и к портам не обращается. Не только портам, нужно смотреть с чем там еще есть пересечения влияющие на DMA.

ну для пикселклок всего 7 мгц... с учетом того что в дма есть FIFO - есть надежда что все таки эти паузы будут сглажены, формат на выходе можно делать 8 бит, этого достаточно для любого этапа выдачи

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

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


Как и для всей остальной периферии это зависит от параметров...

ps. Стоит ли возиться с F4 за $3, если за $5 можно взять H750 с метром RAM и LTDC?

А что помешает подключить к vga ? если все будет аппаратно - то просто поменять значения пересчета... у pal сигнала строка 64 мкс, у vga - 32 мкс...
правда для vga scandoubler надо делать (удваивание строк) чтобы не порушить логику работу при видеовыводе (для спектрума это принципиально)



идея основная чтобы сделать грубо говоря спек при помощи макетки на STM32... какой будет контроллер дело почти десятое (так то в пентагоне 128 кб оперативки всего), главное частоты ядра и возможности dma... у конструкции будет связка железного z80, платки стм32, и некоего дешифратора видео сигнала (ну не понимаю как можно силами stm32 сделать сбор цветов с разных источников по условию)

я тут нашел одну статью интересную о dma.. даааа, навертел я выше... получается можно все проще сделать... считаю сейчас...

кстати, у stm32 вроде бы есть fifo буфер у дма - не должно быть там скачков.. читаем по 32 бита, выдаем по 8.. - по любому время обновить буфер более чем достаточно... но конечно нужно пробовать

Для VGA минимальная частота вывода пикселей - 25MHz, причем это для 640x480, не каждый монитор будет работать с таким разрешением, а 800x600 - это уже 40MHz. Во-первых, это достаточно быстро, во-вторых, все дефекты будут видны довольно хорошо.


Даже если FIFO будет постоянно заполнен DMA не сможет вывести в порт данные если в это же время к портам обращается CPU. Тем более у тебя будет внешний z80 с которым постоянно приходится работать обращаясь к портам. Лично я не вижу смысла в установке z80, не факт, что так будет хотя бы быстрее.


По-разному делают, быстрее всего таблицей, на входе 7 + 8 бит(атрибуты + 8 пикселей), на выходе цвета в каком угодно формате сразу для 8-ми пикселей. Если достаточно байта на цвет, то таблица будет 256КБ, при метре флеша ее даже паковать не обязательно.

у спека всего 488 точек по горизонтали :-))) из них 256 это изображение а остальное бордер и синхронизация... так что никаких 25 мгц ему нельзя... 7 и только 7...


вот об этом еще не думал... так то у спектрума максимум 2 обращения к порту\памяти на 7 таков на частоте 3.5 мгц... так что не сильно на что то могут повлиять.. нужно пробовать.. хорошо что предупредили, о конфликте здесь я не думал :-(

[/quote]
а дма как сюда ? таблично то я понимаю как делать.. я не понимаю как туда еще dma прикрутить чтобы по таблице данные выбирались автоматом

глянул н750... https://aliexpress.ru/item/400030000546 ... web201603_ ну что сказать - очень круто.. получается что f4 вообще покупать смысла нет... правда у h7 100-ногий корпус.... других пока не увидел

Удваиваем пиксели и будет 512 из 640, никаких проблем... Ну хотя да, сами пиксели то можно гнать вдвое медленнее, будет 12.5 или 20 MHz. Тут еще более серьезная проблема с частотой кадров, придется от 50 переходить на 60.


Есть реализации, где получают адрес в таблице по которому хранятся 16 байт цветов(по 2 байта на цвет) и DMA гонит их на дисплей прямо из флеша. Или можно предварительно копировать в массив большего размера, например, чтоб вся линия влезла. Кто-то без таблицы все считает и выводит знакоместами, но так уже часть эффектов теряется. В общем как придумаешь, так и будет.


H750 выглядит заманчиво конкретно в контексте спектрума с VGA выводом, там это дело аппаратное и встроенной памяти достаточно для создания буфера 800x600x8, ну и многократный запас по скорости многим точно не помешает :) Если же нужен спектрум с выводом на мелкий дисплей 320x240, то там тайминги не так важны, потому хватает и F4. Есть и F4 с LTDC, но они уже не дешевле H750, а RAM мало, опять придется извращаться с непредсказуемым результатом :) Зато F4 значительно проще, это тоже нужно учитывать.

ps. По линку наверняка платы с мк ревизии Y, такие лучше не брать, в rev. V пофиксили очень много.

нельзя это делать :-( ну вернее технически то можно, но у спектрума с его слабым на 3.5 мгц z80 обычно обновление экрана просчитывается как минимум по кадрам (по сигналу INT), а для всяких мультиколоров просчет идет по строчной развертке !!! так что менять частоту кадров крайне не желательно (программы не смогут правильно выводить изображение)..
можно конечно сделать какой то двойной буфер - но это уже жесть.. проще монитор на 50 гц найти. :-)))



гм.. а не помните ссылку ? по идее через DMA1 копировать в мемадрес DMA2 и уже от туда выдавать на GPIO... но честно говоря это единственный бред пришедший в голову :-(


ну может быть, хотя и просто много onchip памяти это хорошо для создания банков на 128/256 и более кб оперативки без внешней dram


с любым экраном должно быть 7 мгц на вывод пиксела... (см выше)
потом двойной буфер и на 320х240... а это затраты и памяти и времени :-(
потому и хочу сначала сделать базовый режим на телек, у меня есть маленький, типа автомобильного.. дюймов на 8...

кстати, идея с dma1 в dma2 действительно интересная...

получается у нас 8 бит изображения и 8 бит цвета - это 256 значений
для них существует 8 байт цветов для выдачи - это (256 * 256 * 8) = 524 288 байт флеша (! не оперативки!)

буфер экрана должен состоять из адреса который получается PIX_TABLE_BASE + ( img << 8 + color) - это еще 2 байта на смещение

итого на буфер экрана: 56 байт (вместе с синхрой) * 312 строк (Ленинград) * 2 байта смещения - 34 кб на экран...

очень круто если будет работать :-))) потому что я не знаю как делать dma request в этом случае - нужно отключать dma2 перед заменой адреса или можно это делать на лету (если на лету - то супер - просто по таймеру request)

правда 128 кб спек уже на 192 кб стм не реализовать.. не хватит памяти под второй экран (из процессорной памяти наверное не стоит выделять память под экран... хотя можно подумать)

ну и .опа будет наступать при смене атрибутов экрана - его нужно будет быстро переписывать в буфере.. хотя это всего 24*32 байта, но там транзакции будут по 32 байта (будем терять время на перенастройку dma2 перекидывающего цвета.. если конечно опять не припахать dma1)

В спектруме на AVR композитный сигнал, AVR просто больше не потянет, но даже автор подключает его через преобразователь к VGA... Делать спектрум c нуля на современном мк для которого придется искать старый монитор на 50 Hz конечно можно, если это проект чисто для себя любимого :)


Тут на форуме есть тема про спектрум на STM32 где из буфера размером 512КБ идет вывод на дисплей с параллельной шиной. Правда там FSMC, но не принципиально.


Я же приводил пример с VGA когда пиксели удваиваются и получается частота 12.5 или 20 MHz, а если это мелкий параллельный дисплей, то можно выводить быстрее или медленнее, визуально картинка от этого не поменяется, главное выводить актуальные данные. Можно по мере того как реальный спектрум выводит строку накапливать в буфере данные и потом вывести их в несколько раз быстрее, если дисплей такие скорости поддерживает.


7 бит цвета, один бит инверсии, можно просто инвертировать биты изображения и уменьшить таблицу в 2 раза.


Для буфера экрана достаточно 2 строки, а в некоторых эмуляторах он всего 16 байт. Даже на F4 можно генерить прерывание для отрисовки каждых 8-ми пикселей посредством DMA, а если там просто добавление в буфер, используется F7/H7 или прерывание вызывается реже, то вообще без проблем. Но не для видеосигнала, тут как раз проблемы весьма ожидаемы в любом случае, потому я мк с LTDC и рекомендую :) Или нужен QSPI, но F4 у которых он есть или с порезанными частотами, или там маловато RAM.

посмотрел... нет, там по 8 байт цвета подготавливается.. то есть прерывания генерятся каждые 8 точек для перенастройки DMA...
для той задачи - а там софтварно эмулиться z80 и экран внешний - задержки не критичны.. а вот для телевизора и железного z80 уже может стать критично...
хотелось именно решения с минимальным участием ядра arm.. в идеале раз в кадр... ну или хотя бы раз в строку...
а так получается что 875 кгц частота прерываний будет. ну или можно уменьшить их число (меньше накладных расходов на вход выход из прерывания)- но тогда нужно каждую строку предварительно просчитывать.. тоже конечно вариант.. но не тот что хотел :-(