Showing posts with label MSP430. Show all posts
Showing posts with label MSP430. Show all posts

Tuesday, March 15, 2016

The $5 FORTH Computer

The MSP430 makes an excellent choice for a Forth Computer.  It already has a 16 bit architecture, and the Von Neuman  unified memory space makes dealing with data and instructions somewhat simpler. It's choice of low power, non volatile FRAM memory makes it virtually unique in the microcontroller market.

FRAM has a fast write cycle - about 100 times the speed of Flash, and with a life of 10E +14 cycles - it will not wear out anytime soon.   EEprom is made redundant with FRAM, and the boundary between FRAM and SRAM can be moved - so that FRAM is used as RAM - allowing up to 8MHz operation.

The MSP430FR2433 is a new addition to the FRAM range of microcontrollers and at  $1.50 it is very affordable. Add to this an external SRAM or FRAM memory and you have the makings of a powerful little machine.  With volume production, it's possible to have a complete Forth system for around $5 - including the USB programming adaptor.

Performance wise, it's not in the ARM class, not even close, but at 16MHz full speed, it will run about 4 times the throughput of the Arduino R3.

One of it's strengths is that it has been blessed with 3 communications ports - allowing a rich mix of asynchronous UART and synchronous SPI hardware to be added.

The MSP430 may be programmed with a variety of Forths, including Mecrisp, Amforth and 4E4th - the latter having a special port of Camel Forth available specifically for FRAM operation.

Recently I came across Fast Forth by Jean-Michel Thoorens - this is Direct Threaded Code, and has support for SD card.  Programming is done making use of TeraTerm for file sending - at a full 921600 Baud.   It was designed specifically for MSP430 with FRAM - needing just  8K bytes of FRAM.

Forth was designed as a complete, self contained  tool-chain - including Editor, Compiler and Assembler - all the tools that you need to develop code,  at your fingertips - present on the target chip.   Now for the first time we can have all of this on a tiny, manageable 20 pin DIL module - complete with it's own USB programming interface.

The communications interfaces include UART, SPI and I2C.  There are up to 6 port pins available for use as GPIO,  peripheral selects or ADC inputs.

Need to add more I/O? No problem - can be done using simple shift registers clocked off one of the two available SPI ports.

Want to build a WiFi or Bluetooth robot - again no problem. Just drive the stepper motors using a shift register or high power driver  - such as the TPIC6B595 

The SPI port may be used to read a PS/2 keyboard, or I2C will interface nicely to a Wii Nunchuck controller.

ChipStick will accept an external static RAM (23K256 or 23LC1024) up to 128Kx8, or a SPI FRAM of up to 256Kx8.  In streaming mode the speed is about 3uS per byte (for long streams) allowing 32K to be transferred in 100mS.

It should even be possible to experiment with monochrome video output by clocking data out of the SRAM using SPI.



Erm  - Wrong Chipsticks!

ChipStick will be a fully functioning FRAM MSP430 Forth System!

It's nice to have a hobby in which something useful can be designed over a weekend. That's the case with ChipStick - conceived on Friday evening after work - and off to meet it's maker (my pcb board house) at the end of Sunday evening.

ChipStick is the solution to the modern problem that not enough microcontrollers are breadboard friendly - so I just sat down and designed what I needed - a neat 20 pin DIL module - based on the MSP430FR2433.

ChipStick is probably the smallest computer I have worked on, but despite it's small size I have managed to pack a lot in. The MSP430FR2433 has 15.5Kbytes of FRAM and 4Kbytes of SRAM. There are 3 communication ports UART &  SPI, an external memory  - either SRAM or FRAM and up to 4 x 10 bit ADC channels.

The external memory is either a 23K256 SRAM - and there's facility for battery or super-cap backup, or a non-volatile FRAM device.  Either way it extends the memory by a useful 32K to 256K bytes.

ChipStick comes with a detachable programmer section - which consists of the USB- serial converter IC and the 3V3 regulator.  Without the programmer section  ChipStick is just 27 x 11mm  - and that's small enough to fit inside a 2 x 4 LEGO block!

The programmer section is however fairly unobtrusive and can be kept in place - even when the device is plugged into a Launch Pad pcb.



Sunday, March 13, 2016

ChipStick - A Diminutive Dev Board

Chipstick - A complete "Retro" computer on a 40 x 11mm stick

I have recently been looking at the MSP430 as a contender for a general purpose development board. In the last 3 weeks I have looked at several of the extensive range of devices, both the low cost "value line" and other parts, including those with nonvolatile FRAM memory, 24 bit ADCs and LCD drivers. Having absorbed the data sheets of several devices I came to the following conclusions:

1. There are hundreds of MSP variants across several families.
2. Very few packages offer consistent pin-out - allowing one device to be swapped for an upgrade part.
3. Register names and bit names often lack consistency across the various families making common code more difficult.
4. You can never quite find the all peripherals you need in the package you want.

After a bit of consideration, I decided to tackle points 2 and 4 above in one hit - I will design a common carrier board allowing a common footprint.

As I like the small plug-in DIL packages, as they are breadboard and stripboard friendly. So it seemed a sensible idea to use the DIL 20 as a common footprint.  I also found that some devices were available in a very compact 24pin QFN package - which is ideal for mounting at 45 degrees at the centre of a 20 pin DIL footprint.

In my search for the ideal part, I came across the new MSP430FR2xxx series.  These have 15.5K of FRAM and 4K of RAM. In addition they have 2 A type UCSI and 1 B type UCSI universal serial communications interfaces.

So in a few hours, I had designed a tiny carrier board, to which I added a USB to serial converter IC plus some extra features.

Hardware Details

The pcb is designed to take any of the 24pin MSP430FR2xxx range, but in particular the very low cost MSP430FR2433.  The 20 pin DIL footprint breaks out the available pins into a form that can be plugged directly into a low cost Launchpad - in place of the MSP430G2553 device.

This gives almost 16K of nonvolatile FRAM plus 4Kbytes of SRAM - which is eight times the RAM on the '2553.

On the left hand end of the board is the CH340G  USB to serial converter IC. This forms a complete communications and programmer interface - providing the RESET and TEST signals required for the serial bootstrap loader (BSL) programmer.

"Chopstick"  - with the Programmer section removed


