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

The Lost Blog – Part 2 April to July

Intrigued by the architecture of the Parallax Propeller IC – which I discussed last week, I decided to bag a couple of dev-boards and have a go for myself.

I must say – that the more I read about this device, and explore the wide variety of uses that others have found for it, the more enthusiastic I feel for it.

It’s not an ARM, or an AVR or a PIC – it’s something fundamentally quite different.  It has humble beginnings, but appear to be able to punch above it’s weight.  It consists of a combination of 8 individual 32 bit processors arranged around a central servicing hub, each with local memory – fast SRAM, and the means to communicate through the central hub RAM.

Mastering the techniques of the Propeller, will give the novice a much greater understanding of how firmware and hardware can interact in a very positive manner  – to create a system building component – that appears to exceed than the sum of its parts.

Having spent the best part of 2 years designing ARM processors into products, I am very aware of the ever increasing complexity of modern microcontrollers. Approximately half of my code is devoted to setting up the peripherals, so that they do what the application demands.  Just flashing an LED on an ARM Cortex M4, takes about 10K of code, and about a week to reach that magic blink moment – from a standing start.

The tool chains to support these chips are becoming monsters – multi-gigabyte behemoths, that take a long time to master. Nothing is quick nor easy anymore – that’s why,  when I re-stumbled across Parallax’s Propeller (after some years) I was pleasantly surprised.

My Aims:

  1. Learn more about the Propeller and the means of controlling external hardware using it’s “soft peripherals”.
  2. Create a dev-board that can be applied to a number of projects – complete with a supporting infrastructure
  3. Explore the use of the on-chip VGA video generation, as a means of creating a sef-hosting,  more intuitive user interface – to improve my programming productivity.
  4. Re-visit Forth – either PropForth or Tachyon Forth – as a language for Hardware Exploration
  5. Apply this new software/hardware mix to solving everyday engineering problems.
Parallax are working on a new Propeller IC – which is currently available only as a verilog design that will run on an FPGA.  It appears to increase the performance of the existing design by a factor of about 8. When it makes it’s commercial debut, I shall be ready, prepared and waiting for it.
If everything else fails – and 32 bit processor performance plateaus in the next few years, preventing the relentless rise in complexity of the mobile devices we now use, we can re-invent it all – with a big bucket of Propeller chips!

Gimme Hardware 

The longest journey begins with the first step – and in this case that step was to source some suitable hardware, at fairly short notice  – and get experimenting.  Unfortunately, in the UK there are not many distributors who carry the Propeller device – but I did find Pimoroni in Sheffield, who have a board called a Propeller HAT intended to be mounted on top of a Raspberry Pi – available for a modest £15 each.

Propeller HAT (underside) – neat pcb in black solder-resist and gold flash

As can be seen from the photo, the Propeller Hat is a fairly simple circuit consisting of the Propeller P8X32A, a small EEprom (24LC32) a 6MHz crystal and a 3.3V regulator.

On the top side of the HAT, running parallel to the long sides of the pcb, there are  two 20 pin headers that break out the pins from the Propeller IC – all except P30 and P31 that are used for the serial interface.

Along the short sides of the pcb, are 12 pin female header sockets – which connect to various pins on the Pi GPIO connector.   In the centre is an area intended to take a self-adhesive mini-breadboard.

Making it Work

Unfortunately, there is a little bit of preparatory work to do before this becomes a general purpose Propeller 1 dev board, rather than a Pi specific one – as the eeprom is actually intended to be the identity eeprom for the HAT, and is not actually connected to the pins of the Propeller IC – doh!

Additionally the 24LC32 is way too small for the Propeller applications  – so the first job was to replace it with a 24LC256 – which fortunately I had available – left over from another job.

The following pins need to be linked before the Propeller will work as a stand alone.

EEprom Vcc  (Pin 8)   to 3V
EEprom  WP  (Pin 6 )   to 0V
EEprom SCL   (Pi Connector pin 28) to Propeller A28
EEprom SDA   (Pi Connector pin  27) to Propeller A29

The using an FTDI cable or similar USB to Serial adaptor

Pin 1   0V   GND
Pin 2   Not connected
Pin 3   +5V
Pin 4   Tx  to Pi Connector pin 8
Pin 5   Rx  to Pi Connector pin 10
Pin 6   DTR

Pi  GPIO Connector – as viewed from above “through the board”

It should be noted that DTR is normally low – and this will cause the Propeller to be held in Reset. (This confused me for quite a while!)  It is therefore necessary to invert DTR with an NPN transistor before connecting to Propeller Reset.

To make up for the missing Raspberry Pi, I used one of my Piano Forte pcbs to act as a base board for the Propeller Hat.  This provides power and a connection point for the FTDI cable, but also has footprints to accept 3 different wireless modules, a micro SD card socket and a Lithium battery boost and charge circuit. Whilst modifying the Propeller HAT was a minor inconvenience, it it more than made up for by the rapid access to a whole bunch of useful peripheral devices. The Piano Forte board also provides an Arduino Shield header format – allowing the Propeller to access all of the Arduino ecosystem too!

Four wires are needed to hook up the EEprom – see text
A  spare, bare, Piano Forte pcb provides power, comms and peripherals
Finally, it’s time to play Propeller Pirates!

Parallax has traditionally had a long history with microcontroller educational projects – beginning many years ago with the BASIC Stamp.  This tradition continued when the Propeller took over about 10 years ago with some well thought out kits and starter boards – aimed squarely at educating the newcomer about the unique language and interfacing techniques made possible with the Propeller.

With just a dozen or so resistors, the Propeller can generate VGA video and host a PS/2 Keyboard and Mouse – with this you have the basis of a complete mini-workstation, capable of running interactive BASIC or Forth, or providing the User Interface for other products.

Whilst searching for UK Propeller boards, I also found a rather neat application for the Propeller IC – as a serial controlled VGA generator – illustrated nicely in this video by HobbyTronix.

Propeller has been used for some fairly serious hardware projects.  It is not a toy by any means, and it’s ability to use software defined peripherals – make it virtually a unique device.

Several Propellers may be interconnected to form a more complex system, with the peripheral functions shared amongst them.  There is a product called Tri Blade – that contains 3 Propeller ICs – and 1Mbyte of 55nS SRAM.  One propeler handles VGA, keyboards and mouse, another is the main compute engine, and the third is dedicated for interfacing wit external devices – such as ethernet controllers etc.

Some of these boards – often built by interested enthusiasts – feature strongly on the Propeller forum

Here is  a mini board  P8XBlade 2 – by very creative forum member Cluso (Ray Rodrick).

Why I Like the Propeller

I’ve only been looking at the Propeller chip for about a week now, but already I am starting to like it – for a whole variety of reasons – some from the heart and some from the head.  Here’s just a few of those reasons, so far….

The Propeller concept is almost entirely the work of one very talented engineer, Chip Grasey.  Whilst most ICs are these days designed and implemented by a team of engineers – with a multi-million dollar budget, Propeller was developed by Chip aided by a group of friends and co-workers.

Propeller has some very flexible hardware, in the form of counters, which can be used to create a variety of peripheral functions, assisted by some fairly tightly coded assembly language program modules.

The 40 pin DIL version is very easy to prototype with on stripboard, breadboard or perfboard.  As all pins can be allocated to any function, there are no restrictions on what you can connect to what.   Reversing the bus order, or swapping Rx and Tx pins on UARTS becomes simple – just change the code. This is as close as we get to soft-hardware!

Propeller is scalable – more Propeller chips can be added to extend the functionality of a design. PropForth comes with a library that allows high speed communication between Propeller chips. Here’s one example of TetraProp – four Propeller ICs on a small board – all talking to a master device with micro SD card.

TetraProp – Four Propeller ICs on top, and another Master IC below

There is a strong community and forum behind Propeller.  Chip Grasey is a regular contributor and treats his customers as friends and co-developers.

The Propeller Tool is by today’s tool chain standards a fairly small program.  The executable has a disk image size of just 4Mbytes,  and the whole package, of tool, examples and documentation is about 35Mbytes.

The IP behind the Propeller IC has been open-sourced. You can study every detail, modify and create your own variations which will run within an FPGA.

The open core and multi-processor design of the Propeller IC lends itself to demonstrating the fundamentals of digital microelectronics and microprocessor architecture, and is a perfect platform for studying electronics and computing science at undergraduate level, with sufficient content to encourage creative development.

An article – originally written for RS Components by William G. Marshall – about 6 years ago – captures succinctly some of the key aspects of propeller.

Incidentally, RS Components stock Propeller devices! – both DIL-40 and 44 pin LQFP  – this is good to see that at least one of the big UK/Global Distributors is still supporting these devices.

Next Time

In the next part of this series, I will hopefully have had a chance to play with various aspects of the Propeller, had a look at Tachyon Forth, and will have some peripherals including VGA, keyboard and mouse wired up to the board.

I am not planning to write a book on this processor – that has already been done elsewhere by skilled users. I am just hoping that the information I offer here is sufficient to encourage others to have a fresh look at this fascinating device.

FT812 pcb provides pin connectors for VGA , PS/2 Keyboard and Mouse 

A broad outline of future blog-posts in the pipeline would be (subject to change).

Interfacing VGA, Keyboard and Mouse to Propeller IC using Evita pcb – above

Tachyon Forth

Basic Peripherals – GPIO, SPI, I2C, UARTS, ADC, DAC, Audio

microSD Card

Further Graphical Distractions

Almost a month ago I wrote about using low cost graphical display hardware to enhance the user experience. Now some of my ideas are starting to gel – as new hardware and firmware ideas begin to fall into place.

Guido Fawkes

Guido (Guy) Fawkes was a late 16th, early 17th century rebel who plotted to overthrow the Establishment and bring about a New Order, by way of disruptive change.

(Not to mention an ultimately failed attempt at spontaneous religious regime change caused by rapid release of energy and undesirable thermal events involving gunpowder etc…).

Whilst all this historical content is good to know, GUIDO FAWKES is also the proposed name for a new microcontroller programming environment that I have been mulling over for some time which might possibly inspire change to the established ways of working, or ultimately fizzle out  – like a damp squib.

It’s just been a case of waiting for all the component parts to fall neatly into place, and then come up with suitably corny acronyms.

Serial Terminals

It has been commonplace for decades to use a serial terminal or teletype to hook up to to a computer system for text entry and output.  However, a serial terminal can only provide a limited window into the memory of the device, and involves generating a file of text within a text editor environment, which is then compiled to a hex file and sent to the target system. Modern IDEs just recreate this environment, and chuck in a whole load of bells and whistles – that you may or may not need.

If you look at a modern tool chain IDE, it represents tens of megabytes on the hard drive, unnecessary complication and generally does not really improve the text editor experience.

What we need is a computing hero (like Charles Moore or Ken Thompson) to come along and make our lives all a lot easier.  It is within this context that I introduce the concept of Guido Fawkes.

So who or what exactly is Guido Fawkes?

The Guido Fawkes (G-F) proposal is for a two part graphical development environment for generating/developing code for microcontrollers, or other code based devices – such as FPGAs.  It doesn’t really matter what microcontroller, G-F is intended to be a generic application.

Currently, I have surrounding me, now as I type, ATmegas, MSP430s, ARM Cortex M3, M4,  M7 and now Parallax Propellers. In terms of FPGAs I have Altera Cyclone IV and Xilinx Spartan 6 dev boards. Hopefully they will all benefit to some extent from this new direction.

Guido is the part that runs on the PC (Windows, Mac, Linux) and provides Graphical User Interaction (GUI) and Disk Operations (DO).

Fawkes is the part that runs on the microcontroller, with a Forth Application Window, (FAW) Keyboard, Editor and Serial  (KES).

I don’t think I can spell it out any simpler than that!   (But as a 4 year old – I thought his name was Gi-Forks – so there may be still some scope for an acronym or two there).

The whole point of GF, is to allow disparately challenged microcontrollers or computers to communicate with each other, by way or a simple serial (or other) communications channel, and a common language – a Lingua Franca.

So that’s it – the concept in just 3 sentences.  Now I just have to flesh it out using the tools I have available.

Tools for the Job

You will notice that I have been very sparing with detail, in the above brief.  That is because I want to keep things generic.  The PC can be Windows, Mac or Linux – or possibly a tablet running Android, –  and these days, the PC should not be tied to a specific class of machine.

The microcontroller target can be anything from an Arduino Nano to an ARM M7.  The point being that virtually any micro can host a Forth interpreter and handle the serial communication and word interpretation/execution application requirements.

In short, “Gi-Forks” is designed to be flexible enough to port to virtually any microcontroller.

My first thoughts for Guido is to use “Processing

Processing is a flexible software sketchbook and a language for learning how to code within the context of the visual arts. 

Processing is essentially similar to coding on Arduino (in C++ language with supporting libraries), but runs on any of the common platforms, – including the Raspberry Pi,  accessing the capability of their graphics and disk file system.

The target system becomes essentially an I/O or sensor board for the PC – but also more than this, as I will endeavour to explain.

I said that the two systems share a common language so that they may communicate, and for convenience this will be similar to Forth.

This Forth will likely be written in the native assembly language of the target – for maximum speed and minimum footprint. Forth is compact and well defined and translates well to the various instruction sets.  There are implementations of Forth for ATmega, ARM and MSP430 plus virtually every other small microcontroller – from the 6502 and 8080 onwards!  A TinyForth interpreter can be shoe-horned into just 2Kbytes – if written is assembly code, and seldom do they ever exceed 8K.

However, on the PC, native assembler is just too hard, and so a high level language, in this case C++ and Processing is used to to the heavy lifting.

The combination of GUIDO + FAWKES provides an operating and development environment which shields the user from  both the complexity of the PC’s system and the low level nature of the target, yet providing a high level of user interaction, as Forth is fundamentally and interpreted language.

Guido  – The Plot Thickens

On the PC, Processing is used to build the Graphical Interactive environment, Guido and handle requests for drawing objects and disk access.  The Forth interpreter is used to the handle the command stream from the serial port and update the GUI.  This command stream may typically consist of a “display list” of objects, which the GUI has to display.

In short, the microcontroller has the ability to instruct the PC to paint any pre-specified objects at whatever position on the GUI screen – objects consisting of a montage of character graphics, text boxes, lines, circles, windows and bit-map graphics – in fact all of the elements that go up to make a modern GUI screen.

In the simplest case, the target could request a “terminal window” of given size and given position, and just send ascii text to it. This might be as a result of the User wishing to “see” a decompilation of a given Forth definition.  The user could then highlight this text with the mouse, edit it in some manner and send it back to the target – where it would be treated as an updated definition.


Fawkes is the part running on the target – and it has to be small and lightweight.

Fundamentally it can work in either tethered or untethered mode. In Untethered mode – we have essentially a stand-alone system, either with a local VGA monitor or a touchscreen LCD.

In tethered mode, the serial comms acts as an umbilical back to the PC, and we use the resources on the PC to act as our screen and file system.  Tethered mode is likely to be used primarily for code development, debug or for small target systems (eg Arduino Nano etc) which are unlikely to support a usable screen.

FAW  – Forth Application Window(s)

Forth can be made multi-tasking and support more than one display window. As long ago as 1984, I had a Forth that ran from ROM on a ZX81 and generated two text windows.  One was the console, for entering immediate commands and the output of the Forth virtual machine, the other was for output generated by the VM when running the application.

In a simple Forth system there is a process that handles output to a serial terminal – sending plain ascii characters.  In the Fawkes system, this process needs to be extended – allowing the plain text output to be tagged for display and graphical objects generated in memory as a series of graphic commands.

DisplayList – This is the process that updates the screen.  If we are in self-hosting mode with a local display, generated by some graphics engine, then this process generates the list of display objects needing to be updated. This list can be passed to the graphics engine – generally by SPI or sent to the PC – for display on the PC’s monitor.

For example, if the system supports a mouse, then when the mouse is moved, the mouse cursor position needs to be updated on the screen.  If a mouse button is clicked – then some action may be required on that event, – such as opening up a menu box etc.


KES is a 1969 film about a young, northern, working class lad who rescues a kestrel chick, directed by Ken Loach, with Brian Glover as a baldheaded ignoramus PE Master.

It is also the name given to the second half of the FAWKES double act – and refers to Keyboard, Editor and Serial comms.

KES takes the text input from the Keyboard – or the serial comms, parses it in a buffer and executes the Forth outer interpreter.  Any output from the outer interpreter is passed to FAW for display processing.


G-F was originally inspired by the GameDuino series of games consoles, by James Bowman.  In Gameduino 2, an Arduino is used to generate a 1980’s style video game on a colour LCD touchscreen. Whilst the Arduino cannot synthesise the graphics itself, it can instruct a dedicated graphics co-processor to do it – according to a display list, and as such, uses an FT810 “Embedded Video Engine” or EVE for this purpose. Over Christmas 2015, James and I re-purposed the FT81x IC so that it drove a resistor network and allowed the video output to be displayed on a widescreen monitor.

When recently I re-stumbled over the Parallax Propeller, with it’s 32 bit multiprocessor architecture and VGA video generation capability, I realised that there was clearly going to be more than one way to implement G-F.

For standalone applications, there is already a commercially available implementation of the serial driven VGA video display terminal from Hobbytronics in the UK.  Looking carefully at the pin-out below – it looks as though this has an FTDI cable compatible 6 pin header on the left. With a bit of jiggery pokery, the spare lines on pin 2 and 6  (RDY and RST) could be hacked to create a PS/2 keyboard or mouse interface.  Equally well, the system could be implemented on a Propeller Starter Kit – which benefits from keyboard and mouse connectors. Sadly the Starter Kit is no longer available.  However, with the DIL 40 Propeller it could quite easily be recreated on stripboard.

Serial VGA Monitor Driver board
Serial VGA Monitor Driver Board – from Hobbytronics (UK)
Propeller Starter Kit – sadly no longer available – but well Overdue for a Respin!

Next Time

In the next part of this saga I look at some examples of how G-F can be applied.

Additionally, putting money where mouth is – something running on the Propeller – and possibly some tie in with Processing.

The following entry was penned as a contribution to the Parallax Propeller Forum – hence the slightly unusual style.

Here are some notes on how I see the G-F interaction:

We are essentially recreating a late 1980’s style home microcomputer, of the 512kByte to 1Mbyte class (think Commodore Amiga, Atari 1040ST, Acorn Archimedes) but with a Forth inspired GUI – all running on 1 or 2 Propellers.

Plus we now have all the benefits of touchscreen LCDs, micro SD cards for Gigabytes of storage, non-volatile FRAM, high resolution large screen monitors, PS/2 keyboards and mice and very low cost RAM and cpu technology – we couldn’t even dream of 30 years ago.

I too think that there is merit in using small packets of Forth to communicate between widely different systems – in your example Propeller and Pi.
In more general terms I see Forth as a kind of Lingua Franca, which allows small packets of data and executable code to be freely exchanged between different micros, within a context framework (tags) that instructs the recipient to what they are, and what to do with them. This has a a slight smell of Chuck Moore’s ColorForth, but the way the tagging is implemented may be different.

In my workplace and hobby environment, I have a mix of ARM M3,M4, M7, Atmel AVR, MSP430 (FRAM based) and now Propeller. I also have J1 Forth cpu and Oberon system running on Spartan 6 FPGAs.

Trying to bind that lot together in a meaningful way is a little difficult, unless you can reduce everything down to a common Forth, or Forth-like language.

I had a couple of ideas to make the proposed environment easier to work in. After all, Chuck Moore developed Forth to give himself an easier, more productive computing environment – where he was in control.

So I came up with the (unoriginal) idea of BootForth – which is the smallest Forth kernel needed on an mcu, so that it can support a serial communication port, and compile source code from a terminal – allowing an application to be loaded.

There are some TinyForths out there – I found this one for the ATmega – that when written is assembly language is around 1800 bytes. It’s also offered in C.

(Use GoogleTranslate to translate from the Japanese)

BootForth is really just an extended serial bootloader. It is included in protected Flash in the bootloader segment on every mcu you wish to use – and it’s role is to provide the load mechanism – and present a standard programming interface.

In this way, mcu type A can communicate with mcu type B – regardless of what manufacturer or family they belong to.

I got some way to generating a BootForth for various micros – written in C for portability. I have so far used it on ATmega, STM32Fxxx ARM and MSP430. In it’s smallest state – it’s around 2Kbytes of Fash (or FRAM).

BootForth uses single ascii characters as word tokens. This drastically reduced the overhead of decoding words and jumping to the code.

IIRC, the ability to scan through an array of ascii characters and jump to an executable code address based on the value of the character can be reduced to a few hundred bytes – including UART code for key and emit and (getc and putc).

Forth is only verbose (6 significant character plus “length” word format) to make it more human readable, and to allow a large dictionary.

If we reduce our dictionary to 5 bit or 6 bit tokens that immediately reduces the side of the array needed to hold the source. We hold the expanded names of the kernel in ROM – so that we can regenerate the more verbose sourcecode later if needed.

Primitives are coded up as lower case alpha and punctuation characters, whilst user definable words use uppercase alpha characters. That restricts the number of useful words it recognises to about 80 – but it does make the source code readable as a compacted form of Forth – rather than random ascii gobbledeegook.

Restricting the code to ascii chars, makes the source very compact and quick to load and compile.

Source code can be loaded and compiled extremely quickly with a 1Mbaud+ serial terminal – or equally the sort of thing that could be sent in over the air wireless packets, 140 character tweets, (SMS messages), BLE or any other short packet communications method.

By way of example:

Consider the classic washing machine example consisting of the following high level words:


This can condense down to a 7 character string “FADFRDS” plus return.

Integer numeric parameters may be added before the words – without whitespace, allowing a compact 16 byte program


5 litre FILL
100 Agitations
5 Litre FILL
1300rpm SPIN

In Forth this would be 5 FILL 100 AGITATE DRAIN 5 FILL RINSE DRAIN 1300 SPIN

About 53 characters – 70% of which are redundant to the actual logical meaning of the application.

The complete WASH application can be initiated just by sending a single upper case character “W” – followed by return.

Go back and try applying this to your RasPi sending serial instructions to your lathe controller – and you will see just how compact it can be.

If a word requires multiple parameters on the stack, then you need a separation character, which when interpreted pushes the stack down to make way for the new number. I use the space for this – which makes the code fairly readable.

e.g. Plot a pixel at x, y (100,200)

100 200P

This conveniently brings me onto idea #2 – Graphical commands


I got interested in the use of GUIs for creating a better programming environment and less arduous experience. Sequential access into source code using a traditional terminal – constantly scrolling up and down to find a particular block of code is something that is rooted in the teletype and CRT terminal days of original Forth.

As we now have LCD monitors of high resolution, why not lay out the upper levels of the source code out as a 2 dimensional picture of objects – using the whole screen to show the application.

Use of colour, text boxes, drop down menus and a mouse-clickable objects presents the application code in a highly visible format and allows you to drill down to the individual definitions you wish to edit.

Here’s how I envisage it working:

In it’s simplest form, it is used to display the words in the dictionary as clickable coloured text boxes on the screen. (You are able to choose the colour to give meaning to your specific application) Clicking a word executes it – in immediate mode. There also needs to be a text box that allows you to enter the various parameters onto the stack before the word is called.

Right clicking the word opens up the source code behind it – showing all the dependencies. You can further click on these dependencies – each of which open a source window until you get down to the primitives.

Consider the Washing Machine example above – with the five definitions FILL, AGITATE, DRAIN, RINSE and SPIN arranged as small text boxes on the screen – all below the top level word WASH.

Beneath these words would be textboxes for any other dependencies – until you get right back to the Forth primitives.

At a glance, the screen shows graphically the whole application – and you can mouse click on any word and begin to edit the source.

This scheme can also be used for writing new source code.

You have a command that creates a new code object – i.e. a word. On the GUI screen this has the effect of creating a new text box – into which you write the name, and the code associated with that new definition.

Included in the source you may use definitions that have not yet been defined – and the first pass of the compiler detects these and generates the accompanying text boxes in readiness for you to add the definition code.

You should be able to tab between words, and a single right click of the mouse to “see” the source.

A mouse click to expand a word, generates a short Forth sequence that requests the mcu to send the source for that word – basically it sends the “see” word followed by the name of the word that you wish to decompile. The mcu sends the source within a wrapper of GUI commands that ensures that it is displayed on the screen where you want it.

At the other end of the serial (or other comms) link, the PC can be used as a disk filesystem, if there is no local SD on the Propeller target – with file open, close read and write requests being sent over the serial connection. This could utilise the traditional Forth BLOCK, LOAD SAVE words, but I suspect that we have moved on a little since such a regimented system.

As I am not a PC application programmer, I would use something like “Processing” to generate the GUI and Disk O/S – “GUIDO”. It’s cross platform – so will run on any PC including the Raspberry Pi. That makes it accessible to and hackable by, – anyone.

Remember that it is the Propeller that is generating this GUI content – all the PC is doing is displaying it conveniently, object by object. The PC provides the mechanics of the display, a set of displayable objects – but not the content.

All of the content, in terms of the objects to display and position, colour etc is controlled by the target mcu. In this way, if you have no PC present, the whole thing becomes self hosting, with the Propeller running a small O/S which handles the Forth Application Window, keystrokes from PS/2 keyboard, mouse data and clicks, editor and interprets the commands over serial.

Forth Application Window, Keyboard, Editor, Serial = “FAWKES”

Put them together and you have GUIDO running on the PC and FAWKES running on the target microcontroller or FPGA.

In terms of the hardware, I started looking at the FT81x series of embedded video engine (EVE) chips to create this GUI. They use a simple list of 32-bit words to build up the screen, object by object.

So I thought that the “display list” that is normally sent as SPI commands to the FT81x graphics controller IC, could be sent over a serial link to an application running on a PC – which emulates the FT810.

It was about that point where I re-stumbled across Propeller, and realised that the whole thing could be done using Props generating VGA and supporting a mouse and keyboard.

I then came across Ray’s Logic “PropMonitor” and realised that this was mostly what would be needed on the PC end.

There’s a lot of coding to get this to work, but I hope that you get a flavour of what I am trying to implement. The ideas behind this concept are purposefully kept simple and generic. Whilst it might apply to Propellers and ARMs today – who knows what we might be programming in the near future.

0 0
This could come in handy……

Some of you may be familiar with the recently available, Chinese produced CH340G USB to serial converter IC, that offers a very cost effective alternative to the FTDI part. No more paying over $3 for FT232R – when you can pay under $0.50 for the same function.

You may not know that the CH340 is just one of a series of about 60 ICs produced by Jiangsu Heng Qin,  (WCH)  in Nanjing, China.  These ICs provide very useful circuit functions, at very low cost – yet until recently have been virtually unknown to designers in the West.

WCH are amongst a small group of Chinese and Taiwanese chip manufacturers – including Holtek * and UMC, who produce a vast volume of low cost ICs for some of the most basic, yet essential building block circuit  functions. These form the bread and butter devices built into Far Eastern manufactured consumer products, such as MP3 players, telephones, flash drives, USB peripherals etc.  Their chips are literally in everything we buy and use. We just don’t get to hear of them so much about them – as we do, of those semiconductor companies founded in the West.  (* I will feature Holtek in a later post).

Yet until the CH340 arrived on our shores – there was very little knowledge about any of these Chinese domestic ICs. Data sheets have been often only available in almost impenetrable Chinese language, and even if you did find an interesting device – how and where would you source samples of it, or prototype it with it? – with so very little information available.

Fortunately these barriers to creativity are now becoming a thing of the Past. The Chinese language is no longer a problem – thanks to the almost instantaneous translation available using Google Translate, and there are an increasing number of specialist vendors in southern China, who will gladly source you a few samples and post them over to you.  These guys are only a Skype call away – and eager to do business with Western customers. The electronic industry around Shenzhen is unique in that there are literally hundreds of small component vendors who will gladly sell you the parts in individual quantities.  Matching a particular part and finding samples is something that they take pride in – and will go the extra mile to keep their customers happy.

As an aside note. When prototyping with modern IC packages – you often need an SMT adaptor board to accept the SMT package and convert into a DIL footprint.  These prototype adaptors can be quite expensive if you source them from Mouser or Digikey – so here’s a tip for free  – buy them for a few cents each – from these Guys.

QFN32 prototyping adaptor – yours for about $0.10

A Look at some useful Chinese ICs

This post is a little bit different to my usual musings – in that, this time, I explore some of the fascinating IC offerings of the little known IC manufacturer WCH,  in the hope that knowing more about some of these otherwise unfamiliar devices might trigger some design ideas, amongst the hardware product design creatives.

If you like reading about obscure, dirt cheap ICs – carry on.  If not, may I suggest you quit now – whilst you are ahead – there’s bound to be some kitten videos somewhere on the web.

I have no commercial association with WCH –  I just like to use their chips.

WCH     company profile

Jiangsu Heng Qin Ltd. (WCH)  is located in the heart of Nanjing Software Valley is a technology-oriented high-tech enterprises, the core business is the interface class IC, SOC/MCU class of integrated circuits and embedded software development and sales. In the information industry speed the development of technology in an increasingly competitive today, the product of high-tech, user-friendly development path has become a technology-based businesses to comply, the forefront of technology Qin Heng people aware of this concept, and therefore continue to raise Jiangsu Heng Qin large R&D investment, improve R&D system, technology and development. Currently, we have a professional research team with independent research and development capabilities, and gain the right to layout-designs of integrated circuits, software copyrights, patents and a number of independent intellectual property rights. Companies focus on R & D investment and innovation, but also paid great attention to building its own brand, registered international trademark in many countries and regions in the United States, Britain, Germany, Korea, Taiwan and Hong Kong. Jiangsu Heng Qin was identified as the national high-tech enterprise, integrated circuit design enterprises, private technology enterprises in Jiangsu Province, Jiangsu Province, SME, the contract and trustworthy enterprise.
Jiangsu Heng Qin around the core business, with many domestic and foreign professional companies together to provide integrated circuits and overall applications with independent intellectual property rights. Jiangsu Heng Qin product positioning: professional, easy to use, the product is mainly used in the financial tax, information security, industrial control and other fields. Jiangsu Heng Qin technical services and application solutions covering electronic circuit, microcontroller and DSP and embedded software, computer system architecture, especially in the SCM system networking, interoperability of electronic products and computer aspects of the underlying computer hardware and software with professional technology service. Our strength lies in seamless connectivity and collaboration between software and hardware, the mutual penetration and conversion, and thus provide an overall cost-effective professional applications.

In the Future, Jiangsu Heng Qin will continue to lead the development of the domestic IC industry to meet the challenges of ever-changing global IC field, you become more professional and reliable partner.

Low Cost Communications and Interface Devices

WCH have specialised in communication and interface ICs including serial UART, USB functions and ethernet – plus all manner of devices to form bridges between these comms functions.

They have devices for extending USB down 100m of CAT5 cable – by converting to and from 1000 base-T. Also devices for extending keyboard, VGA and mouse functions.

They also produce some 8 bit and 32 bit microcontrollers, based on enhance 8051, and ARM core, with internal USB functions, that may be customised to provide USB Host or peripheral device functions.

Finally, though perhaps not so relevant for the hobbyist, they have range of PCI peripheral devices – the sort of devices that are embedded into PC Expansion cards.

In addition, there are some memory parts (4K FIFO, 66 byte Dual Port RAM) plus a range of devices to manage micro SD cards, host USB flash drives and serial memory, providing FAT16 and FAT32 functionality.

All of their devices are very reasonably priced, (mostly < US$ 3.00 ) and available through the specialist vendors in Shenzhen from the Electronics Market.

Making full use of Google Translate – the WCH website and datasheets have become a lot more accessible.

I have selected some of the more interesting devices in terms of UART, USB, I2C and ethernet devices and translated the introductory outline which describes the function.  If you want the full information – click on the link and use Google Translate (right click) to perform a page translation.

PDFs may be downloaded from the download page – along with C code examples of drivers.

If you are interested in samples contact toby dot yu3 at gmail dot com

Toby runs “Man Friday” – a specialist component sourcing and manufacturing logistics company out of Shenzhen.

Here is a quick translation of their Application Solutions Page  – all in blue italics are clickable links to applications:

The list below is quite extensive – my personal favourites are:

CH317   USB extender over Ethernet – 100m extension via Cat5 cable
CH376   USB Host for Flash drive and uSD cards
CH9130  A multi-peripheral device connected via ethernet
CH9121  An ethernet controller accessed by serial UART
CH395   A Wiznet W5100 competitor.
CH943   USB to 8 or 16 UARTs
CH9331 A uSD disk using serial memory devices
CH341   Multi peripheral functions over USB

Have Fun.

Microcontroller Family  – a mix of 8051 8-bit, 8-bit RISC and 32-bit (ARM9) RISC parts.   

