Jump to content
43oh

gordon

Members
  • Content Count

    536
  • Joined

  • Last visited

  • Days Won

    13

Reputation Activity

  1. Like
    gordon reacted to RobG in Allow .brd and .sch file attachments   
    Let's not forget about .lbr
  2. Like
    gordon reacted to bluehash in Allow .brd and .sch file attachments   
    Added support for eagle brd and sch files.
     
    People normally zip it.
    test.sch
    test.brd
  3. Like
    gordon got a reaction from VIPTech in IR Booster Pack   
    Here's a little Payload (yeah, let's add some more confusion ) for IR communications. It's basically completely oPossum's EHP TV-B-Gone design for the transmitter part, and also oPossum's IR Widget for the receiver parts. You may think of it as Dangerous Prototypes' USB IR Toy for the LaunchPad, but with more oomph.
     
    There's a healthy list of compile-time configurability and features:
     


    [*:22nw21ko]selectable transmitter power source (LP's VCC or external)
    [*:22nw21ko]FTDI cable-compatible RX/TX breakout for the capturing sessions when 9k6 is not enough, selectable for both pre-'2553 and '2553-style RX/TX pinout
    [*:22nw21ko]IR demodulator for your remote
    [*:22nw21ko]IR photodiode for capturing your unknown remote's codes
    [*:22nw21ko]five transmitter blocks (wire in as few or as many as you actually need)
    [*:22nw21ko]all of these are functions are wired to pins where they make most sense
    [*:22nw21ko]unused pins brought out to a tiny bit of a prototyping area so you can do this properly right on the board
    [*:22nw21ko]all of this in 1206 so you can build it even if your kit is a copper rod and a BBQ fireplace
     
    Software-wise there's nothing overly usable yet, but the CIR capture thread and the IR Widget writeup is more or less what one needs to get going.
     
    A big "thank you" to oPossum is quite in order; he has been invaluable help. Thank you!
     


     
    I am now seeking input as to what else might be there you'd like added (though I want to keep it IR-only, and it's pretty good at that , or anything else you may want to add. I'll keep this afloat for a couple of days, then replace these design files with the final ones.(The Eagle files will come soon, when Bluehash allows .sch/.brd attachments :mrgreen: )
    ir8.sch
    ir8.brd
  4. Like
    gordon got a reaction from zeke in Allow .brd and .sch file attachments   
    Seriously, how come noone asked for this before? :twisted:
  5. Like
    gordon reacted to gwdeveloper in WS2801 RGB Led Strip   
    Hey guys, just to break the programming monotony and get the kiddo more interested in electronics, we ported the Arduino code over to control the WS2801 RGB Led Strip from Sparkfun. http://www.sparkfun.com/products/10312 We scored one of these from their 'scratch & dent' sales a while back at half price. It's not waterproof but rainbow lights entertain an 8 year girl like nothing else.
    It runs fine at 3.3v but the Launchpad does not supply enough current to run the strip so we're using a breadboard power supply as well. The software is running on a G2553 plugged into the LP but running at 1MHz. The SPI is bit banged so it should load fine on other devices as well.
    The goal with this is to mount it above her bedroom window, tape a thermistor to the window and provide ambient light based on temperature as well as using a rotary encoder to allow her to set the color on demand.
    Now I think I want another to cut down into a matrix for simple animations.
     

    http://www.youtube.com/watch?v=4qlUw-dbkew
     

    /****************************************************************/ /* Greg Whitmore */ /* greg@gwdeveloper.net */ /* www.gwdeveloper.net */ /****************************************************************/ /* released under the "Use at your own risk" license */ /* use it how you want, where you want and have fun */ /* debugging the code. */ /* MSP430 spi bit bang WS2801 RGB LED strip */ /****************************************************************/ /* code was translated from adafruit ws2801 arduino library */ /* https://github.com/adafruit/WS2801-Library */ #include // constant defines #define DATA BIT7 #define CLOCK BIT6 #define NUMLEDS 32 // wdt delay constants #define MCLK_FREQUENCY 1000000 #define WDT_DIVIDER 512 const unsigned long WDT_FREQUENCY = MCLK_FREQUENCY / WDT_DIVIDER; volatile unsigned long wdtCounter = 0; // data arrays unsigned long pixels[NUMLEDS]; //incrementers int p; long i; // prototypes void init(void); void display(void); unsigned long color(unsigned char r, unsigned char g, unsigned char ; void setPixelS(unsigned int n, unsigned long c); void setPixel(unsigned int n, unsigned char r, unsigned char g, unsigned char ; unsigned long wheel(unsigned char wheelpos); // pattern functions void copcar(void); void goJoe(unsigned long time); // larger time value is slower chase void randomdance(void); void solidblink(unsigned long c); void colorwipe(unsigned long c); void rainbowcycle(void); void showrainbow(void); // random function and delay millis borrowed from NatureTM.com // random generator slightly modified to create 32bit value unsigned long adcGenRand32(void); void delayMillis(unsigned long milliseconds); // main colors unsigned long clear = 0x000000; unsigned long red = 0xFF0000; unsigned long green = 0x00FF00; unsigned long blue = 0x0000FF; unsigned long white = 0x80FFFF; // red is half strenght; full strength yields pink instead of white unsigned long randomcolor; void main(void) { //WDTCTL = WDTPW + WDTHOLD; // use 1MHz calibrated values DCOCTL = CALDCO_1MHZ; BCSCTL1 = CALBC1_1MHZ; // wdt set as interval WDTCTL = WDTPW + WDTTMSEL + WDTIS1; // wdt interrupt IE1 |= WDTIE; // enable global interrupts using intrinsic __enable_interrupt(); // initialize pins for SPI init(); colorwipe(clear); // clear led strip while (1) { int x; // run demos for display for (x = 0; x < 3; x++) { copcar(); } for (x = 0; x < 3; x++) { goJoe(50); } for (x = 0; x < 5; x++) { randomdance(); } colorwipe(clear); for (x = 0; x < 3; x++) { solidblink(green); } for (x = 0; x < 2; x++) { rainbowcycle(); } } } /* use functions */ // police light bar chaser void copcar(void) { int m; int middle = NUMLEDS / 2 ; colorwipe(clear); for ( m = 0; m < NUMLEDS; m++ ) { if ( m <= middle ) { pixels[m] = red; pixels[m - 2] = clear; pixels[NUMLEDS - m] = blue; pixels[NUMLEDS - m + 2] = clear; } display(); if ( m >= middle ) { pixels[m] = blue; pixels[m - 2] = clear; pixels[NUMLEDS - m] = red; pixels[NUMLEDS - m + 2] = clear; } display(); } } // red white and blue chasers void goJoe(unsigned long time) { int m; colorwipe(clear); // clear display from existing patterns for ( m = 0; m < NUMLEDS; m++ ) { pixels[m] = blue; pixels[m - 1] = red; pixels[m - 2] = white; pixels[m - 3] = clear; display(); delayMillis(time); } for ( m = NUMLEDS; m >= 0; m-- ) { pixels[m] = clear; pixels[m - 1] = white; pixels[m - 2] = red; pixels[m - 3] = blue; display(); delayMillis(time); } } // send random colors down each pixel void randomdance(void) { int m; for ( m = 0; m < NUMLEDS; m++ ) { pixels[m] = adcGenRand32(); display(); } } // blink solid color void solidblink(unsigned long c) { colorwipe(c); delayMillis(500); colorwipe(clear); } // animate fading rainbow cycle void rainbowcycle(void) { int k, j; for ( j=0; j<256; j++ ) { for ( k=0; k < NUMLEDS; k++ ) { setPixelS(k, wheel( ( k+j) % 255 ) ); } display(); delayMillis(100); } } // display static rainbow void showrainbow(void) { int k, j; for ( j=0; j < 256 * 5; j++ ) { for ( k=0; k < NUMLEDS; k++ ) { setPixelS(k, wheel( ((k * 256 / NUMLEDS ) + j) % 255) ); } } display(); delayMillis(100); } // wipe strip to selected color void colorwipe(unsigned long c) { int v; for ( v=0; v < NUMLEDS; v++) setPixelS(v, c); display(); //delayMillis(100); } /* library functions */ //initialization void init(void) { P1DIR |= DATA + CLOCK; // set data and clock pins to output } // send data to led strip; create patten with a 'use' function then send with display void display(void) { unsigned long data; P1OUT &= ~CLOCK; delayMillis(1); // send all the pixels for ( p=0; p < NUMLEDS ; p++ ) { data = pixels[p]; // 24 bits of data per pixel for ( i=0x800000; i>0 ; i>>=1 ) { P1OUT &= ~CLOCK; if (data & i) { P1OUT |= DATA; } else { P1OUT &= ~DATA; } P1OUT |= CLOCK; // latch on clock rise } } // toggle clock low to display data P1OUT &= ~CLOCK; delayMillis(1); } // create 24bit color value unsigned long color(unsigned char r, unsigned char g, unsigned char { unsigned long c; c = r; c <<= 8; c |= g; c <<= 8; c |= b; return c; } // set pixel to specified color void setPixel(unsigned int n, unsigned char r, unsigned char g, unsigned char { unsigned long data; if (n > NUMLEDS) return; data = g; data <<= 8; data |= b; data <<= 8; data |= r; pixels[n] = data; } //set pixel to color by function void setPixelS(unsigned int n, unsigned long c) { if ( n > NUMLEDS ) return; pixels[n] = c & 0xFFFFFF; } // rotate colorwheel for rainbows unsigned long wheel(unsigned char wheelpos) { if (wheelpos <85) { return color( wheelpos * 3, 255 - wheelpos * 3, 0 ); } else if ( wheelpos < 170 ) { return color( 255 - wheelpos * 3, 0, wheelpos * 3 ); } else { wheelpos -= 170; return color( 0, wheelpos * 3, 255 - wheelpos * 3 ); } } // generate random 32bit number using ADC10 channel 5; leave P1.4 & P1.5 floating unsigned long adcGenRand32(void) { char bit; unsigned long random; for(bit = 0; bit < 32; bit++){ ADC10CTL1 |= INCH_5; ADC10CTL0 |= SREF_1 + ADC10SHT_1 + REFON + ADC10ON; ADC10CTL0 |= ENC + ADC10SC; while(ADC10CTL1 & ADC10BUSY); random <<= 1; random |= (ADC10MEM & 0x01); } return random; } // millisecond delay counter using WDT void delayMillis(unsigned long milliseconds){ unsigned long wakeTime = wdtCounter + (milliseconds * WDT_FREQUENCY / 1000); while(wdtCounter < wakeTime); } // wdt isr #pragma vector=WDT_VECTOR __interrupt void watchdog_timer(void){ wdtCounter++; }
  6. Like
    gordon reacted to zeke in F5529 Breakout Dev Board (Now with pics!)   
    If you have a ton of TH crystals then your choice makes sense. The guy you sell this board to may not though.
     
    The only gotcha with a TH crystal is that you can't let the body of the crystal touch the ground plane you've poured under it. If it does then it probably is also touching the tracks coming from the crystal pins and that shorts out the crystal. That's why TH crystals had insulator pads on them in ancient days.
     
    The USB tracks should make the straightest line between the connector and the chip as reasonably possible. Make sure the tracks are 0.010" wide. Make sure they have a 0.010" space between them. That's it. Any components that have to attach to the USB tracks should do so at a 90' angle so that the track path isn't disturbed. It is also preferable to minimize their length, if possible.
     
    I haven't consulted the design files for TI's 5529 board so I don't understand their design selections. The 27 ohm resistors are there to minimize the transient responses that occur on the USB lines. They limit the current spikes but they also lower the maximum speed on that transmission line. I guess it all depends upon the MCU and what it expects. For comparison, the FTDI chips want 0 to 10 ohms there.
     
    There's no need to worry about your EE skills. You are demonstrating good EE skills with your work. Just because I'm buffing your layout doesn't mean it's a bad design. I'm sure the design will work. I'm just offering a contrasting opinion for you to compare against. It's like two artists talking about a work of art - a matter of taste and opinion for the most part.
     
    Again, GOOD JOB! And I mean it! :thumbup:
  7. Like
    gordon reacted to n1ksn in State Machine Example Code   
    *** Note: There is an upgraded version of this code in a following post. ***
     
    This is a second state machine implementation based on material in Chapter 3 in Samek. Once again, it blinks three LEDs.
     
    In this version there is no table of state transition functions. Instead there is one "state handler function" for each state. The state handler function contains a switch statement based on the Event/Signal received. There are special switch cases for state entry and exit functions, and these are automatically executed on a state transition by the state machine dispatch function. The state handler functions return status codes, but in this version one of these is actually used (the one for transitions). The others were intended, I believe, to be used in a tracing facility.
     
    As for the previous implementation, the user adds state machine parameters or event parameters by derivation from base structures.
     
    I have made a small change in the applicaton by replacing led_is_off_ticks with led_period_ticks. This was done in anticipation of a future implementation that uses pushbuttons to modify the led blink rates. I also increased the system tick period to about 15.9 ms, since this is small enough for led flashing.
     
    Although this implementation uses a couple of funky macros and is somewhat more difficult to follow (especially the initialization steps), it is nice in that there is one state handler function for each state, and the entry and exit functions are clearly indicated. This makes for a better correspondence between code and the state diagram. Also, there is no storage needed for a state transition table which could get large and sparse in large systems.
     
    On the down side, these handler functions might get long if there are many signal types to be checked in the switch statement, and this might be a problem when things must be accomplished within a single system tick. Fortunately, the switch statement in each handler only needs to include events/signals relevant to that state.
     
    Cheers,
    Andy N1KSN
     
    StateMachineBlink.zip
     
    The C code for the primary module:
     

    //------------------------------------------------------------------------------ // Blink.c in project StateMachineBlink // // This program blinks three LEDs at different rates using state machine // functions based on the QEP FSM processor found in Chapter 3 of "Practical // UML Statecharts in C/C++" by Miro Samek. (Copyright (C) 2002-2007 Miro // Samek. All rights reserved.) // // In this implementation there is no table of state transition functions. // Instead there is one "state handler function" (SHF) for each state. Each SHF // contains a switch statement with cases based on the event signals received. // There are special cases for state entry and state exit functions, which are // automatically invoked by the state machine dispatch function when a state // transition occurs. // // There are two states in this LED blinking state machine, LED_IsOn and // LED_IsOff. // // There is only one type of user event in this state machine, a tick from a // timer interrupt ISR. Blink_ProcessEvents is called by main upon wake-up // from this ISR. // // The state handler functions in this state machine also implement a countdown // timer which determines how long that state is held. On entry the timer // counter is set for the delay interval. The counter is decremented if the // state is active and a tick event occurs. If the delay interval is not over // no state transition occurs. When the counter times out the guard condition // is met and there is a transition to the new state. // // Andrew Palm // 2011.09.30 //------------------------------------------------------------------------------ #include #include #include "System.h" #include "StateMachine.h" #include "Blink.h" // Each tick approximately 15.6 ms with ACLK at 32768 Hz (256 ticks/sec) #define LED1_PERIOD_TICKS 3*(TICKS_PER_SEC) #define LED1_IS_ON_TICKS (LED1_PERIOD_TICKS / 96) // 1/3 Hz, short duty cycle #define LED2_PERIOD_TICKS TICKS_PER_SEC #define LED2_IS_ON_TICKS (LED2_PERIOD_TICKS / 2) // 1 Hz, 50% duty cycle #define LED3_PERIOD_TICKS (TICKS_PER_SEC / 8) #define LED3_IS_ON_TICKS (LED3_PERIOD_TICKS / 4) // 8 Hz, 25% duty cycle //------------------------------------------------------------------------------ // Blink LED finite state machine enum BlinkSignals { // Signals for the Blink FSM TICK_SIG = SM_USER_SIG }; typedef struct TickEvtTag { Event super; // Derived from Event structure } TickEvt; // For this application, no additional user parameters typedef struct BlinkTag { // The Blink FSM StateMachine super; // Derived from StateTable structure uint16_t delay_ticks; // Number of delay ticks remaining uint16_t led_is_on_ticks; // Number of delay ticks for on state uint16_t led_period_ticks; // Number of ticks for flash period volatile uint8_t *led_port; // Pointer to LED port uint8_t led_bitmask; // Bit mask for LED pin uint8_t filler; } Blink; static Blink Blink_1; // Blink FSM for LED1 static Blink Blink_2; // Blink FSM for LED2 static Blink Blink_3; // Blink FSM for LED3 //------------------------------------------------------------------------------ // The "constructor" for Blink state machines void Blink_Ctor(Blink *me, uint16_t led_is_on_ticks, uint16_t led_period_ticks, uint8_t led_bitmask, volatile uint8_t *led_port); static Status Blink_Initial(Blink *me, Event const *e); // Initial trans static Status Blink_LED_IsOff(Blink *me, Event const *e); // State handler fn static Status Blink_LED_IsOn(Blink *me, Event const *e); // State handler fn //------------------------------------------------------------------------------ void Blink_Ctor(Blink *me, uint16_t led_is_on_ticks, uint16_t led_period_ticks, uint8_t led_bitmask, volatile uint8_t *led_port) { StateMachine_Ctor(&me->super, (SHF)&Blink_Initial); // Construct superclass // Set user parameters me->led_is_on_ticks = led_is_on_ticks; me->led_period_ticks = led_period_ticks; me->led_bitmask = led_bitmask; me->led_port = led_port; } //------------------------------------------------------------------------------ Status Blink_Initial(Blink *me, Event const *e) { (void)e; // Avoid unused parameter warning // Insert any additional initialization actions here that are not state // entry actions or initializations done in the constructor. return SM_TRAN(&Blink_LED_IsOn); // Transition to initial state } //------------------------------------------------------------------------------ Status Blink_LED_IsOff(Blink *me, Event const *e) { switch (e->sig) { case TICK_SIG: { me->delay_ticks--; // Decrement timer counter if(0 == me->delay_ticks) // Transition guard condition { return SM_TRAN(Blink_LED_IsOn); // Transistion to new state } return SM_HANDLED(); } // Insert any other user signal type cases here case SM_ENTRY_SIG: { *(me->led_port) &= ~(me->led_bitmask); // Turn off LED // Reload delay timer me->delay_ticks = me->led_period_ticks - me->led_is_on_ticks; return SM_HANDLED(); } case SM_EXIT_SIG: { return SM_HANDLED(); } } return SM_IGNORED(); } //------------------------------------------------------------------------------ Status Blink_LED_IsOn(Blink *me, Event const *e) { switch (e->sig) { case TICK_SIG: { me->delay_ticks--; // Decrement timer counter if(0 == me->delay_ticks) // Transition guard condition { return SM_TRAN(Blink_LED_IsOff); // Transistion to new state } return SM_HANDLED(); } // Insert any other user signal type cases here case SM_ENTRY_SIG: { *(me->led_port) |= me->led_bitmask; // Turn on LED me->delay_ticks = me->led_is_on_ticks; // Reload delay timer return SM_HANDLED(); } case SM_EXIT_SIG: { return SM_HANDLED(); } } return SM_IGNORED(); } //------------------------------------------------------------------------------ void Blink_InitializeHW(void) { TACCR0 = TICK_DIVISOR; // Prepare first interrupt } void Blink_InitializeApp(void) { Blink_Ctor(&Blink_1, LED1_IS_ON_TICKS, LED1_PERIOD_TICKS, LED1, &LEDOUTA); // Make initial transition StateMachine_Init((StateMachine *)&Blink_1, (Event *)0); Blink_Ctor(&Blink_2, LED2_IS_ON_TICKS, LED2_PERIOD_TICKS, LED2, &LEDOUTA); // Make initial transition StateMachine_Init((StateMachine *)&Blink_2, (Event *)0); Blink_Ctor(&Blink_3, LED3_IS_ON_TICKS, LED3_PERIOD_TICKS, LED3, &LEDOUTB); // Make initial transition StateMachine_Init((StateMachine *)&Blink_3, (Event *)0); } //------------------------------------------------------------------------------ void Blink_ProcessEvents(void) // Called from main after wakeup { static TickEvt tick_evt = { TICK_SIG }; // Single event type, a tick // Send tick event to each state machine StateMachine_Dispatch((StateMachine *)&Blink_1, (Event *)&tick_evt); StateMachine_Dispatch((StateMachine *)&Blink_2, (Event *)&tick_evt); StateMachine_Dispatch((StateMachine *)&Blink_3, (Event *)&tick_evt); } //------------------------------------------------------------------------------ #pragma vector=TIMER0_A0_VECTOR __interrupt void TimerA_CCR0_ISR(void) // ISR to generate regular ticks { TACCR0 += TICK_DIVISOR; // Update for next interrupt __low_power_mode_off_on_exit(); // Wake the processor }
  8. Like
    gordon reacted to pabigot in MSP430 USB FET (JTAG + SBW)   
    Whatever said to use -d for the MSP-FET430UIF is out of date. Use -U if you need to select a specific FET, otherwise all you should need is -j (with the current git release, at least, and only if your target uses JTAG instead of SBW).
     

    linux[444]$ lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 0409:005a NEC Corp. HighSpeed Hub Bus 002 Device 012: ID 0451:f432 Texas Instruments, Inc. eZ430 Development Tool Bus 001 Device 012: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 005 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 002 Device 014: ID 0451:f430 Texas Instruments, Inc. MSP-FET430UIF JTAG Tool linux[445]$ mspdebug -j -U 2:14 uif MSPDebug version 0.17 - debugging tool for MSP430 MCUs Copyright (C) 2009-2011 Daniel Beer This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ti3410: warning: can't detach kernel driver: No such file or directory TI3410 device is in boot config, setting active Initializing FET... FET protocol version is 20405003 Configured for JTAG (2) Set Vcc: 3000 mV Device ID: 0x0580 Device: MSP430F5438A Code memory starts at 0x5c00 Number of breakpoints: 8 Available commands: = delbreak gdb load opt reset simio alias dis help locka prog run step break erase hexout md read set sym cgraph exit isearch mw regs setbreak Available options: color gdb_loop iradix fet_block_size gdbc_xfer_size quiet Type "help " for more information. Press Ctrl+D to quit. (mspdebug)
  9. Like
    gordon got a reaction from zeke in STM32F4DISCOVERY for $21.00   
    https://sourcery.mentor.com/sgpp/lite/a ... plate=lite
     
    You want the EABI one, as far as I can tell.
     
    The following links may also be of interest (to some):
     
    https://github.com/texane/stlink
    http://code.google.com/p/stm32flash/
     
    (Haven't tried any of these, just have them stashed away ).
  10. Like
    gordon got a reaction from nuetron in TV-B-Gone using Launchpad   
    http://thecustomgeek.com/2011/09/13/fun ... 4-of-them/
     
    Fun's in the video .
  11. Like
    gordon reacted to oPossum in TV-B-Gone using Launchpad   
    Consumer IR is 940/950 nm, so whatever LED you choose, make sure it is the proper wavelength. The IR333 type is a very common generic IR LED. It is made by many manufactures and there are a few variants of it. The exact specs and quality will vary from one mfg to another. I have been using Vishay IR LEDs - mostly TSAL6200. They have superior specs, but I don't know if that makes any real difference in the real world. Here is a list of some of the Vishay parts and two IR333 for comparison...
     

    IR333A 20 degrees TSAL6100 20 degrees TSAL5100 20 degrees TSAL6200 35 degrees TSAL7200 35 degrees IR333C/H0/L10 40 degrees TSAL5300 45 degrees TSAL7300 45 degrees TSAL6400 50 degrees TSAL7400 50 degrees TSAL7600 60 degrees
     
    I think the TASL6x00 and TSAL7x00 are the same die in a different package (tinted vs clear).
     
    A PN2222A or PZT2222A works well for driving the IR LED. The beta drops as IC (collector current) increases, so it is effectively current limited. It is a proven design (that is often questioned by those who don't understand it). An IR LED will typically handle 50 to 100 mA continuous, and 500 to 1000 mA for a short time. Most IR protocols use bursts of 30 to 60 kHz, so the IR LED can be driven near it's maximum rating. The Vf is about 1 volt (current dependent), much lower than visible LEDs. If you are developing firmware then it is a good idea to limit the current to 50 mA or less until the code is proven to work properly.
     
    I have not done any hardware for the MSP430 yet, but I have done some AVR designs that show the IR LED driver circuit.
     
    The CHiP (Compact High Power): This design fits in one compartment of a AA battery holder. It can operate at moderate power when 2 AA cells are used, or high(er) power when 3 AA cells are used. An emitter follower is used for the high power mode only.
     
    The EHP (Extereme High Power): Several adafruit forum members built this and it performs very well. It pulls about 6 amp pulses from the 4 AA cells and often makes them squeal.
     
    Keychain: Uses two CR2032 cell - one for the micro, and one for the MCU. This prevents MCU brownout while allowing max LED current.
  12. Like
    gordon got a reaction from madmartigan in Programming/Flashing with MSP-FET430UIF in linux   
    (mspdebug) prog file.hex
    In mspdebug's case, you don't need to convert it to Intel hex (if there are no other reasons for you to do so), it will just work fine with prog'ing file.elf directly.
     
    You may have to use load instead of prog; it's only the FRAM parts that need it that I know off the top of my head, though. Whichever works for you.
     
    More on ELF .
  13. Like
    gordon got a reaction from linuxmill in MSP430 USB FET (JTAG + SBW)   
    Here's a tip, based on this post, try

    mspdebug -j -d /dev/ttyUSB0 uif
    (that is, JTAG mode instead of SBW, -j). Does that change anything?
     
    Sorry, wasn't reading the previous posts carefully enough :oops:
  14. Like
    gordon reacted to oPossum in TV-B-Gone using Launchpad   
    This is a reimplementation of adafruit's TV-B-Gone kit. It has been written from scratch to be more efficient and more precise than the AVR version. Assembly code is used for the critical timing, everything else is in C. Clock is 1 MHz (vs. 8 MHz for AVR).
     
    This code is small enough to fit in a G2231 (2K flash, 128 RAM) that comes with the launchpad. There are only 39 codes due to limited flash capacity. Obviously larger parts like the G2553 could be used to fit all codes and add additional features.
     
    main code (excerpt)

    void send_code(TIRCODE * const ic) { const uint8_t *code_byte; unsigned code_bitmask; static uint8_t idx[100]; // static so it is not on the stack unsigned n, j; uint8_t *p; // Make sure there is room for all indicies if(ic->pair_count > sizeof(idx)) return; // Convert variable bit count to uint8_t n = ic->pair_count; code_byte = ic->bitstream; code_bitmask = 0x80; p = idx; // Iterate indicies while(n--) { *p = 0; j = ic->bits_per_index; // Iterate bits while(j--) { *p <<= 1; if(*code_byte & code_bitmask) *p |= 4; code_bitmask >>= 1; if(!code_bitmask) ++code_byte, code_bitmask = 0x80; } ++p; } if(ic->carrier_period) { TACCR0 = ic->carrier_period; TACCR1 = ic->carrier_period >> 1; tx_ir_carrier(ic->pair_count, idx, ic->durations); } else { tx_ir_pulse(ic->pair_count, idx, ic->durations); } } void main(void) { unsigned n; WDTCTL = WDTPW + WDTHOLD; // Disable watchdog // DCOCTL = 0; // Use 1 MHz calibration BCSCTL1 = CALBC1_1MHZ; // DCOCTL = CALDCO_1MHZ; // // // See chart for I/O assignment P1OUT = 0x0E; // Txd, Rxd, S2 high P1REN = 0x0C; // Rxd / S2 pullup enabled P1DIR = 0xF3; // Rxd / S2 in, all others out P1SEL = 0x50; // Timer A T0.1 / SMCLK TACTL = TASSEL_2 | MC_1; // Clock = SMCLK, Mode = UP // do { // /// todo: Sleep while waiting for S2 press // while(P1IN & 8); // Wait for S2 press // for(n = 0; n < code_count; ++n) { // P1OUT |= 0x01; // LED on delay10us(450 * 100u); // Wait 450 ms P1OUT &= ~0x01; // LED off send_code(CodeList[n]); // Send code } // } while(1); // }
     
    ir transmission code (excerpt)

    tx_ir_carrier ; void tx_ir_carrier(unsigned n, uint8_t *i, TDUR *d) ; R12 Duration pair count ; R13 Pointer to duration indicies ; R14 Pointer to durations ; mov #OUTMOD_7, R10 ; IR Carrier On (reset/set output mode) mov #OUTMOD_5, R11 ; IR Carrier Off (reset output mode) ; ir_tx_loop mov.b @R13, R15 ; Get duration index add R14, R15 ; Add duration pointer mov @R15, R15 ; Get duration ; mov R10, &TACCTL1 ; Turn on IR call #delay ; Wait for on duration ; nop2 ; Precise timing ; mov.b @R13+, R15 ; Get duration index and increment pointer incd R15 ; Adjust for off duration add R14, R15 ; Add duration pointer mov @R15, R15 ; Get duration ; mov R11, &TACCTL1 ; Turn off IR call #delay ; Wait for off duration ; dec R12 ; Decrement pair count jne ir_tx_loop ; Do next duration pair... ; ret ; Return ; ; ; ; - Delay in units of 10 cycles (10 us at 1 MHz) delay cmp #4, R15 ; Compare to minimum jlo dlyret ; Below minimum, return... sub #2, R15 ; Adjust loop count for overhead jmp eloop ; Make the first iteration shorter ; delay10us mov R12, R15 ; C callable ; dloop nop2 ; 7 cycles of nop nop2 ; nop2 ; eloop nop ; dec R15 ; Decrement loop count - 1 cycle jne dloop ; Loop if not zero - 2 cycles ; dlyret ret ;
     
    Complete code attached
    tvbg_lp.zip
  15. Like
    gordon got a reaction from bluehash in Real Time Clocks   
    Haven't worked with them yet (they are on the shortlist though), the popular ones are DS1307 (more of Dallas' selection) and the Philips ones.
  16. Like
    gordon got a reaction from bluehash in Booster pack sub-forum   
    While reading this post by this PhirePhly character who's known to camp around here :wave: :wave: , I had this idea. How about having a custom URL-shortener "service" so one could put (example) http://43oh.com/p/1 on the silk, which would then redirect to viewtopic.php?f=9&t=1602 (taking one of Rob's things as an example)?
  17. Like
    gordon reacted to pabigot in TI MSP430 and open source   
    I think TI like any huge company with a bunch of different product lines lacks a unified perspective on open source, but the MSP430 folks seem to get it. They were very cooperative providing mspgcc the same headers used in IAR's commercial compiler and their own Code Composer line, with custom tweaks to meet mspgcc's needs, and augmenting that with the raw chip-relevant parameters in a CSV file (part of msp430-mcu) that enabled me to support all 300+ chips without being a maintenance nightmare. They were clear on wanting it to be BSD-compatible from the start, but it did take a couple months before they were able to provide the license text, suggesting corporate overhead. We still need to work out a solid update process, but all signs say they're onboard with that.
     
    Ian, please convey to them our strong appreciation of that support.
     
    I've discussed funding mspgcc work with them, and at certain levels at least they're interested. The Microchip offer does not help, though: having ported TinyOS to the CC430 (a comparable effort), to offer $1000 for something that's a minimum of 300 hours work for an experienced developer is cheap and insulting. My reaction on seeing that "bounty" echoed Linda Evangelista.
     
    Couple things I'd like to see if TI is looking into a holistic open-source move:
     
    Work with the Linux kernel folks in getting real support for their serial USB stuff. Even if it's stuck at 9600kbps and bit-banging RS232 with the as-delivered chips, I should be able to get serial in and out of a launchpad USB connector without having to buy an FTDI breakout board (or use a bus pirate). The EXP430 board has a similar, but perhaps simpler, issue (I've gotten that to mostly work by adding the vendor/product IDs into the ti_usb_3410_5052 driver, though it's not quite right).
     
    Open-source the SimpliciTI RF stack. I could write a whole essay on why 6lowpan isn't going to fly for last-mile wireless sensors, but want to get to breakfast before noon. I don't know whether this makes business sense for them, but in my hobbyist role I'd be more likely to use it if open sourced.
  18. Like
    gordon got a reaction from pabigot in TI MSP430 and open source   
    A huge thanks for taking up this issue.
     
    The MSPGCC toolchain works really well, and Peter is doing a really wonderful job on it. I do not know how much is TI involved in the development; Peter hinted somewhere (don't remember if it was on IRC or one of the MSPGCC lists or maybe somewhere else) that someone is funding the development, but it is unclear if it's TI or if they are involved at all (never asked, though).
     
    It would certainly make a warm fuzzy feeling if they'd get involved, should Peter think to need some assistance of any form. I know that MSPGCC has and distributes TI's headers (they are licensed standard 3-clause BSD), which is a nice touch.
     
    Toolchain-wise, the other side of the coin is MSPDebug. I don't know of any other actively-developed thing that bridges the gap between compiling an application and actually talking to the device, so, without this, there's really no life . I am also reasonably sure Daniel develops MSPDebug on his own, without any TI involvement or anything.
     
    There's then the open source release of MSP430.dll v3, which is a very nice thing, except so far it looks more like a code dump rather than open development. Granted, it is pretty fresh meat as of now, so it could turn out to be anything, but for now my limited understanding is people don't yet know what to make of it on the long run (don't think there's any documentation except for some reference, no real vision of how its future will look like, non-Windows build things are separate, off the top of my head ). But, as said, it's a start.
     
    Libraries- and such things-wise, I don't know but I'm hazarding a guess that they are at best free beer, though some are definitely worse: both the Eagle library and the code examples come without any sort of license at all (which means full copyright and only full copyright, no additional rights granted whatsoever). Technically speaking, this makes the distribution of any such nice improvements borderline illegal. This is not only sad, but also counterintuitive and -productive, since TI's version is generally rather unusable (for their use of a non-standard grid setting, head to head against all CadSoft/Eagle recommendations and best practices).
     
    I am not (yet?) using any TI-provided libraries (so no opinion here), but for, say, the examples (SLAC017, but possibly all app note code), a friendly license would be more than useful in, say, porting them to MSPGCC and also distributing these ports.
     
    The fact that TI doesn't currently pursue such violations is their goodwill, but they are not legally bound not to (as would be the case with a suitable license).
     
    This is (my best current understanding of) how things are at the moment. It's not bad, we've seen worse, they also apparently mean good, but it's still a long road ahead.
     
    Ed.: I just read your blog entry wrt. Microchip vs. open source, allow me to quote a bit for the context:
     
  19. Like
    gordon got a reaction from zborgerd in TI MSP430 and open source   
    A huge thanks for taking up this issue.
     
    The MSPGCC toolchain works really well, and Peter is doing a really wonderful job on it. I do not know how much is TI involved in the development; Peter hinted somewhere (don't remember if it was on IRC or one of the MSPGCC lists or maybe somewhere else) that someone is funding the development, but it is unclear if it's TI or if they are involved at all (never asked, though).
     
    It would certainly make a warm fuzzy feeling if they'd get involved, should Peter think to need some assistance of any form. I know that MSPGCC has and distributes TI's headers (they are licensed standard 3-clause BSD), which is a nice touch.
     
    Toolchain-wise, the other side of the coin is MSPDebug. I don't know of any other actively-developed thing that bridges the gap between compiling an application and actually talking to the device, so, without this, there's really no life . I am also reasonably sure Daniel develops MSPDebug on his own, without any TI involvement or anything.
     
    There's then the open source release of MSP430.dll v3, which is a very nice thing, except so far it looks more like a code dump rather than open development. Granted, it is pretty fresh meat as of now, so it could turn out to be anything, but for now my limited understanding is people don't yet know what to make of it on the long run (don't think there's any documentation except for some reference, no real vision of how its future will look like, non-Windows build things are separate, off the top of my head ). But, as said, it's a start.
     
    Libraries- and such things-wise, I don't know but I'm hazarding a guess that they are at best free beer, though some are definitely worse: both the Eagle library and the code examples come without any sort of license at all (which means full copyright and only full copyright, no additional rights granted whatsoever). Technically speaking, this makes the distribution of any such nice improvements borderline illegal. This is not only sad, but also counterintuitive and -productive, since TI's version is generally rather unusable (for their use of a non-standard grid setting, head to head against all CadSoft/Eagle recommendations and best practices).
     
    I am not (yet?) using any TI-provided libraries (so no opinion here), but for, say, the examples (SLAC017, but possibly all app note code), a friendly license would be more than useful in, say, porting them to MSPGCC and also distributing these ports.
     
    The fact that TI doesn't currently pursue such violations is their goodwill, but they are not legally bound not to (as would be the case with a suitable license).
     
    This is (my best current understanding of) how things are at the moment. It's not bad, we've seen worse, they also apparently mean good, but it's still a long road ahead.
     
    Ed.: I just read your blog entry wrt. Microchip vs. open source, allow me to quote a bit for the context:
     
  20. Like
    gordon got a reaction from bluehash in Logo.   
    I don't likey the font. Too soft. Too many curves . I'm not saying Eagle vector font, but a bit more edges would look better, IMHO.
     
    The bit pattern for "o" is cool. Maybe make that red, and lose the (currently red) dot. The red/grey scheme is good, though, I'd keep that.
  21. Like
    gordon reacted to zeke in Quad USB UART project   
    Cool!
     
    Then here's the pdf version again:
    QuadUSBUart.pdf
  22. Like
    gordon got a reaction from zborgerd in Quad USB UART project   
    The really cool would be if the ports had (optional) level shifters as well, so one could choose to connect a particular port "natively" to TTL-ish-level devices, or, by using a different set of connector pins (or whatever), to RS-232 level devices via a level shifter.
     
    I quite like this as-is; the level shifters would just make it the be-all-end-all of USB-serial bridges .
  23. Like
    gordon reacted to DrMag in Comparator input not floating?   
    For those who are waiting, the post is now up. On to bigger and better things! I'm excited to start working on this again.
  24. Like
    gordon got a reaction from zeke in Logic Analyzer   
    If implementing the sump protocol is an alternative, then a client is available right away. It's also Java and apparently supports some sort of plugin system, so you could probably even tweak things to your liking (haven't actually checked, this is just based on a cursory look at the sump site).
     
    Dangerous Prototypes' Logic Sniffer and Logic Shrimp are examples of things implementing the protocol and taking advantage of the existing sump client.
     
    Ed.: There are apparently more sump clients available/in development, see http://dangerousprototypes.com/docs/Ope ... r_Software for a nice round-up.
  25. Like
    gordon got a reaction from RobG in Logic Analyzer   
    If implementing the sump protocol is an alternative, then a client is available right away. It's also Java and apparently supports some sort of plugin system, so you could probably even tweak things to your liking (haven't actually checked, this is just based on a cursory look at the sump site).
     
    Dangerous Prototypes' Logic Sniffer and Logic Shrimp are examples of things implementing the protocol and taking advantage of the existing sump client.
     
    Ed.: There are apparently more sump clients available/in development, see http://dangerousprototypes.com/docs/Ope ... r_Software for a nice round-up.
×
×
  • Create New...