Saturday, April 30, 2016

The Windmills of Your Mind - Part 4 G-F Interaction

The following entry was adapted from a contribution to the Parallax Propeller Forum - hence the slightly unusual style.

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.  Think of XML or Hypertext, these are handled by a browser or viewer, and used to create a more rich document.  "MarkDown" might also be useful to achieve this scheme.

This has a a slight smell of Chuck Moore's ColorForth, but the way the in which tagging is implemented may well be different.

Babelfish?

In my workplace and hobby environment, I have a mix of ARM M3, M4, M7, Atmel AVR, MSP430 (FRAM based) microcontrollers and now Parallax Propeller. 


I also have J1 Forth cpu and Oberon system running on Spartan 6 FPGAs and a DE0 Nano FPGA board - hosting a reduced Propeller 2.

The Pepino board is ideal for workstation type projects - it has 512K of fast 32bit memory, VGA plus PS/2 Keyboard and Mouse.

http://www.saanlima.com/pepino/index.php?title=Welcome_to_Pepino

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. 


Perhaps Forth is the code version of the Babel fish?

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 complete control of the computer and its resources. No more need for pesky sys-ops and ridiculous gigs of bloatware.

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.


Such a program can be written in a couple of hundred bytes - including the serial comms routines. As you add more functionality, this grows roughly in proportion to the number of Forth word definitions.  25 to 30 bytes per compiled Forth definition is a reasonable figure to allow for.

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.

http://middleriver.chagasi.com/electronics/tforth.html

(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 ( words are searched using 3 significant characters plus "length" 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 size 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:

FILL
AGITATE
DRAIN
FILL
RINSE
DRAIN
SPIN

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

"5F100AD5FRD1300S"

5 litre FILL
100 Agitations
Drain
5 Litre FILL
Rinse
Drain
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.

https://processing.org/


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.

http://www.rayslogic.com/propeller/programming/PropMonitor/PropMonitor.htm

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.

The Windmills of Your Mind - Part 3 - Guido Fawkes

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 - when written in assembly code, and seldom does the interpreter 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. Forth is fundamentally an interpreted, interactive language, which breaks away from the usual edit-compile-load-run work flow.


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.  As the User has full access to the Processing environment and source code, the command interpreter and GUI may be tailored to be as simple or complex as the application requires. 

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  

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

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.


 Hardware

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.
















Thursday, April 28, 2016

The Windmills of your Mind - Part 2

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






Saturday, April 23, 2016

New Infrastructure

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


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"

Applications

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





Wednesday, April 20, 2016

The Windmills of Your Mind...... Part 1

Single Chip Video Output from Parallax Propeller

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.

I came across the Parallax Propeller at Maker Faire, New York in the Autumn of 2011, having known about the Parallax BASIC Stamp for years. 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.

So it's almost 5 years on - and finally I have got around to working with this fascinating device. Where have I been all this time?

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  with virtually no additional components and has a multitude of purposes both for retro computing, education or for products that require a versatile human-machine interface.

It is capable of generating either VGA component video in 6-bit, or composite to either PAL or NTSC standards, requiring just a few resistors to build the video reconstruction DAC.  With this in place it is capable of supporting 64 colours for both foreground and background and text resolutions of 800x600 and also 1024 x 768.

This makes it well suited to generating a video display interface similar to those of the early colour machines of the mid-1980s. Moreover it will support a PS/2 keyboard and mouse - again with very few components - just 6 additional resistors.

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 80MHz.

The architecture though novel, is well thought out and it creates 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 damage by accidental reverse insertion into the socket - useful for beginners!

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.

Firgure 1.  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.


Adding VGA Video,  PS/2 Keyboard and Mouse


Using some spare hardware and a Propeller Hat board - VGA, Keyboard and PS/2 Mouse are added.


Figure 2:  Adding VGA video, Keyboard and Mouse
Having achieved a minimum circuit configuration - as in Fig 1. it is then very straight forward to add the resistors and connectors that allow the use of VGA video, PS/2 keyboard and mouse - Figure 2.  Also shown are the voltage regulators and connectors for programming header and servos.

The VGA output is 6 bits, and uses 8 of the available port pins - normally P16-P23.  With the standard drivers supplied with Application Note AN004 it will require 2 cogs to implement.

(The Application Notes are a great source of information - I recommend bookmarking them - or downloading for future reference).

The PS/2 keyboard and mouse interfaces require two pins each - normally P26/P27 for Keyboard and P24/25 for mouse. With these in place, with serial programming header, and eeprom,  you have a complete terminal support system in place, which uses P16 to P31 inclusive.  This leaves P0 - P15 free for the User's peripheral circuitry, such as micro SD card, SPI SRAM (or non volatile FRAM) or virtually whatever you wish.  The novel I/O structure includes very versatile counters, configurable by standard firmware drivers,  that make PWM and  even Sigma Delta ADCs very easy to implement.  If you want 16 high speed UARTS - you can have them. This is bordering on FPGA territory - but without the complexity and bloatware of all those proprietary too chains.  It's like shopping for off the peg peripherals - but hand crafted by master-tailors!

With a little ingenuity, and using DIL packages for the ICs, all of the above could be wired up on a 100 x 50mm (4" x 2") piece of  strip board.  A complete computer, capable of a real learning experience by experimentation  - for under $20.

The circuit below, Fig 3. shows how the system may be further expanded to include audio and TV output, electret microphone for audio input and an array of LEDs.  Unfortunately the "Demo Board" is no longer in production - which in my opinion is a sad loss. I think it definitely needs a respin.  I might even just consider cranking it over myself......


Figure 3: Propeller Demo Board Schematic



What makes Propeller Interesting?

A novel 32-bit architecture of 8 risc cores (Cogs) - which has been released to public domain - 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 to link multiple Propeller chips together. Board with three or four Propeller ICs, plus additional memory are available.

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.


Parallax have a healthy User Forum, with many contributors.  Anywhere you can find discussions on CORDIC and Goertzel algorithms, and the Kenyan Multiplication algorithm - you realise that you are dealing with no ordinary microcontroller company!

In the next part, I put together a minimum design using my existing 50x50mm pcbs  that includes Propeller IC plus VGA output, PS/2 Keyboard and mouse.




Saturday, April 16, 2016

More Distractions of the Mind - Building Retro Computers - Part 1

Part 1 of an occasional thread looking at some aspect of  building retro computers:  Computers built from widely available modern parts but used to recapture the wonderment of machines from earlier times. This time I take a look at some fairly basic hardware used to provide a user interface.
I2C Hex Keypad & 8 digit Display - about $2.50

Early computers had a fairly primitive user interface, traditionally they rows of indicator lamps and toggle switches.  The lamps were used as binary indicators to show the state of the computers' registers, whilst the switches were used to "toggle in"  new binary data into the memory.  This was a fairly minimal interface which at least 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 shift 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 - for a traditional machine - such as a PDP-8  - these might be the Accumulator or working register, the Memory Data and Memory Address registers and possibly one to show the state of the toggle key-switches of the front panel.

 If however, it were a stack based processor - we could use the LEDs to show the contents of say the top few members of the stack.  Each time we execute an instruction, by slow running or single stepping - we could watch the data change in the stack. Chuck in a couple of 4-digit 7-segment displays too - and we could read off the top of stack and the Next of stack - very neat way, intuitive and visual way of understanding the operation of a stack machine.

Fortunately for us, there has been a small revolution going on with LEDs - and they are one of the cheapest components on the planet, thatnks to volume production in China.  There are also some really innovative ways of packaging and driving LEDs - such as mini 8x8 and 16x16 arrays - 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!
Multiplexing

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 8x8 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:

11111110
11111101
11111011
11110111
11101111
11011111
10111111
01111111

And for common anode - we invert the polarity of the bits so that the register sources current into the common anode:

00000001
00000010
00000100
00001000
00010000
00100000
01000000
10000000

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 8x8 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 TaoBao.com - 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 8x8 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 16x16 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.

16x16 Red LED Array with change from a $6 bill!


16x16 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 8x8 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 8x8 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!

8x8 LEDS arranged into a 16x16 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 16x16 40mm module - but actually more economically constructed from 4 of the 20mmx 220mm 8x8 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 32x32 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 16x16 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


Starburst Displays -  These were raised in a recent comment. Contain 14 Segments - including those at diagonal - allowing characters such as X, N, M  to be more readily displayed.  Available in single digit, 2 digit and 4 digit - as below. Quite low cost from the Far East.

0.54英寸4位共阴红光时钟米字管批发