Forums

case statements

Started by softoe September 23, 2002
I am using Codewarrior 4.1 for the DSP56F805. I am experiencing
strange problems in a switch/case statement. Note in the code snippet
below the last two cases are commented out; if I uncomment one or
both of them, it compiles fine but then the switch no longer works,
i.e. execution never reaches any of the other cases, as if the entire
switch statement were missing. I comment them and it works fine. Why?

Sean Marble
AMET

switch ( meaning ) {
case MEANING_KILL:
//beginParameterUpdate();
break;
case MEANING_STOPSEGMENT:
//beginParameterUpdate();
break;
case MEANING_STARTSEGMENT:
//beginParameterUpdate();
break;
case MEANING_ATTRIBQUERY:
// Send out attribute data for
specified parameter #:
outData[0] = inMessage.content.data
[0]; // parameter #
// Min:
outData[1] = 1;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 1 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Max:
outData[1] = 2;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 2 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Increment:
outData[1] = 3;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 3 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Default:
outData[1] = 4;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 4 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
break;
case MEANING_STARTUPDATE:
beginParameterUpdate();
break;
case MEANING_UPDATEDATA:
setParameterValue(
inMessage.content.data[0], inMessage.content.data[1], CANdataToFloat
(&inMessage.content.data[2]) );
break;
/*case MEANING_QUERYUPDATE:
if ( isUpdateComplete() )
outData[0] = 1;
else
outData[0] = 0;
sendCANmsg( MEANING_UPDATESTATUS,
false, 1, &outData );
OSTimeDly(1);
break;
case MEANING_ADJUSTOVERRIDE:
break;*/
default: break;
}



Your switch/case statement looks OK. The problem may be due to one of the very
serious bugs we discovered in older versions of CodeWarrior. I would very
strongly recommend that you upgrade to CodeWarrior version 5.0 and the 5.0.2
patch. If your problem still occurs, what we have done here is to make an
example project that can be run on the DSP56F805EVM module and send it to
Metrowerks at:

If you set a breakpoint in your example program just before the switch/case
statement, when the program stops at the breakpoint you can view the
assembly-language instructions by selecting "Mixed" from the "Source" list
pop-up at the bottom of the Source pane in the Debugger Thread Window. This is
described in Chapter 15 "Basic Debugging" in the CodeWarrior IDE 4.2.5 User
Guide. We have found that by looking at the assembly-language instructions, the
bug can usually be spotted quite easily.

CodeWarrior version 4.x (and earlier) has several extremely serious bugs, which
have all been fixed on version 5.0 with the 5.0.2 patch. I would very strongly
recommend that anyone with an older version of CodeWarrior should upgrade to
version 5.0 with the 5.0.2 patch. Two of these extremely serious bugs are
described below (there are quite a few other bugs besides these 2):

1) Local variables inside a function are saved on the stack, but when you use
them the compiler loads the value from a global memory location that has nothing
to do with the stack. Obviously, this can cause your program to have
spectacular and extremely hard-to-find crashes.

2) Memory locations that you have declared as volatile (for example, all of the
DSP chip internal registers) are not accessed correctly. If you read a volatile
memory location several times in a row, it is only accessed the first time and a
cached value is used after that. For example, suppose that you are reading an
input signal from a GPIO port 4 times to see that the value is stable. The
compiler generated code that read the GPIO port the first time and used a cached
value the last 3 times. This could have very serious consequences if (for
example) the DSP chip was used in an Antilock Braking System (ABS), and you were
relying on getting a stable sample of an input signal.

For the above reasons, anyone with an older version of CodeWarrior should
upgrade to version 5.0 with the 5.0.2 patch.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com -----Original Message-----
From: softoe [mailto:]
Sent: Monday, September 23, 2002 12:14 PM
To:
Subject: [motoroladsp] case statements I am using Codewarrior 4.1 for the DSP56F805. I am experiencing
strange problems in a switch/case statement. Note in the code snippet
below the last two cases are commented out; if I uncomment one or
both of them, it compiles fine but then the switch no longer works,
i.e. execution never reaches any of the other cases, as if the entire
switch statement were missing. I comment them and it works fine. Why?

Sean Marble
AMET

switch ( meaning ) {
case MEANING_KILL:
//beginParameterUpdate();
break;
case MEANING_STOPSEGMENT:
//beginParameterUpdate();
break;
case MEANING_STARTSEGMENT:
//beginParameterUpdate();
break;
case MEANING_ATTRIBQUERY:
// Send out attribute data for
specified parameter #:
outData[0] = inMessage.content.data
[0]; // parameter #
// Min:
outData[1] = 1;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 1 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Max:
outData[1] = 2;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 2 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Increment:
outData[1] = 3;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 3 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Default:
outData[1] = 4;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 4 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
break;
case MEANING_STARTUPDATE:
beginParameterUpdate();
break;
case MEANING_UPDATEDATA:
setParameterValue(
inMessage.content.data[0], inMessage.content.data[1], CANdataToFloat
(&inMessage.content.data[2]) );
break;
/*case MEANING_QUERYUPDATE:
if ( isUpdateComplete() )
outData[0] = 1;
else
outData[0] = 0;
sendCANmsg( MEANING_UPDATESTATUS,
false, 1, &outData );
OSTimeDly(1);
break;
case MEANING_ADJUSTOVERRIDE:
break;*/
default: break;
}

_____________________________________
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/


Good day, Art

Thank you (and all the other group members)for all your useful input
so far.

You mentioned that Codewarrior 4 have some serious bugs in it. I
bought Codewarrior on a special deal together with the 56f807evm and
would like to upgrade to Codewarrior 5.

Do you know what the cost involved are?

Kind regards
Roelof Oelofsen

-----Original Message-----
From: Art Johnson [mailto:]
Sent: 24 September 2002 15:25
To: softoe;
Subject: RE: [motoroladsp] case statements Your switch/case statement looks OK. The problem may be due to one of
the very serious bugs we discovered in older versions of CodeWarrior.
I would very strongly recommend that you upgrade to CodeWarrior
version 5.0 and the 5.0.2 patch. If your problem still occurs, what
we have done here is to make an example project that can be run on the
DSP56F805EVM module and send it to Metrowerks at:

If you set a breakpoint in your example program just before the
switch/case statement, when the program stops at the breakpoint you
can view the assembly-language instructions by selecting "Mixed" from
the "Source" list pop-up at the bottom of the Source pane in the
Debugger Thread Window. This is described in Chapter 15 "Basic
Debugging" in the CodeWarrior IDE 4.2.5 User Guide. We have found
that by looking at the assembly-language instructions, the bug can
usually be spotted quite easily.

CodeWarrior version 4.x (and earlier) has several extremely serious
bugs, which have all been fixed on version 5.0 with the 5.0.2 patch.
I would very strongly recommend that anyone with an older version of
CodeWarrior should upgrade to version 5.0 with the 5.0.2 patch. Two
of these extremely serious bugs are described below (there are quite a
few other bugs besides these 2):

1) Local variables inside a function are saved on the stack, but when
you use them the compiler loads the value from a global memory
location that has nothing to do with the stack. Obviously, this can
cause your program to have spectacular and extremely hard-to-find
crashes.

2) Memory locations that you have declared as volatile (for example,
all of the DSP chip internal registers) are not accessed correctly.
If you read a volatile memory location several times in a row, it is
only accessed the first time and a cached value is used after that.
For example, suppose that you are reading an input signal from a GPIO
port 4 times to see that the value is stable. The compiler generated
code that read the GPIO port the first time and used a cached value
the last 3 times. This could have very serious consequences if (for
example) the DSP chip was used in an Antilock Braking System (ABS),
and you were relying on getting a stable sample of an input signal.

For the above reasons, anyone with an older version of CodeWarrior
should upgrade to version 5.0 with the 5.0.2 patch.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com -----Original Message-----
From: softoe [mailto:]
Sent: Monday, September 23, 2002 12:14 PM
To:
Subject: [motoroladsp] case statements I am using Codewarrior 4.1 for the DSP56F805. I am experiencing
strange problems in a switch/case statement. Note in the code snippet
below the last two cases are commented out; if I uncomment one or
both of them, it compiles fine but then the switch no longer works,
i.e. execution never reaches any of the other cases, as if the entire
switch statement were missing. I comment them and it works fine. Why?

Sean Marble
AMET

switch ( meaning ) {
case MEANING_KILL:
//beginParameterUpdate();
break;
case MEANING_STOPSEGMENT:
//beginParameterUpdate();
break;
case MEANING_STARTSEGMENT:
//beginParameterUpdate();
break;
case MEANING_ATTRIBQUERY:
// Send out attribute data for
specified parameter #:
outData[0] = inMessage.content.data
[0]; // parameter #
// Min:
outData[1] = 1;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 1 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Max:
outData[1] = 2;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 2 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Increment:
outData[1] = 3;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 3 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Default:
outData[1] = 4;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 4 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
break;
case MEANING_STARTUPDATE:
beginParameterUpdate();
break;
case MEANING_UPDATEDATA:
setParameterValue(
inMessage.content.data[0], inMessage.content.data[1], CANdataToFloat
(&inMessage.content.data[2]) );
break;
/*case MEANING_QUERYUPDATE:
if ( isUpdateComplete() )
outData[0] = 1;
else
outData[0] = 0;
sendCANmsg( MEANING_UPDATESTATUS,
false, 1, &outData );
OSTimeDly(1);
break;
case MEANING_ADJUSTOVERRIDE:
break;*/
default: break;
}

_____________________________________
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/ ------------------------ Yahoo! Groups Sponsor
---------------------~-->
Sell a Home for Top $
http://us.click.yahoo.com/RrPZMC/jTmEAA/ySSFAA/PNArlB/TM
---------------------------------~
->

_____________________________________
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/


Actually, in my (not-so-humble) opinion, the upgrade should be free due to the
large amount of time and money that these bugs have cost developers everywhere.
I know that here at PMC the bugs we found in CodeWarrior have put us several
months behind schedule. It has got to the point now that if another developer
here has a bug that doesn't look like a problem in their source code, they ask
me to have a look at the assembly language instructions to see if CodeWarrior
has produced bad object code. That's a fact.

Seriously, I do know that we got some kind of special lower price for the
upgrade to version 5.0. I don't know exactly what we paid for the upgrade
because that's handled by our Purchasing department.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com
-----Original Message-----
From: Roelof Oelofsen (RP) [mailto:]
Sent: Thursday, September 26, 2002 11:53 PM
To: Art Johnson; softoe;
Subject: RE: [motoroladsp] case statements Good day, Art

Thank you (and all the other group members)for all your useful input
so far.

You mentioned that Codewarrior 4 have some serious bugs in it. I
bought Codewarrior on a special deal together with the 56f807evm and
would like to upgrade to Codewarrior 5.

Do you know what the cost involved are?

Kind regards
Roelof Oelofsen

