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?

do góry

Sebastian Biały wrote:
> 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?

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?

do góry

Sebastian Biały pisze:

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

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.

> Czy SAM7 to wyjatek, czy wszystkie ARMy tej klasy
> mają tak niefajnie?

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

do góry

Zbych wrote:
> będziesz używał rozkazów thumb to program powinien chodzić z pełną
> prędkością także przy 1 wait state.

Dostałem 5.25MHz. Czyli poprawa jest.

> Co to jest "ta" klasa? Sprawdzałem jak to wygląda na poprawionych
> LPC21xx, STM32. Zmiana stanu portu zajmuje w nich 2 cykle zegara.

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.

do góry

Sebastian Biały pisze:
> Zbych wrote:
>> będziesz używał rozkazów thumb to program powinien chodzić z pełną
>> prędkością także przy 1 wait state.
>
> Dostałem 5.25MHz. Czyli poprawa jest.

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

> No wlasnie. O ile mi wiadomo w AVR zajmuje 1 cykl.

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.

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

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

do góry

Sebastian Biały wrote:
> Zbych wrote:
>> będziesz używał rozkazów thumb to program powinien chodzić z pełną
>> prędkością także przy 1 wait state.
>
> Dostałem 5.25MHz. Czyli poprawa jest.
>
>> Co to jest "ta" klasa? Sprawdzałem jak to wygląda na poprawionych
>> LPC21xx, STM32. Zmiana stanu portu zajmuje w nich 2 cykle zegara.
>
> No wlasnie. O ile mi wiadomo w AVR zajmuje 1 cykl. Pytanie, czy w AVR32
> jest podobnie.

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

--
Jerry1111

do góry

Sebastian Biały <h...@p...onet.pl> wrote:

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

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

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

do góry

Adam Wysocki wrote:
>>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.

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

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.

do góry

Sebastian Biały wrote:
> Adam Wysocki wrote:
>>> 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.
>
>> Może AVR z zewnętrznym DRAM-em?
>
> 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.

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.

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

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

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


--
Jerry1111

do góry

Sebastian Biały pisze:

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

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.

do góry