Uses for the Cortex-M4 cores on the OMAP5?


fahrstuhl

fahrstuhl

Member
Joined
May 29, 2008
Messages
371
Age
33
Location
Germany
Hi,

What are realistic use-cases for the two Cortex-M4 cores on the OMAP5?

I've read they're meant for offloading tasks like handling SMS, phone calls, audio and video en-/decoding but what's the DSP for, then? And if the modem is attached to a serial interface, is there anything to offload for SMS or phone calls?

There is (uC)Linux for M4 CPUs and uClibc aims to be glibc source compatible, so could you run a Linux distro on the cores?

You would probably need to reserve some RAM for it, could that be done live?
 
The M4's are probably indended for real-time stuff.

A theoretically practical, but non-trivial to implement usage, would be a midi driver, to bring down latency. The M4's aren't powerful by any stretch of the imagination. They're there to dedicate for stuff that you'd normally consider an RTOS for.
 
I don't think anyone knows what clock speed they run at, so it's impossible to say what they can be good at. But I doubt they run more than 500MHz or so.

You might be able to run uClinux on them but why would you want to? That would probably make dispatching work to them harder, not easier.. and you wouldn't want to have drivers conflicting over what the main Linux running on the A15s controls.
 
How about having one of the smaller cores run an 'always on' installation of Cyanogenmod Android to handle phone calls, gmail and other non-intensive 'always on' apps?  Then a switching system to go between that OS and the primary device's Debian desktop?
 
Grench said:
How about having one of the smaller cores run an 'always on' installation of Cyanogenmod Android to handle phone calls, gmail and other non-intensive 'always on' apps?  Then a switching system to go between that OS and the primary device's Debian desktop?
Click to expand...
Android isn't uClinux and I'm sure you'd have all sorts of problems past the kernel too.

That doesn't address the other thing I talked about. You can't have two OSes running on different processors that are both trying to control the same hardware. Even if you dedicated the modem entirely to the M4s you'd still have the problem of sharing the screen and I/O.
 
Exophase said:
Grench said:
How about having one of the smaller cores run an 'always on' installation of Cyanogenmod Android to handle phone calls, gmail and other non-intensive 'always on' apps? Then a switching system to go between that OS and the primary device's Debian desktop?
Click to expand...
Android isn't uClinux and I'm sure you'd have all sorts of problems past the kernel too.

That doesn't address the other thing I talked about. You can't have two OSes running on different processors that are both trying to control the same hardware. Even if you dedicated the modem entirely to the M4s you'd still have the problem of sharing the screen and I/O.
Click to expand...
Could the android or uClinux not have access to screen and I/O at all but instead pass through notifications/calls to the cores running Debian? Or would that negate the benefit of offloading processes to those cores in the first place?
 
Yoyobuae said:
Might as well use kvm for that.
Click to expand...
I've read about a huge load of problems using KVM or something similar on ARM. If I remember right it's, for one, vendor-specific (of the SoC) and not even possible on every SoC.I'm sure Exophase or someone else could explain that in more detail (or proof me wrong, but I don't think so, not entirely).
 
Yoyobuae said:
comradekingu said:
Would be nice to use the pyra as a usb soundcard. A special bootup could be made so that it only does that, and not the OS as well.
Click to expand...
http://blackfin.uclinux.org/doku.php?id=linux-kernel:usb-gadget:audio

Not sure if the audio usb gadget would be available on Debian though. Maybe it could be compiled into kernel/as a module if it is not?
Click to expand...

What comes with debian is kind of irrelevant here.  I've no doubt we'll be using a Pyra specific kernel build, just as we're using a Pandora specific kernel build now.   We're also going to need some of the gadget drivers installed for core functionality of the device. (eg USB3 OTG)

That being said:

- I've never got a satisfactory result when trying the audio gadget driver on the pandora - the audio tends to be peppered with popping/clicking sounds which i have never found a solution for.

- I don't see how this relates to the topic of the thread.
 
I have used TI Cortex-M4 microcontrollers (from the Stellaris/Tiva series) and even though they are clocked only at 80 MHz, they are pretty powerful for signal processing tasks. I wrote (more than a year ago) some entries on my blog about using these cores with the GNU toolchain and CMSIS DSPLib library. In case you are interested, find them here.

I suppose they can be used for the same kind of tasks one would load to the DSP, plus others like I/O handling (e.g. keyboard, LEDs by using PWM, nubs, etc.), debug functions...
 
a nice project would be to offload Yamaha OPL synth to the M4 (speed up DosBOX).
 
Letalis Sonus said:
200MHz is pretty much the highest clock I have seen in the wild on an M4, and that's actually what TI claims on the product page of the 5432.
Click to expand...
Oh wow, I looked at that page a million times but never saw that was hidden in the "read more" option. Thanks, that clarifies a lot.

I haven't seen M4s over 200MHz in the wild either, but a chip like OMAP5 could probably achieve higher clocks if it wanted to, because it's made on a much better manufacturing process than microcontrollers are made on, and it's not running code directly off of NOR flash. But their memory is backed by a cache and an MMU, which is not part of the M4 pipeline. Fitting this inside zero wait state memory accesses would limit their clock speed a lot, so I guess I'm not really surprised to see 200MHz.

200MHz Cortex-M4 with 32KB shared cache is worth maybe 1/20th or even 1/30th the power of one of the Cortex-A15 CPU cores at full clock speed. That's pretty much worthless for offloading any kind of compute work. It might still be good for some embedded tasks like bit-banging a GPIO communication interface.
 
The only worthwhile task I can see for the M4s is monitoring the 3G module. Assuming the A15s can be shut off and leave the M4s running, that could result in reasonable idle time while still being connected and waiting for a message. Of course, most users aren't likely to get the 3G and of those that do most again will probably use it sporadically for data only, so it's a niche of a niche of a niche usage.
 
  • Like
Reactions: olf
WizardStan said:
The only worthwhile task I can see for the M4s is monitoring the 3G module. Assuming the A15s can be shut off and leave the M4s running, that could result in reasonable idle time while still being connected and waiting for a message. Of course, most users aren't likely to get the 3G and of those that do most again will probably use it sporadically for data only, so it's a niche of a niche of a niche usage.
Click to expand...
Most likely the 3G module can already do that (signaling an interrupt to wake up a CPU) without needing a CPU to poll it.
 
You must log in or register to reply here.

Similar threads

O
[Roadmap] Using the Cortex M4 CPUs
2
Replies
39
Views
14K
WizardStan
WizardStan
ToastBucket
ARM M4 usage
2
Replies
30
Views
20K
Silent-Hunter
Silent-Hunter
Back
Top