Forums

USE_NESTED_INTERRUPTS

Started by Corey, Rick October 12, 2002
I have another beginner SDK question, after searching the Yahoo archive and
all the manuals that seemed relevant.

I seemed to have found an answer, but it didn't seem to work, nor did any of
the variations I tried.

I'm trying to disable nested interrupts in the SDK. I have some
"impossible" code behavior, and thought it might be due to nested interrupts
changing the Z bit in the status register behind my back.

Although I'm trying to block nested IRQs, bits [9:8] in the SR are always
0x01, which seem to enable maskable IRQs (though perhaps the NestedIPRMask
is blocking them). I see it is the I-one bit (not the I-zero bit as I
thought before) that masks all interrupts except NMIs.

I've tried these three lines (one at a time, of course) in my appconfig.h
for RAM, and FLASH, as the first changed line:
#DEFINE USE_NESTED_INTERRUPTS NO
#undef USE_NESTED_INTERRUPTS
#DEFINE USE_NESTED_INTERRUPTS YES

Below them, I have these lines:

#define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE
#define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE

void ISR_CAN_Transmit(void); // Thanks, MotoDSP group!
void ISR_CAN_Receive( void);

#define NORMAL_ISR_14 ISR_CAN_Transmit // no "F"!
#define NORMAL_ISR_15 ISR_CAN_Receive

