The Lost Blog – Part 3

Following an accidental delete – I have partially recovered the missing blog – and restored it here, as best as possible – on WordPress


Back in May I described a sensor board I was developing as part of a hand held instrumentation project I am engaged in at work.

I am pleased to report that this sensor board is progressing well and we have a new university vacation student working on the firmware – and learning embedded C whilst on the job.

Also new on the MSP430 front, I have received a pair of long awaited, new MSP430FR5994 Launchpad boards, which arrived, whilst I was on holiday.

TI would not ship these to the UK, for whatever reason, – so I had a friend in New York State, purchase them and ship them over.

The MSP430FR5994 is the latest and largest of the FRAM parts with 256Kbytes of FRAM and 8Kbytes of SRAM. The datasheet is here. 

MSP-EXP430FR5994 LaunchPad

The LaunchPad pcb is very similar to others in the series with the programming/debug section included at one end of the pcb, and the target processor, GPIO headers and any application hardware at the other.

As usual, a comprehensive User’s Guide is available, detailing the hardware and numerous software examples are also downloadable.

At a first glance the ‘5994 LaunchPad includes a microSD card, a 0.22F supercapacitor, two LEDs and two switches as the User Application Hardware. Two rows of (2×10) headers allow access to the GPIO signals and power, and accept the expansion shields known as Booster Packs.

Preloaded Firmware.

As with all LaunchPads, the ‘5994 comes with a couple of preloaded firmware examples that illustrate some of it’s key capabilities.  For the ‘5994 these are dataloggers for both the microSD card and for the FRAM. Details are in the User Guide.

In addition the pcb design files have been open-sourced, and are available in EagleCAD format. This is a recent move by TI, which I believe makes them a lot more accessible to the open source and Maker communities.  With EagleCAD reference designs available, it makes incorporating the MSP430FR5994 into new hardware a lot easier.


This is the first of the MSP430 series to have a big chunk of FRAM, and a reasonable amount of SRAM. TI have produced a Guide to FRAM

FRAM is considerably faster to write than Flash by up to 100 times faster, and the ‘5994 can write to FRAM at 16 Mbytes per second. 64KB can be written in 4mS.  This opens up some interesting possibilities for a self-hosting Forth machine, with very high speed compilation and large dictionary space.

Writing to FRAM is also very low power compared to Flash memory – and can be done whilst the device is running from a supercapacitor or back-up battery.

FRAM does not suffer from wearing out by excessive writes in the same way as Flash – the FRAM is good for 10E15 writes before failure.

Incorporating a large FRAM on the microcontroller means that other system components are no longer needed, saving on RAM and Flash.

The large FRAM can be used for storing data and tables such as display fonts and Icons – which can readily be updated.

A FRAM based instrument.

As I am in the process of creating a new hand held instrument, the low power FRAM will be ideal for datalogging and holding display fonts.

My sensor board based on the MSP430i2041, designed in April, will provide up to four 24 bit ADC channels, communicating over UART or SPI with the ‘5994 which will be the datalogger and display controller. This pairing of two microcontrollers will provide the best overall solution, and at a very reasonable cost. The MSP430i2041 is $1.99 in 1000 off – which is a fraction of the cost of providing equivalent 24 bit ADCs by other means.

The MSP430FR5994 is currently only available on a Launchpad development board – but will be on general sale later this year.

Here is a great opportunity to get a head start on a very interesting new microcontroller technology.

0 0
myStorm uses a unique low cost approach to provide system integration

I had been wanting to create an FPGA board for some time – especially now since Clifford Wolf’s open source ICE Storm toolset is available.

The opportunity presented itself, when following a discussion with Alan Wood, over a post-OSHUG beer, we decided that we would produce a small FPGA board using the Lattice ICE40HX4K part.

This would hopefully be produced in time for the September OSHCamp – held in Hebden Bridge, near Halifax, Yorkshire.

We wanted a “no-nonsense” FPGA development board that would encourage open source hardware enthusiasts to take their first steps with FPGAs and verilog or VHDL.

The board had to be 2 layer, fit the size constraints of EagleCAD Lite, and use components that could be soldered at home – by those DIY’ers experienced with Surface Mount parts.  For this reason we chose a 144 pin package for the FPGA rather than a BGA – as these are not very friendly either for 2 layer pcb layout, or for soldering.

Alan did the preliminary system design, whilst I looked at finding an efficient means of routing the SRAM to the FPGA for minimum signal skew.

After several Saturday lunctime pub-meetups we settled on an overall design last weekend – that will go for prototyping towards the end of this week.

Low Cost – Achieving a price-point breakthrough!

Seldom do you get much of an FPGA board for under $50 – with the $22 Lattice ICE Stick setting the current lower limit.

But this  ICEStick was limited by the HX1K part, and very little accessible I/O.  Like a lot of FPGA boards, it also used the FT2232 USB to serial bridge to provide programming and communications, but at around $5, to me has always seemed a rather expensive solution.

Connectivity was a key feature, and so the board uses some old familiar friends – including Arduino “Shield” headers to provide a rich mix of GPIO, 12-bit ADC and communications – including USB, UART, SPI and I2C, as well as providing a large flash array, into which a bitfile could be stored.

The  industry standard connector for FPGA dev-boards is the PMOD connector – devised by Digilent – so our board has several of these available.

Finally, another recent ICE40 FPGA board by Olimex has defined a connector for low voltage differential signalling LVDS – and so this 34 pin connector was added as an alternative to the PMODS.

The Olimex board uses a HX1K part which is about $1 cheaper, but we felt that this might be a bit small – so we opted for the HX4K part. Olimex use a 256K x 16 SRAM, and we have stretched this out with an extra address line to allow for 512K x 16 SRAMs.

Some of the design requirements – summarised:

1.   Open Source
2.   Low cost – suit even the smallest budget – about $30
3.   Compact 75x75mm – but with a useful range of signals available
4.   An onboard ARM for handling USB comms, GPIO and ADC channels and FPGA loading
5.   FPGA should be in an LQFP package – for easier layout and possibility of home assembly
6.   A fast 64K x 16 SRAM (512K x16 max)  to allow soft core cpu development
7.   PMOD and double PMOD connectors
8.   Arduino compatible shield headers – giving 5V tolerant GPIO and peripherals
9.   A cable or direct connection to Raspberry Pi or Pi Zero
10. A connector to directly drive 32 x 32 RGB LED panels

