$20 LCR ESR Transistor checker project

[SA]

Hello Madires,
I have something in my mind. As day passess, there will be improvement and new features will be added. But for the most used MCU in this project Atmega328p won't be able to provide all those fratures because of the bottleneck either the flash memory or eeprom or both. If someone one to use new more powerful MCU with more flash and eeprom, he have to write new code according to the new MCUs architecture and registers, basically have to reinvent the wheel . Is there any way to use external flash and eeprom with atmega328p to avail all the new future updates?

[madires]

Several ATmegas with more pins, RAM and flash memory are supported, e.g. 644, 1284, 640, 1280 and 2560. Additional external flash memory wouldn't help much because it can't be mapped into the ATmega's address space. But it could be used to store data.

[SA]

You are right. But the chinese manufacturers are not keen to make one with atmega2560. I think we have to take the matter into our own hands. 

[madires]

Some clones have an ATmega324 or 644. And there are a few 644/1284 based circuits for DIY.

[gold oxide]

I've had this model since forever. I guess the main board was originally designed for the two line text display (mounting holes) and they just reused it with the graphics display mounted upward. It does not show a firmware version anywhere. If anyone has a compiled version of current firmware for this, let me know.
So my impression is that the current best deal would still be the "AY-AT" in the through hole version if I wanted to get a new one?

[madires]

Looks like a variant of the M328 clone with an ST7565 based display. If you're able to figure out the display signal lines compiling a suitable firmware shouldn'd be a problem. And yes, AY-AT/GM328 with a DIP ATmega is still a good choice.

[indman]

I've had this model since forever. I guess the main board was originally designed for the two line text display (mounting holes) and they just reused it with the graphics display mounted upward. It does not show a firmware version anywhere.

On my resource https://yadi.sk/d/yW8xa5NJgUo5z your clone model is designated as GM328(+). You have a small variation of this clone, but I think and almost sure that the firmwares in the folder /Firmware/Karl-Heinz Kübbeler /English, will work normally. True, they are not very fresh anymore.
There is one more warning if you want to change the firmware on this clone.You need to take a close look at the schematic diagram in the /Schematic diagram folder and pay attention to the red cross that breaks the connection between pin 6 and PD5/Tckb port.
If you have a display with a PD5/Tckb port on your clone, you will need to disconnect it, otherwise the latest firmware will not work properly due to increased current consumption.

[Yuriy_K]

I've had this model since forever.

I had the same one for a long time, but the display is a little different. I raised my archives and collected two k-firmware for you. For your quartz 8 MHz and 16 MHz for testing on my T4_16 MHz. In the photo are examples of measurements. The firmware is very different from the author's, in recent years I have changed and supplemented it. If you change your quartz to 16 MHz, you will see the changes.

With Selftest or Selftest mode the Socket must be closed. As an example, various measurements on a modified T4.

[gold oxide]

If you have a display with a PD5/Tckb port on your clone, you will need to disconnect it, otherwise the latest firmware will not work properly due to increased current consumption.

I raised my archives and collected two k-firmware for you.

I disconnected PD5 from the display and tried both your 8 MHz firmwares, indman and Yuriy_K. Flashed with an USBasp and Avrdudess. Didn't touch the fuses, just hex and eep files.
Both firmwares work on my version of the tester as far as I tried them out. They are both 1.13k but clearly a bit different. When I come across a 16MHz quartz I will also try that version. Thanks guys.

[SA]

Is there any way to use spi flash to store the firmware and have all the features 

[Feliciano]

Do you mean to use external flash memory for the firmware?
On one hand, we would need to asign valuable pins for that interface, or mux its functionality. And ruin the idea of the OSHW.
On the other hand, AFAIK you cannot run code directly from external memory, you rather use it for storage.

The suggestions the developers have already made is to look for higher-end ATmega, like the 644/1284.

[MLXXXp]

Is there any way to use spi flash to store the firmware and have all the features

