Computer Corner by Bill Kibler

It has been great not doing the managerial duties of TCJ, besides
Dave did a wonderful job on the last issue. I think his changes
will make TCJ just that much better. So thanks for continuing on
with TCJ, Dave.

Duties

My duties for TCJ are mostly this column and the occasional
article. You will find my article on picking embedded programming
options elsewhere and is the response to letters and email
messages I have received. So if there is some item you need some
advice or help on, please drop me a message and I'll see what I
can do for you. I think this makes my thirteenth year supporting
TCJ readers.

PLD's

I want to thank Robert Brown from Alta Engineering for his great
PLD article, not only is he supplying a cheap PLD programmer, but
he also explained very clearly the why of using PLD's. One reason
I have been down on using PLD's was simply the cost of a
programmer. Most of our readers have a mantra that goes something
like this: if it cost more than $100, I'm not interested! I think
Bob's product stays well within that criteria.

Another point of the article is his explanation of why and when
to use PLD's. His figure 5 is exactly what I wanted for showing
the main reason to use a PLD. You can see very clearly why it is
cost effective to use one in that case. All the parts used in the
TTL version are not the 25 cent variety and the number of sockets
and trace savings more than make up for the higher cost of the
PLD. It is also very common for items like this (clock timing) to
get changed as the design progresses. Simple changes in the PLD
can mean you are still able to use the same board to achieve your
new goals.

Memory decoding is also covered in the article. The only thing he
didn't mention was when not to use a PLD. I recently designed a
board and used a 139 for it's decoding. The 139 is cheap ($.19)
and does the needed decoding with extra pins to spare. The way to
decide is not on cost alone, but on logic reasoning. If you
really do need the fine grain memory layout as outlined in the
article, a PLD is your only option. Any design using a precise
memory map like that is also apt to change many times before your
done and burning a new PLD is the only way to go.

I have included the schematic of some decoding I used. You can
see how simple my decoding is. The design has two sections, one
that talks to the PC BUS and one part that is a standalone 8031.
There is a dual ported RAM device which fits between the 8031 and
the PC, for buffering data or looking at variables. I thought
about using a PLD to replace both decoding parts, since then
maybe the cost could be justified. The problem here is that you
run out of input or output pins. That means two PLD's would be
needed and since the 138/139's are only $.50 for both, compared
to $2.49 for a single 16V8, PLD's are just too costly. You also
need to keep in mind, that this would be the only board in house
using a PLD of any type. It is pretty hard to justify a single
PLD when the other 30 to 40 boards you make all work fine without
them.

You also need to look at the board layout. In my design, the dual
ported memory sits in the middle of the board, with circuitry on
either side. If I tried to use one part for the cost savings,
some of the lines would have to cross the middle of the board,
and it was all I could do to get 30 some odd lines from each side
to land properly on the memory. Having to run 4 or 5 more lines
through this mess might just be impossible. Keeping in mind how
the board traces run, is another reason to use or not use PLD's.

My experience has shown that often these fine grain designs lack
real reasoning for their design choice. My 139 is anything but
fine grain, you waste tons of memory, are very fixed in your
options, and are pretty much stuck in doing it that way forever.
Since my design's layout is most likely to never change, never
use all the options I provide anyway, these are trade off's I can
certainly afford to play with.

That's basically (and has always been) my position. As the design
gets more complex and you need more flexibility, going from basic
TTL to PLD's changes from overkill to the most appropriate for
the application. It's not a black and white choice! Every project
can have a time when the design is better suited for one choice
over another, but it then could change directions as you continue
to develop and polish your project. My stand still remains, that
you must know both options to be a cost effective designer in
todays market of lean and mean machines.

Code/Data

While I was looking at the memory layout, I remembered I had to
make a small change in the design to use Brad's Camel Forth.
Remember that 8031's have separate space for DATA and CODE. Forth
needs to run code out of data memory. That means you must combine
the two signal lines that control the use of RAM or ROM devices. 

The /PSEN signal is used to turn on the ROM device, while the /RD
signal is used in talking to regular RAM. Keeping the memory
areas separate, means it is possible to have 64K of each memory.
My combining of the spaces limits total memory usage to 64K. Now
please keep in mind these are suppose to be embedded systems and
I have always felt if you needed more than 16 or 20K of ROM, you
must be looking at your design a bit askew.

Implementing the dual use of memory is very simple. There are
other ways than the one I use, but two simple diodes work just
fine. You need the pull-up resistors to make sure they are biased
properly, but overall cost is well under 20 cents. I use a jumper
so you can select whether or not the option is in use.

After installing the diodes and resistors, using Camel Forth
required that I recompile it for the memory map shown in the
schematic. I was then able to burn a ROM, power up and get the OK
prompt. I then wrote test routines to check out memory and other
operations. Camel Forth made hardware testing a breeze and that
design problems were not associated with code I made up for the
projected use. Several times I burnt new ROMs to test a
completely different use only to have it lock up with no output
of any kind. I simply put back Camel Forth and got the OK to tell
me it was in my new code. A very handy tool!

linux

My full time duties now encompass doing Unix development. I had
some Unix experience before taking this job and have since
discovered how much more complex and involved Unix hacking is
from regular programming. To help bring myself up to speed I
started using and playing with linux.

If you own a 386/486 system and have some extra hard disk space,
loading and using linux is very simple. I have tried several
versions of the releases and am still not sure which installation
to recommend. For the casual user or just curious experimenter,
my favorite is the Mini linux. This version is not recommended by
the real linux users since it resides on top of DOS.

linux is so well developed, there are versions for almost any
option and system around. Some users in Portugal, I think, wanted
a simple version to run under DOS to be able to connect with
Internet servers and get their E-mail. The version runs entirely
on DOS and fits in a 20 meg subdirectory.

I use it as a simple testing ground and place to un-archive
files, all without having to install a full system. It will do
X-windows and could do everything a full linux does, but I agree
with the others, that if you are doing a full system, partition
your hard drives and do it properly. The mini version is just, a
simple scaled down, single task system installation. I plan on
doing some testing to see if I can use it in place of our
expensive windows based X-windows interface to the HP-Unix
systems I work on.

Embedded

I keep seeing various articles and messages about using linux for
embedded development. I suppose you can do that, and there are
certainly plenty of tools to help you in that idea. I find some
features of linux/Unix a bit overkill and restrictive. You can
get linux to boot fast, but I find the 5 or so minutes a bit
long. You need to remember however, that normally you would boot
linux and never shut it down.

For those of us who have grown up doing embedded and hardware
work for years, the idea of not being able to just hit the reset
switch to get yourself out of a problem seems like a step
backwards. The idea behind the bigger systems like linux is
memory and hardware protection. Your program can't really get
control of what we are so use to dealing with in simpler systems.
I find that the biggest problem for me.

When dealing with embedded devices, you know where every device
is, how memory is laid out, and usually which hex codes are
needed to make it play. linux/Unix systems do not allow that sort
of access. I look back at several projects and see that using
linux would have made the development considerably longer and
more difficult.

Since I now do most things in C, my understanding of C is
becoming more developed. C really works on systems like linux.
You have large libraries that handle all the inner system calls.
Those system calls are part of the operating system, and as such
give you a direct hook into the system kernel. By that I mean the
design of the operating system is based on the use of the
libraries. The big difference for embedded use is these same
calls just get converted to some assembly language code that gets
included into the ROM, making it very bloated with often unused
code.

A better way to explain this would be program size needed to do
similar processes. Most Unix systems have sharable libraries,
this means the code is not sucked into the program, but called at
run time, not possible in DOS. So it is possible to make a few
hundred byte program in Unix, that would have to have all the
actual library calls coded inside the program to run on DOS,
since DOS has no sharable option. That is a big difference and
also why I don't recommend it for embedded controllers.

For embedded work that means the library code gets sucked into
the ROM and thus the ROM can get pretty large. In the case of
using Forth, it is more like the linux/Unix idea. The kernel
contains or is made up of all the tools you need and you only
make calls to them to get things done. It also reminds me of why
a lot of CP/M users have trouble understanding the PC
architecture. In CP/M and other simple systems, one can grasp and
understand the whole system, and thus take advantage of system
hooks usually hidden by more complex layers.

That's it...

Well keep hacking till next time. Bill Kibler.