• AVR Freaks

LockedRunning code from RAM?

Author
Guest
Super Member
  • Total Posts : 80500
  • Reward points : 0
  • Joined: 2003/01/01 00:00:00
  • Location: 0
  • Status: online
2005/06/08 02:42:43 (permalink)
0

Running code from RAM?

I am in automotive company working on 16F877A. Recently I was posed with the question, is it possible to download code into RAM and run programme from there?
Looking at the architecture of the PIC, I boldly answered that it is not possible, as PC can not be made to point to the RAM.
I think I am correct. If there are any other possible answers or alternatives please reply back....[8|]

P.N.: It is possible in case of PPC5XX series and many others

aspforum.mchp.guest
#1

18 Replies Related Threads

    rkarnik
    Super Member
    • Total Posts : 1355
    • Reward points : 0
    • Joined: 2005/01/02 11:06:42
    • Location: Newark, Delaware, USA
    • Status: offline
    RE: Running code from RAM? 2005/06/08 03:28:21 (permalink)
    0
    ORIGINAL: prasadmshri

    Recently I was posed with the question, is it possible to download code into RAM and run programme from there?
    [8|]



    What were they thinking of doing when this question was asked?

    Maybe ...
    • by code, they didn't mean PIC code. For instance you could have the PIC running a command interpreter and you could upload a new set of instructions for the interpreter to be stored and "executed" from the RAM.

    • it wasn't really RAM they were thinking of, and the real intended question was:
      is it possible to download code into RAM and run programme from there?
      In that case, a bootloader could be used to send updated code to the PIC to be stored and executed from the FLASH memory.
    If neither, your bold answer was correct.

    Rahul

    Recursion
    See Recursion
    #2
    Guest
    Super Member
    • Total Posts : 80500
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: Running code from RAM? 2005/06/09 01:11:31 (permalink)
    0
    I appriciate the quick response....
    But I am afraid, none of ur assumptions are correct.
    In our case we have some product software flashed, which is a deliverable to the customer. We also have test software which is very small and just tests the hardware integrity over the board. The intention here was to test the hardware without touching the flash. If this was one time activity then there was no problem, but the strategy was supposed to be implemented for a automated testing of boards that will go to the customer with the product software being flashed.

    aspforum.mchp.guest
    #3
    schen
    Super Member
    • Total Posts : 790
    • Reward points : 0
    • Joined: 2004/11/15 01:40:07
    • Status: offline
    RE: Running code from RAM? 2005/06/09 03:53:51 (permalink)
    0
    If the test code is small, you might want to include it with the application program. Use an input pin (if you have any to spare) to determine whether the test code or the application code will be used when the device comes out of reset.
    #4
    Guest
    Super Member
    • Total Posts : 80500
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: Running code from RAM? 2005/06/09 09:13:04 (permalink)
    0
    Yeah that was the most simple solution, which is already used for other type of testing program which goes with the product software. In this particular case the requirement is not to touch the product code.
    Looking at such interesting , useful and prompt replies, I am really impressed with this group.
    Kudos...Smile Good job techies...
    #5
    libor
    Starting Member
    • Total Posts : 68
    • Reward points : 0
    • Joined: 2003/11/07 12:48:45
    • Location: Hungary
    • Status: offline
    RE: Running code from RAM? 2005/06/12 01:27:09 (permalink)
    0
    I think, theoretically it would be possible to write a 'command interpreter' that executes the PIC's quasi-native assembly code from RAM, though it would be limited in all aspects. It would have to fetch the next instruction from RAM pointed by an artificial PC register, depending on the opcode it would do a huge switch/table jump to the corresponding instruction category coded in flash ROM, then process the implicit data bits in the instruction code itself, and then repeat the whole loop keeping its own working registers intact.
    Jus for fun, I see no point here.

    Some of our applications are actually written as command interpreters residing in the flash ROM, the 'behavioral code' written in our own very compact, higher level 'language' resides in the EEPROM. We can easily modify/download this very compact code thru air in small packets using RF links in our telemetry applications.
    #6
    rkarnik
    Super Member
    • Total Posts : 1355
    • Reward points : 0
    • Joined: 2005/01/02 11:06:42
    • Location: Newark, Delaware, USA
    • Status: offline
    RE: Running code from RAM? 2005/06/12 08:30:05 (permalink)
    0
    ORIGINAL: libor

    I think, theoretically it would be possible to write a 'command interpreter' that executes the PIC's quasi-native assembly code from RAM, though it would be limited in all aspects. It would have to fetch the next instruction from RAM pointed by an artificial PC register, depending on the opcode it would do a huge switch/table jump to the corresponding instruction category coded in flash ROM, then process the implicit data bits in the instruction code itself, and then repeat the whole loop keeping its own working registers intact.
    Jus for fun, I see no point here.

    Some of our applications are actually written as command interpreters residing in the flash ROM, the 'behavioral code' written in our own very compact, higher level 'language' resides in the EEPROM. We can easily modify/download this very compact code thru air in small packets using RF links in our telemetry applications.

    Very cool!

    I write behavioural code, in my home groan state machine definition language, that ends up residing in arrays of structures.
    The system of stateful objects itself occupies RAM.
    The state transition event handlers are encoded for the/any native micro/platform in use.
    The method pointers are embedded (at compile time using some nifty macro techniques) into the state machines themselves, so for now they don't directly go into the EEPROM in the same pass.
    The method pointer for the next state is looked up and indirectly called from the main loop whenever an interrupt event or a message (from say another object) triggers a state transition.

    I could (and should) look into multiple pass code generation/compilation to generate compact "code-data" which could then be stuffed into an EEPROM (if not on-chip, maybe on an I2C device).

    Rahul

    Recursion
    See Recursion
    #7
    bob_barr
    Super Member
    • Total Posts : 5428
    • Reward points : 0
    • Joined: 2003/11/07 12:35:23
    • Location: Morgan Hill, CA
    • Status: offline
    RE: Running code from RAM? 2005/06/12 08:45:41 (permalink)
    0
    A programming language called Forth does a number of things very similarly to what you're describing.

    Programs are written as tokens which can be stored in non-volatile memory and get executed by an interpreter. A data stack handles most of the data and a separate return stack allows 'subroutine' calling.

    While it's always good to learn from one's mistakes, it's much easier to learn from the mistakes of others.
    Please don't PM me with technical questions. I'll be quite happy to help (if I can) on the forums.
    #8
    wolfins
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2005/06/09 10:53:48
    • Location: Cleveland, OH
    • Status: offline
    RE: Running code from RAM? 2005/06/12 15:29:06 (permalink)
    0
    On a side note, the BASIC Stamp from Parallax uses a PIC and an EEPROM to run programs from EEPROM. The PIC serves as a command interpreter and tokens are downloaded into the EEPROM. As far as I can remember, program execution was rather slow. The Stamps are a good way for beginners to get started in microcontroller development, though wink
    #9
    Guest
    Super Member
    • Total Posts : 80500
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: Running code from RAM? 2005/06/13 02:59:23 (permalink)
    0
    it is not possible to run program from RAM as PICs are not von Neuman architecture, also the ROM is 14bits and RAM only 8bits, how would you want to push 14 bits into 8 bits?
    remeber, the original code CAN NOT be touched
    #10
    libor
    Starting Member
    • Total Posts : 68
    • Reward points : 0
    • Joined: 2003/11/07 12:48:45
    • Location: Hungary
    • Status: offline
    RE: Running code from RAM? 2005/06/14 11:35:58 (permalink)
    0
    The thread went astray (was my fault Smile ) lacking the definition of what we call 'program'. It can be either PIC's native assembly, or any other machine-interpretable executable code in any standard or proprietary language. These higher-level interpreted program codes can be executed from anywhere the PIC has access to.
    You can also store the 14-bits instructions in two RAM locations each and feed your PIC native code interpreter with them. Theoretically.
    #11
    Guest
    Super Member
    • Total Posts : 80500
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: Running code from RAM? 2005/06/15 04:57:41 (permalink)
    0
    ORIGINAL: libor
    You can also store the 14-bits instructions in two RAM locations each and feed your PIC native code interpreter with them. Theoretically.

    I would like to elaborate on that for better clarity, correct me if I am wrong.
    We will be storing the instructions in RAM, in blocks of two. The interpeter code residing in the flash will be having its on vertual PC, which it would keep on incrementing (twice per instruction) to fetch the instructions one by one from RAM.
    But after fetching the instruction, it has to be loaded on to the instruction decode circuitry (or IR, instruction register). This is not possible to implement in PIC as there is no access to IR, other than through Flash.
    Thus having interpreter will not solve the problem for PIC.sad
    I do not have much knowledge on interpreter, hence please correct me if my understanding is wrong.
    If u meant writing "microcode", then it is not supported for PIC.
    #12
    schen
    Super Member
    • Total Posts : 790
    • Reward points : 0
    • Joined: 2004/11/15 01:40:07
    • Status: offline
    RE: Running code from RAM? 2005/06/15 06:38:44 (permalink)
    0
    A programming language called Forth does a number of things very similarly to what you're describing.

    Programs are written as tokens which can be stored in non-volatile memory and get executed by an interpreter. A data stack handles most of the data and a separate return stack allows 'subroutine' calling.

    The Forth implementations I've seen so far still require the threads of tokens be store in the code space. Does anyone know a PIC implementation of interactive Forth?
    #13
    libor
    Starting Member
    • Total Posts : 68
    • Reward points : 0
    • Joined: 2003/11/07 12:48:45
    • Location: Hungary
    • Status: offline
    RE: Running code from RAM? 2005/06/15 12:49:04 (permalink)
    0
    ORIGINAL: prasadmshri
    If u meant writing "microcode", then it is not supported for PIC.

    I meant normal code. You do not load the fetched instruction into the decode circuitry (ie. hardware), rather you execute an identical single instruction or other instructions resulting the required effect (of one instruction at a time) in normal code and then repeat the process carefully watching out to save the relevant processor status between the iterations.
    e.g. if you have fetched movlw 0xAB 's code from RAM, you then execute those instructions that would result loading 0xAB into the W register. And so on.
    I insist, that writing such an interpreter that executes its' host native language has no practical value. It would be slow and limited in many hw related features. This freaky idea is a by-product of my experience in writing interpreters that execute our company's own proprietary, high-level very compact language used for defining state-machines in communication protocols (telemetry) applications.

    This resembles me of my first bigger programming project being a kid, I wrote an assembly language interpreter (simulator) in BASIC that simulated executing 8088's assembly instructions. Just for fun/learning. Funny, isn't it?
    < Message edited by libor -- Jun. 15, 2005 1:12:06 PM >
    #14
    rkarnik
    Super Member
    • Total Posts : 1355
    • Reward points : 0
    • Joined: 2005/01/02 11:06:42
    • Location: Newark, Delaware, USA
    • Status: offline
    RE: Running code from RAM? 2005/06/15 15:22:32 (permalink)
    0
    ORIGINAL: schen

    A programming language called Forth does a number of things very similarly to what you're describing.

    Programs are written as tokens which can be stored in non-volatile memory and get executed by an interpreter. A data stack handles most of the data and a separate return stack allows 'subroutine' calling.

    The Forth implementations I've seen so far still require the threads of tokens be store in the code space. Does anyone know a PIC implementation of interactive Forth?


    Interested in my flavour of Froth? That's what I may decide to call what I'm doing wink

    Rahul

    Recursion
    See Recursion
    #15
    schen
    Super Member
    • Total Posts : 790
    • Reward points : 0
    • Joined: 2004/11/15 01:40:07
    • Status: offline
    RE: Running code from RAM? 2005/06/15 15:31:01 (permalink)
    0
    Sure. I am interested in your flavour of your Froth.
    #16
    jjmcd
    Super Member
    • Total Posts : 856
    • Reward points : 0
    • Joined: 2005/04/01 19:11:14
    • Location: Michigan, U.S.A.
    • Status: offline
    RE: Running code from RAM? 2005/06/22 06:27:57 (permalink)
    0
    First of all, unless you touch the application code once, you are not going to be able to do anything. As a minimum, you need to choose whether to run a test or the application.

    However, the idea of interpreted code may well work for your test scenario.

    There are a limited number of things you can do to test the board integrity. Were you to encode those things, you could write an interpreter for those codes. You would still need to write some way to download the test script into RAM (or maybe EEPROM) as well as the interpreter. But if you look at what you have done in the way of testing in the past, and what would be reasonable to do in the future, I would suspect you would end up with a fairly limited set of operations that could be encoded into some sort of bytecode that could then be interpreted.

    Since you are not trying to implement some general purpose language, you should be able to get much better performance than something like the Basic Stamp that had the problem of implementing a Basic interpreter.

    --McD
    #17
    Guest
    Super Member
    • Total Posts : 80500
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: Running code from RAM? 2005/07/05 23:27:41 (permalink)
    0
    If I understand the breadth of this discussion, we be talking apples & oranges.

    I give my PIC EEPROM, but despite variable potential, I'm stuck with Harvard
    architecture rather than Von Neumann architecture or the reverse if I don't know my terminology. How nice would it be to bootload stuff...

    Not to poo poo things, but I prefer the x86 Z80 yadda yadda all memory is program, all program is memory way of dealing with things despite inefficiencies and the ploethera of problems that are introduced. Why? flexibility. Not without a price.

    dhm
    #18
    jjmcd
    Super Member
    • Total Posts : 856
    • Reward points : 0
    • Joined: 2005/04/01 19:11:14
    • Location: Michigan, U.S.A.
    • Status: offline
    RE: Running code from RAM? 2005/07/06 05:17:39 (permalink)
    0
    ORIGINAL: D_Man
    Why? flexibility. Not without a price.

    And that's the name of the game, isn't it? There are advantages to Harvard, just as there are advantages to von Neumann. There are advantages to the PIC 16F over the 18F over the 30F, as well as disadvantages.

    In many embedded control applications, the advantages of Harvard significantly outweigh the advantages of von Neumann. In many traditional computing environments, the advantages of von Neumann significantly outweigh the advantages of Harvard. It all depends on your application.

    If you look at your x86/Z80/etc. There is a lot of flexibility with "all memory is program", but think about what that means. First, since the program and data memory require the same width, I either need to have a multiple fetch program word, or a data memory that is hard to address. The x86 addresses this with extremely complicated (read expensive) hardware. But this also has an implication on the memory technology. All of the memory must be extemely fast. So a FLASH program memory really isn't an option unless I want horrid performance. Sure, I can build such a computer, with plenty of wait states for program, but now I have a solution that is orders of magnitude more expensive than most embedded applications can stand, and in hardware, I've basically enforced the separate program/data memory of Harvard. (Unless, of course, I choose my "RAM" to be FLASH, in which case I get some pretty astonishingly bad performance!) So I end up having big, power-hungry, expensive "boot devices". They make good sense in a PC, not a lot of sense in a clock radio.

    On the other hand, the traditional operating system features of loading programs and managing memory are really clumsy on the PIC, and not even possible on many models. We see bizarre workarounds like the Basic Stamp to try to make the PIC look like a "real computer", but they are pretty unsatisfying.

    It all boils down to the right tool for the job. If you want to run a microwave oven, you use a PIC. If you want to play Solitaire, you use an x86. Not such a hard concept to grasp.

    --McD
    #19
    Jump to:
    © 2019 APG vNext Commercial Version 4.5