zeke

The seminar was pretty cool. The labs for the cc430 let us build a Chronos to Chronos app that was pretty cool. And wouldn't you know it, the guy sitting next me won the Metawatch they were raffling. Argh.
 
Met the TI guy that designed the MSP-EXP430F5529, he's the Digital Field App guy here in Austin.
 
If anyone is interested, the 50% off codes are at http://www.em.avnet.com/ARMsitara and http://www.em.avnet.com/ARMstellaris

You are so right about Tom Baugh's MSP430 State Machine Programming. I bought it at the same time as Davies' book.
 
I used the state machine approach to design and to code on a recent contract. The beauty is that I could complete a paper code design and know at once that it would work. After fixing two cut and paste errors, I had my code running bug free immediately.
 
So, I'm a big fan of state machine style programming. I even started a thread on how to design a state machine over here. I haven't finished it just yet due to work commitments but I'll get to it eventually.

Zeke, a great set of posts! I started primarily with Davies' book. As you stated, this is a good source for information on the clock system and, I would add, the MSP430 peripherals. I've downloaded the tutorials and look forward to reading them.
 
I just finished crawling though Tom Baugh's "MSP430 State Machine Programming." I worked through the exercises using an Olimex H2274 header board holding an MSP430F2274 on a breadboard combined with a few parts and a couple of SMT to DIP adapter boards with an RS232 interface chip and a DAC. I used a Launchpad as a Spy-Bi-Wire programmer. A picture of the setup is in the Programmers and Debuggers forum under "Launchpad as external programmer."
 
This book is an interesting introduction to designing software based on state machine models without using an RTOS or a task scheduler of any sort. Lots of functionality can be had in 4K of flash. The book covers both bit-banged and peripheral-based UARTs, fancy button debouncing with stuck button detection, reading and writing flash from within a program, and so on. Definately a step or two beyond the examples in Davies. There is also early on an extensive discussion of machine instruction cycle times and addressing modes.
 
I learned a lot from this book. Its strength is that Baugh shows how to incorporate lots of functionality with an event-driven approach with very low power draw (LMP3) in the idle state. So many resources contain toy programs to illustrate a point or two, while this one shows goes much further into software design using its chosen approach.
 
There are a couple of downsides to this book. First, the reader is assumed to have a decent knowledge of C. Function pointers and structures abound. I played some catch-up here, but was glad to see these used as it increased my C abilities. Next, it is unlikely that a reader will absorb all the ins and outs on state machine programming in a first reading, even after working all the examples. You will need to try programming some of your own projects to "get it." You are exposed to many concepts like callbacks, event sinks, and so on that take time and experience to fully understand. The book would benefit from even more diagrams than it already has in this regard.
 
The book has convinced me that the event-driven state machine approach is a good one, and I'm buying a book UML statecharts that takes this approach, but in a more formal way.
 
Again, Zeke, many thanks for these posts.
 
Andy

So, now you got a job doing hardware design and you want to use the MSP430 in your design.
 
But you've discovered that your boss has insisted on using this "wicked cool awesome" and ancient 5V sensor because they have a bazillion in stock.
 
"What's the problem with that?" you ask.
 
The problem is this: the MSP430 is a 3.6V device and it doesn't have 5V tolerant I/O's. This means that you'll probably hurt the part if you put 5V into an input. Go ahead and google it. You'll find our very own OCY schooling someone on this topic back in 2008. I'll let you find the article. OCY is shy. And he's probably gonna rip me open for giving away his secret identity.
 
So, what's the answer? SLAA148 is the answer.
 
It will take you through the various input and output scenarios that you may face trying to interface to higher voltage systems - not just 5V.
 
Using this information, you should be able to measure the status of a 12V power supply with the A/D inputs or figure out how to drive a 12V relay.
 
Have a read. It's useful info.

SCOTTY! MORE POWER!
 
To my eyes, it looks like you need more power than the function generator is going to provide.
 
In fact, I bet the function generator is going to output 1Vpp @ 10mA maximum.
 
A first thought would be to study the MOC3063TVM datasheet to see at what point it triggers. That is, the working voltage and load current to make it do something useful.
 
Also, may I suggest that you test the triac using 24VAC from a standard door bell transformer instead of the function generator? The bell transformer will lower 120VAC to 24VAC and make it less deadly to you but still provide enough current to do something.
 
You could also put an incandescent light bulb in the load side to give you a visual indicator of your circuit function. Either that or a DVM or 'scope.
 
On the input side, you could rig up a simple switch that applies the proper trigger voltage to the anode through a load resistor. You should tie the cathode to ground in that case.
 
What do you think?

This is a follow up to the 5Volt tolerant I/O posting above.
 
I decided that I should put up a picture of a sample circuit that I've used to do 5V tolerant I/O.
 
The resistive divider on the left will scale down the 5V to a range tolerable by the MSP430.
 
