56303 | 563xx | 5680 | 56805 | 5680x | 56F80 | 56F800DEMO | 56F805 | 56f807 | 56F830 | ADC | Bootloader | Codec | CodeWarrior | CW5 | CW6 | Debugger | DSP56303 | DSP56303EVM | DSP563xx | DSP5680 | DSP56800 | DSP56807 | DSP56858 | DSP56858EVM | DSP56F803 | DSP56F805 | DSP56F807 | DSP56F80x | DSP56F826 | DSP56F827 | DSP56F8xx | EVM | FFT | Flash_over_jtag | GPIO | Interrupt | Interrupts | JTAG | LCD | Linker | MCF5307 | Metrowerks | Modulus | MSCAN | PCMaster | PWM | Quad | Rif | RTOS | SDK | SPI

Ron, Art and others may be wrong about “what the product should be” but they are the customers are they not? I hope that if there is something that I don’t like about the product that I will be appeased rather than just being told that it’s my opinion of how the product should work. Maybe it would be nice if features they are requesting could be options in later revisions. The Art's const problem seems reasonable to me. It also seems to me that for the amount of free support that Art offers to the Metrorola community that he would be the last person to you would want to alienate by saying that the feature he thinks should be in the compiler is just his opinion. Yes, you are right, it is just his opinion and I’m sure he expresses his opinion with the dollars he spends as well. “It also helps if people report bugs so we can gather a common factor or judge how much of a priority to put on any one bug so it is fixed.” Please don’t judge the seriousness of a bug by lack of reporting. I really appreciated the request for critical bug reports, but I didn’t submit anything because I felt that what others were complaining about seemed “more important” than my problems. From now on I’m just going to report all bugs so that they can be added and attacked by Motowerks. In general I can say that I have been very happy with CodeWarrior and my development has gone pretty smoothly. I have no plans to change tools sets or processors, because of the great support I have received from Motorola, Metrowerks and this message board. In fact I am certain that my next project will use either the 56000 or 56000E if the support level remains the same. My biggest problem to date had to do with bad silicon of which Motorola was very quick to replace. I am very grateful to know of some of the gotchas that Art and others found, a couple of which I think are very hazardous problems that MUST be fixed. These problems have not YET affected me but I know they one day will if they are not fixed. Another thing I think we should see more of from Motowerks is the fantastic support I had from Leonard when he opened a Motorola tech support case from messages I posted on this board. I know it’s not a typical procedure, but I highly recommend that Metoroloa continue the practice. In fact in my little company I recommend to my customers that all tech support issues be raised on the public message boards for the products so that there can be open discussion and usually faster and better answers from my customers than I can offer (oh, btw, my message board has un-moderated posts so that information can flow faster (nudge nudge, wink wink)) So here is my list of Metrorola issues, not all are bugs 1) SDK defaults to dynamic memory. A few of the libraries are written in such a way that they require dynamic memory, when the projects are switched to Flash projects they no longer work because the linker files are not properly setup or some other such business. Motowerks claims that this was done to make prototyping easier (quicker) but. I can’t remember any product that I created that didn’t have the firmware installed in some kind of non-volatile memory and I have had to hunt down what is causing my link to fail when I chosen to use a library that refuses to go easily into flash. My question, doesn't’t make more since to make it work in flash from the get go, and will you please fix it so others don’t have to spend extra time to use the code how they will need to use it? 2) Every time I add files to my project the CW IDE tells me that one or more files could not be added to my project, yet they ALL successfully add... Huh? I consider this a minor bug but extremely annoying and equally easy to fix. I suppose it’s my fault if it does not get fixed for not reporting it. 3) Disassembled C riddle with NOP’s. I know that the N register needs a nop on Rev A silicone of the 827, but I don’t think the R0 register does??? ioctl(FileDesc, GPIO_TOGGLE, gpioPin(B,0)); becomes: movie #4033, R0 nop move X:(R0), X0 bfchg #0x1, X0 move X0, X:(R0) This is not the only code that I have found that generates NOP’s, As a matter of fact I believe there is well over 100 nop's in my code small program. It’s been suggested to me that this problem comes about because of how the SDK implements the bit toggle, (who ever this problem belongs to, I don’t think it’s mine). I know that on Motorola’s web page that they mention that the SDK is an $800 value offered “for free”, but I’m not so sure, I mite pay $50 for it, or I would want my money back. I don't care what the C code looks like, I don't think I should ever see a NOP generated except where noted above. more to follow I'm sure... Jacob

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