It should be noted that this programmer section of the board is detachable, making the 20pin DIL carrier part not much bigger than a standard DIL socket.  A 6 way 1.27mm (0.05") pitch connector allows the programming section to be connected to the target using a suitable cable.

The MSP430FR2433 has 3 very useful communication ports.  One of these is reserved for UART communications to a PC, whist the other two  can be used for SPI, I2C or other GPIO purpose.

The board also makes the following provisions:

1.  A reset switch
2.  A single LED
3.  A 32768Hz crystal may be fitted for more accurate timing.
4.  A lithium battery or super-capacitor may be plugged in to power the board
5. On the underside of the board there is a footprint to allow an external SPI SRAM or FRAM IC to be fitted. SRAM available up to 1Mbit (128Kx8) or FRAM up to 256Kx8.


In the next part, on receipt of the board back from the manufacturers, around March 23rd - I will discuss some applications for this diminutive dev-board.

Other recent Posts on ChipStick

ChipStick - A Diminutive Dev Board

The $5 Forth Computer

First Steps to Building the $5 Computer

Digital Dust

Constructional Guide

Bootloader

Interfacing Memory

I/O Expansion

Graphical User Interface

Applications





Wednesday, March 09, 2016

Porting SIMPL to the MSP430FR4133 Launchpad.

For the last few days I have been using the entry level, MSP430G2553 Launchpad for my code development.

This was fine to begin with for basic experimentation with functions, but ultimately I knew that my proposed application would probably use on of the larger FRAM based parts, with built-in segment LCD controller.

The MSP430FR4133 Launchpad is excellent value at about $16 and it comes with a 6-digit multi-segment display,  similar break-out headers to the entry level Launchpad and the means to monitor the mcu power consumption - using Energy Trace Technology.

My final application is a hand-held, battery powered instrument with LCD - so the MSP430FR4133 target is a good hardware match to the final device.

The MSP430FR4133 has 15360 bytes of FRAM memory for program storage, plus an additional 512 bytes for Information (calibration data, Identity etc). There is also 2Kbytes of RAM.

The extra RAM means that SIMPL can be run easily in the RAMspace without having to use the external RAM - most of the time.   This makes the user interaction with SIMPL a lot easier, and also allows more functionality to be included.


Porting SIMPL to MSP430FR4133

The following steps had to be performed to get SIMPL to run on the '4133 Launchpad.

1.  Increase the RAM allocation to make ful use of the 2Kbytes of RAM
2.  Convert the uart routines to work with USCA0
3.  Convert the spi routines  to work with USCB0
4.  Modify the ADC initialisation code to work with the onchip ADC_10
5.  Correct the interrupt timer routines so that millis() and micros() work correctly
6.  Make use of the LCD by diverting some printout to it


The code is still a work in progress, with 1, 2 & 3 above, working, and a little progress on 6  - but I have posted the latest code here on this Github Gist.

Monday, March 07, 2016

SIMPLEX - Part 2 - Running SIMPL Code out of External RAM

Running SIMPL Code out of External RAM

In part 1 I looked at the bulk access to the RAM chip using streaming mode - which takes about 3uS to access a byte.  With single byte access, there is the significant overhead of setting up the read instruction and the 24 bit address - making an access about 100uS.

For this reason, I propose a block access mode which loads in a block of 32 bytes into the SIMPL input buffer and executes the code at full speed from there.

Reading in 32 bytes in streaming mode will take around 100uS and then the code will execute at full speed out of internal RAM.

Writing some Commands

A   Assemble
B   Block Read
C   Compile
D   Decimal Dump
E    Execute (Read and Go combined)
F    File
G   Go
H   Hex Dump

We need a simple routine to load a block from RAM - based on the existing bulk read.

I use the  B command to signify a Block Read - and it takes a integer block number and loads the block into a temporary internal RAM buffer called block_array[]

Once the data is in the block_array buffer, it's a simple case of pointing the interpreter at the start of that buffer and letting it execute the code.

To initiate this process, I use the G  (Go) command.

The great thing about SIMPL is that the commands can be concatenated along a line  so to load and run Block 0 you just need to type  0BG.  You can then string these together so that multiple blocks are executed one after another  0BG1BG3BG2G  etc

We could now dispense with the BG construct, and just call it E for Execute.

SIMPL has grown a lot today - and even as I author it, there's a lot of new information and excitement to take in.  It's been a long but rewarding day getting the external RAM to work with SIMPL.

The latest code - with the ability to run code out of SRAM is on this github gist

In the next part, I look at data entry into the RAM and making a simple line editor.




Saturday, March 05, 2016

Interfacing SPI SRAM & FRAM to the MSP430

This week I have mostly been experimenting with the low end MSP430 series of microcontrollers using the standard entry level LaunchPad.

So far, I have looked at serial communications, ADC interfacing and running small applications, written either on Code Composer Studio or using the Energia IDE.

In this post I look at the SPI interface with a view to accessing SPI memory  - including SRAM  and  non-volatile ferroelectric RAM (FRAM).

The low cost MSP430 parts are often very limited in their RAM capacity.  For most of this week I have been experimenting with the 2553 and 2013 parts which have 512 and 128 bytes respectively. Whilst this has been for sufficient for the smallest of applications to test the various on-chip peripherals, it's not enough for serious tasks.

I've used serial SRAM in the past, so decided that it would be a good exercise to interface it to the MSP430.  I came across Rick Kimball's github gist a couple of days ago - where he had successfully interfaced a 32Kx8  23K256 device to the MSP430F2013 - using it's universal serial interface USI peripheral.

With this proven and working correctly on a breadboard, I chose to use Rick's code as a guide and make the necessary modifications so that the USCI on the MSP430G2553 could be used too.  The '2553 part has two USCIs  - one I am already using as a uart for PC communications, leaving USCIB free to work in SPI mode to talk to the SRAM and other devices.

Whilst I had good success with the '2013 part in my loadcell application, the lack of a proper uart peripheral made it too restrictive for any serious application that needs bi-directional serial communications with the PC, so I have parked '2013 developments for the moment, until I have time to look into implementing some form of software uart or some advanced trickery with the USI.

Here's the pinout of the MSP430G2553 - this is the most common part used in the entry level Launch Pad

       +------U------+
  3V3  |VCC      GND | OV
  LED  |P1.0     XIN | 32768Hz
  RXD  |P1.1     XOUT| 32768Hz
  TXD  |P1.2     TEST| 
  ADC  |P1.3     /RST| 
  /CE  |P1.4     P1.7| MOSI
  SCK  |P1.5     P1.6| MISO (LED)
  D0   |P2.0     P2.5| D5 
  D1   |P2.1     P2.4| D4
  D2   |P2.2     P2.3| D3
       +-------------+ 

       +------U------+
/CE    |   23K256    | 3V3
 MISO  |             | HOLD 
 NC    |             | SCK
 0V    |             | MOSI
       +-------------+

The 23K256 is very simple to interface - requiring just 4 wires to the SPI port.  The Hold pin shoould be tied to 3V3 as it is not being used in this application.

The MSP430G2553 benefits from the 20 pin DIL package providing  6 additional port lines from Port 2.  I have labelled these D0 - D5  - purely for familiarity with the Arduino way of naming pins, but they may also be used as additional inputs to the 10 bit ADC.

The firmware to exercise the SPI bus and access the SRAM has been based on Rick Kimballs code - but with changes made so that the USCI can be used.  The code was written within Energia - but can easily be adapted for CCS or IAR Kickstart etc.

I have included the memory test sketch on this Github Gist.

In the next part of this MSP430 series I will attempt to make use of the SRAM within SIMPL, and make further use of the SPI bus for driving other hardware.




More Nano Computing - The "Universal Microcontroller"

In this post I discuss the idea of a "Universal Microcontroller" - a 40 pin plug in module that can host mcus from a variety of different manufacturers and families.  It is based around a standard 40 pin 0.6" wide DIL footprint for convenience and low cost.

The impetus behind this concept is caused by the fact that there are dozens of new microcontrollers appearing on the market every year and by having a common, low cost easy to use module would be a good way to evaluate some of the various product offerings in a breadboard friendly format.

Selecting a Small Microcontroller

There are so many selection criteria - so I will try to target a few of the more important ones

RAM
ROM

POWER
PERIPHERALS

SPEED
SIZE

COST
COMPILER
COMMUNITY

RAM/ROM  - these relate to the size of the on chip memory allocations.  Most microcontrollers these days tend to have a lot of flash ROM and a lesser amount of RAM.

If you are handling arrays and buffers, then RAM is important - and it is very easy to run short if your device has 2K or less. (Notably Arduino ATmega328).

There are a whole class of tiny microcontrollers, which have less than 1K bytes of RAM.  It is more difficult to use these for general purpose applications - and they tend to be used for deeply embedded low end consumer goods, sensors etc.

POWER

A lot of applications for microcontrollers have to be battery powered - so there is a large emphasis on tailoring the application in such a way that battery life is maximised  - particularly if you are operating from a coin cell or similar. Some microcontrollers are very power efficient, and have multiple low power modes including low voltage operation.

PERIPHERALS

The microcontroller manufacturer chooses to fit-out a particular cpu core with a certain set of peripherals and it is these which give the microcontroller it's flexibility and capability in handling various applications. An mcu which is lacking a particular peripheral can be very difficult or impossible to match well to a particular application. A rich peripheral set often minimises the amount of glue-circuitry needed to interface to common external devices.

Peripherals may be grouped as follows:

Communications   UART  SPI  I2C USB etc
Timing     TIM
Driving    PWM
Sensing   ADC  DAC  Comparator
Misc       GPIO

These are the basic building blocks - the larger mcus may have sophisticated peripherals for audio, LCD video and external memory interfaces.

SPEED

The clock frequency of microcontrollers has increased steadily over recent years - and many have sophisticated clock control options to allow variable frequency clocking schemes especially for low power operation at much reduced frequency.

Most modern, general purpose microcontrollers will run at up to 20MHz or so.  From then on upwards it could be best described as following a 1,2,5 progression:

20MHz            AVR   MSP430  ARM M0
50MHz            ARM Cortex M0+
100MHz          ARM Cortex M3/M4
200MHz          ARM Cortex M4/M7
500MHz          ARM


SIZE

This refers to the word size used by the mcu. Originally dominated by the 8-bit families (PIC, AVR, 8051 etc) these low end microcontrollers are being replaced by much more capable and cost-effective 32 bit parts, generally based on the ARM architecture. The 16bit MSP430 is an interesting exception -and will be interesting to see how this family product line fares in the face of competition from ARM.  TI have already brought out their own  MSP432 range based on 32bit ARM Cortex M4F cores.

COST

Microcontrollers range in cost from about 35 cents to about $12.  These will have flash memory sizes from 512bytes to 2Mbytes and clock speeds that range from 20MHz to over 200MHz.  Package sizes from just 6 pins to over 200 pins. Again it might be worth imposing a 1,2,5 scale on your budget - and see just what parts match your requirements.

COMPILER

This is a big factor in choosing a microcontroller.   Can I program it easily, and how much does the tool chain cost?  Fortunately there are free tools available - including code-size limited or time limited evaluation versions of some of the professional tools.  The open source community has done a lot to make microcontrollers more accessible.

COMMUNITY

This has become increasingly important. Is there a good online help forum where beginners can get advice. Is the chosen device well supported by a community?


The Universal Microcontroller

Having selected our microcontroller how do we achieve universality?

About a month ago I reviewed a low cost version of the "Arduino" Nano - made in China using the CH340G USB to serial converter IC. The Nano has a lot going for it  - in terms of low cost and compact size.  The DIL format makes it easy to use.  However it's 8 bit mcu is now showing it's age - especially when there are cheaper, faster and more feature rich 16bit and 32bit mcus available.

Other processors also use this DIL format - such as the "Maple Mini" based on the STM32F103, and my own "ARMiGo" based on the STM32F373 (with 3 x 16 bit differential input ADCS).

Looking further afield there are the Teensy series of boards based on the Freescale (now NXP) MK20DX series of ARM Cortex M4 mcus, and McHCK! also based on the MK20DX series.

I am also more interested in the MSP430 reange of 16 bit microcontrolers - now that they have FRAM memory - and are fully supported by Energia - an Arduino IDE "workalike" for the MSP430 and other TI processors.

Is there a Universal module format that can accept all these different devices?  My mission now is to try to develop one

Progress So Far

In the intervening month, I have had prototype boards back, for a small computing platform, WiNode 5, based on my 50x50mm board format, which uses the CH340G. I can report that the board works perfectly.

At the centre of the 50x50 pcb is a footprint to accept a 40 pin DIL socketed device, and this was placed with the intention of allowing several microcontroller variants to be used with the WiNode 5 pcb.

At the moment, the following processor family options are under consideration:
  1. ATmega1284  - native on board either as a SMT or as a plug-in DIL 40 packaged part
  2. STM32Fxxx    -  added in the form of a 40 pin DIL module
  3. MSP430FRxxx   -  added in the form of a 40 pin DIL module
  4. MK20DXxxx   -  added in the form of a 40 pin DIL module
Other devices that may be considered in the future include:

nRF51822 Bluetooth Low Energy microcontroller
ESP8266   WiFi module

Of these options, 1 has been prototyped,  2 is currently in CAD, 3 is at concept stage (pre-CAD) and 4 is a latecomer - prompted by the popularity of the Teensy series of microcontrollers, and a very neat similar product  McHCK! that I came across this week.

These options represent 4 of the most common processor families, and by creating a generic 40 pin plug in module should allow easy access to the various devices. 

For the newer devices, (STM32Fxxx, MSP430FRxxx and MK20DXxxx) the module will support a 5 pin "programming" header placed at one end of the module.  This will allow access to the 2 wire ST-link/SPW/SWD   Serial Wire Debug pins - for programming and debug.

The ATmega1284 option was chosen so as to offer full Arduino compatibility - but with extra flash and RAM capacity.

The STM32Fxxx module was designed to accept several members of the STM32F Cortex M3/M4 range (in 48 pin LQFP or QFN packages) to exploit the 32bit architecture, clock frequencies up to 120MHz and 16 bit ADCs - on some devices.

The  MSP430FRxxx module allows the use of very low power FRAM based 16bit processors, TI Launchpad compatibility.

The MK20DXxxx module allows compatibility with the Teensy and McHCK ecosystems. It is essentially a MCHCK device respun into the standard 40 pin footprint.

Common Hardware

Each module consists of microcontroller with most GPIO pins broken out to 0.1" headers, and a support system composed of reset circuit, crystal oscillator(s) (HF and 32768Hz if available) and debug/bootloader interface.

In addition to the above there will be a footprint for a SPI memory device - either FRAM, SRAM or Flash - which may be programmed or accessed from the standard pins.  FRAM devices of up to 256Kbytes is the preferred option.

These modules will have a versatile power supply circuit - allowing options for single cell (eg alkaline AAA or coin cell) and LiPo operation.  A high efficiency boost regulator and LiPo charger circuit are included.

The MSP430 Module

This was perhaps one of the easier to lay out. The 38 pin TSSOP package has a fairly good mapping to the 40 pin DIL.  The mcu pinouts are as follows:

//
//                         +---\/---+
//            (P1.4) PB0 1 |        | 40 PA0 (P1.3) AI 0
//            (P1.5) PB1 2 |        | 39 PA1 (P3.3) AI 1
//             [   ] PB2 3 |        | 38 PA2 (P3.2) AI 2
//             [   ] PB3 4 |        | 37 PA3 (P3.1) AI 3
//        NSS (P2.3) PB4 5 |        | 36 PA4 (P3.0) AI 4
//       MOSI (P2.5) PB5 6 |        | 35 PA5 (P1.2) AI 5
//       MISO (P2.6) PB6 7 |        | 34 PA6 (P1.1) AI 6
//        SCK (P2.4) PB7 8 |        | 33 PA7 (P1.0) AI 7
//                  NRST 9 |        | 32 AREF
//                  VCC 10 |        | 31 GND 
//                  GND 11 |        | 30 AVCC
//         [PJ.7] XTAL2 12 |        | 29 PC7 (PJ.5)( Xout) 
//         [PJ.6] XTAL1 13 |        | 28 PC6 (PJ.4)(Xin) 
//       RX0 (P2.0) PD0 14 |        | 27 PC5 (PJ.1) TDI
//       TX0 (P2.1) PD1 15 |        | 26 PC4 (PJ.0) TDO
//   INT0    (P2.2) PD2 16 |        | 25 PC3 (PJ.2) TMS
//   INT1    (P2.7) PD3 17 |        | 24 PC2 (PJ.3) TCK
//     PWM1B (P3.4) PD4 18 |        | 23 PC1 (P1.6) SDA
//     PWM1A (P3.5) PD5 19 |        | 22 PC0 (P1.7) SCL
//     PWM2B (P3.6) PD6 20 |        | 21 PD7 (P3.7) PWM2A
//                         +--------+ 


Pins 2, 3 and 12, 13 in square brackets are only used with the larger VQFN 48 package MSP430FR5969.



Friday, March 04, 2016

MSP430 Serial Communications

Fun with the MSP430F2013.

I have been playing about with the MSP430F2013 for a couple of days now - and finding out what a wonderful little microcontroller it can be.

It really is short of both flash memory and RAM (2K and 128 bytes respectively) - so applications have to be very compact. However it makes up for these shortcomings with some very useful and flexible hardware.

My first application is to use it as a lower cost alternative to an AD7767 ADC which I currently use in a loadcell interface.

Although it does not have an on-chip 24 bit ADC, the output resolution of the SD_16 ADC should be sufficient for my immediate needs. This little $1.50 mcu already saves me $10 on not having to buy an AD7767 then service it with another mcu.

The second useful peripheral is the Universal Serial Interface (USI) - this is a flexible device used for both I2C and SPI communications, and as will be seen below later can also be used for high speed asynchronous uart communications too.

Using the USI

The universal serial interface is a flexible peripheral that is primarily intended to automate the processing of SPI and I2C communications. With a bit of bit-banging trickery - to add start and stop bits, it can also be used as a Transmit UART.  Rick Kimball has also experimented with high speed asynchronous serial from the USI - which is capable of a massive 16Mbaud - but I doubt anything much over 3Mbaud will be accepted over a FTDI cable!

By way of a test, I hacked together a quick routing to read the ADC and send its 16 bit sample to the USI.
At it's heart it has a variable length shift register which can shift a maximum of 16 bits. By adding in a start and stop bit, and setting the shift register length to 10 bits, the USI has no problem sending asynchronous serial data at up to 2Mbaud.

With potential serial at the processor full speed - SPI transfer at 16MHz should be possible - and it's definitely worth trying.

This will allow word length transfers to be made with the serial SRAM, and will be more efficient it setting up longer addresses.

The SRAM needs a 32 bit control packet to be sent prior to any transfer.  This consists of an 8 bit instruction followed by a 24 bit address.  The RAM handler code should be able to efficiently set this up and clock it out  to the SRAM as two consecutive 16 bit transfers. From there on it just emits clocks (dummy bytes) to accept the data bytes from the RAM. On long sequential transfers about 300Kbytes per second transfers should be possible.

MSPEZIO

This is a collection of useful I/O functions to make your programming life a whole lot easier. Written for physics students at the University of East Carolina. I quote:

This guide is intended to serve as a fast introduction to the use of the msp430x2xx embedded microcontroller for use by students in Electronics and Advanced Laboratory environments. The intent is to allow an easy access to calls for I/O applications and serial communications transmitting data to external computers. It is assumed that the student has some understanding of c-programming and has been through the introduction to using the Code Composer Studio or IAR Embedded Workbench Kickstart, IDE’s. 

16 Bit ADC

With code based on one of the mspezio examples, I was quickly able to get the SD16 ADC working and sending data out of a bit banged uart. MSPEZIO offers several examples that can be tried with CCS on the basic LaunchPad hardware.

The SD16 ADC is quite comprehensive - and the mspezio set-up made the initialisation of this peripheral a lot easier.  I was able to set it up to read a strain-gauge based loadcell and send readings to the PC terminal application.  The MSP430F2013 really only has just enough pins to allow a simple loadcell interface with serial comms.  The output of the ADC values can be triggered by sending any character over the serial comms   - using the mspezio WaitForSerial() function.

Much of the progress I have made with the MSP430 has been the result of evenings and weekends looking online at other code examples and good old experimentation.  By modern standards the MSP430 is not a complex microcontroller, requiring significantly less initialisation code to get the basics working.  I would recommend buying a Launch Pad to anyone who wants to tinker with something a bit different.  As stated in a previous post, the board is low cost and there is free access to the CCS Code Composer Studio compiler and also the Arduino like Energia IDE.  CCS offers multiple file projects to be built and debugged whilst Energia allows easy entry level to simple sketches.


SIMPL on MSP430F2013

The plan now is to get Energia working with the MSP430F2013 so as to allow a cut down version of SIMPL to be run on it.

Energia allows the SIMPL application to be built up a routine at a time - so that every last byte of precious code space can be efficiently used. This is very important on the '2013 - which only has 2K codespace and 128 bytes of RAM!

The biggest problem with the MSP430F2013 is that it does not have a proper uart peripheral and whilst uart transmit is possible using the USI module with a bit of  trickery, the uart receive function becomes a major challenge - involving either a timer controlled sampling of the incoming bit stream or something as yet unknown.

The porting of SIMPL and the MSPEZIO helper functions to the '2013 will be the subject of a forthcoming post.




Thursday, March 03, 2016

More MSP430 Machinations

In the last few weeks I have been acquainting myself with the MSP430  - as a possible low cost candidate for future projects.

There are literally hundreds of different variations of the MSP430 - and to the newcomer the range of devices can appear to be quite daunting.

However, for my initial experiments I have been looking at some of the low end devices - which are particularly accessible in terms of very low cost and ease of use - and available for the MSP430G2XX Launchpad dev-board.

The low-end devices are interesting because of their low cost and flexibility of peripherals, and the combination of a 16 bit ADC and a high speed universal serial peripheral makes for some novel sensor applications - particularly when applied to strain gauge, loadcell and barometric sensors.

Low Cost Hardware -  and Free CCS Compiler

This entry level Launchpad is available for about £7 (US$11).  It comes with integrated programmer/debugger and will accept most of the DIL packaged MSP430 ICs.  The free to use Code Composer Studio IDE, consisting of compiler, debugger and other workbench tools may be downloaded from the TI website - after a registration process has been completed.  TI has produced dozens of useful code examples - which are a great way to learn the programming techniques of these devices.



The all round work-horse shipped with the Launchpad is the MSP430G2553 which comes in a 20 pin DIL package and has 16K of program space, but only 512 bytes of RAM.  There is also, included with the Launchpad kit an MSP430F2542 with 8K of codespace but only 256 bytes of RAM.
The MSP430G2553 does have a proper uart - but for BSL purposes Rx is on Port 1.5 and Tx is on Port 1.1.

The other device of current interest is the 14 pin DIL MSP430F2013 - which is a very low cost device but it's unique point of interest is that it is one of the few devices that has a 16 bit SD_16 A ADC and is ideal for sensor applications. However it has even less Flash (2K) and only 128 bytes of RAM! There is however 256 bytes of "Information RAM" - which is handy for storing device identity, calibration factors etc.

According to TI literature, the MSP430F2013 comes with a uart based bootloader (BSL). This is curious, and yet to be fully confirmed,  as the uart is one hardware peripheral missing from the '2013!

There is a RAM based software BSL described in application note  SLAA450

These small devices are all resource limited, but as such inspire ingenuity. Programming code for these is not-dissimilar to what programming the first generation microprocessors was like 40 years ago,  but with  moderately fast 16-bit, very low power processor plus uart or universal serial interface built in.

SIMPL Revisted 

On small devices with perhaps only 2K bytes of flash memory available, I have revisited my implementation of SIMPL on the MSP430, as until now, I have focussed on AVR and ARM implementations.  With a bit of help from online code examples - I have managed to eliminate much of the code intensive remnants of "Arduino"  and shoehorned  a full featured version of SIMPL into just 1868 bytes, putting it well within my self-imposed 2Kbyte limit. This makes it applicable to the '2013, '2452 and '2553 devices.

With additional functionality and further code optimisation then a 2K limit seems a reasonable size for the SIMPL kernel, especially if there is bootloader support included.

The code for the MSP430G2553 version is here on this Github Gist

I have implemented a 10 bit ADC on P1.3 which is read using the s (sample) command.  To read 1000 consecutive ADC samples at 100mS intervals, the following code snippet of a sampling loop with delay can be used

1000{sq100m}

q prints the output of the ADC followed by a crlf.

With a bit of ingenuity it's possible to build up a horizontal bar graph display - of line length proportional to the input on the ADC.


:B  s{_[_}q

Sample the ADC using s and print the corresponding number of brackets along a line. The final q prints the ADC value followed by a crlf.

SIMPLy Short of RAM

The smaller MSP430 parts are really quite short of memory with some only 256 or 512 bytes available.  This really is a limitation when it comes to writing sketches in an interpreted language, so one possible solution is to add a serially accessed SRAM (or FRAM) on the SPI bus.  This will extend the available memory to 32Kx8, 128K x 8 or even 256K x 8 in fast access non-volatile FRAM - (if your budget permits).

MSP enthusiast, Rick Kimball  has written a library to access the 23K256.  A single byte can be accessed in 98uS, but the full 32Kbytes can be streamed in 100mS.

The beauty of the SPI addressed memory devices is that they interface using just 4 pins - ideal for low pinout devices such as the '2013 and '2553.


A Historical Note on Memory.

Ever since the Manchester "Baby" the 1948 small scale experimental computer, the operation of the cpu has been intimately tied to the operating characteristics of the memory.  The computer has essentially been designed around the best memory solution available at the time, be it Williams CRT Tubes,  mercury delay lines, dekatron tubes or magnetic core memory.  The PDP-5 and PDP-8 were designed specifically around the most economical core memory available in the mid-1960s - even though it took half a rack of circuit modules to interface to the core.

In some ways, the little computer that I am proposing, is the modern day equivalent of the PDP-8 (or possibly the 16 bit PDP-11). It is a compact 16 bit von Neuman architecture cpu with limited on chip storage, tied to a serial RAM, which can be efficiently accessed in pages or blocks of 32 bytes.

Within SIMPL it should be possible to write some User words to access the off chip serial RAM in an efficient manner - perhaps treating it like a virtual disk.


Next time - serial communications.




Friday, February 26, 2016

The Great MSP430 Bootloader Swindle

Bootloading Blues.


The MSP430 is a great little micro, and with some proper marketing, it could easily have provided an alternative to the AVR and PIC.  However unclear, obfuscating, archaic documentation, spread very thinly over the web has made this little micro the poor relation of the microcontroller world.

I write this having just spend a considerable amount of time in February trying to provide an effective solution for programming one of our products, an MSP430 based force gauge, which is being produced by a new supplier.

Unfortunately the original programmer from Gessler is no longer available, and so an alternative was needed.

The solution was actually staring in me in the face - so simple, that it's elegance seems to have been lost in the mists of time, and the desire to make everything a lot more complicated than it needs to be.

Here I summarise my findings in an attempt to provide a reference that will allow others to benefit from my 3 weeks of frustrating work and false starts.

As a prologue to the main post - here is an unpublished post from 3 weeks ago - when I first started on this mission

(Previously unpublished - from Feb 9th 2016)


We have an on-going project at work, which needs an MSP430 bootloading over it's serial port with a hex file.  So we went out and bought the cheap open source, Rocket BSL programmer from Olimex.

I then found that I needed the drivers and other software from TI,  which I had to register for and then declare to the US Government that I wasn't going to use it against America in any way, shape or form. So far, so good.

North Korean? No, just Bulgarian.
The MSP430-BSL is described as a joint project between Olimex and Texas Instruments. The reality is that no-one really wants to take ownership of it, and there is no one specific site that you can go to that gives you everything you need to get this programmer to work.  It's like the code has been fragmented and spread to the four corners of the known cyber world - lest anyone dares try put the fragments together again and unleash the awesomeness of this great force on mankind. What I'm trying to say is that both Olimex and the Mighty TI have this time shot themselves in both feet, and it's no surprise that the MSP430  is languishing in some stagnant microcontroller cul-de-sac.

After mulling this over for a while, I began to think that proprietary bootloaders often really suck. There should be a simple, low cost universal tool which allows you to squirt code from a hex file into any microcontroller, from any platform.  And that got me thinking about the humble USB-serial programming cable - such as those by FTDI, SiLabs or our Chinese friends who make the CH340.

It also appears that others have had this thought.  In my search for an alternative MSP430 programmer, I found this interesting approach from Flying Camp Design - a programmer that is literally not much more complicated than an FTDI cable - just an FT232R on a small pcb.

Bootloaders are usually designed to be small, and not particularly human-friendly, because they are normally talking to some proprietary application running on the pc.  But this doesn't need to be the case, there is sufficient flash space in the boot block of most micros to put a more sophisticated bootloader program - one which is actually capable of running some interpreted commands and presenting a more human friendly face to the user.




Getting Started

The MSP may be programmed by one or more of the following interfaces:

1.  A Serial Boot Loader - resident on almost all MSP430 devices - known as BSL
2.  A JTAG interface/programmer
3.  SpyByWire  - a 2 wire serialised version of JTAG.


The Electrical Interface

Our force gauge product has a 6 pin connector on board intended for a BSL programmer.  This has  the following signals present - wired to pins on the IC:

TX
RX
TEST
RESET
0V
VCC

A combination of signals on the test and reset pins puts the device into bootloader mode.  The data is then sent by the PC and received by the Rx pin and acknowledged by the Tx pin.

The Spec Document

The bootloader is fairly well specified in TI's document SLAU319 - and for anyone wishing to understand the bootloader, this should be the starting place.

When the MSP430 was first designed, the engineers made available a small bootloader program, residing in protected ROM, which allowed serial communication directly to a PC via a couple of pins. The BSL interface also allows you to read the contents of the Flash, erase it, verify and a range of other commands - some protected by a password mechanism  - so as to avoid illegal copying of protected IP.

Towards the middle of the SLAU319 document, a circuit for a programming interface is provided:

This circuit dates from the early 2000's  - when all PCs and laptops came with 9 pin serial COM ports.

In essence, there are three, level shifted outputs from the COM port to the target device, and one level shifted input back to the PC. Modern RS232 generally puts out +/-6V - and we need 0-3V TTL levels for the MSP430.  The circuit is powered by harvesting spare energy from the output lines through diodes and pumping up  a capacitor. The raw supply feeds the TL062 op-amp and  is then regulated to 3V to provide a stable supply for the 74AHC14 Schmitt inverters.

This really is a very simple circuit - but sadly off-putting because it uses about 25 components and uses the now obsolete  9 way D-type and COM port.

What is really needed is a modern equivalent that works with USB and modern software drivers.


USB Implementation.

There are several low cost USB to serial converter chips to choose from, including FTDI, CP2102 (SiLabs) and the newer Chinese CH340G.  All of them have the potential to work in this circuit.

I covered the CH340G in a recent post and the datasheet is here. The CH340 is low cost and easy to use. I have subsequently used the CH340G on some of my other projects.

For my experimentation, however, I used a  SiLabs CP2102 device mounted on a small pcb - solely because I had it lying about.  It breaks out all of the common RS232 signals - including RTS and DTR which we need.   These modular devices are available from ebay for a couple of dollars - and a variety to choose from.

CP2102 module by Baite Electronics 
The one above comes with a set of double ended leads - so you can easily make up your own custom cable.




So to make this work we need to access Tx, Rx, RTS and DTR.  RTS and DTR are often available on the 4 way headers down the side of the module.

The module also conveniently supplies a 3V3 supply from an internal voltage regulator (see datasheet) - this can supply a maximum of 100mA - more than enough for powering most MSP430 dev-boards.

Programming Application Software

I tried a couple of programming applications, with very little success - until I stumbled MSPFET - from a Russian gentleman Kurt. This did exactly what was needed - allowing a hex file to be loaded into the MSP430.



Programming the MSP430 really is that cheap and easy - using free software and a USB to serial module costing under $2 - finding out how to do it -  from the information spread over the web it - was so very much harder.

Common Myths - Busted

You don't need a $300 JTAG Programmer.  In desperation I found a FET-Pro 430 reduced to $50 on ebay.

You don't need an $11 Olimex MSP-BSP "Rocket" Programmer.  I bought two of these from Mouser - I am still trying to find the correct software to make them work.


In conclusion

The BSL feature that comes with almost all MSP430 devices is great at doing what it was intended for - a very simple means of getting your hex file into the MSP430's flash.

The resources needed to make this work are trivial, and it could make a great addition to any application that needs the ability to modify the flash memory.

Unfortunately, the documentation has been obfuscated and made more compex than needs-be by JTAG and SpyByWire (for debugging) - and so few people are aware what a simple facility BSL is to use.  The hardware needed in the form of a USB - Serial converter should be part of every hobbyist's or Engineer's toolkit.

The resources needed to make this work are trivial, and it could make a great addition to any application that needs the ability to modify the flash memory.

The protocol is simple, as is the 2 signal start-up sequence -  and at a pinch, if you didn't have a serial converter that supports DTR (eg FTDI cable) you could hack an Arduino or Launchpad to generate the start-up sequence. You could even make a standalone programmer for repeat programming of boards out in the field using a Launchpad.

Energia has made the MSP430 more accessible - providing an Arduino like development environment. However, it is still nice to know how the simple low-level bootloader scheme works.

Update

I have written a follow-up to this post:

The Great MSP430 Bootloader Swindle - Part 2

This looks at the hardware and PC applications needed to make the simple BSL work.

I have also implemented the CH340G bootloader circuit on my latest MSP430 board. Below, on the left is the CH340G, its accompanying 12MHz crystal and a couple of 22pF capacitors. That's almost all you need for a bootloading interface!

ChipStick - an 11mm x 40mm  MSP430FR2433 Dev Board





Wednesday, February 17, 2016

Experimenting With New Devices - Part 2

The '5969 Launch Pad  - an ideal experimenting platform for FRAM

In this post I look at ways in which to get the most performance out of a small computer system based around the MSP430FR5xxx with external serial  RAM and FRAM.

MSP430 Performance

The MSP430 being a 16 bit architecture is pitched performance-wise somewhere between AVR and ARM.

If you are doing a lot of 16 bit maths operations, then it will be quicker than the AVR as these are single cycle operations on registers, rather than having to combine two 8 bit operations.

This report compares execution time and code size for a number of common microcontrollers, in particular comparing MSP430 with ARM and AVR.

The speed up factor over an ATmega328 Arduino is as follows:

Simple Maths       1.27
FIR Analysis        3.29
Dhrystone            1.83
Whetstone           2.56

Average               2.24

When this is combined with a 24MHz clock - rather than the normal 16MHz clock on the Arduino the average speed improvement is approximately 3.35.

Code execution is fastest from RAM, so an important speed improvement will be achieved by copying all commonly used code from FRAM to SRAM at initialisation time. This copying process is extremely fast with 1Kbytes of FRAM memory contents copied to SRAM in approximately 128uS.

SIMPL on the MSP430

I tried SIMPL back in 2014 on a very low spec MSP430 value line device in a 20 pin DIL package with only 512 bytes of memory. The C code for SIMPL was compiled using the Energia IDE. There was no difficulty porting what had been an Arduino sketch to Energia - what runs under Arduino runs on an MSP430 under Energia, with zero or very little modification to the sketch. Only the lack of RAM on the MSP430G2553 device was a little problem.

Porting SIMPL to a FRAM Device.

Boosted by the initial success with the MSP430 Launchpad, in getting a basic version of SIMPL to run, I decided to invest in a couple of FRAM based devices.

First, I tried identical sketches on the ATmega328 and the MSP430FR5969.  This was purely so that I could prove that they both ran as expected, and so I could compare the codesize and execution time for each implementation.

For the same clock frequency of 16MHz, the MSP version used about 80% of the codesize and executed simple loops containing integer maths at about 25% improved time.

It was now time to reduce the Arduino supplied UART routines (Serial.xxx) to self coded putchar, getchar and printlong.  This process removed 2200 bytes of code from the implementation - down to 3720 bytes from a starting point of 5920.

The other large chunk of code is the array allocated to holding the initial word definitions. This is a 26 x 48 character array (1248 bytes) - which when removed brings SIMPL down to about 2472 bytes.

The other thing I noticed was that whilst the UART routines take just less than 300 bytes to implement, when they are combined with setup(), the whole thing bloats out to about 640 bytes. This needs further investigation because without this bloating, SIMPL could reside in just 2Kbytes of memory.

Making Use of the FRAM.

The question now is what new features can SIMPL leverage off the back of the MSP430's FRAM?

The write speed of FRAM is well matched to the higher baudrates of the USB to serial converter. Instead of 9600, we can now upload source code at 921600 baud or higher. Using a hex file format, a full 16Kbytes of code could be sent over the serial link in about 0.25 seconds.

The FRAM may be written to at 125nS per 16 bit word, so the whole FRAM storage space could be updated in about 1 milisecond.

The 10 bit ADC could send data back to the PC at almost 100ksps.

Execution from RAM is 3 times faster, so the primitives and the SIMPL kernel are loaded from flash into RAM during initialisation.

The MSP430 has a 20 bit address space, so up to 64 blocks of code could be swapped into FRAM when required.

Off chip storage could be uSD card or even serial FRAM - such as the Cypress 25LV20   which is a 256Kx8 SPI FRAM device in an 8 pin SOIC package.  The SPI bus runs at a maximum of 10Mbit/s - so a "block load" of 1Kbytes is approximately 1mS or the time to load a full 16K block from external FRAM via SPI is 14mS.  This is effectively 1uS access time to a large non-volatile solid state drive.

For faster access either dual SPI or Quad SPI would need to be employed.  This can be done using bit-banging techniques using quite elementary code.

See the Microchip App Note AN1791 for details. A datarate of 8Mbyte/s should be achievable. This would allow the 23LC1024 to be fully read in about 16mS.

To be continued...... soon





Experimenting with New Devices - Part 1

If you were to summarise the developments in microcontrollers over the last few years, you might suggest the movement to 32-bit, mainly through ARM devices, and the rise in open source hardware and software.

Another less well known development is the incorporation of Ferroelectric RAM or FRAM as an alternative to flash memory in the Texas Instruments (TI) range of MSP430 microcontrollers.

Using FRAM instead of Flash memory opens up some interesting possibilities:

FRAM is non-volatile - it retains it's content after power down
It is low power - it can be programmed at low voltages
It has a fast write speed - up to 8Mbytes per second - about 100 times faster than flash
It can be used repeatedly like RAM - it does not wear out after some 10,000 cycles like Flash

Whilst I did gain some experience of the MSP430 some 12 years ago, the introduction of FRAM and modernised peripherals makes them an attractive proposition.

So I decided to invest a little time and money in exploring the new architecture and the new opportunities presented by FRAM technology.

This post and subsequent posts will look at these topics and make a comparison between the more familiar AVR and ARM based devices.

MSP430 Family.

The MSP430 is a 16-bit RISC type microcontroller, with a Von Neuman architecture. This is unusual for microcontrollers (most are Harvard architecture), as it combines both the instruction store and the data store into one unified memory area.

It arose from an early 1990's devices, which was an 8 bit processor, the TSS400-S2, for interfacing to sensors. This early datasheet gives some insight into the heritage from 25 years ago.

The memory architecture is further simplified, as the FRAM and SRAM blocks can essentially be treated as the same codespace for program execution, although execution from RAM is at up to 24MHz, whereas executing from FRAM is limited to 8MHz.

Energia - "Arduino" for the MSP430

The MSP430 range has been supported with low cost "Launch Pad" development boards since 2010, providing an alternative to the AVR or ARM based Arduino or mbed boards. This support extends to the open source Energia IDE project - which is essentially an Arduino compatible IDE (and lookalike) aimed at the various TI microcontroller families. With Energia you can take an existing Arduino sketch and run it directly on MSP430 hardware, with no or few changes. Arduino is certainly becoming a lingua-franca of these small dev-boards.


A look at the MSP430  FRAM devices

The two devices I wanted  to explore are the MSP430FR57xx series and the MSP430FR59xx series.   The MSP430FR5739 is available as as an Experimenter board - below.



The FR57xx series is the smaller of the two with 16Kbytes of FRAM and 1Kbytes of RAM and a maximum clock of 24MHz. It costs about £1.50 in 1off from Farnell and has the potential as being an alternative to Arduino (Nano beater)  - with very few other system components required.  It has 30 GPIO lines which makes it a very good fit for the WiNode 5 format pcb with the extended Arduino headers. Available in a 38pin TSSOP package, which makes it a little easier for home construction.



The FR5969 has 64kB of FRAM, 2K of RAM and a 16MHz clock.

It offers 40 GPIO pins, plus the ability to use both high frequency (16MHz) and low frequency (32768Hz) crystals.

It comes in 40 pin QFN and 48pin QFN packages. A slightly smaller device- with marginally less I/O, the '5959 is available in a 38 pin TSSOP, making it compatible with the '57xx parts but with the beneffit of 64K FRAM and 2K RAM

The MSP430FR5969 is available as the MSP-EXP430FR5969  as a Launch Pad board - for about £12 from Mouser.  This is exceptionally good value, and it has a number of accessory shields available.

Basic Features.

16 bit Von Neuman RISC architecture with 16Kbytes / 64Kbytes  FRAM
16MHz (24MHz *) clock frequency
1.8V to 3.6V operation
100uA/MHz low power operation.
0.25uA RTC
Multiple low power modes of operation
32 bit hardware multiplier
Choice of 10 bit or 12 multichannel ADC
2 UARTS,  SPI, I2C
5 Timers
Low power oscillator
Optional external 32kHz crystal
Optional HF Crystal
16 bit CRC
128 bit/256 bit AES Encryption/decryption processor
31, 33 or 40 GPIO lines depending on package.
Available in 38 pin TSSOP, 40QFN, 48QFN packages.

* Whilst the data sheet says 16MHz, it is perfectly possible to get the digitally controlled oscillator DCO to run at 24MHz. This might be good for a "Turbo-Boost" mode - when power is available.

Datasheet is here.

Tools & Equipment

The Launch Pad and Experimenter boards come with an on-board programmer section, which allows a hex file to be programmed into memory and allows debugging.

The TI Code Composer compiler and tool chain is distributed free of charge for working with these small boards.

If you want to try an open source compiler there is MSPGCC, and if you are seriously into command line hardcore development , you could try  Michael Kohn's  naken_asm which is a cross assembler for a wide variety of microcontrollers.

There are several free tools for loading the hex file into the MSP430. One that I tried is Elprotronics FET Pro-430  Lite  which worked well with the on-board eZ-FET programmer on the launch pad board.

With the above tools I managed to flash a LED using assembly language and also drive a port line at about 2.5MHz square wave.

In Summary & Conclusion

The MSP430 are a fascinating family of microcontrollers. They have utilised every trick to achieve flexibility and very low power operation.  The clocking and low power modes are a study in their own right - but TI through their Launch Pad series of dev boards have made a feature of low power operation - and encourage users to measure the operational current under various modes of working.

Not only is it a 16 bit machine, but it has a universal storage space  - both code and data in one memory - which is all the more interesting for being non-volatile, high speed FRAM.

Although a RISC machine, the ISA is surprisingly versatile with a rich set of instructions and addressing modes.

Just exploring a new instruction set is fun in itself.

The 16 bit architecture is an ideal platform for developing Forth like languages - as these are often based on a 16 bit virtual machine.  Jean-Michel Thooren's "Fast Forth" written in assembly language for the MSP430FR5969 may be of interest to Forth Fans.

Here is a very interesting device - it has a 16 bit architecture, 12 bit A to D and a Von Neuman architecture.  It reminds me a bit of the PDP-8.  More exploration needed.

In Part 2 I'll be looking at porting some existing code to the MSP430 and leveraging some Arduino sketches using Energia.