chicken

Looking at the port schematic in the datasheet, you can see that PxIN.y (i.e. bit y of port x) is directly connected to the pad (via a buffer).
 
So I think by design P1IN always reflects the physical state of the pins, even for pins configured as output. However, changing the state of a pin via P1OUT is only possible when that pin is configured as output.

Interesting. Not sure what's 3D about it though, looks pretty 2D to me.. I guess it helps the buzz :roll:

@@abecedarian From a quick glance at the source, Energia does only check whether USCI is present and then uses UCB0, which is wired to the same pins for G2553 and F5529. 4.2/4.1 would be UCB1.
 
IMO, this makes sense as it maintains backward compatibility with the MSP430 LaunchPad. Too bad the quick start guide does not reflect this.
 
Unlike for Stellaris/Tiva, the MSP430 implementation of Wire does not yet allow to set an alternative I2C module.
 
PS: On the Tiva LaunchPad, the pins in question are actually connected with 0-ohm resistors (R9/R10), which caused its own set of confusion

@@roadrunner84 I admire that you had a go at this
 
I think it helps the discussion to first agree on what terms like complexity, bloat, abstraction mean.
 
My personal definitions:
* complexity: what's the amount of knowledge and work required to achieve a given task
* abstraction layer: means to hide complexity from programmer, can be tools (Energia), languages (Forth), libraries..
* bloat: price paid in performance and/or effective code size to abstract complexity
 
From that perspective, Energia and Forth offer an abstraction layer to reduce the complexity of developing on MSP430 (including less complex code) at the price of an overall larger memory footprint (when including Energia core and Forth interpreter) and less powerful tools (e.g. no integrated debugger, no direct access to compiler options and output, cumbersome management of projects spanning many files, ..).
 
This is not good or bad, it's about horses for courses (and riders!).
 
So before the next poster starts bashing CCS, please consider that there are many like me, who find it a great and very productive IDE. Yes, even within the limits of the free version - so far I'm more concerned about running out of MSP430's scarce RAM than the 16K limit of the compiler.

Does it make sense to alternate Projects of the Month with the 43oh forum so both are not occurring concurrently? Many users work with both the MSP430 and Tiva and may not have time for projects on both at the same time. 

Replace the antenna with a wire dipole.  This will take some experimentation, but it's something you can do in an hour or so.
 
First, get two copper wires or rods that are 4cm long (each).  
 
Second, remove the antenna from your board.  It is probably a trace that you can scratch-off with a razor blade.  
 
Third, solder one wire to the feed point of the old antenna, and another to the ground plane closest to the feed point.  If you have a dremel with the grinder bit, use it on low-speed to take-off the solder mask.  Otherwise, you can scrape with a razor or use fine-grit sandpaper.
 
Four, build a dipole antenna 1cm away from your ground plane by extending the wires straight-out (in parallel) and then bending them into 180-degrees from each other.  It should look something like this image below, with 1cm feed and 6cm = lambda/2 (thanks, google images).

 
Five, it's not over yet.  Very likely, there is some capacitive coupling happening between your PCB and this antenna.  It is making the resonant frequency lower than 2450 MHz.  It is also reducing the impedance of the antenna from 74 Ohm to less... although I'm sort-of counting on that because the NRF module is undoubtedly tuned to 50 Ohms.  Start trimming the wires.  Trim both the same each iteration (try 2mm).  Now test the range with a normal NRF board and take notes.  At some point, the range will be longest, and this is where you're getting the best resonance.
 
Final note: position your wire dipole in a vertical orientation.  This will give it toroidal radiation about the Z axis, which will be the best for earthly pursuits.

For a monopole antenna, the resonant length is 0.25 * wavelength.  The frequency is 2450 MHz, so the wavelength is: c/f, where "c" is speed-of-light and f is Hz.  In other words, 300000000 / 2450000000 = wavelength in meters.
 
A normal monopole has impedance of 37 Ohms, which will match reasonably well with your board.  However, you need to trim the antenna more than wave/4 because there is always capacitance and inductance in non-ideal wires.  It is causing the actual wavelength to be shorter than the free-space wavelength.  The best way to get your tuning optimized in with a vector-network-analyzer (VNA).  If you don't have one (I can't imagine you do), you can do it experimentally as described above.
 
The dipole configuration described above is a balanced antenna, so it is more reliable than a monopole is.  Monopoles depend on the grounding of the device, dipoles do not.  If your board has a small ground plane or bad grounding, the monopole will have poor performance.  So, I usually recommend half-wave (i.e. dipole) antennas if possible.
 
If you want to get really clever, you could try to improve the tuning by constructing a monopole "inverted-F antenna" (IFA), but I would hold-off on that -- maybe a second project.

