{"id":3086,"date":"2021-09-01T13:47:47","date_gmt":"2021-09-01T13:47:47","guid":{"rendered":"https:\/\/physics.uwb.edu.pl\/wf\/fi-bot\/?page_id=3086"},"modified":"2021-09-16T18:29:31","modified_gmt":"2021-09-16T18:29:31","slug":"joy-radio-2-3-2-2-2","status":"publish","type":"page","link":"https:\/\/physics.uwb.edu.pl\/wf\/fi-bot\/?page_id=3086","title":{"rendered":"Jak szybkie s\u0105 porty cyfrowe Arduino?"},"content":{"rendered":"\n
\"\"
Sprawdzanie czas\u00f3w generowania sygna\u0142\u00f3w.analizator\u00f3w Saleae.<\/figcaption><\/figure>\n\n\n

Autorzy: KG + ?
Zaawansowanie: badania trwaj\u0105, s\u0105 ju\u017c wst\u0119pne wyniki
Cel: wiedza, wiedza, wiedza – potem prze\u0142o\u017cona na praktyk\u0119<\/p>\n

Motywacja<\/h2>\n

Mikrokontroler ATmega 328P znajduj\u0105cy si\u0119 w platformie Arduino UNO (i innych, ale ta jest najbardziej popularna) dysponuje 14-toma wej\u015bciami\/wyj\u015bciami cyfrowymi (skupiam si\u0119 jedynie na portach cyfrowych, pomijam analogowe). Porty te zgrupowane s\u0105 w trzech bankach (B,C,D) i mamy do nich dost\u0119p za pomoc\u0105 funkcji digitalWrite() lub bezpo\u015brednio – przez manipulacj\u0119 rejestrami. Powstaje pytanie, jak szybko mo\u017cemy zmienia\u0107 stan wysoki na niski w danym porcie? Jak si\u0119 to ma wykorzystuj\u0105c dedykowan\u0105 funkcj\u0119 z Arduino IDE a jak programuj\u0105c rejstry? Kolejne pytanie, to jak szybko mo\u017cemy odczytywa\u0107 zmiany napi\u0119\u0107 (np. funkcjami obs\u0142ugi przerwa\u0144). Jedno z drugim jest zwi\u0105zane i cz\u0119sto potrzebne, np. w przypadku obs\u0142ugi enkoder\u00f3w do silnik\u00f3w. Takie enkodery mog\u0105 generowa\u0107 64 impulsy na obr\u00f3t (co jest bezproblemowe do wy\u0142apania przez Arduino), ale cz\u0119sto silniki maj\u0105 przek\u0142adni\u0119 (np. Pollolu 37Dx70L ma przek\u0142adni\u0119 70:1) i liczba impuls\u00f3w na sekund\u0119 wynosi ju\u017c 4480. Czy Arduino odczyta wszystie te impulsy?<\/span><\/p>\n

Sprawdzamy czasy wyj\u015bcia.<\/span><\/p>\n

Pierwszy program to prawie kopia popularnego Blink-a, jednak tym razem zmieniam stan pinu numer 7 (zdefiniowanego 1 pierwszej linijce kodu pod nazw\u0105 PIN) i robi\u0119 to bardzo szybko – co 1 ms. Celowo nic nie wypisuj\u0119 na port szeregowy, aby nie powodowa\u0107 niepotrzebnych op\u00f3\u017anie\u0144.<\/p>\n

\"\"

Program 1: program testowy w dialekcie C\/C++ Arduino.<\/p><\/div>\n

Oczywi\u015bcie zmian napi\u0119\u0107 na porcie 7 nie wida\u0107, nawet gdyby\u015bmy pod\u0142\u0105czyli multimetr – ten powinien wskaza\u0107 oko\u0142o 2.5V (gdy\u017c podczas trwania mierzenia warto\u015bci napi\u0119cia na multimetrze czas trwania napi\u0119cia 5V = czasowi trwania napi\u0119cia 0V, co \u015brednio daje w\u0142a\u015bnie 2.5V). Najlepiej pod\u0142\u0105czy\u0107 dobry<\/strong> oscyloskop, ale niewiele os\u00f3b takowy posiada (to wydatek przynajmniej 2000 z\u0142). Tanie „chi\u0144skie” mini-oscyloskopy (za ~200z\u0142) jeszcze z tym sobie poradz\u0105, ale za chwil\u0119 przyspieszymy prze\u0142\u0105czanie pin\u00f3w i takie sprz\u0119ty b\u0119d\u0105 bezu\u017cyteczne. Dlatego w tym wpisie skupi\u0119 si\u0119 na analizatorze stan\u00f3w logicznych Saleae, a dok\u0142adniej ich klon\u00f3w (ze wzgl\u0119du na cen\u0119, ale do orygina\u0142\u00f3w jeszcze wr\u00f3c\u0119). Poni\u017cej aukcja w popularnym serwisie pokazuj\u0105ca o czym mowa.<\/p>\n

\"\"<\/p>\n

Pod\u0142\u0105czamy wi\u0119c GND i CH1 analizatora Saleae do Arduino z uruchomionym pierwszym programem i sprawdzamy, co si\u0119 dzieje (ja ustawi\u0142em czas pr\u00f3bkowania na 0.01 s, aby pomiar by\u0142 szybki).<\/p>\n

\"\"

Wykres 1 – Wynik Programu 1: sprawdzenie poprawno\u015bci odczyt\u00f3w pierwszego programu.<\/p><\/div>\n

Widzimy prostok\u0105tny przebieg w cz\u0119\u015bci Channel 0<\/em> (cho\u0107 na tanim klonie analizatora Saleae naklejka m\u00f3wi, \u017ce jest to port pierwszy – czyli Channel 1). Mysz\u0105 sprawdzamy jakie s\u0105 faktyczne czasy trwania sygna\u0142u HIGH i LOW. Na powy\u017cszym zdj\u0119ciu czas sygna\u0142u LOW to 1.008292 ms, czyli bardzo, bardzo zbli\u017cone do 1 ms. Dok\u0142adniejsze sprawdzanie kolejnych sygna\u0142\u00f3w mo\u017ce pokaza\u0107, \u017ce inne sygna\u0142y LOW r\u00f3\u017cni\u0105 si\u0119 niewiele – nie s\u0105 identyczne. C\u00f3\u017c, tak w\u0142a\u015bnie dzia\u0142a elektronika (nieidealnie). Przy okazji widzimy, \u017ce sygna\u0142 jest periodyczny z cz\u0119stotliwo\u015bci\u0105 496 Hz (napis Freq z lewej strony).<\/p>\n

Zmieniamy program wyrzucaj\u0105c funkcje op\u00f3\u017aniaj\u0105ce i sprawdzamy, ile mo\u017cemy maksymalnie „wycisn\u0105\u0107” z Arduino.<\/p>\n

\"\"

Program 2: Wyciskamy maksimum z Arduino (program w dialekcie C\/C++ Arduino).<\/p><\/div>\n

Pozbyli\u015bmy si\u0119 wi\u0119c op\u00f3\u017anie\u0144 i testujemy z wykorzystaniem analizatora Saleae. Po powi\u0119kszeniu skali (k\u00f3\u0142ko myszki) widzimy co\u015b takiego:<\/p>\n

\"\"

Wykres 2 – Wynik Programu 2.<\/p><\/div>\n

Czyli bez funkcji delay(1) sygna\u0142 HIGH trwa 3.208 us, natomiast sygna\u0142 LOW jakby troch\u0119 d\u0142u\u017cej (6.75 us – 3.208 us = 3.542 us). Potwierdzaj\u0105 to kolejne fragmenty wykresu (znowu nie s\u0105 identyczne, ale bardzo zbli\u017cone). R\u00f3\u017cnica tych czas\u00f3w (oko\u0142o 0.300 us) zostanie wyja\u015bniona w dalszej cz\u0119\u015bci wpisu<\/strong> (a mo\u017ce sam si\u0119 ju\u017c domy\u015blasz, sk\u0105d si\u0119 bierze?). Zauwa\u017camy, \u017ce cz\u0119stotliwo\u015b\u0107 wzros\u0142a i wynosi 148.148 kHz, czyli 148148 Hz. Czy to ju\u017c maksymalna warto\u015b\u0107?<\/p>\n

Programujemy rejestry<\/h2>\n

Dialekt C\/C++ Arduino jest fajny, prosty i posiada u\u017cyteczne funkcje, jak pinMode() czy digitalWrite(). Ale nie musimy ich stosowa\u0107, aby „dobra\u0107” si\u0119 do port\u00f3w Arduino. Poni\u017cszy schemat przedstawia piny cyfrowe I\/O w nazewnictwie Arduino UNO (kolor niebieski: ARDUINO PIN) oraz prawdziwe nazwy mikrokontrolera ATmega328 (kolor zielony: PORT PIN). Widzimy wi\u0119c, \u017ce popularny Arduino pin 13, do kt\u00f3rego standartowo pod\u0142\u0105czony jest LED to faktycznie pin PB5. Ja z kolei u\u017cy\u0142em Arduino pin 7 w pierwszych programach, czyli PD7. Sprawd\u017a, czy umiesz to odczyta\u0107 z poni\u017cszego obrazka i nie przejmuj si\u0119, \u017ce z jakiego\u015b powodu piny nie s\u0105 w kolejno\u015bci, a czasami „skacz\u0105” z jednej strony uk\u0142adu na drug\u0105 (dodatkowo: czy zauwa\u017cy\u0142e\u015b, \u017ce s\u0105 „nowe” piny 20 i 21 – do kt\u00f3rych nie masz dost\u0119pu z Arduino IDE?).<\/p>\n

\"\"

Nazewnictwo port\u00f3w dla ATmegi 328 – patrz kolor niebieski i zielony.<\/p><\/div>\n

Programowanie rejstr\u00f3w polega na odwo\u0142ywaniu si\u0119 do konkretnych kom\u00f3rek pami\u0119ci w mikrokontrolerze. Na og\u00f3\u0142 zmieniamy jeden bit, kt\u00f3re odpowiada za dany pin. Ale mo\u017cna od razu zmienia\u0107 ca\u0142y bajt – czyli 8 port\u00f3w na raz! W naszym przypadku najpierw trzeba ustali\u0107 rol\u0119 pinu – wej\u015bcie czy wyj\u015bcie – za to odpowiada rejestr DataDirectionRegisterX kt\u00f3ry pe\u0142ni rol\u0119 wywo\u0142ania funkcji pinMode(), a potem w\u0142\u0105czy\u0107 lub wy\u0142\u0105czy\u0107 dany bit (ponownie: funkcja digitalWrite() w dialekcie Arduino, a w rejestrach to PORTX). X na ko\u0144cu nazw rejestr\u00f3w to w\u0142a\u015bnie banki port\u00f3w, u nas B,C lub D.
<\/span><\/p>\n

Programujemy wyj\u015bcie cyfrowe PD7 (czyli Arduino pin 7) bez funkcji z Arduino IDE – patrz poni\u017cszy program. Linijka 2 to odpowiednik instrukcji pinMode(), tym razem dzia\u0142aj\u0105ca dla ca\u0142ego „banku D” pin\u00f3w (czyli od razu dla wszystkich o\u015bmiu pin\u00f3w Arduino 0,1,2,3,4,5,6,7). Ka\u017cdy bit w rejestrze DDRD (Data Direction RegisterD) odpowiada jednemu portowi, ja tu wpisa\u0142em 255 czyli B11111111 (same jedynki). Jedynka oznacza OUTPUT, natomiast zero oznacza INPUT (\u0142atwiej by\u0142o by to zapami\u0119ta\u0107, gdyby 1=INPUT, a 0=OUTPUT – ale tutaj jest na odwr\u00f3t<\/strong>, czyli 1=OUTPUT, 0=INPUT). Ca\u0142a linijka 2 programu odpowiada wi\u0119c o\u015bmiu instrukcjom pinMode(0, OUTPUT), pinMode(1, OUTPUT), …,pinMode(7, OUTPUT). Tylko jedna instrukcja przypisania pojedynczego bajta do rejestru DDRD zast\u0119puje nam wywo\u0142anie o\u015bmiu funkcji pinMode()! Wiem wiem, poniewa\u017c pracuj\u0119 tylko z jednym portem PD7 powinienem wykona\u0107 DDRD=B10000000; czyli OUTPUT tylko na nim, a reszta port\u00f3w w tym pinie jako INPUT – ale tak mi si\u0119 jako\u015b ca\u0142y bank ustawi\u0142o na OUTPUT i tego si\u0119 b\u0119d\u0119 dalej trzyma\u0107.
<\/span><\/p>\n

\"\"

Program 3: test programowania port\u00f3w.<\/p><\/div>\n

Linijka 6 to w\u0142\u0105czenie w stan HIGH portu PD7, inne porty w tym banku pozostaj\u0105 bez zmian. Robi\u0119 to z wykorzystaniem instrukcji sumy bitowej tego, co jest aktualnie w rejestrze D (rejestr nazywa si\u0119 PORTD) z bajtem B10000000. Odpowiada to wywo\u0142aniu funkcji digitalWrite(7, HIGH). Podobnie jak w linijce 2 mog\u0142em zaprogramowa\u0107 ca\u0142y bank D w jednej instrukcji przypisania, tak i tutaj mog\u0142em (np. PORTD=B00001111 to w\u0142\u0105czenie w stan HIGH port\u00f3w PD0, PD1, PD2 oraz PD3 jednocze\u015bnie w\u0142\u0105czaj\u0105c w stan LOW port\u00f3w PD4, PD5, PD6 i PD7. Ja nie chcia\u0142em zmienia\u0107 innch port\u00f3w, tylko PD7, dlatego u\u017cy\u0142em instrukcji sumy bitowej). Nast\u0119pnie czekam 1 ms. Linia 8 to prze\u0142\u0105czenie PD7 w stan LOW, jednocze\u015bnie pozostawiaj\u0105c bez zmiany porty PD1..PD7 (zastosowa\u0142em iloczyn bitowy). Kompiluj\u0119 i wgrywam. Sprawdzam na analizatorze – wynik poni\u017cej:<\/p>\n

\"\"

Wykres 3 – Wynik Programu 3.<\/p><\/div>\n

OK, wszystko dzia\u0142a jak powinno: mamy cz\u0119stotliwo\u015b\u0107 Freq=495.97 Hz i sygna\u0142y HIGH i LOW trwaj\u0105ce 1 ms (z malutkim ogonkiem). Programowanie rejestr\u00f3w nie jest takie trudne, prawda? \ud83d\ude09 Mo\u017cna wi\u0119c pozby\u0107 si\u0119 p\u0119tli op\u00f3\u017aniaj\u0105cych (linijki 7 i 8) i zobaczy\u0107, jak teraz b\u0119dzie dzia\u0142a\u0107 prze\u0142\u0105czanie port\u00f3w.<\/p>\n

\"\"

Program 4: programowanie port\u00f3w.<\/p><\/div>\n

Wynik powy\u017cszego programu w analizatorze Saleae:<\/p>\n

\"\"

Wykres 4 – Wynik Programu 4.<\/p><\/div>\n

Zaczynaj\u0105 si\u0119 dzia\u0107 ciekawe rzeczy \ud83d\ude09 Stan HIGH trwa 125 ns (nano sekund! a w Programie 2 by\u0142o to 3.208 us = 3208 ns, czyli ponad 25x wi\u0119cej!). Ale dziwne, bo stan LOW nie trwa tyle samo co stan wyoski, a jedynie 500ns-125ns = 375 ns. Sk\u0105d ten brak symetrii? Zreszt\u0105, r\u00f3\u017cnica czas\u00f3w trwania stan\u00f3w HIGH\/LOW pojawi\u0142a si\u0119 ju\u017c wcze\u015bniej<\/strong> – podczas omawiania wynik\u00f3w dzia\u0142ania Programu 2 (patrz dyskusja pod Wykresem 2) i wynosi\u0142a w\u0142a\u015bnie ~0.3 us czyli ~300 ns. Dlaczego w\u0142\u0105czenie HIGH trwa kr\u00f3cej ni\u017c LOW? Tak by\u0107 nie mo\u017ce, tu chodzi o co\u015b innego… Moje przepuszczenie (robocza teza)<\/strong>: po wywo\u0142aniu dw\u00f3ch instrukcji w funkcji loop() Proramu 4 ponownie wywo\u0142uje si\u0119 funkcja loop() – czyli mamy dodatkowe instrukcje skoku (dodatkowe op\u00f3\u017anienie). Aby to sprawdzi\u0107, rozbudowuj\u0119 funkcj\u0119 loop() o kolejne dwa cykle w\u0142\u0105czenia\/wy\u0142\u0105czenia tego samego pinu – w\u00f3wczas loop() wywo\u0142a si\u0119 po trzech prze\u0142\u0105czeniach portu PD7. Oto i program:<\/p>\n

\"\"

Program 5: trzykrotne prze\u0142\u0105czenie PD7 w jednej funkcji loop().<\/p><\/div>\n

Jak to dzia\u0142a? Poni\u017cej obraz z Saleae:<\/p>\n

\"\"

Wykres 5 – Wynik Programu 5.<\/p><\/div>\n

Bingo! Faktycznie, teraz wida\u0107, \u017ce mamy trzy cykle w\u0142\u0105czenia\/wy\u0142\u0105czenia stanu na porcie, a potem d\u0142u\u017csz\u0105 pauz\u0119, czyli stan LOW si\u0119 wyd\u0142u\u017cy\u0142. Wida\u0107 te\u017c, \u017ce po pierwszym w\u0142\u0105czeniu PD7 na HIGH nast\u0119puje stan LOW trwaj\u0105cy dok\u0142adnie tyle samo co poprzednio stan HIGH – czyli 125 ns. Patrz rysunek poni\u017cej.<\/p>\n

\"\"

Wykres 6a – Wynik Programu 5 – pomiar czasu trwania stanu LOW.<\/p><\/div>\n

 <\/p>\n

\"\"

Wykres 6b – Wynik programu 5 – pomiar czasu trwania stanu HIGH.<\/p><\/div>\n

Co z tego wynika? Wykresy 6a i 6b wskazuj\u0105, \u017ce cz\u0119stotliwo\u015b\u0107 sygna\u0142\u00f3w HIGH\/LOW wynosi 4 MHz<\/strong> (ponad 27x szybciej ni\u017c maksimum, jakie „wycisn\u0105\u0142em” programuj\u0105c w dialekcie C\/C++ Arduino, patrz Wykres 2). Czas trwania tych sygna\u0142\u00f3w to 125 ns. Uzyska\u0142em niez\u0142e przyspieszenie programuj\u0105c porty i nie korzystaj\u0105c z funkcji digitalWrite().<\/p>\n

Cz\u0119stotliwo\u015b\u0107 pracy ATmegi 328<\/h2>\n

Arduino UNO bazuje na ATmedze 328p, dzia\u0142aj\u0105cym z kwarcem 16 MHz.Oznacza to, \u017ce zegar „klika” co 1\/16000000 s = 62.5 ns. Czas wykonania ka\u017cdej instrukcji mo\u017cna znale\u017a\u0107 w specyfikacji mikrokontrolera gdzie wida\u0107, \u017ce operacje sumy\/iloczynu logicznego zajmuj\u0105 dwa cykle zegarowe (dwa „kliki”), a przypisanie warto\u015bci tylko jeden „klik”. Jak na razie widzimy, \u017ce prze\u0142\u0105czenie port\u00f3w trwa 125 ns, czyli faktycznie dwa cykle (manipulacje na banku rejestr PORTD wymagaj\u0105 u\u017cycia instrukcji asemblera SEI\/CLI trwaj\u0105cej 2 „kliki”, por\u00f3wnaj tabela 31. Instruction Set Summary ze specyfikacji ATmegi 328p<\/a>). Dlatego rozs\u0105dnie jest zmodyfikowa\u0107 program na okoliczno\u015b\u0107 moich test\u00f3w tak, \u017ce zmieniam wszystkie 8 port\u00f3w (cho\u0107 i tak zale\u017cy mi na jednym) co zajmie jeden cykl (instrukcja OUT w Tabeli 31). Nowy program wygl\u0105da tak:<\/p>\n

\"\"

Program 6: trzykrotne prze\u0142\u0105czenie PD7 w jednej funkcji loop(). Program bez operacji sumy\/iloczynu bit\u00f3w.<\/p><\/div>\n

Po zmianie na Program 6 widz\u0119 poni\u017cszy wykres:<\/p>\n

\"\"

Wykres 8a: wynik dzia\u0142ania Programu 6. <\/p><\/div>\n

 <\/p>\n

\"\"

Wykres 8b: wynik dzia\u0142ania Programu 6. <\/p><\/div>\n

Wida\u0107 charakterystyczne trzy prze\u0142\u0105czenia i wyd\u0142u\u017cony stan LOW na ponowne wykonanie p\u0119tli loop(). Ale stany HIGH trwa 83 ns, podczas gdy stan LOW jakby po\u0142ow\u0119 tego czasu, czyli 42 ns! Ponownie uruchamiam zbieranie danych (no dobra, kilka razy a\u017c trafiam to, co chc\u0119 poni\u017cej przedstawi\u0107):<\/p>\n

\"\"

Wykres 9a: wynik dzia\u0142ania Programu 6. Ponowne uruchomienie.<\/p><\/div>\n

 <\/p>\n

\"\"

Wykres 9b: wynik dzia\u0142ania Programu 6. Ponowne uruchomienie.<\/p><\/div>\n

Wykresy 9a i 9b wskazuj\u0105, \u017ce teraz czasy si\u0119 „odwr\u00f3ci\u0142y”! HIGH trwa 42 ns, a LOW trwa 83 ns. Jaka\u015b pomy\u0142ka? Nie, bo takie Arduino UNO dzia\u0142a z zegarem 16 MHz, czyli zegar „klika” co 1\/16000000 s = 62.5 ns. Programowanie PORD=ile\u015b_tam odbywa si\u0119 w jednej instrukcji asemblera OUT PORD, ile\u015b_tram<\/strong>, co zgodnie ze specyfikacj\u0105 ATmegi 328p<\/a> (Tabela 31. Instruction Set Summary) zajmuje w\u0142a\u015bnie 1 CYKL (jeden „klik”). Z kolei Saleae pr\u00f3bkuje z cz\u0119sto\u015bci\u0105 24 MHz, czyli w \u0142apie sygna\u0142y w oknach po 1\/24000000 = 42 ns. Sygna\u0142y z Aruino o d\u0142ugo\u015bci 62.5 ns wchodz\u0105 nie do jednego okna, ale do „jednego i p\u00f3\u0142” \ud83d\ude09<\/p>\n

Wida\u0107, \u017ce zwi\u0119kszyli\u015bmy szybko\u015b\u0107 generowania impuls\u00f3w HIGH\/LOW i teraz pokazuje si\u0119 Freq = 8 MHz<\/strong> (czyli 2x wi\u0119cej ni\u017c w Programie 5, oraz ponad 50x szybciej ni\u017c Program 2).<\/p>\n

My\u015bl\u0119, \u017ce sprawa 42\/83 ns jest ju\u017c to jasne – ze wzgl\u0119du na brak synchronizacji pracy Saleae i pracy Arduino UNO (no bo sk\u0105d mia\u0142a by by\u0107 taka synchronizacja) analizator raz interpretuje sygna\u0142 jako stan HIGH, a raz jako LOW. Arduino zmienia sygna\u0142y co 63 ns, a pr\u00f3bkowanie odbywa si\u0119 co 42 ns – schematyczny rysunek powinien to jeszcze raz zobrazowa\u0107:<\/p>\n

\"\"

Szkic 1: pr\u00f3bkowanie sygna\u0142u z Arduino analizatorem stan\u00f3w logicznych.<\/p><\/div>\n

Dodatkowe wyja\u015bnienie Szkicu 1: a) krzywa zielona to sygna\u0142 z Arduino (dzia\u0142a Program 6) – rzeczywisty (bo trwa 62.5 ns) ale troch\u0119 wyidealizowany (prostok\u0105ty s\u0105 ostre! a dobrej klasy oscyloskop poka\u017ce, \u017ce na zboczach narastaj\u0105cych i opadaj\u0105cych pojawiaj\u0105 si\u0119 oscylacje); b) okno  pr\u00f3bkowania analizatorem trwa 42 ns i nie musi trafi\u0107 w pocz\u0105tek\/koniec sygna\u0142u z Arduino – jest gdziekolwiek; analizator sprawdza, kt\u00f3ry ze stan\u00f3w przewa\u017ca w oknie pr\u00f3bkowania – stan HIGH czy stan LOW – i na tej podstawie przypisuje odpowiednio 1 lub 0 (oczywi\u015bcie w omawianym przypadku b) b\u0119dzie to 1, bo przez ca\u0142e okno mamy stan HIGH); c) kilka nast\u0119puj\u0105cych po sobie pr\u00f3bkowa\u0144 – aby rysunek by\u0142 wyra\u017aniejszy, zmieniam kolor okna pr\u00f3bkowania na ja\u015bniejszy (co drugie pr\u00f3bkowanie); widzimy, \u017ce drugie pr\u00f3bkowanie da\u0142o wynik 0 (przewa\u017ca\u0142 stan LOW), kolejne da\u0142o 1 (stan LOW by\u0142 oko\u0142o 1\/3 czasu, przewa\u017ca\u0142 stan HIGH) a ostatnie pr\u00f3bkowanie ponownie da\u0142o warto\u015b\u0107 1 (znowu przewa\u017ca\u0142 stan HIGH). Ten przyk\u0142ad przedstawia sytuacj\u0119, gdzie odczyt analizatorem pokaza\u0142 by stan wysoki z czasem trwania 42 ns, potem czas niski z tym samym czasem 42 ns, a potem stan wysoki trwaj\u0105cy 84 ns. Takie sytuacje wyst\u0119puj\u0105 podczas eksperyment\u00f3w z Programem 6. \u0141atwo sobie te\u017c wyobrazi\u0107 inny moment startu pr\u00f3bkowania i sytuacj\u0119, gdzie zawsze trafiamy naprzemiennie 84 ns dla jednego stanu i 42 ns dla stanu przeciwnego – patrz Szkic 2 poni\u017cej.<\/p>\n