Does " #DEFINE USE_NESTED_INTERRUPTS NO" work for other people here?
Should I also poke configNestedIPRmask[ ] manually?
Does USE_NESTED_INTERRUPTS affect only the IPR masks and not the status
register I-one bit (bit #9)?

Thanks again for your help, people.

Rick Corey

- - - - -

The reason I'm concerned about nested IRQs is that I can go to mixed mode
and watch what seems to be wrong behavior for TSTW or BNE (see mixed
display at the end of the email). At the source level, *both* DoA and DoB
would run.

if (ptr == NULL)
{ DoA }

if (ptr != NULL)
{ DoB }

Elsewhere in my code (like, outside ISRs), the test (ptr == NULL) seems to
work OK.

I would always execute DoA whether the pointer was zero or not. I would
execute both DoA and DoB on the same pass through the code, if the ptr was
non-zero, and I wasn't modifying the pointer in DoA.

Just 2-3 times, I saw correct behavior, right after I first added the line
#DEFINE USE_NESTED_INTERRUPTS YES
However, that behavior "went away". Also, if anything, this should turn
nesting ON.

I could watch BNE branch the same way whether the pointer was 0 or $20A3.
The sr.Z bit was always set in those tests, but I could see it go to 0 after
the != test (watching only source level).

I don't completely believe that I'm seeing what I'm seeing, so please don't
take my word for it.
After I'm sure I have nested IRQs blocked I'll report again.

real source code:

volatile struct CanPktBuffer *psTmpDbgPtr;
volatile struct CanPktBuffer *psPRLL_ListHead=NULL;
. . . .

if (psTmpDbgPtr == NULL)
{
psPRLL_ListHead = *ppsPktToInsert; // DoA
}
// there is no "else" here
if ( psTmpDbgPtr != NULL )
{
// DoB
while ( ( psInsertHere->pnext != NULL ) &&
( psInsertHere->pnext->DataByte[PACKET_LEN] <
(*ppsPktToInsert)->DataByte[PACKET_LEN] ) )
{
psInsertHere = psInsertHere->pnext;
}

etc etc
}

I started out with a simpler:
If ( psPRLL_ListHead == NULL)
{
DoA
}
else
{
DoB
}
and then inserted the TmpPtr, and removed the else, switched the order of
the ptr and the NULL, in desperation. real mixed mode:
psTmpDbgPtr = psPRLL_ListHead;
P:000002DA: F8542052 move X:0x2052,R0
P:000002DC: 9832 moves R0,X:0x0032

if (psTmpDbgPtr == NULL)
P:000002DD: BE32 tstw X:0x0032
P:000002DE: A203 bne AddPktToPRLL+0x9 (0x2e2); 0x000173
{
psPRLL_ListHead = *ppsPktToInsert;
P:000002DF: F816 move X:(R2),R0
P:000002E0: D8542052 move R0,X:0x2052
}

if ( psTmpDbgPtr != NULL )
P:000002E2: BE32 tstw X:0x0032
P:000002E3: A319 beq AddPktToPRLL+0x24 (0x2fd); 0x00018b
{ // walk the
ToTxList to insert in order or at end
while ( ( psInsertHere->pnext != NULL ) &&
P:000002E4: A903 bra AddPktToPRLL+0xf (0x2e8); 0x000176
( psInsertHere->pnext->DataByte[PACKET_LEN] <
(*ppsPktToInsert)->DataByte[PACKET_LEN] ) )
{
psInsertHere = psInsertHere->pnext;
P:000002E5: FB43000F move X:(R3+0x000f),R3
P:000002E7: E040 nop
}
P:000002E8: FE43000F tstw X:(R3+0x000f)
P:000002EA: A309 beq AddPktToPRLL+0x1b (0x2f4); 0x00017f
P:000002EB: F843000F move X:(R3+0x000f),R0
P:000002ED: F916 move X:(R2),R1
P:000002EE: F1400004 move X:(R0+0x0004),Y0
P:000002F0: F0410004 move X:(R1+0x0004),X0
P:000002F2: 7C43 cmp X0,Y0
P:000002F3: A171 bcs AddPktToPRLL+0xc (0x2e5); 0x00016b
Rick Corey, Software Development
DPC Instrument Systems Division, Flanders NJ



Unfortunately, our documentation is wrong. You will not find a single
instance of USE_NESTED_INTERRUPTS in the SDK source files. To turn
nested interrupts off, you will have to open dispatcher.asm file located
in the sys directory, and modify the following line of code:

define SUPPORT_NESTED_INTERRUPTS '1'

You will have to change 1 to 0.

I am not sure why SDK implementation doesn't allow configuration of this
parameter via appconfig.h, while SDK documentation talks about it, and I
apologize for any confusion it caused.

Sincerely,

Leonard N. Elevich
Motorola DSPO

-----Original Message-----
From: Corey, Rick [mailto:]
Sent: Saturday, October 12, 2002 2:43 PM
To: Motodsp (E-mail)
Cc: Nickerson, Steve
Subject: [motoroladsp] USE_NESTED_INTERRUPTS

I have another beginner SDK question, after searching the Yahoo archive
and
all the manuals that seemed relevant.

I seemed to have found an answer, but it didn't seem to work, nor did
any of
the variations I tried.

I'm trying to disable nested interrupts in the SDK. I have some
"impossible" code behavior, and thought it might be due to nested
interrupts
changing the Z bit in the status register behind my back.

Although I'm trying to block nested IRQs, bits [9:8] in the SR are
always
0x01, which seem to enable maskable IRQs (though perhaps the
NestedIPRMask
is blocking them). I see it is the I-one bit (not the I-zero bit as I
thought before) that masks all interrupts except NMIs.

I've tried these three lines (one at a time, of course) in my
appconfig.h
for RAM, and FLASH, as the first changed line:
#DEFINE USE_NESTED_INTERRUPTS NO
#undef USE_NESTED_INTERRUPTS
#DEFINE USE_NESTED_INTERRUPTS YES

Below them, I have these lines:

#define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE
#define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE

void ISR_CAN_Transmit(void); // Thanks, MotoDSP group!
void ISR_CAN_Receive( void);

#define NORMAL_ISR_14 ISR_CAN_Transmit // no "F"!
#define NORMAL_ISR_15 ISR_CAN_Receive

Does " #DEFINE USE_NESTED_INTERRUPTS NO" work for other people here?

Should I also poke configNestedIPRmask[ ] manually?
Does USE_NESTED_INTERRUPTS affect only the IPR masks and not the
status
register I-one bit (bit #9)?

Thanks again for your help, people.

Rick Corey

- - - - -

The reason I'm concerned about nested IRQs is that I can go to mixed
mode
and watch what seems to be wrong behavior for TSTW or BNE (see mixed
display at the end of the email). At the source level, *both* DoA and
DoB
would run.

if (ptr == NULL)
{ DoA }

if (ptr != NULL)
{ DoB }

Elsewhere in my code (like, outside ISRs), the test (ptr == NULL)
seems to
work OK.

I would always execute DoA whether the pointer was zero or not. I would
execute both DoA and DoB on the same pass through the code, if the ptr
was
non-zero, and I wasn't modifying the pointer in DoA.

Just 2-3 times, I saw correct behavior, right after I first added the
line
#DEFINE USE_NESTED_INTERRUPTS YES
However, that behavior "went away". Also, if anything, this should turn
nesting ON.

I could watch BNE branch the same way whether the pointer was 0 or
$20A3.
The sr.Z bit was always set in those tests, but I could see it go to 0
after
the != test (watching only source level).

I don't completely believe that I'm seeing what I'm seeing, so please
don't
take my word for it.
After I'm sure I have nested IRQs blocked I'll report again.

real source code:

volatile struct CanPktBuffer *psTmpDbgPtr;
volatile struct CanPktBuffer *psPRLL_ListHead=NULL;
. . . .

if (psTmpDbgPtr == NULL)
{
psPRLL_ListHead = *ppsPktToInsert; // DoA
}
// there is no "else"
here
if ( psTmpDbgPtr != NULL )
{
// DoB
while ( ( psInsertHere->pnext != NULL ) &&
( psInsertHere->pnext->DataByte[PACKET_LEN] <
(*ppsPktToInsert)->DataByte[PACKET_LEN] ) )
{
psInsertHere = psInsertHere->pnext;
}

etc etc
}

I started out with a simpler:
If ( psPRLL_ListHead == NULL)
{
DoA
}
else
{
DoB
}
and then inserted the TmpPtr, and removed the else, switched the order
of
the ptr and the NULL, in desperation. real mixed mode:
psTmpDbgPtr = psPRLL_ListHead;
P:000002DA: F8542052 move X:0x2052,R0
P:000002DC: 9832 moves R0,X:0x0032

if (psTmpDbgPtr == NULL)
P:000002DD: BE32 tstw X:0x0032
P:000002DE: A203 bne AddPktToPRLL+0x9 (0x2e2); 0x000173
{
psPRLL_ListHead = *ppsPktToInsert;
P:000002DF: F816 move X:(R2),R0
P:000002E0: D8542052 move R0,X:0x2052
}

if ( psTmpDbgPtr != NULL )
P:000002E2: BE32 tstw X:0x0032
P:000002E3: A319 beq AddPktToPRLL+0x24 (0x2fd); 0x00018b
{ // walk
the
ToTxList to insert in order or at end
while ( ( psInsertHere->pnext != NULL ) &&
P:000002E4: A903 bra AddPktToPRLL+0xf (0x2e8); 0x000176
( psInsertHere->pnext->DataByte[PACKET_LEN] <
(*ppsPktToInsert)->DataByte[PACKET_LEN] ) )
{
psInsertHere = psInsertHere->pnext;
P:000002E5: FB43000F move X:(R3+0x000f),R3
P:000002E7: E040 nop
}
P:000002E8: FE43000F tstw X:(R3+0x000f)
P:000002EA: A309 beq AddPktToPRLL+0x1b (0x2f4); 0x00017f
P:000002EB: F843000F move X:(R3+0x000f),R0
P:000002ED: F916 move X:(R2),R1
P:000002EE: F1400004 move X:(R0+0x0004),Y0
P:000002F0: F0410004 move X:(R1+0x0004),X0
P:000002F2: 7C43 cmp X0,Y0
P:000002F3: A171 bcs AddPktToPRLL+0xc (0x2e5); 0x00016b
Rick Corey, Software Development
DPC Instrument Systems Division, Flanders NJ

_____________________________________
Note: If you do a simple "reply" with your email client, only the author
of this message will receive your answer. You need to do a "reply all"
if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/



One more clarification about our documentation being wrong. After reading this portion of the documentation more carefully, you will find that it doesn’t talk about some global macro that you can use to toggle nested interrupts in the SDK. This example defines this macro in the appconfig.h for local use only. So SDK documentation is correct. And you have to use method that I have described in my previous email to disable nested interrupts.

 

There is however, another way for you to disable nested interrupts. If you define all interrupts to be the same priority:

 

#define GPR_INT_PRIORITY_14       4      // MSCAN Tx Ready  TXEIE
#define GPR_INT_PRIORITY_15       4      // MSCAN Rx Ready  RXFIE

 

SDK should disable nested interrupts for you automatically. The only time SDK re-enables interrupts (uses nested interrupts), is when you use different interrupt priorities (as in your example).

 

I still think that example in our documentation is some what misleading (I misread it just like you), unless you read it very carefully.

 

Leonard

 

-----Original Message-----
From: Leonard N. Elevich [mailto:l...@motorola.com]
Sent: Monday, October 14, 2002 4:31 PM
To: 'Corey, Rick'; 'Motodsp (E-mail)'
Cc: 'Nickerson, Steve'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS

 

Unfortunately, our documentation is wrong. You will not find a single
instance of USE_NESTED_INTERRUPTS in the SDK source files. To turn
nested interrupts off, you will have to open dispatcher.asm file located
in the sys directory, and modify the following line of code:

define SUPPORT_NESTED_INTERRUPTS '1'

You will have to change 1 to 0.

I am not sure why SDK implementation doesn't allow configuration of this
parameter via appconfig.h, while SDK documentation talks about it, and I
apologize for any confusion it caused.

Sincerely,

Leonard N. Elevich
Motorola DSPO

-----Original Message-----
From: Corey, Rick [mailto:r...@dpconline.com]
Sent: Saturday, October 12, 2002 2:43 PM
To: Motodsp (E-mail)
Cc: Nickerson, Steve
Subject: [motoroladsp] USE_NESTED_INTERRUPTS

I have another beginner SDK question, after searching the Yahoo archive
and
all the manuals that seemed relevant.

I seemed to have found an answer, but it didn't seem to work, nor did
any of
the variations I tried.

I'm trying to disable nested interrupts in the SDK.  I have some
"impossible" code behavior, and thought it might be due to nested
interrupts
changing the Z bit in the status register behind my back.

Although I'm trying to block nested IRQs, bits [9:8] in the SR are
always
0x01, which seem to enable maskable IRQs (though perhaps the
NestedIPRMask
is blocking them).  I see it is the I-one bit (not the I-zero bit as I
thought before) that masks all interrupts except NMIs.

I've tried these three lines (one at a time, of course) in my
appconfig.h
for RAM, and FLASH,  as the first changed line:
      #DEFINE  USE_NESTED_INTERRUPTS  NO
      #undef USE_NESTED_INTERRUPTS
      #DEFINE  USE_NESTED_INTERRUPTS  YES

Below them, I have these lines:

#define GPR_INT_PRIORITY_14       4      // MSCAN Tx Ready  TXEIE
#define GPR_INT_PRIORITY_15       5      // MSCAN Rx Ready  RXFIE

void ISR_CAN_Transmit(void);            // Thanks, MotoDSP group!
void ISR_CAN_Receive( void);

#define NORMAL_ISR_14   ISR_CAN_Transmit      // no "F"!
#define NORMAL_ISR_15   ISR_CAN_Receive

Does "      #DEFINE  USE_NESTED_INTERRUPTS  NO" work for other people here?

Should I also poke configNestedIPRmask[ ] manually?
Does  USE_NESTED_INTERRUPTS  affect only the IPR masks and not the
status
register I-one bit (bit #9)?

Thanks again for your help, people.

Rick Corey

- - - - -

The reason I'm concerned about nested IRQs is that I can go to mixed
mode
and watch what seems to be wrong behavior for  TSTW or BNE (see mixed
display at the end of the email).  At the source level,  *both*  DoA and
DoB
would run.

if (ptr == NULL)
      { DoA }

if (ptr != NULL)
      { DoB }

Elsewhere in my code (like, outside ISRs), the  test (ptr == NULL)
seems to
work OK.

I would always execute DoA whether the pointer was zero or not.  I would
execute both DoA and DoB on the same pass through the code, if the ptr
was
non-zero, and I wasn't modifying the pointer in DoA.

Just 2-3 times, I saw correct behavior, right after I first added the
line
      #DEFINE  USE_NESTED_INTERRUPTS  YES
However, that behavior "went away".  Also, if anything, this should turn
nesting ON.

I could watch BNE branch the same way whether the pointer was 0 or
$20A3.
The sr.Z bit was always set in those tests, but I could see it go to 0
after
the != test (watching only source level).

I don't completely believe that I'm seeing what I'm seeing, so please
don't
take my word for it. 
After I'm sure I have nested IRQs blocked I'll report again.

real source code:

volatile struct CanPktBuffer *psTmpDbgPtr;
volatile  struct CanPktBuffer *psPRLL_ListHead=NULL;
. . . .

      if (psTmpDbgPtr =NULL)
            {
            psPRLL_ListHead *ppsPktToInsert;            // DoA
            }
                                    // there is no "else"
here
      if ( psTmpDbgPtr !NULL )
            {                             
            //      DoB
            while (  ( psInsertHere->pnext  !NULL )      &&
                     ( psInsertHere->pnext->DataByte[PACKET_LEN] <
(*ppsPktToInsert)->DataByte[PACKET_LEN]    )   ) 
                  {
                  psInsertHere psInsertHere->pnext;
                  }
     
            etc etc
            }

I started out with a simpler:
If ( psPRLL_ListHead == NULL)
      {
      DoA
      }
else
      {
      DoB
      }
and then inserted the TmpPtr, and removed the else, switched the order
of
the ptr and the NULL, in desperation. real mixed mode:
      psTmpDbgPtr psPRLL_ListHead;
P:000002DA: F8542052  move     X:0x2052,R0
P:000002DC: 9832      moves    R0,X:0x0032
     
      if (psTmpDbgPtr =NULL)
P:000002DD: BE32      tstw     X:0x0032
P:000002DE: A203      bne      AddPktToPRLL+0x9 (0x2e2); 0x000173
            {
            psPRLL_ListHead *ppsPktToInsert;           
P:000002DF: F816      move     X:(R2),R0
P:000002E0: D8542052  move     R0,X:0x2052
            }
           
      if ( psTmpDbgPtr !NULL )
P:000002E2: BE32      tstw     X:0x0032
P:000002E3: A319      beq      AddPktToPRLL+0x24 (0x2fd); 0x00018b
            {                                    // walk
the
ToTxList to insert in order or at end
            while (  ( psInsertHere->pnext  !NULL )      &&
P:000002E4: A903      bra      AddPktToPRLL+0xf (0x2e8); 0x000176
                     ( psInsertHere->pnext->DataByte[PACKET_LEN] <
(*ppsPktToInsert)->DataByte[PACKET_LEN]    )   ) 
                  {
                  psInsertHere psInsertHere->pnext;
P:000002E5: FB43000F  move     X:(R3+0x000f),R3
P:000002E7: E040      nop
                  }
P:000002E8: FE43000F  tstw     X:(R3+0x000f)
P:000002EA: A309      beq      AddPktToPRLL+0x1b (0x2f4); 0x00017f
P:000002EB: F843000F  move     X:(R3+0x000f),R0
P:000002ED: F916      move     X:(R2),R1
P:000002EE: F1400004  move     X:(R0+0x0004),Y0
P:000002F0: F0410004  move     X:(R1+0x0004),X0
P:000002F2: 7C43      cmp      X0,Y0
P:000002F3: A171      bcs      AddPktToPRLL+0xc (0x2e5); 0x00016b
Rick Corey, Software Development
DPC Instrument Systems Division, Flanders NJ

_____________________________________
Note: If you do a simple "reply" with your email client, only the author
of this message will receive your answer.  You need to do a "reply all"
if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:  m...@yahoogroups.com

To Post:  m...@yahoogroups.com

To Leave: m...@yahoogroups.com

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/



_____________________________________
Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer.  You need to do a "reply all" if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:  m...@yahoogroups.com

To Post:  m...@yahoogroups.com

To Leave: m...@yahoogroups.com

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3


">Yahoo! Terms of Service.


Thanks for the help and frankness, Leonard.

If I get this working, I'll take out my workarounds and reply to the group
"that worked". However, I have to chase another frustrating problem first.

Rick Corey

P.S. Is there a way to generate pre-processor output?

I'm disenheartened and frustrated again; trying to compile from the SDK for
FLASH instead of external RAM is giving me five compiler errors in config.h,
which I don't feel very safe in modifying. Should we #define INCLUDE_FLASH
just to download to FLASH? Surely not. We can download to FLASH all day in
the non-SDK projects we've built.

"preceding #if is missing
config.h line 2381 #endif"

We've gone through 2,381 lines of config.h without finding why #ifdef and
#ifndef might get unmatched when we go from RAM to FLASH. as far as we can
tell, the .H files we have looked at seem to have matching numbers of
#ifdef + #ifndef and #endif ... as far as we can tell, which only goes so
far due to the conditional degree of nesting of includes and #if s.

We assume that some #define somewhere is interfering with the SDK
config/appconfig mechanism.

I am trying to use the SDK interrupt dispatcher for two non-driver
interrupts - CAN IRQs without the CAN driver.
Of course I am not #define - ing INCLUDE_CAN because we aren't/can't use
the CAN driver as it is.

-----Original Message-----
From: Leonard N. Elevich [mailto:]
Sent: Monday, October 14, 2002 7:45 PM
To: 'Corey, Rick'; 'Motodsp (E-mail)'
Cc: 'Nickerson, Steve'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS
One more clarification about our documentation being wrong. After reading
this portion of the documentation more carefully, you will find that it
doesn't talk about some global macro that you can use to toggle nested
interrupts in the SDK. This example defines this macro in the appconfig.h
for local use only. So SDK documentation is correct. And you have to use
method that I have described in my previous email to disable nested
interrupts.
There is however, another way for you to disable nested interrupts. If you
define all interrupts to be the same priority:
#define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE
#define GPR_INT_PRIORITY_15 4 // MSCAN Rx Ready RXFIE
SDK should disable nested interrupts for you automatically. The only time
SDK re-enables interrupts (uses nested interrupts), is when you use
different interrupt priorities (as in your example).
I still think that example in our documentation is some what misleading (I
misread it just like you), unless you read it very carefully.
Leonard
-----Original Message-----
From: Leonard N. Elevich [mailto:]
Sent: Monday, October 14, 2002 4:31 PM
To: 'Corey, Rick'; 'Motodsp (E-mail)'
Cc: 'Nickerson, Steve'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS
Unfortunately, our documentation is wrong. You will not find a single
instance of USE_NESTED_INTERRUPTS in the SDK source files. To turn
nested interrupts off, you will have to open dispatcher.asm file located
in the sys directory, and modify the following line of code:

define SUPPORT_NESTED_INTERRUPTS '1'

You will have to change 1 to 0.

I am not sure why SDK implementation doesn't allow configuration of this
parameter via appconfig.h, while SDK documentation talks about it, and I
apologize for any confusion it caused.

Sincerely,

Leonard N. Elevich
Motorola DSPO

-----Original Message-----
From: Corey, Rick [mailto:]
Sent: Saturday, October 12, 2002 2:43 PM
To: Motodsp (E-mail)
Cc: Nickerson, Steve
Subject: [motoroladsp] USE_NESTED_INTERRUPTS

I have another beginner SDK question, after searching the Yahoo archive
and
all the manuals that seemed relevant.

I seemed to have found an answer, but it didn't seem to work, nor did
any of
the variations I tried.

I'm trying to disable nested interrupts in the SDK. I have some
"impossible" code behavior, and thought it might be due to nested
interrupts
changing the Z bit in the status register behind my back.

Although I'm trying to block nested IRQs, bits [9:8] in the SR are
always
0x01, which seem to enable maskable IRQs (though perhaps the
NestedIPRMask
is blocking them). I see it is the I-one bit (not the I-zero bit as I
thought before) that masks all interrupts except NMIs.

I've tried these three lines (one at a time, of course) in my
appconfig.h
for RAM, and FLASH, as the first changed line:
#DEFINE USE_NESTED_INTERRUPTS NO
#undef USE_NESTED_INTERRUPTS
#DEFINE USE_NESTED_INTERRUPTS YES

Below them, I have these lines:

#define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE
#define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE

void ISR_CAN_Transmit(void); // Thanks, MotoDSP group!
void ISR_CAN_Receive( void);

#define NORMAL_ISR_14 ISR_CAN_Transmit // no "F"!
#define NORMAL_ISR_15 ISR_CAN_Receive

Does " #DEFINE USE_NESTED_INTERRUPTS NO" work for other people here?

Should I also poke configNestedIPRmask[ ] manually?
Does USE_NESTED_INTERRUPTS affect only the IPR masks and not the
status
register I-one bit (bit #9)?

Thanks again for your help, people.

Rick Corey

- - - - -

The reason I'm concerned about nested IRQs is that I can go to mixed
mode
and watch what seems to be wrong behavior for TSTW or BNE (see mixed
display at the end of the email). At the source level, *both* DoA and
DoB
would run.

if (ptr == NULL)
{ DoA }

if (ptr != NULL)
{ DoB }

Elsewhere in my code (like, outside ISRs), the test (ptr == NULL)
seems to
work OK.

I would always execute DoA whether the pointer was zero or not. I would
execute both DoA and DoB on the same pass through the code, if the ptr
was
non-zero, and I wasn't modifying the pointer in DoA.

Just 2-3 times, I saw correct behavior, right after I first added the
line
#DEFINE USE_NESTED_INTERRUPTS YES
However, that behavior "went away". Also, if anything, this should turn
nesting ON.

I could watch BNE branch the same way whether the pointer was 0 or
$20A3.
The sr.Z bit was always set in those tests, but I could see it go to 0
after
the != test (watching only source level).

I don't completely believe that I'm seeing what I'm seeing, so please
don't
take my word for it.
After I'm sure I have nested IRQs blocked I'll report again.

real source code:

volatile struct CanPktBuffer *psTmpDbgPtr;
volatile struct CanPktBuffer *psPRLL_ListHead=NULL;
. . . .

if (psTmpDbgPtr == NULL)
{
psPRLL_ListHead = *ppsPktToInsert; // DoA
}
// there is no "else"
here
if ( psTmpDbgPtr != NULL )
{
// DoB
while ( ( psInsertHere->pnext != NULL ) &&
( psInsertHere->pnext->DataByte[PACKET_LEN] <
(*ppsPktToInsert)->DataByte[PACKET_LEN] ) )
{
psInsertHere = psInsertHere->pnext;
}

etc etc
}

I started out with a simpler:
If ( psPRLL_ListHead == NULL)
{
DoA
}
else
{
DoB
}
and then inserted the TmpPtr, and removed the else, switched the order
of
the ptr and the NULL, in desperation. real mixed mode:
psTmpDbgPtr = psPRLL_ListHead;
P:000002DA: F8542052 move X:0x2052,R0
P:000002DC: 9832 moves R0,X:0x0032

if (psTmpDbgPtr == NULL)
P:000002DD: BE32 tstw X:0x0032
P:000002DE: A203 bne AddPktToPRLL+0x9 (0x2e2); 0x000173
{
psPRLL_ListHead = *ppsPktToInsert;
P:000002DF: F816 move X:(R2),R0
P:000002E0: D8542052 move R0,X:0x2052
}

if ( psTmpDbgPtr != NULL )
P:000002E2: BE32 tstw X:0x0032
P:000002E3: A319 beq AddPktToPRLL+0x24 (0x2fd); 0x00018b
{ // walk
the
ToTxList to insert in order or at end
while ( ( psInsertHere->pnext != NULL ) &&
P:000002E4: A903 bra AddPktToPRLL+0xf (0x2e8); 0x000176
( psInsertHere->pnext->DataByte[PACKET_LEN] <
(*ppsPktToInsert)->DataByte[PACKET_LEN] ) )
{
psInsertHere = psInsertHere->pnext;
P:000002E5: FB43000F move X:(R3+0x000f),R3
P:000002E7: E040 nop
}
P:000002E8: FE43000F tstw X:(R3+0x000f)
P:000002EA: A309 beq AddPktToPRLL+0x1b (0x2f4); 0x00017f
P:000002EB: F843000F move X:(R3+0x000f),R0
P:000002ED: F916 move X:(R2),R1
P:000002EE: F1400004 move X:(R0+0x0004),Y0
P:000002F0: F0410004 move X:(R1+0x0004),X0
P:000002F2: 7C43 cmp X0,Y0
P:000002F3: A171 bcs AddPktToPRLL+0xc (0x2e5); 0x00016b
Rick Corey, Software Development
DPC Instrument Systems Division, Flanders NJ

_____________________________________
Note: If you do a simple "reply" with your email client, only the author
of this message will receive your answer. You need to do a "reply all"
if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp
<http://www.yahoogroups.com/group/motoroladsp>

More Groups: http://www.dsprelated.com/groups.php3
<http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/ _____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp
<http://www.yahoogroups.com/group/motoroladsp>

More Groups: http://www.dsprelated.com/groups.php3
<http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> Terms of Service.

<http://rd.yahoo.com/M!9695.2310151.3725769.2113459/D=egroupweb/S057718
55:HM/A26184/R=0/*http://ad.doubleclick.net/jump/N879.ameritrade.yahoo/B1
054521.11;sz00x250;adc=ZHS;ord34639144?>

<http://us.adserver.yahoo.com/l?M!9695.2310151.3725769.2113459/D=egroupmai
l/S=:HM/A26184/randT3408226>

_____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp
<http://www.yahoogroups.com/group/motoroladsp>

More Groups: http://www.dsprelated.com/groups.php3
<http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> .



OK, I see it now.

The documentation says that code example 4-1 (page 4-3 of SDK Targeting 803
Manual) "shows how nesting MIGHT BE turned on and off." The example shows
how a #define might be used in user code to set all IRQ priority levels to
"1", in user code.

I see that the key part of the code example is the "1" priority, not
#defining anything.

I also see "If any interrupt is defined to have a priority greater than one,
then ... compiled to enable nested interrupts."

I'll try, first, setting all my priorities to '1".

Thanks again.

Rick Corey

-----Original Message-----
From: Leonard N. Elevich [mailto:]
Sent: Monday, October 14, 2002 7:45 PM
To: 'Corey, Rick'; 'Motodsp (E-mail)'
Cc: 'Nickerson, Steve'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS One more clarification about our documentation being wrong. After reading
this portion of the documentation more carefully, you will find that it
doesn't talk about some global macro that you can use to toggle nested
interrupts in the SDK. This example defines this macro in the appconfig.h
for local use only. So SDK documentation is correct. And you have to use
method that I have described in my previous email to disable nested
interrupts.

There is however, another way for you to disable nested interrupts. If you
define all interrupts to be the same priority:

#define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE
#define GPR_INT_PRIORITY_15 4 // MSCAN Rx Ready RXFIE

SDK should disable nested interrupts for you automatically. The only time
SDK re-enables interrupts (uses nested interrupts), is when you use
different interrupt priorities (as in your example).

I still think that example in our documentation is some what misleading (I
misread it just like you), unless you read it very carefully.

Leonard [Corey, Rick]

< big snip


You don’t need to use SDK’s INCLUDE_FLASH to target your application into Flash.

 

I would be glad to help you figure out your preprocessor problem. If you can send me your project (zipped) as is, or trim it down to bare code as long as problem is still there, I will take a look at it.

 

As far as generation of the pre-processor output, I am not aware of any options that you can give to CodeWarrior to force the output.

 

Leonard

 

-----Original Message-----
From: Corey, Rick [mailto:R...@dpconline.com]
Sent: Tuesday, October 15, 2002 8:00 AM
To: 'Leonard N. Elevich'; Motodsp (E-mail)
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS

 

Thanks for the help and frankness, Leonard.

 

If I get this working, I'll take out my workarounds and reply to the group "that worked".  However, I have to chase another frustrating problem first.

 

Rick Corey

 

P.S.  Is there a way to generate pre-processor output? 

 

I'm disenheartened and frustrated again; trying to compile from the SDK for FLASH instead of external RAM is giving me five compiler errors in config.h, which I don't feel very safe in modifying.  Should we #define  INCLUDE_FLASH  just to download to FLASH?  Surely not.  We can download to FLASH all day in the non-SDK projects we've built.

 

"preceding #if is missing

 config.h line 2381 #endif"

 

We've gone through 2,381 lines of config.h without finding why #ifdef and #ifndef might get unmatched when we go from RAM to FLASH. as far as we can tell, the  .H files we have looked at seem to have matching numbers of #ifdef + #ifndef  and #endif ... as far as we can tell, which only goes so far due to the conditional degree of nesting of includes and #if s.

 

We assume that some #define somewhere is interfering with the SDK config/appconfig mechanism.

 

I am trying to use the SDK interrupt dispatcher for two non-driver interrupts - CAN IRQs without the CAN driver.

Of course I am not #define - ing   INCLUDE_CAN  because we aren't/can't use the CAN driver as it is.

 

 

 

-----Original Message-----
From: Leonard N. Elevich [mailto:l...@motorola.com]
Sent: Monday, October 14, 2002 7:45 PM
To: 'Corey, Rick'; 'Motodsp (E-mail)'
Cc: 'Nickerson, Steve'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS

One more clarification about our documentation being wrong. After reading this portion of the documentation more carefully, you will find that it doesn't talk about some global macro that you can use to toggle nested interrupts in the SDK. This example defines this macro in the appconfig.h for local use only. So SDK documentation is correct. And you have to use method that I have described in my previous email to disable nested interrupts.

 

There is however, another way for you to disable nested interrupts. If you define all interrupts to be the same priority:

 

#define GPR_INT_PRIORITY_14       4      // MSCAN Tx Ready  TXEIE
#define GPR_INT_PRIORITY_15       4      // MSCAN Rx Ready  RXFIE

 

SDK should disable nested interrupts for you automatically. The only time SDK re-enables interrupts (uses nested interrupts), is when you use different interrupt priorities (as in your example).

 

I still think that example in our documentation is some what misleading (I misread it just like you), unless you read it very carefully.

 

Leonard

 

-----Original Message-----
From: Leonard N. Elevich [mailto:l...@motorola.com]
Sent: Monday, October 14, 2002 4:31 PM
To: 'Corey, Rick'; 'Motodsp (E-mail)'
Cc: 'Nickerson, Steve'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS

 

Unfortunately, our documentation is wrong. You will not find a single
instance of USE_NESTED_INTERRUPTS in the SDK source files. To turn
nested interrupts off, you will have to open dispatcher.asm file located
in the sys directory, and modify the following line of code:

define SUPPORT_NESTED_INTERRUPTS '1'

You will have to change 1 to 0.

I am not sure why SDK implementation doesn't allow configuration of this
parameter via appconfig.h, while SDK documentation talks about it, and I
apologize for any confusion it caused.

Sincerely,

Leonard N. Elevich
Motorola DSPO

-----Original Message-----
From: Corey, Rick [mailto:r...@dpconline.com]
Sent: Saturday, October 12, 2002 2:43 PM
To: Motodsp (E-mail)
Cc: Nickerson, Steve
Subject: [motoroladsp] USE_NESTED_INTERRUPTS

I have another beginner SDK question, after searching the Yahoo archive
and
all the manuals that seemed relevant.

I seemed to have found an answer, but it didn't seem to work, nor did
any of
the variations I tried.

I'm trying to disable nested interrupts in the SDK.  I have some
"impossible" code behavior, and thought it might be due to nested
interrupts
changing the Z bit in the status register behind my back.

Although I'm trying to block nested IRQs, bits [9:8] in the SR are
always
0x01, which seem to enable maskable IRQs (though perhaps the
NestedIPRMask
is blocking them).  I see it is the I-one bit (not the I-zero bit as I
thought before) that masks all interrupts except NMIs.

I've tried these three lines (one at a time, of course) in my
appconfig.h
for RAM, and FLASH,  as the first changed line:
      #DEFINE  USE_NESTED_INTERRUPTS  NO
      #undef USE_NESTED_INTERRUPTS
      #DEFINE  USE_NESTED_INTERRUPTS  YES

Below them, I have these lines:

#define GPR_INT_PRIORITY_14       4      // MSCAN Tx Ready  TXEIE
#define GPR_INT_PRIORITY_15       5      // MSCAN Rx Ready  RXFIE

void ISR_CAN_Transmit(void);            // Thanks, MotoDSP group!
void ISR_CAN_Receive( void);

#define NORMAL_ISR_14   ISR_CAN_Transmit      // no "F"!
#define NORMAL_ISR_15   ISR_CAN_Receive

Does "      #DEFINE  USE_NESTED_INTERRUPTS  NO" work for other people here?

Should I also poke configNestedIPRmask[ ] manually?
Does  USE_NESTED_INTERRUPTS  affect only the IPR masks and not the
status
register I-one bit (bit #9)?

Thanks again for your help, people.

Rick Corey

- - - - -

The reason I'm concerned about nested IRQs is that I can go to mixed
mode
and watch what seems to be wrong behavior for  TSTW or BNE (see mixed
display at the end of the email).  At the source level,  *both*  DoA and
DoB
would run.

if (ptr == NULL)
      { DoA }

if (ptr != NULL)
      { DoB }

Elsewhere in my code (like, outside ISRs), the  test (ptr == NULL)
seems to
work OK.

I would always execute DoA whether the pointer was zero or not.  I would
execute both DoA and DoB on the same pass through the code, if the ptr
was
non-zero, and I wasn't modifying the pointer in DoA.

Just 2-3 times, I saw correct behavior, right after I first added the
line
      #DEFINE  USE_NESTED_INTERRUPTS  YES
However, that behavior "went away".  Also, if anything, this should turn
nesting ON.

I could watch BNE branch the same way whether the pointer was 0 or
$20A3.
The sr.Z bit was always set in those tests, but I could see it go to 0
after
the != test (watching only source level).

I don't completely believe that I'm seeing what I'm seeing, so please
don't
take my word for it. 
After I'm sure I have nested IRQs blocked I'll report again.

real source code:

volatile struct CanPktBuffer *psTmpDbgPtr;
volatile  struct CanPktBuffer *psPRLL_ListHead=NULL;
. . . .

      if (psTmpDbgPtr =NULL)
            {
            psPRLL_ListHead *ppsPktToInsert;            // DoA
            }
                                    // there is no "else"
here
      if ( psTmpDbgPtr !NULL )
            {                             
            //      DoB
            while (  ( psInsertHere->pnext  !NULL )      &&
                     ( psInsertHere->pnext->DataByte[PACKET_LEN] <
(*ppsPktToInsert)->DataByte[PACKET_LEN]    )   ) 
                  {
                  psInsertHere = psInsertHere->pnext;
                  }
     
            etc etc
            }

I started out with a simpler:
If ( psPRLL_ListHead == NULL)
      {
      DoA
      }
else
      {
      DoB
      }
and then inserted the TmpPtr, and removed the else, switched the order
of
the ptr and the NULL, in desperation. real mixed mode:
      psTmpDbgPtr psPRLL_ListHead;
P:000002DA: F8542052  move     X:0x2052,R0
P:000002DC: 9832      moves    R0,X:0x0032
     
      if (psTmpDbgPtr =NULL)
P:000002DD: BE32      tstw     X:0x0032
P:000002DE: A203      bne      AddPktToPRLL+0x9 (0x2e2); 0x000173
            {
            psPRLL_ListHead *ppsPktToInsert;           
P:000002DF: F816      move     X:(R2),R0
P:000002E0: D8542052  move     R0,X:0x2052
            }
           
      if ( psTmpDbgPtr !NULL )
P:000002E2: BE32      tstw     X:0x0032
P:000002E3: A319      beq      AddPktToPRLL+0x24 (0x2fd); 0x00018b
            {                                    // walk
the
ToTxList to insert in order or at end
            while (  ( psInsertHere->pnext  !NULL )      &&
P:000002E4: A903      bra      AddPktToPRLL+0xf (0x2e8); 0x000176
                     ( psInsertHere->pnext->DataByte[PACKET_LEN] <
(*ppsPktToInsert)->DataByte[PACKET_LEN]    )   ) 
                  {
                  psInsertHere psInsertHere->pnext;
P:000002E5: FB43000F  move     X:(R3+0x000f),R3
P:000002E7: E040      nop
                  }
P:000002E8: FE43000F  tstw     X:(R3+0x000f)
P:000002EA: A309      beq      AddPktToPRLL+0x1b (0x2f4); 0x00017f
P:000002EB: F843000F  move     X:(R3+0x000f),R0
P:000002ED: F916      move     X:(R2),R1
P:000002EE: F1400004  move     X:(R0+0x0004),Y0
P:000002F0: F0410004  move     X:(R1+0x0004),X0
P:000002F2: 7C43      cmp      X0,Y0
P:000002F3: A171      bcs      AddPktToPRLL+0xc (0x2e5); 0x00016b
Rick Corey, Software Development
DPC Instrument Systems Division, Flanders NJ

_____________________________________
Note: If you do a simple "reply" with your email client, only the author
of this message will receive your answer.  You need to do a "reply all"
if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:  m...@yahoogroups.com

To Post:  m...@yahoogroups.com

To Leave: m...@yahoogroups.com

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/

_____________________________________
Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer.  You need to do a "reply all" if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:  m...@yahoogroups.com

To Post:  m...@yahoogroups.com

To Leave: m...@yahoogroups.com

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3


">Yahoo! Terms of Service.

 



_____________________________________
Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer.  You need to do a "reply all" if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:  m...@yahoogroups.com

To Post:  m...@yahoogroups.com

To Leave: m...@yahoogroups.com

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3


">Yahoo! Terms of Service.


Leonard,

You are right. I must have pasted an extra #endif into that file days ago,
and never noticed, because I didn't use it until just now.

Thank you!

(putting on a Dunce Cap and sitting in the corner)
Rick Corey -----Original Message-----
From: Leonard N. Elevich [mailto:]
Sent: Tuesday, October 15, 2002 1:45 PM
To: 'Corey, Rick'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS
Rick, in your appconfig.h file for flash configuration you have an extra
#endif at the end of the file. Since this file is included in the config.h,
preprocessor gives you error for config.h file.
Once I removed extra #endif in your appconfig.h file, your project compiled
fine.
Leonard
-----Original Message-----
From: Corey, Rick [mailto:]
Sent: Tuesday, October 15, 2002 9:49 AM
To: 'Leonard N. Elevich'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS
Thank you! I really appreciate this.
Maybe I'm just worn down by missing deadlines and working weekends and
evenings, yet making no progress.
I've tried re-installing the SDK, then got called over to put out another
fire.
Here's the project - oh please tell me that I did something amazingly
stupid!
Rick Corey

-----Original Message-----
From: Leonard N. Elevich [mailto:]
Sent: Tuesday, October 15, 2002 12:13 PM
To: 'Corey, Rick'; 'Motodsp (E-mail)'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS

You don't need to use SDK's INCLUDE_FLASH to target your application into
Flash.
I would be glad to help you figure out your preprocessor problem. If you can
send me your project (zipped) as is, or trim it down to bare code as long as
problem is still there, I will take a look at it.
As far as generation of the pre-processor output, I am not aware of any
options that you can give to CodeWarrior to force the output.
Leonard
-----Original Message-----
From: Corey, Rick [mailto:]
Sent: Tuesday, October 15, 2002 8:00 AM
To: 'Leonard N. Elevich'; Motodsp (E-mail)
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS
Thanks for the help and frankness, Leonard.
If I get this working, I'll take out my workarounds and reply to the group
"that worked". However, I have to chase another frustrating problem first.
Rick Corey
P.S. Is there a way to generate pre-processor output?
I'm disenheartened and frustrated again; trying to compile from the SDK for
FLASH instead of external RAM is giving me five compiler errors in config.h,
which I don't feel very safe in modifying. Should we #define INCLUDE_FLASH
just to download to FLASH? Surely not. We can download to FLASH all day in
the non-SDK projects we've built.
"preceding #if is missing

config.h line 2381 #endif"
We've gone through 2,381 lines of config.h without finding why #ifdef and
#ifndef might get unmatched when we go from RAM to FLASH. as far as we can
tell, the .H files we have looked at seem to have matching numbers of
#ifdef + #ifndef and #endif ... as far as we can tell, which only goes so
far due to the conditional degree of nesting of includes and #if s.
We assume that some #define somewhere is interfering with the SDK
config/appconfig mechanism.
I am trying to use the SDK interrupt dispatcher for two non-driver
interrupts - CAN IRQs without the CAN driver.

Of course I am not #define - ing INCLUDE_CAN because we aren't/can't use
the CAN driver as it is.

-----Original Message-----
From: Leonard N. Elevich [mailto:]
Sent: Monday, October 14, 2002 7:45 PM
To: 'Corey, Rick'; 'Motodsp (E-mail)'
Cc: 'Nickerson, Steve'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS

One more clarification about our documentation being wrong. After reading
this portion of the documentation more carefully, you will find that it
doesn't talk about some global macro that you can use to toggle nested
interrupts in the SDK. This example defines this macro in the appconfig.h
for local use only. So SDK documentation is correct. And you have to use
method that I have described in my previous email to disable nested
interrupts.
There is however, another way for you to disable nested interrupts. If you
define all interrupts to be the same priority:
#define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE
#define GPR_INT_PRIORITY_15 4 // MSCAN Rx Ready RXFIE
SDK should disable nested interrupts for you automatically. The only time
SDK re-enables interrupts (uses nested interrupts), is when you use
different interrupt priorities (as in your example).
I still think that example in our documentation is some what misleading (I
misread it just like you), unless you read it very carefully.
Leonard
-----Original Message-----
From: Leonard N. Elevich [mailto:]
Sent: Monday, October 14, 2002 4:31 PM
To: 'Corey, Rick'; 'Motodsp (E-mail)'
Cc: 'Nickerson, Steve'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS
Unfortunately, our documentation is wrong. You will not find a single
instance of USE_NESTED_INTERRUPTS in the SDK source files. To turn
nested interrupts off, you will have to open dispatcher.asm file located
in the sys directory, and modify the following line of code:

define SUPPORT_NESTED_INTERRUPTS '1'

You will have to change 1 to 0.

I am not sure why SDK implementation doesn't allow configuration of this
parameter via appconfig.h, while SDK documentation talks about it, and I
apologize for any confusion it caused.

Sincerely,

Leonard N. Elevich
Motorola DSPO

-----Original Message-----
From: Corey, Rick [mailto:]
Sent: Saturday, October 12, 2002 2:43 PM
To: Motodsp (E-mail)
Cc: Nickerson, Steve
Subject: [motoroladsp] USE_NESTED_INTERRUPTS

I have another beginner SDK question, after searching the Yahoo archive
and
all the manuals that seemed relevant.

I seemed to have found an answer, but it didn't seem to work, nor did
any of
the variations I tried.

I'm trying to disable nested interrupts in the SDK. I have some
"impossible" code behavior, and thought it might be due to nested
interrupts
changing the Z bit in the status register behind my back.

Although I'm trying to block nested IRQs, bits [9:8] in the SR are
always
0x01, which seem to enable maskable IRQs (though perhaps the
NestedIPRMask
is blocking them). I see it is the I-one bit (not the I-zero bit as I
thought before) that masks all interrupts except NMIs.

I've tried these three lines (one at a time, of course) in my
appconfig.h
for RAM, and FLASH, as the first changed line:
#DEFINE USE_NESTED_INTERRUPTS NO
#undef USE_NESTED_INTERRUPTS
#DEFINE USE_NESTED_INTERRUPTS YES

Below them, I have these lines:

#define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE
#define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE

void ISR_CAN_Transmit(void); // Thanks, MotoDSP group!
void ISR_CAN_Receive( void);

#define NORMAL_ISR_14 ISR_CAN_Transmit // no "F"!
#define NORMAL_ISR_15 ISR_CAN_Receive

Does " #DEFINE USE_NESTED_INTERRUPTS NO" work for other people here?

Should I also poke configNestedIPRmask[ ] manually?
Does USE_NESTED_INTERRUPTS affect only the IPR masks and not the
status
register I-one bit (bit #9)?

Thanks again for your help, people.

Rick Corey

- - - - -

The reason I'm concerned about nested IRQs is that I can go to mixed
mode
and watch what seems to be wrong behavior for TSTW or BNE (see mixed
display at the end of the email). At the source level, *both* DoA and
DoB
would run.

if (ptr == NULL)
{ DoA }

if (ptr != NULL)
{ DoB }

Elsewhere in my code (like, outside ISRs), the test (ptr == NULL)
seems to
work OK.

I would always execute DoA whether the pointer was zero or not. I would
execute both DoA and DoB on the same pass through the code, if the ptr
was
non-zero, and I wasn't modifying the pointer in DoA.

Just 2-3 times, I saw correct behavior, right after I first added the
line
#DEFINE USE_NESTED_INTERRUPTS YES
However, that behavior "went away". Also, if anything, this should turn
nesting ON.

I could watch BNE branch the same way whether the pointer was 0 or
$20A3.
The sr.Z bit was always set in those tests, but I could see it go to 0
after
the != test (watching only source level).

I don't completely believe that I'm seeing what I'm seeing, so please
don't
take my word for it.
After I'm sure I have nested IRQs blocked I'll report again.

real source code:

volatile struct CanPktBuffer *psTmpDbgPtr;
volatile struct CanPktBuffer *psPRLL_ListHead=NULL;
. . . .

if (psTmpDbgPtr == NULL)
{
psPRLL_ListHead = *ppsPktToInsert; // DoA
}
// there is no "else"
here
if ( psTmpDbgPtr != NULL )
{
// DoB
while ( ( psInsertHere->pnext != NULL ) &&
( psInsertHere->pnext->DataByte[PACKET_LEN] <
(*ppsPktToInsert)->DataByte[PACKET_LEN] ) )
{
psInsertHere = psInsertHere->pnext;
}

etc etc
}

I started out with a simpler:
If ( psPRLL_ListHead == NULL)
{
DoA
}
else
{
DoB
}
and then inserted the TmpPtr, and removed the else, switched the order
of
the ptr and the NULL, in desperation. real mixed mode:
psTmpDbgPtr = psPRLL_ListHead;
P:000002DA: F8542052 move X:0x2052,R0
P:000002DC: 9832 moves R0,X:0x0032

if (psTmpDbgPtr == NULL)
P:000002DD: BE32 tstw X:0x0032
P:000002DE: A203 bne AddPktToPRLL+0x9 (0x2e2); 0x000173
{
psPRLL_ListHead = *ppsPktToInsert;
P:000002DF: F816 move X:(R2),R0
P:000002E0: D8542052 move R0,X:0x2052
}

if ( psTmpDbgPtr != NULL )
P:000002E2: BE32 tstw X:0x0032
P:000002E3: A319 beq AddPktToPRLL+0x24 (0x2fd); 0x00018b
{ // walk
the
ToTxList to insert in order or at end
while ( ( psInsertHere->pnext != NULL ) &&
P:000002E4: A903 bra AddPktToPRLL+0xf (0x2e8); 0x000176
( psInsertHere->pnext->DataByte[PACKET_LEN] <
(*ppsPktToInsert)->DataByte[PACKET_LEN] ) )
{
psInsertHere = psInsertHere->pnext;
P:000002E5: FB43000F move X:(R3+0x000f),R3
P:000002E7: E040 nop
}
P:000002E8: FE43000F tstw X:(R3+0x000f)
P:000002EA: A309 beq AddPktToPRLL+0x1b (0x2f4); 0x00017f
P:000002EB: F843000F move X:(R3+0x000f),R0
P:000002ED: F916 move X:(R2),R1
P:000002EE: F1400004 move X:(R0+0x0004),Y0
P:000002F0: F0410004 move X:(R1+0x0004),X0
P:000002F2: 7C43 cmp X0,Y0
P:000002F3: A171 bcs AddPktToPRLL+0xc (0x2e5); 0x00016b
Rick Corey, Software Development
DPC Instrument Systems Division, Flanders NJ

_____________________________________
Note: If you do a simple "reply" with your email client, only the author
of this message will receive your answer. You need to do a "reply all"
if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp
<http://www.yahoogroups.com/group/motoroladsp>

More Groups: http://www.dsprelated.com/groups.php3
<http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/
_____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp
<http://www.yahoogroups.com/group/motoroladsp>

More Groups: http://www.dsprelated.com/groups.php3
<http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> Service. <http://rd.yahoo.com/M!9695.2310151.3725769.2113459/D=egroupweb/S057718
55:HM/A26184/R=0/*http:/ad.doubleclick.net/jump/N879.ameritrade.yahoo/B10
54521.11;sz00x250;adc=ZHS;ord34639144?
<http://us.adserver.yahoo.com/l?M!9695.2310151.3725769.2113459/D=egroupmai
l/S=:HM/A26184/randT3408226 _____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp
<http://www.yahoogroups.com/group/motoroladsp>

More Groups: http://www.dsprelated.com/groups.php3
<http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> Service.



Hi Rick

Yes, all you have to do to enable nested interrupts is to #define the priorities
to be from 2-7. If you look in the Motorola SDK file "const.c", you can see
that the array "configNestedIPRmask[]" is automatically created from your
#defines of the interrupt priority levels, and the value in
configNestedIPRmask[0] is a Boolean flag for the interrupt dispatcher that
enables nested interrupts. This array is automatically set to enable nested
interrupts when any of the interrupt priorities is greater than 1.

I am posting this message to the motoroladsp discussion group, as I thought the
information about enabling nested interrupts would be useful to other members.

In Vancouver, we don't normally get any frost until late December. Our weather
is _much_ warmer than most of Canada, due to the warm ocean current coming up
from Hawaii. Our temperatures in winter are much like they are in Texas (where
my sister lives), and often we are warmer than Houston or Dallas/Fort Worth.

Art Johnson -----Original Message-----
From: [mailto:]
Sent: Tuesday, October 29, 2002 7:44 AM
To: Art Johnson
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Hi Art

That sounds like a lot of fun. I often wish I had a small wood lathe. I
also had fun, but it was at work, chasing a missed deadline.

I dropped back to non-nestable "Normal" interrupts using the SDK dispatcher,
for now. We are going to pursue some application functionality first to
make our managers stop scowling.

>> One system has a total of 21 interrupts enabled and active. All of these
systems have been running for many months without any hiccups, crashes, or
other strange things happening (other than ones caused by CodeWarrior). <<

This is very re-assuring. If it weren't for you and one or two others
expressing confidence, we would be looking for an alternative to the 803
(and tossing several boards EE designed and weeping and wailing and gnashing
our teeth).

If we find that our stepper motor IRQs do need to interrupt our CANbus IRQs,
we will try out the nestable feature of the SDK. My understanding is that I
should just set some of these lines to 2-7, and the IRQs will become
nestable through dispatcher #ifdefs.

#define GPR_INT_PRIORITY_14 1 // 4 // MSCAN Tx Ready TXEIE
#define GPR_INT_PRIORITY_15 1 // 5 // MSCAN Rx Ready RXFIE
#define GPR_INT_PRIORITY_16 1 // 4 // MSCAN WakeUp WUPIE
#define GPR_INT_PRIORITY_17 1 // 6 // MSCAN Errors RWRNIE
TWRNIE RERRIE TERRIE BOFFIE OVRIE

Thanks for all your help! Good luck with the garden; don't you have heavy
frost already?

Rick Corey

-----Original Message-----
From: Art Johnson [mailto:]
Sent: Thursday, October 24, 2002 9:48 AM
To: Corey, Rick
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Hi Rick,

I had a really good time on my vacation, playing in my garden, and I also
bought a lot of new power tools for my (woodworking) workshop at home.

I just finished clearing up everything that had piled up while I was on
vacation, and reading all my emails.

Are your nested interrupts working OK now? We have several new products
here that use nested interrupts at all 7 priority levels, with both "Normal"
interrupts and "Super Fast" interrupts. One system has a total of 21
interrupts enabled and active. All of these systems have been running for
many months without any hiccups, crashes, or other strange things happening
(other than ones caused by CodeWarrior).

If you are still having problems, please let me know and give me some
details of what is going on.

One thing we do use here (and which I very strongly recommend) is a RealTime
Operating System (RTOS). This allows you to split up your software into
completely independent "tasks", so it is very easy to make sure that there
is no possibility of interaction between different parts of your program.
We use the DSP OS RTOS, here's the link if you're interested:
DSP OS is located at:
<http://www.dspos.com>

Regards,
Art -----Original Message-----
From: Corey, Rick [mailto:]
Sent: Tuesday, October 15, 2002 11:02 AM
To: 'Leonard N. Elevich'; Motodsp (E-mail)
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Leonard,

You are right. I must have pasted an extra #endif into that file days ago,
and never noticed, because I didn't use it until just now.

Thank you!

(putting on a Dunce Cap and sitting in the corner)
Rick Corey -----Original Message-----
From: Leonard N. Elevich [mailto:]
Sent: Tuesday, October 15, 2002 1:45 PM
To: 'Corey, Rick'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS
Rick, in your appconfig.h file for flash configuration you have an extra
#endif at the end of the file. Since this file is included in the config.h,
preprocessor gives you error for config.h file.
Once I removed extra #endif in your appconfig.h file, your project compiled
fine.
Leonard
-----Original Message-----
From: Corey, Rick [mailto:]
Sent: Tuesday, October 15, 2002 9:49 AM
To: 'Leonard N. Elevich'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS
Thank you! I really appreciate this.
Maybe I'm just worn down by missing deadlines and working weekends and
evenings, yet making no progress.
I've tried re-installing the SDK, then got called over to put out another
fire.
Here's the project - oh please tell me that I did something amazingly
stupid!
Rick Corey

-----Original Message-----
From: Leonard N. Elevich [mailto:]
Sent: Tuesday, October 15, 2002 12:13 PM
To: 'Corey, Rick'; 'Motodsp (E-mail)'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS

You don't need to use SDK's INCLUDE_FLASH to target your application into
Flash.
I would be glad to help you figure out your preprocessor problem. If you can
send me your project (zipped) as is, or trim it down to bare code as long as
problem is still there, I will take a look at it.
As far as generation of the pre-processor output, I am not aware of any
options that you can give to CodeWarrior to force the output.
Leonard -----Original Message-----
From: Corey, Rick [mailto:]
Sent: Tuesday, October 15, 2002 8:00 AM
To: 'Leonard N. Elevich'; Motodsp (E-mail)
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS
Thanks for the help and frankness, Leonard.
If I get this working, I'll take out my workarounds and reply to the group
"that worked". However, I have to chase another frustrating problem first.
Rick Corey
P.S. Is there a way to generate pre-processor output?
I'm disenheartened and frustrated again; trying to compile from the SDK for
FLASH instead of external RAM is giving me five compiler errors in config.h,
which I don't feel very safe in modifying. Should we #define INCLUDE_FLASH
just to download to FLASH? Surely not. We can download to FLASH all day in
the non-SDK projects we've built.
"preceding #if is missing

config.h line 2381 #endif"
We've gone through 2,381 lines of config.h without finding why #ifdef and
#ifndef might get unmatched when we go from RAM to FLASH. as far as we can
tell, the .H files we have looked at seem to have matching numbers of
#ifdef + #ifndef and #endif ... as far as we can tell, which only goes so
far due to the conditional degree of nesting of includes and #if s.
We assume that some #define somewhere is interfering with the SDK
config/appconfig mechanism.
I am trying to use the SDK interrupt dispatcher for two non-driver
interrupts - CAN IRQs without the CAN driver.

Of course I am not #define - ing INCLUDE_CAN because we aren't/can't use
the CAN driver as it is.

-----Original Message-----
From: Leonard N. Elevich [mailto:]
Sent: Monday, October 14, 2002 7:45 PM
To: 'Corey, Rick'; 'Motodsp (E-mail)'
Cc: 'Nickerson, Steve'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS

One more clarification about our documentation being wrong. After reading
this portion of the documentation more carefully, you will find that it
doesn't talk about some global macro that you can use to toggle nested
interrupts in the SDK. This example defines this macro in the appconfig.h
for local use only. So SDK documentation is correct. And you have to use
method that I have described in my previous email to disable nested
interrupts.
There is however, another way for you to disable nested interrupts. If you
define all interrupts to be the same priority:
#define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE
#define GPR_INT_PRIORITY_15 4 // MSCAN Rx Ready RXFIE
SDK should disable nested interrupts for you automatically. The only time
SDK re-enables interrupts (uses nested interrupts), is when you use
different interrupt priorities (as in your example).
I still think that example in our documentation is some what misleading (I
misread it just like you), unless you read it very carefully.
Leonard
-----Original Message-----
From: Leonard N. Elevich [mailto:]
Sent: Monday, October 14, 2002 4:31 PM
To: 'Corey, Rick'; 'Motodsp (E-mail)'
Cc: 'Nickerson, Steve'
Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS
Unfortunately, our documentation is wrong. You will not find a single
instance of USE_NESTED_INTERRUPTS in the SDK source files. To turn
nested interrupts off, you will have to open dispatcher.asm file located
in the sys directory, and modify the following line of code:

define SUPPORT_NESTED_INTERRUPTS '1'

You will have to change 1 to 0.

I am not sure why SDK implementation doesn't allow configuration of this
parameter via appconfig.h, while SDK documentation talks about it, and I
apologize for any confusion it caused.

Sincerely,

Leonard N. Elevich
Motorola DSPO

-----Original Message-----
From: Corey, Rick [mailto:]
Sent: Saturday, October 12, 2002 2:43 PM
To: Motodsp (E-mail)
Cc: Nickerson, Steve
Subject: [motoroladsp] USE_NESTED_INTERRUPTS

I have another beginner SDK question, after searching the Yahoo archive
and
all the manuals that seemed relevant.

I seemed to have found an answer, but it didn't seem to work, nor did
any of
the variations I tried.

I'm trying to disable nested interrupts in the SDK. I have some
"impossible" code behavior, and thought it might be due to nested
interrupts
changing the Z bit in the status register behind my back.

Although I'm trying to block nested IRQs, bits [9:8] in the SR are
always
0x01, which seem to enable maskable IRQs (though perhaps the
NestedIPRMask
is blocking them). I see it is the I-one bit (not the I-zero bit as I
thought before) that masks all interrupts except NMIs.

I've tried these three lines (one at a time, of course) in my
appconfig.h
for RAM, and FLASH, as the first changed line:
#DEFINE USE_NESTED_INTERRUPTS NO
#undef USE_NESTED_INTERRUPTS
#DEFINE USE_NESTED_INTERRUPTS YES

Below them, I have these lines:

#define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE
#define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE

void ISR_CAN_Transmit(void); // Thanks, MotoDSP group!
void ISR_CAN_Receive( void);

#define NORMAL_ISR_14 ISR_CAN_Transmit // no "F"!
#define NORMAL_ISR_15 ISR_CAN_Receive

Does " #DEFINE USE_NESTED_INTERRUPTS NO" work for other people here?

Should I also poke configNestedIPRmask[ ] manually?
Does USE_NESTED_INTERRUPTS affect only the IPR masks and not the
status
register I-one bit (bit #9)?

Thanks again for your help, people.

Rick Corey

- - - - -

The reason I'm concerned about nested IRQs is that I can go to mixed
mode
and watch what seems to be wrong behavior for TSTW or BNE (see mixed
display at the end of the email). At the source level, *both* DoA and
DoB
would run.

if (ptr == NULL)
{ DoA }

if (ptr != NULL)
{ DoB }

Elsewhere in my code (like, outside ISRs), the test (ptr == NULL)
seems to
work OK.

I would always execute DoA whether the pointer was zero or not. I would
execute both DoA and DoB on the same pass through the code, if the ptr
was
non-zero, and I wasn't modifying the pointer in DoA.

Just 2-3 times, I saw correct behavior, right after I first added the
line
#DEFINE USE_NESTED_INTERRUPTS YES
However, that behavior "went away". Also, if anything, this should turn
nesting ON.

I could watch BNE branch the same way whether the pointer was 0 or
$20A3.
The sr.Z bit was always set in those tests, but I could see it go to 0
after
the != test (watching only source level).

I don't completely believe that I'm seeing what I'm seeing, so please
don't
take my word for it.
After I'm sure I have nested IRQs blocked I'll report again.

real source code:

volatile struct CanPktBuffer *psTmpDbgPtr;
volatile struct CanPktBuffer *psPRLL_ListHead=NULL;
. . . .

if (psTmpDbgPtr == NULL)
{
psPRLL_ListHead = *ppsPktToInsert; // DoA
}
// there is no "else"
here
if ( psTmpDbgPtr != NULL )
{
// DoB
while ( ( psInsertHere->pnext != NULL ) &&
( psInsertHere->pnext->DataByte[PACKET_LEN] <
(*ppsPktToInsert)->DataByte[PACKET_LEN] ) )
{
psInsertHere = psInsertHere->pnext;
}

etc etc
}

I started out with a simpler:
If ( psPRLL_ListHead == NULL)
{
DoA
}
else
{
DoB
}
and then inserted the TmpPtr, and removed the else, switched the order
of
the ptr and the NULL, in desperation. real mixed mode:
psTmpDbgPtr = psPRLL_ListHead;
P:000002DA: F8542052 move X:0x2052,R0
P:000002DC: 9832 moves R0,X:0x0032

if (psTmpDbgPtr == NULL)
P:000002DD: BE32 tstw X:0x0032
P:000002DE: A203 bne AddPktToPRLL+0x9 (0x2e2); 0x000173
{
psPRLL_ListHead = *ppsPktToInsert;
P:000002DF: F816 move X:(R2),R0
P:000002E0: D8542052 move R0,X:0x2052
}

if ( psTmpDbgPtr != NULL )
P:000002E2: BE32 tstw X:0x0032
P:000002E3: A319 beq AddPktToPRLL+0x24 (0x2fd); 0x00018b
{ // walk
the
ToTxList to insert in order or at end
while ( ( psInsertHere->pnext != NULL ) &&
P:000002E4: A903 bra AddPktToPRLL+0xf (0x2e8); 0x000176
( psInsertHere->pnext->DataByte[PACKET_LEN] <
(*ppsPktToInsert)->DataByte[PACKET_LEN] ) )
{
psInsertHere = psInsertHere->pnext;
P:000002E5: FB43000F move X:(R3+0x000f),R3
P:000002E7: E040 nop
}
P:000002E8: FE43000F tstw X:(R3+0x000f)
P:000002EA: A309 beq AddPktToPRLL+0x1b (0x2f4); 0x00017f
P:000002EB: F843000F move X:(R3+0x000f),R0
P:000002ED: F916 move X:(R2),R1
P:000002EE: F1400004 move X:(R0+0x0004),Y0
P:000002F0: F0410004 move X:(R1+0x0004),X0
P:000002F2: 7C43 cmp X0,Y0
P:000002F3: A171 bcs AddPktToPRLL+0xc (0x2e5); 0x00016b
Rick Corey, Software Development
DPC Instrument Systems Division, Flanders NJ

_____________________________________
Note: If you do a simple "reply" with your email client, only the author
of this message will receive your answer. You need to do a "reply all"
if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp
<http://www.yahoogroups.com/group/motoroladsp>

More Groups: http://www.dsprelated.com/groups.php3
<http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/
_____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp
<http://www.yahoogroups.com/group/motoroladsp>

More Groups: http://www.dsprelated.com/groups.php3
<http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> Service. <http://rd.yahoo.com/M!9695.2310151.3725769.2113459/D=egroupweb/S057718
55:HM/A26184/R=0/*http:/ad.doubleclick.net/jump/N879.ameritrade.yahoo/B10
54521.11;sz00x250;adc=ZHS;ord34639144?
<http://us.adserver.yahoo.com/l?M!9695.2310151.3725769.2113459/D=egroupmai
l/S=:HM/A26184/randT3408226 _____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp
<http://www.yahoogroups.com/group/motoroladsp>

More Groups: http://www.dsprelated.com/groups.php3
<http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> Service. _____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/