chicken

I am happy to announce that release 0101E0010 just went up on energia.nu. 
 
I want to thank everybody for their support and contributions. Energia would not have been possible without such an awesome community!
 
Here are the highlights:
 
Lots of bug fixes. We were not able to squash all of them but got most of the big ones. New MSP430F5529 USB LaunchPad support. This one has a lot of flash (128k) and a lot of ram (8k). Initial support for the CC3000 WiFi BoosterPack on the MSP430F5529 USB LaunchPad. Anaren AIR BoosterPack for RF connectivity on the MSP-EXP430G2 LaunchPad  
Full release notes, F5529 LaunchPad pinmap and getting other details will go up over the weekend.
 
Happy making,
 
Robert

Alright so, I had to keep a zip on it til now but since it's released... I had early access to one of these (thanks to the TI folks!) and got to play with it a little ahead of time.  I'm going to dump my thoughts & observations:
 
1. New eZFET is based on the MSP430.DLL V3 open-source FET library, same as what they use with the FET430UIF.  See http://processors.wiki.ti.com/index.php/EZ-FET_lite
 
You will need the MSP430.DLL (compilable on Windows and Linux; CCSv6 early adopter beta has a binary with full support for it, CCSv5 might not) to use it with "mspdebug" ... I think it's supposed to work on the Mac too but I tried compiling the MSP430.DLL crap months ago and gave up.  For now I compile on my Mac using mspgcc 4.7.0 and scp over to my Windows netbook where I run "mspdebug tilib" with CCSv6 beta's MSP430.DLL to program & debug it.
 
2. The literature all mentions Energia, so I expect a full release of Energia is forthcoming soon.  Might be why they've been waiting so long to release an update.  I expect they will have got MSP430.DLL compilation on the Mac working for this release so I can quit worrying about copying the firmware & using my Windows machine ..... for everything including FET430UIF uses
 
3. eZFET's backchannel UART has 2 new lines; CTS and RTS.  I think these are implemented in the serial link so your PC's terminal program can use them, but on the MSP430 hardware side they merely connect to 2 random lines on the F5529: CTS is a signal from PC-to-F5529 and goes to P1.7 so it's interrupt-capable, RTS is a signal from F5529-to-PC and is connected to P6.7.  The documentation for the FET expects you to use these lines for handshaking when you use UART speeds over 200Kbps I believe.
 
4. I do love the new documentation sheet; it's colorful and way more explanatory than the others I've seen.  Rei Vilo's energia pinout diagrams inspired this BTW.
 
5. Those stackable wire-wrap headers are a pain in the ass.  I couldn't get my Nokia 1202 boosterpack working with this (very flaky problems, including flickering in the backlight) until I bolstered the thickness of the pins with some flux+solder.  Stellaris & Tiva-C LP has the same problem though.
 
6. There is a nasty glitch that TI should fix ASAP (and they do know about it), preferably with a back-fix for existing boards.  The TUSB hub chip holds the reigns on a couple power switch ICs that let 5V pass through to the eZFET and to the F5529's nets.  If there is no real PC on the other end of the USB connection, the TUSB chip never switches the power on.  So you HAVE to have this board plugged into a PC to power it up using the built-in USB port.  Maybe I'm overblowing this one but it's a basic feature we've been able to take for granted on pretty much every dev board on the market... in a pinch you can always plug your project into a USB cellphone charger or battery power brick, but not with this board.
 
I suppose one could argue that with real low-power requirements, nobody's using that USB port anyway.  However I'm not sure, seeing as they used a high-efficiency DC-DC converter for the 3.3V rail and I'm betting that F5528 eZFET chip goes into LPM4 if it has nothing else to do. But still, USB and ULP don't usually go hand-in-hand.
 
7. Board comes with a cool little USB demo, pushbuttons act like keyboard output and you can browse the contents of a USB mass storage device that shows up.  Reinforcing the urgency behind #6, I think a typical use-case for this board will be sensor sampling "in the field" that you can transfer easily to a PC using a USB mass-storage + CSV output generator feature in the firmware.  Or maybe WiFi config or other RF config can be done using easy text files that get dumped onto the USB mass-storage drive.
 
8. @@pabigot 's MSPGCC 4.7.0 release, his last one, supports the >64KB address space on this chip using -mmemory-model=large or -mmemory-model=huge.  I've tested this out
 
