1. Making the most of the Value Line MSP430 with the LaunchPad Explorer
Nov 17, 2015
Simply Embedded
Chris Karaplis & Kevin Strom
Hi and welcome to our unveiling of the LaunchPad Explorer board.
I’m Chris, and this is Kevin
Thanks for joining us
Before we begin, we would like to thank Blake and TI for hosting the webinar for us.
Please feel free to ask questions at any time during the presentation. We will have a Q&A at the end.

2. Overview Who we are and what is Simply Embedded
Value Line MSP430 and Launchpad ecosystem
LaunchPad Explorer: what is it and why did we make it
System overview / block diagram
Clock and timer configuration
Controlling 2 dual 7-segment displays using two shift registers
I2C/SPI with a single USCI_B module
ADC10 with analog front end
PWM based signal generator
General software and hardware considerations
Conclusion
Future improvements / possible features
Q & A
Today we’ll be introducing the Launchpad Explorer, it’s features and some of the technical challenges we faced and are facing in its development
So first off, who are these guys from Simply Embedded
Then we’ll give a brief overview of the MSP430 and LaunchPad Ecosystem
Next we move to why we created the LPEx
And give you a little more detail of what the LPEx looks like up close
We’ll go over some of the basic system configuration we created to accompany this project
After discussing configuration we’ll dive into the display subsystem design and function
Which leads naturally to an investigation into the use of I2C and SPI with a single USCI_B module
Switching gears away from pure digital, we’ll want to look a common requirement for an embedded system, the ADC
Reading input voltages is fun but, even better is generating waveforms using PWM
[We’re not going to lie, this is one of our favourite things about this project so far.]
For the last three points you can see we well will summarize what we have done, learned and how we might move the project forward
And of course Q&A

3. Who we are and what is Simply Embedded
Simply Embedded was founded in August 2014 as a free resource to help people learn about embedded programming
Many frameworks and environments have been developed to make embedded development easier but frequency at the cost of abstraction from the hardware
Simply Embedded’s tutorials are designed to a more complete picture
Chris: embedded software engineer
BSc EE, but began in industry as software designer with 5 years in industry
Experience in avionic communications, consumer electronics and cellular telecommunication equipment
Kevin: digital hardware engineer
BSc EE, 15 years in industry
Digital and Embedded hardware development in Network and Telecommunications, Medical/Consumer, and Industrial segments
Simply Embedded was founded in August 2014 as a free resource to help people learn about embedded programming
It started from our desire to create a resource that we desire from both the hardware and software perspective
In searching the web, we found there is plenty of material but it didn’t suit our needs
Over the last few years many frameworks and environments have been developed to make embedded development more approachable, but at the cost of abstraction from the hardware
Such frameworks provide a good starting point for a novice, but can limit the user’s understanding of the underlying hardware and also tends to preclude using it to the microcontroller’s maximum advantage. We’d like to point out that these frameworks also provide a good platform for rapid development by taking care of some details under the hood.
Simply Embedded’s tutorials are designed to dive deep down to the basics and really push the device to the limit
Following the tutorials allows the student to understand the nuts and bolts of embedded systems
Feel free to come and check us out, sign up for the newsletter if you like what you see.

4. MSP430 and LaunchPad ecosystem
The MSP430 is a 16-bit microcontroller
Low cost, low power but high value
Used in many different devices in a wide range of industries
Mature product: been on the market for years
Line up has been expanded over the years to include higher end MSP430s and other devices
The LaunchPad ecosystem started with the MSP-EXP430G2
Great for development and evaluation because they provide an on- board programmer and debugger
Built to support BoosterPacks developed by TI and Third Parties (like us!)
Most of you are probably familiar with the MSP430 and the LaunchPad Ecosystem, but for those of you who aren’t well start by going over some basics.
The msp430 line is a family of low–power 16-bit RISC microcontrollers with a variety of analog and digital peripherals for a wide range of applications and industries
It is a mature product which has been on the market for many years, being available since the late 90’s. Over time the portfolio has grown to include more and more functionality, including features for integrated WiFi, RF comms, and USB for instance
To help popularize and market the MSP430 family, TI began releasing a series of extremely low cost development platform based on the value line series micros. The first of these boards was the MSP-EXP430G2 which at it’s launch, cost only $4.30
The LaunchPad development platforms were conceived with expandability in mind. They offer bare-bones pin connections straight of the micro, intended to mate with Booster Packs fostering growth the an ecosystem.
We really like the MSP-EXP430G2 as a learning platform because it comes with a built-in programmer/debugger which can be connected off-board to other MSP430 projects providing a really good bang for your buck

