Czy RISC-V (5) "wygryzie" ARM?

Zacznij wspierać ten kanał, a dostaniesz te bonusy:
/ @er-mik
Darmowa książka "praktyczny kurs programowania STM32 w wykorzystaniem HAL iLL" dostępna na:
er-mik.prv.pl/ksiazka_Programowanie_STM32/Kurs_programowania_STM32.pdf
Przedpłata na pełną wersję po wpłacie 50zł : suppi.pl/ermik
w polu do korespondencji proszę napisać "Książka Kurs STM32" i swój adres e-mail.
Jeśli chcesz jednorazowo przyczynić się do rozwoju kanału "postaw mi kawę" korzystając z linku:
suppi.pl/ermik

[@tapy5696]

To jest trudny temat. Porównując przykładowe podobne produkty jak STM32V103C8 vs CH32V103 to różnice w peryferiach są niewielkie, w RISC-V brakuje interface CAN, ale za to ma USB host/device, a jego wyższy zegar trudno porównać bo to są jednak różne architektury. Różnice jednak pojawiają się w cenie, która jest trzykrotnie niższa w przypadku RISC-V i nie jest tu mowa o niewielkich groszowych oszczędnościach. Oczywiście za STM przemawia znany europejski producent, 10 letni czas życia produktu, a o chińskich producentach nic nie wiemy. Nie sądzę, by osoba która zna biegle produkty STM ARM miała jakąkolwiek trudność w użyciu przedstawionego RISC-V. W mikrokontrolerach wykorzystane jądro nie ma znaczenia, a tylko jego wewnętrzna budowa i użyte peryferia. Z poziomu języka C nie ma znaczenia dla jakiego CPU wyprodukuje on kod wynikowy, ważne jest jak konfigurowane są wewnętrzne szyny, domena zegara i peryferia, a w przedstawionym przykładzie są one praktycznie identyczne (myślę, że można się nawet pokusić o wykorzystanie CubeMX do zbudowania szkieletu programu dla RISC-V w którym należałoby zmienić tylko pliki nagłówkowe - to jest do sprawdzenia).

[@eR-MIK]

@tapy5696 To sprawdź bo mam płytkę z RISC-V.

[@dawidkonieczny8713]

Żeby RISC-V wygryzło ARM to ktoś musi skonstruować mikrokontroler na RISC-V bardziej opłacalny niż te na ARM i zapewnić do niego dobrą platformę na wzór CubeIDE oraz dobre wsparcie tak aby programiści mogli szybko (czyli tanio a to dla firm jest najważniejsze) przeskoczyć na RISC-V. Bez tego jak w filmie nie ma po co iść w RISC-V bo nie oferuje niczego co sprawiałoby że z punktu widzenia całego projektu opłaca się iść w RISC-V.

[@eR-MIK]

@dawidkonieczny8713 Zgadzam się w całej rozciągłości.

[@rawel2]

RP2350 ARM Cortex M33 + RISC-V Hazard3 w Pico 2 ma oba rdzenie ;-) do wyboru

[@eR-MIK]

@rawel2 A IDE?

[@rawel2]

@@eR-MIK Do zabawy to Arduino i microPython, a do roboty to c /c++ i tutaj VS code, CLion (płatne) i eclipse, ostatnie 3 z debugowaniem

[@--MK--]

Wystarczy przeprosić się z Arduino i na RISC-V można programować bez problemu.

[@eR-MIK]

Srajduino nie wykorzysta 5% możliwości RISC-V ta jak nie wykorzystuje możliwości ARM.

[@sebek6543210]

@@eR-MIK Prawda jest taka, że gdyby ktoś wypuścił tańszy od atmeg i arm procesor na RISC-V i dobrze go zareklamował wspierając go nawet na tym znienawidzonym przez ciebie arduino, to mógłby coś zawojować. Nikt nie będzie przerzucał się na nowe środowisko jeśli nie skusi go cena bądź wsparcie dla danego produktu

[@eR-MIK]

@@sebek6543210 Mój wybór STM32 a nie Xmega był spowodowany CubeMX i kompilatorem ARm-GCC.

[@--MK--]

@@eR-MIK Dla RISC-V jest taki sam GCC jak dla ARM. Natomiast czy CubeMX można nazywać zaletą to już dyskusyjna sprawa. Ostatnio chyba sam zaczynasz do tego dochodzić klnąc w filmach nad wadami HAL-a...

[@eR-MIK]

@@--MK-- O wadach HAl wiem od początków mojej przygody z STM 32. Jak mam wybór w 3 dni napisać soft na HAL i dzień poświęcić na łatki na rejestrach (teraz na LL) albo miesiąc pisać soft na rejerstrach to wybór jest oczywisty. O przenośności kodu pomiędzy rodzinami układów nie będę pisał bo to chyba "oczywista oczywistość".
O błędach w HAL mówię aby niektórym spadły klapki z oczów a inni wiedzieli jak sobie radzić z problemami. Dla "Srajduino" ni9e ma takiej opcji tam wszystko jest najgorsze dlatego nie pojazuje jak rozwiązać problemy. Ściślej pokazałemn ale alternatywa to tylko rejestry dla 99% arduinowców magia.