ESR meter upgrades

[Per Hansson]

If you want to try Markus (Madires) firmware on the GM328R it is attached here in 8, 16 & 20Mhz versions.
(I have only tested 16Mhz).
But please note the caveats I encountered:
http://www.eevblog.com/forum/testgea...53/#msg1266553

[jondoe]

Don't you need to use the older tool chain? The most recent one creates over sized files, which was the problem I had.

[Per Hansson]

I am using the older toolchain, avr-gcc v4.8.2 is the same that stj uses. (I think he is on Windows though).
My files are identical in size to stj's.
The issue is that the newer code simply take up a bit more space.

[vinceroger69]

Originally Posted by Per Hansson

If you want to try Markus (Madires) firmware on the GM328R it is attached here in 8, 16 & 20Mhz versions.
(I have only tested 16Mhz).
But please note the caveats I encountered:
http://www.eevblog.com/forum/testgea...53/#msg1266553

Thanks i was reading that thread too and did see your posts im suprised no one on there cant sort the issue your having out with the markus firmware hopefully stj will be able too sort his firmware out so its smaller etc

[stj]

i'm not on windows.
i was using the windows toolchain on wine though.

[redwire]

The compiler might have an optimization flag turned off.
That can reduce the output file size.
Does anyone have the compiler command line to look at.

[Per Hansson]

I have compiled the latest SVN version of Karl-Heinz firmware now.
As base I have used stj's Makefile from here.
I have only changed the type of font used in the Makefile.
Instead of "DFONT_7X12" I am using "DFONT_8X8"
This allows the firmware to compile:

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

Program:   32352 bytes (98.7% Full)
(.text + .data + .bootloader)

Data:        206 bytes (10.1% Full)
(.data + .bss + .noinit)

EEPROM:      914 bytes (89.3% Full)
(.eeprom)

Here is a screenshot of how it looks:

IMO it is much better with this font because the previous ones that stj used
Which were both bold and not bold resulted in much less info on the screen as seen here:
http://www.badcaps.net/forum/showpos...&postcount=446

EDIT: redwire, I have attached the compiler output as a zipfile.

[jondoe]

That font certainly looks nice and readable.

[stj]

i had a discusion with vince about that, nice fonts vs more info on screen.

btw, you shouldnt use old makefiles.
you should copy the settings in them to the new makefile.
because the new makefile can contain extra options or critical changes.

[Per Hansson]

Originally Posted by stj

i had a discusion with vince about that, nice fonts vs more info on screen.

Well you had with me too.
That's why I put in the links I did in my post above.
But actually both "DFONT_7X12" that you have used in the latest makefiles.
And "DFONT_8x15" that I wrote that I liked.
They resulted in 3 scrolling lines of text when testing that Mosfet:

Originally Posted by Per Hansson

I understand what you say, but for example in this post I showed the bold font testing an, as you put it:
"fet or a transistor with reverse-diode in it and see how much text it has to display!"
Well the small font is the same, it also has to scroll through three pages to show all the info so it does not seem better to me?

Originally Posted by stj

btw, you shouldnt use old makefiles.
you should copy the settings in them to the new makefile.
because the new makefile can contain extra options or critical changes.

I know, but I compared the Makefiles.
The only addition in the new Makefile is the description of a new option for the UART
And then the complete removal of this section:

# Enable contrast menu option
CFLAGS += -DWITH_CONTRAST

But the option was still there after compiling the firmware so probably it was just made mandatory.

[stj]

oops,

i removed that and hard coded the contrast-value to save memory.
be a bastard if the menu option is hard coded in the driver now.

[Per Hansson]

I updated the ZIP above in post #767 with the 8Mhz build now as well.
I also updated the makefile, I did a before and after check and the 16Mhz output file was identical to that I built yesterday.

A question for stj, the value BAT_OUT is 150 by default.
On my tester after the 9v battery sits a A673
You have changed it to 3, what does that signify?

# The BAT_OUT option enables Battery Voltage Output on LCD (if BAT_CHECK is selected).
# If your 9V supply has a diode installed, use the BAT_OUT=600 form to specify the
# threshold voltage of your diode to adjust the output value.
# This threshold level is added to LCD-output and does not affect the voltage checking levels.
CFLAGS += -DBAT_OUT=3

And here is from the PDF:

BAT OUT enables Battery Voltage Output on LCD (if BAT CHECK is selected). If your 9V
supply has a diode installed, use the BAT OUT=600 form to specify the threshold voltage (mV)
of your diode to adjust the output value. Also the voltage loss of transistor T3 can be respected
with this option. threshold level does not affect the voltage checking levels (BAT POOR).
Example 1: CFLAGS += -DBAT OUT=300
Example 2: CFLAGS += -DBAT OUT

P.S: I have changed my TL431 with a LM4040 and the VCC displayed at poweron is: 5.03v

[Per Hansson]

Posted this on eevblog, reposting here.
Here is how to setup a build environment on CentOS7 or RHEL7 (Red Hat Enterprise Linux)
In the optional repository EPEL we have already avr for our purposes.
The version provided is avr-gcc 4.9.2 which unfortunately produces files that are a little bigger than the previous release.
So if you are not on the limit size wise this version will work fine, but if not read on.

So since an older version is not available for CentOS7 on EPEL we have to try to find one.
Looking around we can see that for Fedora 19 avr-gcc 4.8.2 was released.
This is perfect because Fedora 19 is the same baseline system as RHEL7.
So login as a standard user on your Centos7 or RHEL7 machine and lets rebuild this source RPM:

wget http://archive.fedoraproject.org/pub/archive/fedora/linux/updates/19/SRPMS/avr-gcc-4.8.2-2.fc19.src.rpm
wget http://archive.fedoraproject.org/pub/archive/fedora/linux/releases/19/Everything/source/SRPMS/a/avr-libc-1.8.0-4.fc19.src.rpm

rpmbuild --rebuild avr-gcc-4.8.2-2.fc19.src.rpm
rpmbuild --rebuild avr-libc-1.8.0-4.fc19.src.rpm

su root -c "rpm -ivh /home/per/rpmbuild/RPMS/x86_64/avr-gcc-4.8.2-2.el7.centos.x86_64.rpm /home/per/rpmbuild/RPMS/noarch/avr-libc-1.8.0-4.el7.centos.noarch.rpm"

Replace /home/per with your user used for building.
Happy building

[stj]

the bat-out value is to counteract voltdrop through diodes & stuff.

[vinceroger69]

Originally Posted by Per Hansson

I have compiled the latest SVN version of Karl-Heinz firmware now.
As base I have used stj's Makefile from here.
I have only changed the type of font used in the Makefile.
Instead of "DFONT_7X12" I am using "DFONT_8X8"
This allows the firmware to compile:

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

Program:   32352 bytes (98.7% Full)
(.text + .data + .bootloader)

Data:        206 bytes (10.1% Full)
(.data + .bss + .noinit)

EEPROM:      914 bytes (89.3% Full)
(.eeprom)

Here is a screenshot of how it looks:

IMO it is much better with this font because the previous ones that stj used
Which were both bold and not bold resulted in much less info on the screen as seen here:
http://www.badcaps.net/forum/showpos...&postcount=446

EDIT: redwire, I have attached the compiler output as a zipfile.

thanks i will update both of my testers next week is there any diffrence in calibrating the unit? as ive read somewhere about measuring a capacitor 3 times does this apply too this firmware version many thanks

[Per Hansson]

Originally Posted by vinceroger69

is there any diffrence in calibrating the unit? as ive read somewhere about measuring a capacitor 3 times does this apply too this firmware version many thanks

That only applies to Markus (Madires) firmware that I posted earlier.

Originally Posted by stj

the bat-out value is to counteract voltdrop through diodes & stuff.

How/where to measure this?
The manual does not go into any detail on the subject.
And does it matter at all when the 2.5v precision regulator is installed?

[stj]

it's for battery status at power-up.
the original large value was because the original hardware had a 1n4007 inline with the power - big voltdrop of upto 1,4v on those!

[redwire]

The on/off switch transistor and reverse-polarity protection have some voltage drop.
Because the battery voltage-monitoring is upstream of these, I think BAT_OUT is a correction factor (in mV). Measure voltage drop from BAT+ to the battery sense resistor (10k) and use this number.

Some testers have mosfets or transistors or a diode on input power, so each has different voltage losses.

[Per Hansson]

Thanks for the explanation, now even I get it!
I used a bench PSU to power it and measured the voltage at the sense resistor.
The drop is ca 45mV according to two meters.
I put in 50mW for BAT_OUT

[stj]

test it, put a meter across the battery and compare it to the value displayed at power-on
that's how i finetune'd it for the gm328 hardware.