-----Original Message-----
From: Art Johnson [mailto:]
Sent: 24 September 2002 15:25
To: softoe;
Subject: RE: [motoroladsp] case statements Your switch/case statement looks OK. The problem may be due to one of
the very serious bugs we discovered in older versions of CodeWarrior.
I would very strongly recommend that you upgrade to CodeWarrior
version 5.0 and the 5.0.2 patch. If your problem still occurs, what
we have done here is to make an example project that can be run on the
DSP56F805EVM module and send it to Metrowerks at:

If you set a breakpoint in your example program just before the
switch/case statement, when the program stops at the breakpoint you
can view the assembly-language instructions by selecting "Mixed" from
the "Source" list pop-up at the bottom of the Source pane in the
Debugger Thread Window. This is described in Chapter 15 "Basic
Debugging" in the CodeWarrior IDE 4.2.5 User Guide. We have found
that by looking at the assembly-language instructions, the bug can
usually be spotted quite easily.

CodeWarrior version 4.x (and earlier) has several extremely serious
bugs, which have all been fixed on version 5.0 with the 5.0.2 patch.
I would very strongly recommend that anyone with an older version of
CodeWarrior should upgrade to version 5.0 with the 5.0.2 patch. Two
of these extremely serious bugs are described below (there are quite a
few other bugs besides these 2):

1) Local variables inside a function are saved on the stack, but when
you use them the compiler loads the value from a global memory
location that has nothing to do with the stack. Obviously, this can
cause your program to have spectacular and extremely hard-to-find
crashes.

2) Memory locations that you have declared as volatile (for example,
all of the DSP chip internal registers) are not accessed correctly.
If you read a volatile memory location several times in a row, it is
only accessed the first time and a cached value is used after that.
For example, suppose that you are reading an input signal from a GPIO
port 4 times to see that the value is stable. The compiler generated
code that read the GPIO port the first time and used a cached value
the last 3 times. This could have very serious consequences if (for
example) the DSP chip was used in an Antilock Braking System (ABS),
and you were relying on getting a stable sample of an input signal.

For the above reasons, anyone with an older version of CodeWarrior
should upgrade to version 5.0 with the 5.0.2 patch.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com -----Original Message-----
From: softoe [mailto:]
Sent: Monday, September 23, 2002 12:14 PM
To:
Subject: [motoroladsp] case statements I am using Codewarrior 4.1 for the DSP56F805. I am experiencing
strange problems in a switch/case statement. Note in the code snippet
below the last two cases are commented out; if I uncomment one or
both of them, it compiles fine but then the switch no longer works,
i.e. execution never reaches any of the other cases, as if the entire
switch statement were missing. I comment them and it works fine. Why?

Sean Marble
AMET

switch ( meaning ) {
case MEANING_KILL:
//beginParameterUpdate();
break;
case MEANING_STOPSEGMENT:
//beginParameterUpdate();
break;
case MEANING_STARTSEGMENT:
//beginParameterUpdate();
break;
case MEANING_ATTRIBQUERY:
// Send out attribute data for
specified parameter #:
outData[0] = inMessage.content.data
[0]; // parameter #
// Min:
outData[1] = 1;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 1 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Max:
outData[1] = 2;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 2 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Increment:
outData[1] = 3;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 3 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Default:
outData[1] = 4;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 4 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
break;
case MEANING_STARTUPDATE:
beginParameterUpdate();
break;
case MEANING_UPDATEDATA:
setParameterValue(
inMessage.content.data[0], inMessage.content.data[1], CANdataToFloat
(&inMessage.content.data[2]) );
break;
/*case MEANING_QUERYUPDATE:
if ( isUpdateComplete() )
outData[0] = 1;
else
outData[0] = 0;
sendCANmsg( MEANING_UPDATESTATUS,
false, 1, &outData );
OSTimeDly(1);
break;
case MEANING_ADJUSTOVERRIDE:
break;*/
default: break;
}

_____________________________________
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/ ------------------------ Yahoo! Groups Sponsor
---------------------~-->
Sell a Home for Top $
http://us.click.yahoo.com/RrPZMC/jTmEAA/ySSFAA/PNArlB/TM
---------------------------------~
->

_____________________________________
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/

_____________________________________
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/



Price for the 5.0 version is $1195. If you have purchased CodeWarrior
4.0 with tech support option, you will receive 70% off when you upgrade
(you will pay $360 for version 5.0). However, if you don't have support
option, you will have to pay full amount of $1195.

Leonard N. Elevich
Motorola DSPO

-----Original Message-----
From: Art Johnson [mailto:]
Sent: Friday, September 27, 2002 5:00 AM
To: Roelof Oelofsen (RP); softoe;
Cc: Kevin Ackerley (E-mail); Ed Baillie (E-mail)
Subject: RE: [motoroladsp] case statements

Actually, in my (not-so-humble) opinion, the upgrade should be free due
to the large amount of time and money that these bugs have cost
developers everywhere. I know that here at PMC the bugs we found in
CodeWarrior have put us several months behind schedule. It has got to
the point now that if another developer here has a bug that doesn't look
like a problem in their source code, they ask me to have a look at the
assembly language instructions to see if CodeWarrior has produced bad
object code. That's a fact.

Seriously, I do know that we got some kind of special lower price for
the upgrade to version 5.0. I don't know exactly what we paid for the
upgrade because that's handled by our Purchasing department.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com
-----Original Message-----
From: Roelof Oelofsen (RP) [mailto:]
Sent: Thursday, September 26, 2002 11:53 PM
To: Art Johnson; softoe;
Subject: RE: [motoroladsp] case statements Good day, Art

Thank you (and all the other group members)for all your useful input
so far.

You mentioned that Codewarrior 4 have some serious bugs in it. I
bought Codewarrior on a special deal together with the 56f807evm and
would like to upgrade to Codewarrior 5.

Do you know what the cost involved are?

Kind regards
Roelof Oelofsen

-----Original Message-----
From: Art Johnson [mailto:]
Sent: 24 September 2002 15:25
To: softoe;
Subject: RE: [motoroladsp] case statements Your switch/case statement looks OK. The problem may be due to one of
the very serious bugs we discovered in older versions of CodeWarrior.
I would very strongly recommend that you upgrade to CodeWarrior
version 5.0 and the 5.0.2 patch. If your problem still occurs, what
we have done here is to make an example project that can be run on the
DSP56F805EVM module and send it to Metrowerks at:

If you set a breakpoint in your example program just before the
switch/case statement, when the program stops at the breakpoint you
can view the assembly-language instructions by selecting "Mixed" from
the "Source" list pop-up at the bottom of the Source pane in the
Debugger Thread Window. This is described in Chapter 15 "Basic
Debugging" in the CodeWarrior IDE 4.2.5 User Guide. We have found
that by looking at the assembly-language instructions, the bug can
usually be spotted quite easily.

CodeWarrior version 4.x (and earlier) has several extremely serious
bugs, which have all been fixed on version 5.0 with the 5.0.2 patch.
I would very strongly recommend that anyone with an older version of
CodeWarrior should upgrade to version 5.0 with the 5.0.2 patch. Two
of these extremely serious bugs are described below (there are quite a
few other bugs besides these 2):

1) Local variables inside a function are saved on the stack, but when
you use them the compiler loads the value from a global memory
location that has nothing to do with the stack. Obviously, this can
cause your program to have spectacular and extremely hard-to-find
crashes.

2) Memory locations that you have declared as volatile (for example,
all of the DSP chip internal registers) are not accessed correctly.
If you read a volatile memory location several times in a row, it is
only accessed the first time and a cached value is used after that.
For example, suppose that you are reading an input signal from a GPIO
port 4 times to see that the value is stable. The compiler generated
code that read the GPIO port the first time and used a cached value
the last 3 times. This could have very serious consequences if (for
example) the DSP chip was used in an Antilock Braking System (ABS),
and you were relying on getting a stable sample of an input signal.

For the above reasons, anyone with an older version of CodeWarrior
should upgrade to version 5.0 with the 5.0.2 patch.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com -----Original Message-----
From: softoe [mailto:]
Sent: Monday, September 23, 2002 12:14 PM
To:
Subject: [motoroladsp] case statements I am using Codewarrior 4.1 for the DSP56F805. I am experiencing
strange problems in a switch/case statement. Note in the code snippet
below the last two cases are commented out; if I uncomment one or
both of them, it compiles fine but then the switch no longer works,
i.e. execution never reaches any of the other cases, as if the entire
switch statement were missing. I comment them and it works fine. Why?

Sean Marble
AMET

switch ( meaning ) {
case MEANING_KILL:
//beginParameterUpdate();
break;
case MEANING_STOPSEGMENT:
//beginParameterUpdate();
break;
case MEANING_STARTSEGMENT:
//beginParameterUpdate();
break;
case MEANING_ATTRIBQUERY:
// Send out attribute data for
specified parameter #:
outData[0] = inMessage.content.data
[0]; // parameter #
// Min:
outData[1] = 1;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 1 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Max:
outData[1] = 2;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 2 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Increment:
outData[1] = 3;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 3 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Default:
outData[1] = 4;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 4 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
break;
case MEANING_STARTUPDATE:
beginParameterUpdate();
break;
case MEANING_UPDATEDATA:
setParameterValue(
inMessage.content.data[0], inMessage.content.data[1], CANdataToFloat
(&inMessage.content.data[2]) );
break;
/*case MEANING_QUERYUPDATE:
if ( isUpdateComplete() )
outData[0] = 1;
else
outData[0] = 0;
sendCANmsg( MEANING_UPDATESTATUS,
false, 1, &outData );
OSTimeDly(1);
break;
case MEANING_ADJUSTOVERRIDE:
break;*/
default: break;
}

_____________________________________
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/ ------------------------ Yahoo! Groups Sponsor
---------------------~-->
Sell a Home for Top $
http://us.click.yahoo.com/RrPZMC/jTmEAA/ySSFAA/PNArlB/TM
---------------------------------~
->

_____________________________________
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/

_____________________________________
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/
_____________________________________
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/



I agree with Art. We have had numerous problems of this nature with
Codewarrior 4.1. You should offer a free or heavily discounted upgrade for
us suckers who bought version 4. At the very least put out free patches that
fix the bugs. A C compiler that can't handle some case statements? Come on.

Sean Marble
AMET, Inc.

-----Original Message-----
From: Motorola DSPD News [mailto:]
Sent: Friday, September 27, 2002 1:53 PM
To: 'Art Johnson'; 'Roelof Oelofsen (RP)'; 'softoe';

Cc: 'Kevin Ackerley (E-mail)'; 'Ed Baillie (E-mail)'
Subject: RE: [motoroladsp] case statements Price for the 5.0 version is $1195. If you have purchased CodeWarrior
4.0 with tech support option, you will receive 70% off when you upgrade
(you will pay $360 for version 5.0). However, if you don't have support
option, you will have to pay full amount of $1195.

Leonard N. Elevich
Motorola DSPO

-----Original Message-----
From: Art Johnson [mailto:]
Sent: Friday, September 27, 2002 5:00 AM
To: Roelof Oelofsen (RP); softoe;
Cc: Kevin Ackerley (E-mail); Ed Baillie (E-mail)
Subject: RE: [motoroladsp] case statements

