Sunday, February 07, 2016

A Universal Microcontroller & FPGA Breakout Board mounted on WiNode 5



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

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

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

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

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

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

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

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

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

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

ARM Challenge

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

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

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

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

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

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

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

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

External Memory Connector.

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

LCD Display Connector.

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

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









Thursday, February 04, 2016

WiNode 5 Update

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

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

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

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

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

Latest Update - February 4th 2016

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

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

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

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

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

Job Done!

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

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

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

Final Design Specification

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

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

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

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

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

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

Monday, February 01, 2016

A Review of Tiny Languages - Part 3

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

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

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

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


Program Flow Control

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

IF-THEN-ELSE

FOR-NEXT

DO-WHILE

SWITCH - CASE


1. Simple Loop

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

10{kp_ Green Bottles_}

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

This is similar to C's    while(k)      // k>0
                                 { some task;
                                  k-- ;
                                 }

When executed, you will get this screen output:

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

ok

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

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

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

AND   &
OR      |
XOR   ^

These perform bitwise logic on the x and y operands.

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

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

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

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

// Comparison Test and conditional Group
   
      case '<':
      if(x       break;
   
      case '>':
      if(x > y){x=1;}      // If x > y x= 1 - can be combined with jump j
      else x=0;
      break;
   
      case 'j':                  // test  if x = 1 and jump next instruction  
      if(x==1){*buf++;}  
      break;


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

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

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

Example   If x > 10 then print "x greater than 10 "

11 10 >[_x greater than 10_]

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


Case Selection

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

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

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

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

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

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

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

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

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

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

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

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

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

 case '(':

      k = x;                                                 // copy x to use as the "phrase counter"                                                              
      while (k)
      {
      ch = *buf++;
      if (ch == ',')                                       // decrement k to see whether to interpret or not
      { k--;}    
      }  
      break;
   
      case ',':
   
      k--;                                          
      while (k<0 nbsp="" y="">

      {
      ch = *buf++;                                    // skip the remaining characters
      if (ch == ')') {break;}
      }
   
      break;

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

10(1,2,3,4,5,6,7,8,100,200,300,400)p

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




Sunday, January 31, 2016

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.


Saturday, January 30, 2016

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.


Friday, January 29, 2016

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.

Friday, January 22, 2016

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.




Thursday, January 21, 2016

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






Sunday, January 17, 2016

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.






Friday, January 15, 2016

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.