2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

Dear group

I am planning a high efficiency 3-phase inverter, but having problems
selecting the control platform. I am currently stuck between the LPC
ARM7, Freescale, and Texas instruments C2000 DSP series. From my
research, it seems that higher efficiency and better specifications
can be obtained by utilizing the processing power of a DSP-based
control system. Additional processing power, and lower component
count can also be realized by using a controller with multiple (6 in
my case) PWM controllers, supporting programmable dead time. (I have
already dropped Analog Devices off my list, as the do not recommend
using their ADMC controllers for new designs.)

I have found the following (disturbing) information in the Texas
Instruments documentation, comparing C compiler-based implementation
of a 16bit PID loop
TMS320C28x - Code size: 464, Cycles: 154
ARM7TDMI - Code size: 548, Cycles: 343
Freescale 56F800E - Code size: 808, Cycles: 666

Granted that different C-compilers are used, can it be true that the
Freescale DSP is worse at number crunching than an ARM7TDMI core? At
this point I am thinking of dropping Freescale off my list and
concentrating on LPC ARM vs. Texas C2000 DSP. Freescale also seems a
smaller player in the DSP market, compared to Texas Instruments.

>From the numbers quoted above, it seems that I will be paying a lot
more money for a DSP based system, while only doubling the controller
power!

As reference, I have a working GCC based environment and various LPC
demo boards from Olimex. The C-compiler for the Texas Instruments
C2000-DSPs cost about $500/year in registration fees, and the DSP
that I am considering cost just below $10, when bought in quantity.

Specific questions:
1) Have I missed any controllers that might prove competitive for my
application?

2) Can anyone philosophize on the performance information from Texas
Instruments?

3) Can anyone comment on support and tools for the different options?

Best regards,
Lourens van der Merwe

------------------------------------



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

>Specific questions:
>1) Have I missed any controllers that might prove competitive for my
>application?

Did you look at DSPIC? Not used them myself but have heard some comments that they have good
price/performance.

------------------------------------



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

----- Original Message -----
From: "lourensvdm"
To:
Sent: Wednesday, August 06, 2008 11:03 AM
Subject: [lpc2000] Power electronic control
> Dear group
>
> I am planning a high efficiency 3-phase inverter, but having problems
> selecting the control platform. I am currently stuck between the LPC
> ARM7, Freescale, and Texas instruments C2000 DSP series. From my
> research, it seems that higher efficiency and better specifications
> can be obtained by utilizing the processing power of a DSP-based
> control system. Additional processing power, and lower component
> count can also be realized by using a controller with multiple (6 in
> my case) PWM controllers, supporting programmable dead time. (I have
> already dropped Analog Devices off my list, as the do not recommend
> using their ADMC controllers for new designs.)
>
> I have found the following (disturbing) information in the Texas
> Instruments documentation, comparing C compiler-based implementation
> of a 16bit PID loop
> TMS320C28x - Code size: 464, Cycles: 154
> ARM7TDMI - Code size: 548, Cycles: 343
> Freescale 56F800E - Code size: 808, Cycles: 666
>
> Granted that different C-compilers are used, can it be true that the
> Freescale DSP is worse at number crunching than an ARM7TDMI core? At
> this point I am thinking of dropping Freescale off my list and
> concentrating on LPC ARM vs. Texas C2000 DSP. Freescale also seems a
> smaller player in the DSP market, compared to Texas Instruments.
>
> From the numbers quoted above, it seems that I will be paying a lot
> more money for a DSP based system, while only doubling the controller
> power!
>
> As reference, I have a working GCC based environment and various LPC
> demo boards from Olimex. The C-compiler for the Texas Instruments
> C2000-DSPs cost about $500/year in registration fees, and the DSP
> that I am considering cost just below $10, when bought in quantity.
>
> Specific questions:
> 1) Have I missed any controllers that might prove competitive for my
> application?
>
> 2) Can anyone philosophize on the performance information from Texas
> Instruments?
>
> 3) Can anyone comment on support and tools for the different options?

Have a look at the Microchip dsPICs. They have several devices for motor
control applications. The tools are very good, with free versions, and they
provide excellent support.

Leon
--
Leon Heller
Amateur radio call-sign G1HSM
Yaesu FT-817ND and FT-857D transceivers
Suzuki SV1000S motorcycle
l...@btinternet.com
http://www.geocities.com/leon_heller
------------------------------------



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

> > --- In l...@yahoogroups.com, "Lourensvdm"
> > wrote:
> > I am planning a high efficiency 3-phase inverter, but having
> > problems selecting the control platform. I have found the
> > following (disturbing) information in the Texas Instruments
> > documentation, comparing C compiler-based implementation of a
> > 16bit PID loop
> > TMS320C28x - Code size: 464, Cycles: 154
> > ARM7TDMI - Code size: 548, Cycles: 343
> > Freescale 56F800E - Code size: 808, Cycles: 666
> >
> > Granted that different C-compilers are used, can it be true that
> > the Freescale DSP is worse at number crunching than an ARM7TDMI
> > core? At this point I am thinking of dropping Freescale off my
> > list and concentrating on LPC ARM vs. Texas C2000 DSP. Freescale
> > also seems a smaller player in the DSP market, compared to Texas
> > Instruments.
> >
> > From the numbers quoted above, it seems that I will be paying a
> > lot more money for a DSP based system, while only doubling the
> > controller power!
> >
> > Specific questions:
> > 1) Have I missed any controllers that might prove competitive for
> > my application?
> > 2) Can anyone philosophize on the performance information from
> > Texas Instruments?
> > 3) Can anyone comment on support and tools for the different
> > options?

