książka o programowniu AVR w C

A może zainteresuj się książkami o ANSI C. AVR GCC idzie w tym kierunku. Do tego datasheet'y i mnóstwo przykładów w sieci.

chyba żarty sobie stroisz... nie ma nic gorszego niż "stosowanie" przykładów... marzy mi się książka opisująca całą teorię programowania avr w c... nie mówię o if then else, ale stosowaniu rejestrów, przerwań itp... coś jak ten dokument pdf z winavr, ale ten dokument też "odpiepszony" na maksa...

żaden syfiasty przykład nie jest dla mnie zbyt wartościowy - o to pytałem w pierwszym poście...

Od tego są ksiązki do C *ogólnie*.

Od tego są ksiązki o uC żeby właśnie przykłady z hardware były.

A co?

Ogolnie jakość książek o uC w PL jest taka sobie. Zazwyczaj to coś w rodzaju szybkiego kursu obsługi komputera, podstaw języka, i zaczyna brakować miejsca na sedno sprawy czyli hardware. Przykłady też nie zawsze wyższych lotów, często z błedami implementacyjnymi, wydziera się zła (najczęsciej żadna) szkoła programowania, wstrętem/fobią do C++, odkrywaniem koła na nowo i pieprzeniem głupot o lepszości makr nad kontrolą typów.

Dlatego za każdym razem biorę głeboki oddech i traktuje ksiązke jako małą encyklopedię z ładnym opisem rejestrów, a przynajmniej wygodniejszą niż pdf. Nic jednak nie zastąpi praktyki programowania ogolnego, a na pewno nie zastąpi go paru autorów różnych książek do uC którzy reprezentują szkoły programowania z lat 70tych.

Czytaj z dystansem a będzie dobrze.

W dniu 2011-01-26 21:32, identifikator: 20040501 pisze:

Proponuję w następującej kolejności. Słownik ortograficzny. Język ANSI C Kernighan Brian, Ritchie Dennis M Przykłady z sieci.

Może ty nie jesteś wystarczająco wartościowy jako wannabe AVR developer. Zastanów się nad innym hobby bądź zawodem.

Może ty nie jesteś wystarczająco wartościowy jako wannabe AVR developer. Zastanów się nad innym hobby bądź zawodem.

może i tak, a wracając do książki - co ona zawiera może mi Ktoś powiedzieć? czy 3/4 zawartości to listing programu do obsługi LCD?

Użytkownik "identifikator: 20040501" snipped-for-privacy@go2.pl napisał w wiadomości news:ihrlfk$7q1$ snipped-for-privacy@mx1.internetia.pl...

A czy zadałeś sobie trud przeczytania aukcji od początku do końca i zapoznania się ze spisem treści i wybranymi fragmentami ? Akurat opis sterowania LCD na HD44780 zajmuje 21 stron :D

K.

Krzysztof <osiemk snipped-for-privacy@wp.pl napisał(a):

I stanowi jakieś 5% książki, więc nie tylko LCD ona opisuje :)

Dnia Wed, 26 Jan 2011 21:32:39 +0100, identifikator: 20040501 napisał(a):

To może zainteresuj się kursem programowania w C dla AVR z EdW oraz artykułami z cyklu "AVR–GCC: kompilator C dla mikrokontrolerów AVR" publikowanymi w EP?

Proponuję w następującej kolejności. [..] Język ANSI C Kernighan Brian, Ritchie Dennis M [..]

Do tej książki jest pozycja "Ćwiczenia..." z przykładami. Jako początkujący w C posiadam obie i nie źle mi idzie poznawanie tego języka programowania.

Racja. Kolega identyfikator... nieźle się popisał w tym wątku.

Zrozum język wyższego poziomu jakim jest C. Powstał po to, abyś nie musiał się męczyć w programowanie pod procesor. Wystarczy napisać kilka funkcji (czy metod - jeden pies) do obsługi danego procka. Dzięki temu łatwo mi było kiedyś zmienić biblioteki Microchipa na Atmela. Wystarczyły drobne zmiany odwołań do rejestrów. I reszta kodu ruszyła. Używam fragmentów kodu napisanych pod kompy klasy PC w atmelkach i działają. Generalnie potrzebny jest jedynie podręcznik C i datasheet procka. Ale oprócz tego trzeba wiedzieć jak działa kompilator (abstrakcyjny), jak działa mikroprocesor (też abstrakcyjny). Obawiam się, że tutaj jest pies pogrzebany. Określ się na jakim etapie jesteś - czy masz doświadczenie i znasz assembler do AVR, czy pisałeś coś w C, czy innym języku wyższego poziomu.

Gdzie mozna znalezc informacje o abstrakcyjnym kompilatorze?

Tomek

Użytkownik "bratsiostry" <no_more snipped-for-privacy@interia.pl napisał w wiadomości news: snipped-for-privacy@interia.pl...

