Leaderboard

Conclusion is that the original sketch depends on delays caused by digitalRead(). On MSP430 a digitalRead takes about 2.5 us and on AVR about 3.8 us. This difference + more efficient code on MSP430 caused the below counting loop to be about 3 us shorter on MSP430 vs AVR resulting in more counts than the code anticipates. Replacing the delayMicroseconds(1) with delayMicroseconds(3) compensates for the difference in timing and makes it all work. while (digitalRead(_pin) == laststate) { counter++; delayMicroseconds(1); if (counter == 255) { break; } } An alternative work-a

And after much busy life... paste, stencil, and hot air produce:

[Edit!!! -- fixed already 06/26/2012 -- will leave for people who get this problem and might not have updated ] Just a note to all of you compiling mspdebug from git source on your own. I just updated my mspdebug and aftewards I couldn't program my msp430g2553 chip. It was getting a message: fet: FET returned error code 7 (Could not write device memory) mspdebug thought my chip was a msp430g2403. Looking in the log, I see that support for the msp430g2403 chip was added recently. I manually edited the file fet_db.c and removed that entry, recompiled and then I was able to progra

oh, and im doing a full video blog again, also added to main post: the very first arduino test with LCD and Tactile Button: An overview of the Motion Plus and Nunchuck, extraction, and their boards: Arduino Startup Sequences with and without sensors. Motion Plus bare, Nunchuck still plugged in. And working pcConf: MultiWii PC Gui Screencapture. Seems functional: Motion+ and Nunchuck Stripped and Soldered Together: DIY ESC Test and Configure Setup. Using MSP430 Launchpad, Nunchuck Analog Stick, ESC and Brushless Motor Building a sensor casing

Gerbers @ seeed. I'll keep you posted on progress.

Since there are only 4 pins with different functions (F5510-PT48 & F5310-PT48,) it would probably be easier and cleaner just to use headers to map those different pins and have just one device on board. How about something simple like this: [see 2 posts down]

10R will result in 300mA through your LED, which is starting to get OK :). Some visible red glow is not necessarily bad. I am guessing the LED's peak wavelength is in the 850nm-ish range, that may very well mean that when overdriven, it will emit some light even in the visible red (750-780nm-ish) range (if you look at a webcam or some of these cheap-ish CCD cameras that have "night vision mode", you will probably see them doing this too). CIR applications usually operate in the 940nm-ish wavelength, which doesn't mean others won't work, just that the range and sensitivity will decrease. I

That is sometimes true. I used asm to do Dallas/Maxim one wire @ 1 MHz+, 115200 bps serial @ 1 MHz and 2400 bps serial at 32 kHz. The timing of those was very demanding. The DHT11/DHT22 protocol can be written in C and run at 1 MHz - I have done that. It requires careful coding to get the necessary efficiency. Each bit has to be processed in 70 clock cycles or less.

1-wire protocol works best with a 16MHz DCO frequency. It does not work with a 1MHz DCO frequency unless oPossum waves his magic ASM wand