>> I disagree with your comparison between RISC and CISC. RISC means Reduced Instruction Set Computer. Because Reduced Instruction Set, so some tasks will need more instructions and cycles than CISC. << I wasn't claiming CISC was better than RISC and I certainly wasn't claiming the Mot part is a CISC processor. I'm well aware of what RISC stands for, and I've had this discussion before, but the *spirit* of the whole reduced instruction set was that each instruction cycle is single clock cycle even if that's not what the acronym says! The claims that, with the Mot part, you can have up to 40MIPS for 40MHz bus speed are a little spurious as far as I can see having looked into it; there are hardly any actual single cycle instructions on the Motorola part, but it's not a CISC device either. There are no DJNZ type intructions that you'd normally find on a CISC. I also wasn't saying the Mot *part* couldn't do it, I was just saying that if you new the Infineon architecture I would seriously think twice about learning a new one for something that might well offer little, or any, advantages! I really don't want to get into a RISC v CISC holy war, I grew up doing assembly language on the 8052 family (which I loved) and hated it when I started having to use PICs due to their pathetic excuse for an instruction set! ;-) Sometimes RISC is better, sometimes CISC is. Sometimes DSPs with peripherals are better, sometimes microcontrollers with hardward multiply and divide are better is all I'm saying! Cheers, Rob

Robert, I disagree with your comparison between RISC and CISC. RISC means Reduced Instruction Set Computer. Because Reduced Instruction Set, so some tasks will need more instructions and cycles than CISC. My experience is CISC processor is good for needing intensive computation applications such as motor control. RISC is good for logical based control applications such as automotive engine control. For sure, RISC core consumes less silicon size but also slower ( if run a algorithm benchmarking) than CISC if both designed have the same frequency. I am using DSP56F8322 to control a DC-DC power supply. PWM output frequency is 333Khz. Both current and voltage feedback loops were calculated in every 6.6us. The communication between power supply module to module for current sharing was performed by DSP56F8322 too. So far I do not find any problem. Control performance is very close to analog control but DSP gives a lot flexibilities. Cheers, Charliw W. --- Robert Wood <> wrote: > I'm interested to see that you currently use an > Infineon processor. Is it the > C166 family or the XC166? If it's the C166 why not > migrate to the newer XC > family? If it's the XC166 family I think that would > have enough power to do > what you want. The XC166 can deliver 40MIPs and has > the PEC which seriously > helps if you have a lot of background stuff going > on. > > The Infineon device has CAN, built in debug, > hardware multiply and divide, > loads of functionality and I'm willing to bet is > about as fast as the > Motorola part as it's a true RISC device which the > Motorola isn't. Also the > Infineon has lots of registers whereas the Motorola > has the bottleneck of > just a couple of accumulators. Having looked through > quite a bit of assembly > language that Codewarrior chucks out form the C > compiler it's really brought > home to me how much more I like register based > processors rather than > accumulator based devices! > > Where the Infineon device scores most heavily over > Motorola though, IMHO, is > the software environment. I don't think Codewarrior > is a good environment and > the flash upload speed is very poor indeed. The Keil > tools for the Infineon > device are superb. I would have no hesitation in > recommending Keil tools to > anyone! > > The accuracy of the A/D on the 56F800 isn't much > over eight bits, I'm guessing > they've used the same A/D on the 83xx family, so if > you are looking for a > high accuracy A/D you might have to use an external > one anyway. > > The Infineon device is an MCU with DSP functions and > the Motorola device a DSP > with MCU functions. I suppose which way round you > place the importance of > those functions would decide which route to go down. > Infineon certainly > market the SC16x devices as being suitable for motor > control, maybe if you > need more information you could speak to a > distributor who sells Infineon. > > Good luck! > > Rob > > __________________________________

