Kurs STM32L4 – #14 – czujnik odległości, wyświetlacz 7-seg.

[Kamro]

@Treker Przetestowałem i działają całkiem nieźle w ten sposób. Mam jeszcze pytanie jak można poprawić działanie tych czujników, gdy mają mierzyć odległość w małym kącie. Czy np użycie tulejek (cylindrów) ograniczy taki kąt? Buduję aktualnie prototyp kolejki na podstawie silnika liniowego i na szynie 2m, dosyć mocno wchodzą zakłócenia.

[Treker (Damian Szymański)]

@Kamro czujniki ultradźwiękowe mają z założenia dość szeroki kąt działania. Dodawanie jakiś tulejek będzie prowadziło do powstawania niechcianych odbić. Może do tego projektu konieczne będzie po prostu dobranie innego czujnika. Zachęcam do założenia osobnego tematu na forum - określ konkretne parametry swojego projektu to na pewno uda się coś ciekawego podpowiedzieć.

[bestsiwy]

cześć.

Mam pytanie dotyczące zapisu HAL_GPIO_WritePin(SEG_A_GPIO_Port, SEG_A_Pin, mask & 0x01) w funkcji static void set_output(mask).

Zgodnie z dokumentacją funkcja HAL_GPIO_WritePin przyjmuje GPIO_PIN_RESET oraz GPIO_PIN_SET. Skąd zatem wziął się stan wysoki na wyjściu przy zapisie mask & 0x01? 

Rozumiem nakładanie maski, interesuje mnie tylko skąd funkcja wie, że należy ustawić stan wysoki lub niski. Domyślam się, że gdy maska zwróci wartość 1 to funkcja rozumie to jako GPIO_PIN_SET, jeśli natomiast zwróci wartość 0, to jest to równoważne z GPIO_PIN_RESET.

Jeszcze prościej: 1 = GPIO_PIN_SET, 0 = GPIO_PIN_RESET.

Pójdę krok dalej. Gdy wywołuję funkcję np HAL_GPIO_WritePin(SEG_A_GPIO_Port, SEG_A_Pin, 1) to mam na wyjściu stan wysoki. Dlaczego więc w kursie używany GPIO_PIN_SET / RESET a nie zwyczajnie 0 / 1 ? 

[Treker (Damian Szymański)]

@bestsiwy witam na forum Twoje rozumowanie jest poprawne. 

Dnia 16.08.2024 o 14:14, bestsiwy napisał:

Dlaczego więc w kursie używany GPIO_PIN_SET / RESET a nie zwyczajnie 0 / 1 ? 

Korzystamy z tych wartości, ponieważ takie byłoby założenie autorów biblioteki HAL do tych układów, a chcemy działać zgodnie zaleceniami producenta i tym, co znajduje się w dokumentacji. Dla komputera (i mikrokontrolera) wychodzi na jedno, a dla człowieka jest to bardziej czytelne. Szczególnie, gdy zaczyna się korzystać z bardziej rozbudowanych peryferiów układu.

[aimeiz]

Nie wiem dlaczego tylko mnie się to przytrafiło. Przy kompilacji pierwszego kodu seg7 wyskakuje mi taki błąd:
../Core/Src/seg7.c:9:10: fatal error: gpio.h: No such file or directory

Chodzi o linię:

#include "gpio.h"

Pewnie tworzony przez MX plik zawierający takie definicje:
SEG_B_GPIO_Port
SEG_B_Pin

Ma w aktualnej wersji inną nazwę.

Czy przypadkiem w pliku main.c nie powinno się dodać #include "seg7.h"

Aktualizacja:

Zabrakło tego: "Zaznaczamy też w opcjach projektu, że CubeMX ma wygenerować osobne pliki dla wszystkich modułów."

Gdy ta opcja nie jest wybrana, wtedy te definicje są w main.c

Aktualizacja:

I kolejny problem.

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
	if (htim == &htim6) {
		seg7_update();
	} else if (htim == &htim2) {
		uint32_t start = HAL_TIM_ReadCapturedValue(&htim2, TIM_CHANNEL_1);
		uint32_t stop = HAL_TIM_ReadCapturedValue(&htim2, TIM_CHANNEL_2);
		seg7_show((stop - start) * calc_sound_speed() / 20000.0f);
//		seg7_show((stop - start) / 58);
	}
}


/* USER CODE END 0 */

Funkcja w wersji wywołującej calc_sound_speed() daje na wyświetlaczu jakieś przypadkowe wyniki. Wystarczy zablokować linię z calc_sound_speed() i odblokować tę poniżej i już jest dobrze, ale bez korekty temperaturowej. Próbowałem zmieniać priorytety przerwań i częstotliwość pomiarów, ale to nie pomaga. Odczyt i wydruk ADC w pętli while(), daje prawidłowe wyniki. Jak dotąd nie znalazłem przyczyny.

Aktualizacja:

Ta wersja działa już prawidłowo:

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
	if (htim == &htim6) {
		seg7_update();
	} else if (htim == &htim2) {
		uint32_t start = HAL_TIM_ReadCapturedValue(&htim2, TIM_CHANNEL_1);
		uint32_t stop = HAL_TIM_ReadCapturedValue(&htim2, TIM_CHANNEL_2);
		seg7_show((uint32_t)((stop - start) * calc_sound_speed() / 20000.0f));
	}
}

Pomogło rzutowanie zmiennoprzecinkowego wyniku wyliczeń na uint32_t.

[lpk]

Nie wiem, co jest grane, ale podpinając czujnik temperatury, zaczyna się on momentalnie przegrzewać, a potem wręcz dymić, więc muszę go od razu wyłączyć. filozofii z nim nie ma, 3 piny, 1 zasilanie, 1 masa i 1 pin do odczytu. sprawdziłem z datasheetem i tam piny się pokrywają z tym, co macie w kursie.

wpierw podpiąłem pod 5V z Nucleo, potem osobno do kozsyka baterii 6V, efekt ten sam. 

walnięty czujnik, czy jakiś błąd początkującego?

 

EDIT: podpiąłem zły czujnik z zestawu (DS18B20...)

 

EDIT2: ok, z drugim czujnikiem (LM35DZ) miałem to samo, dopóki nie obróciłem pinów. w datasheecie jak byk jest GND po prawej stronie, jeśli wybrzuszenie jest na dole. U Was na schemacie jest jednak na odwrót i jak zrobię na odwrót, to działa. Czego nie rozumiem tutaj?

 

EDIT3: już rozumiem, widok na schemacie jest od dołu ...
 

Edytowano 19 maja przez lpk