Cheap ATF22V10 Programmer?

[Moosfet]

I was thinking of maybe putting together a design that people can build, but I'm never going to do that. So, for whatever it's worth, here's a picture and the files for the programmer I built:

Low-resolution: http://imgur.com/QMLdn3n
High-resolution: http://imgur.com/UFka1y5

http://www.ecstaticlyrics.com/electroni ... c_junk.zip

Obviously that design isn't easy to reproduce. I only bother to mention it to point out that there are options between spending $160 on a commercial programmer and finding an old PC with a parallel port that you can install DOS onto.

There's no reason a programmer needs to cost $160. That FT240X module cost me about $5 (actually $57.12 for 12 of them, but they're damn useful so it's good to have 12 of them), the ATtiny48 is a $2 chip, the other two logic chips are about $1, all of the other components certainly add up to only a few dollars, and the two pieces of solderless breadboard were probably about $12. The problem are the pre-requisites: You need an AVR programmer (though I'd argue that everyone should have one, as those chips are cheap and useful), and you need software, but the way I do things makes my software incompatible with everyone else's way of doing things. Thus I can't provide AVR code that someone can use if they happen to have an AVR programmer, and my programming script is unlikely to work for anyone other than me.

...but if someone is desperate for a starting-point, it's all there in that ZIP file. It's all useless, but it's all there.

[cbscpe]

Moosfet wrote:

There's no reason a programmer needs to cost $160. That FT240X module cost me about $5 (actually $57.12 for 12 of them, but they're damn useful so it's good to have 12 of them), the ATtiny48 is a $2 chip, the other two logic chips are about $1, all of the other components certainly add up to only a few dollars, and the two pieces of solderless breadboard were probably about $12. The problem are the pre-requisites:

And that's exactly the problem. All these home-brew project have strange or unacceptable prerequisites. And these prerequisites will cost you a lot of time and sometimes even money. I would rather like to see a universal home-brew programmer project that does not rely on a parallel port and very outdated operating systems. And as time is money $160 is not that much when looking at the total costs.

I already thought about having a universal "programmer" with a serial interface that could be programed to act as a universal programmer. A small microcontroller/computer (AVR, PIC or even better 6502 based) with a serial interface and a decent protocol that supports at least GALs (incl. Atmel), AVR, PIC, EPROM, EEPROM, FLASH, and perhaps a JTAG interface would be a nice project. Even if it would cost $100 or more to build it would be acceptable from my side, as long as it is not a closed source design.

[nyef]

cbscpe wrote:

Moosfet wrote:

There's no reason a programmer needs to cost $160. That FT240X module cost me about $5 (actually $57.12 for 12 of them, but they're damn useful so it's good to have 12 of them), the ATtiny48 is a $2 chip, the other two logic chips are about $1, all of the other components certainly add up to only a few dollars, and the two pieces of solderless breadboard were probably about $12. The problem are the pre-requisites:

And that's exactly the problem. All these home-brew project have strange or unacceptable prerequisites. And these prerequisites will cost you a lot of time and sometimes even money. I would rather like to see a universal home-brew programmer project that does not rely on a parallel port and very outdated operating systems. And as time is money $160 is not that much when looking at the total costs.

I already thought about having a universal "programmer" with a serial interface that could be programed to act as a universal programmer. A small microcontroller/computer (AVR, PIC or even better 6502 based) with a serial interface and a decent protocol that supports at least GALs (incl. Atmel), AVR, PIC, EPROM, EEPROM, FLASH, and perhaps a JTAG interface would be a nice project. Even if it would cost $100 or more to build it would be acceptable from my side, as long as it is not a closed source design.

I'm thinking Arduino based, at least as far as hardware goes. Inexpensive, USB interface, easily programmed from a host machine, looks like a serial port once it gets going... Use a Mega R3 or similar and you have tons of I/O pins to work with. And part of the point here is that it comes with a boot loader that lets you reprogram it via USB, so there's no issue of needing a ROM programmer in order to burn the ROM to make your ROM programmer work.

[cbscpe]