Actually, in my (not-so-humble) opinion, the upgrade should be free due
to the large amount of time and money that these bugs have cost
developers everywhere. I know that here at PMC the bugs we found in
CodeWarrior have put us several months behind schedule. It has got to
the point now that if another developer here has a bug that doesn't look
like a problem in their source code, they ask me to have a look at the
assembly language instructions to see if CodeWarrior has produced bad
object code. That's a fact.

Seriously, I do know that we got some kind of special lower price for
the upgrade to version 5.0. I don't know exactly what we paid for the
upgrade because that's handled by our Purchasing department.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com
-----Original Message-----
From: Roelof Oelofsen (RP) [mailto:]
Sent: Thursday, September 26, 2002 11:53 PM
To: Art Johnson; softoe;
Subject: RE: [motoroladsp] case statements Good day, Art

Thank you (and all the other group members)for all your useful input
so far.

You mentioned that Codewarrior 4 have some serious bugs in it. I
bought Codewarrior on a special deal together with the 56f807evm and
would like to upgrade to Codewarrior 5.

Do you know what the cost involved are?

Kind regards
Roelof Oelofsen

-----Original Message-----
From: Art Johnson [mailto:]
Sent: 24 September 2002 15:25
To: softoe;
Subject: RE: [motoroladsp] case statements Your switch/case statement looks OK. The problem may be due to one of
the very serious bugs we discovered in older versions of CodeWarrior.
I would very strongly recommend that you upgrade to CodeWarrior
version 5.0 and the 5.0.2 patch. If your problem still occurs, what
we have done here is to make an example project that can be run on the
DSP56F805EVM module and send it to Metrowerks at:

If you set a breakpoint in your example program just before the
switch/case statement, when the program stops at the breakpoint you
can view the assembly-language instructions by selecting "Mixed" from
the "Source" list pop-up at the bottom of the Source pane in the
Debugger Thread Window. This is described in Chapter 15 "Basic
Debugging" in the CodeWarrior IDE 4.2.5 User Guide. We have found
that by looking at the assembly-language instructions, the bug can
usually be spotted quite easily.

CodeWarrior version 4.x (and earlier) has several extremely serious
bugs, which have all been fixed on version 5.0 with the 5.0.2 patch.
I would very strongly recommend that anyone with an older version of
CodeWarrior should upgrade to version 5.0 with the 5.0.2 patch. Two
of these extremely serious bugs are described below (there are quite a
few other bugs besides these 2):

1) Local variables inside a function are saved on the stack, but when
you use them the compiler loads the value from a global memory
location that has nothing to do with the stack. Obviously, this can
cause your program to have spectacular and extremely hard-to-find
crashes.

2) Memory locations that you have declared as volatile (for example,
all of the DSP chip internal registers) are not accessed correctly.
If you read a volatile memory location several times in a row, it is
only accessed the first time and a cached value is used after that.
For example, suppose that you are reading an input signal from a GPIO
port 4 times to see that the value is stable. The compiler generated
code that read the GPIO port the first time and used a cached value
the last 3 times. This could have very serious consequences if (for
example) the DSP chip was used in an Antilock Braking System (ABS),
and you were relying on getting a stable sample of an input signal.

For the above reasons, anyone with an older version of CodeWarrior
should upgrade to version 5.0 with the 5.0.2 patch.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com -----Original Message-----
From: softoe [mailto:]
Sent: Monday, September 23, 2002 12:14 PM
To:
Subject: [motoroladsp] case statements I am using Codewarrior 4.1 for the DSP56F805. I am experiencing
strange problems in a switch/case statement. Note in the code snippet
below the last two cases are commented out; if I uncomment one or
both of them, it compiles fine but then the switch no longer works,
i.e. execution never reaches any of the other cases, as if the entire
switch statement were missing. I comment them and it works fine. Why?

Sean Marble
AMET

switch ( meaning ) {
case MEANING_KILL:
//beginParameterUpdate();
break;
case MEANING_STOPSEGMENT:
//beginParameterUpdate();
break;
case MEANING_STARTSEGMENT:
//beginParameterUpdate();
break;
case MEANING_ATTRIBQUERY:
// Send out attribute data for
specified parameter #:
outData[0] = inMessage.content.data
[0]; // parameter #
// Min:
outData[1] = 1;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 1 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Max:
outData[1] = 2;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 2 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Increment:
outData[1] = 3;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 3 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Default:
outData[1] = 4;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 4 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
break;
case MEANING_STARTUPDATE:
beginParameterUpdate();
break;
case MEANING_UPDATEDATA:
setParameterValue(
inMessage.content.data[0], inMessage.content.data[1], CANdataToFloat
(&inMessage.content.data[2]) );
break;
/*case MEANING_QUERYUPDATE:
if ( isUpdateComplete() )
outData[0] = 1;
else
outData[0] = 0;
sendCANmsg( MEANING_UPDATESTATUS,
false, 1, &outData );
OSTimeDly(1);
break;
case MEANING_ADJUSTOVERRIDE:
break;*/
default: break;
}

_____________________________________
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/ ------------------------ Yahoo! Groups Sponsor
---------------------~-->
Sell a Home for Top $
http://us.click.yahoo.com/RrPZMC/jTmEAA/ySSFAA/PNArlB/TM
---------------------------------~
->

_____________________________________
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/

_____________________________________
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/
_____________________________________
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/



While we're on the subject of CodeWarrior, you may find it interesting to read
about my experiences with this product, and my opinion of how it compares to the
other compilers/linkers/debuggers I have used in the last 26+ years of
developing software.

First off, here's my own personal rating system for this sort of product. Each
item is given its rating of importance, with the total being 100%. For the
really important items (1, 2, 3, and 4), the product gets either the full rating
or nothing (ie either you fully comply with the ANSI C standard, or you don't).
If you consider this to be unfair, you can use your own rating system.

1. Compiler fully complies with the ANSI C standard
(exceptions are permitted only where the chip
architecture forces non-compliance):
Rating: 30%
2. Compiler generates code that does what you wrote
in your C source code:
Rating: 30%
3. Compiler generates highly optimized code when you
select a high level of optimization:
Rating: 15%
4. Debugger accurately shows you all data regardless
of the optimization level you have selected:
Rating: 15%
5. There is a fancy IDE with lots of point-and-click
bells and whistles:
Rating: 10%

Here are the ratings I have given based on my experiences with CodeWarrior 4.x
and 5.0:

CodeWarrior 4.x:
1. 0%
2. 0%
3. 0%
4. 0%
5. 10%
----
Total: 10%

CodeWarrior 5.0:
1. 0%
2. 30%
3. 0%
4. 0%
5. 10%
----
Total: 40%

Again, you can use your own rating system if you think I am being unfair. It
may also interest you to know that most of the compiler/linker/debugger systems
I have used in the past would receive a 100% score using this rating system.

What is my justification for each of the above ratings? I'm glad you asked.
Here they are:

1. CodeWarrior 4.x violated the ANSI C standard on the meaning of the keyword
'volatile'. This was fixed in CodeWarrior 5.0, but they (apparently
deliberately) introduced a violation of the keyword 'const'. This last one cost
me 2 weeks work (or, more truthfully, wasted time).

2. CodeWarrior 4.x has a bug where local variables inside a function are saved
on the stack, but when you use them the compiler loads the value from a global
memory location that has nothing to do with the stack. This bug has been fixed
in version 5.0.

3. CodeWarrior 4.x and 5.0 both generate a large number of unnecessary register
loads, even when you have selected the highest level of optimization. Here's an
example of the code that's produced when I select "Optimize for Faster Execution
Speed" and "Optimization Level 4" (the highest setting) (also note that
"Optimize for Faster Execution Speed" and "Optimize for Smaller Code Size"
produce exactly the same results at this level of optimization):
My source code:
p_mbus_data->signals = 0; // Signals for the Application Layer
p_mbus_data->rx_ind_timer = 0; // Receive indication timer
p_mbus_data->tx_conf_timer = 0; // Transmit confirmation timer
p_mbus_data->rx_frames = 0; // Total received frames
p_mbus_data->rx_bus_msg_cnt = 0; // Total messages addressed to us
p_mbus_data->rx_crc_err_cnt = 0; // Total CRC errors
p_mbus_data->rx_bufs_dumped = 0; // Receive buffers dumped
p_mbus_data->rx_failure_cnt = 0; // Rx failures (timed out)
p_mbus_data->tx_exc_err_cnt = 0; // Total Exception response messages
p_mbus_data->tx_slave_msg_cnt = 0; // Total non-exception response msgs
p_mbus_data->tx_frames = 0; // Total transmitted frames
p_mbus_data->tx_failure_cnt = 0; // Tx failures (timed out)
p_mbus_data->p_tx_buf = NULL; // Pointer to the transmit
communication buffer
CodeWarrior's generated code for the above:
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0002)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0003)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0004)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0005)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0006)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0007)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0008)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0009)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000a)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000b)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000c)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000d)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0016)
The above is a total of 52 words. Now here's what a good optimizing compiler
would generate:
clr x0
move x0,X:(R2+0x0002)
move x0,X:(R2+0x0003)
move x0,X:(R2+0x0004)
move x0,X:(R2+0x0005)
move x0,X:(R2+0x0006)
move x0,X:(R2+0x0007)
move x0,X:(R2+0x0008)
move x0,X:(R2+0x0009)
move x0,X:(R2+0x000a)
move x0,X:(R2+0x000b)
move x0,X:(R2+0x000c)
move x0,X:(R2+0x000d)
move x0,X:(R2+0x0016)
The properly optimized code is a total of 14 words. So, CodeWarrior has
generated object code that is 371% of the size of properly optimized code in
this example.

4. The CodeWarrior debugger does not display data or the stack frame correctly
when higher levels of optimization are used. You can read all about it in the
attached email. Just another week's work down the drain.

I would welcome hearing about anyone else's experiences with CodeWarrior for
DSP56800.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com

-----Original Message-----
From: Sean Marble [mailto:]
Sent: Friday, September 27, 2002 4:06 PM
To: Motorola DSPD News; Art Johnson; 'Roelof Oelofsen (RP)';

Cc: 'Kevin Ackerley (E-mail)'; 'Ed Baillie (E-mail)'
Subject: RE: [motoroladsp] case statements I agree with Art. We have had numerous problems of this nature with
Codewarrior 4.1. You should offer a free or heavily discounted upgrade for
us suckers who bought version 4. At the very least put out free patches that
fix the bugs. A C compiler that can't handle some case statements? Come on.

Sean Marble
AMET, Inc.

-----Original Message-----
From: Motorola DSPD News [mailto:]
Sent: Friday, September 27, 2002 1:53 PM
To: 'Art Johnson'; 'Roelof Oelofsen (RP)'; 'softoe';

Cc: 'Kevin Ackerley (E-mail)'; 'Ed Baillie (E-mail)'
Subject: RE: [motoroladsp] case statements Price for the 5.0 version is $1195. If you have purchased CodeWarrior
4.0 with tech support option, you will receive 70% off when you upgrade
(you will pay $360 for version 5.0). However, if you don't have support
option, you will have to pay full amount of $1195.

Leonard N. Elevich
Motorola DSPO

