wilywyrm

I assume you mean the 2452 and the 2553?
 
Basically what you said was right, except the 2553 has a USCI (Universal Serial Communication Interface) so you can talk to a computer through the hardware UART or to other chips via SPI or I2C. For chips without a hardware UART, you have to implement it in software, and instead of a USCI, you would have a USI (Universal Serial Interface) for just SPI and I2C communication.
 
EDIT: At 600+ pages, I personally wouldn't print it because eventually you will miss the Ctrl-F ability of a pdf.

COMIO is a protocol and application I am developing that allows IO control over a serial line.
 
http://david-adam-coffey.com/blog/comio-shell
 
https://github.com/COGSMITH/COMIO/blob/master/COMIO/MSP430/COMIO.C
 
 

Hi everyone! Haven't posted here in a long time, so I thought I'd share something I'm working on.
 
Picture this: you and your friends have gotten together for some sweet pen-and-paper roleplaying action. It's the first round of combat, and everyone's getting ready to roll initiative. But then disaster strikes! The family dog has eaten the d20, and you were all sharing the same set of dice because YOUR FRIENDS ARE ALL TOO CHEAP TO BUY THEIR OWN!
 
The obvious solution is to buy sets for them and give it to them for Christmas or something, but there's no fun in that.
 
Cue MSPDice, a fully fledged dice set in a compact 2"x2" frame.
The MCU used will be the MSP430G2231 (DIP and TSSOP footprints both on board), which will push out the results of a d4, d6, d8, d10, d12, d20, or d% roll to a 4-digit common anode 7-segment display through a 74HC595 shift register.
I have tried to break out the pins of the MSP430 so that it fits the launchpad's spacing (4.5cm, is it?), but haven't really checked it. at 1.8". Thanks Rob!
 
I'm using mspgcc and mspdebug for programming, KiCAD for board design, and GerbV to look at the gerbers on a linux box. You know, the whoooole open-source enchilada.
 

#include #include //#define DOUT BIT6 //#define SCLK BIT5 // Data Output and System clock are still P1.6 and 1.5, though. That's the hardware USI #define LATP BIT0 // the Latch Pin on the 595, pin 0 (port 1) #define EN BIT7 // the pin connected to the 595's Output ENable 7 (port 1) // the pins the P-FETS are hooked up to (port 1) const unsigned char digit[4] = {BIT1, BIT2, BIT3, BIT4}; volatile unsigned char a = 0; /*#define DIGIT1 BIT1 #define DIGIT2 BIT2 #define DIGIT3 BIT3 #define DIGIT4 BIT4*/ #define DIGITS BIT1+BIT2+BIT3+BIT4 // for convenience of addressing #define NEXT BIT6 // the pin hooked up to the NEXT button, pin 6 (port 2) #define PREV BIT7 // " " 7 (port 2) // 595 hooked up Q0-a, Q1-b,... Q7-DP. Inverted because 595 is sinking current, and bit order is DP, g, f,... a. const unsigned char digitMask[11] = {0xC0, 0xF9, 0xA4, 0xB0, 0x99, 0x92, 0x82, 0xF8, 0x80, 0x90, 0xA1}; // last digit is d, as in d20. //volatile unsigned char show = 0; // brotip: short is NOT a short. It's 16 bits. volatile unsigned char i = 0; volatile unsigned char dieType = 6; // remember the kind of dice we last used! int main(void) { WDTCTL = WDTPW + WDTHOLD; // stop WD timer BCSCTL3 |= LFXT1S_2; // LFXT1 = VLO IFG1 &= ~OFIFG; // Clear OSCFault flag __bis_SR_register(SCG1 + SCG0); // Stop DCO BCSCTL2 = SELM_2 + SELS; // MCLK = VLO, SMCLK = VLO // initialize all the pins and their resistors P1DIR |= 0xFF; // I was going to add all the pin values, but they're all outputs. P1SEL = 0x00; // All pins on Port 1 are either GPIO or the modules they're connected to don't care. P2SEL = 0x00; // select GPIO functions P2DIR = 0x00; // make the XIN/XOUT pins GPIO Inputs rather than CLK inputs P2REN = NEXT + PREV; // enable internal pull resistors on button inputs P2IES = 0x00; // trigger an interrupt for the button pins on a low-to-high transition. Change this to 0xFF in the interrupt routine because we need to see when they stop pressing the button. P1OUT |= LATP + DIGITS + EN; // make LATP, DIGITx, EN high P2OUT = 0x00; // make the button input resistors pull down P2IE = 0xFF; // enable the interrupts, but hey, TODO: code the interrupt HANDLERS... P1OUT &= ~EN; // enable 595 output (by making the EN pin low) USICTL0 |= USIPE6 + USIPE5 + USIMST + USIOE; // enable SPI out, SPI SCLK, SPI Master, and data output USICTL1 |= USICKPH + USIIE; // Counter interrupt, flag remains set USICKCTL = USIDIV_1 + USISSEL_1; // divide clock source by 2 to get the clock for USI and select SMCLK as the source for USI clock // USI will offset the byte we're shifting out by 3 bits if you don't divide ACLK by 2, so 1 -> 3 and 6 -> 11? Strange. Probably a startup problem. USISRL = 0xFF; // start up cleared USICTL0 &= ~USISWRST; // allow the USI to function CCTL0 = CCIE; // CCR0 interrupt enabled CCR0 = 3000; // timer is on ACLK/2 (7kHz, 2000/(7000 cycles/s * 1s) ~= a period of .286 s.) TACTL = TASSEL_1 + MC_1 + ID_1; // ACLK, Up mode, div ACLK by 2, ~= 7kHz // TimerA doesn't like to have TASSEL_2 (SMCLK) set, so we just stuck it into ACLK, which comes from the same source (ACLK) __bis_SR_register(LPM3_bits + GIE); // Enter LPM0 w/ interrupt } // Timer A0 interrupt service routine //#pragma vector=TIMERA0_VECTOR //__interrupt void Timer_A (void) // so much for that, thanks a lot mspgcc interrupt(TIMERA0_VECTOR) Timer_A(void) { P1OUT &= ~LATP; // latch goes low USISRL = digitMask[i]; // write the byte to the USI i++; i %= 11; P1OUT |= DIGITS; USICNT = 8; // USI shifts out 8 bits (that byte we just entered) P1OUT &= ~digit[a]; a++; a %= 4; P1OUT |= LATP; // latch goes high and previous instructions give time for USI to shift out }
 