9. The RAM is actually 10K; 8KB + 2KB USB RAM that can be used for general purposes if the USB subsystem isn't switched on.  Linker scripts have to be adjusted to use that extra 2KB, but what's funny is in my copy of the msp430mcu files (headers + linker scripts) that Peter released, looking in the msp430f5529 directory there is a "nousb" dir with an alternative memory.x linker script file:
total 40 drwxr-sr-x@ 6 ebrundic staff 204 Sep 4 12:34 . drwxr-xr-x@ 440 ebrundic staff 14960 Jul 1 12:06 .. -rw-r--r--@ 1 ebrundic staff 1770 Sep 4 12:48 memory.x drwxr-sr-x@ 3 ebrundic staff 102 Jul 1 12:06 nousb -rw-r--r--@ 1 ebrundic staff 15817 Mar 21 21:07 periph.x wmmit032091:msp430f5529 ebrundic$ ls -l nousb/ total 8 -rw-r--r--@ 1 ebrundic staff 1770 Mar 21 21:07 memory.x Saving the original memory.x somewhere and copying nousb/memory.x into the main (msp430f5529/memory.x) file, it gives me access to that extra 2KB.
USB version:
MEMORY { sfr : ORIGIN = 0x0000, LENGTH = 0x0010 /* END=0x0010, size 16 */ peripheral_8bit : ORIGIN = 0x0010, LENGTH = 0x00f0 /* END=0x0100, size 240 */ peripheral_16bit : ORIGIN = 0x0100, LENGTH = 0x0100 /* END=0x0200, size 256 */ bsl : ORIGIN = 0x1000, LENGTH = 0x0800 /* END=0x1800, size 2K as 4 512-byte segments */ infomem : ORIGIN = 0x1800, LENGTH = 0x0200 /* END=0x1a00, size 512 as 4 128-byte segments */ infod : ORIGIN = 0x1800, LENGTH = 0x0080 /* END=0x1880, size 128 */ infoc : ORIGIN = 0x1880, LENGTH = 0x0080 /* END=0x1900, size 128 */ infob : ORIGIN = 0x1900, LENGTH = 0x0080 /* END=0x1980, size 128 */ infoa : ORIGIN = 0x1980, LENGTH = 0x0080 /* END=0x1a00, size 128 */ usbram (wx) : ORIGIN = 0x1c00, LENGTH = 0x0800 /* END=0x2400, size 2K */ ram (wx) : ORIGIN = 0x2400, LENGTH = 0x2000 /* END=0x4400, size 8K */ rom (rx) : ORIGIN = 0x4400, LENGTH = 0xbb80 /* END=0xff80, size 48000 */ vectors : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000, size 128 as 64 2-byte segments */ far_rom : ORIGIN = 0x00010000, LENGTH = 0x00014400 /* END=0x00024400, size 81K */ /* Remaining banks are absent */ ram2 (wx) : ORIGIN = 0x0000, LENGTH = 0x0000 ram_mirror (wx) : ORIGIN = 0x0000, LENGTH = 0x0000 signature : ORIGIN = 0x0000, LENGTH = 0x0000 } REGION_ALIAS("REGION_TEXT", rom); REGION_ALIAS("REGION_DATA", ram); REGION_ALIAS("REGION_FAR_ROM", far_rom); /* Legacy name, no longer used */ REGION_ALIAS("REGION_FAR_TEXT", far_rom); REGION_ALIAS("REGION_FAR_DATA", ram2); PROVIDE (__info_segment_size = 0x80); PROVIDE (__infod = 0x1800); PROVIDE (__infoc = 0x1880); PROVIDE (__infob = 0x1900); PROVIDE (__infoa = 0x1980); Nousb version:
MEMORY { sfr : ORIGIN = 0x0000, LENGTH = 0x0010 /* END=0x0010, size 16 */ peripheral_8bit : ORIGIN = 0x0010, LENGTH = 0x00f0 /* END=0x0100, size 240 */ peripheral_16bit : ORIGIN = 0x0100, LENGTH = 0x0100 /* END=0x0200, size 256 */ bsl : ORIGIN = 0x1000, LENGTH = 0x0800 /* END=0x1800, size 2K as 4 512-byte segments */ infomem : ORIGIN = 0x1800, LENGTH = 0x0200 /* END=0x1a00, size 512 as 4 128-byte segments */ infod : ORIGIN = 0x1800, LENGTH = 0x0080 /* END=0x1880, size 128 */ infoc : ORIGIN = 0x1880, LENGTH = 0x0080 /* END=0x1900, size 128 */ infob : ORIGIN = 0x1900, LENGTH = 0x0080 /* END=0x1980, size 128 */ infoa : ORIGIN = 0x1980, LENGTH = 0x0080 /* END=0x1a00, size 128 */ ram (wx) : ORIGIN = 0x1c00, LENGTH = 0x2800 /* END=0x4400, size 10K */ rom (rx) : ORIGIN = 0x4400, LENGTH = 0xbb80 /* END=0xff80, size 48000 */ vectors : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000, size 128 as 64 2-byte segments */ far_rom : ORIGIN = 0x00010000, LENGTH = 0x00014400 /* END=0x00024400, size 81K */ /* Remaining banks are absent */ ram2 (wx) : ORIGIN = 0x0000, LENGTH = 0x0000 ram_mirror (wx) : ORIGIN = 0x0000, LENGTH = 0x0000 signature : ORIGIN = 0x0000, LENGTH = 0x0000 usbram (wx) : ORIGIN = 0x0000, LENGTH = 0x0000 } REGION_ALIAS("REGION_TEXT", rom); REGION_ALIAS("REGION_DATA", ram); REGION_ALIAS("REGION_FAR_ROM", far_rom); /* Legacy name, no longer used */ REGION_ALIAS("REGION_FAR_TEXT", far_rom); REGION_ALIAS("REGION_FAR_DATA", ram2); PROVIDE (__info_segment_size = 0x80); PROVIDE (__infod = 0x1800); PROVIDE (__infoc = 0x1880); PROVIDE (__infob = 0x1900); PROVIDE (__infoa = 0x1980); Not sure if there's an option to msp430-gcc that can force you to use the nousb/memory.x without manually overwriting the main memory.x file, I haven't figured it out yet.
 