-----Original Message-----
From: Art Johnson [mailto:]
Sent: Friday, September 27, 2002 5:00 AM
To: Roelof Oelofsen (RP); softoe;
Cc: Kevin Ackerley (E-mail); Ed Baillie (E-mail)
Subject: RE: [motoroladsp] case statements

Actually, in my (not-so-humble) opinion, the upgrade should be free due
to the large amount of time and money that these bugs have cost
developers everywhere. I know that here at PMC the bugs we found in
CodeWarrior have put us several months behind schedule. It has got to
the point now that if another developer here has a bug that doesn't look
like a problem in their source code, they ask me to have a look at the
assembly language instructions to see if CodeWarrior has produced bad
object code. That's a fact.

Seriously, I do know that we got some kind of special lower price for
the upgrade to version 5.0. I don't know exactly what we paid for the
upgrade because that's handled by our Purchasing department.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com
-----Original Message-----
From: Roelof Oelofsen (RP) [mailto:]
Sent: Thursday, September 26, 2002 11:53 PM
To: Art Johnson; softoe;
Subject: RE: [motoroladsp] case statements Good day, Art

Thank you (and all the other group members)for all your useful input
so far.

You mentioned that Codewarrior 4 have some serious bugs in it. I
bought Codewarrior on a special deal together with the 56f807evm and
would like to upgrade to Codewarrior 5.

Do you know what the cost involved are?

Kind regards
Roelof Oelofsen

-----Original Message-----
From: Art Johnson [mailto:]
Sent: 24 September 2002 15:25
To: softoe;
Subject: RE: [motoroladsp] case statements Your switch/case statement looks OK. The problem may be due to one of
the very serious bugs we discovered in older versions of CodeWarrior.
I would very strongly recommend that you upgrade to CodeWarrior
version 5.0 and the 5.0.2 patch. If your problem still occurs, what
we have done here is to make an example project that can be run on the
DSP56F805EVM module and send it to Metrowerks at:

If you set a breakpoint in your example program just before the
switch/case statement, when the program stops at the breakpoint you
can view the assembly-language instructions by selecting "Mixed" from
the "Source" list pop-up at the bottom of the Source pane in the
Debugger Thread Window. This is described in Chapter 15 "Basic
Debugging" in the CodeWarrior IDE 4.2.5 User Guide. We have found
that by looking at the assembly-language instructions, the bug can
usually be spotted quite easily.

CodeWarrior version 4.x (and earlier) has several extremely serious
bugs, which have all been fixed on version 5.0 with the 5.0.2 patch.
I would very strongly recommend that anyone with an older version of
CodeWarrior should upgrade to version 5.0 with the 5.0.2 patch. Two
of these extremely serious bugs are described below (there are quite a
few other bugs besides these 2):

1) Local variables inside a function are saved on the stack, but when
you use them the compiler loads the value from a global memory
location that has nothing to do with the stack. Obviously, this can
cause your program to have spectacular and extremely hard-to-find
crashes.

2) Memory locations that you have declared as volatile (for example,
all of the DSP chip internal registers) are not accessed correctly.
If you read a volatile memory location several times in a row, it is
only accessed the first time and a cached value is used after that.
For example, suppose that you are reading an input signal from a GPIO
port 4 times to see that the value is stable. The compiler generated
code that read the GPIO port the first time and used a cached value
the last 3 times. This could have very serious consequences if (for
example) the DSP chip was used in an Antilock Braking System (ABS),
and you were relying on getting a stable sample of an input signal.

For the above reasons, anyone with an older version of CodeWarrior
should upgrade to version 5.0 with the 5.0.2 patch.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com -----Original Message-----
From: softoe [mailto:]
Sent: Monday, September 23, 2002 12:14 PM
To:
Subject: [motoroladsp] case statements I am using Codewarrior 4.1 for the DSP56F805. I am experiencing
strange problems in a switch/case statement. Note in the code snippet
below the last two cases are commented out; if I uncomment one or
both of them, it compiles fine but then the switch no longer works,
i.e. execution never reaches any of the other cases, as if the entire
switch statement were missing. I comment them and it works fine. Why?

Sean Marble
AMET

switch ( meaning ) {
case MEANING_KILL:
//beginParameterUpdate();
break;
case MEANING_STOPSEGMENT:
//beginParameterUpdate();
break;
case MEANING_STARTSEGMENT:
//beginParameterUpdate();
break;
case MEANING_ATTRIBQUERY:
// Send out attribute data for
specified parameter #:
outData[0] = inMessage.content.data
[0]; // parameter #
// Min:
outData[1] = 1;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 1 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Max:
outData[1] = 2;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 2 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Increment:
outData[1] = 3;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 3 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Default:
outData[1] = 4;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 4 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
break;
case MEANING_STARTUPDATE:
beginParameterUpdate();
break;
case MEANING_UPDATEDATA:
setParameterValue(
inMessage.content.data[0], inMessage.content.data[1], CANdataToFloat
(&inMessage.content.data[2]) );
break;
/*case MEANING_QUERYUPDATE:
if ( isUpdateComplete() )
outData[0] = 1;
else
outData[0] = 0;
sendCANmsg( MEANING_UPDATESTATUS,
false, 1, &outData );
OSTimeDly(1);
break;
case MEANING_ADJUSTOVERRIDE:
break;*/
default: break;
}

_____________________________________
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/ ------------------------ Yahoo! Groups Sponsor
---------------------~-->
Sell a Home for Top $
http://us.click.yahoo.com/RrPZMC/jTmEAA/ySSFAA/PNArlB/TM
---------------------------------~
->

_____________________________________
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/

_____________________________________
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/
_____________________________________
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/ _____________________________________
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/



From:  "Art Johnson" <>
Date:  Thu Aug 29, 2002  10:22 pm
Subject:  RE: 1-25899146
To:  "Tech Support" <>

Hello Hong,

Thanks for your message, and your suggestion for a workaround.

It is surprising for me that optimization should be turned off when you want to
use the debugger. None of the other IDEs I have used in the past has had this
requirement. I think it would be a significant improvement in CodeWarrior for
Motorola DSP56800 if this restriction could be removed.

Unfortunately, our application program is so large that when optimization is
turned off, it exceeds the size of Program Flash (60K) in the DSP56F807 chip.
The DSP56F807 chip has the largest Program Flash size in the 56800 family, so we
cannot go to a larger chip for debugging.

We do have an active Service Request (SR Number: 1-13810245, removing
unnecessary register loads) that would help with this problem. Even with
optimization turned on to the highest level (Level 4), CodeWarrior generates
large numbers of unnecessary register loads in the program. If these
unnecessary loads were removed, the overall program size would be significantly
reduced, based on the assembly code output I have looked at.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com -----Original Message-----
From: Tech Support [mailto:]
Sent: Thursday, August 29, 2002 1:33 PM
To: Art Johnson
Subject: Re: 1-25899146 Hello ART,

Thank you for your contacting Metrowerks Technical Support. Please see my
comments below.....

SR Number: 1-25899146
Abstract: CodeWarrior for Motorola DSP56800 IDE bug report
Product: CE-DSP4.0__Each
Opened On: 8/28/2002 10:14:35 AM

Answer\Message:
********************************************************************************
We have realized that it is not a bug. CodeWarrior doesn't support optimization
during debugging. You need to turn off optimization during debugging.

You may like to create another target for debugging purpose only. What we should
to do in this debugging target are as below:
1. uncheck "Peephole Optimization" and "Instruction Scheduling" options at
Target Settings Panels> Code Generation> M56800 Processor.
2. You can get the correct result with step one, but you also should turn off
optimization for whole program at Target Settings Panels> Code Generation >
Global Optimizations.(Currently the optimization is Level 4).

I hope it can help.

Regards,

Hong Ye
Metrowerks Technical Support
********************************************************************************

Description:
********************************************************************************
Thanks for your fast response to our Bug Report, and your suggestion for
a workaround.

Unfortunately, we cannot make the variables "PID" and "p_comm_buf"
static, because they are the parameters that are passed to the function
J1587_Parse_Single_Byte_Params(). Also, in most of our functions we
cannot make the local data "static", because we use a Real Time
Operating System (RTOS), so the functions must be reentrant (ie
"thread-safe") and therefore we cannot use any "static" data.

So, we will have to wait for a suitable workaround or fix for these
bugs.
********************************************************************************
If you need further assistance, please call us at 1-800-377-5416 or visit our
web site at http://www.metrowerks.com/.


Good morning all,

Seems like I am in the same situation as a lot of the people
subscribed to this newsgroup.

I work for a telecomms company where, in my humble opinion, DSP is one
of the most needed tools that one can get. Because of restructuring
and maybe also because they do not see the need for DSP, there is very
little funds available to buy DSP compilers and supported equipment.
Our exhange rate (I live in South Africa) makes it even more
difficult.

So along comes the offer from Avnett Kopp on the Motorola DSP and I
decided to spend my own money on the EVM/C-compiler for the following
reasons:
1. The company that I work for, will surely gain from the knowledge
that I am gaining on the DSP, especially since Motorola provides a
free SDK with a lot of telecomms stuff.
2. It is a ideal opportunity to convert all my theory knowledge to
hands-on knowledge.
3. I have the opportunity to work with one of the best 16bit fixed
point processors presently available (I still believe that this is one
of the best processors available presently, together with the SDk and
other software provided with the EVM)
4. Maybe I could do a bit of audio processing as well.

So now you can understand why what I am reading in the newsgroup is a
bit of a concern to me. The simple fact is that I will continue to use
Codewarrior 4.0 even if there appear to be major bugs in it.

What Art is saying makes a lot of sense. I do not have his experience
to agree or contradict his findings, but because I am using the tools,
I will surely take note of what he is saying. I myself have found a
few "bugs", but more in the SDK.

I also take note what Ron is saying and it is good to note that steps
are taken to try and solve all this issues.

So my conclusion is this: Is there any free solutions to the problem
for people like me? If not, what motivation can I use to spend more of
my hard earned money on an upgrade?

Kind regards
Roelof Oelofsen
Tlekom Development Laboratory
Telkom SA

P.S. Art, what is your findings of the DSP56F8XX DSP's and can you use
this for good quality audio processing (despite the limited dynamic
range of 16bit fixed point?). All input welcome -----Original Message-----
From: Art Johnson [mailto:]
Sent: 30 September 2002 15:00
To: ; Motorola DSPD News; Roelof Oelofsen (RP);

Cc: Kevin Ackerley (E-mail); Ed Baillie (E-mail)
Subject: RE: [motoroladsp] case statements While we're on the subject of CodeWarrior, you may find it interesting
to read about my experiences with this product, and my opinion of how
it compares to the other compilers/linkers/debuggers I have used in
the last 26+ years of developing software.

