Jump to content
43oh

sven222

Members
  • Content Count

    41
  • Joined

  • Last visited

Reputation Activity

  1. Like
    sven222 reacted to USWaterRockets in MSP430G2252 with launchpad   
    Try installing Code Composer Studio and build a simple test program or use one of the Launchpad Demos. Debug it in CCS, and it will load through the FET on the Launchpad. Even if you build for the wrong target, it will tell you and ask if you want to go ahead and ignore that error.
     
    If that works, then the hardware is fine, and you just need to debug the software command in your project that is not working. Maybe the force option is broken?
  2. Like
    sven222 reacted to greeeg in MSP430G2252 with launchpad   
    @sven222 It looks like you're trying to load a file into the flash area of a larger chip.
     
    The G2252 only has 2kB of FLASH, where as the G2452 has 8kB The device datasheet shows a table with this information.

     
    Even if your compiled program is less than 2kB, when it is compiled for the G2452 it will sit at the lowest flash address. I think the only way to solve this problem is to re-compile your code with the target set as msp430g2252, not msp430g2452. This should instruct the linker to place the code at an address where memory exists.
  3. Like
    sven222 reacted to spirilis in Ultra Low Power   
    for the G2553, even the 20-pin versions, don't forget about P3... set P3SEL and P3SEL2 to 0 and P3DIR to 0xFF, P3OUT to 0.  It's not connected to any of the external pins but the port is there--and might cause some power consumption if left floating as inputs.
     
    The 28-pin TSSOP package of the G2553 has the P3 pins exposed (and probably the QFN variant).
  4. Like
    sven222 reacted to veryalive in Ultra Low Power   
    @@sven222
     
     
    Hi again,
     
    In fact, I did notice that the ports were initialized in your code.    In the spirit of helping you avoid some strange stuff I found out myself, here is a better explanation...
     
    The main point is that, AFTER RESET -  P2SEL initial value is indeed 0xC0.      See the 0x00 Family guide slau144, page 333, chapter 8.3, table 8.2.      These must be changed to '00' for normal port IO.    The default is so that the 2553 comes up working OK if a 32KHz xtal is installed.
     
     
    This means that even if you write to P2DIR and P2OUT, they will not do anything to P2.6 and P2.7 output port  IO  bits.  
    This will do something else !
     
     
     
    From the 2553 data sheet, Port schematics, pages 53 +  .....
     
    For P2DIR BIT6 set  -  P2.6 will become Timer0_A3 TA1.              (assuming that P2SEL 6 is still at '1' )
    And P2.7 will be XOUT.
     
     
     
     
     
    Just so you are aware.....      
    tcheuss,
  5. Like
    sven222 reacted to Rei Vilo in Ultra Low Power   
    Please find an article about Ultra-Low Power with MSP430.
     
    This article discusses how to implement low power modes with Energia and how to measure with EnergyTrace.
  6. Like
    sven222 reacted to greeeg in Poor Man's PWM   
    @sven222 Any slight timing variations in the duty cycle will cause the brightness to be brighter or darker. If the rest of your program has even just a few conditional branches (if/else) then there will likely be some timing variations for the execution time of the main loop.
     
    The code you have here will maintain a constant +width on your LED. (assuming you don't use interrupts...) if this code is interrupted, then you could also get +width variations between cycles.
     
    If you can afford the hardware resources, utilizing a timer so you have a constant periodic event is the best way to go. Assuming the rest of your code will handle the overhead. The WDT is a good one for this, the period should be set at around 60Hz for the whole cycle... so 600Hz if you wish to have 10 brightness levels.
  7. Like
    sven222 got a reaction from spirilis in Watch Dog Timer Interrupt not working   
    Thank you very much! The part with:
    IFG1 &= ~WDTIFG;
    IE1 |= WDTIE;
    I already found out, but I was still missing
    _EINT();
    Now everything runs again. I also figured out why it was working the last time. Because before I did everything with CCS and the TI compiler. It seems to be more tolerant. Thanks for your help!
     
    Greetings
     
    Sven
  8. Like
    sven222 reacted to greeeg in Very accurate timer   
    @@sven222 121.1 bpm is not particularly fast for the 32KHz crystal.
     
    Every second a timer clocked by the 32Khz crystal will count 32,768 times.
     
    We can work out how many clock cycles the timer will run for to achieve a 121.1bpm output.
     
    121.1 [beats per minute] / 60 = 2.018 [beats per second]
    Clock cycles = 32768 [cycles per second] / 2.018 [cycles] = 16,235.177 cycles.
     
    Now we can't set a timer to 0.177 cycles. so we'll round down. CCR = 16,235.
     
    Now rounding introduces error, lets see how big this error is by working backwards.
    32,768 / 16,235 = 2.01835 Hz
    2.01835 * 60 = 121.1013 bpm
     
    (121.1 - 121.1013) / 121.1 = -0.0000109 = -10ppm (This is in the range of the crystal frequency specification)
     
    I'm not sure if you would like an even more accurate timer than this.
    (Keep in mind that if you use a faster clock source for the timer Module then the timer will be overflowing multiple times during your period, you will need to account for this in software)
     
    Also please correct me if my maths is wrong, This was all "back of the envelope" stuff
  9. Like
    sven222 reacted to enl in Very accurate timer   
    Your error calc isn't correct. At 676,46 counts nominal and 676 counts actual, the error is at most half of (1/676)*100, which is 0,0014*100, or 0,14%, for a max error of 0,07% (this matches your calculation). At 121,2bpm, the error will be much less, as the actual rate with a count of 676 is 121,18. You will have a 0,1% worst case error at a freq of roughly 180bpm. At your 121bpm range, you have an accuracy of approximately +/-0.1bpm.
     
    If you need more accurate than this, you can jitter the count in a manner analogous to the way the DCO clock and the clock divider for the serial module do. In fact, if it was me (which it is not) I probably would. I would have the timer interrupt at count, and reset the terminal count in the interrupt handler. Each time, rotate a 16 bit word with the appropriate bits set for the nearest 1/16th of a count. Mask the low order bit and add that to the count so when there is a '0' to the low order bit, the count is the for higher BPM, when a '1' it is a cycle longer for the lower exact BPM. This will get your error to less than 0,01% (100ppm) for all rates up to approximately 1000BPM. The max error will be less than one half period of the highest audible tone (ok, a bit more than 1/2 period if the listener happens to be a newborn, or a cat, or a dog). This is probably sufficient for most music applications.
     

  10. Like
    sven222 reacted to chicken in Help with delay timer for relay, energia code.   
    There can be problems when doing the math in different orders.
     
    For example when you calculate the end time based on start time and interval, and then compare it against the current time, you will run into issues:
     
    e.g.: if (current time > start time + interval)
     
    start = 250
    interval = 16
    end = 250 + 16 = 266 = 10 -> current time will be larger until it wraps around, i.e. the condition triggers immediately
     
    It can get even worse when end is close to the wrap-around point (e.g. 255) and current already shot past it. In this case current will be smaller than end for a VERY long time.
     
    I think the trick is, to always compare difference of start and current with the interval instead of trying to calculate and compare the end time.
  11. Like
    sven222 reacted to greeeg in Size of binary   
    Here. I took your code and compiled it.
     
    The elf file actually contains more information than what will be programmed to the MSP430. Most of this extra information is used for debugging.
     
    If you compile with mspgcc. Then the msp430-size command will tell you the size that your program needs on your MSP430.

  12. Like
    sven222 reacted to petus in Size of binary   
    When do you load the code to the MSP430, how is size of the code?
    my code (about 1000 line) has *.o 20kb
    Do you try reinstall CCS? Post your code :-)
  13. Like
    sven222 reacted to RobG in Input bits to byte, and byte to array   
    Crete 2 loops, one with count == size of array, the second, inner loop with count of 8. In the inner loop, test your input and set first bit. Shift byte left. Following inner loop, put the byte in the array and clear byte. Something like this:
    int arrayCounter = 0; int arraySize = sizeof(myArray); char bitCounter; char byte; while (arrayCounter < arraySize) { bitCounter = 0; while (bitCounter < 8) { if(input & bitMask) bit |= 0x01; bit << 1; bitCounter++; } myArray[arrayCounter] = byte; byte = 0; bitCounter = 0; arrayCounter++; }
  14. Like
    sven222 reacted to jpnorair in Buildng millis() function with watch dog interrupt   
    Is flipflop supposed to divide by 2?  It is a variable declared on the stack, so unless there is some hack or feature of WDT interrupt I don't know about, it is not going to work the way you want.
     
    Easier way to divide by 2 is to just have millis++ in the interrupt (nothing more) and then have get_millis() { return (millis >> 1); } or something like that.
×
×
  • Create New...