A Review of Tiny Languages - Part 2

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:

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


SIMPL

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.

Typing

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:

a    ANALOG
b    BLOCK
c    CALL
d    DIGITAL
e     END
f     FOR
g    GOTO
h    HIGH
i     INPUT
j     JUMP
k    COUNT
l     LOW
m   mS_DELAY
n    NUMBER
o    OUTPUT
p    PRINT
q    QUIT
r     RETURN
s     SAVE
t     TIME
u    uS_DELAY
v    VARIABLE
w   WHILE
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 26x8 = 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.

Nano Computing

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

Open Source tools for FPGA Development

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:

IcoBoard

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.

Projects We Love

It's been busy here for the last few months as I try to push ahead with some of my own construction projects.  This post is a summary of some of the things I have been working on recently - trying to tie up some loose ends, in the grand scheme of things.

Regular readers may know that I am working on a high resolution video board "Evita" which will enhance even the modest of 8 bit microcontrollers. This is only one small part of the overall project plan - ultimately a series of educational and fun, open source products aimed at teaching and learning.


Open Inverter

This is a project done in collaboration with Open Energy Monitor. The plan is to explore smarter ways to utilise very modest amounts of energy to run basic digital infrastructure - such as laptop or tablet, wireless router etc. This might be in countries where the grid is either not available - or intermittent, or on a remote camping trip where conventional power is just not present.  It could be used for small scale solar energy systems, micro hydro or any number of battery power control applications.

I am putting together some building blocks for the "Open Inverter" project - which is an attempt to build a simple, low cost open-source low wattage, micro solar inverter.  The project explores the interface between power electronics and microprocessor/firmware control. In addition to functioning as an inverter, the aim is also to produce boost converter, buck converter, battery chargers and dc motor drive designs - all using the same kit of parts.

50x50 PCB Format

In order to allow rapid and low cost design developments, I have also devised a new compact pcb format - based on a standard 50mm x 50mm board size.  This board incorporates the Arduino style pin headers, plus another couple of connectors to increase its versatility.

The first project for the 50x50 board format was the H-bridge pcb - based on a common H-bridge driver IC and standard TO220 sized N- type mosfets.  This board is now being tested - and starting to show promising signs of life, having been tried first this week as a speed controler for a 100W dc motor.

The Open Inverter will also require a microcontroller board - and the first of the planned boards is an 8-bit AVR board based on the ATmega1284P.  Combined with a choice of wireless modules (ESP8266, RFM69)  and a microSD card  - this is a powerful monitoring and control board.

The '1284 board is the first of a planned series of small microcontroller projects - all based on the 50x50 pcb format.  Others in the pipeline are the STM32Fxxx range of ARM Cortex processors from ST Microelectronics.  I have 50x50 compatible designs for M3, M4 and M7 processors - it's just a matter of getting on and laying them out.

The 1284 is an 8 bit 20MHz part.  The oters mentioned are all 32bit - with clock frequencies between 72MHz and 216MHz  - which offers a wide scope of performance.

The 50x50 board format is small, neat and cheap to build. Additionally - there's only so much that you can put on a 50 mm square pcb - so a design is often completed within a weekend.


The Cambridge SEM Project

A good friend in the Open Hardware community has recently acquired a Scanning Electron Microscope - by Cambridge Instruments - about 1985 vintage.  The basics are all working, so the plan is to produce an add-on video capture and record system - allowing videos to be digitised and stored - hopefully using open source hardware.  This will be a major undertaking involving fast video data acquisition, frame stores and a lot of software.

It will not happen all at once, but I have already started looking at video acquisition and fast ADCs, plus the Evita video display board. The plan is again to use the 5050 format pcbs and make the system modular.  The project is an excuse - should I need one, to play with a SEM - and also learn a bit about fast data acquisition.


NAND to Tetris (N2T)

This is a very comprehensive course that teaches the basics of building a modern computer system from the ground up.  Through a series of self contained study modules - the student learns the heirarchy of digital logic and software systems.  For some time I have thought that this course could benefit from having some accompanying hardware - so that the systems can be but for real - so I am currently looking at how FPGA programming in VHDL, verilog can be taught concurrently with the NAND to Tetris course - so the student can build a real computing platform.

Project Oberon 

This is related to the N2T course above. About 30 years ago, Niklaus Wirth, the creator of Pascal devised a new computing platform, operating system and compiler tools for a language he called Oberon.  The platform can now be implemented cheaply (<$100) in an FPGA and could provide an ideal basis for the studying the N2T course above.  Moreover, Niklaus Wirth has devised a new FPGA hardware design language called Lola-2  - to run on the Oberon platform.  So we are getting close to the point where an open source workstation can be used to create new FPGA designs.

It is hoped that N2T and Project Oberon may be combined in some form to provide a much needed new means of teaching technology to students.

Magnus Karlsson of Saanlima Electronics has just annouced a new FPGA board Pepino - aimed specifically at Project Oberon and instrumentation - such as logic analysers.