10. The UART includes USCI_A0 on the boosterpack headers, and USCI_A1 connects to the backchannel UART.  So now you can have your cake & eat it too... a GPS boosterpack installed without interfering with your ability to play with backchannel UART comms.  Assuming you don't decide to whip out a USB serial link natively inside the chip, that is.
 
11. CCS still has a 16K flash code limit, but the idea seems to be that CCSv6 will contain the new RedHat GCC port added as an "unlimited code size" option.  It'll be interesting to see how this works out with the USB developer's package and MSP430Ware stuff that TI already has released for this chip.
 
12. Remember, F5xxx series have relatively long wakeup times in LPM3/LPM4 when the SVM is enabled I believe.  @@pabigot had a thread about this I think.
 
13. XT1 and XT2 are both soldered, XT2 has a 4MHz crystal (for accurate USB) and XT1 has your standard 32.768KHz XTAL.  Initializing an F5xxx series chip is substantially different from the value-line parts as to use the DCO you have to enable an FLL loop that "calibrates" the DCO.  I wrote a basic library to do this: https://github.com/spirilis/ucs_clockinit
 
Cool advantage of this, you can easily overclock the MSP430.  Past experiments with the MSP430F5172 taught me that it can run up to ~56MHz doing a very basic LED blink with __delay_cycles() before it started crashing :grin:

MSP430F5259 found in the new Motorola Moto X
http://www.ifixit.com/Teardown/Motorola+Moto+X+Teardown/16867/2 (step 15)
 
There's also a beefy TI C5000 DSP involved.

Do you try to get the integer values of these strings?
"5","4","3","2","1"
 
If so, the function you're looking for is atoi (ascii to integer).
secLevel = atoi(myArray[2]);
 
However, as long as we're talking about a single digit, you can also use
secLevel = myarray[2][i][0]
Note that [0] accesses the first character of the string stored at [2].
 
Subtract 0x30 (or '0') if you want to have an integer from 0-9, but the switch statement can handle character too ('0' is a character, "0" is a string).

It has indeed been a long time since we have done a release. Although not officially announced yet (shhhhhh..), there is a release planned for Sep 12. So please hang in there for a couple more weeks.

Here we go, the first offer is online:
http://e2e.ti.com/blogs_/b/msp430blog/archive/2013/08/19/back-to-school-sale.aspx
Launchpad for $6.99 ("while supplies last" - is an update coming?)

fyi- Rick posted this link in #43oh IRC yesterday, something to look at when migrating from Stellaris to Tiva.
 
http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=spma050a&fileType=pdf
Migrating Software Projects from StellarisWare® to TivaWare™

I had a 128x64 Noritake VFD display at work, which is currently not being used. Did an extensive search for a driver until I found one by Henri Skippari. Code was ported from a a PIC16F877. Took a couple of hours for me to port and wire it up.
 
