EK-TM4C1294XL

Thank you for your answer, I fixed my code and it worked! Here is the important part of my code:

        /* Turn on the LEDS. */
	GPIOPinWrite(GPIO_PORTN_BASE, (GPIO_PIN_0 | GPIO_PIN_1), (GPIO_PIN_0 | GPIO_PIN_1));
			
        /* Delay for a bit. */       
        for(ui32Loop = 0; ui32Loop < 6000000; ui32Loop++)
        {
        }

        /* Turn off the LEDS. */
	GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_0 | GPIO_PIN_1, 0x00);
				
        /* Delay for a bit. */   
        for(ui32Loop = 0; ui32Loop < 6000000; ui32Loop++)
        {
        }

cb1,

As yourself have mentioned before, a useful idea for the third parameter is something like:

#define GPIO_PINS_ON 0xFF   // Drives high any pin mentioned on the 2nd parameter
#define GPIO_PINS_OFF 0x00  // Drives low any pin mentioned on the 2nd parameter

Then use

GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1 | GPIO_PIN_4, GPIO_PINS_ON);

Regards

Bruno

Staff/I have often used, "B3_ON" - "C7_OFF" as (both) a "wrist, energy & time saver."

Endless repetition of "GPIO_PIN_X" actually proves "harder to recognize" than the more elementary "A4_ON." New "defines" must be created (just once) to accommodate this: "Time, Energy & Wrist Saver" technique...

Say Bruno - smart/experienced Biz guy that you are - I'll give you 5:1 odds that "Winner of U.S. Open" tournament - (women) is an American.    (such offers do not occur too often - you know...)

cb1_mobile said:

Well stated - iirc - in the past I received "heat" for such "simplification" - yet your plan here proves a very nice implementation...

Thanks. And in that vein I find myself with a spare minute so an untested, uncompiled, unlinted example that could be used as a starting point. This is only a fragment of what would be necessary for complete working code. There's none of the includes or header definitions that would be needed.

/* Macros for Pin I/O enhancement. There are two goals for these macros
 *  1 - Provide some clarity over the TIVAware functions for the single
 *      pin case and the case where multiple pins are set to the same value.
 *  2 - Reduce the typing load for long arguments.
 *
 * This is completely untested, even by compiling. Its only use is meant 
 * to be as illustration of a possible approach.
 *
 * Since this is only an example some documentation on arguments is missing.
 * Filling those in and testing the result is left as an exercise for the reader :)
 */
 
typedef enum {
        PIN_OFF,
        PIN_ON
    } PIN_STATE;

    /* Change the value of a single pin on a given port. This could be written 
     * as a function instead and there would be advantages to doing so. It 
     * would be more typesafe and there would be no potential risk from
     * multiple evaluation of the argument pin. */
#define GPIOSinglePinWrite(port, pin, state) (((state)== PIN_ON) ? \
                GPIOPinWrite((port), (pin), (pin)) : \
                GPIOPinWrite((port), (pin), 0))

    /* Set the output for multiple pins on a given port simultaneously. 
     * This could be written as a function instead and there would be 
     * advantages to doing so. There would be no potential risk from
     * multiple evaluation of the argument pins. */
#define GPIOMultiplePinSet(port, pins) (GPIOPinWrite((port), (pins), (pins)))

    /* Clear the output for multiple pins on a given port simultaneously. 
     * This could be written as a function instead. */
#define GPIOMultiplePinClear(port, pins) (GPIOPinWrite((port), (pins), 0))

Robert

Robert Adsett72 said:

an untested, uncompiled, unlinted example

Sir - have you NOT just described (95%+ of the code) - regularly arriving here?      (even that from rushed, "LIKE-less" vendor staff)

If I may - might:

GPIOMultiplePinWrite((port), (pin), (pin))

be strengthened by:

GPIOMultiplePinWrite((port), (pins_in_array_n), (pins_selected))

Now my (equally) "untested, uncompiled & unlinted" submission - attempts to (better clarify) "What's What" w/(always pesky) params: 2 & 3."

Note that mine is a, "name change only" (i.e. fast "paint job") which attempts to "better clarify the role of params: 2 & 3."

And while you (surely) know this - others must insure that any such "code construct" produces, "glitch-less" bit Sets & Clears!     (forum would do FAR BETTER to, "Ban the Glitch" - not the well-earned LIKE!")

I may (even) have "snuck in" an element of KISS!      (further horrifying (our) LIKE-less (uninspired/uncomprehending (entitled)) crüe)

cb1_mobile said:

If I may - might:

GPIOMultiplePinWrite((port), (pin), (pin))

be strengthened by:

You will note that there is no multiple pin write in my example. Since it already exists I wasn't reproducing it, even to rename. I was producing the complementary sets, particularly the single pin write so many seem to struggle with.

My feeling is that although there might be a small gain from adding a multiple pin write rename, most of that gain is already there from having a single pin write variant (that suggests the other function is a multiple pin write form) and there is advantage to using the normally named version for anyone who later reads the code and is already familiar with TIVAWare.

Robert

Indisputable - really?      Is it not (so often) true that "indisputable" (really) means: "insufficiently studied/probed/investigated - or awaits new/better facts?"

Certain (beyond engineering) schools teach the value of "caution" when employing: "Always, Never, or Indisputable."     In each case such words "open the user" to a "vast burden of proof."     Indeed caution (most always) trumps bluster!      (note the (hedge) "most")