1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
LDmicro is a ladder logic editor, simulator and compiler for 8-bit
microcontrollers. It can generate native code for Atmel AVR and Microchip
PIC16 CPUs from a ladder diagram.
This program is free software; see COPYING.txt.
I started work on LDmicro in October 2004.
At present, I receive a steady stream of questions and feature requests,
that I do not have time to address. I hope that others who find this
program interesting or useful may be able to complete this work.
BUILDING LDMICRO
================
LDmicro is built using the Microsoft Visual C++ compiler. If that is
installed correctly, then you should be able to just run
make.bat
and see everything build. The regression tests (however inadequate;
see below) will run automatically after the program is built.
Various source and header files are generated automatically. The perl
scripts to do this are included with this distribution, but it's necessary
to have a perl.exe in your path somewhere.
The makefile accepts an argument, D=LANG_XX, where XX is the language
code. make.bat supplies that argument automatically, as LANG_EN (English).
HIGH-LEVEL ARCHITECTURE
=======================
LDmicro is a compiler. Unlike typical compilers, it does not accept a text
file as its input; instead, the program is edited graphically, within
LDmicro itself. The editor represents the program as a tree structure,
where each node represents either an instruction (like relays contacts
or a coil) or a series or parallel subcircuit.
Based on this tree structure, intcode.cpp generates an intermediate
`instruction list' representation of the program. This intermediate code
is then passed to a processor-specific back-end, which generates code
for the target.
The program may also be simulated; in that case, rather than compiling
the intermediate code to a .hex file, we interpret the intermediate code
and display the results in real time.
The intermediate code is useful, because there are fewer intermediate
code ops than high-level ladder logic instructions.
See INTERNALS.txt for some discussion of LDmicro's internals.
POSSIBLE ENHANCEMENTS
=====================
If you are interested in contributing to LDmicro, then I believe that
the following work would be useful. The list is in ascending order
of difficulty.
* Better regression tests. There is a mechanism for this now (see the
reg/... directory), but very few tests. A regression test is just
an LDmicro program; I verify that the same input .ld file generates
the same output .hex file. The code generators are stupid enough
that these don't break all that often (no fancy optimizers that
reorder everything based on a small change to the input).
* Thorough tests of the existing microcontroller targets. This
requires appropriate hardware to test against. When I don't have
the hardware myself, I will sometimes test against a simulator,
but this is not as good as the real thing. The simulation of
peripherals is often approximate.
Even if no bugs are found, the test programs can become regression
tests, and we can mark those targets that have been tested as
`known good'.
* More targets for PIC16 and AVR architectures. In general, this
should be very easy; just add the appropriate entries in
mcutable.h. Some small changes to pic16.cpp or avr.cpp may be
required, if the peripheral registers move around.
I am not interested in new targets that have not been tested
against real hardware.
* The code generator has regression tests now. It would be nice to
also have regression tests for the display code. We could do this
using the "Export As Text" logic, since that calls the exact same
code that's used to display the program on-screen.
* Bitwise instructions that work on integers (e.g., let internal
relay Rfoo equal the seventh bit of integer variable x, set c =
a bitwise-and b, etc).
This would require new intermediate code ops, and thus changes to
both the PIC and AVR back ends, and thus testing of those changes.
Aside from that, it's very straightforward.
These new intcode ops could then be used by higher-level ELEM_XXX
ops, for example to do bit-banged synchronous serial protocols
(I2C, SPI), or to talk to an HD44780-type LCD.
* Intermediate code ops for look-up tables. At present, these are
implemented stupidly, as a chain of if-then statements. This would
require changes to all the code generators.
Look-up tables are important, not just for the `look-up table'
instruction, but also for the `formatted string over serial'
instruction, where the string is stored in a look-up table.
* New architecture targets. An architecture target translates from
LDmicro's intermediate code (intcode) to a binary for that
architecture. This means that it includes a code generator and
an assembler. The PIC16 and AVR targets are about 1500 lines of
code each.
A PIC18 target would be nice. I am not interested in a PIC18
back-end that does not exploit the additional addressing modes
and instructions (like rjmps); it would be easy to hack up the
PIC16 back end to generate something that would run on a PIC18,
but not useful.
An 8051 target is the other obvious choice, maybe also for the
MSP430.
* A Linux port. I am told that the current version runs perfectly
under WINE, but a native GTK port would be nice. That would be
a lot of work.
I am not interested in porting to a cross-platform GUI toolkit, and
thus abandoning the native Win32 user interface. In general, I think
that those toolkits end up looking equally wrong on all platforms.
If I were to undertake this myself, then I would probably end up
writing a miniature compatibility layer for the widgets that I
actually use, that mapped on to GTK under Linux and Win32 under
Windows, and so on. I've seen attempts at general-purpose libraries
to do that, but they look extremely complex for what they do.
In general, I am not interested in changes that involve linking against
non-standard libraries. (By non-standard, I mean anything that's not
distributed with the operating system.)
FOREIGN-LANGUAGE TRANSLATIONS
=============================
Foreign-language translations of the documentation and user interface
are always useful. At present, we have English, German, and French.
These do not require changes to the source code; a lookup table of
translated strings is automatically generated from lang-*.txt during
the build process. If you are interested in preparing a translation,
but do not wish to set up tools to build LDmicro, then just mail me the
lang-xx.txt, and I can build ldmicro-xx.exe for you.
At present, LDmicro does not use Unicode. This means that translations
into languages not written in the Latin alphabet are tricky. This could
be changed, of course.
FINAL
=====
I will always respond to bug reports. If LDmicro is behaving incorrectly
on some target, then please attach the simplest example of a program
that's misbehaving, and a description of the incorrect behavior.
Please contact me if you have any questions.
Jonathan Westhues
user jwesthues, at host cq.cx
near Seattle, Oct 21, 2007
|
