Tag: Maker

MSP430 Launchpad: Random Software Delays

Posted by on December 13, 2010

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.

ESR Meter – What went wrong.

Posted by on November 6, 2010


Current PCB layout for the ESR Meter

Continuing with the ESR project, I’d like to enumerate the various issues I encountered during layout design, fabrication and finishing of the project.

I believe some people only show their “good side” and bury deep down each and every failure they suffered, however you don’t learn from winning and that’s why I thought it would be a good idea to write this.

These are some of the problems diagnosed during troubleshooting in no particular order:

  1. PCB Layout error, first revision circuit had a trace that was mistakenly connected to another component, this rendered the detector phase useless.
  2. Bad ceramic capacitor, the 470pF was damaged. Replaced with two 1nF in series to approximate the value.
  3. The transformer displayed losses at high frequencies, it was replaced with another transformer. (I still worry about the output level, it’s way under 100mV)
  4. Negative supply “biasing” potentiometer had one of the wires broken by the PCB end, most likely due to the amount of handling involved during the troubleshooting phase: always hotglue your wires!!
  5. Power supply wasn’t providing enough voltage for the opamp used, turns out 5v input is a no-go for TL082 due to manufacturing tolerances, etc. I had to go for 12V. The final unit uses 13.8V — I would like to go up to 15V but that calls for a different regulator.
  6. Deflection issues due to the 100uA meter, feedback gain was changed and a potentiometer was added for convenience.
  7. One of the test leads had a high resistance due to severed wires by the connector, this was a cheap DMM set of leads and I regret using them!
  8. The only TL082s I had were in SMD packages, so I had to etch a dip adapter board!
  9. My PCB layout was lost, well — the source file at least, this meant I had to redraw the entire layout from scratch, based on screenshots.
  10. Several placement and power issues during the last phase of the project were encountered, all of which have been fixed ever since — Although I’m not entirely happy with the placement of the potentiometers, they’re at a slight angle and this means their values will shift due to the slight pressure they’re under.

So, I wasn’t kidding when I said this wasn’t a simple project! — Probably the most problematic one thus far. However I didn’t give up and I could probably say I succeeded.

Special thanks to Lee and everyone in ##electronics @ freenode  for the invaluable help and support!

Have fun!
Cheers.