Elvis

Długa dyskusja się wywiązała, więc pozwólcie że napiszę kilka słów. Po pierwsze warto zrozumieć czym różni się wartość od wskaźnika - wartość to np. Bajt (uint8_t), int, albo cała struktura. Typ zmiennej określa ile pamięci jest potrzebne do jej przechowywania oraz jak wykonywać operacje na niej. Różne typy mogą zajmować różną ilość pamięci, więc np. Przypisując wartoś zmiennej 32-bitowej do zmiennej 8-bitowej możemy część danych stracić, bo po prostu się nie zmieszczą. Natomiast wskaźnik jest tylko adresem w pamięci, w stm32l4 to zawsze 32-bitowa liczba, a więc każdy typ wskaźnikowy w pamięci

DMA na M7 to trochę trudniejszy temat. Brak przerwania wskazuje na inny błąd, ale i tak musisz pamiętać że te układy mają pamięć cache, więc odpowiednia konfiguracja MPU może okazać się niezbędna do użycia Cube.

@Leroy Ciężko jest pomóc jeśli nie napiszesz, co nie działa jak powinno. Opis "Niestety program nie działa jak należy" jest nieco zbyt ogólny. Ale przyglądając się Twojemu programowi, wydaje mi się, że jeden z błędów może być tutaj: // Pobieram konfigurację I/O do sprawdzenia uint8_t config = mcp_reg_read(MCP_IODIR); if (check_bit(config, output_num) == 0){ uint8_t reg_val = mcp_reg_read(MCP_GPIO); return check_bit(reg_val, output_num); } else{ return -1; } O ile rozumiem, chciałeś odczytywać rejestr MCP_GPIO tylko wówczas, gdy pin działa jako wejście. W przypad

Dziękuję za miłe słowa, przygotowanie tego kursu wymagało mnóstwa pracy od całego zespołu, tym milej jest słyszeć, albo raczej czytać, że praca nie poszła na marne Natomiast co do przerwań i funkcji HAL_UART_Transmit_IT to chyba zaszło pewne nieporozumienie. Ta funkcja nie wysyła wszystkich danych natychmiast. Zamiast tego wstawia do rejestrów modułu UART pierwszy fragment danych i kończy działanie. Przerwanie zostanie wywołane gdy moduł UART wyśle dane i będzie oczekiwał na kolejne. W międzyczasie program główny będzie dalej wykonywany, więc dane będą przesyłane niejako w tle. Program

Super projekt, fajnie zobaczyć że nawet bez mikrokontrolera można sterować diodami WS2812 Chociaż nie jestem pewien, czy to łatwiejsze rozwiązanie. No i chyba pierwszy raz widzę użycie tablic Karnaugh w praktyce... na studiach katowano tą metodą bez opamiętania, ale jak widać czasem może się jednak do czegoś przydać.

Przed chwilą kurier dostarczył moją statuetkę, pozwólcie więc że również bardzo podziękuję za przemiłą niespodziankę Statuetka na żywo wygląda o wiele lepiej niż na zdjęciu, wyrazy uznania za pomysł i jakość wykonania projektu. A przy okazji, czy gdzieś na forum dostępny jest może opis i schematem tego układu? Przyznam, że jestem bardzo ciekaw jak sterowania diodami RGB bez użycia mikrokontrolera.

@Gieneq Jeśli masz włączoną akcelerację GPU w colab to warto czasem uruchomić polecenie !nvidia-smi Wyświetla ono informacje o używanym sprzęcie, przykładowo: Teraz wystarczy wpisać w google "Tesla T4" i zobaczyć ile taka zabawka kosztuje. Ten akcelerator jest akurat dość tani, jakieś 12 tys. zł... Ale można trafić na maszynki za kilka razy więcej - i wszystko za darmo A przy okazji, cena tych akceleratorów pewnie jest jakoś powiązana z czasami działania, inaczej nikt by w nie tyle pieniędzy nie inwestował.

