chicken

Very nice! Like the TinyDuino, I'd move the USB connector (it's HUGE!  :shock:) to a separate booster pack and use the back of the processor board for an optional coin cell.
http://tiny-circuits.com/shop/tinyduino-processor-board/

hey I was playing around after reading the Tiny Circuits website about their tiny arduino platform...
 
and I decided to see what could be done with a micro launchpad concept.
 
here is my ?-Launchpad v1.0    14mm x 14mm  with full 10 pin header on each side to mount the ?-Boosters to.
the small size makes the boards stupid cheap at OSH...  they are $1.50 for 3 boards.
 
 
12mm spacing between headers, .050 mil headers.  I'm not sure what kind of boosterpack you could build at 14mm  but I got the USB interface and the MSP430 in there so it should be fun to see.

 
I threw together a LED micro booster  it is a 4 x 8 grid of 0402 LEDs  driven directly from the MSP430 pins through resistors with 2 sets of 16.  one in forward bias, one in reverse bias so you can drive the whole matrix with 8 pins.

although in thinking about it, If i were to make it, I would change to SMD female headers, so I could spread the LEDs out more on the top surface.
 
as a comparison to see how small it is, here is a launchpad next to my micro SNES board which is 12x12mm 

Hi,
 
I wanted to play with the low-power abilities of the MSP430, so I put together a simple clock using the e-paper display from a Motorola F3.
See the full documentation in my wiki, as well as the
I recorded. The code can be found on github. 


 
Steve

You can use the LaunchPad to program standalone chips that you purchase and install on your own PCB.  There is a how-to at http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To
 
I'd suggest putting a standard ARM connector on any board you create and interface that to the pins on the LaunchPad http://www.keil.com/support/man/docs/ulinkpro/ulinkpro_hw_if_jtag10.htm  This is what the programmers from Keil, IAR and others use this gives you flexibility if you want a different "standard" programmer later.
 
The chip you buy from TI will identical to the chip on the LaunchPad in terms of how you program and how you get code on to it.  See LMFlashProgrammer, This plus the bootloaders in ROM means that production boards (debug not needed) don't need to waste space and money on JTAG connectors.  You can use serial or USB or other interfaces.
 
The TivaWare examples generally use the ROM_ functions.  These are in ROM so no flash space gets used by them.  They also execute at full device speed.  Flash executes at 40Mhz max then you get a read buffer and some minimal performance loss vs the ROM.
 
Yes again, the TM4C1233H6PM is "identical" to the LX4F.  The TM4C is a later revision of the same silicon.  It has a few errata fixes but the base function is the same.
 
Don't be scared by the ROM.  If you don't want to use it at first then you can pretend it is not there and then you just concern yourself with the code you write that goes in flash.
 
The latest builds of openocd now have integrated the support for the ICDI interface on the LaunchPad so lm4flash should not be needed anymore and you can do much more in depth debugging with openocd and gdb.  Tivaware ships with makefiles for GCC as well as the project files for CCS.  I believe Mentor Sourcery CodeBench is also supported in Linux and project files are in TivaWare.
 
 
 
dellwood

Just came across this post on TI's MSP430 blog:
http://e2e.ti.com/blogs_/b/msp430blog/archive/2013/06/07/who-wants-more-tool-deals.aspx
 
MSP-TS430PEU128 for $20
128-pin ZIF socket target board for MSP430F677xIPEU and MSP430F67791xIPEU Flash parts in a 128-pin QFP package (TI package code: PEU).
http://www.ti.com/tool/msp-ts430peu128
 
MSP-TS430DL48 for $20
48-pin ZIF socket target board for some MSP430F Flash parts in a 48-pin SSOP package (TI package code: DL).
http://www.ti.com/tool/msp-ts430dl48
 
MSP-TS430PW28A for $55
28-pin ZIF socket target board for some MSP430F Flash parts in a 20- or 28-pin TSSOP package (TI package code: PW)
http://www.ti.com/tool/msp-ts430pw28a
 
MSP-TS430PZ100 for $55
100-pin ZIF socket target board for some MSP430F Flash parts in a 100-pin TQFP package (TI package code: PZ).
http://www.ti.com/tool/msp-ts430pz100
 
The product pages show the regular prices ($89-$119), but clicking "Buy from TI" will give you the discounted prices.
 
