From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tony Armitstead <tonya@noral.com>
To: ecos-discuss@sourceware.cygnus.com
Subject: [ECOS] Downloadable tasks?
Date: Tue, 23 Jan 2001 08:38:00 -0000
Message-id: <5.0.2.1.0.20010123160652.00a66090@mail.noral.co.uk>
X-SW-Source: 2001-01/msg00386.html

Hi,

I am considering using eCos in a KS32C50100 (ARM) application which 
requires down-loadable code images each of which contains 2 threads. My 
ideas are:

1. Product contains a boot ROM which downloads the eCos kernel along with 
some resident threads (basically host communications stuff). The eCos 
kernel is then installed and effectively takes over the operation of the 
target.

2. The eCos kernel would be extended to support a 'remote' kernel API 
interface accessed via SWI 'calls'

3. The downloaded images would be downloaded and their threads created 
within eCos. Each image would have a table giving the location, stack ..... 
of the threads within the image. Or maybe just an initialisation call which 
would create the threads using the remote API interface. Each downloaded 
image would be linked with a library of eCos API calls which just SWI down 
to the resident eCos kernel.

I have looked through the 'Native kernel C language API' calls and nothing 
jumps out at me as being a major problem. Note that each image would be 
linked with its own version of the C runtime library so I don't need to 
patch through all those calls as well! None of the images need to do device 
IO so I should be able to get the RTL footprint down to a reasonable level 
for each image.

So, does anyone have any thoughts on this - or maybe already done it (for ARM)!



/======================================================\
| Tony Armitstead BSc        EMail: tonya@noral.com    |
| Development Manager        Phone: +44 (0)1254 295807 |
| Noral Micrologics            Fax: +44 (0)1254 295801 |
| WEB: http://www.noral.com   FTP: ftp://ftp.noral.com |
\======================================================/