Stanowisko do badania prędkości - Raspberry Pi, Python, czujniki PNP

[H1M4W4R1]

36 minut temu, Treker napisał:

Dokładnie tak, tylko, że lepsze podzespoły RPi4 wcale nie oznaczają lepszej wydajności w niektórych zastosowaniach - to po prostu zupełnie różne układy. RPi4 najlepiej porównać wprost do komputera PC, a Arduino do jakiegoś sterownika, który odpowiada za pracę konkretnego urządzenia np. expresu do kawy lub drukarki 3D.

39 minut temu, Czolgista napisał:

Aha, to jak rozumiem Pico jest jakby odpowiednikiem Arduino bo bezpośrednio programujemy w nim C lub MicroPythona, zaś rozbudowane Raspberry (np. 4) to już inna bajka, bo mamy tam system Linuxa oraz lepsze parametry podzespołów, zgadza się? Czyli w takiej opcji (droższej oczywiście), można śmiało robić to Pythonem bo czasy obliczeń będą bardzo krótkie.

Dodam jeszcze, że komputer lepiej sobie radzi ze wstępnym przetwarzaniem danych a mikrokontroler z zadaniami czasu rzeczywistego  Przykład: slicing i drukowanie na drukarce 3D (chociaż Klipper stoi na linuxie, ale nadal wykorzystuje mikrokontroler do zarządzania funkcjami których wykonanie w określonym czasie jest krytyczne). Niby istnieje Linux-RT, ale działanie czasami pozostawia trochę do życzenia (do prac zgrubnych jest OK, ale do rzeczy bardzo precyzyjnych nadal nie dorównuje mikrokontrolerom).

[ethanak]

Reasumując: sprzęt się dobiera do zadania. A język programowania do zadania i do sprzętu. Bo potem się okazuje, że do upieczenia tortu nie wystarczy, że ktoś trochę umie ugotować jajko na twardo

[Elvis]

Jak już jesteśmy przy dobieraniu sprzętu, to proponuję zamiast dyskutować czy mikrokontroler, czy mikroprocesor jest lepszy - bardziej skupić się na dedykowanym sprzęcie. Rozwiązanie polegające na programowym zapamiętaniu czasu pierwszego sygnału a następnie aktywnym czekaniu na drugi będzie działało trochę lepiej na mikrokontrolerze niż mikroprocesorze, ale ogólnie jest to po prostu zła metoda.

Do pomiaru czasu najlepiej jest użyć dedykowanego modułu peryferyjnego, czyli licznika / timera. Nie każdy mikrokontroler ma odpowiedni do postawionych wymagań moduł, a znajdziemy i mikroprocesory wyposażone odpowiednie peryferia (np. STM32MP15x).

Dopiero używając modułu sprzętowego otrzymamy wyniki o oczekiwanej powtarzalności i rozdzielczości, a co najważniejsze użyty język programowania nie będzie miał znaczenia - do odczytu wartości ze sprzętowych rejestrów w zupełności wystarczy Python, czy JavaScript.

[pmochocki]

2 godziny temu, Elvis napisał:

Nie każdy mikrokontroler ma odpowiedni do postawionych wymagań moduł, a znajdziemy i mikroprocesory wyposażone odpowiednie peryferia (np. STM32MP15x).

@Elvis Możesz proszę rozwinąć o jakie dokładnie peryferia masz na myśli? Ja nie mam dużego doświadczenia z STM32, ale gdybym ja miał wybrać jakiś sprzęt to pewnie bym wybrał STM32Fx i użył DWT (Data Watchpoint Trigger). A Ty co proponujesz użyć w STM32MP15x?

[Elvis]

@pmochocki Trochę się nie zrozumieliśmy - podałem SMT32MP15x tylko jako przykład, że można użyć mikroprocesora. Ten SoC jest wyposażony w zaawansowane układy licznikowe, w sumie podobne znanych z małych STM32Fxxx.  Pewnie inne układy, jak powiedzmy i.MX7 też mają podobne moduły, ale nie znam ich dość dobrze, stąd przykład STM32MP.

Jak chodzi o moduły sprzętowe, to ja użyłbym po prostu 32-bitowego timera, podobnie do sposobu opisywanego w kursie STM32L4: https://forbot.pl/blog/kurs-stm32l4-zdalne-sterowanie-ir-nec-liczniki-id49684 Układy STM32 są bardzo bogato wyposażone w układy licznikowe, więc bez problemu można wybrać model z 32-bitowym modułem i wówczas całe zbieranie danych będzie banalne. Po prostu uruchamiamy licznik i czekamy aż dane zostaną zapisane w rejestrach sprzętowych po zakończeniu doświadczenia. Możemy je odczytać natychmiast używając np. przerwań, ale nie musimy, bo wyniki i tak będą zapisane w sprzęcie, więc nie musimy jakoś szczególnie optymalizować naszego programu. Ale co najważniejsze dane są zapisywane sprzętowo, czyli nie będzie problemów związanych z opóźnieniami przez np. obsługę przerwań. Mamy dokładny wynik, uzależniony właściwie tylko dokładnością zegara taktującego mikrokontroler.

W przypadku innych układów trzeba dokładniej sprawdzić, jakie moduły mogą być wykorzystane. W przypadku RP2040 chyba PIO mogłoby się nadawać, natomiast AVR / Arduino Uno może być nieco zbyt ograniczony - ma oczywiście sprzętowe timery, ale nie wiem czy wystarczające w tym przypadku.

 

[ethanak]

3 minuty temu, Elvis napisał:

AVR / Arduino Uno może być nieco zbyt ograniczony - ma oczywiście sprzętowe timery, ale nie wiem czy wystarczające w tym przypadku

Wydaje mi się (uwaga: tylko wydaje) że AVR by wystarczył, ale osobiście gdybym miał to robić to albo właśnie na RP2040, albo pogmerałbym w ESP32 - może któryś z jego wewnętrznych śmiesznych układzików by się nadał?

 

[Elvis]

8 minut temu, ethanak napisał:

Wydaje mi się (uwaga: tylko wydaje) że AVR by wystarczył,

Nie będę się upierać, że nie - ale trzeba byłoby na spokojnie wszystko policzyć. Po pierwsze jaka ma być rozdzielczość (czasowa) pomiaru. Wcześniej mówiliśmy o 1us, później pojawiały się nawet pomysły mierzone w nanosekundach. Przy prędkości 4m/s, pomiar zajmuje jakieś 10ms, ale nie wiem, czy to najniższa mierzalna prędkość. W przypadku rozdzielczości 1us i czasu 10ms, mamy więc licznik zliczający do 10.000. Dlatego 8-bitowy może być nieco za mały, 16-bitowy teoretycznie wystarczy, ale jeśli chcemy zejść poniżej 1us, albo mieć możliwość pomiaru wolniejszego spadania, też może być trudniej.

Oczywiście wszystko "da się zrobić". Chodziło mi tylko prostotę i wygodę. Mając licznik 32 bitowy o 2 wejściach (a takie mają STM32), po prostu uruchamiamy moduł licznikowy i czekamy aż sprzęt pobierze wyniki - nic nie musimy robić poza odjęciem gotowych rezultatów.

Ale jak ktoś lubi wyzwania to na pewno i na attiny da sobie radę. Tylko zakładam, że tutaj szukamy prostych, a nie finezyjnych rozwiązań

[pmochocki]

Uważam, że AVR dał by radę. Wystarczy zastosować metodę pomiaru jaką stosowałem tu do kalibrowania zegara za pomoca PulsePerSecond z modułu GPS:

No i oczywiście zegar taktujący licznika musiałby być szybki - ale np. taki stary ATTiny85 ma PPLa i bez problemu może timer taktować 64MHz:

Edytowano Listopad 29, 2022 przez pmochocki

[Czolgista]

No i tyle opinii, że ja tym bardziej  nie wiem jak w kwestii pomiaru czasu. Załóżmy, że wybrałbym jednak opcję mikrokontrolera z zaprogramowaniem przez osobę znającą się na tym, a sobie zostawił ew. napisanie programu w Pythonie, wyświetlającego wyniki na komputerze (jak się nie uda, to zawsze zostaje opcja ręcznej kalkulacji  albo zlecenia). Ale jaki zatem mikrokontroler wybrać i czy bazować na wbudowanym timerze, czy dołożyć coś z zewnątrz...i na co jeszcze zwrócić uwagę.

[pmochocki]

1 godzinę temu, Czolgista napisał:

Załóżmy, że wybrałbym jednak opcję mikrokontrolera z zaprogramowaniem przez osobę znającą się na tym

To może osoba, która by miałaby to zrobić wybierze sobie mikrokontroler...

[Treker (Damian Szymański)]

@Czolgista a tak z czystej ciekawości mam trochę inne pytanie. Jak zrozumiałem z poprzednich postów próbujesz chyba we własnym zakresie odtworzyć jakieś urządzenie, które jest już dostępne w sprzedaży. Pisałeś coś o firmie pepperl-fuchs. Możesz z ciekawości pokazać konkretnie to urządzenie, wiesz jaką ma cenę?

[Czolgista]

Pokazać niestety nie mogę. To jest urządzenie, w którym obiekt spada swobodnie z określonej wysokości i mierzymy prędkość zanim uderzy w próbkę. Ceny na tę chwilę nie znam, próbujemy zrobić własne rozwiązanie, zobaczymy jak wyjdzie kosztowo i wtedy porównamy do ceny zakupu całości. Czujnik był przykładowy, ale jednak z niego zrezygnujemy bo cena jest za wysoka, a udało się znaleźć o podobnej specyfikacji znacznie tańszy.