$20 LCR ESR Transistor checker project

[prashk20]

Any ideas?

Hello!

  For your circuit to work correctly, you need to modify ARDUINO_UNO. Replace the 1000 pF capacitor and cut the trace to input 5 of the op amp, marked with an X.

Hello Yuri,
I didn't think mods would be needed for Uno. I first implemented the k firmware for Arduino Uno shield using the posted hex files and that seemed to work fine, so I thought it should work here as well. For my finished tester, I will use an Atmega1084 chip or a Teensy 4.0 microcontroller (if permissible). The Atmega chip pcb should not run into this issue. I'll next prototype the tester with Atmega1084 chip on a breadboard and see the output. Thank you for the solution!
Regards

[Maniaxx]

The values are:
Ri- 20.0Ohm
Ri+ 22.0Ohm
C0 43pF
R0 0.20Ohm
Vref 1008mV
Vcc 5001mV
AComp -45mV

Next page on click is Error.

That's only the summary. The test results beforehand are needed. Or check the 'README' yourself for valid ranges. See this and following post.

[prashk20]

The values are:
Ri- 20.0Ohm
Ri+ 22.0Ohm
C0 43pF
R0 0.20Ohm
Vref 1008mV
Vcc 5001mV
AComp -45mV

Next page on click is Error.

That's only the summary. The test results beforehand are needed. Or check the 'README' yourself for valid ranges. See this and following post.

Hello Maniaxx, thank you for the info! It helped!
I found the problem (an embarrassing one), I was not shorting the pins correctly, used disconnected male headers thinking I am shorting the circuit 

On actually shorting the circuits, it all works well. Thank you! 
Video: https://drive.google.com/file/d/1Lh0MI19b0TE3IFjUfQ6MI-D5P-kdI-x4/view?usp=sharing

[madires]

That list is the currently used adjustment profile. When the self-adjustment succeeds the profile will be updated. On error it won't change. In this case the first four values are the default values. Vref and AComp are already updated by measuring a film cap three times. Vcc is also the default value (no external reference available). It's a bit confusing, it's simply the same function as called by the 'show values' menu item to keep the firmware size small. Maybe it would be better to show the list only on success.

[prashk20]

Any ideas?

Hello!

  For your circuit to work correctly, you need to modify ARDUINO_UNO. Replace the 1000 pF capacitor and cut the trace to input 5 of the op amp, marked with an X.

Hello Yuri,
Thank you for the info. Using this I actually found the difference on Uno (100nF) vs Component Tester (1nF) circuit. I also found Madires has clearly given instructions for Uno, which I somehow overlooked. I now enabled ADC_LARGE_BUFFER_CAP in config and that makes it all work. Now 10Ohm, 100, 10k, 22k, etc are all read correctly!
Thank you! 

[prashk20]

That list is the currently used adjustment profile. When the self-adjustment succeeds the profile will be updated. On error it won't change. In this case the first four values are the default values. Vref and AComp are already updated by measuring a film cap three times. Vcc is also the default value (no external reference available). It's a bit confusing, it's simply the same function as called by the 'show values' menu item to keep the firmware size small. Maybe it would be better to show the list only on success.

Thank you for the explanation Madires. I earlier didn't really connect that measuring a film cap three times before was doing something. I'm new to this project, so some of the info on Readme and the manual, I miss even after reading it. It's a superb project, I'm super impressed!

I bumped onto this project while looking for better implementations of resistor measurement using potential divider. I got tired of using the Multimeter for every measurement. I made one basic resistor measurement program on Uno but that doesn't work well for small resistors or big ones. Maybe because I didn't use port and pin controls but I'll look into that sometime. Right now this is like amazing! And thank you for maintaining a superb documentation on this project!

[Maniaxx]

This linker option gives even more space

Nice, indeed. My config on avr-gcc 8.5.0:

32600 bytes (99.5% Full)
32062 bytes (97.8% Full) #CFLAGS += -flto
31522 bytes (96.2% Full) #CFLAGS += -flto / LDFLAGS += -Wl,--relax

I'm wondering though why 'lto' is present but commented out in MAKEFILE. Maybe it doesn't work on Windows compiler?

[moimem]

This linker option gives even more space

Nice, indeed. My config on avr-gcc 8.5.0:

32600 bytes (99.5% Full)
32062 bytes (97.8% Full) #CFLAGS += -flto
31522 bytes (96.2% Full) #CFLAGS += -flto / LDFLAGS += -Wl,--relax

I'm wondering though why 'lto' is present but commented out in MAKEFILE. Maybe it doesn't work on Windows compiler?

(#CFLAGS += -flto) is working for me in windows 11 x64 and reduce the 1.50m firmware size
I have tried some versions of avr-gcc from version  4.3.3 (included with the last winavr of 2010)  to  version 12.1.0 and i had the best results with version 7.3.0 and binutils: 2.26.20160125, newer versions seems to drop some optimizations but its in my todo list to try every gcc version. With the m_firmware evolving, for the atmega328 with only 32kb we need to find the best compiler version and options to fit as many features as possible.
with the same code i get

Code: [Select]

avr-gcc 7.3.0
Program:   32652 bytes (99.6% Full)
(.text + .data + .bootloader)

avr-gcc 12.1.0  (110.5% Full)

[indman]

Maniaxx,moimem and everyone, without attaching the config_h and config_328.h settings files to your messages about compilation with different avr-gcc, the information is of little use, since there is no way for other people to compare results on their computers. majortom did the right thing in his message above and attached these files.
AVR-GCC 13.2 showed surprisingly good compilation results but i can't test it on my Windows machine yet. With avr-gcc 8.3.0(flto enabled) and majortom configuration files I get a firmware size of 31740 bytes (96.9%).

[moimem]

Maniaxx,moimem and everyone, without attaching the config_h and config_328.h settings files to your messages about compilation with different avr-gcc, the information is of little use, since there is no way for other people to compare results on their computers. majortom did the right thing in his message above and attached these files.
AVR-GCC 13.2 showed surprisingly good compilation results but i can't test it on my Windows machine yet. With avr-gcc 8.3.0(flto enabled) and majortom configuration files I get a firmware size of 31740 bytes (96.9%).

avr-gcc 7.3.0 windows11_x64

Code: [Select]

AVR Memory Usage
----------------
Device: atmega328

Program:   32652 bytes (99.6% Full)
(.text + .data + .bootloader)

Data:        260 bytes (12.7% Full)
(.data + .bss + .noinit)

EEPROM:      903 bytes (88.2% Full)
(.eeprom)

avr-gcc 8.3.0

Code: [Select]

AVR Memory Usage
----------------
Device: atmega328

Program:   32662 bytes (99.7% Full)
(.text + .data + .bootloader)

Data:        260 bytes (12.7% Full)
(.data + .bss + .noinit)

EEPROM:      903 bytes (88.2% Full)
(.eeprom)


[indman]

moimem, with your configuration files i get slightly different results on Windows 10x64.
A more compact size is obtained with avr-gcc 8.3.0.

[madires]

32600 bytes (99.5% Full)
32062 bytes (97.8% Full) #CFLAGS += -flto
31522 bytes (96.2% Full) #CFLAGS += -flto / LDFLAGS += -Wl,--relax

I'm wondering though why 'lto' is present but commented out in MAKEFILE. Maybe it doesn't work on Windows compiler?

Because that option isn't supported by all compilers. IIRC, very old avr-gcc versions don't. I'll add a hint about compiler/linker optimizations to the README textfile.

Addendum:
When experimenting with other optimization options not already in the CFLAGS be careful with time critical functions/measurements. We have seen some options screwing up delay loops. A few years back I had to change a few inline asm delays for that reason.

[moimem]

moimem, with your configuration files i get slightly different results on Windows 10x64.
A more compact size is obtained with avr-gcc 8.3.0.

interestingly we obtain the exact file size with avr-gcc 8.3.0 (32662 bytes) so its not related to windows version but i have better results with avr-gcc-7.3.0
i have mixed a lot of versions of gcc and binutils and cant tell wich file is responsible of this defference in results, its either we have different gcc7.3.0 files or its related to an other bin called during compilation.
can you try my attached avr-gcc-7.3.0.exe file, and just drop it in place of the 8.3.0 with all other files from gcc 8.3.0 and check the results

[moimem]

moimem,404 - Attachment Not Found

reattached here

[indman]

moimem,I tried to compile with your file, but the size of the firmware did not change at all - 99.8%.

[horo]

These are the results for my AY-AT setup with different options, available at GitHub:
https://github.com/Ho-Ro/ComponentTester/tree/77066735c597e81ee78742bb1c902b6356520e12

Interesting that version 13 is back on small size, almost similar to version 8.

Code: [Select]

avr-gcc v. 13.2.0
Program:   33246 bytes (101.5% Full)
Program:   32524 bytes (99.3% Full) -flto
Program:   32090 bytes (97.9% Full) -flto; -Wl,--relax

avr-gcc v. 12.1.0
Program:   36834 bytes (112.4% Full)
Program:   35592 bytes (108.6% Full) -flto
Program:   35162 bytes (107.3% Full) -flto; -Wl,--relax

avr-gcc v. 8.3.0
Program:   33262 bytes (101.5% Full)
Program:   32562 bytes (99.4% Full) -flto
Program:   32044 bytes (97.8% Full) -flto; -Wl,--relax

avr-gcc v. 7.3.0
Program:   33332 bytes (101.7% Full)
Program:   32588 bytes (99.5% Full) -flto
Program:   32094 bytes (97.9% Full) -flto; -Wl,--relax

avr-gcc v. 5.4.0
Program:   (> 100% Full)
Program:   (> 100% Full) -flto
Program:   32034 bytes (97.8% Full) -flto; -Wl,--relax


[indman]

Thanks horo!
With your archive, I got a compilation with the same firmware size as yours on avr-gcc 8.3.0.
Perhaps I'll stop at this point with experiments.

[moimem]

These are the results for my AY-AT setup with different options, available at GitHub:
https://github.com/Ho-Ro/ComponentTester/tree/77066735c597e81ee78742bb1c902b6356520e12

Interesting that version 13 is back on small size, almost similar to version 8.

Code: [Select]

avr-gcc v. 13.2.0
Program:   33246 bytes (101.5% Full)
Program:   32524 bytes (99.3% Full) -flto
Program:   32090 bytes (97.9% Full) -flto; -Wl,--relax

avr-gcc v. 12.1.0
Program:   36834 bytes (112.4% Full)
Program:   35592 bytes (108.6% Full) -flto
Program:   35162 bytes (107.3% Full) -flto; -Wl,--relax

avr-gcc v. 8.3.0
Program:   33262 bytes (101.5% Full)
Program:   32562 bytes (99.4% Full) -flto
Program:   32044 bytes (97.8% Full) -flto; -Wl,--relax

avr-gcc v. 7.3.0
Program:   33332 bytes (101.7% Full)
Program:   32588 bytes (99.5% Full) -flto
Program:   32094 bytes (97.9% Full) -flto; -Wl,--relax

avr-gcc v. 5.4.0
Program:   (> 100% Full)
Program:   (> 100% Full) -flto
Program:   32034 bytes (97.8% Full) -flto; -Wl,--relax


most intersting fact in my opnion is that the best result so far is obtained with avr-gcc-5.4.0 and -flto -wl, --relax flags
confirmed after testing your code in windows and linux

Code: [Select]

Program:   32034 bytes (97.8% Full)
(.text + .data + .bootloader)

Data:        260 bytes (12.7% Full)
(.data + .bss + .noinit)

EEPROM:       22 bytes (2.1% Full)
(.eeprom)

[hapless]

But the question is, does this happen because something important is optimized out and newer versions are smart enough to keep it?

[indman]

most intersting fact in my opnion is that the best result so far is obtained with avr-gcc-5.4.0 and -flto -wl, --relax flags

Code: [Select]

Program:   32034 bytes (97.8% Full)
(.text + .data + .bootloader)

Data:        260 bytes (12.7% Full)
(.data + .bss + .noinit)

EEPROM:       22 bytes (2.1% Full)
(.eeprom)

The funny thing is that when I returned to my old version of the compiler based on avr-gcc 6.3.1, the code turned out to be the most compact. I just added the -wl, --relax flag to -flto on the advice of horo 

[Maniaxx]

The 13.2.0 even outperforms the 8.5.0 now so i will go for that. I'd always prefer newer compilers over older ones if near on-par in size.

Code: [Select]

Custom config (--relax, -flto, avr-gcc 13.2.0):
AVR Memory Usage
----------------
Device: atmega328

Program:   31448 bytes (96.0% Full)
(.text + .data + .bootloader)

Data:        270 bytes (13.2% Full)
(.data + .bss + .noinit)

EEPROM:       22 bytes (2.1% Full)
(.eeprom)

Code: [Select]

Custom config (--relax, -flto, avr-gcc 8.5.0):
AVR Memory Usage
----------------
Device: atmega328

Program:   31522 bytes (96.2% Full)
(.text + .data + .bootloader)

Data:        252 bytes (12.3% Full)
(.data + .bss + .noinit)

EEPROM:       22 bytes (2.1% Full)
(.eeprom)

[moimem]

The 13.2.0 even outperforms the 8.5.0 now so i will go for that. I'd always prefer newer compilers over older ones if near on-par in size.

I installed the 13.2.0 (had to build an archlinux VM) and tried some experiments and its getting a little bit more complicated since its not always a matter of compiler version but it  also depends of the code itself; adding or removing some features of the firmware make mixed final results, but with few bytes difference i prefere the 13.2 too.

Code: [Select]

config-maniaxx (--relax, -flto) avr-gcc 6.3.1
Program:   31526 bytes (96.2% Full)

config-maniaxx (--relax, -flto) avr-gcc 13.2.0
rogram:   31448 bytes (96.0% Full)

config-horo (--relax, -flto) avr-gcc 6.3.1
Program:   31998 bytes (97.7% Full)

config-horo (--relax, -flto) avr-gcc 13.2.0
Program:   32090 bytes (97.9% Full)

[JohnC]

Help please to fix my old FISH8840 

Hi everyone, and thanks very much for all your work on these clone testers!

I would like to repair my original FISH8840 "Big Screen", to repay it for many years of faithful service. It's had the "power fix", upgraded LDO, matched resistors, etc but now the screen is stuffed.

It's been in storage for years, however I think that the front polarizer peeled off - anyway, now it has a very strange circular distortion (see attached pics). I tried overlaying a few polarizing sheets but they didn't improve it, so I thought maybe it used a circular polarizer or something?

The screen is 63 x 51mm, with an 18-conductor ribbon. I've attached a photo of the rear of the PCB, and you can see the 6 pin header going down to the main PCB. The SID, SCLK, RS and REST pins go to the LCD, the VCC goes through an LDO, and there's a heap of bypass caps on the other ribbon connections.

I read that it used a ST7565 controller (??), however I have not un-glued the panel to check and there is no markings on the ribbon cable. I tried searching but can't seem to find a matching replacement, nor even a screen with similar ribbon connection.

Do you have any idea what might be wrong with it, and is it repairable? If not, how could I find a replacement screen, even it it's a smaller footprint?

Obviously it'd be easier just to replace the whole gadget, but I thought I'd give you guys a shout out before I retired it permanently. Do you have any ideas or assistance for me?

Cheers, John 

[madires]

Most likely fubar. You could search AliExpress for ST7565 and look for one with a matching flat-flex. Another way is to get an ST7565 display meant for Arduino (5V) and wire it up. Or go for the OSHW firmwares (k or m) and use any supported display.

[hapless]

Looks like it may be fixable with what this guy is doing:



After that, you just replace the polarizer with a good one and you should be good to go.

However, doing all that, even if you have the patience, can result in a shattered display and personal injury, so I can't really recommend the procedure. It would be best to just replace it like madires said.