> --- In l...@yahoogroups.com, "Leon" wrote:
> Have a look at the Microchip dsPICs. They have several devices for
> motor control applications. The tools are very good, with free
> versions, and they provide excellent support.

Thanks Leon and Mike. I will have a look at the dsPICs. I have never
been a PIC fan, but I guess dsPIC will be sufficiently different from
their offerings 10 years ago to warrant another look.

In a recent DSP market report that I looked at, Microchip did not
feature at all! I am hesitant to base a new design on a component
that is not established and with good market penetration. Texas
Instruments was the DSP manufacturer with the largest market share
overall, and the largest non-cellular phone market penetration.

I want to be sure that I make the right decision before tackling
details of this design. With limited resources I will only get 1
chance.

I appreciate any further input.

Lourens
------------------------------------



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

you may try RENESAS as well

On 8/6/08, lourensvdm wrote:
>
> Dear group
>
> I am planning a high efficiency 3-phase inverter, but having problems
> selecting the control platform. I am currently stuck between the LPC
> ARM7, Freescale, and Texas instruments C2000 DSP series. From my
> research, it seems that higher efficiency and better specifications
> can be obtained by utilizing the processing power of a DSP-based
> control system. Additional processing power, and lower component
> count can also be realized by using a controller with multiple (6 in
> my case) PWM controllers, supporting programmable dead time. (I have
> already dropped Analog Devices off my list, as the do not recommend
> using their ADMC controllers for new designs.)
>
> I have found the following (disturbing) information in the Texas
> Instruments documentation, comparing C compiler-based implementation
> of a 16bit PID loop
> TMS320C28x - Code size: 464, Cycles: 154
> ARM7TDMI - Code size: 548, Cycles: 343
> Freescale 56F800E - Code size: 808, Cycles: 666
>
> Granted that different C-compilers are used, can it be true that the
> Freescale DSP is worse at number crunching than an ARM7TDMI core? At
> this point I am thinking of dropping Freescale off my list and
> concentrating on LPC ARM vs. Texas C2000 DSP. Freescale also seems a
> smaller player in the DSP market, compared to Texas Instruments.
>
> From the numbers quoted above, it seems that I will be paying a lot
> more money for a DSP based system, while only doubling the controller
> power!
>
> As reference, I have a working GCC based environment and various LPC
> demo boards from Olimex. The C-compiler for the Texas Instruments
> C2000-DSPs cost about $500/year in registration fees, and the DSP
> that I am considering cost just below $10, when bought in quantity.
>
> Specific questions:
> 1) Have I missed any controllers that might prove competitive for my
> application?
>
> 2) Can anyone philosophize on the performance information from Texas
> Instruments?
>
> 3) Can anyone comment on support and tools for the different options?
>
> Best regards,
> Lourens van der Merwe
>
>=20
>

--=20
Doshi Harshal
POTENT EMBEDDED SOLUTIONS
F-27, VRAJWADI COMPLEX,
Nr. UTKARSH SCHOOL,
OLD PADRA ROAD,
VADODARA
GUJARAT =96 390015, INDIA
PH: 09429071421
[Non-text portions of this message have been removed]
------------------------------------



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

Hi all,
just joined the group hoping to get some help.

I have a board with LPC2138 and I would like to use it with Eclipse and
OpenOCD on windows.

I need windows because the board is supported in windows only (short
version).

So far I was able to set an environment and do some debugging with the
program samples. What I would like to do is to use the LPC2138 peripherals,
redirect the printf on the serial ports and so on.

I would like to know how to use newlib, I need some ready made examples on
how to declare and use it. For example, does newlib support the LPC2138
fully?

Board is Xylo-LM (fpga+LPC2138):
http://www.knjn.com/docs/KNJN%20FX2%20FPGA%20boards.pdf

Toolchain is: Eclipse + Yagarto + Msys + MinGW

TIA

Giuseppe Marullo
------------------------------------



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

--- In l...@yahoogroups.com, "Giuseppe Marullo" wrote:
>
> Hi all,
> just joined the group hoping to get some help.
>
> I have a board with LPC2138 and I would like to use it with Eclipse and
> OpenOCD on windows.
>
> I need windows because the board is supported in windows only (short
> version).
>
> So far I was able to set an environment and do some debugging with the
> program samples. What I would like to do is to use the LPC2138
peripherals,
> redirect the printf on the serial ports and so on.
>
> I would like to know how to use newlib, I need some ready made
examples on
> how to declare and use it. For example, does newlib support the LPC2138
> fully?
>
> Board is Xylo-LM (fpga+LPC2138):
> http://www.knjn.com/docs/KNJN%20FX2%20FPGA%20boards.pdf
>
> Toolchain is: Eclipse + Yagarto + Msys + MinGW
>
> TIA
>
> Giuseppe Marullo
>

You should have started a new thread rather than posting to an
existing one.

Look at www.jcwren.com/arm for examples of newlib using the LPCC2148.
This package implements EVERYTHING including FreeRTOS, USB and a FAT
filesystem.

Richard

------------------------------------



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

lourensvdm Wrote
>I have found the following (disturbing) information in the Texas=20
>Instruments documentation, comparing C compiler-based implementation=20
>of a 16bit PID loop
>TMS320C28x - Code size: 464, Cycles: 154
>ARM7TDMI - Code size: 548, Cycles: 343
>Freescale 56F800E - Code size: 808, Cycles: 666

