I bought the LCR-T4 version from ebay and now I'm trying to modify it to run on 18650 battery but I need to adjust battery voltage settings. I uploaded the .hex file from "mega328_T3_T4_st7565" and it seems to be working. Then I tried adjusting BAT_POOR setting and compiling, but it does not fit in size even with default makefile:
I'm using latest WinAVR (from year 2010 lol). Tried atmel gnu toolchain but it gave me errors when compiling. Any ideas why it gets so large?
Please try a recent version of avr-gcc (better optimization)!
Tried atmel gnu toolchain but it gave me errors when compiling. Any ideas why it gets so large?
If you do upgrade the AVR-GCC (I recommend to version 4.8.1) then try this fix of the compilation error (applies to Win 8, 8.1 & 10):
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg818096/#msg818096
Note:
Check the version of the compiler with command "avr-gcc --version".
I managed to compile with avr-gcc 4.8.2 within size limits. However, finding binaries for that took a while and I couldn't find any newer ones. It seems that the only option getting avr-gcc for windows is to compile it from sources?
It seems that the only option getting avr-gcc for windows is to compile it from sources?
For the purposes of updating the WinAVR you need download and unpack the contents of the Atmel AVR Toolchain 3.4.4 or 3.4.5 (contains compiler 4.8.1) to a directory with installed WinAVR.
In terms of efficiency compile I recommend using the compiler version 4.8.1, because the current version 4.9.2 (Toolchain 3.5.0) generates a larger files.
Atmel AVR Toolchain for Windows (direct download links):
*
Toolchain 3.4.4 (contains compiler 4.8.1)
*
Toolchain 3.4.5 (contains compiler 4.8.1)
*
Toolchain 3.5.0 (contains compiler 4.9.2 - NOT recommended)
Notes:
- Self-extracting archives (downloaded exe files) can be extracted using
WinRAR.
- Alternatively for the updating you can use the contents of the
Arduino IDE.
In terms of efficiency compile I recommend using the compiler version 4.8.1, because the current version 4.9.2 (Toolchain 3.5.0) generates a larger files.
Is there not some command-line option to generate the smaller files like the earlier compiler?
I don't compared with other optimization settings and options. Do you have any idea?
Comparison of the compilers (standart settings):
avr-gcc 4.8.1:
TransistorTester.hex [77311b]
TransistorTester.eep [142b]
avr-gcc 4.9.2:
TransistorTester.hex [77671b]
TransistorTester.eep [142b]
Comparison of the compilers (standart settings):
avr-gcc 4.8.1:
TransistorTester.hex [77311b]
I'd compare the binary firmware.
The hex file is the ASCII encoded firmware including address information.
Sure. But also the size of the file in binary form was bigger
Hi;
I have built several of these.
What I would like to know is the recommended pinout for ATMega644/1284 version.
As the firmware has outgrown the 328.
I could not find any hardware info on the larger versions.
I would like to stick with PTH parts for convenience, if possible.
It's nice to be able to pop the part out.
Is there a version for Arduino Mega 2560?
Thanks
Mick M.
M328 can be still used even with all the new features.
All the other required information you will find in the
official manual.
Specifically these chapters:
2.7 Extented circuit with ATmega644 or ATmega1284 (page 28)
2.8 Buildup of a tester with ATmega1280 or Arduino Mega (page 30)
Thanks tom666;
now I can use my old Sarduino for something.
Mick M.
M328 can be still used even with all the new features.
All the other required information you will find in the official manual.
Specifically these chapters:
2.7 Extented circuit with ATmega644 or ATmega1284 (page 28)
2.8 Buildup of a tester with ATmega1280 or Arduino Mega (page 30)
Manual? Damn! That's better than most thesis I did read! It explains things better than all books on my vocational school.
Great work!
I did read about graphical LCD. Are there plans to to support color displays?
I'm sorry, these days my mind isn't in right shape. Maybe or was in the document.
What about discussing limitations /bugs in hardware and possible fixes?
I did read about graphical LCD. Are there plans to to support color displays?
The k-firmware supports ST7735, but just uses a fixed set of fg/bg colors IIRC. The m-firmware supports ILI9341/ILI9342 and uses a few colors.
BTW, LCD samples are welcome
I did read about graphical LCD. Are there plans to to support color displays?
The k-firmware supports ST7735, but just uses a fixed set of fg/bg colors IIRC. The m-firmware supports ILI9341/ILI9342 and uses a few colors.
BTW, LCD samples are welcome
Can you provide a wishlist?
BTW, LCD samples are welcome
Can you provide a wishlist?
The m-firmware supports HD44780, ST7565 and ILI9341/ILI9342 at the moment. So any other LCD controller would be interesting.
I've installed
ComponentTester-classic-1.20m firmware on my 2 X 16 tester. I decided to see if a
Sharp GP1U587X IR module would work with the new
IR RC detector feature. When the tester is powered up with the module attached, and it probes to determine what kind of device is plugged in, it displays just the diode symbol followed by the number 6 (see attached photo).
I know the tester won't properly detect the module, since it's not a discrete component, but what does a diode symbol followed by 6 say that it thinks it is?
P. S. In case anyone cares, this module doesn't work with the tester. It's specified to require 4.7V to 5.3V but the current that it draws through the 680 ohm resistor drops Vs on probe pin 2 to only 3.7V. It would be nice to have an IR mode option that provides Vs from one of the pins (PC0-2) directly attached to the probe pins for this case (with proper warnings about shorting the pin included in the documentation).
I've installed ComponentTester-classic-1.20m firmware on my 2 X 16 tester. I decided to see if a Sharp GP1U587X IR module would work with the new IR RC detector feature. When the tester is powered up with the module attached, and it probes to determine what kind of device is plugged in, it displays just the diode symbol followed by the number 6 (see attached photo).
It thinks that there are 6 diodes.
P. S. In case anyone cares, this module doesn't work with the tester. It's specified to require 4.7V to 5.3V but the current that it draws through the 680 ohm resistor drops Vs on probe pin 2 to only 3.7V. It would be nice to have an IR mode option that provides Vs from one of the pins (PC0-2) directly attached to the probe pins for this case (with proper warnings about shorting the pin included in the documentation).
In IR.c in function IR_Detector() please change
ADC_PORT = 0; /* pull down directly: */
ADC_DDR = (1 << TP1); /* probe-1 */
/* pull up probe-2 via Rl, pull down probe-3 via Rh */
R_DDR = (1 << (TP2 * 2)) | (2 << (TP3 * 2)); /* enable resistors */
R_PORT = (1 << (TP2 * 2)); /* pull up probe-2, pull down probe-3 */
to
ADC_PORT = (1 << TP2);
ADC_DDR = (1 << TP1) | (1 << TP2);
R_DDR = (2 << (TP3 * 2));
R_PORT = 0;
to get Vcc just limited by the MCU's internal resistance (around 20 Ohms).
It thinks that there are 6 diodes.
6 diodes across which probe pins?
In IR.c in function IR_Detector() please change [...]
Thanks for the code changes. I'll try them out as soon as I get some time (which might take a few days). If it works, would you consider making this configurable using a define in config.h or by some other easier means?
Please help me,..
when I compile files with settings makefile "with sampilngADC", an error message appears on the image. But if no "with sampling ADC", no problem. I compile with winavr2010. What is the problem ? And What should I do? Thanks.
6 diodes across which probe pins?
Across all three probe pins. The diode output function only supports up to 2 diodes. Any more diodes are displayed as you've already seen.
Thanks for the code changes. I'll try them out as soon as I get some time (which might take a few days). If it works, would you consider making this configurable using a define in config.h or by some other easier means?
No problem, I'd go for the #define switch.
Thanks for the code changes. I'll try them out as soon as I get some time
madires,
I've tested your code changes to provide direct 5V to the IR sensor. The GP1U587X module now works, but not very well. Some remotes work fine. For others the remote has to be held very close to the sensor and at a certain angle or else I get garbage codes, and for a few I just always get random codes. I don't think the problems have anything to do with the tester. I'm guessing it's because my module has a band pass centre frequency of 56.8kHz, so it isn't very sensitive for remotes with lower carrier frequencies.
Because of this problem, I won't be using the GP1U587X module, so for me the change is no longer important. It's up to you if you want to add a #define and code for it.
I also have tried a
VS1838B IR module. It works fine, both without and with the code change.
Thanks for your help.
I've tested your code changes to provide direct 5V to the IR sensor. The GP1U587X module now works, but not very well. Some remotes work fine. For others the remote has to be held very close to the sensor and at a certain angle or else I get garbage codes, and for a few I just always get random codes. I don't think the problems have anything to do with the tester. I'm guessing it's because my module has a band pass centre frequency of 56.8kHz, so it isn't very sensitive for remotes with lower carrier frequencies.
Thanks for the feedback! I think you're right, most IR RCs use a 36 or 38kHz carrier. I've tested the decoder with about 20 or so RCs and an universal one using a 38kHz TSOP (2.5V-5.5V). One interesting thing I've found is that most no-name stuff uses the NEC protocol.
Because of this problem, I won't be using the GP1U587X module, so for me the change is no longer important. It's up to you if you want to add a #define and code for it.
I'll add a #define switch for it, in case someone has a 5V only IR receiver module. I should also add a remark about the supply voltage in the documentation.
I also have tried a VS1838B IR module. It works fine, both without and with the code change.
Thanks for your help.
You're welcome!
I've just released "Happy New Year" 1.21m
Changes for Trendy:
- licensed under EUPL v1.1
- two adjustment profiles
- IR detector: RC-6, bugfix and support for 5V-only modules
Changes for Classic:
- licensed under EUPL v1.1
- IR detector: bugfix and support for 5V-only modules
- will most likely only receive bug fixes in the future (hint: upgrade to Trendy Edition!)
Presumably the next major step will be an ATmega 664/1284 board and support for 664/1284 in the m-firmware. And touchscreen of course.
Why changing to EUPL? Weekday about license compatibility?