While I agree that CodeWarrior 5 produces poorer code than 4.0.2 in this
example, when changing data in any shared resource (like a GPIO port or
globally
shared memory), one should never assume that the compiler will generate code
that performs the operation atomically (ie as one indivisible operation).
This
is particularly important when you are using a RealTime Operating System
(RTOS)
(we use the DSPOS RTOS in all our applications).
The generally accepted way of coding to prevent this sort of problem with a
shared resource is shown by the following example from one of our programs:
#define Sci0_Tx_Connect( ) \
{ \
register WORD interrupt; \
interrupt = Disable_Int(); \
g_p_dspregs->pwma.pmout &= ~SCI0_TX_ENABLE_BIT; \
Enable_Int(interrupt); \
}
#define Sci0_Tx_Disconnect( ) \
{ \
register WORD interrupt; \
interrupt = Disable_Int(); \
g_p_dspregs->pwma.pmout |= SCI0_TX_ENABLE_BIT; \
Enable_Int(interrupt); \
}
The functions Disable_Int() and Enable_Int() are provided by the DSPOS
library.
In this example, we are using one output on PWMA to control the Transmit
Enable
pin of an RS-485 transceiver for the SCI0 serial port.
In any case, as I mentioned before, the very serious bugs that exist in
CodeWarrior 4.x and earlier mean that you are taking a big risk of having
your
program crash in an unpredictable manner. We stumbled upon the "local
variable
bug inside a function" almost by accident. It was discovered when we
were
tracking down a completely different CodeWarrior bug. Our software could
easily
have been sent out with this "time bomb" embedded in it.
For the above reasons, anyone with an older version of CodeWarrior should
upgrade to version 5.0 with the 5.0.2 patch.
I agree with you, that in my 26+ years experience I have never seen a
compiler
as buggy as CodeWarrior. While no product this complex is ever
"perfect", the
bugs we keep finding go way beyond what is acceptable. The Metrowerks
compiler
writers apparently don't even understand basic ANSI C concepts like the
meaning
of the keywords "volatile" or "const". This is not exotic,
high-level stuff,
it's basically kindergarten-level C programming. You might expect these
sorts
of problems in Version 1.0 of some product, but they should not exist in a
"mature" product like Version 5.0 (which we recently had to buy to get
some
other bugs fixed). They even deliberately introduced a bug into Version 5.0
(Compiler/linker puts const data into X RAM) that contravenes the ANSI C
standard meaning of "const". They refused to fix this bug (they think
it's
actually a "new, improved feature"), but gave us a work-around that
cost me
weeks of work to change every build target of every project we have here.
I'm sure we'll never know how much all this extra time and effort has
cost our
company (both in direct development costs and lost sales due to delayed
product
launches), but I'm sure it's well over $100,000. Forcing us to pay for
an
upgrade rather than issuing patches to version 4.x is just adding insult to
injury. Maybe that's the price you have to pay to design in leading-edge
devices ...
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: wdhaan [mailto:]
Sent: Tuesday, October 01, 2002 12:55 AM
To:
Subject: [motoroladsp] Re: CodeWarrior 4 Upgrading
Hi,
Upgrade from Codewarrior 4 to 5?
I did it, but I returned to version 4.0.2, due to the following new
bug in version 5:
*********** C-listing
#define GPIOD_BASE 0x13E0 // Table 3-36 for DSP56F807
#define GPIO_D_DR *(WORD *) (0x1+GPIOD_BASE)
GPIO_D_DR |= 0x02; // set GPIO-D1 to 1
*********** Assembly listing Codewarrior version 4.0.2
orc #2,X:13e1
*********** Assembly listing Codewarrior version 5
movei #5089,R0
nop
move X:(R0),X0
orc #2,X0 ; <=== What happens
if here an interrupt occurs?
move X0,X:(R0)
The problem of this bug is not the additional memory nor the
additional execution time,
but the problem is if during the main program an interrupt function
occurs, which sets f.e. GPIO-D7.
In this case the main program resets the GPIO-D7 value, just set by
the interrupt function.
In this way you get software bugs, which are difficult to reproduce
and difficult to find!
This is only one bug of my Codewarrior bug collection (most of them
have not been solved in version 5). I have sent them to Metrowerks,
but only very few have been answered (some after half a year). I have
14 years experience in developing embedded software, but I have never
used a compiler with so many bugs as Codewarrior. We paid the full
price for Codewarrior version 4 and my supplier understood that I was
not willing to pay a cent for version 5, so I got the upgrade to
version 5 for free. However now I use version 4.0.2 for compilation
and version 5 for debugging
Kind regards,
Wim de Haan
Exendis B.V.
W.J. de Haan
P.O.box 56, 6710 BB Ede
Keesomstraat 4, 6716 AB Ede
The Netherlands.
Tel: +31- 318 - 676305
_____________________________________
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/
|