książka o programowniu AVR w C

J.F. <jfox snipped-for-privacy@poczta.onet.pl> napisał(a):

Pod 95 nie dało się więcej jak 49 dni bo się przekręcał licznik milisekund i wyskakiwał BSOD :)

Po co miałbym koloryzować? Pierwszy Windows95 PL, jeszcze nie OSRany, zainstalowany w czerwcu 1996 roku. Po dwóch tygodniach walki z aktualizacjami driverów zakończonymi powodzeniem był stabilny. Pracowałem na nim 8 lat - wytrzymał wiele zmian sprzętowych. Do przejścia na XP zmusił mnie brak aktualizacji innych programów dla Windows95 i brak obsługi USB a nie "techniczna śmierć" systemu jako takiego. Z Windows98 wytrzymałem 3 lata. Dopiero od 2007 roku przeszedłem na XP. Wcześniej był Windows 3.1 (nawet nie 3.11!) - "zmarł" z powodu całkowitego braku oprogramowania. Najstabilniejszy był DESQview z taskami DOSowymi, ale tu mało kto wie, co to w ogóle było... BTW: w opisie na Wiki jest błąd: piszą, że to multitasker tekstowy a pod DESQview dawało się uruchamiać Windows 3.0 w trybie standard. W okienku graficznym DESQview.

Dokładnie tak.

Miesiąc to mniej niż 49 dni...

RoMan Mandziejewicz snipped-for-privacy@pik-net.pl napisał(a):

Tak, dlatego napisałem to jako uzupełnienie-ciekawostkę a nie zaprzeczenie. Może trochę niezręcznie to ująłem.

A przy okazji widac ze niektorzy faktycznie uzywali miesiacami, skoro zauwazyli taki objaw ... i nie byl to MS :-)

J.

Dnia 01-02-2011 o 10:52:23 4CX250 <taunusmtv@poæta.3onet.pl> napisał(a):

IMHO ustawi po swojemu.

Ale to musisz zrobić wstawkę w asm. Nie wiem co zrobi gcc, nie ćwiczyłem tego.

Ale asm to nie kompilator tylko translator który zapis mnemoniczny przekłada na kod, kompilator C robi znacznie więcej.

Podobnie jak pisanie w asm znakomicie rozwija umiejętnośc tworzenia nastepnej implementacji fdiv która jak pierdyliard innych pisanych przez całe stada assemblerowców jest spieprzona.

Jakość kodu nie wynika z pisania wszystkiego po swojemu a już na pewno nie z pisania wszystkiego na nowo za każdym razem.

Zupełnie jak w C.

Oczywiście poza tym, że dzięki możliwości kompilacji kodu w C i testowania go w środowisku PC można zdobyc tą i mase innych ważnych informacji których nie sposób uzyskać mając do czynienia z kodem natywnym na uC. O takich drobnostkach jak unit testy nie wspominam, bo przecież assemblerowcy bez wątpienia mają jakieś własne, lepsze rozwiązania zagadnień jakości i testowania kodu produkcyjnego, prawda?

W każdym języku programowania można spotkać ignorantów, ludzi z doświadczeniem w Basicu/Delphi czy zwykłych idiotów. Co z tego?

W dniu 2011-01-31 13:25 Piotr Gałka napisał(a):

Nie, nie "patrzy". Blokuje przerwania na początku a na końcu odblokowuje (w tej postaci ATOMIC_FORCEON). Jest też bardziej pożyteczna wersja, która przywraca stan przerwań sprzed zablokowania - można takie kawałki bez stresu używać wtedy w przerwaniach.

Użytkownik "Adam Dybkowski" snipped-for-privacy@45wp.pl napisał w wiadomości news:iiab1p$7in$ snipped-for-privacy@news.onet.pl...

Wiem, że nic nie wiem, no i tego nie rozumiem. Przecież jeśli zablokuje przerwania to stan się w czasie gdy są zablokowane nie zmieni więc co tu przywracać. Czego nie chwytam ? P.G.

W dniu 2011-02-02 09:24, Piotr Gałka pisze:

Wychodzisz z błędnego założenia, że ten fragment kodu zaczyna się zawsze przy włączonych przerwaniach, więc po zakończeniu blokady możesz je znowu włączyć (zamiast przywrócić stan poprzedni).

Użytkownik "janusz_kk1" <janusz snipped-for-privacy@o2.pl napisał w wiadomości news:op.vp9s140z1cvm6g@jk-laptop...

Uśmieszków moich nie dostrzegłeś :) Chodziło mi tylko o to że gcc nie ma szans obliczyć głębokości stosu jeżeli będziemy zmieniali wartośc wskaźnika SP programowo. Tak ironizowałem tylko.

Marek

Użytkownik "J.F." <jfox snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news: snipped-for-privacy@4ax.com...

I tego nie da się nijak programowo załatwić choćby nie wiadomo jaki był uniwersalny ten gcc.

Wystarczy też małe potknięcie programisty np. włączenie fuse bitu kompatybilności 103 w atmega 128 i żaden gcc nie wykryje błędu. Okaże się że pamięć za krótka i stos mamy na zmiennych i dodatkowo nie ma fiuczerów które sa tylko w 128 a które chce nasz program wykorzystać.

Marek

Java i .Net jakby to obchodza.

Mozna sie upierac ze C powinien to sobie ustawiac sam :-)

J.

kompilator C zasadniczo w ogole nie ma szans obliczyc glebokosci stosu na etapie kompilacji, chyba zeby tak budowal drzewo zagniezdzen i sprawdzal rekurencyjnosc.

Moze sprawdzac na etapie wykonania, ale to strata na szybkosci i kolejny klopot.

Programista ma zadbac o wystarczajacy stos.

J.

Kompilator zna początek stosu i zna jego koniec, więc oczywiście, że się przystosuje do zmiany rejestru i nawet będzie działać kontrola głębokości stosu, jeżeli ją wkompilujemy. A do kontroli "za darmo" można użyć pułapki sprzętowej o ile procesor obsługuje.

Problem stopu jest nierozwiązywalny ;)

Użytkownik "J.F." <jfox snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news: snipped-for-privacy@4ax.com...

Nie znam gcc, uczę się dopiero. "Kompilator" kodu dla 8085 jaki napisałem dawno temu przelatywał przez listing asm 2 razy gdyż za jednym razem nie był w stanie sprawdzić wszystkich etykiet skoków i przypisać adresy do odpowiednich ich wywołań. Więc program podczas tłumaczenia zapisywał sobie kolejne wywoływane etykiety skoków na własnym coś jakby stosie i przy drugim przebiegu jeśli trzeba było uzupełniał brakujące adresy etykiet etykiet przy skokach. Ilość kolejnych odwołań do etykiet była więc ilością adresów odkładanych na stos gdyby jeszcze uwzględnić polecenia push i pop to można by było normalnie wyliczać głębokośc stosu ale nadal nie dałoby się zrobić tego jeżeli wskaźnik stosu zmieniany miałby być programowo.

O właśnie. Dlatego zawsze jak pisałem w ASM to sobie robiłem arkusz pod tytułem mapa pamięci który na bieżąco aktualizowałem.

Marek

Dnia 02-02-2011 o 12:09:49 4CX250 <taunusmtv@poæta.3onet.pl> napisał(a):

Ok :)

nie wiem czy nie podpadnę, ale zapytam: czy coś na temat książki się dowiem? w tym mega wątku...