Konference: Počítač SHARP MZ-800 a emulátory
| Od: | Bohumil Nováček |
| Datum: | 10.12.2012 07:51 |
| Předmět: | Re: Re: Novy FDC pro Sharp MZ-800 |
Ahoj tak na přání ještě jednou, pro ty co se zajímají o ARMy, ostatním se omlouvám za OT.
přikládám moje poznámky ke generování VGA na ARM Cortexech.
Samotné vykreslování obrazu by nemělo zatěžovat procesor, osobně používám
jak pro STM32F407 tak LPC1769 DMA přenost RAM->periférie.
STM má obrovskou výhodu v možnosti strobovat některé časovače jiným časovačem, takže hodiny
pro přenos DMA jdou jen, když jdou pixely na obrazovku a není potřeba v přesně stanovený čas
spouštět DMA. Naproti tomu jsou hodiny pro časovače svázané s referencí pro USB, takže lze
volit jen násobky 24MHz na vstupních hodinách, takže o přesném generování frekvence pixelů
si může člověk jenom nechat zdát.
LPC má naproti tomu téměř ideální možnosti v nastavení hodin, pro USB má extra PLL. Jde udělat
časování natolik věrně, že ho všechny monitory zobrazí pixel na pixel na default nastavení.
Já používám hodiny procesoru lehce přetaktované na 125,695MHz odvozené z 12MHz krystalu :-)
Trošku potíž je ale v tom, že nejde hodiny dost dobře strobovat, musí se spouštět DMA vždy
ve stejnou chvíli na řádku a to je problém i s přerušením, které musí mít nejvyšší prioritu
(i tady je problém, pokud přeruší nižší přerušení, zareaguje o 6 taktů dříve, je potřeba
s tím počítat a spuštění časovače synchronizace a časovače pixelů přesně synchronizovat),
musí běžet z RAM, aby případné wait stavy (nebo jejich absence, pokud je nakešováno) nezměnily
rychlost vykonávání kódu, vyplatí se poslat pár znaků ještě před "užitečným" signálem pro
synchronizaci DMA přenosu s časovačem, který jej spouští.
Stran počtu a rychlosti DMA, STM32F4xx má rychlejší přesun (zvládá stabilně přenos za cca 10 taktů),
ale ačkoliv by se mohlo zdát, že má víc DMA kanálů, ve skutečnosti má DMA jen dvě a každá z nich
má 8 tzv. streamů, což je jen postupné (i když s prioritou, nezabrání to zdržet stream s vyšší
prioritou, započatý přenos se nestornuje při příchodu vyšší priority) přepínání mezi různými
nastaveními (streamy). Naproti tomu LPC1769 má 8 plnohodnotných nezávislých DMA kanálů.
Rychlost je sice trochu menší (stabilně dokáže 1 přenos za cca 13 taktů), ale můžou jet zároveň
a pokud nepožívají ve stejnou chvíli stejné sběrnice, tak se nezpomalují ! Zkoušel jsem napřiklad
"poštvat" dvě DMA na LPC1769 obě na přenos RAM->IOport(dokonce ten samý) a propustnost se téměř
zdvojnásobila. Akorá do paměti přistupoval i procesor, takže měl výstup jitter, plus mínus pár
cyklů "plaval" kolem správného okamžiku, kdy se měl přesunout na výstup.
Předpokládám, že vše, co jsem vypozoroval na STM32F4xx bude platit i pro STM32F1xx. Do ARMů
od ST jsem "naskočil" nedávno, hlavně mám zkušenosti s vývojem na LPC od NXP.
Ale i tak si troufám prohlásit, že generovat 320x240 na VGA s STM32F1xx s 72MHz nepůjde přímo.
Generovat výstup přímo z kódu by zabralo dost paměti (pravděpodobně RAM) a hlavně procesor
příjde během generování o většinu času, který potřebuje k výrobě samotného obrazu, který
má jít na výstup. DMA má šanci někde kolem 7,2MHz pixel-rate. To je na 320x240 málo, pro
640x480 na 60Hz je pixel rate 25,175MHz (pro 320x480 je to 12,5875). Jde ale udělat fintu,
kterou jsem použil u LPC, generovat 160x240 ale do každého přesunu dát pixely dva, plus
jeden řídící bit, který bude střidavě 1 a 0, pokud bude 1, bude v nižší části lichý pixel,
pokud bude bit 0, bude v nižší části sudý pixel. Tento bit navíc se pak RC členem zpozdí
o dobu trvání jednoho pixelu (pro generování 320x240 je to 1/12,5875 mikro sekundy) a
řídí se jím multiplexer (v mém případě 74HCT157), který rozhodí ty dva pixely, aby šly
zasebou. Přikládám schéma, kde to je vidět použité, ta 74HCT04 je tam navíc, pokud to
bude používáno v malém teplotním rozsahu, jde ji nahradit pouze dvěma odporama a kondíkem.
S STM32F1xx ale budou hodiny o skoro 4% rychlejší (72MHz/11 je 6,55MHz a je potřeba 6,29MHz
pixel-rate). Ideální by bylo nastavit hodiny procesoru na 69,231MHz respektive 75,525MHz, pak
by byl dělící poměr přesně 11 respektive 12. No ale to nevím jestli vůbec s nějakým dostupným
krystalem jde.
Co se týče STM32F4xx, tam není problém s 320x240, je dostatek paměti na celou stránku,
není potřeba generovat každý řádek znovu, při přechodu na další, takže statický obraz
bere tak do 2% strojového času, dokonce přerušení v kterém se spouští DMA nemusí mít
nejvyšší prioritu. Ale hodiny jsou zase o 2,5% rychlejší (je třeba hýbat s nastavením monitoru),
a chraň ruka Páně programátora od použití stejného DMA řadiče (byť jiného streamu),
obraz se rozsype a japonský font je tu aniž by ho někdo chtěl.
Safra jsem se nějak rozepsal, no snad jsem aspoň vnesl trochu světla to temných ARMovských koutů.
Případné (konkrétnější) dotazy na mou hlavu, rád se podělím s tím co vím,
Zatím
---------- Původní zpráva ----------
Od: Michal Hučík (sharpemu tu byla ta zakroucena vec pandora.cz) <ordoz tu byla ta zakroucena vec ordoz.com>
Datum: 10. 12. 2012
Předmět: Re: Novy FDC pro Sharp MZ-800
Ahoj, taky bych se rad primluvil k tomu, at to napises sem :)
Michal
Dne 10.12.2012 0:55, Ctirad Feřtr (sharpemu tu byla ta zakroucena vec pandora.cz) napsal(a):
> Dne Ne 9. prosince 2012 22:32:46, Bohumil Nováček napsal(a):
>
> Ahoj,
>
>> K principům generování obrazu na jednotlivých platformách se vyjádřím na
>> email, tady v konferenci už je to asi silně OT.
> jestli můžu poprosit, tak mě přidej do kopie, taky mě to zajímá.
> Ale za sebe si myslím, že to klidně může přistát i tady v konferenci.
>
> Ctirad
> ---
>
---
[2012/1 (125)] [2012/2 (34)] [2012/3 (57)] [2012/4 (46)] [2012/5 (40)] [2012/6 (44)] [2012/7 (64)] [2012/8 (57)] [2012/9 (32)] [2012/10 (55)] [2012/11 (25)] [2012/12 (63)]