Well, it's up and running.  All the hardware seems to check out.  Display and accelerometer are playing nice on a shared spi bus.  The FR5738 RTC is keeping time.  LIS3DH initialized and generating interrupts properly.  Lots of programming to do now for the interface, calibrations, etc.

This electronic bike lock seems to use an MSP430:
http://www.kickstarter.com/projects/126495570/bitlock-turning-your-smart-phone-into-your-bike-ke
 
Can't tell from the images which MSP430 they are using, but there are two EZ430 and an MSP-FET430UIF shown in the "history" section

TI has provided many tutorials for getting started with CCS.  Finding one you understand can take a long time.  I think this one may be more helpful than some of the others: http://processors.wiki.ti.com/index.php/Blink_your_first_LED.  It covers installing CCS, creating a project, writing code, and programming the LP. I think it is simpler than the CCSv5 Getting Started Guide or the Getting Started with the MSP430 LaunchPad Workshop, so you may want to start there and go through the others after.
CCS provides the pin outs, register declarations, etc. in the header files that get included when you create the project (when you tell it which processor you are going to use).  You can use GRACE or MSP430Ware to initialize your program.  If you

Agreed, the workshops are more about getting started with MSP430 than getting started with coding and using a full-featured integrated development environment (IDE).
 
Having the C++ development background (mostly Microsoft Visual Studio) but knowing nothing about MSP430/Stellaris and very little about embedded development, I found these workshops very helpful.
 
Someone that's new to both should probably first try to take the training wheels of with Energia. E.g.
- realize that there's no such language as Arduino or Energia, so get that C/C++ book/tutorial and venture beyond setup() and loop().
- get up close to the hardware by accessing ports (easy) and peripherals (harder, particularly without debugger) without relying on Energia/Arduino libraries
- write your own libraries for MSP430 peripherals or some external chips/hardware
- when you're able to port some of the more AVR-optimized Arduino libraries to Energia, or manage to fix some of the still remaining bugs in core Energia libraries, you might be ready for the next step
 
After that try to migrate to GCC or CCS. Personally, I prefer the latter as I can't live without auto-complete and a fully integrated debugger and am not too fond of messing with make-files. But then I'm a lazy old Windows guy

You mean like the official Getting Started with the MSP430 LaunchPad Workshop?
http://processors.wiki.ti.com/index.php/Getting_Started_with_the_MSP430_LaunchPad_Workshop

PF1, PF2 and PF3 can already be used as is if you don't care about the flickering LED.
 