Arduino is an option. I think the challenging part are the "universal" Pins for the "universal" Socket. Each pin needs to be programmable is input, output with variable signal levels (aka 5V and 3V3 logic) or are grounded and others optionally source the (variable) power voltage (some EPROMS require that VCC is risen to 6.25V during programming) and the programming voltage. Older devices need up to 27V, current devices tend to use only 12V or 12.5V. I would prefer a solution that is software configurable as much as possible instead of requiring tons of adapters or a plethora of sockets. Anybody has a copy of a schematic of such a design or is anybody aware of a IC that integrates all these features?

[Moosfet]

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 Programmer

It'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.

[BigEd]

We've had threads before about the bootstrapping problem. It's always there for boot code, and if you design with GALs, PALs, PLDs, CPLDs or FPGAs then it's also there for the logic itself. I'm sure I've seen a video of someone hand-toggling SPI protocol on a breadboard - to program a minimal bootstrap by hand in bit-serial format probably isn't more than an hour or two's work. Parallel-loading an EEPROM in-circuit is going to be faster and easier. For me, it would always be a matter of toggling in a minimal bootloader and then proceeding with serial - which these days is usually serial via a USB dongle, although the laptop I'm on now does have a genuine serial port.

The solution of having preprogrammed chips mailed from other forum members is a very practical one.

And then, there's building a circuit specifically for programming, as you've done - thanks for publishing your work and linking it!

[BigDumbDinosaur]

Moosfet wrote:

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...

The parallel port is hardly "non-existent." Cards are readily available to be plugged into the PCI slots of a PC.

[Tor]

Most PCs these days are laptops or notebooks, and they don't even have Ethernet ports anymore.. just wi-fi and USB. So those are the options we can work with.

[BigEd]

I've got a little laptop from 2001 which I've kept around because it has a parallel port. And there's always the BBC micro... but writing something to play JTAG files would be a little extra challenge. The Raspberry Pi is almost certainly another option. Or even an Arduino - see JTAGWhisperer.

[joanlluch]

Hi All,

I am aware this thread is rather old, but since 3+ years have passed I wonder if there's any update on this. Particularly, what's the right programmer (a.k.a the one that will work reliably) to program Atmel ATF22V10 and ATF16V8 plds? The weilei web site claims that the VP-290 programmer supports the mentioned plds (http://www.weilei.com/VP-290list.htm#ATMEL), however earlier posts in this thread suggest the opposite. Also more expensive programmers seem to support these chips as well, so I'm confused on what to use. I am ready to pay for a more expensive programmer as long as it's guaranteed to work reliably. Anyone with updated experiences on this?

Thanks

Joan

[dourish]

As of June 2019, I have been successfully programming Atmel 16V8s using the latest Minipro programmer (the TL866II, *NOT* the prior versions -A and -CS). I think that technically it's now called the Xgecu, not the Minipro. You must make sure that you are using the latest firmware (V8.51 at the time of writing).

I haven't tried Lattice GALs personally, although support for those was already there; support for the Atmel devices is the recent addition. It's been working well for me.

--p.

[floobydust]

I've been using a Dataman 40Pro for several years now. It easily programs the Atmel chips and Dataman also updates their software on a regular basis. The only Atmel chip (which I have in my little collection) which gave me a bit of trouble was the ATF750CL, which requires a 0.1uF cap be placed across the power pins when being programmed. They do mention this in their notes, amd they offer an adapter that has the cap(s) installed, but at an absurd price. I just fitted a cap into the same pins in the ZIF socket and it programmed and verified fine.

There's only one downside to the Dataman, it's expensive... but it's been flawless since day one in operation. Overall, I've been completely happy with it and it's one less tool I need to futz around with when working on projects.

[cbscpe]

Good to know that there is at least one cheap programmer that works with Atmel GALs. Have you tried the 22v10 as well?
Personally I have completely switched to the Atmel CPLDs ATF1504/08. The in-circuit programability is very usefull and they provide a lot more features and are still easy to use.

[LIV2]

I believe someone mentioned previously that the Minipro could do Atmel 16V8's but not 22V10's so I'd be interested to know if the XGECU supports 22V10s as I've got a tube of them I'd like to use someday

[drogon]

cbscpe wrote:

Good to know that there is at least one cheap programmer that works with Atmel GALs. Have you tried the 22v10 as well?
Personally I have completely switched to the Atmel CPLDs ATF1504/08. The in-circuit programability is very usefull and they provide a lot more features and are still easy to use.

Are there any Linux tools for them yet?

Thanks,

-Gordon