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.

learning tivaware c series

Dear seniors,

i am trying to learn how to program tivaware c series and arm cortex-M by both methods ;using the libraries or directly have access to the register, yet i have a very big difficulties to learn as i don't have any ressources(like examples, code), if you can suggest me any good book on which i could rely on it as i want to start with solid basics

thank you

  • Hello Tarik

    TivaWare has examples and there is the following link

    processors.wiki.ti.com/.../Getting_Started_with_the_TIVA™_C_Series_TM4C123G_LaunchPad

    Regards
    Amit
  • Hi Amit, this link i have it,it helps a little bit,however to deep my knoweledge i need more, what do you think about these books of jonathan W valvano and others

    www.amazon.com/.../ref=pd_sim_351_1

    www.amazon.com/.../ref=br_lf_m_b53qptcy22pm797_1_3_ttl

    www.amazon.in/.../B00L9DRAI2
  • Hello Tarik,

    I am not sure on the books, as I have never had a copy and didn't required one (pardon me for my over use of the data manual). I do know other forum members may be able to help you out ( cb1-, Robert, f.m., Chester)

    Regards
    Amit
  • Much of your MCU study - as well as other subjects - will be aided by your developing solid, Investigative skills.   Simply (asking) here - w/out providing much (necesary) personal background - confounds your request - does it not?   We're in the dark as to your tech level - that would prove helpful - don't you think?

    If you've not past MCU experience - in general - ARM MCUs are "not" the place to begin.   Simpler, 8 bit devices prove far faster/easier to master - and build skills & familiarity - which then leads to your "appreciation" of ARM.

    As an example - few "climbers" choose Kilimanjaro as their first event.   Care, thought & consideration should dictate your "climb" - not "market-hype."   (again - unstated is how/why you've chosen ARM...)

    I could provide you our firm's list - but would it not serve you better to devise your own "investigative plan" - and present that (here) for comment?   You've asked for resources - yet have provided few inputs to guide hapless helpers...

  • May I recommend Miro Samek's excellent YouTube tutorial, the first lesson of which is called 'Embedded Systems Programming Lesson 0: Getting Started'

    Currently here:

    As a Texas ARM based tutorial better than any book I've seen.

  • May I note that (only) Direct Register AND Assembly code reveal w/in your pasting. Neither are recommended for new users - and often their complexity leads to difficulty for those here - for years.

    Vendor's rich & extensive and long "tried/true/tested" API is clearly preferred by Vendor's Amit - and most all, "forum helpers."

    Indeed you've shown just one small part of the suggested tutorial - yet the "heavy" use of DRM (which is always an adventure & extra-effort) is disturbing.

    As a believer in "KISS" - heavy use of DRM would be, "On the spot" rejected!

    I've yet to visit a successful tech firm where "videos" have substantially replaced books. And "starting" w/an ARM based MCU remains very much a subject of great educational debate...
  • Hello cb1,

    Indeed, API is the preferred route. Even though the DRM continues in the next release, the example is now changed to TivaWare...

    Regards
    Amit
  • Hi Amit,

    Re: examples now changed to TIware - good that.

    Pity that the MCU data manuals (STILL!) make not one mention of the API - and illustrate all code via DRM. (Not good - that!)
  • Hello cb1,

    I think the MCU Manual does not do that for a lot of peripherals and instead the Peripheral DriverLib User Guide does that.

    Regards
    Amit
  • Hi Amit,

    Your writing signals that I should have been more detailed in my writing.

    I seek to emphasize the fact that w/in each/every MCU data-sheet/manual I've read - not a single mention of your powerful API appears!   Not one!  Can that be - at all - good?   (unless legally restricted - such cannot be justified!)

    Now here I present a "true copy" from our past LX4F manual:

    "9.1 GPIO Signal Description:

    These signals are configured by clearing the corresponding DEN bit in the GPIO Digital Enable (GPIODEN) register and setting the corresponding AMSEL bit in the GPIO Analog Mode Select (GPIOAMSEL) register.

    The digital alternate hardware functions are enabled by setting the appropriate bit in the GPIO Alternate Function Select (GPIOAFSEL) and GPIODEN registers and configuring the PMCx bit field in the GPIO Port Control (GPIOPCTL) register to the numeric encoding shown in the table below.

    9.2.4 GPIO Commit Control:

    Writes to protected bits of the GPIO Alternate Function Select (GPIOAFSEL) register (see page 652), GPIO Pull Up Select (GPIOPUR) register (see page 658), GPIO Pull-Down Select (GPIOPDR) register (see page 660), and GPIO Digital Enable (GPIODEN) register (see page 663) are not committed to storage unless the GPIO Lock (GPIOLOCK) register (see page 665) has been unlocked and the appropriate bits of the GPIO Commit (GPIOCR) register (see page 666) have been set."

    Note that such writing and direction, "Drives/Herds the user into DRM!"   Does it not?   Not one mention of the short-cut - robust - proven - and highly readable API - is to be seen.   ANYWHERE w/in the 1K+ pages.  And - each/every of those critical Register Settings (above) may be handled far faster/easier and more robustly - via the API!   And "any mention" of the API has - "Left the Building!"


    On reflection - you are correct - the PDL too often falls back upon DRM (suggesting that it may have (originally) been written before or along w/the API.)  Sufficient time (may) now have passed so that the API can assume its "rightful place" - and the DRM herded to "rear of the bus."

  • Hello Tarik,

    I thought I might be able to offer some helpful advice as well. I also recently have been in the process of learning the Tiva C Arm Cortex-M4. I've only been working on it for a couple of months and already feel like I have a pretty good handle on it. The learning curve at the start is a little steep, but once you get more familiar with how the TivaWare libraries work, as well as how to find answers in the various documents and source files, it actually becomes quite fun to work with. I have found that after that initial learning curve, using the TivaWare libraries really accelerates getting the hardware set up and I can get right into working on my application logic. I'm not an experienced engineer and have not been working with MCU for years. I work at a university as a tech for an engineering department. My background before taking that job 2 years ago was IT and networking, as well as studying physics. MCUs were completely new to me, as well as the C programming language. I was only familiar with Java, Python and C#.

    Amit wisely posted the link to the Tiva C Series TM4C123G LaunchPad Workshop:

    processors.wiki.ti.com/.../Getting_Started_with_the_TIVA™_C_Series_TM4C123G_LaunchPad

    This really is a great starting point. It's going to cover some of the initial hurdles involving setting up your workspace in CCS, and is going to hit quite a number of peripherals using the TivaWare Libraries. I would really encourage you to go through the workshop very slowly and not just rush through it. Investigate each part as you do it and try to understand why it works. When it says this or that peripheral is on this or that pin, stop and go into the pinmux utility and look. Try to set up the peripheral using the Pinmux utility as well and see what kind of code it generates. Compare that code with the code in the labs and see what types of calls the Pinmux Utility is going to leave out. After you have completed a lab, see if you can modify it to use a different pin or different instance of the same type of peripheral.

    The pinmux utility can be downloaded here:

    http://www.ti.com/tool/tm4c_pinmux


    Between the pinmux tool, the TivaWare Peripheral Driver Library and the TivaWare source files (mostly the headers but there is some good info in comments in the .c's as well) you should be able to find most information you need. I find myself going into the MCU's actual datasheet rarely, and mostly that's just either read an overview of a module or get block diagrams of a module.

    I would strongly suggest using the TivaWare libraries unless you have a very specific reason not to for a very specific task. If you really want to get to know the registers, then I would suggest working from the top down, as in starting at working in TivaWare, then digging deeper from there. You can find a lot of information by right clicking a TivaWare call and selecting "open declaration." There's a lot of comments in the TivaWare source so this is a good practice to get into anyways. Please note that if the function call starts with ROM_ or MAP_ , delete the ROM_ or MAP_ from the front in order to get to the real library's .h file. Look at the path to the library's .h file and go find the .c file to get even more information. Compare the #define statements that associate friendly names to addresses, and find those register addresses in the MCU's datasheet.

    I don't know of any books for this. I don't think there's going to be any book that you can read that will leave you feeling comfortable with working on this MCU. You really have to just dig in. I find it a rather fun MCU to use now that I have become familiar with it.

    Some ideas:

    Take the workshop's Lab 5 (ADC) lab, and try to set it up to read from an external pin. Connect a potentiometer to that pin (mind the voltage) and read the value. use a watch expression in the debugger at first, then maybe threshold the values and set the color of the RGB LED based on what you set the potentiometer to.

    Take the workshop's Lab 15 (PWM generation) and feed that into some other pin and try to read the pulse width, frequency and other common tasks. Figure out how to turn that value into a meaningful value. Set up an additional PWM output that you modulate based on the other PWM signal that you are reading.

    Set up 2 SSI (SPI) ports, one as a master and the other a slave. Wire them together appropriately, and then send data out one and into the other. There is an example for this one somewhere. Modify the clock speeds. Find more complex ways to either generate the data you send, or process the data you receive.

    Most importantly, don't try to complete these learning exercises quickly or by just trying to find code that you can copy and paste. Sure, your're going to copy and paste some code, but take your time and really understand what you are doing. The first couple of projects are the toughest no matter what they are. After that its really not bad at all.

    Cheers and Happy Coding
    Dennis

  • @ Dennis,

    We find yours a very thoughtful & caring reply - well done. Your caution re: "Speed Reading/Coding/Cut-Pasting" makes great sense - would that more would adopt.

    Our poster has gone quiet for more than two weeks now - don't take it personally if he does not respond. (others here note & appreciate your work...)

  • I agree with cb1,

    I've seen as an argument to "why do I use DRM?": "well I learn a lot on how to use the MCU from the datasheet so..."
    At least some mentions, would be nice. Sometimes the biggest problem (and it's a big one here) is knowing what are the tools and info available.
  • Hello Luis,

    Well - your presence here - before Christmas - wins cb1 "Big Bucks" from staff.   (who thought Luis was, "outta here" till 2016.)  

    The problem you mention (really) is one of developing broad & good, "Investigatory Skills" - is it not?   Matters not if its programming, or math, business or law - you must learn to efficiently seek & "hunt/gather" that which you need.   (few cave ancestors cried, "Don't Work" (i.e. "carved upon the cave (forum) wall") when their arrows missed the deer!)   Times have changed - have they not?

    Odds are high this poster's, "Left the building."   Your (re-entry) proves a far greater PLUS - many here - would agree!   Good to have you back - even for short time.

  • I was enjoying the fact that I don't have to do anything for the rest of the week and before sleeping I decided to visit the forum. Lucky I guess :p

    I find that 90% of my colleagues have troubles getting accustomed to the documentation, finding the info and working with the tool chain, the last one can be a consequence of the first 2 which can also be a consequence of hardships in using the parts.

    So I usually now try to teach to read and search or else I always get the same questions.

    I keep telling them "googling" is a skill and to not disregard it (nor it's just typing a phrase, click first link, good enough or give up), and there is so many times that I've been asked something because I answer it fast - I didn't know the answer, I just searched.

    Organizing info is also so important! A simple thing like just bookmarks in a PDF. It turns a hard to move around book into something so much better. I usually now organize a file with the info I gather as I need (with a initial quick and general search) - with (an attempt at) a good tittle and a small phrase if needed. All this of course required a search previously - so I find this habit of organizing where what you need is at.  

    So I am a big fan of the TI Cloud, specifically for the resource explorer.
    But, I may be wrong, but when going from most TM4C pages, the resource explorer is a bit hidden? I think you should have this on the top page of every launchpad! It should be in the top and pretty clear on the Tivaware page.
    I open this, open the TM4C tab and "devices", dev tools,  libraries, tools and ti designs pop right in my face. I hope libraries and boom, driver library (among all the others). Open it - there user guide!
    All the examples are also easy to find. Open any  dev board (this one is a bit weird, maybe a top file with handy "you are here" kinda explanation map).
    App notes for each device are right there too!

    Yea I'm a fan. It organizes the info, it's all there and it's not overwhelmingly full as a page is (much easier to navigate and find what you need). This is my opinion. But since it's a bit hidden for tm4c users... it fails

    I'm gonna have 4 finals in a period of 2 weeks - well, in 15 days span so it will be a really short stay. (yay - guess who will be the whole holidays studying?).

  • Luis - once again you are FAR ahead of cb1 (and staff). I did not know of "resource explorer!" Again & again - here & at other ARM vendors - I find "key/critical" data hidden - or buried - or placed where one would not "normally" search.

    Recall the "delight" w/PF0/PD7. If the reader is really alert - and combs the GPIO section - he/she (may) note that. And many would "move on" even after so noting. That's just one example of POOR PROMOTION! The resource explorer escaped me - and I've been here forever.

    The bright red bar - across the top of this forum - alerts/pounds us w/the uber critical, "Blogs, Groups, Videos" - NOT ONE WORD describing, "Resource Explorer!" Can that make sense? Ever? (I suspect that's vendor's "style rule" - Long Live Style - delay, frustration and inefficiency are the lot of (most all) users.

    I do not know how to better call this, "misuse of prime ocean property" (that bright red bar) to forum management's attention! I've pounded here for years - we work w/multiple ARM vendors - so cannot "dig as deep as Luis, here" but should we have to? How possibly can, "Blogs, Groups & Videos" be granted PRIME SPACE - and "Resource Explorer" (stashed) in a moldy basement? Management (here) somehow believes that makes sense. I do not!
  • HI Dennis,
    That was a great post from you. Thank you for help !