First off, here's my own personal rating system for this sort of
product. Each item is given its rating of importance, with the total
being 100%. For the really important items (1, 2, 3, and 4), the
product gets either the full rating or nothing (ie either you fully
comply with the ANSI C standard, or you don't). If you consider this
to be unfair, you can use your own rating system.

1. Compiler fully complies with the ANSI C standard
(exceptions are permitted only where the chip
architecture forces non-compliance):
Rating: 30%
2. Compiler generates code that does what you wrote
in your C source code:
Rating: 30%
3. Compiler generates highly optimized code when you
select a high level of optimization:
Rating: 15%
4. Debugger accurately shows you all data regardless
of the optimization level you have selected:
Rating: 15%
5. There is a fancy IDE with lots of point-and-click
bells and whistles:
Rating: 10%

Here are the ratings I have given based on my experiences with
CodeWarrior 4.x and 5.0:

CodeWarrior 4.x:
1. 0%
2. 0%
3. 0%
4. 0%
5. 10%
----
Total: 10%

CodeWarrior 5.0:
1. 0%
2. 30%
3. 0%
4. 0%
5. 10%
----
Total: 40%

Again, you can use your own rating system if you think I am being
unfair. It may also interest you to know that most of the
compiler/linker/debugger systems I have used in the past would receive
a 100% score using this rating system.

What is my justification for each of the above ratings? I'm glad you
asked. Here they are:

1. CodeWarrior 4.x violated the ANSI C standard on the meaning of the
keyword 'volatile'. This was fixed in CodeWarrior 5.0, but they
(apparently deliberately) introduced a violation of the keyword
'const'. This last one cost me 2 weeks work (or, more truthfully,
wasted time).

2. CodeWarrior 4.x has a bug where local variables inside a function
are saved on the stack, but when you use them the compiler loads the
value from a global memory location that has nothing to do with the
stack. This bug has been fixed in version 5.0.

3. CodeWarrior 4.x and 5.0 both generate a large number of
unnecessary register loads, even when you have selected the highest
level of optimization. Here's an example of the code that's produced
when I select "Optimize for Faster Execution Speed" and "Optimization
Level 4" (the highest setting) (also note that "Optimize for Faster
Execution Speed" and "Optimize for Smaller Code Size" produce exactly
the same results at this level of optimization):
My source code:
p_mbus_data->signals = 0; // Signals for the
Application Layer
p_mbus_data->rx_ind_timer = 0; // Receive indication
timer
p_mbus_data->tx_conf_timer = 0; // Transmit
confirmation timer
p_mbus_data->rx_frames = 0; // Total received frames
p_mbus_data->rx_bus_msg_cnt = 0; // Total messages addressed to
us
p_mbus_data->rx_crc_err_cnt = 0; // Total CRC errors
p_mbus_data->rx_bufs_dumped = 0; // Receive buffers dumped
p_mbus_data->rx_failure_cnt = 0; // Rx failures (timed out)
p_mbus_data->tx_exc_err_cnt = 0; // Total Exception response
messages
p_mbus_data->tx_slave_msg_cnt = 0; // Total non-exception
response msgs
p_mbus_data->tx_frames = 0; // Total transmitted frames
p_mbus_data->tx_failure_cnt = 0; // Tx failures (timed out)
p_mbus_data->p_tx_buf = NULL; // Pointer to the transmit
communication buffer
CodeWarrior's generated code for the above:
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0002)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0003)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0004)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0005)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0006)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0007)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0008)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0009)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000a)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000b)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000c)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000d)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0016)
The above is a total of 52 words. Now here's what a good optimizing
compiler would generate:
clr x0
move x0,X:(R2+0x0002)
move x0,X:(R2+0x0003)
move x0,X:(R2+0x0004)
move x0,X:(R2+0x0005)
move x0,X:(R2+0x0006)
move x0,X:(R2+0x0007)
move x0,X:(R2+0x0008)
move x0,X:(R2+0x0009)
move x0,X:(R2+0x000a)
move x0,X:(R2+0x000b)
move x0,X:(R2+0x000c)
move x0,X:(R2+0x000d)
move x0,X:(R2+0x0016)
The properly optimized code is a total of 14 words. So, CodeWarrior
has generated object code that is 371% of the size of properly
optimized code in this example.

4. The CodeWarrior debugger does not display data or the stack frame
correctly when higher levels of optimization are used. You can read
all about it in the attached email. Just another week's work down the
drain.

I would welcome hearing about anyone else's experiences with
CodeWarrior for DSP56800.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com

-----Original Message-----
From: Sean Marble [mailto:]
Sent: Friday, September 27, 2002 4:06 PM
To: Motorola DSPD News; Art Johnson; 'Roelof Oelofsen (RP)';

Cc: 'Kevin Ackerley (E-mail)'; 'Ed Baillie (E-mail)'
Subject: RE: [motoroladsp] case statements I agree with Art. We have had numerous problems of this nature with
Codewarrior 4.1. You should offer a free or heavily discounted upgrade
for
us suckers who bought version 4. At the very least put out free
patches that
fix the bugs. A C compiler that can't handle some case statements?
Come on.

Sean Marble
AMET, Inc.

-----Original Message-----
From: Motorola DSPD News [mailto:]
Sent: Friday, September 27, 2002 1:53 PM
To: 'Art Johnson'; 'Roelof Oelofsen (RP)'; 'softoe';

Cc: 'Kevin Ackerley (E-mail)'; 'Ed Baillie (E-mail)'
Subject: RE: [motoroladsp] case statements Price for the 5.0 version is $1195. If you have purchased CodeWarrior
4.0 with tech support option, you will receive 70% off when you
upgrade
(you will pay $360 for version 5.0). However, if you don't have
support
option, you will have to pay full amount of $1195.

Leonard N. Elevich
Motorola DSPO

-----Original Message-----
From: Art Johnson [mailto:]
Sent: Friday, September 27, 2002 5:00 AM
To: Roelof Oelofsen (RP); softoe;
Cc: Kevin Ackerley (E-mail); Ed Baillie (E-mail)
Subject: RE: [motoroladsp] case statements

Actually, in my (not-so-humble) opinion, the upgrade should be free
due
to the large amount of time and money that these bugs have cost
developers everywhere. I know that here at PMC the bugs we found in
CodeWarrior have put us several months behind schedule. It has got to
the point now that if another developer here has a bug that doesn't
look
like a problem in their source code, they ask me to have a look at the
assembly language instructions to see if CodeWarrior has produced bad
object code. That's a fact.

Seriously, I do know that we got some kind of special lower price for
the upgrade to version 5.0. I don't know exactly what we paid for the
upgrade because that's handled by our Purchasing department.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com
-----Original Message-----
From: Roelof Oelofsen (RP) [mailto:]
Sent: Thursday, September 26, 2002 11:53 PM
To: Art Johnson; softoe;
Subject: RE: [motoroladsp] case statements Good day, Art

Thank you (and all the other group members)for all your useful input
so far.

You mentioned that Codewarrior 4 have some serious bugs in it. I
bought Codewarrior on a special deal together with the 56f807evm and
would like to upgrade to Codewarrior 5.

Do you know what the cost involved are?

Kind regards
Roelof Oelofsen

-----Original Message-----
From: Art Johnson [mailto:]
Sent: 24 September 2002 15:25
To: softoe;
Subject: RE: [motoroladsp] case statements Your switch/case statement looks OK. The problem may be due to one of
the very serious bugs we discovered in older versions of CodeWarrior.
I would very strongly recommend that you upgrade to CodeWarrior
version 5.0 and the 5.0.2 patch. If your problem still occurs, what
we have done here is to make an example project that can be run on the
DSP56F805EVM module and send it to Metrowerks at:

If you set a breakpoint in your example program just before the
switch/case statement, when the program stops at the breakpoint you
can view the assembly-language instructions by selecting "Mixed" from
the "Source" list pop-up at the bottom of the Source pane in the
Debugger Thread Window. This is described in Chapter 15 "Basic
Debugging" in the CodeWarrior IDE 4.2.5 User Guide. We have found
that by looking at the assembly-language instructions, the bug can
usually be spotted quite easily.

CodeWarrior version 4.x (and earlier) has several extremely serious
bugs, which have all been fixed on version 5.0 with the 5.0.2 patch.
I would very strongly recommend that anyone with an older version of
CodeWarrior should upgrade to version 5.0 with the 5.0.2 patch. Two
of these extremely serious bugs are described below (there are quite a
few other bugs besides these 2):

1) Local variables inside a function are saved on the stack, but when
you use them the compiler loads the value from a global memory
location that has nothing to do with the stack. Obviously, this can
cause your program to have spectacular and extremely hard-to-find
crashes.

2) Memory locations that you have declared as volatile (for example,
all of the DSP chip internal registers) are not accessed correctly.
If you read a volatile memory location several times in a row, it is
only accessed the first time and a cached value is used after that.
For example, suppose that you are reading an input signal from a GPIO
port 4 times to see that the value is stable. The compiler generated
code that read the GPIO port the first time and used a cached value
the last 3 times. This could have very serious consequences if (for
example) the DSP chip was used in an Antilock Braking System (ABS),
and you were relying on getting a stable sample of an input signal.

For the above reasons, anyone with an older version of CodeWarrior
should upgrade to version 5.0 with the 5.0.2 patch.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com -----Original Message-----
From: softoe [mailto:]
Sent: Monday, September 23, 2002 12:14 PM
To:
Subject: [motoroladsp] case statements I am using Codewarrior 4.1 for the DSP56F805. I am experiencing
strange problems in a switch/case statement. Note in the code snippet
below the last two cases are commented out; if I uncomment one or
both of them, it compiles fine but then the switch no longer works,
i.e. execution never reaches any of the other cases, as if the entire
switch statement were missing. I comment them and it works fine. Why?

Sean Marble
AMET

switch ( meaning ) {
case MEANING_KILL:
//beginParameterUpdate();
break;
case MEANING_STOPSEGMENT:
//beginParameterUpdate();
break;
case MEANING_STARTSEGMENT:
//beginParameterUpdate();
break;
case MEANING_ATTRIBQUERY:
// Send out attribute data for
specified parameter #:
outData[0] = inMessage.content.data
[0]; // parameter #
// Min:
outData[1] = 1;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 1 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Max:
outData[1] = 2;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 2 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Increment:
outData[1] = 3;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 3 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Default:
outData[1] = 4;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 4 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
break;
case MEANING_STARTUPDATE:
beginParameterUpdate();
break;
case MEANING_UPDATEDATA:
setParameterValue(
inMessage.content.data[0], inMessage.content.data[1], CANdataToFloat
(&inMessage.content.data[2]) );
break;
/*case MEANING_QUERYUPDATE:
if ( isUpdateComplete() )
outData[0] = 1;
else
outData[0] = 0;
sendCANmsg( MEANING_UPDATESTATUS,
false, 1, &outData );
OSTimeDly(1);
break;
case MEANING_ADJUSTOVERRIDE:
break;*/
default: break;
}

_____________________________________
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/ ------------------------ Yahoo! Groups Sponsor
---------------------~-->
Sell a Home for Top $
http://us.click.yahoo.com/RrPZMC/jTmEAA/ySSFAA/PNArlB/TM
---------------------------------~
->

_____________________________________
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/

_____________________________________
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/
_____________________________________
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/

