AnsweredHot!MZ DA heap location

Author
friesen
Super Member
  • Total Posts : 1850
  • Reward points : 0
  • Joined: 2008/05/08 05:23:35
  • Location: Indiana, USA
  • Status: offline
2017/07/12 14:35:47 (permalink)
0

MZ DA heap location

How would one go about forcing the heap location to DDR in the DA series?
 
Is it going to take linker mods, or is this the wrong way to go about it?

Erik Friesen
#1
simong123
Lab Member No. 003
  • Total Posts : 1172
  • Reward points : 0
  • Joined: 2012/02/07 18:21:03
  • Location: Future Gadget Lab (UK Branch)
  • Status: online
Re: MZ DA heap location 2017/07/12 16:19:52 (permalink)
3 (1)
For static allocation you can use regions.
For dynamic allocation, I think the linker determines the heap automagically, and it's location cannot be specified. I think you will have to supply your supply your own malloc(), realloc(), free() etc. Fortunately the stdlib functions are weak, so if you supply these functions yourself Harmony etc. will use your version. I'm sure you can find some suitable malloc replacements on the web which can be modified.
You might include some heuristics such that allocations < a certain size go to RAM, larger ones to DDR, in effect maintaining two heaps.
#2
friesen
Super Member
  • Total Posts : 1850
  • Reward points : 0
  • Joined: 2008/05/08 05:23:35
  • Location: Indiana, USA
  • Status: offline
Re: MZ DA heap location 2017/07/12 18:48:48 (permalink)
0
Really what I am trying to do is have the tcpip stack use ddr, and it appears easy enough to specify a different malloc calloc and free.

Erik Friesen
#3
friesen
Super Member
  • Total Posts : 1850
  • Reward points : 0
  • Joined: 2008/05/08 05:23:35
  • Location: Indiana, USA
  • Status: offline
Re: MZ DA heap location 2017/07/14 13:06:14 (permalink)
3 (1)
Are there any docs anywhere, or any future plans for the DA chip and memory management?  Pretty much right now it looks like user managed memory.  It seems obvious that malloc is going to have to idea whether or not ddr is enabled.  Any idea where I could find pic32 malloc source?

Erik Friesen
#4
jdeguire
Super Member
  • Total Posts : 366
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: MZ DA heap location 2017/07/17 06:04:25 (permalink)
0
The allocation functions I think call sbrk() to get blocks from the OS (normally Unix/Linux, but a bare metal shim in this case), so you might be able to look into implementing that instead.  You can find Microchip's sbrk() implementation in "<xc32 install dir>/pic32-libs/libpic32/stubs/sbrk.c".  You may need to unzip the libpic32 sources first on XC32 v1.43 or newer.
#5
friesen
Super Member
  • Total Posts : 1850
  • Reward points : 0
  • Joined: 2008/05/08 05:23:35
  • Location: Indiana, USA
  • Status: offline
Re: MZ DA heap location 2017/08/23 09:14:00 (permalink)
0
This really is crazy, that we have a 32mb ddr, and there isn't a Microchip provided way to manage memory.

Erik Friesen
#6
andersm
Super Member
  • Total Posts : 2334
  • Reward points : 0
  • Joined: 2012/10/07 14:57:44
  • Location: 0
  • Status: offline
Re: MZ DA heap location 2017/08/23 09:55:24 (permalink)
3 (1)
simong123For dynamic allocation, I think the linker determines the heap automagically, and it's location cannot be specified.

IIRC if you define the heap section yourself, the linker will not create it, but Microchip's "helpful" extensions have a habit of getting in the way. In any case, if you look at the source of _sbrk_init() you'll see that if they're available it'll use the linker symbols _minbrk and _maxbrk to define the heap start and limit.
#7
friesen
Super Member
  • Total Posts : 1850
  • Reward points : 0
  • Joined: 2008/05/08 05:23:35
  • Location: Indiana, USA
  • Status: offline
