Svenska ElektronikForumet

Hej hej,

Sitter här med en PIC18F25K22 och klurar lite på hur jag ska räkna på Timer1 för att få overflowflaggan vid den frekvens jag önskar - ca 100 Hz.
IDE:t är mikroC PRO for PIC.

Tänker jag rätt så här?:

• - Om systemklockan sätts till 16 MHz men PLL aktiverat blir systemklockan 64 MHz. (Anledningen till den höga frekvensen är pga andra applikationer är i behov av detta)
  - Genom att välja att Timer1 ska följa instruktionsklockan istället för systemklockan så hamnar vi på 12 Mhz, dvs 64 MHz / 4.
  - Med en prescaler med förhållandet 1:2 så är vi nere på 6 MHz.
  - Då jag kan välja om Timer1 ska vara 8 eller 16 bitar så väljer jag 16 bitar. Detta leder till 6 Mhz / 65535 = 91,5 Hz

Är det så här man räknar? Lite osäker på just det där med 8 eller 16 bitars-timer.

Har fler frågor men det är nog bättre att reda ut en sak i taget.

Det du beskriver verkar vettigt. Om det också
går att göra just så vet jag inte utan att (också)
läsa databladet...

Det är alltså inte så kritiskt vilken tid det blir.
90 eller 100 Hz spelar ingen större roll...

Låter lovande. Fick inte till urklippen från databladet men det räcker för stunden att jag tänkt rätt med valet av antal bitar på timern.

Just det, frekvensen är inte så kritisk. Den ska bara användas till en knappavstuds (eller vad det kallas), så 90 Hz kommer gå bra.

Sist jag kollade var 64/4=16. Men det kanske inte gäller längre.

Hehe, vet inte vilken räknare du använder men ok då, kan likaväl räkna på ditt sätt

Skämt åsido, återkommer med lite kod och annat. Som det är nu mäter jag interruptet till 500 kHz men förväntar mig lite över 120 Hz, ditt sätt räknat...

Och jag har testat en hel del, just med knappar.

Helt utan debounce räcker det att polla knappsatsen med 10 Hz, det fångar alla. Jag har testat att påverka brytaren så kort som möjligt med det blir alltid fångad vid 10 Hz.

Men jag vill oftast ha en säkerhet mot störningar varför jag gör avläsningar dubbelt så ofta och bara när en ny avläsning är identisk med den förre accepteras avläsningen.

Detta betyder att jag kör med 20 Hz som lägsta frekvens. Sen kan man ju ha andra saker som ska hänga med i den interrupt varför man kan höja frekvensen men det är en annan sak.

100 Hz för att bara kolla knappar är spill av resurser, 25 Hz räcker långt.

Avstudsning brukar jag göra med ett "skiftregister" som uppdateras med lagom frekvens. Om värdet (8 bit) är 0x00 sätter jag värdet på variabeln till 0, om värdet är 0xff sätter jag värdet till 1. Fungerar perfekt. Det enda man behöver tänka på är att 8 sample tar längre tid än kontaktstudsarna.

@Icecap:
Ska prova lite olika. Det finns mycket matnyttigt att läsa bland EF:s trådar. Tänkte testa lite olika och i mitt fall kommer inte resurser vara något problem då µC:n kommer vara väldigt överdimensionerad. Å andra sidan är det aldrig fel att tänka effektivt ändå.

@lillahuset:
Det här var också intressant! Du skiftar alltså in portstatusen (på vald ingång) i en byte med lagom intervall. Har du då bara en if (skiftregister == 0xff) { Button_Status = 1; } som körs vid varje skiftning?
Ursäkta den låga nivån men jag vet tyvärr inte bättre. Korvspadet är grumligt.

Mycket bra tips och det som jag tänkte prova först var en variant som Swech tipsade om i en annan tråd där man helt enkelt räknar upp/ner beroende på portstatus. När man nått önskat värde så är knappen tryckt.
Vi får se vart det slutar men jag tyckte verkligen lillahuset metod var enkel.

Nåja, inget av detta är värt att prata om så länge man inte kan hantera interrupts.
Nedan är den lilla kodsnutt jag provat med nu och när jag mäter med skopet på RC4:an så kommer pulserna med ganska exakt 30 Hz, vilket inte stämmer alls med uträkningen.