Typical usage should go like this:


[*:erp26ks3]Type of die to roll (dX)
[*:erp26ks3]Number of dice to roll (YdX)
[*:erp26ks3]Randomization display (Raw random output is pushed to the display)
[*:erp26ks3]Result display
 
I've put up this post mainly because it forces me to have a clear picture of how everything will fit together, but if anyone has any suggestions, say something before I send this design off to Seeed at the end of the week! This needs to be as awesome as possible so my friends stop borrowing my dice!
 
Most recent edit: R4r3. Added a DIP footprint for the 74HC595. Every major component but the buttons can now be a through-hole part.
 
(Oh, and I did finish that robot arm from earlier. One of these days I'm going to clean it up and put up the board design on github, along with the dice board, but Right now the code's disgraceful.)
mspDice.pdf

mspDice.zip

LaunchPad headers are 1.80" apart.

Hi everyone! Haven't posted here in a long time, so I thought I'd share something I'm working on.
 
Picture this: you and your friends have gotten together for some sweet pen-and-paper roleplaying action. It's the first round of combat, and everyone's getting ready to roll initiative. But then disaster strikes! The family dog has eaten the d20, and you were all sharing the same set of dice because YOUR FRIENDS ARE ALL TOO CHEAP TO BUY THEIR OWN!
 
The obvious solution is to buy sets for them and give it to them for Christmas or something, but there's no fun in that.
 
Cue MSPDice, a fully fledged dice set in a compact 2"x2" frame.
The MCU used will be the MSP430G2231 (DIP and TSSOP footprints both on board), which will push out the results of a d4, d6, d8, d10, d12, d20, or d% roll to a 4-digit common anode 7-segment display through a 74HC595 shift register.
I have tried to break out the pins of the MSP430 so that it fits the launchpad's spacing (4.5cm, is it?), but haven't really checked it. at 1.8". Thanks Rob!
 
I'm using mspgcc and mspdebug for programming, KiCAD for board design, and GerbV to look at the gerbers on a linux box. You know, the whoooole open-source enchilada.
 