Wonder if SSOP sizes are standardized.. if so I'm tempted to get the DL48 as a general breakout tool.

Well, you moved most of the overhead of digitalWrite/Read outside of the loop with sbi/cbi. Include the calculation of _port and _mask into the second loop and we're probably getting closer.
 
When you look at the source of StellarisWare / driverlib, you will see that GPIOPinWrite/Read are a single command:
return(HWREG(ulPort + (GPIO_O_DATA + (ucPins << 2)))); and
HWREG(ulPort + (GPIO_O_DATA + (ucPins << 2))) = ucVal; respectively.
 
I'd venture to guess that moving those lines directly into wiring_digital.c instead of calling ROM_GPIO already makes a big difference. Given that we save a call, the size penalty should be small.
 
Another thing I notice is, that we first create a bitmask out of the single pin and that mask then get's shifted by 2 in the code above. Maybe the two operations can be combined. Though I guess creating another look-up table just for this minor improvement is not worth the trade-off.

I see the same behavior with the official 0101E0009 build and the Stellaris Launchpad.
 
Looks like there was a major overhaul of wiring.c since then that might fix the issue. Unfortunately I couldn't get the newer version to work for me. Grabbing wiring.c alone seems to completely screw timing (i.e. Serial doesn't work anymore), and grabbing larger parts of the hardware folder causes compile errors about a missing syscalls.h.
 
PS: You might have more luck getting an answer over on Stellarisiti http://forum.stellarisiti.com/

They have two PanaVise models on sale online:
http://www.radioshack.com/shop/rsk_onsale_results.jsp?categoryId=2032058&cp=2056569.2032058&f=Taxonomy%2FRSK%2F2032058&znt_campaign=Category_CMS&znt_medium=RSCOM&znt_source=CAT&znt_content=CT2056569
 
Didn't see any Arduino related items on sale.

Another Fluke another MSP430:
 

 
Fluke 113 Utility Multimeter  
MSP430F448 - lots of pins thanks to the integrated LCD controller.

For test purposes, you could set the initial milliseconds value to something else than 0 in line 48 of wiring.c:
 
 
volatile unsigned long wdt_millis = 0;  
e.g. 0xffff0000 should give you about a minute before roll over.

@@chicken,
 
wow, I really appreciate your support. Thank you for your time on this one.
 
I will try to test this tomorrow.
 
Scott

Actually, one last thing: Pull the jumper to the LED on P1.6, powering the LED might conflict with the I2C communication.

I am sorry, I was wrong. The program compiles with the following modification (I don't know why yesterday didn't):
uint8_t i = 0; //The new wire library needs to take an int when you are sending for the zero register With this modification I get two different results. When I supply the module with +5V It doesn't show any communication: 

 
But when I supply the module with 3.3V I get this (something curious happens):

 
On the other hand, i've tried with the following sketch: 
#include <Wire.h> void setup () { Serial.begin(9600); Wire.begin(); } void loop() { Wire.beginTransmission(0x68); Wire.write((uint8_t) 0); Wire.endTransmission(); Wire.requestFrom(0x68, 7); uint8_t ss = Wire.read(); uint8_t mm = Wire.read(); uint8_t hh = Wire.read(); Wire.read(); uint8_t d = Wire.read(); uint8_t m = Wire.read(); uint8_t y = Wire.read(); Serial.print("raw RTC data "); Serial.print(ss); Serial.print("\t"); Serial.print(mm); Serial.print("\t"); Serial.print(hh); Serial.print("\t"); Serial.print(d); Serial.print("\t"); Serial.print(m); Serial.print("\t"); Serial.println(y); delay(1000); } And I also get two different things, when i supply the module with 5Volt I get nothing, but when I supply it with 3.3V I get this: 
 

 
I think this demonstrates that the module is incompatible. Isn't it? 

Don't give up yet, we haven't even identified the actual issue

If that won't compile, please respond with the actual error message. Otherwise it's hard to guess what went wrong.
 
