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.

LPC1768 - gdzie te 100MIPS?

29 Wrz 2011 08:24 4658 49
  • Poziom 8  
    Zacząłem swoją przygodę z ARM od CORTEX'a LPC1768. Miał być bardzo szybki.
    Ustawiłem PLOCFG = 0x00050063, CCLKCFG = 3 (czyli N=6 M=100 przy Fosc=12MHz co powinno dać ok. 100MIPS) i napisałem krótki programik, który "macha nóżką". Czyli:
    -ustaw na pin GPIO jedynkę
    -zrób pętlę while(i++ < 5000){;}
    -i=0;
    -ustaw na pin GPIO zero
    -zrób pętlę while(i++ < 5000){;}
    -i=0;
    ... i w kółeczko
    Optymalizacja na najwyższym poziomie.
    Z tego co odczytałem na oscyloskopie (przebieg prostokątny ok. 1kHz) i prostych wyliczeń mam co najwyżej 10MIPS'ów.

    Czy ktoś może mi powiedzieć dlaczego?

    Zdaję sobie sprawę, że program wykonywany z flesh'a jest wolniejszy, ale chyba nie aż tak.
  • PCBway
  • Poziom 30  
    Oj, procesor wykonuje swoje operacje z prędkością taktowania. I na tym koniec. reszta zwykle ma swoją prędkość, wolniejszą od procesora. Wtedy procesor czeka aż się operacja wykona. Procesor wykonuje 1 instrukcję na cykl tylko wtedy gdy:
    1) Operacja nie wymaga użycia pamięci (chyba że wewnętrzna pamięć procesora, ARM'y czasami mają Tightly Coupled Memory)
    2) Procesor ma cache jednocyklowy i operacja nie wymaga odczytu/zapisu linii.
    3) Procesor robi nic - NOP (w ARMach<v7 nie ma instrukcji NOP)
    4) Nie musi wykonać skoku warunkowego, bo inaczej pip-line musi byś przeładowany. Chyba, że ma dobry branch-prediction,
    5) Nie zmienia trybu pracy (przerwanie albo inne tryby)

    Reszta operacji to po kilka i kilkanaście cykli. Poszeregowałbym to tak (od najszybszej): dostęp do RAM, dostęp do FLASH, dostęp do rejestrów (tzn. dostęp do peryferiów).

    Przecież z procesora wychodzi jedna magistrala i wszystko musi się tam zmieścić. Magistrala w prostym systemie jest synchroniczna i blokuje procesor do momentu odpowiedzi/zakończenia.

    Napisz pętlę która tylko się kreci, z jakąś bardzo dużą liczbą cykli. Optymalizacja powinna zmienną lokalną utrzymać w rejestrze, jeśli nie to użyj dyrektywy "register". Zmierz czas jej wykonania machając pinem przed i po wykonaniu (nie w trakcie). Korzystając z listingu assemblerowego zobacz ile instrukcji wykonuje procesor i wtedy ci wyjdzie.
  • Poziom 38  
    Machaniem Pinem nie da się sprawdzić faktycznej prędkości. Większe prędkości machania pinem mógłbyś osiągnąć tylko na timerze. Wbrew pozorom zapalenie diody potrzebuje więcej niż jednego cyklu (przy softowym sterowaniu)
  • Poziom 8  
    michcior napisał:
    Oj, procesor wykonuje swoje operacje z prędkością taktowania. I na tym koniec. reszta zwykle ma swoją prędkość, wolniejszą od procesora. Wtedy procesor czeka aż się operacja wykona. Procesor wykonuje 1 instrukcję na cykl tylko wtedy gdy:
    1) Operacja nie wymaga użycia pamięci (chyba że wewnętrzna pamięć procesora, ARM'y czasami mają Tightly Coupled Memory)
    2) Procesor ma cache jednocyklowy i operacja nie wymaga odczytu/zapisu linii.
    3) Procesor robi nic - NOP (w ARMach<v7 nie ma instrukcji NOP)
    4) Nie musi wykonać skoku warunkowego, bo inaczej pip-line musi byś przeładowany. Chyba, że ma dobry branch-prediction,
    5) Nie zmienia trybu pracy (przerwanie albo inne tryby)

    Reszta operacji to po kilka i kilkanaście cykli. Poszeregowałbym to tak (od najszybszej): dostęp do RAM, dostęp do FLASH, dostęp do rejestrów (tzn. dostęp do peryferiów).

    Przecież z procesora wychodzi jedna magistrala i wszystko musi się tam zmieścić. Magistrala w prostym systemie jest synchroniczna i blokuje procesor do momentu odpowiedzi/zakończenia.


    Nie wiem czy dobrze zrozumiałem, ale zaczynam mieć coraz więcej wątpliwości czy dobrze zrobiłem wybierając CORTEX'a. Będę musiał napisać program sterujący który musi bardzo szybko wykonywać obliczenia (regulator PID). Wygląda na to, że aby uzyskać dużą szybkość działania należy zmienne umieszczać w rejestrach. Czy dobrze zrozumiałem?
    A co z obliczeniami na dużej ilości danych?
    Struktur do regulatora PID chyba nie uda mi się zmieścić w rejestrach.

    michcior napisał:
    Napisz pętlę która tylko się kreci, z jakąś bardzo dużą liczbą cykli. Optymalizacja powinna zmienną lokalną utrzymać w rejestrze, jeśli nie to użyj dyrektywy "register". Zmierz czas jej wykonania machając pinem przed i po wykonaniu (nie w trakcie). Korzystając z listingu assemblerowego zobacz ile instrukcji wykonuje procesor i wtedy ci wyjdzie.


    To co napisałem "macha nóżką" po obliczeniach. Najpierw wykonuję prostą pętlę "while", potem ustawiam stan nóżki przez rejestr FIOxVAL bo wpisanie FIOxCLR i FIOxSET nie daje żadnego efektu. Też nie wiem jeszcze dlaczego.
    Jedno co zauważyłem to, że zwiększanie pętli proporcjonalnie wydłuża trwanie impulsów o ok. 100ns na jeden "i++".
    Coś czuję, że będę żałował przejścia z dsPIC na CORTEX'a.:cry:
  • Specjalista - Mikrokontrolery
    No to jak będziesz żałował, bo pętla while() nie kręci się wystarczająco szybko, to wracaj i nawet się nie zastanawiaj. Jeśli uważasz, że rozwiązanie które przedstawiłeś można choć postawić obok frazy "test wydajności", to proponuję abyś taki sam test zrobił na tym dsPICu wyciągającym 2.5x mniejszą częstotliwość (nie mówiąc już nawet o szerokości danych [mniejszej] czy rozmiarach rozkazów [większych]) i daj nam znać czy dioda miga szybciej.

    Dodanie jednego obrotu pętli zwiększa Ci czas trwania całości o 100ns, czyli około 10cykli przy 100MHz. No i teraz tak, skoro "i" jest volatile (a zapewne jest, bo bez tego by ta pętla została skasowana) to na dzień dobry mamy odczyt i zapis do pamięci RAM. Potem jest inkrementacja, porównanie, i skok warunkowy. Przy optymistycznym założeniu, że adres zmiennej "i" i wartość max dla pętli jest w rejestrach, daje to 5 "operacji", przy odrobinie pesymizmu potrzebne będą jeszcze dwie "operacje" (ładowania adresu i wartości), co zależnie od przypadku wręcz może zająć dwa rozkazy albo cztery.

    Reasumując faktycznie tragedia, że 5-9 rozkazów wykonuje się 10 cykli zegarowych... Na dsPICu pewnie wykonałyby się w 2 cykle (w sumie wszystkie oczywiście). Pamiętaj tylko, żeby były te same warunki przy porównaniu, czyli żadnego assemblera i kosmicznych instrukcji typu REPEAT czy DO-WHILE.

    Rejestr FLASHCFG ustawiłeś, czy poprzestałeś na włączeniu PLLa?

    A na zakończenie tego wywodu chciałbym napisać, że podobne "testy wydajności" poprzez machanie jakimś pinem pojawiają się tu całkiem często i zawsze śmieszą mnie tak samo [;

    4\/3!!
  • Pomocny post
    Poziom 30  
    Zdecydowanie proponuję analizę kody wynikowego. Można się bardzo wiele nauczyć i zrozumieć co tak na prawdę robi kompilator i dlaczego coś działa albo nie. Najwyższa optymalizacja nie jest czasami najlepsza. Może być optymalizacja na prędkość lub rozmiar kodu. ARM'y mogą chodzić w trybie ARM(nieco szybszy) lub Thumb. Krytyczne kawałki najlepiej wyrzeźbić w assemblerze.
    Według mnie nie ma powodu do płaczu. Jak szybko ma liczyć ten PID?
  • PCBway
  • Poziom 33  
    Gdzieś wyczytałem że na ARM'ach od NXP można wyciągnąć do 15MHz przebiegu na GPIO z programowego sterowania.
  • Poziom 19  
    Poniżej masz benchmark z ST (Cortex M3) co do prędkości obliczenia PIDa:
    http://www.st.com/internet/com/TECHNICAL_RESO...CHNICAL_LITERATURE/USER_MANUAL/CD00208762.pdf

    Przy taktowaniu 72MHz jest to poniżej 1us. Osobiście używam PIDy w pętli do 2kHz, ile kolega musi mieć że Cortex miałby być za wolny? Próbowałem znaleźć podobny benchmark dla dsPIC niestety na szybko nie znalazłem.

    Cytat:
    A na zakończenie tego wywodu chciałbym napisać, że podobne "testy wydajności" poprzez machanie jakimś pinem pojawiają się tu całkiem często i zawsze śmieszą mnie tak samo [;

    Mnie również intryguje dlaczego dla ludzi wyznacznikiem prędkości CPU jest prędkość przemiatania pinem :).
  • Poziom 8  
    michcior napisał:
    Zdecydowanie proponuję analizę kody wynikowego. Można się bardzo wiele nauczyć i zrozumieć co tak na prawdę robi kompilator i dlaczego coś działa albo nie. Najwyższa optymalizacja nie jest czasami najlepsza. Może być optymalizacja na prędkość lub rozmiar kodu. ARM'y mogą chodzić w trybie ARM(nieco szybszy) lub Thumb. Krytyczne kawałki najlepiej wyrzeźbić w assemblerze.
    Według mnie nie ma powodu do płaczu. Jak szybko ma liczyć ten PID?


    Szacuję, że w mniej niż 60...80us muszę odczytać pomiary i obliczyć nastawy do następnego kroku.

    Dodano po 2 [minuty]:

    markosik20 napisał:
    Gdzieś wyczytałem że na ARM'ach od NXP można wyciągnąć do 15MHz przebiegu na GPIO z programowego sterowania.


    Gdzie w moim mailu przeczytałeś, że ja chcę wyciągnąć 15MHz na pinie?
    Jak na razie chciałem "pomachać nóżką" z częstotliwością ok 1kHz.
  • Poziom 33  
    nibbit napisał:

    Mnie również intryguje dlaczego dla ludzi wyznacznikiem prędkości CPU jest prędkość przemiatania pinem :).


    Bo to najszybsza i najprostsza metoda "sprawdzenia możliwości" :D. Sam na początku pamiętam jak to tak sprawdzałem i wtedy zmuszony byłem do weryfikacji uzyskanych wyników (zrozumienia działania rdzenia, podstaw ASM, szyn danych, peryferii etc.etc.).

    Jurek H. napisał:

    Jak na razie chciałem "pomachać nóżką" z częstotliwością ok 1kHz.


    O J..., jak się da 15MHz to dlaczego by się nie dało 1kHz?
    A bez podglądu w wygenerowany plik ASM to te wyliczone MIPS'y można do kosza....co najwyżej.
  • Poziom 8  
    markosik20 napisał:

    Bo to najszybsza i najprostsza metoda "sprawdzenia możliwości" :D. Sam na początku pamiętam jak to tak sprawdzałem i wtedy zmuszony byłem do weryfikacji uzyskanych wyników (zrozumienia działania rdzenia, podstaw ASM, szyn danych, peryferii etc.etc.).


    W rzeczy samej. Jest to najprostsza metoda do sprawdzenia szybkości procka. Zdaję sobie, oczywiście sprawę z ograniczeń hardweru. Kiedyś projektowałem i oprogramowywałem reflektometr i szybko zrezygnowałem z machania nóżkami do generowania krótkich impulsów. Zrealizowałem to na małym CPLD i było OK.

    Dodano po 1 [godziny] 13 [minuty]:

    Freddie Chopin napisał:
    No to jak będziesz żałował, bo pętla while() nie kręci się wystarczająco szybko, to wracaj i nawet się nie zastanawiaj. Jeśli uważasz, że rozwiązanie które przedstawiłeś można choć postawić obok frazy "test wydajności", to proponuję abyś taki sam test zrobił na tym dsPICu wyciągającym 2.5x mniejszą częstotliwość (nie mówiąc już nawet o szerokości danych [mniejszej] czy rozmiarach rozkazów [większych]) i daj nam znać czy dioda miga szybciej.

    Dodanie jednego obrotu pętli zwiększa Ci czas trwania całości o 100ns, czyli około 10cykli przy 100MHz. No i teraz tak, skoro "i" jest volatile (a zapewne jest, bo bez tego by ta pętla została skasowana) to na dzień dobry mamy odczyt i zapis do pamięci RAM. Potem jest inkrementacja, porównanie, i skok warunkowy. Przy optymistycznym założeniu, że adres zmiennej "i" i wartość max dla pętli jest w rejestrach, daje to 5 "operacji", przy odrobinie pesymizmu potrzebne będą jeszcze dwie "operacje" (ładowania adresu i wartości), co zależnie od przypadku wręcz może zająć dwa rozkazy albo cztery.

    Reasumując faktycznie tragedia, że 5-9 rozkazów wykonuje się 10 cykli zegarowych... Na dsPICu pewnie wykonałyby się w 2 cykle (w sumie wszystkie oczywiście). Pamiętaj tylko, żeby były te same warunki przy porównaniu, czyli żadnego assemblera i kosmicznych instrukcji typu REPEAT czy DO-WHILE.

    Rejestr FLASHCFG ustawiłeś, czy poprzestałeś na włączeniu PLLa?

    A na zakończenie tego wywodu chciałbym napisać, że podobne "testy wydajności" poprzez machanie jakimś pinem pojawiają się tu całkiem często i zawsze śmieszą mnie tak samo [;

    4\/3!!


    Ależ bardzo przepraszam, że swoim naiwnym (na początku napisałem wyraźnie że zaczynam przygodę z ARM) pytaniem uraziłem tak wielkiego GURU ARM jak Sam Freddi CH., ale chciałbym zauważyć, że jest to forum, na którym można zadawać nawet takie pytania. I one nie powinny dziwić takich wspaniałych znawców ARM jak szanowny kolega. Bo podejrzewam, że na początku swojej drogi w stronę ARM kolega miał być może nawet głupsze pytania niż to moje.
    Mam mało czasu na projekt, a miałem wątpliwości, które nawiasem mówiąc paru kolegów na tym forum rozwiało. Z przykrością muszę powiedzieć, że kolega Freddi nie jest w tej grupie. Jestem lekko zielony z ARM'ów. To fakt. Ale to jest raczej oczywiste. Inaczej bym nie pytał.
    Co do "machania nóżką" to nie widzę w tym nic śmiesznego. W końcu ta grupa ARM'ów jest mikrokontrolerami z peryferiami. Jedną z funkcji, prostych i łatwo mierzalnych jest nieszczęsne machanie nóżką. Wystarczy oscyloskop i procesor np. na płytce ewolucyjnej.
    Na koniec chciałbym koledze zwrócić uwagę, że nie wszyscy są tak mądrzy w tej kwestii jak kolega.
    Na nauczyciela to kolega się raczej nie nadaje. Przynajmniej nie z takim podejściem do pytań.
    Podobno nie ma głupich pytań....Są tylko głupie odpowiedzi.
  • Specjalista - Mikrokontrolery
    Jurek H. napisał:
    chciałbym zauważyć, że jest to forum, na którym można zadawać nawet takie pytania. I one nie powinny dziwić takich wspaniałych znawców ARM jak szanowny kolega.

    Zgadza się, tylko skąd to egocentryczne przeświadczenie, że Ty pierwszy te pytania zadajesz? Było już o to pytane nie raz, ani nie dwa razy - wystarczyło poszukać.

    Cytat:
    Bo podejrzewam, że na początku swojej drogi w stronę ARM kolega miał być może nawet głupsze pytania niż to moje.

    Wrong (;

    Cytat:
    Mam mało czasu na projekt, a miałem wątpliwości, które nawiasem mówiąc paru kolegów na tym forum rozwiało. Z przykrością muszę powiedzieć, że kolega Freddi nie jest w tej grupie.

    Pójdę później popłakać do kąta z tego powodu, dobra?

    Cytat:
    Co do "machania nóżką" to nie widzę w tym nic śmiesznego.

    Zapewne ze względu na swoją zieloność o której pisałeś wcześniej, bo nie wiem w jaki sposób machanie pinem można odnieść do czasu wykonywania obliczeń, nie mówiąc już o tym, że samo sformułowanie "MIPS" jest ogólnie mało sensowne, bo i AVR na 20MHz i dsPIC na 20MHz ma tych "MIPSów" 20, a chyba nie ma wątpliwości który z nich obliczy cokowiek szybciej, choć machać pinem będą tak samo szybko akurat? Gdyby teraz wziąć Cortex-M3 na te 20MHz, to on też miałby 20 "MIPSów", nóżką będzie machał wolniej, a większość rzeczy obliczy szybciej niż dwa poprzednie razem wzięte. Jeśli więc dalej nie widzisz nic śmiesznego w takich porównaniach, to nic nie jestem w stanie na to poradzić - zapewne przez brak talentu pedagogicznego.

    Cytat:
    W końcu ta grupa ARM'ów jest mikrokontrolerami z peryferiami. Jedną z funkcji, prostych i łatwo mierzalnych jest nieszczęsne machanie nóżką. Wystarczy oscyloskop i procesor np. na płytce ewolucyjnej.

    Definitywnie jest to "nieszczęsna" funkcja, bo sam pomyśl do jak krytycznych czasowo i wyjątkowo szybkich rzeczy używasz tej funkcji (żadnych timerów z PWMem, interfejsów, itp.!): zapalanie diody LED, machanie pinem CS w magistrali SPI, wejścia przycisków naciskanych przez użytkowników, ... Generalnie w 99% przypadków jakby max częstotliwość GPIO wynosiła 1kHz to nikomu by to nie przeszkadzało. Dla dalszego uświadomienia dlaczego funkcja ta jest nieszczęsna, chciałbym tylko powiedzieć, że w procesorze który masz w komputerze pewnie też można jakimś pinem machać ręcznie, obawiam się tylko, że byłoby to jeszcze wolniejsze niż na tym LPC, który na podstawie swoich doświadczeń określiłeś jako "wolny" - nie ma możliwości, żeby wyniki tego "testu" podsumować inaczej niż uśmiechem politowania.

    Cytat:
    Podobno nie ma głupich pytań....Są tylko głupie odpowiedzi.

    Inny słynny filozof na takie teksty odpowiada anegdotką - "A jak stanę okrakiem na torach tramwajowych i złapię drutów to pojadę jak tramwaj?"

    Takie porównania są śmieszne, przedewszystkim dlatego, że szybkość machania pinem regulowaną KRÓTKĄ pętlą opóźniającą chcesz odnieść do szybkości obliczeń. To prawie tak sensowne jak stwierdzenie, że dowolny_nowoczesny_samochód wcale nie ma (przykładowo) 150KM, bo maluch pali tyle samo benzyny, a koni ma dwadzieścia kilka, więc nie ma opcji, żeby ten samochód miał więcej niż 30KM. Takie stwierdzenia zapewne też nie byłyby dla Ciebie śmieszne. No cóż...

    4\/3!!
  • Poziom 8  
    Cytat:
    Zgadza się, tylko skąd to egocentryczne przeświadczenie, że Ty pierwszy te pytania zadajesz? Było już o to pytane nie raz, ani nie dwa razy - wystarczyło poszukać.

    Przed rozpoczęciem tematu sprawdziłem czy są jakieś podobne tematy na forum ARM. Jakoś nie znalazłem.
    Cytat:

    Cytat:
    Bo podejrzewam, że na początku swojej drogi w stronę ARM kolega miał być może nawet głupsze pytania niż to moje.

    Wrong (;

    Czyli już wszyscy wiedzą że mają do czynienia z absolutnym GURU i MISTRZEM.
    Cytat:

    Zapewne ze względu na swoją zieloność o której pisałeś wcześniej, bo nie wiem w jaki sposób machanie pinem można odnieść do czasu wykonywania obliczeń, ...

    Moje kolory są nie istotne, chyba że jesteś rasistą. Dla człowieka, którego stopień zadufania w sobie i swojej wiedzy absolutnej jest na tak wysokim poziomie faktycznie może nie być oczywiste, że machanie nóżką nie jest adekwatnym testem prędkości. I nie samą nóżką macham, a w pętlach można umieścić różne działania. Pozwala on w przybliżeniu zorientować się z jak szybkim procesorem mamy do czynienia. Machnięcie nóżką jest łatwo mierzalnym stanem, który przy zdaniu sobie sprawy z ograniczeń hardwer'u jest w niektórych sytuacjach wystarczający. Nie mam zamiaru otwierać przewodu doktorskiego na ten temat i nie interesuje mnie dokładny pomiar wydajności procesora. Z pierwszego posta i tytułu wątku wyziera w sposób dość oczywisty chęć zrozumienia pewnych rozbieżności. A sam tytuł wątku jest obliczony na prowokację, która ma doprowadzić do wyjaśnienia zauważonego faktu.
    Cytat:
    ... który na podstawie swoich doświadczeń określiłeś jako "wolny" - nie ma możliwości, żeby wyniki tego "testu" podsumować inaczej niż uśmiechem politowania.

    Nie określałem tego procka jako "wolny" tylko zadałem pytanie gdzie jest te 100MIPS.
    Cytat:

    Inny słynny filozof na takie teksty odpowiada anegdotką - "A jak stanę okrakiem na torach tramwajowych i złapię drutów to pojadę jak tramwaj?"

    I to ma być to głupie pytanie? To nie jest głupie pytanie. Ono tylko mówi o tym że człowiek który je zadał nie ma pojęcia o elektryczności. Ale z tonu tego pytania wynika raczej drwina niż brak wiedzy. A z mojego pytania nie wynika drwina tylko brak pewnej praktycznej wiedzy. Taka to drobna różnica.
    Cytat:
    Takie porównania są śmieszne, przedewszystkim dlatego, że szybkość machania pinem regulowaną KRÓTKĄ pętlą opóźniającą chcesz odnieść do szybkości obliczeń.

    Gdzie w moim pytaniu żeś zobaczył "że szybkość machania pinem" chcę "odnieść do szybkości obliczeń"????? Przeczytaj najpierw pytanie, zrozum je a potem odpowiadaj. Machanie pinem jest tylko "flagą", namacalnym stanem zakończenia operacji, a nie miernikiem!!! Pętla miała być miernikiem.
    Na koniec powstaje pytanie: jeśli nie chcesz odpowiadać to PO CO KOMENTUJESZ POSTY? A wyśmiewanie kogoś, że śmiał zadać pytanie przypomina mi szczeniackie wybryki, a nie dyskusje na poziomie.
  • Użytkownik usunął konto  
  • Admin grupy Projektowanie
    Proszę nie rozwijać tej przepychanki.

    Faktem jest że nowe procesory są nastawione na,
    współpracę z peryferiami na konkretnych interfejsach,
    interfejsy te są często sprzętowe i znajdują się wewnątrz uP,
    podłączone magistralami o szybkości zależnej od ich typu.
    Także budowanie interfejsu "on wire" w napisanej w software procedurze,
    staje się nieefektywne i warto stosować wbudowany sprzęt.

    Coś za coś, z prostych uP w których rejestr odpowiedzialny był za stan pinu,
    rozbudowały się do urządzeń na których można uruchomić system operacyjny,
    lecz nie można szybko "machać pinem"...

    Jurek H. nie przekreślaj tak szybko możliwości ARM,
    spróbuj wyzerować i wystartować licznik,
    wykonać krytyczną część kodu z PID,
    zatrzymać timer i wysłać wynik po RS-232 lub innym interfejsie.
    Znając częstotliwość taktowania licznika da to odpowiedź na pytanie o możliwości procesora.

    Weź też pod uwagę że na procesorach ARM możesz uruchomić,
    system czasu rzeczywistego gdzie poszczególne fragmenty kodu mogą być zadaniami o różnych priorytetach,
    może to również współdziałać z systemem przerwań, co daje duże możliwości i inne podejście do projektów na uP.
  • Specjalista - Mikrokontrolery
    Jurek H. napisał:
    Przed rozpoczęciem tematu sprawdziłem czy są jakieś podobne tematy na forum ARM. Jakoś nie znalazłem.

    Nie znaczy to, że ich nie ma...

    Cytat:
    I nie samą nóżką macham, a w pętlach można umieścić różne działania.

    Jakbyś je umieścił, to pewnie nie pisałbym tych postów, bo wtedy to miałoby jakieś zalążki sensu...

    Cytat:
    Pozwala on w przybliżeniu zorientować się z jak szybkim procesorem mamy do czynienia.

    Tyle tylko, że ten który przedstawiłeś na coś takiego nie pozwala i o tym jest dyskusja.

    Cytat:
    Machnięcie nóżką jest łatwo mierzalnym stanem, który przy zdaniu sobie sprawy z ograniczeń hardwer'u jest w niektórych sytuacjach wystarczający.

    Piszesz, że jesteś "zielony", a do tego zakładasz, że zdajesz sobie sprawę z ograniczeń hardware'u - widzisz tu konflikt?

    Cytat:
    Nie określałem tego procka jako "wolny"...

    "Wprost" może faktycznie nie, ale z treści postów o tym jaki to dsPIC szybszy i jak to żałujesz zmiany i jak to ARM się nie wyrobi można wyczytać coś innego.

    Cytat:
    ...tylko zadałem pytanie gdzie jest te 100MIPS.

    MIPS - Millions Instructions Per Second. Po pierwsze - w jaki sposób przełożyłeś wyniki Twoich testów na LICZBĘ INSTRUKCJI? Po drugie - gdzie wyczytałeś, że 1MHz = 1MIPS? Na początek tylko tyle. Potem przejdziemy do tego skąd pomysł, że pomiar przy użyciu krótkiej pętli można przełożyć na SEKWENCYJNĄ wydajność.

    Cytat:
    Gdzie w moim pytaniu żeś zobaczył "że szybkość machania pinem" chcę "odnieść do szybkości obliczeń"????? Przeczytaj najpierw pytanie, zrozum je a potem odpowiadaj. Machanie pinem jest tylko "flagą", namacalnym stanem zakończenia operacji, a nie miernikiem!!!

    Może stąd, że coś tam zmierzyłeś, wyliczyłeś z kosmosu, że to się przekłada na 10 "MIPSów", a następnie stwierdziłeś, że w takim razie ten układ nie wyrobi się w liczeniu PIDa (który przecież liczy się przy użyciu praktycznie pustej pętli while()...). Nadinterpretacja?

    Cytat:
    Pętla miała być miernikiem.

    Kiepski miernik == kiepski pomiar. Skala dokładności miernika (bardzo bardzo kiepska, ze względu na długość tej pętli i tak naprawdę brak wiedzy o tym z ilu faktycznie instrukcji się składa) jest zupełnie niedopasowana do tego co chcesz mierzyć (nanosekundy).

    4\/3!!
  • Moderator Mikrokontrolery Projektowanie
    Poza tym co pisał Freddy, to dla mnie megaśmieszne jest liczenie MISPSów (ze wszystkimi ograniczeniami) na podstawie pętli w C bez spojrzenia nawet na wygenerowany kod assemblerowy. Przy tym wróżenie z fusów to niemalże nauka ścisła.
  • Poziom 19  
    Możesz to zrobić np. wywołując jakieś przerwanie od timera (w Twoim wypadku można zastosować okres 60..80us o których pisałeś). Napisz po prostu swego PIDa umieść go w funkcji obsługi przerwania machnij nóżką w stan wysoki przed samym kodem PIDa, po zakończeniu kodu machnij końcówką w stan niski. Czas trwania stanu wysokiego będzie mniej więcej odpowiadał czasowi obliczeń. Nie jest to oczywiście dokładna metoda odzwierciedlająca sam czas obliczeń (dochodzą np. instrukcję zmiany stanu pinu, pobranie zmiennych i stałych z pamięci).
  • Poziom 35  
    Akurat na LPC17xx można szybko machać pinem, gdyż, jak się nxp pochwalił, GPIO jest na AHB. Chcesz programowo machać pinem? Enjoy:
    Kod: C
    Zaloguj się, aby zobaczyć kod

    Macha pinem P0.0 i kompiluje sie pod mdk-arm (embedded assembler).
    Pisane z głowy, ale raczej nie ma zonków.

    Jak chcesz jeszcze szybciej "programowo" machać pinem, użyj DMA...
  • Specjalista - Mikrokontrolery
    nsvinc napisał:
    mov r0,#0x2009
    lsl r0,#16
    mov r1,#0xC014
    orr r0,r0,r1

    Właśnie do tego wymyślono instrukcję MOVT, która ładuje 16-bitową wartość do górnej połowy rejestru [; Dokładnie tak samo wydajne jest ładowanie PC-relative.

    To tak apropo odwiecznej dyskusji, czy jest sens cokolwiek pisać w assemblerze (;

    Code:
    080001c0 <machaj>:
    
    }

    void machaj(void)
    {
       volatile uint32_t * ptr = 0x2009C014;
       uint32_t value = 0;
     80001c0:   f04f 0300    mov.w   r3, #0

       while(1)
       {
          *ptr = value;
     80001c4:   4a02         ldr   r2, [pc, #8]   ; (80001d0 <machaj+0x10>)
     80001c6:   6013         str   r3, [r2, #0]
          value ^= 1;
     80001c8:   f083 0301    eor.w   r3, r3, #1
     80001cc:   e7fb         b.n   80001c6 <machaj+0x6>
     80001ce:   bf00         nop
     80001d0:   2009c014    .word   0x2009c014

    Wygląda to tak samo na każdej optymalizacji poza -Os (no i poza -O0 oczywiście [; ), kiedy to kompilator decyduje się skakać o jedną instrukcję wcześniej, nie wiem czemu.

    4\/3!!
  • Poziom 35  
    Jak bym miał przed sobą tabelke UAL to bym nie pominął MOVT, pisałem z głowy...

    Jest sens pisać niektóre rzeczy w asmie, bo
    Code:
    hop:
    
    eor r1,#1
    str r1,[r0]
    b hop

    Mam pewne wątpliwości, że takie aż trzy instrukcje znalazły się dla pętli w kodzie wynikowym autora tego smutnego wątka. Jeśli mnie pamięć nie myli, to zajmą one aż 5 cykli zegara ;] Z czego wynika że siłą rzeczy pin bedzie chodzić szybciej niż biedne
    Cytat:

    Z tego co odczytałem na oscyloskopie (przebieg prostokątny ok. 1kHz)


    EDIT:
    patrząc na powyższy kod, wychodzi na to samo. No więc nadal jestem tym bardziej zdziwiony tym 1kHz... Bodajże 14MHz wyrabiał zwykły STM32F1 na swoim 72MHz zegarze, tak samo kod w asm, jak i C z -O3...
  • Specjalista - Mikrokontrolery
    No ale autor ma inne pętle, u niego jest coś w ten deseń:

    Code:
    080001bc <machaj>:
    

    void machaj(void)
    {
     80001bc:   b410         push   {r4}
       volatile uint32_t * ptr = 0x2009C014;
       register volatile uint32_t counter = 0;
     80001be:   2100         movs   r1, #0
          LED_bb = 0;
       }
    }

    void machaj(void)
    {
     80001c0:   b083         sub   sp, #12
       register volatile uint32_t counter = 0;
       uint32_t value = 0;

       while(1)
       {
          *ptr = 1;
     80001c2:   480e         ldr   r0, [pc, #56]   ; (80001fc <machaj+0x40>)
    }

    void machaj(void)
    {
       volatile uint32_t * ptr = 0x2009C014;
       register volatile uint32_t counter = 0;
     80001c4:   9101         str   r1, [sp, #4]
       uint32_t value = 0;

       while(1)
       {
          *ptr = 1;
     80001c6:   2401         movs   r4, #1
          while(counter < 10000) { counter++; }
     80001c8:   f242 730f    movw   r3, #9999   ; 0x270f
       register volatile uint32_t counter = 0;
       uint32_t value = 0;

       while(1)
       {
          *ptr = 1;
     80001cc:   6004         str   r4, [r0, #0]
          while(counter < 10000) { counter++; }
     80001ce:   9a01         ldr   r2, [sp, #4]
     80001d0:   429a         cmp   r2, r3
     80001d2:   d805         bhi.n   80001e0 <machaj+0x24>
     80001d4:   9a01         ldr   r2, [sp, #4]
     80001d6:   3201         adds   r2, #1
     80001d8:   9201         str   r2, [sp, #4]
     80001da:   9a01         ldr   r2, [sp, #4]
     80001dc:   429a         cmp   r2, r3
     80001de:   d9f9         bls.n   80001d4 <machaj+0x18>
          counter = 0;
     80001e0:   9101         str   r1, [sp, #4]
          *ptr = 0;
     80001e2:   6001         str   r1, [r0, #0]
          while(counter < 10000) { counter++; }
     80001e4:   9a01         ldr   r2, [sp, #4]
     80001e6:   429a         cmp   r2, r3
     80001e8:   d805         bhi.n   80001f6 <machaj+0x3a>
     80001ea:   9a01         ldr   r2, [sp, #4]
     80001ec:   3201         adds   r2, #1
     80001ee:   9201         str   r2, [sp, #4]
     80001f0:   9a01         ldr   r2, [sp, #4]
     80001f2:   429a         cmp   r2, r3
     80001f4:   d9f9         bls.n   80001ea <machaj+0x2e>
          counter = 0;
     80001f6:   9101         str   r1, [sp, #4]
       }
     80001f8:   e7e8         b.n   80001cc <machaj+0x10>
     80001fa:   bf00         nop
     80001fc:   2009c014    .word   0x2009c014


    No i muszę przyznać, że raczej kompilatora nie da rady zmusić, żeby wartość licznika przechowywał w rejestrze, ale nie jest to wada, bo jaki ma cel przyspieszenie wykonywania funkcji opóźniającej? (;

    Tak czy siak instrukcji jest baaaaardzo sporo, w assemblerze w istocie można by zejść do sporo mniejszych ilości.

    4\/3!!
  • Poziom 38  
    A może kolega doświadczył aliasingu? :)
  • Poziom 35  
    No to nie rozumiem. Autor napisał kod który według niego ma benchmarkować procesor, ale zrobił to tak, aby to wykonywało się najwolniej jak tylko możliwe, a potem dziwi się, że benchmark daje śmieszne wyniki?...

    Benchmark: częstotliwość machania pinem
    Kod benchmarka: machanie pinem z pętlami opóźniającymi
    wtf?...
  • Poziom 8  
    LUUUDZIE! Nie o to mi chodziło w tym wątku.
    Może napiszę jednak parę zdań wyjaśnienia.
    Siadłem po raz pierwszy do płytki z LPC1768. Chcąc "poczuć tą moc" postanowiłem napisać coś co pozwoli mi się zorientować
    (i to jest słowo klucz w całej tej sprawie) czy rdzeń działa z taką częstotliwością jaką ustawiłem. Więc siadłem i napisałem kawałek kodu, który akurat do głowy mi przyszedł. Uruchomiłem i miałem wątpliwości.
    Z wątpliwościami mogłem zwrócić się do pana Google, albo spytać się mądrzejszych od siebie. Wybrałem to drugie.
    Otrzymałem odpowiedź. Tylko nie wiedzieć czemu paru z tych mądrych zamiast wyjaśnić ludzkim językiem, gdzie jest błąd w rozumowaniu
    zechciało dowartościować swoje ego i zrugać mnie za to, że śmiem zadawać takie głupie, z ich punktu widzenia, pytanie. Tego to ja strasznie nie lubię.
    Zawsze odpowiadam na pytania choćby i te które wydają mi się oczywiste.
    Jeśli, ktoś kto mnie nie zna, nie wie co potrafię, kim jestem, ocenia mnie negatywnie to zaczynam się trochę burzyć.
    Może nie potrzebnie dałem się wciągnąć w przepychanki słowne z Freddim.

    Gdyby z tego mojego "wróżenia z fusów" wyszedł wynik 30...40MIPS nie było by sprawy. Ale, że on różnił się od spodziewanej wartości ok. 10 razy, to się zapytałem.

    Co do "machania nóżką" to w przypadku procesorków AVR, '51 i dsPIC ten test daje prawie 100% dokładność obliczenia prędkości CPU.
    Prawdą jest, że do dokładnych obliczeń trzeba przeanalizować kod assemblera. Ale to wydawało mi się raczej oczywiste. Ja chcę orientacyjną informację.
    NIE CHCĘ ROBIĆ TESTU WYDAJNOŚCI PROCESORA! Skoro metoda sprawdza się na mikrokontrolerach 8 i 16 bitowych to założyłem, że na ARM'ach też może dać rozsądne wyniki.
    Ten test ma taki sam sens jak wciskanie pedału gazu w stojącym samochodzie z odpalonym silnikiem. Chcę poczuć tą MOC, posłuchać pracy silnika nie wyjeżdżając z parkingu. Spodziewałem się wielkiego BRRRRUUUM!, a tu wyszło małe bzzzyk.
    Jak się okazało ta moc objawia się dopiero w "trasie". Wystarczyło to powiedzieć i nie było by sprawy.
    Co z resztą kilka osób uczyniło i to "ludzkim językiem". Za co im dziękuję.

    Jak widzę wątek zaczyna żyć własnym życiem. Swoją drogą warto poznać ARM w tej jak widać mało zbadanej dziedzinie. Kiedyś do projektu reflektometru (to jest coś w rodzaju radaru tylko jednowymiarowego) potrzebowałem generować krótkie impulsy rzędu 6...10ns. Próbowałem to zrobić na procku. Niestety nie dało się. Naj krótszy czas jaki udało mi się uzyskać to było 20ns na procesorze Cyan Technology eCOG1X. Ale to było za długo. Musiałem niestety dołożyć jeszcze CPLD do układu i śmiga do dziś. Generuje impulsy 6ns/18V na R=100R bez żadnych drogich buforów wyjściowych.
    Jak widać procesory nie służą tylko do sterowania diodami LED, testowania przycisków czy sterowania LCD nie wspominając o obliczeniach.
    HEJ
  • Specjalista - Mikrokontrolery
    Jurek H. napisał:
    Zawsze odpowiadam na pytania choćby i te które wydają mi się oczywiste.

    Biorąc pod uwagę, że masz aż 7 postów na forum i wszystkie są w tym temacie ja osobiście powstrzymam się od oceniania Cię jako osoby wysoce pomocnej itd.

    Cytat:
    Co do "machania nóżką" to w przypadku procesorków AVR, '51 i dsPIC ten test daje prawie 100% dokładność obliczenia prędkości CPU.

    Chętnie zobaczę tą 100% dokładność. Wystarczy że przedstawisz wyniki i ich interpretację.

    Cytat:
    Prawdą jest, że do dokładnych obliczeń trzeba przeanalizować kod assemblera. Ale to wydawało mi się raczej oczywiste.

    Nam też wydawało się oczywiste, mniej oczywiste jest to, czemu tego nie zrobiłeś? Assemblera masz nawet powyżej, przeanalizuj sobie teraz i zastanów się nad wynikiem który osiągnąłeś oraz jego dokładnością.

    Cytat:
    Ja chcę orientacyjną informację.

    Orientacyjną informację już masz - pomachałeś pinem i wyszło Ci z tego orientacyjne "10MIPSów". Ma być mniej czy więcej żeby wynik Cię zadowalał?

    Cytat:
    NIE CHCĘ ROBIĆ TESTU WYDAJNOŚCI PROCESORA! Skoro metoda sprawdza się na mikrokontrolerach 8 i 16 bitowych to założyłem, że na ARM'ach też może dać rozsądne wyniki.

    Transkrypcja: Nie chcę robić testu wydajności. Ta metoda testowania wydajności sprawdzała się na 8- i 16-bitowych mikrokontrolerach, to zrobiłem ten test też na 32-bitowym licząc na rozsądny wynik.

    Do tego mam więc dwa pytania:
    1. Co Ty w zasadzie chcesz? Bo ja już się zgubiłem - najpierw chcesz poczuć moc, potem nie chcesz robić testu wydajności, no to ja nie kumam...
    2. Ile to jest "rozsądny wynik"?

    Cytat:
    Ten test ma taki sam sens jak wciskanie pedału gazu w stojącym samochodzie z odpalonym silnikiem. Chcę poczuć tą MOC, posłuchać pracy silnika nie wyjeżdżając z parkingu. Spodziewałem się wielkiego BRRRRUUUM!, a tu wyszło małe bzzzyk.

    Jeśli dla Ciebie przejawem mocy jest hałas silnika (machanie pinem), to chyba nikt z "niedowartościowanych lamerów" tego forum nie będzie Ci w stanie pomóc... Może założysz sobie nakładkę na wydech (powielacz częstotliwości na wyjściu), to "moc" wzrośnie?

    Cytat:
    Kiedyś do projektu reflektometru (to jest coś w rodzaju radaru tylko jednowymiarowego) potrzebowałem generować krótkie impulsy rzędu 6...10ns. Próbowałem to zrobić na procku. Niestety nie dało się. Naj krótszy czas jaki udało mi się uzyskać to było 20ns na procesorze Cyan Technology eCOG1X. Ale to było za długo.

    Kreujesz się na wielkiego znawcę, a z tego co piszesz wynika coś zupełnie przeciwnego! Opanuj się! Do wygenerowania programowych impulsów 6-10ns na mikrokontrolerze potrzebowałbyś układu o taktowaniu 100 - 170MHz (no i zerowym opóźnieniu między zegarem a portami wyjściowymi), więc jak może Cię dziwić, że nie udało się to na eCOGu, który wg strony producenta ma 70MHz? No chyba że ja nie umiem liczyć, ale jestem całkiem pewny, że okres przebiegu 100MHz wynosi 10ns.

    Tak czy siak taki przebieg da się wygenerować na ARMie z tego tematu (oczywiście 10ns, a nie 6), tyle że to trzeba sięgnąć swoją wielką wiedzą nieco dalej niż do GPIO, bo aż do timerów i PWM. Zupełnie inną sprawą będzie kształt tego przebiegu przypominający w najlepszym wypadku trójkąt.

    4\/3!!
  • Moderator Mikrokontrolery Projektowanie
    No ba, taki przebieg da się też wygenerować zwykłym AVR (XMega), który może popędzać timery z zegarem 128MHz. Można go też wygenerować banalnie za pomocą 3 bramek AND/NAND, czy co tam pasuje, ale żeby zareaz CPLD?
    BTW, jak już autor pisze co go wkurza to ja też dodam co mnie denerwuje - ludzie, którzy zamiast powiedzieć zrobiłem głupotę, wybaczcie, idzie w zaparte i udowadnia swoje bezsensowne racje.
  • Poziom 8  
    Cytat:

    Do tego mam więc dwa pytania:
    1. Co Ty w zasadzie chcesz?Bo ja już się zgubiłem - najpierw chcesz poczuć moc, potem nie chcesz robić testu wydajności, no to ja nie kumam...

    odsyłam=>
    Cytat:
    ... czy rdzeń działa z taką częstotliwością jaką ustawiłem.

    Cytat:

    2. Ile to jest "rozsądny wynik"?

    odsyłam=>
    Cytat:
    Gdyby z tego mojego "wróżenia z fusów" wyszedł wynik 30...40MIPS nie było by sprawy.
  • Poziom 35  
    dsPIC z serii GS jest w stanie generować PWMy z rozdzielczością lepszą niż 10ns (nie pamietam dokładnie, ale chyba 4ns). IMHO uzywanie CPLDka do tego samego, co potrafią zrobić mikrokontrolery, jest bez sensu...

    Sprawdzenie
    Cytat:
    czy rdzeń działa z taką częstotliwością jaką ustawiłem

    przez machanie pinem...no już dostałeś odpowiedź do czego to prowadzi. Dziwne jest tylko, że to samo robiłeś w inne procki i na nich wyniki były takie jak sobie wymysliłeś. Siłą rzeczy na dsPICu 40MHz nie ma szans aby machać programowo pinem z 20MHz...

    No i jakiego typu testem jest, napisać kod który macha pinem z pętlami opóźniającymi, a potem narzekać, że pin jest powoli machany? Nadal nie odpowiedziałeś rzeczowo i sensownie na pytania, jakie ci tutaj postawiono...

    Jurek H. napisał:
    Kiedyś do projektu reflektometru (to jest coś w rodzaju radaru tylko jednowymiarowego) potrzebowałem generować krótkie impulsy rzędu 6...10ns. Próbowałem to zrobić na procku. Niestety nie dało się. Naj krótszy czas jaki udało mi się uzyskać to było 20ns na procesorze Cyan Technology eCOG1X.

    Ale czemu te impulsy musiały być generowane programowo? Przecież od tego są peryferia... A ty i tak zrobiłeś dodatkowe, zbędne peryferium w postaci CPLD...
  • Użytkownik usunął konto