PIC18F25K22 - Timer, Nested interrupts och annat

[lillahuset]

Flanker är känsligare för störningar än nivåer. Tittar du bara på nivåer i tex en interruptrutin som sköter "klockan" i systemet så minskar du bekymren.

[Magnus_K]

@TomasL:
Sitter just nu och provar allt möjligt i ren desperation.
Vanligtvis (utan att verkligen verifiera om det fungerat) så har jag gjort det i IDE:s konfigurationsfönster. Se bild nedan.
När jag här väljer PLL enable/disable så ser man i fönstret (th) att CONFIG1H ändrar sig.

Förutsatte att detta var knas så tänkte att den är nu inställd till att slås på rent mjukvarumässigt så testade med OSCTUNE.PLLEN = 1;, dock utan framgång.

Ibland kan jag lägga ifrån mig datorn och undra vad jag egentligen håller på med. Här sitter man och tragglar i kanske 3 timmar, en lördagkväll. 3 timmar för att få till en systemklocka på en plastbit med lite kisel i.
Man kan bara borde hitta på något annat? Lära sig spela ett instrument?

PLL_enable.JPG

[TomasL]

Om du studerar databladet, kommer du fram till att PLL för den interna oscillatorn måste sättas i mjukvaran, sätta den i fuses funkar inte:

2.8.2 PLL IN HFINTOSC MODES
The 4x frequency multiplier can be used with the
internal oscillator block to produce faster device clock
speeds than are normally possible with the internal
oscillator. When enabled, the PLL multiplies the
HFINTOSC by four to produce clock rates up to
64 MHz.
Unlike external clock modes, when internal clock
modes are enabled, the PLL can only be controlled
through software. The PLLEN control bit of the
OSCTUNE register is used to enable or disable the
PLL operation when the HFINTOSC is used.
The PLL is designed for input frequencies of 4 MHz up
to 16 MHz.

[Magnus_K]

Jo precis, hittade detta också och därför lade till OSCTUNE.PLLEN = 1; som jag skrev ovan. Tyvärr blev det ingen skillnad utan interruptet tickade fortfarande på i 30,5 Hz.
Säg att jag glömt något...

[TomasL]

Har du testat i MPLAB?
Kan ju vara MicroC som hittar på nått.

Dessutom använd ALDRIG sådana där konfigureringsverktyg.
Skriv konfigen i koden i stället.
Det blir bara fel.

[Magnus_K]

Nja, har kikat lite på det men i ärlighetens namn så behöver jag MicroC. Det finns så många bra bibliotek och guider på nätet vilket är otroligt viktigt för någon som mig, som inte har någon tidigare utbildning eller har tid att sitta med det här mer än några timmar i månaden.
Ska lösa det här. Kan ha hittat något spännande. Återkommer.

[TomasL]

du har nog 100 gånger mer info mm med MPLAB, jämfört med MicroC, skulle jag tro.
Frågan är ju vilka bibliotek du saknar i MPLAB?

[Magnus_K]

Jag vet inte TomasL. Det enda jag vet är att jag sitter så sällan med det här så MikroC och Arduino räcker många gånger till det jag gör. Skulle jag någonsin får ro till att byta miljö så kommer absolut MPLAB en av de första jag kikar närmare på (om jag håller på med PIC vill säga).
Det är lite samma med vilken µC jag använder mig av. Då jag börjat lära mig beteckningar, databladens struktur och språket kring PIC så håller jag mig till det. Jag har helt enkelt för lite tid för att bry mig om andra µC:s. Det Microchip har att erbjuda räcker för mig. Detta i kombination med Arduinons otroliga "community" och förenklade miljö blir en fin blandning av det bästa, för mig.

Nog om det. Problemet löst.

Man var tvungen att i OSCCON-registret sätta klockkälla till 00 = Primary clock (determined by FOSC<3:0> in CONFIG1H). Jag hade valt 1x = Internal oscillator block, vilket kändes logiskt för mig men då används tydligen inte PLL:en.
Nu kommer interrupten med en frekvens av 122 Hz. Tur ingen såg mig när den frekvensen dök upp på skopet....

[TomasL]

Ehh, fick du O.... eller??

[Magnus_K]

[Icecap]

ecenier: att läsa knappar, sedan vänta 10ms och läsa igen o jämföra fungerar helt klart.

Men man kastar bort 10ms (vänttiden) i onödan och med en µC som kör 16.000.000 instruktioner/sek är det 160.000instruktioner som kastas bort i onödan. Det är dock ett ganska vanligt sätt för personer som inte klarar att använda interrupt.

Kollar man sedan knappar 10 gg/sek går 10% av CPU-kraften till att vänta och det känns knappast vettigt eller hur?

