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.