What's Unclear? Tell T.I. ... Updates to, "DriverLib User Guide"

Guru 47910 points

Greetings,

Amit has announced that updates are being prepared for the "DriverLib User Guide."   (well...not really!)

Vendor experts have prepared - yet the voice of user-clients offers a broad perspective - and may serve to enhance and/or speed this effort.

May make sense to attempt to "prioritize" any listing of such updates.     Goal may be, "Most good for the greatest number."

As some (equally critical) gatherings advise, "Speak now - or (forever) hold your peace."

[edit 12:05 CST, 16 May 2015  Title changed from, "Call for User Inputs"]

135 Replies

  • cb1-
    "Speak now - or (forever) hold your peace."

    Ok already - this reporter (instigator in this case) rises to the bait.    (99 first day views - not a single bite - headline writer needs, "talking to.")

    Follows several suggestions to strengthen the "DriverLib User Guide."

    a) Far more detail aimed at, "Care/Handling of the (external, user supplied) analog circuitry."     Again - this is (external) to the MCU - it describes the user's treatment of the analog signals (prior) to their presentation to the MCU!      Too often - as well noted here - user's allow the analog pins to "float" - and then "protest" when ADC readings seem (outside) their expectations.     ADC pins need to be properly connected/terminated - existing ADC "input specs" (rear of the manual) appear too complex for many, here.    Suspect that sample schematics - w/"general" part values - will go far to improve.

    b) uDMA was among the last peripherals added to these MCUs.    And - if memory serves - the written descriptions, number, and variety of (properly) detailed uDMA examples must be increased.     There are many "hooks" and sometimes even the sequence of uDMA set-up/config proves vital - especially when the uDMA manages & coordinates multiple MCU peripherals - running at high speed.     Suggest the "most likely peripherals" to benefit from the uDMA be well represented - w/detailed, application-ready examples.

    c) Interrupts - due to their inherent complexity and demanding requirements - require more detailed description & illustrative examples.     The (usual) requirement to define/detail the interrupt handlers w/in the "start-up" file is too often missed - signalling the need for greater emphasis.     And it cannot hurt to (gently) suggest that the (near) universal trend of placing, "Calls to the UART" w/in interrupt handlers (which should be quickly executed so as not to prove disruptive) should be resisted.     Simple toggle of test Leds far better confirms interrupt entry - w/out over-burdening the program.     (not a word to this guide exists...)

    d) JTAG - though not a "prime MCU feature" - when, "MCU cannot connect" - users are pretty much, "Dead in the water."     Indeed laundry list of, "What to do, now" exists - but forcing frustrated & already delayed users into google or site search - appears not the best/brightest method of advisement.

    I can list more - yet the richest response results from varied User Input - which Amit has invited.     (after just a "bit" of arm twisting)

    Here's a (rare) chance to, "Post your greatest, "DriverLib Update needs."      Pity if your key need is "missed" - which may be prevented - with your brief listing here!

    Should this thread remain, "empty/under-served" - a strong message that, "Users do (not) really care" seems sent - does it not?    Even a quick, single item is likely to "blip" this vendor's radar - this is our chance to gain, "some voice" in vendor's actions...

  • Guru 47910 points

    In reply to cb1_mobile :

    Hi Amit,

    As gleaned from, "Advertising 101" - if readers don't note & respond - change the "Headline!"

    "Monster ate my Tiva" (unfortunately - already taken) so I updated my past, "Call for Updates" w/"Tell T.I."    

    And now note that the "sticky" lost its adhesive properties in that process.      (may not be all bad - response was not what I had wished for/anticipated...perhaps "drift into obscurity" has been earned...)

  • Guru 47910 points

    In reply to cb1:

    Gang,

    Silence deafens - does everyone landing here have absolute mastery/understanding of each/every element of MCU's Bootloader?   

    That one "left open" so that "youse guys" could request.

    It's long said that we, "Get the G'ovt we deserve."    Might a similar fate await this updated DriverLib User Guide - minus any forum-user input?

  • In reply to cb1_mobile :

    I don't know why but I must have a problem with stickies - they are always there so I tend to miss new ones (always overlook them).

    I made some wishes here, not exactly specific to the user guide:
    e2e.ti.com/.../417472

    The driverlib user guide specifically I don't have complaints that I can remember now, it gives info about the functions and that's it.

    What I think is needed is examples and/or application guides/notes.
    I speak of what I've used, can't say (of course) anything about peripherals I rarely/never use.

    The DMA first, I think there is a bit of info lacking. Again not driverlib specific the problem, could use more info in for example the FIFO behavior with the DMA.
    A note about the differences about the TM4c1294 DMA vs the TM4C123 one. How to use the TM4C123 DMA interrupts (DMA done flag is in the DMA registers but it uses the peripheral ISR).
    And some more simple examples for understanding the use of it with the driverlib - could be just good codes to understand like toggle a GPIO with the DMA. Scather-gather I just ran way from that, it like has kinda good (I ran away after a while) info on the datasheet but could use more info directed to application using the driverlib.

    Basically I think that there should be a good guide in migrating from TM4C1294 to TM4C123. There are changes in hardware that can break a code. There are changes that I don't even know why they exist (some were explained to me as improvements later). I think it's a must so a sneaky change doesn't make users pull their hairs out.


    Can't remember more now...


    Luís Afonso

    For more reply options press "Use rich formatting" on the bottom right.

    I have a blog that i am making to help some colleagues with learning Tiva:  https://sites.google.com/site/luiselectronicprojects/home
    I have here now example codes for the Tiva more organized: https://github.com/LuisAfonso95

  • The biggest issue is simply knowledge of its existence. I had to resort to the sage Google to find it and then I probably got the wrong manual.

    I suspect many do not rrealize the manual exists.

    Robert
  • Guru 47910 points

    In reply to Robert Adsett72:

    Indeed Robert - indeed.    Some here have suggested that ALL such data be immediately "clickable" from the red bar - atop this forum.

    That bar holds the (uber) critical, "Blogs, Groups, Videos" - clearly: "MCU data, App Notes, & vital DriverLib Guide" should be there too!

    Unclear, "How, when & why" the obscuring of vital data has resulted - and been (apparently) "cast in stone!"

  • Not manual but the library itself

    (u)int32_t is over used.  Some of the uses should be replaced with other types.  Obvious examples are

    • the SSI interface which should use void * for the data
    • the uart interface, UARTCharGet should return a uint8_t (char if it were restricted to printable characters).  The nonblocking should probably return an int, preferably it should be re-written so that the read byte is not returned via the exception interface.

    There should also probably be more general use of types rather than using the (near) bare compiler types for everything.

    Robert

  • In reply to Robert Adsett:

    I actually like the uint8_t, uint32_t, etc, use of near bare compiler types instead of int (char doesn't really matter it's always the same). THat way I know exactly the size of the variable... Though is mostly due to me using Energia in the past where there are lots of different platforms (plus Arduino).

    But that is just a personal preference :p


    Luís Afonso

    For more reply options press "Use rich formatting" on the bottom right.

    I have a blog that i am making to help some colleagues with learning Tiva:  https://sites.google.com/site/luiselectronicprojects/home
    I have here now example codes for the Tiva more organized: https://github.com/LuisAfonso95

  • Guru 47910 points
    As suggested earlier today by Amit - following is copy/paste for "centralization:"

    You may create a function similar to the FlashUserGet to add the USER_REG2 and USER_REG3. Or you can modify the existing function and recompile the driverlib.

    BTW, that is a good suggestion to add to the existing driver files. I will file the same into the enhancement request

    Regards
    Amit
  • In reply to cb1:

    Hello All,

    Changes to existing function will not be done, since most of them are ROM functions and this will break the continuity of the function in ROM and Flash. Instead functions shall be created to add capabilities.
    The main focus is on the documentation right now.

    Regards
    Amit

    Regards,

    Amit Ashara