[PIC] interrupt snelheid

Ik ben nog altijd met mijn optische-encoder-project bezig.
Deze keer een vraag over de interrupt functie van een PIC.

In mijn software wordt een signaal binnengelezen dmv een interrupt op pin RB0 (on rising edge). Signaal een puls afkomstig van een optische encoder.
Encoder 1000 pulsen/toer.
max toerental gekoppelde as = 100toeren/min.
->100000pulsen/min
->max frequentie binnenkomend signaal =1666.66Hz

Hoe controleer ik nu als de interrupt snel genoeg werkt en geen puls overslaat.

Ik maak gebruik van: C-compiler, interne 4MHz osc

edit:
even de *.asm file opengeslagen.
In de ISR kom ik maximum 72 instruction cycles. Op 4Mhz (1µs/instruction cycle) kom je dan aan 72µs.
Terwijl de pulsen van de encoder een periode hebben van max 0.6ms.
Volgens goede vriend Nyquist moet ik dus minstens 2keer zo vlug kunnen samplen dus minstens om de 300µs.
Volgens mij moet dit dus lukken op de interne osc en moet ik geen vlugger kristal aansluiten.

Iemand die mijn redenering kan bevestigen? (of afkraken?)

[Bericht gewijzigd door pol op ]

Praktijktest's zijn IMHO de enige dingen die je zekerheid kunnen geven. Breid de interrupt-handler uit met wat nutteloze zaken: laat hem bv. aan het begin een pin hoog maken en aan het eind terug laag. Drijf de snelheid van de encoder nog wat op, als dit mogelijk is. Ga na of de pin die snelheid volgt. Als dat zo is, kan je gerust zijn.

Ik mis even wat je wilt samplen als iets interrupt-driven is...

Verder moet je natuurlijk buiten je ISR ook nog wat lucht over houden voor andere zaken. Als ik je voorbeeld zo zie, lukt dat wel. Let er wel op dat als je 'elders' eens interrupts uit zet (bewust of omdat je in een andere handler zit), dit niet 'te lang' mag duren. Hoe lang heb je zelf al berekend...

Ik ben het hardgrondig met pros oneens dat testen de enige manier is, tenzij je software heel erg 'basic' is en je alle situaties uit kunt proberen. Naar mijn idee is de enige '100%' methode uittellen zoals je reeds gedaan hebt.

Overigens... doet zo'n pic-ding echt maar 1mips op 4MHz??

Hangt van het type pic af.

Op 27 december 2006 20:51:39 schreef Marco69:
Ik mis even wat je wilt samplen als iets interrupt-driven is...

'Samplen' was inderdaad een wat verkeerde woordkeuze. Komt erop neer dat ik de 'maximum mogelijke herhalingsfrequentie van de interrupt' wou weten. (als dit een betere woordkeuze is :-p)

Overigens... doet zo'n pic-ding echt maar 1mips op 4MHz??

Ik gebruik voor dit project een simpele 16F627 en deze doet idd 1mips @4MHz. Ik gebruikte enkel nog maar de 8bit 16F serie van Microchip. Ik weet niet of dit ook geldt voor andere types.

Testen in de praktijk wordt wat moeilijk, de machines waarvoor de modules bedoeld zijn staan enkele kilometers hiervandaan. Ik kan wel een encoder simuleren met mijn functiegenerator...
Maar als men berekening van instructie cycles kloppen, dan zou het geheel moeten werken.

Op 27 december 2006 20:55:07 schreef Henry S.:
Hangt van het type pic af.

Dit is nieuw voor me... ik dacht dat alle PICtjes de Von Neuman cyclus afgingen?
noem es een handig typje die sneller is?
groet,
Michel

Op 28 december 2006 02:35:02 schreef Miezjel:
[...]
noem es een handig typje die sneller is?

De 18F252 bijvoorbeeld

En dan volgens mij alleen als je in de compiler aangeeft dat ie 4x sneller moet lopen.
Zo is het bij een 18F4320 wel tenminste, 20Mhz kristal eraan, fuse zetten 4x pll en dan kristal op 80Mhz instellen.
De rs232 communicatie werkte toen niet meer !

Jij durft, een 40MHz exemplaar op 80 MHz klokken.
Met overklokken hou ik meestal op bij een procent of 25 (Dus op 50 MHz) en dat gaat altijd goed maar ik zou het niet voor een "productieserie" doen. Hier ben je wel erg enthiousast bezig. Werd ie niet erg warm ?

Als ik alleen de fuse van 4x pll aanzet, en de declaratie van het kristal op 20Mhz laat staan dan klopt de timing van geen kant.
Nadat ik de declaratie van 20 naar 80Mhz heb verandert klopt de timing wel weer.
De pic werdt niet warm maar ik heb het ook niet echt lang getest omdat de serieele communicatie niets meer deed.

Op 28 december 2006 10:00:54 schreef diode:
Als ik alleen de fuse van 4x pll aanzet, en de declaratie van het kristal op 20Mhz laat staan dan klopt de timing van geen kant.
Nadat ik de declaratie van 20 naar 80Mhz heb verandert klopt de timing wel weer.
De pic werdt niet warm maar ik heb het ook niet echt lang getest omdat de serieele communicatie niets meer deed.

Maar je zit buiten de specs te werken, in het datasheet staat: max 40 MHz. Zo kan een 7805 misschien ook wel werken met 40Volt op de ingang, maar dat is niet wat de fabrikant garandeert. Hoogstwaarschijnlijk ging er nog wel meer mis in de pic (maar heb je dat niet getest).

Het kristal is 20Mhz, binnen de specs dus.
In de compiler heb ik aangegeven dat die op 80 Mhz draait, puur alleen om te zorgen dat het hele ding werkelijk 20 MIPS draait.
Misschien dat het "in het echt" anders hoort, als dat zo is dan hoor ik het graag.

Op 28 december 2006 10:15:00 schreef diode:
Het kristal is 20Mhz, binnen de specs dus.
In de compiler heb ik aangegeven dat die op 80 Mhz draait, puur alleen om te zorgen dat het hele ding werkelijk 20 MIPS draait.
Misschien dat het "in het echt" anders hoort, als dat zo is dan hoor ik het graag.

Datasheet lezen!!!!.
Je mag wel een 20 MHz kristal gebruiken, maar dan mag je de 4X PLL niet meer aanzetten.
Waarom denk je dat er 10 MIPS (Of 40 MHz) staat op de eerste bladzijde staat van dat datasheet. Als ie het dubbele aankon dan zou Microchip dat vast wel vertellen (goeie reclame)

Dan heb ik toch iets verkeerd begrepen, ik dacht namelijk dat die dingen 40 MIPS konden lopen!
Helaas, niet dus.
Dus alleen bij kristallen tot 10 Mhz mag je 4X pll gebruiken?