Quote:
All these home-brew project have strange or unacceptable prerequisites.
One cause of that is that, outside of the now non-existent parallel port, there aren't many means to communicate data with a PC that don't require the other end of that communication to be already programmed in some way. So it's always a chicken and egg problem as you need a programmer to build a programmer.
...but then, thinking of this made me realize I've already solved that problem:
My Z80-Based EEPROM ProgrammerIt's worth repeating here, even though it says as much on that page: You don't have to program any chips to make that circuit work. You just buy the blank EEPROM, build the circuit, run my ****** Perl scripts in Linux, and you can program an EEPROM over a USB port in five seconds. (Not counting the hours spent figuring out how to install Linux, the hours spent figuring out why a script that runs just fine in my Linux doesn't work at all in your Linux, and the hours spent figuring out the four different ways you mis-wired the circuit, of course. That stuff doesn't count.)
Anyway, where that design becomes useful here is that you don't have to build it so that it is ever able to run in "normal mode," nor do you have to put any SRAM or EEPROM into the circuit in order for it to be useful. You can instead send the instruction sequence for "write byte 0x5E to I/O port 0x27" and the Z80 will do that, transferring that data byte to whatever you've wired up to that port address. Similarly, you can send the instruction sequence for "read a byte from I/O port 0x27 and write it to memory address 0x0000" and it will read that byte and send it back to the PC over the FT240X link. So what you do then is just wire up some 74HC573 as input ports and some 74HC574 as output ports and now you've got as many I/O lines as you want under the control of software running on your PC, all without having to program a single chip. Additionally, if you do put SRAM into it, you have the advantage that you can then write code into that SRAM and utilize it to run timing-sensitive operations rather than have to rely upon accurate timing from the PC.
So in theory, if someone were to take the time to draw a PCB of that circuit built with basic logic gates as it is shown on my web site, then anyone could order ten of that PCB for $25 from dirtypcbs.com, and if anyone felt like being helpful to other forum members, they could mail the other 9 boards they don't need to other people for free. I'm pretty sure the circuit will fit on the 10 cm x 10 cm board, as I've almost done it myself (just without the reset circuit, as I used an ATtiny13A for that), it's just ugly as hell when it's all done since there's no way to arrange the basic logic gates such that you're not running half the signals half way across the board, and so that was when I looked into programming the ATF22V10C. (You can see the results at the bottom of
this post on my blog.) ...but someone more talented at PCB layout than myself can probably find a way to make it all fit elegantly despite using only the basic logic gates, especially since if one strips out the ability for the board to switch to "normal mode" then that eliminates the need for like half of the logic. Using a header pin to attach the I/O bus externally (like I did for the one shown on my blog), one could then use a ribbon cable to attach various modules designed to program specific chips.
That of course still leaves the problem of software. The ideal solution would be to create something written in C that compiles in MinGW, so that it could be compiled for both Linux and Windows. The two OSs have totally different means for accessing serial ports, so the access to the FT240X would have to be custom-written for each OS (and don't use FTDI's special driver, as it requires unloading the virtual COM port driver, which no-one wants to do as FTDI devices are common and they all require the virtual COM port driver), but the rest of the software (programming algorithms, acceptance of command line parameters, configuration files, reading various file formats of data to be programmed into chips, etc.) would just be basic C and so the same code would run on both systems. Unfortunately, my code is Perl scripts due to having written it before I learned C. ...but, at least in theory, someone who knows how to do Perl in Windows could easily modify those scripts so that they run in Windows, but that's still only half of the problem since my code only addresses the programming of an EEPROM. ...and Perl just seems like a bad idea anyway.
Quote:
or even better 6502 based
While I'm not familiar with the 6502, I imagine there's a good possibility that the same algorithm could be utilized to build the circuit around a 6502 rather than a Z80, as it doesn't rely on anything Z80-specific. However, I *know* it works with the Z80 as I've built it many times and never had any trouble with the circuit, so the Z80 would have to be my recommendation even though I know it isn't the favorite CPU around here.
Quote:
I would prefer a solution that is software configurable as much as possible instead of requiring tons of adapters or a plethora of sockets.
I wouldn't go that route. As you mention, there are many things that a pin might need to do, and even if you find a circuit that provides for every possibility you can imagine, not only do you have to duplicate that circuit for every pin, but you also have the problem that the circuit still doesn't account for things you haven't considered, and there's *always* something you haven't considered.
E.g., despite the SPI programming of AVR chips being simple, I've already gone through two revisions, both to address the same problem, which was that the previous version wasn't providing strong enough outputs. The current one uses transistors so that each SPI output can provide 500 mA. It's overkill to do that for every pin when programming most chips, but it's good for the AVR since in-circuit programming is quite useful, but with so few pins on the less-expensive chips, I'm often using the programming pins for something else in the circuit, and so the programmer needs to override those voltages. Obviously I use resistors so that the voltages being provided to those pins by the circuit are weak and easy to override, and so it doesn't necessarily need 500 mA, but at the same time, if it fails to provide enough current, it potentially misprograms the chip such that it no longer accepts SPI programming, effectively bricking it until I build the more complex parallel programmer. (Which I did, it was part of my GAL programmer, but then I removed that portion. I'm just going to hope my latest version of the programmer doesn't brick any more chips and so I won't need it again.)
So basically I just think it's best to use unique circuits for each chip, that way each module can perform as well as it possibly can rather than being limited to the capabilities of the universal socket. That said, I do think a semi-universial socket would be useful. For example, many EPROM chips are very similar and so they might as well all use the same module. Also, I wouldn't worry too much about supporting every existing EPROM chip, but instead just focus on modern standards like just 12 volt programming voltages and only on the pins where it is common to apply it. I wouldn't expect to ever *have* to program anything else, since if the situation arises, there's always the option of ordering a modern replacement from Digikey which will certainly be programmed in a more modern way. E.g., those AT28C256 EEPROMs I wrote my software for can certainly replace any 32 kB EPROM or Flash memory, so if I needed to reprogram one of those old UV-erased EPROMs, I'd just toss it in the trash and replace it with an AT28C256 as it wouldn't be worth the effort of doing anything else.
Login
Register
FAQ
Search
