We have had the identical problems with CodeWarrior for DSP56800. We
estimate
that due to the bugs in CodeWarrior alone, our new product launches have been
delayed by over 5 months, at a total cost to us of well over $100,000.
In this regard, I have attached an email I sent to one of the other DSP56800
developers on the motoroladsp discussion group. From that email, here is my
opinion of CodeWarrior:
"I have been developing software for more than 26 years, and in that time I
have
used hundreds of software products. In my opinion, if there was a race to
find
the WORST software product in the whole universe, CodeWarrior would be in
first
place, by a huge margin. It would be so far ahead of whoever's in second
place
that you couldn't see them with the Hubble Space Telescope!!!
- using the best far-field lens
- and a month-long exposure
- with all of NASA's, JPL's, NSA's, and DOD's supercomputers
running image
enhancement software"
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: Tom Burrell [mailto:]
Sent: Tuesday, December 03, 2002 1:27 PM
To: 'Coldfire CPU Discussion List'
Subject: RE: Development tools for MCF5307
Mark,
I am glad I am not the only one to have trouble with metrowerks.
Tom
-----Original Message-----
From: Mark Roush [mailto:]
Sent: Tuesday, December 03, 2002 2:12 PM
To: 'Coldfire CPU Discussion List'
Subject: RE: Development tools for MCF5307
Fernando,
Using Wind River Diab C compiler and Single Step Debugger with P&E Micro
BDM, all on MCF5272. 5307 is also supported. All are excellent tools and
not buggy. I have used Diab / single step on previous projects for several
years on 68K designs. I also recomend getting P&E micros low level
debugger
and FlASH burner if you have a new design as they work better with buggy
hardware.
I started with Metrowerks this time around but it was so buggy as to be
laughable so I sent it back and got good old Wind River again.
Best luck,
Mark
-----Original Message-----
From: Fernando Xavier [mailto:]
Sent: Tuesday, December 03, 2002 9:12 AM
To: '
Subject: Development tools for MCF5307
Hi developers,
Can anyone help me with the developments tools available for MCF5307? Is
seems that CodeWarrior from Metrowerks is not including the C compiler and
linker, is that true? Which compiler and linker are you using? And about BDM
interface?
Regards
Fernando Xavier
----
---------------------
EFACEC Sistemas de Electronica SA
Automao de Sistemas de Energia e Telecontrolo
Divis de Desenvolvimento e Gest de Produto
Departamento SCADA / DMS
----
---------------------
Apartado 3078
4470-907 MOREIRA MAIA
PORTUGAL
Phone: +351 22 9403393
Fax: +351 22 9485428
Prof. Email:
Partic.. Email:
Web: www.efacec.pt
________________________________________________________________________
ColdFire Discussion List
See: <http://www.WildRice.com/ColdFire/
________________________________________________________________________
ColdFire Discussion List
See: <http://www.WildRice.com/ColdFire/
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.408 / Virus Database: 230 - Release Date: 10/24/2002
________________________________________________________________________
ColdFire Discussion List
See: <http://www.WildRice.com/ColdFire/
|
Hi Rick,
It's a pleasure for me as well, to have these discussions.
I don't think it would be helpful to share details of the relative
priorities of
the bugs that need to be fixed. As you say, everyone would have a different
opinion and so it could actually slow down progress on the bug fixes.
I do think that it should be obvious to Metrowerks, that bugs causing total
program crashes should be put above all other bug fixes. This is just common
sense.
In this regard, the 'do' instruction bug that I found recently is in
this
category. I tried to show Metrowerks the seriousness of this in 3 paragraphs
of
my bug report:
============================
"This Bug is a real "Show Stopper" for us. Since it is
responsible for total
system crashes and is likely to happen at any time in any of our products, we
cannot ship anything until we receive a fix or work around for this Bug.
Obviously, this Bug can cause the same failures in any other company's
software
as well.
The DSP56800 family of devices are often used in critical safety or control
systems, where a program crash could be responsible for property damage,
personal injury, or even death.
I feel very strongly that this Bug should be addressed immediately, and it
should be given a higher priority than any other Bug or feature enhancement
that
Metrowerks is currently working on. If it is necessary for you to go higher
up
the chain of command at Metrowerks to raise the priority of this Bug, please
do
so."
============================
This did not have the desired effect, so my manager here started going
through
"other channels". This DID have the desired effect!
We were visited yesterday afternoon by our local Motorola rep who brought
along
John R. Deck, the Western US Regional Sales Manager at Metrowerks. We went
over
all the problems we are having (basically everything that's been said on
the
discussion group), and I summed up my feelings about CodeWarrior as follows:
"I have been developing software for more than 26 years, and in that time I
have
used hundreds of software products. In my opinion, if there was a race to
find
the WORST software product in the whole universe, CodeWarrior would be in
first
place, by a huge margin. It would be so far ahead of whoever's in second
place
that you couldn't see them with the Hubble Space Telescope!!!
- using the best far-field lens
- and a month-long exposure
- with all of NASA's, JPL's, NSA's, and DOD's supercomputers
running image
enhancement software"
I have no doubt he clearly understood our message. He promised that things
will
be moving ahead briskly and efficiently with this critical Bug Report.
Anyway, I have to get back to work now, so have a great weekend (even though
you
have to work)!
Best regards,
Art
-----Original Message-----
From: Corey, Rick [mailto:]
Sent: Friday, October 11, 2002 5:29 AM
To: Art Johnson
Subject: RE: install static NORMAL_ISR_XX in SDK
Hi Art,
What a pleasure to read your email! The perspective was very helpful, and I
do agree: how *could* it get any better? I happen to have heavy rain and
two days of code-work this weekend, but still, if the tools are working well
enough to make progress, and our cute little boards still haven't
smoked,
and more and more of my code is working, I am whistling while I work.
(Our managers seem almost frightened to see the most-nerdy developers
cheerful and finally upbeat, when they only see a deadline missed and more
slippage in our future. However, we know that progress comes from pain, and
that we may even be past the worst of the pain!)
Ron at Metrowerks has sent me several very thoughtful and reasonable Emails
explaining their constraints and intentions, and I feel better about them,
too. Perhaps the only true underlying difference is what constitutes
"fast
enough", and what can be done to appease the ravening pack of wolves (my
phrase) while total perfection of the toolset is pursued as fast as
resources permit.
What do you think: would sharing details of what order they hope to address
issues help or hurt? I thought that many folks who saw their own pet peeve
below the top 10% might become even more indignant. Also, I would dread the
response (or even my own response) of someone who saw his claim of a
compiler bug relegated to the status of "*perceived* compiler bug".
I'm
just glad not to be in the position of a Metrowerks manager facing 450
demanding developers on a daily basis!
Have a great few days in your garden! The field of corn next door to me is
all brown and withered, and we just figured out what that huge patch of
weeds is. Nightshade! I'm glad I didn't nibble on the flowers.
It's been great getting to know you. And feel free to call me a newbie!
There is always so much to learn that we are *all* perennial newbies in
this industry. All is relative.
Rick Corey
-----Original Message-----
From: Art Johnson [mailto:]
Sent: Thursday, October 10, 2002 6:35 PM
To: Corey, Rick;
Subject: RE: install static NORMAL_ISR_XX in SDK
Hi Rick,
I'm always glad to be of help.
When I started working with the DSP56800 family in May of last year, I had
the same problems that you and other members of this group are having. I
would ask questions and _sometimes_ I would get complete (and correct)
answers, but also I would often get minimal answers, incorrect answers, or
no answers at all (I didn't know about this group back then).
So, I had to dig in and basically learn everything myself, often by trial
and error, including things that did _not_ work according to the manuals,
data sheets, and tech support people that I talked to.
When I first joined this group near the end of July this year, I was
basically passive, expecting that most questions asked by members would get
prompt, complete, and detailed answers. When I saw this was not happening,
I decided to do as much as I could to help. I just thought of all the grief
and frustration I went through over many months, and how much I would have
appreciated some truly helpful answers.
<<< OK, OK, end of self-pity section! >>>
On the subject of "beginner questions", I received an email that a
young
developer in India sent me directly, as he was too afraid to ask his
questions on the group. Here's part of my answer to him:
'The only other thing I can suggest is to post a message to the
motoroladsp
yahoo group to see if any other members can help you. Don't be afraid
just
because you are a "newbie", every one of us was a newbie at one
time.'
<Please, no insult intended, I am NOT calling you a newbie!!!>
On a brighter note, I do think the 56800 family is an excellent group of
products, Metrowerks is working hard to fix the bugs in CodeWarrior, and
here at PMC we're getting very close to finishing our work on several
exciting new products using the 56F807 chip. It's also a beautiful,
sunny
fall day here in Vancouver, the weekend is close at hand, and I have a
week's vacation next week to work (or actually play) in my garden. Does
it
get any better than that?
<rhetorical question>
Best regards,
Art Johnson
PS: The reason you got my answer so fast is that I cheated! As a Moderator
of this group I get to see the members' messages before they are posted
to
the group, so I started my reply just after approving your message to go to
the group. So, my answer was sent _before_ your message made it onto the
group (there is some delay at Yahoo, most likely due to the huge number of
messages they have to process). So, I have to admit it, I'm a cheater! :-)
-----Original Message-----
From: Corey, Rick [mailto:]
Sent: Thursday, October 10, 2002 1:13 PM
To: Art Johnson;
Subject: RE: install static NORMAL_ISR_XX in SDK
Thanks, Art!
That works. I put my prototypes into both appconfigs, RAM and FLASH.
Page 7-12 of the Programmer's Guide seemed to imply that I should have
added:
#define NORMAL_ISR_14 FISR_CAN_Transmit
However, it only compiled after I got the "F" out.
If you had a nickel for every time you saved someone days of frustration,
you would already be a multi-millionaire.
Thanks again.
Rick Corey
P.S. Daniel Malik promptly reproduced my "#pragma interrupt saveall warn
RTS/RTI" bug and reported it to Metrowerks, so now maybe they will
acknowledge it. After more thought and re-reading Chapter 7 of the
Programmer's Guide a few more times, I think more strongly that the
"inline"
and "#pragma interrupt called" factors may be as relevant as the
"auto-inline" and "deferred inline" checkboxes.
-----Original Message-----
From: Art Johnson [mailto:]
Sent: Thursday, October 10, 2002 3:29 PM
To: Corey, Rick;
Subject: RE: install static NORMAL_ISR_XX in SDK
You have to do the following in the file "appconfig.h":
1) add the following function prototypes:
void ISR_CAN_Transmit(void);
void ISR_CAN_Receive(void);
2) add the following defines:
// Definitions for the J1939 (CANbus) interrupts
//
#define GPR_INT_PRIORITY_14 3
#define NORMAL_ISR_14 ISR_CAN_Transmit
#define GPR_INT_PRIORITY_15 3
#define NORMAL_ISR_15 ISR_CAN_Receive
The above is an example of what we do here, you can change the priority
values to be anywhere from 1 to 7 as required by your system.
The reason you must do this is that the interrupt vector file
"vector.c" has
only the following includes:
#include "port.h"
#include "arch.h"
#include "config.h"
The file "config.h" includes the file "configdefines.h",
which in turn
includes your file "appconfig.h". So, the interrupt vector file
"vector.c"
only "knows" about the function prototypes that are explicitly inside
your
file "appconfig.h".
This should solve your problem, but if it doesn't please let me know.
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: Corey, Rick [mailto:]
Sent: Thursday, October 10, 2002 11:59 AM
To: '
Subject: install static NORMAL_ISR_XX in SDK
A novice question: what am I missing in installing a normal ISR (not fast),
statically, not dynamically. I'm trying to use the IRQ Dispatcher, but
not
the whole driver.
The symptom is that a compile notifies me of "undefined
identifiers"
FISR_CAN_Transmit and FISR_CAN_Receive (my ISR function names with an
'F'
pre-pended. It is pramdata.c that can't find my functions.
What is an "approved method" of registering my ISR function with
the
dispatcher when I'm not using the SDK *driver*? This would have to occur
at
compile time.
I tried changing the order of compiling by dragging sections around in the
'Files' pane, and dragging my ISR file above appconfig.h in the
'link order
list". This did not help. I tried compiling my ISR file seperating
before
building, no help. It is as if the linker just doesn't see my ISRs.
I would be inclined to patch vector.c by changing 2
"configUnhandledInterruptISR" to by the names of my ISR functions
(with or
without an 'F').
I unlocked pramdata.c and pasted in my function prototypes - no change. Of
course, my prototypes don;t have the "F" in them.
Then I realized that I was just shooting in the dark and decided to ask
those who know. I've re-read the 26 pages of Chapter 7
"Implementing
Interrupts using the SDK" multiple times, and searched the Yahoo archive
and
looked through Exercise 3-c.
So far, I've added this to the bottom of appconfig.h, in both the
"external
RAM" tree and the "FLASH" tree. This was all that I
// *** set PLRs in GPR (page C-24 803 User Man.)
#define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE
#define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE
// *** the SDK vector table patch follows
#define NORMAL_ISR_14 FISR_CAN_Transmit
#define NORMAL_ISR_15 FISR_CAN_Receive
My ISRs are named ISR_CAN_Transmit & ISR_CAN_Receive. I put them into a
user .c file, not any SDK-defined file.
I have not yet patched archUserISRTable[ ] or archISRType[ ] or vector.c
(because Chapter 7 said not to). Perhaps that documentation assumes that I
am using a #define to include the whole driver, but I'm not.
Thanks in advance.
P.S. I just received an email virus with the subject "correct
declaration
in C style" from []. The virus was Exploit-MIME.gen.b or
W32/Bugbear@MM. McAfee found it. Beware!
Rick Corey, Software Development
DPC Instrument Systems Division, Flanders NJ
|