Atmega: Intern RTC, extern RTC eller intern Watchdog med RC?

Joe · Inlägg av **Joe** » 13 september 2008, 10:44:48

Funderar om jag ska ha intern RTC, extern RTC eller intern Watchdog med RC på just idetta fall en Mega8

Intern RTC då har man en 32kHz kristall för RTC'n och intern RC för uC'n
Extern RTC med interrupt signal (wake up), vanlig kristall för uC'n
Intern Watchdog med intern RC, vanlig kristall för uC'n

uC'n skall utföra en kommunikationskontroll med en annan uC tex var 3600 sekund mha av en RTC eller liknande.
Om den "sover" så ska den vakna.

Vilket skulle ni ha föredragit?

Hmm, undra om man kan använda Watchdog'en till tidsräkning. Dvs timmar, minuter, sekunder

Får se om jag kan hitta nåt i databladet. Eller så kanske man köra en wake-up varje sekund och räkna upp?

sodjan · Inlägg av **sodjan** » 13 september 2008, 10:51:07

> undra om man kan använda Watchdog'en till tidsräkning.

Normalt så har en watchdog ingen noggranhet alls.
Duger för att starta om processorn om den hänger upp sig,
vilket den ju är avsedd för...

Joe · Inlägg av **Joe** » 13 september 2008, 10:59:06

Atmel kallar den "Programmable Watchdog Timer with Separate On-chip Oscillator" i Mega8 manualen.
Hittar dock inget hur stabil den är.

Tanken är att den andra uC'n skall ligga och lyssna "hela tiden" och agera clock-master.

thepirateboy · Inlägg av **thepirateboy** » 13 september 2008, 11:09:18

Min erfarenhet är som Sodjans att watchdoggen har väldigt dålig noggrannhet. Jag kör med extern 32.768 kristall med uppvakning var 8 sekund och det verkar vara "stabilt".

Från databladet Atmega88:

"Note that the 128 kHz oscillator is a very low power clock source, and is not designed for a high accuracy."

Finns även några grafer i slutet som visar hur frekvensen driver iväg vid olika spänning och temperatur.

Joe · Inlägg av **Joe** » 13 september 2008, 11:21:58

Får nog titta på en annan Atmega, typ 16/32/64/128 etc som har separata ben för 32kHz kristall till intern RTC'n så att man kan ha vanlig kristall till uC'n
Det verkar som man kan använda RTC'n som interrupt.. Får studera databladen närmare..

björn · Inlägg av **björn** » 13 september 2008, 11:23:44

räcker att du går upp till ATmega8:ans ersättare, dvs atmega88.

thepirateboy · Inlägg av **thepirateboy** » 13 september 2008, 11:36:25

Det är relativt enkelt att använda en 32,768 kristall låta den vakna av interrupt av timer overflow. Initiera med följande kod:

Kod: Markera allt

	
set_sleep_mode(SLEEP_MODE_PWR_SAVE);		// Power save mode	

// Timer setup
TCCR2B =  (1<<CS22) | (1<<CS21) |(1<<CS20);   // Prescaler (1024/32768)*256 = 8 seconds interrupt
TIMSK2 = (1<<TOIE2);			// Timer 2 overflow interrupt enabled
ASSR = (1<<AS2);				// Asynchronous (crystal oscillator)

Du behöver placera ett tomt interrupt nånstans för timer overflow:

Kod: Markera allt

//----------------------------------------------------------------------------//
// Empty interrupt for wake up of sleep
//----------------------------------------------------------------------------//
ISR(TIMER2_OVF_vect)
{
	
}

För att försätta den i sleepläge:

Kod: Markera allt

				
cli();
sleep_enable();
sei();					// Activate global interrupt
////////////////////////////////////////////////////////////////////
sleep_cpu();				// Now its sleeping, ZZzzzzzzzz
////////////////////////////////////////////////////////////////////
sleep_disable();

Den vaknar nu var 8 sekund och börjar exekvera koden efter sleep_disable

Precis som du säger måste man byta upp sig till exempel Atmega324P om man både vill ha 32,768 kristall och köra MCU:ns klocka på extern kristall.

Joe · Inlägg av **Joe** » 13 september 2008, 12:55:03

björn skrev:räcker att du går upp till ATmega8:ans ersättare, dvs atmega88.

48/88/168 har samma ben för XTAL och TOSC. Dvs då kan man bara köra uC'n på RC om man vill ha en extern 32kHz för RTC

Tack för koden thepirateboy! Får införskaffa en annan uC

Swech · Inlägg av **Swech** » 13 september 2008, 23:02:38

Är det batteridrift som gäller?
Är noggranheten att du måste träffa på sekunden,
du säger 3600 sek, funkar 3400 - 3800 sekunder eller
måste du ha 3599 - 3601 sek

Om du inte kör batterimatat och inte skall sälja en hel hög av dem
så kan du ju låta processorn rulla och räkna med timers istället.
Den drar ju inte många mA även vid "full fart"

Swech

Joe · Inlägg av **Joe** » 14 september 2008, 09:10:21

Det är batteridrift med solcellsladdning jag hade tänkt.

Som jag skrev ovan så kommer den andra uC'n att ligga och lyssna var 10ms? (mer eller mindre) Detta för att det kommer att bli mera kommunikation än dessa regelbundna komunikationskontroller.
Den är dock nätdriven.

Ingen försäljning, den blir "one of a kind"

Jag hade tänkt mig att det skulle bli precis vid 3600s för att den nätdrivna uC'n skulle jämföra mot sin RTC och skicka tillbaka korrektion om nödvändigt.

Men man kan ju lika gärna skicka med en timestamp från den batteridrivna uC'n: "Klockan 12:00:00 sände jag, status OK"
Då är det inte lika kritiskt när den sänder. Så 3400 - 3800 sekunder skulle funka.

Swech · Inlägg av **Swech** » 14 september 2008, 10:54:51

kan inte den processor som är nätansluten väcka den batteridrivn när det
är dax istället? det verkar ju ändå vara den som bestämmer?

Vad skall den batteridrivna göra mer än sova?

Du behöver nog beskriva vad det är du vill göra lite närmare. Lösningen
kan vara helt annan än att greja med RTC...

Swech

Joe · Inlägg av **Joe** » 14 september 2008, 13:01:23

I grova drag:

Den batteridrivna uC'n har en extern interrupt (ett ben på uC'n) som väcker den och får den att sända typ: "Klockan 14:28:39 extern interrupt"

Då tar den nätanslutna emot och svarar med CRC + CTS eller nåt enklare.

Om inte den nätanslutna svarar så försöker den batteridrivna igen.
Om svar "CTS" så skickar den batteridrivna "DATA"

Den nätanslutna svarar med CRC + End? eller nåt enklare.

Om den batteridrivna får "End" så somnar den igen till nästa gång, extern eller RTC interrupt.

Så det är den batteridrivna som initierar kommunikation oavsett om det är interrupt eller regelbundet via tex RTC.

sodjan · Inlägg av **sodjan** » 14 september 2008, 13:07:50

> ...eller regelbundet via tex RTC.

Med vilken precision måste det ske ?
Om menar du verkligen "Real Time Clock" ?
Är det inte bara ett visst fördröjning som behövs ?
Eller måste timestampen vara ett visst klockslag ?
Gör det något att dessa timestamps driver över tiden ?
Vad är syftet med RTC-avbrottet ? Är det ett "heart-beat",
d.v.s för att signalera att "lugn, jag lever" eller liknande ?

Joe · Inlägg av **Joe** » 14 september 2008, 15:04:11

Ja det är en "heart-beat" funktion, skrev kanske otydligt förrut.

I Atmels värld så betyder RTC Real Time Counter, vilket går att använda som en Real Time Clock.

"Heart-beat" behöver inte vara ett visst klockslag utan ett fast intervall, eller fördröjning som du skriver.

Se 5 inlägg innan ang precisionen på den regelbundna "heart-beat'en"

För övrigt så behövs timestampen då den batteridrivna uC'n samlar på sig "events" om inte den nätdrivna skulle svara.

sodjan · Inlägg av **sodjan** » 14 september 2008, 16:01:01

OK, det är väl "Real Time" här som är viktigt.
Normalt avser det något som inte bara håller reda på
h

s utan även dag/månad/år och ibland veckodag.
Det är ju lite skillnad från om det räcker med ett "intervall".

En variant är att räkna intervallet från senaste kontakt och
sedan kan den nätdriva enheten räkna ut den faktiska
tidpunkten som <senaste tidpunkt> + <intervall>. Det är
lättre att räkna ett intervall (som börjar på noll vid varje
kontakt) än att hålla reda på h

s (och eventuell dag/mån/år).

Hur som helst, om du vill att den batteridrivna prylen ska
lägga "timestamp" på händelser så behöver du ju en klocka
som går även under "sleep". Jag tror inte att Watchdogen
kan ge det.