From the schematic in the Stellaris (and Tiva C) LaunchPad user manual (http://www.ti.com/lit/ug/spmu289b/spmu289b.pdf) the 0-Ohm resistors are R2, R11 and R12.

 
R3 through R5 on the right of the transistors are the current limiting resistors, so the transistors would still be driven by the MCU if you just remove these.
 

Picture (MSP430F2132) from http://e2e.ti.com
 

Yes.

I beg to differ; since not ALL the cases are identical (be it 1/2000 or 1/20,000,000,000), this shouldn't be the compiler's decision to make. The microcontroller is a logic device, not a statistical device... Where would you put the limit? is 1 in 5 "optimizable"? 1 in 100? and if it insists on optimizing, it should at least be consistent and optimize "i % 2000" as well. To make a long story short, what we have here is unpredictable compiler behavior and that can't be good.
 
Of course, the code I wrote is not too smart and I wouldn't use this technique in real development. But that's not the point.

In another thread @@Lyon posted a link to the web page of Jonathan Valvano.
http://users.ece.utexas.edu/~valvano/arm/

Turns out Valvano is quite a prolific author and published three books based on Stellaris/Tiva:

Embedded Systems: Introduction to Arm® Cortex-M Microcontrollers (Volume 1)

Embedded Systems: Real-Time Interfacing to Arm® Cortex-M Microcontrollers

Embedded Systems: Real-Time Operating Systems for Arm Cortex M Microcontrollers


Did anyone read one of these? If so, any feedback?

@@bluehash feel free to edit Amazon links to include affiliate ID

This tells the compiler to put the code following that #pragma into a specific section, which influences the location in memory where the linker will put it. See 5.10.4 in MSP430 Optimizing C/C++ Compiler User's Guide.
http://www.ti.com/litv/pdf/slau132g
 
Looking at the lnk*.cmd files in the project folder and *.map in the debug or release directory of the project might shed some more light on what's happening.
 
What's "somewhere" in your example?

Thanks for the write-up. How does the display look in real? Comparable to a Kindle?
 
What is PWM used for?
 
Re RAM requirements, there's a fork of RePaper/gratis on GitHub that supports partial screen updates reducing the memory footprint from almost 6K to as little as 33 bytes:
https://github.com/brodykenrick/gratis

Yes, I posted a full review some months ago...
 
Find it at http://embeddedcomputing.weebly.com/pervasive-display-e-paper-epd-extension-kit.html
 
But I didn't promote it because for technical reasons:
The screen needs external SRAM to store the picture before drawing it. Former MSP430G2553 didn't pack enough RAM But the new MSP430F5529 does! However, 
The BoosterPack requires PWM on pin 9 = P2_1 @ G2553 = P4_2 @ F5529.  Problem is, P4_2 @ F5529 doesn't feature PWM, so I need to simulate software PWM. Hence my call for Help! Software PWM for the MSP430F5529 

I wasn't aware of these epaper BoosterPacks by Pervasive Displays. Did anyone already play with these?
 
http://www.pervasivedisplays.com/kits/ext_kit
 

 

 
Seems to be identical with Adafruit's offering, at least as seen from the top
http://www.adafruit.com/category/63_150
 

Also available at Digikey, but Adafruit is approx. $5 cheaper.
 
PS: Not listed on TI's "official" BoosterPack list yet, someone nudging the right people please
 
 

HI,
 

Well, while it is possible to do such small program as you do for MSP430, you must take into account the major differences between MSP430 and Cortex-M4: the latest imposes some discipline in program writing. This is due to hardware realization of the inside circuitry of Cortex.    First flash location is at address 0 and in this location must reside the address of stack pointer, even if it is not used. The second location is the address of startup routine; this must be also present; at startup the processor uses these two locations and then goes further, so you must provide them. This address and the rest of interrupt vectors must have the last bit set to 1, making it odd number, despite even alignment - this last bit is internal signal for thumb interrupt - as requested by ARM. Note this is compiler's job, but directed by you.   Next, after these two locations, there must be the rest of interrupt vectors locations, properly initialized. You need these also - otherwise you will be soon in trouble, at the first mistake. You must know also this processor is provided with a unusual big and complex debug and diagnostic machine - so fault interrupts must be really initialized and a code body provided for them. So this is why in general, you must use two files for every small program (and Valvano is best to follow and learn from):  - one is a startup.S, which is written only once; - the other one is main.S which is your program.   I understand your pain - this is not so simple - and using IAR is an add-on, since no example - of coarse you must read/learn IAR documentation - however an example written in IAR assembler can be found in TIVA/boot_loader/bl_startup_ewarm.S - you can copy/paste from that file a lot...   Hope this will help you,

OK, I received it today. The bad news is that they appear to be Atmel focused. Though as you will see later, not so much Arduino focused.

The box includes:
1x VFD 128x32 1u graphic VFD.
1x simple wire harness connector (three wires for data and two for power and ground)
1x strip of 6 Male-Male headers to connect to a breadboard/arduino/etc.
1x spare male connector (but no pins )
1x piece blue acrylic filter designed for VFD displays
1x Quick setup pamphlet
1x Informational sheet detailing the acrylic filters

Now about the hardware. This thing is NICE! Puts any basic LCD I have played with to shame. It's very solidly built, feels very nice in the hand (not that this is important but still ), the soldering on it is clean. The device itself  is an integrated module which includes all the power circuitry and communications.  It can run off of just a 5V and ground. Plus, unlike many cheap ass LCD displays (which require D0-D7) this one only uses three digital lines.

If you plan on using it with an Arduino, download both the Arduino library and the file labeled:
"Arduino demo files from the video". The Arduino library appears to be generic for at least their GU-7000 series displays. There are a myriad of settings and which ones are important is not explained in the Quick Start pamphlet, let alone what they should be set to. To be honest the configuration section sucks. It tells you that an option should show up that they don't provide the files for. It's VERY VERY clear that this is their first Arduino rodeo. Most of the other stuff on their site is geared more towards AVR Studio, Atmel Studio or Linux. Basically, what I did was I imported the GU-7000 library (you won't get a GU-7003 option unlike what the pamphlet says). Then once that was imported, I used the demo files to play around.

As for the included libraries, unlike most which perform the bare minimum; namely, make the display work. These actually provide a good amount of function. They are clearly designed with making interface displays in mind. They provide easy integated features such as creating selectable "windows" of space, highlighting/inverting, scrolling text and graphics, etc. These "windows" of space allow you to dynamically transform that section more easily, without bothering the other areas in the display. Also, on their site they provide tools for creating the image code from bitmaps, jpgs,etc. If you use Atmel or AVR they provide tools for generating entire interfaces.

Hi,
A very useful site with example in asm programming is this: http://users.ece.utexas.edu/~valvano/arm/