EEVblog #411 - MiniPro TL866 Universal Programmer Review

[BravoV]

Is far enough! i have an experimental replacement firmware for that Attiny13, and also the first version of Linux version of my firmware updater is ready to be tested here:
https://github.com/radiomanV/TL866

There's no do documentation yet on how to compile but i will update the readme file soon. Who want to contribute are welcome. Thanks.

Hey radioman, I'm a noob when it comes to programming, let alone using Linux  , just a stupid question if you don't mind. 

As long its supported by the existing hardware design, will your work there open the "opportunity" to support other chip that is not officially supported ?

[radioman]

Hey radioman, I'm a noob when it comes to programming, let alone using Linux  , just a stupid question if you don't mind. 

As long its supported by the existing hardware design, will your work there open the "opportunity" to support other chip that is not officially supported ?

well, the response is yes and no how the whole thing is working? simple, we have three major layers here:
1.PC software application
2.Device firmware
3.Hardware

The PC software application do not talk directly with the hardware but with the device firmware instead. The device firmware is implemented as a collection of programming
algorithms; for example the 24C (i2c) series have a dedicated algorithm in firmware, 25 spi series have another dedicated algorithm and so on. Currently the 3.2.62 firmware version have exactly 41 programming algorithms.
 All of those >13000 supported chips belongs to one of the 41 programming algorithms, so if we want to add a new chip,
then that chip must have the programming algorithm implemented in firmware, if no we are out of luck

The PC software is nothing more than a chip database manager which sends simple programming primitives to the device firmware which in turn do all the dirty job!
So programming a chip is like this:
1.PC software sends a simple command to the firmware like "Select protocol nr. X", the device firmware will then switch to that programming algorithm
2.PC software sends/receive data blocks to/from firmware, the firmware will do the dirty job of manipulating pin drivers and talking with the chip

The problem is not the PC client software but the device firmware! Simple eh?

Yes i know FM1608 , DS-1225 

Here is the supported chip list arranged by programming  algorithm

[Kjelt]

What we actually need is an open hard and software universal programmer, that would be a great forum team effort.

[eprom]

Hi I use this adapter please see the attachments pics my programmer is tl866a.
Thanks

The Solution is on the second Picture, the Bottom of the SOP-Adapter.
Look at the lower left corner, there is one wire which ends without any connection. This is A15, so one Adressline is floating.

[radioman]

Look at the lower left corner, there is one wire which ends without any connection. This is A15, so one Adressline is floating.

Huh! wireless connection  this is advanced tehnology...

[linux-works]

its the 'randomness bit'.  leave it alone or you'll lose all your entropy!

(lol.  no, not serious.)

[jinzo]

Hey radioman, I'm a noob when it comes to programming, let alone using Linux  , just a stupid question if you don't mind. 

As long its supported by the existing hardware design, will your work there open the "opportunity" to support other chip that is not officially supported ?

well, the response is yes and no how the whole thing is working? simple, we have three major layers here:
1.PC software application
2.Device firmware
3.Hardware

The PC software application do not talk directly with the hardware but with the device firmware instead. The device firmware is implemented as a collection of programming
algorithms; for example the 24C (i2c) series have a dedicated algorithm in firmware, 25 spi series have another dedicated algorithm and so on. Currently the 3.2.62 firmware version have exactly 41 programming algorithms.
 All of those >13000 supported chips belongs to one of the 41 programming algorithms, so if we want to add a new chip,
then that chip must have the programming algorithm implemented in firmware, if no we are out of luck

The PC software is nothing more than a chip database manager which sends simple programming primitives to the device firmware which in turn do all the dirty job!
So programming a chip is like this:
1.PC software sends a simple command to the firmware like "Select protocol nr. X", the device firmware will then switch to that programming algorithm
2.PC software sends/receive data blocks to/from firmware, the firmware will do the dirty job of manipulating pin drivers and talking with the chip

The problem is not the PC client software but the device firmware! Simple eh?

Yes i know FM1608 , DS-1225 

Here is the supported chip list arranged by programming  algorithm

What about reverse engineering the firmware/fw algorithms? So there's already an open source PC client software, there's the updater that can be used to interchange the FWs, there's the schematic and a lot of other info (let's say which algorithms have the most devices in the list). I know that's not easy - but what I'm wondering if it's feasible? I tried to look up different programmer designs/protocols but didn't find much info on what a good design of such a system/protocol would be. So I'm wondering, would a completely new system/protocol be better? There doesen't seem to be much open source programmers which could be used as a base software or are they?

[matekhr]

Look at the lower left corner, there is one wire which ends without any connection. This is A15, so one Adressline is floating.

