Sleep/wake up PIC

[ToPNoTCH]

Tycker ie har en mycket relevant synpunkt här.

En sovande processor ser inga blinkningar "what soo ever" så.

Sen blinkar i allfall min elmätare så pass ofta att det nog skulle göra marginell skillnad om jag sövde pic'en, men du har kanske mindre räkning än mig oxo

Du lär nog kolla lite vad som "egentligen" drar ström i din lösning om du skall få bukt med det där problemet.
Jag är övertygad om att PIC'en inte är boven i slutändan.

Jag tänker så här.
- Kör uC'n så långsamt du kan
- Sampla data med släckt XBEE
- Pusha data FRÅN ute delen och pulla inte från inne delen. (Då kan du väcka XBEE på intervall för att skicka data och sedan släcka den igen).
- Se över verkningsgraden i strömförsörjningen (Du har inte skrivit något om hur du försörjer, jag antar att du inte kopplar batteri direkt utan har step-up eller switchregulator typ.)
- Kolla battritekniker som tål kyla bra

[sodjan]

Eller dra fram fast spänningsmatning.

[TomasL]

En sovande processor ser inga blinkningar "what soo ever" så.

Öh, vad menar du?
Vissa delar i en sovande processor, typ möjligheten att vakna upp från ett INT finns alltid där, annars så är ju sleep-modet tämligen meningslöst.
I vissa processorer funkar räknarna, med extern klocka oberoende av sleep-modet, och dessa kan generera ett INT som väcker processorn.
Det innebär att du med oavkortad precision kan väcka processorn, varje, var 10'de, var 100'ade etc puls och skicka antalet pulser i en burst.
Såvida du inte behöver exakt tidpunkt för varje puls. Om inte, så kan du spara mycket energi på det sättet (och interpolera pulserna jämt över tiden).

[TomasL]

Eller dra fram fast spänningsmatning.

Kan ju faktiskt räcka med en lämplig strömtrafo för att driva det hela/ladda upp batteri.

[ToPNoTCH]

En sovande processor ser inga blinkningar "what soo ever" så.

Öh, vad menar du?
Vissa delar i en sovande processor, typ möjligheten att vakna upp från ett INT finns alltid där, annars så är ju sleep-modet tämligen meningslöst.

Det var just därför jag utryckligen påtalade att ie's inlägg var relevant.

Utan den interrupten var ju hela vitsen med sleep borta i den här tillämpningen.

[TomasL]

Jo men du skrev ju

Tycker ie har en mycket relevant synpunkt här.

En sovande processor ser inga blinkningar "what soo ever" så.

Vilket jag tolkar väldigt motsägelsefullt.
Eftersom IE skrev att en sovande processor kan väckas av en blinkning, och därmed kan se alla blinkningar.

[ToPNoTCH]

Men...

Fan vad du e grinig nu, ibland känns det som Boston legal här.

Jag tar detta så pedagogiskt jag kan.

1.) Trådskaparen vill ha hjälp med följande:

Jag är ute efter en kodsnutt i C som:
- sätter rätt register/bitar
- sparar undan data (om det är nödvändigt)
- försätter PIC:en i sömn
- väcks av sig själv (Watchdog)

2.) ie skriver ett par poster längre ned:

Pulsen från elmätaren borde kunna generera en interupt som väcker CPU'n.

3.) Sedan kommer 8 inlägg i hur WDT fungerar (irellevant för att lösa problemet).

4.) Jag försöker få tillbaka fokus på lösningen med min post.

Om TS skriver väcks av sig själv (Watchdog) som lösning så missar han blinkningarna. Det är hela pointen som jag försöker förmedla och tyckte jag skrev oxo.

[TomasL]

Ja Ja, tagga ned.

[magnuscj]

Jag kommer att ge mig på alla delar i kretsen i jakten på mA. Här vill jag dock ta en sak i taget för att inte tråden skall bli svår att följa. Nu gäller det PIC:ens sömn och uppvaknande som gäller och inget annat.

Jag bestämde mig för att försöka mig på "Interrupt-on-change".

Jag sätter PIC:en i sleep för att sedan väcka den med +5v på PB5. PORTC används som indikator.

Följande program skall göra detta men det fungerar inte... Vad kan problemet vara?