Robert - The answer on the 56F800 and 56F8300 flash is that it is the same 0.25 flash used in our other 0.25 flash products. It does have a very fast program time. And the reason that the time to upload is slow is because of the method that CodeWarrior has chosen to load the flash. I think the method they use causes a significant amount of JTAG traffic and hence a major portion of the upload time is the JTAG overhead. We have another programming tool called flash_over_jtag that we distribute to customers that uses a much more efficient programming method that lowers the JTAG traffic and is much faster. This tool is meant to be used as a prodcution flash programming tool and is in the SDK and can also be downloaded from the Web. For CodeWarrior v6 we had Metrowerks upgrade the download method of the debugger to use the same method as the flash_over_jtag tool and the upload time of the 56F8300 products is much faster than the 56F800 products. The reason we prioritized the upgrade for the 56F8300 and not the 56F800 products is because many of the 56F8300 devices have much more memory and hence the benefit is much greater. Before CodeWarrior v6 we have had some customers using the flash_over_jtag tool with the larger 56F8300 products to load up the processor when debugging. Basically it can be envoked before the starting the debugger from CodeWarrior. And the debugger is configured to not download when it is envoked. Hence the net upload time is much faster. This same trick can be used on the 56F800, but is probably not worth it for smaller programs. I'll have to check on the plan for upgrading the CodeWarrior upload when using the 56F800. Thanks. - Bill -----Original Message----- From: Robert Wood [mailto:] Sent: Wednesday, February 04, 2004 3:27 PM To: Hutchings William-p23437; Subject: Re: [motoroladsp] Help about motorola DSP choice (2) >> Actually the 56F8300 has 4 accumulators and a larger register set than the 56F800 devices so the Code density is much improved. In addition the ADC has also been improved with a higher performance reference circuit, noise reduction, and current protection on the inputs. << OK, fair enough! :-) >> The Infineon devices DSP performance is not comparable to the 56F8300 due to the lack of the harvard architecture, dual read, zero overhead looping and other signal processing constructs. << Again fair enough, but as I was pointing out, it depends on whether, in this instance, DSP or MCU type performance is the most important factor. I would have though, and I may be wrong. that if there's just the occasional bit of multiplication and division then a DSP's not necessarily the way to go, whereas if you're doing FIRs or something similar then then DSP comes in its own. While I've got the ear of someone from Motorola, why *is* the device so incredibly slow on code upload? I have heard it said by someone that it could be vastly improved by the folks at Metrowerks, but they just can't be arsed. If you compare the code upload with something like the MSP430, it is around about twenty to thirty times slower. As Motorola quite often boast about how quick the write time is for their flash devices (HC08s and HCS12s anyhow, so I assume the DSPs' flash is the same), it certainly would point to it being a problem with Codewarrior and not the devices themselves. Solving this problem would be a massive improvement to the Codewarrior environment, IMHO. I'd be very interested to hear your thoughts on this! Cheers, Rob.

>> Actually the 56F8300 has 4 accumulators and a larger register set than the 56F800 devices so the Code density is much improved. In addition the ADC has also been improved with a higher performance reference circuit, noise reduction, and current protection on the inputs. << OK, fair enough! :-) >> The Infineon devices DSP performance is not comparable to the 56F8300 due to the lack of the harvard architecture, dual read, zero overhead looping and other signal processing constructs. << Again fair enough, but as I was pointing out, it depends on whether, in this instance, DSP or MCU type performance is the most important factor. I would have though, and I may be wrong. that if there's just the occasional bit of multiplication and division then a DSP's not necessarily the way to go, whereas if you're doing FIRs or something similar then then DSP comes in its own. While I've got the ear of someone from Motorola, why *is* the device so incredibly slow on code upload? I have heard it said by someone that it could be vastly improved by the folks at Metrowerks, but they just can't be arsed. If you compare the code upload with something like the MSP430, it is around about twenty to thirty times slower. As Motorola quite often boast about how quick the write time is for their flash devices (HC08s and HCS12s anyhow, so I assume the DSPs' flash is the same), it certainly would point to it being a problem with Codewarrior and not the devices themselves. Solving this problem would be a massive improvement to the Codewarrior environment, IMHO. I'd be very interested to hear your thoughts on this! Cheers, Rob.

Actually the 56F8300 has 4 accumulators and a larger register set than the 56F800 devices so the Code density is much imporved. In addition the ADC has also been improved with a higher performance reference circuit, noise reduction, and current protection on the inputs.

The Infineon devices DSP performance is not comparable to the 56F8300 due to the lack of the harvard arhcitecture, dual read, zero overhead looping and other signal processing contructs.

