$20 LCR ESR Transistor checker project

[flywheelz]

*Collection of Helpful information *
Firmware Building environment for Windows

• Download and Install WinAVR > Link
• Download Toolchain > Link
• Extract Toolchain using Winrar or 7-zip into the C:\WinAVR-20100110 folder overwrite everything, avr, bin, doc...
• credit: tom

Compiling the Firmware

• Download GNU tarball > Link
• Extract GNU tarball using Winrar or 7-zip somewhere
• Launch Programmers Notepad installed by WinAVR
• Open desired Makefile in the device specific folder from extracted tarball
• Click Tools menu > [WinAVR] Make All
• In the folder of Makefile you will find the flash .hex and eeprom .eep files

Writing Firmware

• Simple Atmega Programmer Serial Com1, credit: maxcombor
  
• ArduinoUNO as ISP programmer Com3
  

Hardware

• T3/T4 mod for svn661+

[flywheelz]

Original firmware had 1mhz, 2mhz, and others...

if that's true then the original firmware must be seriously ancient.

On start up it showed 1.12k

I think the list was 10Hz, 50Hz, 100Hz, 250Hz, 439.9956Hz, 441.9890Hz, 443.0170Hz, 1kHz, 2.5kHz, 5kHz, 10kHz, 25kHz, 50kHz, 100kHz, 153.8462kHz, 250kHz, 500kHz, 1mHz, 2mHz, 1000mHz

[stj]

On start up it showed 1.12k

that does not mean anything, they have been labelled 1.12k for over a year.
that's why i use the SVN number.

[stj]

Hi, I am also trying to build myself.  I can't figure out what gcc related files I need grab from arduino zip and where to put them in Winavr folder to get it to work

I copied avr-gcc.exe, cc1.exe, device-specs folder, some dll... now its giving , make.exe: *** [lcd-routines.o] Error 1, 

@stj, could you be more specific.

no i cant, but your not copying enough.
pm me your email - i'll archive my folder

[hapless]

[...] 1mHz, 2mHz, 1000mHz

I think that's 1MHz, 2MHz, but 1000mHz. Mega vs milli.

[flywheelz]

Hi, I am also trying to build myself.  I can't figure out what gcc related files I need grab from arduino zip and where to put them in Winavr folder to get it to work

I copied avr-gcc.exe, cc1.exe, device-specs folder, some dll... now its giving , make.exe: *** [lcd-routines.o] Error 1, 

@stj, could you be more specific.

no i cant, but your not copying enough.
pm me your email - i'll archive my folder

PM sent. But I think it might be working now...It compiles not exact file size as yours  but atleast it should fit... not sure about the dwarf errors.

Code: [Select]

BFD: Dwarf Error: mangled line number section.
BFD: Dwarf Error: mangled line number section.
BFD: Dwarf Error: mangled line number section.

8 MHz operation configured.
AVR Memory Usage
----------------
Device: atmega328p

Program:   31772 bytes (97.0% Full)
(.text + .data + .bootloader)

Data:        202 bytes (9.9% Full)
(.data + .bss + .noinit)

EEPROM:      888 bytes (86.7% Full)
(.eeprom)



> Process Exit Code: 0
> Time Taken: 00:58


[stj]

my winavr is 20100110
i cant remember the arduino version.

[flywheelz]

my winavr is 20100110
i cant remember the arduino version.

I just compiler and flashed  svn690 with included Makefile in ../trunk/mega328_color_kit/    It boots up!  The f-Gen lets you select custom frequencies, wow 

[flywheelz]

@madires,

I have mega328_color_kit "AY-AT" with LCD 7735.  Took trendy 1.24m for a drive.

To get LCD to work I had to change lines below.  One weird thing I see is on Start the LCD refreshes with multi color dots/sand.

In config_328.h:
1. From

Code: [Select]

#define LCD_ST7735_SPI
...
#define LCD_DC           PD3            /* port pin used for D/CX */
#define LCD_SCL          PD2            /* port pin used for SCL */
#define LCD_SDA          PD1            /* port pin used for SDA */
...
To

Code: [Select]

