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.

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

Diving Into Forth

I have always had a soft-spot for the Forth Programming Language, since first hearing about it as a sixth-former in the very early 1980s when I was running the after-school computer club on Friday afternoons.

At that time, I lived in the technological backwaters of the Isle of Man, gleaning all my information from electronics and home computing magazine articles and the occasional worthwhile BBC "Horizon" programme.

There was mention of Forth in the popular computing magazines - but it was probably the August 1980 Byte article - which originally galvanised widespread interest in using Forth.

Towards the end of my school days, an innovative Z80A based home computer the "Jupiter Ace"  became available - but sadly it was a "day late and a dollar short" in those crazy, pioneering days of UK Home Computer industry - with new products announced nearly every week.

Since that 1980 article, we now have the internet, Github, open source software and hardware, ubiquitous 32-bit and 16-bit microcontrollers, FRAM memory, FPGAs and dozens of other technical innovations which should all help encourage users to have a look at Forth for digital interaction.

Getting started in Forth has never been simpler, in addition to Matthias Koch's Mecrisp they are other downloadable packages, including 4E4th (for MSP430) and VFX/XC7 Lite (for MSP430 or ARM M4) from MPEForth.

I have focused on the above two architectures MSP430 and ARM, because a Forth implementation of the Forth 16-bit virtual machine is so much simpler - and sensible - on a 16-bit or 32-bit architecture, than on an 8-bit processor.

4E4th runs on the low cost MSP430 Launchpad - details of this implementation.

There is also AmForth for MSP430  - based on Brad Rodriguez's  camelForth.

