On 08/05/2013 10:17 AM, Robert Schwebel wrote:
On Mon, Aug 05, 2013 at 09:25:18AM +0200, Michael Schnell wrote:
You can't. And you can't, even if you try to run bare-metal software
on a dedicated core. I can't imagine how for example the cache
influences between the cores could be determined.
This would render all efforts for hard realtime embedded Linux
applications useless. You always need to calculate the max latency.
You can't calculate the max latency with today's complex processor
hardware any more. It's all a matter of system failure probabilities.
So don't use them for realtime embedded applications ?
There are companies such as SysGo that seem to claim this possibility
with their PikeOS (see
http://www.sysgo.com/products/pikeos-rtos-and-virtualization-concept/rtos-technology/
). AFAIK, they don't even are able to use dedicated cores (yet). Of
course they don't support "virtual peripheral" technology here, but
strict determinism is a strung requirement with the critical "security"
applications they have in mind.
Nevertheless, there always have been settings where you could get rid
of all realtime complexity by spending a 1-Euro microcontroller to the
BOM.
For "virtual peripherals" applications you will need either a fast CPU
or an FPGA.
AM335x has PRU subprocessors (not ARM architecture).
The 4788 page "AM335x Applications Processor Technical Reference Manual"
(SPRUH73 – October 2011) on page 226 depicts the "ARM Cortex M3 Memory
Map".
What kind of application is that?
At first we are discussion DMX I/O (there already is a running project
doing this with the 335x PRUS (on a BeagleBone board).
But this is only sample "virtual peripheral" project with rather low
demand that easily could be done with "a 1-Euro microcontroller". (and
in fact we already did this using a PIC33).
But in future we are planning for several kinds of propriety digital
waveforms that are to be generated or analyzed.
-Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
