[AVR] Waarom clkdiv8?

Wat voor component gaat het over?

Het stroomverbruik van je processor is grotendeels afhankelijk van de clocksnelheid.Je kan in bepaalde delen van je programma de clocksnelheid verlagen en (bijv ergens op wachten) en in andere delen van het programma op full speed draaien.
Als je een lager kristal eraan hangt heb je die mogelijkheid niet.Kan ook zijn dat de ingebouwde kristal oscillator alleen in een bepaalde range wil oscilleren (staat meestal in het datatsheet).Als dat niet laag genoeg is voor jouw kun je hte delen.
Verder: kristallen voor lage frequenties zijn(waren vroeger) fysiek groter vandaar dat vaak een exemplaar met hogere frequentie wordt gekozen om daarna te delen.Tegenwoordig kom ik dat fenomeen echter niet meer zo tegen.Hoewel de frequenties onder de 3Mhz moeilijker te vinden zijn.
Je ziet het: er zijn legio redenen te bedenken.

Een AVR, denk ik.

Het kan handig zijn, als je (tijdelijk) een lagere frequentie kan kiezen om alzo stroom te besparen.

Jep, avr ... en het staat standaard aan ( bij mega8 88 ed toch )

Why ?

Bijvoorbeeld van bepaalde avr draait de interne RC oscillator op 8Mhz om de avr zuiniger te krijgen en zonder dat je gebruik te moet maken van kristal kan je de avr op 1mhz laten lopen. Wat ook de default setting zijn van aantal atmega en tiny.

[Bericht gewijzigd door peter79 op zondag 24 juli 2011 16:11:43 (18%)]

Ah sorry, vergeten te vermelden .
Het betreft inderdaad een AVR (ATmega48P), ik dacht dat dit in iedere µC voorzien was?

Het is één van de fusebits. Kan je die dan zomaar softwarematig beïnvloeden om in sommige delen van een programma aan een lagere snelheid te werken?

Om nog duidelijker te zijn, ik ben een beetje aan het experimenteren. Stuur een ledje 150ms aan en 150ms uit, maar dat knippert ofwel veel te snel, ofwel veel te traag, maar zelden zoals ik zou willen
Daarom ben ik me wat aan het verdiepen in de kloksnelheid en instellingen.

Op 24 juli 2011 16:13:48 schreef duveltje4:
Het is één van de fusebits. Kan je die dan zomaar softwarematig beïnvloeden om in sommige delen van een programma aan een lagere snelheid te werken?

Nee, fusebits zijn niet vanuit de controller zelf te manipuleren.

Nee dat heeft niet elke micro controller, zijn zoveel verschillende controller te krijgen in ook hele hoop smaken, van heel kaal tot heel uitgebreid. Zelfs AVR onderling hebben niet de zelfde functies, laat staan andere merken.

clkdiv8 is dacht ik een specifiek AVR bit, die overigens bij de moderne avr wel meestal(altijd?) wel aanwezig is.

Edit/
Heb je de snelheid waarom de AVR draait wel juist ingesteld in je code? meestal als iets te snel of te traag is komt de snelheid van de avr niet overeen met die je opgeeft in de code.

[Bericht gewijzigd door peter79 op zondag 24 juli 2011 16:27:36 (22%)]

CKDIV8 kan je wèl softwarematig in- en uitschakelen naar wens.
Het fuse-bit blijft daarbij ongewijzigd.

[Bericht gewijzigd door pros op zondag 24 juli 2011 16:34:26 (29%)]

Ja inderdaad pros, daar hadden we tijdje terug nog over gehad in een ander topic.

Interessant, kan dat bij alle AVRS? (Sommige PIC's kunnen at runtime de klokfrequentie wijzigen, 16f887 bijvoorbeeld.)

Bij sommige AVR's kan het lopend programma de systeemklok zelfs delen door 2, 4, 8, ... 256.
Kleinere AVR's hebben meestal minder mogelijkheden.

Heeft het feit dat hij standaard aan staat (dus 1MHz ipv. 8MHz op de interne RC oscillator) niet te maken met backwards compatibility, omdat de oudere modellen (AT90xxxx) ook standaard op 1MHz liepen?

Ik meende dat de kloksnelheid voor het stroomverbruik weinig uit maakt. Het wel of niet gebruiken van een kristal, en sleep modes maken veel meer uit dan 1MHz of 8MHz. Hogere kloksnelheid is in sommige gevallen juist gunstiger omdat je meer tijd in sleep doorbrengt.

Ik ga straks nog wat verder experimenteren...
Wat gebeurd er met de geprogrammeerde tijden wanneer je de klok halveert? Verdubbelen die dan of blijven die onveranderd?

Die veranderen proportioneel.

Op 24 juli 2011 19:13:01 schreef duveltje4:
Ik ga straks nog wat verder experimenteren...
Wat gebeurd er met de geprogrammeerde tijden wanneer je de klok halveert? Verdubbelen die dan of blijven die onveranderd?

Ligt eraan wat je doet met de code, maar lijkt me als je die dus ongewijzigd laat op 8Mhz en je halveert de core clock zal de code twee keer zo traag uitgevoerd worden. Maar je kan de code ook aanpassen zodat ze weer gelijk lopen.

Als jij "1dag" als geprogrammeerde tijd hebt en die bepaald door de RTC die je hebt aangesloten uit te lezen en te wachten totdat ie eerst een andere en dan weer dezelfde waarde aangeeft (bij uur-minuut-seconde), dan verandert de "geporgrammeerde tijd" niet met de clocksnelheid.

Bij AVRs moet IK altijd aangeven:

#define CPUMHZ 20
#define F_CPU ( 1000000UL * CPUMHZ )

Als ik dan delay_ms(150) doe, dan zorgt de compiler er voor dat er (ongeveer) 150 * 1000*20 clock cycles gewacht wordt. Deel je de clock door twee, dan is dat dus 2x zo lang als bedoeld.

Ik werk zelf niet met AVRs maar kan het zo zijn dat bv de timer (counter op de clock) wel op 8mhz blijft werken. Hierdoor kun je op lage snelheid (1 mhz) wel tijd meten op hogere resolutie.

Dat zou een verschil kunnen zijn tussen 1mhz kristal en 8mhz en deler.

[Bericht gewijzigd door knifter op maandag 25 juli 2011 11:05:06 (16%)]

Nee, toch niet. De systeemklok is tevens de klok voor de (prescaler van) timers.
Met een uitzondering: sommige AVR's beschikken over een PLL, en kunnen daarmee de timers voorzien van een 64MHz- of een 32MHz-klok terwijl het systeem op 8MHz draait.