The NPN transistor will do the same in the output direction. You could drive anything with the NPN - not just a relay.
 
This should make things clearer.

SCOTTY! MORE POWER!
 
To my eyes, it looks like you need more power than the function generator is going to provide.
 
In fact, I bet the function generator is going to output 1Vpp @ 10mA maximum.
 
A first thought would be to study the MOC3063TVM datasheet to see at what point it triggers. That is, the working voltage and load current to make it do something useful.
 
Also, may I suggest that you test the triac using 24VAC from a standard door bell transformer instead of the function generator? The bell transformer will lower 120VAC to 24VAC and make it less deadly to you but still provide enough current to do something.
 
You could also put an incandescent light bulb in the load side to give you a visual indicator of your circuit function. Either that or a DVM or 'scope.
 
On the input side, you could rig up a simple switch that applies the proper trigger voltage to the anode through a load resistor. You should tie the cathode to ground in that case.
 
What do you think?

My board and MSGEQ7 chip in action.
 
Three 5x7 matrix displays (15x7) are connected to my 595 expander board.
MSGEQ7 does all the hard work here, nothing fancy, no FFT.
 

It's finally here!
 
See my original post for more pictures and the movie.
 

According to his webpage, all the code is right here.
 
The processing sketch is pretty cool. I bet we could come up with some interesting things with it. Thanks Jeremy and Matt! :thumbup:

very well done production. he was using python and arduino and he mentioned a web socket and telnet connection. Very smooth operation but i couldnt find his code :cry:
 
I saw a couple dudes at Cornell that used the msp and ezrf2500.
 
http://jeremyblum.com/2011/05/14/msp430-wireless-weather-station/
 
it looks like TI has some good software which works. They programmed their GUI in "Processing", http://processing.org/ and are sharing all of it. I am still pondering schematics here.....

Did any of you guys enter this contest? http://www.bluetooth.com/Pages/IWC.aspx It's somewhat MSP430 related...
 
I entered a while back and submitted 2 projects. Today, I was notified that my projects have been accepted and they sent my code for a free Freescale Sensor Toolbox. Of course, I picked the nicest kit and they're sending a $300 hardware and sensor tool box to me for free. I'm hoping that I was one of the first 20 entrants so I'll get the TI CC2540 Dev kit free too but if not, it's still discounted 50%.
 
The project ideas submitted were: 1) a bluetooth based, pH and eC meter that sends data wirelessly to androids or iOS devices. It can be used for ponds, aquariums, aquaponics, swimming pools or anywhere else this data might be needed. 2) a bluetooth based wine cellar monitoring system. It will monitor rfid-tags/barcodes on bottles, barometric pressure, temp and humidity and of course send the data to a pc, iOS or android. (My father-in-law holds a few patents in the wine making and storage industry and he loved this idea and wants to buy the prototype - currently commercial systems are expensive and require a hardwired monitoring station)

Now I remember where I saw that LCD module!
 
I used to repair cell phones for a living many years ago.
 
That LCD was in the handset for a cell phone that was made in the UK. I wished that I could remember the manufacturer name.
 
I'll see if I can find more info on it.

Now I remember where I saw that LCD module!
 
I used to repair cell phones for a living many years ago.
 
That LCD was in the handset for a cell phone that was made in the UK. I wished that I could remember the manufacturer name.
 
I'll see if I can find more info on it.

To me, if it's a reputable company name on the mat then the only things to worry about are the wrist strap and connecting the mat to electrical ground.
 
I despise wrist straps. They feel like handcuffs to me. So I have a pair of anti-static shoes. Yes. Shoes.
 
The other thing that I've developed is the habit of touching a work surface (if my hands are full) with my pinky or empty free hand when moving around the lab. I call it spidering around the lab. If touching a anti-static mat or metal table leg then you should be able to quickly dissipate the static.
 
Static becomes a real problem when the relative humidity of a room drops below 35%.
 
Say! There's an application for one of those humidity sensors and RobG's displays! :thumbup:
Any takers?

Winter is coming so the air will be dryer. At least it will where I live.
 
You can generate a couple 1000 Volts of static electricity just by getting up off of your chair. So save yourself some circuit troubleshooting grief get an anti-static mat.
 
I have both a Desco and a 3M anti-static mat.
 
The 3M one is cheaper for some reason.

Winter is coming so the air will be dryer. At least it will where I live.
 
You can generate a couple 1000 Volts of static electricity just by getting up off of your chair. So save yourself some circuit troubleshooting grief get an anti-static mat.
 
I have both a Desco and a 3M anti-static mat.
 
The 3M one is cheaper for some reason.

Yes. It's a two wire bus that has a time based protocol. Maxim/Dallas is the only manufacturer in the world.
 
Here's an excellent summary of it.
 
Most people use their temperature sensors in their HVAC projects.
 
But, it's also used in a serious manner. I have a client who has based their entire business on these temperature sensors. They are one of the largest users of one wire technology in the world.

