TI TMS320F28335 vs STM32 Cortex M4

[VSV_electron]

When looking into options of getting into some MCU DSP/FPU introduction I've noticed that while ARM based boards are all over the Internet forums and blog entries and the information is abundant for them, when it comes to the TI C2000 series in this case available with the TMS320F28335 onboard these are barely mentioned at all (in fact I haven't found any user's information but only the official TI documentation) and there is an impression they are forgotten and neglected. Why is that?

[bidrohini]

I think it's because TMS320F28335 is less used than STM32 Cortex M4. Naturally, ARM chips are advanced. Those are not as user-friendly as the Arduino. And when it comes to ARM, STM chips are more popular. However, here I found a tutorial series  on TMS320F28335. May be you have already seen it:

[T3sl4co1l]

Accessibility and familiarity.

ARMs generally make poor DSPs, in relative terms -- they're general-purpose CPUs and MCUs -- but even the lowest level options are more than capable for a lot of simple applications like audio mixing and effects, or, Idunno, MP3 decoding?  Not to mention vector controls like FOC, or, Idunno, some SDR maybe, even some light video processing or rendering (obligatory itrunsdoom).

And, that said, you can get ARMs with a ton of extensions, whether in terms of instructions (FMAC, FP, SIMD, etc.), or hardware support (advanced DMA, say?).

I know a lot of TI and other relatively small or proprietary MCUs/ISAs require buying dev tools, haven't looked at that family specifically but needless to say it's a huge differentiator between hobby/amateur use (PCs, ARMs and Arduinos everywhere!) and professional use.  And no one's talking about the latter, because it's all on internal forums, or served by internal support, and concerning confidential projects for companies/clients.  So, confirmation bias too, but that also happens to feed back in marketing terms as ARMs for example are so popular, found in basically anything, has broad support from free tools, that aren't even awful (indeed GCC is supported by many manufacturers).

That last point, kinda just to say -- I mean, there are many reasons why and why not, some good, some bad -- but a basic review of avr-gcc (e.g. Arduino on any AVR platform) output shows it's pretty rough; whereas the optimization for ARM, x86, etc. is quite good (AFAIK).  And this is a minor point, of course -- if you need sheer CPU cycles, you're simply barking up the wrong tree using AVR, anyway.

But, that said, AVR can be used to modest effect, perhaps with a bit of optimization effort (and fortunately AVR asm is rather easy, as ISAs go) -- I made a reverb effects box, mono 12 bit x 25kSps, using an XMEGA.  That's just about rough enough to still be useful; any fewer bits, or a lower sample rate, and it would be probably too unpleasant to use.  16 bit x 44.1kHz stereo would of course be preferred -- that's not going to happen here, but would be easy on ARM.

Not that this is all that relevant, if you're talking TMS320s versus Cortex M4s.

Tim

[bhave]

I use the C2000 series professionally for large motor drives.  This is the sort of application they are intended for and excel at. TI is rolling new versions out pretty regularly and they are certainly not neglected.  As for performance, you have to step up to the Cortex M7 to be in the same ballpark.  Even then, certain operations such as trigonometric calculations are not close.  I would also argue the C2000 analog and PWM peripherals are superior to anything I have used on an M7.

[ace1903]

STM32s are more present on net because investment to start is basically 5$. Blue pill and st-link clone and that is.
I own several dev boards for 28335/377, but cost was something like 300$.
And also one don't need DSP to blink LED or to read some sensor on I2 bus.
If you filter out stuff like that and look for some DSP related things, you will that basically there is no examples for STM too.
If I want to do something, I usually pick some small STM with 48pin max and start designing with Nucleo-32 board.
To do the same with TMS I need first to make PCB for the chip and that is boring since smallest package is 176pins.
Even to solder that package I need hot air station and fiddling couple of hours.
Hope some day someone will make something like blue pill for TMS28F335 too. 

[SiliconWizard]

What exactly is the question? A "specialty" line of processors is of course going to be less "popular" than a very general-purpose series of MCU. News at 11.
Popularity is by no means an indicator of quality or performance. Should be kinda obvious by now.

And if, on top of that, your references are internet forums, random blogs and YT videos, yeah. Very distorted view of reality. By that measure, you'd assume billions of products would be made using 20+-years old ATMEGA MCUs and ARM-Cortex stuff would be almost non-existent, except maybe the STM32F103 (which is itself 15 years old already!) .

And yes, TI processors in general tend to be pretty good, and I think TI have been clever enough not to try and compete in the wrong areas. They tried a very general-purpose Cortex-based MCU with the MSP432, and while it's an OK MCU, I don't think it's been that successful. OTOH, they have a range of MCUs and processors that are less general-purpose and much better at what they do.

[peter-h]

I remember the early DSPs and it looks like most of their original applications have now been eaten by general purpose CPUs like arm32, running at 150MHz+ and being good enough for DSP work in the audio range.