Below is the code which will need stellarisware.
/* * Noritake VFD 800B 128x64 Parallel Interface * Code courtesy : http://www.sourceboost.com/Products/C2C-plus/ExampleCode/noritake/noritake.c.html * Original author : Henri Skippari * Ported to Stellaris Launchpad : Gerard S, 12th August, 2013 */ #include "inc/hw_memmap.h" #include "inc/hw_types.h" #include "inc/hw_gpio.h" #include "driverlib/gpio.h" #include "driverlib/pin_map.h" #include "driverlib/sysctl.h" #include "driverlib/systick.h" #include "driverlib/gpio.h" #include "driverlib/sysctl.h" #include "utils/uartstdio.h" #include "utils/ustdlib.h" #define LAYER0_ON 1 #define LAYER0_OFF 0 #define LAYER1_ON 1 #define LAYER1_OFF 0 #define DISPLAY_ON 1 #define DISPLAY_OFF 0 #define REVERSE_ON 1 #define REVERSE_OFF 0 #define MODE_AND 0 #define MODE_EXOR 1 #define MODE_OR 2 #define VERTICAL_ON 1 #define VERTICAL_OFF 0 #define HORIZONTAL_ON 1 #define HORIZONTAL_OFF 0 #define D7 0x80 #define D6 0x40 #define D5 0x20 #define D4 0x10 #define D3 0x08 #define D2 0x04 #define D1 0x02 #define D0 0x01 #define VFD_CONTROL_PERIPH SYSCTL_PERIPH_GPIOA #define VFD_CONTROL_BASE GPIO_PORTA_BASE #define VFD_WR GPIO_PIN_2 #define VFD_CD GPIO_PIN_3 #define VFD_RD GPIO_PIN_4 #define VFD_CSS GPIO_PIN_5 #define VFD_WR_HI HWREG(VFD_CONTROL_BASE + GPIO_O_DATA + (VFD_WR << 2)) = VFD_WR #define VFD_WR_LO HWREG(VFD_CONTROL_BASE + GPIO_O_DATA + (VFD_WR << 2)) = 0 #define VFD_CD_HI HWREG(VFD_CONTROL_BASE + GPIO_O_DATA + (VFD_CD << 2)) = VFD_CD #define VFD_CD_LO HWREG(VFD_CONTROL_BASE + GPIO_O_DATA + (VFD_CD << 2)) = 0 #define VFD_RD_HI HWREG(VFD_CONTROL_BASE + GPIO_O_DATA + (VFD_RD << 2)) = VFD_RD #define VFD_RD_LO HWREG(VFD_CONTROL_BASE + GPIO_O_DATA + (VFD_RD << 2)) = 0 #define VFD_CSS_HI HWREG(VFD_CONTROL_BASE + GPIO_O_DATA + (VFD_CSS << 2)) = VFD_CSS #define VFD_CSS_LO HWREG(VFD_CONTROL_BASE + GPIO_O_DATA + (VFD_CSS << 2)) = 0 #define VFD_DATA_PERIPH SYSCTL_PERIPH_GPIOB #define VFD_DATA_BASE GPIO_PORTB_BASE #define VFD_DATA GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3 | \ GPIO_PIN_4 | GPIO_PIN_5 | GPIO_PIN_6 | GPIO_PIN_7 | // Fonts, first part const unsigned char font5x7[]={ 0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0xF2,0x00,0x00, 0x00,0xC0,0x00,0xC0,0x00, 0x28,0xFE,0x28,0xFE,0x28, 0x24,0x54,0xFE,0x54,0x48, 0xC4,0xC8,0x10,0x26,0x46, 0x6C,0x92,0x9A,0x64,0x0A, 0x00,0xA0,0xC0,0x00,0x00, 0x00,0x38,0x44,0x82,0x00, 0x00,0x82,0x44,0x38,0x00, 0x28,0x10,0x7C,0x10,0x28, 0x10,0x10,0x7C,0x10,0x10, 0x0A,0x0C,0x00,0x00,0x00, 0x10,0x10,0x10,0x10,0x10, 0x06,0x06,0x00,0x00,0x00, 0x04,0x08,0x10,0x20,0x40, 0x7C,0x8A,0x92,0xA2,0x7C, 0x00,0x42,0xFE,0x02,0x00, 0x42,0x86,0x8A,0x92,0x62, 0x84,0x82,0xA2,0xD2,0x8C, 0x18,0x28,0x48,0xFE,0x08, 0xE4,0xA2,0xA2,0xA2,0x9C, 0x3C,0x52,0x92,0x92,0x0C, 0x80,0x8E,0x90,0xA0,0xC0, 0x6C,0x92,0x92,0x92,0x6C, 0x60,0x92,0x92,0x94,0x78, 0x00,0x6C,0x6C,0x00,0x00, 0x00,0x6A,0x6C,0x00,0x00, 0x10,0x28,0x44,0x82,0x00, 0x28,0x28,0x28,0x28,0x28, 0x00,0x82,0x44,0x28,0x10, 0x40,0x80,0x8A,0x90,0x60, 0x4C,0x92,0x9E,0x82,0x7C, 0x3E,0x48,0x88,0x48,0x3E, 0xFE,0x92,0x92,0x92,0x6C, 0x7C,0x82,0x82,0x82,0x44, 0xFE,0x82,0x82,0x44,0x38, 0xFE,0x92,0x92,0x82,0x82, 0xFE,0x90,0x90,0x90,0x80, 0x7C,0x82,0x92,0x92,0x5C, 0xFE,0x10,0x10,0x10,0xFE, 0x00,0x82,0xFE,0x82,0x00, 0x04,0x02,0x82,0xFC,0x80, 0xFE,0x10,0x28,0x44,0x82, 0xFE,0x02,0x02,0x02,0x02, 0xFE,0x40,0x20,0x40,0xFE, 0xFE,0x20,0x10,0x08,0xFE, 0x7C,0x82,0x82,0x82,0x7C, 0xFE,0x90,0x90,0x90,0x60, 0x7C,0x82,0x8A,0x84,0x7A, 0xFE,0x90,0x98,0x94,0x62 // 50 }; // Fonts, second part const unsigned char font5x7_2[]={ 0x64,0x92,0x92,0x92,0x4C, 0x80,0x80,0xFE,0x80,0x80, 0xFC,0x02,0x02,0x02,0xFC, 0xF8,0x04,0x02,0x04,0xF8, 0xFC,0x02,0x0C,0x02,0xFC, 0xC6,0x28,0x10,0x28,0xC6, 0xE0,0x10,0x0E,0x10,0xE0, 0x86,0x8A,0x92,0xA2,0xC2, 0x00,0xFE,0x82,0x82,0x00, 0x40,0x20,0x10,0x08,0x04, 0x00,0x82,0x82,0xFE,0x00, 0x20,0x40,0x80,0x40,0x20, 0x02,0x02,0x02,0x02,0x02, 0x00,0x80,0x40,0x20,0x00, 0x04,0x2A,0x2A,0x2A,0x1E, 0xFE,0x12,0x12,0x12,0x0C, 0x1C,0x22,0x22,0x22,0x22, 0x0C,0x12,0x12,0x12,0xFE, 0x1C,0x2A,0x2A,0x2A,0x1A, 0x10,0x7E,0x90,0x40,0x00, 0x12,0x2A,0x2A,0x2A,0x3C, 0xFE,0x10,0x10,0x10,0x0E, 0x00,0x00,0x5E,0x00,0x00, 0x04,0x02,0x02,0xBC,0x00, 0xFE,0x08,0x14,0x22,0x00, 0x00,0x82,0xFE,0x02,0x00, 0x3E,0x20,0x18,0x20,0x3E, 0x3E,0x10,0x20,0x20,0x1E, 0x1C,0x22,0x22,0x22,0x1C, 0x3E,0x28,0x28,0x28,0x10, 0x10,0x28,0x28,0x28,0x3E, 0x3E,0x10,0x20,0x20,0x10, 0x12,0x2A,0x2A,0x2A,0x24, 0x20,0xFC,0x22,0x04,0x00, 0x3C,0x02,0x02,0x02,0x3C, 0x38,0x04,0x02,0x04,0x38, 0x3C,0x02,0x0C,0x02,0x3C, 0x22,0x14,0x08,0x14,0x22, 0x20,0x12,0x0C,0x10,0x20, 0x22,0x26,0x2A,0x32,0x22, 0x10,0x6C,0x82,0x82,0x00, 0x12,0x7E,0x92,0x82,0x42, 0x00,0x82,0x82,0x6C,0x10, 0x80,0x80,0x80,0x80,0x80, 0xFE,0xFE,0xFE,0xFE,0xFE}; // 44 /* Write data byte */ void VFD_WriteData(unsigned char data) { VFD_CD_LO; VFD_WR_LO; VFD_RD_HI; VFD_CSS_LO; GPIOPinWrite( VFD_DATA_BASE, 0xFF, data); VFD_CD_LO; VFD_WR_HI; VFD_RD_HI; VFD_CSS_LO; } /* Write command byte */ void VFD_WriteCtrl(unsigned char command) { VFD_CD_HI; VFD_WR_LO; VFD_RD_HI; VFD_CSS_LO; GPIOPinWrite( VFD_DATA_BASE, 0xFF, command); VFD_CD_HI; VFD_WR_HI; VFD_RD_HI; VFD_CSS_LO; } /* Horizontal and vertical address auto increment on/off */ void VFD_AddressIncrementMode(unsigned char h, unsigned char v) { unsigned char bit2=0, bit1=0; if(h==HORIZONTAL_ON) bit2 = 0x04; if(v==VERTICAL_ON) bit1 = 0x02; VFD_WriteCtrl(0x80+bit2+bit1); } void VFD_SetColumn(unsigned char column) { VFD_WriteCtrl(0x64); VFD_WriteCtrl(column); } void VFD_SetRow(unsigned char row) { VFD_WriteCtrl(0x60); VFD_WriteCtrl(row); } /* Display brightness 0-15 */ void VFD_SetBrightness(unsigned char brightness) { if(brightness>15) brightness=15; // Check for too big values if(brightness<0) brightness=0; // Check for too small values VFD_WriteCtrl(0x40+(0x0F-brightness)); // Delay for 100ms SysCtlDelay( (SysCtlClockGet()/(3*1000))*1 ); } void VFD_ClearDisplay(void) { VFD_WriteCtrl(0x5f); SysCtlDelay( (SysCtlClockGet()/(3*1000))*1 ); } /* Set layers on/off + other display attributes */ void VFD_DisplaySetup(char layer0, char layer1, char gfx_on_off, char reverse, char mode) { unsigned char l0=0, l1=0, gs=0, grv=0, and=0, exor=0; if(layer0==LAYER0_ON) l0 = D2; if(layer1==LAYER1_ON) l1 = D3; VFD_WriteCtrl(0x20+l0+l1); if(gfx_on_off==DISPLAY_ON) gs = D6; if(reverse==REVERSE_ON) grv = D4; if(mode==MODE_AND) and = D3; if(mode==MODE_EXOR) exor = D2; if(mode==MODE_OR) { } VFD_WriteCtrl(gs+grv+and+exor); } unsigned char swap(unsigned char x) { unsigned char result=0,mask1=1,mask2=128; int b; for(b=0;b<8;b++) { if ((x&mask1)==mask1) result=result+mask2; mask1=mask1<<1; mask2=mask2>>1; } return(result); } void VFD_PrintChar(unsigned char chr) { unsigned char data, i; VFD_AddressIncrementMode(HORIZONTAL_ON, VERTICAL_OFF); // Horizontal auto increment ON for font writing chr=chr-0x20; // Convert ascii code to Noritake code if(chr<51) // First font array { for(i=0;i<5;i++) { data = font5x7[chr*5+i]; data = swap(data); VFD_WriteData(data); } VFD_WriteData(0); } else if(chr<96) // Second font array { chr = chr-51; for(i=0;i<5;i++) { data = font5x7_2[chr*5+i]; data = swap(data); VFD_WriteData(data); } VFD_WriteData(0); } } void VFD_Init( void ) { unsigned char i; SysCtlPeripheralEnable(VFD_CONTROL_PERIPH); GPIOPinTypeGPIOOutput(VFD_CONTROL_BASE, VFD_WR | \ VFD_CD | \ VFD_RD | \ VFD_CSS); SysCtlPeripheralEnable(VFD_DATA_PERIPH); GPIOPinTypeGPIOOutput(VFD_DATA_BASE, 0xFF); for(i=0;i<8;i++) { // address area set VFD_WriteCtrl(0x62); VFD_WriteCtrl(i); VFD_WriteData(0xff); } VFD_AddressIncrementMode(HORIZONTAL_ON, VERTICAL_OFF); // Default to horizontal address increment ON VFD_SetColumn(0); // Set address pointer to (0,0) VFD_SetRow(0); // Set address pointer to (0,0) VFD_SetBrightness(0); // Set brightness to lowest possible VFD_DisplaySetup(LAYER0_OFF, LAYER1_OFF, DISPLAY_OFF, REVERSE_OFF, MODE_AND); // Set everything OFF VFD_ClearDisplay(); } /* Draw vertical bar. Used in the sample.*/ void DrawVertBar(unsigned char height, unsigned char pos) { unsigned char i; VFD_AddressIncrementMode(HORIZONTAL_OFF, VERTICAL_ON); // Vertical bars are drawn so vertical auto increment is enabled VFD_SetColumn(pos); VFD_SetRow(7-height); for(i=7-height;i<8;i++) { VFD_WriteData(254); // Draw vertical byte with one bit off: oxxxxxxx // Address pointer is incremented vertically after every byte written } } int main(void) { int i, j, c; // Setup the processor clock at 80Mhz. SysCtlClockSet( SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | \ SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ); // Enable UART0 @115200bps N81. SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA); GPIOPinConfigure(GPIO_PA0_U0RX); GPIOPinConfigure(GPIO_PA1_U0TX); GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1); UARTStdioInit(0); //Clear the terminal UARTprintf("\033[2J"); UARTprintf("\n\nNoritake VFD 800b test\n"); UARTprintf("-----------------------------------\n"); // Arrays to store height and current direction for moving bars unsigned char value[16]; // Height of bar, 0 to 8 unsigned char dir[16]; // 1=up, 0=down // Initialize values for bars for(i=0;i<8;i++) { value[i]=i; // 8 bars with values from 0 to 7 dir[i]=1; // Going up value[8+i]=(8-i); // 8 bars with values from 8 to 1 dir[8+i]=0; // Going down } VFD_Init(); VFD_DisplaySetup(LAYER0_ON, LAYER1_ON, DISPLAY_ON, REVERSE_OFF, MODE_OR); VFD_SetBrightness(15); // Set brightness to maximum // Write all available fonts to display // Change row after 20 characters c=32; for(i=0;i<5;i++) { VFD_SetColumn(0); VFD_SetRow(8+i); // Start from the beginning of second layer for(j=0;j<20;j++) { VFD_PrintChar(c++); } } SysCtlDelay( (SysCtlClockGet()/(3*1000))*1000 ); while( 1 ) { // Draw some moving bars on the display for(i=0;i<16;i++) { for(j=0;j<8;j++) { DrawVertBar(value[i], i*8); } if(value[i]>=8) dir[i]=0; else if(value[i]<=0) dir[i]=1; if(dir[i]==0) value[i]=value[i]-1; else if(dir[i]==1) value[i]=value[i]+1; } SysCtlDelay( (SysCtlClockGet()/(3*1000))*50 ); VFD_ClearDisplay(); } return 0; }

