Wpis z mikrobloga

Mirki od #mikrokontrolery oraz #programowanie
Powiedzmy ze chciałbym od zera zbudować portfel krypto - coś jak ledger ale w dużo uboższej formie i nieco inną funkcjonalnością.

Z tego co się zdążyłem zorientować ledger wykorzystuje STM32…i tu się zaczynaja schody…

Jaki język C++ czy może python? A może coś innego?
Jak podejść ogólnie do sprawy - w żołnierskich słowach poproszę :)

Umiem w C# i naokoło…jeśli to istotne.
  • 17
@masaj: ofc są interpretery pythona na stm32 ale wydajność i kompletność tego to inna sprawa

Jeżeli nie miałeś NIC do czynienia z mikrokontrolerami, to na początek kurs forbota, a potem książka Carmine Noviello Mastering STM32
@masaj: Embedded to bardzo szeroki temat - od tanich, 8-bitowych MCU prosto z Chiń jak Padauk to wielordzeniowych SoC. Jeśli masz dużo mocy obliczeniowej, a nawet system operacyjny to możesz sobie pozwolić na C++ lub Pythona.
Tylko, że w przypadku STM32 to naprawdę średnio ma sens. Widziałem jakieś próby zabawy z C++, ale zwykle to były niezbyt sensowne pet projects. Istnieje coś takiego tiny Python, ale nigdy nie widziałem tego w
@groman43: Zawsze zastanawiało mnie skąd w embedded to zamiłowanie do C. C++ nie ma większych wymagań sprzętowych od C, wydajność miewa lepszą, a szybkość pisania też lepsza.
C++ nie ma większych wymagań sprzętowych od C


@Krolik: przecież runtime C++ ma bodajże kilka kb overheadu. Na MCU jest to już realnie odczuwalne, szczególnie na mniejszych.

Myślę, że po prostu w embedded nie ma żadnych większych korzyści z używania C++, a C jest prostszy i mniejszy.
@zwei: Runtime C++ jest zależny mocno od opcji kompilacji. Odpowiednimi opcjami można go zredukować do poziomu takiego jak w C. Przede wszystkim wyłączyć RTTI i wyjątki.
@Krolik: O panie, ale pan puszkę pandory teraz otworzył! Przyczyn jest co najmniej kilka.
1. Legacy - mnóstwo projektów zostało napisane w C i przepisanie wszystkiego na C++ teraz nie ma sensu.
2. W C++ kompilator może wygenerować dużo kodu - konstruktory, destruktory, operatory przypisania, etc. Jeśli pracujesz nad systemami, które mają ograniczone zasoby (pamięć, objętość kodu, cache, czas wykonania), to nie skończy się dobrze.
3. Jeśli nie wymyślono nic mądrzejszego
via Wykop Mobilny (Android)
  • 1
@Krolik: jak wyłączysz wyjątki, rtti i cały ten badziew to zostaje ci c z klasami xd klasy to tylko sugar syntax, a w c spokojnie można pisać obiektowo, więc sensowność użycia cpp staje się wątpliwa
@masaj zawsze powtarzam, że embedded to miejsce, gdzie spotykają się wymogi funkcjonalne z niefunkcjonalnymi (low cost, czas życia na baterii, systemy czasu rzeczywistego). I to właśnie wymogi niefunkcjonalne robią z embedded coś naprawdę interesującego, coś innego niż kolejny CRUD czy aplikacja mobilna.
Tylko że Ty, ponieważ pracujesz tylko nad swoim pet project, nie masz prawie w ogóle wymogów niefunkcjonalnych ( ͡° ʖ̯ ͡°)
@groman43: każdy CRUD czy aplikacja mobilna ma wymagania odnośnie latency i wydajności. I w tych obu kategoriach można zawrzeć wszystko. Miliardy różnych platform, baz danych, usług w chmurze, brokerów, mikroserwisy, zarządzanie złożonością systemu. Do tego biblioteki, języki programowania, algorytmy, architektura kodu, dzikie optymalizacje. Śmiem twierdzić, że wyzwań w CRUDzie jest więcej niż w embedded
Śmiem twierdzić, że wyzwań w CRUDzie jest więcej niż w embedded


@Saly: meh, jako ktoś kto pracował w embedded, a teraz robi crudy webowe, to powiem, że wyzwań jest mniej więcej tyle samo tylko że różnej natury
@groman43:
1. Pełna zgoda
2. Przecież w C ten kod też musiałby być wygenerowany, tylko zapene musiałbyś go po prostu napisać jawnie; a jeśli nie potrzebujesz, to nie definiuj konstruktorów, destruktorów, operatorów przypisania w C++. Jak ich nie zdefiniujesz, to się nic dodatkowego nie wygeneruje.
3. W C++ przecież masz polimorfizm na template'ach, optymalizowany statycznie. To w C polimorfizm robisz wskaźnikami do funkcji, a to generuje cache missy. Dlatego uniwersalna funkcja