That being said, there are several things that could go wrong, including some know issues with I2C in the last official release of Energia. Here a basic test program that you could use in a fresh Energia sketch to at least rule out issues with the library and Energia itself.
#include <Wire.h> void setup () {     Serial.begin(9600);     Wire.begin(); } void loop() {     Wire.beginTransmission(0x68);     Wire.write((uint8_t) 0);     Wire.endTransmission();       Wire.requestFrom(0x68, 7);     uint8_t ss = Wire.read();     uint8_t mm = Wire.read();     uint8_t hh = Wire.read();     Wire.read();     uint8_t d = Wire.read();     uint8_t m = Wire.read();     uint8_t y = Wire.read();       Serial.print("raw RTC data ");     Serial.print(ss);     Serial.print("\t");     Serial.print(mm);     Serial.print("\t");     Serial.print(hh);     Serial.print("\t");     Serial.print(d);     Serial.print("\t");     Serial.print(m);     Serial.print("\t");     Serial.println(y);     delay(1000); } Hope that compiles, just writing/copying blindly without Energia right now
 
Make sure to power cycle the LaunchPad (i.e. unplug / replug the USB cable) to rule out any hardware issues from previous attempts.
 
If you still get garbage (e.g. all 255 or 0), then it's time to check your wiring.. or listen to the others and get a 3.3V compatible module, but where's the fun with that?

When you press Reset on the LaunchPad, does it display "RTC is not running!"?
 
Also, for better debugging you can try to insert the following lines into your loop:

Wire.beginTransmission(0x68); Wire.write((uint8_t) 0); Wire.endTransmission();   Wire.requestFrom(0x68, 7); uint8_t ss = Wire.read(); uint8_t mm = Wire.read(); uint8_t hh = Wire.read(); Wire.read(); uint8_t d = Wire.read(); uint8_t m = Wire.read(); uint8_t y = Wire.read();   Serial.print("raw RTC data "); Serial.print(ss); Serial.print("\t"); Serial.print(mm); Serial.print("\t"); Serial.print(hh); Serial.print("\t"); Serial.print(d); Serial.print("\t"); Serial.print(m); Serial.print("\t"); Serial.println(y); And while looking at the code, I noticed a pretty unusual hack that actually might be a freak cause of the issue:
int i = 0; //The new wire library needs to take an int when you are sending for the zero register .. Wire.beginTransmission(0x68); Wire.write(i); Wire.endTransmission();  That's one ugly way to do a cast. AVR being an 8bit might interpret the int as 8 bit, MSP430 will treat it as 16bit. This might confuse the RTC. Try replacing the first line (line 19 in the original library) with
 

uint8_t i = 0;

Does it compile?
 
If not, what's the error?

Taking a quick look at the code, you'll need to change at least the following:
 
Remove this line, MSP430 can access data stored in ROM just fine without.

5: #include <avr/pgmspace.h>  
Related to this, remove PROGMEM directive here: (you might prefix the line with static)
 
23: const uint8_t daysInMonth [] PROGMEM = { 31,28,31,30,31,30,31,31,30,31,30,31 }; and access to the array has to be rewritten, original:
 
31: days += pgm_read_byte(daysInMonth + i - 1); .. 62: uint8_t daysPerMonth = pgm_read_byte(daysInMonth + m - 1); changed:
 
31: days += daysInMonth[i - 1]; .. 62: uint8_t daysPerMonth = daysInMonth[m - 1];  
And finally, replace this section with #include "Energia.h"
 
13: #if (ARDUINO >= 100) 14:  #include <Arduino.h> // capital A so it is error prone on case-sensitive filesystems 15: #else 16:  #include <WProgram.h> 17: #endif

Looks like the RTCLib is using native AVR code, i.e. it needs some fixing to be portable beyond Arduino.
 
Are you using the Adafruit library?
https://github.com/adafruit/RTClib

Found an error in my micros() implementation, double-counting some microseconds.
 
By coincidence, it now compiles to exactly the same size as the old wiring.c.
 
I did some basic verification with MSP430G2553. As this is a rather central piece of code, it would be great if others could verify with different MSP430 variants before I send a pull request to the Energia project.
 
For testing, replace /energia/hardware/msp430/cores/msp430/wiring.c with the version in the attached archive.
TimerFixes v2.zip

Roadrunner,
 
I am a big fan of abstraction and automation.  I see plenty of room for accidental defects using the iomacros (i.e. P1OUT, P1REN, etc).  A good abstraction could help push the defect discovery process back to compilation.  So, I've been thinking about ways to solve your challenge.
 
Like Rick, I'm going to solve the problem with templates.  But I'm going to take it a step farther.  I'm going to make it simpler on the library user's end, but at the cost of a more complicated library.
 