#define LCD_DC           PD1            /* port pin used for D/CX */
#define LCD_SCL          PD2            /* port pin used for SCL */
#define LCD_SDA          PD3            /* port pin used for SDA */
2. From

Code: [Select]

//#define LCD_FLIP_X                      /* enable horizontal flip */
#define LCD_FLIP_Y                      /* enable vertical flip */To

Code: [Select]

#define LCD_FLIP_X                      /* enable horizontal flip */
//#define LCD_FLIP_Y                      /* enable vertical flip */
And for Encoder changed:

3. From

Code: [Select]

#define ENCODER_A        PD2       /* rotary encoder A signal */To

Code: [Select]

#define ENCODER_A        PD1       /* rotary encoder A signal */


I also noticed in PWM and Square Wave modes it shows Pins 2-13.  I don't understand what it means 

In variables.h

Code: [Select]

const unsigned char PWM_Probes_str[] EEMEM = "2-13"

[madires]

Thanks for the settings! I think, I'll add a dedicated file with the settings for the various tester versions/clones. So users just need to copy & paste. Back to your questions. The display isn't cleared directly at power up, because clearing the whole display is slow. That would interfere with the mode selection, which is based on how long you press the button when powering on. And it might irritate some users ("I've pressed the button, but nothing happens."). After the initial full clear only the lines used are cleared to speed up the process. "2-13" means that the signal is at probe/pin 2 and ground at probes/pins 1 and 3.

[flywheelz]

The display isn't cleared directly at power up, because clearing the whole display is slow. That would interfere with the mode selection, which is based on how long you press the button when powering on. And it might irritate some users ("I've pressed the button, but nothing happens.").

The mode selection is done prior you do anything with the LCD so it should not interfere , I think.

Anyways, I've added command LCD_Clear() after line 1107: LCD_Init(); and this seem to solve the issue I saw with LCD 7735.  I don't notice any delay and screen stays black then text appear 

changes in main.c
 

Code: [Select]


  1106: /* init LCD module */
  1107: LCD_Init();                           /* initialize LCD */
  1108: LCD_Clear();                          /* clear display */
  1109: LCD_NextLine_Mode(MODE_NONE);         /* reset line mode */

[ja421]

On the color units (one just arrived, it wasn't supposed to be color); can the firmware be compiled as monochrome to regain some memory?  It is not put together, so I can't test it... Or can the display be swapped out for a mono display?  I don't think it's worth trying to send back (postage+time > what I paid for it), but don't want to bother putting it together if it's going to be crippled by lack of memory due to color display... tx

[stj]

the memory is tight, tens of bytes out.
so it may be o.k. with enough experimenting.

as it stands, the only option you cant fit in is the crystal test, and that needs a 16MHz crystal upgrade anyway.

btw, the monohrome stuff isnt much better - a case of "just fits" as opposed to "just over"

[ja421]

aah; thanks.  I guess that's not as crippled as I thought it would be.
I can definitely live w/o a crystal test.

[flywheelz]

Maybe it my eyes but the AY-AT kit with color lcd 7735 that I got is not as crisp as monochrome displays (comparing screenshots).  Maybe its the fonts types or sizes not sure.  The screens physical dimensions are also smaller.  Finally, the slower refresh rate  but I got used to it.

The good thing is the color kits seem to be best bang for the buck.  You get the protection mod, encoder, dc jack and extra screw connectors already included.

When I compiled the latest k-firmware,  I get, "Program:   32550 bytes (99.3% Full)" and the m-firmware, "Program:   28158 bytes (85.9% Full)". 

@ja421,  Let us know who did a switch-a-roo on you.  Maybe you can file item not as discribed.  Regardless,  I hope the build go well.  These kits are super fun and freaking smart I tell ya.

[stj]

Maybe it my eyes but the AY-AT kit with color lcd 7735 that I got is not as crisp as monochrome displays (comparing screenshots)
[/quote

maybe you left the protective film on the display
is there a small tab lower-right?

[flywheelz]

Maybe it my eyes but the AY-AT kit with color lcd 7735 that I got is not as crisp as monochrome displays (comparing screenshots)
[/quote

maybe you left the protective film on the display
is there a small tab lower-right?

No, I took it off already.

What I need to do is get a unit with ST7565 screen and then compare it to ST7735.

btw, I've ordered 10 x SVR05-04 for $0.33 from Ali.  Will slap one back on my unit.  The original is still MIA.

[madires]

The mode selection is done prior you do anything with the LCD so it should not interfere , I think.

LCD_BusSetup() is called before checking how long the push button is pressed.

Anyways, I've added command LCD_Clear() after line 1107: LCD_Init(); and this seem to solve the issue I saw with LCD 7735.  I don't notice any delay and screen stays black then text appear 

changes in main.c
 

Code: [Select]


  1106: /* init LCD module */
  1107: LCD_Init();                           /* initialize LCD */
  1108: LCD_Clear();                          /* clear display */
  1109: LCD_NextLine_Mode(MODE_NONE);         /* reset line mode */

That's funny, because at the end of LCD_Init() LCD_Clear() is already called.

[madires]

On the color units (one just arrived, it wasn't supposed to be color); can the firmware be compiled as monochrome to regain some memory?  It is not put together, so I can't test it... Or can the display be swapped out for a mono display?  I don't think it's worth trying to send back (postage+time > what I paid for it), but don't want to bother putting it together if it's going to be crippled by lack of memory due to color display... tx

Color handling needs just a few bytes more in the firmware. And since color diplays mostly need 16bits per pixel instead of 1 bit any output is slowed down by that factor. What really impacts the firmware size is the font and the symbols. A smaller font/symbol size decreases the firmware.

The following is relevant for monochrome displays. A smaller font might create large gaps between lines on page-oriented displays. A page is an 8 bit high adressing area, i.e. you write a byte to address 8 pixels in a column. That could be solved by a display RAM buffer, but we don't got that luxury

Most graphic displays are driven by SPI plus /CS, /RES and D/C. So chances are high that you can replace the color display with a monochrome one, if you prefer that.

[flywheelz]

The mode selection is done prior you do anything with the LCD so it should not interfere , I think.

LCD_BusSetup() is called before checking how long the push button is pressed.

Anyways, I've added command LCD_Clear() after line 1107: LCD_Init(); and this seem to solve the issue I saw with LCD 7735.  I don't notice any delay and screen stays black then text appear 

changes in main.c
 

Code: [Select]


  1106: /* init LCD module */
  1107: LCD_Init();                           /* initialize LCD */
  1108: LCD_Clear();                          /* clear display */
  1109: LCD_NextLine_Mode(MODE_NONE);         /* reset line mode */

That's funny, because at the end of LCD_Init() LCD_Clear() is already called.

I have now removed the LCD_Clear() that I added expecting the display to show noise like before but it no longer is doing it.  I don't know what was going on before.  I will report back if it reappears.

[flywheelz]

@madires,

The weird issue is still there but only if I restart with the switch.  If restarting with SPI it doesn't show up.

https://youtu.be/EPsf8d41A60

[hapless]

Is that with the extra LCD_Clear() or without it?

[flywheelz]

Is that with the extra LCD_Clear() or without it?

The extra LCD_Clear() had no effect. I thought it did because I was doing SPI resets while testing the TT and was still connect to Arduino 5v rail effectively it never fully powered off.  I only see it when applying external power at DC jack.

[stj]

maybe the display has a page-buffer.

[madires]

@madires,
The weird issue is still there but only if I restart with the switch.  If restarting with SPI it doesn't show up.

The video was a great idea. It's not a bug, it' a feature. That "noise" is the uninitialized display RAM. Normally you would first clear the display/RAM and then turn the display output on. I'm doing it the other way around to give the user an immediate visual feedback when powering on. The video shows nicely how slow the initial LCD_Clear() is. For a ILI9341 (240 x 320) it takes about 2 or 3 seconds at 8MHz. Those LCD controllers don't got a fast built-in clear function and require you to send "black" (or whatever background color you prefer) for each pixel. Since the ST7735 isn't extremely slow, you could try and move the power-on section in LCD_Init() to the end. Maybe just LCD_Cmd(CMD_DISPLAY_ON), and removing MilliSleep(120).