IMHO, a more regular update of the binary release packages would be great.
 
Especially for beginners it can be very frustrating to 1) spend hours figuring out that it's not their fault when I2C does not work, and then having to master the hurdles of 2) learning about github, 3) setting up a local build system, including 4) a detour to the Arduino site for complete build instructions and then 5) (at least for Windows) copy missing files into the right directories, just to 6) find out that the library they copied from Adafruit won't work without rewriting some low-level optimizations. At that point most will have discarded MSP430 and Tiva as being too complicated for them and gone back to Arduino.
 
Aside from this, a more regular schedule might also motivate more advanced community members to contribute on a more regular basis - be it bug fixes, optimizations or new libraries.
 
PS: I'm happy to help out as code monkey and Windows tester

VCC like the voltage?
 
There's no way to control this in Energia (or any other way of programming). If you are looking for a way to connect peripherals at other voltages than what the MSP430 runs on (approx. 3V), you'll need to use level convertors:
 
Theory:
http://www.ti.com/lit/an/slaa148/slaa148.pdf
 
Or buy/build something like these:
https://www.sparkfun.com/products/8745
http://www.adafruit.com/products/757

Thank you for asking.
 
Personally, 43Oh store discounts won't make a difference to me. Compared to other hobbies, tinkering with LaunchPads is already pretty cheap
 
