Story:

I’ve been meaning to build a “line seeker” robot for a while now, however I can’t source LDRs (Light Dependent Resistor) due to RoHS nonsense, so I decided to use plain old LEDs instead. While you could use a couple analog amplifiers and comparators to do this I thought it would be a fun little microcontroller project.

Right now we’re just exploring how to utilize a regular LED as a photo-diode, ie. an input sensor.

There are a couple ways to accomplish this – I chose the simplest for the time being – The idea is to sample the voltage present on the LED anode (or cathode!) by using the ADC on the MSP430, this voltage will be relative to the ambient light. You could picture the LED as a solar cell in this case.

The code:

We’re going to use the on-board LEDs on the LaunchPad to simplify things. The Red LED will be our “sense” input and the Green LED will be used to depict the current state of the sensor.

You’ll have to modify the header (and your project target) depending on which MCU you’re using, I happen to have a G2452 currently populated for another project I’m working on, but you can use any value-line MCU as long as it’s got an ADC.

/* LED as Photo-Sensor
 / By: Gustavo J. Fiorenza (GuShH - info@gushh.net)
 / No external components required, simply shine a light to the RED onboard LED!
 /
 / Note: Tested on a G2452 only, should also work with other value-line MCUs.
*/

#include "msp430g2452.h"	// Change the header to "msp430x20x2.h" if you're using the default MCU bundled with the LaunchPad.

#define LED_SENSE INCH_0 	// LED 1 (Red LED from LaunchPad).

unsigned int adcval = 0;

unsigned int analogRead(unsigned int pin) {

  ADC10CTL0 = ADC10ON + ADC10SHT_2 + SREF_1 + REFON + REF2_5V;
  ADC10CTL1 = ADC10SSEL_0 + pin;

  ADC10CTL0 |= ENC + ADC10SC;

  while (1) {
    if ((ADC10CTL1 ^ ADC10BUSY) & ((ADC10CTL0 & ADC10IFG)==ADC10IFG)) {
      ADC10CTL0 &= ~(ADC10IFG +ENC);
      break;
    }
  }

  return ADC10MEM;
}

void main(void) {
	unsigned int i, delay;

	WDTCTL = WDTPW + WDTHOLD;	// Hold the watchdog.
	P1DIR = BIT6; // LED 2 (Green LED from LaunchPad).

	while (1){

		// Multi-sampling (8 samples with delay for stability).
		adcval = 0;
		for ( i=0; i < 8; i++ ) {
			adcval += analogRead( LED_SENSE );	// Read the analog input.
			delay = 1000;
			while (--delay);
		}
		adcval >>= 3; // division by 8

		// Interpret the result
		if ( adcval < 500 ){
			P1OUT |= BIT6;	// Turn on the onboard Green LED.
		}else{
			P1OUT = 0x00;	// Turn off the entire Port 1, thus turning off the LED as well.
		}

	}

}

Why so vague?

Lately I've been suffering a serious mental block, I would really like to explain the theory behind all this but not only am I uninspired I also can't focus on writing... I would however recommend you Google "LED Sensor" (or similar query) to learn more about the subject.

Have fun.

The goal: to “randomly” flash the on-board LEDs at P1.0 and P1.6

The weapons: CCS, Launchpad, Cookies (you may choose your favourite ones)

The reason: To familiarize yourself with the coding environment, or just for the heck of it.

The library:

#ifndef GRAND_H_
#define GRAND_H_

static unsigned long int rand_next = 1;

int gRand( void ) {
	rand_next = rand_next * 1103515245 + 12345;
	return (unsigned int)(rand_next/65536) % 32768;
}

void gSRand( unsigned int seed ) {
	rand_next = seed;
}

#define gRandom()		((gRand() & 0x7fff) / ((float)0x7fff)) 	// random in the range [0, 1]
#define gCRandom()		(2.0 * (gRandom() - 0.5)) 			// random in the range [-1, 1]
#define gMax(x,y)		(x > y ? x : y)				// minimum
#define gMin(x,y)		(x < y ? x : y)				// maximum

#endif /*GRAND_H_*/

That’s our random library, it’s grand.h

The “g” prefix is one I often use privately, it’s simply the first letter of my name. However because there may be other routines in the future with a similar naming convention, having “g” prefixed is not a bad idea; without having to fall into namespace gibberish.

The PRNG is an old standard. No need to discuss it.

You may recognize those macros, yes! They’re from Quake3! — Although we aren’t using them I left them there for future reference on how to obtain usable value ranges from the PRNG. There’s a lot to be said about floating point values and whatnot, But I’m going to restrain myself in this case.

Now to the main code:

// MSP430 Launchpad - Blink onboard LEDs using random delays.
//	GuShH - info@gushh.net

#include  "msp430x20x2.h"	// Include the necessary header for our target MCU
#include  "grand.h"		// Include our simplistic prng lib.

void delay_ms(unsigned int ms ) { // This function simply performs a software delay, hard from efficient but it's practical in this case.
	unsigned int i;
	for (i = 0; i < = ms; i++) { // Make sure your < and = has no space in between (the syntax parser seems to be messing things up)
		__delay_cycles(500); // This should be dependent on clock speed... but what the hell, even the loop itself should be taken into account...
	}
}

void set_and_wait( int led ) {
	P1OUT = led;			// Set the bits
	delay_ms( gRand() * 0.01 );	// Delay a "random" amount of time
}

void main(void) {

	WDTCTL = WDTPW + WDTHOLD; // Hold the WDT (WatchDog Timer)
	P1DIR |= BIT0|BIT6;       // Enable the appropriate output

	while(1) {
		set_and_wait( BIT0 );	// Set BIT0, that's our first LED.
		set_and_wait( BIT6 );	// Set BIT6, The other LED.
	}

}

No external hardware is required, just make sure both P1.0 and P1.6 jumpers are set.

As you can see we're simply toggling the LEDs with a random delay, the delay_ms(); function was taken from here.

Like I said there are quite a few topics to explain, however I decided to keep this one as simple as possible (Alright, I'm in a rush!)

So... Compile, run and enjoy!

Once I get the time I'll put together some utilitarian code libraries and lengthier explanations, promise.

For those interested, you may download the entire project directory from here: Random Software Delays.

I received the launchpad a couple weeks ago, however I’ve been busy so I couldn’t even cook up an example. I do plan on working with it and posting some code here. I have some fun ideas for it (but still waiting on components I ordered…).

Mind you, I still feel strongly about the company TI hired to deal with this product. I would really like to see an explanation from them; but that’s the thing… when you’re a huge company you don’t have to explain anything to anyone, you just do what you want until you go bankrupt and someone gets shot. 😉

These Harte Hanks, or should I call them “Hard at Wanks” guys are shameless. I (and a few others) could not contact them or get any information whatsoever on the shipping status for the MSP430 Launchpad.

To contact TI you must spend at least half an hour filling out a massive form just to never be contacted by them…

It’s rather obvious that the whole MSP430 Launchpad was an afterthought and that TI has no infrastructure for small companies and/or buyers; they play with the big fish and they don’t know how to handle regular human beings. Heck, they’re paying some clowns to deal with them and look at what happened! More…