I think so, the interrupt in the schematic of Mica2 is INT3, but it is
connected to PE7 pin in ATMEGA128 chip, which is defined as INT7.

Shawn

On Wed, Oct 19, 2011 at 3:34 PM, Michael Schippling <[email protected]>wrote:

> Just for reference....
>
> Moteworks uses TOS1 which has different functions than TOS2
> for doing everything useful.
>
> That's one reason I stayed out of the fray...
> but it is "interesting" that the interrupt number seems to be
> mixed up between major versions. I wonder if it has to do with
> the mica boards using a different numbering scheme than the
> actual atmega manual for their hardware interrupts?
>
> MS
>
> dong bo wrote:
>
>> Hi,
>>
>> What I found in the tos/sensorboards/sensorboard.h is a
>> TOSH_ALIAS_PIN(TONE_DECODE_
>> SIGNAL, INT3)
>>
>> Hi Antonio, I did not find what you mentioned in that file. Is it under
>> tos/sensorboards ?
>>
>> Thanks!
>> Shawn
>>
>>
>> On Wed, Oct 19, 2011 at 12:11 PM, antonio rosa <
>> antoniorosarodriguez@gmail.**com <[email protected]><mailto:
>> antoniorosarodriguez@**gmail.com <[email protected]>>>
>> wrote:
>>
>>    Hi,
>>
>>    Moteworks provides a function that management the interrupts:
>>    TOSH_SIGNAL(SIG_INTERRUPT) {  } when  SIG_INTERRUP is a label
>>    defined on a sensorboard.h
>>
>>
>>    2011/10/19 dong bo <[email protected]
>>    <mailto:[email protected]>**>
>>
>>
>>        Hi Micheal,
>>
>>        Thanks for your reply. Actually, I am working on the tone
>>        detection part, and the interrupt response seems very strange.
>>        The following is my original code for this part, and I can see
>>        that the interrupt is coming continuously. But when I probe the
>>        INT3 pin using an oscilloscope, I found the hardware is working
>>        fine. I suspect the interrupt part is not working fine.
>>
>>        By the way, I am using the environment of Moteworks downloaded
>>        from Xbow website. Thanks a lot!
>>
>>            command result_t StdControl.init()
>>            {
>>                call RadioControl.init();
>>                call HPLUART.init();
>>                call Leds.init();
>>                call Serial.SetStdoutSerial();
>>
>>                call MicControl.init();
>>                call Mic.muxSel(1);
>>                call Mic.gainAdjust(64);
>>                               return SUCCESS;
>>            }
>>                       command result_t StdControl.start()
>>            {
>>                call RadioControl.start();
>>                call MicControl.start();
>>                call MicInterrupt.enable();
>>                return SUCCESS;
>>            }
>>                       command result_t StdControl.stop()
>>            {
>>                    call RadioControl.stop();
>>                    call MicControl.stop();
>>                return SUCCESS;
>>            }
>>
>>            async event result_t MicInterrupt.toneDetected()
>>            {
>>                call MicInterrupt.disable();
>>                call Leds.redToggle();
>>                               TOSH_uwait(5000);
>>                call MicInterrupt.enable();
>>                __nesc_enable_interrupt();
>>                return SUCCESS;
>>
>>            }
>>
>>
>>        On Tue, Oct 18, 2011 at 12:46 PM, Michael Schippling
>>        <[email protected] <mailto:[email protected]>> wrote:
>>
>>            We would have to look at your code, but most likely you
>>            are not returning from the interrupt correctly.
>>
>>            MS
>>
>>            dong bo wrote:
>>
>>                I am trying to implement the tone detector software in a
>>                Mica2 motes with MTS310 sensor cards. The current
>>                problem is that as soon as the interrupt is triggered,
>>                the system would crash. I triggered green LED to toggle
>>                every a while and red LED will be toggled in the
>>                interrupt callback function. As soon as there is a
>>                sound, red LED will be toggled, and green LED will not
>>                be blinking at more, and there will be no more response
>>                from the system. Does anyone know about this?
>>
>>                Thanks in advance!
>>                Shawn
>>
>>
>>                ------------------------------**
>> __----------------------------**--__------------
>>
>>                ______________________________**___________________
>>                Tinyos-help mailing list
>>                Tinyos-help@millennium.__berke**ley.edu<http://berkeley.edu>
>>                
>> <mailto:Tinyos-help@**millennium.berkeley.edu<[email protected]>
>> >
>>                https://www.millennium.__berke**ley.edu/cgi-bin/mailman/__
>> **listinfo/tinyos-help<http://berkeley.edu/cgi-bin/mailman/__listinfo/tinyos-help>
>>
>>                <https://www.millennium.**berkeley.edu/cgi-bin/mailman/**
>> listinfo/tinyos-help<https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help>
>> >
>>
>>
>>
>>        ______________________________**_________________
>>        Tinyos-help mailing list
>>        
>> Tinyos-help@millennium.**berkeley.edu<[email protected]>
>>        
>> <mailto:Tinyos-help@**millennium.berkeley.edu<[email protected]>
>> >
>>        https://www.millennium.**berkeley.edu/cgi-bin/mailman/**
>> listinfo/tinyos-help<https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help>
>>
>>
>>
>>
>>
>> ------------------------------**------------------------------**
>> ------------
>>
>> ______________________________**_________________
>> Tinyos-help mailing list
>> Tinyos-help@millennium.**berkeley.edu<[email protected]>
>> https://www.millennium.**berkeley.edu/cgi-bin/mailman/**
>> listinfo/tinyos-help<https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help>
>>
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to