• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 99 subscribers
  • Views 596 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[C6747] Downsizing McASP drivers in the PSP

E2E_display_name_Mike
Expert 1700 points


Hi,

I've been studying the C6747 McASP driver code from PSP release 1.20.00.  For our application, we need to reduce the size of this driver.  Our goal is to have our entire application executing from L2 memory w/o need for external memory.  Here is what I thought of doing:

  1. Have the driver only support a single McASP instance.  We only use McASP1 in our application and are using McASP0 and 2 pins for other peripherals.  It seems this will reduce the size of a few global variables and buffers.  I suppose I could even dedicate the driver to just McASP1 but I don't think it's much savings over a single instance driver (user selects 0-2).  Any attempt to create an instance on another McASP device would fail.
  2. Remove support for DIT mode.  We have no need for this mode in our application.
  3. Remove code checks for "isDmaDriven" since the driver only works when this is TRUE.
  4. Have each function placed in a separate file and rebuild the library.  Then unused functions aren't imported.

Any other suggestions for reducing the driver footprint would be helpful.

Here are general questions I have that might also help me reduce code size:

  1. If the application is executing entirely within L2 (and L3?), do I need to worry about cache issues? (e.g. calls to BCACHE_xxx, etc.)
  2. Which high-level (e.g. SIO_xxx)  functions call the IOCTL functions?  Would it be possible to eliminate the function "Mcasp_localSubmitIoctl" and the functions it calls?

Feel free to comment on any/all of these points.[;)]

thanks,

