Czy Pi ma wystarczającą moc do projektu oscyloskopu?

Moim celem jest tworzenie instrumentów opartych na Pi, zaczynając od oscyloskopu. Więc czytam odpowiedzi na

• Jakie konwertery analogowo-cyfrowe są dostępne dla RPI?
• Jak podłączyć konwerter analogowo-cyfrowy (ADC)?

Wydaje się, że możliwe jest odczytanie wejść analogowych przy bardzo niskich częstotliwościach próbkowania, ale zastanawiam się, czy mógłbym osiągnąć mega prędkości próbkowania na sekundę. Ciągłe gromadzenie danych byłoby prawdopodobnie trudne, jeśli jest to w ogóle możliwe, więc mogę się bez tego obejść. Czy Pi nie byłby do tego przygotowany? Chcę obserwować przebiegi najpierw na wyświetlaczach podłączonych do Pi, a później na urządzeniach mobilnych (podczas gdy Pi przesyła do nich dane bezprzewodowe).

Moje doświadczenie z układami system-on-chip mówi mi, że systemy te mogą łatwo nasycić się ciągłym We / Wy. Czy to samo dotyczy Pi?

Spójrzmy na ogólny przegląd tego, co ma oscyloskop:

Najpierw mamy analogowy interfejs. Tutaj mamy sieć dopasowującą impedancję dla sond (ale sondy będą musiały również mieć część dopasowującą pojemność), sekcję tłumienia (bardzo ważne, aby nie przeciążać ADC i nie wpuszczać wysokich napięć), wyzwalanie i połączenie z Analogowy do cyfrowego konwertera. Nie będę za dużo o tym mówić, ponieważ nie jestem zbyt dobry w analogowych rzeczach, ale sedno jest następujące: nic nie możemy zrobić z Pi w tej sekcji.

Następnie mamy część konwertera analogowo-cyfrowego. Będziesz potrzebował co najmniej jednego ADC dla każdego kanału. Więcej można zastosować w celu zwiększenia częstotliwości próbkowania. W tradycyjnym zakresie ADC jest podłączony do układu ASIC lub FPGA. Są używane, ponieważ tradycyjne komputery nie mają wystarczającej ilości czasu rzeczywistego (i nie mylą czasu rzeczywistego z szybkim!) Do przetwarzania danych dostarczonych przez ADC. Te dane są następnie przechowywane w jakiejś pamięci RAM. Niektóre urządzenia będą używać statycznej pamięci RAM, a inne będą używać dynamicznej pamięci RAM. Ogólnie rzecz biorąc, podejście SRAM jest bardziej tradycyjne i jest postrzegane przez znanych producentów, podczas gdy użycie DRAM wydaje się być nowszym podejściem obserwowanym w tańszych urządzeniach zaprojektowanych w Chinach.

Ilość pamięci RAM i jej szybkość określą, ile próbek można zapisać. Prawie zawsze ADC będzie ADC 8-bitowym, więc powiedzmy, że jeden megasample będzie nam potrzebny 8 b razy 100000 = 8 Mb lub 1 MB pamięci RAM. Dla jednego MSa / s potrzebujemy pamięci RAM, która może pracować z taką prędkością. Dziś powinno to być stosunkowo łatwe do uzyskania. FPGA zwykle napędza pamięć RAM bezpośrednio i jest odpowiedzialna za przechowywanie w niej danych. Działa poprzez wypełnienie pamięci próbki, gdy jest jeszcze pusty pokój, a następnie nadpisanie jej, gdy jest pełna. Gdy na kanał przypada kilka przetworników ADC, układ FPGA ustawi je tak, aby najpierw rozpoczynało próbkowanie, a następnie na drugi zegar i tak dalej. Po zakończeniu próbkowania próbka pierwszego ADC zostanie najpierw zapisana w pamięci, a następnie próbka drugiego ADC. To sprawi, że ADC będą próbkować szybciej niż w rzeczywistości.

Kolejnym punktem w tej sekcji jest to, że próbki powinny być jednakowo odległe w czasie. Jest to główny problem z użyciem komputerów PC w oscyloskopach i powód, dla którego dominują układy FPGA i ASIC. Jeśli niektóre próbki są spóźnione lub wczesne, obraz przedstawiony na ekranie będzie nieprawidłowy.

