Jump to content
43oh

cde

Members
  • Content Count

    940
  • Joined

  • Last visited

  • Days Won

    21

Reputation Activity

  1. Like
    cde got a reaction from GeekDoc in What are you working on today/this week?   
    Planning and ordering stage of trying to replicate an object from a tv show.
     

     
    So I'm ordering some EL wire, and sampling some drivers. A inductorless driver, two resistors and two caps, plus a msp430 to add some fading/pulsing, all powered from a single cr2032.
  2. Like
    cde reacted to abecedarian in What are you working on today/this week?   
    Or maybe inductance sense with the LDC1000?
    Get your friends together to pick up the pod, and it glows with 'mediocrity', while you pick it up (with a ring on your finger) and it goes berserk when you get close.
     
  3. Like
    cde got a reaction from simpleavr in What are you working on today/this week?   
    Planning and ordering stage of trying to replicate an object from a tv show.
     

     
    So I'm ordering some EL wire, and sampling some drivers. A inductorless driver, two resistors and two caps, plus a msp430 to add some fading/pulsing, all powered from a single cr2032.
  4. Like
    cde got a reaction from abc in Reversing the LED? i.e. sinking it to MCU?   
    Simply put, you can drive (sink) two leds at 20mA each, from a single port, with a few 0.1Vs raise on Ground, on that port. 40mA cause too much of a drop/raise for 2 leds with a forward voltage drop of 3.3V or higher. That means as the Ground rises from 0.0v to 0.3v, the voltage potential decreases, and the leds will take less current until they finally won't light.
     
    As for anything else on that port, depending on how much the voltage changes, it can interfere, but probably won't. A 3.3V Uart has  0.7V~1V as the highest that a Logic Low is registered, and 1.3V~1.7V as the minimum to register a Logic High. If you draw enough current for that to happen, you have other issues.
     
    But it won't hurt anything to test it out.
  5. Like
    cde reacted to Xuan in Fixing damaged dell power adapter using MSP430G2211   
    This is all about learning OneWire communications. I'm able to make a small "adapter" playing the "man in the middle" hack between dell laptop and its power brick to provide "fake" wattage information. For me I'm using it to "fix" a power adapter which has a damaged identification chip. Of course it can also be used to use non-dell power adapter (on your own risk of damaging the laptop, or even burn your house, who knows...)
     
    All the code and pcb design can be found at https://github.com/HclX/DELL_POWER_SPOOFER.git and my http://hclxing.wordpress.com/2014/02/26/hacking-a-dell-power-adapter-final-not-really/
     
    Some pictures:
      schematic:

     
    pcb layout:

     
    final populated pcb, toner transferred and hand soldered, some of the parts are salvaged from old dvd rom pcb:


     
    dc jack from a broken dell laptop, it took me a fair amount of work to cut the pcb into that shape using my dremel so I can solder the dc jack

     
    connecting with a working power adapter

     
    to prove it's working, i'm faking my working 90W adapter as 65W 


     
    There is still work to do like enabling push button to import data from the connected working adapter, or switching between multiple imported data, making use the led indicator, ...
  6. Like
    cde reacted to p2baron in To stop drolling in front of those Arduino Yun web pages...   
    Please note that the precompiled Openwrt binaries contains ACM drivers that contain a bug. When your MSP430 spits out serial messages before you open the serial port (in python or bash) the driver crashes and no communication is possible. Wasted a couple of hours figuring that out. :-(
    This isn't a problem when the OpenWRT devices initiates communication. You can fix this by modifying the drivers and compiling OpenWRT yourself.
     
    Verstuurd vanaf mijn HTC One met Tapatalk
     
     
  7. Like
    cde reacted to grahamf72 in Timed Camera Remote   
    Here's what has been keeping me busy (apart from my real job) since just after Christmas - a timed camera remote.  It is mostly code complete, although could do with a few tweaks here and there. The hardware however isn't quite finished as I'm still waiting for a few parts to be delivered before I can finally finish it - the most critical of which is the 2.5mm stereo plug to go into the camera. Consequently it hasn't actually fired my camera yet, but I'm confident it will work correctly when the final parts arrive.
     
    Background
    Many moons ago, I created a serial port remote release for my Samsung GX10 DSLR, designed to be triggered from my Palm Pilot. I had a program for the palm that would run through a timed sequence, and could trigger the camera remote release through the Palm's serial port. A circuit diagram of the original is here: http://www.flickr.com/photos/gdaj/1317816870/  (my apologies for the link to an image on another site - this was done years ago, and is only slightly relevant to this project).  It worked well but was very limited, and unfortunately after several house moves, the Palm Pilot and the cable seem to have vanished. So when I started playing around with the MSP430, I thought a proper timed shutter release would be a good project. After months of procrastination I finally set to work creating it just after Christmas. 
     
    Functions
    I wanted something that could do more than just fire off a shot every n seconds for x shots. So my aim was for the timer to have multiple modes. The things I wanted it to be able to do were:
    Timed bulb shots (I love night-time photography), capable of handling bracketed shots - so instead of just firing the camera once every n seconds, it should fire it 3 times, or 5 times etc capable of bracketing multiple bulb shots - so the timer has to control longer or shorter exposure times. allow for the camera's inbuilt noise reduction for long exposures - my cameras will do dark-frame subtraction after a long bulb exposure, whereby they take another photograph of the same length of time but with the shutter closed. This means taking multiple bulb shots would have to allow for this time delay I came up with a flow control that allows for all these different scenarios, but still with a fairly straight forward user interface.
     
    The Camera Interface
    I have a Samsung GX10 (Pentax KD10 copy), and a Canon EOS 450D. Both of these cameras use the same interface for the remote release. Physically, the camera has a 2.5mm stereo headphone socket. Electronically, the tip is the shutter, the ring is the focus, and the sleeve is ground. To activate shutter or focus, the tip or ring is connected to ground. An open collector transistor is suitable for this.  The trick is though, that the focus has to be grounded before the shutter. If you look at the above diagram, you'll see they both get their signal from the same pin, and are therefore both grounded at the same time. This mostly works, but if the camera goes into sleep mode, the focus activation will wake it, but it won't acknowledge the shutter press.  My final code allows you to set the delay between when the focus is activated and the shutter is activated, to give the camera time to wake up. This also allows you to use auto-focus if you really want to, by increasing the delay long enough to allow focus.
     
    The Hardware
    The brains behind the operation is an MSP430G2452, currently on the launchpad, but it will ultimately be on a standalone board.  To drive the camera interface, all the MSP430 does is drive a pair of open-collector NPN transistors - I use BC549's but pretty much any small-signal NPN transistor will do the trick.  To convey all the information to the user, a standard 16x2 text LCD module is used, in 4 bit mode. I use a transistor to switch the backlight, controlled from a pin on the 430, and also use a couple of transistors to switch power to the whole module. This allows me to turn the display completely off when not in use, or while doing a long shooting sequence to save power.  Finally, the user interface is controlled by a rotary-coder switch. This uses 3 pins on the 430 - two for the grey-coded rotation and one for the push-button. I initially was using hardware debouncing with capacitors & resistors, and the fact the 430 has Schmidt inputs, but was running into hassles getting reliable operation, so changed to software debouncing.  The 32khz crystal is used to manage the timing.  All up I'm using all but one GPIO pin.  Pin allocation is as follows:
    P1.0 - LCD RS
    P1.1 - LCD EN
    P1.2 - LCD Backlight control
    P1.3 - LCD Power control
    P1.4-P1.7 - LCD D4-D7
    P2.0 - Rotary Coder Pushbutton
    P2.1 & P2.2 - Rotary Coder rotation sensor
    P2.3 - Focus Control
    P2.4 - Shutter Control
    P2.5 - spare. 
    P2.6 & P2.7 - 32kHz crystal
     
    Note - on the attached circuit diagram, you'll see some scribble next to the TEST pin of the MSP430 - this was a mistake and I couldn't find any whiteout. The capacitor and resistor are obviously connected to the RESET pin, not TEST.

     
    Software
    I started out using Energia, but very soon into the design I started running into RAM problems on the 2452, so I put in the 2553. I didn't get much further when I started running into RAM problems with it too. Energia is great in that it is simple to use, and has ready-to-use libraries for a lot of things. But those libraries come with overhead - for example 32 bytes of RAM just to store the list of interrupt functions, even if I'm only using interrupts on 3 pins. So I started again - still in the Energia IDE (because CCS refuses to run on my main development machine), but I didn't use any of the Energia framework. Consequently my code will look familiar to CCS developers. The main file has the .ino extension like all Energia sketches, but if you rename it to .cpp it should compile with GCC no problems. I am using C++, although the only C++ extension I'm using is function type overides. No classes to help keep the code lean.  By restarting in this manner, I was able to go back to the 2452 with 6.6k of code, and no RAM problems.
     
    For readability the code is arranged into separate files for different functions.
    CameraTimerGCC.ino contains main() and has the general flow control.
     
    clocks.cpp sets up the clocks (1MHz main clock, 32.768 crystal for ACLK, WatchDog Timer running at 4Hz) as well as implementing a Wait() routine using TIMER-A & the crystal to pause for a few milliseconds in LPM3.
     
    encoder.cpp implements the rotary encoder. It contains the P2 interrupt which handles the grey-coded rotation sensor and the pushbutton. A variable holds the relative value of the rotation sensor and indicates if the button has been pressed.
     
    flashsave.cpp copies the current settings to flash or reads from flash. I use the 3 user segments of flash (Segments B, C & D) as 3 "slots" to save your settings into.
     
    lcd.cpp is a basic library to drive the LCD. Only the functions that I needed are implemented.
     
    sequence.cpp handles the logic of shooting the programmed sequence
     
    textconstants.cpp - pretty self explanatory holds most (I need to do some tidying up so it is all) of the text constants used for the display.
     
    ui.cpp - implements the main menu
     


     
    UPDATE - 26 January 2014 - Nearing Completion
    Well I finally managed to track down a cable with a 2.5mm plug - after checking all the local "electronics" shops again and drawing a blank, I just happened to be wandering through a department store and saw a lone 2.5mm cable in ratty packaging. Hooked it all up, and nothing. I switched to bulb mode, and still nothing. Then I touched one of the base resistors into one of the transistors, and the camera went nuts.  I soon discovered my error - I hadn't made the connection between the emitters of my driver transistors and ground. With no ground reference the MSP wasn't turning the transistors on, so nothing at the camera. Fixed that, ran a sequence, and the camera woke from sleep but still did nothing. A little tweaking and I discovered my program was sound, the problem was just that the time it was holding the shutter down was too short. Dialled up 100mSec instead of 25mSec and everything leapt into action and was working perfectly.
     
    Then came the trickiest part of the whole exercise - converting my breadboarded circuit into stripboard. After a few hours with a piece of paper printed with a 1/10" grid I finally worked out a layout that would work. It is probably a long way from optimal, and when I look at the board I see a huge amount of wasted space as well as more wire links than I would like, but it works, that's the main thing. I did end up changing a few pin allocations to things that would allow a more efficient board layout.
     
    So last night I sat down and soldered it up. Updated the code with the new pin allocations, flashed it to the 2452, plugged it into the board, connected power, and nothing. Actually not quite true, the backlight flickered a bit. So I poured over the board layout, and found one fault - I had pins P1.6 & P1.7 connected to the LCD's DB7 & DB6 respectively instead of 1.6->DB6, 1.7->DB7. That shouldn't cause the backlight to flicker but it would stop the LCD starting up, so I fixed that and still just had a flickering backlight. All the voltages were what they should be - my 5V line was held at 5.1V by the Zener, my 3.3V line was exactly 3.3V. All the pins on the MSP430 were held at 0, even the rotary coder inputs which should be pulled high. Thinking I may have blown the MSP430 I unplugged it and put it back on the launchpad. With the pin changes, the backlight was now controlled by P1.0, so in theory when I put it back on the launchpad the red led should light for a few seconds before turning off. Nothing. I was pretty sure I'd wrecked the MSP430, so just to test I loaded Energia's basic blinking light program. It was then that I noticed that down the bottom of Energia it said "LaunchPad w/ msp430g2553". Changed that to the msp430g2452, and the blinking light worked. Re-flashed my code and the red led lit up for 10 seconds before turning off. Plugged the 430 back into my board, and everything lit up perfectly just like it should.  Did a test run and it operated perfectly, except I noticed the backlight wasn't going out.
     
    So, now I was trying to find the reason why the backlight stayed on. My first suspicion was a bridged solder track or similar, but couldn't find any.  Next idea was that maybe the controlling transistor had gone short circuit - it had been a little stubborn when I was trying to solder it, the solder didn't want to take. Desoldered it, but I was still getting 0 ohms between the backlight Cathode and ground. Maybe the 10k resistor that I had across the transistor to provide the low backlight was the issue? Removed it, and I was still getting 0 ohms. I came to the conclusion that the problem had to be on the LCD module itself - I was using a brand new module, not the one I had breadboarded. I noticed that the pin for the backlight LED went extremely close to the ground-plane - could it be shorting there? I desoldered the lead (it is sort of wrapped around the end of the board), and the short circuit went away. Soldered the lead back in place and the short circuit was still gone - there must have been a bit of stray solder or something linking it to the ground plane. With that sorted, I put the transistor & resistor back in place, and the backlight control was now working perfectly.
     
    All that remains is to put it in a case, and to change the 2 x 2AA holders for a 4AA holder when it arrives.
     
    Here's a video showing a run-down of the completed unit. 


     
     
    Overall I'm very happy with the result. It is working, and does what I intended for it. Hopefully we'll have some clear nights soon so I can do some long exposure shots.
     
    Another Update
    Now attached is an updated version of the source code. New in this version is:
    Reflects the final pinout that I used when I went to the stripboard.
    Time display is improved. Instead of just displaying the time in seconds, the time is now displayed as a combination of days, hours, minutes & seconds, eg "1 hr 5 min"
    Improved logic within the menus - it skips over the "Burst Interval" option if the Burst Count is 1.
    When bulb mode is off, it states "Bulb Mode Off" Instead of just having a time of 0.
    Improved logic when dialing up large values - For times larger than 3 hours it now goes in 15 minute increments.
    Increased maximum focus time to 10 seconds.
     
    Here's a picture of the (near) finished product on stripboard and showing an example of the new time display.

    CameraTimerUpdated.zip
  8. Like
    cde got a reaction from dubnet in cheapest and/or simplest switching DC/DC regulator? (24v in, 3.6v out)   
    Most car usb adaptors have a MC34063 based switching regulation circuit. Reasonably small, Adjustable, will work with 24v with the default parts, just change the resistor divider for 3.6v use. Check a dollar store.
  9. Like
    cde got a reaction from bluehash in 120 LED Ring Clock   
    Push them together then create Solder bridges on the four different traces/pads on the edges.
  10. Like
    cde got a reaction from spirilis in cheapest and/or simplest switching DC/DC regulator? (24v in, 3.6v out)   
    Most car usb adaptors have a MC34063 based switching regulation circuit. Reasonably small, Adjustable, will work with 24v with the default parts, just change the resistor divider for 3.6v use. Check a dollar store.
  11. Like
    cde reacted to Rei Vilo in Volt/Amp/Watt meter   
    I packed an INA219 and a MSP430G2553 with a 128x64 OLED screen into a compact 6x3cm box to measure the volt-amp-watt of my fischertechnik models.
     
    One simple bulb lamp uses almost 1W! So large models can easily add up to various amps... putting the batteries under heavy stress.
     

     
    The screen comes from Digole and features an I



  12. Like
    cde reacted to Rei Vilo in embedXcode   
    Please find a new release of the User Manual, with reference for debugging and improved presentation.

    (link)
  13. Like
    cde got a reaction from tml in External power supply on MSP430F5529-LP boosterpack connector?   
    Sure, just pull the 5v and 3.3v jumpers on the ezfet connector first. If you don't want to power ANY of the fet or hub side, just pull all the jumpers. And yes, you can only provide 3.3v (or any DVCC voltage in the f5529's range), given that you know that the 5v side will not be used/needed.
     
    Power can be injected at any 3.3v or 5v point on the board, including the jumper block, the 40 pin headers, or the two power headers at the bottom.
  14. Like
    cde reacted to GeekDoc in Tip on unused pins   
    I was browsing some info in the User Guide and saw this (section 8.2.7, p8-6 (p362 in pdf)):
     
    Reducing power use might not mean that much, as the MSP430 is already extremely low power, but I feel that the floating input may cause some slow-down (as the chip deals with changing states). It might even cause instability in some applications.
     
    I haven't seen this practiced in the examples I've looked at (mine included), so I thought I'd share.
     
    -Doc
  15. Like
    cde got a reaction from bluehash in RDA5807P (TEA5767 clone) FM Radio inside a PC speaker   
    Anton Veretenenko created a simple FM Radio with a TEA5767 compatible chip. The RDA5807P is an I2C (Or spi) controlled FM Radio Tuner. He used a generic AC Powered PC Speaker, added a 3.3v regulator, a rotary encoder, and stuffed it in.
     
    The post and code don't mention it, but from the pictures, the stated 2kb limit, and the use of USI, it's using the G2231 on a v1.4 Launchpad.
     
    Blog Post: http://blog.avrnoob.com/2013/10/ti-launchpad-rda5807p-tea5767-fm-radio.html
    Code Repo: http://code.avrnoob.com/ti-launchpad-fm-radio
     
    Similar to @@juani_c project: http://forum.43oh.com/topic/2359-fm-radio/
  16. Like
    cde got a reaction from tai in I2C communication problem using TI library   
    Op's question was answered by a TI Forums Community Member a while back:
    I pretty much agree. Also, for single master systems, especially if you are only using one device (Your msp430 master, one i2c slave), you can pretty much ignore the need for a repeated start, and use the standard stop, then start again. 98% of slaves will accept that. Repeated starts are needed when the bus might be controlled by more than a single master.
     
    For @@tai the i2c master library they use is a (not well) modified version of the Texas Instruments slaa382 USCI I2C Master Library, found here: http://www.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=slaa382
  17. Like
    cde got a reaction from bluehash in Audi Car Stereo AUX Input Hack with Launchpad   
    VTL On the Hackaday Forums was able to use a 2kb Msp430 to trick a Audi Concert Stereo into thinking it has a CD-Changer connected, enabling Aux Inputs. The code is a Port of a Arduino Port of a AVR Port of the VWCDPIC project (PIC Based).
     
    Using a MSP430G2231, VTL was able to implement two different Uni-Direction Protocols, through Timer_A1 and the Watchdog Timer using extra software delays.
     
    The same protocol is used in B5, B6 and B7 Audi A4s i.e. Generation I, Generation II and Generation II+ Audi head units.
     
    Unfortunately, the code is no longer available, but the post is still a nice writeup on reverse engineering a stereo and porting of code found on the internet, with good pictures too.
     
    http://forums.hackaday.com/viewtopic.php?f=3&t=123
  18. Like
    cde got a reaction from daviddigo in Watch Dog timer   
    Three ways. Use an external Watchdog Timer ic. Create a passive or simple watchdog timer from a 555 ic (google "watchdog 555" or "555 watchdog"). Or if you have a msp430 ic to spare (you should, the launchpad comes with two), create a watchdog timer with it.
     
    In all three cases, you would need to drop a few digitalwrites (high and low) into your code, on a spare pin.
  19. Like
    cde got a reaction from bluehash in Embedded Systems Thanksgiving and Black Friday Deal List   
    Heads up, the Panavise 301 at Radioshack, while less electronics based, is still fairly good, and has been on 20 dollar (or less by now) clearance for a while now in store. Especially if you need a medium duty, heavy one.
  20. Like
    cde reacted to RobG in LaunchPad IR Receiver   
    Here's the alternate code. It uses method from post #3 and port interrupt instead of timer's capture/compare feature.
    Timer is used to measure pulse's width and for timeout when signal is lost half way through.
     
    Enjoy.
     
    #include "msp430g2553.h" #define T05 300 #define T25 T05*5 #define T35 T05*7 #define T50 T05*10 #define TMAX 65000 #define IR_DETECTOR_PIN BIT1 void reset(); unsigned int rxData = 0; // received data: A4-A0 and C6-C0 0000 AAAA ACCC CCCC unsigned int bitCounter = 0; void main(void) { WDTCTL = WDTPW + WDTHOLD; // stop WDT BCSCTL1 = CALBC1_1MHZ; // load calibrated data DCOCTL = CALDCO_1MHZ; P1OUT &= ~(BIT0 + BIT6); // P1.0 & P1.6 out (LP LEDs) P1DIR |= (BIT0 + BIT6); P1REN |= IR_DETECTOR_PIN; // P1.1 pull-up P1OUT |= IR_DETECTOR_PIN; // P1.1 pull-up P1IE |= IR_DETECTOR_PIN; // P1.1 interrupt enabled P1IES |= IR_DETECTOR_PIN; // P1.1 high/low edge P1IFG &= ~IR_DETECTOR_PIN; // P1.1 IFG cleared CCR0 = TMAX; // interrupt if no edge for T32 TACTL = TASSEL_2 + MC_1; // SMCLK, up mode __bis_SR_register(LPM0_bits + GIE); // switch to LPM0 with interrupts } // Port 1 interrupt service routine #pragma vector=PORT1_VECTOR __interrupt void Port_1(void) { if (P1IFG & IR_DETECTOR_PIN) { P1IE &= ~IR_DETECTOR_PIN; if (bitCounter == 0) { P1IES &= ~IR_DETECTOR_PIN; // P1.1 low/high edge bitCounter++; TACTL |= TACLR; TACTL |= MC_1; CCTL0 = CCIE; } else { switch (bitCounter) { case 14: // received all bits // process received data, for example toggle LEDs switch (rxData & 0x001F) { // mask device number case 19: // Volume - 0010011 = 19 P1OUT ^= BIT0; break; case 18: // Volume + 0010010 = 18 P1OUT ^= BIT6; break; case 21: // Power 0010101 = 21 P1OUT |= BIT6; P1OUT |= BIT0; break; case 20: // Mute 0010100 = 20 P1OUT &= ~BIT6; P1OUT &= ~BIT0; break; } reset(); break; case 1: // start bit? if (TA0R < T35) { // could also add || TA0R > T50 reset(); } else { TACTL |= TACLR; TACTL |= MC_1; bitCounter++; } break; default: // data bit rxData >>= 1; if (TA0R > T25) { rxData |= 0x0800; // set bit 12 of rxData } TACTL |= TACLR; TACTL |= MC_1; bitCounter++; // increase bit counter break; } } P1IFG &= ~IR_DETECTOR_PIN; P1IE |= IR_DETECTOR_PIN; } } void reset() { CCTL0 &= ~CCIE; P1IES |= IR_DETECTOR_PIN; // P1.1 high/low edge rxData = 0; bitCounter = 0; } #pragma vector=TIMER0_A0_VECTOR __interrupt void Timer_A(void) { // reset P1IE &= ~IR_DETECTOR_PIN; reset(); P1IFG &= ~IR_DETECTOR_PIN; P1IE |= IR_DETECTOR_PIN; }
  21. Like
    cde reacted to jsolarski in PWM with WDT+   
    not a bad idea, once i have the servo code working i will ship it over your way.
     
    and here is the single led code, better commented too
    //options for interval timer/* WDT is clocked by fSMCLK (assumed 1MHz)
    WDT_MDLY_32 (WDTPW+WDTTMSEL+WDTCNTCL) 32ms interval (default)
    WDT_MDLY_8 (WDTPW+WDTTMSEL+WDTCNTCL+WDTIS0) 8ms
  22. Like
    cde reacted to jsolarski in PWM with WDT+   
    Just a different way to create PWM on 3 pins, this code is for 3 leds or an RGB led
    changing the WDT interval will change how many cycles it will go through before calling an interrupt
    the PWM period can be changed by changing the value 200 on line 22 to what ever period you will need
    changing the led_ value is the duty cycle of the leds
    This code has not been streamlined, but it does do the job, updated code and limitation are going to be experimented with later this weekend, i am going to see how many servos LEDs i can hook up to it, max pins i can use is 9 pins, but that is using all pins possible........
    my test circuit

    FYI mspgcc code

    #include #include //add for interrupt #define UP 0x00 #define DOWN 0x01 volatile int millsecs = 0; volatile int counter2 = 0; volatile int led_red = 0; volatile int led_green = 199; volatile int led_blue = 199; volatile int dir = UP; void main(void) { WDTCTL = WDT_MDLY_0_064; P1DIR |= BIT5 + BIT4 + BIT3; P1OUT |= BIT5 + BIT4 + BIT3; IE1 |= WDTIE; eint(); }//end main interrupt(WDT_VECTOR) watchdog_timer(void) { ++millsecs; if (millsecs == 200) { millsecs= 0; P1OUT |= BIT0 + BIT6; ++counter2; } if (millsecs == led_red ) { P1OUT ^= BIT3; } if (millsecs == led_green) { P1OUT ^= BIT4; } if (millsecs == led_blue ) { P1OUT ^= BIT5; } if (counter2 == 25 ) { counter2 =0; switch (dir){ case UP: ++led_red; --led_green; --led_blue; if (led_red == 199) {dir = DOWN;} break; case DOWN: --led_red; ++led_green; ++led_blue; if (led_red == 0) {dir = UP;} break; }//end switch }//end if }//end interrupt
  23. Like
    cde got a reaction from JVimes in Development kit terminology (newbie question)   
    These are quite interconnected in the MSP Launchpad world. A Debugger allows you to debug your code, through changing memory values and breakpoints. A Programmer allows you to program the chip using usb on one side, and SpyBiWire/Jtag on the other (a protocol adaptor). A FET, Flash Emulation Tool, allows a microcontroller to run code on memory outside of it's own memory, through the debugger/programmer setup.
     

    A breakout board is often a blank pcb that an IC can be soldered to, changing it's package from one form to another, with all pins broken out. You find these for SMD chips alot. Sometimes it comes with the smd chip used, and sometimes has some needed parts, like a regulator or passive components. 
    Evaluation Kit is a board or module designed to show off the features of a chip. An experimenter board is really just marketing, or targeted to a education crowd [look at the neat things you can do] ( vs business crowd [look at the useful/purposeful things you can do]). A starter kit is a set of parts put together as a "these will get you started" method. A development board is a combination of an evaluation kit and experimenter board, targeted towards implementing final products.
     

    The reason for that is that the F5529 is a high pin count thin/small smd chip, not a giant through hole chip. Its not practical for most experimenter/evaluation boards to have removable smd chips, and boards that do have sockets for those high pin count smd parts are expensive, because the sockets are expensive. BUT that does not mean you can't use the F5529 board to program other f5529s. They have jumpers that can be removed, and using a cable, can be connected to your own pcbs or break out boards, for in circuit programming.
  24. Like
    cde got a reaction from Rickta59 in US Air Force Academy Embedded (Launchpad) Class ECE382 for free   
    From Hackaday:
     
     
     
    http://ece382.com/ and  http://github.com/toddbranch/ECE382
     
    A full embedded system course provided by the Tax Payers Yay. Based around the launchpad and an undocumented learning board (see lesson 3 for a partial picture of it).
    They even have a link to the 43oh forum post on msp430 in consumer devices.
     
     
  25. Like
    cde got a reaction from pine in US Air Force Academy Embedded (Launchpad) Class ECE382 for free   
    From Hackaday:
     
     
     
    http://ece382.com/ and  http://github.com/toddbranch/ECE382
     
    A full embedded system course provided by the Tax Payers Yay. Based around the launchpad and an undocumented learning board (see lesson 3 for a partial picture of it).
    They even have a link to the 43oh forum post on msp430 in consumer devices.
     
     
×
×
  • Create New...