Mike

  • 0
    TI__Guru*** 125430 points

    Mike said:

    Have each function placed in a separate file and rebuild the library.  Then unused functions aren't imported.

    There's a compiler switch  called --gen_func_subsections that automatically does that for you.  There is a negative in that each new code section has to be aligned on a 32-byte boundary and so that can sometimes cause a lot of extra padding in the code, i.e. this can back fire!

    Mike said:

    Any other suggestions for reducing the driver footprint would be helpful.

    I had requested the PSP team add an #ifdef statement around all the parameter checking at the beginning of each function.  I think it was called PSP_DISABLE_PARAMETER_CHECKING or something similar.  When you rebuild the code you should make sure in your compiler options to create a defintion (-D) for PSP_DISABLE_PARAMETER_CHECKING or whatever it was called, e.g. -DPSP_DISABLE_PARAMETER_CHECKING.  That will immediately make all that code vanish.

    Mike said:

    Here are general questions I have that might also help me reduce code size:

    1. If the application is executing entirely within L2 (and L3?), do I need to worry about cache issues? (e.g. calls to BCACHE_xxx, etc.)

    In L2, no.  In L3, yes.  It's only if you have a shared buffer in L3.  That is if both DMA and CPU are accessing the same buffer in L3 then you would need to worry about cache.  If it's only code or data touched exclusively by the CPU (or exclusively by a DMA) then you don't need to worry about cache coherence.

    Mike said:
    1. Which high-level (e.g. SIO_xxx)  functions call the IOCTL functions?  Would it be possible to eliminate the function "Mcasp_localSubmitIoctl" and the functions it calls?

    Sorry, don't recall off-hand.  Maybe someone else will chime in.

     

  • 0 in reply to Brad Griffis
    Expert 1700 points

    Mike said:

    Have each function placed in a separate file and rebuild the library.  Then unused functions aren't imported.

    Brad Griffis said:

    There's a compiler switch that automatically does that for you.  There is a negative in that each new code section has to be aligned on a 32-byte boundary and so that can sometimes cause a lot of extra padding in the code, i.e. this can back fire!  (Sorry, I don't remember the switch off-hand and it's too late at night for me to dig for it!)

    But can I use this option to at least find out which functions aren't being used by my application, right?  Then I can go back and comment out or remove them.  This would be much easier than moving each function to its own file.  Let me know when you find out what the option is.  I'm not familiar with it either.  I just know the one that dumps dead functions to an output file.

    Brad Griffis said:

    I had requested the PSP team add an #ifdef statement around all the parameter checking at the beginning of each function.  I think it was called PSP_DISABLE_PARAMETER_CHECKING or something similar.  When you rebuild the code you should make sure in your compiler options to create a defintion (-D) for PSP_DISABLE_PARAMETER_CHECKING or whatever it was called, e.g. -DPSP_DISABLE_PARAMETER_CHECKING.  That will immediately make all that code vanish.

    Yep.  I see this and will include the define when the driver module is rebuilt and debugged.  But I should do a test build with it defined to have an idea about the code size reduction.

     

  • 0 in reply to E2E_display_name_Mike
    TI__Mastermind 18130 points

    Mike said:
    But can I use this option to at least find out which functions aren't being used by my application, right?  Then I can go back and comment out or remove them.  This would be much easier than moving each function to its own file.  Let me know when you find out what the option is.  I'm not familiar with it either.  I just know the one that dumps dead functions to an output file.

    I believe the switch Brad mentioned is -mo which tells the compiler to create a separate compiler section for each function (e.g., .text:_func1 and .text_func2). The linker should then only link in the compiler sections that are actually used.

  • 0 in reply to yl
    Expert 1700 points

    My understanding is that it's not so much a bug as just an over-allocation of memory.  When I reduce the driver to only support a single McASP, I'll also adjust the loopjob buffer sizes.  I may even be able to get rid of the mute buffer since our application is not audio.

    Another weird thing is, as per my understanding of the C6747, you can't even configure the chip to use both McASP0 and McASP2 because their pins are multiplexed.  So really the most instances you could support is 2.  But the driver code supports 3 McASP device instances [*-)]

    Mike

  • 0 in reply to TimHarron
    Expert 1700 points

    TimHarron said:

    I believe the switch Brad mentioned is -mo which tells the compiler to create a separate compiler section for each function (e.g., .text:_func1 and .text_func2). The linker should then only link in the compiler sections that are actually used.

    Tim, yes I checked the option and with this invoked I can see in the linker output file that each function has its own section.  But now I see the real problem is that the linker doesn't know your code execution and therefore includes all conditional function calls.  For example, the function mcaspMdDeleteChan is part of the IOM function table but may never get called.  The linker will put this in the application because it's referenced in the code even though it never gets executed.

    For the function mcaspMdDeleteChan, I replaced it with IOM_DELETECHANNOTIMPL in the function table and removed the function and all it's unique sub-functions.  That was easy.  But it will be harder for something like mcaspMdControlChan since I don't know which APIs call this function.  This goes back to one of my initial questions:

    Which high-level (e.g. SIO_xxx)  functions call the IOCTL functions?  Would it be possible to eliminate the function "Mcasp_localSubmitIoctl" and the functions it calls?

    Or more specifically, which DSP/BIOS API's in turn call mcaspMdControlChan? If I don't use any of those APIs, and if there are no conditions in my application under which it gets called, I can remove it from the driver as I did with mcaspMdDeleteChan.

    Mike

  • 0 in reply to Brad Griffis
    Expert 1700 points

    Brad Griffis said:

    I had requested the PSP team add an #ifdef statement around all the parameter checking at the beginning of each function.  I think it was called PSP_DISABLE_PARAMETER_CHECKING or something similar.  When you rebuild the code you should make sure in your compiler options to create a defintion (-D) for PSP_DISABLE_PARAMETER_CHECKING or whatever it was called, e.g. -DPSP_DISABLE_PARAMETER_CHECKING.  That will immediately make all that code vanish.

    I tried this and it saved ~250 bytes of code - not really that much considering the PSP GA release 1.20.00 consumed about 75kbytes memory of my application.  It actually would save more than this (maybe 500 bytes) if this were done directly to the PSP release. 

    I used the define in my build which is now quite a bit modified from the original PSP release.  One thing I did was remove the MD functions I don't use in my application ( mcaspMdUnBindDev, mcaspMdDeleteChan, mcaspMdControlChan)- this saved the most code.  These functions also had parameter checking code which was no longer in my modified lib build.

    Mike

  • 0 in reply to E2E_display_name_Mike
    Expert 1700 points

    I've about finished my downsizing of this driver for now.  My application was initially using about 75 kBytes of the Mcasp library.  After doing items 1-3 in my original post and a few other modifications, it seems to work fine and only uses about 36 kBytes.

    Mike

  • 0 in reply to E2E_display_name_Mike
    Expert 1700 points

    One more thing I discovered which reduces code size is to build the library with -mv6400+ instead of -mv6740.  Execution seems to be the same.  It reduced my code size from 25408 to 24352 bytes.  Note I'm still using Debug configuration so optimization is -o0 (e.g. none).

    mcc_mcasp.a674
          CODE ---------------------------------------
                        .text:      25408   0x00006340
          DATA ---------------------------------------
                       .cinit:         60   0x0000003c
                       .const:       5716   0x00001654
                      .switch:         28   0x0000001c
         UDATA ---------------------------------------
                         .bss:          4   0x00000004
                         .far:       5020   0x0000139c
                               ==========   ==========
        LIB TOTAL            :      36236   0x00008d8c

    ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

    mcc_mcasp.a674
          CODE ---------------------------------------
                        .text:      24352   0x00005f20
          DATA ---------------------------------------
                       .cinit:         60   0x0000003c
                       .const:       5716   0x00001654
                      .switch:         28   0x0000001c
         UDATA ---------------------------------------
                         .bss:          4   0x00000004
                         .far:       5020   0x0000139c
                               ==========   ==========
        LIB TOTAL            :      35180   0x0000896c

    Can anyone from TI comment on why this is so?  And is it safe to do this?

    Mike