Tap sensing with BMA180 accelerometer

[kender]

Folks,

By any chance, does anyone have a code snippet, which would show how to initialize BMA180 accelerometer for tap sensing? Doesn't matter whether it's SPI or I2C, I should be able to adapt it to my setup.

So far, I was able to communicate with my BMA180 via SPI. I can read chip ID, accelerations. I can set up a new data interrupt, and it behaves as expected.

When I try to set up the tap sensing interrupt, the INT pin goes high without tapping and stays high. I've added code, which resets the interrupt every second, but the pin immediately (within 0.5ms) goes back high. I guess, somehow the BMA180 thinks that it's tapped all the time.

Here are my present settings:

interrupt is latching
range: 2g (default)
tap duration: 500ms
tap threshold: 254
the rest are default

Any suggestion, insight or reference is really appreciated!

Cheers,
- Nick
_________________
Read the label, before opening a can of worms.

[temtronic]

obvious comments are ...
have you downloaded any relevant documentation and test code from the OEM ?
googled to see what's out 'there'? I got a few thousand hits including code(though not CCS C), code is code.

You say you have the sensor configured to latch the interrupt so what resets it ?
Since I don't have that sensor, I can't cut code but as you have it working I suggest it's something in the setup, either the config or a timing(sampling) problem.

[kender]

Obvious response to your comments: Please don't assume that I'm stupid. Do me such a favor.
... and you're always welcome to post something that is not completely useless. That is, less useless than ballpark number of hits on google.

[Ttelmah]

Thing is Kender, that this is a help forum, for _CCS code_, not for general 'how to get something to work'. Unfortunately it suffers from rather a lot of abuse, and in particular from people doing projects who seem to want the posters here to write complete code for them. Hence some people have become a bit 'short tempered' about posts that are perhaps too open sounding.

Looking at the chip, you do realise you need to turn _off_ the other possible interrupt sources?. The chip internally "OR's" the interrupt sources, so if any of the other bits are set, you may get a 'conversion complete' interrupt setting the pin, and the behaviour you are seeing.

The data is a bit naughty, since it lists the 'power on' values for several of these registers as '0', but then says that they are set by default to values from the EEPROM, with these given on page 26. These seem to be saying that just about every interrupt is _enabled_.....

You need to set all these bits to zero, and read them back, to 'check'.

Best Wishes

[temtronic]

I don't assume anyone is stupid, heck you got the thing working...but I've found that OEM datasheets may need to be read a few times as different mfrs. say the same thing different ways, or init their chip to some odd config (never the one you want).
OEMs typically have lots of 'application notes' , some might use that chip, though not obvious, and have some tidbit of info (like the wired or setup) that you need to know.
Same holds true of 'googling', It is an amazing tool to use and can save a ton of R&D time. Knowing that the order of the words in 'search' is important can quickly drop the hits from 1000s to 100s.

re: my last comment...
you said...
interrupt is latching

So what I wanted to know is what mechanism 'resets the latched interrupt' on the perhipheral ? Ttelmah says the int is wired 'or, so it appears something else, inside the chip is keeping the int high making it a chip problem NOT a PIC or code issue.

It's all in the 'details' that hopefully the datasheet has.

[kender]