myStorm is a unique combination Pi Zero, of a fast 32-bit ARM microcontroller and a versatile low power FPGA.
The Raspberry Pi Zero – which hosts all of the FPGA development tools, provides an integrated design environment for FPGA and ARM  – aimed at a new concept in hardware hacking projects.
The Lattice ICE40 series FPGA with a large SRAM attached, connected to an ARM M3/M4 Cortex microcontroller provides the ideal platform for developing soft core cpu designs.
The ARM holds the bit-file for the FPGA in flash,
The ARM M3/M4 Cortex provides a USB interface to a PC, plus the following I/O & peripherals:
72MHz/96MHz/108MHz  64 pin ARM Cortex M3/M4 processor:
Arduino compatible with STM32-Duino extension
256Kbytes Flash
32Kbytes SRAM
Up to 37 GPIO lines with 5V tolerance
Up to 10 ADC inputs with 12bit 1MHz ( 2 ADCs)
Three 16bit differential input SD-ADCs (optional)
2 I2C
Lattice iCE40HX4K  – 144pin LQFP package
Up to 64 I/O lines  – arranged on industry standard PMOD ports
Choice of 64K or 512K fast (10nS) SRAM
Can use ICE Studio graphical design environment.
Pi Zero Host Port
Standard Pi 40 pin (2 x 20) GPIO header – allows easy attachment of Pi-Zero for programming and development
Compact 75 x 75mm
ARM Section
Wide assortment of GPIO brought to Arduino shield connectors
6 Analogue Input Lines AN0 – AN5
UART (with bootloader facility) TX, RX
Up to 18 digital lines – including I2C and SPI
Up to 3 differential input 16 bit ADC channels (If STM32F373 fitted)
USB 2.0 connection for programming, data and power
8 bit bidirectional bus interface to FPGA and Pi – Zero with handshaking lines
SPI bus for programming FPGA from bit file
FPGA Section
5 double PMOD connectors
8 bit bidirectional bus to Pi-Zero and ARM
LVDS to “Olimex” style 2 x 16 connector
2 x 8 header for direct connection to 32 x 32 RGB matrix display.
100MHz clock oscillator
64Kx16 fast SRAM
Pi Section
Standard 2 x40 GPIO header for Raspberry Pi GPIO
EEPROM for PIHAT identity
Efficient dual voltage switching regulator
4 USER buttons
BOOT switch
All I/O on 0.1″ grid – wherever possible
1. As a stand alone versatile application controller
2. As an advanced Analogue and Digital  I/O board for the Raspberry  Pi and Pi Zero
3. As a teaching platform for learning 32 bit ARM and FPGA programming.
4.  As a platform for developmenting Open Core cpus on the FPGA
5. For high speed digital instrumentation – such as DSO or logic analyser

Cost Reduction

Keeping the cost down was a primary concern, yet we wanted to make a board that was genuinely useful.

To achieve this, Alan came up with a unique strategy:

1.  Low cost FPGA with open source tool chain
2.  Low cost ARM – to act as “system integrator” and glue.
3.  On board Pi Zero – to host the open source FPGA tools – user supplies this at $5.00

Having settled on the ICE40HX4K – as the largest ICE40 available in an LQFP package – and thus more easily routed on a 2 layer board than a BGA part, we set about identifying the other key components.

Having seen James Bowman’s J1a Forth Processor – a soft core running in an ICE40HX1K part, I wanted to add a fast (10nS) 16 bit wide SRAM – which in a TSSOP-44 package allows parts between 64K and 512K words. With this combination comes the ability to create a number of soft core processors, of which the 16 bit simple processor described in the “Nand to Tetris” course would seem a very suitable candidate.

Other applications include digital instrumentation that require large arrays of fast memory – such as digital oscilloscopes and logic analysers.

The lynchpin in this design is the use of a low cost ARM device, not only to provide USB communications,  storage (in flash) of the FPGA bitfile, plus provide a series of ADCs and  5V tolerant GPIO pins and peripherals to augment the FPGA architecture.


We believe that if an FPGA board sells for around $30 then it will attract a fair bit of attention.

This was going to be tricky – so we set ourselves a BOM on a very tight budget of arount $10 based around the principal components – costed in 100 and 1000 off quantities:

            100 off            1000 off

FPGA        $5.56               $5.37
ARM         $1.20               $1.00
SRAM        $1.69               $1.22
PCB         $0.88               $0.49
Connectors  $0.50               $0.40
Remainder   $0.50               $0.40

Sub Total   $10.33              $8.88

LOP         $2.58               $2.22

Total       $12.91              $11.10

Pi Zero     $5.00               $5.00

So in 1000 of quantity, the BOM and manufacturing (LOP = Labour, Operations Profit) comes to a total of around $11, which allows a selling price of about $30.

The customer provides their own Raspberry Pi or Pi Zero, from as little as $5.00.

This post comments on the rise in popularity of FPGAs in the hobbyist & maker communities – thanks to some open source tool chains.

For many years, the FPGA silicon vendors, Altera, Xilinx and Lattice have made sure that their FPGA tool chains were anything but open – remaining either chargeable, licence locked and always proprietary. This strategy has rather restricted the uptake of FPGAs within the hobbyist community – where budgets are tight.

The situation improved a few years ago, when all of the major vendors released free to use tools, for example the Xilinx WebPack, which allows design, compilation, and programming of at least some of the low-end ranges of devices, leaving the premium ranges still chargeable.

However the bottom line still remained – that if you wanted to get into FPGAs, the tools are restricted and an entry level FPGA development board would cost around $100.

Fortunately, due to the work of several dedicated individuals, the previously impenetrable fortress, that was FPGA development has now been breached by the open source community. Moreover, as FPGA devices represent the embodied interface between software and programmable hardware, it has brought together both the open source software and open source hardware communities.

The Breakthrough

The FPGA marketplace is dominated by two rival companies, Altera and Xilinx, both of whom hold close to 45% of the world sales, and whose primary business is to sell high end FPGAs and licenced toolchains.  Lattice Semiconductor, on the other hand, who are are the 3rd minority party, appear to be focusing on low cost, low power FPGAs aimed at portable, mobile and battery powered applications.

Lattice’s sales strategy is reflected in their development board offerings – starting at about $20 with the ICE40HX1K “IceStick” .  This is an entry level dev-board in the form of a USB stick which has some LED indicators and a few GPIO pins broken out to a PMOD connector and a pair of headers. In addition to the ICE40HX1K FPGA, there is the familiar FTDI 2232H dual channel USB-serial interface IC, which provides the programming and debug interface to a PC, plus a serial communications port.

The breakthrough to increasing the availability of FPGAs to the hobbyist community came as a result of lower cost entry level hardware platforms, plus the reverse engineering of the Lattice serial bitstream format, which is used to program the FPGA device.

This was achieved by a small group of dedicated open hardware enthusiasts in Project Ice Storm – headed by Clifford Wolf.

In this recent video from the 2015 CCC,  Clifford Wolf explains the Ice Storm tool chain.

Ice Storm is just one module within a tool suite consisting of the following modules

YoSys – Verilog Open Synthesis toolsuite
Arachne-pnr    – Place and Route
Ice Storm
IcoBoard   – a low cost ICE408K dev board – in Raspberry Pi-HAT format.

YoSYS  –>  Aranchne-pnr –> IceStorm –> IceProg

In a nutshell, Ice Storm allows some Lattice FPGAs now to be programmed using an entirely open source tool chain, running under Linux, and hosted on a low cost platform –  for example a Raspberry Pi.

The arrival of IceStorm has heralded a new wave of low cost FPGA boards – based on the Ice40 series – here’s the latest round-up:


NandLand Go Board 

Cat Board

These are likely to be the first of many similar boards – now that toolchains have been reverse-engineered and oped sourced.

0 0

