$20 LCR ESR Transistor checker project

[DAIRVINE]

So I just did the following:
1. Re-extracted v1.42m and tried that Makefile
2. Extracted v1.41m and tried that Makefile
3. Downgraded to AS7 7.0.1645 and tried both 1.41m and 1.42m Makefiles
4. Reinstalled AS7 7.0.1645 on my C: drive instead of my D: drive

Same thing each time "Failed to get info from Makefile. Did you select a valid makefile?" 

I am using AS7 7.0.2389
I extracted v1.42m into a folder on my downloads. Then had to extract that file into a folder on downloads. You get a lot of .c and .h files and one named makefile. Do not try and modify this makefile or anything else in the download to start with.
I initially selected the wrong CPU, but that actually compiled and worked OK. Then repeated the process with the correct CPU to try and fix a problem. I have now moved all the defines from the makefile into config.h and now have a normal AS7 project. I am using the latest win10 64 bit on a HP 2570P laptop.

If you sort it out, please can you tell us how you fixed it?

[DAIRVINE]

mrmox, if you were to put the ultimate transistor tester on the market, here are some cool features that it could include:
-- precision 5 volt regulator
-- high precision resistors
-- header pins for programming
-- a hardwired capacitor for convenient self adjustment
-- a relay to short connections whenever a measurement is not being made, preventing accidental tester destruction
-- an ATMega in a DIP socket so that it can be easily replaced if it ever gets damaged by misuse
-- clear markings to show the connections for frequency measurement, voltage measurement, and function generator
-- a 16MHz crystal
-- the latest M or K firmware
A typical user does not really need all of the above, but there is no reason that a kit or completed device could not have all of the above features.  I would like to buy one. 
Since an ideal tester is not available now, and since I don't quite know how to design my own board, I ordered an AY-AT type of kit from eBay, and precision parts from mouser.com.  Earlier posts from "blurpy" describe what to do, and I expect that it will all turn out quite well.   My tester will not have the relay or the self adjustment capacitor. 
For that matter, if you know how to design a board with all of those features, there must be lots of people on this forum who would like to buy one and populate it themselves, or who would like to get your Gerber file to have their own boards manufactured.

Bring out at least all unused pins to PTH pads, ideally all pins. Soldering onto fine SMD IC leads is challenging. Add a 0.1" matrix of holes/pads in unused board area.
Fit a self calibrate capacitor so that we can use the (variable frequency) internal RC oscillator.
Allow for use of debugwire(do not use the reset pin, a simple 10k to 5V is all that is required)
Put the 9V battery pads a bit further apart to avoid the risk of a stray wire shorting out the battery.

[DAIRVINE]

Has anyone tried using flyback to measure inductance?
Add a 1N4148 class diode with the anode to probe 1. Connect the cathode to a 100n X7R 50V capacitor, with the other capacitor terminal connected to 0V.
Then add a 1k resistor from the cathode of the diode/capacitor to PC3 (On a T4). The main purpose of the resistor is to limit current during discharge.
To start with, discharge the 100n. Then generate flyback pulses which charge the capacitor. For example probe 2 680R to 5V and probe 1 to 20R 0V, then set probe 2 to 20R 0V and three state probe 1, (in one action using DDRC).
This may allow slightly smaller inductors to be detected and higher resolution below 1000uH.
The 50V capacitor rating is necessary to keep the X7R within tolerance.
The cost of these components? Perhaps £0.03
Any thoughts?

[Alphonso]

Thanks Madires,

Not making a lot of progress...

Can you advise what is required to build these these AVR projects using the current version of Windows 10.
I take it that WinAVR-2010010 is long dead, or,  can it be patched with the latest AVR toolchain.
WinAVR and Atmel Studio seem to conflict with each other.
Is it best to build these using avr-gcc from command line shell?

Regards
Alphonso

[indman]

