CCS/TM4C1294NCPDT: Use user switches

Hannah Kirstein

Prodigy 30 points

Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: EK-TM4C1294XL

Tool/software: Code Composer Studio

Hello,

My question might sound a little simple stupid:

How do I use the onboard user switches of my Tiva TM4C1294 Launchpad?

This are the lines from my Hardware setup regarding the switch (PJ1):

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOJ)

ROM_GPIOPinTypeGPIOInput(GPIO_PORTJ_AHB_BASE, GPIO_PIN_1);

and this is the code where I want to read the switches state:

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

buttonpressed = GPIOPinRead(GPIO_PORTJ_AHB_BASE, GPIO_PIN_1);
if(buttonpressed == 1){
GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_0, 1);
}else{
GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_0, 0);
}

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

but it doesn´t work, the code reads from the PJ1 pin and not the switch

does anybody know how I get the state from the switch?

Thanks in advance!

over 6 years ago

0 cb1_mobile over 6 years ago

Guru 117855 points

Greetings,

Your question proves (far) from (even) a little simple/stupid. And - you've provided (almost) all of the detail - usually required for, 'remote diagnostics.' (that's quite good for a 2nd time poster!)

Follows several tech details which should enable you - (especially you - or your crack/remote diagnostic crüe) to resolve:

Are you (absolutely) certain that your 'switch' connects to MCU pin PJ1? Such 'certainty' results (only) from successful measurement.
It proves normal/customary for such a switch to operate in conjunction w/a 'pull-up or pull-down' resistor. (that provides a base logic level - which switch actuation can alter.) Can you identify such resistor on your LPad's schematic - and then confirm its presence upon your board? And finally - its connection to PJ1?
The switch should be wired in 'opposition' to (either) the pull-up or pull-down resistor. (i.e. if the PJ1 resistor 'pulls-up' to Vdd - the switch should 'actuate' to ground.) Probing carefully - you should be able to confirm that 'Switch Actuation' - indeed changes the logic state of PJ1. (yet only when & while the switch is being actuated.)
It is suspected that your switch is 'momentary in nature' - thus your code must run, 'During the ACTUATION period!' If your code 'loops' near continually - then it is likely that the 'Actuation Read' (i.e. 'buttonpressed = 1') - will have been subsequently, 'over-written.'

Is this sufficient to meet your program needs? Based upon the above - 'How can you 'capture' that (brief) switch actuation' - while preventing 'follow-on pin reads' from destroying - your 'actuation's capture'? (i.e. again - the unwanted 'overwrite' of 'button pressed.')

[edit] Staff noted your comment, "Code reads from the PJ1 pin - and not the switch!" They believe - that 'Reading from the pin' (any pin) is, 'Exactly what should be happening!' Further - they believe that (assuming the switch implementation meets our (earlier) bullet point specs) your switch indeed WAS READ! That 'pin-switch recognition & read' stands as a 'high-priority' function - yet received 'No Special nor Protective treatment!' Minus such 'proper, timely & protective handling' (huge clue!) your likely (successful) 'switch read' (buttonpressed =1) - was (surely) over-written...

That 'special & protective treatment' is the job of your program - and now 'brought to your attention' - should prove not too difficult for you to resolve!

My small tech firm employs & interns many college students - we strive to, 'Present a Solution Method!' (which proves 'far more valuable/lasting' - than a copy/paste, effort-lite, 'solution'...)

Tag: How best to detect then 'latch' (i.e. 'protect') a momentary switch's (brief) actuation.

0 Ralph Jacobi over 6 years ago

TI__Guru*** 135355 points

Hello Hannah,

Honestly the easiest way to do this is to the buttons driver that we have included in TivaWare.

That said, I will also commend cb1's commentary as a great way to further learning about what goes in the background with switches and how to properly debug switch operation as a whole. I would encourage following along with his advice for your learning.

The files for the buttons drivers are located at [Install Path]\TivaWare_C_Series-2.1.4.178\examples\boards\ek-tm4c1294xl\drivers

0 cb1_mobile over 6 years ago in reply to Ralph Jacobi

Guru 117855 points

Thank you for that 'vote of confidence' Ralph - always appreciated.

Staff's/my goal was to, 'Encourage this poster' (and forum readers) to, 'More closely examine' what goes into the (seemingly) easy, 'Read of GPIO connected Switches.'

We believe that this poster had not (yet) 'Thought deeply enough' about the various 'program mechanisms involved' - in even her (simple) 'switch read' quest.

Even more complex - low cost switches exhibit 'Contact Bounce' (they both 'Make & Break' contact several times) - and that too requires (first) recognition - and then a 'thoughtful & considered strategy!' Thus - just maybe - poster's belief in her "Switch Read quest" being 'simple' - proves not entirely true... (i.e. there are 'multiple' (unanticipated factors) lurking - just beneath the surface...)

Each poster/reader must 'weigh' the "learning value" - gleaned from:

simply finding/reading/copying/pasting existing driver files

versus

the (added) thought process - imposed by greater poster/reader, 'study, thought & focused effort.' (i.e. to first 'identify' key program objectives - & then 'build' a series of highly focused/specific - individual 'issue resolving' programmed solutions.)

(Many believe - only one of those methods - yields both (real depth) & (long lasting) understanding ... Such proves especially true - when one enters the 'real-world' - and NO 'API' is available for 'rescue!')

0 Hannah Kirstein over 6 years ago

Prodigy 30 points

Tanks to both of you for the answers!

It was the pull up resistor... I guessed this was the problem but I didn´t know how to activate it.

Thanks to your advice I googled for it again and added this line I found in another thread:

GPIO_PORTJ_AHB_PUR_R |= 0x02;

And now it works!

Unfortunately I don´t have the time to get a deeper understanding of what´s exactly going on using the switches but I will take the time after I finished my project so- thanks a lot for your explanations and advices!

0 cb1_mobile over 6 years ago in reply to Hannah Kirstein

Guru 117855 points

Good job - thank you and (mid-morning) congratulations. (it is believed that you are in Euro.)

Do pay (some) attention to these following two points: (both impact your real-world usage of that switch)

You must (really) 'Capture & Sustain' that switch-read variable. That is so as the 'next trip thru' your switch-read loop is likely to 'overwrite' it! There are several methods to do this - my preference is for (you) to 'personally make that analysis effort!'
Later post informed/advised of 'Switch Bounce.' It proves 'possible' (even likely) to 'Read the Switch too early or too late!' (Delightful - that!)

While you have achieved, 'Apparent Success' - these 'low level details' have a way of lurking - and, 'Spoiling one's day!' These details are likely to arise - thus delay your project's completion.

'Recognition of' these issues' AND 'Attention to Detail' (even when there is little time) almost always are demanded. (Shortcuts/Rush ... unfortunately not so much!)

Tag: 'Half-Life' of a 'Rushed' or 'Pre-Packaged' solution ... not so long...

Arm-based microcontrollers

Arm-based microcontrollers forum

CCS/TM4C1294NCPDT: Use user switches