Elektroda.pl
Elektroda.pl
X
Tektronix
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?

Jurek H. 01 Paź 2011 18:27 4640 49
  • #31
    nsvinc
    Poziom 35  
    U mnie nie działa, sprawdziłem ;] Przynajmniej wykonując kod z C, asma nie sprawdzałem...
  • Tektronix
  • #32
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #33
    Jurek H.
    Poziom 8  
    nsvinc napisał:
    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...

    No i tu masz w pełni rację. Gdybym miał ten procesor 7 czy 8 lat temu gdy projektowałem ten reflektometr to na pewno bym go użył.

    Cytat:
    Sprawdzenie czy rdzeń działa z taką częstotliwością jaką ustawiłem
    przez machanie pinem...no już dostałeś odpowiedź do czego to prowadzi.

    Już mnie zmęczyło to tłumaczenie. Dlaczego niektórzy z Was czytają z jakimiś klapkami na oczach. Proszę przeczytać uważnie to co napisałem i nie wmawiać mi, że chcę zmierzyć coś przy pomocy machania nóżką. Tłumaczyłem już czym ma być machanie nóżką.

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

    Ja bardzo proszę, przeczytaj najpierw porządnie co pisałem w wątku i jakie zadałem pytanie i na co narzekałem.

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

    Nie chcę tłumaczyć jak działa reflektometr. Odsyłam do google. Do prawidłowego działania jest tam niezbędna pełna kontrola momentu generowania impulsu oraz regulacja szerokości impulsu z bardzo dużą stabilnością. Dlatego zrobienie tego na bramkach odpada. Ja wykorzystałem do tego sygnał z generatora (620MHz) istniejącego w inne części układu. Po przejściu przez jeszcze inny układ: deserializera, wykorzystywanego w szybkim przetworniku ADC miałem już gotowe impulsy ok. 6.4ns. Musiałem je zliczać w CPLD, które służyło jako regulowany generator impulsów w zakresie od 6.4ns do (o ile dobrze pamiętam) 240ns.
  • #34
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Jurek H. napisał:
    Już mnie zmęczyło to tłumaczenie. Dlaczego niektórzy z Was czytają z jakimiś klapkami na oczach. Proszę przeczytać uważnie to co napisałem i nie wmawiać mi, że chcę zmierzyć coś przy pomocy machania nóżką. Tłumaczyłem już czym ma być machanie nóżką.

    A wiesz jak nas już zmęczyło tłumaczenie Ci na czym polega Twój błąd? Niemniej jednak - choć wysiłek jest zbiorowy - Ty dalej w zaparte idziesz, że ten test ma jakikolwiek sens.

    Zrobiłeś jakiś kod w C. Zmierzyłeś ilość impulsów czy tam ich okres czy cokolwiek. Strzeliłeś jakąś liczbą z kosmosu ("10 MIPSów"), oczekując (oczywiście założenie znów z kosmosu) 3-4x tyle. Zrozum, że te Twoje "wyliczone" / "zmierzone" (w rzeczywistości co najwyżej "wywróżone") "MIPSy" z rzeczywistością nie mają N-I-C wspólnego. Nie odniosłeś czasu obiegu pętli (tego co faktycznie zmierzyłeś) do ilości instrukcji assemblera. To jest tutaj podstawowym błędem, który pokazuje, że w ogóle nie wiesz co mierzysz. Nie odniosłeś tego do czasu wykonywania tych instrukcji, choć to akurat można Ci darować - większość instrukcji i tak wykonuje się jeden cykl, poza skokami i dostępem do rejestrów peryferyjnych. Innymi słowy liczba którą "zgadłeś" nie ma po prostu żadnego sensu, porównywanie jej z czymkolwiek jest "błędem założenia", podobnie jak narzekanie na "słabość" ARMów na podstawie tych "testów".

    Proponuję inny świetny test: Weź dwa komputery PC - jeden z DOSem (totalny staroć), drugi z najnowszym Windowsem i czterema rdzeniami. Na obydwóch uruchom program, który w kółko będzie wyświetlał jedną linijkę tekstu - w DOSie oczywiście "natywnie", w Windowsie w konsoli lub w pełnoekranowej emulacji. Sprawdź na którym tekst będzie się pojawiał szybciej i ogłoś światu, że 486 wygrywa z 64-bitowymi wielordzeniowymi procesorami o kilka rzędów wyższej częstotliwości taktowania. Wszelkie próby tłumaczenia dlaczego ten test jest głupi, bezsensowny i niczego nie udowadniający określ "wyładowywaniem swojej frustracji" podkreślając przy tym, że masz "wielkie doświadczenie w informatyce" i nie będziesz słuchał "zakompleksionych małolatów z forum".

    Jak to nie jest prowokacja, to ja się chyba poddaję.

    To co ktoś wcześniej Ci wytłumaczył (za co pięknie podziękowałeś), że dostęp do rejestrów peryferyjnych jest wolniejszy, nie ma nic wspólnego z Twoimi abstrakcyjnymi "obliczeniami" i "metodami" testowymi, bo masz błąd w samych założeniach. Żaden procesor nie wykonuje instrukcji języka C i w żadnym ilość instrukcji C nie ma przełożenia 1:1 na ilość MIPSów. Do tego samo pojęcie MIPSów jest totalnie bezsensowne tak naprawdę, bo przecież 1 MIPS na 8-bitach to raczej nie 1 MIPS na 32-bitach, nie mówiąc już o zestawie instrukcji (np. mnożenie, dzielenie, instrukcje DSP, ...). Jestem 100% pewny, że te "testy" które przeprowadzałeś na AVR czy innych układach dały gorsze wyniki niż na ARMie (no chyba że porównujesz ARMa na 1MHz z AVRem na 20, to wtedy w takim teście faktycznie AVR mógłby "wygrać"). To co pokazujesz tutaj to jest jakaś parodia!

    Prawdziwym wyznacznikiem mocy są np DMIPSy czy FLOPsy i gwarantuję Ci, że AVRy czy dsPICe są o kilka rzędów wielkości wolniejsze niż Cortex-M3. Do tego mówimy o wydaności na MHz, więc niezależnej od częstotliwości, bo tutaj też (niespodzianka!) Cortex wygrywa z każdym innym rdzeniem który wymieniłeś.

    4\/3!!
  • #35
    gaskoin
    Poziom 38  
    Sprawdzenie
    Cytat:
    czy rdzeń działa z taką częstotliwością jaką ustawiłem


    robi się timerem a nie w kodzie, skoro raczkujesz i gubisz się w peryferiach ARM to warto uruchomić cortexowy systick bo jest bardzo prosty w konfiguracji.

    Jak koledzy już milion razy napisali, żeby oszacować czy faktycznie działa tak jak napisałeś to musiałbyś znać czas wykonywania każdej instrukcji (czas = liczba cykli) sprawdzić ile takich instrukcji assemblerowych się wykonuje w Twoim kodzie i dopiero potem stwierdzić, że CM3 jest beznadziejny. Oczywiście nie można zapominać, że niektóre rozkazy w zależności kiedy są wykonywane, na niektórych procesorach czasem mogą się wykonać szybciej czasem wolniej (najlepszym przykładem są instrukcje MAC)
  • #36
    Jurek H.
    Poziom 8  
    Freddie Chopin napisał:
    {...} - Ty dalej w zaparte idziesz, że ten test ma jakikolwiek sens.

    Hmmm.
    To wróćmy się trochę. Wcześniej pisałem że jedna inkrementacja pożera 100ns.
    Zacytujmy Twój kod:
    Freddie Chopin napisał:
    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>

    bo mniej więcej gdzieś tutaj jest te i++. Teraz należy powiedzieć sobie ile to może kosztować cykli zegara. Sam stwierdziłeś wcześniej że, jak to ładnie ująłeś:
    Freddie Chopin napisał:

    ... faktycznie tragedia, że 5-9 rozkazów wykonuje się 10 cykli zegarowych...

    Reasumując 100ns/10=10ns co daje 100MHz. I o to mi chodziło. Bo cały ten test mniał mnie tylko upewnić czy PLL chodzi z tą częstotliwością jaką ustawiłem.

    Freddie Chopin napisał:

    Nie odniosłeś czasu obiegu pętli (tego co faktycznie zmierzyłeś) do ilości instrukcji assemblera. To jest tutaj podstawowym błędem, który pokazuje, że w ogóle nie wiesz co mierzysz.
    I tutaj masz nie stety (dla mnie) rację. Gdybym najpierw przeanalizował kod, nie było by w ogóle tego prowokacyjnego pytania. Trochę się pośpieszyłem. Sorry.

    I teraz już na spokojnie: czy można tak to zmierzyć?
    Mi się wydaje że tak. I to nie wynika z mojego uporu.
    Pamiętając o tym że każda zmiana M czy N w PLL powoduje znaczące różnice w częstotliwości pętli, oszacowanie (bo nie są to bardzo dokładne obliczenia, nie o takie tu chodzi) daje możliwość, graniczącą z pewnością, że zegar chodzi tak jak ja chcę. Jeżeli się mylę, to proszę o wyjaśnienie (na spokojnie) gdzie.
  • Tektronix
  • #37
    nsvinc
    Poziom 35  
    Jurek H. napisał:
    I teraz już na spokojnie: czy można tak to zmierzyć?

    Można, przecież już przedmówcy o tym pisali. Cały bajer polega na tym, że można wróżyć z fusów mając fusy, a nie kilo zgniłych jabłek. Znając kod asemblera, architekturę procesora i częstotliwość machania pinem, możesz z jakimś niezerowym błędem oszacować czy kolejne instrukcje wykonują się w takim czasie, jak powinny...

    Jurek H. napisał:
    Pamiętając o tym że każda zmiana M czy N w PLL powoduje znaczące różnice w częstotliwości pętli, oszacowanie (bo nie są to bardzo dokładne obliczenia, nie o takie tu chodzi) daje możliwość, graniczącą z pewnością, że zegar chodzi tak jak ja chcę.

    Jeśli wpisujesz w SFR według manuala to co ty chcesz, to procesor będzie pracował tak jak ty chcesz. O ile prawidłowo ustawisz SFRy. Jeśli prawidłowe ustawianie SFRów nie prowadziłoby do tego, że procesor pracuje według twoich wymagań - to byłoby o tym w erracie.

    Jurek H. napisał:
    Jeżeli się mylę, to proszę o wyjaśnienie (na spokojnie) gdzie.

    Trochę się mylisz, ponieważ test można przeprowadzić inaczej, uzyskując wyniki ze znikomym błędem.
    Wystarczy wygenerować kod, który będzie zawierał w sobie np. 3k pojedyńczych instrukcji add r0,#1 jedna po drugiej, na początku tego bloku włączyć timer, na końcu bloku wyłączyć timer, i odczytać wartość timera. Jeśli timer będzie robił "cyk" co 10ns, i odpowiednio przygotujesz kod, to mniej więcej z taką dokładnością (+1 str na koniec) będziesz wiedział jak szybko wykonało się x rozkazów add.
    Code:

    mov r2,(adres sfra lsw)
    movt r2,(adres sfra msw)
    mov r3,(liczba do sfra włączająca timer)
    mov r4,(liczba do sfra wylaczajaca timer)
    str r3,[r2] ;dokladnie tu odpala sie timer
    add r1,#1 ;pierwsza instrukcja "benchmarkująca"
    add r1,#1
    ....
    add r1,#1 ;ostatnia instrukcja "benchmarkująca"
    str r4,[r2] ;zatrzymaj timer

    Wartość timera będzie odpowiadać czasowi wykonywania się add'ów z błędem wynikającym z czasów wykonania str'ów (mniej więcej)
  • #38
    Jurek H.
    Poziom 8  
    nsvinc napisał:

    Jeśli wpisujesz w SFR według manuala to co ty chcesz, to procesor będzie pracował tak jak ty chcesz. O ile prawidłowo ustawisz SFRy.

    Ja w pełni wierzę manualowi, ale nie wierzę sobie do póki nie wyczuję procesora. To są moje pierwsze kroki z konfiguracją PLL w CORTEX'e i wolę sam siebie sprawdzić.

    nsvinc napisał:

    Wystarczy wygenerować kod, który będzie zawierał w sobie np. 3k pojedyńczych instrukcji add r0,#1 jedna po drugiej, na początku tego bloku włączyć timer, na końcu bloku wyłączyć timer, i odczytać wartość timera. Jeśli timer będzie robił "cyk" co 10ns, i odpowiednio przygotujesz kod, to mniej więcej z taką dokładnością (+1 str na koniec) będziesz wiedział jak szybko wykonało się x rozkazów add.
    [....]
    Wartość timera będzie odpowiadać czasowi wykonywania się add'ów z błędem wynikającym z czasów wykonania str'ów (mniej więcej)

    Oi,........... coś mi się to nie podoba. Wybacz, ale przypomina mi to metodę barona Minchauzena. Obawiam się, że w timerze będziesz miał tylko liczbę cykli (co do ilości nie jakości) zegara, którego i tak (w moim wypadku) nie będziesz pewien. Chyba raczej nie da się zmierzyć częstotliwości zegara wykorzystując do tego ten sam zegar. Chyba, że ja czegoś nie rozumiem.:|
    Chyba, że wyprowadzisz ten interwał przy pomocy np. machania nóżką na zewnątrz i zmierzysz go niezależnym miernikiem np. oscyloskopem. Ale ta metoda nie wiele będzie się różniła od mojej.:cry:
    I znowu wróciliśmy do machania nóżką. Jak w Mulę Róż.
  • #39
    nsvinc
    Poziom 35  
    Do metod Münchhausena to temu daleeeko... ;] Może i jest pewna analogia, gdyż przykład który podałem zwróci właściwy wynik jeśli dokładnie wiesz, jak szybko chodzi timer...

    Skoro ty chcesz tylko i wyłącznie przekonać się, czy PLL chodzi tak jak powinien, to może nie warto tutaj w ogóle sugerować się rdzeniem i jak on macha pinem, tylko włączyć timer bez preskalera i kazać mu generować prostokąt na swoim wyjściu. Wystarczy użyć trybu Output Compare+auto reload, aby generować przebieg. Timer będzie również o tyle lepszy, że ty jesteś w stanie obliczyć i skonfigurować go tak, aby wypluwał konkretną częstotliwość, a następnie ten przebieg badasz oscylem. Jeśli na oscylu widzisz tą częstotliwość, którą chciałeś, oznacza to ze zegar tego timera jest taki jak chciałeś, czyli PLL tez najpewniej generuje taką częstotliwość jak chciałeś...
    Nadal imho zmuszanie rdzenia do takich operacji nie da wyników którym możnaby zaufać w tej sprawie.
  • #40
    Jurek H.
    Poziom 8  
    nsvinc napisał:
    ...tylko włączyć timer bez preskalera i kazać mu generować prostokąt na swoim wyjściu.......a następnie ten przebieg badasz oscylem.

    Oooo. I to wygląda całkiem do ludzi.
    Co prawda, zmusza mnie do zagłębienia się w dokumentację (trzeba skonfigurować odpowiednie rejestry), w której i tak już "utonąłem". CORTEX to jednak kolubryna, którą trudno zgłębić jednym chełstem. Za pierwszym podejściem to łatwiej mi było machać nóżką. Było to prostsze. Nie trzeba było się tak zagłębiać w dokumentację. Ale od tego machania trochę sobie przykopałem w szczękę. :)
  • #41
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Prostsza opcja:
    Biorąc pod uwagę fakt, że praktycznie każdy nowszy mikrokontroler po resecie chodzi z jakimśtam zegarem wewnętrznym (w tym przypadku chyba 4 albo 8MHz). Proponuję obliczenia przez porównanie. Odpalasz swój kod machający pinem z opóźnieniami BEZ jakichkolwiek ustawień częstotliwości czy czegokolwiek. Wychodzi Ci częstotliwość x. Dokładasz włączenie PLLa, pomiar, wychodzi ci y. Obliczasz częstotliwość po ustawieniu PLLa jako:
    x/y=4MHz/freq (jeśli częstotliwość startowa to 4MHz).

    Generalnie błąd czegoś takiego powinien być znikomy. Pamiętaj tylko o włączeniu akceleratora pamięci flash PRZED przestawieniem zegara mikrokontrolera. Możesz też w manualu upewnić się, że po resecie flash ustawiony jest na najbardziej optymalną wartość dla częstotliwości startowej (czasem ustawiony jest na "worst case").

    4\/3!!
  • #42
    michalko12
    Specjalista - Mikrokontrolery
    Jeszcze prościej można

    User manual - strona 66 napisał:
    4.10 External clock output pin

    For system test and development purposes, any one of several internal clocks may be
    brought out on the CLKOUT function available on the P1.27 pin, as shown in Figure 12.

    Clocks that may be observed via CLKOUT are the CPU clock (cclk), the main oscillator
    (osc_clk), the internal RC oscillator (irc_osc), the USB clock (usb_clk), and the RTC clock
    (rtc_clk).
  • #43
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Tyle że zwykle są tam ograniczenia częstotliwości - w STM32 max co można wypuścić na ten pin to 50MHz. Może w LPC17xx jest inaczej, ale trochę wątpię (;

    4\/3!!
  • #44
    michalko12
    Specjalista - Mikrokontrolery
    Freddie Chopin napisał:
    Tyle że zwykle są tam ograniczenia częstotliwości - w STM32 max co można wypuścić na ten pin to 50MHz. Może w LPC17xx jest inaczej, ale trochę wątpię (;

    4\/3!!

    Pewnie dlatego jest jeszcze dzielnik po drodze [;
  • #45
    Jurek H.
    Poziom 8  
    To mamy cztery metody.
    1. metoda michalko12 - wygląda na bardzo dokładną
    2. metoda nsvinc - oparta o PWM wygląda na bardzo dokładną
    3. metoda Feddiego - oparta o zmodyfikowany metodę Moulin Rouge - wygląda na dokładną
    4. i moją - metodę Mouline Rouge prymitywną - czyli niedokładną
    OK. To chyba wystarczy. Dzięki.

    Tak przy okazji, mam jeszcze jeden problem techniczny. I nie jest to żadna prowokacja.
    Mam problem z układem, który zaprojektowałem na CORTEX'e. Wzorowałem go na kilku płytkach prototypowych, których schematy znalazłem w sieci więc raczej nie ma tam błędu układowego. Efekt jest następujący:
    Płytka działa z podpiętym JTAG'iem. Jak wyłączę zasilanie, wyjmę wtyczkę JTAG i zasilę ponownie to CPU nie chce ruszyć. Aby ruszyła, trzeba ręcznie resetować procesor. Sygnał resetu jak we wszystkich schematach z LPC1768 wisi w powietrzu. Próbowałem go podpinać do +VCC przez opornik 12k, ale to nic nie daje. Bez resetu ręcznego nie rusza. Czy ktoś może podrzucić jakiś pomysł co się dzieje? Może trzeba jeszcze coś ustawić w jakimś rejestrze konfiguracyjnym?
  • #46
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Bardzo możliwe, że włącza się jakiś BOD albo coś takiego, bo masz zbyt wolne narastanie napięcia zasilającego. Pomóc może kondensator od resetu do masy - oczywiście standardowe 100n - wraz z rezystorem podciągającym - standardowe 10k.

    Generalnie ja celowałbym w zasilanie...

    No ale powiedz też jaki kompilator?

    4\/3!!
  • Pomocny post
    #47
    nsvinc
    Poziom 35  
    Możliwe że włącza się bootloader. Upewnij się, że pin (w lpc11xx jest to P0.1) odpowiadający za aktywację bootloadera nie jest na siłę trzymany w stanie niskim lub nieustalonym. Miałem takie szopki z LPC1113, gdzie pin aktywujący bootloader miał przywieszony filtr RC i opamp - procek nie wstawał z flasha, tylko uruchamiał się bootloader, z racji tego, że wewnętrzne podciąganie pina nie zdążyło naładować kondensatora w filtrze, zanim został sprawdzony stan pina i zdecydowane skąd ma rdzeń zacząć wykonywać kod.

    Jeśli wszystko zdaje się być w porządku, to sprawdź (jak pisze Freddie) prędkość narastania zasilania na pinie procesora. Jeśli wszystko wydaje się być w normie i ogólnie OK, a przypał istnieje dalej, pomyśl o jakimś supervisorze resetu/zasilania. Układ można kupić za parę groszy a daje prze-gwarancję że wszystko wstanie tak jak powinno...
  • #48
    Jurek H.
    Poziom 8  
    Dzięki nsvinc. Miałem na pinie P2.10 wejście, które było zblokowane 100nF-ówką do masy. Przelutowałem ją tak, aby blokowała do +VCC i zadziałało. Czyli był to notorycznie włączający się bootloader.

    Jako kompilator używam LPCxpresso. Nie wiem czy jest to dobry kompilator, a właściwie powłoka bo on chyba używa GCC. A co byście polecili jako kompilator?
  • #49
    nsvinc
    Poziom 35  
    Z komercyjnych to ja polecam keil mdk-arm. Uzywam od lat, i świetnie sie pracuje... Tyle, że nie obsługuje on JTAGów opartych o ft2232. Ale mozna kupić chińskiego j-linka za stówkę na allegro, one bardzo dobrze działają z keilem ;]

    No i keil ma dosyć hardcorowy kompilator, obsługujący agresywne optymalizacje pod wydajność (i praktycznie każdy kod który piszę wykorzystuje te optymalizacje).
  • #50
    Jurek H.
    Poziom 8  
    Ja mam JTAG'a z PROPOX'a na LPT. Nie wiedziałem jak zmusić LPCxpresso do współpracy z nim, więc zainstalowałem H-JTAG, który sprawuje się bardzo dobrze.
    Dzięki wszystkim za pomoc. Chyba jak na razie nie mam więcej pytań.