Just to answer the "R0" thing quickly, the NOP is required because the changed value in the address register R0 is not available to the next instruction, which is already in the pipeline. Art -----Original Message----- From: Jacob [mailto:] Sent: Friday, December 06, 2002 8:38 AM To: Cc: Subject: [motoroladsp] CW Bugs Ron, Art and others may be wrong about "what the product should be" but they are the customers are they not? I hope that if there is something that I don't like about the product that I will be appeased rather than just being told that it's my opinion of how the product should work. Maybe it would be nice if features they are requesting could be options in later revisions. The Art's const problem seems reasonable to me. It also seems to me that for the amount of free support that Art offers to the Metrorola community that he would be the last person to you would want to alienate by saying that the feature he thinks should be in the compiler is just his opinion. Yes, you are right, it is just his opinion and I'm sure he expresses his opinion with the dollars he spends as well. "It also helps if people report bugs so we can gather a common factor or judge how much of a priority to put on any one bug so it is fixed." Please don't judge the seriousness of a bug by lack of reporting. I really appreciated the request for critical bug reports, but I didn't submit anything because I felt that what others were complaining about seemed "more important" than my problems. From now on I'm just going to report all bugs so that they can be added and attacked by Motowerks. In general I can say that I have been very happy with CodeWarrior and my development has gone pretty smoothly. I have no plans to change tools sets or processors, because of the great support I have received from Motorola, Metrowerks and this message board. In fact I am certain that my next project will use either the 56000 or 56000E if the support level remains the same. My biggest problem to date had to do with bad silicon of which Motorola was very quick to replace. I am very grateful to know of some of the gotchas that Art and others found, a couple of which I think are very hazardous problems that MUST be fixed. These problems have not YET affected me but I know they one day will if they are not fixed. Another thing I think we should see more of from Motowerks is the fantastic support I had from Leonard when he opened a Motorola tech support case from messages I posted on this board. I know it's not a typical procedure, but I highly recommend that Metoroloa continue the practice. In fact in my little company I recommend to my customers that all tech support issues be raised on the public message boards for the products so that there can be open discussion and usually faster and better answers from my customers than I can offer (oh, btw, my message board has un-moderated posts so that information can flow faster (nudge nudge, wink wink)) So here is my list of Metrorola issues, not all are bugs... 1) SDK defaults to dynamic memory. A few of the libraries are written in such a way that they require dynamic memory, when the projects are switched to Flash projects they no longer work because the linker files are not properly setup or some other such business. Motowerks claims that this was done to make prototyping easier (quicker) but. I can't remember any product that I created that didn't have the firmware installed in some kind of non-volatile memory and I have had to hunt down what is causing my link to fail when I chosen to use a library that refuses to go easily into flash. My question, doesn't't make more since to make it work in flash from the get go, and will you please fix it so others don't have to spend extra time to use the code how they will need to use it? 2) Every time I add files to my project the CW IDE tells me that one or more files could not be added to my project, yet they ALL successfully add... Huh? I consider this a minor bug but extremely annoying and equally easy to fix. I suppose it's my fault if it does not get fixed for not reporting it. 3) Disassembled C riddle with NOP's. I know that the N register needs a nop on Rev A silicone of the 827, but I don't think the R0 register does??? ioctl(FileDesc, GPIO_TOGGLE, gpioPin(B,0)); becomes: movie #4033, R0 nop move X:(R0), X0 bfchg #0x1, X0 move X0, X:(R0) This is not the only code that I have found that generates NOP's, As a matter of fact I believe there is well over 100 nop's in my code small program. It's been suggested to me that this problem comes about because of how the SDK implements the bit toggle, (who ever this problem belongs to, I don't think it's mine). I know that on Motorola's web page that they mention that the SDK is an $800 value offered "for free", but I'm not so sure, I mite pay $50 for it, or I would want my money back. I don't care what the C code looks like, I don't think I should ever see a NOP generated except where noted above. more to follow I'm sure... Jacob _____________________________________ /groups.php3

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