Note that there are two weasel phrases in there. "16bit" and "C compiler".=
=20
The particulars of the implementations can make a big difference. C
compilers don't tend to use MACs very effectively (although DSP compilers
should do pretty well) because C semantics don't really allow for retaining
extra bits in a chain of multiplies (1). It's also possible a 16 bit
implementation will be slower than a 32bit on some chips (I would be
particularly wary of a 16bit benchmark on a 24bit DSP). Finally the ARMs
don't have a built in divide but can do shifting quickly so an
implementation that isn't optimized to do shifting will fare badly on the
ARM.

There's also no mention of the clock rates available.

I'm getting cynical.

Robert

1- I usually end up doing PIDs in assembly in order to retain the extra
bits the C compiler will throw away.

--------------------------------------------------------------------
mail2web.com =96 What can On Demand Business Solutions do for you?
http://link.mail2web.com/Business/SharePoint

------------------------------------



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

> Specific questions:
> 1) Have I missed any controllers that might prove competitive for my
> application?

I don't know about cost but I doubt that the main chip will be driving
the selling price. For performance there is no way to beat an FPGA
implementation. Xilinx Spartan 3 devices have built-in 18 bit
multipliers and have DSP capabilities. But everything is hardware.
No compiler nonsense, no overhead.

Then there are the offerings from Analog Devices like the Blackfin.
Now here is a CPU with SPEED! Clocking at 500 (600) MHz, it just
blows away the low end ARM devices. It also has DSP capability.
Analog Devices has another chip (SHARC) that may be more appropriate.
Both of these devices are FAST and DSP oriented. Blackfin has GNU
support.

But if a low price CPU is the goal, none of these offerings can
compete. It just seems to me that the CPU price is irrelevant.

Nevertheless, Microchip has an app note for using the PIC16F72 to
control single and 3 phase induction motors:
http://ww1.microchip.com/downloads/en/AppNotes/00967A.pdf The 16F72
is about $2 in quantity.

>
> 2) Can anyone philosophize on the performance information from Texas
> Instruments?

Everybody lies! At the very least, they don't make an attempt to
describe WHY there is a difference in performance: toolchain,
optimization level, algorithm vs hardware, etc.

There are so many 3 phase inverter app notes around I'm surprised you
aren't flooded in paper. Pick a platform, any platform, and there
will be a 3 phase inverter. Everybody wants to get into industrial
controls.

Richard

------------------------------------



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

> >--------lourensvdm Wrote--------
> >I have found the following (disturbing) information in the Texas
> >Instruments documentation, comparing C compiler-based
> >implementation of a 16bit PID loop
> >TMS320C28x - Code size: 464, Cycles: 154
> >ARM7TDMI - Code size: 548, Cycles: 343
> >Freescale 56F800E - Code size: 808, Cycles: 666
> ---------Robert Wrote---------
> Note that there are two weasel phrases in there. "16bit" and "C
> compiler". The particulars of the implementations can make a big
> difference. C compilers don't tend to use MACs very effectively
> (although DSP compilers should do pretty well) because C semantics
> don't really allow for retaining extra bits in a chain of
> multiplies (1). It's also possible a 16 bit implementation will be
> slower than a 32bit on some chips (I would be particularly wary of
> a 16bit benchmark on a 24bit DSP). Finally the ARMs don't have a
> built in divide but can do shifting quickly so an implementation
> that isn't optimized to do shifting will fare badly on the ARM.
>
> There's also no mention of the clock rates available.
>
> I'm getting cynical.
>
> Robert
>
> 1- I usually end up doing PIDs in assembly in order to retain the
> extra bits the C compiler will throw away.

Thanks for the reply Robert. While I understand that benchmarking
can be misleading, I do not have the necessary experience with either
ARM assembly or DSP programming to do the comparison myself.

What I do know is that the trend in inverter, UPS and variable speed
motor drive design is towards DSP implementation. This is the reason
I find it particularly interesting that a DSP manufacturer (Texas
Instruments) would publish performance data suggesting that the
improvement in DSP PID implementation is only 2.2 times better than
ARM7TDMI (assuming similar clock speed of the lower DSP devices).
Before I read this I was quite ready to order a DSP demo board. Now
I don't know. An arm controller with suitable PWM implementation
might be a viable alternative.

My biggest concern is that 6 months into the development I find that
the ARM is not up to the number crunching required for an extra high
efficiency implementation.
------------------------------------



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

> > -------Lourensvdm wrote--------
> > 1) Have I missed any controllers that might prove competitive for
> > my application?
> -------rtstofer wrote-----
> I don't know about cost but I doubt that the main chip will be
> driving the selling price. For performance there is no way to beat
> an FPGA implementation. Xilinx Spartan 3 devices have built-in 18
> bit multipliers and have DSP capabilities. But everything is
> hardware. No compiler nonsense, no overhead.
>
> Then there are the offerings from Analog Devices like the Blackfin.
> Now here is a CPU with SPEED! Clocking at 500 (600) MHz, it just
> blows away the low end ARM devices. It also has DSP capability.
> Analog Devices has another chip (SHARC) that may be more
> appropriate. Both of these devices are FAST and DSP oriented.
> Blackfin has GNU support.
>
> But if a low price CPU is the goal, none of these offerings can
> compete. It just seems to me that the CPU price is irrelevant.
>
> Nevertheless, Microchip has an app note for using the PIC16F72 to
> control single and 3 phase induction motors:
> http://ww1.microchip.com/downloads/en/AppNotes/00967A.pdf The 16F72
> is about $2 in quantity.

OK, I should probably have given some additional information. The
system that I am designing is modular. There can be more than 10
modules, each with its own controller. Unfortunately this does not
imply that the number crunching can be split. Synchronization and
power sharing place an even bigger requirement on each module.
Choosing a 'nice' floating point DSP can add 20% to the final product
cost. The product is aimed at the African market (South Africa for a
start) and production cost is of the essence.