CH557 is a compatible enhanced E8051 core microcontroller MCS51 instruction set, 79% of single-byte instructions are single-cycle instructions.
CH557 provide a rich interface resources, including built-in classes 485 data transceiver, LED control card interface and the capture function level, others include a group of SPI, 2 serial ports, parallel ports, etc. 8, UART1 compatible 16C550; built-in timer 4 group ; provides one 16-bit PWM and two 8-bit PWM; supports 8-channel 10/11 bit ADC.

  •  CH558      Enhanced 8051 USB mcu for peripheral device applicatios
  •  CH559      Enhanced 8051 USB mcu for Host applications
  •  CH563      32 bit 100MHz RISC
  •  CH536      8 bit 12MHz RISC for USB Host/Device Applications
  •  CH537      Multichannel USB mcu  – for Hub applications

Network Chips

  •  CH9130   Ethernet Multi-Function Peripheral IC
CH9130 is a tool for Ethernet expansion of multi-chip peripheral interface, built-in 10/100M Ethernet media transport layer (MAC) and physical layer (PHY), fully compatible with IEEE802.3 10 / 100M protocol can be extended simultaneously: 2 Road UART, 16-way GPIO, 2-way SPI, 3-way PWM, 1 channel 3-channel ADC, 8-bit parallel port or passive 8/16 bit bus interface. End PC with a network interface library, you can quickly achieve a variety of network interface devices.
  •  CH9121  Serial Connected Ethernet Controller
CH9121 integrated TCP/IP protocol stack, enabling network data packets and transparent two-way serial data transmission, with TCPCLIENT, TCP SERVER, UDP 3 modes of operation, the baud rate support up to 921600bps, can be easily configured via PC software, Convenient.
  •  CH395   Ethernet Controller with on chip TCP/IP Stack, MAC & PHY
CH395  Ethernet protocol stack management chip, for single-chip system for Ethernet communications.
CH395 chip comes with 10/100M Ethernet media transport layer (MAC) and physical layer (PHY), fully compatible with IEEE802.3 10/100M protocol, built-in PPPOE, IP, DHCP, ARP, ICMP, IGMP, UDP, TCP, etc. Ethernet protocol stack firmware. SCM system can easily network communication through CH395 chip.
CH395 supports three communication interfaces: 8-bit parallel, SPI interface, or asynchronous serial interface, the MCU/DSP/MCU/MPU and other controllers for Ethernet communications through any of the above communication interface control chip CH395.

USB Series Devices

  •  CH378  microSD card and USB Flash Drive Disk Management & Control IC
CH378 is a file management control chip, single-chip system for fast read and write U disk or SD card file.
CH378 supports USB device mode and USB host mode, and built-in basic firmware USB communication protocol, built-in firmware processing Mass-Storage mass storage devices dedicated communication protocol, built-in SD card communication interface firmware, built-in FAT16 and FAT32 and FAT12 file system management firmware to support popular USB storage devices (including the U disk / USB hard disk / USB flash drive / USB card reader) and SD card (including standard-capacity SD card and high capacity HC-SD card and protocol compatible the MMC card and TF card).
CH378 supports three communication interfaces: 8-bit parallel, SPI interface, or asynchronous serial interface, the MCU / DSP / MCU / MPU and other controllers can be any of the above communication interface chip CH378 control, access U disk or SD card file or communication with the computer.

  •  CH376   microSD card and USB Flash Drive File Management & Control IC
CH376 is a file management control chip for the SCM system to read and write U disk or SD card file.
CH376 supports USB device mode and USB host mode, and built-in basic firmware USB communication protocol, built-in firmware processing Mass-Storage mass storage devices dedicated communication protocol, built-in SD card communication interface firmware, built-in FAT16 and FAT32 and FAT12 file system management firmware to support popular USB storage devices (including the U disk / USB hard disk / USB flash drive / USB card reader) and SD card (including standard-capacity SD card and high capacity HC-SD card and protocol compatible the MMC card and TF card).
CH376 supports three communication interfaces: 8-bit parallel, SPI interface, or asynchronous serial interface, the MCU / DSP / MCU / MPU and other controllers can be any of the above communication interface chip CH376 control, access U disk or SD card file or communication with the computer.
CH376 and CH372 USB device mode is fully compatible chip, CH376 and CH375 USB host mode chip basically compatible.

  •  CH375   USB Host/Device Bus Interface IC
CH375 is a common USB bus interface chip that supports both USB-HOST mode and USB-DEVICE / SLAVE mode device. The local side, CH375 with 8-bit data bus and read, write, chip select control lines and interrupt output can be easily attached to the microcontroller / DSP / MCU / MPU and other controllers of the system bus. In USB host mode, CH375 also provides serial communication, serial input, serial output and interrupt output and MCU / DSP / MCU / MPU, etc. are connected.
CH375 and CH372 USB device mode is fully compatible chip, CH375 contains all the functionality of CH372. This manual does not provide instructions in CH375 USB device mode, the relevant information can refer to the CH372 manual CH372DS1.PDF.
CH375 USB host mode supports common USB full-speed device, the external microcontroller can follow the appropriate USB device communication protocol and USB through CH375. CH375 also built firmware processing mass storage device Mass-Storage dedicated communication protocol, the external device can be directly read and write the basic unit of a sector common USB storage device (including USB hard disk / USB flash disk / U disk).

  •  CH374   USB Host/Device Bus Interface IC with Parallel or SPI Interface
CH374 is a common USB bus interface chip that supports both USB-HOST mode and USB-DEVICE / SLAVE device mode, built-in 3-port HUB root hub, support low-speed and full-speed control transfer, bulk transfer, interrupt transfer and synchronous / isochronous transmission. The local side, CH374 with 8-bit data bus and read, write, chip select control lines and interrupt output can be easily attached to the microcontroller / DSP / MCU / MPU and other controllers of the system bus. In addition, CH374 also provides a saving I / O pin SPI serial communication via 3-wire or 4-wire SPI serial interface, and interrupt output and MCU / DSP / MCU / MPU, etc. are connected.
  •  CH372  USB Bus Interface IC
CH372 is a USB bus universal device interface chip, an upgrade is CH371, CH375 chip function is a simplified version. In the end, CH372 with 8-bit data bus and read, write, chip select control lines and interrupt output can be easily attached to the microcontroller / DSP / MCU / MPU and other controllers system bus; in a computer system, CH372 supporting software provides simple user-friendly interface and communicates with local MCU is like reading and writing files.
CH372 built-in USB communications in the underlying protocol, save the firmware up internally mode and flexible external firmware mode. Built-in firmware mode, CH372 automatically handles all matters default endpoint, 0 and local MCU as long as the responsible for data exchange, the SCM process is very simple. In firmware externally mode, external MCU deals with various USB requests according to requirements, which can achieve compliance with various USB class specification.

  •  CH370  USB Host Interface IC with Parallel or SPI bus.
CH370 is a USB bus Host Host interface chip that supports low-speed and full-speed bulk transfer and control transfer and interrupt transmission, and MCU / DSP / MCU / MPU and other controllers interface supports 8-bit parallel bus and 4-wire or 3-wire SPI serial bus.
  •  CH9343   Android Host Interface  UART, GPIO, PWM, I2C, SPI
CH9343 is a highly integrated, low-power, single-chip full-speed USB Android Host interface control chip, can be configured as six kinds of expansion interfaces: UART, GPIO, PWM, I2C master, SPI master and slave SPI for built-in USB device interface Android devices to access external components.
  •  CH9326      HID Serial IC
CH9326 is a HID serial chip. CH9326 supports two-way data transmission, for receiving serial data, and in accordance with the HID class device specification data package uploaded to the computer through a USB port, or from a computer to receive data packets compliant with the USB HID class device, and transmitted from the serial port. By increasing the external EEPROM devices, users can configure their own chip VID, PID, and a variety of string descriptors.
  •  CH341  USB to Parallel, UART, SPI, and I2C Interface Bridge
CH341 is a USB bus adapter chip, providing asynchronous serial interface via USB bus, printer port, parallel port and the common 2-wire or 4-wire synchronous serial interface. In asynchronous serial interface mode, CH341 provides serial port is enabled, the serial port on the other interactive reception rate control signal and the common MODEM communication signals for the computer extended asynchronous serial port, or an ordinary serial device upgrade directly to the USB bus.
In the printer port mode, CH341 provides a compatible USB relevant norms and Windows operating system’s standard USB printer port used to upgrade ordinary parallel printer directly to the USB bus.
In parallel mode, CH341 provides a way to EPP or MEM mode 8-bit parallel interface, without the need for microcontroller / DSP / MCU environment, direct input and output data.
In addition, CH341A chip also supports some common synchronous serial interface, such as 2-wire interface (SCL lines, SDA line) and the 4-wire interface (CS line, SCK / CLK line, MISO / SDI / DIN line, MOSI / SDO / DOUT line).

  •  CH340 USB to Serial Adaptor
CH340 is a USB bus adapter chip, USB to serial port, USB to IrDA infrared, or USB printer port forwarding.
In serial mode, CH340 provides common MODEM liaison signal for the computer extended asynchronous serial port, or an ordinary serial device upgrade directly to the USB bus. Turn on USB printer port are described in the Reference Manual (b) CH340DS2.
In the infrared mode, CH340 plus infrared transceiver can constitute a USB infrared adapter, realize SIR infrared communication.

  •  CH317  USB over CAT5/CAT6 Extender Device
CH317 control chip is USB2.0 extender for extended remote USB signal. The program is a two-chip solution, the CH317 plus third 1000BASE-T Gigabit Ethernet PHY and external auxiliary components constitute. Signal transmission path from the USB to Gigabit Ethernet via Category 5 cable (CAT6 better performance), from Gigabit Ethernet switch USB.
  •  CH315   USB Extender/Isolator
USB extension cable is CH315G control chip, real-time transit and transmission distance extension for USB signals.
CH315H is a USB signal isolation control chip for USB bus opto-isolators or magnetic isolators.
CH315 supports USB full-speed transmission and low-speed USB transfer, USB device support dynamic plug.

  •  CH345   USB MIDI Peripheral
CH345 is a USB-MIDI chip. CH345 supports a MIDI signal input channels and two output channels MIDI signals for MIDI keyboard making the USB bus, MIDI music playback, as well as the electronic musical instrument MIDI to USB interface.

  •  CH331   4MB Flash Drive Controller
CH331 is a small-capacity U disk controller chip, plus a serial memory chip as long as you can achieve a small U disk capacity of 2KB to 4MB.

  •  CH9331   16MB Flash Drive Controller
CH9331 is a small-capacity U disk controller chip, just need SPI interface plus a serial memory chip, it can achieve a capacity of a small U disk capacity of 512K to 16M.
  •  CH412  USB TVS Protection Devices
CH412 is a dual or quad ESD protection diode arrays, it can withstand up to ± 15KV Human Body Model to IEC 61000-4-2, ± 8KV contact discharge and ± 15KV air discharge ESD pulse for the external interface electronics High speed and differential signals and ESD protection common signals.
CH412B provides 2-channel low capacitance TVS diode protection and transient voltage suppressors clamp are suitable for high speed and low speed signal can be used for high-speed and full-speed and low-speed USB signal protection.
CH412A 2-channel low capacitance diode provides protection for high-speed and low-speed signals can be used for high-speed and full-speed and low-speed USB signal protection.
CH412Z provide 4-channel TVS TVS clamp are suitable for low-speed signals can be used for low-speed and full-speed USB signal protection.

  •  CH9350  PS/2 Keyboard and Mouse Extender
CH9350 is a USB keyboard and mouse to serial communication controller chip, to be used in pairs. Combining asynchronous serial interface simple and easy to use, implementation extends between the USB keyboard and mouse, and USB Host USB communication is asynchronous serial interface (UART) manner, and to facilitate audio and video signal data integration, can be used for communication distance KVM extension applications.

I2C LCD, LED, 7 Segment Driver, GPIO Expander / Keyboard Scanner Series

  •  CH463    16 x 8 Segment LCD Driver
CH463 is an LCD display driver chip. CH463 built-in clock oscillator circuit, 128 points (16 × 8), 48 points (12 × 4) LCD panels, but also can be 35 keys (based on 7 × 5 matrix) keyboard scanning; CH463 through a 2-wire serial line interface I2C with the microcontroller and other exchange data.
  •  CH462    32 x 4 Segment LCD Driver
CH462 is an LCD display driver chip. CH462 built-in clock oscillator circuit, 128 points (32 × 4) LCD panel.
  •  CH456   I2C 7 Segment LED driver / 64 key Scanner
CH456 is a 16-bit digital tube display driver and the keyboard scan control chip. CH456 built-in clock oscillator circuit can dynamically drive up to 16 digital or 128 LED light tube; also can be scanned keyboard of 64 keys; CH456 via two wires serial interface I2C to exchange data with the microcontroller.
  •  CH454  I2C 7 Segment LED driver / 64 key Scanner 
CH454 is a digital tube display driver and the keyboard scan control chip. CH454 built-in clock oscillator circuit can dynamically drive 8 16 digital segment tube or 128 LED, supports 11 segments, 14 segments, 16 segments × 8 and 17 segments × 7, etc; also can be keyboard scan 64 keys; CH454 and so on through 2-wire serial interface I2C to exchange data with the microcontroller.
  •  CH453  I2C 7 Segment LED driver / 64 key Scanner 
CH453 is a 16-bit digital tube display driver and the keyboard scan control chip.
CH453 has built-in clock oscillator circuit and can dynamically drive 16 or 128 digital tube LED light tube.
It can also scan a 64 key  keyboard.
CH453 exchanges data with the microcontroller via two wires serial I2C interface
  •  CH455  I2C 7 Segment LED Driver / Keypad Scanner
CH455 is a digital tube display driver and the keyboard scan control chip. CH455 built-in clock oscillator circuit can dynamically drive the 4-digit code or tube 32 LED; also can be scanned keyboard 28 with switches; etc. CH455 through SCL and SDA consisting of 2-wire serial interface to exchange data with the microcontroller.
  •  CH452   I2C LED Driver, BCD Decoder / Keyboard Scanner
CH452 is a digital tube display driver and the keyboard scan control chip.
CH452 has built-in clock oscillator circuit can dynamically drive 8-digit code tube or 64 LED, with a BCD decoder, flashing, shift, Dan addressing beam decoding and other functions;
It can also be used to scan keyboard of 64 keys;
CH452 It can be cascaded via 4-wire serial interface or 2-wire serial interface to exchange data with an equal SCM; microcontroller and can provide power-on reset signal.
  •  CH451  I2C LED Driver /  Keyboard Scanner
CH451 is an integrated digital tube display driver and the keyboard scan control, and multifunction peripheral chip μP monitored.
CH451 within the set RC oscillator circuit can dynamically drive 8 or 64 digital tube LED light tube, with BCD decoder, glitter, shift and other functions;
It can also scan a 64 key keyboard
CH451 through the string may be cascades and so on-line interface to exchange data with the microcontroller; and providing power-on reset and watchdog monitoring functions.
  •  CH450   I2C LED Driver/ Keyboard Scanner
CH450 is a digital tube display driver and the keyboard scan control chip.
CH450 uses a built-in clock oscillator circuit and can dynamically drive six-digit code or tube 48 LED;
It can also scan a 48 key keyboard
CH450 communicates via two wires I2C serial interface to exchange data with the microcontroller; and may provide single-chip power-on reset signal.
  •  CH423   I2C I/O Expander / LED Driver
CH423 is a universal remote two-wire serial interface I / O expansion chip. CH423 provides 8 bidirectional input and output pins 16 through output pin, supports input level change interrupt; CH423 built-current drive circuit can drive 24 static or dynamic LED light tube LED driver 128 (equivalent to 16 digital); CH423 via two wires serial interface to exchange data with the microcontroller.
  •  CH422   I2C  I/O Expander / LED Driver
CH422 chip can be used in digital tube display driver or the I / O expansion.
CH422 has  a built-in clock oscillator circuit can dynamically drive four -digit LED or 32 LED light tube;
CH422 is used for I / O expansion, can provide eight bidirectional input and output pins and four general-purpose output pins;
CH422 communicates through 2 wire serial I2C interfaces for data exchange with the microcontroller.

Multiple UARTS

CH438 is an eight UART chip, comprising eight compatible 16C550 or 16C750 asynchronous serial ports, supports up to 4Mbps communication baud rate, can be used for RS232 serial port expansion MCU / embedded systems, high-speed serial interface with automatic hardware speed control, RS485 communication Wait.
CH432 is a dual UART chip contains two 16C550 compatible asynchronous serial, half-duplex transceiver supports automatic switching and IrDA red outer codec that supports baud rates up to 4Mbps, used for RS232 serial port expansion Microcontroller / Embedded Systems high-speed serial interface with automatic hardware speed control, RS485 communication, IrDA communications.

Analogue Switches

  •  CH446   8 x 16  (or 5 x 24) analogue Crosspoint Switch
CH446Q is 8×16 matrix analog switch chip. CH446Q contains 128 analog switches, located in the signal path 8×16 matrix, each intersection, each analog switch can be individually turned on or off, in order to achieve any signal path routing 8×16.
CH440 4-channel two-way broadband low-resistance analog switch chip. CH440 contains 4 SPDT analog switches, high bandwidth, low on-resistance, or USB can be used for video signal switching a second election.CH440E CH440G less than 2-channel analog switch.
CH444 is a two-way broadband channel low-resistance analog switch chip. CH444 contains 2-channel single-pole four-throw analog switches, high bandwidth, low on-resistance, can be used for video signal 4 election or a USB switch.
CH441 4-channel two-way broadband low-resistance analog switch chip, the chip is pin-compatible 74HC4066, 4016, 74LV4066. CH441 contains 4-channel independent SPST analog switches, high bandwidth, low on-resistance, or USB can be used for video signal switching.

FIFO and Dual Port Memory

CH424 is a 4K-byte FIFO-capacity memory chips. CH424 W and having the end of the two ends of R 8 passive parallel port, the CH424 by eight data lines and read, write, chip select control lines attached to the microcontroller / DSP / MCU / MPU system bus controller, etc. for connecting the microcontroller and the microcontroller, MCU and DSP / MCU, etc.
  •  CH421  Dual Port RAM
CH421A provide a bidirectional data buffer interface chip. CH421A having X and Y are two 8-bit passive parallel port via a shared 66-byte dual-port data buffer, the bi-directional asynchronous data terminals X and Y between the end of the exchange. CH421A support operations both ends for connecting the microcontroller and the microcontroller, MCU and DSP / MCU, and the MCU and other Zhu Kongduan with active parallel interface, such as a computer or printer port CH365 local ports.

Finished Products and Modules

Evaluation Boards

The Best Things Come in Small Packages…….

What is true for wedding rings, is possibly also true for microcontroller hardware.

At least two microcontroller manufacturers have ARM M0 or ARM M0+  devices packaged in TSSOP 20 packages.  There is the STM32F0xxx series from ST Microelectronics, and the LPC82x series from NXP.

Freescale (now NXP) even had some M0+ parts in a 16 pin TSSOP – but the documentation is in such a mess – I failed even to find a pinout!

These are great little, low cost devices, with a clock speed of approaching 50MHz,  plenty of RAM and some even with native USB onchip 12 bit multichannel ADCs and multiple UART and SPI ports are also common.

This all adds up to a neat little package that could really knock spots off the now long-in-the-tooth Arduino.

For any microcontroller to become popular it has to first have the following in place – but sometimes it’s a bit like a Chicken and Egg situation.

