|
If the Microchip PIC is to be criticised for anything; at the top of the list
must come the atrociously designed Assembly Language mnemonics.
|
|
|
|
The Microchip PIC processors have been a
phenomenal success. These low-cost, highly powerful microcontrollers have found
a home in many professional and home-grown applications.
The biggest complaint I have with the PIC family is the atrociously designed
Assembly Language which makes development harder than it is with other
processors and cripples productivity.
Maybe it's just me, but I find it almost impossible to use the PIC Assembly
Language, which is not what I'd have expected as I've had no trouble using
Assembler on a wide range of processors including Motorola 6800, 6803 and 6809,
Rockwell 6502, Intel 8048 and 8051, Zilog Z80, Intel 80x86, Atmel AVR, Digico
M16 and even DECsystem PDP-10.And it's not as if I'm not experienced with Assembler; 15 years of my working
life as a professional Software Engineer have been spent working in Assembler,
so it's not a case of not being able to understand what I'm dealing with.
I have tried to analyse why I have such difficulty with the PIC when I have had
no such problems with any other microprocessor instruction sets I've used or
just looked at. The main reason I think it's so complex is because I am more
familiar with an instruction set which 'moves data' from source to destination
and has an instruction which reflects that concept, most often with an
instruction which has a format like "opcode destination,source".
The PIC on the other hand uses a minimal set of opcodes and specifies the
destination of the operation by way of a W or F flag, but often
drops the flag entirely with the destination being implicit in the instruction.
This brings in considerable confusion when unfamiliar with an instruction set
such as when encountering the PIC's "MOVF reg,W", "MOVWF reg" and
"MOVLW number" instructions. These instructions respectively move the contents of a register into the working
register ( "MOVF reg,W" ), move the working register into a another
register ( "MOVWF reg" ), and load the working register with a numeric
value ( "MOVLW number" ).
There is nothing "orthogonal" nor consistent about the related instructions,
which in a "proper assembly language" would have one opcode with suitable
operands specifying the actual operation intended - "MOV W,reg",
"MOV reg,W" and "MOV W,#number", where the destination of the
operation is always on the left, and the source is on the right.
The PIC Assembly Language is obviously linked very closely to the underlying
PIC hardware architecture and actual opcode bit usage, but there is no reason
that an Assembler cannot translate between a "sensible Assembly Language",
using well thought out mnemonics and constructs, and the underlying opcode
format. In a well thought out assembler, "INC W" and "INC reg" would increment the
working register or any other register. For the PIC, it is necessary to use
"ADDLW 1" and "INCF reg". There are many other similar examples.
I accept that almost all Assembly Languages have their quirks and peculiarities,
but not to the extent of the PIC. Using the PIC requires remembering all the
nuances of the instruction set, the variations depending upon what it is one
is trying to do, and, despite there only being 35 instruction or so, the mental
hoops one has to go through are horrendous when not using the instruction set
on a day to day basis. If I want to "Increment Something", I expect to use an
instruction which looks like "Increment Something", not have to read the manual
to see exactly what instruction I have to use everytime.
Maybe I'm asking too much, but every other Assembly Language I've used has
managed to make life easier for the programmer. Perhaps lack of familiarity
with the PIC is the root of the problem, but I've had no difficulty in quickly
picking up Assembly Languages I've never seen before, or haven't used in ages,
otherwise. Note that I am not complaining about the architecture of the PIC itself; the
peculiar Special Function Register and Port mapping into pages, which is also
done with code memory, is done for a reason, and a very obvious one when there
are only so many bits available in an instruction to carry out an action.
My only conclusion is that there's something badly flawed with the PIC Assembly
Language design. Perhaps it's just that it's so at odds with every other
Assembly Language I have encountered, but if that is so, it is little more
than confirmation that everyone else has got it right, and Microchip have
got it badly wrong. In truth, I find the PIC Assembly Language easier to read
than to write with. The translation from opcode to meaning is fairly easy to
determine ( which means I can fairly easily debug, emulate and simulate with
PIC code ), but in the reverse direction, I find it incredibly difficult,
translating a requirement into the necessary opcode.
Those who have taken the time to learn the PIC Assembly Language may disagree,
but I am sure there are many who have had as much difficulty as me.
Those working for Parallax Inc
and Tech-Tools seem to agree that the
Microchip Assembly Language is difficult to use, as they
both created Assemblers which accepted not just Microchip defined Assembly
Language constructs, but also a form where the Assembly Language could be
specified in a much more conventional way, based upon that used with the Intel
8051. Parallax no longer seems to carry that Assembler, but the
CVASM16 Assembler from
Tech-Tools still exists, and it is possible they may be one and the same.
To me, the creation of an alternative Assembly Language syntax to that
prescribed by Microchip is the best way to approach using the PIC; this allows
programs to be written quickly, without worrying about the PIC idiosyncracies.
The effort is invested in creating the code, not battling the PIC itself.
This has been my view since I started using the PIC, so the first thing I did
was create a Cross-Assembler which took my own Assembly Language format and
converted it into Microchip opcodes, and generated the same output files as
the Microchip Assembler does, so my Assembler could be as standalone, and as
easy to use a s Microchip's own product. The original Cross-Assembler was targeted at the 12-bit PIC's, the 16C58 and
equivalents, as these were the only processors available at the time, and the
Cross-Assembler proved difficult to update to cater for the 14-bit and numerous
variants of processors that Microchip offer today.
Recently, I got back into thinking about developing for PIC processors again,
and started re-writing the Cross-Assembler from the ground up, targeted
primarily at the 14-bit processors, but also catering for the older 12-bit
cires. The effort was relatively short lived, but my efforts towards creating
a Basic Stamp Clone has brought the
Cross-Assembler back out of retirement. If I am to use a PIC as a Basic Stamp interpreter, I will need a programming
language to code in which I can work with productively, and I will be using
the Cross-Assembler for this development. The Cross-Assembler has therefore been put into the public domain as part of
the Build Your Own Basic Stamp project, to be used with that project, and for
use by anyone else who is having problems using the native Microchip PIC
Assembly language.
The PICASM Assembler
The PICASM Assembler is in many ways a glorified Macro-Assembler, translating
the language as defined by PICASM into the Microchip PIC Assembly Language
equivalent; but it does much more.The PICASM Assembler is a standalone program which will convert program source
files to burnable code images without requiring any other programs or jumping
through hoops. The code images are compatible with those produced by the
Microchip Assembler and can therefore be processed and used, as the files from
their compiler would be. The PICASM Assembler provides all the features which would be expected of a
modern tool including MACRO processing, conditional assembly, comprehensive
error checking an reporting, and it supports a large range of Microchip PIC
processors. All supported processors are defined by provided files which
are loaded at run time, and can be easily modified to support new processors
as they materialise. For complete information on the PICASM Assembler; please refer to the
PICASM User Manual, which is available on-line, and is
included in the PICASM.ZIP Distribution Archive. A
complete list of PICASM Opcodes is also available
online and in the Distribution Archive. Downloading the PICASM Assembler The PICASM Assembler Version
0.01
is available for download as part of the
PICASM.ZIP Distribution Archive. The source code
consists of the PICASM.BAS file and a number of .BAZ "include files" ( please
see README.TXT in the Distribution Archive for details ), and the PICASM.EXE
file is the assembler executable. A number of .CPU definition files are used
to configure the assembler for a variety of processors at runtime. The entire
Distribution Archive can be downloaded by clicking the link below ...
Download PICASM.ZIP - Version
0.01 ( 195 KB ) Version
0.01
of the PICASM Assembler is the latest version.
Although I am running a Virus Checker on my development PC, please check
the PICASM.ZIP and PICASM.EXE files after downloading and unzipping to
ensure that they are virus free.
Using the PICASM Assembler
The PICASM Assembler can either be placed in the directory from which it is to
be run or placed in a directory which is included in the "SET PATH="
environment variable, or it can be run by prefixing its name with the fully
qualified path of where it is installed. In short, the PICASM Assembler is
just like any other MS-DOS executable you will encounter.
A .ERR file will be generated if any errors are detected. Checking whether or
not this file exists will allow the success or failure of the compilation to
be determined if the assembler is run within a .BAT batch file.
The best way to see the functionality of the assembler is to try it. There are
a number of examples of source code included in the
PICASM.ZIP Distribution Archive which can be used.
The PICASM Assembler Source Code The PICASM Assembler is written in Basic and is compatible with the
FirstBasic 1.00 shareware assembler and the PowerBasic 2.10f assembler
from PowerBasic Inc.
The source should be fairly easily convertible into other variants of the Basic
language, including QBasic and Visual Basic, and even alternative programming
languages, such as C, C++ and Java. Reporting Bugs in the PICASM Assembler
Operation of the PICASM assembler has been checked by compiling numerous source
code files but it is possible that there may be some source code configurations
which have not been checked and the behaviour of the assembler may be incorrect.
Before reporting a bug, please check that you have the latest Version
0.01
PICASM Assembler. If you do find any significant bugs, please send an email detailing the
problem ( with an indication as to how to replicate the bug, and specifying the
assembler version number ) to
hippy@psynet.net.
Licensing The PICASM Assembler is provided as Freeware for personal, educational and
non-commercial use. The PICASM Assembler Executable and Source Code may be modified and
redistributed providing that the Licensing and Copyright statements contained
therein are unchanged, and no charge other than distribution cost is made.
For commercial use of the PICASM Assembler, or any program derived from it,
please contact the original author, and Copyright holder, at
hippy@psynet.net.
Warranty The PICASM Assembler is provided "as is", without any warranty of any kind,
and without any guarantee as to fitness for purpose.
Downloading, installing and using the PICASM Assembler is undertaken at your
own risk.
|
