Thursday, July 21, 2016

A Perfect Storm

After 11 years of Blogger, I am increasingly frustrated with it's lack of sensible features - like the all important code window.

As such I am looking for alternatives - but for the meantime some recent posts will now be available here:

So long and thanks for all the fish.......

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


Interfacing Memory

I/O Expansion

Graphical User Interface


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.

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.

Sunday, March 06, 2016

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


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


Teensy 3.0, 3.1, 3.2

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.

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

  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

/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  - 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.


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.


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.


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


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.


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.


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.


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.


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


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:


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.


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

Saturday, February 20, 2016

Building WiNode 5 - Part 3

Some five years have passed since the original WiNode design, and WiNode 5 - consider it to be the Anniversary Edition, has tried to build upon some of the changes that have happened over the intervening years. There has been an explosion of low cost wireless modules onto the hobbyist market, WiFi, Bluetooth Low Energy (BLE) and upgraded <1ghz an="" and="" be="" devices="" ism="" latest="" may="" modules="" mounted.="" of="" offers="" onto="" open-platform="" p="" some="" these="" this="" version="" which="" winode="">
More than just an ATmega1284 Platform

WiNode comes towards the end of my involvement with 8-bit microcontrollers - as I move towards 16 bit and 32-bit devices. For this reason it was designed with future proofing in mind.

Whilst a surface mounted ATmega1284 may be soldered to the pcb for the basic board, there is also provision for a 40 pin DIL socket or pair of female header strips to be fitted down the centre of the pcb.  If the ATmega1284 is not fitted to the board, then any other mcu of up to about a 48 pin package - suitably mounted on a small carrier pcb that matches the 40 DIL pin-out,  may be plugged into the board. The 40 pin "socket" is based around the pin-out of the DIL ATmega1284 - so even one of those can be fitted if necessary.

This technique allows the use of a range of small processors, including ARM Cortex M, MSP430 and the like. I already have prototype designs for STM32Fxxx and MSP430 microcontroller variants.

With the upgrade in processor, comes an increase in clock frequency, increase in memory, improvement in peripheral features and speed and often an increase in ADC resolution.

ARM Cortex M4 Variant

For instance, the STM32F373 - a 72MHz ARM Cortex M4 in a 48 pin LQFP package comes with 3 UARTS, 2 SPI, 2 I2C,  up to 256Kbytes of Flash and up to 32Kbytes of RAM, plus a multichannel  12 bit ADC and 3 separate differential input Sigma Delta 16 bit ADCs. The Cortex M4F core comes with floating point and DSP operations. This is the ideal processor for high speed manipulation of analogue sampled data - for example 3 phase energy monitoring.  These processors start at £3.33 in 1 off.

MSP430 Variant

Another interesting processor is the ultra low power MSP430 FR series.  These are a 16 bit processor with 24MHz clock frequency, 12 bit ADC channels, 2 UARTs, SPI and I2C.  The unique feature of the FR series is that they use non-volatile ferroelectric FRAM memory for program and data storage. This allows exceptionally low power operation, retaining data after power down and capable of very fast write access - for high speed programming or datalogging.

Other Interesting Options

There is an increased interest in the use of FPGAs as a means of providing open source soft core processors.  One such option is the J1 Forth processor implemented on a low cost Lattice FPGA - using an open source toolchain.  The FPGA is available in an 84 QFN package just 7mm x 7mm which could be fitted onto the DIL 40 carrier board.

The WiNode 5 Hardware and Peripherals

Here I describe the hardware in a little more detail:

All of the hardware on WiNode 5 is designed to work at a 3.3V Vcc - thus keeping power requirements to a minimum.  Think carefully before you connect to any non- 3.3V shield!

The RFM69 wireless transceiver is still very much fundamental to the design, tracing it's roots to Jean Claude Wippler's JeeNode design - which used the ATmega328 and the RFM12B - and was probably about one of the first commercial wireless connected Arduino variants.

The RFM69 uses D10 for it's chip select, and the new INT2 interrupt that is available on the ATmega1284 - appearing on D8.

In addition to the encumbent RFM69, WiNode 5 also offers an un-committed "X-Bee" footprint (XB1)  This allows any additional wireless device to be added at a later date - based on a shield that conforms to the X-Bee pinout.

One of the biggest advances in the last 2 years is the emergence of very low cost WiFi modules based on the ESP8266 device. WiNode provides a 4x2 connector to allow an optional ESP-01 WiFi module to be plugged in directly so that it can communicate with the mcu using the additional UART 1. Note that WiFi support is optional and not central to the WiNode philosophy. Using a pre-built mass-produced plug-in module is the quickest and cheapest way to give it WiFi connectivity.

The original WiNode used a non-volatile 32Kbyte 23K256 SPI SRAM - backed up by a small super-capacitor.  This feature has also been retained with IC3 a SOIC-8 package, but now the device can be an SRAM of up to 128Kbytes or a ferrroelectric FRAM of up to 256Kbytes. Chip selection is by port B0.