Huh! wireless connection  this is advanced tehnology...

Here's my old fashioned, non wireless model:

[radioman]

Good! now we have two sop44 adapters version, wired and wireless, this is just amazing 

What about reverse engineering the firmware/fw algorithms? So there's already an open source PC client software, there's the updater that can be used to interchange the FWs, there's the schematic and a lot of other info (let's say which algorithms have the most devices in the list). I know that's not easy - but what I'm wondering if it's feasible? I tried to look up different programmer designs/protocols but didn't find much info on what a good design of such a system/protocol would be. So I'm wondering, would a completely new system/protocol be better? There doesen't seem to be much open source programmers which could be used as a base software or are they?

Yes, if we keep the bootloader, a new firmware can be made to work with those unsupported chips.

[BravoV]

The problem is not the PC client software but the device firmware! Simple eh?

Appreciate the long post in explaining that, its crystal clear now ! 

Cmiiw, the mechanism here is like the old day computing buzz word ... "client & server" thingy  , the client is just the pretty front end, while the "server" part is that poor little mcu that is doing all the dirty works.

I guess the real challenge & probably hard work is on the reverse engineering the whole circuit diagram + the mcu's code, aren't they ? 

Yes i know FM1608 , DS-1225 

Hey, thanks a lot for remembering that ! 

If you seriously decided to implement that "someday"  , just PM me, I will be happy to send you the Ramtron FM1608-120-BG f-ram chip for you to play with. 

Your skill sets regarding this matter, and the persistence all this time are a proven track record. 

[romantronixlab]

Going Back to sellers on eBay I saw see-ic had good prices on the programmer and adapters, Has anyone bought and item from them, are they reliable?
eBay auction: #http://www.ebay.com/itm/170979794939?ssPageName=STRK:MESINDXX:IT&_trksid=p3984.m1436.l2649
eBay auction: #http://www.ebay.com/itm/170979738011?ssPageName=STRK:MESINDXX:IT&_trksid=p3984.m1436.l2649

[jinzo]

Going Back to sellers on eBay I saw see-ic had good prices on the programmer and adapters, Has anyone bought and item from them, are they reliable?
eBay auction: #http://www.ebay.com/itm/170979794939?ssPageName=STRK:MESINDXX:IT&_trksid=p3984.m1436.l2649
eBay auction: #http://www.ebay.com/itm/170979738011?ssPageName=STRK:MESINDXX:IT&_trksid=p3984.m1436.l2649

I bought the TL866CS with some adapters for a friend from them (CS + the second link adapters it seems) - no TSOP tho. So I don't know if they sell the genuine TSOP adapters (or their quality) but otherwise they were good. The package was quickly shipped and neatly packaged. Stuff looked ok and worked good. So quite decent seller from my experience (but I didn't deal a lot with them).

[eLAB]