Jacob, I am going to step in here and try to help out a bit. We indeed have listened and carefully considered Art's suggestion of being able to access constant data from C in Program ROM. However, this is no small task or feature to add, and we would have a hard time putting this into the timeframe for the next major release as it is not something trivial to add. It is currently possible with the existing toolset to access constant data from Flash ROM, but it is just not very easy and must be done all via Assembly since you cannot employ C pointers to Program space. We do listen to our customers and are trying our best to implement what features are being asked for, but some just cannot be implemented due to time constraints and resources, but this one is definitely on the list to be considered....just FYI. We also are not trying to alienate Art by any means as he has been a great source of support for DSP56800 developers and we certainly recognize that, we were just trying to put his comments in perspective and try to be fair to us as a company. > From now on I'm just going to report all bugs > so that they can be added and attacked by Motowerks. COMMENTS: OK, submit away. We appreciate the feedback. The best way would be to contact and submit a small test case if you have one. Or you can submit via our webpage: http://www.metrowerks.com/MW/Support/Contact+Support/bug.htm Either way you issue should be examined and investigated. We also have a newsgroup for codewarrior specific items "codewarrior.embedded" which you can post questions regarding DSP56800, DSP56800E, 68K/CF, 8/16 bit, EPPC, MIPS, and ARM related CW products. We try to monitor that and this newsgroup as best we can on top of handling the incoming support issues. :-) > 1) SDK defaults to dynamic memory. A few of the libraries are written in > such a way that they require dynamic memory, when the projects are switched > to Flash projects they no longer work because the linker files are not > properly setup or some other such business. Motowerks claims that this was > done to make prototyping easier (quicker) but. I can't remember any product > that I created that didn't have the firmware installed in some kind of > non-volatile memory and I have had to hunt down what is causing my link to > fail when I chosen to use a library that refuses to go easily into flash. > My question, doesn't't make more since to make it work in flash from the get > go, and will you please fix it so others don't have to spend extra time to > use the code how they will need to use it? COMMENTS: I disagree with your assertion that it is easier to work from flash from the get go. Since the DSP56800 supports the Development Mode which uses all external memory it's great for debugging code purposes (if you have this available on your target .... all of the EVM's except the DSP56F801 can support it) as you are always in RAM and have the highest debugging capabilities (unlimited software breakpoints). You can then spend the time to examine the space usage before switching over to the Flash Target where you are more restricted on your debugging capabilities. I can't really address the SDK dynamic memory complaint. > 2) Every time I add files to my project the CW IDE tells me that one or more > files could not be added to my project, yet they ALL successfully add... > Huh? I consider this a minor bug but extremely annoying and equally easy to > fix. I suppose it's my fault if it does not get fixed for not reporting it. The source of this error is due to the fact that one of the targets that the file is being added into has no linker selected in the Target Settings Panel (selecting a linker in the Target Settings Panel creates most of the product specific target settings). However, there are 2 common reasons customers encounter this error. They are listed below: 1) The most common reason this error occurs is when products (like DSP56800, DSP56800E) include "Build All" targets within their included stationery. When customers go to add a file to their stationery project, typically the "Build All" target will be selected by default as one of the targets to add the file to. Since the "Build All" targets typically have no linker associated with the target (since it is simply a target comprised of subtargets), customers will usually see this error when adding a file. It is just basically letting the customer know that it could not add the file to the "Build All" target given the reasons above. The customer could get around this error in the future by being sure to uncheck the "Build All" target when adding files to their project. 2) This error can also occur when a customer has started by using the "Empty Project" stationery and has not selected a linker for the project. > 3) Disassembled C riddle with NOP's. I know that the N register needs a nop > on Rev A silicone of the 827, but I don't think the R0 register does??? > > ioctl(FileDesc, GPIO_TOGGLE, gpioPin(B,0)); > > becomes: > movie #4033, R0 > nop > move X:(R0), X0 > bfchg #0x1, X0 > move X0, X:(R0) On the contrary, there is a pipeline dependency here and the NOP must be present, see below: In Example 4-10 there is a pipeline dependency since the address pointer register written in the first instruction is used in an address calculation in the second instruction. For the case where a dependency is caused by a write to one of these registers, this sequence is not allowed and is flagged by the assembler. This sequence may be fixed by rearranging the instructions or inserting a NOP between the two instructions. Example 4-10. Dependency with a Write to an Address Pointer Register MOVE #$7,R2 ; Write to the R2 register MOVE X:(R2)+,X0 ; R2 register used in address ; arithmetic calculation Regards, John --- In motoroladsp@y..., "Jacob" <jacob@p...> wrote: > > Ron, > > Art and others may be wrong about "what the product should be" but they are > the customers are they not? I hope that if there is something that I don't > like about the product that I will be appeased rather than just being told > that it's my opinion of how the product should work. Maybe it would be nice > if features they are requesting could be options in later revisions. The > Art's const problem seems reasonable to me. It also seems to me that for > the amount of free support that Art offers to the Metrorola community that > he would be the last person to you would want to alienate by saying that the > feature he thinks should be in the compiler is just his opinion. Yes, you > are right, it is just his opinion and I'm sure he expresses his opinion with > the dollars he spends as well. > > "It also helps if people report bugs so we can gather a common factor > or judge how much of a priority to put on any one bug so it is fixed." > > Please don't judge the seriousness of a bug by lack of reporting. I really > appreciated the request for critical bug reports, but I didn't submit > anything because I felt that what others were complaining about seemed "more > important" than my problems. From now on I'm just going to report all bugs > so that they can be added and attacked by Motowerks. > > In general I can say that I have been very happy with CodeWarrior and my > development has gone pretty smoothly. I have no plans to change tools sets > or processors, because of the great support I have received from Motorola, > Metrowerks and this message board. In fact I am certain that my next project > will use either the 56000 or 56000E if the support level remains the same. > My biggest problem to date had to do with bad silicon of which Motorola was > very quick to replace. I am very grateful to know of some of the gotchas > that Art and others found, a couple of which I think are very hazardous > problems that MUST be fixed. These problems have not YET affected me but I > know they one day will if they are not fixed. > > Another thing I think we should see more of from Motowerks is the fantastic > support I had from Leonard when he opened a Motorola tech support case from > messages I posted on this board. I know it's not a typical procedure, but I > highly recommend that Metoroloa continue the practice. In fact in my little > company I recommend to my customers that all tech support issues be raised > on the public message boards for the products so that there can be open > discussion and usually faster and better answers from my customers than I > can offer (oh, btw, my message board has un-moderated posts so that > information can flow faster (nudge nudge, wink wink)) > > So here is my list of Metrorola issues, not all are bugs > > 1) SDK defaults to dynamic memory. A few of the libraries are written in > such a way that they require dynamic memory, when the projects are switched > to Flash projects they no longer work because the linker files are not > properly setup or some other such business. Motowerks claims that this was > done to make prototyping easier (quicker) but. I can't remember any product > that I created that didn't have the firmware installed in some kind of > non-volatile memory and I have had to hunt down what is causing my link to > fail when I chosen to use a library that refuses to go easily into flash. > My question, doesn't't make more since to make it work in flash from the get > go, and will you please fix it so others don't have to spend extra time to > use the code how they will need to use it? > > 2) Every time I add files to my project the CW IDE tells me that one or more > files could not be added to my project, yet they ALL successfully add... > Huh? I consider this a minor bug but extremely annoying and equally easy to > fix. I suppose it's my fault if it does not get fixed for not reporting it. > > 3) Disassembled C riddle with NOP's. I know that the N register needs a nop > on Rev A silicone of the 827, but I don't think the R0 register does??? > > ioctl(FileDesc, GPIO_TOGGLE, gpioPin(B,0)); > > becomes: > movie #4033, R0 > nop > move X:(R0), X0 > bfchg #0x1, X0 > move X0, X:(R0) > > This is not the only code that I have found that generates NOP's, As a > matter of fact I believe there is well over 100 nop's in my code small > program. > > It's been suggested to me that this problem comes about because of how the > SDK implements the bit toggle, (who ever this problem belongs to, I don't > think it's mine). I know that on Motorola's web page that they mention that > the SDK is an $800 value offered "for free", but I'm not so sure, I mite pay > $50 for it, or I would want my money back. I don't care what the C code > looks like, I don't think I should ever see a NOP generated except where > noted above. > > more to follow I'm sure... > > Jacob

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

