Rickta59

Nice write up and project description. Thanks! -rick

Now that you have a g2553 I would stop using TimerSerial and just use HardwareSerial. It is automatically included in Energia.h and you can reference it via Serial.xxx .. where xxx are the functions. We need to deal with this better. I'll see what I can do. -rick

I'm not sure I would agree with that. As with everything, It all depends on what you are doing. If you take the ASCIITable example and compile it on Energia 1.0 it only uses 1,518 bytes. On Arduino 1.0 that same example needs 2704 bytes. BlinkWithoutDelay on Energia is 628 bytes, on Arduino it is 1002 bytes. Depending on the chip ( g2231 vs g2553 ) it can be smaller or larger depending on what the code does. I don't see how that puts memory usage under heavy stress. -rick

I'm wondering if there are people out there who have thought about using Energia on linux but when they couldn't find a binary distribution stopped looking? If you would like to see a binary distribution, what linux distribution are you running ubuntu, debian or something else? Is it 64 bit or 32bit? Do you already have the latest msp430-gcc ( 4.6.3 ) or (4.5.3) ? If you don't have a gcc compiler would you want it bundled? I personally run ubuntu 11.04 32 bit with the latest 4.6.3 compiler. -rick

I think it is just as important to find a bug as to fix it. Thanks for your efforts and keep it up! -rick

After conferring with Robert he thinks and I concur that the problem is probably that the watchdog isr is kicking off between the time the ADC capture starts and before it has completed. The watchdog timer reenables the CPU which causes the analogRead code to continue execution when it really isn't ready. The code below seems to work and is somewhat more power friendly. It uses a combination of sleeping and checking the ADC busy bit. uint16_t analogRead(uint8_t pin) { // make sure we have an ADC #if defined(__MSP430_HAS_ADC10__) // 0000 A0 // 0001 A1 // 0010 A2 // 0011 A3 //

I took a look at this problem and I'm seeing the same results as you. I tried changing the analogRead code so that instead of sleeping and waiting for the ADC interrupt, it just sits in a busy while loop. That seems to fix it. Sitting in a busy loop isn't a very power friendly solution though. If you want the gory details here is a patch: diff --git a/hardware/msp430/cores/msp430/wiring_analog.c b/hardware/msp430/cores/msp430/wiring_analog.cindex 1bb2539..0543aa9 100644 --- a/hardware/msp430/cores/msp430/wiring_analog.c +++ b/hardware/msp430/cores/msp430/wiring_analog.c @@ -179,14 +1

Lots of interesting ideas over at MIT high low tech site: http://web.media.mit.edu/~plusea/ -rick

More of an FYI. The current coding focus of Energia has been getting the msp430g2452 and msp430g2553 chips working nicely with the standard and popular libraries. The original launchpad msp430g2231 chip only has 2k of flash and 128 bytes of ram. It also doesn't have a hardware UART. You might want to consider ordering one of the newer V1.5 launchpads from the TI EStore Launchpad. The V1.5 version comes with the newer msp430g2452 and msp430g2553 chips. These chips are a better fit for the Energia framework and it only cost $4.30 with free shipping. -rick

In TimerSerial.cpp in the code just before line 205 where you get the error you might replace: #ifdef TIMER0_A1_VECTOR with #if defined(TA0IV) && defined(TA0IV_TACCR1) -rick

The whole pin number thing makes me crazy. The way the arduino code was done, it requires runtime code to figure out something that is typically known at compile time. I would rather see the pin to port/bitmask mapping determined at compile time so code space and processing isn't wasted on this task. However, that isn't going to happen. However, there is already a solution to deal with the pin numbers so humans can read them. In pins_energia.h there are static constants that map the P1_0 names to pin numbers. If you use these variables, your code will be self documenting and make bet

Right now there isn't a binary version of the linux Energia. You will have to checkout the latest code and use 'ant' to build and run it. You need the following prerequisite software: msp430-gcc 4.5.3 or above mspdebug (the latest version would probably be best ) java compiler ant once you have checked out the git source or downloaded a zip and unpacked it, in a terminal window type: $ cd Energia/build $ ant clean build run If all goes well, it should compile the java Energia code, and then start running the IDE. -rick