\"\"

Szkic 2: Wyja\u015bnienie dwukrotnie d\u0142u\u017cszego stanu HIGH w stosunku do czasu stanu LOW.<\/p><\/div>\n

W powy\u017cszym obrazku wystarczy lekko przesun\u0105\u0107 czas rozpocz\u0119cia pr\u00f3bkowania aby mie\u0107 sytuacj\u0119 odwrotn\u0105 – czas trwania sygna\u0142u LOW b\u0119dzie 2x d\u0142u\u017cszy od czasu trwania sygna\u0142u HIGH.<\/p>\n

Prawdziwe analizatory Saleae<\/h2>\n

Ja u\u017cywam taniego klona, ale oryginalne maj\u0105 nie tylko analizatory cyfrowe, ale i wej\u015bcia analogowe – to ju\u017c s\u0105 ma\u0142e oscyloskopy! Wyst\u0119puj\u0105 w trzech rodzajach a poni\u017cej tabelka z por\u00f3wnaniem parametr\u00f3w (ze strony Kamami – kliknij w tabelk\u0119 aby przeskoczy\u0107 do ich sklepu):<\/p>\n

\"\"<\/a>

Por\u00f3wnanie specyfikacji analizator\u00f3w Saleae.<\/p><\/div>\n

Super urz\u0105dzenia, ale na os\u0142odz\u0119 zapa\u0142 naiwnego czytelnika ich cenami:<\/a> zaczynaj\u0105 si\u0119 od nieca\u0142ych 2000 z\u0142 a ko\u0144cz\u0105 na 5500 z\u0142. Mo\u017ce te klony za 30 z\u0142 nie takie z\u0142e? \ud83d\ude09<\/p>\n

BitScope<\/h2>\n

To bardzo fajny, hobbystyczny oscyloskop + 8-mio kana\u0142ow analzator stan\u00f3w logicznych za kwot\u0119 ~300 z\u0142. Do jego pracy potrzebny jest komputer z ekranem, a poda\u0142\u0105cza si\u0119 go przez USB. Najlepsze, \u017ce dzia\u0142a on pod Linuxem, Maciem i Windowsem (podre\u015bl\u0119 – dzia\u0142a pod Linuxem<\/strong>, wi\u0119c w sieci jest sporo projekt\u00f3w BitScope + Raspberry Pi). Ciekaw\u0105 ofert\u0119 na niego ma sklep Botland<\/a>.<\/p>\n

\"\"

Oscyloskop cyfrowy BitScope – ma\u0142y, ale dzik! \ud83d\ude09<\/p><\/div>\n

Parametry tego urz\u0105dzenia s\u0105 bardzo przyzwoite jak na cele hobbystyczne (do nauki elektroniki, analizy uk\u0142ad\u00f3w LRC czy innych) i wynosz\u0105: pr\u00f3bkowanie 20 MHz z 40Msps<\/strong>. Jednak to nie wystarcza, aby poprawnie zinterpretowa\u0107 wynik Programu 5:<\/p>\n

