$20 LCR ESR Transistor checker project

[madires]

Your tester looks like my JOYIT T7.
I have removed the Stc chip, and flashed m-firmware.
It is not working anymore, because the srv05 got damged, but i made some notes of the pinout.

LCD_RES          PB4           
LCD_DC           PB3
LCD_SCL          PB7
LCD_SDA          PB5

Have you configured bit-bang SPI or hardware SPI? With that pin assignment hardware SPI should be possible.

[Feliciano]

@madires: I don't know about the firmware binaries 2hry shared, but with 1.46m I enabled bitbang for the old TC1 (now I recall you said hardware SPI was not possible) and I did the same for the new one; and with 1.51m I got undefined function errors when trying to enable the default hardware SPI for the FNIRSI, so I choosed bitbang as well.
Sidenote: I'm using 1.46m now because the same set of features represent 99.7% usage on that, and 100.6% (32980B) on the other. I was planning to try intermediate versions, or perhaps you can suggest what to remove for this particular unit in order to save some Bytes.

@indman: the STC was connected to traditional PD1 and PD2. I attach the updated draft diagram for comparison.

Thank you both.

[indman]

Have you configured bit-bang SPI or hardware SPI? With that pin assignment hardware SPI should be possible.

On such a small display 1.8 we should not notice any difference in speed, or are there any other important factors that indicate the usefulness of hardware SPI?

[Feliciano]

If code-wise hardware SPI would save some Bytes (vs software SPI), that alone would it be useful/worthy.

[rddube]

Programmed my TT with version 1.51m and when I try to put it into L Monitor (inductance) it just stands on the screen in the photo and won't read anything and won't respond to the button press either.

Enable the RLC Monitor mode in the firmware. Will the tester in this mode react to the connection of resistance, capacitance, inductance?

Feliciano, To which ports of the ATmega324 were pins 7 and 8 of the STC connected? I've almost updated the circuit diagram for FNIRSI's LCR-TC1.

Hello Indman, when I enable RLC Monitor, tester reacts to resistance, capacitance perfectly, when I try to test an inductor, it gives me a resistance reading... Thank you for your help!

[indman]

when I try to test an inductor, it gives me a resistance reading...

This means that the tester cannot determine the inductance because it is too small or its resistance is greater than 2 kOhm.

[madires]

Sidenote: I'm using 1.46m now because the same set of features represent 99.7% usage on that, and 100.6% (32980B) on the other. I was planning to try intermediate versions, or perhaps you can suggest what to remove for this particular unit in order to save some Bytes.

You could disable checks for rare components (SW_UJT, SW_SCHOTTKY_BJT).

[madires]

On such a small display 1.8 we should not notice any difference in speed, or are there any other important factors that indicate the usefulness of hardware SPI?

A slightly smaller firmware size, as Feliciano already pointed out. And the most visible impact would be a faster screen clearing.

[rddube]

when I try to test an inductor, it gives me a resistance reading...

This means that the tester cannot determine the inductance because it is too small or its resistance is greater than 2 kOhm.

But whatever size I put it always gives me a resistance reading. Can it not read a 1uh 1R0 inductor ? These are inductors around a CPU on a motherboard. What is the range that it can read? Many thanks.

[indman]

rddube,The lower range of inductance measurements on m-firmware starts at about 10 microHenry. If you want to measure inductance values ​​lower than 10 microHenry, you can build an additional LC meter attachment or use the resonant method in k-firmware.

[Feliciano]

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


[madires]

If you enable SPI_HARDWARE in config_644.h you don't need to do that also in config.h (it will trigger a compiler warning). The error messages about undeclared register names could be caused by a missing header file. That should be avr/io.h (#include <avr/io.h> which is included in common.h). Try an additional #include <avr/io.h> in SPI.c.

[Feliciano]

No joy with the suggested modifications. I post here the relevant sections:

Code: [Select]

*
 *  SPI bus
 *  - might be required by some hardware
 *  - could be enabled already in display section (config_<MCU>.h)
 *  - for bit-bang SPI port and pins see SPI_PORT (config_<MCU>.h)
 *  - hardware SPI uses automatically the proper MCU pins
 *  - uncomment either SPI_BITBANG or SPI_HARDWARE to enable
 */

//#define SPI_BITBANG                /* bit-bang SPI */
//#define SPI_HARDWARE               /* hardware SPI */
//#define SPI_RW                     /* enable SPI read support */
//#define SPI_SLOWDOWN               /* slow down bit-bang SPI */


Code: [Select]

/*
 *  ST7735
 *  - 4 wire SPI interface using hardware SPI
 */

//#if 0
#define LCD_ST7735                      /* display controller ST7735 */
#define LCD_GRAPHIC                     /* graphic display */
#define LCD_COLOR                       /* color display */
#define LCD_SPI                         /* SPI interface */
/* 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) */
//#define LCD_CS           PB?            /* 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 */
/* display settings */
#define LCD_DOTS_X       128            /* number of horizontal dots */
#define LCD_DOTS_Y       160            /* number of vertical dots */
#define LCD_OFFSET_X     2               /* enable x offset of 2 or 4 dots */
#define LCD_OFFSET_Y     1               /* enable y offset of 1 or 2 dots */
#define LCD_FLIP_X                      /* enable horizontal flip */
//#define LCD_FLIP_Y                      /* enable vertical flip */
#define LCD_ROTATE                      /* switch X and Y (rotate by 90°) */
//#define LCD_BGR                         /* reverse red and blue color channels */
#define LCD_LATE_ON                     /* turn on LCD after clearing it */
/* font and symbols: horizontally aligned & flipped */
#define FONT_10X16_HF                   /* 10x16 font */
//#define FONT_6X8_ISO8859_2_HF           /* 6x8 Central European font */
//#define FONT_8X8_ISO8859_2_HF           /* 8x8 Central European font */
//#define FONT_8X12T_ISO8859_2_HF         /* thin 8x12 Central European font */
//#define FONT_8X16_ISO8859_2_HF          /* 8x16 Central European font */
//#define FONT_10X16_ISO8859_2_HF         /* 10x16 Central European font */
//#define FONT_8X16_WIN1251_HF            /* 8x16 cyrillic font */
//#define FONT_8X16ALT_WIN1251_HF         /* 8x16 alternative cyrillic font */
#define SYMBOLS_30X32_HF                /* 30x32 symbols */
//#define SYMBOLS_30X32_ALT1_HF           /* 30x32 alternative symbols #1 */
//#define SYMBOLS_30X32_ALT2_HF           /* 30x32 alternative symbols #2 */
//#define SYMBOLS_32X32_HF                /* 32x32 symbols */
//#define SYMBOLS_32X32_ALT1_HF           /* 32x32 alternative symbols #1 */
//#define SYMBOLS_32X32_ALT2_HF           /* 32x32 alternative symbols #2 */
/* SPI bus */
#define SPI_HARDWARE                    /* hardware SPI */
//#endif
And as I said, it makes no difference to me to include or not the

Code: [Select]

#include <avr/io.h>
on SPI.c

I'm using WinAVR2010 with the replaced dll and toolchain over W10.

[indman]

On such a small display 1.8 we should not notice any difference in speed, or are there any other important factors that indicate the usefulness of hardware SPI?

A slightly smaller firmware size, as Feliciano already pointed out. And the most visible impact would be a faster screen clearing.

To my surprise, the size of the test firmware with SPI BitBung turned out to be smaller than SPI Hardware?!!! 
Feliciano, check both test firmware on your clone and compare their behavior. Unless, of course, I made a mistake somewhere with the settings?

[Feliciano]

indman, are you messing with me? 

• The bitbang_SPI version boots, in continous mode, in Russian, rotated (from top to bottom), and flipped horizontally
• The hardware_SPI version gives me a white screen. Regardless, did you modify something else compared to the configurations I shared earlier?
• It also amazes me that the hardware subroutine takes more memory than the software subrutine. I'll try to confirm/deny if I find how to fix the compiler error

[EDIT] I found the error, it was the toolchain of my WinAVR. I can confirm that hardware SPI should be faster, but takes a little more memory on the m-firmware (33358B vs 33396B in my case). (Interesting, I got less memory usage with the other toolchain, but errors when trying to enable hardware SPI).

[indman]

indman, are you messing with me? 