How about convincing TI (and other vendors) to give evaluation boards for new ICs to proven library developers, with the explicit goal to publish an Energia library for it?
 
I envision a program similar to the Dangerous Prototypes Free PCB drawer:
1) Qualify for the program by publishing an Energia library
2) Get a free chip/breakout/evaluation kit
3) Publish Energia library for it
4) Rinse and repeat
 
A similar cycle could work for Booster Packs.

Thank you for asking.
 
Personally, 43Oh store discounts won't make a difference to me. Compared to other hobbies, tinkering with LaunchPads is already pretty cheap
 
How about convincing TI (and other vendors) to give evaluation boards for new ICs to proven library developers, with the explicit goal to publish an Energia library for it?
 
I envision a program similar to the Dangerous Prototypes Free PCB drawer:
1) Qualify for the program by publishing an Energia library
2) Get a free chip/breakout/evaluation kit
3) Publish Energia library for it
4) Rinse and repeat
 
A similar cycle could work for Booster Packs.

Thank you for asking.
 
Personally, 43Oh store discounts won't make a difference to me. Compared to other hobbies, tinkering with LaunchPads is already pretty cheap
 
How about convincing TI (and other vendors) to give evaluation boards for new ICs to proven library developers, with the explicit goal to publish an Energia library for it?
 