------------------------ Yahoo! Groups Sponsor
---------------------~-->
Sell a Home for Top $
http://us.click.yahoo.com/RrPZMC/jTmEAA/MVfIAA/PNArlB/TM
---------------------------------~
->

_____________________________________
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/


The "local variable bug inside a function" (number 2 in my list) is the only one
that can seriously affect your programs, to either crash the program or cause it
to give incorrect results. We only saw it in functions that were very large
(several hundred lines), or that were using complex macros. So, it may be
enough to keep all of your functions small, and do not use complex macros. This
is not a complete guarantee that everything will be OK, but it will greatly
reduce the possibility of CodeWarrior generating this bug.

On the subject of the DSP56F8xx DSP's, I think that Motorola has come up with an
excellent range of products. Although there were some serious hardware bugs
earlier in the program, Motorola has worked quickly and diligently to fix them
all. I don't have any experience on the audio processing side (we make Marine
and Industrial Control Systems), so I can't help you there.

To put my opinions into perspective, I have 31+ years hardware design experience
in addition to 26+ years experience in software development. During this time I
have always been very impressed with Motorola's products and the quality of
their documentation and technical support.

Motorola also seems to have an uncanny ability to come up with the "perfect"
product just when you need it. I was working at another company in the late
1980's when we needed to design a 32-bit CPU module to replace an 8085-based
8-bit CPU. This had to fit into an STD-Bus form factor. We chose the 68000
family, but to get all the memory, FPU, I/O, and serial ports we needed would
have involved a messy 2- or 3-board system with ribbon cables between them.
Then Motorola introduced the 68302. It was as if they had read our minds, it
had EXACTLY the right amount of everything on a single chip! I immediately
designed it into our new CPU module and it was a huge success. It made me a
millionaire and my boss a multi-millionaire (he's retired now and just plays on
his 65-foot motor yacht).

It's the same with the DSP56F8xx here at PMC. The DSP56F807 has exactly the
right amount of everything for many of our new products. We're very excited
about these new products and are confident they will be quite successful. If
you are interested, you can go to our website and look at "New Products" near
the bottom of our home page.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com
-----Original Message-----
From: Roelof Oelofsen (RP) [mailto:]
Sent: Monday, September 30, 2002 11:04 PM
To:
Subject: RE: [motoroladsp] case statements Good morning all,

Seems like I am in the same situation as a lot of the people
subscribed to this newsgroup.

I work for a telecomms company where, in my humble opinion, DSP is one
of the most needed tools that one can get. Because of restructuring
and maybe also because they do not see the need for DSP, there is very
little funds available to buy DSP compilers and supported equipment.
Our exhange rate (I live in South Africa) makes it even more
difficult.

So along comes the offer from Avnett Kopp on the Motorola DSP and I
decided to spend my own money on the EVM/C-compiler for the following
reasons:
1. The company that I work for, will surely gain from the knowledge
that I am gaining on the DSP, especially since Motorola provides a
free SDK with a lot of telecomms stuff.
2. It is a ideal opportunity to convert all my theory knowledge to
hands-on knowledge.
3. I have the opportunity to work with one of the best 16bit fixed
point processors presently available (I still believe that this is one
of the best processors available presently, together with the SDk and
other software provided with the EVM)
4. Maybe I could do a bit of audio processing as well.

So now you can understand why what I am reading in the newsgroup is a
bit of a concern to me. The simple fact is that I will continue to use
Codewarrior 4.0 even if there appear to be major bugs in it.

What Art is saying makes a lot of sense. I do not have his experience
to agree or contradict his findings, but because I am using the tools,
I will surely take note of what he is saying. I myself have found a
few "bugs", but more in the SDK.

I also take note what Ron is saying and it is good to note that steps
are taken to try and solve all this issues.

So my conclusion is this: Is there any free solutions to the problem
for people like me? If not, what motivation can I use to spend more of
my hard earned money on an upgrade?

Kind regards
Roelof Oelofsen
Tlekom Development Laboratory
Telkom SA

P.S. Art, what is your findings of the DSP56F8XX DSP's and can you use
this for good quality audio processing (despite the limited dynamic
range of 16bit fixed point?). All input welcome -----Original Message-----
From: Art Johnson [mailto:]
Sent: 30 September 2002 15:00
To: ; Motorola DSPD News; Roelof Oelofsen (RP);

Cc: Kevin Ackerley (E-mail); Ed Baillie (E-mail)
Subject: RE: [motoroladsp] case statements While we're on the subject of CodeWarrior, you may find it interesting
to read about my experiences with this product, and my opinion of how
it compares to the other compilers/linkers/debuggers I have used in
the last 26+ years of developing software.

First off, here's my own personal rating system for this sort of
product. Each item is given its rating of importance, with the total
being 100%. For the really important items (1, 2, 3, and 4), the
product gets either the full rating or nothing (ie either you fully
comply with the ANSI C standard, or you don't). If you consider this
to be unfair, you can use your own rating system.

1. Compiler fully complies with the ANSI C standard
(exceptions are permitted only where the chip
architecture forces non-compliance):
Rating: 30%
2. Compiler generates code that does what you wrote
in your C source code:
Rating: 30%
3. Compiler generates highly optimized code when you
select a high level of optimization:
Rating: 15%
4. Debugger accurately shows you all data regardless
of the optimization level you have selected:
Rating: 15%
5. There is a fancy IDE with lots of point-and-click
bells and whistles:
Rating: 10%

Here are the ratings I have given based on my experiences with
CodeWarrior 4.x and 5.0:

CodeWarrior 4.x:
1. 0%
2. 0%
3. 0%
4. 0%
5. 10%
----
Total: 10%

CodeWarrior 5.0:
1. 0%
2. 30%
3. 0%
4. 0%
5. 10%
----
Total: 40%

Again, you can use your own rating system if you think I am being
unfair. It may also interest you to know that most of the
compiler/linker/debugger systems I have used in the past would receive
a 100% score using this rating system.

What is my justification for each of the above ratings? I'm glad you
asked. Here they are:

1. CodeWarrior 4.x violated the ANSI C standard on the meaning of the
keyword 'volatile'. This was fixed in CodeWarrior 5.0, but they
(apparently deliberately) introduced a violation of the keyword
'const'. This last one cost me 2 weeks work (or, more truthfully,
wasted time).

2. CodeWarrior 4.x has a bug where local variables inside a function
are saved on the stack, but when you use them the compiler loads the
value from a global memory location that has nothing to do with the
stack. This bug has been fixed in version 5.0.

3. CodeWarrior 4.x and 5.0 both generate a large number of
unnecessary register loads, even when you have selected the highest
level of optimization. Here's an example of the code that's produced
when I select "Optimize for Faster Execution Speed" and "Optimization
Level 4" (the highest setting) (also note that "Optimize for Faster
Execution Speed" and "Optimize for Smaller Code Size" produce exactly
the same results at this level of optimization):
My source code:
p_mbus_data->signals = 0; // Signals for the
Application Layer
p_mbus_data->rx_ind_timer = 0; // Receive indication
timer
p_mbus_data->tx_conf_timer = 0; // Transmit
confirmation timer
p_mbus_data->rx_frames = 0; // Total received frames
p_mbus_data->rx_bus_msg_cnt = 0; // Total messages addressed to
us
p_mbus_data->rx_crc_err_cnt = 0; // Total CRC errors
p_mbus_data->rx_bufs_dumped = 0; // Receive buffers dumped
p_mbus_data->rx_failure_cnt = 0; // Rx failures (timed out)
p_mbus_data->tx_exc_err_cnt = 0; // Total Exception response
messages
p_mbus_data->tx_slave_msg_cnt = 0; // Total non-exception
response msgs
p_mbus_data->tx_frames = 0; // Total transmitted frames
p_mbus_data->tx_failure_cnt = 0; // Tx failures (timed out)
p_mbus_data->p_tx_buf = NULL; // Pointer to the transmit
communication buffer
CodeWarrior's generated code for the above:
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0002)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0003)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0004)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0005)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0006)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0007)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0008)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0009)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000a)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000b)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000c)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000d)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0016)
The above is a total of 52 words. Now here's what a good optimizing
compiler would generate:
clr x0
move x0,X:(R2+0x0002)
move x0,X:(R2+0x0003)
move x0,X:(R2+0x0004)
move x0,X:(R2+0x0005)
move x0,X:(R2+0x0006)
move x0,X:(R2+0x0007)
move x0,X:(R2+0x0008)
move x0,X:(R2+0x0009)
move x0,X:(R2+0x000a)
move x0,X:(R2+0x000b)
move x0,X:(R2+0x000c)
move x0,X:(R2+0x000d)
move x0,X:(R2+0x0016)
The properly optimized code is a total of 14 words. So, CodeWarrior
has generated object code that is 371% of the size of properly
optimized code in this example.

4. The CodeWarrior debugger does not display data or the stack frame
correctly when higher levels of optimization are used. You can read
all about it in the attached email. Just another week's work down the
drain.

I would welcome hearing about anyone else's experiences with
CodeWarrior for DSP56800.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com

-----Original Message-----
From: Sean Marble [mailto:]
Sent: Friday, September 27, 2002 4:06 PM
To: Motorola DSPD News; Art Johnson; 'Roelof Oelofsen (RP)';

Cc: 'Kevin Ackerley (E-mail)'; 'Ed Baillie (E-mail)'
Subject: RE: [motoroladsp] case statements I agree with Art. We have had numerous problems of this nature with
Codewarrior 4.1. You should offer a free or heavily discounted upgrade
for
us suckers who bought version 4. At the very least put out free
patches that
fix the bugs. A C compiler that can't handle some case statements?
Come on.

Sean Marble
AMET, Inc.

-----Original Message-----
From: Motorola DSPD News [mailto:]
Sent: Friday, September 27, 2002 1:53 PM
To: 'Art Johnson'; 'Roelof Oelofsen (RP)'; 'softoe';

Cc: 'Kevin Ackerley (E-mail)'; 'Ed Baillie (E-mail)'
Subject: RE: [motoroladsp] case statements Price for the 5.0 version is $1195. If you have purchased CodeWarrior
4.0 with tech support option, you will receive 70% off when you
upgrade
(you will pay $360 for version 5.0). However, if you don't have
support
option, you will have to pay full amount of $1195.

Leonard N. Elevich
Motorola DSPO

-----Original Message-----
From: Art Johnson [mailto:]
Sent: Friday, September 27, 2002 5:00 AM
To: Roelof Oelofsen (RP); softoe;
Cc: Kevin Ackerley (E-mail); Ed Baillie (E-mail)
Subject: RE: [motoroladsp] case statements

Actually, in my (not-so-humble) opinion, the upgrade should be free
due
to the large amount of time and money that these bugs have cost
developers everywhere. I know that here at PMC the bugs we found in
CodeWarrior have put us several months behind schedule. It has got to
the point now that if another developer here has a bug that doesn't
look
like a problem in their source code, they ask me to have a look at the
assembly language instructions to see if CodeWarrior has produced bad
object code. That's a fact.