#include #include //#define DOUT BIT6 //#define SCLK BIT5 // Data Output and System clock are still P1.6 and 1.5, though. That's the hardware USI #define LATP BIT0 // the Latch Pin on the 595, pin 0 (port 1) #define EN BIT7 // the pin connected to the 595's Output ENable 7 (port 1) // the pins the P-FETS are hooked up to (port 1) const unsigned char digit[4] = {BIT1, BIT2, BIT3, BIT4}; volatile unsigned char a = 0; /*#define DIGIT1 BIT1 #define DIGIT2 BIT2 #define DIGIT3 BIT3 #define DIGIT4 BIT4*/ #define DIGITS BIT1+BIT2+BIT3+BIT4 // for convenience of addressing #define NEXT BIT6 // the pin hooked up to the NEXT button, pin 6 (port 2) #define PREV BIT7 // " " 7 (port 2) // 595 hooked up Q0-a, Q1-b,... Q7-DP. Inverted because 595 is sinking current, and bit order is DP, g, f,... a. const unsigned char digitMask[11] = {0xC0, 0xF9, 0xA4, 0xB0, 0x99, 0x92, 0x82, 0xF8, 0x80, 0x90, 0xA1}; // last digit is d, as in d20. //volatile unsigned char show = 0; // brotip: short is NOT a short. It's 16 bits. volatile unsigned char i = 0; volatile unsigned char dieType = 6; // remember the kind of dice we last used! int main(void) { WDTCTL = WDTPW + WDTHOLD; // stop WD timer BCSCTL3 |= LFXT1S_2; // LFXT1 = VLO IFG1 &= ~OFIFG; // Clear OSCFault flag __bis_SR_register(SCG1 + SCG0); // Stop DCO BCSCTL2 = SELM_2 + SELS; // MCLK = VLO, SMCLK = VLO // initialize all the pins and their resistors P1DIR |= 0xFF; // I was going to add all the pin values, but they're all outputs. P1SEL = 0x00; // All pins on Port 1 are either GPIO or the modules they're connected to don't care. P2SEL = 0x00; // select GPIO functions P2DIR = 0x00; // make the XIN/XOUT pins GPIO Inputs rather than CLK inputs P2REN = NEXT + PREV; // enable internal pull resistors on button inputs P2IES = 0x00; // trigger an interrupt for the button pins on a low-to-high transition. Change this to 0xFF in the interrupt routine because we need to see when they stop pressing the button. P1OUT |= LATP + DIGITS + EN; // make LATP, DIGITx, EN high P2OUT = 0x00; // make the button input resistors pull down P2IE = 0xFF; // enable the interrupts, but hey, TODO: code the interrupt HANDLERS... P1OUT &= ~EN; // enable 595 output (by making the EN pin low) USICTL0 |= USIPE6 + USIPE5 + USIMST + USIOE; // enable SPI out, SPI SCLK, SPI Master, and data output USICTL1 |= USICKPH + USIIE; // Counter interrupt, flag remains set USICKCTL = USIDIV_1 + USISSEL_1; // divide clock source by 2 to get the clock for USI and select SMCLK as the source for USI clock // USI will offset the byte we're shifting out by 3 bits if you don't divide ACLK by 2, so 1 -> 3 and 6 -> 11? Strange. Probably a startup problem. USISRL = 0xFF; // start up cleared USICTL0 &= ~USISWRST; // allow the USI to function CCTL0 = CCIE; // CCR0 interrupt enabled CCR0 = 3000; // timer is on ACLK/2 (7kHz, 2000/(7000 cycles/s * 1s) ~= a period of .286 s.) TACTL = TASSEL_1 + MC_1 + ID_1; // ACLK, Up mode, div ACLK by 2, ~= 7kHz // TimerA doesn't like to have TASSEL_2 (SMCLK) set, so we just stuck it into ACLK, which comes from the same source (ACLK) __bis_SR_register(LPM3_bits + GIE); // Enter LPM0 w/ interrupt } // Timer A0 interrupt service routine //#pragma vector=TIMERA0_VECTOR //__interrupt void Timer_A (void) // so much for that, thanks a lot mspgcc interrupt(TIMERA0_VECTOR) Timer_A(void) { P1OUT &= ~LATP; // latch goes low USISRL = digitMask[i]; // write the byte to the USI i++; i %= 11; P1OUT |= DIGITS; USICNT = 8; // USI shifts out 8 bits (that byte we just entered) P1OUT &= ~digit[a]; a++; a %= 4; P1OUT |= LATP; // latch goes high and previous instructions give time for USI to shift out }
 
Typical usage should go like this:


[*:erp26ks3]Type of die to roll (dX)
[*:erp26ks3]Number of dice to roll (YdX)
[*:erp26ks3]Randomization display (Raw random output is pushed to the display)
[*:erp26ks3]Result display
 
I've put up this post mainly because it forces me to have a clear picture of how everything will fit together, but if anyone has any suggestions, say something before I send this design off to Seeed at the end of the week! This needs to be as awesome as possible so my friends stop borrowing my dice!
 
Most recent edit: R4r3. Added a DIP footprint for the 74HC595. Every major component but the buttons can now be a through-hole part.
 
(Oh, and I did finish that robot arm from earlier. One of these days I'm going to clean it up and put up the board design on github, along with the dice board, but Right now the code's disgraceful.)
mspDice.pdf

mspDice.zip

Hi everyone! Haven't posted here in a long time, so I thought I'd share something I'm working on.
 
Picture this: you and your friends have gotten together for some sweet pen-and-paper roleplaying action. It's the first round of combat, and everyone's getting ready to roll initiative. But then disaster strikes! The family dog has eaten the d20, and you were all sharing the same set of dice because YOUR FRIENDS ARE ALL TOO CHEAP TO BUY THEIR OWN!
 
The obvious solution is to buy sets for them and give it to them for Christmas or something, but there's no fun in that.
 
Cue MSPDice, a fully fledged dice set in a compact 2"x2" frame.
The MCU used will be the MSP430G2231 (DIP and TSSOP footprints both on board), which will push out the results of a d4, d6, d8, d10, d12, d20, or d% roll to a 4-digit common anode 7-segment display through a 74HC595 shift register.
I have tried to break out the pins of the MSP430 so that it fits the launchpad's spacing (4.5cm, is it?), but haven't really checked it. at 1.8". Thanks Rob!
 
I'm using mspgcc and mspdebug for programming, KiCAD for board design, and GerbV to look at the gerbers on a linux box. You know, the whoooole open-source enchilada.
 

#include #include //#define DOUT BIT6 //#define SCLK BIT5 // Data Output and System clock are still P1.6 and 1.5, though. That's the hardware USI #define LATP BIT0 // the Latch Pin on the 595, pin 0 (port 1) #define EN BIT7 // the pin connected to the 595's Output ENable 7 (port 1) // the pins the P-FETS are hooked up to (port 1) const unsigned char digit[4] = {BIT1, BIT2, BIT3, BIT4}; volatile unsigned char a = 0; /*#define DIGIT1 BIT1 #define DIGIT2 BIT2 #define DIGIT3 BIT3 #define DIGIT4 BIT4*/ #define DIGITS BIT1+BIT2+BIT3+BIT4 // for convenience of addressing #define NEXT BIT6 // the pin hooked up to the NEXT button, pin 6 (port 2) #define PREV BIT7 // " " 7 (port 2) // 595 hooked up Q0-a, Q1-b,... Q7-DP. Inverted because 595 is sinking current, and bit order is DP, g, f,... a. const unsigned char digitMask[11] = {0xC0, 0xF9, 0xA4, 0xB0, 0x99, 0x92, 0x82, 0xF8, 0x80, 0x90, 0xA1}; // last digit is d, as in d20. //volatile unsigned char show = 0; // brotip: short is NOT a short. It's 16 bits. volatile unsigned char i = 0; volatile unsigned char dieType = 6; // remember the kind of dice we last used! int main(void) { WDTCTL = WDTPW + WDTHOLD; // stop WD timer BCSCTL3 |= LFXT1S_2; // LFXT1 = VLO IFG1 &= ~OFIFG; // Clear OSCFault flag __bis_SR_register(SCG1 + SCG0); // Stop DCO BCSCTL2 = SELM_2 + SELS; // MCLK = VLO, SMCLK = VLO // initialize all the pins and their resistors P1DIR |= 0xFF; // I was going to add all the pin values, but they're all outputs. P1SEL = 0x00; // All pins on Port 1 are either GPIO or the modules they're connected to don't care. P2SEL = 0x00; // select GPIO functions P2DIR = 0x00; // make the XIN/XOUT pins GPIO Inputs rather than CLK inputs P2REN = NEXT + PREV; // enable internal pull resistors on button inputs P2IES = 0x00; // trigger an interrupt for the button pins on a low-to-high transition. Change this to 0xFF in the interrupt routine because we need to see when they stop pressing the button. P1OUT |= LATP + DIGITS + EN; // make LATP, DIGITx, EN high P2OUT = 0x00; // make the button input resistors pull down P2IE = 0xFF; // enable the interrupts, but hey, TODO: code the interrupt HANDLERS... P1OUT &= ~EN; // enable 595 output (by making the EN pin low) USICTL0 |= USIPE6 + USIPE5 + USIMST + USIOE; // enable SPI out, SPI SCLK, SPI Master, and data output USICTL1 |= USICKPH + USIIE; // Counter interrupt, flag remains set USICKCTL = USIDIV_1 + USISSEL_1; // divide clock source by 2 to get the clock for USI and select SMCLK as the source for USI clock // USI will offset the byte we're shifting out by 3 bits if you don't divide ACLK by 2, so 1 -> 3 and 6 -> 11? Strange. Probably a startup problem. USISRL = 0xFF; // start up cleared USICTL0 &= ~USISWRST; // allow the USI to function CCTL0 = CCIE; // CCR0 interrupt enabled CCR0 = 3000; // timer is on ACLK/2 (7kHz, 2000/(7000 cycles/s * 1s) ~= a period of .286 s.) TACTL = TASSEL_1 + MC_1 + ID_1; // ACLK, Up mode, div ACLK by 2, ~= 7kHz // TimerA doesn't like to have TASSEL_2 (SMCLK) set, so we just stuck it into ACLK, which comes from the same source (ACLK) __bis_SR_register(LPM3_bits + GIE); // Enter LPM0 w/ interrupt } // Timer A0 interrupt service routine //#pragma vector=TIMERA0_VECTOR //__interrupt void Timer_A (void) // so much for that, thanks a lot mspgcc interrupt(TIMERA0_VECTOR) Timer_A(void) { P1OUT &= ~LATP; // latch goes low USISRL = digitMask[i]; // write the byte to the USI i++; i %= 11; P1OUT |= DIGITS; USICNT = 8; // USI shifts out 8 bits (that byte we just entered) P1OUT &= ~digit[a]; a++; a %= 4; P1OUT |= LATP; // latch goes high and previous instructions give time for USI to shift out }
 
Typical usage should go like this:


[*:erp26ks3]Type of die to roll (dX)
[*:erp26ks3]Number of dice to roll (YdX)
[*:erp26ks3]Randomization display (Raw random output is pushed to the display)
[*:erp26ks3]Result display
 
I've put up this post mainly because it forces me to have a clear picture of how everything will fit together, but if anyone has any suggestions, say something before I send this design off to Seeed at the end of the week! This needs to be as awesome as possible so my friends stop borrowing my dice!
 
Most recent edit: R4r3. Added a DIP footprint for the 74HC595. Every major component but the buttons can now be a through-hole part.
 
(Oh, and I did finish that robot arm from earlier. One of these days I'm going to clean it up and put up the board design on github, along with the dice board, but Right now the code's disgraceful.)
mspDice.pdf

mspDice.zip

I have to say, I don't think typing all that out will save anyone any time.

While that does work, it was only designed for the 1xx generation of MSP430.
 
As a general practice, I'd recommend instead getting the family user guide for the specific chip (in the case of the MSP430G2553, go to the mcu homepage, and download MSP430x2xx Family User's Guide revision H). In the UART chapter for your chip, there'll usually be a table of "Typical Baud Rates and Errors", which lists the sub-register settings for a specific clock. There are a lot of UART alternatives across the MSP430 line, and looking in the guide rather than using a script will help keep you aware of any inconsistencies between them. (I was surprised to learn that the eUSCI UART on the FRAM parts has a few differences, including recommendation of UCOS16 and a new register field.)
 
There are a variety of UART configuration examples for different UART peripherals in the platform support directories of test430. If you use standard DCO rates (like the pre-calibrated ones), and SMCLK or a derivative thereof as the UART clock, calibration is pretty straightforward. Keep in mind that while "32K" in crystal-speak is really 32 kiHz or 32.768 kHz or 2^15 Hz, 1MHz is really 10^6Hz and never 2^22Hz. This can have a significant impact on error rate.
 
One other thing to keep in mind: in a lot of cases, the crystal doesn't contribute to the DCO unless the XIN/XOUT port pins are correctly configured in addition to the relevant clock register settings. demo/clocks in test430 configures and validates the crystal on a launchpad; see the comments. I seem to recall noticing that if this isn't done, a brought-to-GPIO ACLK doesn't actually tick unless it's reconfigured to use VLOCLK, at least on the value-line devices, but I don't know what impact that might have on internal use. I alway use SMCLK to control a UART; the only reason I can think of to use ACLK is if you're doing interrupt-driven I/O in low-power mode using DMA, and don't want to wait for the DCO to re-stabilize.

The easiest way to deal with the baud rate registers is to use this page:
 
http://mspgcc.sourceforge.net/baudrate.html
 
http://mspgcc.sourceforge.net/cgi-bin/msp-uart.pl?clock=32768&baud=9600&submit=calculate
Seems to yield:
 
UBR00=0x03; UBR10=0x00; UMCTL0=0x29; /* uart0 32768Hz 9637bps */
 
I haven't tried the setting above so I can't vouch for it. I'm still trying to understand the proper way to use these registers also.
I've looked at the msp-uart.pl perl code and compared it to another site on the net that uses an Excel spreadsheet
and they produce different results and use different algorithms. If you can set your MCU_FREQ to be a multiple
of the baud rate you want to use you can ignore all the modulation. Using a 1.2288 Mhz clock frequency the cycle count between bits would be an even multiple of 9600 so the UBR00 would be 1228800/9600 = 128.
 
-rick

No. Hence the assumption that the first one (or several) are not being correctly decoded by the PC, possibly due to clock differences. I didn't bother sending a different character on each iteration to see which one got through first, and I've shut down my development machine for the night.
 
The spew shouldn't be an issue at 9600, but it was really just a proof of concept (note that I use the HID interface rather than the tty interface, as noted here, which may be is less susceptible to serial port instabilities). If the possibility bothers you, put a delay in the loop; the point is to see whether you do start getting characters out or not. If not, there's something else wrong: your 32kiHz clock isn't, or your jumpers are wrong, or other things. That you said the demo code from TI worked suggests those aren't an issue.

Just start by sitting in a loop waiting for a request. Once you receive something you can start sending back your position data.
 
This seems to work:
 
main.cpp

/** * main.cpp - swserial/timerserial/usciserial Serial Asynch test driver. * * To test: use putty and connect to /dev/ttyACM0 at 9600 Baud * */ #include #include #include "serial.h" #define MCLK_FREQ 16000000UL /* run @16MHz */ /** * typedef Serial - start of a simple serial wrapper class */ typedef struct { /** * begin() - initialize serial port, sets registers, port direction, and * alternative port features as required by implementing serial routines. * Depending on the implementing method, you may not be able to use * arbitrary rx/tx pins the software only implementation is the only * version capable of using any arbitrary pin. * * baudRate - bits/sec default: 9600 * rxPin - receive pin default: 1 (P1.1) ( g2553 defaults ) * txPin - transmit pin default: 2 (P1.2) */ static void begin(uint32_t baud = 9600, int rxPin = 1, int txPin = 2) { init_serial(1 << txPin, 1 << rxPin, MCLK_FREQ / baud, (MCLK_FREQ / baud) >> 8); } /** * puts - writes the string s to the serial output stream without a trailing * newline character. Note: this differs from the ISO standard puts() * function which appends a newline character. ` */ static void puts(register const char *s) { while(*s) { putchar(*s++); } } } serial_t; static serial_t Serial; static void initMCLK() { #ifdef __MSP430FR5739 CSCTL0_H = 0xA5; // CS_KEY CSCTL1 |= DCOFSEL0 + DCOFSEL1; // Set max. DCO setting CSCTL2 = SELA_3 + SELS_3 + SELM_3; // set ACLK = MCLK = DCO CSCTL3 = DIVA_0 + DIVS_0 + DIVM_0; // set all dividers #else // Use 16MHz DCO factory calibration DCOCTL = 0; BCSCTL1 = CALBC1_16MHZ; DCOCTL = CALDCO_16MHZ; #endif } int main(void) { WDTCTL = WDTPW | WDTHOLD; /* Disable watchdog */ initMCLK(); // configure serial device using defaults Serial.begin(9600); //__eint(); // we enable interrupts after user setup() to give them a chance to customize // if you are using an FTDI or other reasonable USB-serial chip you can output // serial data at reset. If you want to use the Launchpad /dev/ttyACM0 you have // to wait for a request before spewing. #if 0 printf("\rWelcome to msp430 uNix! %s %s %d, %d:%d %s\r\nlogin: ", "Fri", "Oct", 9, 11, 25, "AM"); Serial.puts("\r\n# "); #endif int c; int nCharCnt = 0; for (; { c = getchar(); // do some minimum line control to handle backspace if ( c != 127 ) { putchar(c); nCharCnt++; } else { if (nCharCnt > 0) { putchar(c); --nCharCnt; } } // append newline on CR if ( c == '\r' ) { Serial.puts("\n# "); nCharCnt = 0; } // restart processor on CTRL-D if ( c == 0x04 /*CTRL-D*/ ) { WDTCTL = WDTHOLD; // restart by setting the WDTCTL without a password } } return 0; }
 
