$20 LCR ESR Transistor checker project

[indman]

These are my results for the tests T0-T7:

As I suspected, your hardware test results are bad. Look at my example of T1-T7 above and compare the numbers with yours.
You have problems with your hardware. Check the 6 measuring resistors and the +5V regulated voltage source.

[stj]

what part number is on the atmel?
does it end in  "PB" ?

[avr]

These are my results for the tests T0-T7:

As I suspected, your hardware test results are bad. Look at my example of T1-T7 above and compare the numbers with yours.
You have problems with your hardware. Check the 6 measuring resistors and the +5V regulated voltage source.

OK, I will do it in 2 or 3 days, when I have time to disassembly the  tester.

Thanks

what part number is on the atmel?
does it end in  "PB" ?

I cannot remember now, but I think it is a 328pb one.

[Yuriy_K]

I cannot remember now, but I think it is a 328pb one.

No, the parameters are close to mine, I have the end of PU

[Davo013]

Hey Bro!

Long time no speak hahaha
IK have a huge problem, I lost my data cable to burn my Atmel Chip for my ESRPRO002
I soldered a male 6 pin standard header, to connect a Female header 6pin to burn the Atmal straight on the device with AVR Dudes, or more likely with the Zadig driver haha
I have a USB A board with a 10pin output, with Pin 1 to 5, 1: VCC Probally 5V, Pin5: Ground, Pin6: MOSI, Pin7: No Contact, Pin8 RST, Pin9 SCK, Pin10 MISO

So how to wire the 6pin Female connector for the ESRPRO002?
I can post picz, but I Don't know hoe to do that over here   

[Davo013]

Hey Bro!

Long time no speak hahaha
IK have a huge problem, I lost my data cable to burn my Atmel Chip for my ESRPRO002
I soldered a male 6 pin standard header, to connect a Female header 6pin to burn the Atmal straight on the device with AVR Dudes, or more likely with the Zadig driver haha
I have a USB A board with a 10pin output, with Pin 1 to 5, 1: VCC Probally 5V, Pin5: Ground, Pin6: MOSI, Pin7: No Contact, Pin8 RST, Pin9 SCK, Pin10 MISO

So how to wire the 6pin Female connector for the ESRPRO002?
I can post picz, but I Don't know hoe to do that over here   

BTW I see a-lot of familiar names right here 
It looks like your still helping out the community! 
Much respect to you guys!
I Know 1 guy over here, he helped me big time over here, I can't remember his name...
It can be because he's Russion, dunno 4 sure...
You have Familiar names like:
Yuriy_K, Wait wait hold it.. I think it's Yuriy_K 

[stj]

here:

[Yuriy_K]

I think it's Yuriy_K

Add...

[Davo013]

Thnx!

[avr]

I cannot remember now, but I think it is a 328pb one.

I was wrong, it is a 328PU

[wifikebab]

Hey everyone,

I’m trying to source the PCB files for a Mega-4GSL transistor tester 2022 or 2023 build. Edit: I still need help if you're reading, when someone does help I will edit this comment to say someone helped.

I know the newer 2022/2023 revisions are around the Russian VRTP.ru threads, but their user registration is locked down for new accounts. Since I can't register, the forum completely hides all the file attachments from me when I browse as a guest and I can't use the search function.

Does anyone here happen to have the 2022 or 2023 .lay6 file or a pre-exported Gerber ZIP stashed that they could PM me? I just want to spin a standard 5-board run at JLCPCB to build one for myself and a buddy.

Appreciate any assistance you can offer!  I appreciate the work everyone has put into this over multiple forums and I'll keep it private if that's what the problem is. Still looking for the files.

Thanks for your time.

[madires]

Enjoy the new firmware version!

