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.

uC for Indirect Execution

Discussion in 'Embedded' started by rektide, May 12, 2006.

  1. rektide

    rektide Guest

    Hey everyone,

    I'm looking at starting a new uClinux platform for myself sometime in
    the not-too-far-future. I've got a couple favorites I'd like to play
    with, namely the Blackfin BF561 and the Lpc3180. However, I'm kind of
    worried about what code I can execute: if i recall correctly, neither
    of these architectures (ARM9 and blackfin) can execute code indirectly,
    can run code from ram. I presume this is a restriction of their
    Harvard architetures.

    Where can you store code for these architectures?
    What are fast & low powered micros that can execute code from memory?

    I could be dead wrong, if so, please except my graceful apology.
    -Rektide.
     
    rektide, May 12, 2006
    #1
    1. Advertisements

  2. rektide

    Jack Klein Guest

    I don't know about the Blackfin, but ARM9 processors can most
    certainly execute code from RAM, both from the internal RAM that they
    have, and from external RAM, if they have an external bus.

    But I have no idea what you mean by "execute code indirectly".

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c++-faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, May 12, 2006
    #2
    1. Advertisements


  3. Why uCLinux for an ARM9 with an MMU.
    Curious to know why you want to run Linux without any Ethernet nor LCD?
     
    Ulf Samuelsson, May 12, 2006
    #3
  4. rektide

    David Brown Guest

    People often run ucLinux in embedded systems even if there is an MMU.
    An MMU provides two things - flexibility for things like swap space,
    which is seldom used in embedded systems, and memory protection between
    processes. In most embedded systems, you have (or should have!) total
    control over which processes and programs are running, and don't need
    this sort of protection. MMU's are not free - they often add latency to
    memory access, and they can greatly increase processes switching
    overhead, so there are good reasons not to use one even when it is
    present. Of course, it all depends entirely on your application - there
    are plenty of good reasons *for* using the MMU as well.
     
    David Brown, May 12, 2006
    #4
  5. That presumption is quite universally wrong. Harvard architecture
    means that the CPU *can* strictly separate code and data memory,
    because it's designed that way. It doesn't mean that it *has* to be
    used that way. People have been setting up memory chip selection
    circuitry for Harvard CPUs to behave like von-Neumann ones since the
    dawn of the business.

    Just consider it: all current PC CPUs are actually Harvard
    architectures, with separate primary memories for code and data
    (called the "level 0 cache" or other misguiding names), yet they
    exactly reproduce the behaviour of the original von-Neumann i386
    they've replaced.

    The only thing that can actually keep you from executing code out of
    RAM is if the chip doesn't export its code memory bus to the outside
    world at all. But that has nothing to do with von Neumann
    vs. Harvard.
     
    Hans-Bernhard Broeker, May 12, 2006
    #5
  6. rektide

    Bob Guest

    you are wrong. Blackfin most certainly can (and usually does for speed
    reasons) execute from SDRAM.

    Bob
     
    Bob, May 12, 2006
    #6
  7. rektide

    Tim Wescott Guest

    And the ones that _do_ strictly separate their on-board RAM into program
    and data spaces, such as the Motorola 56000 and Analog's ADSP21xx
    series, have special instructions to access program memory as data, or
    to load program RAM from external flash, or both.

    --

    Tim Wescott
    Wescott Design Services
    http://www.wescottdesign.com

    Posting from Google? See http://cfaj.freeshell.org/google/

    "Applied Control Theory for Embedded Systems" came out in April.
    See details at http://www.wescottdesign.com/actfes/actfes.html
     
    Tim Wescott, May 12, 2006
    #7
  8. The ARM9 datacache gets disabled when you dont have the MMU enabled.
    This is a real performance killer.


    --
    Best Regards,
    Ulf Samuelsson

    This message is intended to be my own personal view and it
    may or may not be shared by my employer Atmel Nordic AB
     
    Ulf Samuelsson, May 13, 2006
    #8
  9. rektide

    David Brown Guest

    That seems a strange limitation to me - especially as the paper I read
    showing something like ten times improvement in process switching speed
    for linux with the MMU disabled was running on an ARM (I forget which).
    But then, I have never looked at the details of ARMs (at least, not
    since the days of the Archimedes when I was still at school), so I have
    no idea of the details.
     
    David Brown, May 13, 2006
    #9
  10. rektide

    rektide Guest

    For some reason, I was under the impression that Harvard uc's often did
    have this limitation, that it was only more full blooded cpu's that
    didnt have this restriction.
     
    rektide, May 17, 2006
    #10
  11. rektide

    rektide Guest

    As to your peripherial query,
    USB powered wifi.

    Although I hadnt noticed there was no ethernet. Ouch. Ah well.

    Good info on the datacache, I probably will run real linux.
     
    rektide, May 17, 2006
    #11
  12. What limitation?
    What are you talking about?

    Please quote appropriately.
     
    Grant Edwards, May 17, 2006
    #12
  13. Disabling the MMU on the ARM9 disables the data cache as well so running
    ucLinux is not "for free" either.
    Disabling the data cache gives a significant performance hit.
    Not only long accesses to RAM, you are all the time doing new RAS cycles on
    the SDRAM
    killing SDRAM accesses for instructions.
     
    Ulf Samuelsson, May 18, 2006
    #13
    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.