\"\"

Wynik Programu 5 na BitScopie.<\/p><\/div>\n

Dzia\u0142am tutaj na maksymalnej cz\u0119sto\u015bci 20MHz (podzia\u0142a czasowa 1 us) i cho\u0107 wida\u0107 tr\u00f3jki pik\u00f3w – to s\u0142abo z precyzyjnym odczytaniem ich czas\u00f3w. Prze\u0142\u0105czenie BitScopa w tryb analizatora stan\u00f3w logicznych pomaga – cho\u0107 i tak jest s\u0142abszy ni\u017c omawiany klon Saleae ze wzgl\u0119du na pr\u00f3bkowanie jedynie 20 MHz (przypominam: Saleae ma 24 MHz).<\/p>\n

RIGOL 1204B<\/h2>\n

Skoro testuj\u0119 r\u00f3\u017cne sprz\u0119ty, to przedstawi\u0119 profesjonalny oscyloskop stacjonarny za kwot\u0119 oko\u0142o ~5000 z\u0142 (cho\u0107 tak wysoka cena wynika z posiadania a\u017c czterech kana\u0142\u00f3w – podczas gdy typowo mamy dwa kana\u0142y analogowe; odpowiedni model z dwoma kana\u0142ami to ju\u017c wydatek jedynie ~3500 z\u0142). Ju\u017c na obudowie mo\u017cna odczyta\u0107, \u017ce oscyloskop ten pracuje z 200 MHz i 2 Gsps<\/strong>.<\/p>\n

