ATNEL tech-forum

Re: jeszcze raz przerwanie od Timera w trybie CTC

2013-08-18T16:45:48+01:00

Quote:

Ale przyznasz Mirku, że dzięki assemblerowi bardziej czujesz "co jest w środku"

Ale dlatego ja zawsze i to bez żadnej ironii czy prześmiewania - polecam (o ile ktoś ma czas) właśnie "polizać" że tak powiem procka od strony asemblera

Tyle że to już moje zboczenie - że ja akurat procka muszę od asemblera choć troszkę poniuchać

Z drugiej strony uwierz mi ... że nawet gdybym go nie znał - to na potrzeby pisania i tworzenia projektu wcale nie korciłoby mnie zajrzenie do tzw "czarnych skrzynek" języka C - jak one działają pod spodem. To tak samo jak z autami. Jeżdżę sobie nimi - ale czy zawracam sobie głowę tym jak działa w nich każdy szczegół ? absolutnie nie ..... bo jak miałbym poznać ten każdy szczegół zanim wsiądę to pewnie nie doczekałbym końca żywota zanim wszystko ogarnę

Za to jak mam wolny czas i z czystej ciekawości - .... pewnie, że nieraz lubię poczytać a to o tym a to o siamtym co jest w środku

I tak samo podchodziłbym do programowania. Bo czasem (jak widzę po niektórych czytelnikach) .... jak się zatną na tym że nie wiedzą jak to działa w środku a czasem chcą aż zrozumieć wręcz co się dzieje i jak się dzieje tam w krzemie to koniec - nie mogą przejść dalej ...

Tym bardziej byłoby takim osobom zrozumieć i nauczyć się programowania obiektowego - chociażby C# .... no bo tu próba rozgryzienia jak to działa pod spodem na początku nauki - żeby wyświetlić sam napis

"hello world"

zajęłaby na prawdę kilka lat

A tymczasem - dostajemy narzędzia - "obiekty", "klasy" itp i mamy się tylko nauczyć jak się z nich korzysta a nie jak Bill napisał podstawową wersję Windows'a

Statystyki: Napisane przez mirekk36 — 18 sie 2013, o 16:45

Re: jeszcze raz przerwanie od Timera w trybie CTC

2013-08-18T15:54:00+01:00

mirekk36 napisał(a):

NIC, bo w tym przypadku to ja traciłem tylko czas na przygotowywanie tablicy wektorów przerwań ...

Ale przyznasz Mirku, że dzięki assemblerowi bardziej czujesz "co jest w środku"

A cały problem wziął się z tego że o ile np.
LED ON ; (str 125)
mogę rozłożyć na "czynniki proste"
Tzn że LED ON; to przyjazna nazwa czegoś takiego PORTC &=0111111;
to miałem problemy z
ISR(TIMER0_COMP_vect) To przyjazna nazwa ...no właśnie czego?

Do dzisiejszego dnia to mnie gryzło.
Jednak forum jest super!! Wielkie dzięki za korepetycje

Statystyki: Napisane przez mg101 — 18 sie 2013, o 15:54

Re: jeszcze raz przerwanie od Timera w trybie CTC

2013-08-18T14:40:53+01:00

Quote:

Dla programisty 20 to przyjazna nazwa TIMER0_COMP_vect którą znajdzie w pdf-ie .To jest właśnie zaleta C.
Programista nie musi znać liczb 20 i 1250. Te 1250 "obliczy" kompilator który wie jak rządzić pamięcią.

No bardzo dobrze rozumujesz bo o to chodzi

mg101 napisał(a):

Z drugiej strony czy czegoś nie tracimy? Jak głęboko wchodzić w szczegóły?

No to spróbujmy dowiedzieć się co ew tracimy?

NIC, bo w tym przypadku to ja traciłem tylko czas na przygotowywanie tablicy wektorów przerwań gdy pisałem taki sam kod w asemblerze. Owszem zajadły zwolennik tylko asemblera - powie, ależ to żaden kłopot można sobie makro napisać ... hyhy no można, tyle że jak ludzie używają prawie samych makr w asemblerze - i po jakimś czasie przechodzą na C i go zrozumieją - to później sami widzą - że tworząc te makra - robili coś na kształt języka C ... tyle że miało to bardziej coś wspólnego z wymyślaniem od nowa koła, które jak wiadomo wynaleziono już XXXX lat temu

Owszem .... w innych przypadkach - bardziej zaawansowanych i czaso-zależnych procedur - pewnie że może się kiedyś przydać asembler - no ale to do wstawek .... albo do napisania np jakiejś funkcji czy całej procedury obsługi przerwania - o ile POTRAFIMY napisać to bardziej optymalnie niż kompilator .... a z tym ma problem nawet wielu zagorzałych zwolenników asemblera niestety. Ja na początku też pisząc w C miałem koci nawyk, że co chwilę zaglądałem do pliku *.lss czyli listingu asemblerowego .... czy aby kompilator mnie "nie oszukuje" jak to niektórzy mówią albo czy nie robi czegoś gorzej ode mnie ..... i się mocno zdziwiłem bo w wielu rzeczach robił to lepiej ode mnie a nawet jak się trafiały momenty że gorzej - to co ? co na tym tracę - kilkanaście nanosekund podczas gdy mam wolnego czasu np kilkanaście milisekund ?

