1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

dynamic execution of tasks in uC

Discussion in 'Embedded' started by heiko_greiner, Jun 18, 2004.

  1. 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.
     
    heiko_greiner, Jun 18, 2004
    #1
    1. Advertisements

  2. wrote in
    I believe VxWorks can do this. See www.windriver.com
     
    Mark A. Odell, Jun 18, 2004
    #2
    1. Advertisements

  3. IIRC, somebody wrote an ELF loader for eCos

    <http://sources.redhat.com/ecos>
    <http://www.ecoscentric.com/>

    It requires a 32-bit uC, so it's not going to run on an HCS12
    or C16x.
     
    Grant Edwards, Jun 18, 2004
    #3
  4. 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. :)
     
    Grant Edwards, Jun 18, 2004
    #4
  5. You know it's sad, really, how I cannot read postings completely. Thanks
    for the correction.
     
    Mark A. Odell, Jun 18, 2004
    #5
  6. 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.
     
    Grant Edwards, Jun 18, 2004
    #6
  7. heiko_greiner

    CodeSprite Guest

    wrote in
    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.
     
    CodeSprite, Jun 18, 2004
    #7
  8. heiko_greiner

    CodeSprite Guest

    wrote in
    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.
     
    CodeSprite, Jun 18, 2004
    #8
  9. heiko_greiner

    onestone Guest

    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
     
    onestone, Jun 19, 2004
    #9
  10. Sciopta (www.sciopta.(de|com)) is fully dynamic even for 16bit
    machines (including M16C, MSP430, HC(S)12).
     
    42Bastian Schick, Jun 19, 2004
    #10
  11. ...It is a fairly simple task to do this on any
    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.
     
    heiko_greiner, Jun 19, 2004
    #11
  12. heiko_greiner

    Stephen Pelc Guest

    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,
    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
     
    Stephen Pelc, Jun 19, 2004
    #12
  13. heiko_greiner

    John Taylor Guest

    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.
     
    John Taylor, Jun 19, 2004
    #13
  14. heiko_greiner

    onestone Guest

    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
     
    onestone, Jun 19, 2004
    #14
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.