Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by grahamf72

  1. 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 low speed oscillator (VLO clock or the crystal), UART etc. Using a GPS, I'd probably also put in a 0.001uF to cover the gigahertz range of frequencies that GPS uses. These are typical values - the actual theory behind optimal decoupling capacitor values is quite complex, but the figures above will do the job fine on most designs.
  2. 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 and it's LEDs on. Because the 2k2 & 47k resistors form a voltage divider, the voltage drop across the 2k2 is less than the forward voltage of the left LEDs, so no current flows through them, and they remain off. Sent from my iPad using Tapatalk
  3. 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=LFXT1S_2; to the setup() just before the lines to configure TimerA, and now it is running with approx 3 seconds between blips as expected on a board without the crystal. Sent from my iPad using Tapatalk
  4. 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 between pin 2 (data) to pin 1 (power) of the sensor /// #define DHTPIN P1_4 DHT22 mySensor(DHTPIN); int wakeupCounter; int frequency; #define LED P1_0 void setup() { TACCTL0 = CCIE; TACCR0 = 12000; //1 second TACTL = MC_1 | TASSEL_1; for (int i=0;i<16;i++) //put all pins in INPUT, helps cut power consumption pinMode(i,INPUT); mySensor.begin(); pinMode(LED,OUTPUT); digitalWrite(LED,0); } void loop() { _BIS_SR(LPM3_bits); int flag = mySensor.get(); int h = mySensor.humidityX10(); //t = mySensor.temperatureX10(); if (flag) { if(h>=485) { digitalWrite(LED,HIGH); //on delay(5); //this maybe could be optimized without using delay() but since this is only a few ms, I think it's ok for now digitalWrite(LED,LOW); //off frequency=3; } else frequency=10; } } #pragma vector=TIMER0_A0_VECTOR __interrupt void Timer0_A0 (void) { if(wakeupCounter % frequency == 0) { //check every 10 seconds and sleep deep meanwhile __bic_status_register_on_exit(LPM3_bits); wakeupCounter=0; } wakeupCounter++; }
  5. 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 thread. -------------- Edit -------------- Had another look, and I'm almost certain that the serial debug code in the library is the source of your frustrations. You are using P1_2 for your sensor, which is the TX pin for the 2452's timerserial library. I'd say that what's happening is the serial code in the debug is sending data on P1_2, which is messing up the DHT22. The reason you need the 1 second delay in LPM3, is to give the timerserial library time to clear the serial queue.
  6. 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 caps, which the RTCplus library enables when it enables the 32k crystal. However, the library does activate the 12.5pF capacitors, which are the ones used by the crystal that ships with the Launchpad. Check the specs for your crystal and if it requires different values, you can change it in RTCplus.cpp - change the XCAP value in line 45 - XCAP_1 for 6pF, XCAP_2 for 10pF.
  7. 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
  8. 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
  9. 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.
  10. 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 doesn't warrant the use of direct hardware manipulation, but gives a basic example of how I use the macros. When doing it this way, you do have to be careful to not incorrectly mix pin naming styles. The Energia pin names P1_0, P1_3 etc are NOT synonyms for BIT0, BIT3 etc, so a command like "pinMode(SWITCH, INPUT)" won't give the expected results. Likewise "(P1IN & P1_3)" won't give expected results.
  11. 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 is quite heavy on power. I have changed it so it utilises TimerA so that it can go down to LPM3 while it is providing the motor pulse. 3. The original code had a bug in that when the coil was off, both PNP transistors were turned on. PNP transistors turn on when their base is brought low, and since in the idle state the original code set those pins to 0, both transistors were turned fully on. This didn't result in current flowing through the motor, but base current was constantly flowing through the transistors - approx 3mA each. This sapped battery life. With the original code, I was getting about 1 month on a pair of AA alkaline batteries. With my changes I've had a clock running for about 6 months now. /****************************************************************************** * * Project : Vetinari Clock * Target CPU : MSP430G2553 * Compiler : CCS 5.2.1 * Copyright : None * Version : $Revision: 1A * \file main.c * \brief The Vetinari clock is from a book series known as Discworld, where * Lord Verinari has a clock in his waiting room which has an irregular tick. The * idea of the clock is to add a sense of unease and anxiety to anyone in the waiting * room since their brain doesn't filter out the ticks like a normal clock. * * To accomplish this task on a 430, we create an array of possible time frames to * tick the clock, and parse through it at 4Hz. The array is 32 entries long, so it * equates to 32 seconds in the real world. By randomly setting 32 of the elements high, * we create a timing sequence. A high element will generate a tick of the clock. This * means a second on the clock can be as little as 250ms, or as long as 24 seconds, and * still keep accurate time. ***************************************************************************** * * Code modified by Graham Fountain to: * Use a bit array instead of byte array. This is much more RAM efficient and * allows a smaller 128B device to be used instead of needing a 256B device. * Tested with an MSP430F2012 (which at the time was the least expensive MSP430 * in DIP casing my supplier had in stock). * * The delay code that conrols how long the pulse is delivered to the motor * has been changed from a simple __delay_cycles to use TimerA. This allows us * to drop into LPM3 mode while the motor is pulsing, saving considerable power. * In my tests, a pair of AA batteries lasted about 1 month with the __delay_cycles * code, while they lasted more than 6 months with the TimerA code. * *********************************************************************** * * H Bridge Configuration. * The below code is configured for the below configuration of the * H Bridge. If you use different pins to control transistors then * use different values for COIL_OFF, COIL_ONE & COIL_TWO * * V+ ----------------+-----------+ * | | * E E The top two transistors are PNP, eg BC557 * P1.3<---RESISTOR---B B---RESISTOR--->P1.2 * C C * | | * +---MOTOR---+ * | | * C C * P1.1<---RESISTOR---B B---RESISTOR--->P1.0 * E E The bottom two transistors are NPN, eg BC547 * | | * GND ---------------+-----------+ * * * *****************************************************************************/ #include "msp430.h" #include <stdint.h> #include <stdio.h> #include <string.h> /* Defines - Too lazy to put these in a header, maybe later */ /* How many clock cycles cycles to keep the io high * This will chgange depending on the model of clock movement used */ #define ENERGISE_TIME 820 //time in 1/32768 clock cycles. 820 = 25mS /* IO Mapping */ #define COIL_OUT P1OUT #define COIL_DIR P1DIR /* H-Bridge control pins */ /* * NB: PNP Transistors are ON when low, OFF when high * NPN Transistors are OFF when low, ON when high */ #define COIL_OFF (BIT2 | BIT3) //Both PNP's high (off), Both NPN's low (off) #define COIL_ONE (BIT2 | BIT0) //B0101 PNP on P1.3 on, PNP on P1.2 off, NPN on P1.1 off, NPN on P1.0 on #define COIL_TWO (BIT3 | BIT1) //B1010 PNP on P1.3 off, PNP on P1.2 on, NPN on P1.1 on, NPN on P1.0 off /* Lazy man globals*/ static uint16_t timingSequence[8]; //8 x 16 bits = 128 bits inline uint16_t GetBit(uint16_t x) //get the current value of bit x { return (timingSequence[x>>4] >> (x & 0xF)) & 0x1; //x>>4 is our index to the array (top 3 bits). x & 0xF is the bit we want. } inline void ClearAllBits() //0 the array. This loop takes less code than memset { for(int i=0;i<8;i++) timingSequence[i]=0; } inline void SetBit(uint16_t x) //set bit x of the array { timingSequence[x>>4] |= (1<< (x & 0xF)); } inline void delay() //delay for the period specified by ENERGISE_TIME. { TA0CCR0= ENERGISE_TIME; //set what we will count to. TA0CCTL0 = CCIE; //enable CCR0 interrupt TA0CTL = TASSEL_1 | MC_1 | TACLR; //ACLK (the crystal), count up, reset any value currently in the timer LPM3; //wait until the interrupt happens. TA0CCTL0 = 0; //reset the timer TA0CTL =0; } /* * send a pulse to the clock coil */ void pulseClock(void) { /* the polarity on the coil must swap each time it ticks, so we need to keep track of it */ static uint8_t polarity; if (polarity == 0) { COIL_OUT = COIL_ONE; delay(); COIL_OUT = COIL_OFF; polarity = 1; } else { COIL_OUT = COIL_TWO; delay(); COIL_OUT = COIL_OFF; polarity = 0; } } /* * Using a LFSR, generate a "random" 16-bit number. This was snagged from wikipedia */ uint16_t get_rand(uint16_t in) { uint16_t lfsr = in; static unsigned bit; static unsigned period = 0; /* taps: 16 14 13 11; feedback polynomial: x^16 + x^14 + x^13 + x^11 + 1 */ bit = ((lfsr >> 0) ^ (lfsr >> 2) ^ (lfsr >> 3) ^ (lfsr >> 5) ) & 1; lfsr = (lfsr >> 1) | (bit << 15); ++period; return(lfsr); } /* * Reset the clock sequence, runs every 32 seconds */ void ResetSequence(void) { uint8_t i=32; uint8_t location; static uint16_t feedback = 0xACE1; /* Zero out all elements */ //memset(&timingSequence, 0x0, sizeof(timingSequence)); ClearAllBits(); /* The array needs to have 32 random elements set high. * To do this we generate 32 different random numbers to use as indexes for the bits that will be set high. * If the index is already set, we just discard that number and try for a new one. */ do{ /* get a new random number */ feedback = get_rand(feedback); /* We only want the lower 7 bits since it's a 128 element array * The 16-bit number is still used so that we get a longer * chain in the LFSR before it repeats */ location = 0x7F & feedback; /* If the random location has already been set high, we ignore the random number */ if(GetBit(location) == 0) { /* Other wise we set the element */ SetBit(location); /* and decrement the counter */ i--; } /* This needs to be done 32 times */ }while(i); } /* * I setup the MSP, and run the main program loop */ int main(void) { /* counter to determine when 32 seconds have past */ uint8_t counter = 0; if (CALBC1_1MHZ ==0xFF || CALDCO_1MHZ == 0xFF) { // If calibration constants erased, do not load, trap CPU!! while(1); //G_uc_SystemFailureCode = McuCalValueFail; } // Set DCOCLK to 1MHz DCOCTL = 0x00; BCSCTL1 = CALBC1_1MHZ; DCOCTL = CALDCO_1MHZ; /* setup watchdog for a .25s interval * WDT ISR set at watchdog_timer(void)*/ WDTCTL = WDT_ADLY_250; IE1 |= WDTIE; /* Enable Osc Fault */ IE1 |= OFIE; /* Setup IO */ COIL_DIR = COIL_ONE | COIL_TWO; COIL_OUT = COIL_OFF; /* Initialize the pulse sequence */ ResetSequence(); /* Enter LPM3 w/interrupt */ _BIS_SR(LPM3_bits + GIE); while(1) { /* If this element of the sequence is high, we need to tick the clock */ if (GetBit(counter)) { pulseClock(); } /* Increment the counter to get us closer to 32 sec */ counter++; /* The WDT runs at 4Hz, so 32sec at equates to 128 ISR firings * At the 32 sec mark, we want to reset the counter and generate a new pulse sequence */ if (counter == 128) { counter = 0; ResetSequence(); } /* Enter LPM3 w/interrupt */ _BIS_SR(LPM3_bits + GIE); /* Once the WDT interrupt fires, it will return here looping back to the start of the while loop */ } } #pragma vector=TIMER0_A0_VECTOR __interrupt void timera0 (void) { _BIC_SR_IRQ(LPM3_bits); //we don't need to do anything but make sure we are woken up. } /* * The watchdog timer is actually useful */ #pragma vector=WDT_VECTOR __interrupt void watchdog_timer (void) { /* Clear LPM3 bits from 0(SR) * This will send us back to the main while loop */ _BIC_SR_IRQ(LPM3_bits); } /* * Just in case */ #pragma vector=NMI_VECTOR __interrupt void nmi_ (void) { uint16_t i; do { IFG1 &= ~OFIFG; // Clear OSCFault flag for (i = 0xFFF; i > 0; i--); // Time for flag to set } while (IFG1 & OFIFG); // OSCFault flag still set? IE1 |= OFIE; // Enable Osc Fault }
  12. 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
  13. 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.
  14. 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 a PNP transistor such as the BC557. The emitter is connected to your positive supply, the base (through a resistor) to the MSP430 pin, and the collector to the LED anode. Doing it this way becomes negative logic - i.e., the transistor & LED are turned on when the output pin is set to low. As for code, the basic code would look something like the following... const uint8_t anode_pins[4]={P2_0, P2_1, P2_2, P2_3}; //the pins that our anodes are connected to. //note that the rest of this code assumes that you are //using a PNP transistor to drive the anodes as //recommended above. uint8_t display_segments[4]; //this array holds the values for each of the digit's segments. //display_segments[0] is the first digit, [1] is the 2nd etc. //each bit is active low, so a value of B11111111 would have all //segments off, while B000000000 would have all segments on. //the actual mapping of the bits depends on the mapping of your pins //to the segment displays, but if you have P1_0 -> a (top segment), //P1_1 -> b (right-top segment), P1_2 - > c (right-bottom segment) etc, //then a value of B11111000 would be a 7 (a, b & c lit) // // // put your setup code - you will want to set your pins to outputs, and initially set all // the pins to high // //code snippet to update display. Each time you call this function, it will light up the //next digit of the LCD display. This routine should be called frequently - preferably at //least 100 times per second, so that the display won't have noticeable flicker. //You could call this in your loop() routine if it doesn't do things like have big delays, //or for more advanced usage, set up a timer with an interrupt routine. // void DisplayNextDigit() { static uint8_t current_digit = 0; digitalWrite(anode_pin[current_digit],1); //turn off the last digit that was displayed current_digit++; //step up to the next digit if (current_digit==4) current_digit=0; //if we were on the last digit, go back to the 1st P1OUT=display_segments[current_digit]; //load the cathode values for the segments. //we use direct register access rather than //digitalWrite so we can set all segments //simultaneously for better speed & less code. digitalWrite(anode_pin[i],0); //turn the digit on }
  15. 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
  16. Are you using the 2231? I suspect the code is too big for the little processor.
  17. I finally managed to track down the register documentation for the Stellaris processor (for some reason i couldn't find it on Ti's site), and it all makes sense now. The SPI clock frequency is set by 2 registers - CPSDVSR (Clock Prescaler) & SCR (Serial Clock Rate) by the formula SSI Clock = System Clock / (CPSDVSR * (1 + SCR)) Energia's setClockDivider just sets the Clock Prescaler register. According to the spec's of this register it must be an even number between 2 & 254. The LSB is ignored. Consequently by calling the routine with a divisor of 1, it was actually storing 0 and hence seems to go to some error state - the doc's don't say what happens when this is set to 0. Another limitation is that it won't allow any frequency above 25Mhz for the SPI. Unfortunately it is not possible to achieve the 25MHz maximum SPI speed with a system clock of 80MHz. The following are some of the valid combinations of registers and resulting frequency CPSDVSR SCR FREQ CPSDVSR SCR FREQ 2 1 20MHz 4 0 20MHz 2 2 13MHz 4 1 10MHz 2 3 10MHz 4 3 5MHz 2 4 8MHz 4 4 4MHz 2 7 5MHz 4 9 2MHz 2 9 4MHz 4 19 1MHz 2 15 2.5MHz 2 19 2MHz The function ROM_SSIConfigSetExpClock sets the registers in such a way that you get the frequency closest to the frequency set in that function. Because setting it 16MHz (as suggested in your comment on the github page) is actually impossible, it actually sets the speed to 20MHz. I'd suggest an improvement would be in the config to set the CPSDVSR to 2, and the SCR to 9 to get the default 4Mhz clock. Then in setClockDivider change the SCR rather than the CPSDVSR.
  18. I'm just getting started with my Stellaris LP, and am porting my msp430 library for my ILI9341 based display over to the Stellaris. I got it working, but am encountering performance issues. I'm using Energia 12. The ILI9341 is very demanding on the SPI bus. To test the performance I created a simple benchmark that involved filling the display a couple of times. On the MSP430, I was able to get good performance by putting SPI.setClockDivider(1) after SPI.begin(). With this setting, the MSP430F5529 at 25MHz was able to complete my benchmark in 1608mS. Then I ported it to the Stellaris, and instead of getting the faster performance I was expecting, the same benchmark took 73682 mS or about 45 times slower! I discovered in the SPI library, that instead of getting the default speed of 4MHz by starting with 16MHz and then dividing by 4, the SPI library sets the SPI speed to 8MHz. So setting the divisor to 1, should make it still at 8MHz, which I'd expect to be slower than the MSP430, but not by as much as I'm seeing. So then I took out the call to setClockDivider and it sped up substantially. It now ran my benchmark in 1926mS, still slower than the MSP430, but now with acceptable performance. I then tried it with setClockDivider(2) and this was the big surprise, it was now actually faster than without a divider set! But it was still slower than the MSP430. I tried changing the line ROM_SSIConfigSetExpClk in the SPI library to use a 16MHz clock instead of 8MHz, and this improved the performance to the point where it was now slightly faster than the MSP430, and once again the big surprise was that setting a divider of 2 was quicker than having no divider. Once again though, setting a divider of 1 slows everything down to a crawl. So it seems to me there is a bug in the SPI library for the Stellaris. Setting a divider of 1 should have it run at the full SPI clock speed, not much slower. Also, it seems strange that a divider of 2 should be faster than not setting a divider. I must admit I'm still in the early stages of learning the Stellaris, so I don't quite completely know what is happening in the library. Is there a way of configuring the SPI so that it runs at 16MHz or higher? Because it seems that 16MHz with a divisor of 2 means it is only running at 8MHz currently. For those interested, here is a table with the various benchmark times for various configurations. As would be expected, the MSP430 speed scales nicely with the processor speed. Stellaris 8 & Stellaris 16 refer to the SPI frequency set in the SPI.cpp file. 8 is Energia's default as-shipped value. Divider F5529 @ 25 F5529 @ 16 Stellaris8 Stellaris16 None 2487 3183 1926 1551 1 1608 2573 73682 30449 2 1737 2780 1883 1532 4 1989 3183 2408 1883
  19. 74ls logic recognises a voltage above 2v as a high input, so levels won't be a problem. Drive currents are also in the order of tens of micro amps so that won't be an issue either. I'd suggest double checking all connections, that the 74ls has a 5v power supply and that grounds are common. Sent from my iPad using Tapatalk
  20. You can use the WDT as a periodic timer like you suggest, but you can't set it to exactly 1mS as you suggest. You can use any of the clock sources, but can only trigger on /64, /512, /8192 or /32768. Consequently if you source it from the 1mHz clock, you can have it trigger at 1uS x 512 = 0.512mS or approximately 1/2 mS. Alternatively with the 32.768kHz crystal and /64 you can have it trigger 1/512 second or 1.95313mS. Check the documentation on the WDT for the processor family you are using, eg the MSP430g2xx family guide downloaded from TI. (Usually linked from the specific processor's page). Sent from my iPad using Tapatalk
  21. I haven't looked at the code for driverlib, but I'm not surprised you got the result you did with Energia's digitalWrite. 216kHz means 116 clock cycles per loop. Considering you have the overhead for 2 function calls, putting parameters on the stack, then determining the port & bit mask at runtime, then ensuring the port is configured right, then finally setting the output & returning from the function I'm not surprised it uses that many clock cycles. The maximum speed you can achieve would be with direct register access. Ie: P2OUT |= BIT5; P2OUT&=~BIT5; As for mixing code styles, it is not a problem as long as you exercise care to make sure things aren't reconfigured in incompatible ways, eg by manually changing a direction register after configuring a port. Sent from my iPhone using Tapatalk
  22. @@pdrift the reason you are seeing the behaviour you are getting is because the timers still run in lpm1, consequently when Energia's background timer triggers it wakes the processor up. The timer that Energia uses is disabled in LPM3 & LPM4. If you use either of those, the processor will go to sleep with nothing to wake it, so will blink once before going to sleep as you intended. Sent from my iPhone using Tapatalk
  23. If you remove the jumpers, then put a current meter across where the Vcc jumper goes you can measure the consumption of just the mcu and any connected loads such as LEDs etc. Sent from my iPad using Tapatalk
  24. Libfixmath has a 16 bit whole number and 16 bit fraction portion. Therefore the number range is +/-32767 with 1/65536 resolution. In decimal that is approx 0.000015. Because it has a total of 32 bits, as long as you take care not to have overflow or underflow conditions, it is more than adequate for pretty much any calculations originating from a 12 bit source. Sent from my iPhone using Tapatalk
  25. Over in the Energia Libraries folder I have posted a port of libfixmath to msp430. I had to make a few changes to get it to compile, but not many. It is tested with Energia but I can't see any reason why it shouldn't compile with CCS. Libfixmath is much smaller & faster than floating point, but still gives good accuracy. You just have to be careful to avoid overflows. Sent from my iPhone using Tapatalk
  • Create New...