This is one of my electronics projects and it is currently a work in progress.
There are several versions of the EMDP1 mother board:
This project has been partitioned into three general sections where each section has its own directory:
The EMPD1 is an open source hardware project for an extensible multiple device programmer. An extensible multiple device programmer is a multiple device programmer that can be extended in the future to program new electronic devices as they are introduced to the marketplace. Frequently these multiple device programmers are called universal device programmers or more simply universal programmers.
Personally, I've never liked the term `universal programmer' because there are almost always a whole bunch of devices that they do not support; thereby make making the term `universal' fall well short of expectations. By calling them multiple device programmers, there are no falsely raised expectations that a multiple device programmer can actually program every programmable electronic chip out there. Anyhow, if you want to call them universal device programmers, you are free to do so; just do not expect me to do so as well.
The questions arise, "Why do another multiple device programmer? What is wrong with the programmers that are already out there? Why not just buy one of those and get on with your other projects?"
As I survey what sort of extensible programmers are out there they all have one problem or another. Remember when you bought a piece of electronic equipment, it came with a schematic and maybe some additional documentation on configuration. Those days are long gone. All of the commercial extensible programmers have closed proprietary protocols. The only documentation they provide is how to install and use the associated software on some version of Microsoft® Windows®. Protocol and schematic documentation is simply not provided any more. I have two problems with this. First, my preferred operating system is Linux, not Windows®. Second, if the company ever decides to stop supporting the product, I am totally out of luck; there will be no software upgrades as Microsoft releases yet another slightly incompatible version of their operating system, and new devices that show up on the market will not be supported. Since the commercial programmers cost hundreds of dollars, it is quite painful to me if I manage to pick a programmer from a vendor that decides to get out of the business. Given that most markets consolidate over time, it is quite likely that some vendors in this product space will opt to get out. All in all, the commercial offerings do not leave me feeling very comfortable.
What I really want is an open source hardware extensible programmer. When I looked around, I really only found two. One was called CUMP [CUMP] for Community Universal Microcontroller Programmer and the other is the LP120 by Brian Beard [Beard2000a]. The CUMP project is discussed further below. The LP120 is pretty good, there are some design choices there that I would have made differently. So, again, the existing open source programmers do not quite fit my needs (the LP120 was close, though.)
Ultimately, the reason why I am doing this project is because it is, for me, fun.
There are two fairly recent magazine articles about multiple device programmers with the both the hardware and software published. The first article is Build a Serial EPROM Programmer by Stuart Ball [Ball1998a, Ball1998a]. and the second article is Designing a General Purpose Programming System by Brian Beard [Beard2000a, Beard2000a]. The overall architecture of both systems is quite similar:
Just as important as the hardware design is the overall software design. Both designs expect to be talked with via a terminal emulator program. The data to be programmed is downloaded in Intel® hex file format via the file download capability in the terminal emulator. The software for the Ball design is quite static in that all of the device programming code is burned into the PROM; whenever it is desired to provide programming code for a new device, the code is added to the existing code in the PROM. However, it should be noted that there is no particular reason why code can not downloaded into the RAM and executed; it is just the case that the current firmware does not support downloading of code. The Beard design is a little more flexible in is has a program loader that can accept downloaded programs to program additional devices; thus, there is no need to reprogram the PROM in order to support a new device.
It is amusing to note that both the Ball and Beard designs both have a bootstrapping problem in that it is necessary to find some alternate way of programming the main PROM's before the system can be used to program other parts.
There is another open source hardware project called CUMP [CUMP] for Community Universal Microcontroller Programmer. I eventually contacted the CUMP group and after a bunch of discussion, we agreed to a common bus for the programmers. Thus, the EMDP1 adheres the CUMP bus `standard'. As I write this in October of 2002, it is not clear that any other implementations of the CUMP bus are going to actually occur.
Stuart Ball has authored another magazine article for a programmer that is specific to programming the AVR® microcontroller from Atmel® [Ball2000]. This programmer a parallel port programmer that is quite a bit more specialized than the 1998 design. What is interesting about the design is that it programs the AVR part in parallel mode rather than serial mode. It is prudent to keep this in mind when designing the EMDP1.
Another interesting programmer that is documented on the web is GALBLAST by Manfred Winterhoff [Winterhoff1998]. What makes this programmer interesting is that it programs GAL's and PAL's rather then microcontrollers and EPROM's. Of course, it would be truly nice if if the EMPD1 could program GAL's and PAL's as well.
Lastly, the bootstrap problem that both the Ball and Beard programmers suffered from can be dealt with by providing a alternate way to first program the microcontroller. The PIC microcontrollers from MicroChip® have a long history of easily built programmers. Indeed, I did my own cheap PIC programmer [Gramlich1999]. The relatively new PIC16F87x chips have the ability to be programmed in something called LVP (Low Voltage Programming) mode. An article by Ron Russ [Russ2001] describes how do do a parallel port programmer for the PIC16F87x series that only requires an additional couple of resistors and a single transistor. The EMPD1 can certainly benifit from being easily programmed the first time.
The overall architecture of the EMDP1 is shown below:
This is basically the same architecture as the other ones.
I decided to design a bunch of adaptor boards before I finalized my EMDP1 design. What I discovered is that the vast majority of chips could be programmed by simply connecting a wires from the EMDP1 bus to the appropriate pins of a 40-pin ZIF (Zero Insertion Force) socket. Thus, I could eliminate most of the adaptor boards I had painfully designed by just putting a 40-pin ZIF socket directly on the EMDP1 and an 80-pin wiring plug to connect between the 40 pins of the ZIF socket and the 37-pins of the EMDP1 bus. The EPROM adaptor was the only adaptor that needed more than just a wiring plug. The EPROM adaptor needed an aditional 12-pins of latch. Also, the bootstrap adaptor is really specialized as well. The overall simplication to the user of needing substantially fewer adaptor boards, makes the inclusion of a wiring plug and ZIF socket directly on the EMDP1 worth while.
Clearly, as I design the EMDP1, I want to benifit from previous designs and hopefully improve upon them. The basic hardware architecture for the EMDP1 is the same as the others -- a power supply, a microcontroller, a serial port, a programmable voltage supply, and some device sockets. However, before I dive into the hardware design, I need to go over the software design first.
The advantage of using a terminal emulator to interact with the programmer is that the programmer can be used on any platform without needing an additional software for that platform. Given that commercial solutions already exist for Microsoft® Windows®, I am much more willing to accept a software architecture that requires software to be run on the host platform, if there is a corresponding cost reduction. For the EMDP1, I have totally eliminated the RAM buffer found on the other two reference designs. However, this part savings comes at a cost of requiring more sophisticated software to be run on the host platform.
The next issue is what should the division of labor be between the host and the EMDP1? Given that most host platforms have plenty of memory and disk space and very reasonable software development environments, it seems like most of the software should actually run on the host platform, with substantially less running in the EMDP1. The division of labor that makes the most sense to me is for the EMDP1 to do all of the timing sensitive stuff and leave the rest to the host software. This software design fits well with the decision to elminate the RAM buffer. The plan is download a little data, program it in, and repeat until done.
In order to meet the goal of being extensible, I liked the idea of having downloadable device drivers for doing device specific tasks (e.g. the Beard design.) So the basic concept is that the user will select the appropriate adaptor card and plug it into the EMDP1. The host software will notice which adaptor card has been plugged in and automatically download the correct device driver. (This means the adaptor card will have some sort of hardware identifier.) Then the user will select a specific device and start programming.
Finally, I get really tired of programs that are not architected to be easily integrated together with other programs. The host software for the EMDP1 is run as a server that can be connected via a TCP/IP stream so that other applications can utilize the device programmer services.
There is much more software design to go, but this high level software archictecture allows me to proceed with the hardware design decision.
Probably the first hardware design decision is to choose a microcontroller. I picked the MicroChip PIC16F877 for several reasons. The first reason is because it supports the ability to download code into its flash memory. This capability is needed to support downloadable device drivers. The second reason is because the 'F877 has LVP (Low Voltage Programming) mode. This means that the 'F877 can be initially programmed using the LVP mode via a parallel port. Thus, the EMDP1 will not have the bootstrap problem that plagues both the Ball and Beard designs mentioned above. The third reason for choosing the 'F877 is because I am already quite comfortable with developing code for this device; indeed, I have my own programming language called µCL, [Gramlich2000] that I use to program PIC microcontollers in. The 'F877 also has an embedded UART that is used for serial communication.
The next issue to deal with is the power supply. I personally do not approve of hardware designs the skip out on either the power supply design or case design. My preference is that the EMDP1 use a single `wall wart' power supply. The reason for choosing a `wall wart' is because it means that someone building the EMDP1 from scratch will not have to deal with 110VAC or greater voltages. The disadvantage of choosing a `wall wart' supply is that it means that all other voltages must be generated from the single incoming supply voltage.
Internally, I need 5 volts for most of the logic chips and 24 volts for the programming voltages. The basic choice is between getting 24VDC transformer and stepping down switcher to 5 volts, or getting a 6VDC transformer and stepping up 24 volts. I can use a µA78S40 [Jameco Part Number: 51238] universal switching regulator subsystem for either a step up or step down converter. Motorola Application note 920 [AN920] provides all of equations and examples needed to figure out all of the needed resistor, capacitor and inductor values. I have gone through the design steps for both the step down and the step up power supply designs. The parts count and costs are pretty similar. I eventually picked the 6VDC transformer because that way I could alternatively grab my power from the SimpliciNet hub [Gramlich2001]. This is not a very compelling reason to me, but given how even the design choice was, it was enough to nudge me over to the 6 volt to 24 volt step up design.
The EMDP1 uses either RS-232 or RS-422 via SimpliciNet cabling and protocols. The RS-232 connection will be via a MAX232 and a DB-9S. The EMPD1 also has a SimpliciNet RJ-45 connector.
The voltage controlled supplies are pretty similar to the Ball design, only I use a MAX518 because it seems to be substantially less expesnsive than the MAX505 that Ball used in his design. I switched over to a LM1458 to save a little board space. Everything else is the same.
The EMDP1 mother board communicates with each adaptor board via a 37 conductor ribbon cable bus that contains power, ground, and 35 signal wires. Where the magic number 37 comes from is discussed a little further below.
My first cut at assigning pin-outs to the 37-pin bus is listed below:
When it comes to adaptor boards, I am quite firm about wanting the EMDP1 to be `perf-board friendly'. What is perf-board and what does `perf-board friendly' mean? Perf-board is short for perferated board and consists of a fiberglass board that has been drilled in a .1 inch grid (e.g. Jameco part number 52943.) It is easy to prototype new circuit designs on perf-board, particularly if the component leads align with .1 inch grid (such as DIP's, IDC ribbon cable headers and the like.) Thus, if you get your hands on some hot new chip that does not have a printed circuit adaptor board yet, you can instead prototype a new adaptor on perf-board.
So what, in detail, does `perf-board friendly' really mean? What it really means is that the connectors to the rest of the EMDP1 must be compatible with the .1 inch perferated grid. Ribbon cable headers are easily obtained that adhere to .1 inch grid. Since I need to get 37 wires signals to and from the main board, each adaptor board has a 2 × 20 male ribbon cable header at the top, where only 37 of the 40 pins are used. In addition, each adaptor board has four rubber feet at the four corners to hold it off the top of the EMDP1 case. There is no additional box structure surrounding each adaptor board.
In order to avoid having ribbon cables flopping through holes in the EMDP1 case, the 40 conductor cable will be run through a male/female 37-pin `D' connector. 37-pin `D' connectors are readily available from vendors (e.g. Jameco 115991, 116003.) By the way, this is where the magic number 37 comes from. The 3 extra wires on the 40 conductor ribbon cable are snipped off at the 37-pin connectors. The picture below should help visualize all of this:
The main EMDP1 board is mounted upside down in the case. The 80-pin plug, ZIF socket are soldered to the bottom of the board and stick through holes cut in the top of the case.
The following equations exactly follow the examples shown in the Motorola Application Note 920 [AN920] for a 24 to 5 volt step down power supply.
Power Supply Characteristics:
The following equations exactly follow the examples shown in the Motorola Application Note 920 [AN920] for a 6 volt to 24 volt step up power supply.
Power Supply Characteristics:
