Re: Atmel AVR assembler

On Mon, 25 Jul 2005 05:10:34 PST, mojaveg@xxxxxxxxxxxxxxxxxx (Everett
M. Greene) wrote:

>Jonathan Kirwan <jkirwan@xxxxxxxxxxxxxx> writes:
>> { restricted to comp.arch.embedded }
>> Herbert Kleebauer <klee@xxxxxxxxx> wrote:
>>
>> >Have to write some AVR code and therefore have read the
>> >AVR Instruction Set manual and tried the assembler included
>> >in AVR studio. I think the used syntax is completely
>> >unusable, so I decided to write my own assembler.
>[snip]
>> Let me point out some thoughts:
>[snip]
>> (c) Writing your own tools for a client project (or your employer's
>> project) means adding yet another project to the body that must be
>> preserved by them. They must have a way of reconstructing the tool
>> you write, if needed, and they must have a way of repairing bugs or
>> adding other needed features as time proceeds. Not to mention the
>> fact that they may need to rehost the tools. Anyway, a history of bug
>> fixes and added features needs to be tracked; code branches
>> maintained; etc. WHICH MEANS THEY HAVE TO PAY FOR THIS. But when you
>> rely upon the tools of your vendor (and the assembly tool chain,
>> including the linker and so on, is very often free and otherwise often
>> quite good despite your disagreement at times over the assembly
>> syntax), you can capture all the effort that the vendor supplies in
>> their tool chain. And this includes the development changes and
>> extensive testing on various machines and operating environments.
>
>This particular point cuts both ways. If the available
>tool(s) is(are) unsupported and have bugs, what do you do?
>Even if there aren't any support issues, the tool(s) have
>to be retained for future product support.

I try and keep backups of all of the tools used to produce any
project. This means, for example, keeping the exact version of MPLAB
used on that project, despite the fact that newer versions *may* still
be compatible. I preserve my old Microsoft compilers and Borland
compilers and Zortech and Lattice C and so on, for exactly the same
reasons. I have so many of these around now, but I keep them
maintained together with the projects so that I can always go back and
reconstruct the executables. So your last sentence about retaining
tools for future product support is right on target. That is a must.

The above issue comes to the fore for me when developing on a tool
where I may not be able to legally restore the compiler toolset. In
those cases, I try and avoid the tools in the first place. An example
here happened in the case of tools from Analog Devices, where the
toolset was key-locked to the machine. What happens to me, say 5 or 8
years later when a client asks me to make a small but important
feature addition? I set about to recover my tools and source code
and, no longer having that exact machine with the exact same disk
drive, discover that I cannot operate the compiler, at all. So I call
up Analog Devices for help. And do you imagine that even they know
how to help me, after so much time has gone by? Or will keep records
of my ownership that long? Or still have their own tools by which to
regenerate the unlocking code given information I provide them on my
new system??

I stay away from such situations like the plague. This is one of the
reasons I do NOT use tools locked to machines. I am still, today,
supporting tools where the code was developed using Lattice C around
the year 1987. I still have the complete tool chain used for that
project, including some tools by Intel needed for the locating part of
the linking process. And because the OBJ files of Lattice C aren't
entirely compatible with those locating linkers from Intel at the
time, I also have a custom tool needed to modify the OBJ file so that
it is acceptable. I have that tool and the source code and the
development chain for that, too. The point here is that I need to be
able to support clients I have for periods of 20 years and longer. So
my concerns about what tools I buy are severe. (Similarly, I have
working 80286 and 80386 machines I keep around, along with boxes of
multi-I/O cards, floppy and hard disk cards, and so on to maintain
them -- when I find some tools will not run properly on modern PCs.)
So I will only use tools I can rely upon, even when the vendor has
gone out of business entirely and cannot be called upon. This means
no machine-lock crap, unless the vendor is willing to give me an
unlock code that will work on any machine. (An owner of Paradigm,
after listening to my needs, very generously gave me a complete
toolset with such a code, for example.)

Regarding 'bugs' or whatnot, I just gave an example above where I
*had* to develop a tool. The Lattice C compiler did not, at that
time, have the ability to locate code. However, the system is not PC
compatible and is a dedicated 8088 design -- a truly embedded system.
So I had to use the Intel toolset for the locating feature. But to
make that work, I needed to build something to mediate between the OBJ
files that Lattice C wrote out and the OBJ files that the Intel tool
could accept. Sometimes, this happens. And when it does, you do what
you have to.

But then, it's easy to explain to people why you did. There is no
real question.

Jon
.

Quantcast