For example, this--or something similar--is what I want to do:
int main(int,char**) { // disable watchdog, setup clocks removed to simplify legability typedef define_pin<port1,6> green; // P1.6 typedef define_pin<port1,0> red; // p1.0 enable_output<green,red>(); set_high<green>(); set_low<red>(); while(1) { delay_300ms(); // delay 300ms toggle_pins<green,red>(); } } Here's how I did it:
// need to add reinclusion protection #include msp430.h #include <stdint.h> // convinience / dispatch type template<typename PORT, uint8_t PIN> struct define_pin { typedef PORT port; enum pin_ { pin = (1 << PIN) }; }; // port definitions struct port_none { ; }; struct port1 { static inline void enable_output(const uint8_t& bits) { P1DIR |= bits; } static inline void set_high(const uint8_t& bits) { P1OUT |= bits; } static inline void set_low(const uint8_t& bits) { P1OUT &= ~bits; } static inline void toggle(const uint8_t& bits) { P1OUT ^= bits; } }; struct port2 { static inline void enable_output(const uint8_t& bits) { P2DIR |= bits; } static inline void set_high(const uint8_t& bits) { P2OUT |= bits; } static inline void set_low(const uint8_t& bits) { P2OUT &= ~bits; } static inline void toggle(const uint8_t& bits) { P2OUT ^= bits; } }; // // ENABLE OUTPUT // // default template template<typename PORT1> inline void enable_output1_impl(const uint8_t& p1) { PORT1::enable_output(p1); } // default template template<typename PORT1, typename PORT2> inline void enable_output2_impl(const uint8_t& p1, const uint8_t& p2) { PORT1::enable_output(p1); PORT2::enable_output(p2); } // default template template<typename PP1, typename PP2=port_none> struct enable_output { enable_output() { enable_output2_impl<typename PP1::port, typename PP2::port>(PP1::pin,PP2::pin); } }; template<typename PP1> struct enable_output<PP1,port_none> { enable_output() { enable_output1_impl<typename PP1::port>(PP1::pin); } }; // specialized template<> inline void enable_output2_impl<port1,port1>(const uint8_t& p1, const uint8_t& p2) { port1::enable_output(p1 | p2); } template<> inline void enable_output2_impl<port2,port2>(const uint8_t& p1, const uint8_t& p2) { port2::enable_output(p1 | p2); } // // SET HIGH // // default template template<typename PORT1> inline void set_high1_impl(const uint8_t& p1) { PORT1::set_high(p1); } // default template template<typename PORT1, typename PORT2> inline void set_high2_impl(const uint8_t& p1, const uint8_t& p2) { PORT1::set_high(p1); PORT2::set_high(p2); } // specialized templates template<> inline void set_high2_impl<port1,port1>(const uint8_t& p1, const uint8_t& p2) { port1::set_high(p1 | p2); } template<> inline void set_high2_impl<port2,port2>(const uint8_t& p1, const uint8_t& p2) { port2::set_high(p1 | p2); } // default template template<typename PP1, typename PP2=port_none> struct set_high { set_high() { set_high2_impl<typename PP1::port, typename PP2::port>(PP1::pin,PP2::pin); } }; // specialized template template<typename PP1> struct set_high<PP1,port_none> { set_high() { set_high1_impl<typename PP1::port>(PP1::pin); } }; // // SET LOW // // default template template<typename PORT1> inline void set_low1_impl(const uint8_t& p1) { PORT1::set_low(p1); } // default template template<typename PORT1, typename PORT2> inline void set_low2_impl(const uint8_t& p1, const uint8_t& p2) { PORT1::set_low(p1); PORT2::set_low(p2); } // specialized templates template<> inline void set_low2_impl<port1,port1>(const uint8_t& p1, const uint8_t& p2) { port1::set_low(p1 | p2); } template<> inline void set_low2_impl<port2,port2>(const uint8_t& p1, const uint8_t& p2) { port2::set_low(p1 | p2); } // default template template<typename PP1, typename PP2=port_none> struct set_low { set_low() { set_low2_impl<typename PP1::port, typename PP2::port>(PP1::pin,PP2::pin); } }; // specialized template template<typename PP1> struct set_low<PP1,port_none> { set_low() { set_low1_impl<typename PP1::port>(PP1::pin); } }; // // TOGGLE // // default template template<typename PORT1> inline void toggle1_impl(const uint8_t& p1) { PORT1::toggle(p1); } // default template template<typename PORT1, typename PORT2> inline void toggle2_impl(const uint8_t& p1, const uint8_t& p2) { PORT1::toggle(p1); PORT2::toggle(p2); } // specialized templates template<> inline void toggle2_impl<port1,port1>(const uint8_t& p1, const uint8_t& p2) { port1::toggle(p1 | p2); } template<> inline void toggle2_impl<port2,port2>(const uint8_t& p1, const uint8_t& p2) { port2::toggle(p1 | p2); } // default template template<typename PP1, typename PP2=port_none> struct toggle_pins { toggle_pins() { toggle2_impl<typename PP1::port, typename PP2::port>(PP1::pin,PP2::pin); } }; // specialized template template<typename PP1> struct toggle_pins<PP1,port_none> { toggle_pins() { toggle1_impl<typename PP1::port>(PP1::pin); } }; This is a great example, I think, of generic programming using dispatch tags and specialized templates.
 
This code works great to operate on 1 or 2 pins at a time.  It needs to be extended (easy, but tedious) to handle more.  Maybe 8 or 10.  Also, needs to be extended to enable input, enable resistors, and read input.  Again, easy and tedious.
 
But what about comparing the resulting assembly to C based iomacro only?  The same code, only using P1DIR and P1OUT, produces the EXACT same assembly output.  (Note that I am using mspgcc and have optimization turned on.  But, I wouldn't expect it any other way.  Well written, abstract C++ is often as optimal as boring old C.   ;-)  )
 
I'm sure if I thought about it longer, I could change the function call to 'enable_output(green,red)', even if only through a macro.

I finished up my first Energia project, a template library for the Bosch BMP085 temperature and pressure sensor. It uses I2C and supports temperature in Celsius and pressure in Pascal.
 
https://github.com/astuder/BMP085-template-library-Energia
 
I connected the GY-80 breakout commonly found on eBay, but it should also work with most other BMP085 breakouts, like the ones from Adafruit or Sparkfun.
 
Note that I had to patch Energia to make 1-byte read work on MSP430G2553 with Rev1.5 LaunchPad. I also had to remove the LED2 jumper, probably due to too weak I2C pull-up.
 
Update:
 
Tested on LaunchPad 1.5 with MSP430G2553, StellarPad Rev A and Arduino R3.
 
Energia requires patches 226 and 235 in twi.c for I2C to work properly on MSP430G2553
https://github.com/energia/Energia/pull/226/files
https://github.com/energia/Energia/pull/235/files
 
Updates:
- Tested with Energia 0101E0010 with MSP430G2553 and F5529, no more I2C patches needed.
- Tested with BMP180 and Software I2C http://forum.43oh.com/topic/3777-energia-library-bosch-bmp085-template-library/?p=44410
- Fixed I2C for Energia 0101E0016 by removing ugly hacks from the past from the library code. Tested only with MSP430G2553

Now tested on StellarPad and Arduino.

Just came across this announcement of a math library optimized for MSP430:
http://e2e.ti.com/blogs_/b/msp430blog/archive/2013/05/07/mspmathlib-amping-up-the-performance-of-msp430-but-not-the-power.aspx
 
Unfortunately only for MSP430F5xx and F6xx and FRAM devices. Any idea what kind of peripheral these have to accelerate math?
 
MSPMATHLIB maim page here:
http://www.ti.com/tool/mspmathlib

Just came across this announcement of a math library optimized for MSP430:
http://e2e.ti.com/blogs_/b/msp430blog/archive/2013/05/07/mspmathlib-amping-up-the-performance-of-msp430-but-not-the-power.aspx
 
Unfortunately only for MSP430F5xx and F6xx and FRAM devices. Any idea what kind of peripheral these have to accelerate math?
 
MSPMATHLIB maim page here:
http://www.ti.com/tool/mspmathlib

Just came across this announcement of a math library optimized for MSP430:
http://e2e.ti.com/blogs_/b/msp430blog/archive/2013/05/07/mspmathlib-amping-up-the-performance-of-msp430-but-not-the-power.aspx
 
Unfortunately only for MSP430F5xx and F6xx and FRAM devices. Any idea what kind of peripheral these have to accelerate math?
 
MSPMATHLIB maim page here:
http://www.ti.com/tool/mspmathlib