🚀 go-pugleaf

On 2020-03-08 22:03, heby wrote:
> On 08/03/2020 21:29, JDX wrote:
>>> Co to za argument że architektura jest "znana"? Od 40 lat
>>> większość software jest pisana w językach wysokiego poziomu.
>>> Jakim cudem argument "znamy '51" ma jakikolwiek związek z
>>> podejmowaniem decyzji współcześnie?
>> Bo zdarzają się jeszcze nieźle sprzedające się produkty na 51,
>> które zostały zaprojektowane w czasach, gdy ten rdzeń nie był
>> jeszcze przestarzały.
> 
> Czyli jakie unikatowe cechy rdzenia '51 lub peryferiów nie występują
> w ByleCzym?
No banki rejestrów i wydzielony stos raczej nie występują we
współczesnym byle czym. :-D

> Nie, to już nie jest utrzymywanie. To prosta droga do katastrofy.
Dlaczego zaraz katastrofy? Firma ma nowy produkt na nowym, zupełnie
innym MCU, ale stary produkt na 51 też (się) sprzedaje.

> Problemem nie jest pieniądź.
Ooo, na podstawie mojego doświadczenia jako klepacza kodu w tzw.
biznesie myślę, że problemem jest przede wszystkim pieniądz. Trudno mi
sobie wyobrazić użycie 51 w nowym projekcie, ale kto wie, może jakaś
firma chciałaby lekko zmodyfikować sprzęt i zrobić 51 w ASICu (+ jakiś
dodatkowy stuff) i wykorzystać istniejące oprogramowanie. Właśnie w celu
zaoszczędzenia, najprawdopodobniej krótkoterminowego.

> Od 40 lat słyszę jakie to szerokie i głębokie zalety posiada '51, ale
> jakoś bez detalicznego enumerowania tychże. O kasie nikt nie
> wspomina. Tam bez wątpienia jest jakiś inny powód, po tych wszystkich
> rozmowach dochodzę do wniosu że jest tylko jeden: religia.
Na pewno ode mnie czegoś takiego nie słyszałeś. Od dawna uważam, że 51
to padlina. Tak z 15+ lat temu na p.m.e lobbowałem za MCU na ARM. To
były czasy, gdy rodzina LPC2000 Philipsa na ARM7TDMI wchodziła pod
strzechy. Chociaż tak BTW to większy sentyment mam do H8/300H i H8S –
fajne ortogonalne CISCi.

> I potem się dziwie że na C++ w embedded przeciętny Pan Zdzisław od
> 40 lat robiący sterowiki zegarów szkolnych reaguje alergicznie. Skoro
> się nie da użyć w "najszybszym procesorze świata" to najlepiej nie
> używać wcale i nigdzie.
Na ja np. chciałbym użyć, ale nie tylko gołego C++, ale też kontenerów z
STL-a. Ale jak ich użyć, skoro nie wiem jak działają, albo może i wiem,
ale mi się to nie podoba – chodzi mi o alokację i realokację pamięci na
stercie. Rust pod tym względem jest fajny, bo specjalnie z myślą o
rzeźbiących w embedded dostarcza dwie wersje kontenerów – z pamięcią
alokowaną dynamicznie na stercie i z pamięcią alokowaną statycznie.
Oczywiście ze względu na te alokacje są pewne niuanse w ich użyciu, ale
można z tym żyć. No i wtedy jest fajnie – piszesz sobie kernel czy
drajwer bez martwienia się o alokacje, tak jakbyś pisał coś na desktopa.
A w C++ nie wiadomo jak to łatwo zrobić. Tzn. ja nie wiem. W każdym
razie jeśli już mamy być postępowi, to nie C++ tylko Rust. :-)