In theory, it could be done. An SPI flash chip could share the bus with an SPI display. One pin and an inverter could provide the chip select for both (with one selected when the other isn't).

The MCU could have a bootloader that provided a menu on the display to select the desired feature, or feature set, and then load it from the flash chip into program memory for execution. Control of the menu could be via push button and rotary encoder, as is already used. As an example of something similar, the ATmega32U4 based Arduboy game system can have hundreds of games on its SPI flash chip and can load any one of them in to program memory for playing (one at a time).

Since the tester runs at 5V and SPI flash is usually max 3.3V, you would probably also need a regulator and level shifters.

Whether anyone would go to the effort of designing the hardware, implementing the bootloader, and splitting the code into separate functional blocks, is another story.

[gadefox]

I'm trying to understand the source code in cap.c, but I don't quite get why the CYCLE_OFFSET is set to 17 cycles. According to the assembly code (see attached), the function `DelayTimer` seems to take more cycles (see bellow), so the calculation of 17 as the fixed overhead is unclear.

Prologue: 6
Reset TCNT0: 5
TCCR0B = 1: 6
Stop + clear flag: 10
Epilogue: 8
(35 cycles)

Any idea?

[madires]

IIRC, the offset of 17 MCU cycles isn't meant to match DelayTimer() excatly, but a part of it. It's based on what the compiler (some older version) generated when I was working on that code.

[gadefox]

I understand. I suggest to replace `DelayTimer` with assembler source code and calculate exact number of cycles..

I used `avr-gcc -S -mmcu=atmega328p main.c -o main.asm` to translate C code to assembler.. (I'm using Linux)
 

[gadefox]

I can't compile the source code with this configuration in Makefile:
# MCU freqency:                                                                                                                                                               
# - 1MHz  : 1                                                                                                                                                                 
# - 8MHz  : 8                                                                                                                                                                 
# - 16MHz : 16                                                                                                                                                               
# - 20MHz : 20                                                                                                                                                               
FREQ = 1

I'm getting the following error:
/home/fox/.build/tester-1.55m/ST7565R.c:434:(.text+0xe2): undefined reference to `wait1us'
/usr/lib/gcc/avr/14.2.0/../../../avr/bin/ld: /home/fox/.build/tester-1.55m/ST7565R.c:437:(.text+0xe8): undefined reference to `wait1us'

Do we need frequencies<8MHz?

[gadefox]

I'm also little bit confused. For the frequency 8MHz the function wait1us is defined as nop + ret (5 cycles and only 0.625μs).
For the frequency 16MHz this function takes only 0.8125μs (13 cycles)

Am I missing anything? Thanks..

[gadefox]

I was looking at that ADC sampling loop and I think there’s a little bug in it. Right now, it checks Value < 1024 after 5 samples to decide whether to switch to the bandgap reference. The problem is, Value is the sum of the first 5 readings, not the average. So the condition is totally off – it might never trigger or trigger at the wrong time.

Basically, you should be comparing the average of those samples instead of the sum. Oh, and the goto sample is a bit messy too – it resets all your previous sums, which works but is kinda confusing. Just thought I’d give you a heads-up.

[gadefox]

I ported wait.S to the LGT8F328P with exact timing, but I’m not sure whether I should fix the bugs in the old source code or carry them over to the LGT part, since I assume the firmware was tested with those bugs present.

[madires]

I can't compile the source code with this configuration in Makefile:
# MCU freqency:                                                                                                                                                               
# - 1MHz  : 1                                                                                                                                                                 
# - 8MHz  : 8                                                                                                                                                                 
# - 16MHz : 16                                                                                                                                                               
# - 20MHz : 20                                                                                                                                                               
FREQ = 1

I'm getting the following error:
/home/fox/.build/tester-1.55m/ST7565R.c:434:(.text+0xe2): undefined reference to `wait1us'
/usr/lib/gcc/avr/14.2.0/../../../avr/bin/ld: /home/fox/.build/tester-1.55m/ST7565R.c:437:(.text+0xe8): undefined reference to `wait1us'

Do we need frequencies<8MHz?

I'll remove the 1 MHz option since it doesn't make much sense anyway as the TransistorTester needs 8 MHz for several measurements.

[madires]

I was looking at that ADC sampling loop and I think there’s a little bug in it. Right now, it checks Value < 1024 after 5 samples to decide whether to switch to the bandgap reference. The problem is, Value is the sum of the first 5 readings, not the average. So the condition is totally off – it might never trigger or trigger at the wrong time.

Basically, you should be comparing the average of those samples instead of the sum. Oh, and the goto sample is a bit messy too – it resets all your previous sums, which works but is kinda confusing. Just thought I’d give you a heads-up.

average = sum of values / number of values

To save a few bytes and speed up things you can skip the calculation of the average and compare the sum of values with the threshold (average * number of values).

[madires]

I'm also little bit confused. For the frequency 8MHz the function wait1us is defined as nop + ret (5 cycles and only 0.625μs).
For the frequency 16MHz this function takes only 0.8125μs (13 cycles)

Am I missing anything? Thanks..

+ function call. It's meant to be short (in size) and good enough (not to be super precise).

You'll find many oddities in the code and they are there for several reasons, e.g. to minimize firmware size or to mitigate MCU issues (not explained in the datasheet). The firmware is tested across different TransistorTesters models, different ATmegas and different MCU clock rates to get the best compromise of performance. When porting the firmware to a different MCU family you should keep that in mind and test every part extensively and make changes if needed.

[gadefox]

Yep, call instruction! That's what I'm missing, thanks..

I added the note at the top of the source file..

[gadefox]

To save a few bytes and speed up things you can skip the calculation of the average and compare the sum of values with the threshold (average * number of values).

I thought so, but you're comparing the sum of values with 1024 which is incorrect. The correct number is 1024 * Counter, so this optimization didn't save any few bytes and didn't speed up things. Please note you don't need to fix this, it's up to you. I'm just the messenger.. The same with regard CYCLE_OFFSET issue.

Value += ADCW;                 /* add ADC reading */
...
if ((uint16_t)Value < 1024)       /* < 1V (5V / 5 samples) */
...
Counter++;   /* another sample done */

[madires]

Sorry, you still don't get it. The voltage of the internal bandgap reference is 1.1V +/- 100mV. So the worst case lower limit is 1 V. And it's a 10 bit ADC. The mamximum raw binary ADC value is 2^10 - 1 = 1023. When measuring a voltage using Vcc as reference (5 V) the maximum raw ADC value of 1023 means 5 V. When measuring a voltage of 1 V (reference still 5 V) the raw ADC value would be 1/5 of the maximum (about 205). Take five samples of the raw value for 1 V and the sum is 5 * 1/5 * 1023 = 1023. And only after the whole measurement procedure the raw binary value is converted into a voltage.