[TriEmbed] IR sensor vs trigger

[Jon Wolfe]

Yes, I think this sounds doable in a single chip. My sarcasm probably didn't come through in my email. On the other hand, sometimes it is fun to get all Rube Goldberg with hardware for one-off projects.



________________________________
 From: The MacDougals <paulmacd at acm.org>
To: 'Joe Fair' <joe at fairanswers.com> 
Cc: triembed at triembed.org 
Sent: Thursday, July 31, 2014 10:07 PM
Subject: Re: [TriEmbed] IR sensor vs trigger
 


The Tiny chips support pin change interrupts on all pins.  You surely do not need two chips.
I would definitely get rid of the 1 second timeout.  I use the interrupt to be sure that I do not
miss a pulse on a pin.  If the pulses are long enough, then you can just poll and not worry about
using interrupts.
 
Here are fragments of code from my rain gauge that sleeps most of the time.  It wakes up
on the rain sensor changing state or on a button press.  If you want more details, let me know.
 
---> Paul
 
 
#if defined(__AVR_ATtiny84__)
#include <avr/interrupt.h>
#endif
 
const uint8_t SW_PIN  = 4;
const uint8_t RAIN_PIN = 8;    // PCINT0
 
volatile uint8_t rain_pin_state = LOW;// does not matter what it is initialized to
volatile uint8_t rain_count = 0;
 
#if defined(__AVR_ATtiny84__)
// PA4 handler
ISR(PCINT0_vect) {
    // just wake up
}
 
// PB2 handler
ISR(PCINT1_vect) {
    // see if the rain gauge has tipped
    uint8_t save_rain_pin_state = rain_pin_state;
    if (save_rain_pin_state != (rain_pin_state = digitalRead(RAIN_PIN)))
        rain_count++;
}
#endif
 
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif
 
setup()
{
    pinMode(RAIN_PIN, INPUT_PULLUP);
    rain_pin_state = digitalRead(RAIN_PIN);
 
…
#if defined(__AVR_ATtiny84__)
    sei(); // Turn on interrupts
    // Pin interrupt setup for rain bucket
    sbi(GIMSK,5); // Enable pin change interrupt 1
    sbi(PCMSK1,2); // Allow pin changes on PB2
#endif
…
}
 
void loop()
{
    // we expect rain_count to be 0 or 1.  If it is more than 1, then it is likely a signal bounce
    if (rain_count) {
        …
    }
}
 
 
 


From:TriEmbed [mailto:triembed-bounces at triembed.org] On Behalf Of Joe Fair
Sent: Thursday, July 31, 2014 7:15 PM
To: Jon Wolfe
Cc: triembed at triembed.org
Subject: Re: [TriEmbed] IR sensor vs trigger
 
I think you are right, they kind of each need a chip.  I was hoping to be smart enough to not to need more hardware. 
Does the tiny sport two interrupts?  Or maybe i can tie them together?
I guess i need to learn more about days sheets, too.
Joe
On Jul 30, 2014 10:09 PM, "Jon Wolfe" <jonjwolfe at yahoo.com> wrote:
I agree with the others, it sounds like the trigger should get the interrupt.
 
Like Jeff said, you want your interrupt to execute in as short of a time as possible. One approach might be to just set a flag on trigger presses then process the action in the main loop. That could still leave you with 1 sec latency if you are detecting IR hits, which would probably be pretty noticeable.
 
I have never tried this on a tiny, but I'm making it a personal mission to find a use case for it, but you could use an RTOS, like http://www.femtoos.org/  Looks promising. I've used ChibiOS on Cortex M3/4's and found it pretty nice to work with, YMMV. 
 
The other alternative approaches might be to try to reduce the 1 second detection loop. Or, to try to architect your own "cooperative multitasking" or coroutines. In short, write your detect loop so that instead of looping for 1 second, it just does a little bit of work and returns to the main loop, remembering where is was in the loop between each call. I use this approach a lot.
 
I will say that you should try to handle debouncing the trigger in hardware as much as you can. I've tried software debouncing mechanical encoders in interrupt driven routines, and I can attest that it is maddening.
 
Lastly, you *could* always just buy a separate tiny for the detection, but I have no ulterior motive or bias there ;)
 
 
 
 

________________________________

From:Joe Fair <joe at fairanswers.com>
To: triembed at triembed.org 
Sent: Saturday, July 26, 2014 4:09 PM
Subject: [TriEmbed] IR sensor vs trigger
 
Ok.  I'm pretty close on getting my home made laser tag with at tiny 85s going, but now i have a question about design.
The loop I'm using detects a trigger pull, then a hit on the sensors.  however, The pulse in function I'm using to sense IR ha a timeout of 1 second.  If there is no inbound signal it is only checking got a trigger pull once a second.
So i need to use an interrupt, but does it matter if i use one on the trigger pull or the ir sensor? 
Joe

_______________________________________________
Triangle, NC Embedded Computing mailing list
TriEmbed at triembed.org
http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
TriEmbed web site: http://TriEmbed.org



_______________________________________________
Triangle, NC Embedded Computing mailing list
TriEmbed at triembed.org
http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
TriEmbed web site: http://TriEmbed.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20140731/f52cde84/attachment.htm>