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
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.
On Mar 12, 12:45 am, Sean McBeth <sean.mcb...@gmail.com> wrote:
> 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
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.
On Mar 12, 1:36 am, pezman <mikehoga...@gmail.com> wrote:
> 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.
> On Mar 12, 12:45 am, Sean McBeth <sean.mcb...@gmail.com> wrote:
> > 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
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. On Mar 12, 2012 1:42 AM, "pezman" <mikehoga...@gmail.com> wrote:
> 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.
> On Mar 12, 1:36 am, pezman <mikehoga...@gmail.com> wrote: > > 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.
> > On Mar 12, 12:45 am, Sean McBeth <sean.mcb...@gmail.com> wrote:
> > > 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
> > > }
> -- > To post to this group, send email to hive76-discussion@googlegroups.com > To unsubscribe send email to > hive76-discussion+unsubscribe@googlegroups.com > For more awesome goto > http://groups.google.com/group/hive76-discussion?hl=en
On Mon, Mar 12, 2012 at 1:52 AM, Sean McBeth <sean.mcb...@gmail.com> wrote: > 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. > On Mar 12, 2012 1:42 AM, "pezman" <mikehoga...@gmail.com> wrote:
>> 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.
>> On Mar 12, 1:36 am, pezman <mikehoga...@gmail.com> wrote: >> > 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.
>> > On Mar 12, 12:45 am, Sean McBeth <sean.mcb...@gmail.com> wrote:
>> > > 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
>> > > }
>> -- >> To post to this group, send email to hive76-discussion@googlegroups.com >> To unsubscribe send email to >> hive76-discussion+unsubscribe@googlegroups.com >> For more awesome goto >> http://groups.google.com/group/hive76-discussion?hl=en
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.
On Mon, Mar 12, 2012 at 2:32 AM, Sean McBeth <sean.mcb...@gmail.com> wrote: > BTW, thanks for that bit on the internal pull-down. That's pretty awesome.
> On Mon, Mar 12, 2012 at 1:52 AM, Sean McBeth <sean.mcb...@gmail.com> wrote:
>> 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.
>> On Mar 12, 2012 1:42 AM, "pezman" <mikehoga...@gmail.com> wrote:
>>> 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.
>>> On Mar 12, 1:36 am, pezman <mikehoga...@gmail.com> wrote: >>> > 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.
>>> > On Mar 12, 12:45 am, Sean McBeth <sean.mcb...@gmail.com> wrote:
>>> > > 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
>>> > > }
>>> -- >>> To post to this group, send email to hive76-discussion@googlegroups.com >>> To unsubscribe send email to >>> hive76-discussion+unsubscribe@googlegroups.com >>> For more awesome goto >>> http://groups.google.com/group/hive76-discussion?hl=en
> -- > To post to this group, send email to hive76-discussion@googlegroups.com > To unsubscribe send email to hive76-discussion+unsubscribe@googlegroups.com > For more awesome goto http://groups.google.com/group/hive76-discussion?hl=en
