Flankdetectie 16F886

In plaats van delays kun je ook periodiek pollen, zolang de puls minstens zo lang is als de polling interval mis je nooit een puls.

Het nadeel van een pin change interrupt is dat die je processor kan ophangen als er een hoge frequentie op de pin komt.

Wat je ook kunt doen, is de pulsen tellen met een hardware timer/counter, en periodiek kijken of de count veranderd is. Je kunt dan niet triviaal de pulslengte bepalen.

De interrupts zijn niet re-entrant, dus 'vastlopen' kan niet. (je mist dan gewoon interrupts)

De processor heeft vele mogelijkheden om pulsen te tellen en die zijn bijna allemaal beter als delayloops. Er zijn o.a.:

- IOC (interrupt on change)
- INTE (external interrupt)
- TMRx (pollen met timer interrupt)
- CCP (capture compare interrupt)

Ik zou trouwens een nieuwere (pin-compatible) vervanger nemen als de PIC16F1778. Goedkoper en een stuk efficienter. (enhanced 16F processor)

Op zaterdag 3 januari 2026 21:20:14 schreef deKees:
Het zorgt er wel voor dat de kans dat het fout gaat kleiner wordt, dus dan gaat het ´tamelijk vaak´ goed. Maar dus niet altijd.

Nee, zelfs dat niet. Het duurt alleen heel erg lang. :-) !

Op dinsdag 6 januari 2026 10:11:07 schreef Arco:
De interrupts zijn niet re-entrant, dus 'vastlopen' kan niet. (je mist dan gewoon interrupts)

Wat sparky bedoelt is dat als je interrupts vaak genoeg komen er geen tijd is voor "main". Je programma hangt. Ik dacht dat ik gezien had dat in de AVR er altijd minstens 1 instructie van "main" uitgevoerd zou worden. Dat helpt nauwelijks: ze ziet de boel gewoon echt "bevriezen", en dat er nog heel langzaam iets wordt uitgevoerd helpt niet.

Nog even over "kans dat het fout gaat"... Met die delay: de kans blijft bij iedere keer door de "if/update" code gelijk. Het enige is dat je per seconde minder vaak door die code gaat. Dus per 1Hz puls gaat de kans toch wel omlaag, maar per keer dat je door de code loopt niet.

Nog even over "altijd zo nu en dan". DeKees heeft het goed uitgelegd: Je krijgt ALTIJD code die het in de eerste instantie lijkt te doen, maar bij nader inzien toch "zo nu en dan" niet.

Je moet het patroon herkennen. Of het nu een hardware pin of een variabele die in de interrupt opgehoogd wordt... Altijd een copie maken van de huidige waarde, die vergelijken met de oude waarde en als dat triggert, dan zet je de oude waarde op de KOPIE en niet de HUIDIGE waarde op moment dat je de actie gedaan hebt. De "oude waarde" is dan altijd gelijk aan waar je programma op gereageerd heeft.

Mijn huidige project, dan krijg ik via interrupts nieuwe waardes door. En een main routine kijkt (hopelijk vaak genoeg) of er veranderingen zijn en stuurt die door als dat nodig is. Dat werkt dus ook op deze manier om te voorkomen dat terwijl ik al besloten heb de boel te updaten er NOG een update komt. Als ik dan "de laatste" waarde in mijn "oude waardes" tabel zou zetten, dan krijgt mijn slave dus nooit meer een update.

Voorbeeld: stel de waarde gaat van 0 naar 5, naar 10. Als ik dan zie: 5 != 0, dan de update "5" doorstuur, en ondertussen is ie tien geworden. Als ik dan de oudewaarde update met "10", dan stuur ik dus zolang ie 10 is nooit meer een update en blijft de slave op 5 staan.

[Bericht gewijzigd door rew op (78%)]