New chips for libtoprammer

[tomvleeuwen]

Hi Michael,

I recently found libtoprammer, and I wish I had found it before. I especially like it since it runs on Linux and since I can add support for the CAT28F102 flash chip (which is not present in the original software)

I added support for the 27C1024 and 28F102 to libtoprammer.
I currently have not tested the write function of the 27C1024, since I only have OT-PROM's.
The 28F102 works correctly with my CAT28F102N-90.
The code reads the device ID and manufacturer ID as "signature", which is not present in the 27cxxx version, but I thought it would be nice to have.

I also added a little hack that re-tries reading the version string (4b9ea36) since this is the first action on the USB bus. I often had problems running libtoprammer for a second time without disconnecting/reconnecting the programmer (especially when using the GUI or when an exception occurs), but this fixes that problem.

I am planning to test the write function of the 27C1024 by flipping some bits to zero on an old OT-PROM, I will let you know if it works.

I am also thinking of a function that checks the connectivity of all pins, by applying VCC to the GND pin and having all other pins floating (due to the ESD protection diodes, all pins shall be high), Applying GND to the VCC pin will do the same check in reverse, but I think the TOP2049 will always read '0' if a pin is not connected. Checking pin connectivity is important for me since I use a PLCC44 converter in combination with OTPROMS, so a floating pin is quite common but it would ruin the chip.

Regards,

Tom

[mbuesch]

Thanks a lot for your contribution!

I'm wondering what the difference between 27c1024 and 27c512 is and whether it really is required to have a separate implementation. Would it be possible to add support for 27c1024 to the existing 27cxxx chip support driver?
The idea behind this is to keep the testing effort minimal. There already are a lot of drivers that I can't test, because I don't have the actual chips.

The retry loop I think is a good idea. Can you please create a separate pull request for this, so I can merge this right away. Also please add a time.sleep(0.05) after failure before retry. We should give the device some time to recover. 5 or 10 repetitions probably are enough, too.

[mbuesch]

Is there any news on merging the 27c1024 Python code into chips/_27cxxx.py?
(Further discussion was here: #2)