rebeltaz

OK... this is the code that I am using (from http://processors.wiki.ti.com/index.php/Playing_The_Imperial_March): //This function generates the square wave that makes the piezo speaker sound at a determined frequency. void beep(unsigned int note, unsigned int duration) // ex. beep (a, 500) { int i; long delay = (long)(10000/note); //This is the semiperiod of each note. long time = (long)((duration*100)/(delay*2)); //This is how much time we need to spend on the note. for (i=0;i<time;i++) { P1OUT |= BIT7; //Set P1.7... delay_us(delay); //.

I'm pretty new to all of this MSP stuff, too, but I found this very helpful pertaining to shift registers: processors.wiki.ti.com/index.php/MSP430_Launchpad_Shift_Register

OK... this is odd. I have been compiling my code as Debug and programming the MSP with that. Worked great. After I got everything right, I built the project as Release and programmed that. Running with the Release code, timing is sped up by at least double. I am using a snippet of code that I found on the TI wiki (I think) for Playing the Imperial March which uses __delay_cycles for timing. With Debug, this is fine, but with Release this is playing way too fast and too soft. Does the timing change between Debug and Release and (obviously it does) why? I guess the code is more optimized? Bu

Oh, OK... I understand the static part (I figured that out after I posted this ) but I couldn't find anything that said it only set it once. Thanks guys.

I found this topic - http://forum.43oh.com/topic/2025-software-debouncing/?hl=debounce - which lead me to this pdf - http://www.eng.utah.edu/~cs5780/debouncing.pdf - from which the code on this page - https://github.com/lucsmall/MSP430-Launchpad-Clock/blob/master/main.c - seems to take it's debounce routine. I've read that through it and I don't understand something. Going on the code in the clock example... inline void update_switches(void) { static unsigned char state[2] = {0xFF, 0xFF}; // Current debounce status state[0] = (state[0] << 1) | ((SWITCH_IN & SWITCH_0) ?

LOL.. that's a cute trick! You must be a teacher. I do plan on supplying the source code as well. Unfortunately, the article is more of a general how-to with little focus on the dynamics of the code itself. There isn't enough room for a complete in depth look at the code unfortunately. Thanks though, guys.

OK... I'll give it a try. Thanks guys.

Even if that means increasing the size of the interrupt function? I guess the reduced overhead would compensate for the added bloat? Thanks.

I will admit that I am new to C programming, but it has always been my understanding that, in any language, small functions are better than one large main block of code. In the alarm keypad program that I wrote (which works well... thank you) CCS complains that I am calling functions from within the interrupt routines. It suggests that I "inline" them. I was just wondering why? Thanks...

I wrote a program in CCS and I am trying to write an article for a magazine. I want to offer the compiled code so that others can program their own chips. Is the .out file the only file in the Release directory that I need to offer or would I need to include all of the files in that directory? I am going to offer the source code as well, but I thought offering the compiled version might make it easier for newbies (like me ) Thanks.

@rickta59 I got the backpack working (crystal on the PIC wasn't making good connection to one of the pins ) but I'm still having trouble with your code. I tried both yours and the software approach. The software approach seems to work fine, but I'd rather use yours if possible - it's simpler and more straight forward. So that I could tell what it was doing, I put the print("HELLO WORLD") inside of a perpetual loop with a delay between the print commands. It does send the data to the backpack, but it only displays "HELLO WO []" (where [] is a solid block on the LCD) over and over. For

Oh, so that is what they mean (silkscreened on the board) by HW UART and SW UART? I thought that meant HardWare Flow Control and SoftWare Flow Control. OK... I get that, but it is more confusing.

@rickta59 In your code, I see that P1.1=RXD and P1.2=TXD in your comments, but I can't figure out how that is determined. It looks like the initialization routine is setting both bits 1 & 2 of both P1SEL and P1SEL2 and clearing both bits 1 and 2 of P1DIR. What actually determines that 1.1 is receive and 1.2 is transmit? I only ask because in the demo, the comments say that 1.2 is receive and 1.1 is transmit, although I really don't see what determines which is which in the demo code, either. Never mind... I just saw in the datasheet that 1.1 is reserved as receive and 1.2 is re

OK.. I don't know what I am doing wrong. I loaded the code you provided, rick, on the chip and hooked everything up. Nothing. Just for a goof, I loaded up HyperTerminal and sure enough, there was no data received there either (with the msp in the eval board). So I loaded the code I had, the demo code from the "Getting Started" guide, and ran HyperTerminal. That data (IN, LO and HI) did show up in the terminal. I tried using that code with the backpack and LCD display, but still nothing. So, I assume that the backpack isn't working for some reason, but neither did the UART code either.

Thanks. I downloaded the calculator (luckily it runs under wine). I'll keep that handy.

I suppose the 2452 doesn't support UART? Build failed with msp430g2452,h so I built the code including the msp430g2553.h instead of msp430.h and I will try it out after dinner.... <crossing fingers> I'll try to wrap my brain around what is going on later tonight if this works. Thanks.

I'm not sure that the backpack actually has to send data back to the processor. This is what I am using: http://www.best-microcontroller-projects.com/serial-lcd.html I wouldn't see why it would need to read data from the processor, but...

Other than I have NO idea what I am doing as far as the UART goes? No... I don't even get the software approach but that is what the "Getting Started" guide uses.

I'm sorry... I should have posted this: //*********************************************************** // Lab7.c Software UART // // SFB 1/2012 //*********************************************************** #include <msp430g2553.h> #ifndef TIMER0_A1_VECTOR #define TIMER0_A1_VECTOR TIMERA1_VECTOR #define TIMER0_A0_VECTOR TIMERA0_VECTOR #endif #define TXD BIT1 // TXD on P1.1 #define RXD BIT2 // RXD on P1.2 #define Bitime 13*4 // 0x0D unsigned int TXByte; unsigned char BitCnt; volatile long

I saw that last night, but I didn't see how it related to the example in the "Getting Started" guide...

My latest effort is this: I build an LCD serial backpack based on a PIC16F877. I want to interface it to the MSP430 so the MSP can drive the LCD module. I figure I can connect the TX line of the MSP directly to the (5v) RX PIC, and I am using a 10K-10K divider to connect to the TX line of the PIC to the RX of the MSP. My problem is the code. I have gone through lab 7 in the "Getting Started" book, and I have looked at the USART / UART section of the User's Guide until I was nauseous, but I am still confused. I understand the BitCnt variable; I understand loading TxByte and adding the s

OK.. so I found this on my own. Here's what I found in case anyone else has the same questions I did: The Python script used to generate the look up table is found here: http://reprap.svn.sourceforge.net/viewvc/reprap/trunk/reprap/firmware/Arduino/utilities/createTemperatureLookup.py?view=markup&pathrev=3448 This is the original schematic that goes with the script: http://reprap.org/wiki/Temperature_Sensor_2_0#Schematic The values for R0, T0 and Beta are found in your thermistor's datasheet, where T0 typically equals 25 (degrees Celsius) and R0 is the thermistor's resistance

I just wanted to say Thank You to everyone here. My first project with the MSP430 looked like Mount Kilimanjaro when I started, but with y'alls help, my shop is now fully protected by an alarm system designed, built and programmed by me. Now off to my next project - a Beta Fish heater. And then... ?? Who knows! Thank You!!!

Your code looks like what I am looking for, but I am trying to adapt this to an Ametherm nt03 50169 thermistor ( www.ametherm.com/datasheetspdf/NT03%2050169.pdf ). I see on the datasheet for your thermistor where you get the values for r0, t0 and beta but I'm not sure about the r1, r2 and max adc. Also, going on your datasheet, I can't figure out how you built the look up table. Maybe you could explain it... kinda of Thermistor Look-up Tables for Dummies Thanks...

I'm sorry guys... I forgot to follow this topic. I will check those out. Thanks...