chicken

Hi all,
 
I was wondering if modifying the compiler flags was easily possible? 
 
I have a program that is really tiptoe-ing the maximum program size for my FR5739, and when I add some extra functionality, it goes overboard by 1-2k. 
 
I think some of this is due to some extra bloat that Energia adds, but for the simplicity of getting up and running, alongside the sweet already-created libraries, it's totally worth it. 
 
So, before I go out and re-design a board with a different chip, I was wondering if there were some freebies I should look into. I think I've removed as much extra code as is feasible, and played around with adding/removing libraries, but the impact is negligible. 
 
One thing I would like to try is the msp430-strip command... I don't know what that will do, but I've seen that with --strip-unneeded -g -x, the results on the .o files seems to be good... I don't yet know how this will translate to the actual elf or hex files though.
 
Has anyone tried this before?
 
Thanks,
-SJ

Did you already check out the Stellaris Launchpad Workshop?
http://processors.wiki.ti.com/index.php/Getting_Started_with_the_Stellaris_EK-LM4F120XL_LaunchPad_Workshop
 
Files for lab exercises are in the Workshop Material section of the page.
 
Regards
Adrian

I bit the bullet and went to RadioShack to grab an Arduino Uno for reference. I know, sacrilegious!
 
Anyways, on Arduino both conditions (stop and restart) work. So I think it's save to say that my fix of restart is valid for MSP430 USCI. I will submit a pull request. (Assuming that maximum compatibility with Arduino libraries is an important goal of Energia)
 
Still trying to figure out why Stellaris doesn't like stop. Might be a timing issue due to the faster CPU..

I can't find the reference right now, but I think Seeed, does have a royalty sharing program for designers, similar to Adafruit and Sparkfun. Though there are so many Touch TFT Shields out there that I doubt this is some kind of unique design.
 
Anyways, I don't see any difference whether Seeed sells something through their website or traditional retail channels. The more the merrier.
 
[rant](not directed at anyone above)
It's a personal pet peeve of mine, that many in the OS community complain about rules imposed on them by software and hardware companies, but then turn around and put up "unwritten" rules about what others can do with open source. It's a bit like the bible thumpers that complain about the state taking away their freedom, but have no qualms imposing their rules on others.
[/rant]

I can't find the reference right now, but I think Seeed, does have a royalty sharing program for designers, similar to Adafruit and Sparkfun. Though there are so many Touch TFT Shields out there that I doubt this is some kind of unique design.
 
Anyways, I don't see any difference whether Seeed sells something through their website or traditional retail channels. The more the merrier.
 
[rant](not directed at anyone above)
It's a personal pet peeve of mine, that many in the OS community complain about rules imposed on them by software and hardware companies, but then turn around and put up "unwritten" rules about what others can do with open source. It's a bit like the bible thumpers that complain about the state taking away their freedom, but have no qualms imposing their rules on others.
[/rant]

I can't find the reference right now, but I think Seeed, does have a royalty sharing program for designers, similar to Adafruit and Sparkfun. Though there are so many Touch TFT Shields out there that I doubt this is some kind of unique design.
 
Anyways, I don't see any difference whether Seeed sells something through their website or traditional retail channels. The more the merrier.
 
[rant](not directed at anyone above)
It's a personal pet peeve of mine, that many in the OS community complain about rules imposed on them by software and hardware companies, but then turn around and put up "unwritten" rules about what others can do with open source. It's a bit like the bible thumpers that complain about the state taking away their freedom, but have no qualms imposing their rules on others.
[/rant]

First, Sorry for my poor english.

I am from Taiwan. Taiwan to Boston United States is 7718 miles.

I appreciate that bluehash make awesome 43oh.com.
I read 43oh forum every day and I learn a lot every day.

I bought some awesome boards from 43oh store totally $278.53 USD
There are my order history:

1.) 15 March 2013 have not received this package "yet".
2.) 25 March 2013 have received package in less then three weeks.
3.) 09 April 2013 have received package in less then two weeks.
4.) 27 April 2013 just shipped, a few days ago.

About the first package that I have not received yet. I just waiting.
I didn't send e-mail to bluehash.
i don't want to ask about claim.

The only thing I did is that I order again some boards when these awesome boards restock.

why?

bluehash is not digi-key / mouser.
bluehash use his own time in order to support the 43oh.
I learned a lot from the 43oh forum, I truly appreciate that.
I don't want to disturb bluehash.

The USPS package tracking system shows that package had shipped.
Taiwan is far away from the U.S. Anything could happen.
This is trade-off between flat rate shipping fee and increasing shipping fee include "insurance fee" to cover up lost packages.

In my opinion..if this continues
Stop international shipping is OK for me , I can use package forward service instead.
or Add a option which is increasing international shipping fee include "insurance fee".
Expensive Fedex is a good option too.

In short, I truly appreciate that bluehash is doing good job and nothing can stop me from buying awesome boards from 43oh store.

