knoppen uitlezen met microcontroller

en interrupts zouden de timing gaan verstoren.

Een goede interrupt werkt zonder verstoring van de rest.

Waarom zou pollen de timing zo verstoren?
8 ingangen uitlezen is nu toch zoveel werk niet voor een microcontroller.

MCP23017 is een 16bit I2c IO expander, met latches, interrupts, microchip. heeft volgens mij ook een kleiner broertje, 8bit.

of MAX7310 (8bit)
philips: PCF8574A (8bit)

Op 26 september 2006 00:07:44 schreef steenaap:
Nu is het zo dat de code in de microcontroller nogal timing gevoelig is. Pollen is dus onmogelijk en interrupts zouden de timing gaan verstoren.

Nu vroeg ik me af of er componentjes bestaan met bv acht latches en seriele uitlezing. Indien een knop ingedrukt wordt de latch geset. Met een vaste frequentie zou ik dan de latches serieel kunnen uitlezen en nadien resetten.

Ik ben lost. Je project is zo timing gevoelig dat je niet de knoppen kan pollen, maar wel een serieel chipje kan pollen? Vertel eens wat meer over dat project.

Overigens bestaan die chipjes wel, ze worden oa door Microchip en Atmel gemaakt en je moet ze nog wel zelf van de juiste firmware voorzien...

Op 26 september 2006 00:19:59 schreef Henry S.:
Een goede interrupt werkt zonder verstoring van de rest.

Als je op de voorgrond iets moet doen dat echt naukeurige timing vereist (software UART, Dallas one-wire, video, hobby servo aansturing, etc) dan kan een interrupt behoorlijk verstorend werken.

[Bericht gewijzigd door Wouter van Ooijen op dinsdag 26 september 2006 07:54:38 ]

met 8 diodes een OF poort maken en daar een INT ingang aansturen (met eventueel een lagere prioriteit)

Op 26 september 2006 00:07:44 schreef steenaap:
Nu is het zo dat de code in de microcontroller nogal timing gevoelig is. Pollen is dus onmogelijk en interrupts zouden de timing gaan verstoren.

Ik draai de handel vaak om: Doe de timing gevoelige zaken in een interrupt en de ongevoelige zaken in de hoofdloop. De ongevoelige zaken worden dan onderbroken (maar dat is niet belangrijk) en de timing dingen (zoals een DDS) lopen via een hardware timer.

[Bericht gewijzigd door JoWi op dinsdag 26 september 2006 09:18:21 ]

Herbekijk je code eens goed, die paar instructie's om knopjes in te lezen kunnen er toch bij. Een delay routine bijvoorbeeld, daarvoor gebruik je de (goed uitgerekende) knopjesverwerking, zodat hij evenlang bezig is met de knopjes verwerken (en evt wat extra NOP's) als hij voorheen aan het delayen was.
En wees gerust, een mens kan niet in een µs een knopje indrukken en weer loslaten, dus zo extreem snel moet je de knopjes niet uitlezen.

Timing gevoelige zaken doe je op een Timer interrupt. In een main loop handel je de zaken af zoals knoppen, en timing ongevoelige IO (zoals status ledje, display updaten).

Op 26 september 2006 07:51:57 schreef Wouter van Ooijen:
[...]
Als je op de voorgrond iets moet doen dat echt naukeurige timing vereist (software UART, Dallas one-wire, video, hobby servo aansturing, etc) dan kan een interrupt behoorlijk verstorend werken.

Zie de posts van JoWi en Lexy:

Op 26 september 2006 09:16:29 schreef JoWi:
[...]Ik draai de handel vaak om: Doe de timing gevoelige zaken in een interrupt en de ongevoelige zaken in de hoofdloop. De ongevoelige zaken worden dan onderbroken (maar dat is niet belangrijk) en de timing dingen (zoals een DDS) lopen via een hardware timer.

Op 26 september 2006 09:57:46 schreef Lexy:
Timing gevoelige zaken doe je op een Timer interrupt. In een main loop handel je de zaken af zoals knoppen, en timing ongevoelige IO (zoals status ledje, display updaten).

Zo zit het elkaar niet in de weg, behalve als de interrupt routines te lang duren.

Op 26 september 2006 10:36:42 schreef Henry S.:
Zie de posts van JoWi en Lexy:

Dat kan een optie zijn, maar het geeft weer zijn eigen problemen. In een interrupt moet je dan af en toe de interrupt verlaten, en dan ben je je 'call context' kwijt (maw: dat kan alleen op 1 vaste plek in wat anders de hoofdlus was). Niet alle programmas hebben een struktuur die zich hier voor leent.

Op 26 september 2006 10:46:45 schreef Wouter van Ooijen:
[...]
Dat kan een optie zijn, maar het geeft weer zijn eigen problemen. In een interrupt moet je dan af en toe de interrupt verlaten, en dan ben je je 'call context' kwijt (maw: dat kan alleen op 1 vaste plek in wat anders de hoofdlus was). Niet alle programmas hebben een struktuur die zich hier voor leent.

Je moet zo snel mogelijk uit de interrupt routine als maar mogelijk is. Onder andere om de latency kort te houden. Als je iets langdradigs wil doen wat getriggerd wordt door een interrupt doe je het noodzakelijke (b.v. karakters in een ringbuffer stoppen) en zet je een event vlag. In je hoofdprogramma gebruik je een scheduler die de events afloopt.

Op 26 september 2006 11:20:38 schreef JoWi:
Je moet zo snel mogelijk uit de interrupt routine als maar mogelijk is.

Ja, dat is ook een algemene regel. Die werken prima in de algemene (makkelijke) gevallen. Maar ik reageerde om iemand die het andere criterium gebruikte: tijdgevoelige zaken moeten in de interrupt. Wat nu als tijdgevoelige zaken 95% van de tijd in beslag nemen? Denk bv aan het genereren van video.

Op 26 september 2006 11:40:35 schreef Wouter van Ooijen:
[...]

Ja, dat is ook een algemene regel. Die werken prima in de algemene (makkelijke) gevallen. Maar ik reageerde om iemand die het andere criterium gebruikte: tijdgevoelige zaken moeten in de interrupt. Wat nu als tijdgevoelige zaken 95% van de tijd in beslag nemen? Denk bv aan het genereren van video.

Da's simpel, je laat de syncpulsen door een interrupt genereren, da's elke 64 uS, zo'n puls duurt 4,7uS, dus heb je ca. 60 uS over, in die tijd moet je heel wat kunnen doen.
D'r zijn lijnen die geen beeldinhoud behoeven, omdat ze niet afgebeeld worden, dan kun je dus allerhande zaken doen als knopjes pollen, uarts in en uitlezen etc. en het neiuwe plaatje berekenen. Tegen de tijd dat je zichtbare video gaat genereren heb je de cpu 100% nodig om je video-inhoud te berekenen. (bij 32 MIPS kun je 8 MHz pixelfrequentie halen. (je hebt meestal 4 instructies per pixel nodig)

Op 26 september 2006 16:53:23 schreef DC2PCC:
Tegen de tijd dat je zichtbare video gaat genereren heb je de cpu 100% nodig om je video-inhoud te berekenen.

ja, en in jouw aanpak is dat dus in de interrupt.

laat verder maar, dit gaat wel erg veel van de OP vraag weg.

[Bericht gewijzigd door Wouter van Ooijen op dinsdag 26 september 2006 17:13:05 ]

Op 26 september 2006 11:40:35 schreef Wouter van Ooijen:
[...]

Ja, dat is ook een algemene regel. Die werken prima in de algemene (makkelijke) gevallen. Maar ik reageerde om iemand die het andere criterium gebruikte: tijdgevoelige zaken moeten in de interrupt. Wat nu als tijdgevoelige zaken 95% van de tijd in beslag nemen? Denk bv aan het genereren van video.

daarvoor bestaat tegenwoordig HARDWARE.

je kan ook een multilevel interrupt systeem gebruiken. meerdere processen die elk op interrupt draaien (of zelfs timers , das ook een vorm van interrupt) . door middel van interrupt priority kan je dan schedulen.

ik gebruik vaak het volgende mechanisme :
de hoofdlus doet niets anders dan i/o. das het hoofdprogramama (zoals jowi en lexy)
dat scan keyboard , updated display en dergelijke.
rs232 is interrupt driven en maakt gebruik van een circular buffer. ditto voor usb ( via ftdi245 gememorymaped ) die hang ik op een extenre interrupt

het enige wat in die interrupt handler zit is het setten van een vlag. 'der is iets op usb binnegekomen'
ditto voor rs232 ' der is iets op rs232'
ditto voor keyboard.

die vlaggen zitten in een byte of word.
de interrupt handlers zijn dus extreem kort ( 1 of 2 lijnen assembler )

de hoofdlus kijkt naar de vlaggen.
is het flag byte nul dan is er niks te doen en slaapt de hoofdlus ( jumpt naar zichzelf en test opnieuw )

is byte niet nul : verwerk

het echte programma ( het stuk wat 'realtime' moet draaien ) hangt aan een timer vast die op highest priority draait. dat ding draait bij mij zelfs in een andere bank. ( kwestie van niet telkens de boel te moeten pushen en poppen naar de stack. )

voor meerdere van dergelijke processing assigneer ik voor elk een bank apart ( ik heb er 4 dus ik kan in princiepe 4 tasks lopen in parallel zonder penalty door gemodder op de stack )

Op 26 september 2006 17:11:06 schreef free_electron:daarvoor bestaat tegenwoordig HARDWARE.

ja, en? er bestaat ook UART hardware, is het dan verboden dat in software te doen?

Natuurlijk kun je sommige dingen makkelijker doen met geschikte hardware modules op je MCU. Ook kun je met een krachtige MCU makkelijker meerdere dingen tegelijk doen.

Maar ik denk dat dat nu juist het probleem is. Ik vermoed dat dit een hobby projectje is van steenaap en hij gebruik maakt van een MCU die niet meer genoeg resources heeft of de juiste hardware modules om dit soort dingen (makkelijk) tegelijk te doen. Je kunt dan voor een andere MCU kiezen (maar waarschijnlijk heb je er nog een thuis die je wil gebruiken), of je plakt er wat extra externe hardware aan, of je past als het mogelijk is de software aan.

Er zijn in dit topic al een aantal mogelijke oplossingen aangedragen, maar ik denk dat zonder verdere informatie van steenaap hier geen zinnig antwoord op gegeven kan worden. Welk soort project is het? Wat voor software is het precies? Welke microcontroller word er gebruikt?

Op 26 september 2006 17:13:54 schreef Wouter van Ooijen:
[...]

ja, en? er bestaat ook UART hardware, is het dan verboden dat in software te doen?

neen verboden is het niet , maar tis onnozel. ( in mijn ogen dan ) allemaal werk voor niks. ( ik ben van nature lui , en zoals ik in een ander topic al schreef vandaag : een idee uitwerken op zich brengt al geneog problemen mee zonder dat je er dergelijke geintjes gaat in stoppen.
elke microcontrolelr die niet half braindead is heeft een uart aan boord

Op 26 september 2006 11:20:38 schreef JoWi:
[...]Je moet zo snel mogelijk uit de interrupt routine als maar mogelijk is. Onder andere om de latency kort te houden. Als je iets langdradigs wil doen wat getriggerd wordt door een interrupt doe je het noodzakelijke (b.v. karakters in een ringbuffer stoppen) en zet je een event vlag. In je hoofdprogramma gebruik je een scheduler die de events afloopt.

Die methode gebruikte ik al op m'n C64

Maar goed, ik weet (nog) niet hoe de tegenwoordige microcontrollers het doen, net m'n eerste PIC geflashed.

@Wouter: Ik snap je verder wel hoor, is zeker een dilemma, maar ik ben ook van menig dat je dergelijke taken beter door een tweede MCU/dsp/codec kan laten doen.

Maar goed, dat is een aparte discussie waard, de TS zal meer over zijn project moeten vertellen.
"Need more input"

[ot]
Je zending is vandaag in goede staat aangekomen, en de Wisp draait al met succes, bedankt voor de snelle afhandeling van m'n bestelling.
[/ot]