FPGA might be an overkill, while the analog devices offerings require
additional components to implement the PWM. I prefer the solutions
that require minimum part count, if only because I have the choice.
I don't believe that the PIC will allow the number crunching required
for harmonic control.

> > --------Lourensvdm Wrote-----
> > 2) Can anyone philosophize on the performance information from
> > Texas Instruments?
> -------rtstofer wrote-----
> Everybody lies! At the very least, they don't make an attempt to
> describe WHY there is a difference in performance: toolchain,
> optimization level, algorithm vs hardware, etc.
>
> There are so many 3 phase inverter app notes around I'm surprised
> you aren't flooded in paper. Pick a platform, any platform, and
> there will be a 3 phase inverter. Everybody wants to get into
> industrial controls.

I started this project 6 months ago (full time) and am only now
getting to the point of choosing a processor. I have read close to
1Gig worth of pdf-s on every related concept, technique, component
and market report. The paper flood (pdf flood) seems to be
contained, if only barely. My problem is that reading does not make
up for experience.

I really appreciate all the input I am receiving. It does help a lot
with making this decision.
------------------------------------



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

> > ------ Lourensvdm Wrote ------
> > I am planning a high efficiency 3-phase inverter, but having
> > problems selecting the control platform. I am currently stuck
> > between the LPC ARM7, Freescale, and Texas instruments C2000 DSP
> > series.

> > Specific questions:
> > 1) Have I missed any controllers that might prove competitive for
> > my application?

> ------Harshal Doshi wrote---------
> you may try RENESAS as well

Thanks, I will have a look at them. Have you used their products
before? How do their documentation, support and compiler compare to
the LPC?
------------------------------------



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

Lourensvdm said: Wednesday, August 06, 2008 5:03 AM
> Freescale 56F800E - Code size: 808, Cycles: 666

I know the DSP56F8xxx family pretty well. We sell those on
boards as well as the LPC2xxx's. In our testing we've found the
DSP56F8xxx's 80MHz 40MIPs to run neck and neck with the LPC2xxx
60MHz (what is it they claim?) 52 MIPs. The LPC2xxx's have clear
advantages in 32 operations and address space. The DSP56F8xxx's
show well in 16-bit operations in general, but have killer-good
hardware for motion control.

But due to Freescale making their software side a profit center,
their CodeWarrior C development suite and reluctance to support
3rd party with real instruction set details, their development
environment has suffered from lack of competition. (We support
them with a Forth in IsoMax(TM) language). Consequently, I am
always suspicious of Code Warrior. Around here we say Code
Warrior was appropriately named, because if you try to use it,
you're in for a heck of a fight.

The example I use is we finally found a bug that came from one
of their deeply embedded libraries, where they used fixed
locations in code that was supposely professional and made for
real time preemption. They even went to the trouble to take
things out of a safe stack from to reuse a fixed location.
Consequently, you'd get flaky interrupt routines that would
crash under bizzare combinations. I'm sorry, but that is the
work of hacks, and not real time professionals.

Then when we switched from a previous version to their new
release, we had the size of our code expand, so we couldn't be
compatible with the same addresses we'd already published.

So there have been several events which I would find
disqualifying of a software vendor, but you don't have a
possible plan B and still programming in C. (I haven't looked in
quite a few years now to see if this situation has changed.)

Now on the flip side, the hardware of the DSP56F8xxx's are
utterly outstanding for motion control. The PWM is very
automatic, has complimentary outputs, lets you insert deadbands.
There are 6-PWM in a group so you can directly drive the level
shifters to the three phase high and low transistors with no
other hardware. The PWM hardware is set and forget, until you
want to change values. Very sweet. Also the timer set is among
the best I've ever seen, with modes including quadrature input.
So given the two hardware quadratures and the timers, you can
read up to 7 channels of quadrature in hardware. This is 32-bit,
again, set-and-forget, read it when you need it.

We figured we could run about a dozen PID loops (some
quadrature, some analog) at 2K update rates and have plenty of
processor left over.

I don't have much experience with the TMS320, but I do have some
with the LPC2xxx, So for me, the Freescale is unquestionably the
best for what I hear you asking about, and I don't believe for a
moment their numbers on code size or cycles.

On the other hand I wanted to data log over a few K of RAM as
well as do the control, then I'd look to something with a bigger
address space, so I'd be looking to ARM then. I suspect TI is
pretty potent, but just can't comment there.

Randy

------------------------------------



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

Randy M. Dumse wrote:

> But due to Freescale making their software side a profit center,
> their CodeWarrior C development suite and reluctance to support
> 3rd party with real instruction set details, their development
> environment has suffered from lack of competition. (We support
> them with a Forth in IsoMax(TM) language). Consequently, I am
> always suspicious of Code Warrior. Around here we say Code
> Warrior was appropriately named, because if you try to use it,
> you're in for a heck of a fight.

We used to call it Code Worrier, because you could never be
sure where the next code generator bug would pop up and
bite you.

Yeah, it's too bad Mot put all those great little compiler
shops out of business...

Ralph

------------------------------------



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

Ralph, it seems you had the same nightmares with CodeWarrior than me.
Here we used to name it CodeHorror.
Now the Metrowerks guys passed the "hot-potato" to Freescale.
But Freescale guys seem to be more shocked than us. :)
Even though Mot have nice microcontrollers like the Coldfire.
Too bad, because without reliable tools ... no deal.!

-------Original Message-------

From: Ralph Hempel
Date: 8/6/2008 19:10
To: l...@yahoogroups.com
Subject: Re: [lpc2000] Power electronic control

Randy M. Dumse wrote:

> But due to Freescale making their software side a profit center,
> their CodeWarrior C development suite and reluctance to support
> 3rd party with real instruction set details, their development
> environment has suffered from lack of competition. (We support
> them with a Forth in IsoMax(TM) language). Consequently, I am
> always suspicious of Code Warrior. Around here we say Code
> Warrior was appropriately named, because if you try to use it,
> you're in for a heck of a fight.

We used to call it Code Worrier, because you could never be
sure where the next code generator bug would pop up and
bite you.

Yeah, it's too bad Mot put all those great little compiler
shops out of business...

Ralph

[Non-text portions of this message have been removed]
------------------------------------



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

Jorge wrote:

> Even though Mot have nice microcontrollers like the Coldfire.
> Too bad, because without reliable tools ... no deal.!

I've used Mot (I still can't call it FreeScale) devices
since the 6805, 6809, 6811, 6816, 6812, 68302 etc...

Once they killed off the compiler vendors (each of
which had their own quirks as well) they killed
any need to be competitive with tools.

And you've hit it right on the head - no tools, no sale.

Which is why we're talking about this on an ARM newsgroup :-)

Ralph

------------------------------------



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

At 04:34 PM 8/6/2008 +0000, lourensvdm wrote:
> > >--------lourensvdm Wrote--------
> > >I have found the following (disturbing) information in the Texas
> > >Instruments documentation, comparing C compiler-based
> > >implementation of a 16bit PID loop
> > >TMS320C28x - Code size: 464, Cycles: 154
> > >ARM7TDMI - Code size: 548, Cycles: 343
> > >Freescale 56F800E - Code size: 808, Cycles: 666
> > ---------Robert Wrote---------
> > Note that there are two weasel phrases in there. "16bit" and "C
> > compiler". The particulars of the implementations can make a big
> > difference. C compilers don't tend to use MACs very effectively
> > (although DSP compilers should do pretty well) because C semantics
> > don't really allow for retaining extra bits in a chain of
> > multiplies (1). It's also possible a 16 bit implementation will be
> > slower than a 32bit on some chips (I would be particularly wary of
> > a 16bit benchmark on a 24bit DSP). Finally the ARMs don't have a
> > built in divide but can do shifting quickly so an implementation
> > that isn't optimized to do shifting will fare badly on the ARM.
> >
> > There's also no mention of the clock rates available.
> >
> > I'm getting cynical.
> >
> > Robert
> >
> > 1- I usually end up doing PIDs in assembly in order to retain the
> > extra bits the C compiler will throw away.
>
>Thanks for the reply Robert. While I understand that benchmarking
>can be misleading, I do not have the necessary experience with either
>ARM assembly or DSP programming to do the comparison myself.

Lie, damned lies and benchmarks! Quite frankly this looks like a pretty
classic case of a meaningless benchmark.
>What I do know is that the trend in inverter, UPS and variable speed
>motor drive design is towards DSP implementation.

An UPS/Inverter is quite a different beast compares to a
drive/inverter. I'm going to assume you are talking about a drive since I
don't see the point of using a high power DSP for generating a simple AC line.

>This is the reason
>I find it particularly interesting that a DSP manufacturer (Texas
>Instruments) would publish performance data suggesting that the
>improvement in DSP PID implementation is only 2.2 times better than
>ARM7TDMI (assuming similar clock speed of the lower DSP devices).
>Before I read this I was quite ready to order a DSP demo board. Now
>I don't know. An arm controller with suitable PWM implementation
>might be a viable alternative.

I'm not sure PID is actually the best benchmark for a drive
implementation. What are you trying to implement? AC drives run from
simple V/F through flux vector with feedback up to sensorless flux
vector. The last requires some serious work and is rather motor sensitive
from what I can tell. I've only done the simple stuff since projects have
been cancelled before moving to more complex control. What kind of control
are you needing to achieve? Do you need control near zero speed? Or only
over something more narrow like a 2:1 range. Maybe only a softstart or
something close to a single speed? How wide a range of different
motors? Is requiring feedback acceptable?

Robert

http://www.aeolusdevelopment.com/

From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."
------------------------------------



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

exactly....been there done that 68376 and Cosmic compiler.

ARM now
Ralph Hempel wrote:
>
> Jorge wrote:
>
> > Even though Mot have nice microcontrollers like the Coldfire.
> > Too bad, because without reliable tools ... no deal.!
>
> I've used Mot (I still can't call it FreeScale) devices
> since the 6805, 6809, 6811, 6816, 6812, 68302 etc...
>
> Once they killed off the compiler vendors (each of
> which had their own quirks as well) they killed
> any need to be competitive with tools.
>
> And you've hit it right on the head - no tools, no sale.
>
> Which is why we're talking about this on an ARM newsgroup :-)
>
> Ralph
>
>

------------------------------------



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

At 09:23 PM 8/6/2008 -0400, Ralph Hempel wrote:
>Jorge wrote:
>
> > Even though Mot have nice microcontrollers like the Coldfire.
> > Too bad, because without reliable tools ... no deal.!
>
>I've used Mot (I still can't call it FreeScale) devices
>since the 6805, 6809, 6811, 6816, 6812, 68302 etc...
>
>Once they killed off the compiler vendors (each of
>which had their own quirks as well) they killed
>any need to be competitive with tools.
>
>And you've hit it right on the head - no tools, no sale.
>
>Which is why we're talking about this on an ARM newsgroup :-)
I seem to recall some Cassandras predicting this outcome when Motorola
bough the compiler. Too bad they were proven prescient.

Robert

" 'Freedom' has no meaning of itself. There are always restrictions,
be they legal, genetic, or physical. If you don't believe me, try to chew
a radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/
------------------------------------



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

