adamnar

Z artykułu dość jasno wynika, że delay_us nie jest dobrym podejściem i nie powinno być używane w większych projektach. Autorzy używają tego podejścia żeby zilustrować działanie protokołu 1-wire, co byłoby trudne używając rozwiązania docelowego, czyli UART. Wersja pro, czyli ta z UART, nie wymaga żadnego delay_us.

Witam. Rozwiązałem problem. Program funkcjonuje poprawnie po zmienieniu linijki led_buffer[RESET_LEN + 24 * LED_N] = 100; na led_buffer[RESET_LEN + 24 * LED_N] = 0; Ogólnie, wydaje mi się, że w tym odcinku kursu znajduje się poważny błąd. Zaprezentowany sposób komunikacji z linijką led jest niezgodny z notą katalogową. Zacznijmy od następującego zdania: Dlaczego? Po co potrzebne jest nam pełne wypełnienie? W nocie katalogowej nigdzie nie jest napisane że stan wysoki jest do czegokolwiek potrzebny. Następnie: Dlaczego RESET jest na początku? W nocie katalogowej nie ma nic o stanie przed rozpoczęciem transmisji. Reset ma zostać wysłany PO zakończeniu transmisji. Czyli zgodnie z notą katalogową transmisja wygląda tak: 1) przesyłamy dane, 24 bitów na każdą diodę, 2) ustalamy stan NISKI na przynajmniej 50 us, 3) możemy wysłać kolejną transmisję. Tak więc ani robienie RESET na początku ani ustalanie 100% PWM na koniec nie ma sensu. Ten błędny model komunikacji jest potem ciągnięty przez cały artykuł, w efekcie zarówno kod podstawowy (przed utworzeniem biblioteki) jak i kod już po optymalizacji nie działają poprawnie. Zasugerowana przeze mnie zmiana wypełnienia z 100 na 0 sprawia, że urządzenie zaczyna działać poprawnie (najprawdopodobniej dlatego, że diody odebrały w końcu prawidłowy sygnał RESET na koniec komunikacji), choć kod nadal konceptualnie jest niepoprawny.

Muszę przyznać, że totalnie zgłupiałem. Zrobiłem wszystko zgodnie z instrukcjami (kod kopiuj-wklej etc.). A diody zachowują się bardzo dziwnie. A konkretnie, linijka diod czasami zapomina o diodzie numer 0. Żeby znaleźć przyczynę tej usterki zmodyfikowałem kod funkcji main() (wszystko inne pozostawiłem tak samo). Teraz wygląda on tak: ws2812b_init(); HAL_Delay(1000); ws2812b_set_color(0, 32, 0, 0); ws2812b_set_color(1, 0, 32, 0); ws2812b_set_color(2, 0, 0, 32); while (1) { ws2812b_update(); HAL_Delay(250); Czyli spodziewane zachowanie to: wszystkie diody gasną na sekundę, potem zapalają się trzy pierwsze: czerwona, zielona i niebieska, a potem sytuacja ta się już nie zmienia. Niestety, zamiast tego diody dziwnie mrugają. Żeby ustalić czy to nie jest wina posiadanej przeze mnie linijki, podpiąłem równolegle drugą linijkę spodziewając że będzie się zachowywać jak pierwsza. Efekt jest taki, że druga linijka ma podobny problem, ale mrugnięcia są zupełnie losowe i nie są zsynchronizowane z pierwszą linijką. Wygląda to tak: Na wideo resetuję układ. Jak widać ws2812b_init() nie wyłącza diody 0, ale gaśnie ona przy którymś kolejnym wywołaniu ws2812b_update(), potem zapala się na czerwono i już się nie zmienia. Niestety nie mam oscyloskopu, żeby sprawdzić dokładnie jak wygląda sygnał. Czy ktoś wie z czego może wynikać takie zachowanie?

Robiąc ten rozdział od razu przyszło mi do głowy, że przydałoby się, gdyby można było wysyłać dowolne wiadomości, a nie tylko te predefiniowane w send_next_message - chociażby wiadomości o tym, ile razy został wciśnięty przycisk. W tym celu napisałem funkcję send_message, która wpycha tekst do bufora, a bufor jest sukcesywnie opróżniany przez HAL_UART_Transmit_IT. Wyszło mi coś takiego: char buffer[1024]; char tmp[1024]; uint8_t busy = 0; void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { if (huart==&huart2) { busy = 0; if (strlen(buffer)>0) { busy = 1; strcpy(tmp,buffer); buffer[0] = '\0'; HAL_UART_Transmit_IT(&huart2, (uint8_t*)tmp, strlen(tmp)); } } } void send_message(char * message) { if (strlen(buffer)+strlen(message)>1023) return; strcat(buffer,message); if (!busy) HAL_UART_TxCpltCallback(&huart2); } Ogólnie działa wyśmienicie. Można sekwencyjnie wywołać send_message wielokrotnie z dowolnymi tekstami i wszystko się wysyła; podczas testów nie zauważyłem żadnego problemu. Niemniej, jako że jestem zupełnie zielony jeśli chodzi o programowanie asynchroniczne (nie wiem jak używać volatile itp.; btw. jestem też zielony jeśli chodzi o operacje na stringach w C i ogólnie C bez dwóch plusów), będę wdzięczny za krytyczne uwagi, bo na pewno coś skopsałem. Dodatkowo, dorobiłem jeszcze funkcję echo tak, żeby tekst wpisywany do terminala od razu się wyświetlał. Wygląda to tak: char rxb[2]; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart==&huart2) { send_message(rxb); if (rxb[0]=='\r') send_message("\n"); HAL_UART_Receive_IT(&huart2,rxb,1); } } Też działa jak złoto. Nawet można skopiować i wkleić do terminala kawałek tekstu i zostanie on w całości odebrany i wyświetlony. Oczywiście trzeba to zainicjować wrzucając HAL_UART_Receive_IT(&huart2,rxb,1); przed pętlą główną (o czym jak widziałem w poście powyżej nie tylko mnie udało się na początku zapomnieć). Jak wyżej, krytyczne uwagi mile widziane.

