LPC11U68 + C rychlost portu

[Pavel Hudecek]

24 MHz by bylo, kdyby všechny pulzy měly 20,83 ns. Ale protože část z nich 
má kolem 50, celkový výsledek je asi 20 MHz. Ty prodloužení jsou rozmístěny 
nepravidelně, ale celá sekvence se pravidelně opakuje. O běh z RAM jsem se 
nesnažil, ale nevylučuji, že ho optimalizace udělala.

Po vypnutí debuggeru se v této části nic nezmění. Ale popsání celého 
displeje různými barvami a fonty se zrychlí z něco pod 40 ms na asi o malý 
kousek méně. U smazání viditelná změna z původních 7,7 ms nenastane.

GPIO přes DMA mají např. LPC5410x. Ale zas mají porty na AHB a DMA mi asi 
moc nepomůže. Prakticky jde o to, že ve fontu jsou nějaké bajty a podle 
jednotlivých bitů se do displeje posílá 16b barva písma, nebo barva pozadí.

Zobrazení jednoho řádku ze znaku momentálně vypadá takto:

p8 =(uint8_t *)  &(fnt.dat[znak+r]);
for (x=0, b=0; x<wid; x++) {
    if (p8[b] & (1<<(x&7))) ili_wrI16(); else ili_wrP16();
    if ((x&7)==7) b++; // dalsi byte
}
přičemž v ili_wrI16 je:

DISP_data=dispInk16;
DISP_wr=0;
DISP_wr=1;

Do poznámky ve schematu jsem si dal, že WR přesunout na stejný port jako 
data, takže pak nebude potřeba DISP_wr=0.

PH

-----Původní zpráva----- 
From: Jan Waclawek

> Výsledkem je cca 20/20 ns nezávisle na deklaraci,

Ako pan kolega Buchta pisal, pre casovanie je dost nepodstatne co napisete
v C, podstatne je, ako sa to prelozi. Ak Vam na tom casovani naozaj
zalezi, napiste to priamo v asm, alebo - lepsie - hladajte sposob, kde
pozadovanu funkciu urobi hardware.

Ten LPC11U6x ma jadro Cortex-M0+, ktore ma pre GPIO sukromnu zbernicu
nazvanu vtipne "Single-cycle I/O port", a GPIO v tom LPC su prave na tejto
zbernici (*). Inak (t.j. ak by boli GPIO na AHB zbernici ktorou procesor
pristupuje k ostatnym periferiam, alebo nedajboze este dalej za AHB/APB
bridge (co u LPC nie je zvykom, prave NXP machrovali ze maju ako prvi
"high-speed GPIO" priamo na AHB)) by ste 1-cyklovy pristup nedosiahli, uz
len preto nie, lebo by pristupy na GPIO bojovali o zbernicu s fetchom kodu.

Ale v suvislosti s tym vznika otazka: odkial bezi ten program? Ak dobre
citam UM, FLASH je 50ns, t.j. by ste pri 48MHz system clock mali mat
nastavene 2 waitstaty pri behu z FLASH. Pritom tam nevidim ziadny
prefetch/cache/cokolvek ine co by to zrychlilo, musi to byt beh z RAM, je
to tak?

> s nepravidelnými prodlouženími na 40 ns.

Ak je ten beh z RAM, tak toto si viem vysvetlit len pristupom k GPIO z
debuggera - mata zapnuty debugger a pozerate v nom GPIO? Ak ano, po
vypnuti debuggera prestanu tie nepravidelne predlzenia na 40ns?

> Frekvence generovaná v "burstu" je průměrně cca 20 MHz.

Snad 24MHz, nie?



(*) Pozeral som do datasheetu aj UM, a v oboch je nakreslene GPIO akoby
bolo na spolocnej zbernicovej matici - DS Fig.7, UM Fig.3. Ale to by
jednak nefungoval ten jednocyklovy pristup ako som bol pisal, druhak by sa
dalo do GPIO chodit z DMA, co sa podla mna neda - to by ste mohli Vy alebo
niekto iny schvalne aj vyskusat.

Do DMA by sa dalo chodit len kebyze ma bud GPIO nejaku dual-port strukturu,
co by ho zbytocne zozlozitovalo a ktovie ci by sa dalo vobec spravit
dostatocne rychle, alebo by muselo mat jadro AHB slave port s pristupom na
tu sukromnu "I/O port" zbernicu cez nejaky arbiter (ktory tam zase kvoli
debuggeru zrejme je) - takto to ma Cortex-M7, ale u M0+ nic take pokial