• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 127 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.

AM263P4: SDK Fixes Suggestions

Carl Mattatall
Prodigy 40 points

Part Number: AM263P4

  1. Shared memory writer API should have options to put a character OR buffer. Ideally we would have both APIs
void DebugP_shmLogWriterPutChar(char character);
int DebugP_shmLogWriterPutBuf(const char* buf, uint16_t num_bytes);


2. The `DebugP_shmLogRead` API should be configurable to yield after a certain number of log entries are processed. Suggestion to put a field inside `DebugP_ShmLogReaderCtrl`

3. The DebugPShmWriter API should be configurable to disable (OR configure) the log message prelude. Without this it is impossible to create machine-parseable structured logs e.g. JSON/CBOR
 
4. There appears to be an off-by-1 bug between the line buf sizes in `DebugP_shmLogReader.c` and  the internal buffer of `DebugP_shmLogWriterPutChar`

If you think these are useful, I would be happy to put up PRs for these changes on https://github.com/TexasInstruments/mcupsdk-core

  • 0
    TI__Mastermind 19202 points

    HI Carl,

    Thanks for the above suggestions and reporting the bugs that you found, let me discuss this internally with the team and get back to you.

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    TI__Mastermind 19202 points

    Hi Carl,

    1.On 1, if I understand correctly, calling DebugP_shmLogWriterPutChar required number of times should yield the same result right? Do you see any performance bottlenecks as well. Do you expect a huge performance bottleneck here? I have conveyed this to the SDK team, but im not sure if this would be accepted as a valid bug since at higher optimization levels, the difference in performance should be minimal/none. Will file a bug as the discussion proceeds.

    2. JIRA filed: https://jira.itg.ti.com/browse/MCUSDK-15062 (internal tracking link)

    3. JIRA filed: https://jira.itg.ti.com/browse/MCUSDK-15061 (internal tracking link)

    4. Bug filed: https://jira.itg.ti.com/browse/MCUSDK-15060 (internal tracking link)

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    Prodigy 40 points

    Thank you very much for items 2,3, and 4

    For item 1 - If SDK team decides not a priority that is totally up to you guys.

    However, I want to be very clear that the performence even on -O3 is quite significant.

    Compilers will not optimize across TU boundaries.

    These APIs are meant to be used for logging/troubleshooting and should be as lightweight as possible. Copying from a user buffer into an SDK-internal buffer and incurring a stack-frame push/pop FOR EVERY SINGE BYTE is absolutely not something the compiler will be able to optimize at call sites. 

    As an example, please see below.

    This code below will MOST certainly not be optimized to consolidate characters into string literals or char/uint8_t buffers. Evidence On Compiler Explorer. Even on O3 you will see the 5 stackframe push/pops versus a single one.

    extern void DebugP_shmemPutchar(char c);

// Original function
void User_writeMessage() {
    DebugP_shmemPutchar('h');
    DebugP_shmemPutchar('e');
    DebugP_shmemPutchar('l');
    DebugP_shmemPutchar('l');
    DebugP_shmemPutchar('o');
    DebugP_shmemPutchar('\n');
    DebugP_shmemPutchar('\0');
}

// WILL __absolutely__ not be optimized to
void User_writeMessage() {
    const char* message = "hello\n";
    DebugP_shmemPutBuf(message, sizeof(message));
}


    Obviously a real world example will more likely have FUNCTION(uint8_t*fmt, vargs args) or something so the example code is just to prove the point.

  • 0 in reply to Carl Mattatall
    TI__Mastermind 19202 points

    Hi Carl,

    Thanks for the detailed explanation, I will take this further with the team internally, I have filed a requirement for the above as well, thanks.

    Regards,
    Shaunak