I bit the bullet and went to RadioShack to grab an Arduino Uno for reference. I know, sacrilegious!
 
Anyways, on Arduino both conditions (stop and restart) work. So I think it's save to say that my fix of restart is valid for MSP430 USCI. I will submit a pull request. (Assuming that maximum compatibility with Arduino libraries is an important goal of Energia)
 
Still trying to figure out why Stellaris doesn't like stop. Might be a timing issue due to the faster CPU..

This has been an issue that has been discussed at length on the Arduino forums. It boils down to that if a Library uses Wire then the Sketch will have to include Wire.h and not the library as the library does not know where to find it. This has to do with how things get setup during the build phase.
 
The reason why MSP430 has Wire.c/h and ultimately twi.c/h in the core is because USCI shares the TX/RX interrupt between I2C and UART. See usci_isr_handler.c for details. 
 
I wouldn't call it a bug as including Wire.h in a Sketch still works. Libraries in this case BMP085 should not make the assumption that including Wire.h is going to work as it for sure does not work on Arduino and Energia LM4F.

A PCB might be too heavy.
 
Plugging 6x3cm surface area, 1mm air gap and 6g weight into an online hovercraft calculator says we need about 35 Pa air pressure.
http://www.hoverhawk.com/lcalc.html
 
That number grows linearly with weight. However required pressure decreases with more surface area.
 
Assuming static pressure is the relevant spec:
The mightiest MightyMini fan UB5U3-500 at 30x30mm and 2.5g delivers 88.2 Pa. The 8x8mm fan in the original post only delivers a paltry 3 Pa at a weights of 0.45g. In-between models like the 17x17mm, 0.91g, 40 Pa blower UB3H3-700 look more promising.

A PCB might be too heavy.
 
Plugging 6x3cm surface area, 1mm air gap and 6g weight into an online hovercraft calculator says we need about 35 Pa air pressure.
http://www.hoverhawk.com/lcalc.html
 
That number grows linearly with weight. However required pressure decreases with more surface area.
 
Assuming static pressure is the relevant spec:
The mightiest MightyMini fan UB5U3-500 at 30x30mm and 2.5g delivers 88.2 Pa. The 8x8mm fan in the original post only delivers a paltry 3 Pa at a weights of 0.45g. In-between models like the 17x17mm, 0.91g, 40 Pa blower UB3H3-700 look more promising.

Did you already check out the Stellaris Launchpad Workshop?
http://processors.wiki.ti.com/index.php/Getting_Started_with_the_Stellaris_EK-LM4F120XL_LaunchPad_Workshop
 
Files for lab exercises are in the Workshop Material section of the page.
 
Regards
Adrian

I have merged pull request https://github.com/energia/Energia/pull/226 that was submitted by @@chicken.
This was indeed an issue with receiving only 1 byte. Thanks for the report and the fix!!

I'm not sure if you mean a periodic auto-save or an auto-save every time the sketch is uploaded.
 
I'd prefer the latter, as that keeps what your chip is doing in sync with the code, and acts as a nice checkpoint for saves (for me, anyway, I am a change-try-change-try sort of developer).
 
I once spent an evening working on a sketch, and for the last save (upon exit) I said "no", because for some reason I assumed it saved when a sketch was uploaded. Needless to say, I lost a bunch of work, and while my chip was in a pretty good state, I didn't know how to dis-assemble the code back to source (if that is even possible). Auto-save upon sketch upload would be very cool, and it could be a preference.
 
Thanks,
sutekh137

There's now an MSP430 LaunchPad book:
 
Getting Started with the MSP430 Launchpad
http://e2e.ti.com/blogs_/b/msp430blog/archive/2013/04/21/new-to-the-launchpad-check-out-the-new-quot-getting-started-with-the-msp430-launchpad-quot-book-now-available.aspx
 
Here it is on Amazon:
Getting Started with the MSP430 Launchpad
 
(does 43oh have an Amazon affiliate account?)

It works! 
 
time to study!!!
 

You can read more about Tiva C from our whitepaper here: http://www.ti.com/lit/wp/spmy010/spmy010.pdf

Funny.. I changed twi.c line 249 thinking that i can't lose anything, now its working
By the way yes my itg was getting the VDD from VCC port of the launchpad, close to 3.5V. But the signals were always like that, never a real square wave. 

Finally home and checked the impact of removing begin/endTransmission from requestFrom/read. Unfortunately I observe the same behavior.
 
Wire.requestFrom(BMP085_I2C_ADDR, 2); uint8_t id = Wire.read(); uint8_t ver = Wire.read(); works, but
Wire.requestFrom(BMP085_I2C_ADDR, 1); uint8_t id = Wire.read(); hangs at next time I2C is accessed.
 
Looking at the pins with an oscilloscope shows that
- reading 2 bytes properly completes with SDA and SCL high
- reading 1 byte keeps SDA low and continues driving SCL, until power is cycled
 
