[TriEmbed] TriEmbed Digest, Vol 14, Issue 37

Charles McClelland chip at mcclellands.org
Thu Jul 31 21:47:43 CDT 2014


Pete and all,

I have been working on a GPRS-based data logger which uploads data to Xively.  

Here is the stream I have been testing - notice you can capture location data as well.

With Adafruit’s recently released GPRS modem and Sparkfun’s new data service, there are exciting new options for collecting and publishing data from distributed sensors using the cellular network.

If that is interesting to anyone, happy to demonstrate and share the code.

Thanks,

Chip


On Jul 31, 2014, at 9:08 PM, triembed-request at triembed.org wrote:

> Send TriEmbed mailing list submissions to
> 	triembed at triembed.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> or, via email, send a message with subject or body 'help' to
> 	triembed-request at triembed.org
> 
> You can reach the person managing the list at
> 	triembed-owner at triembed.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of TriEmbed digest..."
> 
> 
> Today's Topics:
> 
>   1. looking for a talk for August 11th/NCSU mtg & also somebody
>      to record it (Pete Soper)
>   2. Re: IR sensor vs trigger (The MacDougals)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 31 Jul 2014 21:24:33 -0400
> From: Pete Soper <pete at soper.us>
> To: Triangle Embedded Computing Discussion <triembed at triembed.org>
> Subject: [TriEmbed] looking for a talk for August 11th/NCSU mtg & also
> 	somebody to record it
> Message-ID: <53DAEC51.8010109 at soper.us>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Anybody interested?
> 
> -Pete
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 31 Jul 2014 22:07:39 -0400
> From: "The MacDougals" <paulmacd at acm.org>
> To: "'Joe Fair'" <joe at fairanswers.com>
> Cc: triembed at triembed.org
> Subject: Re: [TriEmbed] IR sensor vs trigger
> Message-ID: <00ae01cfad2d$60150e80$203f2b80$@acm.org>
> Content-Type: text/plain; charset="utf-8"
> 
> 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 <http://triembed.org/> 
> 
> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20140731/f0ad0fbc/attachment.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> TriEmbed mailing list
> TriEmbed at triembed.org
> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> 
> 
> ------------------------------
> 
> End of TriEmbed Digest, Vol 14, Issue 37
> ****************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20140731/72a6ad04/attachment.htm>


More information about the TriEmbed mailing list