Robert Adsett wrote:

> I seem to recall some Cassandras predicting this outcome when Motorola
> bough the compiler. Too bad they were proven prescient.

English translation:

I told you so.

Ah, to be old enough to remember the good old days....just for
fun, I googled "Motorola buys Metrowerks" and discovered that
they paid 95 MILLION dollars for it in 1999.

I wonder if any of the original dealmakers are still kicking
themselves for that one.

Ralph

------------------------------------



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

>
> Have a look at the Microchip dsPICs. They have several devices for motor
> control applications. The tools are very good, with free versions, and
> they
> provide excellent support.
>
and in most cases, 6 PWM output with programmable dead time too.
Warm Regards,

Mukund Deshmukh,
Beta Computronics Pvt Ltd.
10/1 IT Park, Parsodi,
Nagpur -440022 India.
Web site - http://betacomp.com

Meet us at Booth I102, Taipei PLAS 2008, Sept 18-22 , Taiwan.

------------------------------------



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

> >--------Lourensvdm Wrote--------
> >What I do know is that the trend in inverter, UPS and variable
> >speed motor drive design is towards DSP implementation.
>---------Robert Wrote---------
> An UPS/Inverter is quite a different beast compares to a drive/
> inverter. I'm going to assume you are talking about a drive since
> I don't see the point of using a high power DSP for generating a
> simple AC line.

In general this would be true. There are, however, ways that high
processing power can perform harmonic compensation, allowing reduction
in output filter size. Conversion efficiency can also be improved
(saving battery cost), especially with low inverter loading, by using
adaptive control strategies. This becomes a horribly complicated
tradeoff: Processor cost vs. Battery + Filter costs. The purpose of
this post is to get a handle on processor performance and cost, as
applied to this application.

Lourens
------------------------------------



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

> >--------Lourensvdm Wrote-------
> > Freescale 56F800E - Code size: 808, Cycles: 666
>------Randy Wrote--------
> In our testing we've found the DSP56F8xxx's 80MHz 40MIPs to run
> neck and neck with the LPC2xxx 60MHz (what is it they claim?) 52
> MIPs. The LPC2xxx's have clear advantages in 32 operations and
> address space. The DSP56F8xxx's show well in 16-bit operations in
> general, but have killer-good hardware for motion control.
....
> On the other hand if I wanted to data log over a few K of RAM as
> well as do the control, then I'd look to something with a bigger
> address space, so I'd be looking to ARM then.
...
> For me, the Freescale is unquestionably the best for what I hear
> you asking about, and I don't believe for a moment their numbers on
> code size or cycles.
...
> the hardware of the DSP56F8xxx's are utterly outstanding for motion
> control.
...
> We figured we could run about a dozen PID loops (some quadrature,
> some analog) at 2K update rates and have plenty of processor left
> over.
...
> So there have been several events which I would find disqualifying
> of a software vendor, but you don't have a possible plan B and
> still programming in C. (I haven't looked in quite a few years now
> to see if this situation has changed.)

Thanks Randy, that's great info. While the hardware sounds
excellent, I am inclined to drop Freescale off the shortlist because
of the software, especially since your sentiments were echoed by Ralf
and Jorge. I really don't have the energy to fight a compiler that
is not transparent.

Such a pity that NXP does not have a processor to compete head-on
with the 56F800E.

>------Randy Wrote--------
> I don't have much experience with the TMS320, but I do have some
> with the LPC2xxx ... I suspect TI is pretty potent, but just can't
> comment there.

I must say, I find it worrying that no one seems to comment on these
controllers. Perhaps they are not as widely used as I believed at
first. Then again, this is a LPC forum not DSP :-)

------------------------------------



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

lourensvdm wrote:
>>> --------Lourensvdm Wrote-------
>>> Freescale 56F800E - Code size: 808, Cycles: 666
>> ------Randy Wrote--------
>> In our testing we've found the DSP56F8xxx's 80MHz 40MIPs to run
>> neck and neck with the LPC2xxx 60MHz (what is it they claim?) 52
>> MIPs. The LPC2xxx's have clear advantages in 32 operations and
>> address space. The DSP56F8xxx's show well in 16-bit operations in
>> general, but have killer-good hardware for motion control.
> ....
>> On the other hand if I wanted to data log over a few K of RAM as
>> well as do the control, then I'd look to something with a bigger
>> address space, so I'd be looking to ARM then.
> ...
>> For me, the Freescale is unquestionably the best for what I hear
>> you asking about, and I don't believe for a moment their numbers on
>> code size or cycles.
> ...
>> the hardware of the DSP56F8xxx's are utterly outstanding for motion
>> control.
> ...
>> We figured we could run about a dozen PID loops (some quadrature,
>> some analog) at 2K update rates and have plenty of processor left
>> over.
> ...
>> So there have been several events which I would find disqualifying
>> of a software vendor, but you don't have a possible plan B and
>> still programming in C. (I haven't looked in quite a few years now
>> to see if this situation has changed.)
>
> Thanks Randy, that's great info. While the hardware sounds
> excellent, I am inclined to drop Freescale off the shortlist because
> of the software, especially since your sentiments were echoed by Ralf
> and Jorge. I really don't have the energy to fight a compiler that
> is not transparent.
>
> Such a pity that NXP does not have a processor to compete head-on
> with the 56F800E.
>
>> ------Randy Wrote--------
>> I don't have much experience with the TMS320, but I do have some
>> with the LPC2xxx ... I suspect TI is pretty potent, but just can't
>> comment there.
>
> I must say, I find it worrying that no one seems to comment on these
> controllers. Perhaps they are not as widely used as I believed at
> first. Then again, this is a LPC forum not DSP :-)

