Making progress with SIMPL

If you have read any of my last few posts you will know that I am working on a tiny language called SIMPL which was inspired by Forth.

SIMPL stands for Serial Interpreted Minimalist Programming Language – as that’s what it started out in life as being – a serial command shell for microcontrollers, when a few simple single alpha character commands could be used to run simple programs and loops on microcontrollers such as Arduino and Teensy.

SIMPL was adapted from Ward Cunningham’s Txtzyme – a character interpreter running inside a loop, and over a period of a few years I have augmented the language to provide  more functions such as maths operators, logic operators, loops and conditional branching, and perhaps most importantly, and borrowed from Forth –  the means to compile new words using the “colon definition”.

SIMPL is a lightweight language, it does not try to even attempt to do all the things that Forth can do, and with a word set that has been reduced to a maximum of 85 unique functions, it is much smaller than amost all implementations of Forth.

In just 300 bytes, the heart of the SIMPL kernel can take serial text – either typed in manually or sent as a file from a serial terminal program, and buffer it into RAM memory. It can also take colon definitions, and based on their identifying character – normally a capital letter, store them at precalculated addresses in RAM so that they can be accessed and run later with the minimum of decoding.

This unique feature of SIMPL effectively removes the overhead of the dictionary search in Forth.  A character read from the input buffer is decoded within a few cpu cycles, and program execution is directed to that block of code.


In addition to the engine that drives the inner interpreter, there are a series of low level primitives that define the SIMPL kernel.  These primitive words are effectively the minimum wordset from which the rest of the language can be written. Bill Meunch, C.H. Ting and Chuck Moore all arrived at roughly the same conclusion – back in the early 1990s  – that there was a small subset of words from which a full implementation of Forth could be synthesised. It is in this spirit that SIMPL has been written.

These primitives include stack operators, math and logic operators, memory access operators and those that allow conditional branching and control program flow.

There are just 32 primitives – which allows for a 5 bit instruction scheme.  These primitives mostly consist of symbols taken from  ascii characters  0x20 to 0x40.

The primitives have been chosen to offer register compatibility with Ting’s MSP430 eForth.  This offers a proven route to extension and makes building and testing the code a lot simpler.

At it’s lowest level, SIMPL takes the place of a serial bootloader allowing source code to be loaded into the program space of the target microcontroller, using nothing more sophisticated than a serial terminal program such as terraterm.

SIMPL is written in MSP430 assembly language for efficiency, speed and compactness, and it has strong influences from Dr CH Ting’s eForth for MSP430.

As I read through Ting’s book  Zen and the Forth Language – I realised that it should be possible to make the kernel of SIMPL a cut down version of eForth, that resides in just 1k bytes of program space, and presents a programmer’s “tookit” in addition to the means to load source code into the device and run that code on a virtual machine.

Progress to Date

Inspired by CH Ting’s book on the MSP430 eForth,  I decided to restructure my rudimentary code to make it compatibe with his register model.  This will allow for easier expansion later on.

Jump Table

 I have included a “jump table” to jump to the code addresses of all of the 96 possible ascii character instructions. This framework will allow me to quickly add the other functions and run them from the code addresses stored in the jump table.

Whist this jump table in itself is 192 bytes long, just over one quarter of the code so far, it reduces other overheads of instruction decoding. The jump table structure is not going to be as fast as direct threaded code, and this is the price we pay for using a tokenised instruction set – but it is easier to understand and extend with more functionality. In hardware, this jump table would be analagous to a microcode ROM for instruction decoding.

The jump table accepts an index value  in the form of a single ascii character. This is first copied to a temporary register as we need the original character later. Then we subtract 32 from this  – to remove the offset from zero – as the first printable character is “space” which is ascii 32. Finally we multiply whats left by 2 (by adding it to itself) and add this to the program counter.  This causes the pc to be incremented by the correct number of words into the table where we find the code address of the function we wish to run. A snippet of this below shows how this selects from the first 5 instructions

; Now we need to decode the instructions using a jump table
; Jump table uses 2 bytes per instruction - so 2 x 96 = 192 bytes

next:     mov.b @ip+,R12     ; Get the next character from the instruction memory
          mov.w R12,R13      ; Copy into R13 - as needed to decode Jump Address
          sub.w #0x0020,R13  ; subtract 32 to remove offset of space
          add.w R13,R13      ; double it for word addressing
          add.w R13,pc       ; jump to table entry

JumpTbl:  jmp space          ; SP
          jmp store          ; !
          jmp dup            ; "
          jmp lit            ; #
          jmp swap           ; $


In this way all of the 96 possible ascii tokens are handled, including numbers – which have their own decoding routine, also accessed via this jump table.


Primitive Progress

Most of Ting’s set of eForth primitives have been coded in now – and I can do simple arithmetic, logical operations and memory 16 bit fetch and store.

The code to enter and decode decimal numbers and print them out to the terminal is also in place and working. – this allows me to type in 123 456+. and the machine responds 00579, as I have yet to suppress leading zeroes on my printnum routine.

I have tested memory fetch and store, and also the conditional operators < = and >.

With the conditional operators returning either 0 for false or 1 for true, the next thing to implement will be the simple looping structures, and the mechanism that allows conditional execution of code.

These structures make use of parentheses ( ), and a single parameter on the stack which is passed into the loop counter

Any code to be conditionally executed is paced between the parentheses.  The loop counter defines how many times the code within the brackets should be executed –

0   not at all  – skip everything between the brackets until the end ) is detected

1   execute once – i.e use for conditional execution

n  execute n times – decrementing the loop counter until it is zero

This is a useful structure, as as well as conditional execution and DO-LOOPs  it can also be used for comments – by setting the counter to zero, anything between the brackets is not executed – so the text characters can be treated as a comment.

I am fairly confident that I can keep the kernel below 1024 bytes, with the higher level routines built on top of this 1K kernel. The codesize is now 738 bytes.

I have created a github gist to allow you to view the code so far – as this is clearly a work in progress.







Posted in Uncategorized | Leave a comment

More Thoughts SIMPL and eForth


Image result for CH ting zen

I recently downloaded Dr C.H. Ting’s book via Kindle “Zen and the Forth Language” – published by fellow Forther, Juergen Pintaske.

In the book, Ting describes in detail his eForth model ported to the MSP430, and how a complete direct threaded Forth can be built using a limited set of primitives.

Ting’s book is very comprehensive, giving details of how to use TI’s Code Composer to assemble a program and create an output file in a form that can be used by the 4E4TH IDE.  There is sufficient information in his book for any curious person to discover the inner workings of Forth and have a complete working system on the inexpensive MSP430 Launchpad.

Whist at Forth Day, I had the opportunity to talk with Ting and this was the motivation I needed to take the plunge with MSP430 assembly language. Ting’s book, and it’s detail of the eForth mode convinced me that I was on the right lines with my approach to SIMPL – indeed almost to the point where my implementation of SIMPL could be considered to be a sub-set of Ting’s eForth.

Having got the basics of the SIMPL interpreter running in assembly language, the plan is now to massage the allocation of the registers, so as to make it compatible with Ting’s model. Then SIMPL really will be a simplified version of eForth.  This means that if I ever choose to extend SIMPL at a later date – there is a clear and proven route via Ting’s eForth.

SIMPL removes the dictionary search overhead that otherwise exists in Forth. The “words” are just singe ASCII characters, and it is easy to jump to an address, calculated from that value. Whilst this might appear wasteful of memory, the ultimate  MSP430 target has 256Kbytes of FRAM to play with.  It massively reduces the overhead of decoding text strings.

Can we switch between SIMPL and Forth?

SIMPL source code  can be written in such a way that it can be expanded into standard Forth, using the SIMPL interpreter to automatically generated this more verbose form.  The SIMPL primitives can all be expanded out to their conventional Forth names, as can the internal words associated with letters a-z and user words A-Z.

Conversely, small eForth application programs could be analysed for their word content and mapped onto the primitives and user symbols used in SIMPL.  Provided that only 52 user defined words have been used in writing the application – then the switch between Forth and SIMPL should be relatively straightforward.

SIMPL is essentially a shorthand or shortform of Forth. The two should be designed in such a way that they are interchangeable. SIMPL is just a subset of Forth – simplified!


MUP21  & eForth Primitives 

From Ting, Dr. Chen-Hanson. Zen and the Forth Language: eFORTH for the MSP430 from Texas Instruments (Kindle Locations 406-413). Juergen Pintaske. Kindle Edition.

Here’s a list of the instruction set of Chuck Moore’s MUP21 Forth cpu. Ting compared his 31 eForth primitives with these and this confirmed that they were thinking along very similar lines.

Transfer Instructions JMP, JZ, JC, CALL, RET, LOOP

Math/ Logic Instructions AND, OR, XOR, NOT, SHR, ADDC

Memory Instructions LDR, STR, LIT

Stack Instructions PUSH, POP, DUP, DROP, SWAP, OVER, NOP