W tej części widzimy pierwsze możliwe użycie Pi. Jeśli częstotliwość próbkowania jest wystarczająco niska, możemy być w stanie wyprowadzić ADC bezpośrednio z Pi i zapisać ich wyniki w pamięci RAM Pi. To, jak szybko możemy jechać, zależy od sposobu podłączenia ADC do Pi i od tego, jak Pi wykonuje swoje operacje I / O. Z tego, co przeczytałem, najwyższa prędkość portów I ^ 2C Pi wynosi 150 MHz (to, jak łatwo byłoby to osiągnąć w GNU / Linux to kolejne pytanie), podczas gdy najwyższa standardowa prędkość wynosi 5 MHz, a dla SPI najwyższa prędkość w Pi wynosi 250 MHz. Nie jestem pewien, jaka jest najwyższa standardowa prędkość SPI, ale spodziewam się, że będzie ona maksymalnie w zakresie 100 MHz.

Tak więc teoretycznie mamy ponad wystarczającą prędkość na Pi, aby uruchomić ADC w niskim zakresie MSa / s. Mam wrażenie, że szybkość pamięci RAM nie będzie tutaj problemem, ale nie mam danych, aby to zrobić. W takim przypadku mielibyśmy dużą przewagę nad zwykłymi zakresami: dostępna byłaby bardzo duża ilość pamięci przechwytywania. Na przykład, jeśli poświęcimy 32 MiB pamięci RAM dla programu na pamięć próbną i mamy dwa kanały, to dałoby nam 16 MiB na każdy kanał lub nieco więcej niż 134 Mb lub 134 megampar na kanał. Jest to coś, czego nawet dzisiaj nie ma wiele oscyloskopów.

Minusem jest to, że potrzebowalibyśmy ciężkich modyfikacji systemu operacyjnego, aby móc uzyskać dokładne próbkowanie tutaj. Nie mam doświadczenia z Linuksem w czasie rzeczywistym, więc nie wiem, jakie to byłoby łatwe.

W każdym razie przejdźmy do następnego kroku. Mamy więc system próbkowania, który wypełnia pamięć RAM. Następna część to spust. Trigger jest ściśle powiązany z częstotliwością odświeżania ekranu. Zasadniczo polega na znalezieniu interesującej próbki i zachowaniu jej w pamięci. Po uruchomieniu zakresu próbkowanie jest kontynuowane po wyzwoleniu, dopóki nie zapełni pamięci, a następnie wyśle ​​ją do przetworzenia i wyświetlenia na ekranie. Podczas przetwarzania danych system próbkowania często zamrożony i czeka na wyświetlenie danych. Właśnie dlatego dolne zakresy mają niższe częstotliwości odświeżania, podczas gdy górne zakresy będą miały specjalne wyświetlacze o wysokiej częstotliwości odświeżania i spędzą znacznie mniej czasu na oczekiwaniu na wyświetlenie danych.

W tej sekcji często pojawia się inny układ ASIC lub FPGA, który będzie przetwarzał sygnał na próbkach, dowolne dekodowanie protokołu, jeśli zakres go obsługuje i faktycznie steruje samym wyświetlaczem.

To jest część, w której z tego, co widzę, Pi może naprawdę zabłysnąć. Może obsługiwać ładny wyświetlacz 1920x1080 (podczas gdy zakresy często znajdują się w obszarze sub 800x600) i może bardzo dobrze dekodować protokół. Jedyny problem, jaki widzę, to szybkość i wpływ przetwarzania na czas wstrzymania. Jeśli zdecydujemy się na niską częstotliwość odświeżania, możemy uzyskać naprawdę dobry analizator logiki.

Na koniec słowo o oscyloskopach USB i dlaczego USB jest ogólnie zły w tego typu projektach: tradycyjny oscyloskop USB pobiera dane i pobiera próbki oraz przesyła dane próbkowania do komputera PC w celu przetworzenia, dla którego istnieje aplikacja hosta. Zasadniczo coś bardzo podobnego zrobiłoby się również z Pi. Zwykle aplikacje na PC są źle zaprojektowane i pełne błędów. Kolejną wadą jest sam USB. Jest reklamowany jako szybka magistrala, która może osiągnąć 480 Mb / s w trybie „Hi-Speed”. Prawda jest taka, że ​​niezwykle rzadko można znaleźć kontroler USB, który może obsługiwać tak wysokie prędkości (średnia wydaje się wynosić około 250 Mb / s z tego, co widziałem) i że jako protokół nie jest bardzo odpowiedni dla żadnego prawdziwego -czasowa aplikacja. Najpierw jest współdzielony przez wszystkie urządzenia w koncentratorze (a Pi ma tylko jeden port USB, do którego podłączony jest Ethernet + Hub USB), ma stosunkowo wysoki narzut (w porównaniu do powiedzmy SPI) i ma duże opóźnienie (pamiętaj, że przy 1 MSa / s każda próbka trwa tylko 1 µs, więc musimy mieć pamięć na płycie, ponieważ nie możemy wysyłać próbek w czasie rzeczywistym przez USB). Wreszcie użycie USB sprawiłoby, że akwizycja danych stałaby się po prostu kolejnym oscyloskopem USB i tutaj tracimy jakąkolwiek korzyść z korzystania z Pi: Tradycyjne komputery stacjonarne są znacznie bardziej powszechne, szybsze, łatwiejsze do uzyskania i mają znacznie lepsze możliwości USB.

