Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Using External RAM

Sourcy
2014-07-04
2014-07-08
  • Sourcy
    Sourcy
    2014-07-04

    Hello,

    So I managed to get my hands on a version of the QUADram by rugged circuits to be specific I got it from the link below.

    I was reading through the code and as far as I understand I just have to define portQUAD_RAM and the following linker and object copy and t should work right?

    Do I also need to comment out this line: void extRAMinit (void) attribute ((used, naked, section (".init3")));

    Are these add the two lines I need to add to linker and object copy:

    linker: -Wl,--section-start=.ext_ram_heap=0x802200 -Wl,--defsym=heap_start=0x802200,--defsym=heap_end=0x80ffff

    Objectcopy: --remove-section=.ext_ram_heap

    Just to clarify to add stuff to the linker under eclipse i just need to put it into (AVR C linker -> general -> other aruguments )

    And to add stuff into the object copy (AVR create Flash imagine -> addtioanl Options for objcopy)

    I am using an atmega2560

    http://www.lagrangianpoint.net/en/prebuiltmodules/arduino-mega-sram-expansion-shield-pre-built

     
  • No, don't comment out the
    void extRAMinit (void) attribute ((used, naked, section (".init3")));
    line in the header file. You need all of this to initialise the XRAM properly. It is automatically added into the .init3 section of the code by the Linker, naked, i.e. without normal function preamble and postscript. To get it linked properly, just a call of any function in the same file is needed. This is taken care of automatically by a call to extRAMcheck() in portable.c.

    Check the Lagrangianpoint hardware is identical to the Rugged Circuits version. The hardware lines might be implemented differently. I haven't looked at potential differences.

    And yes, to your Linker and Object Copy statements.

     
    Last edit: Phillip Stevens 2014-07-04
  • Sourcy
    Sourcy
    2014-07-07

    Which project do I place the two into? Do I place it in my static library (contains freeRTOS) or application code that uses the static library.

    linker: -Wl,--section-start=.ext_ram_heap=0x802200 -Wl,--defsym=heap_start=0x802200,--defsym=heap_end=0x80ffff
    Objectcopy: --remove-section=.ext_ram_heap

    Currently when I try to do a self test on the memory the read line just stays high. I waited for 2 mins and it never came off. I think the MCU is crashing.

    Update:
    Actually the board are a bit different
    That is the board I am using
    http://andybrown.me.uk/wk/2013/05/05/512k-xmem-in-shield-format/
    I am currently going through the code that posted on the website above so I could try and change your code so it could work with the board

     
    Last edit: Sourcy 2014-07-07
  • Sourcy
    Sourcy
    2014-07-07

    I think I may need some help I tried to. I tried using the code attached below. To adjust your code but when I try "extRAMSelfTest" my serial port stop working.

    :/

     
    Attachments
  • The issue is very simply resolved. extRAMSelfTest is destructive.
    You should expect everything to stop working.

    I mention this explicitly in the code examples.

    #if defined (portEXT_RAM_8_BANK)
        extRAMSelfTestResults testResults;
        extRAMInitHeap( pdTRUE );
        // FIRST a test on the external RAM, before we do anything else.
        // This test is destructive.
        testResults = extRAMSelfTest();
    #endif
    
     
  • Sourcy
    Sourcy
    2014-07-08

    Ok, thanks. That explains alot. Is there anyway I can get freeRTOS to use more than 32kB for the heap? I am currently looking into that.

     
  • No you can't (simply) get AVRfreeRTOS to use more than 32kByte for the heap.

    I remember spending quite a few nights digging into the code to determine why, but I seem to have forgotten the actual reason. I think it may have been something about using signed 16bit values for heap sizes on the AVR port. That may be a false memory though.

    I was thinking of building some options in the task switcher to assign one heap per task, effectively giving 15 tasks (plus the scheduler / idle task) each 32kB of heap space. But, it meant quite a few patches and more problems than I really needed.

    There's not really any reason to use the heap for such large RAM requirements anyway. If you want to store large buffers, just use the extRAM tools to do bank switching for the particular function you need.

    I took the path of keeping one heap, but accessing 16 buffers, in this example of maintaining 16 RAM buffers for 16 client devices, for ArduSat XRAMFS Prototyping

    Remember with preemptive multitasking your function will be interrupted, so your tick interrupt will need to handle reverting the RAM bank back to the correct one to allow other functions to work.

     
    Last edit: Phillip Stevens 2014-07-08