Post by thread:[PIC]: To poll or not to poll: that is the questio

Hi, PIClanders! (or pic Highlanders! :-) Are there any ideas, what technique is better: polling or interrupt driven? I have a PC with attached to it PIC-based hardware by RS232. It contains a dozen of buttons, the same quantity of lamps and a couple of simple devices to be switched on or off. So I have 3 loops where I have to choose polling or interrupt driven technique. 1. Between input/output hardware and PIC. 2. Between PIC and Com Port 3. Software loop between Com Port driver and Application software. (ActiveX, incapsulating protocol between PIC and Com Port, showing to Application app-specific methods and properties) Apparently, application - men would refuse polling from their side. they would prefer to have Sub (MS VB) in their project (method), to be lunched when needed by my ActiveX. OK, I'll do it by callbacks. From the other end: Why not force this PIC loop 20 times per second reading buttons, and then sending to PC a series of bytes from this loop. During this loop it may check incoming bytes, if any, and switch lamps. In the middle, my ActiveX is to perfome half-passive role, continiuosly receiving bytes from PIC, starting Sub in app software, if needed, And sending bytes to PIC, when app software wants it. ------------------------------------ In this context, it seems to be interesting the idea of software debouncing even with SPST switch (Jinx are you on-line?). Let associate with buttons a register, to store button's states. Then let PIC set bits of the register only to "1" when button is pressed, Then let application software set bits of the register only to "0". ------------------------------------ Have anybody any considerations to the topic? Is there any common or standard approach in developing architecture of peripherals, controled remotely by PC through RS232, protocols, software design in common and so on. Any references to serous docs, please, if possible. I think, it may be interesting to many PICList members. Mike. Ukraine. -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

> debouncing even with SPST switch (Jinx are you on-line?) Yes, I are > It contains a dozen of buttons, the same quantity of lamps > and a couple of simple devices to be switched on or off Aaaahhh. An activity centre, how cute. I'm sure it will keep you amused for absolutely hours > So I have 3 loops where I have to choose polling or interrupt > driven technique. It's hard to generalise. It depends on what resources you have and how much spare time they have. For example, I'm working on something that has RS232 as the first priority (as I can't re- request the data). Everything else has to fit in around that. It could get messy breaking out of a serial routine to service an interrupt from a not-very-important event that could have waited. Event occurrences can be held in flags without causing an interrupt, and can be polled at will. You could also store external transients in a simple sample-hold using R D & C Don't know if this is possible with your set-up, but I've used parallel-serial registers to store pushbutton presses and toggle switche changes. Kind of like scanning a keyboard matrix but you do it with serial data Break it down in terms of worst-case timing. What could you miss, how could you fix that, etc etc -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu