Jump to content
43oh

timotet

Members
  • Content Count

    223
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    timotet reacted to RobG in WIZpix - Internet enabled pixel controller with PoE   
    WIZpix is an internet enabled RGB pixel controller with built in PoE. 
     
    WIZpix uses W5500 internet appliance to connect to internet and MSP430F5172 MCU to control RGB pixels.
    Built-in DC/DC converter allows use of PoE, which eliminates need for directly connected power supply, ability to place controller far away from the outlet, and use of only one inexpensive CAT-5 cable. 
    It




  2. Like
    timotet reacted to alikian in Arduino Adapter Booster Pack for LaunchPad XL   
    Hi All,
     
    This my first prototype for Booster Pack that connect LaunchPad XL to Arduino Shields
    It convert 3.3V to 5 Bidirectionaly, I just test it with my own Arduino Shield with SPI works fine.
    I know board is too long and jumpers are not necessary, I will removed them.
     
    It will help Arduino Shields as BoosterPack.
     
    Thanks,
    Ali


  3. Like
    timotet reacted to enl in Quadrature encoders and interrupts   
    I would guess at bounce issue as well. Simplest solution is an RC filter. Several ways to do it, but I tend to avoid the simplest, which is putting a cap directly across the contacts, unless I know that it is a very limited use device, as this method tends to destroy the contacts quickly. A three resistor solution is better, and properly tuned generally satisfactory. (see attached MSpaint sketch) Adjust the cap as needed. The Tc as shown is about 1ms, which is my usual starting point.
     
    This is not the best way to go for production devices, but is quick and simple for a one off, and a good check for bounce issues.
     
    A better solution is to disable the interrupt for a while after the first one. Figure the first one will be the true, unbounced read for the other line. How long to disable? Depends on rate you expect the control to be turned at. If it is a 16posn unit, and figure maybe 2 rev per sec at breakneck speed (32 motions per sec), disable interrupt for 25ms  and you will catch the next.
     
    ANY debounce scheme can be sensitive to the half-step issue. Half way to the next click, then back. Is it counted? If the knob is held near half step, does it continually retrigger?
     
    I tend to prefer a state machine approach to reading quad encoders. Both lines to interrupt inputs, and set the interrupt enables based upon current state. That way, all bounce does is go back and forth between to adjacent states, until settling occurs to the final state. With mechanical switching, I still usually put an RC in if I can, as that reduces the need for quick response to the interrupts due to switch bounce, but the RC Tc can be short enough (maybe 20us, depending on circumstances) that the cap can be very small, sometimes lead capacitance being enough if the resistors are at the switches.

  4. Like
    timotet reacted to RobG in EduKit BoosterPack   
    After couple of years and many ideas, I have finally settled on a design for my experimenter's board. 
    Say hello to EduKit BoosterPack. 
     

     
    The EduKit BP comes with 1.8" color LCD and 8 accessory connectors. Each connector provides access to power and 2 or 4 MCU pins and are used to connect accessory boards. Those boards will allow user to perform tests and experiments, and could be used to teach about MCU's. There are also 4 jumpers on the board, which are used to change LCD's connections. LCD can use SPI1 (UCA0) or SPI2 (UCB0,) CS and D/C have also 2 possible connection options.
     

     
    Accessory boards can be simple, for example switch, LED, or potentiometer, or can be more complex, like shift register, mic with amp, sensors, MIDI, GPS.
     

     
    The EduKit is meant to be used with MSP430G2 LaunchPad (though it could be used with any other LP,) and will come with a library that will allow easy setup and use of LCD. User can write his code and then display results using one of the included functions (text, bar graph, etc.)
  5. Like
    timotet reacted to RobG in Geek Clock BoosterPack   
    Geek Clock's big brother is in town!
     
    The Gear Clock.
     
    72 LEDs, most likely MSP430G2553 + CC2500.
     

     

  6. Like
    timotet reacted to greeeg in ringLight. A WS2812 led based light for my 3d printer.   
    Cool project, these LEDs are so versatile
     
    Another option, is to place a high wattage resistor in series before your LDO.
    This could be done now, the resistor could be mounted on a small heatsink somewhere in your printer, and the then a cable can run from that to the LEDs.
     
    R = V/I = 5/0.5 = 10R
    P = 2.5W
     
    Then the LDO's power dissipation,
    V_drop = 7 - 5 = 2.
    P = 2 * 0.5 = 1 W.
     
    That is still high, but now a 3x improvement.
  7. Like
    timotet got a reaction from jsolarski in ringLight. A WS2812 led based light for my 3d printer.   
    I built a 3d printer last year and needed a small light to illuminate the build area, this is what I came up with.
    I call it the ringLight.

     
    I thought about using an Adafruit Neopixel ring, but due to the finished part being for a specific size I decided to roll
    my own. I used a MSP430G2452 in the TSSOP 14 pin package for the micro. I have to thank every one on the forum for
    the wealth of info related to the WS2812 leds, and a special thanks to @@oPossum for the led driver code he posted.
    The code is pretty straight forward. Once powered on the msp430 loads what ever value from flash that was
    used from the last time power was on, then waits for a button press. If the button gets pressed it will scroll through a few
    pre programmed colors or animations, per press. Then that value is re-written into flash for the next time.
     
    Here is the code:
    // 5/10/14 // For controlling the Mandelbots ringLight WS2812 leds // Thanks to Kevin Timmerman for the ws2811_hs.asm led driver code // Written by Larry Fogg and Tim Toliver // #include "stdint.h" #include "stdlib.h" #include <msp430g2452.h> void write_ws2811_hs(uint8_t *data, unsigned length, uint8_t pinmask); //prototype for ws2811_hs.asm #define button BIT3 #define ledPin BIT7 #define numColors 1972 static const uint8_t red[12] = { 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00 }; static const uint8_t green[12] = { 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00 }; static const uint8_t blue[12] = { 0x00, 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00, 0xFF }; static const uint8_t purple[12] = { 0, 128, 128, 0, 128, 128, 0, 128, 128, 0, 128, 128 }; static const uint8_t yellow[12] = { 0xFF, 0xFF, 0x00, 0xFF, 0xFF, 0x00, 0xFF, 0xFF, 0x00, 0xFF, 0xFF, 0x00 }; static const uint8_t orange[12] = { 0x80, 0xFF, 0x00, 0x80, 0xFF, 0x00, 0x80, 0xFF, 0x00, 0x80, 0xFF, 0x00 }; static const uint8_t steelBlue[12] = { 130, 70, 180, 130, 70, 180, 130, 70, 180, 130, 70, 180 }; static const uint8_t pink[12] = { 20, 255, 147, 20, 255, 147, 20, 255, 147, 20, 255, 147 }; static const uint8_t aqua[12] = { 255, 0, 255, 255, 0, 255, 255, 0, 255, 255, 0, 255 }; static uint8_t z[12]; //GRB values for 4 LEDs uint8_t pressCount; //keep track of button presses uint8_t buttonPressed = 1; //start with true so stored pressCount is executed //for writing flash uint8_t * Flash_ptr = (unsigned char *) 0x1040; //location to write in flash info segment C void millisecDelay(int delay) { int i; for (i=0; i<delay; i++) _delay_cycles(10000); //roughly 1 msec. calibrate this } #pragma vector=PORT1_VECTOR __interrupt void PORT1_ISR(void) { _disable_interrupts(); pressCount++; //increment button presses buttonPressed = 1; //true millisecDelay(300); //for button debounce P1IFG &= ~button; //clear interrupt flag _enable_interrupts(); } void writeFlash(unsigned char data){ _disable_interrupts(); FCTL1 = FWKEY + ERASE; //Set Erase bit FCTL3 = FWKEY; //Clear Lock bit *Flash_ptr = 0; //Dummy write to erase Flash segment FCTL1 = FWKEY + WRT; //Set WRT bit for write operation *Flash_ptr = data; //Write value to flash FCTL1 = FWKEY; //Clear WRT bit FCTL3 = FWKEY + LOCK; //Set LOCK bit _enable_interrupts(); } void loadLED (int ledNum, uint8_t R, uint8_t G, uint8_t //load z[] for one LED { z[ledNum*3]=G; z[ledNum*3+1]=R; z[ledNum*3+2]=B; } void writeLEDs () { _disable_interrupts(); write_ws2811_hs(z, sizeof(z), ledPin); _enable_interrupts(); } void getRGB(int color, uint8_t *R, uint8_t *G, uint8_t * //this generates RGB values for 1972 rainbow colors from red to violet and back to red { float brightness = 0.3; //scale factor to dim LEDs. if they are too bright, color washes out if (color>=(numColors/2)) //adjust color for return from violet to red color=numColors-color; if (color < 199) { *R = 255; *G = 56 + color; *B = 57; } else if (color < 396) { *R = 254 - (color - 199); *G = 255; *B = 57; } else if (color < 592) { *R = 57; *G = 255; *B = 58 + (color - 396); } else if (color < 789) { *R = 57; *G = 254 - (color - 592); *B = 255; } else { *R = 58 + (color - 789); *G = 57; *B = 255; } *R*=brightness; //apply brightness modification *G*=brightness; *B*=brightness; } void allWhite(uint8_t intensity) //all LEDs stay white { int i; for (i=0; i<12;i++) z[i] = intensity; writeLEDs(); } void allBlack() //all LEDs off (black) { int i; for (i=0; i<12;i++) z[i] = 0x00; writeLEDs(); } void lightning () { uint8_t R, G, B; int color; //numeric index into color palette int flashDuration; while (!buttonPressed) { allBlack(); //clear LEDs color = rand()%numColors; if (color%7==0) //every so often, throw in a bright white flash { R=G=B=0xff; flashDuration = 10; //quicker for white flash } else { getRGB (color, &R, &G, &; //get random color flashDuration = 50; //slower for color flash. makes color more apparent } loadLED (rand()%4, R, G, ; //load color into random LED writeLEDs(); //flash the LED millisecDelay(flashDuration); allBlack(); //clear LEDs millisecDelay(rand()%500); //wait for next flash } } void drawSnake (int headLoc) //draw snake starting at headLoc { int shoulderLoc, torsoLoc, tailLoc; uint8_t R, G, B; //color of head getRGB (rand()%numColors, &R, &G, &; shoulderLoc = (headLoc+1)%4; //find correct array locations for body parts. keep within 0-3 range torsoLoc = (headLoc+2)%4; tailLoc = (headLoc+3)%4; loadLED (headLoc, R, G, ; //random color head loadLED (shoulderLoc, 0, 0, 0); loadLED (torsoLoc, 0, 0, 0); loadLED (tailLoc, 0, 0, 0); //black tail writeLEDs(); //draw the snake } void chaseSnakeTail () //white head, black tail. Snake goes in circles { int headLocation=0; //which LED is the head (white) int crawlSpeed; //delay between snake moves int slowSpeed=150; int fastSpeed= 10; int CWdirection = 1; //start with clockwise direction = true while (!buttonPressed) { for (crawlSpeed=slowSpeed; crawlSpeed>fastSpeed; crawlSpeed-=2) //speed up tail chasing { drawSnake (headLocation); millisecDelay(crawlSpeed); if (CWdirection) headLocation +=3; else headLocation++; headLocation%=4; //keep LED in range (0-3) if (buttonPressed) break; } CWdirection = !CWdirection; //reverse direction for next cycle for (crawlSpeed=fastSpeed; crawlSpeed<slowSpeed; crawlSpeed+=2) //slow down tail chasing { drawSnake (headLocation); millisecDelay(crawlSpeed); if (CWdirection) headLocation +=3; else headLocation++; headLocation%=4; //keep LED in range (0-3) if (buttonPressed) break; } } } void allColors() //display rainbow color progression, each LED out of phase with the others { uint8_t R, G, B; int color; int ledNum; //0-3 while (!buttonPressed) for (color=0; color<numColors; color++) //progress from red to violet and back to red { for (ledNum=0; ledNum<4; ledNum++) { getRGB ((color+ledNum*200)%numColors, &R, &G, &; //offset LED colors by 200 from neighbors loadLED (ledNum, R, G, ; } writeLEDs(); millisecDelay(4); if (buttonPressed) //allow exit from function break; } } void writeLeds(const uint8_t color[12]) { unsigned j; for (j = 0; j < 12; j++) { z[j] = color[j]; write_ws2811_hs(z, sizeof(z), ledPin); } } void main(void) { WDTCTL = WDTPW + WDTHOLD; // No watchdog reset DCOCTL = 0; BCSCTL1 = CALBC1_12MHZ; // Run at 12 MHz DCOCTL = CALDCO_12MHZ; //P1SEL &= ~ledPin | button; P1DIR |= ledPin; // ledPin is an output P1OUT = 0; // set port 1 low P1DIR &= ~button; // button is an input P1REN |= button; // pull down on button P1OUT &= ~button; // set pull down P1IES &= ~button; // Interrupt Edge Select - 0: trigger on rising edge, 1: trigger on falling edge P1IFG &= ~button; // interrupt flag for p1.3 is off P1IE |= button; // enable interrupt FCTL2 = FWKEY + FSSEL_1 + FN3; // MCLK/32 for Flash Timing Generator 12mhz/32 = 375hz // these both work has to be between 257-476 hz //FCTL2 = FWKEY + FSSEL_1 + 0x1A; // MCLK/27 for Flash Timing Generator 12mhz/27 = 444hz pressCount = *Flash_ptr; // load value written in flash _enable_interrupts(); while (1) { if (buttonPressed) { buttonPressed = 0; //reset switch (pressCount) { case 0: //bright white allWhite(0x80); break; case 1: //dim white allWhite(0x40); break; case 2: lightning(); break; case 3: allColors(); break; case 4: chaseSnakeTail(); break; case 5: writeLeds(red); break; case 6: writeLeds(blue); break; case 7: writeLeds(green); break; case 8: writeLeds(purple); break; case 9: writeLeds(yellow); break; case 10: writeLeds(orange); break; case 11: writeLeds(steelBlue); break; case 12: writeLeds(pink); break; case 13: writeLeds(aqua); break; default: pressCount = 0; //default to 0 buttonPressed = 1; //force execution of case 0 break; } writeFlash(pressCount); // write to flash for poweroff } } } I didn't use any kind of level shifting for the leds. It seems alot of folks on here had no trouble getting the leds to
    work with out it, and I didn't read about the level shifting until after I sent off for the boards. So I got lucky on that one.
     
    For powering the the board I wanted to use the existing 12volt supply for the printer, so I put a couple of LDO's on
    board for that. I of course used TI parts that I sampled from TI. (as a matter of fact I sampled the msp430 too thanks TI!!!)
    For the 3.6 volt side I used the TPS70936 and for the 5 volt side I used the LP2989. Both of the LDO's are able according to
    the data sheets to handle a 12 volt input.The 3.6 volt side worked out as expected but I must have done something
    wrong with the LP2989. The data sheet says the part will provide up to 500mA continuously, the WS2812 at full brightness
    pulls 60mA. I put 4 leds on the board so thats 240mA if they are all full blast. When I have all the leds on full the LDO gets
    HOT! As far as the layout goes I copied the shematic from the data sheet, and used the recommended parts.
     
    This is from the datasheet:

    This is from my schematic:

     
    To get around a full redesign I don't push them that hard, and it works. It does bug me though, so if anyone has any
    insight or suggestions let me know. I have one more pcb I can hack on and see if I can make it work better.
     
    Besides that I am happy with the design and it fits the machine perfectly. (Just like it supposed to!)
    It's nice to see what I am printing.
    Here are a couple more photos , and some video.
     


     

     
  8. Like
    timotet reacted to oPossum in ringLight. A WS2812 led based light for my 3d printer.   
    12V - 5V = 7V
     
    7V * 0.5A = 3.5W
     
    So you need a heatsink that will get rid of that 3.5 watts with acceptable temperature rise. It's in a SOIC package, so that's not really possible.
     
    So... use a TO-220 package regulator with a heatsink or a switching regulator.
  9. Like
    timotet got a reaction from bluehash in ringLight. A WS2812 led based light for my 3d printer.   
    I built a 3d printer last year and needed a small light to illuminate the build area, this is what I came up with.
    I call it the ringLight.

     
    I thought about using an Adafruit Neopixel ring, but due to the finished part being for a specific size I decided to roll
    my own. I used a MSP430G2452 in the TSSOP 14 pin package for the micro. I have to thank every one on the forum for
    the wealth of info related to the WS2812 leds, and a special thanks to @@oPossum for the led driver code he posted.
    The code is pretty straight forward. Once powered on the msp430 loads what ever value from flash that was
    used from the last time power was on, then waits for a button press. If the button gets pressed it will scroll through a few
    pre programmed colors or animations, per press. Then that value is re-written into flash for the next time.
     
    Here is the code:
    // 5/10/14 // For controlling the Mandelbots ringLight WS2812 leds // Thanks to Kevin Timmerman for the ws2811_hs.asm led driver code // Written by Larry Fogg and Tim Toliver // #include "stdint.h" #include "stdlib.h" #include <msp430g2452.h> void write_ws2811_hs(uint8_t *data, unsigned length, uint8_t pinmask); //prototype for ws2811_hs.asm #define button BIT3 #define ledPin BIT7 #define numColors 1972 static const uint8_t red[12] = { 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00 }; static const uint8_t green[12] = { 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00 }; static const uint8_t blue[12] = { 0x00, 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00, 0xFF }; static const uint8_t purple[12] = { 0, 128, 128, 0, 128, 128, 0, 128, 128, 0, 128, 128 }; static const uint8_t yellow[12] = { 0xFF, 0xFF, 0x00, 0xFF, 0xFF, 0x00, 0xFF, 0xFF, 0x00, 0xFF, 0xFF, 0x00 }; static const uint8_t orange[12] = { 0x80, 0xFF, 0x00, 0x80, 0xFF, 0x00, 0x80, 0xFF, 0x00, 0x80, 0xFF, 0x00 }; static const uint8_t steelBlue[12] = { 130, 70, 180, 130, 70, 180, 130, 70, 180, 130, 70, 180 }; static const uint8_t pink[12] = { 20, 255, 147, 20, 255, 147, 20, 255, 147, 20, 255, 147 }; static const uint8_t aqua[12] = { 255, 0, 255, 255, 0, 255, 255, 0, 255, 255, 0, 255 }; static uint8_t z[12]; //GRB values for 4 LEDs uint8_t pressCount; //keep track of button presses uint8_t buttonPressed = 1; //start with true so stored pressCount is executed //for writing flash uint8_t * Flash_ptr = (unsigned char *) 0x1040; //location to write in flash info segment C void millisecDelay(int delay) { int i; for (i=0; i<delay; i++) _delay_cycles(10000); //roughly 1 msec. calibrate this } #pragma vector=PORT1_VECTOR __interrupt void PORT1_ISR(void) { _disable_interrupts(); pressCount++; //increment button presses buttonPressed = 1; //true millisecDelay(300); //for button debounce P1IFG &= ~button; //clear interrupt flag _enable_interrupts(); } void writeFlash(unsigned char data){ _disable_interrupts(); FCTL1 = FWKEY + ERASE; //Set Erase bit FCTL3 = FWKEY; //Clear Lock bit *Flash_ptr = 0; //Dummy write to erase Flash segment FCTL1 = FWKEY + WRT; //Set WRT bit for write operation *Flash_ptr = data; //Write value to flash FCTL1 = FWKEY; //Clear WRT bit FCTL3 = FWKEY + LOCK; //Set LOCK bit _enable_interrupts(); } void loadLED (int ledNum, uint8_t R, uint8_t G, uint8_t //load z[] for one LED { z[ledNum*3]=G; z[ledNum*3+1]=R; z[ledNum*3+2]=B; } void writeLEDs () { _disable_interrupts(); write_ws2811_hs(z, sizeof(z), ledPin); _enable_interrupts(); } void getRGB(int color, uint8_t *R, uint8_t *G, uint8_t * //this generates RGB values for 1972 rainbow colors from red to violet and back to red { float brightness = 0.3; //scale factor to dim LEDs. if they are too bright, color washes out if (color>=(numColors/2)) //adjust color for return from violet to red color=numColors-color; if (color < 199) { *R = 255; *G = 56 + color; *B = 57; } else if (color < 396) { *R = 254 - (color - 199); *G = 255; *B = 57; } else if (color < 592) { *R = 57; *G = 255; *B = 58 + (color - 396); } else if (color < 789) { *R = 57; *G = 254 - (color - 592); *B = 255; } else { *R = 58 + (color - 789); *G = 57; *B = 255; } *R*=brightness; //apply brightness modification *G*=brightness; *B*=brightness; } void allWhite(uint8_t intensity) //all LEDs stay white { int i; for (i=0; i<12;i++) z[i] = intensity; writeLEDs(); } void allBlack() //all LEDs off (black) { int i; for (i=0; i<12;i++) z[i] = 0x00; writeLEDs(); } void lightning () { uint8_t R, G, B; int color; //numeric index into color palette int flashDuration; while (!buttonPressed) { allBlack(); //clear LEDs color = rand()%numColors; if (color%7==0) //every so often, throw in a bright white flash { R=G=B=0xff; flashDuration = 10; //quicker for white flash } else { getRGB (color, &R, &G, &; //get random color flashDuration = 50; //slower for color flash. makes color more apparent } loadLED (rand()%4, R, G, ; //load color into random LED writeLEDs(); //flash the LED millisecDelay(flashDuration); allBlack(); //clear LEDs millisecDelay(rand()%500); //wait for next flash } } void drawSnake (int headLoc) //draw snake starting at headLoc { int shoulderLoc, torsoLoc, tailLoc; uint8_t R, G, B; //color of head getRGB (rand()%numColors, &R, &G, &; shoulderLoc = (headLoc+1)%4; //find correct array locations for body parts. keep within 0-3 range torsoLoc = (headLoc+2)%4; tailLoc = (headLoc+3)%4; loadLED (headLoc, R, G, ; //random color head loadLED (shoulderLoc, 0, 0, 0); loadLED (torsoLoc, 0, 0, 0); loadLED (tailLoc, 0, 0, 0); //black tail writeLEDs(); //draw the snake } void chaseSnakeTail () //white head, black tail. Snake goes in circles { int headLocation=0; //which LED is the head (white) int crawlSpeed; //delay between snake moves int slowSpeed=150; int fastSpeed= 10; int CWdirection = 1; //start with clockwise direction = true while (!buttonPressed) { for (crawlSpeed=slowSpeed; crawlSpeed>fastSpeed; crawlSpeed-=2) //speed up tail chasing { drawSnake (headLocation); millisecDelay(crawlSpeed); if (CWdirection) headLocation +=3; else headLocation++; headLocation%=4; //keep LED in range (0-3) if (buttonPressed) break; } CWdirection = !CWdirection; //reverse direction for next cycle for (crawlSpeed=fastSpeed; crawlSpeed<slowSpeed; crawlSpeed+=2) //slow down tail chasing { drawSnake (headLocation); millisecDelay(crawlSpeed); if (CWdirection) headLocation +=3; else headLocation++; headLocation%=4; //keep LED in range (0-3) if (buttonPressed) break; } } } void allColors() //display rainbow color progression, each LED out of phase with the others { uint8_t R, G, B; int color; int ledNum; //0-3 while (!buttonPressed) for (color=0; color<numColors; color++) //progress from red to violet and back to red { for (ledNum=0; ledNum<4; ledNum++) { getRGB ((color+ledNum*200)%numColors, &R, &G, &; //offset LED colors by 200 from neighbors loadLED (ledNum, R, G, ; } writeLEDs(); millisecDelay(4); if (buttonPressed) //allow exit from function break; } } void writeLeds(const uint8_t color[12]) { unsigned j; for (j = 0; j < 12; j++) { z[j] = color[j]; write_ws2811_hs(z, sizeof(z), ledPin); } } void main(void) { WDTCTL = WDTPW + WDTHOLD; // No watchdog reset DCOCTL = 0; BCSCTL1 = CALBC1_12MHZ; // Run at 12 MHz DCOCTL = CALDCO_12MHZ; //P1SEL &= ~ledPin | button; P1DIR |= ledPin; // ledPin is an output P1OUT = 0; // set port 1 low P1DIR &= ~button; // button is an input P1REN |= button; // pull down on button P1OUT &= ~button; // set pull down P1IES &= ~button; // Interrupt Edge Select - 0: trigger on rising edge, 1: trigger on falling edge P1IFG &= ~button; // interrupt flag for p1.3 is off P1IE |= button; // enable interrupt FCTL2 = FWKEY + FSSEL_1 + FN3; // MCLK/32 for Flash Timing Generator 12mhz/32 = 375hz // these both work has to be between 257-476 hz //FCTL2 = FWKEY + FSSEL_1 + 0x1A; // MCLK/27 for Flash Timing Generator 12mhz/27 = 444hz pressCount = *Flash_ptr; // load value written in flash _enable_interrupts(); while (1) { if (buttonPressed) { buttonPressed = 0; //reset switch (pressCount) { case 0: //bright white allWhite(0x80); break; case 1: //dim white allWhite(0x40); break; case 2: lightning(); break; case 3: allColors(); break; case 4: chaseSnakeTail(); break; case 5: writeLeds(red); break; case 6: writeLeds(blue); break; case 7: writeLeds(green); break; case 8: writeLeds(purple); break; case 9: writeLeds(yellow); break; case 10: writeLeds(orange); break; case 11: writeLeds(steelBlue); break; case 12: writeLeds(pink); break; case 13: writeLeds(aqua); break; default: pressCount = 0; //default to 0 buttonPressed = 1; //force execution of case 0 break; } writeFlash(pressCount); // write to flash for poweroff } } } I didn't use any kind of level shifting for the leds. It seems alot of folks on here had no trouble getting the leds to
    work with out it, and I didn't read about the level shifting until after I sent off for the boards. So I got lucky on that one.
     
    For powering the the board I wanted to use the existing 12volt supply for the printer, so I put a couple of LDO's on
    board for that. I of course used TI parts that I sampled from TI. (as a matter of fact I sampled the msp430 too thanks TI!!!)
    For the 3.6 volt side I used the TPS70936 and for the 5 volt side I used the LP2989. Both of the LDO's are able according to
    the data sheets to handle a 12 volt input.The 3.6 volt side worked out as expected but I must have done something
    wrong with the LP2989. The data sheet says the part will provide up to 500mA continuously, the WS2812 at full brightness
    pulls 60mA. I put 4 leds on the board so thats 240mA if they are all full blast. When I have all the leds on full the LDO gets
    HOT! As far as the layout goes I copied the shematic from the data sheet, and used the recommended parts.
     
    This is from the datasheet:

    This is from my schematic:

     
    To get around a full redesign I don't push them that hard, and it works. It does bug me though, so if anyone has any
    insight or suggestions let me know. I have one more pcb I can hack on and see if I can make it work better.
     
    Besides that I am happy with the design and it fits the machine perfectly. (Just like it supposed to!)
    It's nice to see what I am printing.
    Here are a couple more photos , and some video.
     


     

     
  10. Like
    timotet reacted to zeke in RandomElectrons LP10062   
    Hi Guys,
     
    It's been quite a while since I was really active on the board (dang work!) so I thought I would take some time to make something that I could contribute back to the community.
     
    I put together something not really new. Well the idea isn't new but the implementation is new.
     
    I designed a LaunchPad board and it's called the LP10062.
     
    This preliminary design is based on the MSP430G2452 TSSOP.
     
    It has the same connector pinout and spacing as the original Launchpad board so all the shields will (should) work on it although they may look goofy.
     
    I decided to use the Sick of Beige 100mm x 62mm PCB shape since it is pleasing to the eye and acrylic "cases" can be obtained from SeeedStudio super cheap. This will let you permanently mount the board if you want.
     
    My motivation for designing this board is practical as well as aesthetics. I believe we can have beautiful looking boards THAT HAVE MOUNTING HOLES!
     
    Additionally, this board has a USB-Serial UART on it. It will provide power to the board as well as give you a way to talk to the MSP430.
     
    My preliminary investigation tells me that the BOOSTXL-BATTPACK should power this board without difficulty. Again, it will look goofy but that can be remedied in the future by redesigning the battery pack layout.
     
    I still have to design a decent power supply and I can't make up my mind on the topology just yet. So the board isn't fully routed just yet. I think it's too late in the day or something. I would like this thing to accept 12V DC and not give a care about which pin is +ve or -ve. You won't be able to blow it up by accidentally reversing the polarity.
     
    I have attached a preliminary pdf schematic and a screen capture of the PCB. 
      Yeah, I realize that the MSP430G2452 looks tiny on this PCB but it is my intention is to use this as a launching point [nyuck nyuck nyuck ;-) ] for a couple more LaunchPad designs that have more powerful MCU's on them i.e.: bigger MSP430 or a TIVA processor. I wanted to start small and work my way up in complexity.
     
    Until that time, I invite your feedback on this design. 
     
    What do you think?
    RELP10062.PDF


  11. Like
    timotet got a reaction from simpleavr in Simulating a TI calculator with crazy 11-bit opcodes   
    Great work !
  12. Like
    timotet reacted to simpleavr in Simulating a TI calculator with crazy 11-bit opcodes   
    Bump.
     
    Finally moved the emulator to a single PCB design (after one failed PCB design). Now my kids can take them and use them in school.
     
    Source code can be found at https://github.com/simpleavr/tms0800.
     
    Source code based on Ken Shirriff and other's work, please see http://righto.com/ti and http://righto.com/sinclair
     

     
    A few photos...
     

     
    PCB design available upon request.
     
     
  13. Like
    timotet reacted to pabigot in Newbie general C code question   
    I see that happening more and more; I blame it on injudicious application of MISRA rule 6.3.
     
    It's absolutely the case that types with specific sizes should be used when the range is potentially beyond the native word size of the processor or data is exchanged over a communication link, including via a file.
     
    I have yet to see a cogent argument why specific-size types should be used in preference to "int" and "unsigned int" for indexes and offsets where the native word size is appropriate, or when you're manipulating a processor peripheral that is known to be that native word size.
     
    On one hand, you might select a type that's too large for a target processor, impacting portability. TI did this recently to the CC3000 host interface, changing it so every parameter is a uint32_t even if its value range is less than one octet. This unnecessarily bloats code and hampers performance on the MSP430. Sure, when it goes out over SPI it needs to be 4 octets: but that's an encoding issue and should not propagate up to the library API.
     
    Or you might go too small, and select uint8_t. Two problems: (1) it's a pain if you wrote code to index over an array, and somebody increases the array size above 255. (2) A uint8_t value will promote to the signed type int when used in expression calculations. I've got some discussion of this on my blog; the non-C++ stuff related to uint8_t is at the end. tl;dr: -x doesn't mean what you probably think it does.
     
    The advice @@roadrunner84 gave is better, though if the "appropriate type" argument is applied consistently one should use size_t for all variables used as indexes as well as sizes. Which will hurt you badly on the MSP430 if you're using a memory model that supports objects larger than 64 kiBy, so I prefer unsigned int there too.
     
    Note: If you are going to use the size-specific types, get in the habit of explicitly including either <inttypes.h> or its lesser cousin <stdint.h>. Yes, for MSP430 and ARM the vendor headers provide it for you, but if you don't remember that it comes from the C library, not the C language, you'll be confused when you graduate to host platforms where it's not part of the null context.
  14. Like
    timotet reacted to pabigot in How to calc the clock   
    An anomaly with this: if you're using driverlib TivaWare_C_Series-2.1.0.12573 on a TM4C123GH6PM (i.e. an EK-TM4C123GXL launchpad) you can use

    SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ); /* 2*PLL/5 = 80 MHz */ to set the clocks to 80MHz, but if you then call SysCtlClockGet() it'll tell you you're running at 66MHz. This is because SYSCTL->DC1.MINSYSDIV, which driverlib consults, insists that the minimum divider is 3, so you can't possibly be running faster than 66MHz. 
    At least TI gives us the source code so we can figure these things out, and per this e2e post with a patch it'll be fixed some day.
  15. Like
    timotet got a reaction from emailcausey in Measuring external voltage   
    I found the document:
     
    TMS320x2802x, 2803x Piccolo Analog-to-Digital
    Converter (ADC) and Comparator Reference guide
     
    To be helpful, if you dont have it.
     
    Search for SPRUGE5F on TI's site.
     
    I think in your ADC_init code you want:
     
    ADC_setVoltRefSrc(myAdc, ADC_VoltageRefSrc_Int);   // sets adc to internal reference
    According to the chips data sheet pin 12 on the Tms320F28027 is VREFLO.
    Datasheet also says it always tied to ground.
     
    or for external source:
     
    ADC_setVoltRefSrc(myAdc, ADC_VoltageRefSrc_Ext);  // for external reference source
    In this case you would have your VREFHI connected to pin 10 on the micro(J5.6 on C2000 launchpad)
     
    I looked at the example you are using and its in there as an internal source.
     
    Hope this helps
    Tim
     
     
  16. Like
    timotet reacted to spirilis in Adafruit 1.2" LED 7-seg Display Backpack - MSP430F5172 edition   
    So a primary project of mine right now is to reinvent my alarm clock.  I have an old POS I probably bought for $10 from a department store over 10 years ago that still works..... for the most part, but its digits are too small for my squinty eyes to see across the bedroom at 3AM when my son likes to wake us up for no good reason.
     
    Obviously the first line of business here, then, in reinventing an alarm clock is the display.  I like red displays at night, and I like larger digits, so Adafruit's 1.2" red LED display was perfect- http://www.adafruit.com/products/1264
     
    They sell one with an I2C backpack too (HT16K33-based).  But something just doesn't jive right with me there; I want mine overengineered to the point of exhaustion.  So I designed my own backpack with suitable P-channel and N-channel MOSFET transistors controlled by an MSP430F5172.  Used the F5172 for two reasons: Native 5V on some pins (great for direct control of the P-channel's when powering the LEDs with 5V for maximum brightness & compatibility with different LED colors), and Timer_D should give me an absolutely hideously inappropriate amount of brightness control if I PWM the P-channel FETs using a Timer_D output.
     
    In any case, board fabricated, my first test revision of the Spy-Bi-Tag for eZ-FET all assembled and my new Tag-Connect TC2030-MCP programming cable in hand (bought last month), I've given it a test.  Just lighting up one thing at a time to make sure all the cathode & anode lines work.
     
    Looks good so far:




     
    Don't mind the FuelTank boosterpack, I noticed that my eZ-FET-to-Spy-Bi-Tag adapter didn't offer any options for connecting the 5V or 3.3V rails to the rest of the LaunchPad for sending 5V/3.3V to the project, so I popped on the FT BPak to cover that for now.  In any case, that Spy-Bi-Tag eZ-FET adapter will need at least 1 more revision before I feel it's good enough to publish.  I must say though, the eZ-FET programs the F5172 nice & fast!
     
    Another thing I noticed is I put the Tag-Connect footprint way too close to the 2x5 power/data IDC connector; I've bent one of the corner pins on the IDC pinout many times trying to get my fingernail in there to pinch the connector legs, although I got it down to a science now so I'm not hurting it anymore.  That said, I'm pretty impressed with the Tag-Connect and the legged version doesn't seem all that hard to install & remove; a bit of effort but nothing horrible IMO, no tools required to be sure (just pinch & pull at the same time to remove).
     
    This LED Display Backpack offers a 2x5 connector suitable for IDC which has two GND's, 5V, 3.3V, and a number of GPIOs from P1.0-P1.5 for the full USCI experience; choose whatever protocol you want to use to talk to this one!  I'm planning on using UART in my final alarm clock project.  The main brain of the alarm clock will likely be an F5529 LaunchPad, and the mainboard will include enough circuitry to charge two tablets at the same time, or a tablet and a phone, or two phones, or 1 phone or tablet or whatever.  Got samples of TI's TPS2511 for that part of the project.
     
    Probably going to ignore the RTC's on the MSP430's and use the DS3231 for keeping time, although I might change my mind.
  17. Like
    timotet reacted to emailcausey in Hardware SPI working with the Nokia 5110 LCD   
    Thanks for everything.

  18. Like
    timotet reacted to Lyon in Execution time - the easy way   
    Hi,
    Found on web several postings related to some available, but unused hardware on Cortex-Mx processors (unused on some platforms, available on others.
    Adapted for TM4C as below:
    #include "inc/hw_nvic.h" /* for definition of NVIC_DBG_INT */ #include "inc/hw_memmap.h" /* for definition of DWT_BASE */ #include "inc/hw_types.h" /* for definition of HWREG */ #define DWT_O_CYCCNT 0x00000004 static  uint32_t     c_start, c_stop; // declaration of an initialization function void EnableTiming(void); // definition of that function /******************************************************************************/ void EnableTiming(void){    HWREG(NVIC_DBG_INT) |= 0x01000000;      /*enable TRCENA bit in NVIC_DBG_INT*/    HWREG(DWT_BASE + DWT_O_CYCCNT) = 0;   /* reset the counter */    HWREG(DWT_BASE) |= 0x01;                /* enable the counter */    enabled = 1; } /******************************************************************************/ // and then, in the code to be examined write these: EnableTiming();  c_start = HWREG(DWT_BASE + DWT_O_CYCCNT); // at the beginning of the tested code  // your code follows here  c_stop = HWREG(DWT_BASE + DWT_O_CYCCNT); // at the end of the tested code // then c_stop - c_start is the execution number of cycles for the code; // just multiply with clock period to find out the execution time of the code. // At 80MHz, the 32 bit counter gives you a total time 2^32 x 12.5ns = ~53 seconds! // Another interesting function is this one /**********************************************************/ void TimingDelay(unsigned int tick) { unsigned int start, current; start = HWREG(DWT_BASE + DWT_O_CYCCNT); do { current = HWREG(DWT_BASE + DWT_O_CYCCNT); } while((current-start)<tick); } /*********************************************************/ Enjoy!
    L
  19. Like
    timotet got a reaction from bluehash in Mailbag   
    Yes kind of , I built a 3d printer and wanted to mount a light up under the print head.
    I looked into using one of the neo pixel rings but they didnt quite fit the dimensons needed.
    I also wanted to be able to control it more than just on and off so I put a msp430 on there.
    I will post about it once I have them built up and working.
  20. Like
    timotet got a reaction from bluehash in Mailbag   
    I got these a couple days ago!
     

  21. Like
    timotet reacted to chicken in [POTM] dAISy - A Simple AIS Receiver   
    Overview
    dAISy (do AIS yourself) is a very simple AIS receiver that I developed from scratch. It is built around the Silicon Labs EZRadioPRO Si4362 receiver, using a Texas Instruments MSP430G2553 MCU for processing and the MSP-EXP430G2 v1.5 LaunchPad as development platform.

    The complete project source code and schematics are available on GitHub: https://github.com/astuder/dAISy

    Update 5/18/2015: A finished, self-contained AIS receiver based on this project is now available for purchase in my web store.
     
    AIS, short for Automatic Identification System, is a standard for tracking ships. Ships advertise their position, course and other information with short transmissions on specific frequencies (161.975 MHz and 162.025 MHz). More on Wikipedia.
     
    An AIS receiver, like dAISy, receives and decodes AIS transmissions. It then re-packages the raw data into NMEA sentences (specifically formatted ASCII strings). Finally, using a serial connection, these strings are forwarded to more capable equipment for further processing.
     

     
    If you're the lucky owner of a tricked out boat, you could connect dAISy to your navigation computer. For land lobbers like me, a more common use case is to run naval mapping software that supports AIS data input on a PC. In the screenshot below I've connected dAISy to OpenCPN (link), an open source chart plotter and navigation software.
     

     
    On the top right you can see my setup war-driving at the Seattle waterfront as my lab is too far from the coast to receive anything. The LaunchPad sits on the dashboard with a white USB cable connecting to the notebook computer in the foreground.
     
    dAISy's data is fed into OpenCPN, bottom right shows a log of the serial data received. OpenCPN maintains a database of all the collected data (lower left) and visualizes nearby ships on a map (top center), including past and projected course. Hovering the mouse over a ship will display its name (text on yellow ground) and clicking it will reveal more detail (top left).
     
    Hardware
    I wanted to build my own, non-SDR, AIS receiver for a long time. There are a few projects floating around the internet (e.g. here) which refer back to an article by Peter Baston, published 2008 in Circuit Cellar magazine (copy available here gone.. google for Peter Baston Circuit Cellar to find other copies). Unfortunately, the CMX family of modem ICs by CMS Microcircuits (link) used in these projects are relatively expensive ($15+) and hard to find for hobbyists. In addition you'd need a radio to do tune into and down-convert from the ~162 MHz carrier frequency.
     
    So I was quite excited when earlier this year a parametric search on Mouser brought up a new IC  that covered the required range (162 MHz) and modulation (GMSK). And best of all, available in single quantities for $3.56 $2.27 $2.22! (link)
     
    The Silicon Labs EzRadioPRO Si4362 (link) is a single chip receiver that covers frequencies from 142 to 1050 MHz and supports various modulations, including GMSK. It comes in a tiny 20-pin QFN package and the only external parts required are a 30 MHz crystal, an antenna with a few capacitors and inductors for impedance matching, and finally some decoupling caps and pull-down resistors.
     
    Time to whip up a breakout board. I used the opportunity to give KiCad a try and quite like it.
     
    Here's the schematic:

     
    And the layout:

     
    I used OSHPark to make the PCBs. At a smidgen over one square inch it cost  $5.15 for 3 copies:

    http://oshpark.com/shared_projects/QUWi71r4
     
    Note that the layout still has three issues that I already fixed in the schematic:
    GPIO0 and GPIO1 were flipped SDO required a pull-down resistor as the radio leaves it floating when not actively sending, which confused the hell out of me while trying to figure out the communication protocol. Lastly, the holes for the headers turned out to be slightly too small to comfortably fit the cheap breakout headers I had at hand. Edit: Here's Rev B where I fixed these issues: http://oshpark.com/shared_projects/WI6u3Qmk
     
    Which brings us to the BOM:
    Silicon Labs Si4362 (U1) 30 MHz crystal (X1) Si4362 datasheet specifies <11 pF load capacitance, but a crystal specified for 12pF load capacitance seems to work fine too Antenna/LNA matching network, calculated based on SiLabs AN643 (link, approx. values, +/- 5% shouldn't matter too much): 75 ohm (dipole): 10 pF (CR1), 5 pF (CR2), 280 nH (LR1), 200 nH (LR2) 50 ohm: 12 pF (CR1), 6 pF (CR2), 240 nH (LR1), 160 nH (LR2) Decoupling caps: 100 pF, 100 nF, 1uF (C1, C2, C3) Pull-down resistors 100 k (R1, R2) First thing I noticed when I received the parts: The 20-pin QFN at 4x4 millimeters is tiny!

     
    I mounted it by first tinning the pads with a small quantity of solder. I then added flux and placed the chip on the pad. I then used a hot air station to carefully reflow the solder. Worked the first time around.

    After using jumper wires to figure out how to talk to the chip, I mounted the breakout board on a makeshift BoosterPack using perfboard, double-sided tape and wire (see picture at the top of the post).



    Here's how I ended up connecting the breakout board to the LaunchPad / MSP430G2553:
    SEL -> P1.4 (SPI chip select) SCLK -> P1.5 (SPI CLK) SDO -> P1.6 (SPI MISO) SDI -> P1.7 (SPI MOSI) GPIO0 -> P2.0 (I/O unused) GPIO1 -> P2.1 (I/O clear-to-send) GPIO2 -> P2.2 (I/O RX clock) GPIO3 -> P2.3 (I/O RX data) SDN -> P2.4 (shutdown / reset) IRQ -> P2.5 (I/O channel-clear) Software
    The software of dAISy consists of three major blocks:
    Radio configuration and control over SPI Packet handler, including a basic FIFO for received messages NMEA encoding and transmission to the PC over UART For UART (TX only) and SPI (TX/RX) I use the MSP430G2553's USCI A0 and B0 respectively. In both cases I don't use interrupts which simplifies things considerably.
     
    Upon reset the following steps happen:
    Initialize MSP430 peripherals Initialize packet handler, which will also reset FIFO Initialize and configure of radio, which will also setup SPI Start packet handler, which will also put the radio into receive mode And in the main loop:
    If debug messages are enabled, poll packet handler for status and errors and report them over UART Check FIFO for new packets If there is a new packet, invoke NMEA processing (which sends the message over serial to the PC) and remove packet from FIFO Below follows a more detailed discussion of the radio integration and the implementation of the packet handler.
     
    Radio
    The communication with the radio is vanilla SPI using 4 wires: MOSI (SDI), MISO (SDO), CLK (SCLK) and CS (SEL). I used the MSP430's USCI B0 to implement SPI and a separate pin to control CS.
     
    The only tricky thing to figure out was, that the Si4362 keeps the MISO line floating unless it actively transmits data. This is unfortunate as the master is supposed to poll for a specific response (FF) to detect when the radio is ready to receive more commands. This is easily fixed by adding a weak pull down resistor to SDO. I did this on the board, but it probably also works with using MSP430's internal pull-down.
     
    Additional lines I used to control the radio are:
    SDN to reset the radio CTS, which by default is mapped to the radio's GPIO1, indicating that the radio is ready for the next command While taking up an extra pin, CTS turned out to be much more convenient than the SPI response code to properly time communication flow with the radio. In dAISy, I wait for CTS to go high after each command to ensure the radio completed its task.
     
    The communication protocol is quite extensive but well documented:
    EZRadioPRO API Documentation describes the complete API and all registers AN633 Programming Guide for EZRadioPro Si4x6x Devices describes how to use the API in common scenarios Both are available on the Si4362 product page (link), under Documentation > Application Notes and are still updated quite frequently.
     
    The radio is set up by dumping a large configuration sequence into it. This includes configuration of radio frequency, modulation, GPIO pins and more. This information is stored in radio_config.h, which has to be generated with a tool called WDS (Wireless Development Suite). WDS is available in the Tools section on the Si4362 product site.
     

     
    Above are the settings I used for dAISy. WDS will use this information to configure various amplifiers, filters, clocks and decoding algorithms inside the chip. As Si4362 supports GMSK encoding only indirectly (see this thread), I'm certain there's more optimization potential by tweaking registers, but that's currently way beyond my knowledge of RF theory.
     
    While the Si4362 comes with its own packet handler, it unfortunately does not support NRZI encoding (Wikipedia). So I set up the radio to expose the 9600 baud clock and received data on separate pins and implemented my own packet handler.
     
    Packet Handler
    The packet handler (inspired by Peter Baston's implementation) is implemented as a state machine that is invoked on each rising edge of pin P2.2 which receives the data clock.
     

    There are 5 main states:
    Off, no processing of incoming data Reset, start from anew, either on start up or after successful/failed processing of a packet Wait for Sync, waiting for a training sequence to arrive (010101..) and start flag (01111110), implemented with its own state machine   Reset, start new preamble 0, last bit was a zero 1, last bit was a one flag, training sequence complete, now process start flag Prefetch, ingest the next 8 message bits to ease further processing Receive Packet, process bits until the end flag (01111110) is found or an error situation occurs Independent of state, the interrupt routine continually decodes NRZI into actual bit sequence.
     
    In the "Receive Packet" state there's continuous calculation of the packet CRC and some bit-de-stuffing. When the end flag is found and the CRC is correct, the received message is committed into the FIFO. If an error is encountered, the bytes already written to the FIFO are discarded. In both cases, the state machine starts anew by transitioning into RESET.
    This reads like a lot of code for an interrupt handler. However with the MCU running at 16MHz even the most complex state only uses a fraction (<10%) of the available time.
     
    Future Improvements
    Lastly a list of things I'd like to improve with the next version of dAISy.
     
    Software:
    Receiving on both AIS channels through channel-hopping done 1/5/2014 Tweak radio settings for better sensitivity and lower error rate LED(s) for indicating reception of valid/corrupt packets Hardware:
    Proper antenna connector Layout PCB as BoosterPack and/or USB dongle Receiving on both AIS channels at once with two radio ICs -- edit 12/25: replaced original post with high-level project description, more detailed documentation of implementation to come
    -- edit 12/28: added documentation for hardware (here and on Github), fixed some typos
    -- edit 12/31: added documentation for software and list of future improvements
    -- edit 01/05: implemented channel hopping (change to state machine)
    -- edit 01/15: changed state machine to reflect recent changes (see post further down for details), added link to shared project on OSHPark
    -- edit 01/25: major rework of sync detection state machine

  22. Like
    timotet reacted to Lyon in Toolchain setup under GNU/Linux (including Eclipse)   
    Hi,
    It is not clear what you downloaded - if you mean the launchpad's gcc, then it should be installed in /usr/local/gcc-arm-none-eabi-4_7-2012q4 if you use linux and must have /usr/local/gcc-arm-none-eabi-4_7-2012q4/bin in your path. (there is my gcc version and path)
     
    Also, not clear if you downloaded also gnuarmeclipse plug-in. The link provided is useful also since has installing instructions. But some more words about this a little bit later.
     
    Now, you must know some things about how TI made Stellaris/Tiva package: (I hope you use the latest TIVA package - you do not specify your micro, it is also important) - it is made for "bach" processing - i.e. you must open a terminal, change to the TIVA folder and from that one, you can launch the command "make", which will build all examples/boards inside. This is because there is also the makedefs file which prepare the environment for that (check also this file since it may require some modifications). Doing from Eclipse console is not the right thing to do - could be some missing paths.
     
    But, working directly from Eclipse you must make a project (you made it, but not happy with the picture, the Console tab should be posted instead) and, if you have a Cortex-M4 micro, the things can be easier to do - you are not forced to build the libraries, but to use instead ROM_ prefixed functions since these are already embedded into flash.
    Also, using the suggested plug-in, you do not need to use/write your own makefiles - that's the job of the plug-in (it is a "managed make").
     
    In the case of a Cortex-M4 micro, the option -mfloat-abi=softfp is wrong, should be -mfloat-abi=hard, the other one is not compatible with the specified  gcc library.
     
    I know it will take some time until you will have a good working tool chain (also happened to me, nobody is born savant), keep trying and for sure you will succeed. 
     
    L
  23. Like
    timotet reacted to D^2 in Christmas PCB   
    Hey @@cubeberg, I've added a project configuration into your code. Starting with CCSv5.3, we have introduced a new and more elegant way of defining a project for easier import/export. This feature is called projectspec. By adding a .projectspec into your code folder, you can specify the names, files to copy over, compiler settings such as optimization or --gcc extension in this specific case. Users no longer have to include the other confusing .project or .debug files/folders anymore. All you need to fully replicate the project is:
     
    1. Your code files.
    2. The .projectspec file
    [optional] Linker command file ONLY IF you customize it, otherwise the stock linker command file will be copied over to the project.
     
    Here's the new zip file that anybody can simply import into their CCS and immediately compile & download.
     
     
    43ohChristmas.zip
  24. Like
    timotet reacted to RobG in MSP430 Xmas   
    This year, LaunchPad has a very special assignment during the holidays - to control our Xmas tree lights. 
    So far, more than 20 different sequences are programmed into G2553. Piano pedal connected to LP allows easy selection.
    Finally, my wife can have Xmas lights she likes, one day white, another day warm colors, then maybe little strobe light here and there, and so on.
     
    There are 100 WS2811 pixels on the tree (those lights look much, much better in real life)
    (You can see LP right above the train, tiny green light.)

     
     
    MSP430 is also used to power my 10W RGB flood lights.
     

  25. Like
    timotet reacted to zeke in Does anyone work as an embedded engineer?   
    I have always wanted to be an embedded systems engineer. I got my tech diploma first, worked as a board level troubleshooter/repair then I went back to university and got my EE degree. I have since worked for others and now I work for myself.
     
    What I realize from all of that experience is that the definition of Embedded Engineer is inside your head and heart. If you want to do it then it doesn't matter how much training you have or who you work for. If the thought of doing all of this EE like stuff consumes your thoughts, emotions and spare time then you are an Embedded Engineer.
     
    The "world" needs definitions and metrics to measure economic compensation and progress therefore you will be judged by the academic accolades behind your name. It's a fact of life. Don't let that get you down. There are some hurdles worth climbing over. Like strategically getting that degree or diploma that let's you pass the gatekeepers (HR department).
     
    Concerning the work itself, nothing is impossible to accomplish when you have knowledge, skills and abilities. You can learn the unknowns. You can practice the skills. If you don't have the abilities then you are screwed. 
     
    An example of an (dis)ability would be color blindness. If you cannot distinguish all the colors of the resistor codes then you are at a disadvantage.  If you cannot see with your eyes then you cannot code very fluidly. If you cannot hold your hand steady then you cannot hand place 0603 resistors very easily. If you do not believe in yourself then you will be gripped by fear and never take a risk to achieve your goals.
     
    I have been working in this electronics industry since 1988. I am constantly learning. I am constantly being judged by the work of my hands and my mind by peers, employers and, now, clients. I could create a very large list of important knowledge, skills and abilities that I consider as prerequisites to succeed in the electronics industry. That list would be only for me though. Your list will be different.
     
    I came across a speech by Arnold Schwarzenegger this week on youtube. I took notes since the speech is 25 minutes long unedited. Here is the sensationalized TL;DR version. Here's what I wrote down:
     
    1. Trust yourself:
    - What do you want to be?
    - What makes you happy?
     
    2. Break the rules
    - Don't follow society's rules and traditions blindly
     
    3. Don't be afraid to fail
    - Do NOT be paralyzed by fear or you will never make a decision
     
    4. Don't listen to the Naysayers
    - IT CAN BE DONE
     
    5. Work your butt off!
    - Leave no stone unturned aka: Network! Network! Network!
    - No pain No gain
    - There is no way around hard work
    (This next one is my favorite)
    - You cannot climb the ladder of success with your hands in your pockets!
     
    6. Give back
    - You have to help others around you
    - Pay it forward, Pay it back
    - Be generous to and with others
     
    In my opinion, YES, you can do it! You can be the Embedded Engineer that you see in your mind. You can make bluetooth peripherals work. You can do everything that you set your mind to do.
     
    Yes, it will be hard work learning how something works.
    Yes, it will be challenging learning how to craft code.
    Yes, you will have to ask for help.
    Yes, you will have obstacles.
    Yes, you will overcome them.
    Yes, you will succeed.
     
    Jack Ganssle did it. So can you.
     
     
     
     
×
×
  • Create New...