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.

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

Dla STM32F10xx datasheet podaje ze GPIO przelacza do
> 18 MHz

Tak, GPIO jest również powolne w dużych procesorach z przyczyn niejasnych.

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

> Dla LM4F120H5QR (marketing zmienil numer na TM... ale o ile
> wiem parametry maja byc te same) Ti podaje o GPIO:
>
> : Fast toggle capable of a change every clock cycle for ports on AHB, every
> : two clock cycles for ports on APB
>
> przy 80 MHz to wyglada duzo lepiej niz AVR. Fakt ze to drozszy
> model, ale nie najwysza polka.
> Co przegapilem?

Nic. Do wyboru jest wiele szybkich cpu, ale niektórych nie ma sensu do
zabawy z różnych względów brac: albo 3.3V, albo obudowa z miliardem
nózek, albo 7 napięć zasilających, itd.

> No, jak chcesz naprawde szybkie CPU

Nie, nie chce. Chce odpowiednie narzedzie do problemu. Wydaje się że PIC
się nie sprawdzi a AVR tak.

do góry

On Tue, 17 Nov 2015 20:32:41 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> 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 :)

Jakośv ciągle stosujesz ogólniki "jak najszybciej" zamiast podać
konkretne liczby. Ile w Mhz wachlowanie pinem Cię zadowoli 20Mhz,
100Mhz, 1000Mhz?

--
Marek

do góry

On 2015-11-17 23:23, Marek wrote:
>> jakiegoś urządzenia albo pobrać z niej dane. Nie pytaj po co, retro
> jako
>> hobby :)
> Jakośv ciągle stosujesz ogólniki "jak najszybciej" zamiast podać
> konkretne liczby. Ile w Mhz wachlowanie pinem Cię zadowoli 20Mhz,
> 100Mhz, 1000Mhz?

Potrzebuje minimum około 10 cykli cpu (najlepiej >16 bo wtedy mam
swobodę) pomiedzy 1 cyklem zegara Z80, taktowanie powiedzmy 3MHz. Czyli
potrzebuje w moim cpu 30MIPSów licząc instrukcję na cykl, tak na start,
oraz spodziewam się że GPIO bedzie machało tak samo szybko. Ponadto
liczy się też asm, np. niezwykle byłby wygodny skok przez tablicę
adresów we flash.

do góry

On 2015-11-15 19:25, janusz_k wrote:
[...]
> Mylisz się, po pierwsze łatwiejszy w nauczeniu, po drugie 95% projektów
> amatorów nie wykorzystuje mocy obliczeniowej 8 bitowca a co dopiero 32.
Bez przesady z tą trudnością. IMO np. AVR i ARM7TDMI to "the same shit".
Jednak MCU 32-bitowy pozwala uniknąć programiście niektórych
upierdliwości, ot, np. atomowe dodawanie liczb "szerszych" niż 8-bitowe.
No i fakt, do realizacji jakiegoś urządzenia często nie są potrzebne
jakieś duże ilości (D)MIPS-ów, ale np. potrzeba sporo pamięci danych i
pod tym względem 32-bitowce są z reguły lepiej wyposażone co pozwala na
umieszczenie na PCB jednej kostki zamiast MCU i dodatkowego RAM-u.

do góry

On 2015-11-14 13:42, Marek wrote:
[...]
> http://www.youtube.com/watch?v=LjfIS65mwn8
>
> Po czym Microchip odpowiedział mu tym filmem :-)
>
> http://www.youtube.com/watch?v=3YUvlrVlNao
Hehe, jak oglądałem Dave'a to od razu pomyślałem, że przyczepią się do
tego dickhead manager-a. :-D

do góry

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

do góry