This is the rationale for the EMPD2 project and should be considered to be a work in progress.
The reason why I design and build my own device programmers is because the commerical offerings are both expensive and closed. For me, the commercial device programmers suffer from the following problems:
Does vendor desupport really happend? Yes, it does. Let me tell you the story of a friend of mine that decided to purchase the Needham Electronics EMP-20. This was a sizable investment, but the EMP-20 has an impressive list of devices that it is capable of programming. One day, he decided he wanted to upgrade his processor from a rather ancient version of Windows to something a little less ancient. When he asked about upgraded Windows software for the EMP-20 he was told that newer Windows software was only being made for the newer EMP-30; there would be no software upgrade for the EMP-20. I suspect that my friend was not the only person unhappy about this policy, since Needham Electronics eventually came out with the EMP-21, which was a reengineered EMP-20. None-the-less, in order to upgrade to newer software, my friend was going to have to purchase an new and expensive EMP-21 or EMP-30 when there was nothing wrong with his existing EMP-20. By the way, my friend would was willing to pay for upgraded software, but no deal. If he wanted new software, some sort of unnecessary hardware upgrade was required. He decided to give up on Needham Electronics instead. This story illustrates the problems of using the existing commerical device programmers out there.
Given the general lack of open source device programmers I wound up working on my own.
I never got trapped in the vendor lock in scenerio disussed above. Instead, I wound up designing my own parallel port PIC programmer that is pretty much like many of the other ones out there. It is not an exciting design, but it definitely gets my various PIC based projects programmed.
There are all sorts of other interesting devices out there that I would like to try out in my various electronics projects, but the lack of a programmer has always prevented me from using them. Obviously, what I wanted was an extensible programmer that was open and extensible rather than closed and proprietary. In addition, designing such a programmer, would be a fun and interesting project for me as well.
My research on the topic took me to a couple of magazine articles on extensible programmers and the CUMP project. The first programmer is written up in a two part magazine article by Stuart Ball in August (issue 97) and September (issue 98) issues of Circuit Cellar. The second programmer is the LP120 by Brian Beard written up in the December 2000 and January 2001 issues of Nuts and Volts. Both magazine articles published the schematics and software, but each one had sufficient concerns that I decided not to go with either one and design and instead set off on my own. I also ran across a project, called CUMP, for Community Universal Microcontoller Programmer. I joined the CUMP on-line group and we basically pounded out a 37-pin bus specification that we could all live with. The history leading to the EMPD2 spans a number of years.
I went off and designed my own programmer called the EMDP1 for Extensible Multiple Device Programemr 1. The EMDP1 uses the CUMP bus specification for extensibility. Before sending the EMDP1 off to be manufactured, I decided I needed at least one adaptor module to plug into it. After designing one adaptor, I designed a whole family of EMDP1 adaptors. When I looked at the adaptors, they were all pretty similar, they all basically took various signals from the CUMP bus and rerouted them to the appropriate pins on a ZIF (Zero Insertion Force) socket. I always needed a some sort of little plug to on the adaptor itself to do some additional rerouting. Eventually I asked the question "is there some way I can combine most of these boards into one?" The answer was a definite "yes!" and resulted in the revision C (and D) of the EMDP1. For these revisions, the programmer proper has both a CUMP extension bus and an on board ZIF socket with a rewiring plug.
The next question is "are there any adaptors that need the CUMP bus?". The answer is "yes, but not many". The EPROM adaptor needed even more pins than were present on the CUMP bus. Hence, the EPROM adaptor had a couple of extra latches, followed by the standard rewiring plug. The latches are cheap and could easily be migrated to the main board.
What I learned from the entire experience of designing the EMDP1 adaptors is that there are three issues that impact adpator design for a given device:
Evenually somebody on the CUMP mailing asked for a potentially smaller version of the CUMP bus. The resulting discussion has caused me to conclude that the initial CUMP extensibility bus was a good first try, but it is unlikely to very useful in the long run. Thus, the EMDP1 and its corresponding adaptors is never going to be manufactured by me. The time has come to start over again with the EMDP2.
The EMDP2, is based on the lessons learned from designing adaptors for the EMDP1. The EMDP1 extensibility bus is a serial bus based on industry standard RS-422 signalling rather than a parallel bus. The EMDP2 serial bus requires that each adaptor have its own dedicated microcontroller with hardware UART; this requirement is deemed acceptatble since microcontrollers have become so inexpensive. There is the issue of how to program the adaptor microcontroller in the first place, but that is an easily managed problem that is discussed below. In addition, the EMDP2 adaptors can be easily daisy chained. However, if the voltage drops and/or current draw going down the daisy chain become too significant, multiple EMDP2 adaptors can be plugged into a EMDP2 bus expander instead. Each EMDP2 bus expander has its own power supply, so that current draw and voltage drop should not as much of an issue.
{more goes here}
{Talk about bootstrapping here.}
Many people suggest using I2C® as the bus to connect the extensible programmer master to its associated adaptor(s). Every time I evaluate I2C for this application, I conclude otherwise. The remainder of this section outlines issues that I have with I2C as a master to adaptor interconnect bus.
The first step is to read the I2C specification. Please pay particular attention to sections 15 through 18.
The next step is to play around with a proposed adaptor design. For example, let's do an easy adaptor -- an adaptor for programming the PIC16C505. The PIC16C505 is programmed with two wires -- a serial clock and serial data line. The '505 is programmed with a sequence of 100µSec progamming pulses. Each 100µSec pulse requires clocking in a 6 bit start programming command, followed 100µSec later by a 6 bit stop programming command. These 100µSec pulses are continued until the word is verified as being properly programmed.
For this adaptor let's use the Philips® PCA9555. This is a 16-bit I2C port expander. Since we only need 2 bits to program the '505, we could get by with a smaller 8 bit port expander, but the PCA9555 will demonstrate all of the issues just as well.
In order to start the programming pulse, we can take as long as we want to clock in the 6 bit start programming command. However, afterwards, we have to have to clock in the 6 bit stop programming command in 100µSec. This requires, 6 up transitions and 6 down transitions of the '505 clock pulse. In order to achieve the required 12 clock transitions, we need to toggle the '505 clock line every 100µSec/12 = 8.3µSec.
A full command to the PCA9555 requires 4 frames of 9 bits (8 data + 1 acknowledge) each frame. The first frame is the device address, followed by a command frame, followed by two data frames. Thus, without any trickery, we need to clock the I2C SCL line 4 × 9 = 36 times in 8.3µSec. This requires a SCL clock pulse every 8.3µSec/36 = .2314nSec. This is a SCLH clock frequency of 4.321MHz. Alas, this exceeds the maximum I2C clock frequency for HS mode of 3.4MHz.
But wait, can't we use an 8-bit port instead of 16 bit port and save a 9 bit frame? Yes. Can't we use repeated start to prevent sending the same address over and over? Yes. We've now cut the required frequency from 4.321Hz to 2.16MHz which is in the I2C HS mode range. Is it possible to trim the frequency even further? Perhaps, there is an 8-bit I2C port that requires no command byte. (I don't know of any, but I am hardly familiar with all of the I2C compatible devices on the market.) No matter what, the point that I am trying to make is that trying to use a basic I2 port to wiggle the clock line fast enough to program a '505 is a pretty challenging task for the I2C bus. It is possible, but it definitely requires running the I2C bus in HS mode at a 1MHz or greater; the FAST and STANDARD speeds for the I2C bus are definitely not be adequate for the task.
Please note that the argument above only applies to using I2C I/O port chips. If the I2C is being used to talk to a dedicated microprocessor with I2C slave hardware, the microprocessor can have dedicated code to meet the most stringent timing requirements; generating 100µSec pulses is trivial for a dedicated microcontroller.
The next issue with I2C is bus capacitance management. Please be sure to read sections 15 through 18 of the I2C specification. Note that in table 7 on page 46, that running the I2 faster that 1.7MHz requires that the bus capacitance be kept to 100pF or less. For 1.7MHz and below, the maximum bus capacitance is 400pF.
If you examine figure 39 on page 46 of the specification, you discover that the pull up resistor (Rp) for HS mode varies with the bus capacitance. Thus, for HS mode the combined capacitance of the master and the adaptor needs to be determined prior to picking the the value of Rp. If you want to used a fixed value for Rp, every time you plug a different adaptor into the I2 bus, you must ensure that the total bus capacitance does not change. There is some wiggle room here. Rp could be placed on the adaptor module, in which case only the capacitance of the master module and cabling needs to be fixed. Finally, it is possible to provide a processor contrlled resistance for Rp, but that is some pretty tricky engineering as well. Does this mean that it can not be done? No, somebody who is truly dedicated to the idea can probably carefully work out all of the engineering details, but it is by no means simple engineering to get HS mode I2C to span between the master and interchangable adaptors.
There are some people who would like to daisy chain adaptors using the I2C bus. For HS mode, this is a very difficult task due to the capacitance managment issue discussed above. For FAST and STANDARD mode, managing Rp is not an issue, but the I2C bus is still only specified to run on a bus whose total capacitance is 400pF or less. Once, the 400pF capacitance allowance is consumed there can be no more daisy chaining.
In section, 17.3 of the I2C specification they mention the topic of cross talk. Here is a little snippet from that section:
In general, the wiring must be so chosen that crosstalk and interference to/from the bus lines is minimized. The bus lines are most susceptible to crosstalk and interference at the HIGH level because of the relatively high impedance of the pull-up devices.
If the length of the bus lines on a PCB or ribbon cable exceeds 10 cm and includes the VDD and VSS lines, the wiring pattern must be...Basically, cross talk starts to to be a problem on an I2C after about 10Cm of bus length. Since 10 Cm is not that long, any master to adaptor design is going to have to worry about crosstalk. The specification does give some guidance towards reducing crosstalk, but it does not suggest how much longer the bus can become if this guidance is followed.
In summary, my analysis of using the I2C bus for this application is that HS mode is required to use I2C port devices and the engineering required for HS mode between master and adaptor is extremely challenging. If there is an microprocessor required on every adpator board, then either FAST or STANDARD I2C mode could be used instead; however, I2C provides no significant advantages over lower cost designs based on asynchronous communication and higher noise immunity signalling such as RS-422. In general, microprocessors in the same vendor family with I2C slave support tend to cost more than those microprocessors with only UART support.