Men tar man en interrupt på (ung.) 100 Hz är det 10ms mellan varje interrupt. Så läser man knapp-porten och sparar i ett register kan man jämföra med förra sparade värde och få exakt samma funktion - med det undantag att µC'n faktisk använder långt störstaparten av de annars bortkastade 160.000 instruktioner till verkligt arbete.

Knapp-avkänningen med debounce och allt kommer då att förbruka kanske 0,0156% av CPU-kraften vid 25 interrupts/sek och en rimlig snabb ISR på 100 instruktioner, alltså en skillnad på 640 gg.

Och har man gjort det en gång är det hur enkelt som helst. Sedan är det rimligt vanligt (i min värld iaf.) att man har en basal timer-interrupt för att sätta delay och liknande och då använder jag nästan alltid den samma till knapp-avkänning.

Men vänta, jag skriver om delay fastän jag just avråder från dom! Varför då?
Jo, ibland ska vissa funktioner ha lov att starta något, få svar eller annat. Och många sätter hela programmet till att stanna av och vänta på att detta händer.

Men vad nu om man är lite smart?
Jag utgår ifrån att det finns en timer-interrupt med en hastighet på TIMER_SPEED per sekund.
det finns en variabel ("volatile unsigned short Delay_Counter_1") som behandlas som följer i samma ISR:
if(Delay_Counter_1) Delay_Counter_1--;

Faktisk ska alla efterföljande Delay_Counter_x man använder behandlas på liknande sätt.

Självklart kan variabels storlek anpassas till vad man gör, en BYTE i en 8-bit µC där man inte behöver vänta längre tid än den kan hålla vill vara en fördel osv.

I main-loop kan man sedan ha:

Kod: Markera allt

while(true)
  {
  if(NåntingSkaSke)
    {
    if(!Nånting) Delay_Counter_1 = TIMER_SPEED / 2; // Max. 0,5 sek väntande och bara om Nånting inte är aktiv
    Nånting = true; // Slå på Nånting men först EFTER raden ovan!
    if(Delay_Counter_1 && Nånting)
      {
      if(Nånting_Kör) // OK, Nånting har startat
        {
        // Gör vad som ska göras när Nånting kör
        NåntingSkaSke = false; // OK, klart med det, nolla flaggan
        }
      }
    else
      {
      // Hoppla, time-out, felhantering, t.ex:
      Nånting = false; // Hann inte starta, stäng av
      NåntingSkaSke = false; // Jahopp, det gick ju inte, så det så!
      }
    }
  // Här kör resten av main-loop vidare oavsett status på Nånting och timeout osv.
  }

Självklart kan man ha fler Delay_Counter_x och använda dom på olika sätt.

Om man t.ex. ska aktivera/utlösa en funktion i main-loop varje sekund (eller annat intervall) utan att spilla tid på den annars:

Kod: Markera allt

if(!Delay_Counter_x) // Sann om Delay_Counter_x är noll
  {
  Delay_Counter_x = TIMER_SPEED; // Ladda om tidräknaren
  // Här ska funktionen utföras.
  }

OBS: Timingen är inte exakt!!! Den varierar mellan Inställd värde och inställd värde - 1. Om main-loop tar längre tid än 1 timer-tick kommer den tid att läggas till!

Men till "småsaker" duger det alldeles utmärkt och undviker man helt och totalt de "gammaldags" Delay() brukar det gå tämligen bra om man inte klantar sig i programmeringen, en rundtur i main-loop ska nämligen inte ta så värst lång tid ändå.

[sodjan]

> Man var tvungen att i OSCCON-registret sätta klockkälla till 00 = Primary clock (determined
> by FOSC<3:0> in CONFIG1H). Jag hade valt 1x = Internal oscillator block, vilket kändes
> logiskt för mig men då används tydligen inte PLL:en.

Om man kollar med oscillator schemat på sidan 28 "FIGURE 2-1: SIMPLIFIED OSCILLATOR
SYSTEM BLOCK DIAGRAM", så framgår det att "4xPLL", den lilla rutan i mitten, enbart
ligger i flödet för "Primary Clock". Väljer man "INTOSC" så går signalen aldrig
igenom 4xPLL modulen.

Men visst, det är många bitar som måste falla på plats...

[Magnus_K]

Ja jäklar. Så blir det ja. När jag valde 1x så gick signalen direkt till MUX:en.

Dom där blockdiagrammen är väldigt bra men måste träna mer på att läsa dom.

Ikväll ska jag gå vidare med "nested interrupts" vilket är något jag aldrig testat innan. Tror nog ni vet vad det innebär... Återkommer...

[sodjan]

För mig låter det som när man accepterar nya interrupt medan man
ligger kvar i ISR'en. Är det det du menar? Inte speciellt enkelt och
deet är nog bara i väldigt speciella fall som det krävs/behövs.

Eller så menar du något helt annat...

[lillahuset]

Nästade interrupt är ofta praktiskt men kan ställa till det ordentligt.