I designed around the Analog Devices Shark processor and TI's TMS320. I liked the TI product and compiler much better then the Analog Devices part. The hardware was pretty much the same between each other but the compiler was top notch from TI. No problems. No hidden compiler bugs. It just worked. I like the NXP parts because it is well integrated and space is a problem with most of my current projects.

Just to let you know I recently designed a fixed floating point PID on a LPC2103 running in Thumb mode. I had the clock set for 60MHz and achieved all the calculations in 60us.

regards,
Charles

------------------------------------



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

>>> ------Randy Wrote--------
>>> I don't have much experience with the TMS320, but I do have some
>>> with the LPC2xxx ... I suspect TI is pretty potent, but just can't
>>> comment there.

>> ------lourensvdm Wrote--------
>> I must say, I find it worrying that no one seems to comment on
>> these controllers. Perhaps they are not as widely used as I
>> believed at first. Then again, this is a LPC forum not DSP :-)

> --------Charles Wrote------
> I designed around the Analog Devices Shark processor and TI's
> TMS320. I liked the TI product and compiler much better then the
> Analog Devices part. The hardware was pretty much the same between
> each other but the compiler was top notch from TI. No problems. No
> hidden compiler bugs. It just worked. I like the NXP parts because
> it is well integrated and space is a problem with most of my
> current projects.
>
> Just to let you know I recently designed a fixed floating point PID
> on a LPC2103 running in Thumb mode. I had the clock set for 60MHz
> and achieved all the calculations in 60us.

Thanks Charles, this is also great information. Sounds like the
TMS320 series is a good contender. I guess its time to download the
relevant datasheets and do a detailed comparison:
1) TMS320F28xx
2) LPC (apparently LPC2468 can do 6xPWM with programmable dead time)
3) dsPIC
4) (Renesas)

Thanks again
Lourens
------------------------------------



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

At 08:34 AM 8/7/2008 +0000, lourensvdm wrote:
> > >--------Lourensvdm Wrote--------
> > >What I do know is that the trend in inverter, UPS and variable
> > >speed motor drive design is towards DSP implementation.
> >---------Robert Wrote---------
> > An UPS/Inverter is quite a different beast compares to a drive/
> > inverter. I'm going to assume you are talking about a drive since
> > I don't see the point of using a high power DSP for generating a
> > simple AC line.
>
>In general this would be true. There are, however, ways that high
>processing power can perform harmonic compensation, allowing reduction
>in output filter size.

OK, I see where you are heading. Higher frequency/smaller filter. Just as
power supplies have done. I take it you can't go high enough in frequency
to just use a PWM and avoid having to worry about harmonics.

Sounds like 'fun'. Good luck.

Robert

"A million lines of code costs $20m to $40m ..... a million times
the cost of the flash chips it lives in. .... Yet accounting screams
over each added penny in recurring costs, while chanting the
dual mantras 'software is free,' and 'hey, it's only a software
change.'" Jack Ganssle in "A Million Lines of Code"

Robert Adsett - http://www.aeolusdevelopment.com/

------------------------------------



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

On Thu, Aug 7, 2008 at 4:34 PM, lourensvdm wrote:
>>---------Robert Wrote---------
>> An UPS/Inverter is quite a different beast compares to a drive/
>> inverter. I'm going to assume you are talking about a drive since
>> I don't see the point of using a high power DSP for generating a
>> simple AC line.
>
> In general this would be true. There are, however, ways that high
> processing power can perform harmonic compensation, allowing reduction
> in output filter size. Conversion efficiency can also be improved
> (saving battery cost), especially with low inverter loading, by using
> adaptive control strategies. This becomes a horribly complicated
> tradeoff: Processor cost vs. Battery + Filter costs. The purpose of
> this post is to get a handle on processor performance and cost, as
> applied to this application.
>

As for the performance of using DSP to implement PFC
(power factor correction), APF (active power filter) or
VAR compensator, from what I know, DSPs can not
beat analog as yet. The main advantage of digital power
compared to analog control is actually more about diagnostics
and communications from what I learned last time.

Last time I was studying in one leading power electronics lab.
They have done somes evaluations of ADI DSPs and TI DSPs,
the performance can not yet beat carefully designed analog
circuits.

You may want to look at their commercial offerings here:
http://www.onecyclecontrol.com/OCCv7/Products/Products.html

Xiaofan

------------------------------------



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

> > >---------Robert Wrote---------
> > > I don't see the point of using a high power DSP for generating a
> > > simple AC line.

> > --------Lourens Wrote---------
> > In general this would be true. There are, however, ways that high
> > processing power can perform harmonic compensation, allowing
> > reduction in output filter size. Conversion efficiency can also
> > be improved (saving battery cost), especially with low inverter
> > loading, by using adaptive control strategies.

> -------Xiaofan Wrote--------
> As for the performance of using DSP to implement PFC (power factor
> correction), APF (active power filter) or VAR compensator, from
> what I know, DSPs can not beat analog as yet. The main advantage of
> digital power compared to analog control is actually more about
> diagnostics and communications from what I learned last time.
>
> Last time I was studying in one leading power electronics lab. They
> have done somes evaluations of ADI DSPs and TI DSPs, the
> performance can not yet beat carefully designed analog circuits.
>
> You may want to look at their commercial offerings here:
> http://www.onecyclecontrol.com/OCCv7/Products/Products.html

DSP may not beat analog if you have some knowledge of the load
connected. For a general purpose inverter, with unknown load, a DSP
provides for adaptive control strategies which could be a major
advantage. While 'Brute force' PID control cannot match analog,
there are inventive DSP control strategies to compensate for this.

