grahamf72
-
Content Count
189 -
Joined
-
Last visited
-
Days Won
15
-
When you tested it away from the board, was it still getting it's power from the same supply? I'm wondering if it is a decoupling issue (or something simpler like your power supply is having a voltage drop under the load of both the GPS and the MCU). Do you have the power to both the MCU and the GPS adequately decoupled with capacitors situated as close as possible to the power pins of the IC's? Generally I would use decoupling capacitors of 0.1uF and 10-47uF with the MSP430. The 0.1uF covers the system clock frequency range, while the larger capacitor covers the frequencies used by the l
-
Why not just do something simple like this Apologies for the rough drawing, it was with my finger on an iPad. When the MSP pin is high, the left transistor turns on, turning on the LEDs in its collector. This pulls the base of the left transistor down to below its turn-on voltage, so no current flows through its base, turning its LEDs off. When the MSP goes low, the left transistor goes off. Because it is no longer sinking the bottom of the 2k2 resistor to ground, current is able to flow through the 2k2 resistor and 47k resistor, through the base of the right transistor, turning it
-
I think I've solved it. Mine is working, even when I changed to P1_2. But then I noticed that it was blinking about once every second, not once every 3 seconds as it should. That indicated to me that the clock it was using for the timer was about 3x faster than VLOCLOCK should be. What is 3x faster than VLOCLOCK? The 32768 crystal, and it just so happens my launchpad has the crystal. Grabbed a launchpad without the crystal and I got the failure. Then I realised, nowhere in the above code is the clock source for ACLK configured, so it is probably defaulting to the crystal. I added BCSCTL3=
-
I've had a bit of a play, and the following code (a mash up of yours and roadrunner's) is working fine, going into LPM3 with about 50uA according to my meter. Note that I have edited the header for the DHT22 library to comment out the #define DEBUG, and that my data pin for the DHT22 is on P1.4. // Include application, user and local libraries #include "DHT22_430.h" /// /// @brief Pin for DHT22 signal /// @n Connect /// * pin 1 (on the left) of the sensor to +5V /// * pin 2 of the sensor to DHTPIN /// * pin 4 (on the right) of the sensor to GROUND /// @n Place a 10k resistor be
-
It looks like you are using rei_veilo's DHT22 library. Did you edit the header file and disable the DEBUG ? The reason I ask, by default his library uses the serial port to output debugging information. Because the 2452 lacks hardware serial, it uses timer_serial, and the 2452 only has 1 timer. If you are trying to use the timer to manage your wake times, it will clash with the timer that timer_serial uses, and hence you'll see funny behaviour like what you are seeing. I haven't actually used your code to see if this is the problem, but it is what jumps out at me from reading the thre
-
The only thing that jumps out at me is that your LED is connected to the serial RX pin. I know you aren't using serial RX but I wonder if using it in this fashion is interfering with the serial routines. Other than that, the RTCplus library is more RAM hungry than it should be. When I did it, I was aiming for small code size rather than small RAM usage. The above shouldn't run out of RAM, but if it is only a snippet from a larger piece of code, then it is possible you are encountering RAM problems. As for the suggestion above about crystal capacitors, the MSP430 has built-in crystal c
-
Only Port 1 & Port 2 are interrupt capable. All pins on these ports are interrupt capable, i.e. P1_0->P1_7, P2_0->P2_7
-
Excessive current useage when analogReference is not DEFAULT
grahamf72 replied to mgonsalv's topic in Energia - MSP
In your main loop, put your call to BIS_SR... inside your while(1) loop, and take the call to BIS_SR out of your interrupt. I think it is ending up in your while loop, and not going back to LPM. Also, it probably wouldn't hurt to explicitly clear REFON bit. I know the family guide says the reference is automatically turned off, but it can't hurt. Sent from my iPad using Tapatalk- 8 replies
-
- 1
-
-
- analogReference
- INTERNAL2V5
- (and 2 more)
-
I've been using the libfixmath library (I posted an energia port in the Libraries sub forum), which compiles considerably smaller than the gcc floating point library, and yields accurate results. The 2553 has plenty of grunt to calculate altitudes from pressure and log and/or display them. But... If all you are doing is logging altitude during the flight for later viewing, I'd just be logging the raw pressure readings. Then you can do all the funky maths on the computer that you use to view the results.
-
My preferred method is to create macros to make things more readable. Plus if you change which pin something is connected to, you just need to modify the macros. So for example I might have something like the following: #define RED BIT0 #define RED_ON {P1OUT |= RED;} #define RED_OFF {P1OUT &= ~RED;} #define SWITCH BIT4 #define IS_SWITCH_PRESSED (!(P1IN & SWITCH)) //Switch is active low, so we invert the state. void setup() { pinMode(P1_0, OUTPUT); pinMode(P1_3, INPUT_PULLUP); } void loop() { if (IS_SWITCH_PRESSED) RED_ON; else RED_OFF; } Obviously this little example d
-
I've improved the code a little, so here is my updated version. Fixes include: 1. Using a bit array instead of a byte array, dramatically reduces the amount of RAM used, so that smaller MSP430's can be used. I have been using an F2012, only because it was the cheapest DIP MSP430 my supplier had on hand. It should compile and work with pretty much any of the low end processors. I've tested with the F2012 & G2452, but it also compiles with the G2231, so I'd expect it should operate fine. 2. Previously while the motor was turned on, it used a simple __delay_cycles loop for the timeout. This
-
I'd typically use the first method when measuring something that changes slowly compared to the sample rate. The second method would be when the thing being measured is likely to rapidly change and the most recent result is the most important. For example if I was sampling barometric pressure, I'd use the first method for a weather station, but the second method for an altimeter. Sent from my iPad using Tapatalk
-
analogWrite bug with msp430g2553 in energia
grahamf72 replied to altineller's topic in Energia - MSP
On the MSP430G2553 P2_1 and P2_2 are analog write capable. But they are both connected to TimerA1 CCR1, so if you use analogWrite on both, they will both deliver the same output. You need to change one of your pins to one that is on a different Timer or a Different CCR register. Options include: P1.2, P1.6 or P2.6 - all on Timer0, CCR1 P2.4 or P2.5 - on Timer1, CCR2 This is a common mistake with analogWrite on the MSP430G2 launchpad - although the device has 7 pins capable of PWM output, the way the timers are connected there are only 3 PWM channels. -
I'll also add, that for a common anode LED display using an NPN transistor such as the BC547 is probably not the best option, as the maximum voltage at the emitter is the base voltage less 0.65V. A high from the MSP430 is typically .3V below Vcc, so with the 3.6v supply of the launchpad, you'll only get 2.65V at the anode. The pins driving the cathode will typically go to Vss+0.3V, so you are only left with 2.35v across the LED, which will probably be enough for most red LEDs, but is barely enough for yellow or green, and definitely not enough for blue or white. A better solution is to use
-
Personally I'd be interested in something that broke out a higher end chip (eg f5xxx, cc430f5xxx, g2955) to a 40 pin dip footprint, probably with no other support circuitry, or maybe just pads for a crystal, but wouldn't be interested in breakouts for chips already available in dip, as I don't really see a point. Sent from my iPhone using Tapatalk