Sign in

Not a member? | Forgot your Password?

Search motoroladsp

Search tips

Find us on Facebook!





Subscribe to motoroladsp

Search tips

Free PDF Downloads

A Quadrature Signals Tutorial: Complex, But Not Complicated

Understanding the 'Phasing Method' of Single Sideband Demodulation

Complex Digital Signal Processing in Telecommunications

Introduction to Sound Processing

C++ Tutorial

Introduction of C Programming for DSP Applications

Fixed-Point Arithmetic: An Introduction

Cascaded Integrator-Comb (CIC) Filter Introduction

Discussion Groups

FFT Spectral Analysis Software

See Also

Embedded SystemsFPGA

Discussion Groups | Freescale DSPs | Help about motorola DSP choice (2)

Technical discussions about Freescale (Motorola) DSPs (including the DSP56000, DSP56300, DSP56600, 56800 DSPs).

  

Post a new Thread



Is this thread worth a thumbs up?

0

Help about motorola DSP choice (2) - and_mnt - Feb 4 15:13:00 2004

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 .







RE: Help about motorola DSP choice (2) - Hutchings William-p23437 - Feb 4 17:07:00 2004

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 .


_____________________________________
/groups.php3

Yahoo! Groups Links
  • To








Re: Help about motorola DSP choice (2) - Robert Wood - Feb 4 18:44:00 2004

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








RE: Help about motorola DSP choice (2) - Hutchings William-p23437 - Feb 4 19:43:00 2004

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


_____________________________________
/groups.php3

Yahoo! Groups Links
  • To







Re: Help about motorola DSP choice (2) - Robert Wood - Feb 4 22:26:00 2004

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







RE: Help about motorola DSP choice (2) - Hutchings William-p23437 - Feb 4 23:49:00 2004

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.







Re: Help about motorola DSP choice (2) - Charlie W - Feb 9 16:40:00 2004

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
__________________________________








Re: Help about motorola DSP choice (2) - Robert Wood - Feb 11 0:06:00 2004

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






Codewarrior 6 - Steals the parallel port? - Robert Wood - Feb 14 12:09:00 2004

Hi Folks,

Anyone had a go with V6 of Codewarrior? I installed the 8k free version on my
computer and it's completely screwed up my IAR parallel port dongle for the
MSP430!

You can see now that when the PC boots up it runs this program that does a
parallel port negotiation which I suspect is taking all of the parallel port
resources and not allowing any other program access to the parallel port.

I know it's not a problem with the dongle as I've tried it on a different
computer which recognises it [the dongle] no problem.

Has anyone else had any issues with V6 Codewarrior and the parallel port, and
if so, what did you do to solve it?

Many thanks,

Rob.