I have just ordered one of the Pepino boards with a Spartan 6 LX25 FPGA and 2Mbyte of fast SRAM - watch this space.

Open Source Tools and Equipment 

The electronic engineer relies on certain instruments and design tools for his or her everyday work.

For example in the electronics lab, a multimeter (DVM), oscilloscope and logic analyser are often needed.  What if these otherwise comple pieces of equipment could be easily created from low cost FPGA or ARM technology, possibly using a $50  7" tablet to display the results.  With a modern internet connected tablet, data could be stored in the cloud for further processing or distribution. An experiment done in the lab on one continent could be shared instantaneously with others around the world,  with Skype, YouTube and Periscope we have the means to distribute valuable learning experiences to anyone who can access the internet.

Here's the Pepino FPGA board being used as a logic analyser

At the same time as encouraging learning skills by building real hardware, there are equal opportunities for computer science students to create open source software tools which would be invaluable for engineering design.  Tools such as 2D and 3D CAD packages, 3D printer file converters, Printed circuit layout tools, circuit simulators and IDE packages for programming the latest chips with code..

I the last 10 years, since Arduino was first created as a teaching aid, we have made great strives with ever increasingly complex systems.  We need to find new ways of training and educating people so that they can get the most out of rapidly evolving digital systems, creating a new generation of coders, makers, hackers and engineers.

I can't expect to do everything on this list myself, that is why I am involved with some extremely smart, capable people - experts in their own fields.  Hardware, software, firmware, making - the list is wide and varied of the individual skills needed to make great things happen.

If you have read anything above and you would like to know more  - or have something along similar lines you may wish to contribute - please feel free to leave a comment, or contact me via email or @monsonite on Twitter or Ken Boak on FB.

Open Inverter Part 8 - a General Purpose ATmega1284 Microcontroller Board

Versatile ATmega1284 board with Wireless, microSD card and USB interface

An update on the original originally posted on January 21st 2016

Open Inverter Controller Board

Recently I have been using some of my WiNode 4 boards as general purpose "Arduino Like" dev boards, whilst working with the FT812 video board and controlling the Open Inverter Power Board.

The WiNode is a good little workhorse - but with the needs of the Open Inverter Project, I decided that it would be better to take the best parts of the WiNode and update it - so as to be a better match for the Open Inverter H-Bridge circuit - which is also on a 50x50 format pcb.

The WiNode is close enough in configuration to an Arduino, but benefits from a uSD card, an RFM69 low power wireless transceiver, some non-volatile SRAM and a real time clock.

Additionally WiNode had a dual H-bridge driver - useful for driving Mosfets, or switching relays or fans.

One of the main limitations with Arduino is the lack of SRAM - and so one of the projects on my list was to update the WiNode 4 to use an ATmega1284P (datasheet) - which has 16K of SRAM, 128K of Flash ROM, and an extra UART.  The ATmega 1284P comes in a 44 pin TQFP package which has sufficient pins to give it four, 8-bit ports - so there is the benefit of some more I/O and an extra 2 ADC lines.

The WiNode 4 is a through hole kit, which makes it easy to build, but the time has come to move away from through hole designs and get the greater circuit density that surface mount packages offer. Taking advantage of my new 50mm x 50mm pcb format, I decided to spend some time updating WiNode to make full use of the additional resources available on the ATmega1284P.

Features.

The ATmega1284P is arguably the best of the small 8-bit AVR devices in terms of features.  It has been described elsewhere as the "Goldilocks" of the ATmega line-up. Not ony is it available in a breadboard friendly 40 pin DIL package (the largest of the AVRs in this package) but with extra timer, interrupt, 32kHz oscillator - plus the huge by comparison memory - it is one of the most useful.  It is a shame that in 2009 when Arduino launched the MEGA - that they didn't consider using the 1284P - as a "mid range" offering. This blogpost from Winter 2011 sets the scene regarding the ATmega1284.

I wanted to create a compact, general purpose Arduino compatible pcb that could be used for a wide range of applications. It would make use of the following additional features offered by the '1284P

• 32 GPIO pins - arranged as 4,  8-bit ports
• Extra interrupt input INT2
• Additional USART
• Extra 2 ADC channels - for battery monitoring
• Extra Timer T3
• 32kHz external oscillator - to implement RTC
• Extra Flash (128K)
• Extra RAM (16K)

To do this, the following hardware was considered:

• RFM69 low power wireless module - (RFM12B footprint compatible)
• Lithium battery support including boost regulator and battery charge controller
• 32K battery backed SRAM for general purpose storage
• Mini Ports - two, 4 x 2 connector with PWM, ADC and power to support other hardware *
• Real Time Clock - MCP79410 - can wake up the mcu at regular intervals.
• microSD card - for datalogging, program storage etc.
• Extra UART channel - used to communicate with optional ESP8266-01 WiFi module
• 40 pin 0.6" DIL socket to allow optional use of DIL version of  ATmega1284P

Fitting all that onto a 50 x 50 pcb was a bit of  a challenge - and having done the basic route by hand, I left it up to the autorouter to do the donkey work.

Whilst the ATmega 328 used in the Arduino has 6 Analogue pins and 14 Digital,  the ATmega1284P has 8 Analogue pins and 24 Digital.  These are arranged as  8 bit Ports A, B, D and D.  Fortunately the 50x50 board format has 6 additional  header pins which are used to accommodate some of the extra pins of Port C - that are not present on the smaller device.

Board Layout

The surface mounted ATmega1284P is in the centre of the pcb, and is pinned out to a conventional 40 pin DIL footprint. This not only gives easily accessible probing points for all of the pins - but also aids connectivity during pcb layout - as all of the pins are routeable from both the top side and underside of the pcb. 

At the top and bottom edge of the pcb are a pair of 4x2 headers.  These are to allow a pair of the experimental Open Inverter H-bridge boards to be plugged in and controlled by the '1284P.  The headers are a mirror image of one another allowing one H-Bridge to be stacked below the controller, and the other stacked on top - effectively making a sandwich arrangement  with the controller in the middle as the "filling".  Each header carries a pair of complementary pwm signals, two analogue inputs - for current or voltage measurement and two general purpose GPIO pins for driving relays, fans etc.

The WiNode was originally designed to be a universal wireless sensor/controller board - made compatible with the JeeLabs RFM12 library and compatible with JeeNodes and the Open Energy Monitor range of devices.  I have continued this approach - but upgraded the RFM12B to the more capable RFM69 - which shares the same footprint.

In addition I have also added a dual row socket to accept the ESP8266-01 WiFi device.  This will allow this board to act as a bridge between WiFi and the RFM low power wireless ecosystem.

Applications  

As stated earlier - this board has been designed to act as a controller for the experimental Open Inverter Project.

It's main function is to carry out the safe drive up to two H-bridges and monitor the currents and voltages when the inverter is operational. The inverter is sufficiently flexible to work as a buck and boost converter - allowing dc to be transformed.

The on board RFM69 (or ESP8266) allows the voltage, current and temperature readings to be conveyed to either EmonCMS, Emon-Pi or a wireless router.

The board is capable of being  battery powered from a lithium or other (alkaline) cell  - as it has a boost converter that works down to 0.6V.

The board may also be used as a stand alone battery powered multi-channel datalogger.

Circuit Description

This is all very standard Arduino stuff.  ATmega1284 running from a 3V3 logic supply and running at 16MHz (- proven to work reliably  - despite what the data sheet suggests).

In addition to the standard FTDI cable 6 pin connector for power, debugging and serial UART connection, there is the option of a USB- virtual serial port connection - provided by the CH340G - a low cost alternative to the FT232R.

The GPIO is pinned out in a way that is similar to the Arduino - but certain differences between the allocation of the peripherals to the ports, means that the '1284 is a little different to the '328. The pinout of the processor is below:

Main Peripherals:

Analogue Inputs:  PA0 - PA7
SPI port:  PB4, PB5, PB6, PB7
I2C port:  PC0, PC1
UART0   PD0, PD1
UART1   PD2, PD3
Timer 0:  PB3, PB4
Timer 1:  PD4, PD5
Timer 2:  PD6, PD7
Timer 3:

Physical Pinout of the ATmega1284P GPIO

List of Allocated Signals

First the fairly standard Arduino pins - except that the Timer outputs are relocated, and there is also an extra INT2 on D8:

D0  RXD  (UART 0)   T3 (Timer 3 clock input)
D1  TXD  (UART 0)
D2  RXD  (UART 1)  (ESP TX) INT0   (RFM69)
D3  TXD  (UART 1)  (ESP RX) INT1   (RTC)
D4   OC1B  (Timer 1 Outputs)
D5   0C1A   (Timer 1 Outputs)
D6   0C2B   (Timer 2 Outputs)
D7   0C2A   (Timer 2 Outputs)

D8    INT2
D9     OC0A    (Timer 0 Outputs)
D10   SPI SS  OC0B  (Timer 0 Outputs)
D11   SPI MOSI
D12   SPI MISO  0C3A  (Timer 3 Outputs)
D13   SPI SCK    0C3B  (Timer 3 Outputs)

D14   I2C SDA  ( These come from Port C and are no longer shared on analogue inputs)
D15   I2C SCL

A0
A1
A2
A3
A4
A5

These signals are in addition to those normally found on ATmega 328 Arduino.  I have allocated them for general housekeeping tasks.

A6      Battery Volts Monitor channel
A7      Battery Temperature monitor channel

PB0   Timer 0 External clock Input T0
PB1   Timer 1 External clock Input T1

These 6 additional digital lines are taken from Port C  PC2 to PC7.  PC6 and PC7 form the inputs for a 32kHz crystal oscillator.

D16
D17
D18
D19
D20  32kHz crystal (RTC implementer in Timer 2)
D21  32kHz crystal.


Selection of Peripherals

WiNode 5 makes full use of the SPI bus to control the peripheral devices:

RFM69 Wireless transceiver   /CS  = Dig10   Int = D2
23K256 SRAM   /CS =
microSD card     /CS =


The MCP79410 Real Time Clock uses the I2C bus

D14 = DDA
D15 = SCL

Interrupt/Alarm  = D3


Inverter Headers JP1 and JP2

Inverter Header JP1 uses A0 and A1 for current measurement and B0, B1 for miscellaneous control signals.

Inverter Header JP2 uses A4 and A5 for current measurement and A2, A3 for miscellaneous measurement and control signals.

ESP8266-01 WiFi Module

Uses UART 1  (D2 and D3) for communication

Circuit Schemtic and EagleCAD files 

These will be added soon - as the design is finalised

A Simple Computing Platform

Is this how modern computers appear to users - even experts? 

It is becoming ever increasingly clear to me - and others, that computing platforms have become just too complex. In an attempt to be all things to all users they are built on a massive agglomerate of software, some which has it's roots in the 1960s, and most people have forgotten why it was there in the first place. Literally they have become a tower of Babel

Reading the Wikipedia entry - the Tower of  Babel was a huge edifice - so big that no-one really knew how big it was. Ironically it was created, so that everyone living in Babel could speak the same language.  According to the myth, the big chap upstairs didn't like this, and confounded the people's speech, so they could no longer understand each other. He then destroyed the tower and sent it's residents scattering to the four corners of the world, and this led to the diversification of language.

Loosely applying this myth - as an analogy of the current state of the computing industry - we are now trying to recreate a Tower of Babel, as a concretion or conglomeration of thousands of different software modules 20+ million lines of code, 1200 developers/contributors, loosely tied together in a Linux wrapper - in the hope that they somehow will fuse to form a unified entity.

Well just as Babel ultimately failed, I believe that our current strategy of building vast megalithic operating systems - then spending all our time worshiping them, is a road to ruin.

Like I might say to a historical resident of Easter Island "Keep on carving the stone heads, Dude,  - just wait and see exactly where that gets you!".

Here's a breakdown of a recent image of the Debian distribution:

=============================================
    Item           Lines             %
=============================================
  ./usr                 845        0.0042
  ./init              5,739        0.0283
  ./samples           8,758        0.0432
  ./ipc               8,926        0.0440
  ./virt             10,701        0.0527
  ./block            37,845        0.1865
  ./security         74,844        0.3688
  ./crypto           90,327        0.4451
  ./scripts          91,474        0.4507
  ./lib             109,466        0.5394
  ./mm              110,035        0.5422
  ./firmware        129,084        0.6361
  ./tools           232,123        1.1438
  ./kernel          246,369        1.2140
  ./Documentation   569,944        2.8085
  ./include         715,349        3.5250
  ./sound           886,892        4.3703
  ./net             899,167        4.4307
  ./fs            1,179,220        5.8107
  ./arch          3,398,176       16.7449
  ./drivers      11,488,536       56.6110
=============================================

A massive 20.3 million lines of code! As you can see, the Linux kernel is just 1.2% of this total.  It is the drivers - for every conceivable peripheral, and every conceivable processor that makes up the bulk of the bloatware.

Don't get me wrong, Linux plays a very important part of the modern digital infrastructure - but this colossal edifice may eventually collapse under it's own weight.

What about small embedded systems - traditionally coded in C and running from Flash? These high end microcontrollers are generally limited to 1Mbyte of Flash and 0.5Mbyte RAM and clock frequencies of <300mhz .="" p="">
So, if you, like me, are fed up dealing with 15 gigabytes of someone else's software in multiple non-compatible languages then this recent article from "The Register" may be of interest.

Project Oberon

This was an ambitious project started in 1985 to create a simple workstation with it's own lightweight language and operating system called Oberon - a successor to Pascal / Modula 2.  The chief designer was Niklaus Wirth - who also was the creator of Pascal, Modula 2 and other languages.  Here's Wirth's presentation of the historical perspectives of the project.

Oberon is not only a language, but an Operating System that includes a compiler. Remarkably the whole Oberon System, when loaded fits into 110kbytes - making it an ideal fit for smaller cpus with limited amounts of RAM.

Below are the line counts for the various Oberon System modules:

                     LOC.                    %

MenuViewers          208                   4.89
Viewers              216 (outer core)      5.08
Modules (loader)     226                   5.32
Edit                 233                   5.48
Kernel               271 (inner core)      6.38
FileDir              352                   8.28
Oberon               411                   9.67
System               420                   9.88
Files                505                  11.88
Texts                532                  12.52
TextFrames           874                  20.57

Total               4248

Adding these up we see that the whole Oberon System consists of 4248 lines of code!  That's consideraby less than the Linux ./init code. and approximately 1/5000th of the Linux distribution. You will also notice that each module is roughly 5% to 20% of the total.

One reason why this is possible is that the Oberon System has been tailored for one particular - and very simple hardware platform and it is so it is not having to cater for every different processor or peripheral device on the planet.

The Oberon Platform

