Elvis

Największym problemem HAL nie jest uint8_t jako taki, ale brak const przy wysyłaniu. Natomiast w C lepszym rozwiązaniem byłoby użycie void* nawet jeśli to nieco archaiczne - ale oszczędziłoby używania konwersji tam gdzie nie jest to konieczne. Tym bardziej że wysyłane dane nie zawsze są w 8-bitowych bajtach. Natomiast czy trzeba zmieniać język programowania to bym polemizował. Wystarczy nauczyć się używać tego co się ma.

Trzy dni to krótko, wręcz standardowy czas na znalezienie błędu Oczywiście nie zawsze można pomijać czy zmienna jest ze znakiem, czy bez - chodziło mi o ten konkretny przypadek i napisy w 7-bitowym ASCII. A wyjaśniając - właśnie dlatego wprowadzono typy w rodzaju int8_t, uint8_t i podobne, żeby uniknąć różnic wynikających z wersji, czy parametrów kompilatora. Stare typy w C mają niestety taką cechę, że mogą mieć różną reprezentację w zależności od środowiska - przykładowo int może mieć 16, albo 32 bity, char może być ze znakiem lub bez itd.

uint8_t to najzwyklejszy, w dodatku 8-bitowy bajt. W języku C odpowiada dokładnie unsigned char. Zarówno signed char i unsigned char zajmują 8-bitów, różnica polega na interpretacji najwyższego bitu, czyli liczby ze znakiem lub bez. Sam typ char niestety nie wiadomo czy jest signed, czy unsigned - ale ew. pomyłka nie jest krytyczna. Kompilator ostrzega że typ jest inny, ale nic złego się nie dzieje. Biblioteka HAL jest delikatnie mówiąc przeciętna, używanie uint8_t jako typu bufora jest marnym pomysłem, ale ST potrafi produkować dobre mikorokontrolery, z programowaniem u nich gorzej. Nie pozostaje więc nic innego jak rzutować typ wskaźnika (rzutowany jest typ wskaźnika, nie same dane). Odbieranie po jednym bajcie jest oczywiście mało wydajne, ale nie jest błędem. Tym co było najgorsze w programie to brak miejsca na znak końca napisu, czyli '\0' - trzeba o tym pamiętać, że w języku C napisy są przechowywane z zerem na końcu. Czyli żeby zapisać łańcuch o długości 4 znaków potrzebna jest tablica o długości 5.

Naucz się chłopie czym się różni CubeMX od Cube - bo z cubemx raczej ciężko coś wycinać. To tylko aplikacja napisana w javie, jak Arduino IDE.

Chyba pomyliło ci się Cube z CubeMX. Można używać Cube HAL nie dotykając CubeMX. Inna sprawa że TCP bazuje na lwIP, więc nie ma potrzeby nawet HAL dotykać. A co do USB to w przypadku device czemu nie zrobić samemu, to wcale nie takie trudne.

Potwierdzam pierwszą część, ale nie zgadzam się że jest nieodzowny Nawet z zegarami lepiej sobie poradzić bez niego, chociaż może być pomocny jako kalkulator - o ile akurat działa. A przy okazji polecam przeczytać komentarz na początku wygenerowanego przez CubeMX kodu... Prawa autorskie do pliku z funkcją main ma ST.

Czyli jednak piszesz głupoty, bo nie masz nic innego do roboty. W sumie to przykre.

Skoro piszesz tylko banalne programiki sterujące diodami to nic dziwnego, że asember nie jest ci potrzebny. Ale skąd masz dane że 98% osób na tym forum nie używa debuggera to chyba napiszesz, bo przecież nie wymyśliłeś tych danych i głupot nie piszesz, prawda?

Ja tylko wspomnę, że ARM to nie tylko Cortex-M więc to co zostało wcześniej napisane nie jest prawdą - w przypadku Cortex-M ogólnie się zgadza, ale już na Cortex-A nie. Natomiast znajomość asemblera bardzo się przydaje, chociażby podczas debugowania. Poza tym w Cortex-A jest potrzebna przy obsłudze przerwań, ale nawet na Cortex-M kod wykonywany przed wejściem do main jest napisany w asemblerze. Natomiast poleganie na tym co ST dostarcza nie zawsze wystarcza.

To zmień księgowość i przestań wypisywać bzdury na forach internetowych.

Jeśli wózek inwalidzki jest sprzętem medycznym to pisanie kodu od zera może nie być przejawem megalomanii, ale koniecznością. No chyba że biblioteki Arduino spełniają wymgania PN-EN 62304, w co akurat wątpię.

Jak chodzi o moduły SOM, to ogólnie jest tak jak napisał kolega @msalamon, ich zastosowanie to głównie profesjonalne, komercyjne projekty. Nie znaczy to oczywiście, że w projekcie amatorskim na takie moduły nie ma miejsca - mogą się przydać chociażby do nauki, w końcu kiedyś możemy chcieć nie tylko bawić się w programowanie, ale może i coś na tym zarabiać. W każdym razie podejście nie powinno być takie - mam moduł i myślę do czego go mogę zastosować. Lepiej jest podejść odwrotnie - mam do rozwiązania pewien problem, przykładowo muszę zaprojektować urządzenie, które będzie zapewniało określoną funkcjonalność. Dopiero wtedy można zastanawiać się jak taki problem rozwiązać. I tutaj jest wiele możliwości, a wybór rozwiązania zależy od mnóstwa czynników. Jeśli mikrokontroler jest wystarczający, to często jest najlepszym wyborem. Są jednak problemy, przy których mikrokontrolery nie dają sobie rady - i tutaj znowu jest wiele możliwości: można zaprojektować własną płytkę, użyć gotowego komputera przemysłowego, taniego SBC, albo modułu SOM. Nie ma jednej odpowiedzi które rozwiązanie jest najlepsze (bo gdyby było, już dawno pozostałe by zniknęły z rynku).

@Faramir Można też po prostu przestać pisać, w końcu każdy ma prawo zmienić zdanie i może konto jeszcze się przyda. A to że forum nie jest dla każdego... coś w tym jest. Ja tylko zacytuję powiedzenie "Jeśli jedna osoba mówi ci że jesteś osłem to ją zignoruj, jeśli dwie osoby mówią ci ze jesteś osłem to je zignoruj. Jednak jeśli pięć osób mówi ci że jesteś osłem to idź i kup sobie siodło..." - tak do przemyślenia

masz na tej samej stronie, wystarczy kliknąć. A jak nie to poszukaj po autorze.

Ale to jest wersja ethanaka, inne już niekoniecznie