They also suffered from weird software tools, only later getting C compilers for example. So there is generally less programming and hardware design expertise around the place.

BTW the TMS320F28335 is very popular in Iranian drones right now These use solid state gyros (not FOGs AFAIK) and GPS.

On a similar topic, I used to do tons of FPGA and ASIC design work and was really glad to get out of it. Everything was just weird, weird and crap tools, weird quirks to get stuff to work, tools licensed with protection, etc. I know a lot had changed since but in the end if you are trying to produce a solution it is better to use tools which you know and which you can still get back into in a few years' time. So I would always prefer the 32F4xx I am working on now (and maybe work a bit harder to get the required system performance) than to use a better suited CPU (e.g. a DSP).

Of course if you are employed and paid by the hour then weird ways give you better job security - assuming the management is technically inept which mostly they are

[mkissin]

I also use the C2000 micros professionally, and I can say that as digital controllers they're excellent.
The software support used to be very weird and came with a very bad user license agreement (so much so that originally, I was forbidden by our legal department from using them).
Now however it's excellent (Code Composer Studio is just Eclipse, and the C2000Ware code library is very complete), and the chips have excellent data sheets and application notes available.
One thing to be aware of is that the 28335 chips are older generation now, so newer variants (the 28002x, 28003x, and 28004x) are probably better choices for playing with. Also, availability is a disaster zone, but that's not out of the ordinary! The LaunchPad devboards for them are very good and there's a very decent ecosystem of boosterpacks available.

[coppice]

Current ARM parts do a pretty good job of most DSP work. What makes the C2000 special is not its DSP capability, but its ability to do signal processing with extremely low latency in control loops, like in motor control and digital power supplies. Its one of the very best choices for that kind of work.

[JPortici]

Current ARM parts do a pretty good job of most DSP work. What makes the C2000 special is not its DSP capability, but its ability to do signal processing with extremely low latency in control loops, like in motor control and digital power supplies. Its one of the very best choices for that kind of work.

True, anybody doing digital power i talked with, or almost any application note on digital power uses the C2000. Of say 100 cases 96 are C200, 2 are STM32F3/Other simillar arm, 2 are dsPIC

[peter-h]

What kind of interrupt latency is involved (in microseconds)?

The ST HAL ISRs are very inefficient because they step through a load of possible interrupt sources, checking each one and calling a function to service it (if pending) but nobody would do that in real code they wrote for a real job.

[Jester]

I have used the 28335 for a few projects stretching back quite a few years, I quite like it. Years ago I was tasked with commercializing a crazy design that had IIRC 256 PICs spread over 10 boards. I replaced all of them with one 28335 on a small board and improved performance. Cost reduced by 95%. Code composer studio is free.

[Siwastaja]

Current ARM parts do a pretty good job of most DSP work. What makes the C2000 special is not its DSP capability, but its ability to do signal processing with extremely low latency in control loops, like in motor control and digital power supplies. Its one of the very best choices for that kind of work.

Except that this low-latency signal processing is completely unnecessary in motor control or digital power supply. Motor controllers run signal processing at rate of tens of kHz max, and this "signal processing" usually means a few PID controllers. You can do a decent, modern, high-performance motor controller on Cortex-M0 part like STM32F030.

[SiliconWizard]

Current ARM parts do a pretty good job of most DSP work. What makes the C2000 special is not its DSP capability, but its ability to do signal processing with extremely low latency in control loops, like in motor control and digital power supplies. Its one of the very best choices for that kind of work.

Except that this low-latency signal processing is completely unnecessary in motor control or digital power supply. Motor controllers run signal processing at rate of tens of kHz max, and this "signal processing" usually means a few PID controllers. You can do a decent, modern, high-performance motor controller on Cortex-M0 part like STM32F030.

Oh, absolutely. You can even do that with an 8-bit PIC with fixed-point calculations. And with say a RP2040, you can definitely implement a pretty beefy multi-channel motor controller.

For switching power supplies, that is more relevant, where hundreds of kHz to a few MHz is not uncommon, and latency can be critical. For motors, given the mechanical inertia, latency is never that critical as long as it's not ridiculously long.

[Siwastaja]

There may be some experimental or otherwise special switch mode topologies / control schemes where stock peripherals are not useful and CPU needs to nearly or totally bit-bang the control. Although, classically these are done with a CPLD; actually CPLDs can be found in many AC induction motor VFDs because having peripherals capable of motor PWM generation with pulse-by-pulse current limiting and safety features in $1 microcontrollers is a 2010-era thing. In 1990's or early 2000's, there was no other way but to have CPLD the PWM or space vector modulation plus pulse-by-pulse current limiting, and let a separate MCU handle the FOC / speed control loops.