EDYCJA Przeczytałem stosunkowo niedawny post Gert van Loo i według niego, realistyczne prędkości dla Pi I ^ 2C wynoszą 400 kHz, a dla SPI wynoszą 20 MHz.

Odkryliśmy, że Raspberry Pi jest doskonałą platformą do uruchamiania oprogramowania, którego potrzebujesz do takiego projektu. Problemem jest przede wszystkim przekazywanie sygnałów do RPi i wykonywanie szybkiego przechwytywania sygnału w czasie rzeczywistym bez zakłóceń na tym samym procesorze, na którym działa system operacyjny i oprogramowanie. Naszym rozwiązaniem jest oscyloskop BitScope Raspberry Pi który łączy BitScope (do szybkiego przechwytywania fali sygnału mieszanego) z Raspberry Pi, który obsługuje wszystkie niezbędne oprogramowanie.

Uwaga: Jest to bardziej „głośno myślący” fragment tekstu, niż prawdziwa odpowiedź

Pomysł ten przyszedł mi do głowy jakiś czas temu i nadal podoba mi się ogólny pomysł!

O ile mi wiadomo, wysokiej klasy lunety są od 15 lat (a nawet więcej) tylko komputerami (PC) z szeregiem specjalistycznych szybkich I / O. Myślę, że kiedy podobne I / O zostanie zaprojektowane / podłączone do RPi, wynik może być zaskakująco dobry.

IMHO dobrym sposobem na to jest pozwolić RPi po prostu przechowywać i wyświetlać zebrane dane (otrzymane na przykład przez port USB) i pozwolić wyspecjalizowanemu sprzętowi wykonać szybki pomiar. Ta szybka jednostka pomiarowa może być następnie kontrolowana przez RPi na podstawie danych wprowadzonych przez użytkownika lub czegoś podobnego.

W pierwszej wersji RPi były / są pewne problemy z portami USB, ostatnio nie szukałem, jeśli są one obecnie rozwiązane. Słyszałem także pogłoskę, że nowa wersja RPi 2.0 nie powinna mieć tych problemów, ale też nie sprawdziłem tej plotki.

Myślę, że wyniki bez zewnętrznego (specjalistycznego) sprzętu są ograniczone ze względu na liczbę portów I / O i fakt, że działa na nim cały system operacyjny (co ogranicza opcje w czasie rzeczywistym). Chyba że planujesz napisać własny system operacyjny?

Także użycie na przykład układów I2C do tego celu nie będzie miało wystarczającej prędkości, aby zrobić coś naprawdę fajnego. SPI zapewnia już znacznie większą przepustowość (do 100 MHz z góry mojej głowy), ale wybrałbym USB i w razie potrzeby kompresowałbym lub korzystałem z dobrego schematu kodowania przed wysłaniem danych, aby uzyskać większą przepustowość.

Sądzę więc, że jest to możliwe, ale sprzęt, który należy dodać do RPi, będzie znacznie droższy niż sam RPi.

Wreszcie (zanim przestanę marzyć o tym temacie) nie zdziwiłbym się, gdyby wyszukiwanie w Internecie spowodowało, że jakaś grupa była już zajęta.

Odpowiedź brzmi tak.

Jest wystarczająco silny! Ale tylko w przypadku niektórych częstotliwości - jak wskazano już z powodu ograniczeń.

WIĘC! -> Musisz zapytać siebie, co chcesz zmierzyć?

• Ponieważ nie pytasz konkretnie, co chcesz zmierzyć, odpowiedzi są otwarte na spekulacje.
• Pozwól, że przedstawię Ci alternatywy i sugestie. Może możesz zadać nowe pytanie, które jest bardziej specyficzne dla Malin, a nie ogólny temat Oscylatora!

Oscylatory mogą wahać się od prostych niskich częstotliwości, które kosztują 5 USD, a następnie inne mogą obsłużyć do 50 Ghz + - to kosztuje tyle, co mały dom! 75 000 USD-100 000 USD!

