W dniu poniedziałek, 13 stycznia 2020 19:30:20 UTC+1 użytkownik Maciej Sobczak
napisał:
> > Podobnie jak to, żeby na mikrokontrolery dostarczać "warstwę abstrakcji
sprzętowej" (?).
>
> To nie jest zły pomysł (ale można go oczywiście źle zrealizować). Jeśli jest cała
rodzina mikrokontrolerów, które np. mają Ethernet, to nie jest złym pomysłem, żeby
ten Ethernet był obsługiwany z grubsza przez takie samo API.
> To znakomicie ułatwia producentowi wciśnięcie odbiorcom nowego mikrokontrolera a
tempo tego wciskania jest coraz szybsze. Przecież bez takiego HALa nikt by nigdy nie
kupił nowego układu.

No, ale w moim odczuciu lepszym pomysłem byłoby po prostu dbanie o zgodność
niskopoziomowego interfejsu pomiędzy kolejnymi urządzeniami kontrolera.
(A jeżeli miałoby to być niemożliwe, to zastanowienie się, dlaczego ma to być
niemożliwe)

> Pytanie 1: co ma dłuższy czas życia? Software czy hardware?
> Pytanie 2: jak na poprzednią odpowiedź wpływa rozróżnienie pomiędzy PC i embedy?
>
> > Tzn. ja bym się raczej spodziewał po opisie takiego narzędzia, że dostanę wysoce
zoptymalizowany kod inicjalizujący,
>
> A po co zoptymalizowany? To się wykonuje tylko raz.
> Być może chciałbyś mieć błyskawicznie startujący układ, ale oczekiwanie na fizyczny
rozruch peryferiów i tak trwa dłużej, niż wykonanie nawet najbardziej szmacianego
kodu inicjalizującego.

Zoptymalizowany pod dwoma kątami:
- rozmiaru, jaki zajmuje w pamięci stałej
- kolejności inicjalizacji, ze względu na czas inicjalizacji peryferiów (bo producent
wie to lepiej ode mnie)

> > Bo jest kod wygenerowany, który nie ja pisałem, i w którym wprowadzanie zmian
jest bolesne (bo muszę regenerować projekt)
>
> Teoretycznie nie musi być bolesne, bo są mechanizmy pozwalające rozgraniczyć kod
generowany od modyfikowanego.

Jest bolesne.
Fajny pomysł mają goście z Krakowa, język Luna
https://www.luna-lang.org
opiera się o "dualną reprezentację graficzno tekstową". Można sobie przełączać. To
jest lepsze od generowania, bo mamy izomorfizm. Czyli można np. używać tradycyjnych
narzędzi diffujących (o czym sam kiedyś wspominałeś).

W CubeMX nie można (albo ja nie wiem jak). A ich pomysł na rozwój aplikacji (że dają
mi szablony, i ja wciskam swój kod pomiędzy ich komentarze) jest po prostu koszmarny.

> Oczywiście to nadal nie usprawiedliwia wypychania języka C na tron. Ale tak się
właśnie dzieje.

Nie wiem jaki inny język mieliby wcisnąć.