LPC11U68 + C rychlost portu

[Josef Štengl]

Dne 26.7.2016 v 10:08 Jan Waclawek napsal(a):
>> 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?
>
Dokumentaci k Cortex-M jsem viděl jen zběžně, ale pokud mě má zrádná paměť neklame, tak velikost mezipaměti (není to 
cache, ta je až za touto pamětí, pokud je) pro čtení kódu z flashe je 4 byte, což jsou dvě Thumb instrukce (víceméně). To 
jest, načtení dvou instrukcí jednou za dva CPU cykly by nemělo lineární a kód zdržovat. Cache tam sice není ale ten malý 
buffer by tam měl být (už pro to, že se čte vždy 32 bitů) by design.

M0 má 2 stavovou pipeline M0+ snad i 3. Nepamatuji si to přesně.

Běh z RAM / FLASH je časově různý zejména u skoků a čtení konstant z paměti programu a tak podobně. Na lineárně čtený kód 
by to nemělo mít vliv. Pokud waitstatů není příliš :-).



>> 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.
>

Jednocyklový přístup, nebo jednocyklové vykonovávání? Ona ta pipeline a  podobně trošku komplikuje časování.
I když hádám,  pro M ka jsem časování zatím bohužel ještě nestudoval.

Ono je také důležité, jaký se nastaví přístup k zařízení, jestli device nebo normal nebo strong ordered. Pro Normal by se 
nemělo čekat na dokončení operace, pokud nenásledují dva a více přístupů za sebou.

Ale pro Mko by přístup neměl mít takový význam, jde o trochu jiný koncept než pro A/R.

> 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
> viem nie je.	
>
>
> wek
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>