TM4C123GH6PM: What is the origin of "SYSCTL" and "->" in a statement like SYSCTL->RCC = (SYSCTL->RCC & 0xF83FFFFF) | 0x800 ;

May I provide an observation - and then make a recommendation - intended to, "Speed, Ease & Enhance" your MCU "learning" (first) - later your mastery.

Twice now you have seized upon (relatively) minor - and/or obscure - MCU details.    (bit-band arrived earlier)

Is it not likely - that by questioning "each/every" (new for you) detail - your understanding will be fragmented, delayed, and inefficient?    (that's the belief of my small, reasonably successful, tech firm & others)

Might an alternative method - which may (more naturally) answer many such "MCU details" - prove better?     Your combined read of the MCU manual, the "User Guide to the Peripheral Drivers" and the (many) vendor supplied, code examples (found @ "peripherals/examples") - all "Open & At the Ready" - WHILE you run the vendor supplied code examples - has proved - by far - the top learning vehicle @ my firm!   (and others)

It is likely "too early" for you to note the "relative importance" of MCU minutia.     Would it not prove more efficient to (instead) "piggy-back" upon the efforts of this vendor (they ARE the most skilled - and interested in your success) - which are substantially "MCU Peripheral based" - and seek your active participation via "EXAMPLE" code entry - code flow - and code execution?     This vendor's API is extensive, detailed, greatly "tried/true/tested" and the "occurrence" of "new/strange" concepts or descriptions - tend to be noted - and explained.   (i.e. Number of such "new item," (mentions/occurrences) usually will reflect their importance)

My attempt here is to offer a different (improved) route - yet to your same - successful destination...

I must "protest" the apparent YANK of my earlier post!

Amit has long urged against DRM - has gone so far as to note that DRM examples are being eliminated. Post immediately above this one "invites" a new poster into the DRM Swamp!

Vendor inconsistency does not convey a strong sense of organization - and if not identified & presented here - where better?

Staff have programmed (other) than a, "wide counter" to capture the "duration" of this post's existence...

Thank you, Bruno - and all 3 of us have invested time/effort.

Not so sure about, "all on the same page" though.    I see the poster - while clever & motivated - having his learning efficiency "held hostage" to "interesting" - yet not "uber-critical" nor (even) mainstream, MCU issues.    

As time/effort are finite - time spent (pardon) "off in the weeds" must subtract from that time available for, "serious, focused & progressive" learning.   (does not stem from keywords!)

Having attended many such college level courses - and having "adjunct instructed a few" - learning via "Keywords" (no matter how enticing) is not famed as an efficient learning mechanism.    Poster of course is free to accept/reject this observation/recommendation - yet the "trend" was well noted - and I cannot believe it serves this poster's (nor others') best interest...    And that - just may - warrant my comment...

Keith,

The way I see it: registers are there, and must be comprehended by whoever deals with MCU's. They are a huge collection of switches, turning features on or off - and the features are quite complex and interlocked, raising the need for lots of those "configuration switches".

BUT there is no need to turn on or off every switch separately in one's code, because vendor provides something that resembles more to English (or to human language, for what is worth), that somehow can execute "ProperlySetAllSwitchedRequiredForTimerAToWork();". That's what driver libraries (TivaWare) is about.

SYSCTL is indeed a MACRO (a nickname) for another variable in that code... John's example of pwm_servo shows it being used - but not being declared. Someone just had the hard work of slicing one System Control register into lots of little pieces, each piece with a name like RCGCGPIO, RCC and others. But all these things have to be mapped somewhere. If you change the part number, chances are the mapping no longer works for you.

Tivaware is "closer" to solving that - at least, of course, while you remain using this vendor's family of products - for once you define the PART you are using, the affected registers inside any Tivaware function automagically point to the right place. And they are easier to human eyes to be read. Still, don't dream too much - I wonder if any English teacher will comprehend something like:

ADCSequenceConfigure(ADC0_BASE, 1, ADC_TRIGGER_PROCESSOR, 0);
ADCSequenceStepConfigure(ADC0_BASE, 1, 0, ADC_CTL_TS); 
ADCSequenceStepConfigure(ADC0_BASE, 1, 1, ADC_CTL_TS | ADC_CTL_IE | ADC_CTL_END);
ADCSequenceEnable(ADC0_BASE, 1);

DRM? Try to configure the ADC with registers - your code will become an unreadable havoc, even if it works.

Cheers

Bruno

Ha ha,

I think I'm weakening, but at least I found one other person asking a similar question back in 2009 LOL:

http://www.keil.com/forum/15726/          Apart from that I can find zippo on the matter.

It is really irritating me, that I cannot find a plain forward explanation for where the heck that SYSCTL is declared, or for that matter all the other macros that precede "->" in the code examples I've seen. But I guess it's time to let it go and give Tivaware more attention.

Heck, if I still want to punish myself I can always go back to DRM learning after I've got something real happening using Tivaware.

Thanks for all the input everyone.

Keith.

Keith,

I don't want to get into the debate on direct register writes, but I also don't want to imply that there is anything hidden or secret. The example code from the book you sited was for an older part and used an include file that I do not have. However, I can make a very good guess at what that code was doing.

SYSCTL was defined as a pointer to a structure with an address equal to the base address of the control registers:

typedef volatile struct systemBase
{
    uint32 DID0_R;                 /* 0x0000 */
    ...
} systemBASE_t;

#define SYSCTL ((systemBASE_t *)0x400FE000)

Then the value "SYSCTL->RCC" would evaluate to the RCC register at address 0x400FE060

The current TivaWare header files define the register differently:

#define SYSCTL_RCC_R            (*((volatile uint32_t *)0x400FE060))

The example you saw:

SYSCTL->RCC = (SYSCTL->RCC & 0xF83FFFFF) | 0x800 ;

Reads the register RCC at address 0x400FE060, ANDs the value read with 0xF83FFFFF, ORs the result with  0x800 and then writes that result back to the RCC register.

Perhaps this detailed explanation will make the point even stronger why we encourage using the TivaWare API instead of doing direct register writes. At least I find the following function call much easier to understand even without comments:

    SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN |
                   SYSCTL_XTAL_16MHZ);

Firm/I have that exact book - and pgs. 315, 316 reveal - almost exactly as Bob notes:    (I'd scan it - yet the background is dark grey - contrast poor)

SYSCTRL - by itself - is never defined nor referenced.    And - (always) all such "SYSCTRL" operations employ "assignments" (=) never pointers!   (w/in my book)

#define SYSCTRL_RCC *((volatile unsigned long *)(0x400FE060))
#define SYSCTRL_RIS *((volatile unsigned long *)(0x400FE050))
#define SYSCTRL_RCGC1 *((volatile unsigned long *)(0x400FE104))
#define SYSCTRL_RCGC2 *((volatile unsigned long *)(0x400FE108))

There then follow 5 operations upon "SYSCTRL_RCC."   Our poster listed one - Bob detailed - the others cause my fingers to stiffen, "fall from the home row."

Such was the DRM implementation of, "hello.c" - which outputs to the UART as listed w/in Joseph Yiu's, "Definitive Guide to ARM CORTEX-M3."  (2nd edition)

As vendor's Bob well noted - the API call to SysCtlClockSet() - is SO much more user friendly, understandable and likely to succeed.
I'm unable to report upon the number of, "leaps from tall buildings, wrist slashings, or single-car fatalities" - resulting from this foray into DRM...