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.

do góry

On 30/01/2011 6:00 AM, bratsiostry wrote:
> 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

do góry

Użytkownik "bratsiostry" <n...@i...pl> napisał w wiadomości
news:4D4471C5.8060804@interia.pl...
> 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.
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.

do góry

> P.G.

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

do góry

Użytkownik "Piotr Gałka" <p...@C...pl> napisał w
wiadomości news:4d467cd6$1@news.home.net.pl...

> "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."

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.

do góry

W dniu 31.01.2011 11:05, Marcin Wasilewski pisze:
> 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.
Jak na przykład?

--
Pozdrawiam
Michoo

do góry

W dniu 31.01.2011 10:11, Piotr Gałka pisze:
> "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."
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;
}


--
Pozdrawiam
Michoo

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:ii66p3$56t$1@news.onet.pl...
>W dniu 31.01.2011 10:11, Piotr Gałka pisze:
>> "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."
> 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;
> }
>
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.

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:ii6612$1o6$1@news.onet.pl...
> W dniu 31.01.2011 11:05, Marcin Wasilewski pisze:
>> 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.
> Jak na przykład?

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.

do góry

W dniu 31.01.2011 15:11, Marcin Wasilewski pisze:
> Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
> news:ii6612$1o6$1@news.onet.pl...
>> W dniu 31.01.2011 11:05, Marcin Wasilewski pisze:
>>> 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.
>> Jak na przykład?
>
> Np. tak:
>
> a) co jest zrzucane na stos i dlaczego w takiej kolejności,
Jakie to ma znaczenie w kodzie C?

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

> c) że czasami po zapisie do rejestru warto wstawić nop, zanim zaczniemy
> go czytać.
O co powinien zadbać kompilator. Tak samo jak o uporządkowany zapis do
rejestrów 16b.

> d) że pewne instrukcje działają wyłącznie na dedykowanych rejestrach,
Jakie to ma znaczenie w kodzie C?

> 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,
Jakie to ma znaczenie w kodzie C? Poza tym to jest w dokumentacji.

> 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,
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.)

> g) że znacznie lepiej mnożyć/dzielić przez 2, 4, 8 itd., niż przez 10.
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 w tej chwili nie pamiętam.
I wiele, wiele innych rzeczy o których programista C _nie musi_ pamiętać.

--
Pozdrawiam
Michoo

do góry