Can Tivaware UARTprintf() C.lib memory heap space available status.

Hi Rafael,

Thanks for info and if you check the C.lib compiler tools there is a lot of heap manipulation classes found in Algorithm.

Seems that SYSBIOS tools can watch the heap in real time graphs but we are (NO_SYS  1). LWIP 1.4.1 allows heap from (mem.c) and the debug stats can be displayed like shown below.

That ability to display the heap goes away when setting LWIP to use a C.lib heap.

MEM HEAP
avail: 65536
used: 12940
max: 17148
err: 0

Hi Rafael,

Notice a typo in Wiki page stating the Heap is used for (printf) when it is typically the stack used for (printf)? That is in the actual text it states explicitly the Stack and no heap. The default on the IOT project code was heap=0, stack=4096+512. Have been running the Stack=8096 for past high speed printf (1024 char/sec) which was recently replaced by USBprinf smokes at 56kbps average speed using modified Bulk USB device for text display.  

BTW: This is how LWIP gathers Heap info for printf and replacing (mem) with symbol (.sysmem) didn't work yet the build was clean.

 Seeminly there is a hidden variable tracing the heaps real time value (symbol) we can replace (mem)?

(stats.c)

#if MEM_STATS
 lwip_stats.mem.name = "MEM";
#endif /* MEM_STATS */

#if MEM_STATS 
void
stats_display_mem(struct stats_mem *mem, const char *name)
{
  LWIP_PLATFORM_DIAG(("\nMEM %s\n\t", name));
  LWIP_PLATFORM_DIAG(("avail: %"U32_F"\n\t", (u32_t)mem->avail)); 
  LWIP_PLATFORM_DIAG(("used: %"U32_F"\n\t", (u32_t)mem->used)); 
  LWIP_PLATFORM_DIAG(("max: %"U32_F"\n\t", (u32_t)mem->max)); 
  LWIP_PLATFORM_DIAG(("err: %"U32_F"\n", (u32_t)mem->err));
}

(stats.h)

#if MEM_STATS
#define MEM_STATS_AVAIL(x, y) lwip_stats.mem.x = y
#define MEM_STATS_INC(x) STATS_INC(mem.x)
#define MEM_STATS_INC_USED(x, y) STATS_INC_USED(mem, y)
#define MEM_STATS_DEC_USED(x, y) lwip_stats.mem.x -= y
#define MEM_STATS_DISPLAY() stats_display_mem(&lwip_stats.mem, "HEAP")

Hi,

Sorry, I had to take a closer look at the LWIP code before replying, thus the delay.

The LWIP is built on top of our Runtime Support library (RTS) but, as you noticed, implements a high level heap management that is unavailable in our RTS. In this case, I suggest migrating the <mem.c> and its dependencies if you require this functionality in your project.

BP101 said:

Notice a typo in Wiki page stating the Heap is used for (printf) when it is typically the stack used for (printf)?

I am not 100% sure what you mean by that. Console I/O functions such as printf() require heap (and stack as well).

Regards,

Rafael

Hi Rafael,

Figured that might be your answer about the Clib heap monitor after I did some further research on the subject.

>I am not 100% sure what you mean by that. Console I/O functions such as printf() require heap (and stack as well).

That is my point - the main wiki page overview states heap required for printf nothing about stack and the back ground text then states Stack is required with no mention of the heap. Some members in the Tiva forum miscommunicated the same belief of the Stack being necessary for printf no mention of heap. The QS-IOT project import into CCS has (0) C.lib heap and 4096 stack yet has LWIP heap.

Question of the day, does or can printf use the LWIP heap built from (mem.c)?

Hi,

BP101 said:

That is my point - the main wiki page overview states heap required for printf nothing about stack and the back ground text then states Stack is required with no mention of the heap.

I am not 100% sure what you mean by "main wiki page" and "back ground text", but the linked wiki page talks about the need to allocate heap for printf() and probably assumes that, talking about "C" code, the need for stack allocation is a given. At the bottom of the page there is a link that I should have probably sent as well (check sections 2.3 and 2.4 of this page).

BP101 said:

Some members in the Tiva forum miscommunicated the same belief of the Stack being necessary for printf no mention of heap. The QS-IOT project import into CCS has (0) C.lib heap and 4096 stack yet has LWIP heap.

Do you have links to threads that talk about this? Given that heap is not allocated, I assume the QS-IOT does not use the standard printf() but perhaps its own implementation.
 

BP101 said:

Question of the day, does or can printf use the LWIP heap built from (mem.c)?

Not without heavily modifying the routines of the core RTS library.

Regards,

Rafael

Hi Rafael,

No links from long past discussion. A member just today posted TM4C (Amit's domain) similar belief that both Stack and Heap are required or we get no output from UARTprintf. I remain spectacle heap is always needed for reasons put forth.

Might be the qs-iot  UARTpirntf() (uartstdio.c) can have a buffered mode in TM4c Tivaware driverlib.  So it may not require heap or is using the LWIP heap. Might try the XML break out at some future time and today set Clib heap 4096 byes for good measure though rather not be wasteful with SRAM if the buffer is removing the need for heap?

Also seem to recall the MPS430 has some restriction in Sysbios RFS heap graphs and discussion of printf in the wiki threads via CCS5.4 help index. Perhaps the heap and UARTprintf has more to do with hardware than software and the heap is no longer a temp storage median for the TM4c1294 UART.

Read the top wiki link again and the heap subject link on that page leads to another page with no heap subject info, likely an incorrect URL.

There a predefined symbol (UART_BUFFERED) in the project to assert the buffer during build.

//*****************************************************************************
//
// If built for buffered operation, the following labels define the sizes of
// the transmit and receive buffers respectively.
//
//*****************************************************************************
#ifdef UART_BUFFERED
#ifndef UART_RX_BUFFER_SIZE
#define UART_RX_BUFFER_SIZE     128
#endif
#ifndef UART_TX_BUFFER_SIZE
#define UART_TX_BUFFER_SIZE     1024
#endif
#endif