Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Fmilburn

  1. Hi @@ZenClide


    I tried it just now on a CC3200, Energia V17 without EMT and it worked fine other than the expected bounce from the switch... I hooked up a pushbutton switch to pin 4 and ground (without a pullup) as shown in the photo below:


    I used the following sketch:

    #define PUSH4  4
    volatile int state = HIGH;
    volatile int flag = HIGH;
    int count = 0;
    void setup()
      pinMode(GREEN_LED, OUTPUT);
      digitalWrite(GREEN_LED, state);
      /* Enable internal pullup. 
       * Without the pin will float and the example will not work */
      pinMode(PUSH4, INPUT_PULLUP);
      attachInterrupt(PUSH4, blink, FALLING); // Interrupt is fired whenever button is pressed
    void loop()
      digitalWrite(GREEN_LED, state); //LED starts ON
      if(flag) {
        flag = LOW;
    void blink()
      state = !state;
      flag = HIGH;


    This solution is in atmelstudio and i'am trying to compile that to an arduino uno but without success.

    You are referring to an issue around Atmel microcontrollers on a Texas Instruments oriented site so it is very unlikely you will get a satisfactory response to your question.   Anyway, you will not get something written for an ARM processor using direct register access to compile on a 8 bit processor like the Uno.  Nor will it compile on a MSP430.  And it is unlikely that anyone has ported this to Arduino/Energia but the best persons to ask would be the authors of the firmware.

  3. @@NurseBob,  That is a great link - much appreciated.  I discovered Jack Ganssle a while back but still haven't worked through all his articles and had not seen that one. As usual, he hits it out of the park.  The quick answer to the comparison question is that the two sets are a bit apples to oranges but if anything my tests left me expecting shorter battery life than what his do.  The internal resistance of the batteries from my tests seems higher.


    They are apples to oranges because he tested with a constant current whereas for simplification I used constant external resistance and as a result the current varies over time.  I also have a much sparser dataset consisting of one manufacturer (which I am now skeptical of) and only two samples.


    The measured current in my setup with the 219 ohm load (nominal 220 ohm resistor) varies from about 13 mA at the 1 minute mark to about 9 mA when it crosses 2V.  It took it 190 min to get there.  So the battery life is roughly 11 * 190 / 60 = 35 mAh.  Jack reports 180 mAh 3 sigma for a constant 10 mA load.  I believe my data is good so I may have some knockoff or bad batteries - entirely possible since I acquired them super cheap over the internet - like 11 cents a piece in a quantity of 20 and free shipping.  The difference in life is enough that I am tempted to go buy some batteries I know are name brand and repeat the test.


    I agree with your observation on whether 10 mA is within specification.  In any event, I don't think what I am attempting here meets any normal engineering criteria or approach to product development.  I spent almost 40 years as an engineer in an industry where safety considerations and cost meant we applied very rigorous testing and safety factors to designs.  Product failure was not acceptable.


    I am a hobbyist tinkerer now and outside my area of expertise and it is kind of fun to be ignorant and just experiment (making sure I don't do anything that could hurt myself or others).   I may end up with only a modest number of dim LEDs and very short battery life but that is acceptable.  In addition I have provided for an external battery and could easily hook up a AA pack if it were necessary.

  4. Glad you got it working.  Using switch to control the program flow is a common way to do it and makes it easy to see what is going on or add new pins.  For example, the following watches for the interrupt and toggles the LaunchPad LEDs (with a lot of bounce).

    /* Watch for interrupts on two buttons and toggle LEDs
     * Written for the G2553 on MSP-EXP430 G2 V1.5 LaunchPad
    #include <msp430.h> 
    #define RED_LED    BIT0                 // LaunchPad LEDs
    #define GREEN_LED  BIT6
    #define S1         BIT3                 // LaunchPad button
    #define EXT        BIT4                 // External switch
    int main(void)
        P1DIR |= RED_LED;
        P1OUT &= ~RED_LED;
        P1DIR |= GREEN_LED;
        P1OUT &= ~GREEN_LED;
        P1OUT = S1 | EXT;                   // Switches will be pull-up inputs
        P1REN = S1 | EXT;
        P1IE = S1 | EXT;                    // Enable interrupt for switches
        P1IES = S1 | EXT;                   // Interrupt occurs on HI --> LO
        P1IFG = 0x00;                       // Ensure no interrupts are pending on Port 1
        _BIS_SR(GIE);                       // Global interrupt enable
        while(1){}                          // Loop forever
    #pragma vector=PORT1_VECTOR
    __interrupt void Port_1(void)
        switch(P1IFG & P1IE){                // Which pin was it?
            case BIT0: break;
            case BIT1: break;
            case BIT2: break;
            case BIT3:
                P1OUT ^= RED_LED;
                P1IFG &= ~ S1;               // clear interrupt
            case BIT4:
                P1OUT ^= GREEN_LED;
                P1IFG &= ~EXT;               // clear interrupt
            case BIT5: break;
            case BIT6: break;
            case BIT7: break;
            default:   break;                // should never get here
  5. Hi @@Synoptic,


    That is definitely doable.  As you said, there are lots of examples for doing similar things on the internet.  You seem to have the problem fairly well defined.  In your code, catch the button pushes in an interrupt or poll during the loop.  Record the state of the buttons and act accordingly with a if... else control structure or with switch.  There are examples for reading buttons and control structures on energia.nu: http://energia.nu/guide/


    Try putting together the code and come back if you have an issue.... 

  6. CR2032 Battery Performance


    Most of what I am doing in this project is well plowed ground, but the elevated current requirements differ from what is normally done with a CR2032 battery.  For example, here is data from an Energizer data sheet:


    The battery maintains a fairly constant voltage after an initial drop but there is a marked increase in the internal resistance of the battery at 105 mAh and the voltage supplied drops off.  The background drain in the upper green curve is 0.2 mA.  The red pulsed curve is 23 mA on for 1 mSec and then off for 14 mSec.


    My application requires high currents (10 mA +) continuously without interruption.  The tests that follow have a constant resistive load and were recorded continuously at one minute intervals. Temperature was 20^C (68^F) and the test batteries were fresh Sony Lithium 3V CR2032 with a 2025 expiration date.  Voltages were measured with a MSP-EXP430FR6989 and checked with a multimeter.  Fixed resistances of 150 ohms and 219 ohms were tested.  Before the test the open voltage across both batteries was measured at 3.18 V (it makes me feel like a real engineer just to write this kind of stuff again).  Data was written to the serial terminal and copied into an Excel spreadsheet.  Here is the test setup:


    And here are the results:


    I've drawn a line at 2.2 V across the graph as this is about the minimum voltage I think I can get away with - at least with regular LEDs, I need to find the minimum voltage where WS2812s will work reliably.  Here are some observations:

    • There is a knee to the curves but they aren't particularly sharp or steep.  Neither curve is particularly flat.
    • With a 150 ohm load the battery lasted about 30 minutes before the voltage dropped below 2.2 V.  At that point the current was around 14.5 mA.  At peak it was 19 mA, and it averaged about 16 mA.
    • With a 219 ohm load the battery lasted about 2 1/2 hours.  Current dropped from about 13 mA to 10 mA and the average was around 11 mA or so.

    The results are good news and available power appears to meet project requirements.  The next step is to test a more realistic setup with some WS2812s and the TSOP38238. 


    Code for the battery test (Energia) is here:  https://github.com/fmilburn3/battery_voltage

  7. Rick:  Thanks for the ideas.  I've gone back now and looked at some of the older posts and there is some good stuff there.  There is an interesting link to an Adafruit forum as well.


    Terje: I am pretty sure any code you post would be more than equal to mine.  I would be interested in seeing what you did.


    I ran a quick test using a CR2032 with my existing wearable and regular LEDs to get some initial battery life data.  The coin cell is powering the G2553, the TSOP38238, and LEDs on the PCB.  The multimeter is measuring battery voltage.


    It has been operating for more than two hours now.  I need to instrument it better and get some current measurements as well.  Probably should do it with EnergyTrace.  Here are a couple of observations:

    • No transmission errors were detected (except the ones I purposely caused to test the setup) over a 2 hour trial
    • The LEDs are not at full brightness - the number and brightness of the LEDs will be the controlling factor on battery life
    • There is a lot of internal resistance in the CR2032 with higher currents.  Note that the multimeter is reading about 2.7 Volts  (the photo was at about one hour but it was well under 3V with a fresh battery ).
    • The G2553 is running at 16 MHz and the datasheet recommends at least 3V at this speed - need to slow it down to 12 MHz or so.

    But overall, it appears that I can reach the requirements.

  8. Hi @@dubnet,


    I was aware of the IR booster pack, but not of that bundle at that price.  I also wasn't really aware that the MSP430FR4133 was so well matched to IR.  It beats the clunky pad with a ribbon connection that I have on hand and was going to prototype with.  I think I will order one.  The other way I am considering is to use a phone and connect to the IR transmitter microcontroller via bluetooth.  I have a CC2650 BoosterPack and could attach that to a microcontroller located with and driving a big bank of IR transmission LEDs for a pretty slick solution.


    Your second link is interesting and has a good discussion of various protocols and how they can be implemented.  I  did some research on protocols earlier but decided to make up my own for the educational value and insight on how modulation and encoding works while testing the limits of the receiver I had on hand.  I should go back now and look at other implementations to see what might be gained.


    I think the receiver end is going to be challenging.  It is greatly constrained by the CR2032 battery and WS2812s (which I would like to use) with their somewhat fiddly timing requirements all the while dealing with interrupts from the IR. 

  9. This project is an offshoot of an earlier investigation of wireless wearables using the MSP430G2553: http://forum.43oh.com/topic/10060-msp430-wearable-with-radio/. The concept has been successfully tested and is described below. I plan regular updates as the project progresses.


    The objective is to develop a wearable powered by a coin cell that can be controlled remotely. It could be used, as an example, in the tiara below or on a costume worn by dancers in a performance and controlled from offstage. In the photo an earlier MSP430G2553 coin cell powered wearable is attached to the tiara and driving 3 WS2812 LEDs.



    The constraints are:

    • cost - unit cost for the receiver of $10 or less
    • technology - common off the shelf components, MSP430G2553
    • construction - standard double sided PCB spec, keep SMD parts large enough to be hand soldered
    • power - CR2032 (rated 3V and 225 mAH)
    • life - needs to run at least half an hour on fresh batteries
    • reception - 10m with clear line of sight, update at least every 100 ms
    • transmission - desirable but not required
    • size - 40mm/1.6" diameter for receiver
    • programming - Energia desirable
    • schedule - 6 month completion
    The transmitter will probably be placed on a "Booster Pack" for a LaunchPad running Energia. Multiple LEDs will be driven to gain extra distance, and if required multiple transmitters could be set up from different angles to assure good reception. A display would be helpful as on the FR6989 shown below with an IR LED.


    The initial Energia transmission sketch to test the concept is located here: https://github.com/fmilburn3/Infrared/blob/master/IR_sendByte.ino. The sketch was developed in Energia V17 using a MSP430G2553 LaunchPad and a 940 nm infrared LED. It loops from 0 to 255 and sends a single byte with the count via infrared to the receiver when a button is pushed. The packets for sending bytes do not follow an existing protocol. It is specific to this application and developed with the goal of getting a byte transmitted at least every 100 ms.


    The receiver will be a custom MSP430G2553 board powered by a coin cell with a TSOP38238 IR receiver. There will LEDs on the PCB and it will also have the capability to drive LEDs off board.


    The preliminary receiver code was written in C using CCS and direct register access: https://github.com/fmilburn3/Infrared/blob/master/IR_Receiver/main.c . The framework for the code is based on a post by RobG here on 43oh. The receiver takes transmissions from the Energia sketch linked above and outputs the current byte on eight LEDs in binary form. When the last byte is received it clears the LEDs and outputs the number of bytes received in error out of the expected 255. This allows analysis of reception at different distances and conditions.


    Shown below is the preliminary testing setup. In the foreground is the G2553 receiver with a TSOP38238 and output LEDs on a breadboard. Middle ground is a G2553 with the infrared LED sending bytes. Background is output from the receiver being monitored on an oscilloscope. The output of the TSOP38238 is quite clean and no errors were seen with the transmitter and receiver this close together. Transmission is at approximately 1000 bytes per minute or 16+ bytes/sec which is within the desired range.


    I subsequently modified the test setup to run off batteries so I could do some preliminary distance testing. With clear line of sight reception I saw no errors up to 5 meters with one transmission LED aimed directly at the receiver. Errors crept in after that, especially if the transmission is off to one side, not pointed directly at the receiver, or at a greater distance.


    Near term activities:

    • increase the number of transmission LEDs
    • evaluate the impact of off-center transmission further
    • test in an environment that doesn't have reflective surfaces
    • add WS2812 driver capability and investigating the impact of TSOP38238 interrupts on the WS2812 driver
    • evaluate 2032 battery life further
  10. I should have labelled this MSP430 Wireless Wearable instead of Wearable with Radio.  Anyway, I have been happy with the progress using IR and plan to commit to it for now.  Here are the options that I considered and the reason for choosing IR:


    CC26xx - ruled out due to cost - did not pursue technical viability

    ESP8266 - ruled out due to power requirements when using CR2032 coin cell - not viable technically

    nRF24L - this is a potential alternate, the main concerns are power and distance which I did not pursue to the end.

    IR - cost is low, power requirements are low for receiver, able to cram it all into memory and fast enough on the MSP430G2553 if I use CCS and direct register access with C.  The main concerns are distance which should be able to overcome with higher power transmitters  (possibly multiple transmitters) since they need not be powered by a coin cell, and the difficulty in acknowledging successful receipt of a packet.


    I have started a new thread to document the development of the IR option: http://forum.43oh.com/topic/10098-msp430-infrared-controlled-wearable/

  11. Just about any microcontroller could do this - if you are serious about learning how then there are lots of resources.  For example:



    Several free courses at edX

    this one at udemy I thought was good:  Microcontrollers and the C Programming Language by Mark Budnik

    Lots of stuff on 43oh and other internet locations to explore


    Energia/Arduino has a place but you are basically stuck with whatever microcontroller and ICs that other people have written Energia/Arduino libraries for.  Good luck...

  12. It is saying that to send a "0" requires pulse high for 0.5 us, and follow with a low pulse for 2 us.  To send a "1" pulse high for 2 us, and pulse low for 0.5 us.  Each pulse should vary by no more than +/- 0.15 us.  So, for example, an acceptable pulse for0.5 us could be between 0.35 and 0.65.  Those values should work reliably since they come from the datasheet.  The total pulse length should be about 2.5 us.  Unfortunately I don't see a value which fits well with a 16 MHz clock.  However, often times things work for values outside the datasheet which is why I suggested what I did.  Clearly you would not want to do this for a critical application.


    You can try lengthening / shortening things from what I suggested and see if something will work - I really can't say since it is outside the specification.  Not sure I can be of much more help....


    The values for the SPI clock divider are fixed for the micro-controller peripheral being used.  You can only use the values that are given in the micro-controller datasheet (or in this case whatever Energia provides).  If you weren't using Energia/Arduino then you could change clock speed and account for it that way but you aren't - that kind of flexibility is something you give up with Energia/Arduino.

  13. I am going to try and update this weekly in the hope it will give me extra impetus to get it done.  I've done more looking at IR and as is normally the case have found lots out there that I didn't know, including some good stuff on 43oh.  To quickly summarize:

    • The IR receiver I am using (TSOP38238) works on 2.5V - 5.5V, and has a typical supply current of 0.27  - 0.45 mA. - seems like it will work OK with coin cell for this application
    • Using a matched 950 nm IR LED with the receiver at the moment.  Even with a single LED transmitter can get 10 m although not 100% reliable.  I expect to overcome this with a more powerful transmitter (e.g. IR illuminator as suggested by chicken)
    • The receiver is sensitive to transmission frequency but that is easily configured in software
    • The receiver is sensitive to burst length but that is also configured in software
    • The receiver is sensitive to spectral wavelength - need to consider this when ordering an IR illuminator ring or constructing a multi-LED transmitter
    • It has vertical and horizontal directivity but this isn't expected to be a problem

    Rather than use existing code or libraries I decided to strike out on my own as an educational exercise since it appears to be within my capability.  I started by writing a simple output function at 38 kHz that looks pretty good coming out of the G2553:


    Here it is on the oscilloscope after being processed by the TSOP38238 IR Receiver:


    Next I made up a protocol for sending 1s and 0s:


    OK, should be able to work with that.  Up to this point I had been working in Energia (one of my original objectives) but timing was too coarse in the micro second range.  So I have switched to CCS with the objective of using TimerA0 with interrupts, and then accessing it within Energia.  Tone() won't be usable, but hopefully there won't be other interference inside Energia and I don't need tone().

  • Create New...