5. LaunchPad Explorer: What is it and why did we make it
Here is a picture of a LaunchPad Explorer booster pack. You can see that it is similar in size to the LaunchPad itself. Trying to keep things compact was one of our key design goals, as we want to provide a convenient platform to learn about embedded systems work.
You may have noticed, this board is not fully populated. We are still verifying the prototype performance in preparation to produce a manufacturable board.
To streamline development, we have partially populated our various prototypes to allow of to focus on verification of specific subsystems. It saves time over fully populating all boards. This picture gives you an idea of the over layout of the board. Not shown here, but it’s roughly the size of the LaunchPad.

6. LaunchPad Explorer: What is it and why did we make it
The LaunchPad Explorer is a BoosterPack we developed to teach embedded system design
Compliments our free online tutorials
Hardware and software will be open source
Has everything you need to learn the basics and explore the majority of peripherals on the MSP430G2553
Intended to be useful even after you have completed the tutorials
Currently at the prototype stage with plans for availability in Q2 of 2016
Project will be crowd funded end of 2015
The LaunchPad Explorer is a BoosterPack intended to accompany the resources we are developing at simplyembedded.org
To us, embedded system design implies the marrying of hardware and software
We wanted to create a useful resource for those interested in learning the full scope of embedded design
All the code and hardware design material will be released as open source for use by the community
Hackability is one of the goals of our project, we hope others will find it useful as a jumping off point
We encourage users to experiment and see what they can get out of the design
A second goal was to unlock as many features on the MSP430G2553 as possible while keeping the design reasonable
The intent being to allow someone to start with a small micro and learn the fundamentals while growing their knowledge base
In looking at other similar offerings, we are hoping to offer a platform that someone could still use after they’ve gone through the tutorials
We tried to put as much flexibility into the design as was reasonable and cost effective.
We’ve been working most recently on verification of the prototypes and working out any wrinkles.
As you can see, our plan is to gauge interest by crowdfunding the manufacturing of the product
We expect to have completed validation, revised the design and ready for manufacture in Q2 2016, sooner if possible

7. System Overview Here is a block diagram of the LaunchPad Explorer
As you can see USCI_A is dedicated for UART use only
USCI_B allows us to connect digital peripherals and we’ll discuss the details later
Finally, the bottom half shows analog inputs and outputs
Using the ADCs for input voltage measurement and PWM outputs from the Timers for analog control

8. Clock and Timer Configuration
8MHz MCLK sourced from DCO
Using TLV calibration tables
4MHz SMCLK sourced from DCO (divided by 2)
Clock source for most peripherals
AUXCLK sourced by VLO
Only used for watchdog
TimerA0 used by a custom timer library
TimerA1 used for PWM based signal generator
The foundation for all the features developed in the LPEx tutorials starts with the clock configuration
Using the internal DCO for main clock, easier than populating included crystal, also uses an extra pin, note that pin allocation is critical when using small count devices
Calibration data exists in the information memory of flash for each device, this data is used to calibrate the DCO and configure to 8MHz
MCLK is the main CPU clock, 8MHz (DCO)
SMCLK (Submain Clock) is set DCO/2, for I2C, SPI, UART, Timers, and ADC
AUXCLK sourced by VLO, about 12kHz, not particularly accurate
Two timer A modules are available, timer A0 and A1
Each Timer Ax is comprised of three individual timer blocks.
The tutorials at Simply Embedded are founded upon the use of a timer library, targeting timer A0. This library will allow creation of a one-shot or periodic interrupt which executes a callback on timer timeout
For instance, a one-shot may be useful in debouncing a noisy switch input, while periodic timers are used extensively for items we will discuss.
More details of the timer library and implementation are available at simplyembedded.org Software Tutorials: Lesson 8
The LaunchPad Explorer requires the use of the timer A1 module for the PWM based signal generator

9. 7-Segment Display Control
MSP430G2553 is only a 20 pin device, insufficient I/O to drive display directly (16 signals to drive two dual displays)
A shift register is a convenient way reduce the pin requirements on the microcontroller while maintaining higher speed than an general I/O expander
For LPEx the shift register is driven by a subset of the SPI interface lines, SCLK, MOSI, and CS#
MSP430G2553 is only a 20-pin device and we had a considerable number of things we wanted to do with it do we had to get creative with our pin allocations
The shift register chosen runs at a theoretical max of 10MHz, allowing lots of update flexibility
Using part of the SPI bus on USCI_B, we are able to drive the shift registers keeping the pin count low while giving good performance compared to other options
This is critical when periodic refreshes are required to allow all four digits to illuminate
To drive two dual 7-Segment displays, we daisy chain two shift registers to form a single 16-bit shift register, so all access are 16-bits
Anyone familiar with dual 7-Seg display will know that they have two pins to control which character is driven at any moment (only one characters is drawing current at time), on LPEx these directly driven by the uC but are shared between the dual displays
The next picture will illustrate (D0, D1)

