Następny poczuł się w obowiązku zakomunikować, że niczego nie rozumie, ale pogadać sobie musi....drzasiek90 pisze: ↑15 lis 2022, 19:51Kod 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.
Programowanie w C
-
tuxcnc
- Lider FORUM (min. 2000)
- Posty w temacie: 12
- Posty: 9323
- Rejestracja: 26 lut 2011, 23:24
- Lokalizacja: mazowieckie
Re: Programowanie w C
-
drzasiek90
- Lider FORUM (min. 2000)
- Posty w temacie: 7
- Posty: 2329
- Rejestracja: 25 kwie 2016, 11:58
- Lokalizacja: Jodlowa
- Kontakt:
Re: Programowanie w C
Czego nie rozumiesz?
Kod który pokazałeś jest bardzo słaby i zwyczajnie tak się nie robi.
Kod: Zaznacz cały
if (TIM2->CR1 & 0x10)
Jak zerkniesz za chwilę to programu to nie będziesz wiedział co tu sprawdzasz. Zaś trzeba wertować dokumentację, żeby odszukać co to jest 0x10.
-
tuxcnc
- Lider FORUM (min. 2000)
- Posty w temacie: 12
- Posty: 9323
- Rejestracja: 26 lut 2011, 23:24
- Lokalizacja: mazowieckie
Re: Programowanie w C
Ja na prawdę nie mogę uwierzyć, z kim tutaj rozmawiam...drzasiek90 pisze: ↑15 lis 2022, 20:44Zaś trzeba wertować dokumentację, żeby odszukać co to jest 0x10.
Wkleiłem kilka linijek wyciętych z programu, gówno wiecie co w tym programie jest, a mądrzycie się jeden przez drugiego...
A jest tam tak:
Kod: Zaznacz cały
// (TIMx->CR1 & 0x10) is direction bitKOD JEST DOBRY I NAPISANY ZGODNIE Z ZASADAMI !
<rejest/zmienna>&<maska> jest prawidłowym sposobem testowania bitów.
Jeśli nie potraficie zrozumieć, to zapamiętajcie.
Więcej na ten temat dyskutować nie będę.
EOT
-
grg12
- ELITA FORUM (min. 1000)
- Posty w temacie: 8
- Posty: 1743
- Rejestracja: 03 sty 2007, 14:27
- Lokalizacja: Wiedeń
Re: Programowanie w C
W niektórych sytuacjach jest to konieczne - ale taki kod warto schować w odzielnym pliku albo przynajmniej wydzielonych funkcjach opisanych jako dedykowane do konkretnego sprzętu.tuxcnc pisze: ↑15 lis 2022, 19:27
Ogólnie to ten kod miał być tylko przykładem, że nie tylko warto znać budowę procesora na który się pisze kod, ale nawet czasem jest to konieczne.
Tutaj (STM32) jest na przykład taka heca, że procesor jest 32-bitowy, ale licznik tylko 16-bitowy. Skąd ktoś traktujący procesor jako "czarną skrzynkę" ma wiedzieć jakiego typu zmiennych użyć?
Oczywiście ktoś piszący program na peceta nie musi wiedzieć co to jest tablica deskryptorów, ale jakieś ogólne pojęcie o budowie procesora mieć trzeba, choćby żeby wiedzieć dlaczego bardzo podobny kod wykonuje się dziesięć razy wolniej...
Ale czasami poleganie na konkretnej architekturze może się bardzo zemścić. Parę lat temu miałem "przyjemność" pracować przy portowaniu na ARM kodu napisanego pod Motorolę 68k. Autorzy orginalnego kodu (ze wstydem przyznam że jestem jednym z nich) uprościli sobie życie wykorzystując fakt że Motorola 68k jest "big endian" i podczas interpretacji danych z portu szeregowego albo eeproma może odczytać wartości 32bit wprost z binarnego bufora, bez żadnych dodatkowych deklaracji. ARM (tak jak x86) jest "little endian" i czytał głownie brednie...
Z drugiej strony - libpng (http://www.libpng.org/pub/png/libpng.html ). Można ją bez problemu skompilować pod windows i linuxem x86. Można ją skompilować pod Motorolę 68k. W razie potrzeby można zdefiniować własny alokator pamięci (przydaje się przy systemach "bare metal", nie posiadających malloc/free) - po prostu coś pięknego
Albo FatFs (http://elm-chan.org/fsw/ff/00index_e.html) - implementacja FAT16,FAT32 i extFAT - chodzi praktycznie na wszystkiem. W konfiguracji można wyłączyć wszystko co niepotrzebne (np. zostawiać sobie "read only" FAT16, albo ReadWrite ze stałą datą modyfikacji pliku jeśli nie mamy RTC) i zredukować wilkość kodu do minimum. Jest nawet wersja działająca na mikorkontrolerach z ilością ramu mniejszą niż wielkość sektora na karcie SD... po prostu coś pięknego
nigdy nie pracowałem na stm32 ale kolega z biura tak i parę rzeczy obiło mi się o uszy...
https://micromouseonline.com/2013/01/13 ... -approach/
-
drzasiek90
- Lider FORUM (min. 2000)
- Posty w temacie: 7
- Posty: 2329
- Rejestracja: 25 kwie 2016, 11:58
- Lokalizacja: Jodlowa
- Kontakt:
Re: Programowanie w C
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.
-
Olivier_XX
- Nowy użytkownik, używaj wyszukiwarki
- Posty w temacie: 2
- Posty: 2
- Rejestracja: 29 sie 2021, 20:24
Re: Programowanie w C
tomcat65 pisze:Żeby zasiąść do Atnela, trzeba już trochę język znać.
Kurs jest od podstaw.
upanie pisze:..... 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.
To fakt... C nie jest dla pismaków.
-
atom1477
- Lider FORUM (min. 2000)
- Posty w temacie: 3
- Posty: 3775
- Rejestracja: 21 kwie 2011, 10:58
- Lokalizacja: ::
Re: Programowanie w C
Dorzucę do pieca.
Pisze się nawet w assemblerze. I to nie z kaprysu. Ale po prostu się pisze.
Sam miałem okazję pisać kody biblioteki DSP do procesora z architekturą AArch64.
Jakieś były dostępne, ale bez tych funkcji jakie potrzebowaliśmy. Albo jak już były, to nie używały wszystkich możliwości procesora (NEONa).
Można było oczywiście nie pisać tylko użyć gotowej ... którą ktoś też napisał w assemblerze (ale z wadami jak wyżej: mała wydajność).
Można było napisać w C albo i w C#, ale znów: mała wydajność.
Można też napisać lepszy kompilator który nawet dla kodu w C# da wydajny kod.
No ale jak napisać kompilator? : Trzeba znać assembler (samego kompilatora się nie pisze w assemblerze, ale trzeba znać assembler żeby wiedzieć jakie rozkazy ma ten kompilator ma wstawiać do kodu wynikowego).
Wszystko to można negować, albo mówić że to są zaawansowane rzeczy dla wąskiej grupy specjalistów.
No ale mam pytanie: Skąd za 20 lat weźmiemy tą wąską grupę specjalistów, jak dzisiaj ci specjaliści (będący jeszcze początkującymi) nie będą pisać w assemblerze albo w innych językach niskiego poziomu?
Pisze się nawet w assemblerze. I to nie z kaprysu. Ale po prostu się pisze.
Sam miałem okazję pisać kody biblioteki DSP do procesora z architekturą AArch64.
Jakieś były dostępne, ale bez tych funkcji jakie potrzebowaliśmy. Albo jak już były, to nie używały wszystkich możliwości procesora (NEONa).
Można było oczywiście nie pisać tylko użyć gotowej ... którą ktoś też napisał w assemblerze (ale z wadami jak wyżej: mała wydajność).
Można było napisać w C albo i w C#, ale znów: mała wydajność.
Można też napisać lepszy kompilator który nawet dla kodu w C# da wydajny kod.
No ale jak napisać kompilator? : Trzeba znać assembler (samego kompilatora się nie pisze w assemblerze, ale trzeba znać assembler żeby wiedzieć jakie rozkazy ma ten kompilator ma wstawiać do kodu wynikowego).
Wszystko to można negować, albo mówić że to są zaawansowane rzeczy dla wąskiej grupy specjalistów.
No ale mam pytanie: Skąd za 20 lat weźmiemy tą wąską grupę specjalistów, jak dzisiaj ci specjaliści (będący jeszcze początkującymi) nie będą pisać w assemblerze albo w innych językach niskiego poziomu?
-
drzasiek90
- Lider FORUM (min. 2000)
- Posty w temacie: 7
- Posty: 2329
- Rejestracja: 25 kwie 2016, 11:58
- Lokalizacja: Jodlowa
- Kontakt:
-
grg12
- ELITA FORUM (min. 1000)
- Posty w temacie: 8
- Posty: 1743
- Rejestracja: 03 sty 2007, 14:27
- Lokalizacja: Wiedeń
Re: Programowanie w C
Kod pisany "ręcznie" nie musi być lepszy - czasem po prostu trzeba napisać kilka linii w asm żeby użyć bardzo konkretnej funkcji procesora w bardzo konkretny sposób. Przykład z mojego podwórka, funkcja wymuszająca przeładowanie cache kodu w procesorze- dokumentacja wymaga żeby po zapisie w rejestrze następna instrukcją był NOP - albo piszesz dwie linie w asemblerze, albo kod w C i się modlisz żeby kompilator czegoś nie "zoptymalizował".