\"\"

Program 6 na oscyloskopie. Wida\u0107 brak idealnych prostok\u0105t\u00f3w w rogach sygna\u0142\u00f3w.<\/p><\/div>\n

Nie b\u0119d\u0119 robi\u0107 telefonem screen-shot\u00f3w tylko wykorzystam funkcj\u0119 USB i zapisu przebiegu z oscyloskopu bezpo\u015brednio na pendrv (mog\u0119 do CSV, jaki\u015b innych format\u00f3w lub obrazka PNG – jednak jest to zrzut ekranu graficznego dzia\u0142aj\u0105cego w trybie 320×240 pikseli – i dlatego rozdzielczo\u015b\u0107 plik\u00f3w PNG nie powala).<\/p>\n

\"\"

Tak zapisuje RIGOL swoje screenshoty do formatu PNG (szkoda, \u017ce takie to ma\u0142e!). S\u0105 inne formaty (CSV, WAVEFORM).<\/p><\/div>\n

 <\/p>\n

\"\"

Powi\u0119kszenie na pojedynczy pik (skala x=20 ns) – pomiar d\u0142ugo\u015bci trwania (tak ustawi\u0142em kurosry, \u017ce mi wysz\u0142o 69.6 ns).<\/p><\/div>\n

 <\/p>\n

\"\"

Pomiar ponownego wywo\u0142ania funkcji loop() – wychodzi mi 296 ns.<\/p><\/div>\n

A tani chi\u0144czyk? DSO188<\/h2>\n

