Jump to content
43oh

cde

Members
  • Content Count

    940
  • Joined

  • Last visited

  • Days Won

    21

Reputation Activity

  1. Like
    cde reacted to Register in Detecting msp430g2553 package (28/20 pins)   
    Hmm maybe I could create a program which just write a value in flash memory segment, run it on 28 pins packages before loading my main program in which i could test this value to detect the package and change assignments accordingly.
  2. Like
    cde reacted to curtis63 in Detecting msp430g2553 package (28/20 pins)   
    The solution to detecting pin count can be found on Stack Exchange at the following location:
     
    http://electronics.stackexchange.com/questions/228082/how-do-you-programmatically-detect-pin-count-on-an-msp430g2553
  3. Like
    cde got a reaction from tripwire in Detecting msp430g2553 package (28/20 pins)   
    Use bootstrapping. By that, I mean a single high value resistor tied to a spare pin, high or low. Any project where the 28 pin device is used, the resistor should tie the line high, your code reads it on boot, then ignores it the rest of the time it is running code. The 20 pin would have a resistor tied to ground. Or you could skip the resistor and tie the pins directly to vcc/gnd as long as you are sure you never set that pin as an output. (The resistors provide some level of idiot-proofing).
     
    This works on spare gpio pins, and can even be used later as an output (with the resistor!), an led output (again with the resistor), or a button input (again, with the resistor). Of course, this is a hardware level runtime method of defining boot options, not a compile-time or programming level.
  4. Like
    cde got a reaction from tripwire in Stupidest Thing you had to Troubleshoot?   
    Yeah, VIH levels are tricky. The AVR Mega line is supposed to accept VCC * 0.6 as input high, but that's the minimum. So 3 at 5V. But if your at 5.1V and the input is at 2.9V...
  5. Like
    cde reacted to tripwire in Stupidest Thing you had to Troubleshoot?   
    I used sprintf on CC2650 and it smashed the stack
     
    When I was looking at my code in the debugger the SP was about 2/3 of the way down into the stack, and beyond that the memory all appeared unused. Eventually I spotted a few bytes had been written right at the limit of the stack. Apparently sprintf needs a 510 byte buffer to format the string version of numbers from %d etc. I only wanted to convert a 32 bit value to a hexadecimal string!
     
    I think I was spoiled by MSP430 which defaults to "minimal" (s)printf using a tiny internal formatting buffer. It only breaks the C standard, not the stack limit!
     

    Me too! Sometimes I use the MSP432 or FR5969 launchpads to energytrace another launchpad. When the time comes to reprogram the target I always forget to remove the external VCC/GND jumper wires and reconnect the target to its emulator.
  6. Like
    cde got a reaction from bluehash in The excitement of ordering parts on Ebay   
    Mifare classic hasn't been compatible with most galaxy phones from the S4 generation and up. Mifare classic is basically broken out the box by NXP, and since they don't license out, all the phones with broadcom NFC radios can't access them.
  7. Like
    cde got a reaction from spirilis in The excitement of ordering parts on Ebay   
    Mifare classic hasn't been compatible with most galaxy phones from the S4 generation and up. Mifare classic is basically broken out the box by NXP, and since they don't license out, all the phones with broadcom NFC radios can't access them.
  8. Like
    cde got a reaction from bluehash in Motion Sensing Pantry Light   
    A small project.
    G2211 PIR Sensor 5630 LED strips On/Off button Button Doubles as Test Mode Board half way done. Using a Reg104 DPAK (I'll stick to a TO-220 next time) as the regulator, and MMBT3904 sot-23 transistors on a board of my own design. The base resistors should be on the back, but I didn't have the right value 0805/1206 resistors at the time.

     
    Quite proud of my clean, flush mount, perfect fit for the button, led, and sensor.
     

     
    Two tricks. One, I used two pins to provide high to low, and low to high interrupts, instead of swapping the interrupt in code, since I won't always know it's state. It is much simpler like this for me. Two, the status led is only 0.66 mA. 600 microamps. Look how visible it is. Keep that in mind when building your own projects.
     
    One issue. I have the PIR sensor directly powered by the 3.2V regulator I am using, bypassing the HT7133 on it. As such the PIR sensor triggers when the leds turn off, likely due to noise/ripple experienced. Next time I'll just power the sensor from the 12V with it's regulator, or I could change the sensor to non-retriggerable mode, or wire the enable pin to the msp430. I just coded a delay that ignores the trigger. The timing of the lights is long enough that it shouldn't be an issue in normal use.
    main.c
    common.h
  9. Like
    cde reacted to Tieri in Stupidest Thing you had to Troubleshoot?   
    Setting different addreses to two of nRF24L01's. Took me two days to figure...
     
    L
  10. Like
    cde reacted to Rei Vilo in Stupidest Thing you had to Troubleshoot?   
    Inverse the +3.3V and Ground for an MSP430... Luckily, the MSP430 survived!
  11. Like
    cde reacted to L.R.A in Stupidest Thing you had to Troubleshoot?   
    Power 2 launchpads from 1 USB - used jumper wires to connect the USB powered launchpad to the 2nd one - I did GND-3.3V and 5V to 5V or something weird like that... The thing still worked somehow resenting from time to time. I took me while to notice how the launchpad heat up.

    Somehow that launchpad is still going after so many tests and I have just one of those 
  12. Like
    cde reacted to bluehash in Stupidest Thing you had to Troubleshoot?   
    Forgetting to setup or enable clocks for peripherals. Had to do this for the Stellaris/Tiva-C
  13. Like
    cde reacted to Fred in Stupidest Thing you had to Troubleshoot?   
    I've managed a few. Swapping VCC and VSS on my first etched PCB was a good one. I'm glad I'm not the only one who's done that.
     
    I also noticed that a TS430RGC64USB target board that I had supported the F5510 that I was coding for. Great! So I stuck it in and wondered why it didn't work. It turns out that a LQFP48 will fit in a QFN64 socket. It might not fit that well or work, but it goes in.
     
    Amazingly neither of these (and probably worse that I've forgotten) damaged the MSP430.
  14. Like
    cde reacted to spirilis in Stupidest Thing you had to Troubleshoot?   
    Those darned MSP430's are almost unreasonably difficult to kill! LOLMakes the FRAM "zombie MCU" idea ever more relevant...
  15. Like
    cde reacted to roadrunner84 in Stupidest Thing you had to Troubleshoot?   
    Pin direction is a pain in the *ss. I've learned so far that the I/O direction description is mostly more informative than the net name....
  16. Like
    cde reacted to hlipka in Stupidest Thing you had to Troubleshoot?   
    Switching MISO and MOSI for a SPI EEPROM, while building my PicKit3 clone. On the original schematic from the PK3 user guide they are called SDI and SDO, for both the MCU and the EEPROM. So I naturally connected SDI to the same net, and SDO to another one. But in reality SDI was the input on both sides, and SDO the output - so they should have breen swapped. It took me about 3 months to find this out
  17. Like
    cde reacted to Fred in Stupidest Thing you had to Troubleshoot?   
    When something doesn't work one of the first things I do is swap I/O pins. Even if I'm pretty sure it's right. In fact this exact thing happened last night between a LPCXpresso1769 and an SD card. (Sorry for the MSP430 infidelity - I'm working on some Smoothieboard improvements.)
  18. Like
    cde reacted to Druzyek in Stupidest Thing you had to Troubleshoot?   
    I've have several projects with a 5 pin header for the 6 pin FT232 cable since none of the projects use the 6th pin. One time I plugged the header into pins 2-6 of the FT232 cable instead of 1-5 and my launchpad died :S Also, took a while to get my first MCP23S17 I/O expander to work since the datasheet incorrectly lists the RESET pin as an output, not an input.
  19. Like
    cde got a reaction from Fmilburn in OV7670 and MSP430   
    If you are using i2c, and have properly coded the i2c open-collector (output ground and high-z input, never output high), you don't really need the 2231 as a level translator. But this really seems like a coding issue. we can't help without your code.
  20. Like
    cde got a reaction from dubnet in Motion Sensing Pantry Light   
    A small project.
    G2211 PIR Sensor 5630 LED strips On/Off button Button Doubles as Test Mode Board half way done. Using a Reg104 DPAK (I'll stick to a TO-220 next time) as the regulator, and MMBT3904 sot-23 transistors on a board of my own design. The base resistors should be on the back, but I didn't have the right value 0805/1206 resistors at the time.

     
    Quite proud of my clean, flush mount, perfect fit for the button, led, and sensor.
     

     
    Two tricks. One, I used two pins to provide high to low, and low to high interrupts, instead of swapping the interrupt in code, since I won't always know it's state. It is much simpler like this for me. Two, the status led is only 0.66 mA. 600 microamps. Look how visible it is. Keep that in mind when building your own projects.
     
    One issue. I have the PIR sensor directly powered by the 3.2V regulator I am using, bypassing the HT7133 on it. As such the PIR sensor triggers when the leds turn off, likely due to noise/ripple experienced. Next time I'll just power the sensor from the 12V with it's regulator, or I could change the sensor to non-retriggerable mode, or wire the enable pin to the msp430. I just coded a delay that ignores the trigger. The timing of the lights is long enough that it shouldn't be an issue in normal use.
    main.c
    common.h
  21. Like
    cde got a reaction from MSPLife in LPM and Timer interrup   
    A timer based delay will not work like you are expecting.
     
    First, every 49 times the code loops, you run Delay(). Which resets the timer (TA1CTL = TACLR). So the interrupt never happens.
     
    Second, You don't do anything in the interrupt. You don't clear the flag. You don't run any code.
     
    Third, your expecting it to block your main code. It won't. It runs in the background, allowing your code to continue. That's why you see most Timer based delays using LPM. LPM stops the main code until the timer interrupt happens, and then starts running the code again.
     
    If you want something to work like that, you need a blocking delay (Like running a large "for" loop), or LPM, or using the interrupt to run the code.
  22. Like
    cde reacted to pine in Stupidest Thing you had to Troubleshoot?   
    Keep getting error message in CCS saying unable to program the LP (not exactly but something very similar to that meaning). 100% sure the board is connected. Unplugged the USB and plugged in again, restarted CCS and restarted PC. Turns out I tried to program a non-existent 2553 as I moved it out from the LP to a breadboard 
  23. Like
    cde got a reaction from bluehash in Stupidest Thing you had to Troubleshoot?   
    Today, while trying to create a motion sensing Pantry light, using a HC-SR505 mini PIR sensor, was the overly sensitive sensor. I was trying to power it directly from the Launchpad's 3.5V line, but it kept retriggering and retriggering for no reason! It has a beefy 22
  24. Like
    cde reacted to veryalive in Using 5volt LCDs on 3.3volt MSP430s - with no extra power supply   
    Hi forum,     I have many 5 volt LCDs.   Here's an idea for using them on 3.3 volt MSP430 systems, other 3 volt systems and LaunchPads.   Let's think of the typical 16 char  x 2 row LCD, with a 16 pin connector (pin 1 = GND, pin 2 = Vcc, pin 3 = Vee, etc) and operate the MSP and LCD off only one 3volt source.    No extra power supplies.   I've been using this technique for a long while, its nothing new, you may have already seen it.      PROBLEM STATEMENT - how to use a 5volt LCD unit on a 3.3 volt system without creating a separate 5v supply.     SOLUTION  SUMMARY - use a simple circuit to create a negative voltage from the MSP 430 ACLK.  This negative voltage then drives the LCD Vee on pin 3.   The ACLK ***must*** be enabled in your software.   You can enable ACLK in either CCS or Energia.      Current measurements and waveforms are shown below.   Clearly, you have to sacrifice use of the PORT P1_0 (red LED) pin, but this can be a reasonable trade off.   If you can't do this, then you can use another MSP output to generate the negative voltage.       HARDWARE -   a-- create a simple negative voltage charge pump (two capacitors, 2 diodes). - input is from MSP ACLK pin +- 12 KHz. - output is to LCD Vee, which is almost always pin 3.   b-- here is a simple charge pump circuit:       (please do google this if you've a question, it is really simple)                | |                    || ACLK -->---| |---------O----------||<|------O--------->---- to Vee, pin3 on LCD.             | |         |          ||        |             C1         |        D2          |                        |                    |                       ===                 =====                 D1    \ /             C2  =====                     =======                 |                        |                    |                        |                    |                        |                    |                      GROUND               GROUND     Typical component values are not critical. I used:  C1 = C2 = 1 uF.   D1 = D2 = Germanium 1N569. Results are below.   c--  then connect the LCD module as follows: - pin1 to GROUND - pin2 to +3.3 volts (same line as the MSP430 positive supply) - pin3 to the charge pump inverter circuit, above in para 'b'. - all the other pins (RS   R/W    E   DATA0-7) to PORT pins suitable for your application.   d--  the scope output of the waveform in actual operation is shown in the scope screen shot below.     SOFTWARE -  you must enable the ACLK / VLO to be output from the MSP430:   P2SEL |= 0x07; // aclk P2_0 pin8.  smclk P2_1 pin9.   ta0 3 P2DIR |= 0x07; BCSCTL3 = LFXT1S_2; // aclk = vloclk abt 12khz   This can be done in CCS or in Energia 'SETUP'.     CURRENT CONSUMPTION -  .... With this configuration: - MSP430F2272 at 1MHz,  PORTs 1,3,4 all set to OUTPUT LOW.  PORT 2 set up as above.     4 x 20 LCD with blue backlight (powered by 3.3volts to a reasonable back light output)   ....  here is the typical current consumption I measured:   - MSP430F2272 running tight loop, 1MHz    1.1  mA - loop + charge pump                      1.55 mA   <<<< so, only 0.45 mA for the charge pump - loop + charge pump + LCD backlight      9.44 mA    (these are high efficiency blue LEDs)     PLUS POINTS -  - only one power supply needed for a simple 430 + LCD project. - rather low current consumption - even lower current consumption by switching ACLK off (but then you should turn off the LCD Vcc +3.3 - use another PORT pin as the LCD Vcc)   MINUS POINTS -  - you have to use a MSP430 port pin   ALTERNATIVES -  - use a timer / int driven PORT pin to replace the ACLK. - LCD too much contrast? :       - insert series resistor to LCD Vee from charge pump to reduce neg volts - LCD not enough contrast? :       - use a negative voltage triple / quadrupler.       Hope someone can use this idea.....   Cheers.      
     
     
     
     
     

  25. Like
    cde got a reaction from roadrunner84 in Running straight off Battery vs LDO   
    Found a nice app note by TI, and wrote some thoughts on it:
     
    Just recently read an app note that targets your same circumstances. Using power solutions to extend battery life in MSP430 applications By TI's Michael Day. While it uses the MSP430 as its target, the same applies to any MCU.
     
    Depending on the MCU's Current vs Voltage, and Voltage vs Clock Speed, using an LDO with a low Quiescent Current will be much better than powering the MCU directly off the battery. The example uses 2x AA, and a TPS780xx regulator with 0.5
×
×
  • Create New...