atom1477 pisze: ↑

14 gru 2022, 21:24

A poza tym to nie ma nic dziwnego w tym że kod napisany przez człowieka jest lepszy od tego z kompilatora.

No właśnie jest.
W większości przypadków kompilator z języka C zrobi lepszy assembler niż większość całkiem niezłych programistów.
Nie wiem czy jest sens paprać się w pisanie całych procedur w asm, bo pisząc je w C wyjdzie na to samo lub nawet lepiej.
Jedyny sens to jakaś krótka wstawka.
Używanie assemblera sprawia, że twój kod staje się "mało przenośny" a tak naprawdę nic nie zyskujesz.
Co zupełnie nie przeszkadza, aby wiedzieć co to jest i umieć go użyć.

atom1477 pisze: ↑

14 gru 2022, 17:28

Można było napisać w C albo i w C#, ale znów: mała wydajność.

Aż taki dobry jesteś, że napiszesz lepszy assembler niż zrobi to kompilator z języka C?

tuxcnc pisze: ↑

15 lis 2022, 20:59

KOD JEST DOBRY I NAPISANY ZGODNIE Z ZASADAMI !

To, że coś działa nie oznacza, że jest dobre.
Jak sobie tam w zaciszu piszesz, twoja sprawa.
Jak dla mnie to nawet nie musisz nazwy rejestru używać, możesz bezpośrednio pod adres pisać.
Ale jak wklejasz kod pokazując jak "świetnie" to wymyśliłeś i napisałeś to wklejaj kod z dobrymi wzorcami dla innych.
Bo jeszcze ktoś to przeczyta i pomyśli, że tak się powinno robić.
Jeśli tylko autor jest w stanie wydedukować co dany fragment robi (bo ma komentarz), to kod jest do bani. Poza tym dobry kod to taki, który nie potrzebuje komentarza.

tuxcnc pisze: ↑

15 lis 2022, 20:22

Następny poczuł się w obowiązku zakomunikować, że niczego nie rozumie, ale pogadać sobie musi....

Czego nie rozumiesz?
Kod który pokazałeś jest bardzo słaby i zwyczajnie tak się nie robi. I kto co z tego wie? Poza tym dlaczego wolisz pamiętać, że bit który chcesz sprawdzić to bit 4 zamiast pamiętać jego nazwę?
Jak zerkniesz za chwilę to programu to nie będziesz wiedział co tu sprawdzasz. Zaś trzeba wertować dokumentację, żeby odszukać co to jest 0x10.

A ja podzielam zdanie obu panów
Generalnie tendencję do tworzenia programistów oderwanych od sprzętu są. To nic złego, jeśli chodzi o programowanie w systemie. Natomiast jeśli chodzi o programowanie uC, to zazwyczaj jest to ściśle związane ze sprzętem (nie tylko uC) i moim zdaniem oderwać od sprzętu się tego nie da.
Kod tego typu co przedstawił tux jest rzeczywiście beznadziejny, ponieważ nie ma żadnego usprawiedliwienia aby wpisywać do rejestru (czy zmiennej) w taki sposób a tym bardziej, aby sprawdzać flagę w taki sposób.
Od tego są definicje poszczególnych bitów, zawierające ich nazwy. Odszukanie potem w dokumentacji, co było ustawione jest o wiele prostsze. A kompilator i tak to zamieni na to samo.

Co do przenośności kodu. Ja mam takie obserwacje, że przenośność kodu na uC to tylko takie chwytliwe hasełko, mające na celu zachęcić do używania bibliotek. Same biblioteki nie są złe, pod warunkiem, że nie zawierają błędów i używa się je świadomie. Ale tak naprawdę, uC używa się konkretnie pod dane zastosowanie, typowo związane z peryferiami które uC posiada i ze sprzętem towarzyszącym.
Ja z założenia od początku pisałem na rejestrach, ale nie tak radykalnie jak to przedstawił tux. Używam do tego definicji, które do tego zostały stworzone i powodują, że kod jest przejrzysty i czytelny (dla mnie dużo bardziej czytelny niż w przypadku używania bibliotek) i nigdy nie miałem problemów, żeby fragment kodu przenieść na inny uC (oczywiście w ramach rodziny).

Ale wracając do początku,
Jak kiedyś nie było gotowych środowisk do STM32 tak teraz mamy ich nadmiar, między innymi CUBE. Jest to dobrodziejstwo ale i przekleństwo, ponieważ tworzy z programisty klikacza. Zamiast zaglądnąć do manuala i ustawić kilka rejestrów, wyklikuje konfogurację i w gruncie rzeczy nie ma pojęcia jak i co ustawił. Następnie przechodzi do pisania programu traktując sprzęt jak abstrakcję. Wszystko fajnie, dopóki działa. Ale jak pojawiają się problemy, coś nie działa, pewne zależności to taki programista/kilkacz nie umie sobie z tym poradzić, przecież wyklikał wszystko dobrze.

Dlatego moim zdanie, tworzenie warstwy abstrakcyjnej-owszem ale na oprogramowaniu, gdzie program to w większości algorytmy oderwane od sprzętu. Natomiast jeśli tworzy się program który bezpośrednio steruje sprzętem, moim zdaniem im poziom niższy tym kontrola i przewidywalność większa.

Tu nie chodzi o to, żeby negować stwierdzenie, że we przyszłości rust będzie szeroko używany. Możliwe, że tak będzie.
Tu chodzi o to, że stwierdzenie:

upanie pisze: ↑

14 lis 2022, 16:45

Ja wiem, że embedded rust może nie do końca jest jeszcze "dorobiony" ale z C jest taki problem, że to język dinozaurów i pewnie z kilka lat już nikt po to nie sięgnie do nowych projektów.
Ale jeśli nie chodzi Ci o mikrokontrolery to w ogóle zapomnij o C.

jest nieprawdziwe, a przynajmniej w dużej części.
Ja też się tym zajmuje zawodowo, może nie tak długo jak ty bo 10 lat. A Hobbystycznie kilkanaście.
I nie widzę ani nie słyszę przesłanek, dla których C miałby za kilka lat zniknąć z powszechnego użytku w programowaniu niskopoziomowym uC.
Możliwe, że coś go wyprze. Możliwe, że to będzie rust. Ale to będzie długa droga, na pewno nie na kilka najbliższych lat.

upanie pisze: ↑

14 lis 2022, 17:32

W żadnym przypadku. Takie są fakty.

Co ty odpowiadasz.
C ma się świetnie w branży, szczególnie embedded. I nie zanosi się, żeby się to miało zmienić.