-----Original Message-----
From: Robert Wood [mailto:r...@apostrophe.co.uk]
Sent: Wednesday, February 04, 2004 11:45 AM
To: m...@yahoogroups.com
Subject: Re: [motoroladsp] Help about motorola DSP choice (2)

I'm interested to see that you currently use an Infineon processor. Is it the C166 family or the XC166? If it's the C166 why not migrate to the newer XC family? If it's the XC166 family I think that would have enough power to do what you want. The XC166 can deliver 40MIPs and has the PEC which seriously helps if you have a lot of background stuff going on. The Infineon device has CAN, built in debug, hardware multiply and divide, loads of functionality and I'm willing to bet is about as fast as the Motorola part as it's a true RISC device which the Motorola isn't. Also the Infineon has lots of registers whereas the Motorola has the bottleneck of just a couple of accumulators. Having looked through quite a bit of assembly language that Codewarrior chucks out form the C compiler it's really brought home to me how much more I like register based processors rather than accumulator based devices! Where the Infineon device scores most heavily over Motorola though, IMHO, is the software environment. I don't think Codewarrior is a good environment and the flash upload speed is very poor indeed. The Keil tools for the Infineon device are superb. I would have no hesitation in recommending Keil tools to anyone! The accuracy of the A/D on the 56F800 isn't much over eight bits, I'm guessing they've used the same A/D on the 83xx family, so if you are looking for a high accuracy A/D you might have to use an external one anyway. The Infineon device is an MCU with DSP functions and the Motorola device a DSP with MCU functions. I suppose which way round you place the importance of those functions would decide which route to go down. Infineon certainly market the SC16x devices as being suitable for motor control, maybe if you need more information you could speak to a distributor who sells Infineon. Good luck! Rob

_____________________________________ 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: m...@yahoogroups.com To Post: m...@yahoogroups.com To Leave: m...@yahoogroups.com Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3Yahoo! Groups LinksTo

I'm interested to see that you currently use an Infineon processor. Is it the C166 family or the XC166? If it's the C166 why not migrate to the newer XC family? If it's the XC166 family I think that would have enough power to do what you want. The XC166 can deliver 40MIPs and has the PEC which seriously helps if you have a lot of background stuff going on. The Infineon device has CAN, built in debug, hardware multiply and divide, loads of functionality and I'm willing to bet is about as fast as the Motorola part as it's a true RISC device which the Motorola isn't. Also the Infineon has lots of registers whereas the Motorola has the bottleneck of just a couple of accumulators. Having looked through quite a bit of assembly language that Codewarrior chucks out form the C compiler it's really brought home to me how much more I like register based processors rather than accumulator based devices! Where the Infineon device scores most heavily over Motorola though, IMHO, is the software environment. I don't think Codewarrior is a good environment and the flash upload speed is very poor indeed. The Keil tools for the Infineon device are superb. I would have no hesitation in recommending Keil tools to anyone! The accuracy of the A/D on the 56F800 isn't much over eight bits, I'm guessing they've used the same A/D on the 83xx family, so if you are looking for a high accuracy A/D you might have to use an external one anyway. The Infineon device is an MCU with DSP functions and the Motorola device a DSP with MCU functions. I suppose which way round you place the importance of those functions would decide which route to go down. Infineon certainly market the SC16x devices as being suitable for motor control, maybe if you need more information you could speak to a distributor who sells Infineon. Good luck! Rob

To point out some of the advanatges of the 56F8300:

- The 56F8300 is a flashed based device while the ADI is RAM based. So the ADI will require an external device of some kind to load up the program.

- The 56F8300 offers flash security while the ADI device does not. Hence you can protect your Software Intellectual property

- The 56F8300 data flash can be used to emulate EEPROM while the ADI device has not non volatile memory storage capability

- The 56F8300 has an internal voltage regulator, POR, and LVI while the ADI doesn't

- The 56F8357 offers much greater internal memory than the ADI 21992

- The 56F8357 offers many more internal peripherals than the ADI. The 56F8300 has two 6 ch PWM units, 16 channels of ADC, two quad decoders, more SCI and SPI and GPIO and timers as opposed to the ADI 21992 that offers only one 6 ch PWM, 8 channels of ADC, one decoder, and far fewer of the other peripherals listed.

