If you're looking for the latest k-firmware, check the revision of "trunk" at https://www.mikrocontroller.net/svnbrowser/transistortester/Software/ and compare that to your local copy. You can do the same for the m-firmware ("Markus") to see if there's anything new, but the revision isn't relevant.
Dear NickNI - participant of the Russian speaking forum VRTP.RU created very evident illustrated assistant on use of SVN of an array. I translated this document into English. I think that it will be useful, especially to beginners!
https://yadi.sk/d/NrdXtqc_uBCPZ
Thanks for the effort. I suggest also posting a link to the original article as a courtesy to its original author.
Thanks!
To speed things up, I made a few assumptions about the tester and compiled the firmware. Unfortunately, I can't test it right now. If this doesn't work right, try to describe the problem in as much detail as you can, and I will adjust parameters and have another go at it.
thanks for help me
i installed mandires
the screen show this when i test a kia 7812a (voltage regulator?)
this is a a970 pnp transitor ( no diagram of bjt pnp transitor )
since i dont know which screen i have, i upload a photo from it, where i can search the type of screen?
i used the same efuse config that i used for trunks firmware
Yes, the tester can't correctly identify integrated circuits, including voltage regulators. This is normal.
As for the lack of icons... I think you found a small bug.
518c518
< #if defined (SYMBOLS_24X24_V) || defined (SYMBOLS_24X24_H) || defined (SYMBOLS_32X32_H)
---
> #if defined (SYMBOLS_24X24_VP) || defined (SYMBOLS_24X24_H) || defined (SYMBOLS_32X32_H)
Try the file that I've attached now.
Edit: Your screen's controller is ST7565 with SPI interface. I know that because that's what I compiled into the firmware, and it obviously worked.
Edit 2: Delay set to 5 seconds rather than 3, default contrast is now 5 and the encoder should work better thanks to a post (2396) by mauroh.
Yes, he did. Thanks for the report and bugfix!
Yes, the tester can't correctly identify integrated circuits, including voltage regulators. This is normal.
As for the lack of icons... I think you found a small bug.
518c518
< #if defined (SYMBOLS_24X24_V) || defined (SYMBOLS_24X24_H) || defined (SYMBOLS_32X32_H)
---
> #if defined (SYMBOLS_24X24_VP) || defined (SYMBOLS_24X24_H) || defined (SYMBOLS_32X32_H)
Try the file that I've attached now.
Edit: Your screen's controller is ST7565 with SPI interface. I know that because that's what I compiled into the firmware, and it obviously worked.
while it's nice that you included the license in that zip, you *should* have also included any files you changed.
Yes, he did. Thanks for the report and bugfix!
You're most welcome.
while it's nice that you included the license in that zip, you *should* have also included any files you changed.
I should have put the filename in the previous post (thought I did, but apparently was in too much of a hurry), but other than that, no, I should not have included the changed file in my archive. Markus will do that when he changes it in the SVN. I posted the simple change that I made, and it is absolutely trivial to make it for anyone who's looking at the source. Someone who cares only about the stuff that comes out after it was compiled should be able to read the license, the instructions, and have the necessary files to complete the task they set out to perform, that is, to flash the microcontroller. When you download a game, do you really want it to contain all the source code files that the last reviewer had changed? All you care about is the executable and any files that make it run. This is no different.
your missing the point.
including any changed files helps people understand hardware they may not have in front of them.
and try to remember that this is OPEN SOURCE.
How am I missing the point? The source is freely available, and my patch is out there for everyone to see. Including the file in the archive would thus have been redundant and also confusing for someone who had downloaded it just to flash it. I should also mention that if I were to submit this change as a file, it would not be the changed file, but the very text you see in my post inside a .diff file. So I guess I don't see your point. Do elaborate on what goes against someone's learning or open source in the way I did it.
STJ,
FWIW, I think Hapless has the correct approach for Open Source software. He passed out a simple correction that anyone could make to their own files. If they chaged it, they would understand the change.
On the other hand you released a "version" called svn 684 but only included two files. This version is in a version system that doesn't exist except on your machine.
As best I can tell comparing to my SVN copy, these files are NOT the same as those in the k version repository and if I incorporate them into my svn, I potentially create a problem down the road. If Karl-Heinz modifies his version of these two files I would lose your changes and may not know why. If he doesn't change them but references something that you have now removed from those files, my build would fail. Either way, I would probably report it as a bug when, in fact, it was the result of changes from you that I mistakenly thought were part of the same branch.
Open Source means the source is available and modifiable by anyone. You are free to create a proper branch and continue maintaining and distributing it but if you are going to modify Karl-Heinz version of the code it would be far better if you had done it as Hapless did (the author was informed of the bug and left up to him when to include it in his official release) or JUST distributed the recompiled versions that would get replaced the next time a build is done.
This, of course, is just my opinion, but while you may be an experienced programmer, you have obviously never dealt with serious software maintenance and distribution.
the files i zipped are clearly marked "changed files"
of course they dont match the svn - you need to diff/compare them.
HOWEVER.
they do show people the correct settings for the hardware.
because the makefiles hosted by karl are generic and pretty bad.
(being polite about it)
they have badly configured contrast, incorrect included features etc.
i go to a lot of trouble to finetune those makefiles - display contrast, voltdrop from the battery etc.
it's only right that i share them afterwards for others to use.
I don't know whether to laugh or cry, but it sure feels like I'm getting a degree in psychology or something of the sort here.
What I'm trying to say is that I have finally puzzled out what this is about. Basically, the idea is to include the changes done to the configuration file
to match the hardware (unless I missed something again). I don't mind doing that, but don't see the point right now anyway. That's because I used mostly the defaults and simply enabled some of the features that I thought the hardware has. There was no tweaking, since I had no way of knowing at the time which exact tester the person asking for the firmware had. I think it would be a better idea for owners of different devices to share their specs and measured voltages and resistances, best contrast settings, and so on, so that tweaking
any firmware (hey, who says there have to be only two, right?) to support those testers would be more straightforward. A forum is not the best place for such a collection of data, but a website with a database... why not?
Any takers?
the hard part is getting people to answer questions like "what's the best contrast value".
they cant be bothered repying once the firmware works!
then there is the curse of the devil's operating system - Win10
i have been getting a number of people recently who couldnt program the tester with AVRdude.
it looks like win10 cuts the command-line buffer short, possibly terminating it at a back-slash.
i have to get win10 victims to program the flash,eeprom and fuses in 3 seperate passes!
The Banggood tester firmware you can use:
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/?action=dlattach;attach=245484
See https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg997651/#msg997651
Thanks !
But I still wonder whether in the repository there's a 'k' ("trunk") or 'm' ("Markus") version for the 12864 LCD ?
( and whether the 12864 is the ST7565 ? )
Hi STJ,
Me again...
I'am trying to compile (how it's done, i'am an absolute n00b with this) the .hex and .eep files for my lcr-t4 tester with your original un-modified Makefile.
I've installed WinAVR (latest) and set-up the directories (maps) on my hdd with the files from the SVN- repository (downloaded the whole tarball).
It seems to be working, at least i see no errors, had to replace the msys-1.0 file in the utils\bin directory of winavr.
...but my output TransistorTester.hex- file is 103kB in size! Your files are a .hex- file of 83kB (8MHz version) and 89kB (16MHz version) in size.
(I've used your supplied Makefile to compile.)
How is this possible?
Any help, comments, e.t.c. is -dearly- appreciated.
TIA.
[...]I think he fixed some display issue version v2[...]
Yes, he thinks he did so, too. He can't be sure because of the lack of feedback, but, as stj mentioned a few posts ago, when something works, people tend to just grab it and disappear.
[...]Still, What are proper config.h lines to change to make it (and future repository 'm' versions) work with the banggood LCR ?
The configuration in
config.h is not set in stone for any tester. In
config_328.h, you need to set the display driver to
/*
* M12864 DIY Transistor Tester
* - ST7565 display
* - rotary encoder at PD1/3
*/
by commenting out the corresponding
#if 0 and
#endif and uncommenting the currently commented ones, and in
config.h you can choose some of the options that you want to be enabled, again, by uncommenting the corresponding
#define statements. You'll want the encoder, the voltage reference, and the frequency counter because that is what the hardware is designed with, the rest is up to you.
List of all changes you need to make on the config.h to have the m-firmware working correctly with M12684 DIY Kit
Config.h Changes to work with M12684 DIY KIT (Banggood)
Section:
/*
* M12864 DIY Transistor Tester
* - ST7565 display
* - rotary encoder at PD1/3
*/
Uncomment entire secion and comment other LCD sections
Comment the following line to:
//#define LCD_OFFSET_X
Change the following line to:
//#define LCD_OFFSET_X
#define LCD_CONTRAST 5
Section:
/* **********************************
* Hardware options
* ********************************** */
Uncomment
#define HW_ENCODER
#define HW_REF25
This should be already
#define UREF_25 2495 //Tipical output of TL431AA (you shuld measure it?)
Section:
/* **********************************
* port and pin assignments
* ********************************** */
Change to
#define ENCODER_A PD1 /* rotary encoder A signal */
Mauro
Hi STJ,
Me again...
I'am trying to compile (how it's done, i'am an absolute n00b with this) the .hex and .eep files for my lcr-t4 tester with your original un-modified Makefile.
I've installed WinAVR (latest) and set-up the directories (maps) on my hdd with the files from the SVN- repository (downloaded the whole tarball).
It seems to be working, at least i see no errors, had to replace the msys-1.0 file in the utils\bin directory of winavr.
...but my output TransistorTester.hex- file is 103kB in size! Your files are a .hex- file of 83kB (8MHz version) and 89kB (16MHz version) in size.
(I've used your supplied Makefile to compile.)
How is this possible?
Any help, comments, e.t.c. is -dearly- appreciated.
TIA.
newer versions of gcc make larger files
the answer is to overwrite gcc with a slightly older version.
i use the one bundled with the ARDUINO IDE.
https://www.arduino.cc/download_handler.php?f=/arduino-1.6.10-windows.zip
[...]
Section:
/* **********************************
* port and pin assignments
* ********************************** */
Change to
#define ENCODER_A PD1 /* rotary encoder A signal */
Mauro
Thanks, don't know how I missed that one. Corrected.
Mauroh,
Excellent ! - That's exactly what I needed.
One wonder though:
'hapless' says uncomment:
================
/*
* M12864 DIY Transistor Tester
* - ST7565 display
* - rotary encoder at PD1/3
*/
while mauroh says uncomment:
===================
/*
* M12864 DIY Transistor Tester
* - ST7585 display
* - rotary encoder at PD1/3
*/
What gives ?