Control a LED with the MSP430F2012
things you might not have thought of. You also have misunderstood the
use of P2SEL. It is used to select the alternate mode functions for a
pin, not its I/O direction. that is done by PxDIR. You don't need to
explicitly clear trhe bit at power on, if that was your intent.
For example the button won't make contact cleanly, so you need to get
around the fact that contact makes and breaks rapidly several times.
this is called debounce. After that it is a case of starting a timer to
time how long the button is pressed.
So basically you will need to set up a timer. the watchdog is
absolutely nothing to do with this. You have a TIMERA peripheral on
every MSP430 I know of, so that is best to use. I don't know what clock
you are using, but for accurate timing a watch crystal works well.
I would use interrupts to handle the button detection, but if you aren't
familiar then it may be difficult for you at first.
here is the logical sequence of what you might need to do.
Configure your hardware Set the I/O port for the pin as follows:_
name the pin the button is connected to BUTTON, it makes it easy to
understand the code, and the LEd pin LED
in your setup
As I said using interrupts makes most sense, but it is probably simpler
ti undertsand this in a polling mode. so
Set the LED pin as an output
Set up Timer A to generate a known time base. using the continuous run
mode of the timer for example and a watch crystal means you only get a
timer overflow event every 2 seconds, making 5 second shard to time. i
suggest that, for this first time around you use the timer in run to
mode, so you set a value in CCRA0 that the timer will run up to, and
then reset. the value used is 1 less than the actual count you need, for
eample a 1 second overflow occurs every 32768 counts, so set CCRA0 to
32767. A more practical value, that would let you time smaller values
might be 2047, so the overflow occurs 32 times a second
Then run the following pseudo code
If NOT BUTTON goto DETECT
COUNTER = 160 (32 times a second * 5 = 160)
if NOT BUTTON goto DETECT
if NOT TIMERA overflow flag goto BUTTON_TIMER
clear TIMERA overflow flag
COUNTER -= 1
IF COUNTER != 0 goto BUTTON_TIMER
LED = ON
You can use a similar timer action to time how long the LED stays on
for, for example,then wait in aloop until the button is released before
looping back to the beginning at DETECT
This is really simple, not a very practical program, just a learning
excercise. I hope this helps.
------- Google ------ 4e4th ------ need only two line non compliled code --
Where's the harm --------
Thenks in advance!
In the foreground we set up a timer to generate an interrupt at a 10 ms rate.
The Timer ISR consisted of a state machine. A variable was used as a state counter with selected the active thread to be executed.
Initial state: 0 - Every entry into the ISR check for key activation.
If the key is detected then State = 1.
Next timer tick 10 ms later: State 1 - Verify that the key is still detected active. If the key is no longer pressed, it might be due to contact bounce. If the key is still active, then State = 2. If the key is non longer active, then state = 0.
Next timer tick 10 ms later: State 2 - Verify that the key is still active. If the key is no longer active, then State = 0. If the key is active, then load a dwell counter with the value 480 and advance the state to 3.
Next timer tick 10 ms later: State 3 - Verify that the key is still active. If the key is no longer active, then State = 0. If the key is still active, then decrement the dwell count. If the dwell count is not zero, then hold the current state. If the dwell count is now zero, activate the LED. Then advance the State to 4.
State 4 is where you would do the post LED activation tasks. Ultimately, the state process would return to State 0 where you would be looking for an initial key press.
This technique is useful because you can easily vary the debounce time by adding more states or changing the timer period. You can implement complex key press sequences by detecting events and branching to other states. All of this runs underneath the foreground code, so it is quite non intrusive. Since only the next portion of the thread is executed during the interrupt, the overhead is quite low.