Jump to content

gordon

Members
  • Content Count

    536
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by gordon

  1. gordon

    Welcome!

    Just remember... no killy jsolarski... no killy jsolarski... again...
  2. Almost, but that is getting quite workable now. I could kiss you. Metaphorically.
  3. 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.
  4. Ah, http://forum.43oh.com/public/js/mobile_touch.js With that gone at least the foam is back in my mouth.
  5. 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.
  6. ... and make an array of three radio buttons to choose from: Microchip, Atmel, Renesas. Those who complain, pass.
  7. 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 ); }
  8. Thread got me interested, and here's something that I bumped across, might be useful to your application as well: Theory and Applications of the MC34063 and
  9. Welcome to the wonderful world of TI Websites. Get used to it *G*...
  10. viewtopic.php?f=10&t=2207 viewtopic.php?f=10&t=2240
  11. Why, you are used to that aren't you :) *SCNR*
  12. 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.
  13. P1REN |= BUTTON; Also, make blink volatile.
  14. Might be of interest to this project too: viewtopic.php?f=38&t=3392&p=24397
  15. Fresh find: http://mspdebug.git.sourceforge.net/git ... 94b110f07e ...and a group bow towards Daniel's general direction!
  16. 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.
  17. I mean search.php?search_id=active_topics
  18. 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?
  19. gordon

    Hello guys

    viewtopic.php?f=8&t=449
  20. 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.
  21. You need either the FTDI to go from TTL serial to USB or you need the MAX3232 to go from TTL to RS232 (I don't know if the MAX232 can cope with 3.3V, the 3232 can, IIRC).
  22. Connect a USB-serial converter (FTDI cable, whatever) to on the RX and TX pins of J3 on the target side, RX is J3 pin 2, TX is J3 pin 3 (see the schematics and the board layout in SLAC437).
×
×
  • Create New...