Tak samo napisanie głupiej pętli for() z wieloma rarunkami i kawałem kodu w środku - to (jak dzisiaj na to patrzę) masakra - aby pisać to w asm. Owszem da się - i pisałem to często przecież - ale dzisiaj zamiast kilograma kodu źródłowego w asm wolę napisać

for( i=0; i<10; i++ )

i po zawodach - nie interesuje mnie za każdym razem mielenie skokami branżowymi

Statystyki: Napisane przez mirekk36 — 18 sie 2013, o 14:40

Re: jeszcze raz przerwanie od Timera w trybie CTC

2013-08-18T13:28:02+01:00

mirekk36 napisał(a):

No dokładnie - bo właśnie w asemblerze trzeba samemu się troszczyć o te numerki jak i o wiele innych rzeczy ... tylko po co tracić czas - mając C pod ręką ?

Czy dobrze rozumuję?
1. Nastąpiło zrównanie Timera0 z OCR0
2. Procesor skoczy do programu ISR(TIMER0_COMP_vect)
Procesor znajdzie w pamięci FLASH miejsce tego programu w sposób następujący
Dla danego procesora (tu Atmega32) TIMER0_COMP_vect to konkretne miejsce w pamięci FLASH np nr 20. Pod adresem 20 jest adres np 1250 do programu obsługi tego przerwania. Dla programisty 20 to przyjazna nazwa TIMER0_COMP_vect którą znajdzie w pdf-ie .To jest właśnie zaleta C.
Programista nie musi znać liczb 20 i 1250. Te 1250 "obliczy" kompilator który wie jak rządzić pamięcią.
Dalej sprawy są już oczywiste.

Widzimy więc zalety języka C. Nie trzeba dokładnie znać hardware' u. Nawet nie była nam potrzebna wiedza, że nastąpił skok do miejsca, którego adres obliczony jest w sposób pośredni. Z drugiej strony czy czegoś nie tracimy? Jak głęboko wchodzić w szczegóły?

Statystyki: Napisane przez mg101 — 18 sie 2013, o 13:28

Re: jeszcze raz przerwanie od Timera w trybie CTC

2013-08-18T12:43:12+01:00

mg101 napisał(a):

a C "samo" zrobi tak, żeby było dobrze.

No dokładnie - bo właśnie w asemblerze trzeba samemu się troszczyć o te numerki jak i o wiele innych rzeczy ... tylko po co tracić czas - mając C pod ręką ?

Statystyki: Napisane przez mirekk36 — 18 sie 2013, o 12:43

Re: jeszcze raz przerwanie od Timera w trybie CTC

2013-08-18T12:39:41+01:00

mirekk36 napisał(a):

Tym bardziej, że programując w C - kogo to obchodzi jaka tam jest liczba
Tylko jak mówię - przy programowaniu w C - jest to do niczego niepotrzebne

Chyba na tym poprzestanę. Tu widać zalety C. Nie trzeba wchodzić w szczegóły, a C "samo" zrobi tak, żeby było dobrze.

Statystyki: Napisane przez mg101 — 18 sie 2013, o 12:39

Re: jeszcze raz przerwanie od Timera w trybie CTC

2013-08-18T12:35:12+01:00

mg101 napisał(a):

Wiadomo że _VECTOR(10) to konkretna liczba - podejrzewam że 10

Czyli gdzieś powinno być
#define _VECTOR(10) 10

proponuję liznąć asemblera - np z książek BTC "Mikrokontrolery ATmega w praktyce", spróbować RAZ napisać własny prosty program do migania diodą w asm to wiele rzeczy się wyjaśni jeśli chodzi o to - o co kolega pyta.

Tym bardziej, że programując w C - kogo to obchodzi jaka tam jest liczba

A gdybyś zaczął od ASM to wiedziałbyś że jest to odpowiednia komórka w pamięci FLASH licząc od zerowej, w której jest skok do programu, a po niej są adresy skoków do przerwań zgodnie z kolejnością podaną w PDF każdego procka. Tylko jak mówię - przy programowaniu w C - jest to do niczego niepotrzebne

Statystyki: Napisane przez mirekk36 — 18 sie 2013, o 12:35

jeszcze raz przerwanie od Timera w trybie CTC

2013-08-18T11:59:54+01:00

Męczy mnie jedna rzecz.

Nazwa programu obsługi przerwania
ISR(TIMER0_COMPA_vect)

Na podstawie
#define TIMER0_COMP_vect_VECTOR(10)

kompilator zamieni to na:
ISR(_VECTOR(10))

Wiadomo że _VECTOR(10) to konkretna liczba - podejrzewam że 10

Czyli gdzieś powinno być
#define _VECTOR(10)10

To gdzie to jest? W pliku iom32.h nie widzę tego.

Statystyki: Napisane przez mg101 — 18 sie 2013, o 11:59