Vet inte hur jag ska göra för att verkligen bekräfta att systemklockan går i 64 MHz...

@lillahuset:
Det här var också intressant! Du skiftar alltså in portstatusen (på vald ingång) i en byte med lagom intervall. Har du då bara en if (skiftregister == 0xff) { Button_Status = 1; } som körs vid varje skiftning?
Ursäkta den låga nivån men jag vet tyvärr inte bättre. Korvspadet är grumligt.

Korvspad som inte är grumligt tyder på dålig korv.
Jo du har fattat rätt, men du ska lägga till en test på 0x00 också. Om det är en blandning av ettor och nollor avvaktar man.

Edit: Ett bra sätt att verifiera en klockfrekvens är att "vifta" med en pinne och se om man får förväntad period. Det har avslöjat många klantigheter i min karriär, både egna och framförallt andras.

Ja just det. Kanon, det ska jag testa!

EDIT: Jag viftar på. Tror jag är det på spåret. Återkommer!

Jag har inte förstått varför man behöver kolla portstatus ett förutbestämt antal gånger. Visst, det kan vara bra om man inte har en aning om hur lång knappstudsen kommer att kunna vara, men man kan väl anta att den oftast är under 10ms, och att den inte varierar så mycket på samma knapp från ett knapptryck till ett annat?

Om det är <10ms, och om man har en signal som är normalt låg. Kan man inte göra så här då,
1. ställa in så att man triggar på positiv flank
2. Vid positiv flank, Vänta 10ms
3. Läs portstatus
4. Är den fortfarande är hög -> Knappen intryckt.

Eller missar jag något? Algoritmen ovan har jag använt utan problem på Reed-switch och mikrobrytare.

Flanker är ofta förrädiska. Ofta bättre att titta på nivåer.

Men på vilket sätt är flankerna förrädiska?

Tänk att man har en ingång med pull-down-motstånd som du ska lyssna på efter en knapptryckning. Mellan ingången och Vdd har man en knapp med 2-5ms knappstuds.
Varför skulle min algoritm ovan inte fungera? Jag menar, kommer det en flank, så sker ett interrupt. Om signalen ff är hög efter 10ms så är det ju en knapptryckning.
Eller menar du att t.ex. en PIC kan missa en flank? eller kan en flank detekteras utan att knappen trycks ner även med en pull-down?

Eftersom jag inte sett så många exempel på min alogritm på övriga nätet så gissar jag att den inte är helt vattentät , men jag vill gärna veta varför.
En dålig sak som jag kan komma på direkt är att det är ganska fult med en delay inne i en interruptrutin. Men om man tittar på funktionen så borde den väl var OK?

Har funderat lite ecenier och frågan är om inte detta också är en väldigt bra metod.
Det man skulle kunna göra är ju att faktiskt nyttja Interrupt on change på den porten och går den hög så använder man inte en delay utan istället använder sig av antingen en redan rullande timer eller en dedikerad "debounce"-timer och justerar dess intervall på 10ms, eller vad man vill ha.
På så sätt borde processorn kunna jobba fritt medans väntetiden tickar på.
Nej jag vet inte bättre än att lyssna på er men oavsett, avstudsningen ser jag inte som ett direkt stort problem. Just nu är det att få systemklockan att snurra som jag vill.

Vad jag nyss upptäckte var att oavsett om jag aktiverade/deaktiverade 4 x PLL så sker interruptet ändå med ~30 Hz.
Om jag, med detta, förutsätter att 4 x PLL -funktionen inte fungerar så snurrar bara klockan med 16 MHz och detta gör att allt stämmer.
Dvs:
- Systemklocka 16 MHz
- Instruktionsklocka 4 MHz
- 1:2 prescaler på Timer1 = 2 MHz
- 16 bitars Timer1 = 2'000'000 / 65535 = 30,5 Hz

Jahopp, nu blir det till att reda ut vart det går fel med 4 x PLL

Jahopp, nu blir det till att reda ut vart det går fel med 4 x PLL

Hur gör du för att slå på PLLen?