These are also very similar to the instruction set of James Bowman’s J1 Forth processor, which is the intended FPGA target for my SIMPL language. So my plan is to have a maximum of 32 primitives – which can be represented by a 5 bit instruction, and three of these instructions can be pipelined into a 16 bit wide memory – again an idea borrowed from Chuck’s MUP21.

However, the J1 uses a 16 bit wide instruction, where the bit fields directly control the hardware. In my proposal, there will need to be a further level of decode – effectively a 5 bit to 16 bit ROM, which generates the J1 instructions from the 5 bit instruction token. This is the price we pay for having a token set that has been chosen for human readability – it needs a further level of decoding to suit the ISA of the Forth processor.

We can of course model the instruction set and architecture  of the J1 in MSP430 assembly language, and this might be a useful step to do.  In effect we will have created a cross assembler, where SIMPL code is assembled into J1 instructions. Whilst slower than running SIMPL directly in MSP430 assembler, it would be useful to prove the development of the language on the J1 – all be it simulated in code. When run directly on the J1, there will be an order of magnitude speed up.

Uses of SIMPL.

Writing SIMPL has been an education for me, as I have learned about the inner workings of virtual stack based machines, and how they are created within a conventional register based processor.  A learning exercise for me, can equally be a educational process for others, so I see one of the uses of SIMPL is as a learning tool to teach students about the instruction set and the architecture of simple stack processors. In the same theme as “From NAND to Tetris”  “Building a SIMPL Stack Processor” could be offered in the form of an online study course, consisting of theory, implementation on the MSP430 Launchpad, or Juergen Pintaskes MicroBox. For some, learning electronic engineering and hardware description languages –  the implementation in a dedicated soft core processor on an FPGA woud aso be a useful earning exercise.

At it’s heart, SIMPL is a text interpreter, and can be used to process text files. Many of our modern manufacturing processes, such as pcb production, CNC machining, 3D printing and laser cutting transfer their information using fairly simple text file formats – such as Gerber and G code.  These files consist of numbers and alpha characters which are translated into sequential machine operations. SIMPL can be used as a text processor to convert these files between standards, or to generated new compatible formats – which may be of interest to the open source and maker communities.  Animating a walking robot, or fying a drone through a sequence of aerobatic manoeuvres are both things that could be translated into SIMPL text files.

In a later post I will describe how SIMPL source code can be used as a lingua franca for bi-directional  exchange of information and program code between radically different classes of computing hardware – from the humble Arduino or Launchpad to the fastest laptop or Octa-core Android platform. Laptops and other mobile computing devices are convenient viewing platforms because of their high performance graphics capabilities, whist small microcontrollers generally struggle to produce anything other than a serial text output.

However if this serial text was effectively a list of drawing commands for graphics primitives – the mobile platform, running a SIMPL virtual machine (written in iForth or Processing for convenience and portability) could interpret the “display list” and produce the fully rendered graphics display from it. SIMPL can send serial text to a Laptop or tablet at some 200,000 bytes per second – perfectly fast enough to render images for datalogging, oscilloscope or IDE type applications.



Posted in Uncategorized | Leave a comment

SIMPL – a Small Forth Inspired Language

SIMPL really is a very small language. The interpreter and primitives kernel fit into less than 1Kbytes on the MSP430.  It can be ported to virtually any microcontroller that has a reasonable number of registers. SIMPL is like Forth – but simplified!

SIMPL was inspired by Ward Cunningham’s TXTZYME – a minimal language written in C that allowed a microcontroller – such as Arduino or Teensy to perform basic operations, such as printing text, looping, toggling port pins and reading an ADC all controlled from a serial terminal. It only had 13 instructions and was quite limited in what it could do.

I was intrigued by TXTZYME and how it worked –  and quickly realised that it could easily be extended to include math and logical operations, conditional execution and like Forth could have new words created from it’s set of low level primitives.

In the last 4 years, as inspiration leads me, I have developed SIMPL much further and ported it to other microcontrollers such as MSP430 and ARM M4. There are now 400MHz ARM M7 microcontrollers available – and porting SIMPL to these monsters should be relatively SIMPL.

This year – taking my inspiration from a recent trip to Forth Day at Stanford University – with Forth cpu expert James Bowman, and eForth guru Dr. C.H. Ting – I have sought to write SIMPL in MSP430 assembly language, as a learning exercise, and so I can experiment further with the mechanics of the language. All I’m doing is following Chuck Moore’s journey,  but 50 years later. I just want to create the tool set that makes programming computers easier and more productive.  I don’t want 20 million lines of code just to run an operating system. I want the machine to spend all it’s time on my application!