I envision a program similar to the Dangerous Prototypes Free PCB drawer:
1) Qualify for the program by publishing an Energia library
2) Get a free chip/breakout/evaluation kit
3) Publish Energia library for it
4) Rinse and repeat
 
A similar cycle could work for Booster Packs.

Thank you for asking.
 
Personally, 43Oh store discounts won't make a difference to me. Compared to other hobbies, tinkering with LaunchPads is already pretty cheap
 
How about convincing TI (and other vendors) to give evaluation boards for new ICs to proven library developers, with the explicit goal to publish an Energia library for it?
 
I envision a program similar to the Dangerous Prototypes Free PCB drawer:
1) Qualify for the program by publishing an Energia library
2) Get a free chip/breakout/evaluation kit
3) Publish Energia library for it
4) Rinse and repeat
 
A similar cycle could work for Booster Packs.

Thank you for asking.
 
Personally, 43Oh store discounts won't make a difference to me. Compared to other hobbies, tinkering with LaunchPads is already pretty cheap
 
How about convincing TI (and other vendors) to give evaluation boards for new ICs to proven library developers, with the explicit goal to publish an Energia library for it?
 
I envision a program similar to the Dangerous Prototypes Free PCB drawer:
1) Qualify for the program by publishing an Energia library
2) Get a free chip/breakout/evaluation kit
3) Publish Energia library for it
4) Rinse and repeat
 
A similar cycle could work for Booster Packs.

TI today announced two new LaunchPads for their Hercules line of MCUs:
http://newscenter.ti.com/2013-07-24-Texas-Instruments-introduces-Hercules-LaunchPad-enabling-designers-to-evaluate-TIs-Hercules-MCUs-safety-features-for-less-than-20
 
Hercules MCU (Dual core ARM Cortex R4), running at 80/100MHz, 384KB flash, 32KB RAM
http://www.ti.com/ww/en/launchpad/hercules.html
 
$20 apiece seems a good deal, given that even the USB stick dev boards for these chips cost $79.
 

