ROBOT

[Sean McBeth]

http://dl.dropbox.com/u/9161524/robot.jpg

MSP430 on the inside. Toothbrushes on the bottom and pager motors inside at the corners, though I don't know if it will actually make it move; it doesn't work yet. Only one of the bumpers was triggering my interrupt code, so I'm not sure exactly what the issue is with the other 3. I have no debouncing caps or pull-down resistors on any of those bumpers; they should probably be added. Hell, I didn't spend much time on the code and I don't remember much about MSP430, so it might not be right. Also, while one of the LEDs would light up, the corresponding motor wouldn't run. The LED is in series after the motor, should they be in parallel?

The idea is for it to run around at random, bumping in to things, which will toggle specific motors.

Code:

#include <msp430.h>

int main(void) 

{

WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer

P1DIR = 0xF0; // P1.[0-3] input, P1.[4-7] output

P1IE  = 0x0F; // P1.[0-3] are interrupt pins

P1OUT = 0xF0; // Make sure all of the motors start on

P1IES = 0x00; // make all interrupts run on leading edge

P1IFG = 0x00; // reset all of the interrupts to be off

__enable_interrupt();

}

// Port 1 interrupt service routine

#pragma vector=PORT1_VECTOR

__interrupt void Port_1(void)

{

P1OUT ^= P1IN << 4; //This should make any input pins toggle a corresponding output pin

P1IFG = 0x00; //Reset all of the interrupts

}

[pezman]

Very cool,

I'll need to think on the code a little -- haven't been msp-ing much
lately (I sense there's an opportunity for a joke in there
somewhere).

You can program the inputs with software pull-downs (I love designs
that are as component-free as possible). For example,

P1REN |= 0xF; // enable the internal resistor for P1.0 through P1.3
P1OUT &= ^0xF; // pull P1.0 .. P1.3 inputs down


Probably asking a little much with the motors and the LEDs in series
-- there is quite a voltage drop across the LED (depends on color,
device chemistry and even the individual device), so there may be
little or no voltage left for the motor. Putting them in parallel may
not be much better (tough to analyze this situation -- the LED has a
very non-linear voltage vs current curve, and the motor has somewhat
complex dynamics that depend on its speed etc). Might need to add some
transistors in order to have the outputs drive the motors. Naturally,
I'd love to see the design get away w/o any pesky outboard
transistors.

Very cool and probably very close to being right. I love the extreme
simplicity of the code.

[pezman]

Also, I'm a little more accustomed to seeing an infinite loop after
the interrupt enable. It's unclear to me how the program above would
managed to service any interrupt -- I presume that it terminates right
after enabling the interrupts.

[Sean McBeth]

I'm going to have to play with it, because I seem to remember writing an interrupt-driven beeper program that had no busy loop for the blink and buzz class, but now I'm not certain. I had it there at first, but deleted it before I posted this email, thinking that a busy loop was burning processor time that I didnt want to waste for no good reason.

Not really thinking too straight right now. I was so busy on this thing that I hadnt realized that I spent 7 hours on it and hadnt eaten anything in that time.

--
To post to this group, send email to hive76-d...@googlegroups.com
To unsubscribe send email to hive76-discuss...@googlegroups.com
For more awesome goto http://groups.google.com/group/hive76-discussion?hl=en

[Sean McBeth]

BTW, thanks for that bit on the internal pull-down. That's pretty awesome.

[Spencer Russell]

It's pretty uncommon for a microcontroller app to terminate. I think
it's architecture-dependent, but I could imagine some micros just
resetting back to the beginning after main() executes, so you still
have an implicit busy loop, it just executes main() over and over
again.

As long as the chip is running and awake it will be pulling
instructions and executing them, so having a busy loop doesn't burn
any more cycles. The only way to stop it from executing is to
explicitly put the chip to sleep (and set it up to wake up an external
interrupt. The general architecture would be:

void main()
{
hw_init(); /* make sure it's configured to wake up on an external
interrupt */
while(1)
{
goToSleep();
handleWakeupStuff();
}
}

void externalInterruptISR()
{
doInterruptStuff();
}

So when goToSleep() runs, the chip goes to sleep immediately. Then
every time the external interrupt hits, it executes the ISR, then
passes control back to the main loop and executes handleWakeupStuff().
If you're just toggling output pins then you can do that from the ISR,
but if you want to do anything that takes a little longer it's good
practice to defer the work to the main loop and keep the ISR fast.

-s