The biggest advantages of DSP are reconfigurability, low component
count and reliability. I hope to leverage these to lower cost.
------------------------------------



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

> > >---------Robert Wrote---------
> > > I don't see the point of using a high power DSP for generating a
> > > simple AC line.

> >-------Lourensvdm Wrote--------
> > In general this would be true. There are, however, ways that high
> > processing power can perform harmonic compensation, allowing
> > reduction in output filter size.

>--------Robert Wrote---------
> OK, I see where you are heading. Higher frequency/smaller filter.
> Just as power supplies have done. I take it you can't go high
> enough in frequency to just use a PWM and avoid having to worry
> about harmonics.

It's not the switching frequency that I want to raise. I want to
actively control for the output frequency harmonics, caused by non-
linear inverter loads. I need to create numerous harmonic filters in
the control loop, hence the DSP.
------------------------------------



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

[It's not the switching frequency that I want to raise. I want to
actively control for the output frequency harmonics, caused by non-
linear inverter loads. I need to create numerous harmonic filters in
the control loop, hence the DSP.]

That seems very odd to me. You are worried about how linear the output is with a nonlinear load. That's purely a matter of output impedance. Well if you want to use DSP, try looking at the SI8250.

Chris.

[Non-text portions of this message have been removed]
------------------------------------



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

-------Leon Wrote--------
> > Have a look at the Microchip dsPICs. They have several devices
> > for motor control applications. The tools are very good, with free
> > versions, and they provide excellent support.

> -----mukund.deshmukh wrote-----
> and in most cases, 6 PWM output with programmable dead time too.

I will definitely look at dsPIC over the weekend. I have found the
following on Wikipedia regarding DSP Controller market shares:
"In order of market share, the top three DSC vendors are Texas
Instruments, Freescale, and Microchip Technology, according to market
research firm Forward Concepts (2007). These three companies dominate
the DSC market, with other vendors such as Infineon and Renesas taking
a smaller slice of the pie."
After already eliminating number 2 (Freescale) I think I will limit
further investigation to TMS320 and dsPIC, with TMS320 currently in the
lead. I will also eliminate the LPC series, as only the LPC2468 seems
to support programmable dead time, and it is more expensive than the
TMS320. While the LPC has many more features, they are not useful for
this project.

Thanks again for everyone's support, it is much appreciated. I will
keep monitoring this thread, so any additional input is welcome.

------------------------------------



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

--- In l...@yahoogroups.com, wrote:
> > ------Lourensvdm Wrote-----
> > It's not the switching frequency that I want to raise. I want to
> > actively control for the output frequency harmonics, caused by
> > non-linear inverter loads. I need to create numerous harmonic
> > filters in the control loop, hence the DSP.

> ------Chris Wrote------
> That seems very odd to me. You are worried about how linear the
> output is with a nonlinear load. That's purely a matter of output
> impedance. Well if you want to use DSP, try looking at the SI8250.

Thanks for the response. While I agree that it seems odd, it's
true :-) I want to limit the voltage THD under non-linear load
conditions. It is also true that this is a function of output
impedance. The output filter, however, is part of the output
impedance. To account for this, discrete harmonic trap filters can
be employed. Alternatively, virtual trap filters can be programmed
as part of the active control loop.

The development presents a catch 22 situation. I don't know what my
processing requirements are before I have a test-platform to
experiment with. All I have to go on is what other people used to
implement similar concepts: DSP control.

I had a quick look at the SI8250. It seems a bit rigid on the DSP
functionality for some of the more experimental techniques I want to
play with. I will, however, have another look at this component, the
Renesas part and the Infineon offerings, if only for completeness.

Thanks again,
Lourens
------------------------------------



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

How about the LPC29xx Device? It has many PWM and a Motor control block.
http://www.standardics.nxp.com/products/lpc2000/lpc29xx/
--- In l...@yahoogroups.com, "lourensvdm" wrote:
>
> >>> ------Randy Wrote--------
> >>> I don't have much experience with the TMS320, but I do have some
> >>> with the LPC2xxx ... I suspect TI is pretty potent, but just can't
> >>> comment there.
>
> >> ------lourensvdm Wrote--------
> >> I must say, I find it worrying that no one seems to comment on
> >> these controllers. Perhaps they are not as widely used as I
> >> believed at first. Then again, this is a LPC forum not DSP :-)
>
> > --------Charles Wrote------
> > I designed around the Analog Devices Shark processor and TI's
> > TMS320. I liked the TI product and compiler much better then the
> > Analog Devices part. The hardware was pretty much the same between
> > each other but the compiler was top notch from TI. No problems. No
> > hidden compiler bugs. It just worked. I like the NXP parts because
> > it is well integrated and space is a problem with most of my
> > current projects.
> >
> > Just to let you know I recently designed a fixed floating point PID
> > on a LPC2103 running in Thumb mode. I had the clock set for 60MHz
> > and achieved all the calculations in 60us.
>
> Thanks Charles, this is also great information. Sounds like the
> TMS320 series is a good contender. I guess its time to download the
> relevant datasheets and do a detailed comparison:
> 1) TMS320F28xx
> 2) LPC (apparently LPC2468 can do 6xPWM with programmable dead time)
> 3) dsPIC
> 4) (Renesas)
>
> Thanks again
> Lourens
>

------------------------------------



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

At 03:37 PM 8/11/2008 +0000, kendwyer wrote:
>How about the LPC29xx Device? It has many PWM and a Motor control block.
>http://www.standardics.nxp.com/products/lpc2000/lpc29xx/

Of course it also appears not to be shipping yet.

Robert

http://www.aeolusdevelopment.com/

From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."
------------------------------------



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