Seriously, I do know that we got some kind of special lower price for
the upgrade to version 5.0. I don't know exactly what we paid for the
upgrade because that's handled by our Purchasing department.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com
-----Original Message-----
From: Roelof Oelofsen (RP) [mailto:]
Sent: Thursday, September 26, 2002 11:53 PM
To: Art Johnson; softoe;
Subject: RE: [motoroladsp] case statements Good day, Art

Thank you (and all the other group members)for all your useful input
so far.

You mentioned that Codewarrior 4 have some serious bugs in it. I
bought Codewarrior on a special deal together with the 56f807evm and
would like to upgrade to Codewarrior 5.

Do you know what the cost involved are?

Kind regards
Roelof Oelofsen

-----Original Message-----
From: Art Johnson [mailto:]
Sent: 24 September 2002 15:25
To: softoe;
Subject: RE: [motoroladsp] case statements Your switch/case statement looks OK. The problem may be due to one of
the very serious bugs we discovered in older versions of CodeWarrior.
I would very strongly recommend that you upgrade to CodeWarrior
version 5.0 and the 5.0.2 patch. If your problem still occurs, what
we have done here is to make an example project that can be run on the
DSP56F805EVM module and send it to Metrowerks at:

If you set a breakpoint in your example program just before the
switch/case statement, when the program stops at the breakpoint you
can view the assembly-language instructions by selecting "Mixed" from
the "Source" list pop-up at the bottom of the Source pane in the
Debugger Thread Window. This is described in Chapter 15 "Basic
Debugging" in the CodeWarrior IDE 4.2.5 User Guide. We have found
that by looking at the assembly-language instructions, the bug can
usually be spotted quite easily.

CodeWarrior version 4.x (and earlier) has several extremely serious
bugs, which have all been fixed on version 5.0 with the 5.0.2 patch.
I would very strongly recommend that anyone with an older version of
CodeWarrior should upgrade to version 5.0 with the 5.0.2 patch. Two
of these extremely serious bugs are described below (there are quite a
few other bugs besides these 2):

1) Local variables inside a function are saved on the stack, but when
you use them the compiler loads the value from a global memory
location that has nothing to do with the stack. Obviously, this can
cause your program to have spectacular and extremely hard-to-find
crashes.

2) Memory locations that you have declared as volatile (for example,
all of the DSP chip internal registers) are not accessed correctly.
If you read a volatile memory location several times in a row, it is
only accessed the first time and a cached value is used after that.
For example, suppose that you are reading an input signal from a GPIO
port 4 times to see that the value is stable. The compiler generated
code that read the GPIO port the first time and used a cached value
the last 3 times. This could have very serious consequences if (for
example) the DSP chip was used in an Antilock Braking System (ABS),
and you were relying on getting a stable sample of an input signal.

For the above reasons, anyone with an older version of CodeWarrior
should upgrade to version 5.0 with the 5.0.2 patch.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com -----Original Message-----
From: softoe [mailto:]
Sent: Monday, September 23, 2002 12:14 PM
To:
Subject: [motoroladsp] case statements I am using Codewarrior 4.1 for the DSP56F805. I am experiencing
strange problems in a switch/case statement. Note in the code snippet
below the last two cases are commented out; if I uncomment one or
both of them, it compiles fine but then the switch no longer works,
i.e. execution never reaches any of the other cases, as if the entire
switch statement were missing. I comment them and it works fine. Why?

Sean Marble
AMET

switch ( meaning ) {
case MEANING_KILL:
//beginParameterUpdate();
break;
case MEANING_STOPSEGMENT:
//beginParameterUpdate();
break;
case MEANING_STARTSEGMENT:
//beginParameterUpdate();
break;
case MEANING_ATTRIBQUERY:
// Send out attribute data for
specified parameter #:
outData[0] = inMessage.content.data
[0]; // parameter #
// Min:
outData[1] = 1;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 1 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Max:
outData[1] = 2;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 2 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Increment:
outData[1] = 3;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 3 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Default:
outData[1] = 4;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 4 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
break;
case MEANING_STARTUPDATE:
beginParameterUpdate();
break;
case MEANING_UPDATEDATA:
setParameterValue(
inMessage.content.data[0], inMessage.content.data[1], CANdataToFloat
(&inMessage.content.data[2]) );
break;
/*case MEANING_QUERYUPDATE:
if ( isUpdateComplete() )
outData[0] = 1;
else
outData[0] = 0;
sendCANmsg( MEANING_UPDATESTATUS,
false, 1, &outData );
OSTimeDly(1);
break;
case MEANING_ADJUSTOVERRIDE:
break;*/
default: break;
}

_____________________________________
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/ ------------------------ Yahoo! Groups Sponsor
---------------------~-->
Sell a Home for Top $
http://us.click.yahoo.com/RrPZMC/jTmEAA/ySSFAA/PNArlB/TM
---------------------------------~
->

_____________________________________
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/

_____________________________________
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/
_____________________________________
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/

------------------------ Yahoo! Groups Sponsor
---------------------~-->
Sell a Home for Top $
http://us.click.yahoo.com/RrPZMC/jTmEAA/MVfIAA/PNArlB/TM
---------------------------------~
->

_____________________________________
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/
_____________________________________
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/


Art,

Thanx for putting everything in perspective. Like I mentioned earlier,
I am sure that most, if not all people on the newsgroup, is gaining
from the knowledge that you have picked up over the years.

Certainly, this does not apply to you only, but to all the people that
do not hesitate to share their knowledge on this website.

When I first joined this newsgroup, many of my questions were left
unanswered, and I even tried to answer some question with my limited
knowledge and time. (Jose will have an good idea when I speak about
limited time!) Surely all this will change as I gain more knowledge on
the subject.

Keep up the good work!

Kind regards
Roelof Oelofsen
Telkom Development Laboratory
Telkom Sa

-----Original Message-----
From: Art Johnson [mailto:]
Sent: 01 October 2002 16:15
To: Roelof Oelofsen (RP);
Subject: RE: [motoroladsp] case statements The "local variable bug inside a function" (number 2 in my list) is
the only one that can seriously affect your programs, to either crash
the program or cause it to give incorrect results. We only saw it in
functions that were very large (several hundred lines), or that were
using complex macros. So, it may be enough to keep all of your
functions small, and do not use complex macros. This is not a
complete guarantee that everything will be OK, but it will greatly
reduce the possibility of CodeWarrior generating this bug.

On the subject of the DSP56F8xx DSP's, I think that Motorola has come
up with an excellent range of products. Although there were some
serious hardware bugs earlier in the program, Motorola has worked
quickly and diligently to fix them all. I don't have any experience
on the audio processing side (we make Marine and Industrial Control
Systems), so I can't help you there.

To put my opinions into perspective, I have 31+ years hardware design
experience in addition to 26+ years experience in software
development. During this time I have always been very impressed with
Motorola's products and the quality of their documentation and
technical support.

Motorola also seems to have an uncanny ability to come up with the
"perfect" product just when you need it. I was working at another
company in the late 1980's when we needed to design a 32-bit CPU
module to replace an 8085-based 8-bit CPU. This had to fit into an
STD-Bus form factor. We chose the 68000 family, but to get all the
memory, FPU, I/O, and serial ports we needed would have involved a
messy 2- or 3-board system with ribbon cables between them. Then
Motorola introduced the 68302. It was as if they had read our minds,
it had EXACTLY the right amount of everything on a single chip! I
immediately designed it into our new CPU module and it was a huge
success. It made me a millionaire and my boss a multi-millionaire
(he's retired now and just plays on his 65-foot motor yacht).

It's the same with the DSP56F8xx here at PMC. The DSP56F807 has
exactly the right amount of everything for many of our new products.
We're very excited about these new products and are confident they
will be quite successful. If you are interested, you can go to our
website and look at "New Products" near the bottom of our home page.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com
-----Original Message-----
From: Roelof Oelofsen (RP) [mailto:]
Sent: Monday, September 30, 2002 11:04 PM
To:
Subject: RE: [motoroladsp] case statements Good morning all,

Seems like I am in the same situation as a lot of the people
subscribed to this newsgroup.

I work for a telecomms company where, in my humble opinion, DSP is one
of the most needed tools that one can get. Because of restructuring
and maybe also because they do not see the need for DSP, there is very
little funds available to buy DSP compilers and supported equipment.
Our exhange rate (I live in South Africa) makes it even more
difficult.

So along comes the offer from Avnett Kopp on the Motorola DSP and I
decided to spend my own money on the EVM/C-compiler for the following
reasons:
1. The company that I work for, will surely gain from the knowledge
that I am gaining on the DSP, especially since Motorola provides a
free SDK with a lot of telecomms stuff.
2. It is a ideal opportunity to convert all my theory knowledge to
hands-on knowledge.
3. I have the opportunity to work with one of the best 16bit fixed
point processors presently available (I still believe that this is one
of the best processors available presently, together with the SDk and
other software provided with the EVM)
4. Maybe I could do a bit of audio processing as well.

So now you can understand why what I am reading in the newsgroup is a
bit of a concern to me. The simple fact is that I will continue to use
Codewarrior 4.0 even if there appear to be major bugs in it.

What Art is saying makes a lot of sense. I do not have his experience
to agree or contradict his findings, but because I am using the tools,
I will surely take note of what he is saying. I myself have found a
few "bugs", but more in the SDK.

I also take note what Ron is saying and it is good to note that steps
are taken to try and solve all this issues.

So my conclusion is this: Is there any free solutions to the problem
for people like me? If not, what motivation can I use to spend more of
my hard earned money on an upgrade?

Kind regards
Roelof Oelofsen
Tlekom Development Laboratory
Telkom SA

P.S. Art, what is your findings of the DSP56F8XX DSP's and can you use
this for good quality audio processing (despite the limited dynamic
range of 16bit fixed point?). All input welcome -----Original Message-----
From: Art Johnson [mailto:]
Sent: 30 September 2002 15:00
To: ; Motorola DSPD News; Roelof Oelofsen (RP);

Cc: Kevin Ackerley (E-mail); Ed Baillie (E-mail)
Subject: RE: [motoroladsp] case statements While we're on the subject of CodeWarrior, you may find it interesting
to read about my experiences with this product, and my opinion of how
it compares to the other compilers/linkers/debuggers I have used in
the last 26+ years of developing software.

First off, here's my own personal rating system for this sort of
product. Each item is given its rating of importance, with the total
being 100%. For the really important items (1, 2, 3, and 4), the
product gets either the full rating or nothing (ie either you fully
comply with the ANSI C standard, or you don't). If you consider this
to be unfair, you can use your own rating system.

1. Compiler fully complies with the ANSI C standard
(exceptions are permitted only where the chip
architecture forces non-compliance):
Rating: 30%
2. Compiler generates code that does what you wrote
in your C source code:
Rating: 30%
3. Compiler generates highly optimized code when you
select a high level of optimization:
Rating: 15%
4. Debugger accurately shows you all data regardless
of the optimization level you have selected:
Rating: 15%
5. There is a fancy IDE with lots of point-and-click
bells and whistles:
Rating: 10%

Here are the ratings I have given based on my experiences with
CodeWarrior 4.x and 5.0:

CodeWarrior 4.x:
1. 0%
2. 0%
3. 0%
4. 0%
5. 10%
----
Total: 10%

CodeWarrior 5.0:
1. 0%
2. 30%
3. 0%
4. 0%
5. 10%
----
Total: 40%

Again, you can use your own rating system if you think I am being
unfair. It may also interest you to know that most of the
compiler/linker/debugger systems I have used in the past would receive
a 100% score using this rating system.

What is my justification for each of the above ratings? I'm glad you
asked. Here they are:

1. CodeWarrior 4.x violated the ANSI C standard on the meaning of the
keyword 'volatile'. This was fixed in CodeWarrior 5.0, but they
(apparently deliberately) introduced a violation of the keyword
'const'. This last one cost me 2 weeks work (or, more truthfully,
wasted time).

2. CodeWarrior 4.x has a bug where local variables inside a function
are saved on the stack, but when you use them the compiler loads the
value from a global memory location that has nothing to do with the
stack. This bug has been fixed in version 5.0.

3. CodeWarrior 4.x and 5.0 both generate a large number of
unnecessary register loads, even when you have selected the highest
level of optimization. Here's an example of the code that's produced
when I select "Optimize for Faster Execution Speed" and "Optimization
Level 4" (the highest setting) (also note that "Optimize for Faster
Execution Speed" and "Optimize for Smaller Code Size" produce exactly
the same results at this level of optimization):
My source code:
p_mbus_data->signals = 0; // Signals for the
Application Layer
p_mbus_data->rx_ind_timer = 0; // Receive indication
timer
p_mbus_data->tx_conf_timer = 0; // Transmit
confirmation timer
p_mbus_data->rx_frames = 0; // Total received frames
p_mbus_data->rx_bus_msg_cnt = 0; // Total messages addressed to
us
p_mbus_data->rx_crc_err_cnt = 0; // Total CRC errors
p_mbus_data->rx_bufs_dumped = 0; // Receive buffers dumped
p_mbus_data->rx_failure_cnt = 0; // Rx failures (timed out)
p_mbus_data->tx_exc_err_cnt = 0; // Total Exception response
messages
p_mbus_data->tx_slave_msg_cnt = 0; // Total non-exception
response msgs
p_mbus_data->tx_frames = 0; // Total transmitted frames
p_mbus_data->tx_failure_cnt = 0; // Tx failures (timed out)
p_mbus_data->p_tx_buf = NULL; // Pointer to the transmit
communication buffer
CodeWarrior's generated code for the above:
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0002)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0003)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0004)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0005)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0006)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0007)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0008)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0009)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000a)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000b)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000c)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x000d)
moves X:0x0038,R2
nop
movei #0,X:(R2+0x0016)
The above is a total of 52 words. Now here's what a good optimizing
compiler would generate:
clr x0
move x0,X:(R2+0x0002)
move x0,X:(R2+0x0003)
move x0,X:(R2+0x0004)
move x0,X:(R2+0x0005)
move x0,X:(R2+0x0006)
move x0,X:(R2+0x0007)
move x0,X:(R2+0x0008)
move x0,X:(R2+0x0009)
move x0,X:(R2+0x000a)
move x0,X:(R2+0x000b)
move x0,X:(R2+0x000c)
move x0,X:(R2+0x000d)
move x0,X:(R2+0x0016)
The properly optimized code is a total of 14 words. So, CodeWarrior
has generated object code that is 371% of the size of properly
optimized code in this example.

