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.

TM4C1294NCPDT: UARTPrintf versus UARTCharPut/Get

Part Number: TM4C1294NCPDT

Folks,

when TivaWare first came out we had the choice of two UART libraries to use.  Either

C:\ti\TivaWare_C_Series-2.1.X\utils\uartstdio.c   (having UARTPrintf) or

C:\ti\TivaWare_C_Series-2.1.X\driverlib\uart.c  (having UARTCharPut and Get etc)

The attraction of UARTPrintf is that it has a S/W  buffer whereas UARTCharPut and UARTCharGet have no S/W buffering.

The problem with uartstdio.c  (containing UARTPrintf ) is that it is only hard coded to work with the first 3 UART port AND it cannot open/buffer more than one UART at a time.  but the TM4C129X has EIGHT UARTs..  To use UARTPrintf on a TM4C129X one needs to modify the library code to add more ports, plus have ONE copy of the library for each UART port (as only one port can be opened at once and the buffering is also not scalable)

  1. Was it intentional or an oversight to exclude a buffered UART Tx and Rx in uart.c  ??
  2. Why wasn't uartstdio.c re-written to support MCUs having more than 3 UARTS ??

UARTStdioConfig is copied below from uartstdio.c  showing how it only handles 3 ports.

void
UARTStdioConfig(uint32_t ui32PortNum, uint32_t ui32Baud, uint32_t ui32SrcClock)
{
    //
    // Check the arguments.
    //
    ASSERT((ui32PortNum == 0) || (ui32PortNum == 1) ||
           (ui32PortNum == 2));

  • Hi Peter,
    The uart.c contains the drivers/API for using the UART module. The uartstdio.c is actually a higher level utility tool to provide simple UART 'console' functions interfacing with the terminal. I think this utility was built in support of the various TivaWare examples to be used on the EVM/LaunchPad boards where UART0/UART1 are mainly used for communication with the console.
  • Hi Charles. thank you , that makes sense. I had incorrectly assumed the uartstdio.c was a library component, instead it is a utility and an example.
    It has been modified and used by my team to work with the TM4C129X MCU . the main downside is that we need one new instance of the uartstdio.c module per UART. e.g. uart0stdio.c , uart1stdio.c etc.

    Given the amount of effort put into UARTPrintf, I think it would be awesome if TI re-wrote uartstdio.c to handle up to 8 UARTs and dynamically allocate buffers as required.
  • You have very well:

    • first described & documented existing API provisions
    • properly identified a 'notable' weakness
    • then proposed a,  'Vendor - when/if/as able' solution

    Pardon - but I'd 'Not hold my breath.'     (note the long/continued existence - of 'Plague-istor' (twins R9/R10 - w/in '123 LPad) - which predictably impale 'so many' - yet remain!)

    Instead - the expansion to include 'Up to 8 UARTs' proves, 'No big deal' - the major issue then - "the Dynamic assignment/allocation of multiple 'UART' buffers!'    To which your team - prefer to 'pass.'

    Now - as your idea is SO SOUND - would not it, 'Draw more talent' - if such 'Dynamic Buffering' - could accommodate 'BEYOND just UARTs?'    

    Is it not true - that  'many MCU Peripheral operations' - would enjoy  benefit - from your 'basic idea?'    Indeed - the 'degree of difficulty' has been raised - but so too - 'the appeal - value - and added performance (even eased coding) - which Dynamic Buffering (implemented skillfully & robustly) is expected to provide.

    Excellent ideas should not 'suffer' from 'self-imposed' limitations!     As noted herein - the, 'Acceptance/Invitation' of Multiple MCU Peripherals - vastly boosts your idea's appeal & benefits - thus 'better igniting & firing' - its speeded launch!

  • cb1_mobile said:
    Excellent ideas should not 'suffer' from 'self-imposed' limitations!     It is believed - as noted herein - that the, 'Acceptance/Invitation' of Multiple MCU Peripherals - significantly propels - your 'neat' base idea...

    Thanks cb1 !   I'm just trying to understand, are you suggesting this buffering idea be implemented by TI for all peripherals ?!    I'd be grateful if it was just for UARTs for now.  I can see that TI might instead suggest we use DMA instead.   I am yet to dive into any DMA implementation, preferring instead something was already written for me with minimal work on my part !

  • Peter John said:
    are you suggesting this buffering idea be implemented by TI for all peripherals

    No - I don't believe that (much) blips vendor's radar.   (my opinion!)   Note - that like you - firm/I are 'outsiders' - although we regularly interact w/multiple vendor personnel.    I cannot recall this subject (ever) arising.

    Peter John said:
    preferring instead something was already written for me with minimal work on my part

    So long as such, 'Already written' manifests sufficient quality, functionality, and breadth - and such 'Desire for 'already written'' - does not become 'over-arching' - then I may agree.

    You have presented the powerful, 'Base Idea' - I've simply attempted to 'Broaden its Appeal' - via (obvious) expansion - so that the case for 'adoption' - is made (even) more compelling...