Small Is Beautiful

At just $2.40 Nano 3 packs an Arduino into just 45 x 18mm!

I bought my first pair of Arduino Nano boards back in 2009, and I remember paying about £20 each for them.

As we all know, hardware has tumbled in price over the last few years, so I was pleasantly surprised to pay just £5.00 each for a pair that I bought this week, from UK ebay vendor Squirrel Labs. They would have been a fraction of this price had I bought them direct from the Chinese supplier.

The boards turned up within 2 days – which was great, because I desperately needed them for this weekends making activities.

The pcbs are produced by a familiar Chinese supplier “Baite Electronics” – whom I have used in the past for their STM32F103 “Maple Mini” clone.  Despite being ” a bit rough around the edges” – where the pcb had been V-scored and left rough – easily cured with a rub on some fine wet and dry sandpaper, the boards were of otherwise high quality.

The reason for the price reduction, is that the clever Chinese have finally engineered their way out of being held to ransom by FTDI.  See this Hackaday Article

Nano 3 uses the CH340G USB-UART converter IC (right)

These Nano clones use the CH340G  USB to serial converter IC, which is claimed to cost as little as $0.20 in China.  The boards worked straight out of the packet – and my Windows 10 desktop had no difficulty locating and installing the driver for the CH340 VCP.

The CH340 means that it is now easy and very cheap to add USB connectivity to any microcontroller which does not already have it on-chip – or to add a second comms port to a microcontroller that has a spare UART or even bit-banged serial GPIO lines.

I found a datasheet for one of the CH340 devices via Olimex, but my part, the “G” variant, is a 16 pin SOIC – and the datasheet is here.  There is a useful application note showing the CH340G being used as an opto-isolated USB to UART interface – which I reproduce below:

This can be very useful – especially if you are working on mains-powered equipment – and need an “FTDI” cable output for programming or debug.

There likely to be many more applications for the CH340 forthcoming – now that it is no longer cost prohibitive like the FT232, and that Blogger Ian has produced EagleCAD libary symbol and footprint for it. An ebay search of CH340G will turn up several sources – for about £0.35 or $0.50 each.

FTDI  FT232  R.I.P.  The cheapest I could buy a FT232 in 1 off was £2.84 +VAT).

So at last we have a USB-UART bridge that doesn’t cost a fortune – and being a 16-SOIC package, it’s fairly easy to solder to the board by hand.  With this small, yet signficant device – we are well on the way to price eroding the cost of microcontroller hardware.

BTW – if you are a Mac User – you might want to read this blog for details on how to get the CH340 working and the source of the signed driver.  Thanks to Dave CJ  (@ceejay) for pointing that one out to me.

I had a quick look at the BAITE website – and was pleased to see a pack of 10, ATmega328P-PU Pro-Mini clone boards for just $15.  At that price you can use a pro-mini for all your latest projects – for a fraction of the price it costs to buy an ATmega328 in the West.  I also looked up their Nano 3 – again only $2.40.

Which brings me onto a minor rant about the extortionate costs of hardware produced in the West. An email earlier this week from Sparkfun Electronics caught my attention – advertising their latest “Red Stick” product.  This is essentially an Arduino Nano clone fitted with a boost regulator – worth about an additional dollar.  How on earth do Sparkfun expect people to pay $24.95 for this product?  Come on Nathan, buck your ideas, or expect to be trampled under a stampede of similar products from China – for under $5!   And whilst on the subject – please take note that Arduino are still trying to charge $20 for the original Nano!  I think that this is probably because they are no longer manufactured in volume in the west – and so have become very expensive.  I saw Protopic asking nearly £40  ($56) for one!

So the humble Arduino Nano has found a new life in the East, and seems to be thriving.  In addition to his cousin Pro-Mini, what other small microcontrollers are emerging from the East?

I covered the STM32F103 boards back last year,  and then there is the Teensy – also a good board.

Chinese IC firm, Giga Device have “copied and enhanced” the range of STM32F M3 Cortex microcontrollers and increased their clock speed to 120MHz. Some of these GD32F103 boards are now available on the market – so if you want a 120MHz board with 12bit ADCs that can be programmed with the Arduino IDE – then these may be of interest. Roger Clark of stm32duino explains in his blog.

ARMiGo Updated

Stretched Nano?  No it’s ARMiGo 5 – Updated to include ESP8266 WiFi Port

Having used the Nano in a couple of small projects, I like the DIL format microcontroller dev boards – they are breadboard friendly, compact and easy to use.

Since I have recently updated my general purpose wireless board, WiNode, I like the ATmega1284P in it’s 40 pin DIL package – again partly because of it’s breadboard friendliness, and the fact that the power pins are arranged in the centre of the package – such that if you get the package in the wrong way around  – you don’t fry the IC!

Back in March 2014, I designed a 40 pin DIL breakout board for the STM32F303 microcontroller called ARMiGo.

Shortly after that, I discovered that the Maple Mini, a very similar STM32F103 board  – also in a DIL format, was available very cheaply from China.  I addition, Roger Clark of stm32duino had been working on implementing “Arduino” on the STM32.

Now it’s time to revisit ARMiGo, and to bring it up to date and in keeping with my generic small microcontroller footprint.

The 40 pin footprint breaks out 32 GPIO lines in four 8 bit ports, nominally called A, B, C and D.

This format ideally suits the small LQFP microcontrollers  – up to and including 48 pin packages.

As I have been working on a 50x50mm breakout board for the ATmega1284P – so I decided to kill 2 birds with one stone – and use that 50×50 board to act as a generic carrier for any of the smaller microcontrollers.

So the task in hand was to make the footprint of ARMiGo look exactly like the 40 pin DIL version of the ATmega1284.

Extra Features

ARMiG0 5 is fitted with a STM32F373CCT6  offers the following – over and above that of the ATmega1284 (ATmega1284 spec in brackets)

  • 256Kbytes Flash memory  (128K)
  • 32Kbytes SRAM  (16K)
  • USB  (no USB)
  • 8 x 12 bit ADC  (8 x 10bit ADC)
  • 3 x 16 bit differential input ADC  (none)
  • 72MHz clock  (20MHz)
These extra resources make it an ideal candidate for an upgraded microcontroller for the Open Inverter project. The 16 bit differential SD-ADC channels are ideal for making simultaneous 3 phase power measurements.
Now comes the task of moulding the available peripheral features – so as to provide the best fit to the ATmega1284 footprint – and also my 50×50 board.
The 12 bit ADC channels can be allocated directly to the PA0 to PA7 pins.
The 16 bit SD-ADC inputs can be connected to the PC2 to PC7 pins
The SPI port, I2C port, USART1 and USART3 –  all have direct equivalent pins on the ATmega1284 DIL footprint.
Crystal, Vcc, GND, AVCC, AREF – all these map directly

That just leaves a few GPIOs left to allocate to Port B and Port D.

The proposed layout is shown above.  I have included a 4 x 2 header allowing the ESP8266-01 WiFi module to be plugged straight in.

Tiny Languages – for Tiny Boards!

It’s a couple of weeks since the first part of this thread reviewing some Tiny Languages where I looked at some minimal BASIC and Forth-like languages.

Inspired by these examples,  I wish to show how Ward Cunningham’s Txtzyme interpreted language can be easily modified adding more features and functionality.

The aim is to have a tiny, generic language that can be embedded into the bootloader of any common microcontroller – providing a minimal operating environment from start-up.

What will such a Tiny Language require in terms of features and functionality?

Wish List

Any small language must provide a minimum vocabulary to be useful.  Here are some thoughts on the bare essentials:

Arithmetic and Logical Operations   + – * /   AND, OR , XOR, INV
Memory Operations – including loading, storing, saving to disk, and bootloading the flash or EEprom
Program flow control – decision making – branching  (IF, THEN, ELSE, SWITCH-CASE etc)
Looping  (DO WHILE,   FOR- NEXT etc)
I/O commands  (digital read/write  analogue read, pwm, etc).
Timing, delays, and scheduling operations (mS_delay, uS_delay, millis()  etc)
Peripheral support – eg UART, SRAM,  uSD, keyboard, mouse, graphics etc.

We also need as a minimum of system support for the language kernel:

Keyboard for text entry,
Terminal output  (serial UART routines)
Text Editing  (line editor)
Hex Dump
Screen listing of code in RAM

With these facilities we can at least enter, edit and run code using a serial terminal application and get output text to screen.

At a higher level – for a stand alone computing environment we need permanent storage to disk and some tools to make life easier:

Disk operations, File Handling (on microSD card)
Graphical output to monitor.


Txtzyme offers a small, understandable, elegant and flexible core with UART communications, analog and digital input and output and delays and timing functions. It is almost the ideal platform on which to base other code.  I have prepared a stripped down version of the Txtzyme interpreter kernel – which compiles to just 658 bytes. It is available here.

At the moment the cut down kernel doesn’t do very much apart from allow a decimal number to be printed out using  the “p” command. However, it represents about the minimum needed to support a UART interface, scan a text buffer and execute commands.  Additional commands are added in the switch-case statement within the textEval() function.

This led me to a series of experiments in which the features of Txtzyme were extended – which resulted in SIMPL (Serial Interpreted Minimal Programming Language).

SIMPL has been ported to several microcontrollers – including MSP430, STM32F103, STM32F373, ‘ 407 and ‘746 – as well as an FPGA softcore processor called “ZPUino”.

SIMPL offers an easy way to interact with hardware, to compose new functions and to schedule functions to be triggered either sequentially or at regular intervals.  It is based on the Txtzyme core functionality – about 1Kbytes which gives a basic communications channel, text entry and display and the means to exercise common microcontroller hardware peripherals.

Adding Maths and Logic Operations

Txtzyme only used a single 16 bit integer variable x, as a control parameter for the coded functions. Whilst this was OK for running loops, reading the ADC channels and toggling I/O it was a little restrictive.

The first extension to Txtzyme was to create the means to have a second variable y.  This immediately allows simple mathematical and logic operations to be performed.

Arithmetical    + – * /  %
Logical            AND OR XOR NOT
Comparison    < >

In Txtzyme, typing a number at the keyboard, with a serial terminal application causes the interpreter to decode the number’s ascii string and place the number into the single parameter variable x.  x can then be used to access I/0, set up loops and delays and other functions.

In SIMPL,  there is a second parameter variable y, and this is used to hold a second operand.


456 123+p  (note the space between 456 and 123)

This pushes 456 into x and then the space is SIMPLs method of moving x into y, so that the interpreter is free to accept the second number 123 into x. In the above example  123 is added to 456 in x and the result printed with p.

This arrangement is a kind of pseudo-stack of just 2 levels x and y, and note that unlike a true stack, y does not move up to occupy x when x is printed out.  Perhaps it should be thought of a s a machine with 2 registers  x and y, and “space” is equivalent to mov x,y.

Additional registers could be added but there is  the complication of naming them.

With 2 registers we can now do simple maths, memory addressing and logical and comparison operations.

The addition of these arithmetical and logical operators adds a further 360 bytes to the kernel.  This seems quite a lot for just 9 functions – and so at this point I began wondering whether the extensions to the kernel might be best done in AVR assembly language.  You may recall that an AVR instruction takes up 2 bytes of flash memory – so my C code case statement selection structure is using on average 20 instructions (40 bytes) per command.  (MUL, DIV and MOD will be more).

Whilst Txtzyme was purely a 16bit implementation, if x and y are cast as long integers, then all operations are extended to 32 bit. This however increases the code size by around 625 bytes (as the 32  bit mats operations all take up more code to implement in C).

It would be possible to make a more compact version of SIMPL by coding up the routines in AVR assembly language rather than C. Having studied the TinyForth code structure – the primitive execution structure is coded such that the commands occupy an average of 24 bytes (for 29 commands).  This would result in a 40% reduction in codesize – so is well worth considering.  The topic of coding SIMPL for assembly language plus an analysis of the SIMPL virtual machine will be covered in a later post. It might just be time to fire up Atmel Studio and start writing some AVR assembly code!

Memory Operations

In keeping with Forth parlance  the basic memory operations are Fetch @ and Store !  These effectively are the equivalent of Peek and Poke – and operate on a 16 bit wordsize. With fetch and store there is now the means to take a number off the stack and place it anywhere in RAM, or conversely take a word from RAM and place it on the top of the stack.  The exact location of the storage could be derived from a variable’s name, or it could be in a set of easily accessed named registers, eg. R0, R1, R2…..

Text Input and Output

Txtzyme offered a very simple mechanism of loading up a character buffer with the inputted text from the UART serial communications. It would carry on filling the input buffer until a newline character was found, or the end of the buffer was reached.  The input buffer essentially held the whole Txtzyme phrase, and on detecting the newline character would begin to interpret each character in turn, decoding it and calling the various functions associated with each character.

When I wrote the first draft of SIMPL, I realised that I could store the inputted characters into any buffer I wished, by redirecting the input characters to a new named buffer.  I used uppercase ASCII letters for these buffers, named A through to Z.  When I wanted to redirect the input characters to a new named buffer, all I had to do was use a colon : at the start of the line, followed by the naming character  – eg M.

:M   – the start of a new buffer called M

I chose for convenience to make all of these buffers the same fixed length (48 bytes), so that the start address of the buffer could easily be calculated from the ASCII code of the letter.

In this example M is code 77 in ASCII, and A is 65, so it’s easy to allocate 48 byte buffers, just by multiplying up the ASCII value by the 48 byte length of the buffer, (plus an offset).

It becomes clear that these named buffers are in their own right small snippets of code – in effect subroutines, and in order to execute the subroutine it’s just a case of typing it’s naming letter.

Txtzyme subroutines are by their very nature quite short, and it was easy to fit almost everything that might conceivably wish to be done into a few tens of characters – hence it was found that 48 was a good size for the buffer – especially when the Arduino only has 2K of RAM to play in.

