Post by Rick CPost by David BrownPost by Rick CI was just curious about what people have used for DSP
applications, but in particular if anyone had used one of the
"crossover" parts. So far, the answer has been "no".
I don't know exactly how you are defining a "crossover" part.
Please read the first post in this thread for that.
I did. That's why I said I don't know exactly how you are defining your
personal meaning of "crossover part". But I see you've given more
information below, so maybe people can give you more helpful feedback
(or at least say that they don't have the relevant experience).
Post by Rick CPost by David BrownBut if it is "a DSP with microcontroller features", then the answer
so far is "yes". Both Grant and I have used TMS320F parts - but I
would not choose to use one again if I could avoid it. (I can't
answer for Grant there.) I have also used a "DSP with
microcontroller features" from Freescale (from the MC56000 family,
IIRC) - though I hadn't mentioned that at all.
And if you mean "a microcontroller with DSP features", then as I
said almost everyone who works with embedded software has used
Cortex-M4 devices. I have lost count of the number of different
ones I have used (plus Cortex-M7, ColdFire, and PPC based
microcontrollers that had DSP features).
So I don't quite see how you could have interpreted the posts as "no".
I was looking for some insight into their experiences with such
devices for DSP work, and I'm counting both DSP like MCUs and MCU
like DSPs. I don't see in your post that you talk about any
particular experience, rather offer a 10,000 foot overview of the
state of the market. Thanks for that, but this is not new to me. So
your post was pretty much a "no", to me.
Of course it is an overview. Do you want detailed information about
everything I have done for the past 15 years or so since Cortex-M
devices took over the embedded world?
I can give a bit more insight into my experience with the TI320F24x
device. That was over 20 years ago, and lots will have changed since
then. The device was horrible to use. The assembly was impenetrable,
and extremely complicated to do well. The C compiler was hopelessly
inefficient, meaning you /had/ to use assembly for critical parts. The
hardware debugging tools were absurdly overpriced (some $1500 for what
was basically a couple of 74-series logic chips), and broke easily. The
software tools had annoying quirks. But the sensorless BLDC motor
control worked well in the end.
I would not willingly choose to do development on these parts again -
there are simply too many alternatives that are vastly easier to work
with for most purposes. But I know TI sell various pre-programmed parts
as dedicated motor control peripherals, and I'd be quite happy to
consider them.
As I said, the great majority of embedded microcontroller work is now
done with Cortex-M microcontrollers - they dominate the industry. At
the low end you have Cortex-M0 and M0+ devices for the very cheapest,
but the most popular are M3 or M4 parts (and the M7 at the high end).
The M4 is like an M3 but with added "DSP" instructions - MAC's of
various types, simple SIMD, saturating arithmetic. In reality,
relatively few people actually do anything that could be called "DSP"
work - it's usually more general control code. And when you want a
digital filter or FFT, you typically use ARM's optimised libraries.
Your code runs the same whether the device has DSP optimisation
instructions or not - only the speed is different.
So when you ask about "experience using these devices", you are really
asking "experience doing microcontroller development".
Post by Rick CI guess I was not quite explicit enough in my initial post. I was
asking about specific experiences where a crossover part was chosen
for a project with a significant DSP content, which would have
required a DSP chip, if these devices were not available.
That is a different question, and more specific.
I've only done quite limited DSP algorithms (such as simple filters) in
my own code, and these devices are absolutely fine for that. As always,
you have to be careful about your scalings when working with fixed-point
numbers.
If you want floating point, some Cortex-M4 have single-precision
floating point (Cortex-M4F). You need to be careful to avoid
accidentally using double precision operations in your C code - there
are gcc flags to help warn you about this. If you want double
precision, it's worth going for an M7 microntroller like an NXP RT10xx
device (ironically called a "crossover microcontroller" by NXP), since
these have double precision floating point in hardware.
I have been involved in a project that was more relevant, using wavelet
transformations, but I did not work directly on the wavelet code. I did
help out on some of the optimising and translation from the original
code (from a PC). Working that way is not optimal, but it was good
enough - we required a certain amount of transformations per second, and
got that from the chip we had on the board, and did not see any point in
going further.
There is no doubt that dedicated DSP cores have instruction types and
features that can make a significant difference to the efficiency of
some algorithms. A good DSP can do "x += *p++ * *q++;" in a single
operation, once per cycle. They generally support cyclic buffers
directly, which can save a fair bit of code. And they have the
specialised bit manipulation instructions useful for FFT's.
However, it is all about getting the results out in the time (and power
and cost budget) you need. And if your code runs fast enough on the
device you have, it really doesn't matter if a different device could do
it faster.
A lot of the choice will, as so often, come down to experience and
familiarity. Getting decent DSP algorithm performance from an M4 is not
too hard if you are already a good embedded programmer. It comes down
to knowing your toolchain, knowing how to write efficient code, and
knowing how to work with vendor's libraries. And since you have good
toolchains, easy and cheap debugging (usually), and peripherals such as
serial ports, USB, and Ethernet, you often have a much nicer development
environment. If you develop appropriately, the same code will also
compile directly on a PC making simulation and testing vastly easier.
On a DSP, getting optimal performance is very difficult - there is a
/lot/ you need to track, and you are often making use of so many
compiler extensions, intrinsics, etc., that you are really programming
in assembly. Getting the same code running on a PC for testing is
hugely harder. Accidentally getting significantly poorer efficiency is
very easy - you might find that writing "while (--n)" gives you
extremely fast specialised loop modes while "while (n--)" gives you
explicit decrements, comparisons and jumps. Toolchains are often poor
quality and very expensive (that is not universal, however). And
non-DSP code is much harder than in a microcontroller - you often don't
have access to 8-bit bytes, and portability between the DSP and other
processors is poor.
We haven't talked much about peripherals or hardware, but DSP's usually
have fewer "general" peripherals, and their interfaces can be more
specialised.
Post by Rick CI am fully aware that MCUs are getting faster and more capable, but
that doesn't mean DSPs are not needed. It simply means they are used
in other applications that require more horsepower. Sometimes, it's
not even the horsepower, but the performance to power consumption
ratio. There are application specific DSPs for hearing aids that run
on very low power, much better than any MCU could do.
Yes, that is correct.
DSP's are still very much an important technology, but they are getting
more niche. There are few people that develop with them - the majority
of companies that have a DSP on their boards will buy the code ready
made, often just as a binary blob or pre-programmed. In many cases, the
code is written by the companies that develop the DSP.
This is not just because getting maximal efficiency from a DSP is
technically hard and requires knowledge and experience (and if you don't
need maximal efficiency, why are you bothering with the DSP in the first
place?). IP and patent licensing is a nightmare in many of the
applications where DSPs really shine, such as in audio and video codecs.
If you are Sony or Sonos, you can afford a big development team and an
even bigger lawyer team and make your own audio codecs. For most
companies, it is a fraction of the overall price if you buy your DSP's
with licenses for codec binary blobs all in one.
Standalone DSP chips are also getting rarer - it is more common to see
them as accelerators alongside a "host" processor that handles the
non-DSP functionality, all within the same die.
Post by Rick CYears ago DSP split into two categories based on the cell phone
market. The high performance devices needed their own power plants,
but cranked out some serious MIPS/MFLOPS. The much smaller, lower
power, fixed point devices gained in speed, without sucking all the
juice from mobile batteries, while serving in hand sets. Now the
hand sets have dedicated CPU chips with built in DSP sections for the
front end processing of cell phones, rather than separate DSP chips.
There's no shortage of DSP cores in the world, we just don't see all
of them because they are part of system chips.
Agreed.
Most (in terms of numerical quantities) are probably generated
specifically for the ASIC or dedicated chip they are used in. There are
parametrized DSP cores available that are often used with 24-bit or
18-bit "bytes" - TMS320's with 16-bit or 32-bit "char" are
programmer-friendly in comparison. And sometimes it is not easy to draw
the line between hardware filters with very programmable state machines,
and limited DSPs.
But a lot is changing. At the high end, processors with SIMD are able
to do many of the tasks that DSP's used to do. Other kinds of
accelerators such as found in graphics card cores can do a better job
than traditional DSPs, while also being easier to work with. At the
lower end, normal microcontrollers, possibly augmented with a few
DSP-friendly instructions, can do a better job. For your hearing aids,
when you have a Cortex-M device that takes less power than the leakage
current of the smallest battery while doing all the filtering fast
enough, the DSP has lost its advantage.