v1.57m:
- Added option to automatically enter the main menu after power-on (UI_MAINMENU_POWERON_DEFAULT, suggested by Bohu).
- Removed redundant statements in SymbolTest().
- Fixed broken OR condition for HW_KEYS in config_support.h (thanks to ThinkerSan).
- Fixed navigation help for 2-line displays in function MenuTool().
- Added support for 4x16 displays to HD44780 driver (thanks to Hennie Jalink).
- Updated JFET symbols in symbols_30x32_alt1_hf.h, symbols_30x32_alt2_hf.h, symbols_32x32_alt1_hf.h, symbols_32x32_alt2_hf.h and  symbols_32x39_hf.h (thanks to indman@EEVblog).
- Updated Romanian texts (thanks to Dumidan@EEVblog).
- Option to measure c_GS also for JFETs (SW_DEP_FET_CGS, suggested by indman@EEVblog and Yuriy_K@EEVblog).
- Alternative mode of third probe during measurement of small capacitances (HiZ instead of Gnd, SW_SMALLCAP_ALT).

Please download at:
- https://github.com/madires/Transistortester-Warehouse/tree/master/Firmware/m-firmware
- https://github.com/kubi48/TransistorTester-source/tree/master/Markus

PS: For Bohu's updated PDFs (Czech, English and German) please see https://github.com/madires/Transistortester-Warehouse/tree/master/Documentation.

[Yuriy_K]

A few years ago, I made a color version of the K-firmware for the ST 7735. If it's still relevant, here are the latest changes. But I don't have those testers, and the versions are untested...
If I don't need it, I'll delete it...

Sorry, replaced...

When I was making the BGR in 2021, the displays didn't work when I replaced the quartz crystal with a 16 MHz one. Perhaps the manufacturers have now replaced the display. Has anyone tried replacing the quartz crystal? So far, I've added an 8 MHz BGR.

[NikolaSoft]

в архиве ST7735_RGB_en16MHz.zip внутри файлы 2024 года

[madires]

In English: The ST7735_RGB_en16MHz.zip archive contains files from 2024.

[GraemeG]

I am a long time user of the TC1 tester and I have been lurking and reading this topic for a long time. The usual story, I killed 2 of them before I understood their limitations and have been happily using a third one for several years. All on the stock manufacturers firmware. I finally decided I want the real firmware and pulled out the 2 dead ones to see if they can be rebuilt.

One is the early version TC1 with a transformer (Unit 1) and the other has the FNIRSI-4A10 board (Unit 2) but luckily both have real ATmega324PA chips in TQFP-44 packages. So while I wait for the replacement/upgrade 644 chips and other improved components to arrive I have been removing the STC15L104W chips, added programming headers and have been compiling and loading a variety of firmware. This has been going well until I tried to switch to H/W SPI today.

I know the pin assignments on both of these are wrong for hardware SPI but I plan to rewire them and I can't even get it to compile without errors. It looks like Feliciano had this exact problem way back in February 2024:

A slightly smaller firmware size

I'm for it. So let's do the 1.51m exercise again (32980B vs X) and please help me troubleshoot my configuration. I enabled
SPI_HARDWARE both on config and config_644, and disabled SPI_BITBANG on the first. I thought that would be enough for the Make, but I get the following errors:

Code: [Select]

SPI.c: In function 'SPI_Clock':
SPI.c:388:10: error: 'SPCR' undeclared (first use in this function)
   Bits = SPCR;                            /* get control register */
          ^
SPI.c:388:10: note: each undeclared identifier is reported only once for each function it appears in
SPI.c:389:19: error: 'SPR1' undeclared (first use in this function)
   Bits &= ~((1 << SPR1) | (1 << SPR0));   /* clear clock rate bits */
                   ^
SPI.c:389:33: error: 'SPR0' undeclared (first use in this function)
   Bits &= ~((1 << SPR1) | (1 << SPR0));   /* clear clock rate bits */
                                 ^
SPI.c:406:18: error: 'SPI2X' undeclared (first use in this function)
     Bits = (1 << SPI2X);           /* set bit to double SPI speed */
                  ^
SPI.c:409:3: error: 'SPSR' undeclared (first use in this function)
   SPSR = Bits;                     /* update register */
   ^
SPI.c: In function 'SPI_Setup':
SPI.c:444:3: error: 'SPCR' undeclared (first use in this function)
   SPCR = (1 << SPE) | (1 << MSTR);
   ^
SPI.c:444:16: error: 'SPE' undeclared (first use in this function)
   SPCR = (1 << SPE) | (1 << MSTR);
                ^
SPI.c:444:29: error: 'MSTR' undeclared (first use in this function)
   SPCR = (1 << SPE) | (1 << MSTR);
                             ^
SPI.c:450:10: error: 'SPSR' undeclared (first use in this function)
   Bits = SPSR;           /* read flag */
          ^
SPI.c:451:10: error: 'SPDR' undeclared (first use in this function)
   Bits = SPDR;           /* clear flag by reading data */
          ^
SPI.c: In function 'SPI_Write_Byte':
SPI.c:469:3: error: 'SPDR' undeclared (first use in this function)
   SPDR = Byte;                     /* start transmission */
   ^
SPI.c:470:12: error: 'SPSR' undeclared (first use in this function)
   while (!(SPSR & (1 << SPIF)));   /* wait for flag */
            ^
SPI.c:470:25: error: 'SPIF' undeclared (first use in this function)
   while (!(SPSR & (1 << SPIF)));   /* wait for flag */
                         ^
make.exe: *** [SPI.o] Error 1

> Process Exit Code: 2


I'm a hardware hobbyist and have to struggle a bit when coding and compiling. But with some googling and a lot of trial and error I finally got it to compile. But I am sure my method is wrong and far from ideal!

I had to add the following to the beginning of the SPI.c file:

#include <avr/io.h>

/* local includes */
#include "config.h"           /* global configuration */

#ifndef SPCR
  #define SPCR  SPCR0
  #define SPSR  SPSR0
  #define SPDR  SPDR0
  #define SPE   SPE0
  #define MSTR  MSTR0
  #define SPR0  SPR00
  #define SPR1  SPR10
  #define SPIF  SPIF0
  #define SPI2X SPI2X0
#endif

#ifndef SPI_SS
  #define SPI_SS    PB4   /* Hardware Slave Select pin for ATmega324PA */
#endif
#ifndef SPI_MOSI
  #define SPI_MOSI  PB5   /* Hardware MOSI pin for ATmega324PA */
#endif
#ifndef SPI_SCK
  #define SPI_SCK   PB7   /* Hardware SCK pin for ATmega324PA */
#endif

I have been using WinAVR and thought I had upgraded gcc but have just realised I am using an old version:
C:\Electronics\Transistor tester\Software\No2_ComponentTester-1.57m>avr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.1_1752) 5.4.0

I could use some advice.

Are the compile errors due to the old gcc version?
Should I try to upgrade my WinAVR toolchain or is there another toolchain you recommend that will work with hardware SPI?

Many thanks to madires, indman, Yuriy_K and all the other who have contributed over the years to this excellent tool!

[indman]

This has been going well until I tried to switch to H/W SPI today.

For a display with a diagonal of 1.8-2 inches, you won't notice much of a difference in speed compared to software SPI. Therefore, I don't see much of a reason to use hardware SPI for this type of display. Hardware SPI significantly speeds up the update of information on larger displays with a diagonal of 2.8-4 inches or more. However, this is just my personal opinion.

[GraemeG]

Thanks indman, if I don't find a simple solution I will certainly go back to BITBANG SPI. It worked well and was not too slow. But for me this is still a learning exercise. I am comfortable with the hardware but my little coding experience is from years ago and mostly perl and shell scripting. I am trying to build my C skills a little, mostly so I am competent compiling and loading the result into the tester.

Troubleshooting the undeclared variables and realising I have not updated gcc as I had thought are exactly the things I want to understand. Hardware SPI is just the classroom exercise set to teach me 

[madires]

I had to add the following to the beginning of the SPI.c file:

#include <avr/io.h>

/* local includes */
#include "config.h"           /* global configuration */

Possibly some WinAVR path issue or setting. The intended way is: config.h includes common.h which includes avr/io.h.

[Feliciano]

GraemeG:
If you read some posts after the one you quoted, I reported that at the end of the day the compiler errors were related with an sub-optimal toolchain for WinAVR. In fact, choosing the proper one for your environment can help coping with the size limitations.

That is besides the other optimizations we can make in chossing one set of functions/methodologies over others on the configuration files.

[GraemeG]

madires and Feliciano, you have both pointed me in the right direction. I had read your later posts Feliciano but I had obviously messed up my updates to the compiler. To make sure I got it right I totally removed WinAVR and reinstalled from scratch. I think the first time I didn't copy the new avr-gcc correctly and that left the original 5.4.0 compiler in place.

My second attempt seems to have fixed my errors. Based on discussions of smallest compiled size I have only installed 8.3.0 so far:

Code: [Select]

C:\Electronics\Transistor tester\Software\No2_ComponentTester-1.57m>avr-gcc --version
avr-gcc (GCC) 8.3.0
By some miracle the TC1 with the FNIRSI 4A10 board has the correct pin mapping for hardware SPI! The older "transformer version" board pinout is wrong and I doubt I will bother changing it around. To get hardware SPI working on the 4A10 board I set up config_644.h with:

Code: [Select]

/* control and data lines */
#define LCD_PORT         PORTB          /* port data register */
#define LCD_DDR          DDRB           /* port data direction register */
#define LCD_RES          PB4            /* port pin used for /RESX (optional) */
// CS tied low in ST7735 display
//#define LCD_CS           PB4            /* port pin used for /CSX (optional) */
#define LCD_DC           PB3            /* port pin used for D/CX */
#define LCD_SCL          PB7            /* port pin used for SCL */
#define LCD_SDA          PB5            /* port pin used for SDA */

#define SPI_HARDWARE                    /* hardware SPI */
//#define SPI_BITBANG /* bit-bang SPI */

And also had to slow down the SPI clock in ST7735.c

Code: [Select]

//SPI.ClockRate = SPI_CLOCK_2X;    /* set clock rate flags */
  // Slow down the SPI clock. 20MHz crystal = 5MHz SPI
  // set clock rate flags - SPI2X = 0, SPR1 = 0, SPR0 = 0, SCK = fosc/4
  SPI.ClockRate = 0;    /* set clock rate flags */

For curiosity I videoed and timed bitbang and hardware SPI with everything else the same. I had it configured to immediately probe for components with CYCLE_DELAY 3000 and CYCLE_MAX 5. I let it run through all 5 cycles with no component found and timed until it turned off after the last probe.
Bitbang SPI = 46.3 seconds
Hardware SPI = 43.2 seconds

I then set #define UI_MAINMENU_POWERON_DEFAULT and timed from button press to the end of the main menu display.
Bitbang SPI = 5.5 seconds
Hardware SPI = 4.7 seconds

As indman pointed out, hardly worth the effort for these small displays.

These testers have a 3.3V regulator on the back of the ST7735 LCD board but there is no level shifter, the signals are simply fed to 10K resistors. If the clock is not slowed down in ST7735.c the screen doesn't initialise and just stays white. I don't know if adding a level shifter would allow for a faster SPI clock but it seems too much effort for little return.

A final question. Are people still using avr-gcc 8.3.0 or are later versions now preferred? Once I have the 644 chips the code size will be less important but I wonder if there is any advantage to chasing the latest compiler version?

[madires]

These testers have a 3.3V regulator on the back of the ST7735 LCD board but there is no level shifter, the signals are simply fed to 10K resistors. If the clock is not slowed down in ST7735.c the screen doesn't initialise and just stays white. I don't know if adding a level shifter would allow for a faster SPI clock but it seems too much effort for little return.

The 10 kOhms resistor is part of a RC filter (low-pass). As higher the resistor's value as lower the cutoff frequency. And the second point to consider is the max SPI clock of the LCD controller, i.e. if it's a genuine one or maybe something compatible with lower specs.

A final question. Are people still using avr-gcc 8.3.0 or are later versions now preferred? Once I have the 644 chips the code size will be less important but I wonder if there is any advantage to chasing the latest compiler version?

Using an older version which creates smaller firmwares is totally fine.

[Feliciano]

I was thinking the main purpose of those resistors was to protect the LCD controller, lowering the Voltage a little bit.

[madires]

The signal inputs of LCD controllers usually have two protection diodes. One to ground and the other to Vcc. The resistor in the signal line limits the current flowing from the 5V MCU output pin (high, 5V) via the 3.3V LCD controller input and its protection diode to Vcc (3.3V). The current needs to be low enough to not damage the protection diode (and the output stage of the MCU). Of course the current also causes a voltage drop across the resistor.

[GraemeG]

I hadn't thought of the resistors in that way but it makes perfect sense. Each input to the LCD controller will have some capacitance and the resistor will slow the charge rate of this capacitor = low pass filter.