4. The CodeWarrior debugger does not display data or the stack frame
correctly when higher levels of optimization are used. You can read
all about it in the attached email. Just another week's work down the
drain.

I would welcome hearing about anyone else's experiences with
CodeWarrior for DSP56800.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com

-----Original Message-----
From: Sean Marble [mailto:]
Sent: Friday, September 27, 2002 4:06 PM
To: Motorola DSPD News; Art Johnson; 'Roelof Oelofsen (RP)';

Cc: 'Kevin Ackerley (E-mail)'; 'Ed Baillie (E-mail)'
Subject: RE: [motoroladsp] case statements I agree with Art. We have had numerous problems of this nature with
Codewarrior 4.1. You should offer a free or heavily discounted upgrade
for
us suckers who bought version 4. At the very least put out free
patches that
fix the bugs. A C compiler that can't handle some case statements?
Come on.

Sean Marble
AMET, Inc.

-----Original Message-----
From: Motorola DSPD News [mailto:]
Sent: Friday, September 27, 2002 1:53 PM
To: 'Art Johnson'; 'Roelof Oelofsen (RP)'; 'softoe';

Cc: 'Kevin Ackerley (E-mail)'; 'Ed Baillie (E-mail)'
Subject: RE: [motoroladsp] case statements Price for the 5.0 version is $1195. If you have purchased CodeWarrior
4.0 with tech support option, you will receive 70% off when you
upgrade
(you will pay $360 for version 5.0). However, if you don't have
support
option, you will have to pay full amount of $1195.

Leonard N. Elevich
Motorola DSPO

-----Original Message-----
From: Art Johnson [mailto:]
Sent: Friday, September 27, 2002 5:00 AM
To: Roelof Oelofsen (RP); softoe;
Cc: Kevin Ackerley (E-mail); Ed Baillie (E-mail)
Subject: RE: [motoroladsp] case statements

Actually, in my (not-so-humble) opinion, the upgrade should be free
due
to the large amount of time and money that these bugs have cost
developers everywhere. I know that here at PMC the bugs we found in
CodeWarrior have put us several months behind schedule. It has got to
the point now that if another developer here has a bug that doesn't
look
like a problem in their source code, they ask me to have a look at the
assembly language instructions to see if CodeWarrior has produced bad
object code. That's a fact.

Seriously, I do know that we got some kind of special lower price for
the upgrade to version 5.0. I don't know exactly what we paid for the
upgrade because that's handled by our Purchasing department.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com
-----Original Message-----
From: Roelof Oelofsen (RP) [mailto:]
Sent: Thursday, September 26, 2002 11:53 PM
To: Art Johnson; softoe;
Subject: RE: [motoroladsp] case statements Good day, Art

Thank you (and all the other group members)for all your useful input
so far.

You mentioned that Codewarrior 4 have some serious bugs in it. I
bought Codewarrior on a special deal together with the 56f807evm and
would like to upgrade to Codewarrior 5.

Do you know what the cost involved are?

Kind regards
Roelof Oelofsen

-----Original Message-----
From: Art Johnson [mailto:]
Sent: 24 September 2002 15:25
To: softoe;
Subject: RE: [motoroladsp] case statements Your switch/case statement looks OK. The problem may be due to one of
the very serious bugs we discovered in older versions of CodeWarrior.
I would very strongly recommend that you upgrade to CodeWarrior
version 5.0 and the 5.0.2 patch. If your problem still occurs, what
we have done here is to make an example project that can be run on the
DSP56F805EVM module and send it to Metrowerks at:

If you set a breakpoint in your example program just before the
switch/case statement, when the program stops at the breakpoint you
can view the assembly-language instructions by selecting "Mixed" from
the "Source" list pop-up at the bottom of the Source pane in the
Debugger Thread Window. This is described in Chapter 15 "Basic
Debugging" in the CodeWarrior IDE 4.2.5 User Guide. We have found
that by looking at the assembly-language instructions, the bug can
usually be spotted quite easily.

CodeWarrior version 4.x (and earlier) has several extremely serious
bugs, which have all been fixed on version 5.0 with the 5.0.2 patch.
I would very strongly recommend that anyone with an older version of
CodeWarrior should upgrade to version 5.0 with the 5.0.2 patch. Two
of these extremely serious bugs are described below (there are quite a
few other bugs besides these 2):

1) Local variables inside a function are saved on the stack, but when
you use them the compiler loads the value from a global memory
location that has nothing to do with the stack. Obviously, this can
cause your program to have spectacular and extremely hard-to-find
crashes.

2) Memory locations that you have declared as volatile (for example,
all of the DSP chip internal registers) are not accessed correctly.
If you read a volatile memory location several times in a row, it is
only accessed the first time and a cached value is used after that.
For example, suppose that you are reading an input signal from a GPIO
port 4 times to see that the value is stable. The compiler generated
code that read the GPIO port the first time and used a cached value
the last 3 times. This could have very serious consequences if (for
example) the DSP chip was used in an Antilock Braking System (ABS),
and you were relying on getting a stable sample of an input signal.

For the above reasons, anyone with an older version of CodeWarrior
should upgrade to version 5.0 with the 5.0.2 patch.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com -----Original Message-----
From: softoe [mailto:]
Sent: Monday, September 23, 2002 12:14 PM
To:
Subject: [motoroladsp] case statements I am using Codewarrior 4.1 for the DSP56F805. I am experiencing
strange problems in a switch/case statement. Note in the code snippet
below the last two cases are commented out; if I uncomment one or
both of them, it compiles fine but then the switch no longer works,
i.e. execution never reaches any of the other cases, as if the entire
switch statement were missing. I comment them and it works fine. Why?

Sean Marble
AMET

switch ( meaning ) {
case MEANING_KILL:
//beginParameterUpdate();
break;
case MEANING_STOPSEGMENT:
//beginParameterUpdate();
break;
case MEANING_STARTSEGMENT:
//beginParameterUpdate();
break;
case MEANING_ATTRIBQUERY:
// Send out attribute data for
specified parameter #:
outData[0] = inMessage.content.data
[0]; // parameter #
// Min:
outData[1] = 1;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 1 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Max:
outData[1] = 2;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 2 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Increment:
outData[1] = 3;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 3 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
// Default:
outData[1] = 4;
floatToCANdata( getParameterAttribute
( inMessage.content.data[0], 4 ), &outData[2] );
sendCANmsg( MEANING_ATTRIBUTE, false,
6, &outData );
OSTimeDly(1);
break;
case MEANING_STARTUPDATE:
beginParameterUpdate();
break;
case MEANING_UPDATEDATA:
setParameterValue(
inMessage.content.data[0], inMessage.content.data[1], CANdataToFloat
(&inMessage.content.data[2]) );
break;
/*case MEANING_QUERYUPDATE:
if ( isUpdateComplete() )
outData[0] = 1;
else
outData[0] = 0;
sendCANmsg( MEANING_UPDATESTATUS,
false, 1, &outData );
OSTimeDly(1);
break;
case MEANING_ADJUSTOVERRIDE:
break;*/
default: break;
}

_____________________________________
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/ ------------------------ Yahoo! Groups Sponsor
---------------------~-->
Sell a Home for Top $
http://us.click.yahoo.com/RrPZMC/jTmEAA/ySSFAA/PNArlB/TM
---------------------------------~
->

_____________________________________
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/

_____________________________________
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/
_____________________________________
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/

------------------------ Yahoo! Groups Sponsor
---------------------~-->
Sell a Home for Top $
http://us.click.yahoo.com/RrPZMC/jTmEAA/MVfIAA/PNArlB/TM
---------------------------------~
->

_____________________________________
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/ ------------------------ Yahoo! Groups Sponsor
---------------------~-->
4 DVDs Free +s&p Join Now
http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/PNArlB/TM
---------------------------------~
->

_____________________________________
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/