Originally (1988) the Oberon Platform (Ceres) was based on the NS32532 processor.  This was a 25MHz 32bit processor - one of the first 32 bit devices commercially available.  It had a performance roughly equivalent to twice that of an i386 for the same clock frequency.

Fast forwarding to 2013, Project Oberon has been recreated in the form of a low cost "OberonStation" using an inexpensive Xilinx Spartan 6 FPGA - accomplished by Paul Reed and Victor Yurkovsky - a regular FPGA Blogger.

In this Xilinx Journal "Xperiment",   Niklaus Wirth writes about the FPGA implementation.  He also describes a new hardware description language called "Lola 2" which allows FPGA hardware to be designed on a Oberon Workstation and then cross-compiled into Verilog - from where it can be imported into the usual FPGA development toolchain.

The Oberon Station - Spartan 6 FPGA plus 256Kx32bit SRAMS

If you wish to look further at Project Oberon - a pdf of the 2013 Book is available - with html index here.

Thoughts- and Questions on OberonStation

Less is more - this hones down a workstation to the level of complexity where any one can understand the hardware.  It is reminiscent of Chuck Moore/Jeff Fox's Ultratechnology Workstation in a mouse

The Oberon Station boots from the uSD in about a second - which is impressive. My laptop thinks for about 5 seconds before it even responds to it's power switch.

The monochrome video could be greatly extended  - a Spartan 6 should be capable of generating 1024 x 768 resolution VGA in full 24bit colour, or even HDMI. Especially if it uses 32 bit wide SRAM.

The PS/2 keyboard and mouse are good old simple technology - but, in time may be difficult to get hold of.

Adding a FT2232 to act as virtual com port and the means to re-flash the FPGA would also be useful for development purposes.

The Network Port is intended to take a nRF24L01 2.4GHz transceiver.  A couple of jumper links and it could take an ESP8266-01 WiFi module.

Want to democratise this?  Re-lay it out using a Arduino MEGA footprint or add a Raspberry Pi style expansion header - so that it can use popular & standard forms of shields.

There appears to be a footprint for an SMT or FPC expansion header on the left side of the PCB.

With the right RAM this could be clocked at 100MHz++

What about an ARM Implementation?

The RISC5 appears to be a fairly simple cpu architecture,  the Oberon System has been cross-compiled by Astrobe to ARM - so it can run on any ARM equipped device. Currently NXP Cortex M3 and M4 devices are supported with more to come.

This opens up the opportunity for a port to the Cortex M7 - which opens up opportunities for 200MHz + operation, with 400MHz promised for later in 2016.  A port to the $50 STM32F7 Discovery platform would make for a portable, battery powered workstation.

Additionally the RISC5 has been ported to run on the $99 Xilinx Artix 7 "Arty" platform.

Astrobe Systems have recently released a cross compiler and development system to allow Oberon to be developed on a Windows platform.

A Review of Tiny Languages Part 1

Tiny Languages

This week I have been looking at bygone computers and some of the languages they used - tailored to work within the framework of their resource limited hardware.

My recent dealings with the "Forth-like" SIMPL language has led me to look for other examples of minimalist programming languages.  Many of these were devised in the 1970s and 1980s - when home microcomputers were very short of memory resources.

In this post I look at some very small computer languages - often less than 4Kbytes in size.

My recent search has unearthed the following:

VTL     Very Tiny Language   - a BASIC like language for resource limited microcontrollers

VTL-2   An updated VTL with more features -  yet assembles in 768 bytes

Mouse  - developed in the late 1970s for electronic music applications on a PDP8

TinyForth  - A cut down Forth, written in C or assembler

Txtzyme  - an I/O oriented minimal control script with some Forth-like features

SIMPL     - an extended version of Txtzyme to run on several platforms.

TinyBasic  - various offerings available. TinyBasicPlus

Bitlash  - a control oriented, Programmable Command Shell to run on Arduino


VTL

VTL is an interpreter designed in 1977 by Frank McCoy for the 6800 and 8080 machines of that era. The complete 6800 version of his interpreter is ROMable, IN 768 BYTES!

VTL was originally devised for the Altair 680 - an early 6800 microcomputer, with a strong similarity to it's stablemate the MITS Altair 8800 but much smaller in size.  It had 1K of RAM and sockets to accept 1K of ROM.  ROM chips at this time were likely to be only 256 bytes - so 4 sockets required!

There appears to be a following for VTL and its derivatives in Japan - so many of the references are Japanese websites - but easily translates with Google Translate.

Summary of VTL languages over the years - translate from Japanese

"Creating a VTL Language" Some description of VTL for 6800, 8080/Z80 and AVR  - source code in assembler and C - Translate from Japanese. This site and source code provided by T. Nakagawa.

The author, T. Nakagawa, has provided source code (about 370 lines - see this Github Gist) that will run on an Arduino with a bit of fiddling. You will need to add the serial putchr and getchr routines to drive the UAR - and include the UART code from AVR-Lib.

Once these are added, it compiles to about 2.6K under the Arduino IDE.  It should be noted that the AVR uses a 16 bit instruction word - so the byte count for AVR Flash code is generally about twice that of other 8 bit microcontrollers.

