interrupt question

I have been working on a project that uses 800khz timing sensitive RGB LEDs. Adafruit Neo Pixels to be exact. This is also my first attempt with Arduino and programming in general. Not knowing that interrupts can effect code timing, i programmed to use. With goofy things going on I then learned about debounce. All is well, and i build a hardware switch debouncer, using 7414 with 10k pullup and cap to ground so pin1 high pin2 low and if switch hit pulls down pin one and pin2 goes high. I tried in project and well it worked very well. I thought I was golden.

Nope. It seems OK if switch presses are spread out in time, nothing bad seems to happen. But a couple very quick "double tap" type presses of switch seems to get timing out enough that more weirdness happens. the programmable LED will seize lights will be wrong color and such. sometimes program seems to recover on its own, sometimes if i press the switch again,program will recover and worse case have to cycle power to get running again.

I went the way of the interrupt as all my project does is different light patterns, but if switch is hit using switch case break it jumps to a random light pattern.

The constant polling (switch press importance) is paramount, it is why I went with interrupt. Is there anything else I can use or try. either hardware or software.

I am going to put scope on output of 7414 pin two and see if i see any weirdness in the mean time.

Thanks Chris

What size cap are you using?

You should be able to tune that to be large enough to remove bounce but small enough to allow repeat taps.


Rob

CNKay: I have been working on a project that uses 800khz timing sensitive RGB LEDs. Adafruit Neo Pixels to be exact. This is also my first attempt with Arduino and programming in general.

Always a bad idea to try using interrupts where they are inappropriate.

They are particularly inappropriate when used to sense pushbuttons, partly due to priority concerns, and partly due to bounce. While you can perform de-bouncing using 74HC14s, it is much more practical to do it in software - after all, you have a processor which spends much of its time doing absolutely nothing useful, so why not use it at least to debounce the switches.

What is good about the Neopixels, is that they remember the commands sent to them. This means that you can issue the commands in a burst, with no interrupts to foul up that burst, and then settle back and monitor your push buttons.

I have explained the debounce procedure in another thread. It uses polling and timing by the millis() function.

Graynomad:
What size cap are you using?

10uf. That part seem pretty good.

Thanks much Paul,

"What is good about the Neopixels, is that they remember the commands sent to them. This means that you can issue the commands in a burst, with no interrupts to foul up that burst, and then settle back and monitor your push buttons."

So that burst theory sounds wonderful, I just don't know how to do. Have you used or done anything similar to what i am looking for? I am only using one button. You would think one button would be easy. Oh and the button may be triggered 5-10msecs apart. I guess I don't care if I miss a couple switch hits while doing the random switch called effect. I just don't want to confuse the pixels. Which multiple interrupt triggers seem to be doing.

Well i have patterns code in the (loop) and using interrupt to sense switch then do random of 5 different effects. I guess I do not know of any other way of programming a switch to be monitored at all times while continuing to run the main loop. I want to react to switch very quickly and at any time. I liked the hardware debounce as it did not take any space. Not that a couple lines of code take that much but i still thought would be better for my application.

Like i said not much programming experience and lots to learn if you can guide me toward your scheme or point me in the right direction, it would be much appreciated. Thanks again Paul.

I don't actually have any NeoPixels, only a heap of WS2801 strings which I have yet to work on. My interest is however in debouncing code. I am fascinated as to how you are going to trigger a button fifty times a second ("5-10msecs apart") however.

Perhaps if you post your code (in "code" tags, and all of it), I might have some suggestions.

I am fascinated as to how you are going to trigger a button fifty times a second

+1


Rob

Oh duh my bad. No i just meant very fast. Several hits in a second however so maybe 250msecs. That would be 4 right. :|

Well I think you get the idea of program i am trying to do. Maybe you could just explain best way to poll a switch without the attachinterrupt. Proper structure and or functions? one dang switch. it seems whenever the data stream to the pixels locks up it is when the switch is hit three times quick. Upon the first switch trigger is goes to do its thing fine, but if it has not finished and a couple more trigger come it finished one and plays catch up and or bombs. I tried to detachinterrupt as first line in each of the five cases and attachinterrupt again as it finished just before the break but that did not seem to work once again i know my lack of programming experience and knowledge of options is my biggest hurtle right now.

SmartGreenHouse.org makes a nifty 6 channel debouncer board with a very reliable circuit and debounce times based on the combination of resistors and capacitors.

The basic kit has components for a 180ms delay but instructions are provided to change those times with alternative components. Each channel can have a different debounce time if required.

http://www.boxabits.com/en/modules/57-6-channel-debouncer-board-kit-of-parts-online-instructions-0799599878717.html

CNKay: I just meant very fast. Several hits in a second however so maybe 250msecs. That would be 4 right.

Maybe you could just explain best way to poll a switch without the attachinterrupt.

That's what I did in the other thread.

CNKay: it seems whenever the data stream to the pixels locks up it is when the switch is hit three times quick.

It does sound like the switch interrupts are interfering with sending the commands to the NeoPixels.

arbutus: SmartGreenHouse.org makes a nifty 6 channel debouncer board with a very reliable circuit and debounce times based on the combination of resistors and capacitors.

That's great - but we are looking here at a circuit using a microcontroller - it is absolutely absurd to add hardware to perform a task for which the microcontroller is a perfect solution - it is as it were, intelligent - it has "brains"; you should use them!

In this sort of situation, the microcontroller spends much of the time "twiddling its thumbs" - pretty literally (performing little loops of code).

In the master "loop" - which should correspond to the loop() function - a number of tasks can be performed in sequence, in a "non-blocking" fashion which is to say, if a particular task needs to wait on an event, it finishes at that point and continues execution to the next task in the loop sequence. When the loop comes back to it, the task "knows" that it is waiting for the event, so tests it and if the event has still not occurred, again passes on to the following task. It "knows" that it is waiting for such event by keeping track of its own "state" using one or more "state" switches, thus it executes a "state machine". And it may be waiting on any of a number of events, testing each on each pass through the loop, such as whether a switch has been pressed or released, or whether a time interval has passed.

Within this structure of code, things that must not interfere - such as commanding a string of NeoPixels or polling pushbuttons - are performed as entirely separate steps in turn. Commanding the NeoPixels should take less than a millisecond, so that should not interfere with the response to pressing a pushbutton. You certainly did not want the pushbutton to alter the commanding of the NeoPixels and indeed, if you allowed a pushbutton event to alter any part of the command sent to the NeoPixels while that command was in progress, that would be asking for trouble.