Thanks to Jinx and Adam.

   Your considerations helped me much in my project.

   I've decided on the mixed polling and interrupt driven technique:
   PIC6F874 continuously polls buttons and sends a set of bytes
to PC Com Port. Driver ActiveX (VB) continuously receives those
bytes, then on changes fires events (starts Subs) in Application
programm (VB) using callbacks by "callback interface" idea.
(Interrupt driven technique).
   ActiveX also has methods to allow  application programm send
bytes to PIC to switch on lamps. (You're right, Jinx: "Aaaahhh. An
activity centre, how cute.")

   Hardware for the project is assembled and tested already. (Based
on built-in programmer, I've posted earlier). Hard to believe it,
I programmed the device from MS Excel. Slightly slowly,
though, but quite comfortably. Adress incrementing is about 100
steps per second. "Loading", "Erase programming" and "Reading"
are slower. Later I'll shift to bootloading, anyway.

   Data to be programmed are cutted  from MASM output and pasted
into Excel worksheets. Each worksheet in cell(1,1) keeps an adress
 to start programming at. (Now I'm thinking about a light self-made
compiler: Why not refresh in mind all that stuff on app mathematics,
I was teached many years ago at Moscow). 35 instructions in 16 bits,
I've a feeling them could be programmed in "0" and "1" even without
compiler :-) (An amateur approach, I know.)

   Thanks again.
   Mike.
.
.
.
   Jinx wrote:

>> 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
.
.
.
   M. Adam Davis wrote:

>>   Hi, PIClanders! (or pic Highlanders! :-)
>>
>>   Are there any ideas, what technique is better: polling or interrupt
>>driven?
>>
>
>Quite a few, actually.  Take the Piclist mailing list as an example.  It
>is interrupt driven in so many ways - the obvious being that it only
>sends out mail when a new message arrives (at a most basic level).  It
>doesn't send each member a message every hour saying, "So, have anything
>you want to ask or answer on the list?"
>
>Less obvious is the administrative system.  For the most part someone
>bugs an admin and an admin responds.  Occasionally they poll us to see
>what we want, but they are so busy servicing interrupts that they have
>little time for polling.
>
>More obvious is our daily/hourly/minutely polling of our inboxes and
>subseuently the subject line of piclist mail.
>
>On the flip side you can consider PICLIST.COM, in some part, as polling.
> Sure, you interrupt the server and it sends you a page, but at the
>bottom of each page it polls you and asks if you have enything you'd
>like to contribute.  Sometimes James and others will make such polling
>on the list itself.
>
>Steven Covey has a lot to say on the subject, though. In essence there
>are four types of work that a person does:
>1. Important time-critical
>2. Important, but not time critical
>3. Unimportant time-critical
>4. Unimportant and not time critical
>
>I've numbered them arbitrarily - I don't recal exactly how he numbered
>them, but I suspect it's correct.
>
>Quadrant 1 would be interrupts, quadrant 2 polling, quadrant 3 would be
>false/spurious interrupts, and quadrant 4 would essentially amount to
>idle time.
>
>Obviously if there are tasks that fall in quadrant one then you must
>handle them, and quickly.  Ideally, however, your most productive time
>will be spent in quadrant 2.  It is in this quadrant that you have the
>most control over your tasks.
>
>In short, the answer to your question "...what technique is better:
>interrupt or polling..." I can conclusively state that polling is far
>superior to interrupt with the caveat that certian things have to be
>handled by an interrupt.
>
>-Adam
>
>
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body