Kod: Markera allt

  
unsigned tempRead;
void interrupt(void)
{
     PORTC = 0x00000001;
     if (INTCON.RABIF == 1)
       {
        PORTC = 0x00000001;
        tempRead = PORTB;           //Read PORTB to clear mismatch
        INTCON.RABIF = 0;        // Clear interrupt flag
       }//end intcon.RBIF if
}
void main() {
  ANSEL  = 0;             // Configure AN pins as digital I/O
  ANSELH = 0;
  C1ON_bit = 0;           // Disable comparators
  C2ON_bit = 0;
  TRISC  = 0;              // PORTC is output
  UART1_Init(9600);     // Initialize UART module at 9600 bps
  Delay_ms(200);         // Wait for UART module to stabilize

  OPTION_REG = 0x7F;      // set internal PORTB pulls ON
  IOCB = 0x00100000;      // set RB5 interrupt on change to ON
  WPUB = 0x00100000;      // ensure RB5 internal pull up is ON
  TRISB = 0x11111111;     // PORTB as input
  tempRead = PORTB;       // read PORTB
  INTCON.RABIF = 0;       // Clear interrupt flag prior to enable
  INTCON.RABIE = 1;       // enable on change interrupts
  INTCON.GIE   = 1;       // enable Global interrupts
  PORTC = 0x00000000;
 
  do{
  asm{
         sleep;
  }
  PORTC = 0x00000001;    //ON
 
   }while (1);

[bearing]

Jag sätter PIC:en i sleep för att sedan väcka den med +5v på PB5

Med pull-up aktiverad kommer +5V till pinnen inte innebära någon förändring, utan det kommer koppling till 0V att göra.

[v-g]

I princip ser ju en SLEEP rutin ut som följer

Kod: Markera allt

Igen
   SLEEP
   Kolla läget
GOTO Igen

Det är en mycket enkel rutin men står någon port fel (tex jobbar MOT en pullup/down) så spar det ingen ström alls. Kör man ner PIC:en på låg frekvens spar man nog lika mycket nästan. Timers och lite annat stoppas när man kör sleep men man kan tex köra en a/d omvanling under sleep om jag minns rätt och man kodar rätt. Det är ganska mycket man ska ha grepp om för att det ska fungera optimalt. Ett måste är en känslig multimeter för att mäta är nästan ett måste. Jag minns inte 100 men jag testade SLEEP en gång för ett par år sedan och skillnaden mellan att ligga på lägsta interna klockan och SLEEP var rätt liten iaf i jämförelse med att klanta sig med externa komponenter.

SLEEP sover som sodjan sagt bara maximalt 2 sek sen måste det "aktiveras" igen. Nu vet jag inte hur långa dina blinkinpulser på mätaren är men sätter man en kort sleep kan man ju enkelt detektera pulserna oavsett.

[Icecap]

Sedan är en mycket viktig del själva sensorn som avkänner blinken, den ska vara ganska optimerat i riktning "drar låg ström" då den är på kontinuerligt.

Självklart går den att köra med PWM men det kräver att PIC'en inte sover.

I mina ögon är detta ett projekt där strömbudget inte är utfört, det fokuseras för mycket på fel del och besparingen blir minimal, helt enligt den gamla 20%/80% - regeln. (20% jobb på rätt grej ger 80% vinst medan 80% jobb på fel grej ger 20% vinst).

Och sedan är effektförbrukning inte det samma som strömförbrukning! En grej som drar lite men är på jämt kan enkelt förbruka mer än en grej som drar en del men som är på sällan och då bara i kort tid.

[sodjan]

> SLEEP sover som sodjan sagt bara maximalt 2 sek...

Nej, det har jag inte sagt. Jag har sagt att den maximala timeout-tiden
for *watchdog* timern är ca 2 sek. Det finns ingen begränsning i hur länge
processorn kan ligga i sleep i sig.

Det jag skulle kolla också (om man nu ändå vill utreda sleep "i botten") är
om någon annan del av processorn (t.ex en timer som "counter") kan fungera
även under sleep. Eller att sätta en extern 4xxx CMOS binär-räknare som sköter
räkningen mellan sändningarna. Eller, som sagt, helt enkelt bara dra fram
matningsspänning...

Ser nu också att Icecap har sammafattat det hela bra medans jag skrev...

[TomasL]

Timer1 fungerar och ger INT om den klockas externt.
Vilket jag tycker vore det optimala, om man inte behöver tidsstämpling för varje puls.
Det är ju bara att skriva lämpligt värde till timern, gå i koma, och vänta tills timern rullar över och väcker processorn.

Dessutom finns det ju färdiga kretsar som tidsloggar, med inbyggd RTC, händelser (dessutom är de extremt strömsnåla), vilka man sedan kan läsa av.

[ToPNoTCH]

Känns som en förutsättning för att kunna hjälpa till med tips på att få ner strömförbrukningen, är att vi får se hela kretsen och hur du gjort/tänkt.

Exempelvis:
Jämfört en PIC 16F886 (här generaliserar jag lite och förutsätter att man inte har andra kopplingar) i 20MHz på 5V drar en XBEE Pro
~52 ggr mer i sändande läge
~11.5 ggr mer i vänteläge
~ 96 ggr mindre i sleepläge
Mosvarande beräkning med samma förutsättningar men med PIC'en i 4 MHz
~178 ggr mer i sändande läge
~39 ggr mer i vänteläge
~ 30 ggr mindre i sleepläge

Kliver du ner på 3.3V (XBEE vill väl ha 3.3V har jag för mig) på processorn blir sifrorna ännu mer talande.

Vad sensorn drar kan vi ju bara gissa.

Min slutsats är altså därför lägg fokus på tiden som XBEE inte är i sleepläge, det är där du gör vinsterna.

Det finns ju massor med knep för att hålla låg förbrukning i PIC (Själv växlande R/C klocka så du kör långsamt när du mäter och speedar när du skall prata XBEE etc. etc.) , men det är meninglöst att spekulera i dessa utan att se kopplingen och optimerar perferi prylarna först.

Den tidigare nämnda 80-20 regeln verkar definitivt gälla detta case (eller kanske 98-2 regeln snarare )