I want to thank Markus for the superb job he`s done with the firmware, and specially thank him for supporting all the hardware that others have developed around his initial project. He's done such a great work, I don't even care about losing 7x1 to Germany!
Everything is in config.h
I'm having a problem with some random pixels now. They don't appear with the 'K' FW.
LCR-TC now in color, and shall probably sell for 50usd on ebay. Not an owner yet, I can't show more.
That modified firmware has nice graphics. Unfortunately the author doesn't provide the source code and ignores that the firmware is open source. But we have color support too. And I think I'm able to add touch screen support for an ATmega 664/1284 version.
Uncomment
#define HW_REF25
avrdude -c arduino -p m328p -P /dev/tty.usbserial -b 19200 -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h -U lock:r:-:h
avrdude: Device signature = 0x1e950f
avrdude: reading lfuse memory:
0xf7
avrdude: reading hfuse memory:
0xd9
avrdude: reading efuse memory:
0x4
avrdude: reading lock memory:
0x3f
avrdude: safemode: Fuses OK (H:04, E:D9, L:F7)
avrdude -P /dev/tty.usbserial -c arduino -p m328p -b 19200 -B 20 -U lock:w:0xff:m
avrdude: reading input file "0xff"
avrdude: writing lock (1 bytes):
Writing | | 0% 0.00s ***failed;
Writing | ################################################## | 100% 0.16s
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0xff:
avrdude: load data lock data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip lock data:
Reading | ################################################## | 100% 0.02s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x3f != 0xff
avrdude: verification error; content mismatch
avrdude -P /dev/tty.usbserial -c arduino -p m328p -b 19200 -B 20 -U efuse:w:0xFC:m
avrdude: reading input file "0xfc"
avrdude: writing efuse (1 bytes):
Writing | | 0% 0.00s ***failed;
Writing | ################################################## | 100% 0.16s
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xfc:
avrdude: load data efuse data from input file 0xfc:
avrdude: input file 0xfc contains 1 bytes
avrdude: reading on-chip efuse data:
Reading | ################################################## | 100% 0.02s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x04 != 0xfc
avrdude: verification error; content mismatch
Writing the lock byte fails and setting the efuse fails too.
Since this kit came with 3% regulator, and only 1% reference, this option probably won't make a significant difference.
The unit is able to do opto-coupler testing. And for the unit to know the "opto-coupler" testing mode, an adapter board need to be attached before powering on. The various parameters of the coupler are displayed after testing, including the CTR. Is this a possibility for the your software?
Writing the lock byte fails and setting the efuse fails too.
It's a problem of undefined bits. For example, the value FC for efuse set this bits to '1' and value 04 set this undefined bits to '0'. Depending on the target device these fuse bits will be read either as '0' or '1'. Therefore, it may cause errors in verification. This same applies to the lock bits, because the upper two bits in the byte are unused.
Note:
I have not noticed the other problems - I recommend updating the program AVRDUDE.
My first tester is from a French company, MW Instruments, now defunct. The unit is able to do opto-coupler testing. And for the unit to know the "opto-coupler" testing mode, an adapter board need to be attached before powering on. The various parameters of the coupler are displayed after testing, including the CTR. Is this a possibility for the your software?
Writing the lock byte fails and setting the efuse fails too.It's a problem of undefined bits....
I recommend updating the program AVRDUDE.
I had the same problem, but only when using the latest version of avrdude.exe ... When using the version of avrdude (.exe and .conf ) that comes with Arduino 1.6.7, I have absolutely no problems...
The voltage reference is a TL431A that should be 2% and the critical resistors at the inputs are 0.1% not 1% as all the others on the board. It will not change the world but it is better
Code: [Select]avrdude -c arduino -p m328p -P /dev/tty.usbserial -b 19200 -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h -U lock:r:-:h
avrdude: Device signature = 0x1e950f
avrdude: reading lfuse memory:
0xf7
avrdude: reading hfuse memory:
0xd9
avrdude: reading efuse memory:
0x4
avrdude: reading lock memory:
0x3f
avrdude: safemode: Fuses OK (H:04, E:D9, L:F7)
That last line worries me because it contradicts the read fuse values. Is that a bug in AVRDUDE?
My kit came with a "Wing Shing" brand 431 reference. Grade A = 1%
there's no significant improvement from enabling #define HW_REF25, unless the reference is 10x more precise.
I plan to order some MCP1702's, so the 431 will be useless anyway.
My first tester is from a French company, MW Instruments, now defunct. The unit is able to do opto-coupler testing. And for the unit to know the "opto-coupler" testing mode, an adapter board need to be attached before powering on. The various parameters of the coupler are displayed after testing, including the CTR. Is this a possibility for the your software?
Could be. I have to check if it's feasable.
After reading a few datasheets of opto couplers I think the CTR could be measured with some caveats.
After reading a few datasheets of opto couplers I think the CTR could be measured with some caveats. The main problem is current. Considering the LED's voltage drop the tester could drive it with about 5mA using Rl (680 Ohms). But the collector curent will become a problem, since the tester can't provide more than 7mA in a safe way. Though, we could overload the MCU's pin briefly. So an external test adapter with an additional current limiting resistor for the LED (aiming for 1mA) could solve that issue. Or a second resistor for the collector, i.e. the MCU provides full current limited by its internal resistance and the additional resistor limits the maximum current to some acceptable value. Or maybe both to support also couplers with a darlington output stage. But the optimal LED current seems to be around 5-10mA. Either we'd have an optimal LED driver current and a CTR range of maybe up to 500% or a not so ideal drive current and a CTR range of up to 5000%. Any suggestions?
Not bad for a PASS/FAIL test and the measured "hFE" gives a reasonable indication of the order of magnitude of the CTR.
Two pages from the MW tester, one is the base circuit, and one of the opto-coupler test adapter. I hope many more type of opto-coupler can be tested, as more and more are using those with built-in drivers.
@speedy29
Attached zip file contains the original firmware for Fish8840. It is of course possible to use the k-version software from the SVN repository (directory mega328_fish8840).
Fuse settings fot M328P:
lfuse:0xf7 hfuse:0xd9 efuse:0x04 (0xfc)