Free international shipping! Ordered one too, even though it seems like one of those things that you play with, write a "proof of concept" app and then never use again.

As long as everyone has the same point of reference - Ground.

Thanks for all the help. Now that I have the struct declared and used properly and my MAX_APP_PAYLOAD is now set to 16 bytes (not 10!) the data is transmitting with no issues.
 
Working but not completed pieces of transmitter:

typedef struct sensors_struct { float thermistor; float relativeHumidity; float gyroRoll; float gyroPitch; }my_sensors; my_sensors sensor; //struct sensors_struct sensor; sensor.thermistor = 1.0; sensor.relativeHumidity = 2.0; sensor.gyroRoll = 380.0; sensor.gyroPitch = 381.0; SMPL_Send(linkIDTemp, (uint8_t *)&sensor, sizeof( my_sensors ));
And receiver:

typedef struct sensors_struct { float thermistor; float relativeHumidity; float gyroRoll; float gyroPitch; }my_sensors; struct sensors_struct sensor; uint8_t smpl_buffer[MAX_APP_PAYLOAD]; SMPL_Init(sRxCallback); static uint8_t sRxCallback(linkID_t linkIDTemp) { SMPL_Receive(linkIDTemp, (uint8_t*)&smpl_buffer, &len); if(len == sizeof(my_sensors)) { P1OUT |= BIT1; memcpy(&sensor, smpl_buffer, len); } else { P1OUT |= BIT0; } // replace with_ return message; return 0; }

As long as everyone has the same point of reference - Ground.

BTW, I found an example in MSP430 Microcontroller Basics that may be just what you're looking for. It's on page 217,218.
 
Listing 7.1: Program butled4.c in C to light LED1 when button B1 is pressed usinginterrupts and low-power mode 4.
// butled4.c - press button B1 to light LED1
// Responds to interrupts on input pin , LPM4 between interrupts
// Olimex 1121 STK board , LED1 active low on P2.3,
// button B1 active low on P2.1
// J H Davies , 2006 -11 -18; IAR Kickstart version 3.41A
// ----------------------------------------------------------------------
#include // Specific device
#include // Intrinsic functions
// ----------------------------------------------------------------------
void main (void)
{
WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer
P2OUT_bit.P2OUT_3 = 1; // Preload LED1 off (active low!)
P2DIR_bit.P2DIR_3 = 1; // Set pin with LED1 to output
P2IE_bit.P2IE_1 = 1; // Enable interrupts on edge
P2IES_bit.P2IES_1 = 1; // Sensitive to negative edge (H->L)
 
do {
P2IFG = 0; // Clear any pending interrupts ...
} while (P2IFG != 0); // ... until none remain
 
for (; { // Loop forever (should not need)
__low_power_mode_4 (); // LPM4 with int'pts , all clocks off
} // (RAM retention mode)
}
 
// ----------------------------------------------------------------------
// Interrupt service routine for port 2 inputs
// Only one bit is active so no need to check which
// Toggle LED , toggle edge sensitivity , clear any pending interrupts
// Device returns to low power mode automatically after ISR
// ----------------------------------------------------------------------
#pragma vector = PORT2_VECTOR
__interrupt void PORT2_ISR (void)
{
P2OUT_bit.P2OUT_3

Nope. It means clear the P1.0 Interrupt Flag.
 

P1DIR &= ~KINT; // set P1.0 as input P1OUT |= KINT; // set P1.0 HIGH P1REN |= KINT; // enable P1.0 internal pullup resistor P1IE |= KINT; // enable P1.0 interrupt P1IES |= KINT; // set P1.0 interrupt detection to Hi/Lo edge transition P1IFG &= ~KINT; // clear P1.0 interrupt flag
 
And then in your ISR
 

#pragma vector=PORT1_VECTOR __interrupt void PORT1_ISR(void) { readKeybd(); sendData(charData); P1IFG &= ~KINT; // clear P1.0 interrupt
 
IMHO, I think that you should avoid low power modes until you've tested out the ISR. LPModes are trixy little buggers and need to be treated carefully.
 
Take a look at this sample usage from MSP430 Microcontroller Basics, page 201:
Listing 6.6: Part of program timintC2.c to toggle LEDs using interrupts from Timer_A. The device enters low-power mode 0 between interrupts. 
// ----------------------------------------------------------------
__enable _interrupt (); // Enable interrupts (intrinsic)
 
for (; { // Loop forever doing nothing
__low_power_mode_0 (); // Enter low power mode LPM0
} // Interrupts do the work
}
 
// ----------------------------------------------------------------------
// Interrupt service routine for Timer A channel 0
// Processor returns to LPM0 automatically after ISR
// ----------------------------------------------------------------------
#pragma vector = TIMERA0_VECTOR
__interrupt void TA0_ISR (void)
{
P2OUT

I have bus scan and CRC written, but not yet tested.