[STM32][F303][Nucleo][I2C] próba uruchomienia czujnika VL53L0X

Witam
posiadam czujnik VL53L0X, który pomyślnie uruchomiłem na arduino. Chciał bym zacząć przygodę z STM32, więc zakupiłem płytke NUCLEO-F303RE (STM32F303). Korzystam z biblioteki HAL oraz CubeMX, potrafię już sterować stanami na pinach, korzystać z przerwań, posiadam również skonfigurowane I2C. Problem zaczyna się z pobraniem odczytów z czujnika, brak tutaj uniwersalnej biblioteki jak na Arduino, przykłady na stronie producenta przygotowane są pod inna rodzinę, próbowałem zmienić pliki nagłówkowe na te wygenerowane dla mojej płytki, ale generowało to sporo błędów. Dokumentacja jest na tyle rozbudowana, że nie wiem co jest wymagane, co nie koniecznie. Jest ktoś w stanie pomoc mi uruchomić ten czujnik? Na sam start jedyne czego oczekuje to odczytanie odległości, bez zmian adresów, przerwań itd.

Z góry dziękuje i pozdrawiam

W ST znajdziesz oprogramowanie do obsługi tego układu z jakimś Nucleo.

@kornel388 To może pokaż co masz teraz oraz z jakim konkretnie problemem się mierzysz. Czy może chciałbyś aby ktoś za Ciebie zrobił ten projekt. Jeżeli tak to powinieneś pisać w innym dziale.

grko napisał:

@kornel388 To może pokaż co masz teraz oraz z jakim konkretnie problemem się mierzysz. Czy może chciałbyś aby ktoś za Ciebie zrobił ten projekt. Jeżeli tak to powinieneś pisać w innym dziale.

Praktycznie nie mam nic bo nie działa, ale powiem co zrobiłem tzn próbowałem zrobić. Ze strony ST pobrałem przykładowy projekt CubeMX dla płytki Nucleo F4, wygenerowałem kod, otworzyłem go w IDE, następnie stworzyłem nowy projekt teraz pod moja płytke Nucleo F303, skonfigurowałem I2C tak jak tam tzn 400Mhz. Skopiowałem pliki (sterowniki?)wygenerowane dla mojej płytki do projektu ze strony ST, zmieniłem też includy na te właściwe dla mojej płytki, ale to nie zadziałało, pełno błędów.

kornel388 napisał:

Skopiowałem pliki wygenerowane dla mojej płytki do projektu ze strony ST, zmieniłem też includy na te właściwe dla mojej płytki, ale to nie zadziałało, pełno błędów.

Ok. W takim razie jest mi bardzo przykro, że nie działa i jest pełno błędów. Udaj się do jasnowidza bo tutaj ciężko o ludzi, którzy są w stanie przewidzieć jakie to błędy masz podczas budowania projektu.

kornel388 napisał:

płytke NUCLEO-F303RE (STM32F303)

Najszybciej chyba, moim zdaniem, było by wejść w ten czujnik przy pomocy MBED. Twoja płytka jest obsługiwana pod MBED , jest tam biblioteka do VL53L0X (firmowa od STM, w C++) i są przykładowe aplikacje, w tym proste demka.
Np:
https://developer.mbed.org/teams/ST/code/HelloWorld_53L0A1/

Jeśli masz tylko czujnik (a nie tą płytkę z STM na którą te dema są robione), to trzeba podejrzeć tylko jak ten centralny czujnik jest podłączony i połączyć tak samo, na te same piny i z tym samym adresem I2C, albo zmienić w programie.

A później zaimportować sobie aplikację do swojego środowiska i jeśli nie chcesz korzystać z mbed w innych sprawach, to dolepić np. to co już masz zrobione pod HAL, bo w MBED z HAL można korzystać. Narzut pamięci na samą bibliotekę mbed, w Twoim przypadku jest nieistotny bo masz duży flash.

rb401 napisał:

kornel388 napisał:

płytke NUCLEO-F303RE (STM32F303)

Najszybciej chyba, moim zdaniem, było by wejść w ten czujnik przy pomocy MBED. Twoja płytka jest obsługiwana pod MBED , jest tam biblioteka do VL53L0X (firmowa od STM, w C++) i są przykładowe aplikacje, w tym proste demka.
Np:
https://developer.mbed.org/teams/ST/code/HelloWorld_53L0A1/

Jeśli masz tylko czujnik (a nie tą płytkę z STM na którą te dema są robione), to trzeba podejrzeć tylko jak ten centralny czujnik jest podłączony i połączyć tak samo, na te same piny i z tym samym adresem I2C, albo zmienić w programie.

A później zaimportować sobie aplikację do swojego środowiska i jeśli nie chcesz korzystać z mbed w innych sprawach, to dolepić np. to co już masz zrobione pod HAL, bo w MBED z HAL można korzystać. Narzut pamięci na samą bibliotekę mbed, w Twoim przypadku jest nieistotny bo masz duży flash.

Okej dzięki udało mi się uruchomić ten czujnik, mbed wydaje się być całkiem okej domyślam się, że nie jest tak wydajny jak biblioteka HAL, spróbuje wykonać swój projekt korzystajac z samego mbed

kornel388 napisał:

mbed wydaje się być całkiem okej domyślam się, że nie jest tak wydajny jak biblioteka HAL

Z pewnością nie jest, bo w mbed górna, widoczna warstwa API (obiektowa) wywołuje drugą, też całkowicie wirtualną warstwę HAL (nie mylić z STM HAL) (nieobiektową), której implementacja jest wielowariantowa, dla każdego z mikrokontrolerów osobna. A ta implementacja z kolei, dotyka już sprzętu.
W przypadku mikrokontrolerów STM, implementacja tej warstwy, już konkretnie do danego typu STM, korzysta intensywnie z STM HAL (ostatnio też trochę z LL), plus sporadyczne wpisy prosto do rejestrów.

Tak że można w programie MBED odwoływać się prosto do HAL (STM), LL i rejestrów, jak zresztą pokazuje wiele przykładów na mbed.
Np. zamiast użyć obiektu DigitalOut, można równie dobrze użyć HAL_GPIO_WritePin lub prosto pisać do rejestrów GPIO, będzie z pewnością szybciej (o ile to ma znaczenie). Tyle że taki program nie będzie przenośny na mikrokontrolery producentów innych niż STM.

Z drugiej strony, wydajność tych wszystkich ARMów na dziś, jest na tyle spora (poza szczególnymi wymaganiami), myślę że ten spadek wydajności MBED z uwagi na te warstwy pośrednie, jest akceptowalny (tym bardziej że MBED API wnosi wygodę i prostotę użytkowania, porównywalną, a może nawet sporo lepszą z, przepraszam za wyrażenie, Arduino ).

W moim odczuciu bardziej dotkliwym problemem MBED, jest nie jest tyle wydajność ale to że ciągle w nim intensywnie grzebią i przerabiają, powodując nieraz błędy w obszarach, które wcześniej działały jakoś tam poprawnie. Oczywiście błędy poprawiają, ale robią nowe i tak w koło Wojtek.

Tak że moja sugestia jest taka, by jakieś ważniejsze projekty, obojętnie w jaki sposób korzysta się z mbed, dla pewności importować kompletnie (biblioteka mbed-dev zamiast mbed itd.) w wersji do jakiegoś IDE, które się ma i niech sobie leżą na dysku.