Nie piszę nic na procki więc może nie powinienem się odzywać, ale tak mi się kojarzy wypowiedź kogoś biegłego w asemblerze AVR czytającego kurs C na AVR w EP czy EdW (kilka ładnych lat temu) świadczące według mnie, że procek trzeba znać dokładnie. Brzmiało to mniej więcej tak: "Przecież tak nie można na AVR! Widać, że gość przeniósł się z 51 gdzie tak było można. Facet użył pól bitowych do przekazywania flag między programem a przerwaniami. Tego się nie da _dobrze_ zrealizować w asemblerze AVR bo zmiana bitu wymaga dwu rozkazów i jak między nimi przyjdzie przerwanie to ustawiona w przerwaniu flaga w tym samym rejestrze zostanie skasowana pierwszym rozkazem po powrocie z przerwania." Wiem, że tego typu problem może rozłożyć cały projekt. Zdarzyło nam się to z Microchipami - przerwanie raz na około 3000 razy było "przegapiane". Sami znaleźliśmy i zrozumieliśmy 3 błędy w działaniu tego procka, ale to był 4, którego nie potrafiliśmy obejść. Uzyskanie erraty (opisywała 6 błędów) od Microchipa zajęło nam 1,5 roku (nie odpowiadali na faxy - dopiero na pierwszym seminarium Microchipa w Polsce ktoś obiecał erratę i za 3 miesiące przysłał) no i było już za późno. P.G.

jasne że tak, cały ten C to nieudany patch dla laików...

Użytkownik "Piotr Gałka" snipped-for-privacy@CUTTHISmicromade.pl napisał w wiadomości news:4d467cd6$ snipped-for-privacy@news.home.net.pl...

To oczywiście może działać, po to m.in. jest cli i sei, aby w newralgicznych miejscach przerwania wyłączać. Ale zgodze się, że pierwszy projekt dobrze jest napisać w assemblerze, bo wtedy ma się pojęcie o rzeczach, o których dłubacz kodu w C, nigdy nie będzie miał pojęcia.

W dniu 31.01.2011 11:05, Marcin Wasilewski pisze:

Jak na przykład?

W dniu 31.01.2011 10:11, Piotr Gałka pisze:

Po pierwsze m.i. od tego jest możliwość zablokowania przerwań aby wykonywać operacje atomowe.

Po drugie C (avr-gcc) udostępnia ładne makro po którym od razu widać, że w tym miejscu zachodzi synchronizacja: ATOMIC_BLOCK(ATOMIC_FORCEON) { flags |= 0b00001001; }

Użytkownik "Michoo" <michoo snipped-for-privacy@vp.pl napisał w wiadomości news:ii66p3$56t$ snipped-for-privacy@news.onet.pl...

Ani nie czytałem tego kursu, ani nie pisałem nigdy nic pod gcc. Przypuszczam, że w tym kursie było coś takiego: struct {int a:1;int b:1;...}flags; i potem zapisy typu: flags.a=1; które prawdopodobnie nie były w nic robiącego z tego operację atomową ujęte. O ile widząc flags|=1 można się spodziewać kilku rozkazów, o tyle widząc flags.a=1 można mieć większe problemy, aby wpaść na to, że to może wymagać otoczenia blokowaniem przerwań. Tak z czystej ciekawości: Czy takie makro patrzy co jest w jego wnętrzu i albo blokuje przerwania, albo nie (jeśli wnętrze z natury jest operacją atomową) ? P.G.

Użytkownik "Michoo" <michoo snipped-for-privacy@vp.pl napisał w wiadomości news:ii6612$1o6$ snipped-for-privacy@news.onet.pl...

Np. tak:

a) co jest zrzucane na stos i dlaczego w takiej kolejności, b) że są rejestry w obszarze I/O i w ext. I/O, a w związku z tym sporo inaczej je się obsługuje, w szczególności jeśli chodzi o operacje bitowe. c) że czasami po zapisie do rejestru warto wstawić nop, zanim zaczniemy go czytać. d) że pewne instrukcje działają wyłącznie na dedykowanych rejestrach, e) że wartość z rejestru PC to tak naprawdę liczba słów i trzeba ją pomnożyć x2, jeśli chcemy tej wartości użyć poprzez lpm, f) że używając w C zmiennej typu char do wymiany danych z proc. obsługi przerwań, nie trzeba się tym przejmować, w odróżnieniu od int-ów i jeszcze dłuższych zmiennych, g) że znacznie lepiej mnożyć/dzielić przez 2, 4, 8 itd., niż przez 10.

I wiele, wiele innych rzeczy o których w tej chwili nie pamiętam.

W dniu 31.01.2011 15:11, Marcin Wasilewski pisze:

Jakie to ma znaczenie w kodzie C?

Jakie to ma znaczenie w kodzie C, poza informacją, że porty mają możliwość ustawiania/gaszenia atomowo jednego bitu? (Co jest w dokumentacji.)

O co powinien zadbać kompilator. Tak samo jak o uporządkowany zapis do rejestrów 16b.

Jakie to ma znaczenie w kodzie C?

Jakie to ma znaczenie w kodzie C? Poza tym to jest w dokumentacji.

Chyba, że się operuje na bitach... Poza tym jest to okropny styl pisania

- komunikację z przerwaniami zawsze lepiej objąć w ATOMIC, bo inaczej łatwo o prosty błąd przy późniejszych przeróbkach kodu. (A koszt zazwyczaj pomijalny - 2 cykle +1 cykl opóźnienia.)

Dlaczego? Jeżeli procesor ma układ sprzętowego mnożenia to jest to jeden cykl różnicy. Dzielenie przez stałą sensowny kompilator zamienia na mnożenie.

I wiele, wiele innych rzeczy o których programista C _nie musi_ pamiętać.