|
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/ |
|
From:
"Art Johnson" <> Date: Fri Oct 11, 2002 1:40 pm Subject: RE: install static NORMAL_ISR_XX in SDK To: "Corey, Rick" <> |
|
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 |
|
|
RE: Development tools for MCF5307
Started by ●December 3, 2002
Reply by ●December 4, 20022002-12-04
|
I am sorry that Art Johnson has chosen to use a public forum to defame Metrowerks. In the same thread he quoted from there are other letters that dispel these questions about our product. I want to assure everyone that Metrowerks is totally committed to providing the finest quality development tools available. Art has consistently insisted that not putting C constants in P FLASH is a fatal bug. We disagree with this and feel we have a sound reason for not putting constants in P Memory and suggested a way to do this in assembler. Having a dispute over this does not constitute making the worst compiler in history. I publicly posted a message in October to the MotorolaDSP list and on the internet requesting any critical compiler bugs regarding the CodeWarrior for DSP56800 v5.x be reported so we could be sure they were fixed. Only one person replied with any reports. We personally contacted Art Johnson and got all that he considered critical, so we could fix these as soon as possible. Now maybe there are more bugs and there always are improvements that can be made. But judging by the lack of critical problems reported with the current version of CodeWarrior it would seem the majority of people are satisfactorily and productively using CodeWarrior for DSP. We are not claiming to be perfect but it is Metrowerks firm commitment to quality and to strive for excellence. Towards this end Metrowerks will have an update for CodeWarrior for DSP56800 later this month. In September there was another flame war based on our previous version of CodeWarrior. For that I asked that everyone that felt they hadn't been treated fairly contact me. I believe that everyone ended up satisfied with this process, and I offer this as proof that Metrowerks cares about our customers. Based on this real evidence and facts of the quality of our product the number of satisfied customers and the support we provide. I feel quite confident of Metrowerks commitment to CodeWarrior for quality tools. So if you have a legitimate grievance please let us know, Please feel free to contact me personally. I will make sure that the president of Metrowerks is made aware of the problems. But please keep it civil and please be realistic. Thank you for listening. Ron -- Ron Liechty, Ombudsman for Metrowerks Corporation |
|
|
Reply by ●December 4, 20022002-12-04
|
Ron, I consider it totally appropriate that customers share their perceptions on a public forum, as Art does. We need to share our experiences frankly in order to perform our jobs effectively and be intelligent customers. Furthermore, I agree with Art completely, that I've never used a commercial product with as many significant defects as CW for the 56803. Furthermore, if it were not for the extremely valuable free support that Art and a few others in this Yahoo group supply for your product on a daily basis, my company would have had no choice but to dump the 803 chip out of our design (at great cost in lost time) and start over from scratch with a TI DSP. Critical Bugs: Ron: >> Only one person replied with any reports. << Was I the *only* person who responded? Perhaps we are partly to blame that we only complain to each other, and do not spend the hours of time required to get even an acknowledgment from Metrowerks of problems that we are very aware of. Perhaps that has come about because asking a question in this forum invariably gets rapid, well-informed responses, often with workarounds and sample code, and time spent sending information to Metrowerks does not. My own biggest beef was that "pragma interrupt saveall" did not even put an RTI into an ISR. That may not meet your criteria for a "critical compiler bug", but it does meet my criteria. For that bug to not be listed in large print in an errata list is amazing to me. For it to exist at all in version 5 of a product was amazing. It required repeated Emails and extremely detailed explanations from me to even get Metrowerks to acknowledge the problem. This is not a "finest quality issue", it is a gross bug which could hardly have escaped any adequate testing process. Another potentially critical debugger issue is that putting a breakpoint on a line like if (pointer == NULL) will cause the test to branch the wrong way sometimes. I would not have thought that anyone who followed the messages in this forum could be unaware of multiple serious defects, whether or not they were called "critical". In my offline conversations with you, I've agreed that Metrowerks is probably working as hard as they can to address major problems. However, I am certainly not "satisfactorily and productively using CodeWarrior for DSP". If you took that impression from anything I've said, I'm sorry that you got the opposite impression from the facts. CodeWarrior's poor quality has almost sunk a project critical to my company. I recently got beat up by my boss and her boss for being eight weeks late on a five week deadline (entirely because the CW compiler/debugger is of such terrible quality). Without the SDK, the CW compiler would be completely unusable. Without the support received from this group, it would still be completely unusable. I've gotten infinitely better support from this group, and Art Johnson in particular than from Metrowerks. I've even gotten better support from Motorola for working around problems with CW tools, than I have gotten from Metrowerks. "finest quality" I'm sure that Metrowerks is "totally committed to providing the finest quality development tools available", in your words. However, in my experience, the quality of 5.02 is by far the worst of any commercial software product I've used in 20 years of software development, including freeware. I'm sorry to be so blunt, but I have to take issue with any reference to "finest quality" in connection with this tool. For the 56803, my company is using CW only because it is the only commercial tool available. We keep looking for another vendor, because we need a commercial-quality tool immediately, and Metrowerks has not delivered that yet. If we had known the quality of 5.02, we would certainly not have designed this chip into our current biggest project. I appreciate Metrowerks' efforts to improve their product, and understand how limited resources can result in delays in addressing known problems. Presumably the 5680x family does not have a high enough volume yet to gain higher priority with Metrowerks or other compiler vendors. We're lucky to have an option besides assembler. The only sense in which I was "satisfied" with Metrowerks was that you convinced me that they were working as hard as their resources permitted on many known, serious problems. However, if the Metrowerks attitude is that there are no known critical issues, I am very deeply disappointed and seriously concerned for the future of our project using the 56803. Regretfully, Rick Corey -----Original Message----- From: MW Ron [mailto:] Sent: Wednesday, December 04, 2002 9:06 AM To: Art Johnson; Tom Burrell; Coldfire CPU Discussion List Cc: Corey, Rick; ; Kevin Ackerley (E-mail); Ed Baillie (E-mail); Ken Andreasen; JB Bjorknas; Greg Clark; Greg Coonley (E-mail); Dick Fons (E-mail) Subject: Re: Development tools for MCF5307 I am sorry that Art Johnson has chosen to use a public forum to defame Metrowerks. In the same thread he quoted from there are other letters that dispel these questions about our product. I want to assure everyone that Metrowerks is totally committed to providing the finest quality development tools available. Art has consistently insisted that not putting C constants in P FLASH is a fatal bug. We disagree with this and feel we have a sound reason for not putting constants in P Memory and suggested a way to do this in assembler. Having a dispute over this does not constitute making the worst compiler in history. I publicly posted a message in October to the MotorolaDSP list and on the internet requesting any critical compiler bugs regarding the CodeWarrior for DSP56800 v5.x be reported so we could be sure they were fixed. Only one person replied with any reports. We personally contacted Art Johnson and got all that he considered critical, so we could fix these as soon as possible. Now maybe there are more bugs and there always are improvements that can be made. But judging by the lack of critical problems reported with the current version of CodeWarrior it would seem the majority of people are satisfactorily and productively using CodeWarrior for DSP. We are not claiming to be perfect but it is Metrowerks firm commitment to quality and to strive for excellence. Towards this end Metrowerks will have an update for CodeWarrior for DSP56800 later this month. In September there was another flame war based on our previous version of CodeWarrior. For that I asked that everyone that felt they hadn't been treated fairly contact me. I believe that everyone ended up satisfied with this process, and I offer this as proof that Metrowerks cares about our customers. Based on this real evidence and facts of the quality of our product the number of satisfied customers and the support we provide. I feel quite confident of Metrowerks commitment to CodeWarrior for quality tools. So if you have a legitimate grievance please let us know, Please feel free to contact me personally. I will make sure that the president of Metrowerks is made aware of the problems. But please keep it civil and please be realistic. Thank you for listening. Ron -- Ron Liechty, Ombudsman for Metrowerks Corporation |
Reply by ●December 4, 20022002-12-04
|
Ron, going back over my records of all the problems we have had, the
"const in P memory" bug was a very small tip of a very big iceberg. Even if it was removed from the list, that only constituted 2 weeks out of the 8 months our product launches have been delayed. When the CPU was being chosen for all of our new designs, the two finalists were the ColdFire family and the DSP56800 family. I have been told very bluntly by senior management that if we had known about these sorts of problems back then, that the ColdFire family would have been the winner. It still may turn out that way. As you know, anytime that CodeWarrior is unfairly blamed for some problem, I am the first one on the discussion group to point out that the fault does not lie with CodeWarrior. One example of this was the "Reset and One Vector" bug report, in which I spent over 6 hours of my extremely limited personal spare time to prove that the problem did not lie with CodeWarrior. So, to say that I am "unfairly defaming" CodeWarrior simply does not hold water. Absolutely everything I have said is very well documented here, although for confidentiality reasons I am not permitted to make this information available outside our company. I do feel a personal responsibility to voice my opinions and experiences based on my 31+ years of hardware design experience, and 26+ years of software development experience. I would hope that if I had asked these sorts of questions during the time we were choosing the CPU family for our new products, that the members of these discussion groups would give their honest and unvarnished opinions and experiences of the hardware and software products being discussed. Sincerely, 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: MW Ron [mailto:] Sent: Wednesday, December 04, 2002 6:06 AM To: Art Johnson; Tom Burrell; Coldfire CPU Discussion List Cc: Corey, Rick; ; Kevin Ackerley (E-mail); Ed Baillie (E-mail); Ken Andreasen; JB Bjorknas; Greg Clark; Greg Coonley (E-mail); Dick Fons (E-mail) Subject: Re: Development tools for MCF5307 I am sorry that Art Johnson has chosen to use a public forum to defame Metrowerks. In the same thread he quoted from there are other letters that dispel these questions about our product. I want to assure everyone that Metrowerks is totally committed to providing the finest quality development tools available. Art has consistently insisted that not putting C constants in P FLASH is a fatal bug. We disagree with this and feel we have a sound reason for not putting constants in P Memory and suggested a way to do this in assembler. Having a dispute over this does not constitute making the worst compiler in history. I publicly posted a message in October to the MotorolaDSP list and on the internet requesting any critical compiler bugs regarding the CodeWarrior for DSP56800 v5.x be reported so we could be sure they were fixed. Only one person replied with any reports. We personally contacted Art Johnson and got all that he considered critical, so we could fix these as soon as possible. Now maybe there are more bugs and there always are improvements that can be made. But judging by the lack of critical problems reported with the current version of CodeWarrior it would seem the majority of people are satisfactorily and productively using CodeWarrior for DSP. We are not claiming to be perfect but it is Metrowerks firm commitment to quality and to strive for excellence. Towards this end Metrowerks will have an update for CodeWarrior for DSP56800 later this month. In September there was another flame war based on our previous version of CodeWarrior. For that I asked that everyone that felt they hadn't been treated fairly contact me. I believe that everyone ended up satisfied with this process, and I offer this as proof that Metrowerks cares about our customers. Based on this real evidence and facts of the quality of our product the number of satisfied customers and the support we provide. I feel quite confident of Metrowerks commitment to CodeWarrior for quality tools. So if you have a legitimate grievance please let us know, Please feel free to contact me personally. I will make sure that the president of Metrowerks is made aware of the problems. But please keep it civil and please be realistic. Thank you for listening. Ron -- Ron Liechty, Ombudsman for Metrowerks Corporation |
Reply by ●December 4, 20022002-12-04
|
I have intentionally tried to stay away from this discussion concerning
quality of the toolset, since this is my first forray into the
Motorola/Metrowerks toolset in over 20 years. I have a 29 year history of
developing products starting with doing logic with discrete transistor
alu's, micro-programmed IC's, to 8-bit through 32 bit
micrpprocessors, thus, I have seen a lot of hardware. In our business we
are constantly faced with the tradeoff between high-level language programming
and "C." Whether it is the quality of the compiler, or the quality of the
programmers who are producing the compiler features, or the quality of the
management team controlling the development and marketing of the toolset, the
real issue is whether or not the toolset is adequate to get the job
done.
What amazes me about the current compiler war, is that while the
marketable feature list is long, and there are impressive GUI interfaces,
when I change the optimization setting from compile for speed, to compile for
size, or any of the points in between, the size of the object code does not
change by a single word!!! I then ask myself is this all window
dressing? Is this a warmed over interface, that was designed for 32-bit
processors? Are the instruction set, and register set totally
misunderstood by the compiler writers? Do they have no concept for
dealing with the trade-off between speed and size on this processor?
Perhaps there is no trade-off that can be conceived by a programming/management
team that may be doing this as a favor to Motorola!!!
The bottom line is this: As long as the assembler generates the
correct bit patterns for the documented instructions, in the real
world of getting code working, products can be produced. As Art has
pointed out.
Whenever I get code that is wrong, or fails, I will tend to revert to
assembler. To some of you, that is patent heresy! I know that, but I
refuse to believe that the only way to write code, is to use
"C."
My biggest complaint is that the decision has been made, early on it
would appear, to not publish the opcodes, and open the door to competition such
as the GNU compiler. While this makes it difficult for us assembly
language hackers to assist in debugging the compiler output, it also means that
the compiler writers are not on a level playing field, and there are few
incentives to invest in the development of good optimization
techniques.
Right now, I may have to re-write our proprietary boot loader in
assembler, since the original code (written under version 4), now no longer fits
into boot flash when compiled by version 5.0.2!!! It overflows by 75
words, and the increase in size was over 10%.
Respectfully,
Jerry L. Johnson
(JJ)
Sheffield Automation, LLC Fond Du Lac, WI j...@giddings.com
|
Reply by ●December 4, 20022002-12-04
|
Hi All, This reply from Ron makes me sick. Maybe Ron needs to get out of his cozy little shell and dig a little deeper. I have reported bugs that other people have reported as bugs and nothing has been done about them. I have wasted a lot of our company's product development time, as Art Johnson has, finding and making "work arounds" for bugs. Also wasting time with Metrowerks Tech support trying to report them so the product would be better. But to little or no satisfaction because things just get dropped. Ron's post a while back where they want the "critical compiler bugs" is a joke. How about all bugs including the ones we have to find and make work arounds for? ("just report them through normal channels" so they can get dropped again?) That post got me going but the one below needed a response. Until Metrowerks gets someone to seriously look into bugs other than the lower echelons of the Tech Support System nothing will really get better than the mediocre level at which it is now. Maybe the Tech Support people need a better way to raise the level of an issue when they see something that looks bad but do not have the time or maybe the knowledge to get to the bottom of it. Pete PS: How about this little "CWirk" of CW that I just received, while writing the above, from a contract developer working for us. You just need to change dvc_gpio.h to dvc_io.h, iodyn_config.h to io_dyn_cfg.h in every source file where it applies. Strictly speaking my builds should not compile without errors. I think that the IDE caches the headers so when I changed the file names and forgot to change the names in the source files the IDE used the cached versions. This is a little upsetting because before every build I select "remove object code; recurse subtarget and subprojects; compact target" which I thought cleared every cache. --- In motoroladsp@y..., MW Ron <mwron@m...> wrote: > > I am sorry that Art Johnson has chosen to use a public forum to defame > Metrowerks. In the same thread he quoted from there are other letters that > dispel these questions about our product. I want to assure everyone that > Metrowerks is totally committed to providing the finest quality development > tools available. > > Art has consistently insisted that not putting C constants in P FLASH is a > fatal bug. We disagree with this and feel we have a sound reason for not > putting constants in P Memory and suggested a way to do this in assembler. > Having a dispute over this does not constitute making the worst compiler in > history. > > I publicly posted a message in October to the MotorolaDSP list and on the > internet requesting any critical compiler bugs regarding the CodeWarrior for > DSP56800 v5.x be reported so we could be sure they were fixed. Only one > person replied with any reports. We personally contacted Art Johnson and > got all that he considered critical, so we could fix these as soon as > possible. > > Now maybe there are more bugs and there always are improvements that can be > made. But judging by the lack of critical problems reported with the > current version of CodeWarrior it would seem the majority of people are > satisfactorily and productively using CodeWarrior for DSP. We are not > claiming to be perfect but it is Metrowerks firm commitment to quality and > to strive for excellence. Towards this end Metrowerks will have an update > for CodeWarrior for DSP56800 later this month. > > In September there was another flame war based on our previous version of > CodeWarrior. For that I asked that everyone that felt they hadn't been > treated fairly contact me. I believe that everyone ended up satisfied with > this process, and I offer this as proof that Metrowerks cares about our > customers. > > Based on this real evidence and facts of the quality of our product the > number of satisfied customers and the support we provide. I feel quite > confident of Metrowerks commitment to CodeWarrior for quality tools. > > So if you have a legitimate grievance please let us know, Please feel free > to contact me personally. I will make sure that the president of Metrowerks > is made aware of the problems. But please keep it civil and please be > realistic. > > Thank you for listening. > > Ron > > -- > > Ron Liechty, MWRon@m... > Ombudsman for Metrowerks Corporation |
|
|
Reply by ●December 4, 20022002-12-04
|
Pete Becher wrote: > This reply from Ron makes me sick. Maybe Ron needs to get out of his > cozy little shell and dig a little deeper. > > I have reported bugs that other people have reported as bugs and > nothing has been done about them. Perhaps we are just a but slower reacting but I can assure you that things are being done and there is a new patch that is imminent that fixes many reported problems > Ron's post a while back where they want the "critical compiler bugs" > is a joke. No it wasn't. You see Metrowerks really does follow through on these things so perhaps you assumed by past history with other firms that this was just PR but it wasn't it was real. Those that sent in their critical bugs are getting them fixed. > How about all bugs including the ones we have to find and > make work arounds for? ("just report them through normal channels" so > they can get dropped again?) That post got me going but the one > below needed a response. Alas the non-critical bugs will be fixed in a future version, with Metrowerks we have a lower upfront cost but have regular updated versions. I know that this is a model that many embedded developers are not familiar with and I think this may be a point of contention. > Until Metrowerks gets someone to seriously look into bugs other than > the lower echelons of the Tech Support System nothing will really get > better than the mediocre level at which it is now. When you write to me and when I reply as ombudsman of Metrowerks you an be assured that this is going to be investigated and there will be a report sent to senior management. > PS: How about this little "CWirk" of CW that I just received, while > writing the above, from a contract developer working for us. This looks like the person was using a precompiled header and didn't re-precompile it. If you can send me more information on it, (if indeed that is not the case) I will look into it. It really does not make sense in the way it is described unless there was a precompiled header involved. Ron > You just need to change dvc_gpio.h to dvc_io.h, iodyn_config.h to > io_dyn_cfg.h in every source file where it applies. Strictly speaking > my builds should not compile without errors. I think that the IDE > caches the headers so when I changed the file names and forgot to > change the names in the source files the IDE used the cached > versions. This is a little upsetting because before every build I > select "remove object code; recurse subtarget and subprojects; > compact target" which I thought cleared every cache. -- Can you really afford not to use CodeWarrior 8.3 ? Faster Compiles, Improved Code Generation, Updated IDE for OS X 10.2 http://www.metrowerks.com/MW/Support/Download/default.htm Ron Liechty - - http://www.metrowerks.com -- Can you really afford not to use CodeWarrior 8.3 ? Faster Compiles, Improved Code Generation, Updated IDE for OS X 10.2 http://www.metrowerks.com/MW/Support/Download/default.htm Ron Liechty - - http://www.metrowerks.com |
|
|
Reply by ●December 5, 20022002-12-05
|
--- In motoroladsp@y..., MW Ron <mwron@m...> wrote: > Pete Becher wrote: > > > PS: How about this little "CWirk" of CW that I just received, while writing the above, from a contract developer working for us. > > > You just need to change dvc_gpio.h to dvc_io.h, iodyn_config.h to > > io_dyn_cfg.h in every source file where it applies. Strictly speaking > > my builds should not compile without errors. I think that the IDE > > caches the headers so when I changed the file names and forgot to > > change the names in the source files the IDE used the cached > > versions. This is a little upsetting because before every build I > > select "remove object code; recurse subtarget and subprojects; > > compact target" which I thought cleared every cache. > > -- > This looks like the person was using a precompiled header and didn't re-precompile it. If you can send me more information on it, (if indeed that is not the case) I will look into it. It really does not make sense in the way it is described unless there was a precompiled header involved. > > Ron > Hi Ron, The following is the response from our developer. >I didn't explicitly set out to create a precompiled header and I don't think that I followed the procedure below (CW help on procompiled headers) by accident. In the Windows and AVR programming environment using precompiled headers is a build option that can be selected with a check box and file name. That is what I would have tried to do first. So I'm confused. So it looks like it "just happened". Pete |
|
|
Reply by ●December 5, 20022002-12-05
|
CodeWarrior for DSP Warriors. A lot of constructive comments were made in the past couple days and one that struck me deeply was that Metrowerks was not communicating well with our users as to what were were doing. We had hoped to have a patch out next week but a bug was found which makes us have to do regression testing all over after the fix (since bug fixes have habits of creating new bugs elsewhere). So the earliest possible date that we can release this patch is December 18th. Also due to Motorola shutting down over the holidays, so the employees can spend time with families, this means that if we find another unexpected bug that it will be delayed until the first of January. However in order to communicate better with you, these are the bugs that are fixed in the 5.03 patch. Please note that there is a 5.1 upgrade expected in the first quarter of next year that will have improvements and more less severe bugs fixed in it. WB1-30992 An extra long line or a line continuation within an expression or assignment statement causes internal compiler error: 'Registers.c' Line: 385 WB1-31351 IDE crashes during the compiling of inline asm BRA instruction (error should be generated) WB1-31735 Using the "Deferred Inlining" option (C/C++ Language) with 2 interrupts, the compiler doesn't generate a correct code WB1-38509 The compiler generates a wrong code for the operation of 2 tables WB1-39699 do instruction is generated even when "Allow DO insturctions" is off WB1-30429 DSP56F80x MetroWerks compiler bug in function call arguments. WB1-38232 Test fails for int13.c test WB1-38233 Test fails for mix10.c test when Peephole Optmization option is ON WB1-38235 Test fails for ne.c test WB1-38237 Test fails for quest.c test. WB1-38242 Test case returns failed result with Global Opt level at L2 and up WB1-38245 The test case fails when MSL hostIO library is built with Global Opt at L2 and up. WB1-38329 Multiplication and Parameter Passing Defects with Global Opt 2,3,4 WB1-38593 The compiler crashes and closes the IDE for a particular statement WB1-37594 Optimization for constant pointers lost between version 4 and version 5 of the compiler WB1-39740 Output is wrong with Optimization level two or up. I hope that this gives you confidence that we are doing as much as we can as quickly as we can to provide useful quality tools. Again many things will be improved in our 5.1 upgrade but I think we have the critical bugs hit with this patch. Thanks Ron Ron Liechty Ombudsman for Metrowerks |
|
|
Reply by ●December 19, 20022002-12-19
|
As a follow up to Ron's post regarding the 5.0.3 patch. The patch is now available on our website at: http://www.metrowerks.com/MW/Support/Download/default.htm The several bugs that are fixed with this patch release are listed on the website for your information so I will not repeat it all here. Just wanted to post and follow up to show we are being responsive to customer's needs. Happy Holidays everyone! Regards, John --- In , MW Ron <mwron@m...> wrote: > > CodeWarrior for DSP Warriors. > > A lot of constructive comments were made in the past couple days and one > that struck me deeply was that Metrowerks was not communicating well with > our users as to what were were doing. > > We had hoped to have a patch out next week but a bug was found which makes > us have to do regression testing all over after the fix (since bug fixes > have habits of creating new bugs elsewhere). So the earliest possible date > that we can release this patch is December 18th. > > Also due to Motorola shutting down over the holidays, so the employees can > spend time with families, this means that if we find another unexpected bug > that it will be delayed until the first of January. > > However in order to communicate better with you, these are the bugs that are > fixed in the 5.03 patch. Please note that there is a 5.1 upgrade expected > in the first quarter of next year that will have improvements and more less > severe bugs fixed in it. > > WB1-30992 An extra long line or a line continuation within an expression > or assignment statement causes internal compiler error: 'Registers.c' Line: > 385 > WB1-31351 IDE crashes during the compiling of inline asm BRA instruction > (error should be generated) > WB1-31735 Using the "Deferred Inlining" option (C/C++ Language) with 2 > interrupts, the compiler doesn't generate a correct code > WB1-38509 The compiler generates a wrong code for the operation of 2 > tables > WB1-39699 do instruction is generated even when "Allow DO insturctions" > is off > WB1-30429 DSP56F80x MetroWerks compiler bug in function call arguments. > WB1-38232 Test fails for int13.c test > WB1-38233 Test fails for mix10.c test when Peephole Optmization option > is ON > WB1-38235 Test fails for ne.c test > WB1-38237 Test fails for quest.c test. > WB1-38242 Test case returns failed result with Global Opt level at L2 and > up > WB1-38245 The test case fails when MSL hostIO library is built with > Global Opt at L2 and up. > WB1-38329 Multiplication and Parameter Passing Defects with Global Opt > 2,3,4 > WB1-38593 The compiler crashes and closes the IDE for a particular > statement > WB1-37594 Optimization for constant pointers lost between version 4 and > version 5 of the compiler > WB1-39740 Output is wrong with Optimization level two or up. > > I hope that this gives you confidence that we are doing as much as we can as > quickly as we can to provide useful quality tools. Again many things will > be improved in our 5.1 upgrade but I think we have the critical bugs hit > with this patch. > > Thanks > > Ron > > Ron Liechty > Ombudsman for Metrowerks > MWRon@m... |