The full non-working example code:
void setup() {   Wire.begin();   Serial.begin(9600);   Serial.println("start"); }   void loop() {   Serial.println("beginTransmission");   Wire.beginTransmission(BMP085_I2C_ADDR);   Serial.println("write");   Wire.write(byte(0xd0));   Serial.println("endTransmission");   Wire.endTransmission();     Serial.println("requestFrom");     Wire.requestFrom(BMP085_I2C_ADDR, 1);   Serial.println("read");     uint8_t id = Wire.read(); //  uint8_t ver = Wire.read();   Serial.print("chip id: ");   Serial.println(id);     delay(1000); } Un-commenting the second read and changing requestFrom to read 2 bytes makes the problem go away.
 
Inserting the following code at line 269 of twi.c solves the 1-byte problem for me:
    if(length == 1) {                   // Special treatment when receiving one by         while(UCB0CTL1 & UCTXSTT);      // Wait for start bit to clear         UCB0CTL1 |= UCTXSTP;            // I2C stop condition to be sent after recv     } As mentioned up-thread, this is based on the USCI documentation, MSP430x2xxx family guide, page 473.
 
What's the preferred method to submit/contribute this fix to the Energia project? - edit: submitted pull request to Energia on github

Finally home and checked the impact of removing begin/endTransmission from requestFrom/read. Unfortunately I observe the same behavior.
 
Wire.requestFrom(BMP085_I2C_ADDR, 2); uint8_t id = Wire.read(); uint8_t ver = Wire.read(); works, but
Wire.requestFrom(BMP085_I2C_ADDR, 1); uint8_t id = Wire.read(); hangs at next time I2C is accessed.
 
Looking at the pins with an oscilloscope shows that
- reading 2 bytes properly completes with SDA and SCL high
- reading 1 byte keeps SDA low and continues driving SCL, until power is cycled
 
The full non-working example code:
void setup() {   Wire.begin();   Serial.begin(9600);   Serial.println("start"); }   void loop() {   Serial.println("beginTransmission");   Wire.beginTransmission(BMP085_I2C_ADDR);   Serial.println("write");   Wire.write(byte(0xd0));   Serial.println("endTransmission");   Wire.endTransmission();     Serial.println("requestFrom");     Wire.requestFrom(BMP085_I2C_ADDR, 1);   Serial.println("read");     uint8_t id = Wire.read(); //  uint8_t ver = Wire.read();   Serial.print("chip id: ");   Serial.println(id);     delay(1000); } Un-commenting the second read and changing requestFrom to read 2 bytes makes the problem go away.
 
Inserting the following code at line 269 of twi.c solves the 1-byte problem for me:
    if(length == 1) {                   // Special treatment when receiving one by         while(UCB0CTL1 & UCTXSTT);      // Wait for start bit to clear         UCB0CTL1 |= UCTXSTP;            // I2C stop condition to be sent after recv     } As mentioned up-thread, this is based on the USCI documentation, MSP430x2xxx family guide, page 473.
 
What's the preferred method to submit/contribute this fix to the Energia project? - edit: submitted pull request to Energia on github

I have been working with the STM32F051 device this past year and I have got to say that it is an amazing processor for the price. 
 
I tried very hard to convince my project manager to design in an MSP430 into our system but he (patiently) repeatedly showed me how much processing power is available per milliamp and per dollar.
 
In the end, if you are designing a big system, there is no contest between an M0 and an MSP430. The M0 creams the MSP430.
 
BUT the price you pay for a device is not the only cost you will face!
 
The complexity of an M0 is a magnitude larger than the MSP430. That means that software development is costlier. We agonized over a software design set for the M0. In the end, Atollic was chosen because it got us across the finish line faster than any other option. I personally wanted to use Rowley because of familiarity but the path to success was a harder path to travel and time was of the utmost essence.
 
In the end, to tinker's, I believe the argument between MSP430 and M0 is not a big deal. So, to us on the board, I wouldn't stress out about this topic. 
 
It is more important to explore, experiment and enjoy the sense of discovery and accomplishment when we get something going.

Well, I think I know what happened here... you need to add the Tiva board to your wishlist and then order it. I think I saw the picture at the bottom of the page and added it to the cart not realizing that that was a link to the old EK120XL... so now what will I do with two more

More test gear with MSP430 inside: A MSP430F437 powers the Tonghui TH2822A LCR meter.
Teardown and pictures on KuzyaTech's blog: http://kuzyatech.com/tonghui-th2822a-lcr-meter

beginTransmission() and endTransmission() are for writing to the I2C device, not reading.  
Your code should be
 

Wire.requestFrom(BMP085_I2C_ADDR, 1); uint8_t id = Wire.read(); Please refer to http://arduino.cc/en/Reference/WireBeginTransmission and http://arduino.cc/en/Reference/WireRequestFrom

This code for BMP085 has been working for several months on my weather station based on MSP430G2553