- The 56F8300 ADC has a superior ADC range of 0 to 3.3 volts

- The 56F8300 has a superior external memory interface that can operate at full rate (80 MHz) while the ADI EMI is limited to 20 MHz

- The 56F8300 has 5 volt tolerant I/O while the ADI device does not

- In addition the 56F8300 portfolio is larger and more diverse than the ADI products. If the ADI 21992 device was sufficient for your project then you can most likely choose a smaller device than the 56F8357.

- The 56F8300 is a Hybrid core so it will much more easily and efficiently handle the Microcontroller code.

- 56F8300 Flexcan module that has been used for many years on many different part families as opposed to ADIs new CAN module. We also support CAN on all the 56F8300 devices

- More full functioned peripherals

As far as the software tools go the 56F8300 core and compiler provide better code efficiency. They also offer a rapid development enviroment called processor expert supporting automatic code generation and a tool called PC MAster for real time debugging. The 56F8300 is supported by CodeWarrior. This tool has been used for several years supporting the previous 56850 series of 56800E based devices.

The 56F8300 should be able to easily handle the processing that your application requires. Thanks.

- Bill

-----Original Message-----
From: and_mnt [mailto:a...@yahoo.it]
Sent: Wednesday, February 04, 2004 8:13 AM
To: m...@yahoogroups.com
Subject: [motoroladsp] Help about motorola DSP choice (2)

I am sorry for my english that is not very good. I try to tell you my incertitude about these DSP. 1) Actually we use an ADMC401 for a brushless motor drive. We interface motor with resolver and sin-cos transducer. But we have on the same board a cpu infineon for the fieldbus CAN interface. Now I have to reduce drastically the board dimentions and I need an effective embedded solution: one only processor with flash, ram and peripheral interfaces. 2) I don't know if the motorola dsp speed (60 MIPS) is enough to complete all the activities in 50us (actual loop timing, 20KHz PWM): - current loop (50us) - speed loop (50us) - position loop (100us) - CAN management Currently we work at 25 MIPS with the ADMC401, but we have some time scheduling problem and the CAN management is delegated to cpu. 3) I have some doubt about the ADC resolution (12 bit) and conversion time (1,2us each pair of channels) beacause for the ADSP21992 we have 14bit and 200ns! The ADSP21992 ADC are much faster. This feature could be useful for the sin-cos signals acquisition. 4) I read the main 56F8357 features and I think this dsp coud be a good choice for our application, but I don't know : - the present condition about the maturity of this DSP (software/hardware bugs) - the documentation level - the problems I can meet with hardware development All these problems are typical when a new design will be started. Thank you .

_____________________________________ 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: m...@yahoogroups.com To Post: m...@yahoogroups.com To Leave: m...@yahoogroups.com Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3Yahoo! Groups LinksTo

I am sorry for my english that is not very good. I try to tell you my incertitude about these DSP. 1) Actually we use an ADMC401 for a brushless motor drive. We interface motor with resolver and sin-cos transducer. But we have on the same board a cpu infineon for the fieldbus CAN interface. Now I have to reduce drastically the board dimentions and I need an effective embedded solution: one only processor with flash, ram and peripheral interfaces. 2) I don't know if the motorola dsp speed (60 MIPS) is enough to complete all the activities in 50us (actual loop timing, 20KHz PWM): - current loop (50us) - speed loop (50us) - position loop (100us) - CAN management Currently we work at 25 MIPS with the ADMC401, but we have some time scheduling problem and the CAN management is delegated to cpu. 3) I have some doubt about the ADC resolution (12 bit) and conversion time (1,2us each pair of channels) beacause for the ADSP21992 we have 14bit and 200ns! The ADSP21992 ADC are much faster. This feature could be useful for the sin-cos signals acquisition. 4) I read the main 56F8357 features and I think this dsp coud be a good choice for our application, but I don't know : - the present condition about the maturity of this DSP (software/hardware bugs) - the documentation level - the problems I can meet with hardware development All these problems are typical when a new design will be started. Thank you .