-
Data: 2013-10-11 00:11:51
Temat: Re: PICowanie
Od: Sylwester Łazar <i...@a...pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]> pamiętać. Podejście typu "muszę mieć wszystko pod kontrolą" niczym się
> nie różni od pisania w asm i świadczy o ubogim warsztacie.
Tu bym się nie zgodził.
Spotkamy się tu za 20 lat i ubogim warsztatem okaże się Twój C++.
Zresztą niektórzy twierdzą, że już tak jest.
Warsztat to chyba nie jest dobre słowo na metody pracy.
Wydaje mi się, że mieszasz. Uznajesz, że wybór języka programowania
wpływa na warsztat.
Na to jest już szereg innych określeń: inteligencja, umiejętność myślenia
przestrzennego,
dobra realizacja zadań. I moim zdaniem nie ma to kompletnie nic wspólnego
z rodzajem języka, którego używasz.
Choć, przyznaję, nauka kolejnego może rozwijać "warsztat".
Zupełnie tak samo, jak nauka budowy kolejnego ukontrolera.
A ja właśnie piszę w ASM tak gdzieś od 28 lat mniej więcej.
Mój warsztat jest bardzo "ubogi":
1) kod jest napisany zwięźle i czytelnie.
2) czysty kod rzadko przekracza kilka kB. Jeśli już, to są to szybkie
tablice LUT.
3) każda linijka ma swój komentarz.
4) nigdy nie analizuje kodu w ASM. Nie używam klawiszy Page Up/Down w tym
celu.
5) strukturę logiczną kodu mam zawartą w przestrzeni 2 wymiarowej w postaci
algorytmu
lub innych form zapisu, takich jak tabela stanów, opis struktur danych itp.
6) samo kodowanie sprowadza się do zamiany bloków logicznych na mnemoniki
konkretnego mikrokontrolera 8,16,32 bitowego
7) kodowanie jest czynnością przyjemną choć dość prymitywną.
8) najprzyjemniejsze jest uruchamianie. IDE mnie interesuje tylko w celu
postawienia Breakpointa i odczytanie stanu procesora.
9) cała analiza opiera się na oglądaniu kolorowych algorytmów.
10) przy moim toku pracy nie interesuje mnie na jaki typ procesora piszę.
Może być to MICROCHIP, Freescale, 8051core, MIPS - cokolwiek.
W szczególności nie interesuje mnie nawet język programowania.
Mógłby to być C++ czy C bez różnicy.
Tylko tak się składa, że asm sprawdza się najlepiej.
I teraz. Twój przykład mnie po prostu zastrzelił.
Nie pamiętam kiedy używałem w ogóle całkowitego blokowania przerwań.
(twoje cli())
Ja je najczęściej tylko włączam na początku kodu po włączeniu zasilania.
Cała reszta oparta jest na logicznym przemyśleniu sposobu wykorzystania
sprzętu.
Ważna jest komunikacja POP (ISR) i programu głównego.
Czasem ważne są priorytety przerwań.
W związku z powyższym proponuję zmienić przykład, gdyż usiłuje on udowodnić,
że:
1) wyższość jednego sposobu komunikacji (tutaj niby C++) nad drugim
(C )polega na tym, że wygodniej jest wyłączać przerwania, co jest po prostu
dość śmieszne.
Poniekąd wskazał to też kolega, który twierdzi, jeśli dobrze zrozumiałem,
że woli sobie sam decydować, gdzie włączyć, a gdzie wyłaczyć przerwania.
A okazuje się, że nikt się nie zastanawia: W jakim celu w ogóle je wyłączać?
Mogła by paść odpowiedź: bo mój kod nie zdąży, gdyż jest obiektowy :-)
2) Twoja argumentacja:
"W C musisz uzyć zmiennej tymczasowej. W C++ nie, kod jest
znacznie czytelniejszy"
Czy ja wiem?
Toż przecież - spójrz w swój kod po kompilacji.
Jestem ciekaw, jak niby to Twój destruktor przekazuje UART_D, czyli fizyczny
rejestr,
bez pośrednictwa nawet rejestru?
3) Jeden z tu obecnych kolegów, powiedział mi przed laty, że on pisze w C, a
potem podgląda skompilowany kod i poprawia idiotyzmy kompilatora.
Ja uważam, że ta metoda jest dobra. Sam próbowałem, ale...
Czas leci do przodu, a kompilatory operują już na wysokiej klasie
abstrakcji.
Po skompilowaniu powstają tak niebosiężne bzdury, że poprawianie zajmowałoby
mi mnóstwo czasu, więc jest to dla mnie zbyt kosztowne.
No bo jak poprawiać kod asm wygenerowany przez kompilator,
który odczytuje timer w przerwaniu i zachowuje na stosie 20 rejestrów
procesora,
wykonuje jedno podstawienie i przywraca te rejestry.
Niestety zwiększając częstotliwość przerwań, okazuje się, że szybki procesor
spędza swój żywot na zapisywaniu stosu w tą i z powrotem, tracąc głupio
swoją moc obliczeniową
oraz potencjalną gotowość do błyskawicznej reakcji na inne zmienne
środowiskowe.
--
-- .
pozdrawiam
Sylwester Łazar
http://www.alpro.pl Systemy elektroniczne.
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB.
Następne wpisy z tego wątku
- 11.10.13 00:19 Sebastian Biały
- 11.10.13 00:53 Sebastian Biały
- 11.10.13 07:53 Marek
- 11.10.13 08:43 Zbych
- 11.10.13 08:56 Marek
- 11.10.13 09:51 RoMan Mandziejewicz
- 11.10.13 10:18 Marek
- 11.10.13 11:00 RoMan Mandziejewicz
- 11.10.13 11:59 Sylwester Łazar
- 11.10.13 12:53 Marek
- 11.10.13 13:13 Sylwester Łazar
- 11.10.13 13:21 Michał Lankosz
- 11.10.13 14:11 J.F
- 11.10.13 14:49 Sylwester Łazar
- 11.10.13 15:05 Michał Lankosz
Najnowsze wątki z tej grupy
- Dziwne zachowanie magistrali adresowej w 8085
- Współczesne mierniki zniekształceń nieliniowych THD audio, produkują jakieś?
- Jaki silikon lub może klej?
- Smar do video
- Litowe baterie AA Li/FeS2 a alkaliczne
- "ogrodowa linia napowietrzna"
- jaki zasilacz laboratoryjny
- jaki zasilacz laboratoryjny
- Puszka w ziemię
- T-1000 was here
- Ściąganie hasła frezem
- Koszyk okrągły, walec 3x AA, na duże paluszki R6
- Brak bolca ochronnego ładowarki oznacza pożar
- AMS spalony szybkim zasilaczem USB
- stalowe bezpieczniki
Najnowsze wątki
- 2025-02-12 Warszawa => Expert Recruiter 360 <=
- 2025-02-12 Ostrów Wielkopolski => Area Sales Manager OZE <=
- 2025-02-12 Bieruń => Regionalny Kierownik Sprzedaży (OZE) <=
- 2025-02-12 Dęblin => Node.js / Fullstack Developer <=
- 2025-02-12 Kraków => PHP Full Stack Developer <=
- 2025-02-12 Karta dźwiękowa stereo
- 2025-02-12 Dęblin => JavaScript / Node / Fullstack Developer <=
- 2025-02-12 Gdańsk => Specjalista ds. Sprzedaży <=
- 2025-02-12 Łódź => NodeJS Developer <=
- 2025-02-12 Błonie => Sales Specialist <=
- 2025-02-12 Dziwne zachowanie magistrali adresowej w 8085
- 2025-02-11 Mini pecet
- 2025-02-10 Spalił się spaliniak
- 2025-02-10 zarowka wifi - z sensowna apka lub lepiej albo lokalnie lub przez web. I zeby harmonogram miala
- 2025-02-10 Chrzanów => Programista NodeJS <=