In May 2013, I learned about Ward Cunningham's Txtzyme language – a very simple serial command interpreter which allowed basic control of microcontroller function using a serial interface.
I wrote about it here:
Txtzyme – A minimal interpretive language and thoughts on simple extensions
Tytzyme was about as easy as a “language” could get, it offered digital input and output, analogue input, rudimentary timing in uS and mS and simple repetitive loops. It was so simple, and offered so many opportunities for extension, that I decided to write some new functions – and called the extended language SIMPL – serial interpreted minimal programming language.
In late May 2013, I described the extensions here:
SIMPL – A simple programming language based on Txtzyme
In the last 30 months I have ported SIMPL to Arduino, ARM and FPGA soft core processors. I have also used the Txtzyme interpreter to help to create assembly language for an entirely new soft core FPGA cpu.
Very often, during initial deveopments, we need a low level human interaction with a new microcontroller, and SIMPL seems to provide that coding framework to allow more complicated applications to be tested and coded.
SIMPL is coded in C – which allows good portability between micros, but recently I have been wondering whether SIMPL would be better coded in Forth, and act as a human interface layer between a Forth virtual machine and the human programmer.
Forth can be a difficult language to master – partly because it involves considerable manipulation of the data stack, and the need to keep track of the stack presents quite a challenge to the new programmer.
Standard Forth consists of a vocabulary of about 180 compound words, which can be entirely synthesised from about 30 primitives. When ported to a FPGA soft core CPU, optimised for Forth, most of those 30 primitives are actual native instructions. That makes it fast in execution, but still not the easiest of languages to grasp.
Can we use SIMPL to access a sufficient subset of the Forth vocabulary to allow real programs to be written, but without having to tie our brains in knots over keeping track of the stack?
The beauty of Forth, is that you can compile a new word and give it any name you wish. In SIMPL terms, this name would be a single alpha or punctuation character. Small alpha characters are reserved for the keywords, whilst capital letters can be used for User defined words.
This gives us access to
26 lower case primitives
26 Upper case User words
33 punctuation characters
This gives us a subset of 85 possible words – which has reduced the scope and complexity of the standard Forth language by a factor of 2.
Forth text entry consists solely of words and whitespace. This is intentional because it makes it more readable from a human point of view, and the spaces between words allows the compiler to know where one word ends and the next begins. The carriage return is usually used to denote the end of a line, and thus signal the compiler to start compilation of the contents of the input buffer.
SIMPL borrows from these ideas, but attempts to simplify by removing the whitespace. In fact a space character (ascii 32) may have it's own unique meaning to the SIMPL interpreter.
Numbers also present a burden to the traditional Forth interpreter – which has to search the dictionary only to find that a number is not listed, and then assume that it is a number. In SIMPL we assume that numbers are all decimal unless prefixed with a character that changes the base to hexadecimal.
As the compiler is only dealing with 85 possible input characters, the dictionary is simplified to an address lookup. For example if the interpreter encounters the character J, it looks up the address associated with the function called J, executes that code and then returns so as to interpret the next character in the buffer.
There are only 85 characters to interpret – so only 85 action routes to execute.
Here are some of the primitives
+ ADD
– SUB
* MUL
/ DIV
& AND
| OR
^ XOR
~ INV
@ FETCH
! STORE
< LT
= EQ
> GT
j JMP
z JPZ
: CALL
; RET
JMP3JPZ3CAL4RET3LT 2EQ 2GT 2MOD3DEC3HEX3PUS4R@ 3POP3
# LIT
% MOD
£ DEC
$ HEX
( Push R >R
\ R@
) Pop R R>
[
]
{
}
”
‘
? Query
_ Text String
a ALLOT
b BEGIN
c CONSTANT
d DO
e ELSE
f FOR
g
h
i IF
k
l LOOP
m
n
o OVER
p PRINT
q
r REPEAT
s SWAP
t THEN
u UNTIL
v VARIABLE
w WHILE
x
y
It's been a frenetic week of progress on the Open Inverter project. Both Trystan and I have managed to cobble together inverters from FETs, H-bridge ICs and other random, readily available modules – bought cheaply from China.
I have powered up the inverter with a DC input of 24V close to 5A and successfully powered a couple of 60W 230V lightbulbs. The efficiency looks promising with neither the H-bridge nor the transformer getting anything more than warm.
In this post, I pause for thought to decide upon the future direction of the project based on our findings, so far in this week of discovery.
Here's the current wish-list:
1. An Open Source Inverter, of modular construction that is scalable in blocks of 125W or 250W.
2. Built from readily available, understandable, low cost electronics.
3. Rugged, robust, reliable – delivering reasonable efficiency and power quality.
4. Grid synchronisable – if required – will synchronise to external source.
5. Built in power monitoring, with wireless communications compatible with emonCMS monitoring
6. “Arduino” or similar microcontroller for hackability.
7. Supports a variety of power conversion topologies, including boost, buck, peak power tracking and split-pi.
8. Uses include micro-solar, LiPo4 battery charging, dc ring main schemes etc.
9. Under $20 for primary building block.
10. Easy to build, easy to repair, extendable, hackable.
Expanding on some of the above points.
The proposed inverter will be built from low cost modules that can be plugged together as required, depending on the application.
The basic design will consist of a microcontroller, one or more H-bridge power boards and a 125VA or 250VA torroidal transformer.
For More Details: Open Inverter, an open source micro-solar inverter
