$20 LCR ESR Transistor checker project

[rddube]

No, my display is working fine for everything on the transistor tester...only the function menu Frequency blanks after a second or 2 into the menu and then the tt is frozen...only way to get it back to work is to unplug battery.
When I unplug battery and start the tt, it works just fine. Can't get the function Frequency to work however.

As I wrote above, everything works normally.

The attached file contains the software that I tested:

Thank you Tom..I'll give it a try and let you know if all is fine.

Well Tom666 is my savior again! It works just fine with your version. I looked at my version which I compiled with a recent version of GCC as you recommended in one of your previous posts, used the makefile in the directory and I get a hex file which is a few bytes  less than you:

Your hex file: 81 222 bytes
My hex file :  81 210 bytes

Both eep files are 56 bytes. My version of avr-gcc is 4.8.1

So I wonder why I don't compile to the same file size as yours and why some functions (like frequency) don't work properly?

Many thanks again Mr. Tom!

[tom666]

... My version of avr-gcc is 4.8.1
So I wonder why I don't compile to the same file size as yours and why some functions (like frequency) don't work properly? ...

Try my updated WinAVR-20100110 - link expires after 48 hours.

[madires]

Both eep files are 56 bytes. My version of avr-gcc is 4.8.1

So I wonder why I don't compile to the same file size as yours and why some functions (like frequency) don't work properly?

The developers of the avr-gcc are improving the optimizations. Usually, a current version generates smaller code than an older version.

[tom666]

The problem is somewhere else, because my updated version of the WinAVR-20100110 is also used the AVR-GCC v4.8.1.

rddube has a probably a some bug in his version 4.8.1 and then the result of the compilation is a error in the final hex file (problem with the function of the frequency measurement).

[Scottjd]