Myślę, że Raspberry będzie wystarczająco dobry do pomiaru częstotliwości sub Giga, takich jak sygnały bezprzewodowe 433 MHz, komunikacja magistrali procesora o niskiej prędkości, TTS / UART, debugowanie I2C - niewiele więcej. Wyższe częstotliwości nie będą naprawdę dokładne, ponieważ z założenia Raspberry nie działa w czasie rzeczywistym. Musisz więc zacząć od systemu operacyjnego (lub, jak wspomniano, zewnętrznych urządzeń czasu rzeczywistego - ale o co zatem chodzi?)

Ale jeśli naprawdę chcesz mierzyć sygnały, możesz kupić naprawdę dobre i niedrogie urządzenie, które jest zgodne ze specyfikacjami Raspberry. Ale jest już dobrze zaprojektowany, pełen funkcji, naprawdę dojrzały w projektowaniu i udowodnił, że jest przydatny w środowisku hobbystycznym.

Nie ma potrzeby ponownego wymyślania koła tutaj. Na przykład DSO Nano dla pojedynczego kanału poniżej 100USD.

Nano Quad Channel DSO za mniej niż 200 USD

A potem, czego NIE MOŻE ZROBIĆ Raspberry lub podobne urządzenie!

I kosztował małą fortunę ...

• Do 110 Ghz, z dyskiem twardym do przechowywania danych, niezwykle precyzyjne, symulacje i wyzwalacze.
• Mierzy Buuetooth, WCDMA / EDGE / 3G / 4G, Wireless A / B / G / N 2,4 Ghz / 5 Ghz, SATA, AGP / PCI / PCI-Express, nieprzetworzone sygnały satelitarne, kanały głowicy dysku twardego, Ethernet itp. Itd. .

Możesz podłączyć jeden z naszych oscyloskopów / generatorów przebiegów arbitralnych TiePie Handyscope HS5 do portu USB. Biblioteka skompilowana dla Raspberry Pi do używania jednego lub wielu oscyloskopów jednocześnie jest dostępna do pobrania. Instrument wykorzystuje własne taktowanie i pamięć, więc nie ma utraty wydajności. Tak, więc Pi jest wystarczająco silny, aby wykonać projekt oscyloskopu.

Kluczowe parametry oscyloskopu: 2 kanały, 14 bitów, 500 MS / s, szerokość pasma 250 MHz, 20 MS / s 14 bitów ciągłe przesyłanie bez przerw, 32 pamięci MS na kanał, dokładność podstawy czasu 1 ppm.

Kluczowe parametry Arbitrary Wave Generator: przebiegi od 1 µHz do 30 MHz, 240 MS / s, 14 bitów, pamięć 64 MS, wyjście od -12 do 12 V (24 Vpp), dokładność podstawy czasu 1 ppm.

Twoja najlepsza szansa to wypróbowanie, czy sigrok i jego interfejs libsigrok można skompilować na Pi, a następnie kupić kompatybilny oscyloskop. W ten sposób możesz pobierać sygnały do ​​24 mega próbek na sekundę. Mając wystarczającą wiedzę, możesz dostosować oprogramowanie w dowolny sposób, w tym transmisję bezprzewodową do urządzeń mobilnych.

Ktoś mówi o Sigrok. Myślę, że najbliższym sposobem jest użycie dobrze udokumentowanego CY7C68013A ze sterownikiem EZ-USB FX2LP. Na komputerze stacjonarnym nie działało to z Weezy, ale na Jessy działa dobrze. Oto znane ograniczenie około 24 Msp. Myślałem o innym sposobie, używając interfejsu aparatu. Interfejs ten może zarządzać 2,1 megapiksela i 30 klatkami na sekundę, co oznacza, że ​​może przesyłać dane do GPU z prędkością ponad 60 mega „próbek” na sekundę. Staje się bardziej przydatny niż SPI 20 MHz lub USB.

Jeśli nie masz nic przeciwko ograniczeniu się do częstotliwości audio, używam niedrogiego 12-bitowego dwukanałowego konwertera A / D MCP3202 do akwizycji na pi ze spidev i pydatascope do wyświetlania danych przesyłanych przez Ethernet przez gniazdo TCP. Pydatascope działa również jako analizator widma!

Wprowadziłem stosunkowo trywialne zmiany w otwartym kodzie pydatascope, aby mieć podwójne kanały, głównie dlatego, że było to łatwe, a nie tak, że naprawdę go potrzebowałem.

Jeśli masz jakieś pytania, napisz do mnie dalsze informacje lub napisz do mnie bezpośrednio, chętnie pomogę.