I see SIMPL as a universal “Shorthand” allowing us to write code at a fairly low level for a wide variety of microcontrollers – at least for simple applications.  I think of it as a debugging toolbox, or Smart Bootloader, that once installed on a microcontroller, grants you the ability to load code into memory,  communicate with the mcu at a fairly basic level, execute code and examine the contents of memory or print out results. It also gives the means to exercise the mcu peripherals – such as GPIO, ADC, UART, SPI etc.

Just like Chuck Moore, I don’t want to learn a whole new set of assembly language for every new processor I take on.  I want to put a version of SIMPL (coded in C or Arduino C++) on the chip, and gain a familiar set of basic tools.

My goal is to produce an extensible language that fits into just 1k bytes – which is effectively an “Access All Areas Pass”  for the mcu.

The MSP430 has been chosen because it is a low-power 16 bit processor and newer devices have up to 256K bytes of nonvolatile FRAM memory.  MSP430 also have some neat features – like 24bit ADC, and very fast UART allowing serial communications at up to 8 Mbaud.

Once the SIMPL virtual machine  has been written in MSP430 assembly language – it is a relatively easy task to port it to any other modern register based processor – including ARM, x86 etc.  But for now I am just finding my way around the MSP430 assembly language – which will suffice as a very capable virtual machine.

Ultimately, the plan is to port SIMPL to it’s own custom stack processor – such as James Bowman’s J1, based on a soft core running in an FPGA. Most of the primitive instructions are executed directly by the J1 hardware, so the port will consist of decoding the primitives from ascii using a look up table and generating  the 16 bit wide instructions that the J1 uses.

What I see SIMPL useful for:

It’s a low overhead tookit that allows you to explore the inner workings of microcontrollers.

It uses many of the ideas of Forth, but without getting bogged down with the Forth virtual machine. Forth could be considered to be an extension of SIMPL, and learning SIMPL teaches you a lot of what you need to know for Forth.

It allows the newcomer to explore a microcontroller with just a serial terminal. Ideal as an educational language, showing what can be achieved in a very low byte count on virtually any microcontroller.

Very compact – a 140 character tweet or SMS could do a lot in SIMPL

Automates the process of getting code to run on a new microcontroller – a useful alternative to the traditional bootloader – with lest than 1K of overhead.

Fast – all primitives are written in assembly language. Instructions are decoded in logic or by look-up table – so reduces the overhead of a dictionary search.

Uses a very simple syntax, many machine tools, 3D printers, laser cutters could be controlled from text files that are essentially lists of SIMPL instructions.

SIMPL has just 32 primitive instructions – based on the non-alphanumeric symbols used in ascii. Lower case alphabetic characters are used for function calls to code that exercises processor specific hardware, or for examining the contents of memory.  The uppercase characters are reserved for user defined words – created from primitives and lowercase words.

SIMPL is a highly mnemonic language – where the choice of character reflects the operation being performed.  This is not a new idea – it was used on the very first Cambridge – built EDCSAC machine – where instructions were loaded in from paper tape. SIMPL pays homage to this machine and the simple way in which things were once done.

SIMPL is Forth like in that it uses words or tokens that cause blocks of code to be executed sequentially. It differs from Forth in that the words consist of single, printable ascii characters that are decoded directly causing the cpu to call a routine at a given address, execute the subroutine found there and then return control to the inner interpreter.

There are 85 printable characters – so this defines how many unique codes the machine will interpret as instructions.

The inner interpreter is very compact on the MSP430 with the main interpreter loop fitting into about 300 bytes.

On top of this interpreter loop, you have the code for the low level primitive symbols – listed below, and then higher level words – such as “toggle a port pin” “n milliseconds delay” “read an adc channel” “output a string to serial port” “produce a hex dump of memory” which are represented by the lower case alphabet characters.

This layer of the language is what I refer to as the “Arduino Layer” – all those useful helper functions that are processor specific.

The next layer is the users application code where the users words use capital letters. For example – the classic washing machine program:


This would be condensed in SIMPL as FWEFRES
– which is a code reduction factor of >5

But each of these can have a parameter – for example if the WASH is an AGITATE cycle A

– In Forth


In SIMPL we also use a colon definition to define W. There is no need for the ; as when this snippet is entered it has a null terminator added, and this is the cue to the interpreter to return to fetch the NEXT word

:W50(A) the code in the parenthesis is repeated 50 times

In fact the ascii code for W is used to store this code snippet at a given address – calcuated as (W-61)*32. So as soon as the interpreter encounters W, it jumps to that code address