Ten miniaturowy oscyloskopik „zabawka” ma kolorowy ekranik LCD 1.8 cala (nie potrzebuje wi\u0119c komputera!) oraz wbudowan\u0105 bateri\u0119, czyli dzia\u0142a „w terenie” \ud83d\ude09 Jego parametry pr\u00f3bkowania to 1 MHz oraz 5 Msps<\/strong> co od razu wskazuje, \u017ce du\u017co tutaj nie zdzia\u0142a (dodam jeszcze: to oscyloskop jednokana\u0142owy<\/strong> bez analizatora stan\u00f3w). Jednak za kwot\u0119 oko\u0142o ~200 z\u0142 mamy fajn\u0105 zabawk\u0119 do przyg\u00f3d z Arduino – i nie musimy go pod\u0142\u0105cz\u0105\u0107 do przewod\u00f3w zasilaj\u0105cych!<\/p>\n

\"\"

DSO 188 z programem 5. Tiaaaa…<\/p><\/div>\n

Cho\u0107 nie poradzi\u0142 sobie, to jednak go polecam! Oczywi\u015bcie po chwili zastanowienia, bo BitScope jest zdecydowanie lepszy, ale musi by\u0107 pod\u0142\u0105czony do komputera. Ten dzia\u0142a niezale\u017cnie (szybko i na baterii). Poni\u017cej zdj\u0119cie z Programem 3:<\/p>\n

\"\"

DSO188 z Programem 3 – jest dobrze!<\/p><\/div>\n

Jak wida\u0107 wyra\u017anie odczytujemy sygna\u0142y zmieniaj\u0105ce si\u0119 co 1 ms, o czasie trwania 1ms (podzia\u0142ka 500 us, a na wykresie mamy bia\u0142\u0105 krzyw\u0105 pokrywaj\u0105c\u0105 dwie podzia\u0142ki – czyli 1000 us = 1ms w\u0142a\u015bnie). Gdzie go kupi\u0107? Polecam gotronika<\/a> (ma te\u017c filmy z wideo-recenzjami) i aukcje w popularnych serwisach.<\/p>\n

Minikombaj AVR<\/h2>\n

No to jeszcze jeden, ostatni (ale nie najs\u0142abszy). Jest to dwukana\u0142owy<\/strong> oscyloskop dzia\u0142aj\u0105cy na bateriach, z monochromatycznym ekranikiem i pr\u00f3bkowaniem 0,3 MHz. <\/strong><\/p>\n

\"\"<\/p>\n

Jest to sprz\u0119t sprzedawany przez firm\u0119 AVR jako kit 2999<\/a>. To nie tylko oscyloskopik ale i generator fal, widma…<\/p>\n

Ile trwa wywo\u0142anie funkcji loop()?<\/span><\/p>\n

Wychodzi na to, \u017ce ponowne wywo\u0142anie loop()-a trwa 300 ns (plus jeszcze epsilon). Z czego to wynika? Na t\u0105 chwil\u0119 powiem, \u017ce trzeba wywo\u0142a\u0107 instrukcj\u0119 skoku do funkcji – a tych jest kilka rodzaj\u00f3w. Poni\u017cej poka\u017c\u0119, \u017ce da si\u0119 skr\u00f3ci\u0107 to 300 ns o 1\/3<\/strong>! Poni\u017cszy fragment tylko dla zuchwa\u0142ych \ud83d\ude09<\/p>\n

Tylko dla twardzieli – programujemy w asemblerze<\/span><\/p>\n

Nie b\u0119dzie to czysty asembler, a wstawka asemblera w j\u0119zyk Arduino. Dlaczego taka hybryda? Aby upro\u015bci\u0107 i nie zniech\u0119ci\u0107 zwyk\u0142ego cz\u0142owieka \ud83d\ude09<\/p>\n

\"\"

Program 7: programowanie ze wstrzykni\u0119ciem kodu w asemblerze.<\/p><\/div>\n

Funkcja setup() jest taka sama jak w Programie 6, czyli ustawiamy rejestr DDRD na OUTPUT. Robi\u0119 to bez asemblera, jak poprzednio. Wstawka w asemblerze pojawia si\u0119 dopiero w funkcji loop() – po makrze __asm__( instrukcje<\/em> ); Jednak nie wida\u0107 odwo\u0142a\u0144 do rejestru PORTD. Nazwa tego rejestru dla wstrzykni\u0119tego kodu asemblera nie jest rozpoznawalna (mo\u017cna to obej\u015b\u0107, zdefiniowa\u0107, ale nie chcia\u0142em zaciemnia\u0107 programu). Dlatego pojawia si\u0119 adres 0x0B, czyli w\u0142a\u015bnie PORTD (sprawd\u017a w specyfikacji ATmegi328p, a dla leniwych podpowiem: przyjrzyj si\u0119 punktowi 13.4.8). Wstawka w asemblerze to para instrukcji:<\/p>\n

