obsłudze GPIO ?

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?
Reply to
Sebastian Biały
Loading thread data ...

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?

Reply to
Sebastian Biały

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.

Reply to
Zbych

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.

Reply to
Sebastian Biały

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.

Reply to
Zbych

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

Reply to
Jerry1111

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

Reply to
Adam Wysocki

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.
Reply to
Sebastian Biały

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.

Reply to
Jerry1111

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.

Reply to
Adam Dybkowski

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

Reply to
Sebastian Biały

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.