> ...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. > > AlFirst 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.
dynamic execution of tasks in uC
Started by ●June 18, 2004
Reply by ●June 19, 20042004-06-19
Reply by ●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
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 ●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 ●June 21, 20042004-06-21
> Lots of interesting things you can do with this. > > Cheers > > AlOK, thanks, i will try it :-) Heiko.
Reply by ●June 21, 20042004-06-21
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... > >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.