1.  A usable package – preferably breadboard or stripboard friendly with 0.1″ pitch pinout
2.  A C compiler that is free to use – with rich featured – but not over complicated IDE
3.  A convenient means to program the device with minimum cost tool.
4.  Unique features that make it appeal rather than the competitor’s device
5.  Well documented code examples and peripheral libraries
6.  A strong User Community.
7.  Documentation you can actually find and use (NXP/Freescale #Fail)
8.  Easy to create code that is portable across various manufacturers’ families of mcu

Unfortunately the poor TSSOP 20 package fails to get off first base – even though it may be a strong contender for all the other options.

The TSSOP 20 is a small device –  yet because of a 0.65mm lead spacing it is a lot easier to solder than a QFN or LQFP package.

In order to remedy this situation, a low cost TSSOP adaptor is required – so as to convert the TSSOP pinout into a more breadboard friendly pinout.

Breakout Options.

As the Makersphere has generally grown accustomed to plug in packages in a 28 pin 0.3 DIL format  (i.e. ATmega328)  that could be one attractive option for the pinout.  It could be an instant upgrade to the Arduino – just by plugging a new module in.  With 28 pins  – there is a little scope for expansion – allowing packages up to about a LQFP/QFN 32 to be used. It also makes the module extremely attractive for breadboarding or using with stripboard.

If anyone wants a smaller package, the DIL 14, 16,18, 20 and 24 are all possibilities.  We could possibly use the neat trick used in the TI valueline Launchpad – where the DIL socket will cater for both 14 pin and 20 pin packages.

Here’s the classic Arduino Pinout – with common names – again in glorious monospaced courier font.

RESET      |            |  AN5/SCL
RXD        |            |  AN4/SDA
TXD        |            |  AN3
INT0       |            |  AN2

               INT1       |            |  AN1
               D4         |            |  AN0
               VCC        |            |  GND

GND        |            |  AREF
XTAL1      |            |  AVCC
XTAL2      |            |  SCK
D5         |            |  MISO
D6         |            |  MOSI

                                    D7         |            |  SS
                                    D8         |            |  D9
So creating a breakout board is just a case of looking at the pinout of the proposed target microcontroller – and making sure that the functions (SPI, UART RX, TX etc) tie up with those on the above pinout diagram.
Two processor families  are under consideration – mainly because they meet or exceed the Arduino’s capacity of RAM and Flash memory.  They are the STM32F03x, 04x and 07x  – which all share a common pinout and the NXP LPC08x series.
First  the STM32F0XX:
This needs a bit of detective work – because STM use simple names fro their GPIO pins that do not reveal the underlying function.  For this we need to further consult the datasheet.
STM32F Pin  Function        28 DIL (Arduino)
1            INT0              4
2            OSCIN             9
3            OSCOUT           10
4            /RESET            1
5            VDDA             20
6            AN0              23
7            AN1              24
8            AN2/TX2          25
9            AN3/RX2          26
10           SS               16
11           SPI1_SCK         19
12           SPI1_MISO        18
13           SPI1_MOSI        17
14           INT1              5
15           VSS               8,22
16           VDD               7
17           TX1               3
18           RX1               2
19           SCL              28
20           SDA              27
Note the 2nd USART is available on pins module 25,26
The STM32F0xx limited pin-out cannot support Arduino Digital pins D4,D5,D6,D7,D8,D9
Now the LPC82X.
This has the advantage that it has a highly flexible switch matrix which can assign the USART, SPI, SCT and I2C functions to any pin that is not power or ground.
LPC82X Pin  Function        28 DIL (Arduino
5            /RESET           1
13            OSCOUT          10
14            OSCIN            9
15            VDD             7
16            VSS             8,22
17            VREFN           22
18            VREFP           20
 VDDA            20

0 0

Reducing Cost.

One of our existing products at work, which I designed about 2 years ago, makes use of the STM32F373 microcontroller interfaced to an AD7767 24-bit sigma-delta ADC, to create a smart sensor.

Whilst at the time of development, (Feb 2014) – this seemed to be an economical solution, our requirements have changed a little, in that we wish to add Bluetooth Low Energy Connectivity, LiPo battery support and the means to drive an OLED display.  These functions could be added in the form of an additional pcb (similar to the Arduino shield concept), and provision had been made to accommodate such a board with an expansion connector, but after reviewing all of the costs, it was decided that a new approach – and a new dedicated pcb design would be ultimately preferable.

At the same time as I was making design decisions, I was aware that cheaper parts had become available – and so the combination of the STM32 mcu and 24 bit ADC, which had been costing around $15 in 1000 off, was starting to look a bit expensive.

Fortunately, I came across the range of MSP430i2xxx  16-bit microcontrollers, which come with 2, 3 or 4 individual 24 bit differential input SD ADC converters with programmable gain amplifiers (PGAs).  These are intended for energy metering applications – and this volume application is reflected in their low cost – about $1.98 in 1000 off from Mouser. Here was a way of stripping out a whole lot of cost from the smart sensor concept – and returning additional functionality, with up to 4 sensor channels.

MSP430i2041 and 128Kbyte SPI SRAM  Breadboard Prototype
After an initial review of the various MSP430 devices it was decided to opt for a generic smart analogue sensor design, capable of driving an OLED display.
I selected to use the MSP430i2041 (which was chosen for it’s 4 x SD24 ADCs) in order to make precision analogue sensor measurements.  It uses a low noise differential input instrumentation amplifier based on the LMP2022 from TI which is described as being “EMI Hardened”.
It can be used for tens of microvolt or millivolt range measurements – typically from bridge sensors, current shunts, milliohm measurements, strain-gauges, PT100 and thermocouple temperature measurements etc, etc.
The product is on a small board – just 42 x 53mm (1.65″ x 2.1″), and has a forwards facing OLED display and 4 button user interface.

MSP430i2041 Bluetooth Smart Sensor Board
As stated last month I am using the MSP430i2041 and 128K byte 23LC1024  SPI serial SRAM.  I am using my SIMPLex Forthlike language which now executes code out of external serial memory, or an be used to respond to serial commands (requests for ADC reading data etc) over a serial link.
As this has been designed as an evaluation, all of the MSP430i2041 mcu pins are available on 2 x 16 pin header strips – allowing it to be plugged into a breadboard, stripboard, or connected to a MSP430 Launchpad with jumper wires, using just Rx, Tx, 3V3 and 0V.  The Launchpad ‘4133 or  ‘6989 are preferred as they provide a 6 digit LCD “meter” like display.
USB to serial communications is handled using a CH340G USB-serial IC.

There is an on board LiPo charger and boost regulator  – allowing the board to run from a LiPo  or  – as little as a 1V dc supply. The super capacitor and LiPo battery are used to back-up the non-volatile memory allowing this to act as a battery powered datalogger..

A Bluetooth Low Energy module (yet to be fitted in top -left corner – in above photo) allows data to be sent to smart phone or tablet.  The mounting holes are pitched to allow direct mounting of an OLED display on the front face of the pcb, plus buttons – to form a simple graphical user interface.
If the module is successful, I hope to be able to open source at least some of the design, for those who are interested.

Shopping for Tech in Shenzhen.

About 5 weeks ago  – in the first part of this post, I looked at some low cost electronics modules and LED displays which could be incorporated into novel retro-computer style designs. I continue this search for retro-tech, looking at some of the pcbs and devices that are widely available at very low cost, virtually off the shelf from the Shenzhen Electronics Markets. Crucially, most of these devices already have code libraries and drivers available for Arduino and Rasp-Pi – so it really is a case of plug and play!

Shenzhen is famous for its electronics markets, and if you can’t get there in person, what better than a Personal Shopper, who can source your purchases for you?

Well, the package from Toby Yu, at Man Friday (Shenzhen) arrived on Friday, and I can share with you some images of the latest shopping haul, and some of the proposed applications.

Firstly the modules:

A small selection of low cost modules

Above we have a selection of the modules.

Top row – left to right

1.  microSD card socket with 5V to 3V3 buffer IC – to allow use on 5v systems – such as Arduino.  Cost $0.65

2. CH376 USB memory stick host. Allows read write of memory sticks, via parallel interface, SPI or UART serial interface.  A tutorial, source code and video of this device is can be found on the Arduino BasicsBlog. Cost  $1.80.

3. Hex Keypad  – a simple 4 x 4 matrix.  Cost $1.20

4. LED&KEY  – 8,  7 segment digit display, 8 individual LEDs and 8 switches. Uses the TM1638 driver/keyscanner IC. An  Arduino library for the TM1638 is available from RJ Batista . Tested and fully working with this particular hardware.  Cost  $2.00.

5  PL2303HX USB to UART adaptor.  This uses the newer HX version of the PL2302. (Datasheet). This will generate any baud rate between 75 baud and 12Mbaud – but unlikelt that the host PC will allow more than 3Mbaud.  Has a jumper link for 5V or 3V3 operation, but only Rx, Tx, V+ and 0V made available to target.  It would benefit from more of the handshaking lines being broken out to header pins.  Cost $3.00.

And now some of the LED displays:

A Selection of Low Cost LED Modules

Above, and pictured together so that you can see the relative sizes are a selection of the LED modules I am currently sampling.

1.  0.56″ 4 Digit, RED, common anode   Cost $0.60
2.   0.36″ 3 digit  RED, common anode   Cost $0.60
3.   10 segment bi-colour (red/green) bargraph   Cost $1.30
4    1.9mm  8 x 8 RED array.  20 x 20mm. Cost $0.40
5.    Holtek HT16K33 LED array driver/keyscanner breakout module   Cost $0.95
6.   3mm   8 x 8 bi-colour (red/green) LED array  38 x 38mm   Cost $0.60
7    16 x 16 RED LED array with rear mounted Holtek HT1632C driver IC. 76 x 76mm  Cost $5.85

These have been purchased to show a representative range of what can be sourced from China.  The prices quoted are those that you would pay when individually bought directly from a Vendor’s stall at  the Shenzhen Electronics Market. Shipping to the West would be extra and dependent on service, volume, weight etc.

One of the interesting modules is the HT16K33 breakout board.  This is a Chinese produced copy of the Adafruit board but $5.00 cheaper! It can drive two 8×8 LED matrices, 16 x 7 segment displays or a bicolour (red-green) 8 x 8 matrix. The datasheet for the HT16K33 is available and also an Arduino and Raspberry Pi Library may be downloaded from here.

The large 16 x 16 matrix is the sort that is built into large display screens.  The rear of the board arrows easy connection to neighbouring display tiles, and connection of 5V power.

With four of these tiles you could recreate the Manchester SSEM – “Baby” – and drive it with an Arduino or Raspberry Pi.  The brightness of the displayed pixels may be modulated – a row at a time using the dimming function.  See the HT1632C (datasheet) for the full versatility of this device.  A comprehensive Library to drive up to four HT1632C devices from an Arduino is available.  The $0.48 low cost HT32C also can serve as a keymatrix scanner device.

Finally, I had been looking for a compact keyboard to use with my 7″ tablet.  I found the following Bluetooth keyboard through my Shenzhen market contacts.

The keyboard is 200 x 125 x 6mm (7.9″ x 5″ x 0.25″) – and is a perfect size for my $50 Amazon Kindle. It can be used with Android, IOS and Windows machines. The cost was $10.80.

All of the above devices are available from Man Friday (Shenzhen).  My contact there, Toby Yu will assist in purchasing other locally available items.

0 0

Just over a week ago, I met up with my colleagues from the Open Hardware User Group (OSHUG) to hear about developments in open core architectures and FPGAs.

OSHUG are now in their 6th year, and meet up monthly in Central London, for discussion and socialising.  I have known them since meeting #5 – but it was interest that I found this video of Professor David May, speaking at the very first OSHUG meeting #1 back in 2010 (44 minutes).

David May worked on the transputer project back in the mid 1980s, and more recently became the founder of XMOS – a fabless semicoductor company based in Bristol. XMOS make a multicore processor – that has specific hardware to support multi thread, concurrent processing.

The XMOS architecture is formally described in this pdf, or as a shortform in this slide presentation – by Professor David May.

Prompted by my OSHUG colleague, Alan Wood, this week, I have been taking a closer look at the XMOS devices, commencing with buying a  $16 startKIT, a 94 x 50 mm dev board, designed to highlight some of the unique features of this interesting multi-thread microcontroller architecture.

Before I dive fully into the XMOS, I would like to suggest that we are living at a time of great innovation in terms of processor architectures, and whilst sometimes it appears that the world is powered increasingly by ARMs, there is certainly a renaissance for new ideas in computing architectures.

A few weeks ago I looked briefly at the Parallax Propeller, again a novel machine, and as I bring myself up to speed with the XMOS, I can see distinct similarities between the devices.  The dev boards for these devices are low cost and widely available – so why not try something a bit different?

Both Parallax and XMOS are fairly small companies, and this might be part of the reason why they have taken innovative approaches, that might often be overlooked by the larger semiconductor manufacturers, or seen to be so far off the beaten track, that might be perceived as too much of a financial risk to the larger vendors. When you are dragged along by the momentum of the herd, there is little opportunity to innovate!


First let’s look at some similarities between the XMOS and Parallax devices.  They are both advertised as multicore microcontrollers, though this terminology  may be a little misleading, as the XMOS device does not have true, separate stand-alone cores inside.   Instead, it has an execution unit, that has access to separate banks of registers, whilst the Propeller, has multiple execution units (cogs), which have access to shared memory resources.  Unless I am mistaken (and I might be, should any one wish to put me right), they appear to be two different approaches to achieve roughly the same outcome – multicore processing with virtually no latency between tasks.

The XMOS device reminds me of the Z80 architecture that had an alternate set of registers A’ F’ B’ C’ D’ E’ and H’ L’ .  Both the main registers and the alternate set were connected to the internal bus via a multiplexer, which allowed fast switching between the banks using the EXX instruction. In common use, the main registers were used for the main program, until an interrupt occurred, at which point the alternate set could be switched in to be used throughout the Interrupt Service Routine – an unrelated task.  The meant that the latency involved in stacking and unstacking registers could be avoided – and a faster interrupt response time achieved.

XMOS appear  to take this bank swapping concept a whole stage further,  and each “core” is effectively a rapidly swap-able bank of registers – consisting of 12 general purpose registers, stack pointer, data pointer, PC etc.

The banks of registers can be selected in an instant by a multiplexer structure, and this is done in a round robin fashion.  I get the image of the execution unit, parking one set of registers and picking up the next to continue with a new task, rather like a turret machine tool automatically changes it’s cutting bits.

The Parallax Propeller device, on the other hand,  has multiple execution units with their own local set of extended registers, which have round-robin access to shared memory resources.

The difference between the two architectures may initially appear subtle, but I suspect they have their distinctive pros + cons, and part of the process of exploring new architectures is to investigate these differences – seeking out advantages in them both.

A later post will look at the all important interconnect between Xcores  (xCONNECT) plus some applications.

However, as this is a bank-holiday weekend in the UK and Memorial Day in the US, I shall park this entry for the moment, allowing the interested to find time for their own reading.

Might I suggest this excellent tutorial – which introduces the architecture and looks at some coding examples.

Finally, a brief reminder – The Silicon Valley Forth Interest Group meet on Saturday 28th May. This month it is a workshop in creating an 8080 core on a Lattice FPGA and running eForth on it. Details here.

An occasional, autobiographical series that looks at milestones of my 30+ year career. This week – early beginnings.

Was it Really 40 Years Ago?

Next year, May 25th marks the 40th Anniversary of the US release of Star Wars, and I have to confess, I haven’t seen it. I should qualify this, by saying I have never watched the original movie  – either in a cinema, on TV or from tape/DVD in a single sitting. I struggled to watch the Blues Brothers from end to end – possibly due to the effects of alcohol rather than lack of attention span.

Frankly, as a precocious 12 year old, I had no interest, I dismissed it, somewhat superficially as a kids’ film – possibly having already seen “Jaws” the year before – smuggled into the cinema, by my elder sister, who herself was not yet 18 at that time.

By 12 or 13, I had digested just about every horror novel by James Herbert, Stephen King and read “Jaws” by Peter Benchley when the book first headlined in the UK sometime around 1975. I still remember the graphic description of a starving rat burying itself into the femoral artery of a tramp, in the opening pages of Herbert’s “Rats” – would you let a 12 year old read that now?

So my mixed up, young teenage brain continued to thrive on a diet of adult pulp fiction, model aeroplane dope, ether vapour and amyl nitrate from mixing glow-fuel and lead fumes – from soldering electronics kits and casting my own fishing weights, from old lead piping, melted in a bean-tin over a primus stove.

I was eventually weaned of this unhealthy diet sometime around the early summer of 1978, when the first 8 bit microcomputers arrived on the Isle of Man. Our school had acquired a Research Machines 380Z  – a Z80 CP/M machine, and the Commodore PET and Tandy TRS-80 were just starting to appear in the shops.

I tinkered with the 380Z, playing Lunar Lander, Space Invaders and other games on the 80 character monochrome screen, and I was perhaps 14 when my school friend Neil suggested that learning Z80 machine code was the way ahead. Neil knew how to edit the binary hex-file of Space Invaders, and adjust certain bytes to speed up or slow down play, or to tip the balance of the game by changing the number of bases, lives or the frequency of the rocket ship bombers.

Perhaps I should have taken his advice, but he was already being beaten up regularly for being an uber- nerd, and so it was some years later, possibly 1981, with the arrival of the much cheaper ZX81, when I finally started to chant Z80 mnemonic incantations. I was still messing with the Z80 a decade later building my own controller pcbs, with ROM, RAM maxxed out, PIO, SIO, CTC and 8255 PIA – all big 28 and 40 pin DIL packages – shoe-horrned onto a 4 x 3″ pcb.  A late developer, I guess.

Computers and their components were still expensive at that time. My ZX81 kit cost me a week’s wages.  A 6264 8Kx8 RAM chip was about £5 – which was my week’s allowance when I was 17 year old.  Why buy the RAM when you could buy 2 gallons of petrol and 4 pints of beer (Friday night priorities at that time) and still have change of a Fiver?

In my lower 6th Year, as a Prefect, I started a computing club at school, held on a Friday afternoon after school hours. My role was perhaps more that of a baby-sitter as most attendees were first or second year pupils (11-13) – who had received £99 ZX81 machines for Christmas or birthdays. On a good day we had about a dozen kids, playing 3D Monster Maze around 5 or 6 machines, with the unmistakable noise of the ZX81 cassette tape interface squealing in the background. The School also had a new BBC Micro – as part of a “Computing in Schools” grant, and I believe there was also an Acorn Electron, bought for the Remedial Department. Such was the state of play when I left Ramsey Grammar School, in the June of 1983.

Around the same time, 1982, a gentleman, recently retired to the Isle of Man and in his 70’s, who had worked for Sperry-Univac in the US, presented himself to our school, and offered to coach in maths and computing. He lent me text books on complex maths – that I still don’t understand, and lectured some of the keener pupils on aeronautical engineering and applied maths. Mr Meacock, was truly an engineer of the spacerace and slide-rule generation. I regret not asking him more questions – when I had the opportunity.

He introduced me to another middle-aged engineer, John, who had built his own 8 bit machine, which ran a weird homebrew language he called Burp. My memories of this are clearly fairly vague, but the Wikipedia entry describes this as a  PSI Comp 80 machine – a Z80 platform built from a kit, – and BURP is an acronym for Basic Using Reverse Polish. This machine is covered in Wireless World beginning in April 1979, page 44. A full pdf is available here.

The Powertran PSI Comp 80 – From Wireless World Magazine Sept 1979

I started a vacation job, at a small electronics company in the south of the Island.  It was a 27 mile commute – to what was really the only electronics company at that time. Each morning I left the house at 7am, drove virtually the whole length of the Island – and clocked in at Lymonyx for 8am.

My salary was £40 a week (£1 per hour) and my fuel bill was at least £18.

My peers thought I was mad – why drive daily to the other end of the Island for just £12 a week, when you could get that on the dole, whilst sleeping till noon, and clubbing till 2am?

However, that summer I learnt a lot about 8-bit computers – probably most of what I know now, I learned to write Z80 machine code using a pencil and paper – and could just about recite Z80 hex op-codes in my sleep.

The project I was helping to develop was an automatic microfilm reader (WTF!), to be used in libraries and record offices.  The Z80 would count the frames of 35mm microfilm, and run the film transport mechanism.  That first summer, because I returned for more punishment the following summer, we got the basic system to work using an Intel SDK -85.

Intel SDK-85 What more could you want?

The Intel SDK-85 was probably the most expensive way of buying a microcontroller at that time. It was a fairly typical late 1970s microcontroller development system. The Intel MCS-85 system allowed you to build a complete microcomputer in just 3 ICs, or 4 if you wanted a hex keypad and 7 segment display.

It used the 8085, which was an 8080 compatible device which used a single phase clock and didn’t need -5V and 12V supplies.  It also used a rather infuriating multiplexed address/data bus, which was a feature of several of the Intel microcontroller offerings at that time.

The SDK-85 had an 8085 and some MCS-85 support ICs – including 8255 PIA, an 8155 with 256 bytes of RAM, a 2K 8755 ROM and 8279 keyboard scanner/display driver.

The 8085 – like an 8080 – but much better – with on-chip serial inteface

The family members of the MCS-85 series could be stuck together on a board like LEGO blocks with almost no additional components – with each device having an internal address latch. The muxed bus meant that only 16 lines needed to be bussed to each IC, rather that 24, which saved on pin-count, packaging and pcb wiring.

Compared to the 8080 system that needed 3 supply rails, dual phase clock and a whole bunch of address decoding logic, this was bliss. It was probably here that I acquired a lasting appreciation for simple devices packaged in 40 pin DILs.

It had a hex keypad, 6 digit, 7-segment LED display and a huge prototyping area. It implemented a 20mA current loop to drive a serial teletype (like we had one there – not!) and this presumably provided keyboard entry and saving of files to paper tape. There was no optional cassette interface – which could have saved me hours. It was built from a kit on a board about 12″ (305mm) square. It was the first “caseless” board I had used, and to me it was a rocket ship, and all I knew that 18th Summer.

Code had to be hand assembled using pencil and paper and typed into the SDK-85 using the on-board 1K Hexadecimal Monitor. The system had been expanded with a second 8155 PIA which added another 256 bytes of RAM.

The ROM was a 2K 8755, a 40 pin DIL device which also has some 8 bit I/O ports on chip, but we lacked the eprom programmer needed to blow this device – so code was never held permanently. Every day I typed in what I had assembled so far – and hoped that I would make some progress before it crashed.

So I was presented with this SDK-85 and told to go away and learn how to use it.  John, with the BURP machine probably independently taught me the basics of using the hex monitor to modify code, produce hex dumps and execute small routines – and needless to say, I was mostly clueless and progress was slow.

Looking back at the Summer of ’83, this was my first introduction to 8-bit assembly language programming, by hand, without an assembler, disassembler, cassette interface or any of the nice things that would have actually allowed me to get the job done!

In hindsight…. the SDK-85 was quaint but already antiquated, even though the 8085 made an excellent controller with it’s on chip serial interface – but who had an ASR-33 teletype sitting around anyway, and who wanted to deal with the weirdness of the Intel proprietary eeprom packages?

I had already built up my ZX81 from a kit earlier that summer – so I should have known that it was easy to wire a conventional RAM or ROM onto the 8 bit bus.  Perhaps it was me being very young, inexperienced, having the SDK-85 thrust upon me by the MD (an expensive bit of kit at the time) and that dammed multiplexed address bus – that prevented me from just wiring some sensible memory devices up in the prototyping area of the SDK-85. So the learning curve was slow, brutally unforgiving and taught me, if nothing else, that a muxed bus sucks!

In the next part, a minor revolution, in which the 8085 is deposed and the Z80A vote as the new top dog.

0 0

Following on in my occasional autobiographical series – I am 19 years old, studying electronic engineering at Bangor University – and discovering the joys of the Z80 microcontroller – and girls.

Please note – The archive photos used in this blog are representative of the period – the mid-1980s – but not necessarily, strictly chronologically correct. Dates are omitted where there would be a discrepancy.

Gawky, Geeky, Underfed – on a hill in Clackmannanshire

Compared to my first year at Bangor University – where I had 26 hour long commitments per week, the second year (1984/85)was positively slack, which was handy, because I had a new girlfriend.

The lecture and lab session timetable made it possible every 2 weeks to bunk off on a Wednesday lunchtime, and reappear the following Monday morning, and not miss anything useful. This made for some interesting travel opportunities.

I made one such trip, up to Edinburgh in February 1985,  part nostalgia, and part visiting friends and relatives. My first cousin Shirley lived in a grand house in Barnton, with her then first husband – a radio communications entrepreneur. So, a scruffy underfed, gangly student descended on them for a long weekend.

With my Cousin’s dog “Clyde” – Arthur’s Seat, Edinburgh

For old time’s sake, I revisited Brown’s Wireless. This was an electronic component stockist located on George IV Bridge – conveniently on my route back to the bus station when I was a schoolboy in Edinburgh in the early 1970’s. I used to spend hours and my pocket money in that shop, buying transistors, resistors and other small components for circuits – that I read about in Everyday Electronics – but seldom got to work.

Sadly – on my last trip to Edinburgh – May 2015, Brown’s Wireless is no longer there.

Peering through the large display window, that cold wet February afternoon,  a window once filed with sun-faded  Babani Books, my attention was caught by something new. It was a Multitech Microprofessor MPF-1b – a Z80A training system. This was now 1985, and the UK home computer industry had well and truly crashed – and here was a Z80A system knocked down to half price.- just £69.95 if I recall.

It was an impulse purchase, not only was it the MPF-1 – but it came with extra Tiny BASIC and an expansion board.  Now I was living in a cellar in Bangor and paying £6 a week rent at the time, and a pint of beer was 60p in the Union Bar – so virtually £70 was a major financial commitment – but hey, I was 19, and I had to have it.

The MPF-1B from Multitech Corporation – from 1981

The MicroProfessor MPF-1b was originally produced by the Taiwanese electronics company Multitech. Some years later, Multitech became the PC Clone manufacturer Acer.  The rights to the MPF-1b were bought up by Flite Electronics of Southampton – and by a rare miracle, you can still but an MPF-1b, 35 years after it’s original introduction date – for a mere £225! I guess that speaks volumes about the longevity and appeal of the Z80 architecture – even if it is for educational purposes.

The MPF-1b was an open board with 6 digit 7 segment LED display for an “address-data” display, 36 key keypad, ROM, RAM, PIO, speaker and cassette interface and came with 3 comprehensive manuals – full of assembly language programming examples and guidance notes on how the hardware and the Z80 peripheral devices worked.

This was not a home computer but squarely aimed at the hobbyist/enthusiast and the purpose of teaching Z80 assembly language. It came with a 2K monitor ROM, and a 4K Tiny BASIC ROM. A keyboard overlay allowed you to enter BASIC programs using a tokenised format – similar to ZX81, but not so easy with just a 6 digit 7-seg display!  I stuck to assembler – it was easier!

It was housed in a plastic case – a bit like an oversize VHS cassette case which opened like a book – with space for an expansion board or manuals in the other case half. The greatest appeal was that the hardware was all fully accessible and there in front of you. It used through hole components, almost fully socketed and the Z80A bus and all PIO expansion connectors were on 0.1″ connectors.
The manuals included full circuit diagrams and a ROM listing of the 2K monitor.

I am delighted to see that the MPF-1 User Manual is available on line – it is well worth a read – to see just how clear and concise it was. The main routines of the monitor ROM were fully explained, so very quickly you could call them – and use them to your advantage – for reading keys, displaying numbers and creating tones.

Fortunately there are other MPF-1 enthusiasts out there – so by the magic of the internet (and 35 years progress) the ROM listing and other MPF-1B documentation is fully available online both as a PDF and as a dump here.

MPF-1 User Manual
Experiments Manual Software & Hardware
ROM Listing& 2K ROM Dump

Mine also came with Tiny BASIC user guide

For the first time there were assembly language example of only a few tens of bytes, that you could type into the system in hex, and have an immediate response from the hardware.  You could single step, and set breakpoints, and examine each memory address you chose. This was an ingenious use of the 7-segment display and extended hex keypad – and something that few have recreated since.

As a newcomer to any microcontroller – this gave you immediate control over the mcu, in an incredibly hands-on manner.  One of the first examples I coded in when I got it back to my Cousin’s was for a telephone ring tone generator (Experiment 16 of Experiment Manual) – a couple of timing loops that output a modulated tone from a port pin to the small loudspeaker, producing a very realistic American style telephone ring.

For the first time I felt that the Z80A was open for business – and I was hooked.

Moving On

The appeal of the MPF-1B was it’s open architecture and ease of use. There was very little about the design that a 2nd year electronics undergraduate couldn’t understand – or copy. I have put the schematics at the end of this post 🙂

This was in stark contrast to the architecture of some of the popular home computers of that era – where custom ICs and ULAs were starting to mop up a lot of the glue logic – particularly around the video generation hardware, to the point where some of it was impenetrable. For example, I might just about be able to copy a ZX80 and recreate it from 74xx00 logic re-engineered into a FPGA, but little chance with the ZX81 with it’s custom Ferranti ULA. Others have succeeded with the reverse engineering of the ZX Spectrum – more of this in a later post.

The MPF-1B was also a little anachronistic – it that it really belonged in the mid-1970s rather than the mid-1980s – but it served it’s purpose and did it well.

By the end of the 2nd year, summer of 1985, I had a vacation job in Caernarvon, writing BASIC programs for a new eletrophoresis scanning instrument – produced by a start-up company ADC Systems.  Electrophoresis is the process by which a small electric field is applied across an agar gel medium, and is used to separate molecules of proteins into graduated bands.  The density of these bands, and thereby the protein type and concentration, can be scanned optically and thereby measured.

The scanner was a simple linear drive – a bit like the print head drive of say a dot-matrix printer that was used to move the sample across the optical scanning head.  The scan was performed with different wavelengths of light – to highlight the coloured dyes used in the electrophoresis sample – and these were selected by a filter wheel on the end of a stepper motor shaft.

I wrote BASIC on the chunky Tatung Einstein machine – a Z80A machine that had twin 3″ floppy drives and ran CP/M.  The results of the scan were plotted on the screen and measurements  – using movable cursors could be made. I was not really a very good software engineer – and took regular bollocking sessions from my somewhat tempermental boss. He was/is a brilliant man – but a short fuse and little patience for students. Out of respect I will not name him here.

The CasioTone CT1000P – polyphonic keyboard from around 1981

My interests lay with electronic music and MIDI control of synthesisers. I had a full size keyboard – a CasioTone CT 1000P and I wanted to make a MIDI sequencer for it.  Using the BFI approach – Brute Force and Ignorance, I chose to make up a bank of analogue switches that could be wired in parallel with the keyswitches thus shorting them and mimicing keypresses, driven by multiple parallel ports. This allowed multi-note polyphony, and could be retro-fitted into the CT100P case with minimum disruption to the existing electronics – also driven from a custom Z80 IC.

The Casio had a 5 octave keyboard (60 keys) – so it seemed logical, but not necessarily economical) to create a Z80 board with sufficient port lines to allow one port per key.  The favourite IC at that time for I/O ports was the Intel 8255 – which had 3 x 8 bit ports.

If I recall correctly, the keyscanning matrix was 12 x 5, which makes sense for a 5 octave arrangement.

So I wired up a large stripboard with multiple 4066 quad analogue switches and created a keyboard mangler.  Then I turned my attention to a suitable controller for this – and the choice was obvious – base it on the circuitry of the MPF-1B.   The MPF-1B main board was physically too big to include in the keyboard case – so I chose to recreate the important parts on a piece of Veroboard (the tradename for a UK stripboard).

The 8255 had been used on the MPF-1B as the display and keyscanner – so I already knew how to drive that. I also wanted to retain a Z80 PIO and CTC from the MPF-1B , so the board design ended up with both an 8255 (3 ports) a Z80 PIO (2 ports) and a CTC.

The final design include:

Z80A  – 40 Pin DIL
32K RAM (62256) 28 pin DIL
32K ROM (27256) 28 pin DIL
Z80A CTC 28 pin DIL
Z80A PIO 40 Pin DIL
8255 PIA  40 Pin DIL
74LS139  – memory and I/O chip selects  16 pin DIL
74LS04  Hex Inverter  – clock oscillator/buffer
74LS74  Reset pulse generator
4053  8 channel analogue multiplexer
2 additional devices – as yet un-remembered

The board was created on a 4.8″ x 4″ piece of veroboard, using verowire (self fluxing insulated wire) painstakingly wired during the middle of July 1985 – Saturday July 13th to be precise.  I remember the time vividly, it was incredibly hot – as I rented an uninsulated attic room, and I watched LiveAID perform on a 9″ black and white portable TV – as I sat all day and wired up the back of the board.

My Z80A controller board – from July 1985 101x122mm
Underside of board – showing verowire and verocombs. White Bus Expansion socket 

The board was constructed so as to be initially an appendage of the MPF-1B. The Z80A bus was extended down from the underside of the pcb using a 40 pin DIL turned pin header. This was a trick that I had learned when I built up my ZX81 from a kit – a couple of years earlier, by fitting a wirewrap socket – with long pins into the processor location. The whole Z80 bus is extended downwards – to a lower board – or master/target system.

There were 2 memory devices – a ROM of up to 32K located at address 0x0000 and a RAM  – also of up to 32K located at address 0x8000.  The PIO, PIA and CTC (counter timer) were chip-selected using /IORQ and one half of a 74LS139 – dual 2 to 4 line decoder, whilst the memory devices were selected using /MREQ and the other half.   A 74LS04 hex inverter formed a crystal oscillator clock circuit with a 4MHz clock.

There is now doubt that some or all of the MPF-1B ROM was utilised to get this board to run code. I used a non-volatile RAM module to develop code – and possibly an assembler on the ZX81 or Tatung Einstein. I know that I hadn’t got the best development tool chain – but all these things cost money, and we were still a decade away from having internet and widely distributed software.

This board was actively used for a couple of years and formed the prototype of a DIY pcb – that will be the subject of the next part of this autobiographical series.

Looking back – I am fairly certain that it spent more time plugged into the MPF-1B cpu socket than actually playing notes on the CasioTone!


The MPF-1B was a simple, innovative product in it’s day – cost engineered, but well documented, It has probably done more for Z80 microprocessor teaching than any home-computer or games machine.  It represented a truly open-architecture, that provide the student a unique insight into how to put together microprocessor hardware.

There is sufficient information available onnline to allow anyone to create a similar product. All of the DIL package ICs are still available – although at much greater speed grade – from the likes of Farnell, Mouser and Digikey. The LED displays and keypad buttons are available cheaply now from China – see my post of April 16th and May 22nd.

A competent, practical student would get great satisfaction from recreating this design and getting it to work – and I suspect it may already have been copied. The techniques highlighted by this product are as valid today as they were in 1976 or 1981 and are applicable to all microcontrollers – not just the venerable Z80. Perhaps it could be updated for the Atmel AVR, the ARM, or as an experimenter’s board add-on for the Raspberry-Pi? With EagleCAD or KiCAD, it would not take long to get this reverse engineered, updated and out into the open source world. 50MHz EZ80 devices are available that would make this thing fly, plus include all the latest must-haves such as Bluetooth comms, microSD storage, colour touchscreen, and ESP8266 wireless connectivity.

There is life in the old dog yet!

The success of the MPF-1B is proven by the fact that it is still sold today – some 35 years after it’s inception. There is still a place for this kind of product, where youngsters can find their way, at their own pace, through the first steps of rigorous microcontroller understanding.

It’s not Arduino teaching C++, nor is it Raspberry Pi teaching Linux command line interaction, Minecraft or Scratch.  It was off-beat and anachronistic in 1984, all the more so in 2016 – but it’s educational value in conveying low level understanding of how microcontroller technology actually works – is immeasurable.

Long live the MPF-1B and all under-dog products like it!

In an upcoming post, I look at a compact Z80 embedded computer pcb I laid out in 1988, which was directly influenced by what I learned from the MPF-1, and a logical descendant of the Z80A stripboard controller described above.

Appendix – Circuit Schematics

A fairly typical processor and memory interface. Memory devices limited to 4K bytes by their 24 pin DIL sockets. A pair of 2 to 4 line 74LS139 decoders creates the memory addressing scheme from the A15, A14 address lines gated with /MREQ.

The MPF-1 used a 3.58MHz resonator divided down to 1.79MHz using a 74LS74 flip-flop. The other half of the flip-flop provided clean /RST and RST reset pulses. The RST was for the 8255 PIA whilst the Z80 PIO and CTC used /RST.

The 74LS90 is a decade counter which is used to count M1 cycles and generate a hardware breakpoint – using the interrupt line. More details in the User Manual.

The 7 segment display was also very typical of it’s day. Whilst some keyscanner/display drivers use an LSI driver chip, this shows the traditional way – using 75491 and 75492 segment drivers, to provide the current needed for the LEDS.

The half- 74LS139 decoder provides chip select lines for the 8255, the Z80 PIO and the Z80 CTC – decoding A6, A7 gated with /IORQ.

The cassette port interface is also standard – providing low pass filtering of the squarewave from the 8255 PIA.

The CTC and PIO were uncommitted – and fully available for User’s purposes.  Note the “daisy chain” interrupt scheme – standard on Z80 peripheral ICs.

Standard 2 x 20pin 0.1″ headers allowed expansion to the Z80A processor bus (P1) and the CTC and PIO signals (P2). The cpu bus connector followed the same order as the pins on the DIL 40 cpu – allowing the MPF-1 to be ribbon cable-jumpered into a target Z80 system.

The MPF1-Plus Avert from  Electronics and Computing Monthly, November 1983, p. 33

Multitech went onto create a range of similar value for money microprocessor products including the MPF 1-Plus, which had Qwerty style keypad, and also similar models for the 6502 – An Apple II workalike called MPF-III,  a reduced MPF-II, a stripped down version with no case called MPF- MKII, 6809and 8088 microprocessors.

A list of known Multitech MPF series products reproduced below

I encountered the 8088 version in my Final Year Project – but that is a tale for another time.

0 0

Sure, I like Martha and the Vandellas Motown version, but I was thinking of Bowie and Jagger’s 1985 remake – as being more my period.

My autobiographical journey of reminiscences of 1980’s technology continues into 1984 – as I have a second summer battling with microprocessors, late teenage angst and moving away from home.

So I went back to the small electronics company in the South of the Isle of Man for the summer of 1984, and also moved out of my parent’s home to live in run down digs in Douglas – the Island’s seething metropolis.  It cut my commute down form 54 miles a day to about 18. The money I saved in petrol, I spent on wine, women and song. I was barely 19, and looking back, I guess both my I and D terms were set to zero, and P cranked up to 11.

I had just returned from my first year at Bangor University, where the maths department’s attempts to teach me Fortran 77 had left me deeply traumatised and resentful. I stormed out of one lecture saying that they could stuff Fortran, ‘effing mainframes – and what took me a morning to code on a VAX 11/780 terminal, I could have done in my room on a ZX81 in half an hour. Mind you – it could have been worse, the year before I started at Bangor – the high level language of choice was Algol ’68.

ZX81’s were pretty much on their way out – but we were poor students, and £129 for a Sinclair Spectrum was about 2 weeks wages. I wrote my Physics “pracs” up on the ’81 and wrote a program to do least squares fit of graphed data.

My friend Hadyn also had an ’81, and with an FM bug attached to one machine’s “MIC” cassette interface output, and a FM radio connected to the “Ear” input of a second machine we effectively transferred a BASIC program a distance of about 30m across the courtyard of our hall of residence. A kind of protozoaan wireless comms.

Hadyn also managed to score an old ASR-33 Teletype from the Electronics Department, and we lugged it up the stairs to the 2nd floor where his study room was located.  Hadyn was (and is) a smart cookie –  and managed to hook it up to his ’81 using a 20mA serial loop. It provided hard copy for the ZX81 – albeit in capital letters only! But what a noise it made – he got noise complaints from the guy that lived below him. The ASR-33 went to Hadyn’s folks’ house at the end of the term, not to reappear.

Around the same time we shared a copy of David Husband’s ZX81 Forth ROM and went together on a London day trip shopping in the Edgeware Road. This was the surplus hardware Mecca for London, and I bought a redundant £40 Jupiter Ace, in a stock liquidation fire sale. The fledgling UK Microcomputer Boom, had crashed and was rapidly becoming bust.

So back on the Island for the summer of ’84, and some of the difficulties of the 8085 were resolved when we bought a Z80 SBC from one of the suppliers who advertised in the back pages of Electronics and Wireless World.  Looking back at the WW archives from that time – I think the board was an “Archer” by Sherwood Data Systems – but there were several similar Z80A boards to choose from.

It came with a monitor program, which got copied, and remained on my Z80 systems for several years afterwards. There were PIOs a CTC and a SIO as well as a full house of 32K ROM and 32K RAM. It wasn’t cheap – about £150 at that time – nearly a month’s wage.

Lymonyx had taken on another student – also my age, and also a ZX81 enthusiast, and between us we sorted out a non-volatile RAM module, and the means to store and edit code, and burn into 2764 Eproms. We had a Z80 disassembler running on the ’81, but we had to use an Apple II to run the eprom programmer.  Our edit-burn-test cycle was a good 20 minutes – as we had disabled the Vpp line in the Eprom programming card of the Apple II to program the NV-RAM, but it still took several minutes to burn an 8K part.

By the end of that Summer, I think that we had a non-volatile RAM actually wired into a ROM socket on a ZX81  – so the tortoise programmer  – the Apple II on the factory mezzanine floor was no longer needed.

I picked up a £50 speeding ticket, and got involved in a “drugs bust” incident – that really never happened, except that an associate ended up swallowing a large lump of cannabis resin, unnecessarily – and not seen for days.

A few weeks later – back in Bangor for the start of the 2nd Year, a sweet young lass called Jenny Higgins, restored my PID terms to something a bit more stable.

Not quite a full-house! – My DIY Z80A experimental board from July 1985.

Some while ago, I had the idea of making my own Z80 based control computer, to be used to sequence my electronic music keyboard. The plan was to build up a minimum Z80 system consisting of Z80, ROM, RAM and GPIO ports on a piece of Veroboard.

Well, that was back in the summer of 1985, and now as part of my “50 Crazy Things to do whilst I am 50” – a kind of Bucket List dry run, I have decided to revisit my old Z80 stuff, and bring my Z80 “Lazarus” back to life. The board has spent the last 15 years in a box in a damp shed – and there is evidence of corrosion and water presence.

Without access to an EPROM programmer, and using only online tools and hobbyist Open Source hardware, my weekend mission was to breathe new life into a 31 year old vintage Z80 project, built during my time at college.

Summer of ’85

In the Summer of ’85, “Back to the Future” was the big hit movie – released on July 3rd in the USA,  and ten days later, on Saturday July 13th, the world was going to be captivated by the LiveAID series of concerts, held simultaneously in London and Philadelphia.  For most people, the internet was still a good 10 years away.

I was not quite 20 years old, living in an attic bedsit in the University town of Bangor, North Wales, and working a summer vacation job, about 10 miles away in Caernarfon. I recall vividly those times, as I sat and watched liveAID on my 9″ portable monochrome TV, and spent that hot Saturday afternoon and evening meticulously wiring up the address, data and control signals of my Z80 system.

A quick search online will reveal that many people still have a soft spot for the Z80, and have built up minimum system boards on stripboard, pcb or breadboard, and documented them on their blogs. A friend, Spencer Owen, has built up a small Z80 system – originally for the 2014 “Retro Challenge”and is now selling this as a kit – the RC2014.

Now more than 40 years old, the Z80, and processors of that same era, have continuing appeal and are central to the emerging retro-computing scene.  In this series of posts, I will cover some of this challenge of recreating old hardware – starting with the resurrection of my DIY Z80 system – nicknamed Lazarus.

Part 2 Z80 Reloaded – The ROMulator

Part 3 Z80 Reloaded – Magic Bus


We have all become familiar with flash based microcontrollers, such as the ATmega328 used in Arduino, but perhaps those who grew up in the 1970s and 80s have our roots in microprocessors – such as the Z80 and the 6502 – as these were the two main devices that powered the early 1980s home computer revolution.

A modern flash microcontroller contains the processor core,  flash ROM, some static RAM and usually a whole host of peripherals inluding GPIO, ADC, SPI, I2C, UART  all in the one IC package.

If we go back 40 years to when the 8-bit ICs were introduced, all you got in the 40 pin IC was the CPU – and all of the other functions were additional ICs – and these all took up pcb real-estate. The 8 bit data bus and 16 bit address bus used about 75% of the available pins of the DIL 40 package.

A microprocessor needs to have other support ICs connected to it, in order to allow it to run. Traditionally, these would have included a ROM, SRAM and possibly some GPIO in the form of a PIO (parallel input/output) and SIO (serial input/output). A minimum Z80 system might consist of half a dozen ICs – most of them large 28 or 40 pin DIL packages.

A small system needed a 4″ x 4″ board  – just to provide the functions you might find in an Arduino mini. And it was a lot slower pace of life.  A 4MHz Z80A executed it’s quickest instructions in 1uS, compared to an ATmega328 – that’s a 1/16th of the speed – it’s Z80 tortoise against AVR hare!

However, we can take advantage of the Ardunino, and it’s vast wealth of Open Source online resources, to help breath life back into this old-timer.

The advantage of working with DIL IC packages was that they were easy to use on stripboard and breadboard, and they could be easily replaced or swapped  – if fitted into DIL sockets.  The usual way of storing a program, was to burn it into an EPROM, which could be swapped out for another – if you wanted to change the program function.

DIL packages were ubiquitous for small 8-bit microprocessors until the late 1980s, when they stared to change to plastic leadless chip carriers (PLCCs) as more and pins were required for 16 bit processor.

The 68000 was one of the first popular 16 bit processors for the home-computer and business market – introduced first in about 1984 in the Apple Macintosh – it became affordable a few years later for the home computers – including the Atari 1040ST and Commodore Amiga.  It came in a whopping 64 pin DIL – which was over 3.2″ (81.5mm) long.

So any minimum system needed CPU, ROM and RAM and the starting point was often a quick sketch showing the pin-out and the proposed wiring of the various bussed signals. The Z80, like many of it’s contemporary 8-bit processors used a 16-bit address bus, an 8-bit data bus, and about a dozen control signals.  Some or all of these signals had to be painstakingly wired up between the pins of the DIL packages. A Z80 plus ROM, RAM and a PIO represented around 200 soldered connections.

A simple sketch showed you what you needed to wire up
The system sketch is converted into a board – over a weekend of intense building and wiring

Once you had sketched out the system it was a case of transferring it across to stripboard or breadboard.  You would need multiple breadboards to hold a minimum system, and the results were generally not good for long-term stability as wires often came loose of the breadboard contacts – particularly during transportation. Coupled with the fact that breadboards were surprisingly expensive at that time – about a week’s pocket money for a small one that might just hold a 40 pin and a 28 pin IC package . Invariably the best approach was to wire it up on a suitable piece of stripboard – a process that would take a very long day, or perhaps over a weekend.

As can be seen from the sketch showing the IC pinouts, sometimes the signals came out of the ICs in an order that would allow them to be connected directly using the copper strips – in the case of the Z80, the lower address bus A0:A7 came out in the correct order to allow a direct connection to the 8k or 32K RAM placed to it’s right. That saved a bit of hand wiring. Sometimes the bit order was muddled – the data bus emerging from the Z80 on pins 7 – 15 was a good source of wiring errors.

In addition to the large LSI ICs, a few smaller TTL devices were needed to act as “glue logic” and other system functions. The most common were the clock generator and the address decoder.  My favourite choice for these was a 74LS14 hex schmitt inverter for the clock generator and a 74LS139 dual 2 – 4 line decoder for the memory and I/O chip-select decoding.

The great thing about this vintage hardware, is that you can readily reproduce it today, using hobbyist tehniques. Most of the Z80 and 6502 microprocessors are still available (Element 14/Farnel, Mouser, Digikey) – and the construction is relatively simple, based on stripboard – as illustrated below.  The biggest problem is getting the first machine code file loaded into the codespace – and that will be covered in parts 2 and 3 of this short series.

The layout sketch is translated onto a piece of stripboard.

How to get started?

Method 1.

Buy one of Spencer Owen’s excellent RC2014 homebrew Z80 computer kits and become part of that community following.

Method 2.

Beg, steal, borrow, scrounge or buy the components you need.  About £10 ($15) will get you the CPU, RAM and a PIA or PIO from Mouser, Newark or Digikey. The Z80 family are available in 6, 8, 10 and 20MHz speed ratings – but you will have to ensure that the RAM you buy has the correct access time for your system clock frequency. Be creative and come up with your own innovative design.

But Why?

What is the fascination of all this vintage computer stuff? The answer may be manifold – depending on who you speak to.

For my generation it’s the nostalgic recreation and resurrection of the kind of systems we had in our youth – possibly as a protest to the blandness of  contemporary devices.  The mass market hardware we enjoyed 30 years ago is not only still available, but affordable.  This would not be the case for someone who was 10 years older – of the PDP-8 or Altair generation. That hardware was relatively rare at the time, costly then – and priceless now.

For younger enthusiasts, it’s the opportunity to get inside a real computer system and tinker. This is often motivated by the desire to engage with or fascination with 1980’s arcade style games – which were within the capabilities of the early 8-bit home computers.

There are so many more opportunities these days with low cost hardware and free to use software tools and detailed information widely available on the internet. Compared to 30 years ago when we had very few affordable tools – and had to glean all our information from monthly computer magazines.

At the time I commenced my Z80 design, this type of construction had been going on for about 10 years – starting in the mid-1970’s with the launch of the 6502.  Launched at the Western Computer Conference “Wescon” – the 6502 was the hot selling new product – and at a fraction of the price of the Intel 8080.  Here was an affordable chip that started a revolution.  Steve Wozniak attended Wescon 75 and bought his first 6502 there – spending about a weeks wages!  It was this chip that he then went on to design into the Apple 1 computer.

The WESCON ’75 Advert – that started a revolution.

The home computer revolution really started in the UK about 5 years later around 1980 – 81.  Clive Sinclar had introduced his minimalist ZX80 in 1980, though he had produced an earlier product called the MK14.  The ZX80 design reduced the cost of the computer to an affordable £100, and showed how Z80, ROM , RAM and video generation hardware could be shoe-horned into a couple of dozen ICs.  This was followed up the following year by the ZX81 that managed to reduce most of the glue logic into a single 40 pin ULA – or uncommitted logic array, reducing the design to just 4 LSI ICs a TV modulator and a 5V voltage regulator.

I had built up a ZX81 from a kit in the Spring of 1983 – when they were being sold off cheaply. The ZX81 was really an exercise in cost reducing the ZX80, plus improvements brought about by an 8K ROM, more RAM and better video generation hardware.

The Sinclair ZX80 crammed a BASIC micromputer into 22 ICs
The ZX80 and the ZX81 pcbs for comparison

By the mid-1980s the cost of memory had fallen, which meant that I could afford at least 32K of RAM on my board.  I anticipated this and used 28 pin memory sockets for both RAM and ROM.

The 74LS139 was a dual 2 to 4 line decoder with active low outputs. It was ideal for decoding the memory address map to create chip select signals for both the ROM and RAM, whslt the other part of the IC was used to decode /IORQ plus a couple of address lines (A6 and A7) to provide four chip select signals for the peripheral I/O chips.

My board was laid out to accept four LSI peripheral ICs –  an 82C55 PIA – a parallel interface adaptor – with three 8-bit parallel ports, a Z80 PIO – with two 8-bit GPIO ports, an 8251A UART for serial communication and a Z80A CTC – a counter-timer chip.

There are numerous small Z80 designs available on the internet. including this one from Tynemouth Software. Another is well documented: Grant Searle’s 7 chip Z80 system – which uses a 68B50 UART for serial output.

There are many ways to build up a minimum chip system – and it’s part of the fun to design your own. There are no hard and fast rules – and the hardware is cheap and forgiving of amateur or home construction.

Software and Programming

Having built up the board, it was traditional to use an EPROM programmer to create a boot ROM for the system. My early boards used a hand typed copy of a monitor ROM, that used a 4×5 keypad for hexadecimal entry or serial comms with a terminal.  Eprom programmers are not so common these days having been superseded by flash ICs – so the alternative is to use another microcontroller to act as the support chip for the Z80 – to allow assembly language software to be developed on a laptop.

There are several choices of what this supporting chip might be – but it would be sensible to pick one that is widely available, such as the Arduino, Raspberry Pi or Parallax Propeller. All of these boards are viable – and it is a challenge to see how just you can implement something new – using commonly available resources.

As a bare minimum level of support, the device has to be able to write data into the Z80’s accompanying SRAM. Such a devices is knows as a ROMulator – or ROM emulator.

This programs a battery-backed, non volatile SRAM, to look just like an EPROM IC. This can be done by holding the Z80 in RESET, and using 16 port lines to set up the address of the byte you wish to write and 8 data lines for the byte itself. Manipulating the /CS, /OE and /WE pins of the SRAM will allow you to program each byte in turn. With battery back-up – from a coin cell or similar, the device will retain its data after power-down.

My Z80 minimum system plugged into a breadboard with the start of my ROMulator experiment.

Designing and constructing a ROMulator is a challenge in it’s own right, and I am still gathering ideas – and so will be the topic for a later blog post. – That gives me the opportunity to actually go ahead and make one.

However you look at it, recreating a minimum system is an excellent way to learn the basics of microprocessor systems, assembly language,  home construction, soldering and interfacing techniques, but most of all the freedom to create something physical from scratch – a pleasure often denied with the smart phone hardware we carry about with us today.

Why the Z80?

The Z80 was a top selling microprocessor during the late 1970s and early 1980s.  It was one of two microprocessors chosen for the majority of 8-bit home computer systems – the other being the 6502. It was used in various guises, including in electronic music keyboards, as a custom chip in the original Nintendo Game Boy, and was also copied by the Soviet Union.  It had a wealth of software written for it, and enjoyed vast library of CP/M operating system and its compatible software.

It was superseded by 16 bit processors such as the 8086 and Motorola 68000 which were incorporated into PCs and games machines, and were capable of greater clock frequencies.

One of the main limitations of 8-bit microprocessors was their 64K addressing limitation.  It took the advent of 16 bit processors with greater address spaces to get over this limitation.

It was also quite slow, by modern terms.  It typically had a 4MHz clock, but 4 clock cycles were needed  to execute one machine instruction, so it was limited to at best 1 million, simple instructions per second.

However – these limitations were overcome and a new generation of compatible processors was designed to compete in the 16-bit arena.

The original Z80 core benefited from more modern IC process technologies, and now appears in CMOS with 6MHz, 8MHz, 10MHz and 20MHz speed grades.

New developments produced even more new cores that can execute original Z80 firmware.  The fastest of these cores, the EZ80190 has a fully pipelined architecture and can be clocked at 50MHz – thus executing one instruction per clock cycle, – a full 50X the throughput of the original Z80 and can run as an extended system with a full 23 bits of addressing space.

In addition to higher speed and vastly improved memory space, it integrates many of the modern peripherals onto the IC, and thus you can have a system on a chip – rather than a system on a 100mm x 75mm board.

A small dev board module is available

Thus is the march of 35 years of progress.

This is part 1 of a 3 part mini-series

Click below for the remaining posts.

Part 2 Z80 Reloaded – The ROMulator

Part 3 Z80 Reloaded – Magic Bus

0 0

A New Month – A New Project

This year, I have worked on a number of interesting projects, as part of a tour of open source hardware.

The regular reader will know by now that I have a soft spot for retro-computer designs, and so this weekend, I am working towards resurrecting an experimental Z80 board I first wired up almost exactly 31 years ago.

First however, and somewhat pressing, I have the small problem of actually programming data into the Z80’s codespace – so I will have to engineer a solution from what I have readily available.

When it comes to designing hardware, there are so many possibilities of what could be done, but the good design engineer needs to come up with a plan of what should be done.  We all have constraints of time and money, and a solution may range from a quick and dirty hack – to a fully tested, documented and certified product.  Often something that starts with a hack, or a simple concept, will lead the way to a new design.

Building prototype hardware is a significant investment in time and money, and you can seldom afford too many false starts.

So before you commence the hard work, do your homework – read up the available literature on existing designs, define your objectives – what you hope to achieve – and by when and how much, and then get on with it!

I am currently at the homework stage, I have a need for a ROM emulator – based on a battery backed static RAM,  so that I can bootstrap a small Z80 system, and I want it to be cheap and not take forever to get it running.

So let’s formulate a plan for the basic hardware.


What I am proposing is a ROM-Emulator (ROMulator) to allow small computer systems to have bootstrapping or development code sent to them from a laptop.

This replaces the EPROM programmer that we all used virtually on a daily basis in the 1990s.

There was an excellent EPROM programmer called the Softy 2 and later the hand-held S3 by Dataman designs, which also acted as a plug in full speed ROM emulator.  Sadly I left all the jobs where I had access to one of those – so I will have to recreate something similar from the commonly available Open Source Hardware building blocks.

The Dataman S3 – EPROM Programmer/Emulator- from the early 1990s

This give me a hardware challenge – come up with something quickly and cheaply that allows me to access the SRAM on the Z80 bus, and program it with the Z80 machine code – by direct manipulation of the address, data and bus control lines.

I have an instinctive feeling that this could be done with an Arduino plus a couple of 74HC595 shift registers to set up the 16 bit RAM address.  I already have these built onto breadboard – saved from an earlier project – plus some code to drive them.  In addition it will need some tristate buffers for the control lines – so that tey may be released from the bus – and a bidirectional 8-bit buffer to communicate with the Z80 data bus.

However, there are other options, which should be reviewed here for completeness:

1.  Raspberry Pi

Spencer Owen uses a Pi Zero to generate video for his RC2014 system.  With three SPI driven shift registers  (for Address and Data) this could be built quite economically, and is a perfectly valid approach for those familiar with interfacing the Raspberry Pi. The problem is that I know nothing about programming the R-Pi.

2. Parallax Propeller

The Propeller P8X32A is a very versatile IC – and I plan to use them extensively later on, for video generation, keyboard and mouse interfacing and other system integration tasks.  For the moment however, I have not got enough Propeller SPIN language coding experience – so I will put this on back burner for later, and another blog post.

3. Arduino or Arduino MEGA

Certainly a low cost and readily available option. A quick web trawl for something similar revealed a design using an Arduino MEGA and a dual port RAM .  A little complicated – and I don’t really want true, full speed emulation – I just want to get the ROM image into the NV SRAM. With consideration, initially it doesn’t actually have to be NV RAM – the Arduino can be thought of a file transfer device that loads the Z80 with whatever code is needed  – in the first few tens of milliseconds before the Z80 is released from reset.

4.  STM32Fxxx Nucleo and Teensy 3.2

Significantly faster and more memory and GPIO than an Arduino.   Low cost and readily available – might make a neat, compact solution for the future. Has the advantage of on chip USB, more I/O & peripherals, Nucleo and STM32 boards are very cheap, and can be programmed using mbed. Thinking about this mbed could be used as an online repository to hold the Z80 ROM images – programmed into the body of the STM32 source code.

Another good contender is the Teensy 3.2 – which has a 256K flash and 64K of SRAM and 72MHz clock – which would give plenty space for all of the Z80 code to be located in the Teensy’s RAM.

It has 34 I/O lines including 21 Analogue inputs that could be used to sense the incoming address lines from the Z80 and return the appropriate byte from it’s SRAM. Indeed, with the right approach the Teensy RAM could possibly be incorporated into the Z80’s address space.

This looks a promising option and with Teensy 3.2 <$20 it is quite affordable.  Remembering of course what can be written for Arduino to test the system may easily be ported across to Teensy.  This looks very promising for the future – but first prove a few of the concepts on the humble Arduino.

5.  Other dev-boards

I have recently played with the TI range of MSP430 microcontrollers and some of their LaunchPad dev boards.  One of these that might be very appropriate is the MSP430FR5994  – which has a wapping 256K bytes of fast FRAM. This may also make a good long term solution as a self contained low cost solution – definitely worth bookmarking for future study.

6.  Serial SRAM or FRAM

These parts have a low pin count and are relatively easy to drive. They are available up to a least 128K bytes at low cost.  The 23LC1024 from Microchip is a 128K byte serial SRAM which is fairly easy to keep non volatile.  It should be relatively easy to keep a ROM image on this, which is then loaded into the 8-bit parallel SRAM when needed.  I already have developed some code to drive these serial devices – plus I have a bunch of them lying around.

7.  microSD Card

The ultimate games juke box for retro-computer systems.  Using an additional microcontroller to access a microSD card to retreive the firmware and program into the Z80 RAM is indeed an attractive prospect.

Clearly there are a lot of valid ideas here, and they outline methods and techniques that could be used on virtually any microprocessor that supports a traditional memory bus architecture. This opens up the possibilties for projects based on  6502, 6809, 68000,  and some of the rarer ones like 8080, 8085, 6800 and 1802  – though in the case of the 1802 – perhaps were they referring to the original date of manufacture!

Hijack the Bus!

Of all the possibilities outlined above – for expediency and wider potential, let’s come up with an initial solution based on Arduino and later possibly serial SRAM/FRAM. This should be the most flexible – and relatively quick and easy to do. If time permits the platform can be migrated to the Teensy 3.2 – with it’s abundance of I/O lines and on chip SRAM.

Assume that somehow using the Arduino we have managed to load the ROM image into the serial SRAM or FRAM. The standard Arduino has 32K of flash progmem – and this could be readily used to hold the ROM images for the Z80. Remember at the time of the 8-bit home computers – 8K ROMs were common, and 16K was considered large. There should be no problem squeezing this into the 32K progmem space.

When the device is powered up, the ROM image from the progmem ( or serial NV SRAM or FRAM ) is copied into the Z80 SRAM which is hanging on the bus. This needs to be accessed using a pair of serial to parallel shift registers to set up the address – as the standard Arduino does not have enough I/O pins for a full 16 bit address, data and control signals.  Off loading 16 addresses to the shift registers not only saves on pins but has other advantages too.

The SRAM is connected to both the Z80 address and data buses and also to some bus control signals such as /RD and /MREQ.  We need to hijack these and drive them with the Arduino – having first forced the Z80 into RESET – where it sets all of its bus lines as fairly high impedance inputs – allowing us to over-ride it.  We could use bus-request (/BUSRQ) and bus-acknowledge (/BUSACK) – but that would be so British, just too polite. Let’s just barge in, uninvited, jam the cpu into RESET and start laying down some new memory contents.

The Arduino is going to be a like parasitic cyber device (ROMulon?) that takes over the Z80 host’s brain and body- and radically alters it’s behaviour.  Retain that image if you can – it just makes it all seem a lot more exciting!

The 74HC595 shift registers are ideal for the job as they have a breadboard friendly pinout, easily driven with either 8 bits or 16 bits and they have an output-enable pin – which allows their output lines to be switched in and out of high impedance mode – so that when tri-stated – they can sit on the Z80 address bus without causing a problem. I also like shift registers, and think that they should be used a lot more often.

More on Shift Registers Even more on Shift Registers

SIMPL_shift A version of my SIMPL hardware bootstrapping language to drive the address shift registers.  Allows typing of a 16 bit number followed by r  (for register) which latches the value of r on the shift registers.

I have sketched the proposed ROMulator below. A quick pin count suggests that it’s going to consume all of the Arduino Uno’s free pins leaving just D0 and D1 for serial communications.

In addition to the address shift registers it also has a 74HC245 bidirectional buffer.  This will allow the ROMulator and the Arduino to be entirely Tristated from the Z80 bus – as a precautionary measure. A hex inverter 74HC04 is used to invert the bus control signals, but on reflection I think that these should be tristated too – possibly using a 74HC125 quad tristate buffer or another 74HC245 to allow them to be isolated them from the  Z80 bus when the Z80 needs to run. The Arduino code will automate the mechanics of capturing the bus, programming the RAM image and releasing the Z80 to run free again once the new code image is loaded.

OK – so its 4 ICs, plus the serial SRAM and the parallel SRAM added to the Arduino – but that’s the nature of hardware hacking – old skool style!

So to recap, the Arduino has a serial SRAM with battery backup sitting on it’s SPI bus and up to a 128K x8 parallel SRAM hanging on a couple of shift registers and 8 GPIO lines that access the RAM data pins.  The Arduino will also have some control signals including /RESET, /MREQ, /RD. /WR that it can use to force the hardware hanging on the Z80 bus. If we include /IORQ to that list – we can also force drive the I/O on the Z80 bus too – handy for testing peripherals etc.

So that’s the plan, next for the implementation.

Quick Sketch of ROMulator scheme – not quite fully finalised! Needs a pcb!

Harware Implementation

Best described as a big mess of wires – as all bus projects invariably end up. There’s no getting away from those 24 signal lines, plus 6 control lines that make up the Z80 bus.

The first step of the project was to wire up the shift registers and data buffer – to prove that the Arduino could program the SRAM. With this working, I was reasonably confident that I could extend the ccircuit to include the full Z80 minimum system  – built on the “Lazarus” board. (Is that like Toys ‘R’ Us ?).

The two 74HC595 shift registers are on the left of the breadboard, then the 74HC245 bi-directional  bus transceiver.  The 62256 SRAM is mostly obscured by a mess of orange jumper wires. If ever a project needed a pcb – this has to be it.

The Arduino UNO has 20 I/O lines – and it looks as though I will need all of them.

D0    Rx
D1    Tx
D2    Data 0
D3    Data 1
D4    Data 2
D5    Data 3
D6    Data 4
D7    Data 5
D8    Shift Register Latch Pin  (12)
D9    Data 6
D10   Data 7
D11   Shift register Clock Pin  (11)
D12   Shift register Data Pin (13)
D13  Spare – but useful as serial clock and LED indicator

And the analogue input pins are set up as their digital equivalent versions D14-D19

D14   /MREQ
D15   /READ
D16   /WRITE
D18   /IORQ
D19   /RESET

Note that most of these control signals are active low.

It should be remembered that the Z80 board plugs into the ROMulator via a 40 pin socket that carries the full Z80 bus.  However, unless the ROMulator actually carries its own 62256 RAM, then the RAM_CS is not available to it – so it relies on the address decoding logic of the Z80 target board to access this signal.

In this case the RAM chip select signal will be derived from /MREQ and the address lines.  So the Arduino pin that is being used for RAM_SEL should be changed to /MREQ.

A small change to the Arduino code will be needed.

The prototype ROMulator on a breadboard – allowing the first 256 bytes of RAM to be written – more wires please!

It took a bit of fiddling around to get the control signals to work.

Arduino Digital Pins 14 – 19  (Analog Input pins A0 – A5)

D14  /RAM_SEL/MREQ      62256 pin 20   /CE
D15  /READ             62256 pin 22   /OE
D16  /WRITE          62256 pin 27  /WE and 74HC245 pin 1 DIR
D17  TRISTATE     74HC245 pin 9 /EN and both 74HC595s pin 13
D18  /IORQ

Software for the ROMulator

As seen above, I am a fan of using my SIMPL language for experimenting with hardware. It allows you free and unhindered access to do what you want to do –  from an interactive serial terminal.

It’s based on a much simplified version of Forth – and as all this renewal of interest in the Z80 is to get a homebrew retro-computing platform that will run Forth, SIMPL seems the appropriate choice. You can read about SIMPL from this post from 2014 – when I added the shift register functions. You can copy that version from the Github Gist.

A brief outline of the read and write cycles are below:

Write Cycle

Set up the address
Set up the data
Un-Tristate the buffer
Select the RAM
Assert /WR
Deselct RAM
De-assert /WR
Tristate registers and data buffer

Read Cycle

Set up the address
Set up the data
Un-Tristate the buffer
Select the RAM
Assert /RD
Read the data buffer
De-assert /RD
Deselct RAM
Tristate registers and data buffer

The “ROMulator3” Arduino initial test software has been put on this Github Gist.

// ROMulator 3

// Compiled using Arduino 1.65 or later

// A customised vesrion of SIMPL to allow RAM and Z80 bus to be exercised using SIMPL.

// Address is st using a pair of 74HC595 shift registers
// Data is passed through a 74HC245 bi-directional bugger
// TRISTATE line when raised isolates the address and data registers from the Z80 bus – // allowing it to run
// RESET – active low is used to put the Z80 into RESET so that the RAM can be loaded

// Other active low  bus control lines are READ, WRITE, RAM_SEL (/CS) and IORQ

//  Basic memory r/w Commands are as follows  – values are integer decimal

//  170 55w      write the value of 170 to address 55
//  44  32760w    write the value 44 to the RAM address 32760

//  55r          read and print the value stored at address 55
//  132n         output 132 on the ROMulator data port
//  240q         output an 8 bit address 240 on lower address lines (for I/O operations)

// ——————————————————————————

In the next part we look in more detail at the workings of the ROMulator and how it controls the Z80 bus. I also look at a possible suitable candidate for a low cost implementation of the design on a pcb.

Part 3  Z80 Reloaded – Magic Bus

0 0
TheBusDriver/ROMulator – During Development

It’s been a busy weekend, and I have rediscovered a lot about the Z80 and the old-fashioned way of wiring chips up with bus-wide memory ICs.

This is something that we forget about these days – now that most of the bus wiring and peripherals are integrated into the metalisation layers of the IC. One modern microcontroller can replace several tens of square inches pcb real-eatate of old DIL packages!

It was also a real buzz getting the Arduino to the point where it could read and write to the SRAM, just using a couple of shift registers and an octal bidirectional buffer. There’s mileage in this concept – and something I wish to explore further.

The plan is that the Arduino acts as a support IC for the Z80 – even allowing the Z80 assembly language to be stored in the Arduino flash, and programmed across the “Magic Bus” into the Z80’s accompanying SRAM, in a few tens of milliseconds before the Z80 is released from reset – and allowed to start program execution. It’s true – both Mr Brute Force and Mr. Ignorance came around to stay this weekend.

With the Z80 hex embedded in the PROGMEM of the Arduino – it means that the Arduino IDE can be used as a fairly crude development system for the Z80 – at least it allows you to cut and paste your hex-dumps into progmem.

The reason for initially choosing the Arduino is that it is popular and inexpensive. The program memory is large enough to hold a substantial Z80 firmware file,  but unfortunately the Arduino RAM is lacking somewhat.  The motivation for this project was to come up with a quick programming solution, and I accept that there are a myriad of ways of achieving the same result.

Moving forwards, a better approach might be to use a more capable microcontroller as the supporting device, and actually map it into the Z80 memory map, by sensing the requested memory address on port lines and responding with the data byte, taken straight from an area of the support mcu’s own RAM. This is likely to require an ARM device to meet the speed and RAM requirements.

More on this in a later post.

Here’s to Progress

So I begin with an update on the progress of the ROMulator design – which as the weekend sails by, I feel should more correctly be renamed the BusDriver. The initial concept has changed slightly – as the priorities have modified from a non-volatile RAM based design to one where the Arduino holds the ROM images permanently in its progmem.

The brief was to come up with a simple design that would allow a venerable Z80 system to be jumpstarted from scratch  – without access to EPROMS or programmer.  I decided that using a standard Arduino might prove the easiest and most popular way of doing this  – and with a circuit that could readily be built up on stripboard or breadboard.

I have made a lot of progress on the ROMulator, to the point where I am thinking that I might turn it into a pcb.  It’s a handy bit of kit to have around – every 25 years or so when you want to jumpstart an old timer like the Z80!

A thought occured that it might make a useful jumpstarter board to add to the boars available for Spencer Owen’s RC2014, Z80 backplane based retro-computer.

Indeed, as the techniques used are fairly general, and applicable to a variety of 8-bit bus processors – all of what is outlines here could be utilised for 6502 retro-designs too!

Over the course of the construction phase, my plans changed a little and the circuit has evolved to meet the changing thoughts .  I soon realised that I would have to add another tri-state buffer for the signals that take over some of the cpu control lines, whilst it is in reset. At the time when you release the reset line, you need to hand the whole bus back to the Z80, control lines included – otherwise much weirdness occurs – and believe me, things have been sufficiently weird this weekend, without me adding more random acts of bus-possessiveness.

Arduino Code

The Arduino code has been evolving too – it started with some simple SRAM read and write commands, which were then built up into a small collection of routines needed to automate the process of loading the ROM image into RAM, releasing the Z80 from Reset, and general niceties such as a hex dump viewer and ultimately a hex editor and disassembler would be nice.

This got me thinking that whilst the standard Arduino is sufficient for the basic BusDriver, one based on an Arduino MEGA or ATmega1284P may prove to be long term more desirable. Both of these parts have considerable more resources than the Uno, and the extra flash memory capacity is ideal for holding larger or multiple ROM images.

The Arduino Nano has the advantage of small size, plus an extra pair of ADC pins – which might come in useful.  The pro-mini and pro-micro, at first glance appear to be just short of a couple of I/O lines – that would otherwise had made them ideal.

If the Bus Driver is to be added to the RC2014 backplane as a “support card” then it could take on a dual role – that of an intelligent I/O processor – a kind of 2nd processor that handles the I/O intensive stuff – leaving the Z80 free to do the more processor/memory intensive operations.

As a historical aside note – This was the original raison d’etre for the Microchip PIC – as a Peripheral Interface Controller – for an early processor by General Instruments – they couldn’t fit everything in the one package – so they split off the main processor from its peripherals – and added a simple processor to manage the peripherals. In time – the PIC became a microcontroller in it’s own right.

It would also be a minimum investment way of bringing the Z80 into the 21st Century – giving it access to all the fun peripherals we take for granted – such as wifi, Bluetooth, microSD cards, flash USB drives – using the CH376, VGA video and other more recent connectivity.  It also avoids the complication of having to source multiple, rare I/O peripherals – as one I/O processor can handle bunch of tasks – including UART, keyboard, mouse, video etc.

The RC2014 Backplane

Here’s the bus connections as used in Spencer’s RC2014 design. It’s fairly logical and meets the physical constraints of low cost SIL connectors and the physical pin-out of the Z80. The general form could be adapted to suit 6502 or other 8-bit processor – or by “doubling up” – using 2 x 40 header strips – the general arrangement could be used for 16-bit machines (68000?)  high pin count ARM processors or FPGAs that need access to a lot of I/O.

1 A15
2 A14
3 A13
4 A12
5 A11
6 A10
7 A9
8 A8
9 A7
10 A6
11 A5
12 A4
13 A3
14 A2
15 A1
16 A0
17 Gnd
18 ‘+5v
19 M1
20 Reset
21 Clock
22 Int
24 WE
25 RD
27 D0
28 D1
29 D2
30 D3
31 D4
32 D5
33 D6
34 D7
35 Tx
36 Rx
37 Spare
38 Spare
39 Spare
40 Spare

The 16 address lines well match the pin-out of the 74HC595 shift registers and the data lines are easily bussed into the 74HC245 octal  bidirectional bus buffer.  The bus control lines between pins 19 and 26 can also be buffered using a tristate 74HC245 buffer.

With some additional address decode logic – the I/O map may be decoded allowing backplane boards to be selected using board enable lines  – brought to the 4 spare signals on pins 37-40.

A bit of a squeeze – but you can actually get this into a 10x10cm board – saving money at the Chinese low cost board houses.

To be continued……

If you missed the first two parts – you can catch up here

Part 1 Z80 Reloaded  – Lazarus Resurrected

Part 2 Z80 Reloaded – The ROMulator

0 0

ARM to Z80 – and Everything In Between!

Building the ROMulator over the weekend was a fun and worthwhile experience – and it has opened up an number of avenues for future work.

It appears that others have done a similar thing – a search on “Arduino Z80” will reveal quite a few interesting projects – all of which show great promise.

One I liked was the in-depth project by @Domipheus and a nice multi-part blog describing his work. Here, he has used a Teensy 3.2 – which has 64K of SRAM on chip – to act as the Z80 RAM. Of course, this is perfetly possible – as a modern ARM Cortex processor is perfectly capable of sampling an address on its input port pins – and returning a byte of data from RAM to a set of output pins.  Here the Teensy can act both as RAM but also it’s rich set of memory mapped peripherals are accessible to the Z80.

So this got me thinking that using a low cost ARM to act as the Z80 system RAM plus peripherals for a vintage cpu seems like a neat idea.  It may seem a bit like a sledgehammer to crack a nut – as the ARM can probably emulate a Z80A in better than realtime – and has full GCC support. However to have a real Z80 executing Z80 code is perhaps sufficient to keep the purists happy.

If you use something like the ST range of Nucleo boards – such as the Nucleo 446 RE – you get a 180MHz ARM Cortex M4, 128Kbytes of SRAM,  about 50 usable I/O lines and USB interface on a small but manageable board for around $12. It can be programmed using mbed – which would allow a repository of vintage cpu code to be held withing one’s mbed account.
The ARM becomes not only the RAM for the Z80 but provides a set of modern peripherals, and supports the development system – in whatever language you choose – BASIC, Forth, C etc, plus access to old CP/M software packages.
The ARM connects to the full Z80 memory and data bus and spits out the byte from RAM according to the address requested. The Z80 can communicate with the ARM via a mailbox set up in RAM.
This method is not limited to the Z80 – strapping an ARM to a 6502 memory bus will certainly give it the ride of its life!  The Western Desgn Centre WDC – who created the venerable 6502 – more than 40 years ago, are still supplying them in 40 pin DIL packages – because there is still a demand for these devices – notably from the hobby community.  The WD65C02 is now available as a 14MHz part.

For $12, some stripboard and half a day spent wiring up 40 pins – it’s definitely worth a punt!

To keep the 6502 affectionados happy – I found this neat little project – an Arduino emulating a 6502 and providing a cute little retro-trainer based on the KIM 1 – start here and follow the links.
Also on the Obsolescence Guaranteed site you will find the PiDP-8 and the PiDP-11 retro-computers – certainly a labour of love and attention to detail.

EZ80190 50MHz and Z80 20MHz

A package arrived in the mail today with some Z80 and EZ80 samples – shown above.  I decided that having a high speed Z80 based retro computer would be a neat project – so took the plunge and bought some ICs from Mouser.

The EZ80 is almost a Complete System on a Chip – requiring only external memory

The EZ80190 is a remarkable device – as it has the fully pipelined 50MHz EZ80 core – which runs 50 times faster than the old 4MHz Z80A, plus it has a really rich peripheral set, consisting of UARTs, SPI, I2C, DMA, GPIO. In addition it has a 24 bit addressing range (16MB) and has 8K bytes of internal RAM, plus a high speed multiplier-accumulator, which can be used for DSP operations such as FFT, digital filtering and additive musical synthesis.  With an ARM included to provide LCD or video output (such as STM32F746) – you could have a supercharged 1980s style retro-computer with 1Mbyte of RAM in about 3 ICs! With the display controller on the STM32F746 – you can have LCD screen or a large screen monitor.

How far you might wish to take this process, remains entirely up to the individual – but the combination of a fine vintage microprocessor – aided and abetted by a modern ARM – sounds a truly fun combination.

Software & Applications

Whilst most retro-computers are created for replaying vintage video games, the possibility of a high speed machine with modern peripherals,  16MB of memory and the ability to run native code could open a whole set of applications. Even BASIC at Warp Factor 50 would be capable of real computing work.  Forth, also might be an attractive option for the old-skool 8-bit programmer, who wants to really get inside the workings of a timeless machine – in just the ways that modern operating systems seek to prevent!

There are so many possibilities – “If we build it – they will come……”

New Arrivals

EZ80190 50MHz and Z80 20MHz

A package arrived in the mail today with some 20MHz Z80 and 50MHz EZ80 samples – shown above.  I decided that having a high speed Z80 based retro computer would be a neat project – so took the plunge and bought some ICs from Mouser.

The EZ80 is almost a Complete System on a Chip – requiring only external memory

New Kid on the Block – the EZ80190

It’s the EZ80190 that has caught my attention most of all.  A 100 pin LQFP which creates an almost complete Z80 computer on a single IC. All we need is a suitable break-out board.

The EZ80190 is a remarkable device – as it has the fully pipelined 50MHz EZ80 core – which runs 50 times faster than the old 4MHz Z80A. Additionally, it has a really rich peripheral set, consisting of UARTs, SPI, I2C, DMA, GPIO.

The external memory bus a 24 bit addressing range (16MB) – and uses cheap byte wide devices. It also has 8K bytes of internal RAM, with the expectation that external SRAM and ROM will be added.

It has a high speed multiplier-accumulator – accumulating 16×16 multiplies to 40 bits –  with it’s own 1K dual port feeder RAM , which can be used for DSP operations such as FFT, digital filtering and additive musical synthesis.

What I like about the EZ80 is that it represents a level of integration just not possible when using separate Z80 peripherals in 40 pin DIL packages. I was torn between a purist all – Z80 system  – using the genuine Z80 peripheral ICS, but then I estimated the board area and the work involved  – plus the fact that the peripherals are getting rare and more expensive.

So I have decided to spend my time putting an EZ80190 device onto a small, breadboard friendly

carrier board – above. The RC2014 bus is along the lower edge and the full EZ80190 I/O is brought out along the top edge. We do try to make things easy around here…..

The EZ80 ControlStick – A 100 x 27mm Breadboard Friendly Computer 

The ControlStick offers a complete integrated Z80 computer that can be used in its own right as a stand alone controller – or incorporated as part of a larger system – the choice is yours.

It has up to 2MByte of 10nS SRAM, and a 32 pin socket to take a traditional boot-ROM. USB VCP connectivity is provided by a CH340 or PL2303 USB to UART adaptor.

So the complete Z80 system is reduced to just 3 or 4  ICs on a 100mm x 27mm pcb with a 0.9″ DIL spacing. The board is specifically designed to fit onto a full size breadboard, or stripboard – with one row of exposed holes on either side  – to connect to.

In addition, the proposed pcb will make use of Spencer Owen’s RC2014 40 pin Z80 bus – so that it is fully compatible with the RC2014.  It is possible to use extended female headers – so that one of Spencer’s RC2014 boards could be stacked on top.

How far you might wish to take this process, remains entirely up to the individual – but the fusion of a fine vintage microprocessor – aided and abetted by a modern ARM and peripherals – sounds a truly fun combination.

With an ARM  (such as STM32F746) or FT812 embedded video engine on a separate card to provide LCD or video output – you could have a supercharged 1980s style retro-computer with 2Mbyte of RAM in about 4 ICs! With the display controller on the STM32F746 – you can have LCD screen or a large screen monitor.

Software and Applications

Whilst many retro-computers are created for replaying vintage video games, the possibility of a high speed machine with modern peripherals,  16MB of memory addressing space and the ability to run native legacy Z80 code at 50X original speed – could open a whole set of applications.

Even BASIC at Warp Factor 50 would be capable of real computing work.  There are several sources of BASIC vailable, but a good choice might be the Z80 version of BBC BASIC  – written and maintained by Richard Russell.  Richard states on his site:

“BBC BASIC (Z80) incorporates a full Z80 assembler, which allows you to include assembly-language code within a BASIC program. This is a very powerful feature: it enables speed-critical operations to be carried out much more quickly than would otherwise be possible in BASIC, and provides access to machine and operating-system features that would otherwise not be available. Example programs are supplied with BBC BASIC (Z80) which illustrate the use of embedded assembler to implement fast string and numeric array sorting.”

Forth, also might be an attractive option for the old-skool 8-bit programmer, who wants to really get inside the workings of a timeless machine – in just the ways that modern operating systems seek to prevent!  There are many Z80 Forths available, and these offer the unique programming and development environment, including Z80 assembler.  Forth might not be to everyone’s liking, but perhaps if hosted by a familiar processor, there may be some looking for a new coding experience.

The EZ80 provides a familiar set of modern peripherals – that take all the hard work out of the design.  If you want a minimum system – you can have a megabyte, 50MHz class machine, with GPIO ports and peripherals on

This simplification of hardware, and the adoption of the latest technology to constantly improve upon a basic design is something that has been central to the computing industry for 70 years. As technology moves on – there will always be simpler, faster and cheaper ways of achieving the same end game.

For example, the PDP-8 between it’s launch in 1965 evolved from a fridge sized cabinet to an LSI chip – in just 10 years, and now recreated as an attractive product based around the Raspberry Pi. Whilst few of us could ever own or maintain an original 50 year old PDP-8, we may still get a lot of retro-computing experience and enjoyment from a recreation based around a $35 R-Pi.

The hardware will always be changing and improving. We have probably passed the point where virtually any computing process of the last 50 years can be effectively simulated on very low cost mobile computing hardware – on an ARM chip costing under $10.

There are so many great ways of achieving wonderful things in readily available hardware these days. There has never been a better time for creative hardware engineers. Making cool stuff from low cost electronics, has really blossomed as a hobby, and become fashionable – after decades in the doldrums.

When once we used 7 segment LEDs – we now have RGB matrix displays.  CRT monitors have given way to LCD  screens of all sizes and resolutions – and rotating magnetic storage media is rapidly being replaced with high density solid state, Flash and Ferroelectric non-volatile memory solutions.  LSI chips – such as the CH376 allow a small DIY computer to host microSD cards and USB Flash drives – with minimum intefacing  – with FAT16/32 handled by the IC.

Equally, a SPI based Ethernet controller – such as Wiznet or even the venerable ENC28J60, will make the internet and web-connectivity available to a Z80 system – and with 50MHz operation, and a 16MB address space – even a Z80 can handle the volumes of throughput that a browser or micro-webserver application requires.  The EZ80190 – is even billed as “Webserver” – hinting at Zilog’s intentions for this much rejuvenated old timer.

The 1MHz clock frequencies, I started with – in the early 1980s, have risen an order of magnitude every decade, to the point where you can but a 200MHz + ARM chip for $10, solder it onto a breakout board and have a very powerful, self contained computing & DSP platform.

My first computer was a ZX81 kit shipped with a pair of 2114  1K x 4bit static RAMs. 75% of this RAM was used by the screen buffer, leaving just 256 bytes for program storage. My first act of defiance, was to fit a socket for a 2K SRAM – by that time affordable, and instantaneously I had 5 times the available RAM space.

As a hardware engineer, it is important to understand and embrace this continual birth and re-birth of better ways of doing the same old thing, and not get unnecessarily hung up on insisting that every last detail of the hardware is correct – as per the original.

At the end of the day, we are merely creating a platform, a stage or stadium – whatever, on which to “put on a show”.

There are so many possibilities – “If we build it – they will come……”

0 0

The 8080 (Z80) Instruction Set.

Federico Faggin worked at first at Fairchild and then Intel in the late 1960s and early 1970s. He was central to the microprocessor design work there  – including the 4004, 8008 and later was instrumental in devising the 8080 instruction set.

He left Intel in 1974, founded Zilog, and created the Z80 processor, who’s design was clearly influenced by the 8080, and had a compatible instruction set – so that the new Z80 immediately had access to the large library of software already available for the 8080.

Expressed in Octal – The 8080/Z80 Instruction Set takes on a new clarity

The 8080 was developed at a time when the PDP-8, PDP-11 and DG Nova were the popular mini computers of the age – and so the 8080 was developed – influenced by the techniques and methods that were commonplace within those minicomputers.

So it was natural to use the then familiar octal representation of the instruction set – and when you use octal for the 8080 rather than hexadecimal – it becomes immediately clear, what a clever piece of design logic was involved.  The spreadsheet above places the 8080/Z80 common instructions in numerical order – but on an Octal grid and adds a little colour to distinguish the various classes of instruction.

The load instructions are in pale blue and occupy all the instructions in the 1xx band – except for 166 which would have been load (hl),(hl) which would be quite pointless – and thus replaced by HALT.

The register – accumulator arithmetical and logical instructions occupy all of the 2xx band.

The 8080 had 8 source and 8 destination registers – and these could be represented by a single octal digit – and thus a 3 bit wide bit field in the instruction.

B    0
C    1
D    2
E    3   
H    4 
L    5
M    6     M stands for Memory and is (HL)
A    7

One quarter of the available instructions are use for moving data between registers – and these take the form of the MOV instruction (later load LD on Z80) :

MOV  r1,r2         move the contents of register r2 into r1

01  xxx   yyy        yyy = source register    xxx = destination register

for example   MOV  A,L       where A  =  r7  and  L  = r5

01  111  101

Expressing in octal  –

1    7      5

Any instruction in octal starting with a 1 is MOV.

For instructions beginning with 2, the first two octal digits are used to decode the instruction operation, with  the 3rd octal digit supplying the operand. These are the ALU arithmetical and logical operations – where a register supplies one operand, the other being provided by the Accumulator A, and the result being placed in the accumulator. These all take the form 2xy

20     ADD  –  Add
21     ADC   – Add with Carry
22     SUB   –  Subtract
23     SBB    –  Subtract with Borrow
24     ANA    – AND with Accumulator
25     XRA    – XOR with Accumulator
26     ORA    – OR with Accumulator
27     CMP    – Complement

For instructions beginning with 0, it is the middle digit that defines the register operand, and the last digit defines the operation.

This is perhaps best depicted in the colour coded spreadsheet above.

The contents of the “Full Monty” RC2014 Z80 Retro Computer Kit

First Impressions.

This is a neat little kit from Spencer Owen, which allows you to build up a complete Z80 Microcomputer, from scratch, in 2 to 3 hours.

Spencer sells this kit through Tindie, and the service was exceptional – I ordered the kit on Thursday morning and it arrived in the post on Friday morning. Fortunately Spencer had what I needed in stock, and it caught the early post.

There are several variants of the kit, tailored to suit your time, expertise and budget. I chose the comprehensive “Full Monty” kit – mainly for expedience.

1. Bare Bones – just the 5 pcbs – to be used with stripboard backplane. You need to source all the components, ICs, sockets, connectors and be able to obtain a suitable ROM image. An economical approach – if you have plenty of time. Cricklewood Electronics is a good source of the rarer ICs.

“Bare Bones” Photo: Spencer Owen

2. Starter Kit – pcbs, connectors, BASIC ROM, stripboard for backpane. Contains the harder to find connectors and the BASIC ROM.

“Starter Kit” Photo: Spencer Owen
3. Full Monty – all components, ICs, 5 pcbs + backplane. The easiest and quickest option. You can be up and running with a full Z80 BASIC computer in 2- 3 hours.
“The Full Monty” Photo: Spencer Owen

For more information – have a look at Spencer’s RC2014 site – which describes the development of the product, offers useful information and blogs some of the high and low points of the project.

There is also a recently formed GoogleGroup devoted to the RC2014.

The Design

The Z80 microcomputer is based around 5 modules:  CPU, ROM, RAM, Clock/Reset and Serial I/O.

With these 5 modules you are able to build up a fully functioning computer that runs Microsoft BASIC and communicates wit a terminal program on your PC via a serial UART and FTDI lead.

The modules are 100% through hole components, and all ICs are socketed. Provided that you can identify pin 1 of an IC socket and be able to solder approaching 600 soldered joints – reliably – then this kit provides suitable distraction/entertainment for a wet June afternoon or evening.


Note the 4 jump straps on left. Your CPU will not be an old 4MHz Zilog Z80A from 1984!

This is a socketed 40 pin Z80 (10MHz) on a slender board, with a 34 way right angle header and a 3K3 resistor.  The whole of the design of this machine and the backplane are based on the efficient means of getting the Z80 memory bus (address lines, data, control) down onto the backplane. The arrangement is not only logical but closely follows the pin-out of the Z80 40 pin DIL package.


Note the position of the jumper links on the left – all connected between A and 0

This module provides address decoding, and segment selection for up to a 64Kx8 EPROM or FLASH equivalent, in a 28 pin socket, with address and data lines broken out to the standard 34 way bus conector.

A single 74HC32 quad OR gate, provides an output enable signal for the ROM chip by OR-ing /MREQ and /RD and a /ROM_CS chip select signal by OR-ing together A13, A14 and A15.  This forces the ROM selection to the part of the address map where these three address signals are all low, which is essentially addresses 0000 to 8192 – which is the bottom 8K of the memory map.

Three additional jumper inks allow selection of the Address line or logic 1 to force even more constraint on the ROM selection.  This caters for alternative ROM sizes.


62256 32K RAM Module with Read/Write selection logic

This board is similar to the ROM module but allows a RAM device to be fitted into the 28 pin socket and provides chip read and write controls by decoding /RD, /WR ORed with /MREQ. Again this is done in a 74HC32 quad OR gate, and a single 74HC04 inverter is used to negate address line A15, and use it to enable the /RAM_CE.  This makes the RAM active whenever A15 is high – thus forcing it into the upper 32K of the address space.

There are many ways to approach address ROM and RAM decoding, and if the ROM and RAM were on the same pcb, some savings could be made.

Clock / Reset.

Component placement on clock – reset module

This is the smallest board of the set and contains the clock and reset circuit.  The clock is generated using the standard method using a hex inverter to for an oscillator with a 7.3728MHz crystal, and an inverter as the clock driver.

Three resistors (1M, 1K and 2K2) and 2 x 22pF capacitors need to be fitted.  A conventional power up reset switch circuit using a 2K2 pull-up resistor is also implemented.

The board only requires to pick up +5V, 0V CLK and /RESET from the bus – so is only fitted with a 5 way bus pin-header.  Users should be careful to get this located properly in the right position.

Serial I/O

Note the 5V strap in the centre next to “FTDI” and the 3 x 2K2 resistors. Other components not fitted.

This module uses the 68B50 UART IC – my example was produced by Hitachi – but there used to be several manufacturers including Motorola and ST.

It requires a single inverter (74HC04) to invert the /IORQ signal – as this IC was originally intended for 6800 systems – not Z80.

It is supplied with the 7.3728MHz clock, which it divides down by 64 to produce serial at 115200 baud. The kit supplies a 6 pin header to allow direct connection of a 5V FTDI lead – A jumper link allows the 5V supply from the FTDI cable to be used to power the computer.

Don’t forget to fit the three 2K2 resistors, which link the 68B50 Rx, Tx and CTS lines to the FTDI header!

There is provision to fit a traditional MAX232 RS232 level converter IC, 4 x 1uF capacitors and a 9 pin D-type connector (cleverly fitted to the edge and picking signals up from each side of the pcb), if standard RS232 com port is needed. These RS232 option parts are not supplied in the Full Monty Kit, but may easily be purchased elsewhere.


Fit the 8 blue 100nF decoupling capacitors first – before soldering the 40 way headers into the 5 central positions.

I have addedd an extra 7805 regulator and 10uF filter/decoupling capacitors which are not included in the “Full Monty” kit.

Building the Kit

The build process was fairly straight forwards and quick, but I did have to consult other online documentation in order to clarify some points. That documentation has been included here.

The first stage was to fit all the IC sockets. First identify the mark on the socket that signifies the “Pin 1 ” end and make sure that is aligned with the “notch” on the screen print legend.

I always tack the socket in place by soldering two or four diagonal pins – ensuring that the socket is flat and level, correctly orientated and has no bent or damaged pins.  Once tacked in place, the remainder of the pins can be soldered quickly and reliably with the full confidence that the socket is correctly placed.

The 5 boards with most of the sockets soldered in. Time 15 minutes.

Next we begin to fit the through hole components – consisting of resistors, capacitors and jumpers. It was at this stage that I had to refer to other documentation to ensure that I had the correct values of resistors – fitted to the right boards.  The graphic below from Spencer helped greatly in this respect.

Component Placement Guide (Spencer Owen)

The three resistors, two 22pF capacitors and 7.3728MHz crystal were fitted to the clock module.  The reset switch was not quite the correct fit for the holes in the pcb – but easily stretched to fit. The 8 pin right angle header will not fit if the crystal is fitted too close to the board, but can be truncated to a 5 pin header if necessary.

The wire ended components supplied in the kit
All modules soldered, 34/26 right angled pin headers fitted and ready for IC insertion.

One slight area of confusion was which side do I fit the right angled header – on the component side or on the reverse side? I opted to fit them all from the component side and solder on the underside. However the CPU board may be an exception to this rule – it does not really matter.

This photo from Spencer’s Tindie site provides some clarification of the order of the boards and direction of pin headers.

This photo from Spencer Owen  indicates the intended order of the pcb modules in the backplane.

As the pin header strips are long – and have a tendency to move – make sure they are correctly tacked in position before committing to soldering a long run of pins.

Only 200 joints to solder on the backplane!

At one hour into the build I started to solder the female connectors into the backplane.

Note – it is best to solder the 8, blue 100nF decoupling capacitors in place before fitting the 40 way female header strips! Just a lot less fiddly.

Make sure that the female headers are tacked in place so that they lie flat, level and perpendicular to the backplane. There are 200 soldered joints to do here – so a little extra time spent here could save you a lot of time looking for unsoldered or defective joints later.

Again there was some question to as which of the eight backplane slots should have the five connectors fitted.  I looked at an image on Spencer’s Tindie site – and this suggested that I should be soldering the central 5 blackplane connectors.

The outside backplane connectors are separated in both the address and data lines – so that series termination resistors could be fitted.  Again – a webpage or a Wiki with this information on, step by step – would have been useful – perhaps that guide is what I am writing here now?

Stop the Clock – We have a completed computer!

The UART board was the last to be completed.  There were no notes on what resistors to fit – so I had to refer back to the schematic on the modules section of the RC2014 site. From here I was able to confirm that they were 2K2 and also note the orientation. it’s easy to get the one on the left of the FTDI header in the wrong orientation.

This schematic shows the 3 series 2K2 resistors and the 5V jumper link needed on the UART board
I learned some years ago with this type of soldered through hole kit is that it is best to use entirely horizontally inserted components, and to put the value in ohms, nF or uF directly on the pcb screenprint.  R1,R2,R3 is fairly meaningless unless you have the schematic at hand.
Note also that you have to fit a jumper link on the UART board to allow the FTDI cable to supply the 5V to the computer.
First Breath of Life
First test of the Micro$oft BASIC – which is supplied on ROM

My machine did not work first time.  It produced a garbled start up message, which led me to think that there might be a baud rate problem.  I tried a few options but with no avail.

So I then individually inspected the 600 soldered joints using a x10 mangnifying lens – and traced my problems down to a badly soldered address line on the underside of the backplane.

Stuff like this can easily happen with systems that have high numbers of signal connections like this.  Check you work before final assembly – particularly the larger ICs and connectors.  It took me 90 minutes to solder this kit – and a further 90 minutes to find the one badly soldered joint that was the cause of it not working.

A great little project for a wet Friday evening in June!

Even 30 years on from the British Home Computer Revolution of the early 1980’s – there is still considerable interest in these mid-1970’s microprocessors.

Z80 Enthusiast, Grant Searle has done a lot to maintain interest, and has recreated several simple microprocessor systems – including Z80, 6502 and 6809. Recently he has moved across to emulation of these three classic microprocessors on a low cost FPGA board.

It was Grant’s 7 chip, minimum Z80 system of 2007 that appears to have provided the inspiration for the RC2014. Here is the complete schematic which makes it easier to understand how the read/write control signals are generated.

The minimal Z80 circuit that provided the inspiration for the RC2014

In the next part I look at extending the system, with digital I/O and hopefully a vintage 7-segment LED numerical display.

In the first part of this series, I looked at the construction of Spencer Owen’s RC2014 – a Z80 retro computer kit. In the is post I look at some of the ways of extending the basic 5 board system.

One of the key advantages of using the backplane method of construction, is that it is very simple to extend the system with additional cards, and the user can choose which cards best suits their overall application. The system can be extended as and when time and budget permits. This was a major consideration with the early homebrew computers  – where memory was expensive and each additional kilobyte represented a substantial investment!

Digital Input and Output.

One of the primary requirements of any computer is the means to connect to other systems and exchange digital data.  This can be readily done with digital input and output ports, which are usually multiple 8-bit wide ports, each with a unique I/O address.

Whilst this can be done using the Z80 series peripheral ICs – generally DIP 40 LSI devices, the more traditional method of interfacing to a microcontroller was to use standard 7400 series TTL chips (TTL is Transistor, transistor logic). These operate with a 5V power supply and with logic levels and drive capabilities that were a good match to those of the early microprocessor ICs.

For digital input, the requirement was to capture the state of the digital input lines and transfer this captured byte onto the Z80 data bus at the right time for the input (IN) instruction. This is best done using an 8-bit tristate buffer – and the 74HC245 meets the requirements perfectly.

For digital output, the normal method is to use an 8-bit latch, such as a 74HC374, or 74HC574 (which has a more bus-friendly pinout).

Conveniently Spencer has put both of the ‘245 and ‘374 devices onto his Digital I/O card – and this is the subject of this blog post.

The Digital I/O board is a simple through hole kit

The kit is supplied with all components and all ICs are socketed – handy as it is these that form the first line of defence against the harsh realities of the real physical world.

Construction was simple, and I chose to add the sockets and switches to the board first. Unfortunately the footprint used for the switches is not quite right – and it was a bit of a fiddle to get them all neat and level.

Next I added the LEDs and the resistors….

and finally the 40 pin right angled SIL pin header strip – which is common to all boards that fit into Spencer’s Z80 backplane.

To use the GPIO board we use the INP and OUT command provided in the ROM BASIC.


This simply reads the input port at Port 0 and sends that byte out to the output port also located at Port 0.

For a more sophisticated demonstration – Spencer offers this Cylon programme:


Here the individual LEDs are lit by using increasing powers of 2 to access them one at a time.

The GPIO board is self contained and good for demonstration or simple interaction with the application using either BASIC or Z80 assembly language.

For more sophisticated control and monitoring applications – Spencer has created another couple of pcb modules  – that provide 24 lines of input, and 24 lines of output – using the same ICs as used in the GPIO demo board. These will be a useful addition to this growing Z80 system.

Input module provides 24 lines of input using three 74HC245
Output module gives 24 lines of output using three 74HC374

Spencer has now standardised on a board outline which has a sloping front corner – which makes inserting it into the blackplane the right way around – foolproof. There is also a hole that can be used to connect all of the boards together using a bolt or length of threaded studding.

The backplane connector has been shrunk to 39 pins – which allows it to fit on a 10cm wide pcb. This makes it useful for those who may wish to design additional boards or modify these – using KiCAD or EagleCAD – and take advantage of the low cost 10×10 cm board offers from certain Far East pcb manufacturers.

In the next Part we look at the Composite Video Terminal board  – which recreates a serial terminal using a Raspberry Pi Zero, – as soon as my Pi Zero arrives!

North Wales beckons – the view from Conwy Castle  27th June


In 2006 on one of my frequent trips to Shenzhen China, I met up, entirely by chance encounter with Toby Yu – a teacher of English in Chinese middle schools.

In later visits Toby acted as my interpreter and guide to the minefield of modern industrial Shenzhen.

Ten years on, Toby has had the opportunity to visit the UK, and so on June 21st – mid summer’s day – we embarked on a two week tour of the UK – visiting as many of the hacker and maker communities as we could.

The tour of the UK coincided with the UK Referendum, and it was interesting to meet new people and gauge their thoughts and feelings about the political situation. The news of the UK Brexit came on the 2nd full day of the tour, and over the next few days the UK political parties seemed to go into self-destruct mode with multiple resignations in all the major parties. The wheels were really falling off the wagon!

During the course of the tour we drove about 2200 miles and between us took about 2500 pictures.

In the next few days – some of the content highlights of these will be added to this blog.

Note – Maps & Routes are approximate – quite a lot of additional driving around either lost or sight seeing – on top of the minimum mileage suggested by the route!

A Simple Plan?

2 Guys in a Golf, 2 Weeks, 2200 Miles, 4 Countries, 2500 Photos – the #ukmegatour

Some Places En Route  – in approximate Order

Market Harborough
Blaenau Festiniog
Y Felinhelli
Parc Menai
Port Penrhyn
Newborough Sands
Menai Bridge


St. Johns
Kirk Michael
Point of Ayre


Hebden Bridge
Sowerby Bridge

Newark on Trent
Stoke Newington

Some Facts about the #ukmegatour

This is a summary and also work in progress – with regular updates.

The tour was planned and executed mostly through the medium of Twitter, with the occasional phone call, email or text message.

The tour officially ran between Thursday 23rd June and Wednesday 6th July – with a pre-amble on 21/22 June, and a post-amble to visit @NADhack in Thatcham on Thursday 7th July.

Toby arrived at Heathrow on the evening of 21st June and had 15 days in the UK before returning on the evening of July 6th.

During this time the outline plan was to meet Toby’s existing customers (Mirobot, MeArm and OpenEnergyMonitor) who are all mutual friends and also visit as many maker exhibitions, festivals and hackspaces as we could – with the intention of seeking out new business.

Toby had put together a short Powerpoint  presentation about the electronics industry in Shenzhen, and his company’s ability to source components and manufacture open source hardware products in the Shenzhen region.

The tour was split into 7 main stages:

London and South East     2 days         June 21/22
North Wales                     3 days         June 23/24/26
North West                      2 days         June 25/27
Isle of Man                      2 days         June 28/29
Central Scotland              2 days          June 30, July 1/2
Yorkshire                        1 day           July 3
London and South East    3 days         July 4/5/6

Total of 15 days with 13 nights “On the Road”

Staying at:

3 Travelodges  – Huddersfield, Cambridge, Kew   (£60, £70, £99)
1 Premier Inn  – Edinburgh Leith (£96)
1 Pub              – Victoria Inn, Haddington (£60)
1 City Hotel     – Cinnabar Cafe, (£85) Hertford, Royal Kings Arms, Lancaster (£50)
1 friend’s sofa – Stratford, London
3 friend’s houses/flats  – Hertford, Isle of Man & North Wales
1 Farmhouse    – North Wales
1 boat cabin     –  ferry to Isle of Man  (£70)

Accommodation costs in twin or family rooms varied from £50 per night (Lancaster) to £99 (Kew). I am sure these could be bettered if we had the time to do more research and seek out cheaper guest houses or hostels.

Traveled in:

1 Isle of Man Ferry (Ben my Chree)
1 Golf
1 Electric Tram
2 Park & Rides (Liverpool Wirral & Newcraighall Edinburgh)
2 Electric Cars
2 London Buses
Many London Tubes
Several friends cars

4 tanks of diesel (refilling at Chorleywood,  Port Sunlight on Wirral, Lancaster, Huddersfield)

Our route was by no means direct, and during the weekend we had in North Wales, we had a 200 mile daytrip to Liverpool to visit the Liverpool MakeFest.

In London we were based in East London, but due to evening rush hour traffic and congestion charging, our route to Kingston, Richmond and Kew was about 75 miles around the M25 via Sidcup and Redhill instead of 16 miles across congested North London.

Drove 2200 + miles

Took  2500+ photos

10 Motorways



2 Mountains – Snowdon, and Snaefell (Isle of Man)
1 Hill – Arthur’s Seat – Edinburgh


Blackpool North West Geeks
Glasgow Electron Club
Edinburgh Hack Lab
Hebden Bridge Rectifier
Richmond Maker Lab
London Hackspace
Isle of Man Fab Lab
Manchester Mad Lab

Sadly missed – due to bad timing:

Does Liverpool
Nottingham Hack Space
Cambridge MakerSpace

What We Visited:

Liverpool Make Fest
Heptonstall Festival
ElectronClub 10th Anniversary Party
PiMoroni – Sheffield

What We Eat

3 Thai meals (Hertford, Hebden Bridge)
1 Wetherspoons (Liverpool)
1 Curry (Haddington)
1 Turkish Barbeque (Hertford)
3 Homemade feasts – (Thanks Rebecca in Hertford & Clair and Amy in North Wales)
2 Beefburgers (Hertford, Market Harborough)
1 Pizza  (Mammas  – Grassmarket, Edinburgh)
5 Chinese meals (Ramsey IoM, China Town, Edinburgh x 2, Glasgow)

Best Bits

Reaching the top of Snowdon  – on a very wet Sunday
The hospitality at the small cafe – just outside Llanberis, on the walk back from Snowdon
Everybody we met – except possibly the impatient woman in Lancaster filling station

Worst Bits

Getting lost in and around Westfield complex, Stratford City for over an hour before we found the taxi rank.

Finding suitable food in Lancaster and Cambridge after 11pm.

The rude gentleman on the bicycle riding without lights at 11pm on a pavement in Cambridge who nearly killed me!

Flaky mobile phone technology – either no internet connection or dead batteries! Might as well be carrying a potato around with you!

Daily Diary Notes

June 21st Redhill, Heathrow, Hertford  74.2 miles

Tuesday 21st June   – Arrival & Hertford

Met Toby at Heathrow 7pm.   Drove around M25 to Hertford where we had a Turkish Barbeque meal with Ben Pirt of Mirobot and my wife, Elaine. Stayed at Cinnabar Cafe in Hertford High Street.

Wednesday 22nd June 

Toby had a day visiting Ben Pirt (Mirobot) in Hertford, and a chance to see his workshop.

I took a day off work, did a bit of clothes & shoe shopping in Redhill and generally got packed and ready for the main part of the tour.

23rd June Hertford – Market Harborough, Nottingham, Derby, Congleton, Conwy, Llanfrothen 302 miles

Thursday 23rd June – Referendum Day – the Road to North Wales

An early – and wet start so voted in Redhill as soon as the Polling Station opened.

Travelled up via M25 and M40, through Northhampton to Market Harborough.

Lunch with Toby, Ben Pirt and Ben Gray of MeeArm.

Continued after lunch through and around Leicester and Loughborough to Beeston Nottingham – where we picked up an old 25 year old Apple Mac II Classic.

From Nottingham, drove through Derby and through the Derbyshire Dales across to Congleton, Chester and along the North Wales Coast road. Turning south at Conwy, arrived at Trystan Lea’s home in Llanfrothen at around 21:30.

Claire cooked a wonderful meal of Tofu & vegetable stirfry with rice.

Retired around midnight after a very long day.

Friday 24th June.  North Wales Tour Day!

June 24th Llanfrothen, Beddgelert, LLanberis, Parc Menai, Llanfair PG, Newborough Sands, Menai Bridge, Bangor, Penrhyn Castle, Y Felinhelli, Brynefail, Llanfrothen  95 miles

Beddgelert with Claire and Trystan, then on to the Megni offices at Plas Menai – where we met up with  Glyn Hudson and Gwillam for lunch at the local cafe.

Toured Anglessey in afternoon visiting Newborough Warren, Menai Bridge, Penrhyn Castle and Bangor. A swift beer at the Menai Vaults by Bangor pier.

Returned to Plas Menai to collect the rest of the group – beers in the evening sunshine at Y Felinhelli (Port Dinorwic) overlooking the Menai Straits.

Quick trip inland to Llanberis – meeting around 7:30pm with Amy and Glyn for Pizza and Pint. Toby stays the night with Glyn and Amy in Llanberis whilst I drive Trystan and Claire back to Llanfrothen.

Saturday June 25th – Daytrip to Liverpool for Liverpool MakeFest  202 Miles plus Park & Ride

Saturday 25th June.  Liverpool MakeFest!

Early start to pick up Toby from Brynrefail and then drive the A55 coast road to the Wirral. Get a Park and Ride train from Hooton into Liverpool Limestreet, to visit the Liverpool MakerFest.

Meet up with Spencer Owen from Nottinghack,  Jenifer & patrick from doesLiverpool, Dominic from Nottinghack, Cefyn from Shrimp-It. Aaran Neilsen from Oomlout, Ben Gray, and Les Pounder. Fix up to meet for burgers in Blackpool for Monday night with Les P.

Return to Hooton and drive back to LLanfrothen, meeting up with Glyn at Y Ring Pub.  Meetup with Glyn’s parents and sister – at their place – see the friendly sheep & bees.  Return to Y Ring with Glyn’s family for evening meal – very busy and noisy as Wales win the football match!

Joined by Trystan for a few more beers then return to Orogonwy.

Sunday 26th June – The Ascent of Snowdon!

Drive across to Brynrefail to meet with Glyn and Amy. Drive to Pen Y Pass and climb Snowdon by the Pyg Track and ridge.  Get very wet – but stop for hot pasties at the summit cafe.  Return to Llanberis via the little cafe – Glyn has a hot foot spa – coal fire burning – good local beer.

Take the tour of the Dinorwig Pump Stroage Powerstation “Electric Mountain” – very interesting. See the huge cavern with the turbine hall – 1 mile under the mountain.

Return to Glyn and Amys for hot show and supper with Gwil & Trystan.  Toby gets a ride back to Llanfrothen with Trystan in his electric Nissan Leaf – whilst I take the Golf.

June 27 Llanfrothen, Conwy, Liverpool, Manchester, Blackpool, Heysham – Douglas, Isle of Man 206 miles

Monday 27th June.

Early start from Llanfrothen and spend an hour looking around Conwy Castle. Cream scones & jam with coffe from castle cafe for breakfast. Drive the A55 back towards the Wirral and on into Liverpool via the Mersey Tunnel.  Park at the Cathedral and have a look around the University.  – Toby meets a Chinese post-grad student.

Lunch (curry) at Wetherspoons close to Lime Street.

Back up to the car and head across to Manchester to visit Mad-Lab.

If it’s June 27th then This is Manchester – and we are lost!
Blackpool’s version of SpaceX

Get lost in Manchester because of changed road system and almost useless sat nav!

Blackpool’s version of “London Eye” June 27th

Leave Manchester and head for Blackpool – where we meet up with Les Pounder and friends from the North West maker community at the West Coast Rock Cafe for burgers and beers.

Good meal and group discussion until about 10:30pm when we leave and go across country (sat nav was set to avoid motorways) to Heysham Docks to catch the night boat to the Isle of Man!

Heysham, Lancs to Douglas, Isle of Man – 4 hours by overnight ferry “Ben My Chree” 65 nautical Miles!

Tuesday 28th June – En Route to Isle of Man!

June 27th Douglas, Ramsey, Laxey, Snaefell, Onchan, Douglas, Ballasalla, Kirk Michael, Ramsey 75 miles

Up until 2am waiting to embark onto Ben my Chree ferry. Have a cabin and get a few hours sleep. Lovely sunrise in the Irish seat around 5am.

Arrive Douglas around 06:15 and find early morning cafe for breakfast. Have a walk along Douglas seafront Gaiety Theatre and Villa Marina. Starts to rain – so head back to meet my sister Alison at the Sea Terminal at 08:00. Alison hand over the car and we drop her off at Manx Telecom.

Head across mountain road north towards Ramsey.  Shower and shave at Alison’s then off up to meet Dad. Arrange to meet Dad for lunch the following day.

Head into Laxey, quick half of Okells at much declined “Mines Tavern” – have lunch at stupidly pretentious French Cafe – where they seem to be in a humourless grump – possibly due to Brexit?

Take electric tram to the summit of Snaefell – and have a quick beer at the top. Cold & wet so take the same tram down after 30 minutes.  Visit Laxey wheel and then head down to the south of the Island passing via Castletown to see the Sound, Cregneish and the Chasms. Have a 3 mile walk around the chasms – glorious evening as sun finally emerged around 4pm.

Back up to Ramsey for Chinese meal with Alison & Tony – drinks in the Swan in Parliament Square – and a walk back to Alison’s – including a chance encounter with a hedgehog in one of the alleyways.

Wednesday 29th June – Second full day on Isle of Man

June 29th – Ramsey, Point of Ayre, Andreas, Kirk Michael, Peel, St Johns, Foxdale, Castletown, Cregneish 75 miles

Meet up with Mike Spooner for coffee in market square at 10am. Off to pick up Dad and lunch at the Grosvenor – Andreas at 12 noon. Lousy weather – so a quick look at the Point of Ayre.  Good lunch.  Returned Dad home.

Drive dow to Peel for a quick nosey around Fenella Beach, Harbour and Peel Castle.  Quick stop at St. Johns and Tynwals Hill, then south through Ballasalla to meet Owen at the MICTA building across from Ronaldsway Airport.

Ownen showed us around the 1000m2 redundant factory that will become the new Isle of Man Hackspace and FabLab – very impressive and so much potential – due to large size.  A geographic central hub for UK and Ireland?

Back to Tromode to meet Alison and Tony for a quick Chow Mein at the Horse and plogh Pub – before returning to the Sea Terminal for the evening boat back to Heysham.

Arrived Lancaster around midnight – stayed at the Royal kings Arms Hotel.  Very spicy chicken kebab, as a late supper.  Toby did not enjoy Lancaster after midnight.

June 30th Heysham, Lancaster, Carlisle, Biggar, Edinburgh, Leith, Haddington 202 Miles

Thursday 30th June.  – The Road to Scotland!

Up with the larks – for starting our drive up to Edinburgh. Managed to forget which street I parked the car – and took 15 minutes to find it – this was going to become a feature of the road trip…..

Filled up with diesel in Lancaster just before the M^.  Drove up to Carlisle and had an hour’s break at the Tesco in Carlisle to use WiFi (Toby’s business connections) top up with coffee and use the loos.

Turned off at the A702 Biggar road and briefly called in at Betty Grays – before getting a snack in Biggar and a quick half at the pub in the main street.

Another 30 minutes and we were rolling into the south side of Edinburgh.  Quick road tour of the soouth side and parked up in Buccleuch Place. Found a really good Noodle Shop run by a guy from Beijing – Toby really enjoyed his noodles.

Quick walk down to Summerhall to meet up with some people at the EdinHacklab. Tea and chat then off up Arthur’s Seat before the rain threatened.

Good view from Arthur’s Seat – then back via Leith Premier Inn to arrange hotel for Friday night.

Back along the old “A1” – now the A199 through Musselburgh, Tranent, Macmerry and into Haddington – where we checked in at the Victoria Inn.

The pub at the end of my old street in Haddington, June 30th

Had a couple of good beers  – then a walk around Haddington – to see some of my old haunts and childhood memories – around the River Tyne.

Evening meal was a curry at the Easter Eye next to the old Laidlaw’s bakery. Very good.

Friday 1st July.

Walk around Haddington with breakfast from the Baynes Bakery – eaten on a park bench by the Nungate Bridge. A look around the Old St Mary’s Church, the Butts and the town. Left around 10am along the Pencaitland road – Samuelston – Humbie where we called in on some old farming friends friends from 40 years ago. Tea with the Marcshalls in their sunlounge – little change to Highlea in 40 years – just as I remember it.

From Humbie – back in along A68 and Dalkeith bypass to Park and Ride at NewCraigHall. Into Waverly for 1pm.  Up Fleshmarket Close and Cockburn Street and down the South Bridge – heading for Summerhall Meetup with Mark Nicol, Jo and friends.  Sat outside Summerhall bar until the heavens opened – retired indoors and had a good chat with the Edinhack Crew.

More noodles in Buccleuch St, then a walking tour of the Meadows, Doctors Pub, Heriots, Vennel, Grassmarket, Castle Hill, Royal Mile, St Giles, Tron Kirk, Cowgate and back through the Grassmarket to meet up at Beehive for beers at 6pm.

Sat outside Beehive – dodging the showers – met up with Evan Tuer and Alan Masson. Headed next door for Pizzas at Mammas.

Evan offered us a lift back to Newcraighall Park & Ride in his electric car – but we had to find it first – 45 minute hike around West End (Rothesay Terrace) looking for where he left it.

Back from Newcraighall to Leith Premier Inn.  Checkin – then quick beer at the Harbour Inn – where live band with saxaphone was playing 60’s dance music. Toby tired.

Saturday 2nd July

July 2nd Leith, Glasgow, Carlisle, Preston, Burnley, Heptonstall, Hebden Bridge, Huddersfield. 286 miles

Left Leith with trip through Granton towards South Queensferry to pick up start of M8 to Glasgow. Raining persistently by now all the way into Glasgow.

Orange Day Parade – so centre of Glasgow blocked off with Police Helicopter hovering overhead. Parked up in central area of Sauchihall Street and headed to the ElectronClub at the CCA building. 2 hours of discussing, presentations and lightening talks as they were celebrating their 10th anniversary. Toby gave his guide to electronics in Shenzhen presentation to about 20 members.

Last souvenir hun in Sauchiehall St, and visited a Chinese buffet restaurant – – stuffed on noodles before 4 hour journey south down the M74, M6, M65 to Hebden Bridge.

Arrived in Heptonstall to the sound of loud music from a local band Maia – around 8pm.  A couple of beers at the White Lion with Andrew Back and Shaun – and then down the hill into Hebden for a Thai meal near the canal.

Drive back to Huddersfield and check into Travelodge.

Sunday 3rd July

Up at 6am to take some photos at first light – sunshine start to day.

Coffee at the local drive – thru Costa – and 90 minutes to type up the first draft of this blog – photos to be added later.

Tody we go back to Hebden Bridge to meet with some of the Hebden Bridge Rectifier (hackspace) members.

Walk along the canal, watch the boats going through the locks

Lunch at Heptonstall Cafe with Andrew Back.

Toby returns to Bridge Rectifier and Andrew videos his presentation. I have a sniff around the various stalls at the Hebble End Mill.

We then set off, south through, Sowerby Bridge and Huddersfield to Sheffield, where we had arranged to meet the team from PiMoroni at 6pm, for a beer. Then it was south down to Cambridge for what was to be the last stage of the tour – Cambridge, London, Richmond.

Sunday 3rd July – Evening drive from Sheffield to Cambridge 155 miles
The PiMoroni Guys and Richard Oliver in Sheffield  – July 3rd

Then on to Sheffield to meet Pimoroni and Richard before heading south around 8pm to Cambridge – for a look around University and possibly Cam Makespace on Monday.

Monday 4th July

Punts on the Cam at the Back of Clare College – Cambridge July 4th

Early start and a chance to do the Cambridge tourist thing for a couple of hours in the morning. We met Alice – a vacation student and college guide at Clare College, studying Economics and Chinese studies at Nottingham. – and she was keen to practice her Mandarin on Toby.

Cambridge to Hackney – with lunch stop in Hertford  58 miles

Met up with Ben Pirt in Hertford for another Thai Lunch and then the final haul down the A10 to Hackney and the London Hackspace – which will be our London working/sightseeing base for the next 2 days.

Toby catches up with some online activities – London Hackspace July 4th 
The Rear Yard at London Hackspace  – July 4th

After the London Hackspace we traveled by tube into St. Pauls to see the Cathedral and then crossed the river by the Millenium Bridge, to have a look at the Globe Theatre.

Beers at Borough Market and a quick look at the George in Borough High Street – the last remaining galleried inn.

Traveling to Leicester Square – we visited the Lamb and Flag – and met some folks from Northern California, who were in good spirits on their Independence Day.

The Lamb & Flag – well hidden, but well worth it!

Then it was across into China Town – for a real Chinese meal – and an opportunity for Toby to meet some of his countryfolk.

The journey back to Stratford started well, but rapidly deteriorated as we became increasingly lost and disorientated by the neww Westfield complex at Stratford City. After an hour of wandering, and the time approaching midnight we eventually managed to hail a black cab and get a ride the mile or so back to where we were staying in the older part of Stratford – West Ham Lane.

Stratford Town – Map does not do justice to the insanity that is Stratford City!

Tuesday 5th July

Overnight stay – courtesy of Billy Smith, in Stratford, East London.

Purchased Oyster cards and rode No 25 bus all the way into Oxford Street.

Walked up Regent Street where we saw the National Union of Teacher’s protest march.

Took tube to Embankment and walked towards Westminster passed the London Eye and old County Hall. Big Ben, Houses of Parliament.

Tube up to St Pancras where we met Damon for lunch at the 101 Euston Road – Digital Catapault.

Walked to British Museum and saw their exhibition of Chinese ceramics. Toby tried to photograph everything! – till his phone battery ran out!

Tube back to London Hackspace to pick up the car

Hackney to Kingston, Richmond & Kew – via the Scenic Route!  73 miles

Drive out via Blackwall Tunnel, A20, M25 to Kingston and on to Richmond Maker Labs – 2 hours in rush hour.

Meetup with Richmond Maker Labs – I did Toby’s presentation about Shenzhen.

Chinese Meal in Twickenham with Debbie & Jason

Checked into another Travelodge – Kew – right by the River Thames – and easy walking distance from Kew Bridge Steam Museum

Wednesday 6th July

Early start on another beautiful July morning – at Kew Travelodge. Recharging phones and laptops.

Catching up with blogposts and downloading photos.

Go to Riverside Cafe for breakfast, bacon roll and half of Toby’s sausage egg & chips. No WiFi – owner thinks we have landed from another planet.

Have Argentinian Pasties for lunch – at little shop just behind the main street. Everything in Richmond is over-expensive and totally pretentious.  See a house to rent that is £13,500 a month!

Meet up with Steve just off Richmond Green for an hour.  Retrieve car from station carpark – £6.80 for 3 hours (£2.90 for first hour).

older | 1 | …. | 7 | 8 | 9 | (Page 10) | 11 | 12 | newer

Posted in Uncategorized | Leave a comment

The Lost Blog

Unfortunately in July 2016 some posts were deleted from my blog “Sustainable Suburbia”

This is a partial restoration of those missing posts. There will be more to follow.

This week I have been working on various MSP430 projects including a prototype board based on the MSP430FR2433.

This is a very small chip in a 4mm square package – which doesn’t make it really easy to work with – so I decided to design a series of small boards to take full advantage of its diminutive package size.

Today I have been laying out possibly what is the smallest board I have done so far – just 10.24mm x 12.7mm.  Remarkably this includes the breakout for the MSP430FR2433 plus an external SPI memory device.

Nanode 2016  – Just 0.4 x 0.5″

As you can see, things are fairly compact on this board, and I have had to use 0402 resistors and capacitors -the layout was  surprisingly  easy for a board of this density. All of the components are on the top side – except for an optional additional memory device and an extra decoupling capacitor.

Despite it’s small footprint, this is a full microcomputer with up to 256K bytes of external memory.  It has 3 communications interfaces which can include up to 2 UARTS and up to 3 SPI ports.

If you are using it with a serial terminal, with one UART dedicated to that purpose,  there are a further 14 GPIO lines available – 6 of which have a 10 bit ADC function.

The board is designed to take external memory – which may be either SRAM or FRAM, or a mix of each. If FRAM is used, then the device will retain the contents even after power down.

This module has been designed as a building block, primarily to be used to interface with SPI based peripheral devices – or where space is too tight for even an Arduino Nano.

0 0

WiNode Lives!

After a weekend of hard graft, I have some samples of the WiNode 5 board in various states of build – with three of them up and running code.

I also built up one of my FT812 “EVITA” video boards so that I could try it out with WiNode:

All in a Weekend’s Work when the day job doesn’t get in the way!

WiNode – The Core of  a Neo-Retro Computer Project!

Since it’s beginnings in early December, the project for this year is a Neo-Retro computing platform. It was just a case of identifying the right hardware and getting on and making the pcbs.

The platform has it’s heritage in Arduino – hence originally the use of an ATmega1284 microcontroller, the Arduino style headers and the stackable shields.

However a new MSP430 FRAM based microcontroller core that plugs right into the central 40 pin DIL socket is under construction – and is likely to become the preferred processor.

The fact is that we have a complete 8-bit computer with high-res colour graphics, PS/2 keyboard and mouse shoe horned into something about the size of a fag-packet. The bulkiest part of this design is the VGA connector and cable!

This is most definitely not a Raspberry Pi, nor any thing similar.  It is a working 8-bit (or 16 bit) computing platform made from about £20 ($30) of components.

 “Hello world” WiNode 5 and EVITA stacked together

It does not run Linux, nor does it need megabytes of someone else’s firmware to make it run. It’s just a simple platform with which to experiment

Brief Summary:

On the EVITA GPU shield

PS/2 Keyboard
PS/2 Mouse
FT812  (Gameduino 2)

On WiNode 5

RFM69 Wireless Module
FM25W256-G  32K x 8bit SPI FRAM
micro SD card
ESP-01 WiFi

In this short series of posts, I have looked at alternative processors to the ATmega1284 for my “Neo-Retro” Computing platform – based on my WiNode 5 and EVITA board stack.

WiNode 5 – shown below, has a 40 pin DIL socket located in the centre of the pcb. The position of the signal pins on this socket are arranged so as to accommodate a Atmel ATmega1284 – as this is a commonly available, reasonably low cost AVR device with 128Kbytes of Flash and 16Kbytes of RAM. It also has the added advantage of two uarts, SPI, I2C and 3 interrupt lines – making it kind of a “super-Arduino”.
WiiNode 5 with ATmega1284 40 pin DIL version fitted
However the socket was not solely intended for the ATmega1284.  It is for generic access to the hardware on the WiNode board – and so any microcontroller, fitted to a suitable 40 pin carrier board, may be fitted in this position.

Recently, in this Blog, I explained how the 40 pin DIL package was a neat way of packaging up some of the smaller microcontrollers, so a s to make them more manageable in the form of a plug in module – that does not require difficult SMT soldering.  This time I take a closer look at the 40 pin format – and show how it can be used to our benefit, for a number of different applications.

As a teenager, growing up in the very early 1980s, the 40 pin DIL was the only format that microprocessors came in.  It was a convenient size that could carry a 16 bit address bus, an 8 bit data bus, a few control lines and power. Some manufacturers even copied the pin-out of their competitors’ devices – so that they could swap their devices for their superior device – although this practice usually ended in law suits.  However, it’s not a bad idea to have a common footprint amongst devices – making the upgrade path very simple.

So with this in mind I have decided to do something similar, and make a series of compatible modules that allow the user to move conveniently between processor families.

A Common Template for a Microcontroller Plug-In

Making a plug-in module is a fairly trivial process – it’s just a  small piece of pcb with a standard pinout, which acts as a chip carrier for whatever devices are needed in the design. I did this a couple of years ago with my STM32F373 based ARMiGo project.First we look at the template for the proposed module.  You will recall that the ATmega1284 is available as a DIL 40 package – and its arrangement of ports allows form a very logical layout with power pins at the centre – which prevents disasters, should you happen to get the IC into the socket the wrong way around! So by the miracles of ASCII-Art in plain courier font we have the package template.

                    ATmega1284 Package
                               B0 |o 1            o| A0   A   I
                               B1 |o              o| A1   n   n
          INT2  B2 |o              o| A2   a   p
          PWM0A B3 |o              o| A3   l   u
          PWM0B B4 |o              o| A4   o   t
          MOSI  B5 |o              o| A5   g   s
          MISO  B6 |o              o| A6   u
          SCK   B7 |o              o| A7   e
            /RESET |o              o| AREF
              VCC  |o              o| GND
              GND  |o              o| AVCC
             XTAL2 |o              o| C7 
             XTAL1 |o              o| C6
           RXD1 D0 |o              o| C5
           TXD1 D1 |o              o| C4
           RXD2 D2 |o              o| C3
           TXD2 D3 |o              o| C2
          PWM1A D4 |o              o| C1  SDA
          PWM1B D5 |o              o| C0  SCL
          PWM2A D6 |o              o| D7  PWM2B
Note that the power pins are in the centre of the package and offset – so cannot be reversed accidentally. Additionally the ports A,B,C,D are neatly stowed in a way that makes navigating around the pinout very easy – it’s all done for maximum simplicity.

I have also labelled the key signals – so when it comes to layout the new processor module – it’s a case of matching up function on a pin by pin basis.

With  the template for the package in place, it is now possible to lay-out any small processor in this format.
My interest lies in two (or possibly three) candidates.   Firstly the 38 pin TSSOP MSP430FR5759 secondly the 48 pin LQFP STM32Fxxx ARM M4 Cortex device. Both of these will be capable of a significant improvement in processing throughput over the original ATmega1284.

An MSP430 FRAM Variant for WiNode 5

Last week, whilst waiting for some pcbs to come back from manufacture I had a quick look at the MSP430 range of microcontrollers – especially those in the MSP430FR5xxx series which have non-volatile ferroelectric memory.

This time I look at some of the more practical aspects of using these interesting SMT devices.

These are available in a relatively easy to use 38 pin TSSOP package, so the plan was to make a neat little TSSOP to 40 pin DIL adaptor board – so that they may be used with breadboards and stripboards.

After a little thought, and a few hour’s with EagleCAD, I came up with the following layout.  The device is uncluttered – for once, I am not trying to squeeze every last component onto a small board.

The board carries the MCU, and external SPI memory device, a 32kHz crystal,  Reset Button, User Button and a LED. In addition there is an external SPI memory device  – which can be FRAM (up to 256Kbytes) or SRAM (up to 128Kbytes).

A simple 40 Pin DIL Breakout Module for the MSP430FR5739 and MSP430FR59xx devices

0 0

A previously unpublished posting from February 9th that has launched me on a wonderful voyage of discovery of the MSP430 series of microcontrollers.

As Kennedy said in September 1962…

We choose to go to the Moon! 

We choose to go to the Moon in this decade and do the other things, not because they are easy, but because they are hard; because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one we intend to win …

But first we need a working Rocket!

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 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 really suck.  There should be a 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.

0 0

Mad as a March Hardware Engineer

We are almost 3 weeks into March, and already it has been a very busy month in terms of both hardware and software developments.


This month I have been getting to know the MSP430,  having previously worked with Atmel AVR and ARM devices. There’s no better way than to create your own dev board.

In relative benchmark tests, the 16 bit MSP430 is capable of about 2 to 3 times the processing throughput of the AVR,  but about half the thoughput of the ARM Cortex M0/M0+. On average the codesize for the MSP430 is about 70% of that used by the AVR.

Whilst I could have used ARM devices for the application, I already have the existing instrument code, and I suspect that it is easier to enhance the current code of the existing target, than port it to a new processor family.

However, what sealed the deal for me was that some devices in the MSP430 series have multiple 24bit Sigma Delta ADCs (intended for 3 phase electricity metering applications), plus there are parts with low power, non-volatile ferro-electric memory (FRAM) and segment style display drivers.

In the 10 years or so since the current instrument was designed, the active mode power consumption for the MSP430 has better than halved from about 280uA/MHz to 126uA/MHz. This will all help to prolong battery life, and possible reduce the number of batteries required.

Having decided to use the MSP430, I needed a crash course in how to use it – so about a month ago, I bought a few of the newer LaunchPad dev boards one featuring the MSP430FR4133 device with 6 digit segment-LCD, another with the MSP430FR5739 and a third with the MSP430FR5969 – which allows the active current consumption to be monitored. My two blogposts of February 17th describe these boards. I was also spurred on when I found that Jean-Michel Thoorens had written a “Fast Forth”for the MSP430FR5969. This I had to try.

In order to get started with the MSP430 series I downloaded the Code Composer Studio tools and tried a few example programs to familiarise myself with the peripherals. After getting the Blinky LED to flash, the next stage was UART send and receive to a terminal followed by ADC readings.

In order to set up with the  MSP430, I had to get the uart BootStrapLoader (BSL) to work. This was the first challenge , in moving to the new processor.   My blogpost of 26th February describes some of the difficulties I had.

With the BSL fully working I then started to look seriously at the MSP430 using the G2 Launchpad I was given free at the San Mateo Maker Faire in May of 2012.

My first task was to retrace my steps from a couple of years ago when I got my first MSP430 Launchpad and  tried porting my SIMPL tiny interpreted language to it using Energia – an Arduino-like IDE – but for the MSP430.  The exercise was a success, but as the MSP430G2553 only had 256 bytes of RAM, I was not going to be able to write a lot of code before the RAM was full.  In the blogpost of March 3rd – I look at the G2 Launchpad and both the MSP430GR2533 device and the MSP430F2013 device which has the advantage of a 16 bit SD ADC.

I studied the ‘2013’s 16 bit SD ADC – as this was possibly going to be required in the final build. I also found some very useful helper functions for the ‘2013 called  “MSPEZIO” written by the University of East Carolina’s Physics Department. I also explored the Universal Serial Interface (USI)on the ‘2013 – which is great if you want to send serial ay 16MHz!  My blog entry of March 4th looks at these topics.

However it was the shortage of RAM, again on the ‘2013 device that encouraged me to look for alternatives.  About that time I came across Rick Kimball’s code for using the 23K256 SPI SRAM device on the USI.  I got his USI code running with a 23K256 and then modified the code so that it would work on the more modern Universal Serial Communications Inteface or UCSI – of which most Modern MSP430 devices have two or three.  My blogpost of March 5th describes these developments.

So one week after getting through the Bootloading Blues, I had serial comms, SPI and external SPI memory working. It was time to set about the challenge of putting this all together as an application.

For this I dusted down my SIMPL language and spent a Sunday afternoon and evening writing some code. The extended SIMPL was then christened SIMPLEX, and features in the two part blogposts from March 6th. It hard to believe that that was only 2 weeks ago. I now had a virtual machine running on the MSP430G2553 Launchpad which could execute code out of external SPI RAM – plus a bunch of other useful functions including a hex-dump facility.

Around about this time, my MSP430FR4133 Launchpads arrived – so I spent an afternoon porting SIMPLEX from the ‘2553 across to the more spacious ‘4133. This is covered in my blogpost of March 9th.

In Summary this post has covered the following  posts from between February 9th and March 9th

Bootloading Blues
The Great MSP430 Bootloader Swindle
More MSP430 Machinations
MSP430 Serial Communications
Interfacing SPI RAM and FRAM to the MSP430
SIMPL Meet SIMPLEX – Part 1 Putting it all together
SIMPL Meet SIMPLEX – Part 2 Running SIMPL code out of External RAM
Porting SIMPL Code to the MSP430FR4133 LaunchPad

The next summary post will feature the remainder of the Mad March MSP430 machinations, including some new hardware developments.

0 0

This is the second summary post for my weekly MSP430 activities.

I am at that age where if I don’t write something down, I will forget it… and if I do write something down, I will forget it in about 2 weeks…….

In this post we cover the various hardware developments that have been made over the last few days.

ChipStick – a diminutive dev-board  March 13th

The “$5 Forth Computer” March 15th

Building a $5 Forth Computer  – First Steps   March 18th

Digital Dust – A Further Venture into Nano-Computing March 19th

Experimenting with New Devices – Part 3 “The FramStick” March 20th

Last week, I wrote about the $5 Forth Computer, and showed an early breadboard version using an MSP430FR2433 mounted on a prototyping adaptor and plugged into a breadboard.

Well, I am pleased to report that the batch of 20 prototype pcbs have arrived back from the manufacturer earlier today and the build of the first unit is underway.

The following pictures show the build sequence – starting from the bare pcb

Top side of unpopulated ChipStick board – millimetre scale!
Underside of ChipStick pcb with locations for SRAM and USB converter IC
ChipStick with USB connector, regulator and MCU added

The ChipStick design has the following features:

  1. MSP430FR2433 with 15.5K FRAM and 4K SRAM
  2. External SRAM or FRAM device connected via SPI on USCI B0
  3. CH340G USB to serial converter IC on detachable section of board
  4. 3V3 voltage regulator
  5. Reset Switch and User LED
  6. 20 Pin DIL footprint to allow insertion into G2 Launchpad socket.
  7. Programmable by SBW or BSL
ChipStick – code loaded and Flashing LED (before sunrise)

Next Time:

Fast Forth – by Jean-Michel Thoorens

This is an implementation of a Direct Threaded Code Forth, written in MSP430 assembly language.  It communicates with a terminal program TeraTerm, at 921600 baud.

I have it running on an MSP430FR5739 – can I port it to the ‘2433 on te ChipStick?

0 0


ChipStick is a tiny 16 bit microcomputer attached to a PC via a USB cable. It comes with up to 256K bytes of non-volatile memory – uniquely using ferro-electric memory.

It has up to 16 accessible GPIO lines – which include a mix of SPI, I2C, UART, Timer and ADC channels.

ChipStick may be plugged into a breadboard or stripboard and act as an intelligent programmable controller interfacing with other circuitry.

ChipStick can also act as a Digital Debug Tool (DDT), with jumper wire attached, – used to debug/develop low voltage (3V3) target hardware.

In each case, the extendable Scripting Language SIMPLEX may be tailored to the exact requirements of the user’ application.

ChipStick is based on non-volatile ferroelectric technology.  This means that your applications and any recorded data remain in memory even after power down.

ChipStick may be extended in hardware to meet the requirements of the application – this is planned through both a series of larger expansion boards (based on low cost 50x50mm format) and stackable micro-modules that match the DIL 20 socket format.


With these primary applications in mind, ChipStick has been designed to be as versatile as possible – within the constraints of the small footprint.

As a debug tool, it is no bigger than a USB Stick – easily carrier around with essential hacking tools.

I have designed it as a socketable component that can easily be added to a board – where a small amount of intelligence is required, or for bridging between sensor devices. It can also collect or send data to SPI devices and bridge that back to the PC via the UART channel.

Equally, it could be used as a small test equipment device to exercise, monitor or control prototype hardware – it has 16 GPIO lines – including two full SPI ports. These can be attached to the target hardware, and using the SIMPLEX scripting language, the various target hardware can be exercised and data reported back to the PC.

With the right SIMPLEX script, it can be used to transfer a hex, bin or ascii file from the PC to the target under development.

The external memory may be used for sensing and datalogging applications, capturing waveforms, playing back arbitrary waveforms – as a signal generator.  The ADC channels may be used as a low bandwidth oscilloscope, test meter or for monitoring changing physical quantities in science experiments.

ChipStick takes much advantage from the trend in modern sensors and peripherals to connect via the SPI or I2C bus. The MSP430FR2433 device provides up to 3 separate SPI buses.

ChipStick can be interfaced to Wirelss and WiFi modules such as the RFM69 and the low cost ESP-01.

Suitable sensors include accelerometers, gyroscopes, digital compass, temperature, pressure, loadcells etc.

For basic GPIO operations – common shift registers may be used with the SPI bus such as the 74HC595 for 8-bits output – for driving LED arrays, the high power TPIC6B595 for driving stepper motors, and the 74HC165 for 8-bit inputs.

Using a LED driver IC – such as the MAX7219 or AS1100 series – up to 8 digits or an 8×8 array of LEDs may be driven from the SPI port.

OLED and LCD graphics displays may also be driven from SPI  with a couple of control signals.

Educational Applications

ChipStick as been designed with education and experimentation in mind.

It can be used specifically to assist in the teaching of electronics, computer science and interactive coding.

It is versatile enough to meet the needs of high-school and university undergraduates, plus simple enough meet the requirements of the maker and hacker community.

The small size of ChipStick allows it to be used to give intelligence and connectivity in situations where other technology is just too bulky to fit – with the programmer section detached it is only 26.5 x 11mm – small enough to fit inside a 4×2 Lego block!

It’s low cost means that it can deployed in areas where other solutions might prove too expensive.

Here are a few of the educational applications:

Teaching Forth.

Forth is an interactive language and can be best taught with hardware that creates a stimulating interactive environment.  This includes the use of LEDs, sound, touch and movement (such as stepper motors and servos).

The MSP430 is a good fit for a “traditional” Forth machine – with 16 bit Von Neuman architecture.

MSP430FR2433 with 16K FRAM and 4K RAM is reminiscent of the early minicomputers that Charles Moore would have first coded Forth onto in the late 1960s.

I have added the external SPI memory – specifically so that users can experiment and learn about interpreted languages running on virtual machines. OK – single byte access to external RAM takes approx 30uS – but block access is 3uS per byte. ChipStick will come with a 128Kx8 external SRAM 23LC1024, or FRAM to special order.

The SPI buses on the MSP430FR2433 allow expansion hardware like sensors and shift registers, LED & graphic display drivers etc to easily be added – with minimum of wiring.

Teaching Coding

ChipStick is not limited to Forth  – it is easily programmed in C with CCS or Energia, BASIC or in native MSP430 assembly language.

Teaching Digital Electronics

ChipStick can animate electronics in a low cost way not previously possible.  With a breadboard and a few LEDs and switches, ChipStick can form the central controller of many digital projects.

It’s ability to easily interface to displays, sensors and actuators allows it to make projects exciting.

ChipStick can also be used to exercise digital electronics, and report results back to a PC for display on a graphical user interface. In teaching environments where real hardware may not be possible or practical – ChipStick can use virtual hardware and achieve most of the same educational aims.

Making & Hacking

As a result of it’s low cost, ChipStick can be used in projects where other solutions may seem over expensive. Projects no longer need to be stripped down, to salvage the $20 Arduino for another purpose.  ChipSticks will be supplied in multi-packs at very low prices – so that the cost of the device is no longer seen to be a barrier to creativity.

ChipStick is compatibe with Energia – an “Arduino Like” IDE. This allows an easy transition to the new device from familiar territory.

0 0
Has our coding efficiency evolved much in 70 years?

When Charles H. Moore began developing a set of tools to allow him to write programs more efficiently in the 1960s, computers were rare beasts, and punched cards and paper tape were the main ways to transfer code around. It was not until the late 1960’s when “glass teletypes” – or CRT terminals began to appear.  Hardware was primitive but expensive, computer resources were minimal and costly and yet with a bit of ingenuity a huge amount was achieved with so little.

Fast forward 50 years to the current day where there are several times more ARM chips on the planet than humans, and $1 buys a fair amount of hardware.  Our technological advances have achieved orders of magnitude more speed and capability, than those early machines – driven primarily by the latest fads and fashions. Yet somehow we seem to reached a plateau in how efficiently we can interact with computer based tools, and the effectiveness at which we can create code to solve problems.

When Moore created Forth in the late 1960’s we did not have GHz multicore processors,  gigabytes of fast RAM, HD Touchscreens, Linux or wireless connected mice. Surely it must be possible to leverage off all of these developments to make the whole process of writing code, faster, cheaper, easier and less prone to bugs.  These are the same goals Moore aspired for – almost half a century ago.

There has never been a better time to revisit Forth. Hardware has become so cheap and readily available and there are several free to use, open source Forth implementations available for the most common microprocessor targets.

Those of you who read tech-blogs will know that Jean Claude Wippler of Jeelabs, is forging ahead with a major new home automation project, and Forth running on ARM Cortex platforms will be at the heart of it. Jean Claude is cleverly introducing us to the tools before he starts the main body of work.

As ARM Cortex chips are a major part of  my day job, I am following JCW’s adventure closely. I am not a naturally strong C programmer, and so when I dabble in C, it feels like I am swimming against a strong tide – a lot of thrashing about, but generally getting nowhere fast.

With Forth, I see a kind of low friction, digital grease – that lubricates the wheels of machine interaction and allows complex problems to be solved faster and with less pain.

Forth is a low overhead language in terms of memory and machine resources.  As such it has the capability of high speed operation, especially when performing tasks that are easily done with integer maths. It can be ported onto virtually any microcontroller, and there is certainly a resurgence of interest in machines that are specifically designed to have instructions sets that execute Forth extremely efficiently. This is quite a departure from traditional thinking where machine architectures have evolved specifically in order to execute C-code efficiently.

I am in the process of developing a modest sized piece of software for instrument control – and it currently runs to just under 4000 lines of C.  It has been written as 9 or 10 discrete modules covering the lower level aspects of instrument control.  On top of these foundations will be a higher level of code, mostly concerned with data manipulation, communications and the graphical user interface – which is a new departure for this device.   My best estimation is that the code will likely double in size, to achieve the project aims, and so will be closer to 20 modules of code of on average 400 lines each.

Managing this code overhead will probably tax most of my coding skills, yet it’s only a small project. I am not a natural born coder, and I suffer from a tendency to glaze over when I read abstract code – a symptom I first experienced when trying to commit to memory a lot of advanced pure maths formulae whilst studying A-levels. As a result, my maths grades are something I tend to gloss over, but a recurring nightmare every year in May.

I understand what the code has to do, I just don’t like the way it is expressed with a lot of words and statements that I struggle to commit to memory. It’s not code dyslexia, more like code illiteracy – especially when it’s someone else’s writing.

What I need is another more visual method to represent code  – that way I might have a better time with it.

Here be Dragons…..

Moore has been quoted as saying “The Map is not the Territory” – an expression that I was not over-familiar with, and perhaps I failed to see his particular context. It did however trigger something in my mind – and has got me thinking about journeys, maps and territories.

A journey is by it’s nature a fairly continuous movement across, for example a landscape. Along the way, you see different things, many of which may not have been visible at the start of the journey. You may be in possession of a map, created by someone who has already traveled and surveyed the terrain, and you can decide from the map what suitable places there are to visit.

To me,  this is how conventional coding appears.  You have a listing in an editor, and you have to do a lot of linear scrolling up and down through screens of code to get to what you want. This is particularly difficult, if it is someone else’s code, and you are desperately trying to follow some threads and find out what the major landmarks might have been.

What you may fail to realise is that this unfamiliar document – the source code – is effectively a set of directions for an alien machine equipped with a teleporter – which can effectively go wherever it wishes, at any time without having to be constrained by mere linear progressions through code. A conventional code listing  on a screen is a very poor map when you are tracking down aliens with teleporters.

A better approach would be to spread out all of the listings out on the desktop, and summarise each code module in terms of it’s major functions. From here you can create the “big picture” of what the scope of the project may be,  and get a better understanding of the overall structure of the code.

It’s still a bit like chasing aliens around London using the tube as your sole means of getting around, you armed with an Oyster card that allows sequential access to the network – and the aliens with a now metaphorically, thinly worn, teleporter.

So you are able to explore the lower levels of the metropolis, by Underground, and at least you can create a map of the main routes and stations. If you want to get between stations, and explore further, it’s a case of leaving the tube network and going above ground.

Above ground, at street level, things are not much better, your directions and horizon are constrained and obscured by streets and immovable buildings,  and every floor of every building, is another layer that needs to be mapped.

This is where maps have helped us understand the complexity of the physical world. They present in a 2D or 3D format information about terrains, that on foot could only be journeyed sequentially – and ever time-consuming. Maps at least help to give us an overall picture of the territory and the geographical relationship between the major features.

Sometimes, as in the case of the iconic London Tube Map,  there is no longer a need to focus purely on emphasising geographical relationship, as all stations are shown equidistant regardless of their distance apart. Instead, to convey an indication of the interchanges between the lines, or networks, which to the undeground passenger who cares little for where they actually are, but more importantly where they change lines or networks.

It is the same for software, a function may be a single line of code or a thousand lines, it’s not the length nor the position in memory that is important, it is how it connects to other functions which matters most.

The tube map allows us to comprehend the scale of the underground network in little more than a single glance. In that glance we take in approximately 270 stations, served by 11 lines. The use of colour plays a major part in  illustrating which line serves which area.

Can we better represent a complex software as a 2 dimensional colour “tubemap” rather than a series of code listings?   If the map represents the scope of the project, and the coloured routes are the collections of functions that go together to make the code modules then certainly we can. A walk through the code, in following the designer’s intentions of performing some particular high level task, can be a great way to understand how the code fits together.

If you travel the London Tube, you will quickly become familiar with the stations and the interconnections of lines. Stations are often geographically names after streets, main line stations, settlements or monuments.  For example Baker Street, Waterloo, Brixton and Tower Hill. These are real world names that have real world meaning. Compare this with the New York subway, which may have Fifth Avenue and Line 7.  Unless you are a native New Yorker and have learned the grid system of streets and subway lines – this may convey little or no meaning. For the rest of us – we rely on a good map which translates the unfamiliar into the familiar.  It’s the same with software – functions should be given names that mean something, and more to the point are memorable!

So back to the exercise of Code Cartography. Rather than scrolling our way up and down through listings on a monitor screen, such as we have been doing for 50 years, we should take advantage of High Definition touch screens, and use a graphical representation arranged in 2 dimensions that spread the information across the wider screen. This will allow us to see the whole terrain. Functions may then be accessed by a simple touch or point from the mouse. Onto this broad, blank canvas, we plot the major functions, aliken them to the tube stations, and then we use colour to thread our way between these functions, in the same way our alien machine does – with it’s imaginary teleporter.

There is no reason to need to see all the detail all of the time. We humans just don’t have that sort of information bandwidth. We just need to see the relative relationships between the functions and their interconnections.  Representing the functions by a series of graphical objects on the screen, which when selected can then open up a window showing the underlying code would be a neat way of representing them graphically – some might call this an interactive flow chart.

This may be quite a lot to take in in one sitting. Therefore, in the next part I shall endeavour to present a graphical scheme, which I believe will help me with my mental mapping of code.

Nobody is expecting you to build a ChipStick from scratch – unless you are very keen.

The ability to work with tiny SMT parts is not one everyone possesses, but it can quite easily be learned, and with practice, good results are possible with the simplest of tools and equipment.

This post follows the construction process step by step – for the curious – or for those brave or foolish to wish to follow in my footsteps.


SMT Hot Air Rework station with choice of nozzles – I used 8mm
Soldering iron with “needle” tip
Soldering sponge
Flux pen or water soluble SMT flux
Tweezers (stainless steel – non-magnetic)
0.38mm 60/40 solder (Don’t struggle with lead-free – it’s dreadful).
x10 magnifying eyepiece
good overall lighting – use spot light or bright daylight
scalpel or craft knife
3rd Hand
Bluetack – stick the pcb to the bench to stop it moving
De-Solder braid – accidents can happen
Patience – set a day aside for this, without interruptions

Use a Flux Pen to flux the footprint of the main IC

Flux is essential for good solder wetting.  Use it liberally on the multipin footprints – such as mcu and other ICs.  I use a rosin flux pen for convenience, but there are now some water soluble fluxes that wash off the board with water and an old toothbrush.

Use a soldering iron and add some solder to the IC pads
but not the centre one!
MCU footprint with solder applied

These boards have been “hot air solder levelled” or HASL.  They are easy to solder, but for IC pins you need to build up a little more solder thickness on the pads – and don’t forget to flux well.

Flux the underside of the IC package
and also reflux the pads on the board

I first position the mcu centrally on the footprint pads with tweezers.  The flux heps to hold it in place.  Check from the sides that al the pins line up, and check again that Pin 1 is in the correct position!!

Set the temperature of the hot air tool to between 370C and 400C.

When happy with positioning –  use the hot air tool about 20mm above the IC and swirl the air around the IC in slow circular motions – about once every second.  I count to 20, and usually the solder has melted and the IC is sitting squarely on the board – and not moved to either side.   Don’t spend more than 30 seconds with heat on any one component.  Leave to cool – it will be hot!

The mcu successfully soldered in position using hot air reflow tool
Now go around the pins with soldering iron checking every joint is good

Next I use the needle point tipped iron and rework every pin.  I check that the solder reflows and that the soldered joints are bright silver an “fresh”. There should be a neat solder fillet between the board and every contact of the QFN package.

Repeat 13 more times!

At this stage – I put the boards into a programming jig and made sure that they accepted the programmed code. If not I inspected carefully and reworked where necessary.

Voltage regulator and decoupling capacitors added – USB next

I then proceeded to put the remainder of the smaller components onto the top of the board – leaving the bulkier mini USB socket until I had completed all the work on the underside of the pcb first!

Underside of board with USB converter on left and 128K SRAM on right
Topside completed – undergoing testing
Four completed units – with penny for scale
Choice of pins – left are for breadboard, right are to fit DIL 20  IC socket

Just over a month ago I talked about the MSP430 bootloader – commonly known as BSL – or bootstrap-loader.

Almost every MSP430 has the facility to load code via this ROM based bootloader – and when first introduced about 15 years ago, it was ahead of its time. The clever engineers at Texas Instruments wanted a simple “Backdoor” method of getting code into the device, using nothing more than a 9 pin serial com port, some trivial level shifting electronics and a modest program running on a PC.

Whilst the 9 pin serial port may have long since disappeared, the BSL is still present in almost every chip – and not just for a UART connection, but for I2C and SPI interfaces too.

With the advent of ferroelectric, non-volatile FRAM memory in the recent range of MSP430 mcus there is all the more reason to want to leverage on the strengths  of the BSL and develop neat new means to get code into these often understated devices.  With a wireless or Bluetooth connection – firmware over the air (FOTA) becomes practical, and also “self-replicating” gadgets – where one MSP430 equipped gadget can “clone itself” into another unprogramed device – ideal for kids sharing hardware around the playground.

What I have Learned this Month

I have now been using this bootloader on and off for a month,  and wanted to share with you what I have learned – in the hope that things are easier for those that may wish to follow in my footsteps.

All the information is out there – it’s just not all in one place, and a lot of time has been spent finding snippets here and there, and trying to make sense of it all.  Like Captain Kirk said… “Our continuing, 5 year mission……”

To start off, you might wish to look at the following TI  documentation

Main Bootloader Specification

MSP430FR4xx / MSP430FR2xx Users Manual

MSP430FR4xx and MSP430FR2xx Bootloader (BSL)

Hardware Initialisation

The basic idea is that the PC uses the DTR line and the RTS line of the USB to Serial converter to create a pulse sequence which when recognised by internal state machine hardware, causes the MCU to enter Boot Mode.

The hardware sequence needed to invoke the Bootloader mode
The key points are that there are 2 pulses on the RST/TEST line, the first is 10mS longs and the second is 20mS long.  The RESET line  (DTR) rises whilst the 2nd RST pulse is still high, and approximately at half way through its duration.
This sequence has been chosen because it uses both edges and levels to encode the BSL envoke command, and the hardware that responds to this sequence is unlikely to be falsely triggered by any spurious noise or other accidental stimulii.
In theory, any bit of hardware that can generate this pattern can be used to invoke BSL mode, all it does is cause the mcu to jump into the bootloader code and the /RESET and TEST lines have no further function within the body of the programming process that follows immediately after this pulse sequence.
After the BSL start sequence has been sent,  the Tx and Rx lines become active as data and acknowledgements are sent between the PC and the MSP430.  This can be at 9600 baud, with even parity, but some faster BSL programs begin at 9600 baud and request a step up to a faster baudrate for the duration of the programming.
At the end of the programming sequence, the PC returns the TEST line high – as shown on the right of the sketch above.
Ideally the reset line should go low and then high to issue a rest pulse – but this is dependent on the PC application and is not always the case.
This may seem simple so far – but then there is the old saying “If it can go wrong, it will go wrong”.
The problem arises in that over the 6 generations of MSP430  – there have been several different start sequences, for the families of 1xx, 2xx, 4xx  5xx,  6xx and FRxx devices.
As the hardwware to drive the bootloader evolved from a simple 9 pin RS232 Comm port – where some of the handshaking lines are inverted, the original specification was aimed at what was easiest to implement from a standard serial port.
In addition, some MSP430 devices share their /RESET and TEST pins with JTAG functions – so to differentiate between JTAG commands and BSL commands sometimes one or both of RST and DTR shown above are inverted.
Here are a few pointers to get you up and running quickly
1. Make sure that /RESET connects to DTR and TEST connects to RTS – easily mixed up.
2. As a temporary hack, be prepared to add a P-FET to invert DTR line so that /RESET is active low. See picture below

3. Some PC applications allow you to swap or individually invert the RTS and DTR lines – but only available for 1xx, 2xx, 4xx.

A P-FET and 10K resistor were added to invert the DTR signal for /RESET
PC Software 
I have found at least 3 variations of  PC BSL Scripting applications.  Here are the links:
There may be more available,  but I struggled to find anything that gave me exactly what I needed.
In the end, despite the msp430-bsl-utility being almost exactly what I needed with the means to swap and individually invert RTS and DTR.   However this utility was not compatible with 5xx and 6xx Bootloaders.
To make the bootloader work, I had to use the 5XX mode and invert the DTR (RESET) signal using a P- FETtransistor  – in order to match the signal diagram above.
Once you can generate the correct boot sequence – the rest is fairly easy.
The script for the BSL is very short   – use a filename such as  script1.txt
MODE 5xx COM9                                                    // Set 5XX mode with USB VCP on COM9
RX_PASSWORD                                                     // Use Default Password  (optional)
MASS_ERASE                                                         // Erase the device
RX_DATA_BLOCK_FAST blink_2433.txt                // Send the TI TXT file  blink_2433.txt
SET_PC 0xC400                                                      //  Set the Program Counter to 0XC400 – ready to run
The comments are for explanatory purposes only – although if you include them in the script, comments should be on separate lines to any script instruction
To use this, put the bsl_scripter.exe,  the script1.txt and the blink_2433.txt file all in the same directory.
Run by typing

bsl_scripter.exe script1.txt

Typical output session from BSL_scripter
If all goes well, this takes a couple of seconds to run – after DTR has been allowed to go high again at the end of the programming.
Further work required – should be possible to invert DTR in software –   so that it doesn’t need the hardware hack with the transistor.  The BSL utility GUI is the way to go, if someone with Python skills would just hack it to handle 5xx bootloader format
The programmer should be modified so that it releases DTR at the end of the programming sequence – so that the code autoruns after loading.
A neat way of programming a MSP430 with very simple USB-serial converter – just need 10% more effort in the PC software to allow it to handle the newer parts – without having to resort to command line and P-FETS!

0 0

I have spent the weekend, on and off, sorting out some memory test functions for a small computer I am developing.  These test functions are written in pidgin-C (my own special dialect) and although they didn’t exist 2 weeks ago –  over the last few days they have grown to almost a third of the 1200 lines of code, and represent adding considerable extra complexity  – to something that started out as a neat idea contained in just 100 lines of code.

The memory device in question, is a 128K bytes RAM connected to the mcu via a SPI bus.  Compared to what I usually work with, 128K bytes seems like a vast empty canvas, and I am like an Artist, or perchance a Cartographer – starting out to map out the territory that lies ahead of me.

Where to Start?  How do you begin to draw lines in the desert? How best to partition the vast array of RAM into meaningful blocks and subdivisions?  This time I think I will choose the “American” model – a series of logical blocks – laid out in a grid – after all – that is the internal structure of memory – however else we wish to abstract it.

The RAM is a Microchip 23LC1024, a 1Mbit part – and the larger version of the popular 23K256. According to the datasheet, this part has a 128K x 8 organisation with 32 bytes to a page, thus 4096 pages in the device.

32 bytes is a convenient sized unit of storage – especially when it comes to an interpreted language like Forth – consisting of short functions or words. 32 bytes is a good fit for a hex-dump routine and well suited to the modern Laptop screen resolution – where 128 characters +  across the screen is not uncommon.

It allows for a function name, a code field address, a length, a payload of around 16 tokenised Forth characters and a character to either terminate the array, or to act as a continuation to the next page.

So each 32 byte page is a “pidgeon hole” into which you can post some source code, and by sticking to 32byte boundaries – it simplifies the addressing of the RAM and the storage, retrieval and movement of code.  The 23LC1024 has a page mode for reading and writing RAM, which allows the address to be set up and the data – up to 32 bytes to be clocked out.  This is much quicker than random byte addressing – which has the overhead of setting up a 24 bit address at the start of each RAM transfer.

In addition to “page mode” there is streaming mode – which allows for much larger transfers.  In this mode you just have to specify the starting address, then just keep clocking bytes until you have transferred all you need.  It works out at an average of about 3uS per byte, allowing the whole device to be dumped in about  0.4 seconds.

When Charles Moore got access to his first disk drive, he picked 1Kbytes as a convenient size for a block of code.  Whilst the 1K block may have fallen from fashion in the modern Forths, within this educational environment, there are certainly valid reasons to re-instate the 1K block concept:

1.  1K of code fits nicely  in the hex-dump window of the terminal application as 32 lines of 32 hex digit pairs – with accompanying ASCII to the right.
2.  On the proposed machine – there is only 4Kbytes of SRAM on chip – so a 1K buffer to allow blocks to be swapped in and out of on-chip RAM seems sensible.
3.  Many small Forth applications will fit into a 1K block of source code – particularly using tokenised code.
4.  1K of code can be transferred in about 3mS. That’s about the duration of the vertical blanking interval (VBI) in some low resolution video standards – PAL etc. This allows for block transfers of the screen  character buffer to be done during the VBI.


These days, when you can buy a 7″ tablet for $50, there is all the more reason for makers and hackers to want to become more engaged with up to the minute 7″ touchscreen technology for their latest projects.  Fortunately, recent developments in hardware have made this both affordable and easy to do – to the point where no project is too small,  not have a neat touchscreen interface  – and sound too!

Touchscreens are now flooding onto the market – at surprisingly low prices.  4.3″, 5″ and 7″ devices are all available – with a 7″ screen with capacitive touch for around $32.

Touchscreens have been generally difficult to drive in the past – requiring a high end microcontroller with sufficient RAM available to support a frame buffer  – between 1Mbyte and 2 Mbyte. There is also the somewhat daunting process of writing a graphics library and the low level drivers needed to push all those pixels around.

This has previously been well out of reach for Arduino class microcontrollers – until recently – when an innovative, low cost family of display controller ICs appeared from a little known, fabless IC company, based in Glasgow, Scotland.

Their solution does not need a 2Mbyte frame buffer in RAM nor a high bandwidth memory bus. Instead their controller, or embedded video engine, uses a simple “Display List” to send lists of objects to display to the screen.  This reduces the processing and memory requirements of the microcontroller by 2 or 3 orders of magnitude – which puts it nicely back into Arduino territory.

This post is all about using their lowcost (<$9) graphics co-processor IC to provide a neat user interface for any low-end microcontroller.

Affordable 7″ capacitive touchscreen – about $32 

Character Building Stuff

Neo-Retro Computer – Interchangeable with £10 note.

One area of of development of my Neo-Retro computer that has been in a holding pattern for the last few months is the graphical user interface, or GUI.  You may recall that over Christmas and New Year, I experimented with the FT812 graphics coprocessor device, normally intended for driving LCDs – but with a little bit of hardware bodgery (24 resistors)  – it can be made to generate a VGA display for a widescreen monitor.

The FT812 is about $8.80 in 1 off quantities and requires very little other than a crystal and a few passives to generate the VGA output.  It connects to the mcu via the SPI bus plus a couple of control signals.

1024 x 768 colour text from the FT812 and ATmega1284

It provides a neat and low cost means to get quality video output from even the most resource strapped microcontrollers eg Arduino/AVR,  MSP430, Teensy etc.

If you can’t Make – Simulate!

FTDI provide a simulator application (download for Windows) that allows you to develop GUI screens on a Windows PC. Very quickly you can build up the various graphical components and “widgets” into the display list (DL), that are typical on a modern LCD based product.

Once you have your display list and the right look, it’s then relatively easy to import the DL into your own C code.  For those using Arduino, Discovery F4, Raspberry Pi – there is technical support for this on the FTDI website.

Even a very modest microcontroller can support a Touchscreen GUI using this method, which can be used for LCDs in handheld equipment – or plugged into a large screen monitor for easier viewing.

LCDs are so cheap now – 7″ screens with capacitive touch from China are selling for about $32. Or you can buy a ready made screen module 5″ diagonal, 800 x 480 pixel resolution complete with FT810 controller, LCD and bezel for $33 or less – all ready to fit to your latest project.

800 x 480 Resolution with FT810 for about $33
Back of console showing various interface connectors

Programming the FT81x

There are several font sizes available, graphics primitves such as lines and points (circles), buttons, sliders, shading effects, clocks, dials and audio samples and effects – which rapidly allow you to build up a full GUI.  Both resistive and capacitive touchscreen technologies are supported – allowing for object selection, swiping, gesturing etc.

Indeed many of these features have been well explored in the GameDuino II product by James Bowman, – a complete retro-gaming platform using the FT8xx embedded video engine and an Arduino. Neither the FT81x datasheet nor Programmers’ Guide do real justice to what this clever $8 IC can actually do.  James Bowman’s Book on GameDuino 2 describes the capabilities in much greater depth with graphical examples.

Now for some quick screen “experiments”.  All of these are achievable with a small microcontroller (MSP430, ATmega, ARM) connected via the SPI bus to an FT81x device.  Suitable dev-boards are available from FTDI, with or without LCD, or the Gameduino 2 is FT800 hardware plus an I2C accelerometer and audio output jack conveniently brought out to Arduino shield compatible pins.

The first shows some 16 lines of text, a shaded background effect and 4 User Buttons.  This can be quickly built up from a series of display list commands by the process of compositing.

A GUI aimed at displaying Forth Source Code – plus some User Buttons

The only downside of the FT81x is that you are limited to 2048 entries on the display list – and this means only about 2000 characters of text – as each character, with formatting occupies on average just over 1 entry in the display list. However, the screen above with 16 lines of source code and 4 buttons uses 32 for the background shading effect, 300 entries for the text and 228 for the buttons.

However, the whole point of a Graphical User Interface is that it uses graphics rather than just plain text to convey the information.  A picture is worth a thousand words … literally. And these days, most things can be conveyed in 140 characters or fewer…..

Just the Forth source code

Dropping the screen effects and buttons results in just 325 entries. As the position of the character on the screen is encoded into it’s display list entry, it may also be possible to code the text such that the whitespace takes up no space in the DL. So we can estimate roughly 512 DL entries per page of “reasonably dense” text – say 16 lines with an average line length of perhaps 32 characters.

This is a fairly efficient way to generate a screen.  Whilst a single ASCII character takes 4 bytes sent to the display co-processor rather than 1 byte, this includes the X,Y position information and the choice of font. If raw bytes had to be sent to a frame buffer, it would take 8 bytes to build up an 8×8 character, and with a conventional serial terminal  being sent ASCII characters – there would be no opportunity to choose to place them any position on the screen to a resolution of 1/16th pixel.

Fairly Dense Text and Display List 55% used
Just the text: 1062 characters – encoded into 1130 entries in the DL

CLEAR(1, 1, 1)
CMD_TEXT(0, 0, 21, 0,”Dropping the screen effects and buttons results in just 325 entries.”)
CMD_TEXT(0, 16, 21, 0,”As the position of the character on the screen is encoded into it’s display”)
CMD_TEXT(0, 32, 21, 0,”list entry, it may also be possible to code the text such that the whitespace”)
CMD_TEXT(0, 47, 21, 0,”takes up no space in the DL. So we can estimate roughly 512 DL entries”)
CMD_TEXT(0, 64, 21, 0,”per page of reasonably dense text – say 16 lines with an average line length”)
CMD_TEXT(0, 80, 21, 0,”of perhaps 32 characters. ”
CMD_TEXT(0, 112, 21, 0,”This is a fairly efficient way to generate a screen. Whilst a single ASCII”)
CMD_TEXT(0, 128,21, 0,”haracter takes 4 bytes sent to the display co-processor rather than 1 byte,”)
CMD_TEXT(0, 144, 21, 0,”this includes the X,Y position information and the choice of font. If raw bytes”)
CMD_TEXT(0, 160, 21,0,”had to be sent to a frame buffer, it would take 8 bytes to build up an 8×8″)
CMD_TEXT(0, 176,21, 0,”character, and with a conventional serial terminal being sent ASCII “)
CMD_TEXT(0, 192,21, 0,”characters – there would – there would be no opportunity to choose to place”)
CMD_TEXT(0, 208, 21,0,”them any position on the screen to a resolution of 1/16th pixel.”)
CMD_TEXT(0, 240, 21,0,”If we think of the Forth computer sending screen display list information over”)

CMD_TEXT(0,256,21,0,”a UART connection to another machine (Laptop, Tablet, Phone, Ras-Pi, or”)

The sequence of commands in the display list to produce the above screen. Whilst I have manually edited my text to fit into command format needed by the FT810 simulator – this process could easily be automated by the MSP430 – in Forth.

Further Thoughts

If we think of the Forth computer sending screen display list information over a UART connection to another machine (Laptop, Tablet, SmartPhone Ras-Pi, or CHIP) which then renders this information into a user display, then the complete DL of 2048 x 32bit words could be sent in approximately 89mS over a 921600 baud serial link. This would allow typing and editing of text in real time – for most humans.

The FT81x device provides on chip support for resistive or capacitive touchscreens – so that positional information of touches, swipes and gestures may be gathered.  On a widescreen implementation, it would be a relatively simple method to create a mouse cursor – and use this for text highlighting, object selection, and invoking common user commands.

Forth is approaching 50 – and so it really is time to move away from purely text based input.  The GUI can offer so much more including command mapping, colour, highlighting – plus perhaps some of the user interface features that the SmartPhone Generation (anyone under 8) will expect. The FT81x series of ICs offers a really cost effective means of achieving or at least experimenting with these ideas.

The simulator allows you to quickly and easily build up various GUI screens 

In the next part I will further some of the user interface ideas, in ways designed to minimise typing and maximise the features of the Forth Language.

As the SPI interface and control lines between the mcu and the FT812 is just 6 wires plus power, it’s fairly easy to hook up to your favourite micro on a breadboard.  Hopefully in a few days I will have the FT812 wired up to ChipStick and be able to generate these screens for real.  I’ve been there alreadywith Arduino based hardware – so now it’s time for the MSP430 FRAM devices.   8 jumper wires and a LaunchPad should be all that’s needed.

In the meantime – if you wish to experiment with the FTDI FT81x Display Simulator application – you can download it from here.

You may also be interested in the othe 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

Project Update

First a few words about the current status of the ChipStick project.

This week, the first of the prototype ChipSticks have been sent out to the “Early Adopters” – those with the skills and experience to port Forth onto the device – and thereby “hit the ground – running”.

I have also spent some time working on the method for bootloading the device using the CH340G USB comm port and a PC BSL Scripter tool. This is now working on a modified prototype board, and these mods will either be handled with a board revision or some change to the available scripting tools.


When I first devised SIMPL – as an extension to Txtzyme, I believed it to be a great means to improve the quality of interaction between the User and the embedded device, especially when coupled with some interactive hardware such as LED arrays and switches.

Within a few days of the first version of SIMPL, I was connecting it up to LED arrays, and devising a user word “n” which would display the number in binary on a LED array.

Learning by Fun!

ChipStick is all about having fun learning about electronics and computing – so that’s why it comes with some preprogrammed words to allow LED displays and musical tone generation to be explored. ChipStick’s hardware has been made as versatile as possible, with the aim of future expansion.

Digital outputs are connected to Port 2 and numbered 0 to 7, and each may be connected to a LED via a suitable (270R) resistor.  With this it is possible to turn on individual LEDs, or to have them display an 8 bit binary number.

In it’s basic configuration, an array of up to 8 LEDs can be supported and three push switches.

With the addition of some extra hardware, an 8×8 LED array or a 32 key keyboard can be used.

Shift Registers

Shift Registers are the key to economic expansion of the hardware. They are ideally suited to the SPI bus environment and can handle reasonably high speed transfers or data both out of and into the mcu.

The 74HC595 is a serial to parallel converter, costing around $0.10 in volume and ideal for driving LED arrays and keyboard scan lines. The 74HC165 provides the complementary function of parallel to series conversion – and is great for scanning key matrices and arrays of digital inputs.

During this week, I had a little success getting an array of 7 LEDs to mimic the stack operations and one upcoming project will be to use a pair of external 74HC595 shift registers to extend these LED arrays to extend the stack viewer to the full 16 bit.

I have already made a start on this by digging out the hardware used on my “shift register” breadboard – first used back in 2014 for my “A Little Bit Shifty” blog post, where I explored the use of shift registers for input, output and driving stepper motors. This board allows an additional 16 output bits to drive LEDs and 16 input bits from switches. This makes it possible to use ChipStick to recreate 60’s style Retro Computers – similar to the Kenbakuino.

ChipStick gains additional 16 Inputs and 16 Outputs using Shift Registers

It’s great to see the effect on the LEDs following stack arithmetic and logic operations – a wonderful, visual and interactive way to learn binary arithmetic and boolean logic.

Memorable Events

Last weekend, I had the opportunity to catch up with writing some new firmware functions to get the 128K memory working, so now most of the pieces of the “Forth Computer” are starting to fall into place.

The remaining parts still to work on are the code that will interface to PS2 kepboard and mouse, and of course tying in the system hardware with the FT812 embedded video engine hardware.

This has just become the subject of a recent post.

0 0

When the team at Cambridge got the EDSAC digital stored program computer to first run on May 6th 1949 – it was a major leap forward for the fledgling British computer scientists.

The “Initial Orders” were effectively a bootloader – which was entered into the memory store, electro-mechanically using preset uniselectors – a bit like dialling the numbers in,  with an old rotary dial telephone. Once loaded into the first 30 or so locations of the store, it would run a small program to allow the main program to be loaded from a punched paper tape.

For those interested in early computer history – the University of Cambridge Computing Laboratory have produced a commemorative poster – detailing the Initial orders, the instruction set and operation of a Squares Program running on the EDSAC machine.

EDSAC – University of Cambridge 1949
ChipStick  – 67 years on – still needs “Initial Orders”

ChipStick, if you can summarise it in a few words, is basically a very small, 16-bit microcontroller based, I/O device dev-board on the end of a USB cable.

The USB connection provides communication, power and the means to program new code into the microcontroller.

ChipStick measures just 40mm x 11mm yet meets or exceeds many of the capabilities of the Arduino, some 7 times its board size.

In order to develop code on this platform, we use an interpreted language – Forth, and so the host computer need only send a few ASCII command strings to the device, in order to control it.

ChipStick Goes Forth!

A first batch of 20 band built ChipSticks were distributed to some eager “early adopters”.  Within a few days of receiving the pcbs – we had a version of Forth ported across to the FRAM based MSP430FR2433 microcontroller.

ChipStick places a strong emphasis on programming interactivity. For this reason it offers native Forth language, as standard, allowing immediate interaction with the application code.

For more details on the Forth implementation, see the Mecrisp site.

ChipStick being used to help debug some SPI RAM issues

ChipStick offers up to 16 I/O lines, of which 2 are generally kept for serial communications to the PC.

Up to 8 LEDs may be driven as an array, for immediate interaction with the application.

ChipStick is intended to be a low cost experimental and educational device. The combination of a moderately fast 16 bit processor, ferro-electric non-volatile memory (FRAM) and three separate fully function communications interfaces make it a versatile device. Additional SPI peripherals may be added including extra RAM or FRAM, shift registers for Input and Output, motor drivers, high resolution ADCs, DACs, temperature and pressure transducers, accelerometers, gyroscopes, compasses etc. In fact ChipStick can interface to virtually any device that has SPI, I2C or UART interface.

ChipStick has 15.5kBytes of FRAM available plus 4kBytes of SRAM. Whilst this may seem small by some standards it is more than enough for most sensing or control tasks.  Additional memory for data storage can be added using the SPI Port B.

Communications Interfaces

ChipStick is based on the newly available MSP430FR2433 microcontroller, but the pcb can also accept similar MSP430 devices from the FR25xx and FR26xx series – which are aimed more specifically at capacitive touch sensing applications.

It features three separate enhanced Universal Serial Communications Interfaces (eUSCIs)  which can provide a mix of UART, IRDA SPI and I2C interfaces.

Two A type eUSCIs provide UART, IRDA and SPI capability.

One type B eUSCI provides SPI and I2C capability.

1             3V3  |  CHIPSTICK  | 0v                20
2             P3.2 |             | P2.1 XIN          19
3      PC-RX  P1.5 |             | P2.0 XOUT         18
4      PC-TX  P1.4 |             | TEST/SBWTXK       17
5  UCA0 CLK   P1.6 |             | /RST/NMI/SBWTDIO  16
6             P2.3 |             | UCA1 MOSI         15
7  RAM_/CS    P3.0 |             | UCA1 MISO         14
8  UCB0 STE   P1.0 |             | UCA1 CLK          13
9  UCB0 SCK   P1.1 |             | P2.3              12
10 UCB0 MOSI  P1.2 |             | P1.3 UCB0 MISO    11

P3.0  /CE          |   23LC1024  | 3V3
P1.3  MISO         |             | HOLD – pull up to 3V3
NC           |             | SCK  – P1.1
0V           |             | MOSI – P1.2

The diagrams above show the pin-out of ChipStick – and also that of the 128K bytes 23LC1024 SRAM that is located on the underside of the pcb.

Programming and debugging the initial code image of Forth  is done with the aid of an MSP430FR4133 Launchpad.  The jumper links are removed from the FET connector, allowing jumper wires to be connected from TEST and /RESET to the SBW pins on the dual row header.

Once Forth is loaded – it takes over and allows the full interactive programming of the standalone ChipStick by way of the USB to Serial adaptor – built into the end of the pcb.

You may also be interested in the 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


Two weeks ago, I introduced a new project, ChipStick – a small dev-board based on the MSP430FR2433 16-bit microcontroller.

The aim of ChipStick is to provide interactive programmable Smart hardware to bring your next project to life.

Late last night I received from Matthias Koch – the first draft of Mecrisp 2.03 Forth ported especially for the ChipStick.

I am please to announce that when loaded into the ferro-electric memory of the ChipStick that it burst into life and was immediately recognisable as a full-blown Forth System.

Forth provides the ideal interactive development tool to help breathe the life into your latest hardware.

Historical Note

Forth was developed in the late 1960s by Charles H. Moore, whilst working with radio telescopes, controlled to minicomputers.

There are numerous online documents describing the history of Forth – so I shall not go into too much detail – needless to say, that Charles “Chuck” Moore wanted a more efficient programming environment and wanted to have control over the whole system.

Forth became popular in the late 1970’s – with the 8-bit microprocessor revolution. It offered an alternative to machine language and was well suited to the resource limited systems of those times – often fitting into 4Kbytes or less.

Needless to say , Forth is a very compact and versatile language – and a very good fit for the modern 16-bit and 32-bit microcontrollers. The Mecrisp implementation is about 11k bytes of FRAM.  On the MSP430FR2433 that leaves 4K of FRAM and 4K of SRAM for the Users application code.  There is also the 0.5kB Info RAM – which can be set as a protected area.

Using Forth

Forth uses natural language words, separated by whitespace.  Forth source code may be composed using nothing more than a text editor and uploaded to the target using a terminal program – such as Termite or TerraTerm.

Forth uses 16-bit integer maths as standard – though there are extensions for floating point. However integer math is not so much of a limitation  355 / 113  can be more useful than you think!

Forth consists of a dictionary of standard words, to which the user may add their own new definitions of words.

Any high level control can be broken down into a series of  smaller operations – for example a control cycle for a washing machine.


Obviously there would be some decision making logic connecting these tasks,  and the CHURN cycle, and RINSE, DRAIN SPIN cycles may be repeated a number of times depending on the type of wash required – but it illustrates the point of reducing the problem to a series of self-contained tasks.

Once the problem has be thus decimated, the high level tasks may be written in Forth, using whatever native language is appropriate to the tongue of the user. If you want to use German, French or Mandarin for the high level names – that is perfectly acceptable.

Forth needs to have a good relationship with the register level hardware of the chosen microcontroller – and the closer to the actual microcontroller peripherals you can get – the more versatile Forth becomes.

It is fairly straight forward to define simple words that allow you to exercise the GPIO.  A quick look at the MSP430 datasheet -and you can construct these new words in a few minutes.  Additional words would be constructed for setting timers, reading ADCs, SPI, I2C transfers to displays or external devices plus anything else of the myriad of operations you might wish to do with the hardware.

Note how all these word definitions start with a colon : and end with a semicolon – this gives them the name “Colon Definitions”

Once entered into the dictionary – these new words are ready and available to use as you like, or combine to make larger words.

Setting the ports
: P1IN  512 C@ ;
: P1OUT 514 c! ;
: P1DIR 516 c! ;
: P2IN  513 C@ ;
: P2OUT 515 c! ;
: P2DIR 517 c! ;
: P3IN  544 C@ ;
: P3OUT 546 c! ;
: P3DIR 548 c! ;
Lighting LEDs on Port 2
: P2LEDSET 255 517 c! ;    (set all Port 2 pins to output)
: LEDNUM 515 C! ;          ( display a binary number on LEDs)
Onboard LED on Port 3.1
Dump the FRAM in HEX base
: hexdump hex c400 c800 do I c@ . space loop ;
: texdump hex c400 c800 do I c@ emit loop ;
Once you have these definitions store in memory, you can type  170 LEDNUM – and turn alternate LEDs on your LED array.
To be continued.
Meanwwhile  – If you want to catch up on previous ChipStick posts – have a look at the links below:

0 0

This week, Matthias Koch sent me the files for his Mecrisp Forth MSP430 –  ported specially across to the MSP430FR2433 which is used on ChipStick.

In this post – something of a tutorial, we look at the basic steps needed to get your minimum Forth system up and running, which means loading and executing Forth source code. Fortunately we do not need a whole bunch of special tools work with Forth – as Forth has much of this functionality built in, editor, compiler, interpreter.

In order to program ChipStick effectively with Forth, load, save and edit source code, you will need the following:

  1. A terminal program capable of sending a text file.
  2. A text editor – such as NotePad++
  3. A breadboard with some LEDs – plus any other hardware you want to interact with

For Windows – the terminal I can recommend is TeraTerm – as it has a very flexible scripting language to allow you to customise the terminal operations.

For Linux there has been especially written  e4thcom, which comes with many additional features incuding a GTK+ GUI called ForthBox. There are comprehensive instructions here with the download  –  e4thcom – A Terminal for Embedded Forth Systems

For MAC OSX – working under Homebrew – you can use PicoCom.

To install PicoCom on MAC OSX with Homebrew, enter this in a command shell:

brew install picocom

As I am more familiar with Windows, the rest of this tutorial will look at working with TeraTerm.

Serial Set-Up

ChipStick running Mecrisp uses 115200, 8, N, 1 serial communications – but if you are using TeraTerm you first have to set up a macro – that inverts the DTR and RTS lines.  The reason for this is that with RTS low – the MSP430 is held in reset – so Forth will not run!

Equally, togging RTS, with DTR high will perform a hardware reset of the MSP430 – if you really get stuck in a jam.

Inverting RTS and DTR is done with the following lines 6 of code which we save in TeraTerm as a script text file.

; enable dtr
setdtr 1
; clear rts
setrts 0
; now clear dtr, so that the system will reset and see rts clear
setdtr 0

Save these as a file  “mecrisp_reset.ttl”  in the root directory of TeraTerm.  TTL is the filename extension given to the TeraTerm scripting language.

Open up TeraTerm, selecting serial and which ever port the ChipStick’s CH340 has connected to- and under the Set Up menu tab – set the terminal options as follows:

Setting up the serial com port parameters

Note the 50mS delay at the end of each line – this gives the Mecrisp Forth interpreter sufficient time to compile each line of source code and answerback “ok.” You may choose to vary this delay to between 10mS and  50mS- depending on your system.  If you make th delay too short, some long lines will not be compiled – so I found 50mS to be a safe compromise.

Later, at the end of this post, I will introduce a more sophisticated TeraTerm script that further automates the file sending – and intelligently waits for the “ok.” prompt at the end of each line. See end of post for details.

Next – under the “Control” menu select Macro, and then navigate to where you saved the Mecrisp macro – that inverts DTR and RTS

Select the “mecrisp_reset” macro

Once you have sent this macro, the Mecrisp Forth should reply with

Mecrisp 2.0.3 for MSP430FR2433 by Matthias Koch

and hitting return a few times should give you the usual ok. prompt.

Now we want to send a few Forth words to the target – to set up the GPIO for simple input and output commands

Here is the text we will send:

: P1IN  512 c@ ;
: P1OUT 514 c! ;
: P1DIR 516 c! ;

: P2IN  513 c@ ;
: P2OUT 515 c! ;
: P2DIR 517 c! ;

: P3IN  544 c@ ;
: P3OUT 546 c! ;
: P3DIR 548 c! ;

: P2LEDSET 255 517 c! ;
: LEDNUM 515 c! ;



Using a text editor, copy this text and create a text file called chipstick_init.4th

This can also be saved for the moment in the TeraTerm root directory

The first nine definitions just allow us to write values into the GPIO registers, or read the state of the input pins.

For purposes of introduction, I have chosen to make all of Port 2 an output port, with LEDs connected via 270 ohm resistors – see photo:

The P2LEDSET word just sets all of the Port 2 lines to outputs.

LEDNUM takes an 8 bit word off the stack and sends it to Port 2 – thus causing the LEDs to light up according to the binary number value sent.

LEDON and LEDOFF alow the single, user LED on P3.1 to be turned on and off.

The last two lines of the file are immediate operations, to be executed as soon as the file is loaded.  P2LEDSET will make all of Port 2 outputs, and 170 LEDNUM will set the LEDs to an alternate on-off pattern – as 170 or AA in hex is binary 10101010.

We now send this file to the ChipStick, by selecting the Send File option from the File menu on TeraTerm.  Select the chipstick_init.4th file that you saved earlier and press send.

It will be sent line by line to the ChipStick – which will respond with ok. as each line of source code is compiled into memory.

The process takes under 1 second – and you can then use “words” to see that the new definitions have been added to the dictionary.

If all is well you should see this:

The new word definitions are now in the dictionary – and you are free to use them as you wish:

63 LEDNUM  will light up the bottom 6 LEDS

you can even try small binary arithmetical or logical operations and display the results on the array of LEDS

6 7 + LEDNUM

Mecrisp Forth is not case sensitive – so lednum and LEDNUM are the same word.

An Improved Uploader Script.

If you are using TeraTerm, you can take advantage of Jean Jonenthal’s Teraterm Mecrisp Upload Helper script that speeds up the source code transfer, by actively detecting the ok. prompts from the compiler before sending the next line of source code. This allows the transfer to run at the full baudrate – without the need for the line delays – which may be up to 50mS.

In addition to removing the need for line delays, the script ignores comments in the source code and also recognises the word “include” so that other source code files can be added in.  It is very useful for uploading larger projects with source code across several files.

The script may be found here via github

Save this .ttl file into the root directory of TeraTerm.  When you want to upload a source file to the ChipStick, you run this script as a macro.  It prompts you for the filename of your source and confirms that you want to send.

Next Time

In the next posting we look at the use of the SPI bus and using shift registers to extend the I/O capability.

If you wish to catch up on the series of Chipstick posts – you can find them from these links:

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


I2C Hex Keypad & 8 digit Display – about $2.50

Early computers traditionally had rows of indicator lamps to show the state of their registers.  This allowed the service engineer at a glance to check that a program was running, and by single stepping through the code, one could see the effect that the instructions had on, for example, the contents of the accumulator. For low level debugging and diagnostics, a row of LEDs takes some beating.

PDP-8 Front Panel – Indicator Lamps – from about 1965

However, it’s about 40+ years since LEDs were fitted to the front panel of mini and microcomputers – which makes them somewhat novel these days.

As a proponent of the Neo-Retro, I set about investigating ways in which LEDs could make a comeback.

The iconic Altair 8800 – from 1975

There are already some fantastic devices out there that use LEDs to great visual effect – such as RGB matrix tiles, POV displays and 3D LED cubes.  A trawl of YouTube reveals some wonderful creations. However, lets start at the beginning and look at the illuminating relationship between computer memory and LEDs.

Shift Registers

Starting with the humble shift register – for example the inexpensive 74HC595, one of the simplest forms of memory. A string of 8 D-type flip-flops connected in series.  As the clock signal rises, whatever the state of the serial input pin at the clock transistion, is copied into the first D-type of the chain. At the same time, the output of the first D-type is copied to the 2nd stage and so on. After 8 clock pulses, all of the D-types have refreshed data, and the previous data held in the register has been clocked out of /H pin.  The diagram below illustrates this in a 4 bit shift register.

shift register
4 bit Shift Register – Internal Workings

It’s taken me 5 sentences and half a lifetime, to discover and describe the elegance of the shift register. It has a low transistor count and this made it popular amongst the early computer designers.  With 74HC devices, the clock can reach the order of 100MHz – plenty fast enough for most purposes.

Shift registers are cheap – as low as around  $0.05.  Though compared to other forms of memory – this is a very high cost per bit!

The 74HC595 has the advantage of a separate 8 bit storage register, so that previous results can be held in the register, whilst other data is being clocked through.  This storage function is very useful when cascading registers, in applications such as driving RGB LED arrays.

So we have an easy to use, versatile storage element, onto which we can connect some LEDs, and we can drive it with simple bit-banged port pin output routines, or use a dedicated SPI interface.

From Paul’s Electronics – wiring LEDs to 74HC595 

So on a  breadboard, we can put a shift register, 8 LEDs with current limiting resistors and start to write light sequencer patterns to the LEDs. But wait, the illuminated LEDs are only mimicking the value of the bit pattern stored in the register – so at a glance we can read the value of the data held in the storage register.

Now if we had a bunch of registers, and enough LEDs, we could set up a series of LED arrays, and use these to show the data contained in certain internal registers within the processor. Fortunately for us, there has been a small revolution going on with LEDs – and they are one of the cheapest components on the planet.  There are also some really innovative ways of packaging and driving LEDs – which makes them so much more fun – very low cost and much simpler to use.

7 Segment Displays

These have been around for about 50 years – and were certainly used to effect on the 1965 Apollo Guidance Computer DisKey unit- but not necessarily using LED technology.  They are now ridiculously cheap and available in a wide variety of colours, sizes and digit configurations.

Apollo Guidance Computer DisKey Unit – using 7 segment displays

Red is the most common colour, but green, orange, yellow blue and even white are also available.

Size refers to the visible height of the illuminated digit – available from about 2.5mm to 125mm (0.1″ to 5″).  Some large outdoor displays – such as fuel signs at filling stations and public clocks also use a 7-segment arrangement – sometimes LED or lamp, but also using solenoid driven reflective flaps – that appear either light or dark.

Traditionally the segments are arranged in an “8” shape and given a specific naming convention – called by lower case letters a to g.  The decimal point, if available, is often labelled as dp.

Digits are available as single units or in multiples of 2, 3 and 4 (possibly 5) – and they butt together neatly so you can build up displays of whatever pattern you wish.  The front face of the display is often painted in black – for good contrast and to reduce reflection.  7 segment displays are often placed behind coloured acrylic, masked with screenprint ink – which allows just the digits to show through, with superior contrast – but hides the workings behind.

7 segment displays have been widely forgotten – as they have a much greater power consumption than LCD technology. Allow about 20mA per segment – but remember that though multiplexing it will not be on continuously.

Here are some typical generic 7 segment displays from China.

A Single 0.56″ digit – showing size, common cathode (top) and common anode (lower) – about $0.05
4 Digit – 0.56″ 7-Segment Display Module – about $0.19

So why not consider 7-segment displays for your next project, possibly your own miniature Apollo Guidance Computer on an Arduino shield or something quite different – whatever it might be…….

A little inspiration – this time from 1985!


Fortunately there is a neat trick we can do, so we don’t need n shift registers to display n – bits, as this could get quite expensive.  Suppose we have a 7-segment display with segments A to G, with the decimal point (DP).  We connect each of these segments to the outputs of our ‘595 shift register via current limiting resistors – and with a binary to 7-segment look-up encoded in our firmware, we can display up to 256 patterns of illuminated segments on our digit – of which about 50 might be useful.

If we add another digit, we could just add another 74HC595 to drive that one’s segments – however, because of the persistence of vision (POV) we can quickly flash up a digit on display 1, then turn that off, and use the same ‘595 to drive the segments of the 2nd digit.  7-segment displays are wired internally to allow for this – and are known in the trade as either common anode (CA) or common cathode (CC).

If we have say a display consisting of 8 digits, we connect all the segments to their own “segment drive” output on one 74HC595, and then use another ‘595 to enable each of the digits in turn  – by pulling down and sinking current out of the common cathode of each digit in turn.  Only 1 digit is illuminated at a time – and for 1/8th of the total display cycle. POV does the rest for us – and it appears that the digits are on all of the time.

The same trick can be applied to the 8×8 LED arrays. One shift register is wired to drive the rows, and the other turns on the columns – in turn. The second shift register is driven with a series of values that only energise one column at a time.  If it is sinking current from a common cathode display it needs the following repetitive pattern:


And for common anode – we invert the polarity of the bits so that the register sources current into the common anode:


You will notice that these sequences are easily programmed in C using either repeated addition (doubling) or bit-shifting.

So just two of the 74HC575 devices will drive an 8×8 LED array – about $0.20 of hardware.

And For My Next Trick……

There’s yet another neat hardware trick that we can do.  We can use the above scan pattern to generate the read sequence required for a keyboard matrix.

Assume that the keys are arranged in an 8 x 8 grid.  We apply the above scan pattern to the rows, ad then use another shift register – this time a 74HC165 wired as a parallel to serial converter,  to read the columns. When a key is pressed, it shorts a row to a column, and so the brief scan pulse appears on the column input of the ‘165.

In our code, we first write the scan pattern, energise the display segments, then read back the data from the ‘165 column shift register.  If a key is pressed it will appear as a 1 in a particular bit position of the ‘165 register.

This is a very economical way to multiplex  7 -segment displays and scan a key matrix. Just two output shift registers and one input register.  It has been in use at least since the mid-1970s – and possibly earlier – applied to vacuum “Nixie” tubes.

Fortunately this functional requirement is very common – for example in cash registers, and machine automation systems – so the function has been integrated into an easy to use IC – available from various manufacturers for a few cents.  Each offers different numbers of display capabilities and keyscan matrix options. Whilst you can drive these from shift registers, there are some really neat, low cost ICs available to make your job a lot easier.  These communicate generally via I2C and are useful for driving either arrays or 7 segment displays. Some also have the means to scan an array of keyswitches. It all makes interfacing to your microcontroller a lot easier.

Display Driver ICs

The Holtek HT1632C is typical of the low cost display driver ICs – and will drive 24 rows by 16 commons.  It’s worth a look at the datasheet for full details.  The HT1632C is a ubiquitous IC in the Shenzhen markets – costing around $0.50 in 1 off. It is however available only in a 48 pin or 52 pin LQFP – so you will need a LQFP adaptor to use this in a breadboard.  Having recently paid $8 for a QFN adaptor from the US – I was delighted to see these available in China for around 11 cents!

There are other driver ICs available – from Holtek and other manufacturers.  The HT16K33 will drive up to 128 LEDs and scan up to 39 keyswitches. Conveniently there is a little breakout board available from Adafruit for the 16K33.  It’s $6 in the US or under $1 in China for a lovely purple pcb – a rapidly becoming popular colour choice for pcb solder resist.

HT16K33 Breakout – An Adafruit Design – Significantly cost reduced in China!

If you don’t have many LEDs to drive – there is the very economical TM1638.  This is about 12 cents and will scan up to 24 keyswitches.  It’s available as a built up board containing 7-segment displays and low cost tact switches. It will drive 8 x 7 segment digits plus 16 individual LEDs – all for under $2!

I2C driven TM1638 on a pcb with 8 x 7 segment, 8 LEDs & 8 Switches Yes – that really is $1.86!

The TM1638 has a sister device – the TM1639 that will run 8 x 8 LEDs and scan up to 16 switches – this time in a more breadboard friendly  DIP24 package.  The datasheet in Chinese has suffcient diagrams and English text to allow you to make a good understanding of how it is deployed – including example circuit diagrams.

Another useful part is the TM1628 – It will scan 20 keys and drive up to 10  segment digits – see below

You can but these ICs already fitted to a board complete with 7 segment displays and switches. The innovatively named “LED & KEY” pcb – below, is one example of a fairly generic design – from as little as $2 in the markets.

All of these items were located via – the Chinese equivalent of Ebay. The TaoBao search engine now recognises English text – and for the reverse translation – let Google translate the page.  So lots of cheap hardware is available – you just need to know where to search online for it!

LED Arrays

For a few tens of cents, you can buy a variety of LED arrays – either with single colour LED,  bi-colour or RGB. These are generally in 8×8 arrays using either 3mm or 5mm LEDs – but there are some using 1.9mm LEDs  – which means a smaller physical size – or more LEDs in a given size package.

Typical Datasheet for a common anode LED array

For, me, the 16×16 array of red LEDs in a 40mm square package holds the greatest potential – and I will look at this later – in the meantime – here’s what they look like.

16×16 Red LED Array with change from a $6 bill!
16×16 array – and a HT1632 driver IC – all in one module

Finding the Chinese search term – or the generic name of the part is half the battle. For example, one item of interest is the YK-788BS 1.9mm 8×8 LED array. Adafruit sell these for $3.95 but the market price in Shenzhen is closer to $0.30.  You just need to know that a TaoBao search on 788BS is going to find most of the references to this part.

These miniature 8×8 LED arrays have a 16 pin DIL pinout – so you can breadboard them easily, and stack them side by side on stripboard to make larger arrays.  You could easily construct  a 16x 16 array, with 2 off HT16K33 driver ICs for well under $5. Here are some I bought recently, with the proposed EagleCAD layout below.

Half Size 20mm x 20mm LED Arrays $0.29 each!
8×8 LEDS arranged into a 16×16 LED Array Shield with 2 x HT16K33 drivers ICs

Shopping Around

I do a fair amount of purchasing in and around Shenzhen – so it helps to have contacts over there who understand electronics, understand the language and culture, have local knowledge of the main markets and who can do business on your behalf.

If you want to source components from Shenzhen markets – I recommend Man Friday. They are a relatively new company offering personal shopping for component sourcing and shipping services.
Contact Toby Yu for details – and mention my name, Ken.

Toby has excellent English –  he used to teach English in High School, and will go out of his way to help you with your sourcing and manufacturing logistics, as well as offering Shenzhen meet and greet, factory visits, language translation, business negotiation and overseas shipping.

Daniel Bailey’s C88 – A computer with just 8 bytes of memory!

This is a neat project by Daniel Bailey of York Hackerspace. It is loosely based on the Manchester SSEM “Baby” but uses a single 8 x 8 LED matrix to show the entire contents of its 8 byte RAM.
Daniel wanted to build a simple processor  from the ground up using a FPGA.

He illustrates his project here  

Daniel has subsequently sourced a 32 x 32 RGB matrix – and is building a machine replica of the Manchester Baby SSEM.

Whilst Daniel’s full colour RGB panels are still quite pricey – they can be found in China for about $30 to $45 and also through Adafruit.

For my experimentation – I will be using a more modest display – based on the 16×16 40mm module – but actually more economically constructed from 4 of the 20mmx 220mm 8×8 788BS modules with 16K33 drivers  These can be arranged quite cheaply to make a 32x 32 array, allowing the Manchester Baby to be simulated – for around $20 of hardware, or to single step through a very small window of code on your latest ARM processor.

With a 32×32 LED array with variable LED brightness control – it may also be possible to recreate an early Baird Televisor – with slowscan mechanically scanned 30 line TV!

The combination of innovative LED array products, low cost, easy to use driver ICs and access to the low cost markets of electronics Shenzhen, has made all of  these devices far more available to hobbyists.  They are now such a cheap and easy solution – that there is now very little reason not to use them in your next project.

In the next part we look at driving the 16×16 LED array – and using it as a unique insight into the inner workings of our retro computer.

Links to Related Topics.

Background on Manchester Baby SSEM

Occasionally, moving within the open hardware circles, you stumble across a really neat bit of technology, affordable, well thought out and well implemented, and you think, yeah – wouldn’t it be cool to do something with that. Unfortunately, as is the case with most things, you find yourself too busy to strike whilst the iron is hot and the cool things get left – to cool.

The Parallax Propeller

Well, that was my first reaction when I came across Chip Grasey’s Parallax Propeller chip. It’s been around for about 10 years now, and it was a hot product when it first came out, and it can still hold it’s own against the far more mainstream processors.  It is easy to program with minimum amount of kit, provides video and audio output and has a multitude of purposes.

The IP for the Propeller core, was released to the Open Source Community in August 2014 – with full Verilog source available – so you can take an inexpensive FPGA dev board and create your own devices with the Propeller 1 core.  The core supports a 64K long word address space – and with a suitable FPGA platform – such as the Pepino board by Saanlima Electronics, the Propeller could be emulated at

The architecture though novel, is well thought out and it is a sufficiently powerful platform to warrant being studied in electronics and computing degree courses.

In recent posts, I have remarked about the elegance of the 40 pin DIL package, for it’s simplicity, ease of handling, breadboard friendliness – and it is no surprise that the Propeller is available in a 40 pin DIL package. It is also available as a 44 pin LQFP and a 44 pin QFN – for applications where space is tight.  All packages provide an easy to remember, very logical pin-out, which for the 40 pin DIL package very effectively mitigates against the possibility of reverse insertion into the socket.

The minimum hardware set-up is trivial – the IC supports everything that you need for an easy to use, quick to set-up multicore microcontroller.

Propeller is Almost Ready to Fly – Minimum Hardware set-up

Propeller has an interesting architecture, consisting of 8 separate 32 bit cores – known as Cogs. These can be individually allocated to hardware intensive tasks – such as video generation, pwm and waveform synthesis and signal analysis.

Propeller can be programmed in assembly language, or a native bytecode interpreted, high level language called Spin.  Additionally for C programmers there is a Propeller-GCC,  other high level languages include Pascal, BASIC and several versions of Forth.

Propeller ICs may be interconnected using high speed serial communications interfaces to extend to a multi-processor system.

I’m not even going to try to describe the full feature set – for that we have the Propeller Wikipedia entry and the extensive documentation on the Propeller Site – including the User Manual and Datasheet.

The Propeller is available in DIP 40, LQFP-44 and QFN packages.  It is stocked in volume by Digikey and Mouser – starting at around $7.99 in 1 off.

What makes Propeller Interesting?

A novel 32-bit architecture – that is now fully open, and can be implemented using various FPGA platforms.

Innovative, scalable hardware – particularly for on-chip video generation. A new Propeller 2 offers higher speed and more Cogs.

Offers a “1980’s micro” on a chip. Provides a singe chip solution for low cost products requiring video, audio, SD card, PS/2 keyboard & mouse.

Extendable to multiprocessor arrays – using high speed comms.

May be used as a companion device to another microcontroller – see Micromite Companion.

The bootloader and bytecode interpreter are written in Propeller assembly language, and could be modified or extended. For example to provide bootup from an SPI device or to extend the bytecode language.

Character Set

The Propeller has a versatile character set – clearly designed with engineering purposes in mind.  A collection of standard ASCII characters, electronic schematic symbols,  timing diagram elements, mathematical symbols and Greek alphabetical characters. The characters occupy 16 x 32 pixels, offering a chunky, though very readable display.  With small additions and some custom characters the Propeller could be used for mathematical report writing, schematic capture (electronic circuit design), digital timing analysis and pcb layout.

In the next part, I put together a 50x50mm pcb to carry the Propeller IC plus VGA output, PS/2 Keyboard and mouse.

0 0

Creating a new Universal Expansion Board  “UXB-101”

For some months I have been creating new designs using a 50mm x 50mm standard shield format – which adds an extra 8 pins to the familiar Arduino shield, and constrains it to just 50 x 50 mm – for minimum manufacturing cost by some of the Far Eastern pcb manufacturers.

I am currently evaluating several different microcontrollers for various projects I have running at the moment.  Some of these can be done quickly cheaply and easily on a 2 x 2″ board – but it only takes one 40 pin DIL or 44 LQFP to swamp the pins availabe on that format.  Increasingly there is the need to access more signals or just put much more circuitry on board. I have been using Arduino and Arduino MEGA for the best part of 5 years – and whilst the “bodged” pin-out sometimes infuriates me – the shield format is simple and easy to work with.

The 50×50 format has worked out well for small designs, but the time has come to extend it – particularly in the requirement of larger pin-count microcontroller and FPGA devices. At the same time I wanted to keep it nominally compatible with Arduino and Arduino MEGA – because of the vast number of shields and other boards that utilise these formats.

So I have added some extra at either end to make a 50mm x 101.5mm board (approx 2″ x 4″) – that has a much greater pin count and increased area for circuitry. It retains Arduino and MEGA compatibility and provides an additional 26 pins more than the Arduino MEGA format.

The name UXB-101 comes from “Universal Expansion Board” 101mm long and that there are 101 useful signals.

Unfortunately it is not possible to shoehorn this board any tighter to get it to fit onto a 100mm board size – to take advantage of the 10cm special offer from some board houses. However, the 10 off price for this board is $2.30 from

Details of Pin Out

The board has 6 generic 16 bit ports labelled A to F – these have been derived from the Arduino naming

Port A   Analogue
Port D   Digital

For the Port C and D headers, the following suggestions loosely apply.

Port  C  Communications  (UARTs, SPI, I2C etc)
Port  B  “Buttons”

To which I have added E and F  – which are the additional signals found in the double row header at the end of the pcb.

Ports E and F are ideally suited for bus applications – where large numbers of signals need to be connected between a series of stacked or backplaned boards. Applications might include 16 address and 16 data lines,  R,G, B digital video plus sync & control lines, HDMI data etc.

To accompany these “backplane” connectors, there are 4 “Identity” pins  I0 – I3  – these may be used to connect an eeprom or other means of identifying the shield.  They are located at the very bottom of the 2 row header – in a location not used by the MEGA. They could be used as a board select address – allowing one of 16 boards to be selected in a backplane.

5V and 0V accompany the backplane – and it would be likely that each board would have its own 3V3 regulator to step the 5V down to the required level.

The board has been designed for simplicity and versatility. It maximises the amount of space available for the placement of large packages, and can be used as a stand-alone, stacked or in a backplane type application.

New Universal Expansion Board  “UXB-101”


This board is large enough to accommodate devices in the order of 144 pins, and for some applications – where 30 lines or more are needed to drive a LCD, or large pin-count FPGA packages – larger devices may be used.

The board is not restricted  to microcontrollers or FPGAs – there are sufficient pins available to host a variety of other devices, such as large SRAMs, video controllers or any ICs that have a high-pin count – and the requirement to break those pins out to a 0.1″ user friendly spacing.

The board may be fitted with standard or “extended” 0.1″ female headers, and for backplane connection – a right angled 2 row “box” header could be used.

The board can be used with half-size breadboards – such as the SYB-46 or other 270 or 300 tie-point breadboards – which fit neatly between the rows of headers.

Some Proposed Projects

It is relatively straightforward to port any microcontroller breakout board design to this board format.

My STM32F746 based “BoB”design of last Summer is an ideal candidate.  The A, B, C, D, E and F port allocations allow the peripherals to be grouped by function to some extent, rather than by pin number.  So if all the pins of the mcu that support ADC, op-am or comparator function are located on Port A, (Analog),  all of those with timer function are on Port D (Digital),  all of those with UART are on Port C (Communications) – etc – this then makes the board fairly compatible with Arduino shields  – regardless of what microcontroller is used. Remember to make sure that at least one UART, SPI and I2C is located on the “original” Arduino pin allocation – to ensure backwards compatibility.

Here are a few of the Breakouts I have in mind:

ARMduino GIGA  –  An Arduino compatible board using a 216MHz STM32F746 ARM Cortex M7

Enterprise              –  A multipurpose board to help teach electronics and computing science. Features LEDs, switches, shift registers etc.

Spartan 6 Breakout   – A breakout board or shield assembly for the popular Xilinx Spartan 6, 144 pin FPGA. Compatible with Gadget Factory’s Papilio DUO 

MSP430FR5994 Breakout   – a board to host the new MSP430FR5994 256K FRAM based microcontroller.

Propeller P8X32A Breakout  –  a projects board for the Propeller chip – as discussed in an earlier post.

Gnome –  A multiprocessor experimental machine based on multiple Propeller 1 architecture – either using P8X32A ICs intercommunicating via high speed serial comms – or alternatively implemented using several FPGAs.  Arranged as a “backplane” system – styled loosely on Cray-1.  “A Barbie (and Ken) Sized Supercomputer”

Now that we have a big new, blank canvas, we can start to design some exciting new gadgets.  Later posts will look at the various designs that make direct use of the UXB101.

Whilst the design I have presented is minimal, it can be augmented with extra features such as mounting holes, other permanent features – eg extra components such as LED & reset switch, voltage regulator etc. Then we could use a modified board outline – so as to allow incorporation into other designs.

Handouts and Downloads

Examples schematic and board files of the blank UXB101 pcb created in EagleCAD have been uploaded to my Github Repository

older | 1 | …. | 6 | 7 | 8 | (Page 9) | 10 | 11 | 12 | newer

Posted in Uncategorized | Leave a comment