10. 7-Segment Display Control
SPI driver initializes the USCI_B peripheral as SPI master
Speed set to 400kHz, SPI mode CPOL = 0, CPHA = 1
CS manually toggled via GPIO
The display function is contained in a library which controls all SPI transactions, the digital control via GPIO, and the display refresh rate
Scaled integer is passed to driver with scaling factor
Convert to 4-bit BCD
Character map for each dual 7-segment display
Refresh is every 75ms (rate of ~13Hz), fast enough for POV to provide no flicker
The USCI_B is set to be a SPI master to communicate with the SR
Speed set to 400kHz, SPI mode CPOL = 0, CPHA = 1
The two display control signals and CS# are driven by GPIO
Since there is only one included CS with the SPI peripheral, and we have more than one SPI device on the board, we made the decision to manually control the CS lines for all devices using standard GPIO.
This permits us to write a SPI driver which is common to all devices
This is the kind of trade off we like to highlight at simply embedded as an overall design consideration
The display function is wrapped up in a library which controls all SPI transactions, the control GPIO, and the display refresh rate
Scaled integers are required since there is no floating point support in hardware
A scaled integer allows you take a decimal value, multiplied by some factor 10, to produce an integer representation
For example, if you want to display the value 1.25, you would multiply by 100, to get 125
The desired precision is 2 decimal places, so the scaling factor is two, ie two decimal places
The library automatically places the decimal in the correct location based on the scaling factor
The scaled integer is converted to 4-bit binary coded decimal value using the double dabble encoding algorithm
Each 4-bit binary coded decimal value is used to index into a character map for each 7-segment display
Display refresh uses the previously mentioned timer library to generate an event to signal when a character update is required

11. 7-Segment Display Control
Here we have a diagram explaining how the display works
On the top diagram, the first and third digit are active
The driver write 16-bits to the SPI
BCD coded value are shown for clarity but in reality these are mapped to the segments based on the schematics and layout
Note, the character map for the first display is not the same as the second for routing reasons, therefore there are two character maps
When the SPI CS is de-asserted at the end of the transaction, the 16-bits are latched in the two shift registers
D0 is asserted, and the digits in bright red are illuminated
In the second image at the bottom, digits 2 and 4 are being set in the same manner
This time D1 is asserted instead
By alternating these two sequences quickly, it gives the impression that the 4 digits are solid
We discovered that between changing sets of digits (ie image on top vs image on bottom), you must de-assert the respective D0/D1 line before updating the shift registers. Not doing so results in a faint glow from segments that shouldn’t be illuminated

12. I2C and SPI via the USCI_B module
USCI_B is the only peripheral available for general use
Support for both I2C and SPI required
I2C devices: temperature sensor, EEPROM & IO expanders
SPI devices: dual 7 segment display & SPI NOR
Solution: drive I2C and SPI using a single USCI_B module
Hardware switch to isolate I2C devices
In I2C mode, SPI devices don’t respond because their chip select is not asserted
In SPI mode, I2C bus is disconnected from USCI_B
Drivers responsible for controlling the switch and configuring USCI_B
Use the open/close model to control access to the peripheral
USCI_A [UART & SPI] is reserved for the UART which is used to control the LaunchPad Explorer via a menu, but we wanted support for both I2C and SPI
SPI is a 4-wire bus, while I2C is only two wire, USCI_B uses the same pins for both allowing us to multipurpose the bus
It makes sense to drive SPI directly from the uC, as it is the faster protocol, and extend the necessary signals to the I2C devices through an analog switch
The lines are MISO and MOSI in SPI mode, so the I2C section is isolated during SPI access to prevent ‘confusing’ the I2C devices. When I2C is required, the CS# for the SPI devices is not asserted to they ignore activity on the other lines
To speak to I2C, we close the analog switch and communicate with the device while all SPI chip selects are de-asserted, and to communicate over SPI we open the analog switch, and no signals reach the I2C devices
For this reason, we use an open/close model for I2C and SPI drivers
The I2C open will toggle a GPIO so that the switch closes and connects I2C devices to the bus
It also configures the USCI_B for I2C mode, and then you can read/write as required
Upon closing, the USCI_B peripheral is put in reset
Similarly for SPI, the open function would open the switch so disconnect I2C devices, configure USCI_B for SPI mode, and allow access to the SPI devices
Upon closing, the USCI_B peripheral is put in reset again