(Although Amforth and eForth implementations for Ardunio's 8 bit AVR are available).

Looking at FPGA implementations, there  is James Bowman's J1 Forth processor which runs on a Xilinx Spartan 6 device, or also on a Lattice iCE 40 series part - with the tool chain now entirely open source.

I also recently came across the N.I.G.E Machine - a 100MHz Forth Workstation,  again based on low cost FPGA technology.

If you want to build a workstation type product - suitable FPGA hardware with  PS/2 Keyboard & Mouse and VGA/XGA video output is available from Saanlima Electronics in their Spartan 6 Pepino board and also from Gadget Factory in their Papillio range of FPGA boards.  If you are looking at the Gadget Factory - take time to look at their new Logic Analyser Kit

Whilst there are various Forth Interest  (FIG) Groups around the world,  it is probably the German,  Forth-Gesellschaft e.V. who are the most active, with regular news and updates on their website

For anyone with an interest in Forth, why not spend a quiet Sunday morning browsing on what is available?

You might also wish to look at Jean Claude Wippler's JeeLabs Blog - with his recent forays into Forth, which inspired me to write this blog post round-up.

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.

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.

SIMPL meet SIMPLEX - Part 1 - Putting it Together

SIMPLEX - the EXtended Version Of SIMPL

So I took SIMPL running on a LaunchPad, and added a 23K256 RAM chip with 6 jumper wires and a 10K resistor:

Overall View

I'm probably infringing a whole bunch of trademarks but the EXtended version of SIMPL which uses the EXternal SPI RAM will be called SIMPLEX. 

Now that's what I call subtle! With a touch of irony.

With the RAM expansion comes the need to examine and modify its contents, and so I have written a bit of code to allow the contends of the RAM to be dumped to the screen in both decimal and hexadecimal formats, with ASCII equivalent in a separate column.

Whilst the SIMPL kernel code fits into 2Kbytes - and as such may be considered as a smart interactive bootloader, the high level routines to manipulate the RAM extend this limit quite considerably.

The code I have produced is "quick and dirty"  C, and I am sure it could be written more succinctly at a later date.

The decimal-dump D and hex-dump H commands are the start of a new group of high level commands to handle external memory, editing etc.

30 or so years ago, "monitor" programs were common place on the early 8-bit micros. They allowed for the direct editing of data within the RAM space of the memory map - and were a means of entering programs - one hex byte at a time.  It was a welcome step up from toggle switches!

The "Editor"  will use the first 8 commands of the User Words, signified by letters A through to H, each representing a high level operation.  One allocation of these is as follows:

A           Assemble
B           Block
C           Compile
D           Decimal Dump
E           Edit
F           File
G          Go   (execute from RAM)
H          Hex Dump

Several of these are really just place-holders for yet to be written command functionality.

The first task of being able to examine the RAM contents has been undertaken, now its time to start looking at the process of getting code into the RAM area and then executing it from RAM.

The 23K256 has a page size of 32 bytes, which is a useful size for a phrase of SIMPL code.

Looking at the Block B and File F commands above, the block command can be used to manipulate the memory 32 bytes at a time - effectively a line of SIMPL code, whilst the File command can be used for handling multiple blocks. 

The hexadecimal conversion is used both for 2 digit (<= 255) and 4-digit (256 <=  x <= 65535) conversions.

I have includes a SIMPL primitive   $  which takes an integer x and converts it to either 2 digit or 4 digit hex.

The dump formats make use of the modern wider terminal screen.  1K of RAM can be dumped to a single screen - of 32 lines of 32  hex bytes.

The Hex -Dump as it appears on Termite Screen. 1K bytes of RAM data shown per screen

I have put the code for SIMPLEX_1 on this Github Gist  Please note that the UART is running at a non-standard 100Kbaud instead of 115200.  This is to be investigated later. 

In the next post, I'll look at more RAM operations plus actually running SIMPL code out of the external SPI RAM.

SIMPL for Beginners - Part 1

It's almost 3 years since I started on the SIMPL project, it has come a long way since it's early beginnings.

This first post, in a series,  is a "catch-up" for those that have come late to the party.

Introduction to SIMPL

0. SIMPL stands for Serial Interpreted Minimal Programming Language. It is intended as a common, interactive hardware exercising language that will run on almost any low-end, resource limited, microcontroller.

So far it has been implemented on the following microcontroller platforms

Arduino
ATmega328
ATmega1284P

Nucleo
RFDuino         nRF51822  Cortex M0
STM32F103  Cortex M3
STM32F373  Cortex M4F
STM32F407  Cortex M4F
STM32F746  CCortex M7

LaunchPad
MSP430G2553
MSP430FR5969
MSP430FR5739

Teensy 3.0, 3.1, 3.2

MK20DX256

Future development will include PIC16Fxxxx and PIC32MX devices too - made accessible using Pinguino - an Arduino-like IDE for PICs.

1. SIMPL is based, unashamedly on Ward Cunningham's excellent Txtzyme "Nano-Interpreter".  You can find his work on his Txtzyme Github   This should be the starting point of any SIMPL development. First you port the C code of Txtzyme across to whatever microcontroller you wish to use.  Once you have Txtzyme working on your mcu, you can then start to extend it's functionality to include the whole SIMPL featureset.

2. SIMPL is a text-based interpretive tiny language, which interacts with the onchip hardware allowing simple applications to be developed for a variety of very low cost microcontrollers. It fits into about 2Kbytes of Flash and requires a minimum of 512bytes of RAM - so it will work on the smallest of RAM limited microcontrollers.  It needs a uart connection to a PC terminal program - for text input and output. It is primarily aimed at 14 -28 pin low end microcontrollers - but of course, will run on larger parts.

3. SIMPL originally ran on Arduino. It makes use of the Arduino "Wiring" functions - such as digitalRead, digitalWrite, analogRead, analogWrite, millis, micros, delay, delayMicroseconds and Serial. Provided that your microcontroller can offer similar functions to these, SIMPL will work. SIMPL also runs on the Teensy series of mcu boards.

4. SIMPL can be developed for other microcontrollers - including ARM, MSP430, RFDuino, ESP8266 etc using the "Arduino-like" IDEs  such as STM32Duino or Energia for MSP430 and Pinguino for PIC devices. These alternative IDEs will help you with the various "Wiring" functions.

5. SIMPL has been written in C, to make it portable between various microcontrollers. It uses standard Arduino functions to interact with the hardware - which are perhaps not always the smallest or fastest.  These functions can be rewritten for a particular microcontroller to make them both smaler in codesize, more efficient and faster.

6. SIMPL is not a polished final product, but it offers a framework for experimentation and education.  As new hardware or ideas come along, SIMPL can be extended to incorporate them.  The core ideas of SIMPL are easy to understand, and it gives a good insight into how computer languages are written to interact with the hardware.

7.  SIMPL has been developed with the same methodology as some of the tiny languages from the mid-1970s - when computing resources were very limited.  Tiny BASIC, and FORTH grew out of this period.

8. SIMPL can be easily extended to allow for external SPI or I2C peripherals - such as SRAM, sensors.

9. SIMPL needs almost no tools to develop code.  Just IDE with serial terminal.

10. Enjoy SIMPL, extend and modify it if you wish - most of all, have fun!


The Command Set

SIMPL uses single ASCII characters for its commands and integer numbers for arithmetic - this makes the command interpreter a lot easier to write.

Lower Case characters are used for the core primitive functions which are generally built into Flash, and should be present for every implementation of SIMPL.

Punctuation characters and arithmetical symbols are also used as part of the kernel of  primitives.

The choice of primitives was made to make the language memorable and more human readable.

Upper Case characters are "User Words"  - these you can write yourself, test interactively, modify and store in RAM.  On some microcontrollers - they may be stored in non-volatile ferro-electric memory FRAM (MSP430FR series)  or in non-volatile EEprom.

Originally Txtzyme offered just these commands - see Ward Cunningham's Read Me:

a-f      Select an I/O port
h        help - a summary of commands
i         input
k        a loop counter - which decrements each time around the loop  see {}
m       millisecond delay
o       output
p       print the value of variable x followed by carriage return/line feed
s       sample an ADC channel
u       microsecond delay
x       a 16 bit integer variable
{}     code between these braces is repeated as a loop
_ _    characters between the underscores are printed to the terminal

Once you have got Txtzyme ported across to your microcontroller, and have experimented with it, you are well on your way to working with SIMPL.

In the next part I look at how Txtzyme is extended to include the SIMPL framework.

It is likely that this series will be included on a SIMPL wiki - so that all the information is accessible in one place.

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.

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.

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.