On the issue that seems to be the major bone of contention, namely the 'const in P memory bug', here is my opinion in considerably more detail: " The following quotation is from the book "The ANSI C Programming Language" Second Edition, by Brian W. Kernighan and Dennis M. Ritchie, on page 211 in Appendix A: Reference Manual: "The purpose of 'const' is to announce objects that may be placed in read-only memory, and perhaps to increase opportunities for optimization." While the word 'may' might possibly be argued about in this context, it is my opinion, and based on personal experience with many other compilers over the last 26+ years, that any product that makes the claim to be 'best in class' would obey not only the letter, but also the spirit of the above statement, which is to say that if it is at all possible, the data which is declared as 'const' WILL be placed into read-only memory. Without exception, every other compiler I have used has done this, and in fact CodeWarrior itself did this, up until version 5 was released. In the DSP56800 Family, "read-only memory" means one of: 1) Program (P) Flash, or 2) Boot (B) Flash, or 3) Data (X) Flash. " So there you have it, my "opinion" in greater detail. I should also mention to you that the above is also the unanimous opinion of all the other "old fogies" like myself with whom I have talked. I truly believe that the above sentence taken from the K&R C book is unambiguous, and cannot be misinterpreted by anyone who understands the English language. One further note: my co-workers have given me the nickname "The Pit Bull". You will find out, if you haven't already, that it is well deserved. 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: Jacob [mailto:] Sent: Friday, December 06, 2002 8:38 AM To: Cc: Subject: [motoroladsp] CW Bugs Ron, Art and others may be wrong about "what the product should be" but they are the customers are they not? I hope that if there is something that I don't like about the product that I will be appeased rather than just being told that it's my opinion of how the product should work. Maybe it would be nice if features they are requesting could be options in later revisions. The Art's const problem seems reasonable to me. It also seems to me that for the amount of free support that Art offers to the Metrorola community that he would be the last person to you would want to alienate by saying that the feature he thinks should be in the compiler is just his opinion. Yes, you are right, it is just his opinion and I'm sure he expresses his opinion with the dollars he spends as well. "It also helps if people report bugs so we can gather a common factor or judge how much of a priority to put on any one bug so it is fixed." Please don't judge the seriousness of a bug by lack of reporting. I really appreciated the request for critical bug reports, but I didn't submit anything because I felt that what others were complaining about seemed "more important" than my problems. From now on I'm just going to report all bugs so that they can be added and attacked by Motowerks. In general I can say that I have been very happy with CodeWarrior and my development has gone pretty smoothly. I have no plans to change tools sets or processors, because of the great support I have received from Motorola, Metrowerks and this message board. In fact I am certain that my next project will use either the 56000 or 56000E if the support level remains the same. My biggest problem to date had to do with bad silicon of which Motorola was very quick to replace. I am very grateful to know of some of the gotchas that Art and others found, a couple of which I think are very hazardous problems that MUST be fixed. These problems have not YET affected me but I know they one day will if they are not fixed. Another thing I think we should see more of from Motowerks is the fantastic support I had from Leonard when he opened a Motorola tech support case from messages I posted on this board. I know it's not a typical procedure, but I highly recommend that Metoroloa continue the practice. In fact in my little company I recommend to my customers that all tech support issues be raised on the public message boards for the products so that there can be open discussion and usually faster and better answers from my customers than I can offer (oh, btw, my message board has un-moderated posts so that information can flow faster (nudge nudge, wink wink)) So here is my list of Metrorola issues, not all are bugs... 1) SDK defaults to dynamic memory. A few of the libraries are written in such a way that they require dynamic memory, when the projects are switched to Flash projects they no longer work because the linker files are not properly setup or some other such business. Motowerks claims that this was done to make prototyping easier (quicker) but. I can't remember any product that I created that didn't have the firmware installed in some kind of non-volatile memory and I have had to hunt down what is causing my link to fail when I chosen to use a library that refuses to go easily into flash. My question, doesn't't make more since to make it work in flash from the get go, and will you please fix it so others don't have to spend extra time to use the code how they will need to use it? 2) Every time I add files to my project the CW IDE tells me that one or more files could not be added to my project, yet they ALL successfully add... Huh? I consider this a minor bug but extremely annoying and equally easy to fix. I suppose it's my fault if it does not get fixed for not reporting it. 3) Disassembled C riddle with NOP's. I know that the N register needs a nop on Rev A silicone of the 827, but I don't think the R0 register does??? ioctl(FileDesc, GPIO_TOGGLE, gpioPin(B,0)); becomes: movie #4033, R0 nop move X:(R0), X0 bfchg #0x1, X0 move X0, X:(R0) This is not the only code that I have found that generates NOP's, As a matter of fact I believe there is well over 100 nop's in my code small program. It's been suggested to me that this problem comes about because of how the SDK implements the bit toggle, (who ever this problem belongs to, I don't think it's mine). I know that on Motorola's web page that they mention that the SDK is an $800 value offered "for free", but I'm not so sure, I mite pay $50 for it, or I would want my money back. I don't care what the C code looks like, I don't think I should ever see a NOP generated except where noted above. more to follow I'm sure... Jacob _____________________________________ /groups.php3

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