Hi Scott,
I also have both Pis : model B and Pi2. They can write .hex files in Atmega, with or without bootloader. The 'gpio' programmer makes bit-banging on 4 serial lines, simply flashing an .hex file. You can afterwards use the bootloader with an ordinary serial interface, but with little or no interest as you're obliged to have the previous programmer to flash the bootloader the first time.
If the lock bits are set, only 'parallel' programmers can reset the device. In all other cases you can re-flash the fuses.
Out of factory the Atmega are configured with internal RC oscillator. You can then put the device on a breadboard without any crystal circuit. If you then configure the fuses to crystal oscillator, further programming will require the crystal on the breadboard (or on the target board if you're using ISP).
Denis

@Tom and @Denis

Guys,
      I was finally able to sit down today and set up my new Pi2, I also bought a "build you own" UNO kit that was clearance at the local electronics store for $3. I bought it because I thought it would be fun to solder together and also it didn't have a programming FTDI or any programming chip on it. So I thought it would be a good test platform to try using Pi AVRDude with.
All went well, I have not programmed anything yet, but I was able to read the AVR and current locks.
Next I want to breadboard it, then use the dev PCB I found and set it up so I can change chips from the 328/128 to AtTiny chips with a couple of changes to some jumpers and use a ZIF DIP socket to be a little easier. I wanted to thank you for your input and help.
Now I just need to figure out what commands to use to make a backup hex file of a chip, assuming it may need some lock bits changed first, then backed up.

Oh, and now I can pull my component tester 328 and plug it into this uno board and flash it with the v1.18.
My friend got his today also, it's a SMD 328P, but his also has a 10 pin program header on the board. His firmware won't even let him bring up a menu to see what version it's currently running. So I think I will update his also after I check pins 6 and the other for contrast to the display to make sure it won't short out. If it's wired we may cut the traces and then update the firmware, but I need to get a closer look at it first to be sure.

Thanks again for the help guys,
Scott

[Scottjd]

I also noticed that IDE on the Mac is using AVRDude in the background for the programming, so IDE is just a sketch editor, compiler and AVRDude does the flashing?

So what is the advantage (if any) of running the full raw AVRDude over using IDE besides being able to use some switches like -F for ignoring the signature of a chip? And even that could be fixed in the conf file.

Yep, avrdude is the common tool to program AVR's fuses, flash and EEPROM. It doesn't matter if you run it directly in a shell or via the IDE. I prefer a simple "make upload" to program flash and EEPROM , or "make fuses" to set the fuse bits. Someone else might prefer a fancy GUI. Another useful option for avrdude is "-B <bitclock>" in case you have to deal with a clock problem. I don't know if most IDEs support that option.

I usually prefer command line VS GUI. I find you can do more with command line. Both the UNO's I bought to play with. One is a R3 with a onboard programming chip, and one was a self build kit without a program chip that I figured would be a good test for AVRDude, and it was. But for some reason both of them look to have authentic mega328p chips, but I get a signature not match error if I try to update the bootloader with the IDE. Trying to dig around the MAC app to figure out were I could a the -F switch was painful. It's was much easier to just add it to the command line from the Pi and run again, and all works now.
Scott

[rddube]

... My version of avr-gcc is 4.8.1
So I wonder why I don't compile to the same file size as yours and why some functions (like frequency) don't work properly? ...

Try my updated WinAVR-20100110 - link expires after 48 hours.

Eureka Tom! I get exactly the same result as you, so it is probably something wrong with my version of WinAVR-20100110. My hex file is now 81 222 bytes, just like yours!

What is confusing, is that the already compiled version of the hex file in the directory mega328_t3_t4_St7564 (compiled by Karl Heinz I think?) for release 508 is 81 304 bytes ??

Looks now like there is a 510 revision out.....

Thank you again Tom!

[rddube]

Where can one find the changelog for the different revisions of version 1.12k (508, 509 and now 510) ?

Does anyone know?

Thank you.

[neslekkim]

Where can one find the changelog for the different revisions of version 1.12k (508, 509 and now 510) ?

Not sure of changelog, but if you know how subversion work, you'd know that the revisionnumber are an global number for the whole three, so if they, as in revision 509 only modifies documentation, you have an increase there, does not mean that there are code changes.

Here you see what have changed in the three for the varios commits:
https://www.mikrocontroller.net/svnbrowser/transistortester?view=revision&revision=508
https://www.mikrocontroller.net/svnbrowser/transistortester?view=revision&revision=509
https://www.mikrocontroller.net/svnbrowser/transistortester?view=revision&revision=510

In 510, there are some changes in config.c and lcd-routines.c (click the link "text-changed" to see what it is), and the rest is changes to documentation.

[tom666]

... What is confusing, is that the already compiled version of the hex file in the directory mega328_t3_t4_St7564 (compiled by Karl Heinz I think?) for release 508 is 81 304 bytes ?? ,,,

The difference in the size of the final hex file is due to the fact that Karl-Heinz compiles (he works under Linux) with the AVR-GCC 4.8.2.

Where can one find the changelog for the different revisions of version 1.12k (508, 509 and now 510) ? ...

As mentioned above, some of the current revisions involve changes in the documentation, or to add support for other types of LCD.

Log of /Doku/trunk
Log of /Software/trunk

[Trilitheum]

Hi, I recently purchased the newer DIY kit from Banggood:
http://www.banggood.com/DIY-M12864-Graphics-Version-Transistor-Tester-Kit-LCR-ESR-PWM-p-986954.html

Some of the screen characters are corrupt and I suspect the initial flash was done incorrectly, it does appear to measure accurately and the menus respond.
I have another mega328 on order in case the chip is damaged. I could go back to Banggood but it would be much faster to just re-flash the chip instead of waiting for them to send out a new one.

I know Tom666 posted that the layout is the same as the original and the official firmware can be used:

I found these boards on banggood and I'm thinking to buy one of these.
Which one should I prefer? 16x2 or 128x64 screen? Which one has the latest firmware and which one follows the original schematic with good quality components? Could I reflash the firmware by downloading the latest one from Karl-Heinz's repo?

The quality of the components is the same. In principle, no matter which device you buy, because the only difference is in the used type of LCD and control. Both devices are identical to the basic schematic diagram and can therefore use the official software from Mr. Karl-Heinz.

My questions is which branch directory is the correct build for this board and LCD? The main /mega328, /mega328 GM328?

Thanks!

[tom666]

Hi, I recently purchased the newer DIY kit from Banggood:
http://www.banggood.com/DIY-M12864-Graphics-Version-Transistor-Tester-Kit-LCR-ESR-PWM-p-986954.html
...
My questions is which branch directory is the correct build for this board and LCD? The main /mega328, /mega328 GM328?

Based on the available information, I recommend to try the directory "mega328_st7565".

[Trilitheum]

Thanks, will do.

[Trilitheum]

Hmm, didn't work the display is unreadable. Going to try some others.

mega328_wei_st7565/ Appears to display properly, but it's reporting the voltages wrong, looks like half.
Its data layout and font are much different than the original firmware, I am wondering if the creator wrote a custom firmware for these.

[firepower]

go through the make file, there are lots of setting to customise it, one option is to set divider for battery voltage, if thats what is incorrect.

[tom666]

Hmm, didn't work the display is unreadable. Going to try some others.

mega328_wei_st7565/ Appears to display properly, but it's reporting the voltages wrong, looks like half.
Its data layout and font are much different than the original firmware, I am wondering if the creator wrote a custom firmware for these.

@Trilitheum
Try this actual firmware (v1.12k revision 521) from the attached file (it also includes a modified Makefile).

[Trilitheum]

Thanks, will try it as soon as I get home.

I'm new to compiling, but I am going to try to get the make file to compile locally as well, figured it will be a good thing to know how to do.

[tom666]

Thanks, will try it as soon as I get home.

It's OK, what I here upload (mega328_st7565_kit_v1.12k_r521.zip)?

I'm new to compiling, but I am going to try to get the make file to compile locally as well, figured it will be a good thing to know how to do.

All necessary information you will find in the official manual contained in the SVN repository.

[Trilitheum]

Hi, yes that one is better. Thanks!
 
Just a quick question, how did you determine the correct Fuses?

[tom666]

I used the recommended values of the fuses by the author of the original software (Karl-Heinz Kübbeler) contained in the file "setup.mk".

[ulix]

Hi,
I finished my transistor tester. Sometimes when i test caps it shows me n-d-mos, between pin 1 and 2. Between 1 and 3 it's ok! Is this normal?

[madires]

Hi,
I finished my transistor tester. Sometimes when i test caps it shows me n-d-mos, between pin 1 and 2. Between 1 and 3 it's ok! Is this normal?

No, it shouldn't do that. What kind of caps triggers that issue?

[tom666]

Sometimes when i test caps it shows me n-d-mos, between pin 1 and 2. Between 1 and 3 it's ok! Is this normal?

Potential problems:
- faulty port of the MCU
- wiring error

What is the result of the selftest (T1 to T7 values)?

[ulix]

T1 Ref= 1067mV
RHf=872
T2 +RL- 12 13 23 1 1 -4
T3 +RH- 12 13 23 -12 -9 -1
T4 Isolate Probe -12 -9 -1
T5 RH- 0 0 0
T6 -6 -5 -5
T7 RH/RL -1 -1 -1
Ri_Hi=22.5Ohm
Ri_lo=19.7Ohm

The Values change a little, when performing more then once.

[tom666]

Hi,
I think the self test result is acceptable.
Try therefore to rewrite the firmware and fuses contained in the attached file.
If the issue will no resolved, I guess that is faulty the MCU.

Edit:
Capacitors should always be discharged before measuring!