• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 312 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.

Want to use alternate heap manager when using Legacy BIOS support

David Negro
Intellectual 330 points
Other Parts Discussed in Thread: SYSBIOS

Hello,

I am using BIOS version 6.34 but I am using support for legacy API as outlined in http://www.ti.com/lit/an/spraas7g/spraas7g.pdf

For example we are using the DSP/BIOS v5 MEM_ interface by including the following line in our configuration:

var MEM = xdc.useModule('ti.bios.MEM');

We have found that using the ti.sysbios.heaps.HeapMem memory manager our heap becomes fragmented and our runtime slows down.  With DSP/BIOS v5 we over-rode the MEM_ API with an alternate memory manager which worked quite well.  For SysBIOS with legacy support I was hoping to use an alternate memory manager by changing "Memory.defaultHeapInstance".  However, when I did this I got an error by the XDC package tools:

error: xdc.cfg.Program: "C:/ti/bios_6_34_00_12/packages/ti/bios/package.xs", line 436: ti.bios : MEM.MALLOCSEG and MEM.BIOSOBJSEG are not set. Both these parameters have to be set or Memory.defaultHeapInstance must be set to a HeapMem instance

I am hoping that someone can provide me with the best solution that will allow me to continue to use the legacy BIOS support but use an alternate heap manager.  If I remove all usage of of the MEM_* usage in our code will that be sufficient, or will the other legacy APIs like SEM_ use the MEM_ API?  Does anyone have any suggestions?

Thanks.

  • 0
    TI__Mastermind 37985 points

    David,
    if you use the module 'ti.bios.MEM' then you have to configure it completely and you should not try to configure both BSP/BIOS5 MEM and SYS/BIOS6 Memory. Just use one of them.

    What did you do to use an alternative memory manager in DSP/BIOS 5? You said it worked quite well, does it mean you also redirected internal BIOS calls to MEM API to your memory manager?

  • 0 in reply to Sasha Slijepcevic
    Intellectual 330 points

    To use a different heap manager for BIOS 5 we implemented all the MEM_ symbols and linked against our version.  It was a solution, but not a very clean one.  With BIOS 6 we can easily change the heap manager by changing Memory.defaultHeapInstance and that has worked quite well.  For this other project which hasn't fully been migrated to BIOS 6 yet we were also hoping to change the default heap but we ran into the issues I reported in my first post.  Given that this doesn't appear to be supported I could try and implement my own version of ti.sysbios.heaps.HeapMem (yuck), or more likely is that I will accelerate our migration of our code base from BIOS 5 to BIOS 6.

    Regards,

    -David

  • 0 in reply to David Negro
    TI__Mastermind 37985 points

    I think I understand what are you trying to do, but I still am not sure why would you even need to use the module MEM in your config script. What happens if you remove
    xdc.useModule('ti.bios.MEM');
    from your CFG script and you use your heap manager as Memory.defaultHeapInstance?