Hi Art, Because of your request for this feature, it is one of the things we hope to have as a optional setting in the 5.1 point update. CodeWarrior v5 does not in any way shape or form prohibit you from doing this, if you want this option you can do it in assembly now. We do not do it now because constants in P memory would be significantly slower. Ron Art Johnson wrote: > On the issue that seems to be the major bone of contention, namely the 'const > in P memory bug', here is my opinion in considerably more detail: > > " > The following quotation is from the book "The ANSI > C Programming Language" Second Edition, by Brian W. > Kernighan and Dennis M. Ritchie, on page 211 in > Appendix A: Reference Manual: > > "The purpose of 'const' is to announce objects > that may be placed in read-only memory, and > perhaps to increase opportunities for > optimization." > > While the word 'may' might possibly be argued about > in this context, it is my opinion, and based on > personal experience with many other compilers over > the last 26+ years, that any product that makes the > claim to be 'best in class' would obey not only the > letter, but also the spirit of the above statement, > which is to say that if it is at all possible, the > data which is declared as 'const' WILL be placed > into read-only memory. Without exception, every > other compiler I have used has done this, and in > fact CodeWarrior itself did this, up until version > 5 was released. > > In the DSP56800 Family, "read-only memory" means one of: > 1) Program (P) Flash, or > 2) Boot (B) Flash, or > 3) Data (X) Flash. > " > > So there you have it, my "opinion" in greater detail. I should also mention > to you that the above is also the unanimous opinion of all the other "old > fogies" like myself with whom I have talked. I truly believe that the above > sentence taken from the K&R C book is unambiguous, and cannot be > misinterpreted by anyone who understands the English language. > > One further note: my co-workers have given me the nickname "The Pit Bull". > You will find out, if you haven't already, that it is well deserved. > > Sincerely, > > Art Johnson -- 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

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