Re: MZ DA heap location 2017/08/23 10:26:31 (permalink)
0
I am looking around yet, I took a look at umm_malloc, but it'll take understanding it first, as out of the box it only supports 512K.  I may just set up a pool too.
 
Looking through the graphics demo, it seems all ddr ram access is predefined rather than malloc'd
 
 

Erik Friesen
#8
NKurzman
A Guy on the Net
  • Total Posts : 15521
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: offline
Re: MZ DA heap location 2017/08/23 10:41:26 (permalink) ☼ Best Answerby MikeinAZ 2017/08/25 14:12:47
3 (1)
friesen
Really what I am trying to do is have the tcpip stack use ddr, and it appears easy enough to specify a different malloc calloc and free.



The TCP/IP stack allocates a single chunk of Memory.  And May never return it.
You can replace just that Malloc with your own.  The DA chips are new and the DDR memory was for graphics.  I do not think they thought about other uses.  SO that may carry you until the compiler catches up, or the TCP Stack allows a static allocation.
#9
friesen
Super Member
  • Total Posts : 1850
  • Reward points : 0
  • Joined: 2008/05/08 05:23:35
  • Location: Indiana, USA
  • Status: offline
Re: MZ DA heap location 2017/08/25 05:17:31 (permalink)
4 (1)
I built a basic pool, changed the malloc calls to my own, and this works like a champ.  I did make sure to feed it uncached 0xA8 range of addresses.  There is freedom in 4mb+ for the tcp/ip module.

Erik Friesen
#10
MikeinAZ
Administrator
  • Total Posts : 280
  • Reward points : 0
  • Joined: 2014/06/03 07:25:32
  • Location: Chandler, AZ
  • Status: offline
Re: MZ DA heap location 2017/08/25 14:17:11 (permalink)
3 (1)
Hello,
 
This is really correct.  The DA "display accelerator" is intended as a graphic and not connectivity design.  Use it as you wish of course, but the intent was not to enable some low level micro processor with DDR.  The intent very specifically is to use the DDR for the multi-layer frame buffer and space for the GPU allocated graphic elements.  If you are using the design with graphics it would be quite challenging to also enable the heap in the same space.
 
Even in our graphics design, we use a large amount of heap for allocation of various elements managed by the CPU.  This includes rendered images, fonts and cached elements of the display not yet shipped to the DDR.  Some customer designs have heap 300K+ KB.
 
Yes, we are aware that a more formal memory manager would be a good addition.  This will come in time.  But that was not the intent of the offering.
 
 
#11
friesen
Super Member
  • Total Posts : 1850
  • Reward points : 0
  • Joined: 2008/05/08 05:23:35
  • Location: Indiana, USA
  • Status: offline
Re: MZ DA heap location 2017/08/25 14:47:25 (permalink)
3 (1)
In my opinion, 32mb is a game changer though.  A single chip DDR offering is rather rare, and is a perfect fit for a lot of other things than just graphics.  For me the alternative is a complete linux soc costing much more, and much harder to lay out.

Erik Friesen
#12
MikeinAZ
Administrator
  • Total Posts : 280
  • Reward points : 0
  • Joined: 2014/06/03 07:25:32
  • Location: Chandler, AZ
  • Status: offline
Re: MZ DA heap location 2017/08/25 14:59:19 (permalink)
4.5 (2)
Hi,
 
Yes, we are aware of the Linux potential, and out there in the world you may even find a port on how to do just that.  It is not a direction we are trying to go in with the offering however, since we do in fact have MPUs.  
 
It is not like we don't understand how this can be used.  I am just trying to explain the current target for use model to you.  A memory management solution is important, and will come with time.  Even graphics can benefit from this since the GPU staging for blit is not fixed.  There are of course many other uses.
 
But this is still not trying to be an MPU with external memory.  Our customers are very clever, and there are no doubt many uses for the architecture.
#13
Jump to:
© 2018 APG vNext Commercial Version 4.5