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

Guru 47910 points


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

  • In reply to Amit Ashara:


    Can you share the compiler options? The docs refer to the -mpic-register=reg option. That appears to be in there to support the transition from R10 to R9. It looks like R9 is used on Arm Linux, but I can't see any evidence that it is on bare-metal gcc EABI. I can see from disassembling some big functions compiled with gcc 4.6 that its treated as caller-saved. I have no idea where this is set/configured.
  • In reply to R Sexton:

    Hello Robert, Stephen,

    It would take me time to retrieve such data.

    Sorry for the question but I do not understand why there is a sudden surge in this particular topic of ROM functions, unless it has stopped working with certain compilers. Or is it a theoretical scenario of it not working.



    Amit Ashara

  • In reply to Amit Ashara:

    I'm calling the ROM functions from another language using the AAPCS conventions.

    The AAPCS conventions are deliberately ambiguous with regards to R9, the platform register. Linux uses it, it would appear that the existing ROM code doesn't - we don't actually know. Code that I compile with current gcc treats it as callee-saved.

    In the absence of actual documentation, I have no assurances that my code will work when I use it on other parts in the Tiva family or on their successors. The alternative is assuming that the ROM code uses R9 (contrary to other EABI code), in which case I'll need to assume that it's caller-saved.

    The closest thing that I can find is this: www.boost.org/.../arm-linux-aapcs.pdf Thats pretty old. I see commits that suggest R9 gets used by gcc for stack frame checking in recent releases.

    Knowing (ideally from the published docs) the compiler options used to build the ROM code would eliminate this ambiguity.

    Based upon what I can infer from what little documentation is available, R9 must be caller-saved to ensure long-term compatibility.
  • In reply to Amit Ashara:

    After further research: R9 is used when compiling with -fpic. So if the ROM never uses position independent code, R9 is safe.
  • Guru 47910 points

    In reply to Amit Ashara:

    In the attempt to return this thread to its, "More general, broader-based, value/utility" I present the following link:


    Poster f.m. presents a solution which may be generalized - and is sure to prove useful to the "masses."

    While "Updates to "DriverLib" appear, "Not to be in the works" - f.m.'s suggestion deserves broader recital...  (i.e. "here" - at least for now)