Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

Hi All,

I was wondering if anyone has any experience polling the GetPin command. Specifically, I was wondering how many times you were able to poll a pin per second (ballpark)? 3 times? 10 times? 25 times? 100 times? 1000 times?

Here is a little background for those interested. I have two pins... and as soon as either one goes into the bxOutputHigh state I need to shut a motor off to avoid damaging the driver. I have a program running Serial I/O, PWM and Servos so my chip is fairly busy. It is important to catch this bxOutPutHigh signal as soon as it happens so I was wondering if I should be using waitForInterrupt instead. ie. Theoretically I could change the circuit board so if Pin A or Pin B is high... then send a high signal to Pin 11. Then after the interupt do my thing.

please share your thoughts on WaitForInterupt vs Polling.

-Trevor

------------------------------------



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... WaitForInterrupt vs Polling...

A BX-24 can poll a pin at ~8kHz, but it can't do anything else at that
rate. Polling at any lesser rate is fine if it meets your response
latency needs.

Polling is usually a literal waste of time, though, since a task can be
built to wait for the pin, as you suggest, with WaitForInterrupt. The
task will usually get control within a few hundred µS after the pin
change. If you need to watch more than one pin, they can be combined in
external logic to generate the interrupt, then individually tested to
determine which caused it. The best scheme requires latching the pin
states at the moment of change if a signal can change before code can
test it - but it sounds like you might not need to be that fast. A
simple OR to the interrupt pin, and a pin for each signal, might suffice.

Tom

------------------------------------



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Hi Tom,

thanks for the helpful response. I'm not the one working on the electronic=
design but the board is really tight for room. I have been told that poll=
ing is preferred. It sounds like I need to do my own tests based on my spe=
cific code to see how often I can poll. I won't be afraid to push the chip=
past 20x per second. ie. I will try for 200 or 2000. I'll try to post a=
follow-up message when I figure out my exact number.

-Trevor

ps: You are right - we wouldn't need to latch the pin states assuming we us=
e waitforinterupt but thanks for bringing that up anyway. It's interesting=
to know that can be done.

=20=20
--- In b...@yahoogroups.com, Tom Becker wrote:
>
> > ... WaitForInterrupt vs Polling...
>=20
> A BX-24 can poll a pin at ~8kHz, but it can't do anything else at that=20
> rate. Polling at any lesser rate is fine if it meets your response=20
> latency needs.
>=20
> Polling is usually a literal waste of time, though, since a task can be=20
> built to wait for the pin, as you suggest, with WaitForInterrupt. The=20
> task will usually get control within a few hundred =B5S after the pin=20
> change. If you need to watch more than one pin, they can be combined in=
=20
> external logic to generate the interrupt, then individually tested to=20
> determine which caused it. The best scheme requires latching the pin=20
> states at the moment of change if a signal can change before code can=20
> test it - but it sounds like you might not need to be that fast. A=20
> simple OR to the interrupt pin, and a pin for each signal, might suffice.
>=20
> Tom
>

------------------------------------



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )