Jump to content
43oh

gordon

Members
  • Content Count

    536
  • Joined

  • Last visited

  • Days Won

    13

Posts posted by gordon

  1. No, it's that the above js makes everything a hot spot in the mobile interface. Which is good if you are actually on a mobile phone, I guess. But whatever, I have filtered a couple of javascripts, now at least it doesn't do random things.

     

    Anything like active topics in the old forum? No, "new content" by far isn't what active topics was. Active topics was a sort order -- you still got all of the index with unread posts marked. "New content" is a filter.

  2. Is there some way (another skin or a list of javascripts I could block or whatever) to make this shiny javascripty Web2.0 abomination go away? I may be whiny, but trying to simply select a piece of text making me go in places I never even knew existed isn't very... nice.

     

    I am already using the mobile skin, but even this is bordering on being unusable. Or should I say, this is bordering on being usable, but isn't quite there yet.

  3. This was working a couple of days back... Load on a LaunchPad, poke button. Scratch that, I didn't notice the Energia part. You could still adapt, though.

     

    #include 
    
    #include 
    #include 
    
    #define LED       BIT6
    #define BUTTON    BIT3
    
    #define DEBUG
    #undef DEBUG
    
    #ifdef DEBUG
    #define DEBUGLED  BIT0
    #endif
    
    void __attribute__((interrupt (PORT1_VECTOR))) port1_isr(void);
    void __attribute__((interrupt (WDT_VECTOR))) wdt_isr(void);
    
    #define PWM_PERIOD  128
    static const uint16_t brightness_levels[] = { 0, 6, 23, 56, PWM_PERIOD };
    #define n_brightness_levels ( sizeof( brightness_levels ) / sizeof( brightness_levels[0] ) )
    static volatile uint8_t cur_brightness = 0;
    static volatile uint8_t debounce_ctr = 0;
    
    /* /3 -- WDT_ADLY_250 assumes LFXTCLK @ 32KiHz, VLO is ~12KHz */
    #define POWEROFF_TIMER  (2400 / 3)    /* 10m @ 250ms */
    #if 0
    #undef POWEROFF_TIMER
    #define POWEROFF_TIMER  (40 / 3)    /* TEST: 10 seconds */
    #endif
    
    static volatile uint32_t poweroff_timer = POWEROFF_TIMER;
    static volatile bool poweroff = false;
    
    void main(void)
    {
     WDTCTL = WDT_ADLY_250;      /* 750ms if running on VLO */
    
     BCSCTL2 |= SELM_3 | SELS;   /* MCLK to LFXTCLK, SMCLK to LFXTCLK */
     BCSCTL3 |= LFXT1S_2;      /* LFXT1 to VLO */
    
     IE1 |= WDTIE;
     IFG1 &= ~WDTIFG;
    
     P1DIR |= LED;
    
     CCR0 = PWM_PERIOD;
     CCTL1 = OUTMOD_7;
     TACTL = TASSEL_1;
    
     P1DIR &= ~BUTTON;
     P1IE |= BUTTON;
     P1REN |= BUTTON;
     P1IFG &= ~BUTTON;
     P1OUT |= BUTTON;
    
    #ifdef DEBUG
     P1DIR |= DEBUGLED;
     P1OUT &= ~DEBUGLED;
    #endif
    
     __eint();
    
     while( 1 )
     {
       if( poweroff || cur_brightness == 0 )
       {
         TACTL |= MC_0;
         CCR1 = 0;
         P1SEL &= ~LED;
         P1OUT &= ~LED;
         __bis_status_register( debounce_ctr == 0 ? LPM4_bits : LPM3_bits );
       }
       else
       {
         TACTL |= MC_0;
         if( cur_brightness == n_brightness_levels - 1 )
         {
           P1SEL &= ~LED;
           P1OUT |= LED;
         }
         else
         {
           P1SEL |= LED;
           CCR1 = brightness_levels[ cur_brightness ];
           TACTL |= MC_1;
         }
         __bis_status_register( LPM3_bits );
       }
     }
    
     WDTCTL = 0xDEAD;
    }
    
    void __attribute__((interrupt (PORT1_VECTOR))) port1_isr(void)
    {
     P1IE &= ~BUTTON;
     debounce_ctr = 1;
    
     if( !poweroff && ( ++cur_brightness >= n_brightness_levels ) )
     {
       cur_brightness = 0;
     }
    
     poweroff_timer = 0;
     poweroff = false;
    
     P1IFG &= ~BUTTON;
     __bic_status_register_on_exit( LPM4_bits );
    }
    
    void __attribute__((interrupt (WDT_VECTOR))) wdt_isr(void)
    {
    #ifdef DEBUG
     P1OUT ^= DEBUGLED;
    #endif
    
     /* Decrement debounce_ctr iff > 0, else WDT timer will keep
      * it on for one more loop, causing a delay in poweroff */
     if( debounce_ctr > 0 && --debounce_ctr == 0 )
     {
       P1IFG &= ~BUTTON;
       P1IE |= BUTTON;
     }
    
     if( ++poweroff_timer == POWEROFF_TIMER )
     {
       poweroff = true;
     }
    
     IFG1 &= ~WDTIFG;
     __bic_status_register_on_exit( LPM4_bits );
    }

  4. You can use MSPDebug (I think it can be integrated into CCS, but if not, you can use it separately). No USB FET support in Linux CCS, this fact is noted (I was going to say "prominently" but now I can't find it, so perhaps not that prominently :)) in the release notes. Or on the TI wiki. Or someplace else. Anyway, case in point, no TI support, yes MSPDebug support.

  5. http://justinstech.org/2010/07/msp430-l ... t-how-too/

     

    Try this in various arrangements. Given that you said you had put in bypass caps, I don't really think power is your problem, I rather wager physical arrangement. Crystals don't pay particularly nice with breadboards and like to fault in all curious ways if load capacitance is thrown off even by a tiny bit... Trim your crystal legs such that they are the shortest possible, put it in the breadboard as close to the MCU as possible, and avoid any wiring anywhere close (for a very generous definition of "close") to it (under, over, near, etc.). It probably wouldn't hurt to ground the can either with an as short as possible wire -- lay the crystal flat, if the can reaches over the breadboard power lines, don't run power on that side just ground, and ground the can there. And variations thereupon.

  6. Um, how do you know what load capacitance does this particular crystal need? May be my junk filter or something, but I can see zero technical info on this Maplin page.

     

    Also, what's the physical arrangement of things on your breadboard? A photo would be nice.

     

    Does the rest of your kit work when the crystal doesn't? Also try the osc fault indicator thingy in various arrangements (I think it was on Justin's blog last I remember?), what does it suggest?

  7. This is opening up a whole can of worms you unlikely to want open.

     

    The terminal emulator will send codes according to what it's been configured as -- let's, for simplicity's sake, assume that it is VT100.

     

    To make sense of this, you will need to write a parser for the VT100 terminal codes (multi-byte and traditionally timing-dependant things). Useful to have indeed, but not something I'd want to write for the '2553 :).

     

    http://vt100.net/ will get you started.

×
×
  • Create New...