Ok, problem solved. Winowajca znajdował się w pliku stm32l4xx_hal_conf.h i wyglądał tak: #define TICK_INT_PRIORITY 15U /*!< tick interrupt priority */ Z jakiegoś powodu u mnie domyślnie (we wszystkich projektach) priorytet przerwania SysTick jest ustawiony na 15. Zmiana na 0 rozwiązuje problem.

Witam. Mam kłopot z priorytetami. Mimo nadaniu niższego priorytetu, program cały czas zawiesza się po wciśnięciu przycisku (tymczasowo dla pętli i permanentnie dla HAL_Delay). Oto moje przerwanie: void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin == UB_Pin) { counter++; //HAL_Delay(100); for (int i=0;i<10000000;i++) {} } } W kodzie funkcji MX_GPIO_Init widzę takie linijki: HAL_NVIC_SetPriority(EXTI15_10_IRQn, 8, 0); HAL_NVIC_EnableIRQ(EXTI15_10_IRQn); Więc domyślam się, że konfiguracja jest prawidłowa. Czy jest jeszcze coś co powinienem sprawdzić? Jak ewentualnie zdebugować taki problem?

Poczytaj kilka postów wyżej, jest rozwiązanie.

Fajny kurs, ale jednej rzeczy bardzo mi brakowało: motywacji. Chodzi o to, że po przerobieniu całego kursu nadal nie wiem do czego może mi się to przydać i jakie ogólnie ma to zastosowania. W kursie nie było ani jednego przykładu konkretnego zastosowania. Dla porównania, w kursie STM32L4 już na samym początku jest sugestia, że tego typu rozwiązania mogą być używane w terminalach płatniczych, dekoderach TV, urządzeniach medycznych itp. Samemu też łatwo wpaść na to, że można ich użyć np. do budowy robotów jako bardziej wypasiony zamiennik Arduino. A do czego można użyć FPGA? Odpowiedź na to pytanie nadal jest dla mnie zagadką. Z pobieżnej lektury artykułów na Wikipedii dowiedziałem się, że Microsoft użył tego do swojej wyszukiwarki Bing i że jakaś firma użyła FPGA zamiast robienia własnych układów na zamówienie, bo miała mały nakład i tak wychodziło taniej. Nie brzmi to zachęcająco. W dodatku, w kursie nie ma wzmianki o parametrach układu. Domyślam się, że jego zaletą nie jest to, że można z niego zrobić przerośniętą i drogą bramkę logiczną OR, tylko że może w nim takich bramek równolegle funkcjonować… no właśnie, ile? Przy mikrokontrolerach znamy pojemność pamięci i taktownie zegara, więc wiemy na co mogą sobie pozwolić. A jak liczy się wydajność FPGA? Co maksymalnie da się z tych układów wycisnąć? Tego też w kursie nie było. Nie mam więc pojęcia co w praktyce da się z tym urządzeniem zrobić. Kurs pozostawił we mnie wrażenie, że to do czego ten układ jest zdolny, to bycie bramką logiczną, prostym automatem skończonym itp. Czyli tym, co zrobiliśmy w ćwiczeniach. Wszystkie te zastosowania może ilustrują funkcjonowanie i pozwalają uczyć się języka, ale z praktycznego punktu widzenia są nudne i zupełnie nie uzasadniają zastosowania FPGA w porównaniu z innymi, prostszymi rozwiązaniami. W efekcie, mam wrażenie, że w tym kursie zdobyłem wiedzę, która do niczego mi się nie przyda. PS. Łezka w oku mi się kręci, gdy patrzę na wyjście VGA, wyświetlacze-segmentowe oraz niezliczone piny płytki, wszystkie pominięte w kursie. Czuję mocne FOMO.

Ok, udało mi się wyjść z tej sytuacji. Po prostu zrobiłem wszystko od nowa i tym razem zadziałało. Nawet zrobiłem własny eksperyment z bramką xor5 i też zadziałał. Automatyczne drzwi też zadziałały. Coś musiałem skopsać za pierwszym razem.

Wydaje mi się, że nie mogę podpisać odczepów. Odczepy nie są automatycznie podpisywane jak na animacji. Natomiast gdy ja próbuję je podpisać manualnie, to nic się nie dzieje. Klikam na różne sposoby w różnych miejscach i nic się nie dzieje. Na rysunku powyżej podpisałem "wire" pomiędzy odczepem a bramką NOT a nie sam odczep. Jak zatem podpisać odczepy?

Witam. Mam kłopot z bramką or4. Dostaję następujące komunikaty o błędzie: ERROR:Xst:2585 - Port <I0> of instance <XLXI_1> does not exist in definition <or4>. Please compare the definition of block <or4> to its component declaration to detect the mismatch. ERROR:Xst:2585 - Port <I1> of instance <XLXI_1> does not exist in definition <or4>. Please compare the definition of block <or4> to its component declaration to detect the mismatch. ERROR:Xst:2585 - Port <I2> of instance <XLXI_1> does not exist in definition <or4>. Please compare the definition of block <or4> to its component declaration to detect the mismatch. ERROR:Xst:2585 - Port <I3> of instance <XLXI_1> does not exist in definition <or4>. Please compare the definition of block <or4> to its component declaration to detect the mismatch. ERROR:Xst:2585 - Port <O> of instance <XLXI_1> does not exist in definition <or4>. Please compare the definition of block <or4> to its component declaration to detect the mismatch. Obrazek załączam. Muszę przyznać, że miałem kłopot z wymyśleniem co zrobić by podłączyć elementy do siebie, bo instrukcje w kursie są dość skąpe i cały czas dostawałem jakieś komunikaty o błędzie. W końcu się udało, ale, jak widać, nie działa.

Mnie też coś takiego od razu przyszło do głowy. Wywaliłem else ze wszystkich czterech warunków i wyszło mi, że wszystko działa ok. Tak więc podbijam pytanie: czy to else w ogóle czemuś służy?

Faktycznie zadziałało - odpalając szybciej a potem zwalniając byłem w stanie zejść do 20 PWM mimo że wystartować z 20 PWM nigdy mi się nie udało. Dzięki!

Dzięki. Mam jeszcze takie pytanie: gdy zapodaję pwm < 40 na oba silniki, to koła nie kręcą się tylko cicho piszczą. Czy jest to zachowanie normalne, tzn. czy oznacza to, że nie da się jechać powoli i istnieje jakaś minimalna prędkość z którą można jechać?

Witam. Nadal jest problem ze śrubkami 6mm. Są za krótkie, albo podwozie ze sklejki jest za grube.