Sebastian Bia?y <h...@p...onet.pl> wrote:
> On 2015-11-17 15:08, Waldek Hebisch wrote:
> >> Nie. Mam tutaj na tapecie przyklad: potrzebuje 1 instrukcj? na 1 clock i
> >> hiper szybkie GPIO bez du?ych oblicze?. AVR to daje. Taktowany 3x
> >> szybciej ARM nie ... Taktowany 10x szybciej ARM kosztuje maj?tek i ma
> >> footprint wielko?ci 10ciu AVR?w. I pewno wolniejsze GPIO ;)
> > Mozesz to rozwinac?
>
> Mam trywialne zagadnienie, musze wyprodukowa? jak najszybciej zmiany na
> magistrali adresowej Z80, ale za pomoc? AVR. To znaczy ?e musze jak
> najszybciej wypycha? rejestry na porty tak aby zaemulowa? odpowied?
> jakiego? urz?dzenia albo pobra? z niej dane. Nie pytaj po co, retro jako
> hobby :)
>
> Dane s? gotowe w rejestrach, chodzi o ich wypychanie jak najszybciej i w
> precyzyjnych momentach.

No, jesli chesz emulowac Z80 to musisz napierw policzyc co
wyslac na szyne...

> > Czytajac datasheety widze ze instrucje obslugujace
> > GPIO w ARM maja sie wykonac w 1 takcie procesora (chyba ze GPIO jest
> > podwieszone do szyny z wolniejszym zegarem, ale to w modelach majaczych
> > szybszy zeger).
>
> Problemem jest fakt ?e w ARM kod wykonywany z Flash jest wolniejszy ni?
> wykonywany z RAM. Efektem czego SAM7 poganiany zegarem 60MHz przegrywa?
> z AVRem poganianym 20MHz. By?em tym bardzo zdziwiony do czasu a? nie
> doczyta?em ?e Flash ma absurdalnie du?e waitstates. W obu wypadkach by?o
> mov 0,port; mov 1,port; jump again; Oczywi?cie mog? przenie?? kod do RAM
> i ju?, ale wtedy okrakiem staje pr?dko?c GPIO w SAM7. I tak si?
> oduczy?em patrze? na MHz.

Niestety, flash jest powonly i jest normalne ze procesor ma szybszy
zegar niz zegar flash-u. Dla liniowych fragmentow kodu powinien
dzialac prefetch, tylko przy skokach powinny dojsc te waitstates.
Po tym con napisales zdecydowalem sie sprawdzic jak to wychodzi
na innych prockach. Na Atemega 328P (jako baza) wychdza 4 cykle
na okrazenie. Na STM32F051R9T6 ponizsza petla z RAM-u wykonuje
sie w 7 taktach:

00000000 <wr_loop>:
0: 6010 str r0, [r2, #0]
2: 6011 str r1, [r2, #0]
4: e7fc b.n 0 <wr_loop>

Tu korekta do tego co pisalem wczesniej: na Cortexie M0
zapis i odczyt to 2 takty. Skok to 3, razem 7. Przy
48 MHz zegarze daje to 6.857 MHz -- pomiar na pinie
z dokladnoscia do bledu pomiaru daje to samo. To jest
lepiej niz 5 MHz osiagalne z Atmegi. Oczywiscie 3 takty
na skok boli w porownaniu z 2 dla Atmegi. Flash moze
dodac waitstates, ale nie powinno to byc wiecej niz 2
na skok (a optymistycznie 1). Wiec mysle ze nawet
przy pracy z flasha Cortex M0 powinien byc szybszy niz
Atmega.

> Dla STM32F10xx datasheet podaje ze GPIO przelacza do
> > 18 MHz
>
> Tak, GPIO jest r?wnie? powolne w du?ych procesorach z przyczyn niejasnych.

Jak rozumiem chodzi o ograniczenie EMI, a przy okazji mozna
uniknac problemow jak sciezki sa niedopasowane do pinow.
Ten STM wyzej ma konfigurowalna szybkosc, "high" ma miec
czasy narastania i opadania ponizej 5 ns przy malym obciazeniu,
"medium" na czasy ponizej 25 ns, ale to wystarczylo zeby
bramka LSTTL zlapala impulsy.

> > wyglada ze gdzis polowa czestoci zegara to maksimum na GPIO.
> > Wiec taki STM32F10xx powinien wygrac z AVR gdzies do 36 MHz.
>
> W moim projekcie jak zauwa?yle? wy?ej potrzeba jest r?wnie? 5V :) Mia?em
> nadzieje na dsPIC33, ale okaza?o si? ze tam zegar dzielony jest dalej
> przez 4 wi?c nic nie zyskam.

5V zasilanie czy zgodnosc z 5V? Jak rozumiem Z80 pracowal na
poziomach zblizonych do TTL i czesto byly do niego podpiete
uklady LSTTL. Ten STM ma produkowac syganaly zgodne z TTL
(pierwszy stopien licznika do zliczania impulsow na pinie
byl w LSTTL) i wytrzymac 5V na wejsciu, wiec jak mu dodasz
zasilacz 3.3 V to powinien dzialac na szynie Z80. Oczywiscie
trzeba by spradzic obciazalnosc, ale 8 mA na pin to chyba
podobnie do Z80...

A propo: uklady serii STM32F030 (podstawowe parametry takie
jak STM32F051) to najtansze procki ktore zauwazylem w
katalogu Farnella (nie szukalen dlugo wiec moze jest
cos tanszego).

--
Waldek Hebisch