two applications on one single processor

[ssmail]

Posted on July 24, 2014 at 22:18

Does anyone have any experience running two applications on single processor?

I have accomplished running two separate images that can communicate with each other with function pointer (callbacks) on other processors by using dlls, but I can’t find information about doing so on a Cortex processor.

This should allow the applications to be built separately.

[Tesla DeLorean]

Posted on July 24, 2014 at 22:57

You'd need an OS of some kind.

You could probably use something like FreeRTOS, and create two tasks and have those call the individual apps, but you'd still want to create some mechanism to share the peripheral resources, etc.

[ssmail]

Posted on July 25, 2014 at 00:44

I like the idea of the two apps running in separate tasks. This way they can 'time slice'.

I guess you coule have three sections of flash: 1) RTOS Scheduler. Also creates the two application threads. 2) Application 1 3) Application 2 The applications are at (linked to) fixed addresses. These are the entry points to the two applications. Is this feasible?  Of course, the applications must play nice. e.g. Not use the same peripheral. The next thing is to be able to share data. I think there may be a way to share a RAM buffer. The trick would be to do so in a thread-safe way.

[jpeacock2399]

Posted on July 25, 2014 at 01:03

You need to use a real-time operating system (RTOS) which can switch between tasks based on events, and has an inter-process communications facility, typically a queue, to pass messages between tasks. 

FreeRTOS is a good way to start.  I use it to manage about 20 tasks on an STM32F4, works very well.   Jack Peacock

[Tesla DeLorean]

Posted on July 25, 2014 at 01:44

You could build your Loader so that it could take relocatable object files, and then burn them at specific addresses (fixing internal references, memory, and external calls). The Loader could then pass a parameter/structure/handle to the apps, and provide functionality to perform dynamic memory allocation, file handling, serial IO, peripherals, semaphores, etc.

Any good book on the topic of operating systems should provide a good foundation.

[ssmail]

Posted on July 28, 2014 at 18:16

Thanks clive1.

1) Is this 'Loader' concept feasible for 'field upgradable code' where the two applications can be upgraded independently (provided, of course, that the interfaces between them don't change).  Are you saying that with the 'Loader' concept an object file (.o) would have to be sent to the device (and not a 'flat binary') to upgrade it? 2) I see an example of this done on a PIC32 using what they call ''

Run Time Library Loading(RTLL)- System Loader Framework

''.  Does someone know of an ARM-based example? 3) It seems to me what I am trying to do is similar to how   a) Smart Phones download and execute apps.   b) An executable file in Windows works. I'm hoping not to have to use a 'heavy duty' OS like RT Linux to do this.

[Tesla DeLorean]

Posted on July 28, 2014 at 18:31

In the most common usage an object or executable file contains relocation information the OS/Loader can use to place it in memory. A Flat binary image, presumably lacks that, and the ability to place it at any arbitrary address.

While you can certainly ask for ''position independent code'' to be generated, the Cortex-Mx series has vector tables that must point a physical/absolute addresses. These could of course be copied to RAM and patched, provided you have carved out space for them. For the most flexibility in situations where two applications can be updated independently is to have them allocated all their memory dynamically, and not have global RAM references. That or give each it's own subset of the RAM arena. The concept of a loader is pretty basic, and certainly predates Linux. You do have to come up with a format that the loader can load, and unless you have experience and tools to pull it off, you might want to see if the ELF format achieves what you need, and that you can adequately parse the format. Concepts used by MIPS processors should be reasonably portable, but it depends a lot on the tools used to tailor the output from the linker, or options used to get the format(s) you want/need.

[ssmail]

Posted on July 29, 2014 at 23:59 I wonder if a 'dual core' Cortex would be a simpler solution?

[Tesla DeLorean]

Posted on July 30, 2014 at 00:54

I wonder if a 'dual core' Cortex would be a simpler solution?

Well it's a different paradigm, I'm not sure I'd characterize it as simpler. There are issues with coherency, synchronization, and atomic operations. If the Cortex-Mx has enough horse power to do your multiple threads it's worth considering. You can run code from RAM, you could used SDRAM (or external RAM) but it is slower and uncached. The Mx also offers little protection, and no virtualization. If you need those things, other ARM cores might be more appropriate. What's the perceived/anticipated FLASH/RAM foot-print of your current applications?

[Tamas Novak]

Posted on July 30, 2014 at 21:34

My very rough opinion is: Cortex M cores are microcontrollers: not really suitable for operating systems, threads, tasks whatever.  The smartphone of your example usually runs on Cortex A processors, mostly dual or quad core GHz class CPU's.. a very different caste.