STM32F7 Zbyt mała szybkość zapisu danych z czujników I2C na kartę SD

[radek04]

8 minut temu, matsobdev napisał:

A nie może obok F7 działać inny mikrokontroler pomocniczy, z którym masz lepsze doświadczenia??

Wolałbym nie. Zależy mi także na mobilności i stosunkowo niewielkim zużyciu energii. Urządzenie ma być przede wszystkim kompaktowe.

[kaworu]

10 minut temu, matsobdev napisał:

Datasheet wydaje się lepszym źródłem.

Ależ, nikt nie broni Ci go przytoczyć. Ale o ile nie wątpię, ze są pamięci, które działają jak byś chciał, tak nijak tego nie przekłada się to na "ogólną zasadę".

5 minut temu, radek04 napisał:

Identyczne jest wtedy wszystkie 48 rejestrów.

Jeśli dobrze widze to w ogole nie sprawdzasz czy się odczyt powiódł (ani nie czyścisz buforu przed odczytem). Więc jest szansa, zapisujesz dane z poprzedniego odczytu, które zostały w pamięci.

Edytowano Listopad 27, 2022 przez kaworu

[radek04]

20 minut temu, kaworu napisał:

Jeśli dobrze widze to w ogole nie sprawdzasz czy się odczyt powiódł (ani nie czyścisz buforu przed odczytem). Więc jest szansa, zapisujesz dane z poprzedniego odczytu, które zostały w pamięci.

Tak. Trochę celowo, by maksymalnie zaoszczędzić czas, trochę przez brak umiejętności.
Myślałem np. o wykorzystaniu przerwań z czujników, ale łatwiej było mi zrobić przerwanie timera.
Zdaje się, że te błędy wynikają właśnie z faktu, że układ nie wyrabia się czasowo z odczytem i zapisem w czasie jednego przerwania. Przy przerwaniu timera równym 100 Hz lub 200 Hz problem nie występuje. Przy 300 Hz powtarzają się dane z niektórych czujników.

Edytowano Listopad 27, 2022 przez radek04

[kaworu]

1 minutę temu, radek04 napisał:

Tak. Trochę celowo, by maksymalnie zaoszczędzić czas, trochę przez brak umiejętności.

Nie wydaje mi się, żeby to tu miało znaczenie czasowe. Dodaj sobie memset() przed odczytem na buforach, będziesz widział czy nieudany odczyt po samych zapisanych danych.

3 minuty temu, radek04 napisał:

Myślałem np. o wykorzystaniu przerwań z czujników, ale łatwiej było mi zrobić przerwanie timera.

Jak dla mnie to jest ok.

3 minuty temu, radek04 napisał:

Zdaje się, że te błędy wynikają właśnie z faktu, że układ nie wyrabia się czasowo z odczytem i zapisem w czasie jednego przerwania. Przy przerwaniu timera równym 100 Hz problem nie występuje.

O ile bym Ci chciał pomóc, to jesli chodzi o sprzęt to spoko, ale jak chodzi o to jakie dziwne rzeczy robi HAL to już nie bardzo. Ale może na początek zapisz bezpośrednio dane binarne na te kartę - pomijając sprintf, który jest wygodny, ale kosztowny.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[radek04]

2 minuty temu, kaworu napisał:

Ale może na początek zapisz bezpośrednio dane binarne na te kartę - pomijając sprintf, który jest wygodny, ale kosztowny.

A jak to zrobić? Będę mógł je wtedy odczytać w PC?

[kaworu]

A skąd mam wiedzieć, nie chwaliłeś się czego używasz do analizy danych na PC 😄
Ale nawet jakby się nie dało, to możesz sobie napisać mały program, który odczyta z pliku te dane binarne i wypluje z siebie inny plik, w formacie jaki potrzebujesz. Tak czy inaczej, oznacz jako komentarz ten sprintf (zapiszą ci sie na SD śmieci ale to chwilowo bez znaczenia) i zobacz czy to Ci coś daje względem czasu, bo może masz wąskie gardło gdzie indziej.

[Anonim]