sbi 0x0B,7
cbi 0x0B,7<\/pre>\n
Instrukcje te w kodzie Arduino zako\u0144czone s\u0105 przej\u015bciem do nowej linii (mog\u0142a by\u0107 spacja, lub tabulator… pojawia si\u0119 dodatkowe \\n<\/em> na koniec ka\u017cdej linii). SBI to instrukcja „Set Bit in I\/O regiter”, po kt\u00f3rej podajemy kt\u00f3ry bit ma by\u0107 ustawiony na 1 (u mnie: ma to by\u0107 7-my bit w rejestrze 0x0B czyli PD7). Potem nast\u0119puje czyszczenie tego bitu, czyli CBI – „Clear Bit in I\/O register” (u mnie: czyszcz\u0119 na zero bit 7, czyli w\u0142a\u015bnie PD7). Ka\u017cda z tych instrukcji wymaga 2 cykl\u00f3w, wi\u0119c dzia\u0142anie Programu 7 widoczne jest na wykresach poni\u017cej:<\/p>\n
\"\"
Wykres 10: wynik programu 7.<\/p><\/div>\n
Sygna\u0142 HIGH trwa 2×62.5 ns czyli 125 ns, tyle samo trwa sygna\u0142 LOW, a ponowne uruchomienie loop()-a to 300 ns – razem 500 ns, co zgadza si\u0119 z powy\u017cszym rysunkiem. Lekko zmodyfikujmy kod, aby jak poprzednio generowane by\u0142y 3 prze\u0142\u0105czenia:<\/p>\n
\"\"
Program 7a: trzykrotne prze\u0142\u0105czenie pinu 7 w Arduino, kod w asemblerze.<\/p><\/div>\n
Wynik jest \u0142atwy do przewidzenia, poni\u017cej obraz:<\/p>\n
\"\"
Wykres 10a: wynik programy 7a.<\/p><\/div>\n
Zwr\u00f3\u0107 uwag\u0119, \u017ce wida\u0107 trzy r\u00f3wne sygna\u0142y HIGH (ka\u017cdy po 125 ns), rozdzielone doma przerwami (tak\u017ce po 125 ns – a trzecia przerwa, ostatnia d\u0142u\u017csza – o kolejne 300 ns). Ale ale, poprzednio powiedzieli\u015bmy sobie, \u017ce operacje bitowe (SBI, CLI) trwaj\u0105 „a\u017c” 2 cykle, i aby to przyspieszy\u0107, mo\u017cna zast\u0105pi\u0107 to bezpo\u015brednim zmienieniem ca\u0142ego rejestru (nadpisaniem). W asemblerze robi si\u0119 to przez instrukcj\u0119 OUT a kod powinien wygl\u0105da\u0107 tak:<\/p>\n
OUT 0x0B, 0x80<\/p>\n
Czyli chcemy zapisa\u0107 bajt B1000000 (przypominam: 7 bit 1, reszta 0) do rejestru PORTD (0x0B). W asemblerze nie mog\u0119 u\u017cy\u0107 Arduiinowego B10000000 wi\u0119c powinienem wpisa\u0107 warto\u015b\u0107 128 (dziesi\u0119tnie), czyli 0x80 (szesnastkowo). Jednak… instrukcja OUT tego nie przyjmie. Ona \u0142aduje do rejestru 0x0B nie konkretn\u0105 warto\u015b\u0107, ale warto\u015b\u0107 innego rejestru. Trzeba wi\u0119c najpierw zapisa\u0107 sobie warto\u015b\u0107 0x80 do wolnego, roboczego rejestru (ja to zrobi\u0119 do rejestru r16) a nast\u0119pnie tak go wykorzystam:<\/p>\n
OUT 0x0B, r16<\/p>\n
Ca\u0142o\u015b\u0107 wygl\u0105da tak:<\/p>\n
\"\"
Program 8a: nadpisanie ca\u0142ego rejestru PORTD bez instrukcji SBI\/CBI.<\/p><\/div>\n
 <\/p>\n
\"\"
Wykres 11a: wynik dzia\u0142ania Proramu 8a. Stan HIGH trwa kr\u00f3tko (w rzeczywisto\u015bci 62ns, ale dla analizatora to 42 ns).<\/p><\/div>\n
Oczywi\u015bcie w kodzie pojawi\u0142 si\u0119 te\u017c roboczy rejestr r17, kt\u00f3ry przechowuje warto\u015b\u0107 zero. No i kolejna drobnostka: jeden raz, na pocz\u0105tku w setup()-ie, \u0142aduj\u0119 odpowiednie warto\u015bci do rejestr\u00f3w r16 i r17 (nie chc\u0119 tego robi\u0107 za ka\u017cdym razem, bo bym traci\u0142 kolejne cykle na wywo\u0142anie instrukcji LDI). Minimalna modyfikacja kodu o generowanie trzech prze\u0142\u0105cze\u0144:<\/p>\n
\"\"
Program 8b: trzy prze\u0142\u0105czenia!<\/p><\/div>\n
Wynik dzia\u0142ania poni\u017cej (dwie wersje, bo raz analizator informuje o 42 ns, a raz o 82 ns – mam nadziej\u0119, \u017ce wiesz, dlaczego):<\/p>\n
\"\"
Wykres 12a: wynik programu 8b. Pomiar d\u0142ugo\u015bci sygna\u0142u HIGHT.<\/p><\/div>\n
 <\/p>\n
\"\"
Wykres 12b: wynik programu 8b. Pomiar d\u0142ugo\u015bci przerwy loop(), czyli 333 ns (minus jeden OUT).<\/p><\/div>\n
 <\/p>\n
\"\"
Wykres 12c: wynik programu 8b – kolejne uruchomienie, zamiana czas\u00f3w HIGH\/LOW.<\/p><\/div>\n
Ponownie widzimy mega-szybkie prze\u0142\u0105czanie pin\u00f3w (8 MHz), a czas trwania przerwy pomi\u0119dzy tr\u00f3jkami pik\u00f3w wynosi 333 ns. Ale 333 ns mo\u017cna jeszcze ulepszy\u0107!<\/strong> Czyli skr\u00f3ci\u0107 przerw\u0119 pomi\u0119dzy kolejnymi wywo\u0142aniami funkcji loop() – a w\u0142a\u015bciwie zrobi\u0107 tak, aby loop() wywo\u0142a\u0142a si\u0119 tylko jeden raz, a wewn\u0105trz niej bezwarunkowo odbywa\u0142 si\u0119 skok do zdefiniowanego miejsca w kodzie.<\/p>\n
\"\"
Program 9: skok wewn\u0105trz kodu asemblera.<\/p><\/div>\n
W tej wersji wstrzykni\u0119tego kodu asemblera definiuj\u0119 (linia 10) adres kodu jako Loop a nast\u0119pnie, po wykonaniu trzech prze\u0142\u0105cze\u0144 (jak poprzednio, w Programie 8) wykonuj\u0119 bezwarunkowy skok do tego miejsca programu (instrukcja RJMP, kt\u00f3ra trwa 2 cykle zegara – i st\u0105d to przyspieszenie!). W takiej wersji programu funkcja loop() wykonuje si\u0119 tylko jeden raz, a ponowne skoki do prze\u0142\u0105cze\u0144 – wewn\u0105trz niej. Szybciej si\u0119 nie da!<\/strong> Wynik poni\u017cej.<\/p>\n
\"\"
Wykres 13a: wynik programu 9 – tr\u00f3jki stan\u00f3w HIGH\/LOW, super szybkie…<\/p><\/div>\n
 <\/p>\n