This post has useful information on how to set up a barebones msp430 that works. http://www.43oh.com/forum/viewtopic.php?f=8&t=1152&p=7679#p7679 -rick

I just saw his schematic posted on the e2e.ti.com forum. He doesn't have a pull up on his configuration .. jeez I thought he had a working system. He doesn't. You need a pull-up and probably a small cap. I guess the first question should be post a schematic or a picture. When you fix this and add the pull up, power the board first with the launchpad 3.3 v and its regulator to make sure that works. If that does work then try your lm317 setup. -rick

What speed are you using for the MCU? Are you using the DCO? looks like you need to be < 5 MHz @ 1.8 volts.

What voltage does your led use? Maybe 1.8 v isn't enough to turn it on.

Is the source code available for this? How about some details on how you designed and plan to use this?

It defaults to 16MHz for the msp430g2553. The value of the define 'F_CPU' is determined by which board is selected in the Energia IDE. This value is stored in the boards.txt file and each board can have its own .f_cpu. value. Here is the default entry for the msp430g2553: lpmsp430g2553.build.f_cpu=16000000L The core code uses the F_CPU value to decide at compile time which precalibrated setting to use for the BSCCTL1 and DCOCTL registers. void initClocks(void) { #if defined(CALBC1_16MHZ_) && F_CPU >= 16000000L BCSCTL1 = CALBC1_16MHZ; DCOCTL = CALDCO_16MHZ; #elif

I haven't tried on windows so I can't say for sure. However, in the FIle/Preferences menu you can turn on verbose upload messages and it should tell you what is going on. One of the nice things about the msp430 is that it doesn't require a boot loader. The upload is handled by mspdebug or the MSP430Flasher.exe on windows. In fact, TX/RX pins are not used to upload. The TEST/RESET pins are used to upload using Spy-Bi-Wire protocol. -rick

Corth, that sounds fun. You might want to look at the C compiler that CCS V4 uses. I think it is Version 3. The calling convention with CCS 'C' is that the first 4 integer arguments to a c function are passed in R12-R15. Arg1 is R12 and arg4 is R15 ( at least for integer arguments) Seems like you should be able to push R12 instead of using R4. More info here: http://www.ti.com/lit/ug/slau132c/slau132c.pdf#page=101 -rick

So what would you do with these intrinsics? Seems like there are lots of solutions to get the same results using standard C. -rick

Interesting... I guess last year when I posted this I had about 2 weeks playing with the msp430 G series. Since that time I've learned a lot about the right way to do this. I agree that it is probably better to use the DCO clock for the SMCLK. However, I'd suggest for getting a more accurate Timer clock it makes sense to drive the Timer with an external clock instead of the driving the LFXT1 oscillator logic level. The data sheet say the external clock for the LFXT should be 10-50kHz. It also says that it is perfectly within spec to run the TimerA using an external clock up to 1

Here are some sample sounds to play. The are all 8 bit unsigned raw files, without any header sampled at 15625. You can import them into Audacity to see what they should sound like on your msp430g2553. Or you could copy them on to an SDcard at the top level directory to play them. -rick testsounds.zip

I've been experimenting with playing sound. I'm using the code below to read raw 8bit unsigned PCM files from the SDCard booster pack. I've attached the main routine. It is heavily commented so I'm not going to say much more than here it is. The Petit Fat Filesystem code can be found on the documents tab of the SDCard booster on the 43oh.com store. I also want to thank oPossum and woodgrainn with their help creating a decent low pass RC filter. I ended up using an LM386 as an amplifier on the P1.2 PWM output. Here is the schematic for that: http://compendiumarcana.com/forumpics

It shows the size in the picture: Binary sketch size: 934 bytes (of a 16,384 byte maximum) sketch == firmware More info here: http://www.43oh.com/forum/viewtopic.php?f=5&t=2565