If you want to try out VTL - this is a packaged exe that runs on a PC in a command prompt window.

VTL remains of interest because it has some very compact C code for the various building blocks of a simple interpreter - and is relatively easy to understand its operation.

VTL-2

In 2007, some thirty years after his original VTL offering, Frank McCoy revisited his VTL and produced an extended and improved version of VTL - which still fits into 768 bytes (on 6800)   The User Manual and some example programs are here.

Mouse 

Mouse is a very small language that was written in the late 1970s - early 1980s by Peter Grogono.

It was a further development of his early 1970s system/language MUSYS - that was written to aid his work with early computer generated electronic music on resource limited PDP-8 machines.

Mouse took aspects of MUSYS and updated them to suit the late 1970s emerging microprocessor scene.

Here are some links:

The Mouse Programming Language

The Great Mouse Programming Language Revival

Wikipedia has further links that may be of interest.


Tiny Forth

This site and source code is again provided by T. Nakagawa, a Japanese enthusiast of Tiny languages.

He has written TinyForth both in well commented AVR assembly language (1964 bytes) and also in C that closely follows the assembly language. This not only gives a good illustration of how the language has been constructed but also how closely AVR assembly is matched to C.

I have created a Github Gist for this TinyForth - complete with UART getchr and putchr routines. The code compiles to 4854 bytes - I used Arduino 1.04  IDE - as I had some difficulty with later versions with getting the UART code to compile.

It appears to be a subset of Forth - but with sufficient keywords currently available to do simple tasks  - but like any Forth is easily extended.

Input and Output is via a serial UART interface only - it would need further extensions to the dictionary to build up a vocabulary of I/O and timing functions for the Arduino/AVR.

The AVR assembly language version is much more compact - I have added a fully commented version to this Github Gist 

If you want to write a Tiny Forth for an AVR or even an ARM - then this is a good place to study the basic language structure.

In conclusion - TinyForth looks like it could provide a useful kernel for a larger project. It would be worth compiling this source for an ATmega1284 - the extra RAM (16K) and additional I/O port would make a very capable Forth Computer.

As a newcomer to AVR assembly (but having done a lot of Z80 years ago) it is rewarding to see how readily C code can be translated to assembly language.  A lot of the Forth primitive wordss are of immediate use for the Txtzyme/SIMPL interpreter (see below) - and having the C and assembler code together is a useful crib on how one might take the project forwards further.


Txtzyme

Txtzyme was created around 2010-2012 by Ward Cunningham.  Txtzyme has the advantage that it is specifically oriented to I/O control and interaction - yet surprisingly simple.

The Arduino version allows simple control of the Arduino I/O and allows timing functions and loops. LED sequences, musical tone generation and printing serial output of analogue sensors are easily performed.

It is simple in nature - essentially just a single character  interpreter contained within a loop. It uses a single stack variable x to control some parameter of the operation. It is fairly simple to understand and easily extendable to include further "words" such as arithmetical and logical functions.

The Arduino version is just 90 lines of code and compiles to 3518 bytes. The codesize can be much reduced by replacing some of the Arduino C functions with more compact code, possibly even resorting to AVR assembly language in order to make a more compact kernel.

The beauty of Txtzyme is it's simplicity and the fact that it can be easily tailored to suit a particular application.

Reducing the Code Size:

Removal and replacement of the Arduino Serial code and using a custom function to print a long number can bring this down to 1884 bytes.

Removal of the Setup() and loop() functions and replacing with a main() and a while(1) will reduce it to 1782 bytes - but at a loss of the timing delays and millis() functions

Removal and replacement of the Arduino delay and delay_microseconds code will bring it down to
1484 bytes.

Replacing digitalWrite with a simplified function  - reduces it to 1040 bytes

Removal of analogRead and digitalRead  reduces it by a further 92 bytes to 948 bytes.

digitalRead alone is 272 bytes!

If you want to try a cut down version of Txtzyme - I have paired out most of the bloat and put a 658 byte minimum kernel here.  It doesn't do much - you have to add your own functionality in the form of case statements.

Txtzyme appears to indicate that a I/O oriented micro language is possible on the AVR (Arduino) in about 1024 bytes. This makes it  possible to include it with a bootloader plus some extensions in under 2K.

The code-shrunk version of Txtzyme is available on this Github Gist   You may wish to re-instate digitalRead  (line 110) and analogRead (line 150) depending on your requirements.


Next Time

In the next post I look at SIMPL and how it has evolved from Txtzyme.

More Thoughts on Retro Computing

Forty years ago when home computers were in their infancy - and I myself was still in short trousers, the tech community in Silicon Valley began to build their own homebrew computers based on the newly available microprocessors such as the 8080, 6800 and 6502.

