>i'm wondering if there is an (rt)os for uC (i.e. HCS12, C16x,...) that
>executes tasks, that can be loaded at runtime. In my mind, there is
>the idea, that there is a central uC with "a lot of binary code" that
>can be swaped in a (can-, serial-) network between some uC. I don't
>want to start with an something like uCLinux, because of a limited
>students budgets...
>
>Please name some rtos or point me to some app notes, white papers or
>so.
What tool chain are you using?
You could use relocatable object files for the tasks. This is how
Linux kernel modules work. This code
http://my.execpc.com/~geezer/osd/exec/runreloc.zip
will load and run an i386 COFF, PE, or ELF object file. It could
be rewritten for use with other CPUs and file formats. Because
it uses some unique features of ld (the GNU linker), I don't
think it will work with anything other than the GCC tool chain,
however.
Reply by ●June 21, 20042004-06-21
> Lots of interesting things you can do with this.
>
> Cheers
>
> Al
OK, thanks, i will try it :-)
Heiko.
Reply by onestone●June 19, 20042004-06-19
heiko_greiner@hotmail.com wrote:
>>...It is a fairly simple task to do this on any
>>micro that can execute code from RAM. I used this technique on a HC05
>>around 1990, as part of a security system, and use a similar technique
>>now on MSP430's to up date software/implement security functions etc.
>>
>>Al
>
>
> First of all, i meant the hardware required for uCLinux might be to
> expensive for my budget ;-)
>
> Al, do you have a link to a project, using ram (or flash?) for dynamic
> tasks? Or can you try to explain how to implement such a technique ?
>
> thanks,
>
> Heiko.
Hello Heiko. The principles are simple. Take the MSP430 for example,
which I currently use in a lot of products/projects. It can execute code
from RAM. There are many ways to execute external tasks. The mechanism
you use will usually depend upon whether the task request is generated
by the process, or externally. Where I have used this for process
requested tasks I have typically had an external secure memory store
which holds the desired task. Thus the micro itself contains no security
information useful to anyone hacking the system. In it's simplest form
the following hopefully will convey the concept. IT ISN'T MEANT TO BE
WORKING CODE!
;******** COMMS PROTOCOL MESSAGE TYPE CONSTANTS
SENDDATA EQU 01
READDATA EQU 02
SENDSTATUS EQU 03
FETCHTASK EQU 04
ORG RAMSTART
CODEBUFF: DS 512 ;RESERVE 512 BYTES AS CODE BUFFER
TASKQ DS 32 ;RESERVE 16 SLOTS FOR TASK
OTHER VARS..
ORG PROGSTART
RESET:
MOV #RAMEND,SP
CALL #INIT ;PERFORM BASIC START UP
CLR R4 ;R4 RESERVED AS TASKQ POINTER
CLR &TASKQ ;SET NULL TASK IN Q0
MAIN:
CALL #TASKQ(R4) ;EXECUTE THE NEXT TASK
DECD R4
JC MAIN
CLR R4
JMP MAIN
NULLTASK:
RET
/*******************************************************************
ETASK IS A REQUEST TO EXECUTE A TASK STORED EXTERNALLY
IN THIS SIMPLE EXAMPLE THERE IS ONLY PROVISION FOR ONE ETASK.
A CRUDE SINGLE BYTE COMMAND IS SENT TO SOME EXTERNAL SOURCE
INSTRUCTING IT TO DOWNLOAD THE CODE TO BE EXECUTED. THE RECEIVED DATA
WILL BE PLACED IN CODEBUFF. YOU THEN GET TWO CHOICES(AT LEAST).
AFTER SENDING THE COMMAND BYTE. LOOP UNTIL THE CODE IS RECEIVED (FOR
WHEN IT MUST EXECUTE IMMEDIATELY. oR SIMPLY EXIT
AND ALLOW THE RECEIVE PROTOCOL TO PUSH THE NEW TASK ONTO THE
QUEUE.
********************************************************************/
ETASK:
MOV #CODEBUFF,&RX_PTR ;SET RECEIVE DATA POINTER
MOV.B #FETCHTASK,&TXDATA ;DON'T NEED A TASK, PROTOCOL IS ;SINGLE
BYTE FROM MICRO.
RET
/***********************************************************************
RECEIVE MESSAGE STRUCTURE
ADDR 0 MSG TYPE
ADDR 1 DATA LENGTH IN WORDS N
ADDR 2 TASKMSB ;TASK TO BE EXECTUTED UPON DOWNLOAD
ADDR 3 TASKLSB
ADDR 4 DATA
ADDR 5 ...
ADDR 2N+4 ...
ADDR 2N+5 MSB CRC
ADDR 2N+6 LSB CRC
ONCE THE MESSAGE HAS BEEN RECEIVED AND VERIFIED The TASK contained
within the message, actually the address of CODEBUFF, is placed into the
TASKQ.
On most occasions I erase the entire code buffer after completion, so,
if this is the case the message header might include a double task
entry, where the firts task placed on the Q (assuming FILO handling) is
the clean up routine.
Typuically the original ETASK might be placed on the queue by an
external interrupt, such a a key press, or detection of a DALLAS secure
memory device.
This is obviously an over simplified explanation, but most of the
necessary elements are there. Most assemblers will generate code for RAM
based source, but keeping the source relocatable will be necessary
sometimes.
The second method is even more powerful, the originating request is
external. The message protocol for the receiver simply places certain
data from each message in the TASKQ. This could be done EVERY TIME a
message is received, as a simple camouflage method using NULLTASK. Or
may only be done for certain message types.
Of course more than one program or function may be buried in the
downloaded code. For example you may download the code necessary to
re-write internal flash using this method, and at the same time download
a decryption algorithm which takes existing data in FLASH, DECRYPTS IT,
then stores it back where it came from. using micro controlled shut down
you can guarantee reverting the flash upon completion, unless the user
pulls power, or RUN an address translator from RAM, and even if power is
pulled the code will be hard to decipher.
Lots of interesting things you can do with this.
Cheers
Al
Reply by John Taylor●June 19, 20042004-06-19
heiko_greiner@hotmail.com wrote in message news:<46d644f4.0406181043.411c95cd@posting.google.com>...
> Hi,
>
> i'm wondering if there is an (rt)os for uC (i.e. HCS12, C16x,...) that
> executes tasks, that can be loaded at runtime.
The BrickOS is a preemptive multithreaded OS for Lego Mindstorm that
supports dynamic programming loading via the IR port. The Mindstorms
�brick' is based on Renesas's (Hitachi) H8/3239 MCU.
(http://brickos.sourceforge.net/ )
A quick snippet from the BrickOS website:
brickOS is an open source embedded operating system and provides a C
and C++ programming environment for the Lego Mindstorms Robotics Kits,
allowing the owner of such a kit to program in good old C (and now
C++) instead of the standard Lego Programming Language. It was
originally developed on Linux, but should run on most Unices as well
as Windows.
Reply by Stephen Pelc●June 19, 20042004-06-19
On 18 Jun 2004 11:43:18 -0700, heiko_greiner@hotmail.com wrote:
>i'm wondering if there is an (rt)os for uC (i.e. HCS12, C16x,...) that
>executes tasks, that can be loaded at runtime. In my mind, there is
>the idea, that there is a central uC with "a lot of binary code" that
>can be swaped in a (can-, serial-) network between some uC. I don't
>want to start with an something like uCLinux, because of a limited
>students budgets...
A major issue to consider is whether the hardware will change, and
how much protection you want from that. We designed what eventually
became Europay's Open Terminal Architecture (OTA) for payment
terminals. See
www.europay.com
for the specifications. See also Open Firmware and Brad Eckert's
Tiny Open Firmware. These all use tokenised binary or source code.
These days, with the available horsepower in an HCS12, I'd just
put a simple compiler on the nodes. You can always compress the
source for delivery. The source can be intermediate language
code.
If you design the RTOS services for the application domain
you will find that the application spends most of its time in
the service code, so that the quality of the on-board compiler
is of secondary performance. This also applies to tokenised
binary systems.
Stephen
--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
Reply by ●June 19, 20042004-06-19
> ...It is a fairly simple task to do this on any
> micro that can execute code from RAM. I used this technique on a HC05
> around 1990, as part of a security system, and use a similar technique
> now on MSP430's to up date software/implement security functions etc.
>
> Al
First of all, i meant the hardware required for uCLinux might be to
expensive for my budget ;-)
Al, do you have a link to a project, using ram (or flash?) for dynamic
tasks? Or can you try to explain how to implement such a technique ?
thanks,
Heiko.
Reply by 42Bastian Schick●June 19, 20042004-06-19
On 18 Jun 2004 11:43:18 -0700, heiko_greiner@hotmail.com wrote:
>Hi,it
>
>i'm wondering if there is an (rt)os for uC (i.e. HCS12, C16x,...) that
>executes tasks, that can be loaded at runtime. In my mind, there is
>the idea, that there is a central uC with "a lot of binary code" that
>can be swaped in a (can-, serial-) network between some uC. I don't
>want to start with an something like uCLinux, because of a limited
>students budgets...
>
>Please name some rtos or point me to some app notes, white papers or
>so.
Sciopta (www.sciopta.(de|com)) is fully dynamic even for 16bit
machines (including M16C, MSP430, HC(S)12).
--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@epost.de instead !
Reply by onestone●June 18, 20042004-06-18
Grant Edwards wrote:
> On 2004-06-18, Mark A. Odell <odellmark@hotmail.com> wrote:
>
>
>>>>>i'm wondering if there is an (rt)os for uC (i.e. HCS12,
>>>>>C16x,...) that executes tasks, that can be loaded at runtime.
>>>>>[...] I don't want to start with an something like uCLinux,
>>>>>because of a limited students budgets...
>>>>
>>>>I believe VxWorks can do this. See www.windriver.com
>>>
>>>VxWorks is never going to run on an HCS12 or C16x, and for
>>>somebody who can't afford uCLinux, it's also going to be darned
>>>expensive. :)
>>
>>You know it's sad, really, how I cannot read postings
>>completely. Thanks for the correction.
>
>
> Unfortunately for the OP, I don't think there is going to be
> much of anything smaller/cheaper than uCLinux or vxWorks with
> dynamic loading -- that tends to be a "big system" feature only
> found on 32-bit systems with several MB of RAM.
>
But it doesn't need to be. It is a fairly simple task to do this on any
micro that can execute code from RAM. I used this technique on a HC05
around 1990, as part of a security system, and use a similar technique
now on MSP430's to up date software/implement security functions etc.
Al
Reply by CodeSprite●June 18, 20042004-06-18
heiko_greiner@hotmail.com wrote in
news:46d644f4.0406181043.411c95cd@posting.google.com:
> Hi,
>
> i'm wondering if there is an (rt)os for uC (i.e. HCS12, C16x,...) that
> executes tasks, that can be loaded at runtime. In my mind, there is
> the idea, that there is a central uC with "a lot of binary code" that
> can be swaped in a (can-, serial-) network between some uC. I don't
> want to start with an something like uCLinux, because of a limited
> students budgets...
>
> Please name some rtos or point me to some app notes, white papers or
> so.
>
> Thanks in advance,
>
> Heiko.
Would it make sense to keep this *much* simpler and build a simple
interpreter task that can execute small scripts downloaded to the
device?
That way you can have the effect of downloadable programs without the
complication of dynamic tasks, and with less chance of erroneous student
programs causing the system to fail in ways that are strange, wonderful
and difficult to debug.
I *guess* something like a p-code interpreter may fit onto your target
system, in which case you can use readily available compilers to
generate applications.
Peter.
Reply by CodeSprite●June 18, 20042004-06-18
heiko_greiner@hotmail.com wrote in
news:46d644f4.0406181043.411c95cd@posting.google.com:
> Hi,
>
> i'm wondering if there is an (rt)os for uC (i.e. HCS12, C16x,...) that
> executes tasks, that can be loaded at runtime. In my mind, there is
> the idea, that there is a central uC with "a lot of binary code" that
> can be swaped in a (can-, serial-) network between some uC. I don't
> want to start with an something like uCLinux, because of a limited
> students budgets...
>
> Please name some rtos or point me to some app notes, white papers or
> so.
>
> Thanks in advance,
>
> Heiko.
Would it make sense to keep this *much* simpler and build a simple
interpreter task that can execute small scripts downloaded to the device?
That way you can have the effect of downloadable programs without the
complication of dynamic tasks, and with less chance of erroneous student
programs causing the system in ways that are strange, wonderful and
difficult to debug.
I *guess* something like a p-code interpreter may fit onto your target
system, in which case you can use readily available compilers to generate
applications.
Peter.