There is certain niche for a highly performant CPUs, but it is much smaller than people tend to assume.

But, if you look at for example the HRTIM peripheral in STM32F334, it is very capable of offloading the CPU, even with special snowflake topologies, because it is so flexible.

Motors, on the other hand, not only have mechanical inertia, but also shitloads of inductance (thanks to that iron core thing). There are special cases of course, like tiny 200 000 krpm ferrite-cored micromotors that require PWM in excess of 100kHz. Which of course is still totally doable with STM32F030.

[T3sl4co1l]

For switching power supplies, that is more relevant, where hundreds of kHz to a few MHz is not uncommon, and latency can be critical. For motors, given the mechanical inertia, latency is never that critical as long as it's not ridiculously long.

I've got an induction heater working up to 50kHz, on an AVR-DA.  Along with ADC and timer overhead, the inner loop (phase detect, comparison, PID) takes about 80% CPU at max frequency (frequency control method, loop runs once per cycle).

I wouldn't be confident in running anything as fully featured, much faster than that.

You could do a peak current mode control at some 100s kHz, but that's mainly because those things have fast comparators and programmable logic onboard.  Average current control wouldn't be as easy, not without errors from ripple aliasing I think.

Indeed, motor controls have been feasible even on old MEGAs, though the slow ADC and comparator makes that a little dicey; you aren't going to have something like peak current fault detection, not without external hardware.

Tim

[SiliconWizard]