Forth readers will recognise this as a very crude means of creating a colon definition, storing the definitions executable code at a fixed address in memory – based on the ASCII name of the routine, and being able to effect a simple jump of the interpreter to that routine.  It’s a little like the restart RSTxx instructions on the Z80/8080.  A few restart addresses that the program counter could be set to, in order to quickly call the most commonly used subroutines.  In our case we have 26 to make full use of!

A “line printing” command to print out a string of the stored text from memory is the underscore character _  This is used as a pair surrounding the text message to be output for example

_This is a message_

We could include this with the previously defined “M” as follows

:M_This is a message_

The text handler would save this in the buffer associate with M, and every time the interpreter encountered the letter M it would print out the message

This is a message

Displaying and Editing Text

In a microcontroller system with only 2Kbytes of RAM, much of this can be taken up with the screen buffer – after all a 25 line x 80 column screen is 2000 bytes!

In a language such as Txtzyme and SIMPL, the source code has been tailored to consist of printable ASCII characters, with some degree of human readability.  The system can easily perform a memory dump to the screen – which is effectively a program listing.

As the program consists of short subroutines threaded together, it would be possible to have a single stepping mode, where a cursor is highlighted as it steps through the current code. With a 115200 baud serial connection, the whole screen of text could be refreshed 5 times per second, more if only the active code is displayed.

Editing text is probably best done on a line by line basis.  A line that requires editing can be brought up using the ? command and then copied into the input buffer, changes made and then pasted back to memory.

Some Forth systems use 1Kbyte blocks for storing and presenting their source code. A similar approach could be employed with SIMPL, with a block command to bring up a numbered block to the screen.

SIMPL is expressed as a series of tokens for compactness in memory and convenience of not having to scan for whole words – however there is no reason why it could be expanded to a more verbose format for screen listings – for example each lower case ASCII character could be expanded to a more easily read format.  The table to do this would be retained in flash ROM – something that there is no real shortage of.  For example:

b    BLOCK
c    CALL
e     END
f     FOR
g    GOTO
h    HIGH
i     INPUT
j     JUMP
k    COUNT
l     LOW
m   mS_DELAY
p    PRINT
q    QUIT
r     RETURN
s     SAVE
t     TIME
u    uS_DELAY
x    1st operand
y    2nd operand
z    SLEEP

All of these will fit into 8 characters – so the additional space needed for the verbose form is 26×8 = 208 bytes

In Summary – So Far

So we have a language largely represented by single character instructions which when decoded by the interpreter cause a jump to a subroutine that defines the program’s action. These character command words may then be assembled into sequences or phrases and stored into named buffer spaces for execution. New phrases may be compiled and stored at fixed addresses for later interpretation and execution.  There is the means to enter and retrieve text from the RAM either by loading and storing single characters or numbers, or by using the text handler and the string printing command.

In Part 3 we look at the program flow control structures like LOOPS, SWITCH-CASE and constructs made up from conditional jumps.

Last time I explained how to add more functionality to Txtzyme to build up a more versatile language that I call SIMPL.

In this post I look at a couple of ways to perform program flow control.

The latest version of SIMPL is located at this Github Gist  – and includes the code below.

The 16 bit maths version compilese to 2268 bytes, whilst the 32 bit version, with it’s more complicated 32bit maths routines adds a further 624 bytes.

Program Flow Control

So far, SIMPL lacks many of the usual program flow control constructs:





1. Simple Loop

SIMPL has a simple loop construct – where a block of code can be repeated k times before exiting the loop.

10{kp_ Green Bottles_}

This initialises the loop counter k to 10, and prints it out along with the text Green Bottles, decrementing k each time it goes around the loop.