13. LPEx Block Diagram

14. I2C and SPI via the USCI_B module
See video in webinar recording.

15. ADC10 with Analog Front End
The internal ADC can be directly fed with a voltage to measured
Many applications require amplification or other signal conditioning
LPEx provides two input conditioning channels with gains of 2,11,101,1001 (Hardware Hackable)
Each AFE is configured as a dual op-amp Instrumentation Amplifier to provide for large gain and high input impedance
Each AFE also includes a calibration feature to account for component tolerances and op-amp non-idealities
Each channel can be generally used or as a unique function
Resistance Measurement
Temperature Measurement via thermocouple
These features provide for experimentation
It’s possible to feed voltages directly into the ADC pins of the uC and make measurements. This may be acceptable in some cases, but frequently some signal conditioning may be desired or required before the signal is delivered to the ADC.
LPEx is outfitted with two signal conditioning channels before the ADC inputs providing four configurable discrete gains (HW Hackable) 2,11,101,1001 (Note this section of the design is still under test)
For most operations the 2 and 11 gains would be the typical choice but the LPEx is intended to allow small voltage detection and conversion. This also allows the user to experiment with the input signal conditioning
As shown in the design block diagram, the IA stages also have a calibration block. Any op-amp based design need to account for non-idealities in the devices used. Things like offset voltages and component tolerances need to be accounted for. In an all analog design this is usually done with trimming pot and so forth, but we can harness the smarts of the uC to make things a bit easier. (Allude to Art of Electronics, 3rd Edition)
The cal options offered on the LPEx include a High Gain test, Low Gain test, and Null input for offset characterization. The software can determine the actual gain settings with a known voltage input and mathematically deal with the op-amp offset number.
An IA configuration is used to provide high gain with high input impedance with true differential input amplification
Finally, both channels can be used generally, each can also offer a unique function. The IA channel housing the CS provides the option to measure resistances, while the other IA channel includes the Temp Sensor near the input terminal block to allow experimentation with thermocouples. (The temp sensor provides a reference temp at the terminal block to allow the uC to compensate for ambient temp offsets)

16. ADC10 with Analog Front End
ADC clock is sourced by SMCLK / 8 = 500kHz (period of 2us)
Sample time: 64 clock cycles = 128us
Sync time for ADC: 1clk = 2us
Conversion time: 13 * 2us = 26us
Total conversion time = 156us
Sampling rate of ~6.5ksps
Using internal 2.5V reference generator
Value calculated using ADC calibration data in Information Memory
Considerations for dealing with component issues
On the software side, the ADC setup is quite straight forward
These are all experimental values chosen conservatively to get things running for validation
Based on the points in the slide total conversion time is = = 156us => ~6.5ksps
So you’d expect to get decent fidelity for a signal under 1kHz
In our demos, we are using DC inputs to characterize the amplifiers
These are conservative values for our verification but there's lots of room for experimentation by increasing clock rates deceasing sampling time.
We chose to use the internal reference voltage of 2.5V because it is convenient (no extra pins requires), a lower voltage gives better resolution

17. ADC10 with Analog Front End
See video in webinar recording

18. PWM based Signal Generator
ADCs in microcontrollers are easy, they’re typically built-in
How can we make a DAC though?
External SPI or I2C DACs are available, but are may be costly
The poor man’s solution is a filtered PWM signal
LPEx provides two PWM channels, one dedicated to the current source, and one for general DAC output
General DAC filter is a low pass filter with a rough 6kHz BW
Configurable (HW) op-amp output stage for gain on General DAC
Most uCs have a built-in multi-channel ADC, making the implementation mostly a software play, at least for basic use
If you want to output anything remotely analog though, you need some kind of DAC
To keep things simpler in the HW domain a purpose built DAC may be used over a supported protocol, like SPI or I2C, but, depending on the application this may add significant cost. A quick look at DK showed the least expensive of such devices was about $1.40 USD.
Another way to get a simple DAC output is to use a filtered PWM signal. Using one channel of a LM324 quad opamp for filtering at a cost of about 10 cents, plus some RC components makes a much more cost efficient solution
The filter is designed with a 3dB bandwidth of about 6kHz or so. This sets a lower limit on the PWM frequency to be used, somewhere optimally in the 100kHz range is the desired spot. Chris will fill you in on the programming impact of this part of the design.