Microprocessors were still expensive (especially Intel) but with the advent of the considerably cheaper 6502 in 1975 there was a significant reduction in the overall cost of a homebuilt machine. The Homebrew Computer Club - that met regularly at Stanford University soon obtained a copy of a cut down interpreted programming language called Tiny Basic, and very quickly it was being adapted to run on all sorts of fledgling machines - a process that involved a lot of tedious copying of listings,  saving onto paper tape or cassette, or even programming onto Eprom.

The early pioneers desperately wanted an easy to use language, in plain English text that was quick to learn and quick to program.  They put up with perhaps limited maths capabilities and lacking in anything but single alpha-character variables,  but the advantages more than overcame the shortcomings an so it was Tiny Basic that helped seed the early microcomputer industry.

Wikipedia has a good account of those early days of TinyBASIC.

Tiny BASIC was compact and designed to fit into about 2 - 3 kbytes of memory - as the early micros generally only had between 4K and 8K of memory - similar to what the first minicomputers had, - a decade earlier.

In some implementations, it was coded in such a way that it would run within a virtual machine on the microprocessor.  This approach led for compact, more portable code - but was not so fast in execution as an implementation coded in the host's native machine language.

1970s

In the mid-1970s microprocessors could at best muster about 1 million instructions per second - but still were able to deliver a credible computing experience when programmed in TinyBASIC.  The first machines generally used teletype or serial terminal for input and output - the ASR33 Teletype being favoured - as it had built in punched paper tape reader and punch which conveniently provided a permanent paper tape record of the program - which could be swapped and exchanged amongst friends at the computer club meetings. When I went through university in the early 1980s - the engineering department were still using 20 year old ASR33 Teletypes!

1980s

Within a few years, the large corporations became interested in the home computer market - and the products were further refined to be more home-friendly.  This involved incorporating some video generation hardware into the design - so that the output could be displayed on the home TV.

Whilst this increased the market appeal, it meant that often the poor overworked microprocessor was further burdened by the overheads of servicing the video display - and that real processing was constrained to the vertical blanking interval - slowing the machines down further.  Early Sinclair machines (ZX80, ZX81) had been honed down to the bare minimum hardware, in order to undercut the cost of competitor's machines - and so the resulting operation of running basic was particularly slow.

Recent benchmarking tests show that a 3.5MHz Z80A - as used in the Spectrum was capable of about 0.142 DMIPS.  Or 250.7 Dhrystones per second.

1990s.

Microprocessor clock speeds increased rapidly over this decade.  The very popular Atmel AVR appeared in 1996 and was capable of being clocked at speeds of up to 20MHz.  The modified Harvard architecture featured a 2 stage pipeline, allowing execution of one instruction whilst the next is being fetched. This gave operational speeds of approaching 1MIP per MHz - so a 20MHz processor would achieve about 20MIPS.

The AVR was optimised for executing high level languages - especially C, and as such has a highly orthogonal instruction set.

There have in recent years been several implementations of Tiny Basic, written in C and aimed at supporting, in particular, the Arduino or Arduino derivatives. The code often supports external accessories such as a micro SDcard used as a disc, external SRAM and on chip EEprom  as well as the usual Arduinio I/O  and timing - such as millis and micros.