This is similar to C’s    while(k)      // k>0
{ some task;
k– ;

When executed, you will get this screen output:

9 Green Bottles
8 Green Bottles
7 Green Bottles
6 Green Bottles
5 Green Bottles
4 Green Bottles
3 Green Bottles
2 Green Bottles
1 Green Bottles
0 Green Bottles


It is also reminiscent of the old Z80 instruction DJNZ, in which the B register was decremented and a relative jump to a label if it was non-zero.  In SIMPL we effectively have 26 labels – the capital letters A to Z so this could be quite a useful feature.   Loop can be used for any repetitive output task – such as flashing LEDs or playing musical tones.

The next construct required is the conditional jump.  Here the number on the top of the stack, x should be compared against a constant y and a call to a block of code executed whilst the comparison remains true.

We have the means to perform logical and comparison operations on the top value of the stack.

AND   &
OR      |
XOR   ^

These perform bitwise logic on the x and y operands.

AND may be used to check if  x != 0   as it returns 1 for any value of x other than zero
OR can check if x = 0
XOR  can check if x != y

Greater Than  >   if  x > y  return 1
Less Than      <   if x  < y  return 1

Any of these operations may combined with a skip operation – skipping over the next operation if the result is true.

Here’s the C implementation of the  SIMPL comparison and jump operators:

// Comparison Test and conditional Group

case ‘<‘:
if(x      break;

case ‘>’:
if(x > y){x=1;}      // If x > y x= 1 – can be combined with jump j
else x=0;

case ‘j’:                  // test  if x = 1 and jump next instruction

So we want to turn these simple comparisons into a more familiar IF-THEN construct.

The block of code to conditionally execute will be enclosed within square brackets  [   ]

If the result if the comparison is true – then the code withing the brackets is executed, if false, the interpreter skips the words until it finds the last bracket and then resumes execution there.

Example   If x > 10 then print “x greater than 10 ”

11 10 >[_x greater than 10_]

11 assigns 11 to x
“space” moves x to y
10 assigns 10 to x
>  performs x >y
[   tests x for true
_x greater than 10_   prints the message
]  marks the end of the conditional execution block

Case Selection

The switch-case statement is a powerful mechanism in C, can it be easily implement in SIMPL?

We could restrict the number of cases to 26, allowing any of the capital letter words to be accessed directly.

Alternatively, we could select a phrase of code from a list of options – based on the value of x. This second methods is more general and is a lot more flexible, as it can incorporate the first method.

We need a pair of balanced characters to instruct the interpreter that we are looking at a list –  so we could use simple parentheses and comma separated elements as follows (, , ,)

We then do a selection of the elements based on the numerical value of x.  The interpreter then jumps into the array, skipping over the entries until the correct one is found.

As an example, the word M is code for _This is a test Message_

5(0p,1p,2p,3p,4p,M,6p)  should select M and print the associated message

A second example adds two integers and prints the message if the result is 3

1 2+(0p,1p,2p,M,4p,5p,6p)

The mechanism to do the skipping can be quite elegant using some simple rules:

First, the value of x is copied into the loop-counter variable k.
If k > 0 the interpreter checks each character in turn incrementing the buffer pointer. If a comma is detected, signifying the end of the first list entry , k is decremented.
If k is zero, the interpreter executes the following table entries until the next comma is detected, this also subtracts one from k forcing it to be less than zero, this condition then forces a break out of the list.  If the final ) is found – this also forces a break out of the selection statement.

This construct is derived from the SIMPL Loop method. We provide C code for two new case statements “(” and “,”

// Select the xth member from the list
// Example 5(0p,1p,2p,3p,4p,5p,6p)  should select 5 and print it

case ‘(‘:

k = x;                                                 // copy x to use as the “phrase counter”
while (k)
ch = *buf++;
if (ch == ‘,’)                                       // decrement k to see whether to interpret or not
{ k–;}

case ‘,’:

while (k0>
ch = *buf++;                                    // skip the remaining characters
if (ch == ‘)’) {break;}


This technique could also be used as a look up table, where a given x is converted into a different value according to a list of numbers.


This will select element 10 (300) and print it. Note that the first element is zero!

0 0
Two weeks ago, I posted about an update to the WiNode, well here’s that long awaited update – now that I have finished the pcb layout and submitted it for manufacture.

The board has had some radical design changes since the first conceptual design – and hopefully I have got a very flexible platform for control and datalogging applications.

In it’s original form, the layout proved a little too complex for the size of board available – which meant that it was a real pain to route.  So I tried dropping tracksizes first from 10 thou to 8 thou and then from 8 thou to 6 thou.  I then realised that it was still going to be a routing nightmare, so I came up with a Plan B, which was to ditch some of the more complex functions and come up with a good all round ATmega1284 board.

So I retained the RFM69 wireless module and the microSD card, the RTC, and 32K battery backed SRAM but unfortunately the dual H-bridge just has to wait for the next bus.  This means that the ATmega1284 design will not be held up waiting to get a very tight route done.

A Slimmed Down WiNode 5 Board – initial component placement.

I managed to spend most of my free time in the evenings and weekends of the last couple of weeks fighting the EagleCAD autorouter.  In the end I decided that the pcb was just too hard to route with the available tool and algortithms, so I decided that there was only one final solution – and to route it by hand.

Latest Update – February 4th 2016

So here is the latest design, still a 50mm square board with all if the ATmega1284 pins brought out to a standard header format.  It can still connect to two of the Open Inverter power boards, which was the original design brief.

There is also a footprint towards the top of the pcb bsed on the X-Bee, which will accept any plug in wireless module on a carrier pcb. In addition, you may notice the outline of a 40 pin DIL socket. This will allow the DIL version of the ATmega1284P to be plugged into a turned pin socket.

After the culling of the Real Time Clock, the 32K SRAM and the dual H-bridge there has been a partial reprieve  – the RTC and SRAM have been re-instated, as has the boost regulator – which allows the board to run off a lithium cell, or even a single 1.5V alkaline cell.

Earlier in the week I wrote about the CH340 USB to serial converter IC. I have included this and a mini-USB B connector – located in the top right corner of the pcb.  This means that the board will run from multiple power sources for maximum flexibility of applications.

The almost final design after 12 hours overnight session of hand-routing!

Job Done!

After some serious burning of the midnight oil, I pushed the remaining tracks into a layout that I (and the EagleCAD DRC) was happy with (see below) and the Gerbers have been sent off to Ragworm – my local pcb supplier.

This is probably the last 8-bit/AVR board that I will do, as it kind of creates the platform that I wanted some years ago.  The extra 16K of RAM on the ATmega1284 will make it useful for bigger, more demanding applications, and the ability to accept wireless and WiFi modules from a variety of sources should make it useful – for example as an RFM69 to ESP8266 bridge.  The uSD card for datalogging and the RTC for turning things on at given times of day have it destined for all my old favourite central heating controller projects – and within a few weeks I should have a relay shield laid out for it.

The board also has been designed to be compatible with the EVITA graphics engine I designed over Christmas – and that has the means to provide high resolution colourful graphics on a big screen – and I must admit that I’m looking forwards to some big, bold colourful chunky graphics and some neo-retro computing projects.   The ATmega1284 is compatible with GameDuino2 – and so can leverage off of that graphics library. The 2 board stack of WiNode plus EVITA will make a great little retro platform – with PS/2 keyboard and mouse interfaces and the means to accept a Wii Nunchuck controller too!

Final Design Specification

ATmega1284P  with 128K Flash and 16K SRAM – either SMT package or 40 pin DIL package.
microSD card socket on underside of pcb
32Kbytes battery backed SPI SRAM (Microchip 23K256)
Real Time Clock / Alarm / NV RAM  (Microchip MCP79410)

Hope RF RFM69 low power wireless module (433 or 868MHz)
Socket to accept ESP8266-01 WiFi module
Socket to accept X-Bee or any pin compatible device

CH340 USB-serial adaptor – connection via mini B USB
FTDI standard cable connector for debug/programming
Reset switch, and RTS automatic reset when programming from Arduino IDE.

Lithium Polymer battery support
Boost regulator ((Microchip MCP1640) boost from 1V to 5V for LiPo or battery operation
250mA 3V3 linear regulator
Battery temperature and voltage monitoring via on-chip ADC

Extended “Arduino” style expansion headers  with 6 extra GPIO pins
Mini-application headers – 2 off, with 5V, 0V.  2x digital 2x ADC  and 2x PWM outputs
ATmega ICSP programming header 2×3 way
Standard 50mm x50mm 2 layer pcb format with 2 diagonally opposite M3 mounting holes.

Final Design as sent off to Ragworm – my local PCB Supplier

Two weeks later,  I receive 25 boards from my local supplier

The prototype WiNode 5 board prior to assembly.

Last November, I devised a new compact pcb footprint on a 50 x 50mm board, and I have started to create a number of boards based on this format.

In November’s blogpost, I speculated about using the board as a universal format for creating small microcontroller and FPGA boards, which share common peripherals and a standard pin-out ports for interconnectivity and “stackability”.

The boards are fitted with “Arduino like” expansion shield headers – which themselves have been extended to provide connection for up to 28 GPIO signals, arranged nominally in four headers A, B, C, D.

The ports have been generally based on the arrangement on the ATmega1284, which in a 40 pin DIL package provides four, 8 bit ports with the power pins & clock oscillator pins located towards the centre of the package. This a compact, logical arrangement, which makes the most of what can be packed into a 40 pin DIL.  (In the late 1970’s manufacturers were very resourceful on how to package an 8 bit microprocessor with 16 address lines into the standard 40 pin DIL package).

The purpose of the breakout board is to put a complete microcomputer system into an easy to use, compact format.  This was the strategy adopted with WiNode which uses the ATmega1284, but which I am now extending to allow for further offerings from ARM and FPGA devices.

With ever increasing sophistication of microcontroller products, the pin-counts are rapidly rising – so it becomes a challenge on just how to access all of the GPIO pins for breakout, especially when some LQFP packages have 208 pins!

Whilst the extended Arduino headers can handle up to 28 GPIO, clearly another strategy is needed for the larger packages.

From my experience with WiNode, it is very easy to quickly use up several GPIO lines just supporting the on-board peripheral hardware devices:

microSD card        SPI bus +  /CS
RTC                     I2C  + interrupt
SRAM                  SPI + /CS
Keyboard              Clock, Data,
Mouse                  Clock, Data
Wii Nunchuck       I2C
FT812                  SPI, /CS
USB                     UART RX0, TX0
WiFi (ESP-01)      RX1,TX1
RFM69                SPI + /CS + interrupt
Battery Volts        ADC
Battery Temp       ADC

So 20+ lines can easily be consumed with the on board devices.  Incidently, the WiNode 5 has been designed so that it will support other processors in addition to the ATmega1284, in this role it becomes a compact I/O shield.

ARM Challenge

Adopting this format to the larger parts will require a different strategy.  Do we assume that almost all of the “Arduino” pins will be consumed with the local peripherals and that a bus strategy should be employed for inter-board communications?

For ARM packages up to 48 pins, the solution is to craft the device GPIO ports into a 40 pin DIL format, such that it can be plugged directly into the WiNode board. This will take care of the essential system peripherals, leaving the remaining lines available for a bus connector.

On the ARM processors, this is likely to connect directly to the Flexible Memory Controller (FMC). As this is involves a lot of signals, a more dense connector format will be required – and 1.27mm pitch would double the connector density yet remain compatible with 2.54mm standard pitch connectors.

The larger package ARM processors have the FMC external memory controller and also a parallel LCD controller interface – both of which are very intensive in terms of pin usage. These should be routed out to the high density “bus” connectors.

As a rule of thumb – the first three 16 bit ports A, B, C on the ARM will be routed out to 2.54mm headers – based on an Arduino compatible theme.  The higher ports D,E,F,G,  H,I,J & K will be routed to their own double density connectors at either end of the pcb. This format will give maximum flexibility, for the larger pin packages, including memory and FPGA devices.

Trial Fitting a 208 pin processor and a 72Mbit 3nS SRAM

This arrangement will allow unique breakout for up to 156 GPIO signals (The 208 pin STM32F746 or STM32F439BGT6 have a maximum of 166 GPIO lines).

The signals unlikely to leave the board are the clock oscillators PC14, PC15, PH0, PH1,  the JTAG/SWD/ST- link signals PA13, PA14, PA15, PB3, PB4 – which will have their own header.

External Memory Connector.

This 64+4 pin connector handles 32 data lines, 24 address lines and control signals.

LCD Display Connector.

This 64+4 pin connector handles 24 bits of RGB data,  synchronisation signals and pixel clock along with other LCD control signals. It is arranged such that a flexible plastic connector (FPC) common on LCD screens can be easily interfaced .

Clearly a work in progress – the weekends are just to short.

0 0
The original WiNode 4.0 plus Evita video board 

Recently I have been thinking again about simple 8-bit computer systems.  By simple, I mean understandable, to me, and those that don’t rely on 20 million lines of someone else’s code to get to the point that you can have fun with them.

The early 1980s was a very prolific period of design for home computers, especially in the UK, before the very costly IBM PC really took a hold. Costly in the fact that it cost about £3000 in 1981 and very costly to the UK computer industry.

Many of these, now 35 year old computers are being revisited and recreated, possibly using new hardware, to create a whole genre of neo-retro machines.

Some History…..

Way back in 2011, I developed an “augmented Arduino” which I called WiNode – a concatenation of Wireless Node.

It featured the ubiquitous ATmega328, an RFM12B 433 wireless transceiver, a real time clock, a microSD connector, a 32kbyte battery backed SPI SRAM and a dual H-bridge for driving small motors and relays.

One of the production batches of WiNode was used in a sound-sculpture installation “Phantom Railings”  at Malet Street Gardens in summer of2012.

About the same time, whilst at Oggcamp 2012, I met Julian Skidmore, who had created a small DIY kit for an 8-bit Forth Computer, called Fignition.

Julian had done a great job in getting it to run a very capable implementation of Forth, and produce audio and video from just an ATmega328.

The Plan…..

Whilst recently reconsidering the role of 8-bit computers, and languages such as Forth, I remembered Julian’s work, and WiNode, and wondered whether they might both benefit from an upgrade.

I have subsequently upgraded WiNode to use the much more resource rich ATmega1284, with 16K of onchip RAM and 128K of flash.  By my reckoning that probably puts it on par with an original 16K Spectrum. However, according to Julian’s Forth benchmark figures, when clocked at 16MHz, an ATmega is going to outperform a 3.5MHz Z80A by a factor of about 24.

In the intervening years, Fignition has gained a PS/2 keyboard interface, and is now showing all the signs of a very useful machine for learning to program in Forth. It easily exceeds all the capabilities of the early 1980’s Jupiter ACE.

The new WiNode design is a good way of taking the Fignition concept a stage further.   It provides much needed additional RAM capacity,   the super-capacitor backed 32kbyte SPI SRAM can now be used as a persistent store – rather than the main execution RAM  – a much needed speed increase, and the microSD card may be used for removable program storage, put all your favourite Fignition games on uSD and share with your friends…..

WiNode also brings on-board wireless connectivity, either using the RFM69  433MHz or 868MHz low power transceiver, or the plug-in ESP8266 WiFi module.

WiNode by itself is really intended as a stand alone controller, with 28 general purpose I/O lines. The realtime clock, LiPo battery support and non-volatile RAM/uSD card means that it is a good fit for data logging, central heating control, internet connectivity (WiFi) , energy monitoring etc.

However, WiNode 5 has been designed to work with a video generation shield, called Evita, which allows full colour video of up to 1024×768 65Hz resolution via a VGA connection to a large screen monitor.  The Evita board also provides PS/2 keyboard and mouse interfaces, audio output, connection to a LCD touchscreen and also to a joystick or Wii Nunchuck controller. All the right interfaces for a colourful neo-retro computer system.

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

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

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

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

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

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

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

MSP430 Family.

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

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

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

Energia – “Arduino” for the MSP430

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

A look at the MSP430  FRAM devices

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

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

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

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

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

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

Basic Features.

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

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

Datasheet is here.

Tools & Equipment

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

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

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

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

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

In Summary & Conclusion

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

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

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

Just exploring a new instruction set is fun in itself.

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

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

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

The ‘5969 Launch Pad  – an ideal experimenting platform for FRAM

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

MSP430 Performance

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

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

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

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

Simple Maths       1.27
FIR Analysis        3.29
Dhrystone            1.83
Whetstone           2.56

Average               2.24

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

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

SIMPL on the MSP430

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

Porting SIMPL to a FRAM Device.

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

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

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

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

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

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

Making Use of the FRAM.

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

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

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

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

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

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

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

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

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

To be continued…… soon

0 0
Bare Board, 2 layer, 50mm x 50mm

Two weeks ago, you may remember I finished the pcb layout for a new microcontroller board – WiNode 5  – based on my 50 x 50mm standard board footprint.

Minimum Build.

With mcu, reset and crystal fitted, the board runs “Blink”code

For this I suggest fitting the ATmega1284 SMT package, the 16MHz crystal and its two 22pF capacitors C14 and C15.

Also the 10K reset resistor R1 and the FTDI 6way right-angled header JP1.

A 3.3V  MCP1702 regulator should be fitted in position IC4 along with C2, C4 and C5 its input and output capacitors.

Fit the four 100nF decoupling capacitors around the main microcontroller, C3, C7, C12 and C19.

The 3×2 pin ICSP programming header JP6 should also be fitted.

For LED output fit green LED1 and its 100R series resistor R10.

With this minimum build you may power the board from the FTDI cable and now program the bootloader using ICSP.  If this is successful, loading the blinky sketch should run and the LED should flash.

Now we add the USB chip IC7 (CH340G) the USB connector and the 12MHz USB crystal. Add the 22pf capacitors C18 and C20 and the 100nF decoupling capacitor C20.

Fit capacitors C8, C9  and resistor R2 to provide a filtered AVCC supply.

Add the RFM69 Wireless, the USB and the ESP-01 WiFi

The RFM69 wireless module and the ESP-01 WiFi connector and module can be added at this stage.

Finally – fit the four female shield mounting headers.

Fit the “Arduino” style female socket strips

These allow complete shields to be added, or small modules like the accelerometer module – which is powered by and connected to the Analogue Input port

With axdl 335 Accelerometer module fitted

Programming and Firmware

The Optiboot loader and Arduino “board” files for this project are located at the Mighty1284 Github repository – with more information about the ATmega1284P implentation of Arduino here.

With the new 1284 board files loaded into the hardware directory of the Arduino IDE, you are now ready to program the Optiboot loader into some chips.

Having got the basics of the board in place, and proven that all was working so far, it was at a stage where it could be left  and I could get some sleep.

The final construction stages were to populate the boost converter, fit the FRAM (or SRAM) IC and fit the micro SDcard socket to the underside of the board.

WiNode 5 virtually complete – topside view

Above – the boost converter components, IC, 5 resistors, 2 capacitors and an inductor are added to the lower right corner of the board.

Just above the mcu is the SOIC-8 FRAM IC.

The microSD card socket is added to the underside of the pcb.

And a final word from our sponsors….. Ragworm provided additional boards at no extra charge and couriered them over in time for some weekend fun, as my job is putting the first few boards together.

0 0

Pin Mapping

WiNode 5 is the successor to earlier WiNodes that were based on the 28 pin DIL ATmega328.

The ATmega1284 offers significantly more features and GPIO pins, 32 compared to the 20 of the ATmega328 – and these all have to be mapped out in a way that makes sense on the PCB. There is also a constraint of 28 header pins – so four of the GPIO appear elsewhere on the pcb – for specific functions – see later.

There is no common standard, with several commercial ATmega1284 boards doing their own thing – generally based on the 40 pin DIL version of the ATmega1284.

Reverting to good ol’ ASCII Art –  Here is one mapping scheme from “Mighty1284P”

//                       +—\/—+
//           (D 0) PB0  1|        |40  PA0 (AI 0 / D24)
//           (D 1) PB1  2|        |39  PA1 (AI 1 / D25)
//      INT2 (D 2) PB2  3|        |38  PA2 (AI 2 / D26)
//       PWM (D 3) PB3  4|        |37  PA3 (AI 3 / D27)
//    PWM/SS (D 4) PB4  5|        |36  PA4 (AI 4 / D28)
//      MOSI (D 5) PB5  6|        |35  PA5 (AI 5 / D29)
//  PWM/MISO (D 6) PB6  7|        |34  PA6 (AI 6 / D30)
//   PWM/SCK (D 7) PB7  8|        |33  PA7 (AI 7 / D31)
//                 RST  9|        |32  AREF
//                 VCC 10|        |31  GND
//                 GND 11|        |30  AVCC
//               XTAL2 12|        |29  PC7 (D 23)
//               XTAL1 13|        |28  PC6 (D 22)
//      RX0 (D 8)  PD0 14|        |27  PC5 (D 21) TDI
//      TX0 (D 9)  PD1 15|        |26  PC4 (D 20) TDO
// RX1/INT0 (D 10) PD2 16|        |25  PC3 (D 19) TMS
// TX1/INT1 (D 11) PD3 17|        |24  PC2 (D 18) TCK
//      PWM (D 12) PD4 18|        |23  PC1 (D 17) SDA
//      PWM (D 13) PD5 19|        |22  PC0 (D 16) SCL
//      PWM (D 14) PD6 20|        |21  PD7 (D 15) PWM
//                       +——–+

This is a fairly logical approach, with pins numbered starting from Pin 1 of the package and just following the package around.  However it does not tie in well with the mapping on the Arduino or WiNode 5 board:

The Bobuino pin mapping is much more like the original Arduino – preserving D0 to D13 in their old familiar positions and functions, plus the analogue inputs mapped to D14 to D21, and the additional (Port C) pins following on as D22 to D29. This just puts SCL and SDA a little bit off beat as D22 and D23.  The mapping scheme is better but not perfect:

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

//                       +——–+

My problem is that pins B0 and B1 are not routed to the regular headers but appear on the upper H-bridge connector JP4 and the “X-Bee” shield. Additionally Analogue inputs A6 and A7 are used on board for battery volts and battery temperature monitoring. These rogue pins need to be accounted for in the mapping scheme.This therefore gives rise to the modified arrangement:

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

With any pin-mapping , it is clearly a compromise between physical and logical arrangement. These changes can be incorporated into the pins_arduino.h header file. We achieve a mapping that is reasonably familiar with existing Arduino pin-out and ties in well with the physical layout of the pcb:

//                   _________________________________
//        RXD0 (D0) |o            A7  (D29)          o|A5  (D27)
//        TXD0 (D1) |o            A6  (D28)          o|A5  (D26)
//   RXD1 INT0 (D2) |o            B0  (D30)          o|A3  (D25)
//   TXD1 INT1 (D3) |o            B1  (D31)          o|A2  (D24)
//       PWM1B (D4) |o                               o|A1  (D23)
//       PWM1A (D5) |o                               o|A0  (D22)
//       PWM2B (D6) |o                                |
//       PWM2A (D7) |o                                |
//                  |                                o|VIN
//       INT2  (D8) |o                               o|0V
//      PWM0A  (D9) |o                               o|0V
//   PWM0B/SS (D10) |o                               o|+3V3
//       MOSI (D11) |o                               o|+5V
// PWM3A MISO (D12) |o                               o|RES
// PWM3B  SCK (D13) |o                               o|C5  (D21)
//         0V       |o                               o|C4  (D20)
//       AREF       |o         Open Hardware         o|C3  (D19)
//        SDA (D14) |o            WiNode 5           o|C2  (D18)
//        SCL (D15) |o                               o|C1  (D17)
//        ANT       |O                               o|C0  (D16)
//                  |_________________________________|

This makes for a neat, logical arrangement, where the pairs of complimentary PWM outputs are located next to one another – and in a neat group D4-D7.
SCL and SDA are on the end of the upper digitals – where you would expect them on an R3 shield.
The JTAG lines (TCK,TMS, TDI,TD0) are in a neat group on the extended headers C0-C5.  C4 and C5 may be used for active signalling to the shield through the Arduino I/O and NC pins on the end of the power header.
ANT is the antenna connection to the RFM69 wireless transceiver module.
In part 3 we further name and map these pins to suit the EVITA graphics shield and the Open Inverter H-bridge module.

0 0


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
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 4×2 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 1024×768 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.1ghz>

0 0

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

0 0

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.

0 0

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.

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 50×50 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.

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.

0 0

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.


About monsonite

mostly human
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s