No, I didn’t even think about it! I have my own method for setting up configuration files, sorry.
I don’t like the 10x16 font at all, it looks awkward and it significantly increases the size of the firmware.
For ATMega328 and ATMega324 this is critical, so for clones with these controllers I only use the 8x16 font.
It’s strange that your firmware launched in Russian, because I chose English in the settings, this font supports the Latin alphabet.
Try 1 more firmware option from bitbung. Now I applied a 10x16 font and rotated the display orientation.

[Feliciano]

(I know you weren't messing with me, that was the wink for).
The new binaries work: correct orientation, and in continous mode. A callibration was needed out of the box, though. After that, it shows a 23V zener, because this unit only generates that much voltage. With DUT in place, it seems to work fine.

And about the bitmaps, we know bigger fonts means more memory, but for older eyes like mines is a trade-off. I haven't rendered the 8x16. By any chance do you have a side by side comparison against the 10x16 (small screen)? Is the 10x16 still the one I graphed on the attached?

I also noticed that more symbols were added to the bitmaps on recent versions of m-firmware, like battery icon, onewire, and maybe other stuff. I wonder whether those symbols are loaded into memory regardless whether we choose to display it or not? (I mean, whether the whole bitmap is loaded, or just the part of it we're declaring it's going to be used).

[indman]

Feliciano, this was a test firmware, the rest of the nuances and fine settings must be chosen by the user himself. This doesn’t interest me much anymore, since I don’t have such a clone and I hope there won’t be one. The main thing is that we managed to adapt m-firmware in a relatively simple way. Say a big thank you again to madires, who provided very flexible port settings in the configuration files.

[madires]

To my surprise, the size of the test firmware with SPI BitBung turned out to be smaller than SPI Hardware?!!! 

That's intriguing!

[Feliciano]

Indeed.

I publically express my gratitude again to madires, for keeping this project going for so long, and keeping improving it on his free time, and to the other people here that help, like indman of course, and others (like 2hry in this case). And because I appreciate that, I also try to collaborate a little bit every now and then.

There are some question marks remaining for this other variant, like the probable hardware SPI support on such, but that's not a priority, I will give it another try at another moment.

[madires]

I also noticed that more symbols were added to the bitmaps on recent versions of m-firmware, like battery icon, onewire, and maybe other stuff. I wonder whether those symbols are loaded into memory regardless whether we choose to display it or not? (I mean, whether the whole bitmap is loaded, or just the part of it we're declaring it's going to be used).

If none of the display features requiring additional characters/symbols are enabled the additional characters/symbols aren't included in the firmware. The additional characters in the font bitmaps are the probe numbers with reversed colors and the battery icons. Addtional symbols are question mark, Zener diode, quartz crystal and one-wire.

[carl1961]

New GM328A  running 1.51m   I had to use Semi-ST7735, took me a great while to figure how, I came across a post searching here.

#if 1
//#define LCD_ST7735                      /* display controller ST7735 */
#define LCD_SEMI_ST7735                /* display controller SEMI ST7735 */

Attached is files changed

I could no get 16 Hz crystal working on this board, it messes with the display driver.

[YouCanDoIt]

Sorry guys for disturbing the discussion, but I need your help to build a Mega 4gsl.
I found these two versions of the pcb (2022, 2019):


I only saw version 2015 developed from Nick Lanchak, the original author. Did he also released the above two versions?
I would like to use a color LCD, but the seller said that he only partially succeded. The output shows up, but very slowly (he said it is due to too high resolution). Plus there was a problem with the encoder, most likely the encoder needs to be transferred to other ports.
Someone can recommend a compatibile color LCD without such problems?

UPDATE
The tested screens with the above problems are ST7789v and ILI9341 on 1.48m. The board used is rev2023:

Works fine with with LG12864E:



I am wondering if the board revision plays a role.

[rddube]

rddube,The lower range of inductance measurements on m-firmware starts at about 10 microHenry. If you want to measure inductance values ​​lower than 10 microHenry, you can build an additional LC meter attachment or use the resonant method in k-firmware.

Thank you Indman for your reply and patience. I am relatively new at this and didn't know that the K firmware could support lower values of inductance. I have a TT with version 1.12K, is that good enough or is there a newer version and if so, where can i find it? I'd also like to read about the resonant method if you point me in the right direction. And again, thanks!

[Feliciano]

The last k-firmware version at the moment is 1.13k. You can find it, as well as the extense documentation (including measuring methods) at madires' github.