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