Check this seller (I bought from him and few more friends)..before buying I asked him about TSOP-48 adapter is it genuine or fake? He sent me pictures to see that it`s genuine adapter. In the meanwhile seller was added pictures and explanation in his auctions.
Also, if You  check here on forum You will see that genuine adapter looks exactly like on his pictures.

http://www.ebay.com/itm/TL866CS-programmer-17-adapters-TL866-AVR-Bios-PLCC-MCU-Flash-EPROM-IC-Programmer-/191103978753?pt=LH_DefaultDomain_0&hash=item2c7eaf4d01

[Harald]

Hi. I'm quite new to all this stuff and I'd like to find out whether this TL866 might be the programmer that I need.
I have downloaded and installed MiniPro 5.80 last night, but I couldn't find every option available, so please help.

Is there a way to set up manually the device code for I2C devices? For example, the device code for 24c02 is 1010 and I suppose this code is automatically used when 24c02 is selected. I don't know the type of the devices that I'm trying to read from, so I can't select their type from the list, but their device code is 1110. Using a ByVac bv4221-v2, after the command "x", the device answered "ec" and I was able to read from it using the command "s-ed", as expected.

Since "ec" = 11101100 and "ed" = 11101101 , that means the control code for this unknown device is 1110 and the chip enable bits are 110. As far as I noticed, in some programming software there is an option to select the chip enable bits, but in some other software there is not such option. Apparently, the latter assume that for every device the chip enable bits are 000, which is obviously wrong.

As I said, I'm quite new to this field and if I got something wrong, please correct me. But at this moment, I'm under the impression that this is what I need, a programmer that will allow me to select the device code and the chip enable bits. Is TL866 such a programmer? Many thanks.

[Bimmeristi]

Hi. I'm quite new to all this stuff and I'd like to find out whether this TL866 might be the programmer that I need.
I have downloaded and installed MiniPro 5.80 last night, but I couldn't find every option available, so please help.

Sorry, but can't help more. If you use 5.80 version, its old. Please look here: http://autoelectric.cn/MiniPro/MinProUpdate.htm


Regards

[linux-works]

direct links seem to be:

 http://autoelectric.cn/MiniPro/minipro_setup.rar

and

 http://autoelectric.cn/MiniPro/MiniProHelp.rar

[Bimmeristi]

Who can help with this. I need to know can i use TL866A like this and what pins are where?

[jinzo]

That looks like a standard ICSP. Select ICSP in the software and click on the info button. And you'll see how to connect this up.

[Bimmeristi]

That looks like a standard ICSP. Select ICSP in the software and click on the info button. And you'll see how to connect this up.

I check this. Thanks!

[radioman]

Here in this post: https://www.eevblog.com/forum/blog/eevblog-411-minipro-tl866-universal-programmer-review/msg342728/#msg342728

[trisonic]

Here in this post: https://www.eevblog.com/forum/blog/eevblog-411-minipro-tl866-universal-programmer-review/msg342728/#msg342728

i think that we need a little wiki

[jinzo]

Here in this post: https://www.eevblog.com/forum/blog/eevblog-411-minipro-tl866-universal-programmer-review/msg342728/#msg342728

i think that we need a little wiki

Working on it, didn't have time (as I had some faculty stuff to do) to put any work into it, I have set up a mediawiki instance at http://minipro.txt.si though. There's basicly nothing in that wiki as of yet and I still have some work to wrap up before I'm going to have some more time to add content - but anyone is welcome to add/edit stuff to it. I'm also planing a minor "mirror" (of the official binaries, schematics, windows/linux builds of the various softwares for the TL866). Any feedback is welcome! Also if anyone is looking for any hosted services in relation to the TL866 (I don't know, project management ala gitlab, ....) I'd be happy to help!

[Sjaak]

It is a shame all the gore details are in the programmer and not into the PC side of things.

I would have guessed the programmer had some simple primitives like put Vpp on pin x, Vcc on pin y and GND on pin z. Should be relative simple to implement IMHO.

If there is a proper schematic I'm willing to help as I've some experience in PIC24F area (did a lot of programming on the BusPirate)

[radioman]

It is a shame all the gore details are in the programmer and not into the PC side of things.

Sorry but this is not entirely true.

I would have guessed the programmer had some simple primitives like put Vpp on pin x, Vcc on pin y and GND on pin z. Should be relative simple to implement IMHO.

You guessed well, the device has already implemented such programming primitives, they use these primitives for device self check and logic ic verify. The reason of why these primitives are not used in normal device programming is that it will be very slow to program a device in a such manner.
Remember that the PIC18F87J50 is a full speed (12Mbps) device and the transfer type is of type 'bulk';
this means that the bandwidth is not guaranteed and maximum packet size is 64 bytes.
Depending on the usb host and OS the minimum packet latency will be somewhere between 3 and 10ms. So even if the data length is 1 byte or 64 bytes the transfer time will be the same, but will be more efficient for large amount of data.
Let's say we want to program a device with 64K bytes in this manner, normally with the existing firmware primitives we can set all of those 40pins in one USB transfer and let's suppose that the USB latency is 5ms. Now with this setup we transfer one data byte in 5ms and one address increment command in another 5ms! the total amount of time will be ~10 minutes for a 64K device not counting the verify time. This is why the programming algorithms are implemented in firmware, because is more efficient to transfer large amounts of data over the usb and let the firmware to do the job much faster.

Actually the TL866 have only 39 control primitives and these primitives are grouped in categories like get device info, reset, start session, end session, erase chip, get chip Id, read data block, write data block and several pin and pin driver manipulation primitives.

If there is a proper schematic I'm willing to help as I've some experience in PIC24F area (did a lot of programming on the BusPirate)

Good to know, you are welcome, the schematic diagram is posted here in this thread.

[jinzo]

It is a shame all the gore details are in the programmer and not into the PC side of things.

I would have guessed the programmer had some simple primitives like put Vpp on pin x, Vcc on pin y and GND on pin z. Should be relative simple to implement IMHO.

If there is a proper schematic I'm willing to help as I've some experience in PIC24F area (did a lot of programming on the BusPirate)

I quickly copy pasted (and uploaded) some stuff (including the answer Radioman gave to you) to http://minipro.txt.si/index.php?title=Design (check the both PDFs for more in depth info). I know it's quick'n'dirty but at least it's a start.
I'll also add the two open source programs/projects there are mentioned in this topic (Radiomans TL866 Updater and the linux client).