>From: "Jacob" <> >Reply-To: <> >To: <> >CC: <> >Subject: [motoroladsp] CW Bugs >Date: Fri, 6 Dec 2002 08:38:08 -0800 It also seems to me that for >the amount of free support that Art offers to the Metrorola community that >he would be the last person to you would want to alienate by saying that >the >feature he thinks should be in the compiler is just his opinion. Yes, you >are right, it is just his opinion and I’m sure he expresses his opinion >with >the dollars he spends as well. The first time I monitored the messages in this group, I thought that Art was connected with either Motorola or Metrowerks. His free support is very valuable. >1) SDK defaults to dynamic memory. A few of the libraries are written in >such a way that they require dynamic memory, when the projects are switched >to Flash projects they no longer work because the linker files are not >properly setup or some other such business. I am also experiencing this. When my project has #define INCLUDE_MEMORY in the appconfig.h and #include "mem.h" in one of the modules, I can't compile to flash anymore. One of the things that Motorola/Metrowerks should improve is their documentation. It is not newbie friendly. Recently, I was trying to run the PWM on the DSP56F805 using the SDK. I had a hard time getting the duty cycle correctly. In assembly, we all know that the duty cycle is the value in the PWM value register divided by the value in the PWM modulo register. But in SDK, the duty cycle is the value you place in the PWM value register divided by 0x7fff. I never found that in the documentation. I was able to deduce it by watching the values of the registers (I lost time too). Sometimes, dealing with SDK is like solving a puzzle. Roger

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

Hi Ron, Thanks for this message, it gives me a much better feeling regarding Metrowerks' responsiveness to our Bug Reports, and to our requests for changes or feature enhancements. We do realize that accessing data in P memory is slower than accessing data in X RAM, but in our designs it is much more important to save the Data (X) RAM memory locations that are used. The cost (and in some cases, the physical size) of an external high-speed RAM chip is prohibitively high, and the savings we get by not having to add one of these RAM chips are more than worth the "cost" of a few extra CPU clock cycles here and there. In fact, for our products, the "benefits" of putting the 'const' data in P Flash instead of X RAM outweigh the "costs" by a factor of about 10000:1. Best regards, Art -----Original Message----- From: MW Ron [mailto:] Sent: Friday, December 06, 2002 4:34 PM To: Subject: Re: [motoroladsp] CW Bugs Hi Art, Because of your request for this feature, it is one of the things we hope to have as a optional setting in the 5.1 point update. CodeWarrior v5 does not in any way shape or form prohibit you from doing this, if you want this option you can do it in assembly now. We do not do it now because constants in P memory would be significantly slower. Ron Art Johnson wrote: > On the issue that seems to be the major bone of contention, namely the 'const > in P memory bug', here is my opinion in considerably more detail: > > " > The following quotation is from the book "The ANSI > C Programming Language" Second Edition, by Brian W. > Kernighan and Dennis M. Ritchie, on page 211 in > Appendix A: Reference Manual: > > "The purpose of 'const' is to announce objects > that may be placed in read-only memory, and > perhaps to increase opportunities for > optimization." > > While the word 'may' might possibly be argued about > in this context, it is my opinion, and based on > personal experience with many other compilers over > the last 26+ years, that any product that makes the > claim to be 'best in class' would obey not only the > letter, but also the spirit of the above statement, > which is to say that if it is at all possible, the > data which is declared as 'const' WILL be placed > into read-only memory. Without exception, every > other compiler I have used has done this, and in > fact CodeWarrior itself did this, up until version > 5 was released. > > In the DSP56800 Family, "read-only memory" means one of: > 1) Program (P) Flash, or > 2) Boot (B) Flash, or > 3) Data (X) Flash. > " > > So there you have it, my "opinion" in greater detail. I should also mention > to you that the above is also the unanimous opinion of all the other "old > fogies" like myself with whom I have talked. I truly believe that the above > sentence taken from the K&R C book is unambiguous, and cannot be > misinterpreted by anyone who understands the English language. > > One further note: my co-workers have given me the nickname "The Pit Bull". > You will find out, if you haven't already, that it is well deserved. > > Sincerely, > > Art Johnson -- 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 _____________________________________ /groups.php3

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

