[michal_]

#programowanie #java

Piszę aplikacje na studia do pobierania danych z żyroskopu (MPU-3300) poprzez I2C. Używam do tego Pi4J, odczytanie jednego rejestru trwa około 0,5 milisekundy, co przy 3 osiach, każdy po 2 rejestry daje mi wynik co 3 milisekundy, co jest dla mnie trochę za wolno.

Czy istnieje jakiś sposób na zmniejszenie tego czasu do np 1 milisekundy? Może istnieje jakaś biblioteka, która działa szybciej?

Inną opcją jest bufor FIFO
Mam do dyspozycji 1024 bajtowy bufor FIFO, mogę ustalić częstotliwość zapisu do buforu na 1 kHz, co mi da wynik, który mnie interesuje, ale wtedy nie będę mógł odczytać na czas wszystkich danych zanim mi się bufor zapełni.

[TheNewIcek]

@michal_: sam jestem ciekaw jak wygladaja czasy w Javie przy tego typu projektach :D. Ale cos czuje w kosciach, ze nie bedzie to low-latency

[b0lec]

hmmm tak se myślę że jeżeli zależy ci na szybkim odczycie to musiałbyś pobierać te odczyty jakoś równolegle - czyli od razu ze wszystkich rejestrów, tylko no nie znam się na tym co opisujesz i nie wiem czy istnieje techniczna możliwość w tym przypadku.
Czy szyna komunikacyjna na takie coś pozwala - od tego bym zaczął.

[TheNewIcek]

@b0lec: @michal_: i2c nie pozwala na "rownolegly odczyt", ale te milisekundy to dlugo. Normalny standard I2C to 100kHz, fast mode 400kHz, wiec nie powinno to tyle trwac. Zakladam, ze rejestr w MPU-3300 to jest 1-2 bajty. Pytanie jeszcze czy sam MPU-3300 nie potrzebuje czasu na "odczyt"/aktualizacje danych.

[michal_]

@TheNewIcek: Tak rejestr to 1 bajt. No właśnie się zastanawiam czy tyle czasu tracę przez użycie javy, bo nawet dla 100kHz to daje nam to 10 mikrosekund, a nie 500

[b0lec]

@TheNewIcek: no i jeszcze kolega korzysta tu zapewne z jakiejś libki i wysoce prawdopodobne że kod nie jest do końca zoptymalizowany - tu też może być ból. Java pod tym względem nie różni się od C - jeżeli zależy nam na wydajności musimy mieć pełną świadomość tego co robimy :-)

[TheNewIcek]

@michal_: @b0lec: Java to jedno, drugie to wlasnie jak ta biblioteka jest zaimplementowana. Szybko rzucilem okiem i Pi4J po JNI uzywa biblioteki WiringPI, a ta z kolei juz operuje sobie na /dev/i2c-*. Nie wiem jakie masz opoznienia dzieki samej Javie, jakie dzieki "komunikacji" Java <-> C, do tego dochodzi koszt przechodzenia user-kernel space no i Twoj proces na czas "read"-a moze pojsc sobie spac i Linux moze go wznowic "kiedy

[michal_]

@TheNewIcek: @b0lec: Mogę przejść na SPI, nie jestem tutaj niczym ograniczony, myślicie że użycie szybszej magistrali pomoże?

[TheNewIcek]

@michal_: obawiam sie, ze czas samej transmisji jest tutaj najmniejszym problemem. Jak masz jakis oscyloskop/analizator stanow logicznych to mozesz to sobie zbadac.

[b0lec]

@michal_ a może zaciągnąć najnowszą wersję ze snapshota ewentualnie możesz też im zgłosić issue na githubie żeby poprawili https://github.com/Pi4J/pi4j/issues

[michal_]

@TheNewIcek: Racja, jeśli po I2C nie osiągam nawet 100kHz, to po SPI też nie osiągne
@b0lec: Spróbuje na snapshocie

[TheNewIcek]

@michal_: a czemu Java i RPi?

[michal_]

@TheNewIcek: Tworze na magistra aplikacje do zbierania danych z robota i zewnętrznych sensorów, w czasie rzeczywistym porównuje dane z obu urządzeń. Potrzebowałem coś co można zamontować na robocie i nie będzie przeszkadzało w jego pracy. Co do języka to ostatnie 2 lata pracowałem w tym języku, a jakbym miał walczyć z C lub C++ w którym ostatnio pisałem bardzo proste programy 5 lat temu, to niezbyt mi się to podobało

[GotoFinal]

@michal_: a jak mierzysz ten czas? Bo java się na początku rozgrzewa, więc wszystko trwa wolniej przez jakiś czas (metody są optymalizowane po X wykonaniach).
A tak to problemy z wydajnością mogą też być w jakimś twoim kodzie lub tej libce co daje wsparcie. Trudno powiedzieć skąd dokładnie takie opóźnienia się biorą bez profilowania.

[michal_]

@GotoFinal: Używam tego rozwiązania: https://stackoverflow.com/a/13001673

Mam tutaj pełną świadomość, że nie jest to idealna dokładność aktualnego czasu, tutaj zależy mi tylko na posiadaniu wyniku pomiędzy pomiarami.

[GotoFinal]

@michal_: to nie ma sensu :D pierwsze wykonanie metody z danej klasy potrafi być setki razy wolniejsze niż drugie (java ładuje klasy dopiero przy pierwszym użyciu) do tego do mierzenia czasu, jak już, to się robi różnicę nanoTime na początku i końcu kodu, ale to i tak słaby pomysł, do benchmarków są specjalnie frameworki jak JHM, i tylko z nimi można dostać sensowne wyniki.

[michal_]

@GotoFinal: O widzisz, czegoś takiego potrzebowałem. Dziękuję :)

[GotoFinal]

@michal_: tylko takich fraemworków też trzeba się nauczyć obsługiwać, ale jest to o wiele prostsze niż pamiętanie o wszystkich zasadach dobrego benchamrku samemu :D