By obliczyć prędkość  należy znać dwie wielkości  przyrost drogi i przyrost czasu czyli Δs i Δt.Dla prędkości kątowej potrzebne jest Δα i Δt.Specjalnie nie zapisałem dv,dt,dα bo te oznaczenia stosowane są w matematyce jako wielkości nieskończenie małe.W układach rzeczywistych mamy zawsze Δ...By obliczyć prędkość kątową trzeba pomierzyć zmianę kąta w jakimś odstępie czasu.Czas czyli Δt w takim akcelerometrze jest  ustawiony przez producenta(proszę nie zapominać,że w strukturze akcelerometru jest procesor cóś😀 na podobieństwo takiego jak stm32.Popatrz w tym programie wykorzystane jest przerwanie do odczytu

(htim->Instance == TIM10) //przerwanie pochodzi od timera 10
	

Podobnie jest w akcelerometrze.W tym programie podobno Δt czyli czas pomiędzy kolejnymi przerwaniami  jest 2ms.W akcelerometrze może być np.10µs.A zatem czas jest znany kąty pomiędzy poszczególnymi odczytami są znane.Wystarczy odjąć α2-α1 a otrzymamy Δα i podzielić przez czas,który z założenia jest znany i mamy prędkość kątową.

Akcelerometr doskonale nadaje się do pomiaru  fal sejsmicznych poprzecznych wszak sensorami są piezoelektryki.By to udowodnić wystarczy położyć czujnik z obsługującym go mikrokontrolerem STM32  na biurku, połączyć do komputera ,włączyć STMStudio,skonfigurować odpowiednio np.BarGraf i zacząć bębnić palcami  w blat biurka i popatrzeć na ekran.

[radek04]

21 minut temu, kaworu napisał:

A skąd mam wiedzieć, nie chwaliłeś się czego używasz do analizy danych na PC 😄
Ale nawet jakby się nie dało, to możesz sobie napisać mały program, który odczyta z pliku te dane binarne i wypluje z siebie inny plik, w formacie jaki potrzebujesz. Tak czy inaczej, oznacz jako komentarz ten sprintf (zapiszą ci sie na SD śmieci ale to chwilowo bez znaczenia) i zobacz czy to Ci coś daje względem czasu, bo może masz wąskie gardło gdzie indziej.

Dobry pomysł.
Na razie dane w formacie HEX odczytuję z pliku txt, a następnie przerabiam je na typ float w MATLAB. Tam też dokonam wstępnej analizy sygnału. Jeśli da radę, będę przerabiał te dane od razu do postaci float i w takiej formie zapisywał na kartę. Ale to jest temat może na kiedyś tam. Na razie eliminuję wszystkie wąskie gardła.

Edit: Sprawdziłem. Wyrzucenie sprintf() niczego nie zmieniło. Czyli to nie ta funkcja jest problemem.

Edytowano Listopad 27, 2022 przez radek04

[radek04]

3 minuty temu, szymonw napisał:

Podobnie jest w akcelerometrze.W tym programie podobno Δt czyli czas pomiędzy kolejnymi przerwaniami  jest 2ms.W akcelerometrze może być np.10µs.A zatem czas jest znany kąty pomiędzy poszczególnymi odczytami są znane.Wystarczy odjąć α2-α1 a otrzymamy Δα i podzielić przez czas,który z założenia jest znany i mamy prędkość kątową.

Z tego co wiem, w sensorach IMU o budowie MEMS (przynajmniej tych, których używałem - kilkanaście różnych modeli) stosuje się fizyczne struktury żyroskopu. Zasada ich działania jest zbliżona do akcelerometru, ale nie identyczna. Czułe są na prędkości kątowe, natomiast akcelerometr na przyśpieszenia liniowe.

[Anonim]

Nie wiem jak to napisać by Cię nie urazić ale jest problem  z wiedzą z zakresu klasycznej mechaniki według Nevtona  oraz geometrii analitycznej czyli wiedzy sprzed ponad 300 lat .Warto wziąć do ręki książki,które w tytule mają fizyka,geometria analityczna i poczytać.Naprawdę zrób to - warto.Jak przeczytasz i zrozumiesz to się uśmiejesz z tego co napisałeś a akcelerometr niewątpliwie pomoże w zrozumieniu

Edytowano Listopad 27, 2022 przez szymonw

[matsobdev]

2 godziny temu, radek04 napisał:

A jak to zrobić?

W sumie w poprzednim temacie wiedziałeś jak to zrobić, mianowicie bezpośrednio z rejestrów wysyłając dane.

 

2 godziny temu, szymonw napisał:

Wystarczy odjąć α2-α1 a otrzymamy Δα i podzielić przez czas,który z założenia jest znany i mamy prędkość kątową.

No tak, racja. Też o tym nie pomyślałem. W skali makro to może fajnie działać, mierząc średnią prędkość przy relatywnie małej prędkości obrotu. Tylko dynamicznie, w ruchu będą na te masy sejsmiczne działać siły, jakby chcąc próbkować bardzo gęsto, to te siły będą dominujące i będą obliczeniowe prędkości kątowe, których faktycznie nie ma. Weź np. płaski przypadek. Oś x w poziomie, y - pionowo. Jednostajny ruch w poziomie, x = 0, y = g. Przyspieszony, x = coś, y = g. Z obliczeń wyjdzie obrót, chociaż go nie było.

Tak od siebie, ogólnie do tematu. Wykonując pomiar sygnału, dobrze, aby częstotliwość próbkowania była co najmniej dwa razy większa od mierzonego sygnału, żeby poprawnie odwzorować jego charakterystykę. Jakiej częstotliwości drgań układu @radek04 się spodziewasz?

Edytowano Listopad 27, 2022 przez matsobdev

[radek04]

3 godziny temu, matsobdev napisał:

Tak od siebie, ogólnie do tematu. Wykonując pomiar sygnału, dobrze, aby częstotliwość próbkowania była co najmniej dwa razy większa od mierzonego sygnału, żeby poprawnie odwzorować jego charakterystykę. Jakiej częstotliwości drgań układu @radek04 się spodziewasz?

Dotychczas główne harmoniczne nie przekraczały 180 Hz, ale chcę zostawić sobie pewien zapas, ponieważ badane będą różne systemy. Akwizycja 500 Hz to było pierwsze założenie, jeśli uda się osiągnąć 400 Hz też będę zadowolony.

[radek04]

4 godziny temu, matsobdev napisał:

W sumie w poprzednim temacie wiedziałeś jak to zrobić, mianowicie bezpośrednio z rejestrów wysyłając dane.

Przesyłałem albo dane typu uint8_t, albo uint16_t (a nawet float), ale zawsze po użyciu funkcji printf() lub sprintf(), czyli de facto przesyłałem/zapisywałem je w formie znaków ASCII.

[Anonim]

Tak z ciekawości zapytam :w tym sprintf jest %02x .To dane mają być zapisane na dysku  w HEX? Nie lepiej zapisać %d będzie w Signed Integer  wszak odczytujesz Signed Integer .

I drugie pytanie o co chodzi w tej linii

unmount_sd();

Mógłbyś nam rozjaśnić.

[radek04]

Hex to maksymalnie 2 znaki z każdego rejestru. Int zajmuje więcej znaków. Rejestry odczytuję w uint8_t, czyli unsigned.

unmount_sd() to funkcja, której nazwa chyba jasno wskazuje, co robi: f_mount(NULL, "/", 1)