> >1) SDK defaults to dynamic memory. A few of the libraries > are written in > >such a way that they require dynamic memory, when the > projects are switched > >to Flash projects they no longer work because the linker > files are not > >properly setup or some other such business. > I am also experiencing this. When my project has #define > INCLUDE_MEMORY in > the appconfig.h and #include "mem.h" in one of the modules, I > can't compile > to flash anymore. I found a similar problem too. But cause was not in SDK but in Metrowerks MSL (C runtime library). You can get this when you use the 'sprintf()' function (from stdio library) without use of dynamic memory configured ... Richard Kis

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

Just to clear up one error in your message, CodeWarrior did the correct thing about putting 'const' data into P memory, right up to the last 4.x.x patch that was released. It was only in version 5.0.0 that this bug was (apparently intentionally) introduced. So, you should be able to use reversion in your Revision Control System (RCS), and put it back the way it used to be, which was the CORRECT way. In my several decades of experience with various RCSs, this is a very simple thing to do, if your RCS is set up and maintained properly. 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: jdw_atx [mailto:] Sent: Friday, December 06, 2002 11:32 AM To: Subject: [motoroladsp] Re: CW Bugs Jacob, I am going to step in here and try to help out a bit. We indeed have listened and carefully considered Art's suggestion of being able to access constant data from C in Program ROM. However, this is no small task or feature to add, and we would have a hard time putting this into the timeframe for the next major release as it is not something trivial to add. It is currently possible with the existing toolset to access constant data from Flash ROM, but it is just not very easy and must be done all via Assembly since you cannot employ C pointers to Program space. We do listen to our customers and are trying our best to implement what features are being asked for, but some just cannot be implemented due to time constraints and resources, but this one is definitely on the list to be considered....just FYI. We also are not trying to alienate Art by any means as he has been a great source of support for DSP56800 developers and we certainly recognize that, we were just trying to put his comments in perspective and try to be fair to us as a company. > From now on I'm just going to report all bugs > so that they can be added and attacked by Motowerks. COMMENTS: OK, submit away. We appreciate the feedback. The best way would be to contact and submit a small test case if you have one. Or you can submit via our webpage: http://www.metrowerks.com/MW/Support/Contact+Support/bug.htm Either way you issue should be examined and investigated. We also have a newsgroup for codewarrior specific items "codewarrior.embedded" which you can post questions regarding DSP56800, DSP56800E, 68K/CF, 8/16 bit, EPPC, MIPS, and ARM related CW products. We try to monitor that and this newsgroup as best we can on top of handling the incoming support issues. :-) > 1) SDK defaults to dynamic memory. A few of the libraries are written in > such a way that they require dynamic memory, when the projects are switched > to Flash projects they no longer work because the linker files are not > properly setup or some other such business. Motowerks claims that this was > done to make prototyping easier (quicker) but. I can't remember any product > that I created that didn't have the firmware installed in some kind of > non-volatile memory and I have had to hunt down what is causing my link to > fail when I chosen to use a library that refuses to go easily into flash. > My question, doesn't't make more since to make it work in flash from the get > go, and will you please fix it so others don't have to spend extra time to > use the code how they will need to use it? COMMENTS: I disagree with your assertion that it is easier to work from flash from the get go. Since the DSP56800 supports the Development Mode which uses all external memory it's great for debugging code purposes (if you have this available on your target .... all of the EVM's except the DSP56F801 can support it) as you are always in RAM and have the highest debugging capabilities (unlimited software breakpoints). You can then spend the time to examine the space usage before switching over to the Flash Target where you are more restricted on your debugging capabilities. I can't really address the SDK dynamic memory complaint. > 2) Every time I add files to my project the CW IDE tells me that one or more > files could not be added to my project, yet they ALL successfully add... > Huh? I consider this a minor bug but extremely annoying and equally easy to > fix. I suppose it's my fault if it does not get fixed for not reporting it. The source of this error is due to the fact that one of the targets that the file is being added into has no linker selected in the Target Settings Panel (selecting a linker in the Target Settings Panel creates most of the product specific target settings). However, there are 2 common reasons customers encounter this error. They are listed below: 1) The most common reason this error occurs is when products (like DSP56800, DSP56800E) include "Build All" targets within their included stationery. When customers go to add a file to their stationery project, typically the "Build All" target will be selected by default as one of the targets to add the file to. Since the "Build All" targets typically have no linker associated with the target (since it is simply a target comprised of subtargets), customers will usually see this error when adding a file. It is just basically letting the customer know that it could not add the file to the "Build All" target given the reasons above. The customer could get around this error in the future by being sure to uncheck the "Build All" target when adding files to their project. 2) This error can also occur when a customer has started by using the "Empty Project" stationery and has not selected a linker for the project. > 3) Disassembled C riddle with NOP's. I know that the N register needs a nop > on Rev A silicone of the 827, but I don't think the R0 register does??? > > ioctl(FileDesc, GPIO_TOGGLE, gpioPin(B,0)); > > becomes: > movie #4033, R0 > nop > move X:(R0), X0 > bfchg #0x1, X0 > move X0, X:(R0) On the contrary, there is a pipeline dependency here and the NOP must be present, see below: In Example 4-10 there is a pipeline dependency since the address pointer register written in the first instruction is used in an address calculation in the second instruction. For the case where a dependency is caused by a write to one of these registers, this sequence is not allowed and is flagged by the assembler. This sequence may be fixed by rearranging the instructions or inserting a NOP between the two instructions. Example 4-10. Dependency with a Write to an Address Pointer Register MOVE #$7,R2 ; Write to the R2 register MOVE X:(R2)+,X0 ; R2 register used in address ; arithmetic calculation Regards, John --- In motoroladsp@y..., "Jacob" <jacob@p...> wrote: > > Ron, > > Art and others may be wrong about "what the product should be" but they are > the customers are they not? I hope that if there is something that I don't > like about the product that I will be appeased rather than just being told > that it's my opinion of how the product should work. Maybe it would be nice > if features they are requesting could be options in later revisions. The > Art's const problem seems reasonable to me. It also seems to me that for > the amount of free support that Art offers to the Metrorola community that > he would be the last person to you would want to alienate by saying that the > feature he thinks should be in the compiler is just his opinion. Yes, you > are right, it is just his opinion and I'm sure he expresses his opinion with > the dollars he spends as well. > > "It also helps if people report bugs so we can gather a common factor > or judge how much of a priority to put on any one bug so it is fixed." > > Please don't judge the seriousness of a bug by lack of reporting. I really > appreciated the request for critical bug reports, but I didn't submit > anything because I felt that what others were complaining about seemed "more > important" than my problems. From now on I'm just going to report all bugs > so that they can be added and attacked by Motowerks. > > In general I can say that I have been very happy with CodeWarrior and my > development has gone pretty smoothly. I have no plans to change tools sets > or processors, because of the great support I have received from Motorola, > Metrowerks and this message board. In fact I am certain that my next project > will use either the 56000 or 56000E if the support level remains the same. > My biggest problem to date had to do with bad silicon of which Motorola was > very quick to replace. I am very grateful to know of some of the gotchas > that Art and others found, a couple of which I think are very hazardous > problems that MUST be fixed. These problems have not YET affected me but I > know they one day will if they are not fixed. > > Another thing I think we should see more of from Motowerks is the fantastic > support I had from Leonard when he opened a Motorola tech support case from > messages I posted on this board. I know it's not a typical procedure, but I > highly recommend that Metoroloa continue the practice. In fact in my little > company I recommend to my customers that all tech support issues be raised > on the public message boards for the products so that there can be open > discussion and usually faster and better answers from my customers than I > can offer (oh, btw, my message board has un-moderated posts so that > information can flow faster (nudge nudge, wink wink)) > > So here is my list of Metrorola issues, not all are bugs... > > 1) SDK defaults to dynamic memory. A few of the libraries are written in > such a way that they require dynamic memory, when the projects are switched > to Flash projects they no longer work because the linker files are not > properly setup or some other such business. Motowerks claims that this was > done to make prototyping easier (quicker) but. I can't remember any product > that I created that didn't have the firmware installed in some kind of > non-volatile memory and I have had to hunt down what is causing my link to > fail when I chosen to use a library that refuses to go easily into flash. > My question, doesn't't make more since to make it work in flash from the get > go, and will you please fix it so others don't have to spend extra time to > use the code how they will need to use it? > > 2) Every time I add files to my project the CW IDE tells me that one or more > files could not be added to my project, yet they ALL successfully add... > Huh? I consider this a minor bug but extremely annoying and equally easy to > fix. I suppose it's my fault if it does not get fixed for not reporting it. > > 3) Disassembled C riddle with NOP's. I know that the N register needs a nop > on Rev A silicone of the 827, but I don't think the R0 register does??? > > ioctl(FileDesc, GPIO_TOGGLE, gpioPin(B,0)); > > becomes: > movie #4033, R0 > nop > move X:(R0), X0 > bfchg #0x1, X0 > move X0, X:(R0) > > This is not the only code that I have found that generates NOP's, As a > matter of fact I believe there is well over 100 nop's in my code small > program. > > It's been suggested to me that this problem comes about because of how the > SDK implements the bit toggle, (who ever this problem belongs to, I don't > think it's mine). I know that on Motorola's web page that they mention that > the SDK is an $800 value offered "for free", but I'm not so sure, I mite pay > $50 for it, or I would want my money back. I don't care what the C code > looks like, I don't think I should ever see a NOP generated except where > noted above. > > more to follow I'm sure... > > Jacob _____________________________________ /groups.php3

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )