Taktowanie AVR'ów

Daymian · Post autor: **Daymian** » 09 sie 2006, 21:08

Mam takie może głupie ale ciekawe pytanie: z jaką najmniejszą częstotliwością można taktować mikroprocesory AVR?

ZbeeGin · Post autor: **ZbeeGin** » 09 sie 2006, 23:26

Otwieram pierwszą z brzegu notę katalogową... Frequency range: 0 - 12MHz, zatem można powiedzieć, że taktowanie zegarem 0,00000000000000000000000000000000000001Hz to i tak za dużo.

Myślę jednak, że 1Hz to będzie jakieś ekstremalne ale rozsądne minimum. Spoglądając jednak na Watchdog (w układach serii Mega) którego zegar może taktować procesor, to najmniejszą częstotliwością jaką się stosuje w praktyce jest 128kHz.

Daymian · Post autor: **Daymian** » 10 sie 2006, 0:29

Czyli jak podłoncze genertaor 10Hz to też procek będzie chodził? (przy wyłonczonym watchdogu) Cos mi sie nie wydaje...sprawdze.

ZbeeGin · Post autor: **ZbeeGin** » 10 sie 2006, 5:49

Daymian pisze:Czyli jak podłoncze genertaor 10Hz to też procek będzie chodził? (przy wyłonczonym watchdogu) Cos mi sie nie wydaje...sprawdze.

Procek powinien chodzić, tylko należy pamiętać aby zbocza sygnału taktującego mieściły się w tolerancji opisanej w danych katalogowych.

Program testowy najlepiej napisz w asemblerze, bo na start programu napisanego w BASCOM-ie możesz się nie doczekać...

Daymian · Post autor: **Daymian** » 10 sie 2006, 10:03

ZbeeGin pisze:Program testowy najlepiej napisz w asemblerze, bo na start programu napisanego w BASCOM-ie możesz się nie doczekać...

A to dlaczego sie nie doczekam? Bascom ma to do siebie że wolno startuje? Czy programy w Bascomie sie dłużej wykonują? A powiedźcie mi jeszcze czy programy w asemblerze i C wykonują sie z taką samasz szybkością?

marcing · Post autor: **marcing** » 10 sie 2006, 10:53

Wszystkie wykonują się z taką samą szybkością, ale robia różne rzeczy po starcie.
W asemblerze masz nad tym kontrolę, w C zależy to od kompilatora. W BASCOM'ie niestety jesteś zdany na ustawienia domyślne - możesz jedynie wyłączyć kasowanie zawartości pamięci RAM po restarcie (dyrektywa $noramclear). Pozostałe rzeczy, jak ustawienie rejestrów SPL i SPH, konfiguracja portów są od Ciebie niezależne.

Ponieważ można przyjąć, że uP AVR wykonuje pojedyńczą instrukcję w jednym takcie zegarowym, to przy 10Hz wykona zaledwie 10 poleceń w ciągu sekundy... Gdybyś napisał program w BASCOM'ie i nic nie zmieniał w ustawieniach, wtedy czekałbyś kilkadziesiąt sekund na start programu (wyczyszczenie pamięci bajt po bajcie trochę trwa).

Zgodzę się z tym, co pisze ZbeeGin, że częstotliwość Watchdog'a to w zasadzie rozsądne minimum... W zasadzie, to wszystko powyżej 100kHz jest rozsądną częstotliwością...

Daymian · Post autor: **Daymian** » 10 sie 2006, 12:17

Czyli skoro wszystko wykonuje sie w Bascomie równie szybko jak w asemblerze czy C to dlaczego niektórzy bardzo doświadczeni tak go unikają jak ognia? Przeciez do przeważającej liczby zastosowań wystarczył by tylko Bascom.

A co ma do rzeczy przy taktowaniu procka prędkość Watchdoga????

marcing · Post autor: **marcing** » 10 sie 2006, 12:32

Dlatego bardziej doświadczeni unikają BASCOM'a, że mają pełną kontrolę nad programem.
Tu nie chodzi o prędkość działania samego programu, lecz czas wykonywania pojedyńczej instrukcji kodu maszynowego (nie BASCOM'a).
BASCOM dodaje kilka rzeczy "od siebie", przez to programy wynikowe zawierają więcej (zbędnego) kodu. Porównanie na korzyść asemblera/C może być znaczne - czasem programy w asemblerze/C mają objętość 10% (lub mniej) programu w BASCOM'ie - a robią to samo. Oczywiście - nakład pracy jest inny, ale dla takiego wyniku warto się natrudzić (czasem w 2kB pamięci dostępnej możesz umieścić program, który pisany w BASCOM'ie ledwo mieści się w 8kB mega8). Dlatego też program (cały) może wykonać się dużo szybciej niż napisany w BASCOM'ie.

W procesorach ATmega jako jedno ze źródeł taktowania możesz wybrać zegar watchdog'a, niezależnie czy ten działa - czy nie...

Daymian · Post autor: **Daymian** » 10 sie 2006, 14:30

Aha, już łapie. A co do Watchdoga to jak będe chciał sie bawić z częstotliwością taktowania co jednak będe sie bawił jakimś zewnętrznym sygnałem.

Hm..ale z tego co piszesz to wynika ze w Bascomie programy są większe-ok. Ale co z tą prędkością? To oznacza że np. wykonywanie polecenia ustawienia jakiegoś bitu w Bascomie trwa dłużej? Bo troche niejsno to napisałeś...a przynajmniej dla mnie

marcing · Post autor: **marcing** » 10 sie 2006, 14:43

Ustawienie pojedyńczego bitu będzie wyglądać tak samo jak w asemblerze - pojedyńcza instrukcja sbi/cbi załatwi wszystko. Ale inne rzeczy, np.: sterowanie wyświetlacza LCD, można zrobić prościej niż jest to w BASCOM'ie - ten przyjmuje najgorszy możliwy przypadek i obudowuje proste polecenie wysłania bajtu do wyświetlacza kilkudziesięcioma instrukcjami kodu maszynowego...

Musisz sobie uzmysłowić, że BASCOM tłumaczy pojedyńcze polecenie na ciąg kilku(nastu, dziesięciu) instrukcji kodu maszynowego.
Zwykłe polecenie PRINT wpierw sprawdzi, czy bufor UART'a jest pusty, wpisze pierwszy bajt z zadanego ciągu do bufora, poczeka aż zostanie zakończona transmisja, wpisze następny bajt itd. aż do wysłania całości. To oczekiwanie jest ciągłą pętlą programową sprawdzającą stan pojedyńczego bitu w rejestrze UART. Łatwiej, i z mniejszym obciążeniem procesora można to zrobić wykorzystując przerwania...

Ps.: Zauważyłem, że coraz mniej robisz błędów, piszesz też całkiem "gramatycznie" - skąd poprawa?

(I jak widzisz, da się pisać "lepiej" - pozdrawiam

)

Daymian · Post autor: **Daymian** » 10 sie 2006, 17:36

Dobra, mniej więcej rozumie...

P.S. To zalezy od nastroju i skupienia. Nastrój swoją drogą a skupienie- im mniej jestem skupiony na błędach tym mniej robi błędów. A jak mysle to robie dużo. W ten sposób załatwiałem sprawe dyktand w podstawówce i gimnazjum