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

Porównanie portów IO - atmega8, lpc2000, stm32

10 Gru 2010 23:21 3064 14
  • Poziom 11  
    Witam

    witam
    załóżmy teoretycznie że na procesory:
    Atmega 8 , STM32F100x, STM32F102x, STM32F103x, LPC214x gram identyczny kod który ma za zadanie tylko zmieniać stan portu A

    Code:


    while(1) //pętla nieskończona
    {
    PORTA = 0xFF;  //ustaw stan wysoki
    PORTA =   0;   // ustaw stan niski
    }

    Jaka byłaby częstotliwość zmian PORTU A?
    przy założeniu że wyżej wymienione procesory działają z maksymalnym zegarem przewidzianym przez producenta (odpowiednio 16, 24, 32, 72, 60 MHz)
  • PCBway
  • Poziom 13  
    Czemu w porównaniu nie zostały uwzględnione cortex-y Philipsa (LPC1xxx). Jakby były uwzględnione to prędkość zmian portu w przypadku tych układów wyglądała by następująco:

    Poniżej fragment kodu w asmie który powinien zostać odpalony w ramie w celu większej szybkości działania.
    Code:
      //pobieranie adresu portu i wstawianie wartości do rejestrów
    
    LDR R3, =ADRESPORTU
    MOVS R1, #0
    MOVS R2, #1 //ta wartość może różnić się w zależności od portu.

    PETLA:  //zmiana stanu portu

    STR R1, [R3]
    STR R2, [R3]

    B PETLA


    Należy pamiętać patrząc na powyższy kod że instrukcja Load (LDR) i Store (STR) potrzebują na realizacje dwóch cykli zegara. Natomiast instrukcja Branch (B) trzech cykli zegara.

    Można by oczywiście ten kod przyspieszyć jeśli w założeniu ma być realizowane tylko coś takiego a można by tego dokonać poprzez układanie instrukcji STR na przemian:

    Code:

    PETLA
    STR R1, [R3]
    STR R2, [R3]

    STR R1, [R3]
    STR R2, [R3]

    STR R1, [R3]
    STR R2, [R3]
    //i tak wielokrotnie aż do wyczerpania zasobów
    B PETLA


    Czyli z tych informacji w zależność od szybkości zegara możesz sobie sam wyliczyć ile czasu będzie kod wykonywał się.

    Oczywiście należy pamiętać o ograniczeniach co do szybkości pracy portów - nie wiem czy jest jakieś w cortex-ach Philipsa ale w przypadku Atmegi8 już jest ograniczenie i wynosi ono parę MHz (niech ktoś poda wartość bo ja nie pamiętam ile wynosiła).

    To co podałem wyżej możliwe że będzie częściowo zgodne z innymi Philipsami. Co do innych układów nie miałem z nimi kontaktu więc ktoś inny musi wykazać się. Podczas pisania odpowiedzi korzystałem z dokumentu: Technical Reference Manual a odnosiłem się głównie do rdzenia cortex-m0 z którym to mam największą styczność.
  • Poziom 33  
    ARM7 nie jest najlepszym wyborem do przełączania stanu na porcie, nie da się to tego zrobić w sposób który podałeś. Najpierw trzeba sprawdzić jaki jest obecny stan, następnie zmienić odpowiedni rejestr. ATmegę możesz sprawdzić w symulatorze ale pomijając instrukcję na wykonanie pętli to osiągniesz na porcie fclk/2.
  • Specjalista - Mikrokontrolery
    wujcio24 napisał:
    Poniżej fragment kodu w asmie który powinien zostać odpalony w ramie w celu większej szybkości działania.

    Niezła bzdura - Cortex-Mx jako układ w zmodyfikowanej architekturze Harwardzkiej bardzo kiepsko wykonuje program z pamięci RAM. A producent LPCxxxx nazywa się NXP, a nie Phillips i to już od bardzo dawna.

    Co do tematu - jak chcesz szybko zmieniać stan pinu, to prościej zrobić generator a nie zastanawiać się jak to zrobić na układach które wymyślono do czego innego niż machanie pinami. Zresztą - używając timera i PWMa można zwykle wyciągnąć max częstotliwość - zegar_timera / 2.

    4\/3!!
  • PCBway
  • Moderator Mikrokontrolery Projektowanie
    wujcio24 napisał:

    Oczywiście należy pamiętać o ograniczeniach co do szybkości pracy portów - nie wiem czy jest jakieś w cortex-ach Philipsa ale w przypadku Atmegi8 już jest ograniczenie i wynosi ono parę MHz (niech ktoś poda wartość bo ja nie pamiętam ile wynosiła).


    Co do ATMeg to też niezła bzdura - nie ma żadnych ograniczeń na częstość przełączania pinów IO - jedynym ograniczeniem jest max częstotliwość zegara. Stąd też max programowo można uzyskać CLK/2.
  • Poziom 11  
    wiem że niektóre uC potrzebują kilku taktów zegara aby ustawić stan logiczny na porcie. W starszych LPC opartych o ARM7 porty IO były bardzo wolne... W nowszych LPC21xx poprawiono to. Chciałem się dowiedzieć jak w tej kwestii wypadają STM32 (przy różnych zegarach) i chciałbym mieć porównanie do Atmegi8 bo na razie takie programuje.

    Zależy mi na szybkim 'machaniem portów' do sterowania wyświetlaczem TFT magistralą 8 bit. Aby zapalić 1 piksel w tryie 16mln kolorów trzeba:

    -ustawaić PINY PORTU A dla koloru Czerwonego
    -ustawić PIN WRITE
    -zerować PIN WRITE

    -ustawaić PINY PORTU A dla koloru Zielonego
    -ustawić PIN WRITE
    -zerować PIN WRITE

    -ustawaić PINY PORTU A dla koloru Niebieskiego
    -ustawić PIN WRITE
    -zerować PIN WRITE

    Czyli co najmniej 9 operacji.

    Przy rozdzielczości 320 x 240 ma to wielkie znacznie bo aby zapełnić wyświetlacz danymi trzeba wykonać ponad 691 tyś ustwień portu !


    i dlatego chce wiedzieć jakiej szybkości mogę się spodziewać (pomijając odczyt danych z Flash)

    Może ktoś zrobił pomiary oscyloskopem?
  • Poziom 13  
    Cytat:
    Niezła bzdura - Cortex-Mx jako układ w zmodyfikowanej architekturze Harwardzkiej bardzo kiepsko wykonuje program z pamięci RAM.


    Mógłbyś to rozwinąć i przedstawić to bardziej szczegółowo a także opisać jaka jest prędkość wykonywania kodu w pamięci RAM i pamięci Flashu (jaka jest najkorzystniejsza prędkość taktowania). Czekam na oświecenie w tej kwestii.

    Cytat:
    A producent LPCxxxx nazywa się NXP, a nie Phillips i to już od bardzo dawna.


    A to jest chyba detal który każdy pomija tutaj, przynajmniej tak wynika z moich obserwacji. Ale proszę bardzo następnym razem z dedykacją dla ciebie będę trzymał się tych szczególików.

    Cytat:
    Co do ATMeg to też niezła bzdura - nie ma żadnych ograniczeń na częstość przełączania pinów IO ...


    Tego nie byłem pewien ale wydawało mi się że takie coś pisało w książce ,,Sztuka Programowania Mikrokontrolerów AVR". Napisz czy jesteś pewien swojego zdania absolutnie - bo jak temat zostanie zakończony to lepiej żeby nie było w nim bzdur a wszystkie kwestie zostały rozstrzygnięte bo później ktoś znajdzie to w google i będzie na tym swoją wiedzę opierał.

    Sprawdziłbym to dokładniej jakbym miał dostęp do oscyloskopu ale niestety nie mam.
  • Specjalista - Mikrokontrolery
    wujcio24 napisał:
    Cytat:
    Niezła bzdura - Cortex-Mx jako układ w zmodyfikowanej architekturze Harwardzkiej bardzo kiepsko wykonuje program z pamięci RAM.


    Mógłbyś to rozwinąć i przedstawić to bardziej szczegółowo a także opisać jaka jest prędkość wykonywania kodu w pamięci RAM i pamięci Flashu (jaka jest najkorzystniejsza prędkość taktowania). Czekam na oświecenie w tej kwestii.

    http://en.wikipedia.org/wiki/Modified_Harvard_architecture
    http://new.eetimes.com/design/embedded/400882...CU?pageNumber=4&Ecosystem=microwave-rf-design - rozdział "Executing from RAM"

    Cytat:
    Cytat:
    A producent LPCxxxx nazywa się NXP, a nie Phillips i to już od bardzo dawna.


    A to jest chyba detal który każdy pomija tutaj, przynajmniej tak wynika z moich obserwacji. Ale proszę bardzo następnym razem z dedykacją dla ciebie będę trzymał się tych szczególików.

    I potem ktoś nowy zacznie szukać informacji o LPCxxxx na stronie Philipsa... Dla mnie nawet nie musisz podawać nazwy producenta, bo ja ją znam, ale nie wszyscy to wiedzą, bo to wcale nie jest oczywiste, że Phillips wyciął dział elektroniki pod nazwą firmy NXP.

    Zaś co do tematu... Nie prościej wziąść LPC2478, dołożyć SDRAM, podłączyć matrycę LCD i mieć wszystko gotowe? Albo jak chcesz wyciągać kosmiczne prędkości, to może czas zainteresować się FPGA, albo choć CPLD żeby te dane przerzucał z bufora na magistralę?

    Wydaje mi się też, że w niektórych ARMach można na timerze zrobić sygnał taktujący (PWM), a do przerzucania danych skądś na port można zatrudnić DMA.

    4\/3!!
  • Poziom 11  
    widze że sie dyskusja toczy...
    .. niestety dalej nie znam odpowiedzi na moje pytanie.
    Nie interesują mnie lpc2478, FPGA i nne...
  • Specjalista - Mikrokontrolery
    Ah, czyli problem z kategorii "sztuczne" - trzeba coś zrobić, musi być super-ultra-szybkie, ale użyć należy układów które nie są super-ultra-szybkie w tym co trzeba zrobić. Your call... Zrozum, że żaden mikrokontroler nie jest przystosowany do machania pinami z wysokimi częstotliwościami, a już na pewno nie te nowoczesne i szybkie. Swoją drogą to Twój interfejs można przypuszczalnie wykonać wykorzystując interfejs pamięci zewnętrznej, chyba że to też Cię nie interesuje, bo koniecznie musi być to tępe machanie pinami w pętli wewnątrz main() i nic innego nie wchodzi w grę. Nawet można coś takiego zrobić wykorzystując pamięć zewnętrzną, która wystawiała by dane, a układ scalony tylko by je ewentualnie zmieniał w wolnych chwilach i taktował wypychanie danych z tej pamięci.

    4\/3!!
  • Moderator Mikrokontrolery Projektowanie
    Dokładnie, tak jak pisze Freddie, należy taki LCD podłączyć pod interfejs pamięci zewnętrznej, jest to szczególnie łatwe w przypadku AVR (ale nie ATMega8). Wtedy zyskuje się na braku konieczności machania pinami, chociaż nie aż tak dużo, bo niestety ten interfejs wprowadza waitstaty.
    Co do prędkości w ATMegach, tak, jestem pewien, można to sprawdzić w dowolnej nocie aplikacyjnej AVR.
  • Poziom 11  
    Freddie Chopin napisał:
    Ah, czyli problem z kategorii "sztuczne" - trzeba coś zrobić, musi być super-ultra-szybkie, ale użyć należy układów które nie są super-ultra-szybkie w tym co trzeba zrobić. Your call... Zrozum, że żaden mikrokontroler nie jest przystosowany do machania pinami z wysokimi częstotliwościami, a już na pewno nie te nowoczesne i szybkie. Swoją drogą to Twój interfejs można przypuszczalnie wykonać wykorzystując interfejs pamięci zewnętrznej, chyba że to też Cię nie interesuje, bo koniecznie musi być to tępe machanie pinami w pętli wewnątrz main() i nic innego nie wchodzi w grę. Nawet można coś takiego zrobić wykorzystując pamięć zewnętrzną, która wystawiała by dane, a układ scalony tylko by je ewentualnie zmieniał w wolnych chwilach i taktował wypychanie danych z tej pamięci.

    4\/3!!


    Z całym szacunkiem dla twojej wiedzy...
    Wiem że można o zrobić lepiej i szybciej itp
    przytoczyłem tylko przykład. Nie zależy mi na mega szybkim machniu portów. Ale nie chce aby się okazłao że STM32 @ 24 MHZ są wolniejsze od Atmegi8, ciekwawi mnie też czy szybsze są stm32 @72 MHz czy LPC21xx @60 Mhz
  • Poziom 32  
    hamilton32 napisał:
    wiem że niektóre uC potrzebują kilku taktów zegara aby ustawić stan logiczny na porcie. W starszych LPC opartych o ARM7 porty IO były bardzo wolne... W nowszych LPC21xx poprawiono to. Chciałem się dowiedzieć jak w tej kwestii wypadają STM32 (przy różnych zegarach) i chciałbym mieć porównanie do Atmegi8 bo na razie takie programuje.

    Zależy mi na szybkim 'machaniem portów' do sterowania wyświetlaczem TFT magistralą 8 bit. Aby zapalić 1 piksel w tryie 16mln kolorów trzeba:

    -ustawaić PINY PORTU A dla koloru Czerwonego
    -ustawić PIN WRITE
    -zerować PIN WRITE

    -ustawaić PINY PORTU A dla koloru Zielonego
    -ustawić PIN WRITE
    -zerować PIN WRITE

    -ustawaić PINY PORTU A dla koloru Niebieskiego
    -ustawić PIN WRITE
    -zerować PIN WRITE

    Czyli co najmniej 9 operacji.

    Przy rozdzielczości 320 x 240 ma to wielkie znacznie bo aby zapełnić wyświetlacz danymi trzeba wykonać ponad 691 tyś ustwień portu !


    i dlatego chce wiedzieć jakiej szybkości mogę się spodziewać (pomijając odczyt danych z Flash)

    Może ktoś zrobił pomiary oscyloskopem?


    Stosując zewnętrzną pamięć RAM którą i tak bedziesz musiał zstosować wykonanie powyższych operacji zajmie ci dla wszystkich 3 kolorów 8 bit 12taktów zegara.
  • Poziom 13  
    Freddie czy jesteś pewien że Cortex-M0 to jest architektura Harwardzka (zmodyfikowana architektura Harwardzka)?
    Co do Cortex-M3 nie mam najmniejszych wątpliwości że masz racje bo to pisze choćby tutaj stm32_w_praktyce i jest świetnie uzasadnione ale także tutaj http://www.arm.com/products/processors/cortex-m/cortex-m3.php na dole w zakładce Specifications pisze: Architecture ARMv7-M (Harvard). Natomiast jak wejdziesz tu http://www.arm.com/products/processors/cortex-m/cortex-m0.php i wybierzesz ponownie zakładkę Specifications to masz napisane coś innego niż w Cortex-M3 a mianowicie: Architecture ARMv6-M (Von Neumann) i dokładnie takie coś widziałem na stronie NXP. I teraz pytanie czy mam racje i jeśli ją mam to ile to zmienia w kwestii szybkości wykonywania kodu w pamięci RAM ?
  • Specjalista - Mikrokontrolery
    Skoro to inna architektura, to inna sprawa - tam szybkość kodu wykonywanego z RAM będzie PORÓWNYWLNA, ale to nie jest też tak, że z RAMu jest 4x szybciej niż z flasha - jakaś tam różnica jest, ale nie jest to nic "kolosalnego". Zwłaszcza w układach z akceleratorem dostępu do flasha.

    4\/3!!