Now with motors, if working with brushless DC motors, you may actually need strict timings to get any kind of efficiency, as the switching timings are "critical" (as opposed to just controlling regular DC motors with PWM.) I would personally not be very fond of implementing that in pure software bit-banging IOs, but very low-cost products are not my area. I can understand why a few-cent MCU could be an option in applications where every cent counts. (But then again that wouldn't be a fit for those TMS320 processors or similar either, so...)

[coppice]

Current ARM parts do a pretty good job of most DSP work. What makes the C2000 special is not its DSP capability, but its ability to do signal processing with extremely low latency in control loops, like in motor control and digital power supplies. Its one of the very best choices for that kind of work.

Except that this low-latency signal processing is completely unnecessary in motor control or digital power supply. Motor controllers run signal processing at rate of tens of kHz max, and this "signal processing" usually means a few PID controllers. You can do a decent, modern, high-performance motor controller on Cortex-M0 part like STM32F030.

It depends what class of power supply you are building. If you are switching at hundreds of killohertz, and expect an impulse response at the output consistent with that kind of switching rate, you need per sample processing. That requires the control loop to update every cycle. So you need an ADC running at the switching rate, without internal filtering causing big delays (e.g. sigma-delta is useless), able to get its results directly into the control loop, along with any protection sensing, and have a result going out to the switcher timing well before the next ADC sample is taken. If you want tight control you can't do much more than simple PID control. The latency in the filters themselves becomes too large for crisp control. That's what high end switcher customers expect, for decent impulse response, and its what high end switchers do. Things like the SMPS oriented C2000 devices have been crafted, by closely working with key customers, to have all its peripherals and its core optimised for that kind of low latency operation.

[SiliconWizard]

I tend to prefer small FPGAs for this, and coupling them with a small MCU for interface and higher-level tasks such as UI/communication.
I have limited trust in full software implementations for controlling hardware at such a low-level, and using the above approach allows you not to be tied to any specific vendor/series. Porting the design to a different FPGA is usually very straightforward.

[T3sl4co1l]

Now with motors, if working with brushless DC motors, you may actually need strict timings to get any kind of efficiency, as the switching timings are "critical" (as opposed to just controlling regular DC motors with PWM.) I would personally not be very fond of implementing that in pure software bit-banging IOs, but very low-cost products are not my area. I can understand why a few-cent MCU could be an option in applications where every cent counts. (But then again that wouldn't be a fit for those TMS320 processors or similar either, so...)

Do they not run those with PWM, anyway?  For best efficiency, I mean?  Or is the open-circuit phase enough degree of freedom for that not to be a problem?  (...Or do they shape the poles so a square wave drive is kind of close..?!)

Tim

[Siwastaja]

Now with motors, if working with brushless DC motors, you may actually need strict timings to get any kind of efficiency, as the switching timings are "critical" (as opposed to just controlling regular DC motors with PWM.)

I have done BLCD controllers and have absolutely no idea what strict timings you are talking about. Commutation is in milliseconds or hundreds of microseconds. Efficiency is just perfect as long as electrical angle is estimated within a few degrees, and fundamental frequency rarely exceeds say 500Hz. Inductance of windings prevent any fast change in current anyway.

Unless, of course, it is said 200krpm micromotor, but it's still microsecond range, even that is doable on lowest tier Cortex-M0.

[Siwastaja]

It depends what class of power supply you are building. If you are switching at hundreds of killohertz, and expect an impulse response at the output consistent with that kind of switching rate, you need per sample processing. That requires the control loop to update every cycle. So you need an ADC running at the switching rate, without internal filtering causing big delays (e.g. sigma-delta is useless), able to get its results directly into the control loop, along with any protection sensing, and have a result going out to the switcher timing well before the next ADC sample is taken. If you want tight control you can't do much more than simple PID control. The latency in the filters themselves becomes too large for crisp control. That's what high end switcher customers expect, for decent impulse response, and its what high end switchers do. Things like the SMPS oriented C2000 devices have been crafted, by closely working with key customers, to have all its peripherals and its core optimised for that kind of low latency operation.

But everything you described: ADC at >1MHz switching rate, protection sensing (sub-microsecond comparator inputs directly into PWM generation break signal), and so on, is available in any STM32 MCU, has been for at least 15 years. $0.50 MCU now does this up to about ~1MHz PWM and $2 MCU up to about ~2.5MHz.

And this is exactly what happens: it's 1990's, and you have an exceptional product which can do X, so it's the greatest thing since sliced bread. But time goes on, it's now 2005 and everybody starts to include the same features in lower-end products. And finally comes 2010's, and we are at the point all of this is completely standard feature set.

Then greybeards continue talking about the dinosaur product series, and the younger generation have hard time understanding what's the big deal.

And because both the great old DSP from 1990's, and the modern-day $0.50 part provide exactly the same end result, the discussion diverges into some weird, totally unimportant (in 99% of cases) detail, like saving two clock cycles of loop overhead.

[coppice]

It depends what class of power supply you are building. If you are switching at hundreds of killohertz, and expect an impulse response at the output consistent with that kind of switching rate, you need per sample processing. That requires the control loop to update every cycle. So you need an ADC running at the switching rate, without internal filtering causing big delays (e.g. sigma-delta is useless), able to get its results directly into the control loop, along with any protection sensing, and have a result going out to the switcher timing well before the next ADC sample is taken. If you want tight control you can't do much more than simple PID control. The latency in the filters themselves becomes too large for crisp control. That's what high end switcher customers expect, for decent impulse response, and its what high end switchers do. Things like the SMPS oriented C2000 devices have been crafted, by closely working with key customers, to have all its peripherals and its core optimised for that kind of low latency operation.

But everything you described: ADC at >1MHz switching rate, protection sensing (sub-microsecond comparator inputs directly into PWM generation break signal), and so on, is available in any STM32 MCU, has been for at least 15 years. $0.50 MCU now does this up to about ~1MHz PWM and $2 MCU up to about ~2.5MHz.

And this is exactly what happens: it's 1990's, and you have an exceptional product which can do X, so it's the greatest thing since sliced bread. But time goes on, it's now 2005 and everybody starts to include the same features in lower-end products. And finally comes 2010's, and we are at the point all of this is completely standard feature set.

Then greybeards continue talking about the dinosaur product series, and the younger generation have hard time understanding what's the big deal.

And because both the great old DSP from 1990's, and the modern-day $0.50 part provide exactly the same end result, the discussion diverges into some weird, totally unimportant (in 99% of cases) detail, like saving two clock cycles of loop overhead.

A lot of C2000 customers started with the STM32 before they switched. Perhaps they've noticed some limitations you haven't. If a 50 cent chip does what you need, use it.

[Siwastaja]

Sounds like marketing speech, not technical discussion. It's quite revealing you had nothing to say to the technical arguments.

Thread title says "TI TMS320F28335 vs STM32 Cortex M4". You listed bunch of features supposedly possible on C2000, but (implicated) not on STM32 Cortex M4. But in reality, I think every single STM32 M4 part in existence is capable of everything you listed. If not, please elaborate, instead of bullshitting something about some customers noticing something I didn't.

Per sample processing not possible on a few hundreds kHz SMPS on Cortex-M4? Are you freaking serious? And all you have to say back is "you did not notice something". This is not engineering, this is the definition of cargo cult science. Magical things only C2000 users know, which can't be elaborated on.

In reality, competition works wonders and if something used to be the only solution to a problem in past, now there are many different ways to achieve the same. But marketing of course will only sell their own product like a 2MSPS ADC is something miraculous no one else has.

And yes, I will continue selling my expertise, please go on and sell yours. I will not use XMOS or C2000 or some other "the only magic sauce" to achieve the same you do.

[T3sl4co1l]

FYI, probably a technical comparison is not possible in this venue due to NDAs/licensing.  That is, you'd have to dive deep and show what all functions are being performed.  Which might not even be contractually possible, let alone worth bringing to a mere forum conversation.

I certainly haven't had to do a project complicated enough to need more than so-and-so CPU, but I certainly don't discount the need for more.  Or even just different, even if the price options seem irrational.  Rarely is an MCU the dominant cost in an overall project.

Tim