Not making a lot of progress...
Can you advise what is required to build these these AVR projects using the current version of Windows 10.
I take it that WinAVR-2010010 is long dead, or,  can it be patched with the latest AVR toolchain.

Alphonso, liquidair - for successful work and compilation of fresh firmware in any edition of Windows (7-10) it is not at all necessary to install
the program is the monster ATMelStudio! I, like many others, have been using the compact and stable WinAVR2010010 for more than 5 years. For Windows 10, you must additionally replace 1 system library msys-1.0.dll. I wrote about this earlier on the forum for Dimidian
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg3269218/#msg3269218
In addition to what I wrote, using this version of AVR-GNUToolchain 3.4.4.24 allows you to get the most compact size of the firmware, which is especially important for the small amount of memory in ATMega328. 

[madires]

Has anyone tried using flyback to measure inductance?

Not yet.  Do you have any weblinks for more details?

[Alphonso]

Hi Indman

Many thanks, spent hours on this and all fixed in 5 minutes with your toolkit.
Could these be added to an updated copy of WinAVR-2010 on sourceforge?

Regards
Alphonso

[DAIRVINE]

Has anyone tried using flyback to measure inductance?

Not yet.  Do you have any weblinks for more details?

Sorry, none at all. It just seemed like a good idea.
The basic advantage is that you build up the capacitor voltage over many cycles. Roughly, you  turn on the inductor at least long enough to build up the maximum current then switch off the current for at least long enough for the current to drop to 0, the inductor energy is then dumped into the capacitor. You then count the number of cycles to trigger the analog comparator, measure the exact voltage and some sums leads to inductance. You can verify that you have reached the maximum current because increasing the ON time does not increase the inductor energy. Even with a dead short you will build up voltage because of switching transients, so you get a zero offset.
Roughly, total energy = 0.5NLI^2, where N is the number of cycles. You can measure the charge vs Voltage for the capacitor+diode combination and so work out energy vs voltage and compensate non linear capacitors and diodes. Or use energy = (Vd* CV +0.5CV^2).

 So we get L = (Vd* CV +0.5CV^2)/(0.5NI^2). You do need to switch from charge to flyback in the same clock edge, which may need assembler.
Performance? I estimate around 10uH to 1000uH using the 680R, but with much better resolution than the RL method.

[Twiggy]

Hello everyone,

thank you for your work on this nice project.
I bought an Hiland m644 that did not power up properly from factory : screen would come on only when i pressed the rotary switch. (attached pic)

I thought that it might have been because the device came without any firmware, so thanks to your thread I built firmware 1.42m (attached .hex and .eep)

However even after flash (screen avrdude)the screen status is the same. I tried even with k firmware (https://www.mikrocontroller.net/svnbrowser/transistortester/Software/trunk/mega644_hiland_m644/)
but got a verification error :

Can you tell from avrdude log if flash had some error? Is there a way to have a command prompt on the device
to know if it is defective?

avrdude log : https://pastebin.com/9GRpmsBQ
settings used :

If you want I can give more details on firmware config.

thanks for reading me

[Ser9ei]

Hi Twiggy!,
as I see in the log, you have an exception in during the firmware process:
  "avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update."

Please try one these options (or perhaps all):
  - upgrade the firmware of usbasp (another programmator is nessasary)
    last firmware is here https://www.fischl.de/usbasp/
  - Install the driver for Usbasp with help the Zadig tool (https://zadig.akeo.ie/). Instructions - https://www.instructables.com/USBASP-Installation-in-Windows-10/

In the screenshot the avrdudess soft work in the "Verify" mode (Combobox "Verify" is checked).
I would like to hope, you don't forget to chose "Write" mode in during flashing process.

PS
And,
 - before start "flash" process, please check connection (and the "Bit clock(-b)") setting with the help "Detect" button.
 - set "Erase flash and EEPROM (-e)" checkbox in during the firmware process (Please be aware, it is just only for the "Write" process, for the "Read/Verify" process should be unchecked)

[Dumidan]

Hello everyone,

thank you for your work on this nice project.
I bought an Hiland m644 that did not power up properly from factory : screen would come on only when i pressed the rotary switch. (attached pic)

I thought that it might have been because the device came without any firmware, so thanks to your thread I built firmware 1.42m (attached .hex and .eep)

However even after flash (screen avrdude)the screen status is the same. I tried even with k firmware (https://www.mikrocontroller.net/svnbrowser/transistortester/Software/trunk/mega644_hiland_m644/)
but got a verification error :

Can you tell from avrdude log if flash had some error? Is there a way to have a command prompt on the device
to know if it is defective?

avrdude log : https://pastebin.com/9GRpmsBQ
settings used :

If you want I can give more details on firmware config.

thanks for reading me

Hello!

From what I saw in the pictures, you have problems with lockbit. The MCU you want to program is locked, see the attached images.
That's why the flash check gives an error. LB should have the value 0xFF.
According to the manufacturer's documentation "The Lock bits can only be
erased to “1” with the Chip Erase command. "

You must enter command com and give the command:

avrdude  -c usbasp -p m664p -e

Then read fuses & lock bits with AVRDUDESS.
Everything should be 0xFF. Write the desired values: L = 0xFF, H = 0xD9, E = 0xFC, LB remains 0xFF.

Only now can you load the desired firmware.

Good luck with that!

[Twiggy]

[...]

Hello Ser9ei, thanks for your reply! It's weird to me that this is the problem because it's displayed as a warning, not an error, and the write process continues and even verifies at the end. So it must somehow be able to find a SCK frequency thats accepted.

- before start "flash" process, please check connection (and the "Bit clock(-b)") setting with the help "Detect" button.

When I click detect, it says :

Code: [Select]

>>>: avrdude -u -c usbasp -B 0.5 -v -p m8
Detected 1e960a = ATmega644P
but does not set the baud rate (-b) nor Bit clock (-B). I left it by default at 1.5 MHz. I don't know what value to use.

I would like to hope, you don't forget to chose "Write" mode in during flashing process.

I did not do that mistake  . I think if I made a mistake, avrdude log would not show the writing process.

Please try one these options (or perhaps all):
  - upgrade the firmware of usbasp (another programmator is nessasary)
    last firmware is here https://www.fischl.de/usbasp/
  - Install the driver for Usbasp with help the Zadig tool (https://zadig.akeo.ie/). Instructions - https://www.instructables.com/USBASP-Installation-in-Windows-10/

Aww, it took long enough for the first one to arrive  Are you absolutely sure this is the issue despite avrdude process saying it succeeds in flashing & verifying data?

I did not have any issues installing the driver on my PC as I do not use windows 10 . I used windows 7 driver from https://eecs.oregonstate.edu/education/inventory_datasheets/P1438967372-1443308202.pdf section 4.1.1 and it installed well. According to what you said, the issue would not be the pc driver but the firmware itself, right? So I don't need to change that driver.

From what I saw in the pictures, you have problems with lockbit. The MCU you want to program is locked, see the attached images.
That's why the flash check gives an error. LB should have the value 0xFF.
According to the manufacturer's documentation "The Lock bits can only be
erased to “1” with the Chip Erase command. "

You must enter command com and give the command:

avrdude  -c usbasp -p m664p -e

Then read fuses & lock bits with AVRDUDESS.
Everything should be 0xFF. Write the desired values: L = 0xFF, H = 0xD9, E = 0xFC, LB remains 0xFF.

Only now can you load the desired firmware.

Good luck with that!

Hello
Where did you go to make those screenshots? I went to : https://www.engbedded.com/fusecalc?P=ATmega644P but it does not say anything for the lock bits.
Also according to my pastebin the flash check does not fail - am I missing something?

I did the command you hinted :

and it directly sets the values you told me.

When I ask to write lock bit, it fails : https://pastebin.com/UwS2DfC1
avrdudess was like this :

do I need to check "Set lock" or do something else?

thanks

[Dumidan]

Hello
Where did you go to make those screenshots? I went to : https://www.engbedded.com/fusecalc?P=ATmega644P but it does not say anything for the lock bits.
Also according to my pastebin the flash check does not fail - am I missing something?


I did the command you hinted and it directly sets the values you told me.

When I ask to write lock bit, it fails
avrdudess was like this : ...  do I need to check "Set lock" or do something else?

thanks

OK. Let's take them one at a time:

1. The USBasp firmware warning can be easily ignored if you do not program any ATtiny series MCUs.

2. in the case of flash memory a cell is deleted (empty) if it is written with logic 1, ie the byte has the value 0xFF. It is normal to give some errors if, instead of erase, you try to write the value 0xFF.

3. try this fusebit computer too: https://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega644p
it is more complete.

4. let's make a difference: avrdude.exe is a program that can be used in the com command terminal, while AVRDUDESS is a graphical interface (GUI) for avrdude.exe.

5. to know the status of the fusebits, in AVRDUDE press the read buttons. If the result is L = 0xFF, H = 0xD9, E = 0xFC, LB = 0xFF then you should have no more difficulties in programming the ATmega644 MCU.

If you still have questions, tell me and, if I know, I'll help you.

A good day.

[Twiggy]

1. The USBasp firmware warning can be easily ignored if you do not program any ATtiny series MCUs.
2. in the case of flash memory a cell is deleted (empty) if it is written with logic 1, ie the byte has the value 0xFF. It is normal to give some errors if, instead of erase, you try to write the value 0xFF.
3. try this fusebit computer too: https://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega644p
it is more complete.
4. let's make a difference: avrdude.exe is a program that can be used in the com command terminal, while AVRDUDESS is a graphical interface (GUI) for avrdude.exe.
5. to know the status of the fusebits, in AVRDUDE press the read buttons. If the result is L = 0xFF, H = 0xD9, E = 0xFC, LB = 0xFF then you should have no more difficulties in programming the ATmega644 MCU.

1. Thanks thats good to know
2. Not sure what you mean. I do avrdude command like you said :

Code: [Select]

PS D:\tools\AVRDUDESS-2.13-portable> .\avrdude.exe -c usbasp -p m644p -e
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s
avrdude.exe: Device signature = 0x1e960a (probably m644p)
avrdude.exe: erasing chip
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: safemode: Fuses OK (E:FC, H:DF, L:FF)
avrdude.exe done.  Thank you.

Then i read lock bits: :

Code: [Select]

> .\avrdude.exe -c usbasp -p m644p -U lock:r:-:h
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude.exe: Device signature = 0x1e960a (probably m644p)
avrdude.exe: reading lock memory:
Reading | ################################################## | 100% 0.01s
avrdude.exe: writing output file "<stdout>"
0x3f

avrdude.exe: safemode: Fuses OK (E:FC, H:D9, L:FF)

avrdude.exe done.  Thank you.
>


and when I write 0XFF :

Code: [Select]

PS D:\Documents de Anis\Hobbies\Hiland m644\tools\AVRDUDESS-2.13-portable> .\avrdude.exe -c usbasp -p m644p -v -v -U lock:w:0xFF:m

[...]

avrdude.exe: Device signature = 0x1e960a (probably m644p)
avrdude.exe: safemode: hfuse reads as D9
avrdude.exe: safemode: efuse reads as FC
avrdude.exe: reading input file "0xFF"
avrdude.exe: writing lock (1 bytes):

Writing |                                                    | 0% 0.00s ***failed;
Writing | ################################################## | 100% 0.06s

avrdude.exe: 1 bytes of lock written
avrdude.exe: verifying lock memory against 0xFF:
avrdude.exe: load data lock data from input file 0xFF:
avrdude.exe: input file 0xFF contains 1 bytes
avrdude.exe: reading on-chip lock data:

Reading | ################################################## | 100% 0.01s

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x3f != 0xff
avrdude.exe: verification error; content mismatch

avrdude.exe: safemode: hfuse reads as D9
avrdude.exe: safemode: efuse reads as FC
avrdude.exe: safemode: Fuses OK (E:FC, H:D9, L:FF)

avrdude.exe done.  Thank you.

We can see in log that the write operation fails. Why?

Besides, thanks for the fuse calculator =)

[Ser9ei]

We can see in log that the write operation fails. Why?

The LockBits can only be erased to “1” with the Chip Erase command.
The Chip Erase will erase the Flash and EEPROM memories plus Lock Bits. The Lock Bits are not reset until the Program memory has been completely erased. The Fuse Bits are not changed. A Chip Erase must be performedbefore the Flash and/or the EEPROM are reprogrammed.

- set "Erase flash and EEPROM (-e)" checkbox in during the firmware process (Please be aware, it is just only for the "Write" process, for the "Read/Verify" process should be unchecked)

[Twiggy]

[...]

I read this already. I made a mistake formatting my previous post; I did chip erase (-e) as Dumidan said, read lock bit and got 0x3f, and tried to write lock bit, which failed as you explained.

Chip erase did not put lock bit to 0xFF.

Look here https://yadi.sk/d/IUL_bjs0K3A6OA

I will try your fuse bits tonight. I would like to see the avrdude command that your GUI executes when flashing please.

[madires]

Everything should be 0xFF. Write the desired values: L = 0xFF, H = 0xD9, E = 0xFC, LB remains 0xFF.

The recommended setting of the low fuse for the Hiland M644 (ATmega 644, 8MHz) is 0xf7.

[Twiggy]

What I compiled was wrong. used Yuriy_K's files (k firmware) with L = 0xF7, H = 0xD9, E = 0xFC and the menu came on. Device is very slow, takes 2s to scroll 1 item in the menu, things such as "exit voltage mode" took 10s of press to finish instead of 4, etc. It said battery 4.5V empty but it reads 7.6V on voltmeter.
Somehow I couldn't get the device to start after  I unplugged the programmer. screen would light up when i press the button but no matter how long i press the menu wouldnt show.
If I plug the programmer screen comes and stays on but menu does not show.
Seems like I don't know how to use the thing.

[Twiggy]

Ok my 9V battery what was caused the device to not start, despite reading >7V. I wouldn't expect a device with a faulty battery to have the screen come on at all when pressing the start button..

Firmware from SVN trunk is ok now. Yuriy, your 8MHz firmware works as well, thanks.
As I bought this device for repair purposes to find dead components, I don't think I'll mind measurements errors.

What I compiled can make the device boot (as the red led light comes on) however the screen isn't driven properly (blank).
My screen is JLX12864G-378 Ver2.1 so i edited only st7565R section


Here are the files I modified. I tried to use section 7.07 of the manual. Please tell me what I did wrong.
https://www.diffchecker.com/bVoA3MMh
https://www.diffchecker.com/5dVZn1Jq
https://www.diffchecker.com/87LiCWo6

[Twiggy]

What I compiled can make the device boot (as the red led light comes on) however the screen isn't driven properly (blank).
My screen is JLX12864G-378 Ver2.1 so i edited only st7565R section

Having a finely tuned version with a color display, it took me several hours to create a working version for you. Firmware for quartz 8 MHz. All corrected files are in the archive, and examples of measurements for monochrome and color displays.
All the best...
https://disk.yandex.ru/d/KOJ56yV7Rxo28g

Thank you so much!

here are diffs of what you changed, in case it helps someone else..
https://www.diffchecker.com/V0LPrhN0
https://www.diffchecker.com/ieuImOYb
https://www.diffchecker.com/KGUSgUMW
https://www.diffchecker.com/PX8fjGOG
https://www.diffchecker.com/gppBmW9E

I couldnt compile your files as is though, I took all your files but config.h and it compiled but with your config.h i got :

Code: [Select]

tools_signal.c: In function 'FrequencyCounter':
tools_signal.c:1779: warning: 'Index' may be used uninitialized in this function
avr-gcc -mmcu=atmega644 -Wall -I. -Ibitmaps -DF_CPU=8000000UL -DOSC_STARTUP=16384 -gdwarf-2 -std=gnu99 -Os -mcall-prologues -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT tools_LC_Meter.o -MF dep/tools_LC_Meter.o.d -c tools_LC_Meter.c
tools_LC_Meter.c: In function 'LC_Calc_C':
tools_LC_Meter.c:363: error: fixed-point types not supported for this target
tools_LC_Meter.c:364: error: fixed-point types not supported for this target
tools_LC_Meter.c:377: error: fixed-point types not supported for this target
tools_LC_Meter.c:378: error: fixed-point types not supported for this target
tools_LC_Meter.c:380: sorry, unimplemented: GCC cannot support operators with integer types and fixed-point types that have too many integral and fractional bits together
tools_LC_Meter.c:380: error: invalid operands to binary - (have '<unnamed-fixed:64>' and 'int')
tools_LC_Meter.c:387: error: fixed-point types not supported for this target
tools_LC_Meter.c:390: warning: implicit declaration of function 'bitsulk'
tools_LC_Meter.c:390: error: '__ULACCUM_FBIT__' undeclared (first use in this function)
tools_LC_Meter.c:390: error: (Each undeclared identifier is reported only once
tools_LC_Meter.c:390: error: for each function it appears in.)
tools_LC_Meter.c:396: error: fixed-point types not supported for this target
tools_LC_Meter.c:402: sorry, unimplemented: GCC cannot support operators with integer types and fixed-point types that have too many integral and fractional bits together
tools_LC_Meter.c:402: error: invalid operands to binary * (have '<unnamed-fixed:64>' and 'int')
tools_LC_Meter.c: In function 'LC_Calc_L':
tools_LC_Meter.c:426: error: fixed-point types not supported for this target
tools_LC_Meter.c:427: error: fixed-point types not supported for this target
tools_LC_Meter.c:443: error: fixed-point types not supported for this target
tools_LC_Meter.c:444: sorry, unimplemented: GCC cannot support operators with integer types and fixed-point types that have too many integral and fractional bits together
tools_LC_Meter.c:444: error: invalid operands to binary / (have '<unnamed-fixed:64>' and 'int')
tools_LC_Meter.c:446: sorry, unimplemented: GCC cannot support operators with integer types and fixed-point types that have too many integral and fractional bits together
tools_LC_Meter.c:446: error: invalid operands to binary / (have 'int' and '<unnamed-fixed:64>')
tools_LC_Meter.c:449: error: fixed-point types not supported for this target
tools_LC_Meter.c:450: sorry, unimplemented: GCC cannot support operators with integer types and fixed-point types that have too many integral and fractional bits together
tools_LC_Meter.c:450: error: invalid operands to binary / (have '<unnamed-fixed:64>' and 'int')
tools_LC_Meter.c:452: sorry, unimplemented: GCC cannot support operators with integer types and fixed-point types that have too many integral and fractional bits together
tools_LC_Meter.c:452: error: invalid operands to binary / (have 'int' and '<unnamed-fixed:64>')
tools_LC_Meter.c:459: error: fixed-point types not supported for this target
tools_LC_Meter.c:460: sorry, unimplemented: GCC cannot support operators with integer types and fixed-point types that have too many integral and fractional bits together
tools_LC_Meter.c:460: error: invalid operands to binary * (have '<unnamed-fixed:64>' and 'uint32_t')
tools_LC_Meter.c:461: sorry, unimplemented: GCC cannot support operators with integer types and fixed-point types that have too many integral and fractional bits together
tools_LC_Meter.c:461: error: invalid operands to binary / (have '<unnamed-fixed:64>' and 'long int')
tools_LC_Meter.c:462: sorry, unimplemented: GCC cannot support operators with integer types and fixed-point types that have too many integral and fractional bits together
tools_LC_Meter.c:462: error: invalid operands to binary / (have 'int' and '<unnamed-fixed:64>')
tools_LC_Meter.c:463: sorry, unimplemented: GCC cannot support operators with integer types and fixed-point types that have too many integral and fractional bits together
tools_LC_Meter.c:463: error: invalid operands to binary * (have '<unnamed-fixed:64>' and 'long int')
tools_LC_Meter.c:472: sorry, unimplemented: GCC cannot support operators with integer types and fixed-point types that have too many integral and fractional bits together
tools_LC_Meter.c:472: error: invalid operands to binary * (have '<unnamed-fixed:64>' and 'int')
tools_LC_Meter.c:482: error: '__ULACCUM_FBIT__' undeclared (first use in this function)
make.exe: *** [tools_LC_Meter.o] Error 1


I found that uncommenting #define HW_LC_METER produced this error. is that related to winavr toolchain somehow?

- Added LC meter hardware option (HW_LC_METER). It’s based on a simple LC oscillator
circuit, similar to some inexensive LC meter kits.

please explain this part of the manual. if it's hardware related how comes yuriy's uses it and it works on my board, but when I don't use it it still works on my board?

[v81]

I've hit a roadblock with my tester, sourced from AliExpress.
Keen to swap firmware on it, but have never compiled or flashed anything outside the Arduino IDE before.

I do have an Atmel AVRISP MkII and a separate board with an ICSP header, is that all i need re hardware?
I have the code "ComponentTester-1.42m" and have made some changes to the make file, specifically the 20MHz xtal and some onewire stuff (it does currently read a DS18B20, and i'd like to keep that).
I've hit a roadblock as to what display i have.
It's colour, has 8 pins CD4050 chip on it.
Pic here..


Any assistance appreciated.

[Steve3103]

Gentlemen, this is my first post and I would firstly like to give many thanks for the help and support you give to those with less knowledge than yourselves.
I have two AY-AT testers and, thanks to the advice given here and many, many hours of reading through the previous posts, they are both working.  The rotary encoder seems to work in reverse on one of them (turn clockwise instead of anti-clockwise) but that does not appear to be a problem.  The measurements are reasonably close but I don’t expect it to be a precision tester just a tool to help me identify faulty components.   My problem is that one of the screens was broken when it was supplied – unfortunately it was some months before I built that tester and it is too late to return the faulty part.  I have purchased a new display 1.8” ST7735 SPI but I notice that the pinouts are not the same as detailed in this forum – picture attached.  I have tried cross wiring to compensate – pin 1 of the new tester to pin 8 of the socket, 2 to 7, 3 to 5, 4 to 4, 5 to 2, 6 to 3, 7 to 6 and 8 to 1 – but only the backlight comes on and only when the encoder is pressed.   Have I wasted my money and need to buy another screen or do you have any ideas that might help?
Thank you for reading.

[indman]

I have two AY-AT testers and, thanks to the advice given here and many, many hours of reading through the previous posts, they are both working.    I have purchased a new display 1.8” ST7735 SPI but I notice that the pinouts are not the same as detailed in this forum – picture attached.

3 questions for you:
1. Why are you sure that the tester with a broken display is working?
2. Have you switched a working display from one device to another?
3. Are you sure the new display has an ST7735 controller?

[Steve3103]

Hello Indman,
yes, I tried the screen from the working tester.

Hello Yuriy_K
thank you - I will reprogram the chip with these new files and report back.

[Steve3103]

Indman - sorry, I forgot to answer your final question - the screen indicates ST7735 on the reverse - photo attached.
Thank you