• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 32 subscribers
  • Views 1268 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.

TM4C123GH6PM: Mapping Between TM4C123x API Functions and Actual Registers?

Bob Jennings
Intellectual 360 points
Part Number: TM4C123GH6PM

I've been having a lot of fun working with my TM4C123 Tiva Launchpad.  Currently I've been learning how to do UART w/ DMA.  It's challenging as there are not many demo's out there other than the udma_demo program.  This program looks to be exactly what I want to learn how to do but my problem with it is that it heavily uses the TM4C123x API functions.  I really prefer to use actual register address manipulation since it allows me to follow along with the TM4C123GH6PM datasheet, reading in detail what every register does and better understand what is going on.

With the udma_demo, I'm having to use the "Tiva C Series TM4C123x ROM User's Guide" (aka SPMU367.pdf) to lookup each API function call and then use that information to figure out what register and bits in that register the function call is using.  This is time consuming and kind of a pain.  There has to be a better way.  Anyone? 

  • 0
    TI__Guru**** 190806 points
    Hi Bob,
    Understand your curiosity on how things work under the API hood. The purpose of the API is to provide a hardware abstraction so it will be easier for people to develop their software rather than spending enormous amount of time understanding every details of the hardware. Per your desire to learn, I will recommend that you use the flash based API rather than the ROM based API. This way you can single step (use the step into button in the debugger) through the API functions and see what code is being executed. At the same time you can view the corresponding registers in the register browser window and see the effect of how the registers are changing with respect to their description in the datasheet.
  • 0 in reply to Charles Tsai
    Intellectual 360 points
    Charles - Hi, thanks for the reply. Good suggestions. I'm not aware of the flash based API. I just tried searching for it in Google and did not find anything. Is there possibly a PDF you can point me to?
  • 0 in reply to Bob Jennings
    TI__Guru**** 190806 points
    Hi Bob,
    For each ROM based API you see in the example there is also an equivalent flash based API. You simply remove the ROM_ prefix and recompile the project again. For example you might have seen ROM_uDMAChannelEnable() in the udma_demo example. Simply remove the ROM_ and it will link the flash based API uDMAChannelEnable() during build.
    Two additional notes I will provide here. First, if you don't care of code optimization, please turn it off in the project property before you rebuild your code. This allows easier debugging of the code. Otherwise, you might see the cursor kind of jumping back and forth as you single step through the code. Secondly, when you step into an API function it may first complain that it is not able to locate the file where the API resides. When this happens, simply click on the 'locate file' button and provide the path to the driverlib. Normally this will be something like c:\ti\TivaWare_C_Series-2.1.4.178\driverlib.
  • 0 in reply to Charles Tsai
    Intellectual 360 points
    Ah, got it. Thank you again!
  • 0 in reply to Bob Jennings
    Guru 117855 points

    May I suggest that in addition to the sound advice provided by vendor's Charles - your study of the, "Peripheral Driver User Guide" should prove of great benefit.

    This 708 page guide greatly details most all of the API functions - explains the necessary "ins/outs" - which simplify & speed your use & exploitation of the API.

    This guide is found w/in TivaWare\docs\ if you've employed (normal) file structure.

    Another key advantage (API enjoys beyond Direct Register or Assembly) is the Code's, "Pre-Testing & Verification" - which (ONLY) exists w/in the API.     in harsh contrast - each/every "Direct Register or ASM" effort - registers as an, "uncharted adventure!"    (indeed you'll have "pride of authorship" - but at great cost - and extreme risk.)     That's not good if you've (any) interest in project efficiency - and few "helpers" here - are willing to make the "deep dive" to assist those who simply "must" use DRM!     (multiple MCU manuals - open WIDE - (always) demanded!)     (and there is - most always - an interesting ball-game on!)

    Charles & I note that (nothing) blocks your  review of key Register (usage & behavior) during the API's (successful) code flow.     Crash/burn - so common under DRM - well exposes MCU Registers - but only (and maybe) at "Herd of Turtle Speed."    Most here "get paid" after project completion & delivery - most clients are, "in a hurry" - the use of the API provides overwhelming advantage!

  • 0 in reply to cb1_mobile
    Intellectual 360 points
    cb1 - Thanks for the insight. I'm just learning so I appreciate insights like this. In my lack of knowledge of the field, I would've thought the API was more of a "dumb-downed" interface to programming the TM4C123x and professionals wouldn't use it, but after reading your post my thoughts have reversed. Do have it right to believe that professionals in the field are more commonly using the API than not? Just curious.
  • 0 in reply to Bob Jennings
    Guru 117855 points

    Thank you for the "Like" Bob - always appreciated. (and we are running "bit low" on vendor's "low thread count T-shirts" and "quality" coffee mugs - (while being (unfairly "moderated") so anything "positive" is a grand plus!)

    Let's examine, "dumb-downed" - you are NOT alone in your (very beginning) assessment!    Is it "dumb" to "piggy-back" upon something: "Vast, (excruciatingly) Detailed (708 pgs.), & Tried - True - Tested?"    And what is the value of Speed and Ease - especially for one "new Bob" - he having just arrived here?

    Most will require tech guidance - sooner rather than later.    Might it be (more) compelling - for your "helpers" - to perform a 2 minute review of the (most) appropriate API functions - or an hour (maybe more) spent "page searching/turning" - valiantly striving to get, "each/every bit w/in ALL key/critical 32 bit, MCU Registers (assuming we can "discover" those, unguided) exactly right?

    As a small tech firm owner - I KNOW that highest profits - by far - are awarded to, "He who arrives "EARLY & properly" to the market!     Can that "first/early to market" EVER result when the team employs DRM (or ASM) exclusively?

    And - is ANY client - anywhere this planet - likely to "pay extra" because our, "Timely delivered, MCU product - was developed (only) via DRM?"

    Might arriving "Late to market" - or NOT at ALL - be a far graver sin?       And - should we ALL not strive to, "Employ every "advantage under the sun" - to drive toward success?"

    Each/every one of these "comparisons" (I prefer the word, Slaughter) stand firmly on the side of the "API" - nowhere is it even close!

    You know that our world is now Global - competition flows from "all corners" - sacrificing development "SPEED & EFFICIENCY" so as to escape the (dreaded) label of, "dumbed-down" - seems not the most "well considered objective!"    And - those w/"time to spare" and/or "insatiable curiosity" may flip MCU manual pages AFTER we have SHIPPED - but NOT during development - THAT would be DUMB!

  • 0
    Guru 13040 points

    Bob,

    Did you come across Luis Afonso's pages on DMA?

    https://sites.google.com/site/luiselectronicprojects/tutorials/tiva-tutorials

    I did learn a lot from it a couple of years ago when starting to deal with DMA.

    Bob Jennings said:
    I really prefer to use actual register address manipulation

    There is an option "somewhere in the middle": use the Tivaware functions for efficiency/reliability/readability, and simply step-into debug each of the lines in it. Most of the times the IDE does not find the source code on the first run, but if you just point to the proper file location, you can see the Tivaware line-by-line just as you do with your own code.

    Regards

    Bruni

  • 0 in reply to Bruno Saraiva
    Guru 117855 points

    Bruno Saraiva said:
    ...you can see the Tivaware line-by-line just as you do with your own code.

    Above quote (lacks) one key/critical "proviso" - should user's (always) "Untested/Unverified" DRM/ASM code be in error - one of the (many) "Fault ISR" code listings - will (instead) greet such user...

    "In the middle" (somewhere) over-states.    Is "each/every" line of the API code to be so reviewed?     If not - which ones - and how is such a determination to be made?    And - will this extra "Time/Effort" not delay project delivery - while (critically) "Breaking the programmer's (proper/required) total focus?"       The program's code flow, the challenge of competing code methods/approaches and the "teasing out" of the optimal, inter-connected, code block(s) MUST remain dominant/central!

    Inspired & efficient code most always results from extreme focus - sweating of program details - and not from "diversions" which, "steer far from course!"     (even when - and especially when - such diversions are "claimed" to be "mid-ship.")

  • 0 in reply to cb1_mobile
    Intellectual 360 points
    Thanks for the additional interesting insights, cb. I probably should've clarified my "dumb downed" statement with a disclaimer that I didn't mean it in a derogatory sense. In my experience with software development there is a general trade-off between power and ease-of-use. As in, when something is easier to use it is less powerful. Or, put another way, when something is easier to use, it has less features or flexibility. As an car analogy - the difference between an automatic transmission and a stick shift.

    Very much appreciate your thoughts though. Every bit of information I get like this helps make the TM4C123 development ecosystem clearer.
  • 0 in reply to Bruno Saraiva
    Intellectual 360 points

    Bruno Saraiva said:

    Did you come across Luis Afonso's pages on DMA?

    https://sites.google.com/site/luiselectronicprojects/tutorials/tiva-tutorials

    No, I did not.  I glanced through it right now and this indeed looks like it would be helpful to study this and try his DMA blinking LED example.   Thank you, Bruno. 

  • 0 in reply to Bob Jennings
    Guru 117855 points

    I much enjoyed your, "auto transmission vs stick shift"analogy - especially as past (and brief) San Francisco resident - with said "stick" AND forced to "stop" (via light or sign) while climbing a (very) steep hill!   And then the car "behind me" - closes to "inches" - from my bumper.   I am told that visits to "mental health" facilities peak - after such episodes - followed quickly by a visit to "auto xmsn. equipped" car dealers.   (i.e. "API" dealers)

    You indeed note, "general trade off, less powerful, less features or flexibility" - all imposed by the API.   Yet - does not the LONGER, "Laundry List of API Assets" - far exceed those (possible/potential) weaknesses (maybe) introduced by the API?     It MUST be, "Net Gain or Loss" which absorbs our focus - is it not?

    No API can fully anticipate (all) user needs - that is true.   Yet - in balance - no, "one thousand page plus" MCU manual can clearly, quickly or efficiently, "Guide every user - to his "exact subject du jour."

    It is my experience that - far and away - the API "AVOIDS" the bulk of your (proper/potential) objections - and spectacularly, "Speeds, Eases & Enhances" MCU project development!    And that - for almost ALL here - should be Goal ONE!

    Clearly your, "dumbed-down" description was "handy" and not "deeply considered."    Instead - was not "dumbed-down"  your, "general, "pre-existing suspicion" - rendered w/out your "reasonable" read/review/use & analysis - of this vendor's API?    That's my (almost) certain take.   (honed by engineering & law-school)

    And a "suspicion"  which I'm quite sure you will (quickly) discard - as you SO benefit (repeatedly) - from (this) vendor's powerful, comprehensive & efficient  API...