Jakie są realne prędkości obsługi GPIO w procesorze SAM7 przy 3.5MHz?

Fri Aug 28, 2009 4:42 pm   

Witam.

Wysyłam na przemian jedynki i zera w pętli 3 instrukcji asm. Osiągam
3.5MHz. Teoretycznie rdzeń pracuje na max. predkości (jeszcze to
sprawdzę). Czy to coś nie jest zdecydowanie za wolno, czy może 3.5MHz to
własciwa predkośc dla SAM7?

Fri Aug 28, 2009 9:43 pm   

Sebastian Biały wrote:

Sam sobie odpowiem ...

Zasilam SAM7 zegarem 48MHz.

Prosta pętla:

loop:
str ...
str ...
b loop:

zajmuje dokładnie 7 cykli zegara. Tzn zajmowala by, gdyby ... nie 1 wait
state w pamięci flash. Więc zajmuje dokladnie 14 cykli. 48MHz/14 = 3.43MHz.

Przyznam, ze mały AVR potrafi znacznie szybciej machać IO przy
mniejszych kwarcach :/ Czy SAM7 to wyjatek, czy wszystkie ARMy tej klasy
mają tak niefajnie?

Sat Aug 29, 2009 9:25 am   

Sebastian Biały pisze:


Na avr zajmie ci to 6 cykli. Nie wiem, czy to tak dużo mniej. Druga
rzecz, to szerokość magistrali flasha - AFAIR 32-bity w SAM7, jak
będziesz używał rozkazów thumb to program powinien chodzić z pełną
prędkością także przy 1 wait state.


Co to jest "ta" klasa? Sprawdzałem jak to wygląda na poprawionych
LPC21xx, STM32. Zmiana stanu portu zajmuje w nich 2 cykle zegara. W
corteksie trzeba pamiętać o wyrównaniu adresu początku pętli do
wielokrotności długości prefetcha, żeby nie tracić dodatkowych cykli
przy skoku.

--
przeciez moje rozumowanie bylo bez skazy,
no sam bym wskoczyl do tego wulkanu,
ale kto by tak pieknie gwizdal...

Sat Aug 29, 2009 2:11 pm   

Zbych wrote:

Dostałem 5.25MHz. Czyli poprawa jest.


No wlasnie. O ile mi wiadomo w AVR zajmuje 1 cykl. Pytanie, czy w AVR32
jest podobnie.

Potrzebuje obslużyć niewtypowy LCD. I każde spowolnienie na IO widze
jako mniejsze frame-rate. I gdyby nie za malo RAM w AVR to bym się nie
bawil w SAM7.

Sat Aug 29, 2009 5:37 pm   

Sebastian Biały pisze:

Jak zrobisz dłuższą pętlę, to powinno być jeszcze lepiej.


Zajrzyj do datasheeta: SBI, CBI trwają dwa cykle. No chyba, że możesz
pisać do całego portu naraz to wtedy IN i OUT kosztują tylko 1 cykl.


STM32 biega na 72MHz, przy 2 cyklowych operacjach IO możesz zmienić stan
linii z częstotliwością 36MHz. Jeśli to jest za mało, to ratuje cię już
chyba tylko cpld/fpga.


--
przeciez moje rozumowanie bylo bez skazy,
no sam bym wskoczyl do tego wulkanu,
ale kto by tak pieknie gwizdal...

Sat Aug 29, 2009 7:36 pm   

Sebastian Biały wrote:

W AVR32 jest niezle - piny mozna uzyc w trybie fast.

--
Jerry1111

Sat Aug 29, 2009 9:14 pm   

Adam Wysocki wrote:

A AVR z DRAMem będzie szybszy od SAM7 ? I bedzie kosztował tyle samo ?
Zadanie jest: jak najtaniej, jak najprosciej. Jeden scalak jest ok.

W sumie muszę tak naprawde odbudowac kawalek elektroniki który ulegl
zniszczeniu. Oryginalnie scalak pracujacy jako sterownik tego LCD jest
uszkodzony mechanicznie i w dodatku ani wsadu ani nawet wiedzy co to
jest (zeszlifowana obudowa). Ale musiało być całkiem do rzeczy bo dawalo
radę 15fps @ 1x640x480 [1]. Abym tego dokonał musze miec pi razy drzwi
średnią predkośc koło 1MHz wciskania nibblów co oznacza jakieś 4MHz
machania I/O (a gdzie przeliczenia?). Obawiam się, że AVR z DRAM nie da
rady. Liczyłem na SAM7 ale troche się przejechałem po pomiarach.

FPGA na razie sobia daruje bo chyba z takim RAMem nie da rady konkurować
z uC za 30zl (ale może mnie ktos wyprowadzi z błedu).

[1] tak naprawdę zmianom ulega jakieś 40% ekranu, więc wymagania RAM sa
nieco lżejsze.

Sat Aug 29, 2009 9:40 pm   

Sebastian Biały <heby@poczta.onet.pl> wrote:


Może AVR z zewnętrznym DRAM-em?

--
http://www.gophi.pl/

Sat Aug 29, 2009 10:00 pm   

Sebastian Biały wrote:

OIDP to AVR32 daje cos 12MHz prostokat na pina (jesli GPIO uzyjesz w
trybie fast).
UC3A0512 ma 64k RAMu, wiec powinno Ci starczyc na obraz.


Czegos nie rozumiem. Piszesz ze sztuka uszkodzona - to na cholere
oszczedzac 10PLN i tracic tydzien? Chyba ze masz tych 'mechanicznie
uszkodzonych' sztuk z 1000.



--
Jerry1111

Sun Aug 30, 2009 1:46 am   

Sebastian Biały pisze:


Odpal pętlę z RAMu - będzie znacznie szybciej niż z Flasha.

Śmigający na 48MHz SAM7 z Flasha ma efektywnie tylko ok. 33 MIPSy (tyle
zwalnia Flash, dając 1 waitstate na każde 32 bity). I wykonuj kod Thumb,
zwykle krótszy niż w trybie ARM. Spróbuj też rozwinąć pętlę (np.
kilkaset mignięć bardzo szybko a potem dopiero skok). SAM7 chodzi
szybko, problemy z częstymi dostępami do I/O dotyczą procków Philips/NXP
np. LPC2106.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Sun Aug 30, 2009 8:03 am   

Jerry1111 wrote:

Musze w końcu wziąść się za AVR32 ...


Biorąc FPGA tracę ~3 tyg na naukę i pewnie falstart bo źle ocenię ilośc
makrocel. Chce to miec "na jutro". Akurat SAM7 mam od ręki, AVR32 w
miarę szybko. Oczywiście gdybym w szyfladzie miał odpowiedniu FPGA to by
nie było o czym rozmawiać ...