usci_serial.c

/* * usci_serial.c - USCI implementations of init_serial(), getchar(), putchar() and puts() * * Created on: Oct 30, 2011 * Author: kimballr - rick@kimballsoftware.com */ #include #include #include "serial.h" /** * init_serial(txPinMask, rxPinMask, bitDuration, durMod) * * Really simple use of the hardware UART so that it will be * compatible with the our simple software ones. We setup the * hardware UART using the pins and bit duration provided. * * This code doesn't use any interrupts. Just simple polling * to decide when to receive or transmit. * */ void init_serial(int txPinMask, int rxPinMask, unsigned duration, unsigned durmod) { // Use UART defaults for most things. // LSB // 8-N-1 ( 8 bit, NO parity, 1 Stop bit) UCA0CTL1 |= UCSSEL_2; // use SMCLK as source for USCI clock UCA0BR0 = duration; // bit duration is MCLK/BAUD UCA0BR1 = durmod; // (MCLK/BAUD) >> 8 #ifdef __MSP430FR5739 P2SEL1 |= BIT0 | BIT1; P2SEL0 &= ~(BIT0 | BIT1); #else P1SEL = rxPinMask | txPinMask; // P1.1=RXD, P1.2=TXD P1SEL2 = rxPinMask | txPinMask; // P1.1=RXD, P1.2=TXD #endif UCA0CTL1 &= ~UCSWRST; // Initialize USCI state machine } /** * int getchar() - read next char from serial port rx pin * * */ int getchar(void) { // sit and spin waiting for baudot heh I make myself laugh while (!(UC0IFG & UCA0RXIFG)) { ; // busywait until USCI_A0 RX buffer is ready } return UCA0RXBUF; // return RXed character } /** * putchar(int c) - write char to serial port * */ int putchar(int c) { // make sure previous character has been sent // before trying to send another character while (!(UC0IFG & UCA0TXIFG)) { ; // busywait until USCIA0TX buffer is ready } UCA0TXBUF = (uint8_t) c; // TX character return 0; }
 
serial.h

//------------------------------------------------------------------------ // serial.h - function declarations for compact asm serial routines //------------------------------------------------------------------------ #ifdef __cplusplus extern "C" { #endif void init_serial(int txPinMask, int rxPinMask, unsigned duration, unsigned durMod); int getchar(void); int putchar(int); #ifdef __cplusplus } /* extern "C" */ #endif
 
To compile just use:
 

msp430-gcc -O0 -g -mmcu=msp430g2553 main.cpp usci_serial.c -o main.elf

If you do that on a linux box, it is going to overflow the serial ACM buffer and the kill the port. It will just be dead.
On linux, you should be waiting till you receive something before you start spewing.

Impolitely following up on my own post: one of the best things about test430 is scripts/ez430, which allows you to monitor serial output from the launchpad using the USB HID interface, bypassing all the problems with Linux tty-style serial support of the TUSB3410. You can even leave this running in one window while you're using mspdebug to program the board in another. You will need the latest Python USB bindings; information is in the README.

Has anyone seen this:MSP430ware?
It has a bunch of functions for the msp peripherals
 
(Not sure if this is the right place to post it)

Hello guys..This has been at the back of my head for a long time. So lets start at Booster Packs.

43oh will be glad to sponsor your initial Booster Pack[bP] development. $10 will be awarded to you to make initial PCBs or purchase parts. It's not much, but it is an incentive. A max of two BPs will be sponsored/month.

Your selection depends on the following factors:
[1] Be a member on this forum for at least 4 weeks and have a minimum of 20 posts.
[2] A thread in the Booster Pack sub-forum.
[3] Create initial schematics and layouts in the thread, including selection of parts.
[4] BP usable by a large number of people.
[5] Open source your schematic and PCB Files. Git it if you have to, but keep a copy on the Forum.
[6] Some amount of test code if the success of your Booster Pack depends on it.
[7] A voting system for the community to decide if the BP needs to be sponsored. I'm not sure how many votes make a good BP. If there are enough "Yes" votes(more than 50%) than "No"... your sponsored.

I can't think of anything else.I'd also like to put a donate button for members to donate towards the pool. Would there be any interest in this? Donations will be made public to ensure transparency. I would appreciate the communities response to the idea. This will also help increase the number of sponsorships/month.