Most of the primitive Forth words are located in the ASCII characters 32 to 63 that leaves 64 to 126 available for the users vocabulary and constructs made from primitives.

There are approximately 32 printable ascii punctuation and symbol characters – and with a bit of pre-processing they can be used to form the basic machine primitives.

Stack Commands (7) PUSH, POP, DUP, DROP, SWAP, OVER, NOP

,        PUSH
.        POP
”       DUP
‘        DROP
$        SWAP
%        OVER
SP        NOP

Maths & Logical Operations (9) AND, OR, XOR, NOT, SHR, ADDC

+        ADDC
–        SUB
*        MUL
/        DIV
&        AND
^        XOR
`        SHR
|        OR
~        INV (NOT/COMPL)

Transfer Instructions (8)

:        CALL (COMPILE)
;        RET
(       LOOP-START
)        LOOP-END
<       LESS
=        EQU
>        MORE
\        JUMP – condition follows

IN/OUT (2)

?        KEY (INPUT)
.        PRINT (OUTPUT)

Memory Instructions (3)

@        LOAD
!        STORE
#        LIT

Others (6)

_ _        String Print
[ ]        String Store
{ }        Array of elements – switch/case

The use of single ascii characters as tokens, makes the language a lot less verbose than Forth, and snippets of source code can be sent in very few characters – for example as an SMS message between 2 systems equipped with GSM modems.
It is a fairly simple task to have a word table – where the verbose form of the words are stored, and can be printed out, to expand the source into something more readable – for example


Three ascii characters expanded to 11 plus 3 spaces

SIMPL does not use the space as word separator, but in the special case where you have several numbers to put on the stack, the space is used to indicate “push onto stack”

The intention is to write an implementation of SIMPL in MSP430 assembly language. This not only helps me learn MSP430 asm code, but it’s a good exercise in creating a SIMPL virtual machine using a very conventional register based microcontroller, to gain experience of the language and its limitations. For example, have I got the right mix of primitives to allow a complete language to be synthesised?  The choice of primitives was based on Chuck Moore’s MUP21 instruction set and CH Ting’s e-Forth model.

Writing in assembler exposes you to the raw roots of the processor, where you have to think hard about what you want the code to do, and always be prepared to rewrite and refine every routine.  Having ported an application to one register-rich processor, porting to a new device like an ARM is much easier, as you have already done the hard work of developing the register functional model.

As the microcontroller is running the SIMPL machine, the SIMPL primitives should give access to the widest range of the host’s instruction set, but with the simplification that the stack takes the place of having multiple registers to write to.  This is further simplified that the top and next locations on the stack are stored in registers rather than RAM.

As the VM needs to perform tests and comparisons on numbers – the usual comparison operators are provided  > , < and  = .

These are used in conjunction with the parentheses operators which provide the means of skipping or looping sections of code depending on the result of the comparison.

As an example     10 11>(_Print if Greater_)












Posted in Uncategorized | Leave a comment

SIMPL – Now Ported to MSP430 Assembly Language

For some time I have been working on a tiny, Forth like language called SIMPL (serially interpreted minimal programming language). Whilst it’s origins are from Ward Cunningham’s “Txtzyme” – and originally written for Arduino, and Teensy,

I have bitten the bullet and started to port it into MSP430 assembly language for speed ad compactness. The reasons for this is that the MSP430 is a good 16 bit mcu, low power and now in variants that offer lots of non-volatile FRAM – plus it’s not such a difficult processor to get to grips with the assembly language (unlike the more complex ARMs) – and as such, it makes a good first choice of affordable 16 bit processor for learning about the mechanics of Forth.

My aspirations lie in creating a minimal tokenised interpreted language – where the words or tokens are single ascii characters. This removes a lot of the more complex aspects of Forth, such as dictionary searches, and it also makes a very mnemonic rich language – in that I can choose what symbols I use for the various stack operations – so I use ” for DUP, $ for SWAP, % for OVER and ‘ for DROP.

Whilst to some in the Forth community this may appear heretical, it makes sense to the way my brain is wired. More conventionally I have &, |, ^ and ~ for AND OR XOR and INVERT for logic operations and the usual +, -, * and / for the maths operators.

Inspired by Ting’s eForth and its minimal word set, I can get most of the primitives into the 32 punctuation symbols, leaving the capital letters for user words, and the lower case for other system words – that are constructed from primitives – for example h to set a port high and l to set it low, m for millisecond delay, u for microsecond delay.

The language is evolving on a daily basis and I can now do basic maths and logic operations and some of the stack manipulations – yet the whole kernel (so far) with UART support is just 582 bytes long – which roughly translates into about 500 lines of code. I have posted the code so far up on Github Gist here…/4af8e1d10e447fa1755873e8ce74f728

This is very much a work in progress – but it’s my way of learning how these obscure languages work, and good fun to tinker with. You just need a Launchpad with a MSP430G2553 – but with a little fiddling with the UART routines it will run on virtually any MSP430. What’s it good for, you may ask. Well I see it as a lingua franca to allow widely different machines to communicate with each other efficiently at a low level – but still human readable. I also see it as being ported easily to a specialist Forth processor – and being used for controlling NC machines and 3D printers, and also rendering any common file format – such as Gerber or G-code that uses a mix of single letter characters and numbers to represent machine control instructions. The MSP430 is only the start of the project, hopefully leading onto custom stack processors that execute forth primitives directly.

Posted in Uncategorized | Leave a comment

Coming Up For Air


2017 has been an eventful year so far, and for the first time in ages, I have been able to pause to take stock of these events. I write this from my quiet seaside dwelling in Hove – actually.

As of 16th Novemeber, I will no longer be a PAYE Employee – so it’s back to freelancing and picking up whatever work interests me and pays the bills.

This is a self imposed change – and it’s only the 3rd times in my 30 year career in electronic engineering that I have pulled the ripcord and bailed out of an otherwise steady job.

Whilst I will continue to pick up some part time contact work from my current employer, and wrap some things up in an orderly manner, the plan is to focus on my own project goals for at least two days a week.

In order to transit gently into this new way of working – I have decided to take a break, and so I am off to San Francisco on Thursday for 12 days.

During this trip, I will be reacquainting with old friends and colleagues, and attending the annual Forth Day – which is held on the Stanford University Campus – by the Silicon Valley Forth Interest Group.

As well as meeting up with some of the Forth group I will be doing a  short presentation to introduce some of the things that I have worked on this year, plus some projects from other friends in the European Forth Community.

It’s a tall order, but somehow I have to condense some fairly  broad subjects into a concise 18 minute presentation. – so in a rather tenuous manner –  that’s why this blog begins with a picture of the Forth Bridge.

In this post I collect together some of the threads of various projects that I have started in the last 12 months – but for a variety of reasons have not yet been taken to conclusion.

Weaving these various threads together to make a stronger fabric – or canvas – on which I am going to paint a whole new strand of embedded technology.  It’s taken all summer, the UK MegaTour with Toby Yu, the forced escape from my day job, and a bit of time to rationalise and coalesce some ideas – and these will form the basis of my presentation at Forth Day.

The Ideal Forth Microcontroller?

Earlier this year I began working with simple microcontrollers, in particular the MSP430 with non volatile ferro-electric memory or FRAM.

The MSP430 makes a good choice as a Forth machine as a result of its 16 bit architecture, it’s not volatile FRAM memory and the inclusion of an instruction that allows the $NEXT  macro of the inner interpreter to be reduced to a single cycle instruction:

mov @ip+,pc

This indirect, autoincrement memory read instruction efficiently implements the $NEXT macro – and makes the direct threaded model for Forth superior to other threading models.

Key details of this direct threaded model and MSP430 eForth are now available in Dr. C.H Ting’s excellent book  “Zen and the Forth Language” – now  from Amazon, and I am indebted to Juergen Pintaske for making this publication available to the wider Forth Community. Dr Ting explains the inner working of the eForth implementation on the MSP430 in a most readable fashion and thus makes this key information available to a much wider audience.

Zen and the Forth Language: EFORTH for the MSP430 from Texas Instruments by [Ting, Dr. Chen-Hanson]

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

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

The MSP430FR5994 with it’s massive 256K of FRAM is a new addition to the FRAM range of microcontrollers and at  $3.76 (1000+) it is very affordable. Add to this an external SRAM memory and you have the makings of a powerful little machine.  With volume production, it’s possible to have a complete Forth system for around $5 – including the USB programming adaptor.

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

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

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

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

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


ChipStick was my first venture into creating an MSP430 FRAM board in the form of a 20 pin DIL module that could replace the MSP430G2553 that comes in the Value Line Launchpad.

It features a detachable programming section, USB serial interface and 128K of SPI SRAM – which can be powered or backed up by supercapacitor or LiPo cell..ChipStick_3

The early prototypes were created in March and sent out to various Forthers around the UK and Europe.  As a result there are now three ports of Forths available for this tiny design.

Fast Forth – Jean Michel Thoorens

Mecrisp – Matthias Koch

Camel Forth for MSP430 FRAM – by Michael Kalus

Additional support came from Juergen Pintaske, Dirk Bruehl, Lars Brinkhoff and Mark Willis.

Now that the MSP430FR2433 is in volume production – this prototype – slightly enhanced can go into production.



Image result for chipstick

Nanode 24

This year I am relaunching my Nanode Design and Technology company with a range of new board designs.

The tiny MSP430FR2443 used on ChipStick is now commercially available – whereas in March it was only available in sample quantities.  This means that I can push ahead with ChipStick and other related designs – including the even smaller Nanode 2016. This tiny module has the MSP430FR2433, which is $1.37 in production quantities, and the module can be fitted with external SPI RAM or FRAM  – up to 128Kbytes. If you need a capable microcontroller in a small space – then this will do much more than the Arduino Nano.

Inspired by my colleagues in France and Germany with their ports of Forth to the MSP430 and my own efforts with the diminutive ChipStick running SIMPL in March and April, I was please to see in July the long awaited 256Kbyte FRAM MSP430 had become available and I had a couple shipped across from the US. This little $16 board has to be the preferred platform for anyone serious about experimenting with Forth and other stack based languages – on a mainstream commercially available microcontroller.

  • 35 lines of GPIO brought out to Launchpad headers
  • 2 User LEDs and 2 switches
  • 256K bytes of FRAM!
  • Low Energy Accelerator – a maths coprocessor
  • microSD card
  • Super Capacitor
  • Very low energy with energy monitoring feature
  • Programming interface with USB serial connection

Talking to small microcontrollers has traditionally been done with a serial terminal link, a text editor or an Integrated Design Environment (IDE).

I have been rummaging a  new idea, which I hinted on  earlier in the Summer – which I am now going to call “Forth Bridge”. It’s a way of connecting widely differing computer or processor systems using Forth like commands to convey information and instructions.

The idea arose from the work that James Bowman and I did on the FT812 EVITA graphics processor board back in January.  Janes successfully applied the FT812 to his Gameduino II product – allowing a high performance handheld gaming device to be driven using an Arduino.  This is possible because all of the hardware needed to support the graphics of the LCD is provided in the FT812 – and the Arduino need only supply a list of commands in order to generate the graphics display – and not the actual RGB pixel signals.

This offloading of the video to the video co-processor is something that has been done in home computers ad PCs since the early 1980s, but the FT812 does this in a $5 chip – effectively reducing the 65MHz bandwith video signal down to a list of video control commands sent over SPI at a few tens of kilobaud this puts it firmly within the grasp of any small microcontroller.  I reworked James’s ideas so that the FT810 could drive a large LCD monitor at up to 1024×768 pixels – and thus my little EVITA board was born.

The next part of the jigsaw was to realise that all that Gameduino and EVITA are doing is connecting two computers together – one is a general purpose 8-bit microcontroller and the other is a machine dedicated to creating high bandwidth streams of pixels and rendering images.  The 32 bit spi commands that are sent between them is a  shorthand means of forcing the co-processor to execute it’s graphic generation primitives – so one computer is controlling another computer over a communications link. Whilst the ICs are generally only a few centimeters from each other – and SPI is the most appropriate comms interface, they could be in different rooms or continents, linked by RS232, ethernet or any other practical comms link.

The next piece of the puzzle was JM Thoorens Fast Forth – a direct threaded MSP430 FRAM Forth, which he supports with a simple serial UART connection to a PC. The only difference is that he is able to send Forth source from the PC text editor to the target at 6Mbaud using a low cost serial UART board that costs about a dollar from China (CP2104). Whilst the source code is sent generally from the PC to the target, there is no reason why debug and other interactive data cannot be sent in the reverse direction at a similar speed, and then be rendered by the PC, tablet or whatever to produce a highly interactive video display. If the PC emulates the command set of the FT810 – then the target can either talk to a real on board FT810  or  a PC – without changing the command set.

This then allows a whole host of interactive devices to be created from low cost microcontrollers fitted with low cost LCDs.  You may recall that I mentioned in the Summer that a 7″ touch screen is now about $30.

Commands, communications, computers talking to each other? This sounds like a job for Forth. An intelligent Forth, that runs across all platforms, that if I were naming it – I’d probably call it iForth. So I googled it, and I see that it already exists – and is well into its 21st year!

That’s good –  it makes the PC end so much simpler if there’s already a tool that can do all the heavy lifting.  So we can host a GUI, and IDE and whatever cross compilers that are needed on any platform from a smart phone, tablet, laptop or PC. And just reading that last sentence – the word GUIDE leaps out of the text. A graphical user interactive development environment…….

We can also start to explore some of the other ideas, I hinted on in the summer.  New ways to write code and display the inner workings of the processor we are targeting.  Now that  the target can send a lot more than a hex-dump or source code listing to the PC, we can start to look at new ways of understanding the way the code sits and runs on the target. We can interact with the processor in whole new ways to better grasp the application and see much further into the logic processes. And in this respect – it makes an excellent platform for education. More on this in  a later post

So we have a PC or tablet platform running an iForth toolset, and a useful “off the shelf” educational target in the form of the latest MSP430 FRAM launchpad running Fast Forth.The third thing in this unholy alliance, is to extend these principles to custom Forth processors – and this is the main thrust of my involvement this year.



Forth and FPGAs

myStorm is a low cost FPGA and ARM dev board – aimed at makers and hobbyists. It consists of a Lattice ICE40HX4K FPGA and an STM32L433 microcontroller.  There is also a 256K x16 SRAM closely coupled to the FPGA and a USB programming interface.

James Bowman has already ported his J1a Forth processor to the myStorm board and Matthias Koch has ported he Mecrisp Forth to the STM32 ARM M4 Cortex microcontroller. Now we have two very different processors, both running Forth – and coupled with a high bandwidth link.  This is where things start to become exciting.

Whilst the ARM M4 is a very capable processor in its own right, it’s main role is to provide a standard set of peripherals, interfaces and 5MSPs ADC  and make these available to the FPGA.  The user can then focus on the design of the FPGA, knowing that the peripherals are standard – and won’t need to be synthesised within the FPGA.  The user can then develop his ideas in the knowledge that all the support hardware is taken care of.


Image result for mystorm

Since the early 1960s, computer engineers have been connecting widely different computing systems together – sometimes this might be several machines on a network, but initially it started with just a complementary pair of machines connected to achieve a specific goal.

This idea of connecting two widely different computers harks back to the time of the first commercial transistorised machines – using RTL, DTL and eventually TTL to implement the architectures.
Digital Equipment Corporation (DEC) and Control  Data Corporation (CDC) are typical of players at this time – working on a class of machine which became the first mass-market, affordable (relatively) mini-computers.
I choose these machines  – because they were new stripped down 12 bit architectures – with the emphasis of reducing the complexity and cost of the system.
The CDC 160 series of 12 bit processors – reputedly designed over a long weekend by Seymour Cray in 1960 – that was created initially to serve as a I/O processing front end to the CDC 1604 mainframes and later modified in the mid-1960s (CDC 160A) to be  used as Peripheral Processors to the larger CDC 6000 series mainframe.
In a similar way, when Digital sold first a PDP-1 and later a PDP-4 to the Canadian Atomic Energy as a reactor controller – Gordon Bell and Edson de Castro conceived and implemented the PDP-5 ( the fore runner to the PDP-8 )- that was used as an analogue data capture front-end at their Chalk River Nuclear labs.
It’s with this heritage that I anticipate that the myStorm board will be used – providing the means to use the FPGA to capture and generate high speed data – for digital oscilloscope or logic analyser projects, and then use the ARM to package all this data up into a form that can be used to drive the display of a tablet or PC.
As you can see – the streams are converging – and we live in interesting times.








Posted in Uncategorized | Leave a comment

The Lost Blog – Part 4

Following an accidental deletion my Sustainable Suburbia Blog vanished from Blogger. Here is a partial restoration.

SIMPLEX – the EXtended Version Of SIMPL

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

Overall View

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Running SIMPL Code out of External RAM

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

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

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

Writing some Commands

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Porting SIMPL to MSP430FR4133

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

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

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

0 0

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

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

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

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

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

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

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

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

There is also AmForth for MSP430 – based on Brad Rodriguez’s  camelForth.

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

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

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

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

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

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

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

0 0
Chipstick – A complete “Retro” computer on a 40 x 11mm stick

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

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

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

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

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

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

Hardware Details

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

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

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

“Chopstick” – with the Programmer section removed

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

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

The board also makes the following provisions:

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

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

Other recent Posts on ChipStick

ChipStick – A Diminutive Dev Board

The $5 Forth Computer

First Steps to Building the $5 Computer

Digital Dust

Constructional Guide


Interfacing Memory

I/O Expansion

Graphical User Interface


0 0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Erm  – Wrong Chipsticks!
ChipStick will be a fully functioning FRAM MSP430 Forth System!

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

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

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

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

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

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

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

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

So long and thanks for all the fish…….


Posted in Uncategorized | Leave a comment

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.

Posted in Uncategorized | Leave a comment