On 30/04/2020 10:58, Grzegorz Niemirowski wrote:
> Nie uważam, żeby możliwość programowania bardziej wypasionego
> mikrokontrolera miała prowadzić do przerośniętego i bardziej
> zabugowanego kodu.

Bierzesz wypasonego ARMa który ma MMU. Na dzien dobry dostajesz w łeb
sporką komplikacją kodu wynikajacą z pamieci wirtualnej. Możesz jej nie
używać, oczywiscie, ale co jesli urządzenia I/O są mapowane przez jakieś
MMUIO? Nagle musisz napisać dużo cholerne skomplikowanego kodu tylko po
to aby to obsługiwać. Coś co dawniej robione jako PORTD |= FOO; dzisiaj
urasta do kilkuset linijek zabawy w dostęp przez MMU, najpewniej z bugami.

Idź teraz i wlacz z przetestowaniem tego invitro.

> Starszy, prostszy mikrokontroler ma różne
> ograniczenia, które utrudniają programowanie, mogą zwiększać ryzyko
> błędu i wydłużają czas tworzenia kodu.

To wszystko zależy ile kodu, boiler plate, niesie ze sobą architektura.
Im większy CPU tym trudniej pisać to co chcesz bez zajmowania się
pierdołami dookoła. W skrajnych przypadkach, jak mikorontrolery na x86,
trzeba było się zajmować całym tym debilizmem jak tryby real, protected,
long, short i h... wie co jeszcze, żeby w końcu po kilku tygodniach
zamigać diodą.

Rozumiesz że każda linijka kodu, kazdy if, każdy zapis do rejestru,
każda akcja globalna to jest nowa ścieżka testowania i generuje coraz
trudniejsze w audytowaniu środowisko?

Jak ktoś miga diodą to pal sześć. Jak to lata samolotem to NIE chcę
skomplikowanego cpu na którym się pisze łatwiej. Bo się cieżej
*testuje*. Dziwne, że wiele osób zapomina o tym, że kod krytyczny
podlega restrykcyjnemu testowaniu a popieprzone architektury nie
usprawniają tego procesu. Wręcz uniemożliwiają w skończonym czasie.