I think the dual cores are meant to run in lock-step, for redundancy & accuracy-checking purposes.  Also has ECC (error correction) for its flash & SRAM.  Probably massive overkill for the vast majority of applications but when you want that extra bit of assurance that your MCU application will WORK, (basically) no matter what (firmware bugs notwithstanding)... sounds like this is a good choice for the job.  Design an electric car's control systems around something like this.  It adds extra measures to help dial out hardware externality-induced failure modes.  I think the temperature tolerances are wider too, so this is immediately useful for extreme temperature applications.
 
I'm guessing not too many hobbyists will have immediate uses for these features, but if anyone does it will make for a very fascinating hackaday article
 
If Iron Man used a TI microcontroller for his suit, this would probably be it....

@@cde @@simpleavr re differences
 
More RAM (12-32KB vs. 32-256KB), more flash (32KB-256KB vs. 256KB-3MB), more speed (80 vs. 80-220MHz, single vs. dual core)
http://www.ti.com/lsds/ti/arm/overview.page
 
But I guess the big differentiator is compliance with various industry, medical, automotive standards (not really relevant to hobbyists).

TI today announced two new LaunchPads for their Hercules line of MCUs:
http://newscenter.ti.com/2013-07-24-Texas-Instruments-introduces-Hercules-LaunchPad-enabling-designers-to-evaluate-TIs-Hercules-MCUs-safety-features-for-less-than-20
 
Hercules MCU (Dual core ARM Cortex R4), running at 80/100MHz, 384KB flash, 32KB RAM
http://www.ti.com/ww/en/launchpad/hercules.html
 
$20 apiece seems a good deal, given that even the USB stick dev boards for these chips cost $79.
 

TI today announced two new LaunchPads for their Hercules line of MCUs:
http://newscenter.ti.com/2013-07-24-Texas-Instruments-introduces-Hercules-LaunchPad-enabling-designers-to-evaluate-TIs-Hercules-MCUs-safety-features-for-less-than-20
 
Hercules MCU (Dual core ARM Cortex R4), running at 80/100MHz, 384KB flash, 32KB RAM
http://www.ti.com/ww/en/launchpad/hercules.html
 
$20 apiece seems a good deal, given that even the USB stick dev boards for these chips cost $79.
 

Until then, try using ' spi' or ' i2c' as a workaround

It's here! Precious!
 

 
The Tiva Launchpad is virtually identical with the Stellaris Launchpad, with the exception of the (IMO crappier) silkscreen and the chips:
 

 
The Tiva chip marking says XM4C123GH6PMI6 vs. the official TM4C123GH6PM designation, so I suspect that this is still preview silicon.
 
[edit] There is a difference: U4 and D2 (voltage regulator?) are not populated.
[edit2] Nope, according to the Stellaris Launchpad manual that was reset circuitry

I haven't looked at the library beyond the description of what it does.
 
One other option - look around and see if you can find other libraries that do what you want, and adapt/adopt them.
 
The description of the libraries you are interested in list 3 main function areas.
 
1) Read SD and SDHC cards
2) Read FAT16 and FAT32 volumes (file information, file content)
3) Play WAV files
 
There are various libraries for reading FAT,
e.g. Petit FATFS, which has been ported to Energia
http://forum.43oh.com/topic/3209-energia-library-petit-fatfs-sd-card-library/
 
If you need more function there is also the FatFS
http://elm-chan.org/fsw/ff/00index_e.html
 
For reading SD cards, there is example code for some of the Stellaris controllers
(e.g. the LM3s8962 has an SD card slot on the evaluation board).  
Some of the FAT ports may also have example code for doing this.
 
For playing wave files - there are various projects out there where people have used Stellaris controllers to play wav files.  
I didn't see much code, except for a sample from TI for the evalbot, but I didn't look very far.
 
If I am going to roll my own library I like to grab several examples of what is out there already.
If I find one that does what I want, it saves me writing my own.  
If I don't, then I have a better basis of comparison for making my own library, so I can be sure it is better than what is out there.  
(If you are going to reinvent the wheel, should make sure yours is rounder than anybody else's.)
 
 

http://xkcd.com/927/
(The cartoon is about standards, but works just as well for libraries.)

Not sure if that's the real issue, but your test code declares string as a single character. Also the parameter buffer, presumably indicating the length of the receiving string-buffer, is ignored in your read function.
 
Try
 
char string[BUFFER_LEN];  
Also the for loop in the read function uses an odd end condition. I'd check I against BUFFER_LEN too. i.e.
 
for (i = 0; i < BUFFER_LEN; i++)  
Or, respecting the target buffer length
 
for (i = 0; i < BUFFER_LEN && i < buffer; i++)

For Stellaris (untested - you might need some type casting to make the compiler happy as GPIO registers are 32bit)
 

uint8_t value = 2; GPIO_PORTB_DATA_R = value; value = GPIO_PORTB_DATA_R;  The register for direction is GPIO_PORTB_DIR_R. The include file lm4f120h5qr.h defines all the registers.