\"\"
Wykres 13b: wynik programu 9 – najkr\u00f3tsze op\u00f3\u017anienie pomi\u0119dzy skokiem programu!<\/p><\/div>\n
Na koniec co\u015b dla zakochanych w asemblerze – ka\u017cdy asemblerowiec<\/em> zna instrukcj\u0119 NOP (no operation – pusty przebieg jednego cyklu, czyli nic-nie-robienie). Wbrew pozorom instrukcja NOP jest super u\u017cyteczna, np. w celu wprowadzenia pauzy (op\u00f3\u017anienia). Z tabeli 31 wiemy, \u017ce NOP trwa 1 cykl zegara, czyli wywo\u0142anie tej instrukcji to przerwa na 62.5 ns. Mo\u017cna zdefiniowa\u0107 p\u0119tl\u0119 takich instrukcji, aby mie\u0107 funkcj\u0119 czekaj\u0105c\u0105 np. 10 us itd. Poni\u017cej jednak ogranicz\u0119 si\u0119 do pojedynczego spowalniania kodu:<\/p>\n
\"\"
Program 10: kod w asemblerze z instrukcj\u0105 NOP (no operation).<\/p><\/div>\n
Jak mo\u017cna si\u0119 spodziewa\u0107 – sygna\u0142 HIGH trwa 2 cykle (bo jeden to NOP, a drugie to dzias\u0142anie OUT-a), a ponim pojawia si\u0119 sygna\u0142 LOW rozdzielony 1 cyklem (analizator wska\u017ce czasami 42 ns, czasmi 84 ns).<\/p>\n
\"\"
Wykres 14: wynik dzia\u0142ania programu 10.<\/p><\/div>\n
Podsumowanie<\/h2>\n
Wykorzystuj\u0105c analizator stan\u00f3w logicznych Saleae uda\u0142o si\u0119 sprawdzi\u0107, \u017ce porty Arduino mo\u017cemy prze\u0142\u0105cza\u0107 z cz\u0119stotliwo\u015bci\u0105 150 kHz gdy programujemy w dialekcie Arduino (z wykorzystaniem funkcji digitalWrite(), por\u00f3wnaj Program 2), albo nawet 8 MHz (czyli ponad 50x szybciej!<\/strong>) gdy programujemy bezpo\u015brednio rejestry ATmegi (PORTD, por\u00f3wnaj Program 6). My\u015bl\u0119, \u017ce pos\u0142ugiwanie si\u0119 portami nie jest trudne, cho\u0107 wymaga wykorzystania operacji logicznych na bitach (ale mo\u017cna zyska\u0107 nawet 50x przyspieszenie!). Okazuje si\u0119 tak\u017ce, \u017ce ponowne wywo\u0142anie funkcji loop() nie jest „za darmo” – to te\u017c przerwa ~300 ns (lub 200 ns, je\u015bli chcemy si\u0119 bawi\u0107 w asembler). Mam nadziej\u0119, \u017ce prezentacja r\u00f3\u017cnych oscyloskop\u00f3w by\u0142a ciekawa.<\/p>\n
O tym, \u017ce programuj\u0105c bezpo\u015brednio rejestry port\u00f3w zyskujemy bardzo du\u017co – niech przem\u00f3wi\u0105 poni\u017csze przyk\u0142ady zbudowania 8-bitowego wyj\u015bcia analogowego dla Arduino i wygenerowanie przebiegu pi\u0142okszta\u0142tnego i sinusa (wiadomo, jestem fizykiem, st\u0105d tak ma\u0142o wyszukane przyk\u0142ady…). Jest to temat z jednego z wyk\u0142ad\u00f3w, a tutaj przedstawi\u0119 tylko kilka wynik\u00f3w:<\/p>\n
\"\"
Arduino z 8-bitowym analogowym wyj\u015bciem (drabinka R2R). Uk\u0142ad z wyk\u0142adu dla student\u00f3w z fizyki.<\/p><\/div>\n
 <\/p>\n
\"\"
Wykres 15: por\u00f3wnanie cz\u0119stotliwo\u015bci generowanych sygna\u0142\u00f3w analogowych: (lewa strona) programowanie w dialekcie Arduino, (prawa strona) programowanie port\u00f3w. Przyspieszenie 25x. Dodatkowo: lewy obraz mocno zaszumiony. Wykorzystano BitScope.<\/p><\/div>\n
 <\/p>\n
\"\"
Wykres 16: por\u00f3wnanie cz\u0119stotliwo\u015bci generowanych sygna\u0142\u00f3w analogowych: (lewa strona) programowanie w dialekcie Arduino, (prawa strona) programowanie port\u00f3w. Przyspieszenie 20x. Dodatkowo: szumy dla pierwszego przypadku. Wykorzystano BitScope.<\/p><\/div>\n
Odczytywanie sygna\u0142\u00f3w – przerwania<\/h2>\n
Niebawem…..<\/p>\n
 <\/pre>\n
void setup() {
   Serial.begin(9600);
}<\/pre>\n
int licz=0;
void loop() {
   Serial.print(millis());
   Serial.print(\" \");
   licz++;
}<\/pre>\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Autorzy: KG + ?Zaawansowanie: badania trwaj\u0105, s\u0105 ju\u017c wst\u0119pne wynikiCel: wiedza, wiedza, wiedza – potem prze\u0142o\u017cona na praktyk\u0119 Motywacja Mikrokontroler ATmega 328P znajduj\u0105cy si\u0119 w platformie Arduino UNO (i innych, ale ta jest najbardziej popularna) dysponuje 14-toma wej\u015bciami\/wyj\u015bciami cyfrowymi (skupiam si\u0119 jedynie na portach cyfrowych, pomijam analogowe). Porty te zgrupowane s\u0105 w trzech bankach (B,C,D) […]<\/p>\n","protected":false},"author":5,"featured_media":3094,"parent":1715,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"ngg_post_thumbnail":0,"footnotes":""},"class_list":["post-3086","page","type-page","status-publish","has-post-thumbnail","hentry","post","post-with-thumbnail","post-with-thumbnail-large"],"_links":{"self":[{"href":"https:\/\/physics.uwb.edu.pl\/wf\/fi-bot\/index.php?rest_route=\/wp\/v2\/pages\/3086","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/physics.uwb.edu.pl\/wf\/fi-bot\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/physics.uwb.edu.pl\/wf\/fi-bot\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/physics.uwb.edu.pl\/wf\/fi-bot\/index.php?rest_route=\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/physics.uwb.edu.pl\/wf\/fi-bot\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3086"}],"version-history":[{"count":66,"href":"https:\/\/physics.uwb.edu.pl\/wf\/fi-bot\/index.php?rest_route=\/wp\/v2\/pages\/3086\/revisions"}],"predecessor-version":[{"id":3371,"href":"https:\/\/physics.uwb.edu.pl\/wf\/fi-bot\/index.php?rest_route=\/wp\/v2\/pages\/3086\/revisions\/3371"}],"up":[{"embeddable":true,"href":"https:\/\/physics.uwb.edu.pl\/wf\/fi-bot\/index.php?rest_route=\/wp\/v2\/pages\/1715"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/physics.uwb.edu.pl\/wf\/fi-bot\/index.php?rest_route=\/wp\/v2\/media\/3094"}],"wp:attachment":[{"href":"https:\/\/physics.uwb.edu.pl\/wf\/fi-bot\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3086"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}