The code is reasonably fast allowing an AVR (16MHz)  to execute about 50,000  empty For-Next loops per second. (This was implemented on an Arduino back in 2011 - see my earlier post from May 2011.

The New Millenium.

If we now fast-forward a few decades, we now have multi-core 32 bit processors capable of executing a billion instructions per second, on each core - and handling larger numbers and larger data sizes.

How would TinyBasic perform on a modern ARM processor for example? Would the interactive nature of the language, easy to learn syntax and the additional resources - memory and peripherals offered by a modern ARM processor make for a rewarding computing experience?

As there are versions of Tiny Basic written in C, it should be fairly easy to port it across to almost any microcontroller. Right?

Benchmarks and Other Performance Indicators

Recently I have been looking at the benchmarks of various ARM processors - especially those that are compatible with the Arduino IDE.

These include the STM32F103 and GD32F103 running at 72MHz and 120MHz respectively. (The GD32F103 is a Chinese produced, licenced version of the STM32F103 - tweaked with faster on chip RAM so it runs at 120MHz).  These may be programmed using the  STM32duino plug-in within the Arduino IDE.

Peak Performance

A very wide range of processors may be programmed within the mbed ecosystem - including the latest Cortex M7 from ST Microelectronics.

The STM32F746  is a Cortex M7 with 1Mbyte of Flash and 384KB of SRAM.  Available in a number of LQFP packages from 100 pins to 208 pins, it is clocked at 216 MHz and claims to deliver 462 DMIPS.  Here's the spec summary:

1MB of flash memory and 340KB of SRAM (320KB system, 16KB instruction and 4KB backup SRAM)

Ethernet, 6/3 SPI/I2S, 4 I2C, 4/4 USART/UART, USB OTG FS/HS, 2 CAN, 2 SAI, SPDIFRX, SDMMC interfaces

168 I/O ports with interrupt capability

8bit to 14bit parallel camera interface up to 54Mbytes/s

Ten general purpose, two advanced control, two basic and one low power timers

LCD-TFT controller up to XGA resolution with dedicated Chrom-ART accelerator for DMA2D

Three 12bit, 2.4MSPS ADC with 24 channels and 7.2MSPS in triple interleaved mode

Two 12bit D/A converters and 16 stream DMA controller with FIFOs and burst support

This looks an impressive spec for a device that costs about £11 in 1 off.

The STM32F746 is about the fastest processor I can lay my hands on, and being LQFP, solder onto a pcb.  Using the online mbed compiler it can be programmed without having to resort to expensive toolchains.

The STM32F746 forms the basis of the STM32F7 Discovery board - a $50 development board with LCD, USB, ethernet, microSD card, SRAM, and a whole host of other features.

• STM32F746NGH6 microcontroller with 1MB flash memory and 340kB RAM in BGA216 package
• On-board ST-LINK/V2-1 supporting USB reenumeration capability
• USB functions - Virtual COM port, mass storage, debug port
• 4.3" 480 x 272 colour LCD-TFT with capacitive touch screen
• Camera connector
• SAI audio codec
• Audio line-in and line-out jack
• Stereo speaker outputs
• Two ST MEMS microphones
• SPDIF RCA input connector

• Two pushbuttons (user and reset)
• 128Mb Quad-SPI Flash memory
• 128Mb SDRAM (64Mb accessible)
• Connector for microSD card
• RF-EEPROM daughterboard connector
• USB OTG HS with micro-AB connectors
• USB OTG FS with micro-AB connectors
• Ethernet connector compliant with IEEE-802.3-2002

If we then make use of an embedded video engine  - or EVE chip, to drive a graphics display we could potentially have an ARM based computer with full colour high resolution graphics that runs about 1000 times faster than the ones we remember from the 1980s - and for a cost of about £20.

My prototype EVE board is designed to plug into the underside of the STM32F7 Discovery board and provide full 1024 x 768 video output and a PS2 keyboard and mouse interface.   This combination would make a very comprehensive computing environment.

In my tests I achieved about 300,000 Dhrystones per second  - about 1200 times the speed of the old Z80.

A Versatile 8 bit Computing Platform

Part Populated WiNode Board

Back in late 2011, I designed a product called WiNode, which was a companion product to the Nanode RF - a simple Arduino based wireless to ethernet hub.

Well that's all ancient history now - but I do still have a box of 40 WiNode kits left over - which I am slowly finding uses for.

WiNode was conceived as a jack of all trades.  It had the usual 16MHz ATmega328P processor - but in addition a whole lot of hardware goodies.

• 32K SRAM with super capacitor back-up
• microSD connector
• RFM12 Low Power 433MHz Wireless transceiver module
• MCP79410 Real Time Clock - again with supercapacitor backup
• 754410 Dual H-Bridge (for motor, stepper, relay driving - or Class D audio Amplifier)

Despite all of the additional hardware, WiNode was a compact but surprisingly uncluttered layout. Almost all of the components were through-hole  - so easy to solder.  It was the perfect platform for a whole lot of Arduino & Low Power Wireless control an monitoring applications.

Now 4 years later - WiNode is going to get a new lease of life.

With the SD card, Realtime clock and additional 32K x 8 RAM it makes an ideal platform to host some of my 50x50 series of shields including the new Evita High-Res Video Shield.

Using the Gameduino 2 Library - the hardware is virtually identical to the Gameduino 2 - except that the Evita board drives an external display - in this case below a 32" wide screen TV

Black Text 128 Characters per Line 1024 x 768 

A very large clock in just 14 lines of code

Whilst the applications above are very simple - and easy to code using the comprehensive Gameduino 2 library, there is sufficient capability in the 8 bit ATmega to produce a retro-computer - not unlike those used in the mid 1980s. 

The Evita shield also offers  PS/2 Keyboard and Mouse connectors, and audio output - allowing a complete 8 bit computer with high resolution video to be created.

Additionally it is easy to add a Wii Nunchuck to the I2C pins - making it ideal for playing games or retro computing. The Nunchuck derives its power from the two unused pins A2 and A3 set LOW and HIGH respectively.

With the right language - such as Tiny Basic or Forth, it could make a very versatile computing platform - and ideal to teach basic programming techniques.

The TinyBasic code gan be found here on Github

Hardware Allocation

D0          UART RX
D1          UART TX
D2          FT812 INT
D3          KBD_CLK
D4          KBD_DATA
D5
D6          MOUSE_CLK
D7          MOUSE_DATA

D8
D9          FT812   /CS
D10        FT812  PowerDown/Reset
D11        SPI MOSI
D12        SPI MISO
D12        SPI SCK
D14        I2C SDA
D15        I2C SCK

A0          Analogue Joystick (X)
A1          Analogue Joystick (Y)
A2          Wii Ground
A3          Wii Power
A4          Wii Nunchuck SDA
A5          Wii Nunchuck SCL


Details of interfacing the Wii Nunchuck may be found here.

In the next post I look at Tiny BASIC as a possible contender for a 21st Century homebrew computer.