@Leroy Nie ja dobierałem wartości rezystorów, ale domyślam się, że większa wartość w przypadku diody niebieskiej wynikała z jej jaśniejszego świecenia. Jasność świecenia diody zależy od płynącego przez nią prądu i masz oczywiście rację, że dioda niebieska będzie miała najwyższy spadek napięcia, a przez to popłynie przez nią najmniejszy prąd. Jednak diody o różnych kolorach mogą się bardzo różnić jasnością, nawet jeśli płynie przez nie prąd o takim samym natężeniu. Prawdopodobnie niebieska dioda świeciła jaśniej od pozostałych, pomimo że pobierała mniej prądu. Więc dostała rezystor w wyższej wa

@APJ Masz oczywiście rację, że procesor czekając na zapalenie lub zgaszenie diody marnuje czas. Warto jednak zawsze dobierać rozwiązanie do problemu, a nie odwrotnie. Jeśli piszemy program, który ma tylko migać diodą, to aktywne czekanie nie jest niczym złym. Przecież i tak w tym czasie nic lepszego procesor nie ma do roboty. W części dotyczącej oszczędzania energii pokazujemy jak można usypiać procesor podczas oczekiwania - ale warto powtórzyć: zawsze dobieramy rozwiązanie do potrzeb. Jeśli chcemy mieć niski pobór energii, odpowiednio projektujemy układ i piszemy program. Jeśli poza miganiem

Podczas obsługi przerwania blokowane jest przyjmowanie kolejnych o priorytecie niżym lub równym aktualnemu. Więc nic się złego nie stanie, jeśli kolejne zostanie zgłoszone podczas wykonywania procedury obsługi poprzedniego.

Nie jestem pewien, czy alokowanie pamięci na stercie to dobry pomysł. Jest jednak duża różnica między pierwszymi programami, gdzie tablica była alokowana na stosie, a ostatnią wersją - może to ładnie w wygląda w C++, ale działać może o wiele gorzej.

@padus Dodanie biblioteki math.h było w przykładzie potrzebne, aby użyć funkcji exp() i nie miało nic wspólnego z wcześniejszym zdaniem Rdzeń Cortex-M4 posiada wsparcie sprzętowe dla operacji na liczbach zmiennopozycyjnych pojedynczej precyzji, czyli po prostu dla typu float. Proste operacje jak np. dodawanie, odejmowanie, mnożenie i dzielenie liczb tego typu są wykonywane sprzętowo, a dzięki temu o wiele szybciej niż w przypadku czysto programowej realizacji obliczeń. Aby skorzystać ze wsparcia koprocesora arytmetycznego nie trzeba robić nic poza użyciem typu float - domyślne ustawieni

@Frantick Najprościej jest użyć wsprintf.

@Emerid Moduł RTC działa nawet w trybie standby i nie musisz aktualnego czasu zapisywać w pamięci SRAM2 - tym bardziej, że wówczas czas spędzony w uśpieniu nie byłby liczony, więc sam "zegarek" pewnie zbyt dokładny by nie był. Problem wynika chyba z nieporozumienia. Na początku programu wywołujesz funkcję HAL_RTC_GetState, która zwraca stan HAL_RTC_STATE_RESET co oznacza, że moduł RTC nie został jeszcze zainicjalizowany. Musisz więc najpierw wywołać HAL_RTC_Init, albo raczej MX_RTC_Init. Warto popatrzeć jak wygląda kod HAL_RTC_GetState: HAL_RTCStateTypeDef HAL_RTC_GetState(RTC_Ha

W tej części chcieliśmy pokazać jak można za pomocą naszego mikrokontrolera komunikować się z czujnikami podłączanymi za pomocą interfejsu 1-wire, ale okazało się, że przy okazji musieliśmy sporo miejsca poświęcić na opisanie działania samego czujnika DS18B20. Nie jest to kurs obsługi tych czujników i wiele funkcji musieliśmy pominąć, ale o jednej warto byłoby wspomnieć. Pokazaliśmy jak można odczytywać temperaturę z jednego czujnika nawet bez znajomości jego kodu (adresu) - wystarczy wysłać polecenie SKIP_ROM (0xCC) i jeśli tylko jeden czujnik jest podłączony, możemy z nim "rozmawiać". W