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