logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Test prędkości odczytu i zapisu pinów GPIO w Raspberry Pi

ghost666 11 Cze 2015 23:17 3405 10
REKLAMA
  • Test prędkości odczytu i zapisu pinów GPIO w Raspberry Pi

    Dobrym pytaniem, które zadać można sobie przy okazji wykorzystywania wyprowadzeń ogólnego przeznaczenia (GPIO) w Raspberry Pi, jest pytanie o ich prędkość. Zasadniczo, jak szybko można z tych pinów czytać i jak szybko można zapisywać na nie stan logiczny? Spróbujmy na to odpowiedzieć prostym testem, którego wyniki są co najmniej zaskakujące.

    Test

    Wszystkie opisane poniżej testy zrealizowane były z konta roota na Raspberry Pi B+ pod Raspbianem w buildzie Jessie (RPi 2 jest generalnie 2..3 razy szybsze). Prędkość działania GPIO wyznaczona została z ilości cykli czy iteracji wykonanych w określonym czasie.

    Jak szybko zapisywać można sygnał na GPIO?

    Autor zdecydował się przetestować dwa języki często używane na RPi - Pythona i Natywne C - aby sprawdzić jak szybko będą one działały. Do testu dołączono także Go, które nie było jeszcze testowane w tego rodzaju sposób podczas generowania przebiegu prostokątnego. W poniższej tabelce znajdziemy wyniki testu:

    JęzykCzęstotliwość pracy
    Python68 kHz
    Go174 kHz
    C15 MHz


    Rezultaty osiągnięte dla Pythona i C są podobne do tych, jakie osiągali inni mierząc prędkość GPIO, jednakże rezultat otrzymany dla Go jest całkiem zaskakujący. Okazuje się, że programy napisane w tym języku działają całkiem szybko na RPi, jest to najszybszy kod, poza C, jaki można mieć. Jest to zasługa biblioteki stworzonej przez Stiana Eikelanda.

    Jak szybko można czytać z GPIO do pamięci?

    Kolejnym pytaniem było to, jak szybko odczytywać można dane z GPIO. W tym przypadku chcemy możliwie szybko i często odczytywać dane z GPIO do pamięci, tak aby uniknąć powstania wąskiego gardła - zapisu na dysk. W tym teście porównano tylko Go i C - dwa najszybsze języki.

    JęzykCzęstotliwość pracy
    Go1,6 MHz
    C7,2 MHz


    Czy trudniej jest czytać czy pisać w danym języku? Dla C, odczyt jest trudniejszy, jako że program w tym języku czyta mniej więcej z połową prędkości zapisu, oznacza to, że wykrywanie zmian stanu pinu jest cztery razy wolniejsze niż zmiana stanu pinu. Z kolei program napisany w Go potrafi szybciej odczytywać niż zapisywać. Go wydaje się być dobrą alternatywą do C dla programów, które mają za zadanie odczytywać wartości z GPIO.

    Te prędkości odczytu są zasadniczo górną granicą prędkości odczytu. Program czyta wartość do pamięci i nic z nią nie robi. W praktycznej aplikacji chciałoby się obrabiać jakoś te dane i najpewniej zapisywać je na dysk, co powoduje powstanie wąskiego gardła dla danych właśnie w tym miejscu. To doprowadza nas do ostatniego pytania:

    Jak szybko można czytać GPIO na dysk?

    Ten eksperyment jest podobny do poprzedniego, z tym że w tym przypadku programy w Go i w C zbierają poszczególne odczytane bity w bajty i zapisują je w bloki po 1000 bajtów na dysku. Rezultaty są dosyć zaskakujące:

    JęzykCzęstotliwość pracy
    Go440 kHz
    C673 kHz


    Co było zaskakujące, to to że Go dogania C, jeśli chodzi o prędkość. Go wydaje się być zatem dobrze zoptymalizowane jeśli chodzi nie tylko o odczyt GPIO, ale także o zapis danych na dysku. Jeśli dodamy do tego łatwość z jaką programuje się w Go, może to być bardzo dobre rozwiązanie dla programów, które odczytują wartości z pinów GPIO.

    Źródło:

    http://rpiai.com/benchmarking-gpio-pins-of-ra...i-model-b-plus/index.html#.VXQuLXj2pc0.reddit

    Fajne? Ranking DIY
    O autorze
    ghost666
    Tłumacz Redaktor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    https://twitter.com/Moonstreet_Labs
    ghost666 napisał 11960 postów o ocenie 10197, pomógł 157 razy. Mieszka w mieście Warszawa. Jest z nami od 2003 roku.
  • REKLAMA
  • #2 14765248
    michalko12
    Specjalista - Mikrokontrolery
    ghost666 napisał:
    Czy trudniej jest czytać czy pisać w danym języku? Dla C, odczyt jest trudniejszy, jako że program w tym języku czyta mniej więcej z połową prędkości zapisu, oznacza to, że wykrywanie zmian stanu pinu jest cztery razy wolniejsze niż zmiana stanu pinu. Z kolei program napisany w Go potrafi szybciej odczytywać niż zapisywać. Go wydaje się być dobrą alternatywą do C dla programów, które mają za zadanie odczytywać wartości z GPIO.

    Bezsensowne porównanie. W pierwszym przypadku jest wykonywana tylko operacja CPU->HWD, a w drugim HWD->CPU->MEM.

    Nie wspomnę już o bezsensowności pierwszego zdania. Jakby to od trudu pisania w danym języku zależała prędkość wykonywania programu.
  • REKLAMA
  • #3 14766032
    ArGut
    Poziom 11  
    michalko12 napisał:
    Bezsensowne porównanie. W pierwszym przypadku jest wykonywana tylko operacja CPU->HWD, a w drugim HWD->CPU->MEM.

    Nie wspomnę już o bezsensowności pierwszego zdania. Jakby to od trudu pisania w danym języku zależała prędkość wykonywania programu.


    Nie ma się co czepiać tłumaczenia. Przeprowadzony test ma taki walor, że wiadomo czego się spodziewać jak się chce użyć gotowych programowych "klocków".
  • #4 14766123
    mrtip
    Poziom 14  
    Ja mogę dodać, że w teście popełniono kilka błędów:
    1: Pomiary w systemie czasu rzeczywistego są relatywne
    2: Wymiatanie bitów było na poziomie funkcji main
    3: Tryb pracy wg. mojej wiedzy w niskim priorytecie.

    Dając młodemu AVRkowcowi taki test dojdzie do wniosku że atTiny jest szybszy.

    Procek w Raspberry nie jest stworzony do wymiatania bitami na poziomie GPIO to nie jest typowy mikrokontroler więc ten test jest nieobiektywny. Faktem jest że peryferia w nim mogą osiągać nawet 100Mhz ale po jaką cholerę mamy do tego stosować RPi.
    Na koniec powiem, że RPi jako sterownik do przeróżnej maści urządzeń jest idealny jak i do pracy jako multimedium. Choć pewnie wyjedzie mi ktoś z elaboratem co po co i dlaczego.
    Ja generalnie RPi stosuję jako multiprogramowalne routery GSM na Debianie.
    Zobaczymy za niedługo jak sobie będzie radził na Windows 10, bo z tego co widzę to Embarcadero jak i Visual C/C# już ogarniają RPi 2.

    Darek z Banerled
  • REKLAMA
  • #5 14767144
    Cosicek
    Poziom 16  
    Masz rację że nie jest stworzony, ale czasem warto wiedzieć jaką prędkość można wyciągnąć, zwłaszcza jak będziesz potrzebował coś nietypowego do zrobienia.

    Ja ze swojej strony dorzucę jeszcze ten artykuł dla porównania
    Benchmarking Raspberry Pi GPIO Speed

    Poza tym te testy pokazują nieco coś innego, a mianowicie pokazują jakie są czasy dostępu do sprzętu z poziomów różnych języków programowania.
  • #6 14768343
    greg789
    Poziom 16  
    Te prędkości przy 700 MHz to chyba jakiś ponury żart ;)
  • REKLAMA
  • #7 14770518
    ghost666
    Tłumacz Redaktor
    greg789 napisał:
    Te prędkości przy 700 MHz to chyba jakiś ponury żart ;)


    Które prędkości?
  • #8 14773739
    mrtip
    Poziom 14  
    No jak ponury żart?
    Weź sobie np: STM32F427xx - ma PLL i zegar wewnętrzny 360 MHz zaś CPU Core 180 Mhz, APB masz max 90 Mhz więc wymieciesz 45Mhz max.
    Optymalnie w RTOS jakieś 20 Mhz z przyczyn wymuszania wątków.

    A myślisz, że CPU multimedialny z RPi będzie miał częstotliwość na peryferia rzędu 350 Mhz? Jak już to około 100 Mhz z uwagi na samą cenę mikrokontrolera jak i pobór mocy. Nie czytałem jego datasheetu więc jedynie się wymądrzam ;)

    Pozdrawiam Darek z Banerled
  • #9 14776334
    greg789
    Poziom 16  
    mrtip napisał:
    [
    Jak już to około 100 Mhz z uwagi na samą cenę mikrokontrolera jak i pobór mocy. Nie czytałem jego datasheetu więc jedynie się wymądrzam ;)
    [/i]


    Tyle że tu jest 7,2 MHz przy odczycie, a to jest gorzej niż niektóre 8 bitowe przy dużo niższych częstotliwościach.
  • #10 14777742
    michalko12
    Specjalista - Mikrokontrolery
    greg789 napisał:
    Tyle że tu jest 7,2 MHz przy odczycie, a to jest gorzej niż niektóre 8 bitowe przy dużo niższych częstotliwościach.

    Napisz sobie soft bare metal na RPi i wtedy porównuj z 8 bitowcami. Odpal Linuxa na 8 bitach i wtedy porównuj do RPi. Uwierz, musi jeszcze dużo wody w Wiśle przepłynąć żebyś zrozumiał w czym jest problem.
  • #11 14788842
    mrtip
    Poziom 14  
    michalko12, nie piję do Ciebie a do fahofcuf ;):
    Faktem jest, że grono fachowców to użytkownicy komputerów, którym nikt nie powiedział że są fachowcami jedynie sami sobie przyznali ten tytuł. Zaś jeśli chcesz ocenić się jako fachowiec w czymkolwiek to nie że musisz zjeść zębów a poświęcić danemu tematowi minimum 10 tyś godzin wówczas możesz powiedzieć że jesteś fachowcem.
    Zatem panie i panowie RPi jest ogólnie pionierem w nano komputerach, w moim mniemaniu za mocno okrojony. Karta SD jako główny "napęd" to porażka dla półprofesionalnych rozwiązań. Takie testy trzeba by było przeprowadzić na Cubieboard z dyskiem SSD.
REKLAMA