There is no liability once you are sponsored(since the schematics/PCB files have been shared). It's a matter of mutual understanding that you will not run away with the boards. Maybe give them away with the interested party paying for shipping.

One thing to keep in mind is to keep this KISS - Keep It Simple, Stupid.
Also, no arguing, but intelligent debate when voting. This is NOT a competition.

-----------------------------------------------------------------------------------------------------------------------------
Update: Apparently the samples are out of stock, even though it doesn't mention it on the Maxim website.
-----------------------------------------------------------------------------------------------------------------------------
 
Saw this over on Dangerous Prototypes but figured I'd post it here as well. Apparently this was posted in April and there are 1000 available, but I ordered one today. You do unfortunately need a business or educational institution e-mail to be able to order one.
 
http://www.maxim-ic.com/landing/?lpk=585
 
This versatile EV kit allows you to measure any analog signal source directly from your computer. Just download the MAXADCLite GUI software (PC only), connect your analog input signal, and start measuring. (Power is provided through the USB port.)
 
Key Benefits
 
* Smallest 12-bit SAR ADC
o 2 channels
o Integrated reference
o 1.9mm x 2.2mm package
* Lowest system cost
o Integrated multiplexer, FIFO, and sequencer
o Same price as competitive stand alone ADCs
* Ultra-low power
o Active: 2

A complete combo-breaker, but
 
 

A complete combo-breaker, but
 
 

Glad you like it.
 
I did it in gimp, so its native format would be this xcf, but here's the exported psd. The png is here.

It may have been pointed out here before, but TI has a few FREE (breakout boards?) in the estore right now. The easiest way to find them is to just enter "free" in the estore's search box. At the moment, there are 2 op-amp modules, a buffer module, and an amplifier module. I don't have time to look in detail, but they ARE there, and they ARE free. Incl. shipping.
 
"Dem-buf-sot-1a - free" is the name/ part number of one of them. The description is "demonstration fixture"
Limit 3 is listed also.
 
Search "free" and you'll get a few dozen hits, most are priced $5.00, but a few are 0.00. I'm wondering if they rotate which ones are free occasionally, since the $5.00 ones also have free in the title.
 
Maybe someone with a bit more free time tonight can look into them, and give us some more info about it.
 
Btw, our friend kenneth finnegan (PhirePhly) has made a thermocouple amplifier board, he has a few spares he's willing to share with anyone who has a use for it. I don't mean to put words in his mouth, check out his blog for info. And once again, thanks Kenneth.

A complete combo-breaker, but
 
 

Found these sites after googling "ceramic capacitor code":http://www.electronics2000.co.uk/calc/capacitor-code-calculator.php
http://www.csgnetwork.com/capcodeinfo.html
http://en.wikipedia.org/wiki/Ceramic_capacitor
http://www.wjoe.com/capacitorinfo2.htm

This is what TI follows on their devices:
 
For a host SBW it is


[*:2o78w2yv]TXD
[*:2o78w2yv]VCC
[*:2o78w2yv]SBWTCK
[*:2o78w2yv]SBWTDIO
[*:2o78w2yv]GND
[*:2o78w2yv]RXD
 
Page 9 http://focus.ti.com/lit/ug/slau176d/slau176d.pdf
 
And for a device it is


[*:2o78w2yv]RXD
[*:2o78w2yv]VCC
[*:2o78w2yv]SBWTCK
[*:2o78w2yv]SBWTDIO
[*:2o78w2yv]GND
[*:2o78w2yv]TXD
 
Page 18 http://focus.ti.com/lit/ug/slau227e/slau227e.pdf

Anyone see this?
 
Ti Launchpad Student Guide and Manual
http://www.csit-sun.pub.ro/courses/cn1C ... nchPad.pdf
 
Also called the Getting Started with the MSP430 LaunchPad Workshop
http://processors.wiki.ti.com/index.php ... d_Workshop
 
Like a full out TI produced class curriculum. Student/hobbyist targeted instead of engineer targeted. Videos and Powerpoints too.

The SCK line for on MSP430G2231 is the same as P1.6, which is connected to LED2 on the Launchpad. SCK is supposed to be pulled up for I2C to work, therefore you will have to disconnect the jumper J5 - 1.
 
If you do not, LED2 will glow a faint green as it is would be connected to VCC through a pullup, and I2C will not work at all.
 
This took me a while to figure - I thought I'd share.