Jump to content
43oh

Energia limitations?


Recommended Posts

So, after buying the book "Getting Started with the MSP430 Launchpad" (topic http://forum.43oh.com/topic/3891-any-experience-with-international-versions-of-books/ ), it turns out @@rockets4kids is correct - it is a basic introduction using Energia. Since I have already taught myself (with the help of you good folks, of course :smile: ) programming using C and CCS, another programming language is the last thing I need to learn.

 

However, I am curious... Energia seems to be a semi-BASIC style language with C-style formatting. What, if any, are the limitations of Energia over C/CCS?

Link to post
Share on other sites

It is C++ for what it's worth (not BASIC at all, but C++ with classes included in the framework to abstract away some of the details that are unnecessarily verbose to a beginner), but the framework is not currently laid out to properly & intrinsically support the Low Power Modes of the MSP430.  

 

Best relegated to devices plugged in all the time or with beefy power packs that can be recharged / gadgets that only get used for limited periods of time.  Although the MSP430 is very respectable in its power usage even when fully active.

Link to post
Share on other sites

The best way to look at Arduino/Energia is as training wheels for your micro-controller.   It is a perfectly reasonable way to get started, but you need to take the training wheels off if you ever want to get serious.

 

There is not much of a reason to use Arduino/Energia if you already know how to use the micro-controller natively.

Link to post
Share on other sites

The best way to look at Arduino/Energia is as training wheels for your micro-controller.   It is a perfectly reasonable way to get started, but you need to take the training wheels off if you ever want to get serious.

 

There is not much of a reason to use Arduino/Energia if you already know how to use the micro-controller natively.

 

lol.. yeah. I wish you'd have commented just a few minutes earlier the other day and I wouldn't have ordered this. :) I mean, it's a good book, I think, for beginners, and while I AM a beginner compared to most everyone here, it is a little bit "young" for me, so to speak :)

 

ah, well... I'll review it and pass it on to someone else, I suppose. Thanks, though...

Link to post
Share on other sites
  • 2 weeks later...

It is C++ for what it's worth (not BASIC at all, but C++ with classes included in the framework to abstract away some of the details that are unnecessarily verbose to a beginner), but the framework is not currently laid out to properly & intrinsically support the Low Power Modes of the MSP430.  

 

Best relegated to devices plugged in all the time or with beefy power packs that can be recharged / gadgets that only get used for limited periods of time.  Although the MSP430 is very respectable in its power usage even when fully active.

 

Can you elaborate on the issue with LPM?

 

I use LPM4 to put my little keyboard to sleep, and it works fine (in Energia). I call:

_BIS_SR(LPM4_bits | GIE);

and then pressing any key fires an interrupt that brings the keyboard back to life and finishes the loop. I do have to play a fair amount with attach and detach commands for the interrupts, but that is because I want the tones to be smooth and want to be able to change octaves while the note is playing.

 

I can completely verify that the LPM4 stuff works. When it goes to sleep, the current it is taking drops lower than my ammeter can even read (down from a few ma).

 

And since straight "raw" code will compile fine in Energia (at least the samples I have tried), what exactly is it missing? Just curious.

 

For the full code of my 85-tone keyboard you can check it out here:

 

https://github.com/sutekh137/Energia/blob/master/Keyboard/Keyboard.ino

 

or with fraudulent polyphony:

 

https://github.com/sutekh137/Energia/blob/master/PolyFraudic/PolyFraudic.ino

 

Thanks,

sutekh137

Link to post
Share on other sites

Can you elaborate on the issue with LPM?

 

I use LPM4 to put my little keyboard to sleep, and it works fine (in Energia). I call:

_BIS_SR(LPM4_bits | GIE);

and then pressing any key fires an interrupt that brings the keyboard back to life and finishes the loop. I do have to play a fair amount with attach and detach commands for the interrupts, but that is because I want the tones to be smooth and want to be able to change octaves while the note is playing.

 

I can completely verify that the LPM4 stuff works. When it goes to sleep, the current it is taking drops lower than my ammeter can even read (down from a few ma).

 

And since straight "raw" code will compile fine in Energia (at least the samples I have tried), what exactly is it missing? Just curious.

 

For the full code of my 85-tone keyboard (with fraudulent polyphony, even!) you can check it out here:

 

https://github.com/sutekh137/Energia/blob/master/Keyboard/Keyboard.ino

 

Thanks,

sutekh137

Hmm, I am confused now.  I trust your code works but I'm not sure how it wakes up out of LPM when the attachInterrupt() stuff runs?  From what I see in the msp430 core code, in WInterrupts.c:

__attribute__((interrupt(PORT1_VECTOR)))
void Port_1(void)
{
        uint8_t i;
        for(i = 0; i < 8; i++) {
                if((P1IFG & BV(i)) && intFuncP1[i]) {
                        intFuncP1[i]();
                        P1IFG &= ~BV(i);
                }
        }
}

#if defined(__MSP430_HAS_PORT2_R__)
__attribute__((interrupt(PORT2_VECTOR)))
void Port_2(void)
{
        uint8_t i;
        for(i = 0; i < 8; i++) {
                if((P2IFG & BV(i)) && intFuncP2[i]) {
                        intFuncP2[i]();
                        P2IFG &= ~BV(i);
                }
        }
}
#endif

I guess the interrupt code obviously works, but it shouldn't wake it up to allow it to continue the loop() right?  Or is it?  I'm just confused here cause IIRC to wake up from any LPM mode there needs to be a __bic_SR_register_on_exit() (or _LPMx_EXIT or some other variation) in play there otherwise the CPU returns to LPM4 after the interrupt routine exits...

Link to post
Share on other sites

Hmm, I am confused now.  I trust your code works but I'm not sure how it wakes up out of LPM when the attachInterrupt() stuff runs?  From what I see in the msp430 core code, in WInterrupts.c:

__attribute__((interrupt(PORT1_VECTOR)))
void Port_1(void)
{
        uint8_t i;
        for(i = 0; i < 8; i++) {
                if((P1IFG & BV(i)) && intFuncP1[i]) {
                        intFuncP1[i]();
                        P1IFG &= ~BV(i);
                }
        }
}

#if defined(__MSP430_HAS_PORT2_R__)
__attribute__((interrupt(PORT2_VECTOR)))
void Port_2(void)
{
        uint8_t i;
        for(i = 0; i < 8; i++) {
                if((P2IFG & BV(i)) && intFuncP2[i]) {
                        intFuncP2[i]();
                        P2IFG &= ~BV(i);
                }
        }
}
#endif

I guess the interrupt code obviously works, but it shouldn't wake it up to allow it to continue the loop() right?  Or is it?  I'm just confused here cause IIRC to wake up from any LPM mode there needs to be a __bic_SR_register_on_exit() (or _LPMx_EXIT or some other variation) in play there otherwise the CPU returns to LPM4 after the interrupt routine exits...

 

You know, I am not really sure why it wakes up. As you can see with the most basic ISR I attach, it doesn't even need to have anything in it:

void ISR_ButtonPressed() {
  // Just here to wake up from low power mode (if even attached).
  // It does not appear that any live code needs to occur.
  return;
}

I DID try to add some sort of weird vector thingamabob like the "__bic_SR_register_on_exit()" you mention, but got compile errors (I don't think all of my includes were correct).

 

However, yes, it does work. I'm not sure why. By attaching interrupts to every key before dropping into LPM and then detaching after, that stub ISR serves to wake things up.

 

And even if it didn't, I could probably figure out how to make the __bic_SR_register_on_exit() stuff work, seeing as how the

_BIS_SR(LPM4_bits | GIE);

seems to work (or is that only because it has something in the Energia include files doing the heavy lifting for me?).

 

As you can tell, I'm quite the n00b, hence my asking more about what Energia lacks. In any case, I doubt a hobbyist like me will ever get to the point where I need more than it can offer. *smile*

 

Here's a link to the YouTube video of showing the keyboard drop into LPM after ~5 seconds.

 

 

...gets to the point at around 2:30, sorry I get long-winded, and yes, I did add an LM386 amp all on the same board (need to do another video showing the finished product and polyfraudia)!

 

Thanks for the discussion! I am learning just via osmosis when I am around such clever folks!

 

Thanks,

sutekh137

Link to post
Share on other sites

FYI, the __bic_SR_register_on_exit() has to run from the servicing ISR -- can't run from any function called by that ISR, including your interrupt function.  This is because the __bic_SR_register_on_exit() macro modifies the contents of the stack so the MSP430 "pops" off a copy of the Status Register with those bits cleared when it exits Interrupt mode, thus making it wake up.

 

It does look like Energia makes use of LPM0 at least with delay() which is nice.  And the WDT ISR does a __bic_status_register_on_exit(LPM3_bits) for the millis() clock tick, but that shouldn't be running in LPM4 (and for that matter, the WDT uses the SMCLK which is disabled in LPM3)... Very confused how that actually works.  Might have to do some experiments later on.

Link to post
Share on other sites

Indeed, I was surpised when it worked. Rather, I was surprised when I hooked up the ammeter and saw that it really WAS dropping to a less-hungry power situation (I figured it was just staying full power and not really dropping, but not throwing errors, either).

 

I think I tried the other LPMs and noticed a different current reduction at each, so I just went as deep as I could with still having the thing play (and wake up) properly. I know I am out of my league when dumb luck lets me get something built better than I had planned.  *smile*   Maybe it will "break" with a future Eneriga update or something, and that will provide more clues as to how this is working now!

 

Thanks for the info about ...exit(). If anything DOES draw me further into MCU programming, it will be interrupts. Though many books and docs talk about how the interrupt paradigm is odd and strange to get used to, I immediately likened it to event-driven Windows programming -- which is what I do for a living. A Windows application UI is, in a way, just a massive display of interrupt widgets linked to many, many ISRs. The fact that they need to be used more carefully and thoughtfully in the MCU world was just sort of common sense to me. I leave my "sloppy" work for PCs with massive processors, huge clock speeds, and GBs of RAM...

 

Thanks,

sutekh137

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...