如何在DDA系列中强制堆堆到DDR？

对于静态分配，您可以使用区域。对于动态分配，我认为链接器自动确定堆，并且不能指定位置。我认为您必须提供您自己的MalCube（）、RealCube（）、For（）等。幸运的是，STDLIB函数是弱的，所以如果您提供这些功能，Ortho等将使用您的版本。我确信您可以在Web上找到一些可以修改的合适的Maloc替换。您可以包括一些启发式算法，这样分配一定大小的RAM，较大的一个到DDR，实际上保持两个堆。



      以下为原文

    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.

我真正想做的是让TCPIP栈使用DDR，并且看起来很容易指定一个不同的Malc Caloc和空闲。



      以下为原文

    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.

DDA芯片和内存管理有没有任何文档，或者未来的计划？现在它看起来像是用户管理的内存。显然，MALOC将不得不知道DDR是否被启用。你知道我能在哪里找到PIC32 MALLC源吗？



      以下为原文

    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?

分配函数我认为调用SBRK（）从OS中获取块（通常是UNIX/Linux，但在这种情况下是裸露的金属垫片），因此您可能可以考虑实现这一点。您可以在“& lt；xc32安装dir & gt；/pic32 lbs/lbicp32/tubs/sBrk.c”中找到Microchip的SBRK（）实现。您可能需要先解压缩LbPIC32源，然后再更新XC32 V1.43。



      以下为原文

    The allocation functions I think call ***rk() 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 ***rk() implementation in "/pic32-libs/libpic32/stubs/***rk.c".  You may need to unzip the libpic32 sources first on XC32 v1.43 or newer.

这真的很疯狂，我们有一个32兆的DDR，并且没有一个微芯片提供管理内存的方法。



      以下为原文

    This really is crazy, that we have a 32mb ddr, and there isn't a Microchip provided way to manage memory.

IIRC如果你自己定义堆部分，链接器就不会创建它，但是Microchip的“有用”扩展有一个阻碍的习惯。在任何情况下，如果你查看了SbRKGyIn（）的来源，你会发现，如果它们可用，它将使用链接器符号MimBrk和OxMax Brk来定义堆开始和限制。



      以下为原文

   
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 _***rk_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.

我正在环顾四周，我看了一下UMMYMALOC，但是它会首先理解它，因为它只支持512K。我可能只是建立了一个池。通过图形演示，看起来所有的DDR RAM访问都是预先定义的，而不是MaloC。



      以下为原文

    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
 
 

TCP/IP堆栈分配一个单独的内存块。也许永远不会回来，你可以用你自己的来代替Malloc。DA芯片是新的，DDR存储器是用于图形的。我认为他们不考虑其他用途。因此，它可以承载您直到编译器赶上，或者TCP堆栈允许静态分配。



      以下为原文

   


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.

我建立了一个基本的池，把MALOC调用改为我自己的，这就像一个冠军。我确实确保了它的0xA8范围内的地址。在TCP/IP模块中有4Mb+的自由。



      以下为原文

    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.

您好，这确实是正确的。DA“显示加速器”旨在作为图形而非连通性设计。当然，你也可以使用它，但是它的目的并不是要让一些低级别的微处理器使用DDR。该意图非常具体地是为多层帧缓冲器和用于GPU分配的图形元素的空间使用DDR。如果您使用图形设计，那么在同一个空间中启用堆也是非常有挑战性的。即使在我们的图形设计中，我们也使用大量的堆来分配CPU所管理的各种元素。这包括尚未发送到DDR的显示的图像、字体和缓存元素。有些客户设计有堆300 K+KB。是的，我们知道一个更正式的内存管理器是一个很好的补充。这会及时到来。但这不是提供的意图。



      以下为原文

    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.
 
 

在我看来，32 MB是一个游戏改变。单芯片DDR提供是相当罕见的，它是一个完美的适合于许多其他事情，而不仅仅是图形。对我来说，另一种选择是一个完整的Linux SoC成本更高，更难安排。



      以下为原文

    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.

嗨，是的，我们知道Linux的潜力，在世界上，你甚至可以找到一个端口就如何做到这一点。然而，这并不是我们试图参与的方向，因为事实上我们有MPU。这并不是说我们不明白这是怎么使用的。我只是想解释目前的目标，使用模型给你。内存管理解决方案很重要，而且会随着时间的推移而出现。即使图形可以受益于此，因为BLIT的GPU分期不是固定的。当然还有许多其他用途，但这仍然不是试图成为具有外部存储器的微处理器。我们的客户非常聪明，毫无疑问，建筑有很多用途。



      以下为原文

    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.