Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[stm32] Zmiana częstotliwości pracy a program w pamięci Flash

grzegorzn 17 Lip 2011 17:11 2195 10
  • #1 17 Lip 2011 17:11
    grzegorzn
    Poziom 11  

    Procek działa sobie z częstotliwością 8 MHz, powiedzmy, że sygnał ma z HSE. Chcę sobie go podkręcić na 72 MHz więc odpalam PLL. No i niby jest podkręcony ale Flash może działać tylko do 24 MHz więc trzeba dodawać latencje, np. za pomocą FLASH_SetLatency(FLASH_Latency_2); To z kolei powoduje, że kod programu jest wykonywany dużo wolniej i podniesienie częstotliwości taktowania niewiele dało. Jaki jest więc sens rozkręcania procka do 72 MHz? Chodzi tylko o takie peryferia jak USB czy Ethernet, które muszą działać szybko? Jak to jest w przypadku obliczeń? Wydaje mi się, że jeśli chcę np. wykonywać szybkie obliczenia to nie ma sensu kręcić powyżej 24 MHz, chyba, że kod będzie siedział w RAMie a nie we Flashu.
    Jest jeszcze ten cały prefetch buffer dla Flasha ale nie zauważyłem żeby on coś dawał, nie rozwiązuje problemu latencji.

    0 10
  • Pomocny post
    #2 18 Lip 2011 11:56
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Masz rację - wydaje Ci się... (;

    Latencja to nie jest jakiś delay czy preskaler, po prostu przy nie-sekwencyjnym wykonywaniu rozkazów (skoki), potrzebne są te 2 cykle na załadowanie bufora. Spadek wydajności przez taką latencję oscyluje pewnie w rejonie kilku procent, więc nad czym się tu zastanawiać?

    Jeśli podniesienie częstotliwości "nic nie dało" to znaczy że jej wcale nie podniosłeś, co przy użyciu genialnej biblioteki ST nie jest niczym dziwnym - ci którzy jej używają mają problemy cały czas, Ci którzy jej nie używają ich nie mają [;

    4\/3!!

    0
  • #3 18 Lip 2011 12:18
    grzegorzn
    Poziom 11  

    Dzięki za odpowiedź. Patrzyłem sobie na szybkość działania migając LEDem. Opóźnienie było robione pętlą for (kompilowaną do SUBS, CMP, BNE.N) więc program ciągle skakał i nie było za bardzo widać rezultatu działania prefetchingu.

    Co do biblioteki ST to znam opinię o niej, sam znalazłem błąd w siostrzanej bibliotece do USB. Tutaj jednak nie było z nią problemu, procek działał szybciej ale przy mnożniku 9 dla PLL LED nie migał 9 razy szybciej tylko jakieś 3 razy, nie mierzyłem dokładnie. Teraz wiem, że to przez ciągłe skoki. Jakby zrobić miganie na przerwaniach to problem by zniknął.

    0
  • #4 18 Lip 2011 12:26
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Możesz sobie nieco rozwinąć tą pętlę opóźniającą np tak:

    Kod: C
    Zaloguj się, aby zobaczyć kod


    4\/3!!

    0
  • #5 18 Lip 2011 12:29
    grzegorzn
    Poziom 11  

    Tak, albo nawrzucać nopów :)

    0
  • #6 18 Lip 2011 14:49
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Instrukcja NOP dla rdzenia Cortex-M3 niekoniecznie ma sens, może nie wprowadzić żadnego opóźnienia.

    4\/3!!

    0
  • #7 18 Lip 2011 22:13
    grzegorzn
    Poziom 11  

    NOP does nothing. NOP is not necessarily a time-consuming NOP. The processor might remove it from the pipeline before it reaches the execution stage.

    Use NOP for padding, for example to adjust the alignment of a following instruction.

    Hm, czyli generalnie NOP jest niedeterministyczny jeśli chodzi o czas wykonania?

    0
  • #8 18 Lip 2011 23:00
    Freddie Chopin
    Specjalista - Mikrokontrolery
  • #9 19 Lip 2011 11:00
    grzegorzn
    Poziom 11  

    A mam jeszcze pytanie odnośnie bufora. Piszesz, że latencja to nie delay bo to czas potrzebny na załadowanie bufora. Jednak gdyby buforowanie było wyłączone, to byłby to zwykły delay. Z resztą pojęcie waitstate kojarzy mi się z delay'em. Ale chyba jednak buforowanie jest domyślnie włączone po resecie i nie trzeba go włączać?

    Znalazłem jeszcze ciekawą wypowiedź:
    Cortex-M3 has a prefetch buffer and branch prediction. This
    means that the cost of a single waitstate can be hidden for conditional branches,
    ie. only indirect branches have a penalty. With 2 wait states the branch prediction
    only works on unconditional branches, so you'll get a slowdown.

    0
  • #10 19 Lip 2011 11:53
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Buforowanie domyślnie jest włączone, po resecie trzeba tylko skonfigurować latencję. Możesz znaleźć w na stronie ST manuala "PM0042 Programming manual STM32F10xxx Flash programming" w którym mechanizm ten jest omówiony, opisane są też rejestry sterujące.

    Co do branch prediction, to sprawa jest cięższa, informacje nie są do końca jasne. Taka logika może być opcjonalna, w sensie może być zaimplementowana, ale nie musi, ewentualnie to jakieś piękne słowa opisujące coś zupełnie innego. Lepszy akcelerator flasha (wg dokumentacji [; ) jest w mikrokontrolerach STM32F2xx oraz u konkurencji - w LPC17xx.

    4\/3!!

    0
  • #11 19 Lip 2011 16:13
    grzegorzn
    Poziom 11  

    Z tym włączeniem buforowania po resecie to jest tak, że faktycznie reset ustawia bity PRFTBE i PRFTBS. Jednak jak puszczę program z debuggera (korzystam z IAR) to te bity nie są ustawiane i program leci bez buforowania. Z czego to może wynikać?

    Eksperymentując z buforowaniem oraz ilością operacji typu dummy=dummy w pętli for robiącej opóźnienie zauważyłem, że włączenie buforowania ma największy wpływ przy małej ilości tych operacji, kiedy skoków jest stosunkowo dużo. Wnioskuję z tego, że to całe buforowanie jest tak naprawdę włączone zawsze, i nigdy nie ma czegoś takiego, że procek pobierze sobie instrukcję i czeka dwa cykle (przy latencji 2) aby pobrać następną z Flasha. Włączanie/wyłączanie buforowania jest tak naprawdę włączaniem/wyłączaniem predykcji.

    0