19. PWM based Signal Generator
PWM generated using TIMER_A
Two timer blocks must be used - frequency & duty cycle
At expiration of the first timer block, the output it toggled high
At expiration of the second timer block the output is driven low
For simple PWM, once configuration is set, rest is taken care of in HW
In case of sine wave, duty cycle needs to be variable
Precomputed table of duty cycles - 21 points - half of the sine wave
Interrupt is enabled for second timer block
Upon each expiry, the duty cycle is changes based on the next value in the table
To generate a constant duty cycle PWM signal using TIMER_A, two timer blocks must be used, the first sets the frequency, while the second sets the duty cycle
The TIMER_A module allows us to tie the timer output to an I/O so at expiration of the first timer block, the output it toggled high, and at the expiration of the second timer block the output is driven low
In this manner PWM can be configured once and then the rest is handled by interrupts
Doing this would give you a DC voltage based on the duty cycle of the PWM
So, to create a waveform, we need to be able to vary the duty cycle, thereby changing the voltage output
For a sine wave, half of the waveform is stored in a table, from -1 to 1
Because of the symmetry of a sine wave over 1 period, we only need half of the waveform to produce a full sine wave
Note, the values in the table are scaled to start at zero since we can’t generate a negative PWM voltage
Table is 21 points, and the PWM runs at 40kHz to produce a sine wave of 1kHz
Although optimally the filter should be run at higher PWM frequencies (~100kHz), for the purposes of validation it was faster to get a reliable waveform due to easier math at this frequency
The timer block responsible for controlling the duty cycle has its interrupt enabled, and the interrupt handler loads the next duty cycle value into the timer
Over time, it iterates up and then back down through the waveform table to produce the signal
The waveform generation is the main reason we needed to increase the frequency of the CPU from 1MHz to 8MHz
The board should still be usable even while signal generation is occurring (ie it should still be able to multitask so to speak)
We have two waveforms for demo: a sine wave and a triangle wave

20. PWM based Signal Generator
See video in webinar recording

21. General software considerations
MSP430G2553 has limited memory (16kB flash, 512 bytes RAM)
No hardware multiplier - math can be expensive
No floating point calculations
Using scaled integers where required
Design of each module has to be carefully designed for the best balance between speed and memory
ex: using a lookup table for the function generator vs. calculations
Event queues are much more effective than a super loop
Timer library generates interrupt
Interrupt invokes callback
Callback sends an event
Main event loop processes the event
There is still room for optimization
Compiler optimizations are off
Some ‘easy’ software optimizations, but not much research or effort to find the best way for this prototype

22. General hardware considerations
Many applications employing low cost microcontollers are cost sensitive
A balance between hardware and software trade-offs must be found
Pin count and I/O usage
Rely on peripheral busses to allow I/O expansion
Multi-use of USCI_B to get a greater value from the microcontroller
Balance to provide enough calibration flexibility to AFEs without overloading the software requirements

23. Conclusion
Cost effective designs can be achieved when hardware and software decisions are made in concert
Development of the LPEx continuously considers the strengths and weaknesses in both the circuit design and firmware design arenas
Development effort for all sides needs to be considered, it is tempting to say, sometimes, ‘we can just deal with it in software’, but resource limited microcontrollers may not permit such a cavalier attitude
Did we make the most of the MSP430G2553? Yes!
Things we didn’t cover:
capacitive touch sense
IrDA
Low power mode
Over the course of development we’ve discovered some limitations that we list here as potential improvements to the design.
Unused portions of the MSP430G2553 include: Capacitive Touch Sensing, IrDA mode, Low Power Mode
Due to size constraints we opted again cap touch sensing and IrDa for the moment, but the low power mode could be implemented in software

24. Future improvements Extra filter stage on PWM
Positions on AFEs for filtering components
Pre-divider on at least one AFE input to allow higher voltages to be measured
Store waveforms in flash memory controller and load at runtime
EEPROM for ADC calibration
General purpose GPIO expander library
Other items of interest would improve the performance of LPEx such as: an extra filter stage at the PWM filter input for greater high frequency rejection, a voltage divider on one AFE input to allow auto ranging input voltage measurements.
Also, there may be room for extra component positions to allow the user to customize the AFE responses to their needs
Finally, further development and refinement within the software to permit storage and retrieval of waveforms for the signal generator
Management of calibration for analog sections as required
Library to support easy use of the general purpose GPIO expander (a second dedicated GPIO expander is used for ADC gain and cal control)

25. Thank you! simplyembedded.org Thanks for joining us
Hope what we presented gave you some ideas and was useful
If you want to learn more, be sure to check out the tutorials at simplyembedded.org and sign up for the newsletter
Thanks again to TI and Blake for hosting this webinar
Our hope is that the LPEx will provide a good platform for learning and experimentation using the MSP430 LaunchPad.
If your interested keep in touch and we look forward to hearing from you

26. Q & A