Whilst novel when first introduced on my Nanode RF design of 2011, the micro SD is now common place on many development boards and SBCs.  I have retained the same basic uSD socket - soldered to the underside of the pcb and selected using port D9.

With lower power, yet more capable microcontrollers, there is frequently the need to make portable battery powered devices.  With the emergence of cheap Lithium polymer (LiPo) battery technology, WiNode 5 reflects this with support for an external battery.  This does not need to be a LiPo as an on-board boost converter, IC6, based on low cost MCP1640 allows a single cell to be boosted up to 3V3 so as to power the board.

One of the biggest bug-bears 5 years ago was the crippling cost of placing an FT232R device onto the board in order to allow connection to a PC via USB. Fortunately there are now several much lower cost alternatives available, and WiNode 5 uses the CH340G device in position IC7 - which is available for less that $0.50. It needs a 12MHz crystal  Y3 for correct USB timing.

The ATmega1284 provides a whole additional 8 bit port over and above what the ATmega328 supplies.  Six of these additional port lines are broken out to a header which is placed below the usual 6 pin Arduino "Power" header.  These additional pins are general purpose I/O, but also carry the signals associated with the JTAG interface.

As WiNode 5 uses several SPI devices, the additional port lines C0-C5 can be used to select additional devices on the SPI bus - this offers an easy route for expansion. More on expansion later.

Board Pin Out Details

WiNode 5 has been designed to act either as a stand alone, battery powered, wireless connected controller or monitor,  alternatively as part of a larger system.

//                    _________________________________
//      PC-RXD0 (D0) |o            A7  (D29)          o|A5  (D27)
//      PC-TXD0 (D1) |o            A6  (D28)          o|A5  (D26)
//   * ESP-RXD1 (D2) |o            B0  (D30)          o|A3  (D25)
//   * ESP-TXD1 (D3) |o            B1  (D31)          o|A2  (D24)
//     KBD_DATA (D4) |o                               o|A1  (D23)
//           PD (D5) |o                               o|A0  (D22)
//    MOUSE_CLK (D6) |o                                |
//   MOUSE_DATA (D7) |o                                |
//                   |                                o|VIN
//    RFM_INT2  (D8) |o                               o|0V
//      uSD_CS  (D9) |o                               o|0V
//      RFM_CS (D10) |o                               o|+3V3
//        MOSI (D11) |o                               o|+5V
//        MISO (D12) |o                               o|RES
//         SCK (D12) |o                               o|C5  (D21)
//          0V       |o                               o|C4  (D20)
//        AREF       |o         Open Hardware         o|C3  (D19)
//     I2C-SDA (D14) |o            WiNode 5           o|C2  (D18)
//     I2C-SCL (D15) |o                               o|C1  (D17)
//         ANT       |O                               o|C0  (D16)
//                   |_________________________________|

One of the first applications is that of a retro-computer system using the EVITA graphics driver board (above).  EVITA provides 1024x768 full 24bit colour graphics and an interface for PS/2 keyboard and mouse. It also allows a Wii Nunchuck controller to be plugged in.

With just WiNode 5 and EVITA, you have a complete retro-computing work/play station capable of driving a large screen monitor in just 2 small pcbs.  For portability you can use a Gameduino2 shield and a LiPo battery.

The slight conflict yet to be resolved here is when using the PS/2 keyboard with the ESP-01 WiFi. The keyboard generates a clock which needs to interrupt the mcu via INT1 (D3).

If used with a Gameduino 2 - INT 0 (D2) is also required. This kind of precludes the use of the ESP-01 WiFi - unless a work around is possible.

PCB Layout

WiNode was designed from the start to be smaller than the standard Arduino (Uno) - always considered to be too bulky and "Arty" rather than a simple rectangular board with sensible pin spacing and mounting holes. At 55x64mm it was intended to fit into a readily available plastic case with a battery enclosure. WiNode used predominantly through hod mounted components wherever possible.

WiNode 5 takes advantage of surface mounted components - as it was found that even the through hole parts presented too much of a soldering challenge to the average user.  This means that the circuitry can have a greater density - thus a smaller pcb and be cheaper to assemble - using pick and place machines and reflow soldering ovens.  It is really geared up for the modern electronics pcb assembly processes.  As a result, WiNode 5 packs a lot more functionality into a 50mm x 50mm pcb - some 71% of the board area of it's predecessor.

Whilst WiNode 5 can be hand soldered - it will take a few hours and you really need to be proficient at surface mount detailed soldering, have good light and good magnification available.

The board is based on a 50 mm x 50 mm standard footprint - with the aim of retaining Arduino header compatibility on the smallest pcb possible.   WiNode takes advantage of pre-built plug in modules - such as the ESP-01, the adxl 335 accelerometer module and the X-Bee module.  These can be bought on ebay cheaper than they can be built.