bei meinem Hiland M644 scheint ein anderer Drehgeber verbaut? Ich mußte die Zuordnung der Pins A,B in der 1.41m vertauschen.
> Der Huddelstatus, wenn er denn existiert ...
Da kann man sich drauf verlassen, dass der existiert. Man schaue sich
nur die Software an: unübersichtlich, wartungsfeindlich und voll mit
'defines' vollgemüllt.
name schrieb: > bei meinem Hiland M644 scheint ein anderer Drehgeber verbaut? Ich mußte > die Zuordnung der Pins A,B in der 1.41m vertauschen. Passt schon. ;) Aus dem CHANGES.de für 1.40m: Die Erkennung der Drehrichtung in ReadEncoder() war umgedreht. Auf korrekte Richtung geändert und Einstellungen in config_<MCU>.h und Clones aktualisiert.
:
Bearbeitet durch User
Markus R. schrieb: > name schrieb: >> bei meinem Hiland M644 scheint ein anderer Drehgeber verbaut? Ich mußte >> die Zuordnung der Pins A,B in der 1.41m vertauschen. > > Passt schon. ;) Aus dem CHANGES.de für 1.40m: danke. Auch bei 1.42m : Selbsttest ok, aber Calibrierung endet mit Fehler
Der Selbsttest misst primär die Testpins, um mögliche Fehler oder Probleme aufzuzeigen. Er bewertet nicht die Werte nach gut oder schlecht. Daher ist er immer erfolgreich, außer er wird am Anfang abgebrochen. Nun zum Selbstabgleich. Könntest Du bitte die Werte, die am Ende vom Selbstabgleich angezeigt werden, posten?
Du meinst nur das hier: Ri- 20.1 Ohm Ri+ 23.3 Ohm C0 35pF R0 1.19 1.25 -nächste Seite- 1.19 Ohm Vref 1095mV Vcc 4963mV * AComp 0mv -nächste Seite- Fehler!
Der Widerstandsoffset R0 für die Testpinpaare ist recht hoch. Kontaktprobleme? Hast Du vor dem Selbstabgleich einen Folienkondensator (100nF-2µF) dreimal gemessen?
alternativ 3 mal 100nF gemessen; danach Selbstabgleich -> R0 1.19 1.25 1.20 Ohm Rest unverändert
nochmal mit angelöteten Testkabeln: - 3 x 100nF - Abgleich -> R0 0.25 0.22 0.33 Ohm --> Fehler
Liegt beim Selbstabgleich ein Wert deutlich neben den anderen? Bei jedem Parameter wird fünfmal gemessen und angezeigt.
Markus R. schrieb: > Liegt beim Selbstabgleich ein Wert deutlich neben den anderen? Bei jedem > Parameter wird fünfmal gemessen und angezeigt. - 3 x 100nF gemessen, dann - Abgleich: A1 Vref AComp 0mV 0mV / 5 mal A2 R0 12 13 23 32 22 32 28 26 28 29 28 29 29 21 31 28 23 34 (A3) entferne Kurzschluss A4 Ri- 138 138 138 138 138 138 139 138 138 138 138 138 139 138 138 A5 Ri+ 160 160 160 161 160 160 160 160 160 160 160 160 A6 C0 12 13 23 57 54 55 58 54 55 58 54 55 57 54 55 58 54 55 Ri- 20.1 Ohm Ri+ 23.3 Ohm C0 55pF R0 0.29 0.24 0.30 Ohm Vref 1095mV Vcc 4962mV * AComp 0mV Fehler!
name schrieb: > A1 Vref AComp > 0mV 0mV / 5 mal Ah, Du hast den festen Abgleichkondensator aktiviert. Dann brauchst Du vorher keinen Folienkondensator dreimal messen. Allerdings läuft beim festen Abgleichkondensator etwas schief. Dass die Offsets Null sind, wäre sehr ungewöhnlich. Vielleicht passen die Einstellungen zum Abgleichkondensator in config_644.h nicht. Ansonsten könntest Du auch HW_ADJUST_CAP deaktivieren.
... manchmal ist es hilfreich, den Wert des Abgleichkondensators auf > 100 nF, z.B. 220 nF (Folie) zu ersetzen. Bei meinen beiden TC1/T7 und auch dem Hiland 644 lagen die verbauten 100 nF alle deutlich unter dem Sollwert. Gruß Horst
Markus R. schrieb: > Ansonsten könntest Du auch > HW_ADJUST_CAP deaktivieren. dann funktionierts. > Vielleicht passen die Einstellungen zum > Abgleichkondensator in config_644.h nicht. #define TP_CAP PA7 /* test pin for self-adjustment cap */ #define ADJUST_PORT PORTC /* port data register */ #define ADJUST_DDR DDRC /* port data direction register */ #define ADJUST_RH PC5 /* Rh (470k) for fixed cap */ wo auf der Platine sollte denn dieser Abgleichkondensator sein? Oder wonach könnte ich suchen?
name schrieb: > #define ADJUST_RH PC5 /* Rh (470k) for fixed cap */ > > wo auf der Platine sollte denn dieser Abgleichkondensator sein? Oder > wonach könnte ich suchen? ... Rh -> R23 ADJUST_CAP -> C8 Ändere #define ADJUST_RH PC5 /* Rh (470k) for fixed cap */ auf #define ADJUST_RH PC6 /* Rh (470k) for fixed cap */ Gruß Horst
:
Bearbeitet durch User
Horst O. schrieb: > Ändere auf > #define ADJUST_RH PC6 /* Rh (470k) for fixed cap */ das hat geholfen. In dem von mir genutzten Hiland-M644-de_manual.pdf steht dazu noch nichts. Ist die aktuellste Hardware-Anpassung oder -beschreibung in der Datei Clones zu finden? Danke.
... der Teil der Clones-Datei, welche sich mit der Anpassung des Hiland644 beschäftigt, ist seit der CT-m-1.36 unverändert. Gruß Horst
Mir fehlen einige digitale Funktionen fuer RC-Modellfrickler. Der urspruengliche Fokus des Transistortester sind ja eher analoge/diskrete Bauelemente. Wenn also eine Erweiterung fuer RC-Modellfrickler nicht gewuenscht ist, dann einfach sagen und ich machs dann einfach so fuer mich. Zuerst moechte ich einen ServoTest fuer Heli-Heckservos hinzufuegen. (Die haben einen pwm Range [ 500, 760, 920 ]us @ 560Hz. Motivation: Der normale Servo-Range ist [ 1000, 1500, 2000] @ <=333Hz. Im schlimmsten Fall macht der normale Servo Centerwert von 1500us das Heli-Servo schon kaputt. Aus dem bestehenden SERVO Code kann ich natuerlich den zusaetzlichen Test Code ableiten. Dann koennte ich einen udiff anbieten, damit das in den trunk findet. Ist das hier das uebliche Vorgehen oder wie sonst? Ausserdem moechte ich die Darstellung im Modus PWM-Output soweit ergaenzen, dass neben der %-Angabe auch die Laenge des High-Anteils in us steht. Zuletzt fehlt mir noch ein PWM Analysemodus, der zu einem Input PWM Signal die Frequenz [Hz] und Wert (%-Wert und Laenge des High-Anteils in us) ausgibt.
hamburger schrieb: > Mir fehlen einige digitale Funktionen fuer RC-Modellfrickler Na dann los. Programmiere einfach das fehlende.
hamburger schrieb: > Mir fehlen einige digitale Funktionen fuer RC-Modellfrickler Na dann los. Programmiere einfach das fehlende. ?...
hamburger schrieb: > Dann koennte ich einen udiff anbieten, damit das in > den trunk findet. Ist das hier das uebliche Vorgehen oder wie sonst? > > Ausserdem moechte ich die Darstellung im Modus PWM-Output soweit > ergaenzen, dass neben der %-Angabe auch die Laenge des High-Anteils in > us steht. die Zeiten fuer - 1 Cycle, - den High-Anteil stehen dann in der neuen Zeile 4
Hi, in der Revision 857 werden nur Hieroglyphen angezeigt, wenn die Sprache auf Deutsch eingestellt ist, English funktioniert. In der vorherigen Revision geht auch Deutsch. Hardware ist Hiland M644. Uwe
Uwe S. schrieb: > ist Hiland M644 ... davon ist nicht nur der Hiland betroffen und auch nicht nur DEUTSCH, auch andere Display-Versionen an versch. Tester-Nachbauten haben Anzeige-Probleme bei unterschiedlichen Font-Abmessungen. Beispielsweise der kleinste Font bringt bei meinem Compiler jedesmal Fehlermeldungen, die dann zum Abbruch des Compilierens führen. Scheint bei der REV 857 (Reorganisation of Fonts) eventuell was "schief gelaufen" zu sein? Gruß Horst
:
Bearbeitet durch User
Horst O. schrieb: > Scheint bei der REV 857 (Reorganisation of Fonts) eventuell was "schief > gelaufen" zu sein? Ja, da ist etwas schiefgelaufen. Einerseits sollte beim kyrillischen Font etwas Platz eingespart werden und außerdem sollten die Sonderzeichen von einigen Sprachen unterstützt werden. Es sollte jetzt schon besser funktionieren. Die Sonderzeichen werden für die Grafik-Displays noch nicht bei allen Fonts unterstützt. Wenn noch etwas auffällt, bitte melden. Die Reihenfolge der Menü-Unterpunkte kann jetzt leichter geändert werden. Es gibt zwei Beispiele (function_sequence1.h und function_sequence2.h), die am Ende der autoconf.h Datei ausgewählt werden können. Außerdem ist es jetzt leichter, Menüpunkte wegzulassen.
Hallo Karl-Heinz, ... hier mal die Zusammenfassung des Font-Tests Rev. 857: # If option WITH_LCD_ST7565 is present one of the following fonts should be # choosen. With a font width below 8 more than 16 characters can be shown in one display line. # Engl Germ #CFLAGS += -DFONT_5X8 Comp_Crash! Comp_Crash! #CFLAGS += -DFONT_6X8 OK! OK! #CFLAGS += -DFONT_8X8 OK! OK! #CFLAGS += -DFONT_7X12 OK! Font ist richtig, zeigt aber "MÜLL" #CFLAGS += -DFONT_8X12thin OK! Font ist richtig, zeigt aber "MÜLL" #CFLAGS += -DFONT_8X14 OK! Font ist richtig, zeigt aber "MÜLL" #CFLAGS += -DFONT_8X15 OK! Font ist richtig, zeigt aber "MÜLL" #CFLAGS += -DFONT_8X16 OK! Font ist richtig, zeigt aber "MÜLL" #CFLAGS += -DFONT_8X16thin OK! OK! Karl-Heinz K. schrieb: > Die Reihenfolge der Menü-Unterpunkte kann jetzt leichter geändert > werden. Es gibt zwei Beispiele (function_sequence1.h und > function_sequence2.h), die am Ende der autoconf.h Datei ausgewählt > werden können. Außerdem ist es jetzt leichter, Menüpunkte wegzulassen. ... in der autoconf.h kann man weder die function_sequence1.h noch die function_sequence2.h auswählen und die Dateien sind auch nicht im "trunk" Vezeichnis vorhanden? Gruß Horst
:
Bearbeitet durch User
Zwei Fehler tauchen beim Compilieren auf, wenn die automatische Kalibrierung aus ist.
1 | #CFLAGS += -DAUTO_CAL
|
Sie sind aber leicht zu beheben. In CheckPins.c zwei Zeilen ändern: 391:
1 | i16 = (unsigned int)(((unsigned long)adc.lp2 * 10000) / RRpinMI); // Idss 1uA, with pin_rmi: error without calibration |
498:
1 | i16 = (unsigned int)(((unsigned long)adc.hp3 * 10000) / RRpinPL); // Idss 1uA, with pin_rpl: error without calibration |
MfG. Andreas
Horst O. schrieb: > ... in der autoconf.h kann man weder die function_sequence1.h noch die > function_sequence2.h > > auswählen und die Dateien sind auch nicht im "trunk" Vezeichnis > vorhanden? Die Dateien sollten aber ab SVN-Version 858 im trunk Verzeichnis vorhanden sein.
Karl-Heinz K. schrieb: > Die Dateien sollten aber ab SVN-Version 858 im trunk Verzeichnis > vorhanden sein. ... hatte direkt nach Deinem Beitrag um 12.50 Uhr nach neuen Rev. geschaut, aber keine gefunden. Später dann waren 858 und 859 verfügbar und das Font-Problem gelöst! Vielen Dank, Gruß Horst
:
Bearbeitet durch User
hamburger schrieb: > hamburger schrieb: >> Ausserdem moechte ich die Darstellung im Modus PWM-Output soweit >> ergaenzen, dass neben der %-Angabe auch die Laenge des High-Anteils in >> us steht. > > die Zeiten fuer > - 1 Cycle, > - den High-Anteil > stehen dann in der neuen Zeile 4 Habe die Anzeige der Pulslänge als Option in beide PWM-Generatoren eingebaut, wobei die Pulslänge hinter dem Tastverhältnis steht und auf der jeweiligen Zeitauflösung des Timers basiert.
Markus R. schrieb: > Habe die Anzeige der Pulslänge als Option in beide PWM-Generatoren > eingebaut, wobei die Pulslänge hinter dem Tastverhältnis steht und auf > der jeweiligen Zeitauflösung des Timers basiert. fein. Ist der Sourcecode schon irgendwo zu sehen? Ich wuerde mich daran orientieren fuer naechste Schritte - damit Du nicht alle meine Erweiterungen nochmal neu schreiben musst.
Wenn Du mir eine Email schickst, kann ich Dir gerne eine Beta-Version zukommen lassen.
Ich hab mal meine Version auf den letzten SVN-Stand rebased. Besteht denn eine Chance meine Änderungen übernommen zu bekommen? Andernfalls würde ich meinen Fork gelegentlich rebasen um einen für mich nutzbaren Stand zu bekommen. https://github.com/M-Reimer/transistortester/commit/91af83a7317ef95e5a1dc94114a9e0fdfb42ae99 https://github.com/M-Reimer/transistortester/commit/1cf8dacbe1e46b0a82d9fef707b56841f3353983 Die zweite Änderung ist für "ergonomische Nutzung" des "BSIDE ESP02 Pro" relativ wichtig, weil es nur drei Steckpunkte für die drei Anschlüsse gibt. Je nachdem welche Abmessungen der zu messende Kondensator hat eignen sich entweder die beiden äußeren oder ein äußerer und der innere Anschluss besser zum Messen. Nur durch die Anschlusswahl will ich aber nicht in den "Dauer-Kondensatortest" fallen. Wenn nicht gewünscht das der "automatische Dauertest" generell aus ist wenn ein Menü aktiviert ist, dann braucht es dafür halt noch ein eigenes Define.
!! Achtung SVN ist nich mehr benutzt !! aktuele Stand nur auf https://github.com/Mikrocontroller-net/transistortester !!
Hi all, I have a SSM85T03h from the datasheet it says (rds on 6mΩ), but in my 112k version transistortester, mida 0.4Ω, how is it possible, such a difference?
MisterGNZ schrieb: > Hi all, I have a SSM85T03h from the datasheet it says (rds on 6mΩ), but > in my 112k version transistortester, mida 0.4Ω, how is it possible, such > a difference? Hi MisterGNZ, This difference comes mostly from the fact that, according to the datasheet, Rdson is measured with a gate voltage of 10 V at a drain current of 45 A (!). Clearly, the transistor tester can't handle such values, because voltages from the test pins are limited to 5 V and currents to a few mA. On top of that, the resistance of the elements of your measuring circuit, like test leads, contacts and so on, will almost certainly be already well over 6 mΩ. Measuring a short piece of wire with my tester gives me 20 mΩ. By the way, have you calibrated your tester? Greetings, derri.
Здравствуйте уважаемые разработчики транзистор тестера!!! Скажите пожалуйста вышла ли новая прошивка для дисплея ST7920???
Ivan schrieb: > Hallo liebe Entwickler Transistor Tester!!! > Bitte sagen Sie mir, ob die neue Firmware für das Display ST7920???
45 69 6e 20 42 6c 69 63 6b 20 69 6e 20 64 69 65 20 4b 6f 6e 66 69 67 20 44 61 74 65 69 20 6f 64 65 72 20 64 69 65 20 44 6f 6b 75 20 64 fc 72 66 74 65 20 68 65 6c 66 65 6e 2e 2e 2e 3f Klaus.
Hello everyone, for those who want to change the tl431, on the transistor tester, it can be found on a bosch charger that does not work gal-1880-cv, it is located on the cold part pcb, marked GA1 smd sot23, tolerance 0.4%, I am attaching the pdf datasheet, and the photo of the pcb, with the GA1 component indicated.
Pavel K. schrieb: > !! Achtung SVN ist nich mehr benutzt !! aktuele Stand nur auf > https://github.com/Mikrocontroller-net/transistortester !! Da meine bisherigen Antworten weitgehend ignoriert wurden wird das vermutlich auch niemanden jucken, aber das ihr die Binaries auf GIT habt werdet ihr früher oder später bereuen. GIT ist extrem schlecht im Verwalten von Binaries und wenn jemand das Repo neu klont, dann holt er mal eben jeden Binary-Stand der jemals hochgeladen wurde. Wenn man schon GitHub mit allen seinen Möglichkeiten hat, dann wäre Continuous Integration mit z.B. TravisCI deutlich sinnvoller. Soll heißen: Bei jedem Push auf das Repo könnte Travis ganz automatisch die Binaries bauen und z.B. via GitHub Pages direkt hosten. Mache ich z.B. hier: https://github.com/VDR4Arch/vdr4arch Nur das ich dort ein komplettes Arch Linux-Repository von Travis bauen lasse.
Ivan schrieb: > Ivan schrieb: >> Hallo liebe Entwickler Transistor Tester!!! >> Bitte sagen Sie mir, ob die neue Firmware für das Display ST7920??? Hallo Ivan, sowohl K-Software als auch M-Software unterstützen Dein Display ST7920!!! the K-Software and the M-Software too are supported Your Display ST7920!!! Gruß Horst
Apollo M. schrieb: > soll das english sein?! ... wenn Du sonst keine Frage hast, nein, es ist natürlich russisch. Gruß Horst
Hihi schrieb: > Ist es eigentlich egal, wie man Elkos (Polung) in die Messkontakte > steckt? Ja, das ist egal! Bei den Tests hat sich keine Differenz der Meßergebnisse ergeben. Für die eigentliche Messung wird der Kondensator nur bis max 1.1V geladen. Bei großen Kapazitäten ist die Meßspannung noch deutlich geringer. Die Polarität scheint erst bei höheren Spannungen und längerer Betriebszeit eine Rolle zu spielen.
Hi all, I have T41080 TRIAC 800V 4A - DPAK, but my transistor tester, tells me it's a scr, does anyone know why ?. Thanks in advance
atmega328p fuses: low E2, high D9, Ext FC, do you think they are good? Greetings .. Ignatius
MisterGNZ schrieb: > Hi all, I have T41080 TRIAC 800V 4A - DPAK, but my transistor tester, > tells me it's a scr, does anyone know why ?. Probably the testing current of the tester is too low for detecting the TRIAC. This tester can only detect low power TRIACS doe to the low measurement current of about 6mA.
Hi Karl-Heinz K., thanks for the answer, now everything is clear to me, what do you think about my atmega328p fuses: low E2, high D9, Ext FC?
MisterGNZ schrieb: > Hi Karl-Heinz K., thanks for the answer, now everything is clear to me, > what do you think about my atmega328p fuses: low E2, high D9, Ext FC? Your fuse settings depend on your hardware. My settings for the standard schematic and a 16 MHz crystal are as follows: low:F7, high:DF, ext:F9. Mind that with low:E2 you set the clock source to the internal RC oscillator at 8 Mhz. This is not suitable for the SamplingADC method used to measure small capacitors. Please see also https://www.engbedded.com/fusecalc for details. On the other side, if you set the clock source to an external source or crystal, you will not be able to program the chip afterwards in ISP mode without a clock source applied, but only in-circuit with a crystal connected. Greetings, derri
Thanks for this great project! I bought a tester like this (labelled GM328A) years back but was unaware it was based on an open source project. I'd like to upgrade to the newest firmware just for the heck of it. I've downloaded all of the GIT and searched here but I've been unable to find help in identifying what exactly I have here and which of the many variants and precompiled hexes is right for me. (e.g. what screen is that?!) The best I could find is a mention of the GM328 in the ttester.pdf and warnings about it having a short on PD5. But it also mentions a daughter board and I don't believe that is what I have? Your help would be much appreciated. It is certainly not the newest hardware revision but I would assume it to have been widespread in the past? Vielen Dank! Hajo
you have a newer SMD version from GM328A+ look at your quartz whether 8 or 16Mhz version! https://yadi.sk/d/yW8xa5NJgUo5z/GM328(A%2B) https://yadi.sk/d/yW8xa5NJgUo5z
:
Bearbeitet durch User
Hi Derri, thanks for the advice, I changed the 8mhz quartz with a 16mhz one, fused f7, df, f9, then I calibrated the transistortester, it works but it gives me double results, example 100nf gives me 200nf, any advice ?. my sw is 112k, lcd 16x2, no encoder
MisterGNZ schrieb: > example 100nf gives me 200nf, any advice > ?. You can not change the quartz without recompiling the software. There is no way for the software to find out the operating frequency. You must set the OP_MHZ option in the Makefile correctly and recompile the source.
Hi Karl-Heinz K., thanks for the advice, I changed the makefile, from 8 to 16mhz, I recompiled and programmed the atmega328p, and everything worked, I'm sorry but I'm not a programmer, without your help, I would not have succeeded to make nothing work. Greetings Ignatius
Markus R. schrieb: > Wenn Du mir eine Email schickst, kann ich Dir gerne eine > Beta-Version zukommen lassen. mail angekommen? Ich habe die Beta-Version noch nicht gesehen, solange ruhen meine Erweiterungsversuche. Gruesse,
R. H. schrieb: > ist darüber irgendwo irgend etwas dokumentiert ? Hallo snapper, ... habe mal im Anhang einen Auszug aus der "CloneTester"-Übersicht hochgeladen, könnte ev. zu Deinem Tester passen? Es existieren leider untersch. Versionen. Viel Erfolg, Gruß Horst
Horst O. schrieb: > ... habe mal im Anhang einen Auszug aus der "CloneTester"-Übersicht > hochgeladen, könnte ev. zu Deinem Tester passen? Es existieren leider > untersch. Versionen. > > Viel Erfolg, Gruß Horst ... oh, mein Fehler, war eigentlich für Hajo Piltz bestimmt. Gruß Horst
Horst O. schrieb: > ... oh, mein Fehler, war eigentlich für Hajo Piltz bestimmt. war eh überflüssig, das gleiche hatte ich schon am 13.3. gepostet!
Hallo snapper, hallo Horst, vielen Dank für die Links / Attachments, damit müsste es mir jetzt eigentlich gelingen! Hajo
weis denn hier niemand etwas über die Verwendung von TVS Dioden als Schutz der Messports ?
R. H. schrieb: > weis denn hier niemand etwas über die Verwendung von TVS Dioden als > Schutz der Messports ? Hallo R. H. ... durch Lesen der Dokumentation zum Tester (von Karl-Heinz und Markus) wissen die meisten Anwender dieses Gerätes, es gibt keinen echten Schutz der Messeingänge gegen Überspannung. Daher auch immer wieder der Hinweis: vor Messung von Kondensatoren diese zuerst Entladen! Doku Karl-Heinz --> Kap. 2.2.1 https://github.com/Mikrocontroller-net/transistortester Gruß Horst
:
Bearbeitet durch User
Guten Morgen allerseits !! Dies ist mein erster Beitrag, daher begrüße ich alle herzlich. So ist es heute, wenn Sie im Internet nach einer Lösung suchen, wenn es ein Problem gibt. Ich habe einen Komponententester aus China gekauft und alles war in Ordnung. Aber als ich den Kondensator gemessen habe, ist der Prozessor kaputt gegangen und jetzt kann ich die Software nicht mehr an meine Version anpassen. Sie sind sehr nett, bitte helfen Sie mir, die Version anzupassen. Die Version verfügt über atmega 328p, tl431, ams1117-5V, Frequenzgenerator, Encoder und das Display ist monochrom LCM 12864 v1.30 Ich habe auch ein Programm aus dem Internet, aber es zeigt die Werte geteilt durch 2. Ich verwende TL866II Plus oder Wellon VP 988 für die Atmega-Programmierung. Ich bitte um ein gutes Programm für atmega 328p Vielen Dank
Tomek L. schrieb: > Die Version verfügt über atmega 328p, tl431, ams1117-5V, > Frequenzgenerator, Encoder und das Display ist monochrom LCM 12864 v1.30 > Ich habe auch ein Programm aus dem Internet, aber es zeigt die Werte > geteilt durch 2. > Ich verwende TL866II Plus oder Wellon VP 988 für die > Atmega-Programmierung. > Ich bitte um ein gutes Programm für atmega 328p Hallo Tomek, Es braucht noch ein paar weitere Informationen, um das Modell Deines Testers genauer zu bestimmen. Offenbar handelt es sich um eine Variante des GM328. Das lese ich in dem ZIP-File. Ich gehe davon aus, dass Du das File "ATMEGA328Pmiernik1.BIN" aktuell in Deinem Tester verwendest. Ist das richtig? - Stammt das File "ATMEGA328Pmiernik1.BIN" aus dem beschädigten Chip oder "aus dem Internet"? - Von wo genau hast Du dieses File heruntergeladen? - Wird das LCD korrekt angesteuert? - Ist es dieses File das Dir die zu kleinen Werte liefert? - Wie sind die Fuses des ATMEGA programmiert? - Welches ist die Frequenz deines Quarz? Dass die Werte durch zwei geteilt sind, kommt von einer falschen Taktfrequenz für den Mikrocontroller. Da muss die Software für die richtige Taktfrequenz neu kompiliert werden, oder die Fuses müssen anders gesetzt werden. Das TL866 sollte auch die *.hex Files aus dem Git-Repository brennen, wir müssen "nur" die richtige Variante der Firmware herausfinden. Der springende Punkt ist der Display-Controller, und da bin ich bisher nicht fündig geworden. Gruß, derri
Beitrag #6636890 wurde vom Autor gelöscht.
Tomek L. schrieb: > Ich habe auch ein Programm aus dem Internet, aber es zeigt die Werte > geteilt durch 2. Die Ursache ist wahrscheinlich die falsche Taktfrequenz für dieses Programm. Normalerweise ist durch die Fuses des ATmega ein Quarzbetrieb eingestellt. Dann wäre das Programm für einen 16 MHz Quarz vorgesehen, installiert ist aber auf der Platine ein 8 MHz Quarz. Wenn auf der Platine doch ein 16 MHz Quarz installiert ist, sind die Fuses wahrscheinlich noch auf den internen RC-Takt ohne 8:1 Teiler eingestellt (8 MHz). Das Display hat mit hoher Wahrscheinlichkeit einen ST7565 Controller oder etwas kompatibles. So kann man wahrscheinlich auch die Programmdaten aus dem Software/trunk/mega328_st7565 Unterverzeichnis im git Archiv (https://github.com/mikrocontroller-net/transistortester) auch verwenden. (Voraussetzung ist natürlich, daß das Display so angeschlossen ist, wie in Standard beschrieben.) Da sind zwei Programm-Daten abgelegt, mega328_st7565.hex für den Flash-Speicher und mega328_st7565.eep für das EEprom. Beide müssen in den ATmega geladen werden und außerdem die Fuses richtig gesetzt sein (lfuse=0xf7, hfuse=0xd9, efuse=0xfc). Die Dokumentation zum Transistortester ist übrigens jetzt unter https://github.com/kubi48/TransistorTester-documentation in einem separaten Archiv.
Tomek L. schrieb: > Ich bitte um ein gutes Programm für atmega 328p Nachtrag: Hallo Tomek, Schau Dir doch bitte mal folgende Seiten an: https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg1025863/#msg1025863 https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg1021248/#msg1021248 Auf der letzteren ist ein Link zu einer passenden Software: https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/?action=dlattach;attach=253819 Zusammen mit den Tipps von Karl-Heinz solltest Du Dein Gerät damit zum Laufen bringen. Du musst die Fuses setzen wie im angehängten Bild (Leider besitze ich nur ein älteres TL866A, da kann die Bediensoftware etwas anders aussehen). Gruß, derri
Vielen dank für ihr Interesse !!! Die Datei "ATMEGA328Pmiernik1.bin" stammt wahrscheinlich aus China vom Verkäufer des Testers, aber die Testergebnisse, z. B. Kondensator, Widerstand zeigen geteilt durch 2. LCD funktioniert OK Der Quarzresonator ist 8 MHz FuseByte F7, D9, FC, FF Das ursprüngliche Programm befand sich im beschädigten 328, es ist unmöglich, es zu lesen. Chip 328 ist fehlerhaft. Ja, TL866 und Vellon programmieren BIN und HEX.
Tomek L. schrieb: >es ist unmöglich, es zu lesen. Chip 328 ist fehlerhaft. normalerweise wird da nur 1 Port zerstört, meistens ist das Lockbit gesetzt und verhindert das auslesen!
Tomek L. schrieb: > LCD funktioniert OK > Der Quarzresonator ist 8 MHz > FuseByte F7, D9, FC, FF Dann würde ich versuchen, den Chip mit den Files aus dem eevblog zu flashen (siehe Bild). Die Files sind zwar von 2016, aber als proof of concept geeignet. Sollte Dein Tester dann richtige Werte anzeigen, kann man daran gehen, eine aktuelle Version zu compilieren. Viel Erfolg! derri
Das Atmega 328 Original ist physisch beschädigt, es hat einen Kurzschluss in der Stromversorgung. Ich kann das Programm nicht von 16MHz auf 8MHz konvertieren :( Bitte helfen Sie mir bei der Überarbeitung.
Tomek L. schrieb: > Ich kann das Programm nicht von 16MHz auf 8MHz konvertieren bei EEVBLOG findest du doch auch die 8MHz Version, was ist jetzt dein Problem?
Tomek L. schrieb: > Ich kann das Programm nicht von 16MHz auf 8MHz konvertieren :( > Bitte helfen Sie mir bei der Überarbeitung. Hallo Tomek, Wenn ich Dich richtig verstehe, willst Du dein Programm "ATMEGA328Pmiernik1.bin" patchen, um es an 8-MHz Taktfrequenz anzupassen. Aus verschiedenen Gründen ist das kaum zu schaffen: - wir kennen die Version der Software-Sourcen nicht, - wir kennen die Compiler-Version nicht, mit der die Firmware erzeugt wurde, - wir wissen nicht, welche Optionen im Makefile beim Compilieren eingestellt waren. Es ist leider nicht so, dass man einfach irgendwo ein Byte mit dem Wert 16 auf 08 ändern müsste. Die Sache ist viel, viel, viel komplizierter. Auf der anderen Seite gibt es die Version "GM328x ESR tester (SVN684) - v2" aus dem eevblog. Nach den Fotos, die im Blog gezeigt werden, entspricht der Tester genau Deinem Exemplar. Im ZIP-File haben wir ein Makefile und fertig kompilierte Firmware für 8 und 16 MHz Taktfrequenz. Mein Vorschlag ist, die Files "GM328x ESR tester (SVN684) - v2\original 8MHz\TransistorTester.hex" und "GM328x ESR tester (SVN684) - v2\original 8MHz\TransistorTester.eep" aus dem ZIP-File "GM328x ESR tester (SVN684) - v2.zip\" in Deinen funktionsfähigen 328p-Chip zu brennen. Die Fusebytes so lassen wie sie sind, die sind korrekt. Dann sollte der Tester erst mal funktionieren. Ist das der Fall, dann kann man die aktuelle Softwareversion 1.13k von Karl-Heinz mit Hilfe eines angepassten Makefiles compilieren und neue hex- und eep-Files erzeugen. Dabei bin ich gerne behilflich, wenn Du möchtest. Mit Hilfe des Makefile ist es möglich, eine ganze Reihe von Funktionen des Testers (im Rahmen des verfügbaren Flash-Speichers) an- oder abzuschalten. So kann man den Funktionsumfang Deines Testers nachbilden, oder sogar erweitern. Siehe hierzu https://raw.githubusercontent.com/Mikrocontroller-net/transistortester/master/Doku/trunk/pdftex/german/ttester.pdf ab Seite 49. Wenn Du unbedingt die "ATMEGA328Pmiernik1.bin" benutzen willst, dann bleibt m. E. nur die Lösung, den Quarz mit 8 MHz durch einen mit 16 MHz zu ersetzen. Gruß, derri.
:
Bearbeitet durch User
Vielen Dank für die Erklärung und den Hinweis. Ich habe den Quarzresonator auf 16 MHz geändert und es ist in Ordnung. Ich empfehle einen so kleinen DC-DC-Wandler von USB auf 9V für die Stromversorgung. Für mich geht das. Sie können zum Beispiel bei Aliexpress kaufen. Vielen Dank !!
Tomek L. schrieb: > Vielen Dank für die Erklärung und den Hinweis. Bitte, gerne! > Ich habe den Quarzresonator auf 16 MHz geändert und es ist in Ordnung. Dies war wohl die einfachste Lösung. Freut mich, dass der Tester wieder funktioniert. derri
Tomek L. schrieb: > Ich empfehle einen so kleinen DC-DC-Wandler von USB auf 9V für die > Stromversorgung. Darüber habe ich mir auch schon mal Gedanken gemacht. An sich gibt es mehrere Alternativen zur Stromversorgung: - die Standardlösung mit einer 9 V Blockbatterie (nicht wirklich umweltfreundlich), - 9 V Stecker-Netzteil, - deine Lösung mit Spannungswandler 5 V -> 9 V mit Spannung aus einer USB-Buchse, - die direkte Speisung aus einem USB-Anschluss, - eine günstige kleine USB-Powerbank, - einen 3,7 V Akku mit Ladegerät, ähnlich RPI Powerpack V2.0 (teuer), Zur Zeit benutze ich die beiden ersten Varianten. Die letzten drei Varianten setzen voraus, den Spannungsregler mit seinen Hilfsbauelementen, wie Buchse, evtl. Dioden oder Gleichrichter, Siebkondensatoren usw. des Testers zu entfernen und durch eine USB-Buchse zu ersetzen. Der Einbau der USB-Buchse erfordert etwas Geschick, aber das Einsparen der Batterie reizt mich schon. Der Nachteil bei der direkten Speisung per USB ist, dass der Tester dann nicht mehr portabel ist. Deine Idee finde ich nicht übel, daran hatte ich noch gar nicht gedacht. Aber der Vorteil ist sicher, dass man am Tester nichts ändern muss. Ich bin noch am Überlegen ... Jedenfalls danke für den Tipp!
...naja, die onboard Lsg mit 18650 und integriertem Lade und Boost Ic wie bei den Chins Clones ist schon "nice"! Klaus.
Hier der Umbau der "FISH8840" Variante von 2015 mit gebrauchten Handy-Akku, Stepup und Ladereglung über USB. Der Aufwand hielt sich in Grenzen. Das Teil läuft heute noch... mit 18650 https://www.mikrocontroller.net/attachment/268547/Fish-Tester-Inductor-Mod--05.jpg hier mit Handy-Akku Beitrag "Re: Transistortester AVR" Gruß Michael
Hallo zusammen, mal eine ganz dumme Frage, ich betreibe seit Jahren einen Tester mit Arduino Nano. Bei Version 1.12k läuft das gut außer die Messung von Kapazitäten die sehr viel größer werden angezeigt. Beim gleichen Aufbau mit 1.13k zeigt gleich ein mosfet an ohne das was angeschlossen ist. Compiliert unter Linux mint 20.1 weil ich winavr nicht so gut am laufen bekomme. Heute ardutester 1.13 Sketch über arduino ide hochgeladen mit auch die mosfet Auswertung. Wer o wer weiß was da falsch läuft. Schöne Ostern und Grüße aus Holland
Den zugehörigen wiederstände weggenommen disable—pull-up ausgeschaltet aber beide versucht . Ich überlege das Ganze neu aufzubauen Schöne Grüße und Dankeschön
Das Problem scheint sich langsam zu lösen, ich hatte keine Referenz Spannung angeschlossen. 47k an A4 hat nicht geklappt, Vcc bei usb 4.63v über vin 4.93v. Lösung 5v über labornetzteil oder buckboost an vcc, ein 2*20k spannungsteiler zwischen Vcc und - an A4. 1.12k deutlich besser, 1.13k demnächst testen. Das komische ist das man im Internet viele Tester mit Nano sieht ohne Referenz teilweise mit .ino Dateien für arduino IDE aber funktioniert genauso schlecht oder schlechter. Somit habe ich jetzt ein funktionierendes chinesisches Nano mit zweizeiliges 1602 Display. Wenn alles richtig funktioniert werde ich Karl-Heinz mein Aufbau zuschicken. Zum Problem mit eeprom hochladen über ch340g scheint bei mir zu funktionieren mit optiboot von Karl-Heinz wenn Mann baudrate zurückschraubt auf 57600. Schöne Grüße von Leon
Hi, wollte seit langem mal den Frequenzgenerator des Testers mit der Ver.1.13 REF.781 (Fish8840) verwenden. bei den vorhergehenden Versionen waren die Ausgangsfrequenzen fest vorgegeben und durch scrollen anwählbar, was ich sehr praktisch fand. Bei der neuen Menuführung blicke ich überhaupt nicht durch. Natürlich habe ich auch in der Doku gesucht. Dort wird FG in seiner Bedienfunktion nicht erwähnt... Gruß Michael
Michael D. schrieb: > Dort wird FG in seiner > Bedienfunktion nicht erwähnt... Hallo Michael, ... in den neueren Beschreibungen kannst Du es nachlesen: https://raw.githubusercontent.com/Mikrocontroller-net/transistortester/master/Doku/trunk/pdftex/german/ttester.pdf Kapitel 3.2 Optionale Menüfunktionen für den ATmega328 ... ab Seite 41 Gruß Horst
Das ging ja fix. Auf die Seite wäre ich nie gekommen, bin da wohl woanders rumgedümpelt. Das Projekt wurde nach GitHub verschoben? Vielen Dank für die schnelle Hilfe Horst! Gruß Michael Die Bedienung ist da(ohne Beschreibung) schon ein wenig Tricki, wenn man das nicht weiß...
Scheint doch ein problem In die software zum Beispiel 1.12k beim selbsttest 30 bis 31 pF bei 1.13k zweite stelle -57000, habe die Anschlüsse des Nano neu gelötet mit extra flux 1.12k gibt jetzt 470uF wird als 370 angegeben 2200uF als 15mF. Muss allerdings zugeben das die wiederstände nicht ganz genau übereinstimmen. Kann das die Ursache sein? Schöne Grüße von Leon
Hallo zusammen, ich bin stolz auf meinen nach der Grundschaltung komplett selbst zusammengebauten Tester auf Basis eines 328P. Er funktioniert jedoch nur, wenn ich die Option für die Präzisionsspannungsreferenz in der config.h deaktiviere. Verbaut habe ich einen LM4040A (2,5V) und beim durchmessen schaut alles gut aus. Bei aktivierter Option schaltet sich der Tester nach dem Anzeigen der Batterispanung sofort wieder aus, mit deaktivierter Option bleibt er an und misst. Was kann die Ursache sein? Danke und VG, Ralph #define HW_REF25 #define UREF_25 2500
Hallo Ralph Wenn Vcc 10% weniger ist wird die Batterie Spannung 20% abweichen. Versuch mal im makefile die mindest Batterie Spannung runter zu stellen. Herzlichen Glückwünsche zum erfolgreichen Bau deines Tester Schöne Grüße von Leon
Ralph schrieb: > ich bin stolz auf meinen nach der Grundschaltung komplett selbst > zusammengebauten Tester auf Basis eines 328P. Er funktioniert jedoch > nur, wenn ich die Option für die Präzisionsspannungsreferenz in der > config.h deaktiviere. Verbaut habe ich einen LM4040A (2,5V) und beim > durchmessen schaut alles gut aus. Bei aktivierter Option schaltet sich > der Tester nach dem Anzeigen der Batterispanung sofort wieder aus, mit > deaktivierter Option bleibt er an und misst. Was kann die Ursache sein? > > #define HW_REF25 > #define UREF_25 2500 Wahrscheinlich ist der Tester der Meinung, dass die Batteriespannung zu niedrig ist. Hast du den Spannungsteiler für die Batteriespannung bestückt? Du kannst aber auch die Batterieüberwachung komplett abschalten (BAT_NONE).
Hallo zusammen, hallo Leon, danke für deine Antwort und den Tipp mit der Mindestbatteriespannung. Die Einstellungen habe ich im Power Management der config.h gefunden. Eine Änderung des Wertes hat leider keinen Erfolg gebracht. Beim Start wird die Batteriespannung im Display angezeigt mit "ok" und es erscheint sehr kurz "Suche", dannach schaltet sich mein Tester stets sofort aus. Ich finde den Fehler nicht. Nur bei deaktivierter Präzisionsreferenz läuft der Tester. Was könnte nur das Problem sein? #define BAT_LOW 6400 testweise geändert auf 5800 VG Ralph
Ralph schrieb: > bei deaktivierter Präzisionsreferenz > läuft der Tester ... hast Du mal die Spannung an der Referenz direkt beim Einschalten gemessen, die gibt es ja in unterschiedlichen Werten? Gruß Horst
Hallo Markus, auch eine gute Idee, habe ich natürlich auch sofort ausprobiert, jedoch mit dem gleichen Ergebnis. Mein Spannungsteiler 10k/3,3k zum Messen der Batterie ist ok, auch die gemessene Spannungsreferenz liegt wirklich bei 2,5V. Die Referenz einfach wegzulassen ist keine Option. Wenn schon denn schon, aber das das ist gar nicht mehr so einfach... Hast du noch einen Einfall? #define BAT_NONE VG Ralph
Ralph schrieb: > du noch einen Einfall ... an welchen Port hast Du sie denn angeschlossen, stimmt das mit der Pinbelegung in der config_328 überein? Gruß Horst
Hi... hab mal ne Frage - hatte dazu leider nichts gefunden oder falsch gesucht..?! Ich habe seit gestern den Transistortester GM328 (in Schwarz mit SMD Bauteilen) und habe festgestellt wenn man den Rotary Encoder sehr sehr schnell dreht dann startet der tester neu oder kommt in den "Selection" mode. ist das ein normales Phänomen oder ist möglicherweise was defekt? :( Danke euch
Hallo Ralph Werte im makefile gehen vor Änderungen in config.h Ich würde außerdem mal folgende Spannungen direct am atmega Pins messen Vcc und Referenz Spannung wenn ich mich nicht irre a4 Batterie spannungsteiler a5. Der Vorschlag von Markus Batterie Check auszuschalten würde ich als erstes probieren. Könnte sein das der spannungsteiler falsch herum ist angeschlossen? Viel Erfolg Grüße Leon
Leon T. schrieb: > Scheint doch ein problem In die software zum Beispiel 1.12k beim > selbsttest 30 bis 31 pF bei 1.13k zweite stelle -57000, habe die > Anschlüsse des Nano neu gelötet mit extra flux 1.12k gibt jetzt 470uF > wird als 370 angegeben 2200uF als 15mF. > Muss allerdings zugeben das die wiederstände nicht ganz genau > übereinstimmen. Kann das die Ursache sein? Mit der Toleranz der Widerstände wächst auch die Toleranz der Messwerte, aber nicht so extrem. Merkwürdig ist auch, dass der kleine Elko zu niedrig und der grosse viel zu hoch gemessen wird. Für Kondensatoren ab etwa 47µF wird die gleiche Messfunktion genutzt, d.h. ein Fehler sollte sich auf beide Elkos gleich auswirken. Hast du die Elkos an den gleichen Testpins gemessen?
Ralph schrieb: > Eine Änderung des Wertes hat leider keinen Erfolg gebracht. Beim Start > wird die Batteriespannung im Display angezeigt mit "ok" und es erscheint > sehr kurz "Suche", dannach schaltet sich mein Tester stets sofort aus. Dann liegt es nicht an der Batterieüberwachung. Als Nächstes könntest du, wie von Horst vorschgeschlagen, die Pinzuordnung überprüfen.
Hallo Markus, vielen dank für deine Antwort, klar an den gleichen testpins, jetzt 2 Platinen in Betrieb eine ohne und eine mit genau 5v Vcc und Referenz durch 2x20k spannungsteiler, gleiche Werte mit verschiedene nano‘s. Was aber noch mehr stört ist das die 1.13k gar nicht richtig funktioniert und ohne Anschluss gleich mit ein mosfet anfängt und beim selbstbestimmt wird das 104 nF nicht erkannt, mit die ardutester 1.13 arduino Sketch genau den selben Sch... Und auch mit die uno makefiles von Karl-Heinz ohne Display. Schöne Grüße von Leon. Kann es an die chinesischen arduino nano‘s liegen?
Bei den Arduinos ist übrigens der Kondensator an AREF 100nF (statt 1nF, wie in der Transistortester-Referenzschaltung). Mit dem größeren Kondensator dauert das Umladen beim Wechsel der ADC-Referenzspannung länger. Für die k-Firmware kann man das über das Abschalten von "NO_AREF_CAP" im Makefile kompensieren. Und für die m-Firmware heißt der Schalter ADC_LARGE_BUFFER_CAP.
:
Bearbeitet durch User
Hallo Markus NO_AREF_CAP ist eingeschaltet, verstehe ich richtig das ein 100nF im arduino verbaut ist? Gibt es auch eine M Version die sich für das arduino Nano eignet? Schöne Grüße von Leon
Umgekehrt, NO_AREF_CAP abschalten. Und ja, die m-Firmware läuft auch auf den Arduinos mit ATmega.
:
Bearbeitet durch User
Horst O. schrieb: > ... an welchen Port hast Du sie denn angeschlossen, stimmt das mit der > Pinbelegung in der config_328 überein? Selbsverständlich, geprüft und überein stimmend (default/unverändert). Was sind hier eure Erfahrungswerte bezüglich der Spannungen? Dann könnte ich mal Vergleiche ziehen. Ich messe am Pin: PC5 (Pin 28, Spannungsteiler UBat, neue 9V-Batterie) = 1,95V PC4 (Pin 27, Spannungsreferenz 2,5V am LM4040A) = 1,557V und die Spannungen: Batterie = 9,13V UBat = 7,95V Vcc = 5,13V Ich habe zwar alles durchgemessen, aber Wie wahrscheinlich sind andere Fehler im Aufbau, die ein Abschalten nach dem direkten Erscheinen der "Suche" im Display auslösen können? Leon, ich nutze die Version V1.42m und habe das Makefile ausgedruckt vor mir liegen. Es beinhaltet keine Möglichkeit an den Spannungen zu drehen, diese Möglichkeit besteht nur im Powermanagent der config.h. Welche Version hast du?
Ralph schrieb: > PC4 (Pin 27, Spannungsreferenz 2,5V am LM4040A) = 1,557V -> Tippfehler, es sind natürlich 2,557V
Ralph schrieb: > ... natürlich 2,557V ... ist ein zu hoher Wert, laut Datenblatt hat die A-Version max. 2,515 Volt. Mit welchem Vorwiderstand betreibst Du denn die Referenz? Wenn die Spannung vom vorgegebenen Wert der config abweicht, kannst Du den Wert hier anpassen: #define UREF_25 2557 Gruß Horst
stimmt so ungefÄhren, Referenz soll genauer sein als dein Messgerät. Einzige was ich noch denken kann ist ein Multiplikationsfaktor in die Software um von pc5 1.95v auf die Batterie Spannung zu kommen. Was zeigt das Gerät an für Vcc und Batterie bin ausgeschaltete Referenz? Schöne Grüße von Leon
Hallo Markus gerade versucht die 1.43m zu kompilieren 328p mit 2 Zeilen Display. Leider Fehlermeldungen über doppelte Definition in St7565r und wenn ich st7565r nicht mitnehme Fehler in Main.c und oder Display.c über lcd_contrast. Vielleicht mache ich was falsch könnte ein Hinweis brauchen um das Problem zu lösen. Hab mich auch umgesehen zum esp32 wegen höhere adc Auflösung und dan kam die newsletter mit die Nachricht das der adc wandler nicht so gut funktioniert. Schöne Grüße von Leon und ein schönes Wochenende
Das passiert, wenn man mehr als ein Display konfiguriert. Bei einem HD44780 die Konfiguration für das HD44780 aktivieren und die vom ST7565R deaktivieren (die ist standardmäßig aktiviert). Sofern LCD_CONTRAST gesetzt wurde, obwohl das Display das nicht unterstützt, gibt es die LCD_Contrast()-Fehlermeldungen.
Hallo Markus hatte den Fehler gefunden meine Dummheit Dankeschön und schönes Wochenende Leon
Frage für Karl-Heinz Ist es möglich das 1602 Display mit I2c zu benutzen in 1.12k und 1.13k? Was hat sich geändert zwischen die 2 Versionen, mein Nano Setup hat schwere Probleme mit der 1.13k Version mosfet während nicht angeschlossen, Selbsttest bricht ab weil Kapazität nicht erkannt wird. Ich denke an wait subroutines oder vielleicht adc oversampling. In 1.12k wird nur die Kapazität mit große Abweichungen gemessen, der Rest funktioniert ziemlich gut. Habe das ganze auch auf neue Hardware aufgebaut mit gleiches Resultat. Schöne Grüße von Leon Tummers aus den Niederlanden.
Hallo Markus Leider habe ich mich vertan, der kleine Elko zeigt jetzt 1180 uF an statt 470, der große 15 mF statt 2200uF also der Messfehler steigt exponentiel mit die Größe des Elko. Leider klappt die 1.43m auch nicht so richtig, am Display kommt als erste Zeile Grafik raus und dan was mit Pro und dsg was wieder schnell verschwindet. Auch die 1.13 ardutester kommt mit mosfet Daten ohne angeschlossenes Bauteil. Wenn ich umschalte auf Vt100 das gleiche. Die wiederstände habe ich unter das Nano zwischen die Pins auf die lochplatine verbaut. Was ist deine neueste m Version die sich noch auf 1.12 von Karl-Heinz basiert? Habe jetzt auch ein i2c 1602 zur Verfügung um das ganze noch mal neu zu bauen. Vielen Dank und Schöne Grüße von Leon Tummers aus den Niederlanden.
Vielleicht ist ein Pin vom ATmega defekt. Starte mal den Selbsttest und poste die Werte.
Hallo Markus selbsttest funktioniert auch nicht richtig in der 1.13k Version aber Tester 2x aufgebaut und mit verschiedene arduino nano‘s versucht. Ich möchte noch einmal neu bauen mit i2c 1602 und nur eine Taste sodass der Aufbau so einfach wie möglich ist. Ich will dabei die Wiederstände separat auf die Platine aufstellen vielleicht hilft das. Nützen die testierte von 1.12k vielleicht? Schöne Grüße von Leon
Hallo Markus leider nur eine Datei möglich pro Beitrag dies ist der einzige vollständige Test die mir gelingt Schöne Grüße von Leon
Hallo Markus leider nur eine Datei möglich pro Beitrag dies ist was in 1.13k heraus kommt Schöne Grüße von Leon
Hallo Markus leider nur eine Datei möglich pro Beitrag und dies ist was in 1.43m heraus kommt wahrscheinlich mein Fehler. Schöne Grüße von Leon und voraus Dank für deine Mühe
Leon T. schrieb: > Hallo Markus selbsttest funktioniert auch nicht richtig in der 1.13k > Version aber Tester 2x aufgebaut und mit verschiedene arduino nano‘s > versucht. Ich möchte noch einmal neu bauen mit i2c 1602 und nur eine > Taste sodass der Aufbau so einfach wie möglich ist. Ich will dabei die > Wiederstände separat auf die Platine aufstellen vielleicht hilft das. > Nützen die testierte von 1.12k vielleicht? Bis incl. T6 sind die Tests identisch bei k und m-firmware. Es geht nur darum zu sehen, ob die Werte ok sind. Wenn aber selbst der Selbsttest nicht funktioniert, dann ist wahrscheinlich bei der Hardware etwas schief gelaufen, oder das Pinout passt nicht. Am sinnvollsten dürfte sein, den Schaltplan zu nehmen und alles Stück für Stück zu überprüfen. Und beim Arduino muss auf die LED an D13 (PB5), die TTL-Serielle (USB2serial) und den 100nF-Kondensator an AREF aufpassen.
Leon T. schrieb: > leider nur eine Datei möglich pro Beitrag Andere konnten mehrere Dateien anhängen, z.B. Beitrag "Re: Transistortester AVR" Unter dem "Browse..." Button ist noch der "Weitere Datei anhängen" Button. ... und dann gibt es noch zip.
Hallo Alexander Ein wenig schwierig auf IPAD weitere hat nicht funktioniert Schöne Grüße von Leon
Leon T. schrieb: > Angehängte Dateien: > > > > tt113k.log (5,02 KB) Bei Test2 der Version 1.12k fällt auf, daß der 680 Ohm Widerstand an TP3 deutlich abweicht. Die 680 Ohm Widerstände an TP1 und TP2 scheinen ziemlich gleich zu sein. Den Widerstandswert selbst kann der Tester nicht messen, aber die Port-Innenwiderstände scheinen plausibel zu sein. Bei großen Abweichungen von 680 Ohm würden die Port-Innenwiderstände deutlich vom Normalwert abweichen. Ein völlig seltsames Ergebnis der Null-Kapazität zeigt sich aber bei der Version 1.13k. Das zeigt sich sowohl bei der normalen Messung als auch mit der SamplingADC Methode. Zur Klärung der Ursache ist es wahrscheinlich sinnvoll, die Makefile und die .hex und .eep an meine Email-Adresse zu schicken. Ich habe einen Testaufbau mit Arduino-Nano Clone, der mit der 1.13k normal läuft. Die 1.13k habe ich über meinen optiboot Bootloader geladen. Die LED an PB5 (Arduino D13) des Nano habe ich deaktiviert!
Hi Karl. I have tried to compile your new version for a mega328_color_kit and for a mega328_T3_T4_st7565 but I get errors in the sources. It only compiles me correctly with the English language and the source to 8x16. I attach photos of the compilation in the mega328_color_kit. Thanks and best regards. Hallo Karl. Ich habe versucht, Ihre neue Version für ein mega328_color_kit und für ein mega328_T3_T4_st7565 zu kompilieren, aber ich erhalte Fehler in den Quellen. Es kompiliert mich nur korrekt mit der englischen Sprache und der Quelle auf 8x16. Ich füge Fotos der Zusammenstellung im mega328_color_kit hinzu. Danke und viele Grüße.
Pepe P. schrieb: > I get errors in the sources. Hello, there is a '.h' missing in
1 | #include "language-dependent_characters" |
It should read
1 | #include "language-dependent_characters.h" |
See https://github.com/Mikrocontroller-net/transistortester/tree/master/Software/trunk/fonts
Pepe P. schrieb: > It only compiles me correctly with the English language and the source > to 8x16. Many thanks for the error report! The missing .h is corrected in file 8x8_vertikal_LSB_1.h. Some special characters for Spanish are now available with the latest github source. But some characters are not yet defined and are replaced as follows: a_super='a', o_super='o', n_tilde='n', N_tilde='N', updown_exclam='!', updown_question='?' . As far as I know, no special Spanish characters are currently used in the TransistorTester software. Defined and usable are the characters a_acute, c_cedil, e_acute, i_acute, o_acute, u_acute, u_uml, A_acute, E_acute, I_acute, O_acute and U_acute.
Hello. Thanks Karl and Alexander. I have verified that it compiles well in both English and Spanish and with 8x8, 8x16 and 8X12 Thin fonts. During the morning I will adjust the compilation to my needs and install it in the different component testers that I have for testing. Thank you very much and greetings. Hallo. Danke Karl und Alexander. Ich habe überprüft, dass es sowohl in Englisch als auch in Spanisch und mit 8x8-, 8x16- und 8X12-Thin-Schriftarten gut kompiliert werden kann. Während des Vormittags werde ich die Kompilierung an meine Bedürfnisse anpassen und sie in den verschiedenen Komponententestern installieren, die ich zum Testen habe. Vielen Dank und Grüße.
And now for something completely different ... Für die Source-Code-Historiker habe ich die Entwicklung von Markus' Version in GitHub verewigt (ausgelöst durch diese Diskussion https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg3565497/#msg3565497), Version 0.99m ... 1.43m sind jeweils ein Commit als annotated Tag, man kann also alle Änderungen von Version zu Version nachvollziehen: https://github.com/Ho-Ro/ComponentTester
Hallo und guten Abend, wisst ihr von Problemem mit Grafikdisplays mit ST7920 über SPI Bitbang? Ich habe zwei verschiedene Displays getestet, aber erhalte stets nach der Versionsanzeige "Timeout Error". Herkömmliche Zeilendisplays bei gleichem Aufbau laufen tadellos. Bin für jeden Tip dankbar... Gruß Ralle
Beim Timeout-Fehler wurde der Watchdog ausgelöst. Probiere bitte in ST7920.c in der Funktion LCD_ClearLine() am Anfang nach den Variablen Folgendes einzufügen: wdt_reset(); /* reset watchdog */ Die Funktion LCD_ClearLine() gibt es zweimal!
Markus R. schrieb: > Beim Timeout-Fehler wurde der Watchdog ausgelöst. Hallo Markus, herzlichen Dank für diesen Tip! Tatsächlich klappt es damit jetzt über den Batterietest hinweg bis zur "Suche...". Danach kommt jedoch sofort erneut der Timeout Fehler. Sollte ich noch weitere Stellen in der ST7920.c berücksichtigen, außer den beiden genannten? Viele Grüße, Ralle
Das scheint mir Richtung MCU-Takt zu gehen. Hast du vielleicht den 8:1-Vorteiler in den Fuses aktiviert? Oder ist die MCU-Frequenz im Makefile falsch?
Ahmed M. السلام غليكم ارجو ان تساعدني احمد lcr-T4 لدي اردت تغيير الشاشة ب nokia 1100 lcd وبعد رفع الكود لا يظهر شيء على الشاشة وغيرت السطر الدي ذكرته lcd-routines.c lcd_command(CMD_SET_POWER_CONTROL | 4); to lcd_command(0x2F); هل يمكنك ان ترسل الي الكود والمخطط وشكرا
Hallo Ahmed, Ahmed schrieb im Beitrag #6716582 (aus dem Arabischen mit translate.google.com): > Ahmed M. >... >Kannst du mir den Code und Schaltplan schicken? Den Schaltplan findest Du unter https://c2.at.ua/1SX/1/ESR_shema.png oder https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg709934/#msg709934 Der Code befindet sich in https://github.com/Mikrocontroller-net/transistortester/tree/master/Software/trunk >... >Ich möchte den Bildschirm meines Nokia 1100 LCD ändern Wenn ich richtig verstehe, willst Du das Original-LCD des T4 durch ein Nokia-1100-LCD ersetzen? Dann ist das Makefile im Unterverzeichnis "mega328_PCF8814" wahrscheinlich das richtige (@Karl-Heinz, bzw. andere Sachkundige: bitte korrigieren, falls das nicht stimmt). Tipp: Anpassungen an verschiedene Anwendungsfälle der Software sollen soweit wie möglich im Makefile erfolgen, und nicht in den *.C- oder *.H-Files. Gruss, derri.
Marcel D. schrieb: > Der Code befindet sich in > https://github.com/Mikrocontroller-net/transistortester/tree/master/Software/trunk Die neueste Version der Software ist jetzt unter: https://github.com/kubi48/TransistorTester-source Die Dokumentation ist getrennt auf: https://github.com/kubi48/TransistorTester-documentation Scripts zur Unterstützung einer Linux Installation findet man auf: https://github.com/kubi48/TransistorTester-Linux-install Die Trennung wurde durchgeführt, weil es praktisch unmöglich ist, alte Inhalte aus dem Git Archiv zu löschen. Der Download von den neuen Adressen geht jetzt schneller, weil viel alter Ballast fehlt. Der früher in das Projekt integrierte spezielle optiboot Bootloader ist jetzt ebenfalls getrennt auf: https://github.com/kubi48/avr-assembler-optiboot Marcel D. schrieb: > Dann ist das Makefile im Unterverzeichnis > "mega328_PCF8814" wahrscheinlich das richtige Das ist das richtige Verzeichnis. Ich habe aber nicht selbst getestet, weil mir das Display fehlt.
@kubi48 Danke für die Klarstellung, Karl-Heinz. Mit meinen besten Grüssen, derri.
Markus R. schrieb: > Das scheint mir Richtung MCU-Takt zu gehen. Hast du vielleicht den > 8:1-Vorteiler in den Fuses aktiviert? Oder ist die MCU-Frequenz im > Makefile falsch? Hallo Markus, hallo zusammen, ich habe meinen Testaufbau wieder mit einem einfachen Zeilendisplay verbunden und verschiedene Tests gemacht, der Tester arbeitet tadellos und erkennt die Bauteile. Alle Softwareschalter sind auf default, ich stelle wirklich nur in der config_328.h das Display um auf das ST7920, wechsle das Display aus und schon ist der Timeout-Fehler sofort wieder da, kurz nachdem "Suche" erscheint. Damit würde ich eine falschen MCU-Takt ausschließen, könnte es am Display liegen? Ich habe es ausgewählt, da es sehr groß ist und ohne Brille gut lesbar. Vielleicht sollte ich doch ein anderes Display versuchen, was besser unterstützt wird? Viele Grüße Ralle
Du könntest noch ein "wdt_reset();" in die Funktion LCD_DotPos() in der Datei ST7920.c packen. Ich hatte beim Schreiben des ST7920-Treibers auch mit einem ATmega328 bei 8 MHz und Bitbang-SPI getestet. Daher bin ich etwas über das Timeout verwundert. Der ST7920 braucht zwar bei SPI drei Bytes statt nur einem, aber das ist bei einem Monochromdisplay nicht weiter tragisch. Ich denke, dass das Timeout (2s) eine andere Ursache hat.
Hallo Markus, kleiner Eintrag, große Wirkung! Mit dem wdt_reset läuft es jetzt, was bin ich froh! Damit kann ich den ganzen Aufbau endlich fest zusammenlöten. Vielen herzlichen Dank! VG Ralle
Hello I just joined the forum today. I apologize that this is in English using a google translator to read posts. I Have a GM328A just bought from Amazon. I believe this would be the "mega328_color_kit" hex/eep files from Mikrocontroller github trunk. I flashed another Atmega328P using two Arduino unos, one as an ISP obviously the second one I put a zif socket for easy insertion/removal. Using Arduino IDE to load ISP sketch all connections are correct. I am using the Flash Software "avrdudeprog33" this version I have supports Arduino. Once I flash and insert the MCU into the GM328A there is a lot of latency on startup and moving through the menus. I was guessing maybe some of the Fuses are customized for this device and tried a few combinations using the "https://www.engbedded.com/fusecalc/" and none seem to help the latency issue. I cannot extract the firmware from this default MCU they have locked it so no way to figure out the differences between the default firmware and the one available from the Github. Any suggestions as to what else I could try or fuse settings? Maybe the firmware from the trunk is not exactly correct for this device could that be why? There is another firmware by this person and has a game Tetra on it and it does not work at all. He also has the GM328A but maybe a different version hardware? https://dragaosemchama.com/en/2019/04/gm328a-reverse-engineering-new-firmware-and-tetris/#comment-31406
:
Bearbeitet durch User
Ronald G. schrieb: > Any suggestions > as to what else I could try or fuse settings? The default fuse setting for the teste is lfuse=0xf7, hfuse=0xd9 and efuse=0xfc. You should ignore a error message, if the unused bits of efuse are read back as '0'. It is important, that the clock source in the lfuse is selected correctly. Usually you can program the ATmega with the Makefile. You need only the commands "make fuses-crystal" to set the fuses and "make upload" to upload the firmware. The type of ISP programmer must be selected in the Makefile with a source editor (PROGRAMMER=... and PORT=...). With Windows you should install the Arduino package first and you need additionally a make.exe program (suggested: with cygwin package). I know only a wrong clock selection as reason for a slow menu function. You can additionally speed up the output for the color display by changing the crystal with a 16MHz version and recompile the the software (Makefile setting OP_MHZ=16).
Ronald G. schrieb: > I Have a GM328A just bought from Amazon. > I believe this would be the "mega328_color_kit" ... > hex/eep files from Mikrocontroller github trunk. Yes, I think you're right. I have the same one, see figure 2.24 in the manual "ttester.pdf" from the github repository. Download from: < https://github.com/kubi48/TransistorTester-documentation/blob/main/TransistorTester_english.pdf >. It is a good idea to read the manual any way, especially the chapters about customizing the software. > Once I flash and insert the MCU into the GM328A there is a lot > of latency on startup and moving through the menus ... Maybe the processor runs on the internal 1 MHz clock, which is the factory setting. Please check the frequency of the crystal on your device. The default setting of the precompiled firmware is 8 MHz. If the hardware has a 16 MHz crystal, the parameter OP_MHZ in the makefile must be changed to OP_MHZ=16, and the firmware recompiled (see manual). You need a 16 MHz crystal to use the better resolution offered by the sampling ADC feature. > I tried a few combinations using the "https://www.engbedded.com/fusecalc/" ... Please try to set the fuses to: lfuse=F7; hfuse=D9; efuse=FC; this works for me and almost any atmega328p setup. You can check these settings in fuscalc. > I cannot extract the firmware from this default MCU ... That's the chinese way of handling open source projects. :-( Greetings, derri
:
Bearbeitet durch User
Thanks for the reply I’ll look over the documentation tonight. The crystal is 8mhz so so I choose external crystal 8mhz for the fuse? That’s the only thing I can think of. The one I have says GeekTeches printed on the board is this the one you have and your not noticing any latency? I even accidentally flashed the mcu that came with it same issue but the original MCU ran perfectly fine. I’ll double check the settings but I have L/H Fuse the same as yours the efuse will let me disable or enable boot…….0/1/2 I forgot the name but I think it’s related to brownout protection so I don’t see how that would impact the way it runs it has to be something with the settings of the MCU clock and external crystal onboard 8mhz. I’ll have another one today just to make sure. Is the software I am using to flash possibly the cause?
Ok the issue must be the flash software avrdudeprog33 or something I am doing wrong with the settings in there, because the software is missing some data in the microcontroller after it’s flashed, for example there is no hard coded list of frequencies in the frequency generator menu, something either wrong with the hex and epp files or the software flash programming ? I use the program all button after loading both the HeX and Epp files so now I have to try a different approach. You can load the make file into the arduino IDE software did not know that, thought only sketches or code went in there. Can I use the make file that is located in the folder where you find the hex and epp files from the software folder then trunk? I still don’t understand why flashing with the combination of two arduino’s and avrdudeprog33 is not working? I will first try a couple of different approaches such as instead of programming all button, I’ll program the fuse followed by the hex file then followed by the epp if you can do this?
Sorry tried to edit my last post but it was over 1 hour so I could not. I could run Arduino IDE and whatever else I need in MAcOS BigSur. After watching some Youtube video tutorials, they were able to compile and flash to the arduino from a command line. The tutorial was about the GNU make and they downloaded both the Arduino-cli and CppLint for flashing the firmware onto the Arduino's instead of using IDE's for embedded programing I am guessing they mean instead of using the Arduino IDE. I am not sure what exactly else I would need to do or which direction to go without making this too complicated, is there a tutorial for this on a MacOS? Over 20 years ago I was configuring making and compiling linux kernels when USB was becoming popular, but in linux not MacOS. If its just easy in windows 10, I could use EditPlus or Notepad++ to modify the make file and just do this in the Arduino IDE if that would be easier , but I would need all the source files then correct?
:
Bearbeitet durch User
Hi Ronald, Ich hatte die gleichen Probleme. Ich habe alles getestet, aber unter Windows klappte es nie. Die einfachste Lösung war, auf einem alten Notebook ein aktuelles Linux Mint und die nötigen Pakete installieren. Damit hast du den einfachsten und besten Weg, mit nur einem Befehl alle Quelldateien zu kompilieren und die Firmware-Dateien zu übertragen. Schau dir die Anleitung an, dort ist alles sehr gut beschrieben.
Hallo zusammen, da ich meinen LCR T4 gerne "einhausen" möchte und dabei auch mit Lipo + 5V step up versorgen möchte - ist es funktional nachteilig, von den ursp. 9V Versorgung weg auf 5V zu gehen? Nutzt er die höhere Spg für bestimmte Messungen? EDIT: Laut Schaltplan ja nicht, weil DUT nur an den uC Ports hängt - einzig die LED + Einschalt-Mimik ist auf 9V ausgelegt. Danke, Klaus.
:
Bearbeitet durch User
Klaus R. schrieb: > Nutzt er die höhere Spg für > bestimmte Messungen? Es muß nur die Schaltung zum Abschalten angepasst werden und der Spannungsteiler für die Batteriespannungsmessung sollte für eine bessere Auflösung auch angepasst werden (z.B. 2:1). Leider muß die Batteriespannung hinter dem Einschalt-Transistor gemessen werden, weil sonst dauerhaft Strom aus der Batterie gezogen wird. Das ist auch dann der Fall, wenn man den Spannungsteiler ganz weg lässt wegen der Schutzdioden an den ATmega-Eingängen.
Hallo Karl-Heinz, ist das zufällig im git dokumentiert, der nötige Umbau? Muss man die Batt SpgsM im Code ändern, so dass sie nicht zu früh reagiert (wie man sie abschaltet, weiß ich)? Eigentlich kann ich sie ja eh deaktivieren, oder ich messe damit die LiPo Zelle (das wäre natürlich super) - denn nach dem step-up sinds ja eh konstant 5V :) Danke, Klaus.
Hallo Klaus, vielleicht hilft die Schaltung der Funkamateure (FiFi 2013)weiter, die hier immer noch zum Download bereitsteht: https://o28.sischa.net/bauteiltester/trac/browser/trunk/Hardware?order=name Die passenden Makefiles findet man unter mega328_1.9V für die Batterieversion und mega328_3.3V für die LiPo Version.
Klaus R. schrieb: > der nötige Umbau? … ev. kann die Schaltung des TC1 Dich ja inspirieren. Gruß Horst
...uiii, dachte nicht, dass der TC1 so viel weiter ist / kannte ihn nicht. Wenn man das mal in Betracht zieht, sollte ich den nehmen und um Drehencoder sowie Buchse für fGen und fMess erweitern und fertig. Auch wenn ich das monochrome LCD des LCR T4 besser finde. Edit: Und IRMP haben die da auch noch eingeklaut..eieiei :) Klaus.
:
Bearbeitet durch User
Hallo Klaus, ... ist das jetzt Ironie? Am 16.10.2020 19:41 in einem Betrag von Dir wolltest Du doch schon div. Mod 's an Deinem TC1 durchführen? ;-) Gruß Horst
Hallo, bin mit dem Umbau des LCR T4 fast fertig - kann ich den Drehencoder auch verkabeln, ohne die Option erstmal im Code zu nutzen, also HW Vorhalt? Und dann hinterher aktivieren, so dass es zunächst keine neg. Auswirkungen hat? Karl-Heinz K. schrieb: > und der > Spannungsteiler für die Batteriespannungsmessung sollte für eine bessere > Auflösung auch angepasst werden (z.B. 2:1). Wo ist das im Code dann anzupassen? Werde direkt die LiPo Spg messen. Danke!
Horst O. schrieb: > wolltest Du doch schon div. > Mod 's an Deinem TC1 durchführen? ;-) Ne, habe "nur" den LCR T4, aber ewig - ja, ich hatte das vor, bin aber nie dazu gekommen - bis heute :) Klaus.
Klaus R. schrieb: > Karl-Heinz K. schrieb: >> Spannungsteiler für die Batteriespannungsmessung sollte für eine bessere >> Auflösung auch angepasst werden (z.B. 2:1). > > Wo ist das im Code dann anzupassen? Werde direkt die LiPo Spg messen. > > Danke! Das sollte nicht im Code angepasst werden, sondern im Makefile. Da sind extra zwei Konstanten für den Spannungsteiler definiert: // Voltage divider for battery voltage measurement 10k / 3.3k = 133/33 CFLAGS += -DBAT_NUMERATOR=133 CFLAGS += -DBAT_DENOMINATOR=33 Suche nach diesem Text und ersetze die beiden Werte mit den entsprechenden Kennwerten deines Spannungsteilers. Beispiel: Teiler 2:1 mit 10k/10k also CFLAGS += -DBAT_NUMERATOR=2 CFLAGS += -DBAT_DENOMINATOR=1 Gruss, derri
:
Bearbeitet durch User
Ja, kapiert - Danke! Hätte es iwio als #define erwartet aber so ist es vermtl eleganter... Bleibt noch die Frage der späteren Aktivierung des Drehencoders? Klaus.
Hallo Klaus, ... in diesem Beitrag vom 16.10.2020 hattest Du "LCR T1" geschrieben,was ich dann wohl falsch ausgelegt habe, es hätte sicher "LCR T4" heissen sollen. Gruß Horst
:
Bearbeitet durch User
Ronald G. schrieb: > The crystal is 8mhz so so I choose external crystal 8mhz for the fuse? Yes, that's correct! But just set the fuses to the values Karl-Heinz gave you (See attached screenshot). These values DO WORK! > I have L/H Fuse the same as yours the efuse will let me disable or enable > boot…….0/1/2 I forgot the name but I think it’s related to brownout > protection Yes, it's BODLEVEL, and defines the minimal supply voltage level. An automatic reset occurs when the supply falls below it. You may ignore it for now. > Is the software I am using to flash possibly the cause? Right now I'm confused about which software you mean ... avrdudeprog33 or the MCU firmware? > I use the program all button after loading both the HeX and Epp files I suppose you have also set the fuses and checked all three "Programm" Options FLASH, EEPROM and FUSES? > I’ll program the fuse followed by the hex file then followed by the epp > if you can do this? Yes, try that, in that order, each time hitting "Programm" and then "Verify". If you get errors, then there is something wrong with your setup or your microcontrollers are defective! As for compiling the firmware from the github repository, I would postpone that for the moment. Since your device has a 8 MHz crystal, you can use the precompiled hex and eep files provided by Karl-Heinz Kübbeler. It should run on your tester without modification. So just use the files from the subdirectory "mega328_color_kit". If that works for you, we can talk about customizing. Hope this helps, derri
...damit ich nicht nur Fragen stelle hier mal der Stand, vll ist es ja für irgend wen interessant / inspirierend: - Gehäuse 8x10x2,5 - Prototyp aus Wellpappe (vermtl mache ich ein Pultgehäuse draus) - alte Powerbank geplündert - LiPo Spg wird gemessen (3.3k -> 10k ändern) - Drehencoder ist eingebaut aber noch nicht final angeschlossen - der ZIF Sockel ist schon zml durch, den muss ich mal durch einen neuen ersetzen... - Anschlussmgl für PWM out / FreqMess fehlt noch (weiß noch nicht, was ich "praktisch" finde) - SMD Testfeld TBD (ich hatte leicht federn gelagerte Kupferstreifen am externen Feld, das verschafft besser Kontaktmöglichkeiten durch Andruck - eine Messbuchse für Cs kommt noch dazu, ähnlich wie in meinem alten Voltcraft DMM - SW TBD: BattMsg auf 2:1 anpassen, Warnschwelle auf 3.3V / 3.0V (Lipo) setzen, Drehencoder aktivieren -> "So" funktioniert er aber erstmal wieder... Klaus.
https://www.ebay.de/itm/363114289831 bin auch bei Ebay fündig geworden, sowas scheint mir geeigneter ;-)
...naja, die TP5400 Module sind halt der neueste shit, all in one :) Aber das soll hier nicht das Thema sein / werden... EDIT: Aber bei dem gezeigten kannst du Vout vll auf 9V hochkurbeln, das wäre ein...Vorteil? Naja, iwie auch nicht. Klaus.
:
Bearbeitet durch User
Klaus R. schrieb: > Warnschwelle auf 3.3V / 3.0V (Lipo) > setzen ...auf Seite 59 des pdf stehts - Hut ab, was ne SAUBERE Doku, da würde sich der Q-Ing in unserem laden drüber freuen :) EDIT: Erklärt mir aber noch nicht, wieso die LED des Displays nicht separat über einen R an +9V / +5V liegt - gibts da einen trickreichen Grund für? Klaus.
:
Bearbeitet durch User
...so langsam sind die Ideen, die ich mir aufgeschrieben hatte, umgesetzt - ich weiß nur noch nicht, wie ich PWM_out gestalte, ich würde es gerne wie beim GM328A über einen der freien Pins machen und nicht PB2 - lässt sich das einstellen, Karl Heinz? Ggf auch invertieren um den P-Mos / PNP direkt ansteuern zu können? Danke.
Klaus R. schrieb: > , ich würde > es gerne wie beim GM328A über einen der freien Pins machen und nicht PB2 > - lässt sich das einstellen, Karl Heinz? Da ein Hardware-Ausgang des Zählers benutzt wird, ist der Pin nicht leicht änderbar. Der gleiche Zähler kann nur PD3 als weiteren Ausgang nutzen. Man kann aber einen Ausgang ohne den 680 Ohm Widerstand (TP2) vorsehen, eventuell mit Treiber.
:
Bearbeitet durch User
Beitrag #6743695 wurde vom Autor gelöscht.
Karl-Heinz K. schrieb: > Da ein Hardware-Ausgang des Zählers benutzt wird, Hm, ok klar - das begrenzt die Möglichkeiten...Treiber wäre oblig, befürchte aber, dass der doch ggf das Testergebnis beeinflusst (im pdf steht "kapazitätsarm", das habe ich gelesen). Ich versuche es mal. Klaus.
...es kommt wie es kommen muss: ../lcd_hw_4_bit.S:231:16: error: macro "sbi" requires 2 arguments, but only 1 given Jmd eine Idee? Meine anderen Projekte übersetzen mit sbi noch, aber ich vermute hier eine vll andere / spezifischere Verwendung? AS 4.18 Build 716 Danke, Klaus.
...also, schaut man sich den Ablauf an, geht 1) aber 2) nicht? Setzt die aktuelle Trunk eine andere Toolkette voraus, weil "inline" die Argumente berechnet werden und mein alter Compiler das nicht rafft?
1 | 1) #define set_ce_low cbi _SFR_IO_ADDR(HW_LCD_CE_PORT), HW_LCD_CE_PIN |
2 | |
3 | 2) #define set_ce_output sbi (_SFR_IO_ADDR(HW_LCD_CE_PORT) - 1), HW_LCD_CE_PIN |
Danke, Klaus.
:
Bearbeitet durch User
Klaus R. schrieb: > ...es kommt wie es kommen muss: > > ../lcd_hw_4_bit.S:231:16: error: macro "sbi" requires 2 arguments, but > only 1 given Ohne die Makefile (wegen den gesetzten Optionen) ist der Fehler nicht nachvollziehbar. Vielleicht sind die Konstanten HW_LCD_CE_PORT bzw. HW_LCD_CE_PIN nicht mit Werten versorgt (sollten in config.h gesetzt werden).
...ändere ich 2) #define set_ce_output sbi (_SFR_IO_ADDR(HW_LCD_CE_PORT) - 1), HW_LCD_CE_PIN in 2) #define set_ce_output sbi _SFR_IO_ADDR(HW_LCD_CE_PORT), HW_LCD_CE_PIN läuft er durch, also kann es daran nicht liegen sondern muss an dem ( ... -1) liegen - meine naive Meinung. Aber dann schmiert er ganz am Ende mit irgend einem anderen Fehler ab beim Linken. Schau ich morgen mal... Ist wie immer etwas doof wenn die HW steht und die SW nicht laufen will, aber ich hatte es ehrlich gesagt schon befürchtet, dass es da mit alter Toolkette Probleme geben könnte - wäre ja sonst auch zu einfach (denn ich will ja eigentlich nur die von dir genannten Optionen im makefile ändern und fertig...). Klaus.
Klaus R. schrieb: > aber ich hatte es ehrlich gesagt schon befürchtet, dass es da mit alter > Toolkette Probleme geben könnte Die Arduino IDE beinhaltet eine aktuelle Toolkette. Da fehlt nur das GNU make. Bei Windows wird normalerweise der Pfad zu den ausführbaren Programmen während der Installation in der PATH Variablen eingetragen. Man sollte aber die Pfad zur alten Toolkette aus der PATH Variablen austragen (deinstallieren?). Das GNU make hatte ich für meine Tests aus dem Cygwin64 Paket genommen.
Ihhh, Arduino... :) Es muss doch auch mit AS 4.18 möglich sein - aber, ja, das ist kein TT spezifisches Problem. Klaus.
Was macht "_SFR_IO_ADDR(HW_LCD_CE_PORT) - 1" mit -1 konkret? Kann ich das nicht anders ausdrücken, konventioneller? Danke.
Klaus R. schrieb: > as macht "_SFR_IO_ADDR(HW_LCD_CE_PORT) - 1" mit -1 konkret? Kann ich > das nicht anders ausdrücken, konventioneller? Bei den AVR Prozessoren ist das DataDirection Register immer ein Byte vor dem Port Register. Die "-1" wird verwendet um die Deklaration der DDR Adresse zu sparen. Sonst wird die config.h noch komplizierter.
...das dachte ich mir fast, aber genau so werde ich es tun und dann läuft das auch lean durch. Naja, bis zu dem Linker aber - du ahnst es - damit melde ich mich nochmal :) Danke!!!
...und schwupps läuft er durch - DDR ist übrigens in der config.h schon enthalten, oder? :) /* Chip Enable input */ #define HW_LCD_CE_DDR DDRB #define HW_LCD_CE_PORT PORTB #define HW_LCD_CE_PIN 3 Nun zum hoffentlich letzten Rätsel (einen expliziten Error weist er nicht aus, aber da fehlt mir die Erfahrung...): ../Obj/mega328_T3_T4_st7565/i2lcd.o: In function `i2lcd': (.text+0xa): relocation truncated to fit: R_AVR_13_PCREL against symbol `lcd_data' defined in .text.lcd_data section in ../Obj/mega328_T3_T4_st7565/lcd-routines.o ../Obj/mega328_T3_T4_st7565/i2lcd.o: In function `u2lcd': (.text+0x22): relocation truncated to fit: R_AVR_13_PCREL against symbol `lcd_string' defined in .text.lcd_string section in ../Obj/mega328_T3_T4_st7565/lcd-routines.o ../Obj/mega328_T3_T4_st7565/i2lcd.o: In function `lcd_space': (.text+0x2c): relocation truncated to fit: R_AVR_13_PCREL against symbol `lcd_data' defined in .text.lcd_data section in ../Obj/mega328_T3_T4_st7565/lcd-routines.o ../Obj/mega328_T3_T4_st7565/i2lcd.o: In function `lcd_minus': (.text+0x30): relocation truncated to fit: R_AVR_13_PCREL against symbol `lcd_data' defined in .text.lcd_data section in ../Obj/mega328_T3_T4_st7565/lcd-routines.o ../Obj/mega328_T3_T4_st7565/i2lcd.o: In function `lcd_equal': (.text+0x34): relocation truncated to fit: R_AVR_13_PCREL against symbol `lcd_data' defined in .text.lcd_data section in ../Obj/mega328_T3_T4_st7565/lcd-routines.o ../Obj/mega328_T3_T4_st7565/PinLayout.o: In function `PinLayout': (.text+0x12): relocation truncated to fit: R_AVR_13_PCREL against symbol `lcd_fix_string' defined in .text.lcd_fix_string section in ../Obj/mega328_T3_T4_st7565/lcd-routines.o ../Obj/mega328_T3_T4_st7565/PinLayout.o: In function `data_ipp': (.text+0x3a): relocation truncated to fit: R_AVR_13_PCREL against symbol `lcd_data' defined in .text.lcd_data section in ../Obj/mega328_T3_T4_st7565/lcd-routines.o ../Obj/mega328_T3_T4_st7565/PinLayout.o: In function `PinLayoutLine': (.text+0x66): relocation truncated to fit: R_AVR_13_PCREL against symbol `lcd_fix_string' defined in .text.lcd_fix_string section in ../Obj/mega328_T3_T4_st7565/lcd-routines.o ../Obj/mega328_T3_T4_st7565/PinLayout.o: In function `lloop1': (.text+0x6c): relocation truncated to fit: R_AVR_13_PCREL against symbol `lcd_testpin' defined in .text.lcd_testpin section in ../Obj/mega328_T3_T4_st7565/lcd-routines.o ../Obj/mega328_T3_T4_st7565/PinLayout.o: In function `ldata_ipp': (.text+0x94): relocation truncated to fit: R_AVR_13_PCREL against symbol `lcd_data' defined in .text.lcd_data section in ../Obj/mega328_T3_T4_st7565/lcd-routines.o ../Obj/mega328_T3_T4_st7565/RvalOut.o: In function `RvalOut': (.text+0x38): additional relocation overflows omitted from the output make: *** [../Obj/mega328_T3_T4_st7565/mega328_T3_T4_st7565.elf] Error 1 Build failed with 1 errors and 1 warnings... Klaus.
Klaus R. schrieb: > Nun zum hoffentlich letzten Rätsel (einen expliziten Error weist er > nicht aus, aber da fehlt mir die Erfahrung...): Da vermute ich einen Speicher-Überlauf. Die älteren Compiler haben nicht so gut optimiert, dann wird das Programm vielleicht zu groß. Da kann man versuchsweise speicherintensive Optionen wie WITH_SamplingADC in der Makefile deaktivieren.
Karl-Heinz K. schrieb: > speicherintensive Optionen wie WITH_SamplingADC Hm - nur das zu ändern hat es nicht gebracht, aber wäre ja auch doof drauf zu verzichten. Hätte nicht gedacht, dass der TT auf einem 328p AS 4.18 an seine Gremnzen bringt - schade! Klaus.
Klaus R. schrieb: > Hm - nur das zu ändern hat es nicht gebracht, aber wäre ja auch doof > drauf zu verzichten. Vielleicht kannst Du die Makefile entweder hier veröffentlichen oder an meine Email schicken. Dann kann ich testen, ob es mit avr-ggc Version 5.4.0 klappt.
Super, Danke...das war auch fast meine Hoffnung, dass mir da jmd aushilft - ich bereite es vor und lade es hoch... Klaus.
Hallo Karl-Heinz, hier das makefile mit CFLAGS += -DWITH_ROTARY_SWITCH=2 CFLAGS += -DBAT_POOR=3000 # Voltage divider for battery voltage measurement (R1+R2)/R2 = (10k+10k) / 10k = 2/1 CFLAGS += -DBAT_NUMERATOR=2 CFLAGS += -DBAT_DENOMINATOR=1 Leider weiß ich nicht, ob mein Drehencoder mit der Basiseinstellung optimal läuft - das hätte ich natürlich gerne selber einfach ausprobiert. EDIT: Der Drehencoder schaltet "zwischen" den Raststellungen, aber die sind tw etwas ausgeleiert und daher kommt es auch in der Raststellung tw zu Kontakt - aber die Anzahl der Raststellungen und Impulse ist gleich, ergo vermute ich "2" passt. Danke, Klaus.
:
Bearbeitet durch User
Klaus R. schrieb: > hier das makefile Das Ergebnis mit aktuellem avr-gcc (Linux Mint) ist: AVR Memory Usage Device: atmega328p Program: 32088 bytes (97.9% Full) (.text + .data + .bootloader) Data: 198 bytes (9.7% Full) (.data + .bss + .noinit) EEPROM: 901 bytes (88.0% Full) (.eeprom) Die .hex und .eep habe ich angehängt!
Klaus R. schrieb: > hier das makefile Da hatte ich wohl ein falsches Makefile erwischt. Beim Download wurde die Makefile in Makefile(1) umbenannt, weil schon ein Makefile existierte. Hier jetzt das richtige Ergebnis: AVR Memory Usage Device: atmega328p Program: 30948 bytes (94.4% Full) (.text + .data + .bootloader) Data: 195 bytes (9.5% Full) (.data + .bss + .noinit) EEPROM: 880 bytes (85.9% Full) (.eeprom)
I had a similar problem finally resolved. I don’t think using two arduino unos was working for me I don’t know why. So I bought an USBasp as the ISP programmer and the arduino uno as the target to flash the fuse hex and epp. I switched over from avrdudeprog33 to avrdudess2.3-portable. Not sure if I blame the later for some issues or just my stupidity for bricking a couple of atmega328PUs by changing to a wrong fuse bit. I fixed the bricked 328PU using atmel AVR dragon sitting around for 5 years of no use. I didn’t realize it has an HVPP mode to allow me to get to the fuse bits and fix them that way to unbrick the MCUs. There is an arduino shield available also to do the same thing for a fraction of the cost. I still find it odd that the ISP pins from the USBasp to the ISP pins on the arduino uno is not enough power to do the flashing so I power the target arduino with a 5 volt adapter. I like the newest software v1.13 instead of fixed f-generator frequencies on the default units firmware I believe v1.12, you can now use the rotary knob in the MG328A to get the exact frequency you want.
:
Bearbeitet durch User
@Derri (Marcel D) You said you have the same model as I GM328A also bought from Amazon recently. Did you modify the trace to get the f-generator to output not sure if later models were fixed for this or maybe v1.13 fixes this issue or not link below showing a picture of the issue and the fix. https://dragaosemchama.com/en/2019/04/gm328a-reverse-engineering-new-firmware-and-tetris/
:
Bearbeitet durch User
Ronald G. schrieb: > @Derri (Marcel D) > > You said you have the same model as I GM328A also bought from Amazon > recently. Did you modify the trace to get the f-generator to output not > sure if later models were fixed for this or maybe v1.13 fixes this issue > or not link below showing a picture of the issue and the fix. > > > https://dragaosemchama.com/en/2019/04/gm328a-reverse-engineering-new-firmware-and-tetris/ My GM328A is the same as the one in the figure 2.24 in the manual "ttester.pdf" from the github repository (see my post #6740701 dated 28.06.2021 11:38). I bought it maybe 4 years ago. It is a kit version with through hole components, not SMD components like the one on the page that you mention. So the PCB is not the same (see attached picture). The f-generator works without any trace modification. But now, after close inspection I have found a via hole in the middle of the PCB trace going from the ZIF socket to the frequency output terminal (see attached picture, pointed by the arrow). But since the trace is wide enough, the connection is not broken. So it seems that this mysterious via hole is an old bug of the PCB design that has never been corrected and has made it to the latest updates. It explains why some testers of this type are defective and others are not, depending on the trace width and the precision of the via placing.
Marcel D. schrieb: > So it seems that this mysterious via hole is an old bug of the PCB > design that has never been corrected and has made it to the latest > updates. It explains why some testers of this type are defective and > others are not, depending on the trace width and the precision of the > via placing. No, no, no, no! The mysterious via connects the test pin 2 to the protective diode array SVR5-04, a 6 pin SMD device just beside it. It's not a bug, but a feature. Silly me! derri
Karl-Heinz K. schrieb: > Da hatte ich wohl ein falsches Makefile erwischt. Beim Download wurde > die Makefile in Makefile(1) umbenannt, weil schon ein Makefile > existierte. > Hier jetzt das richtige Ergebnis: Danke, Karl-Heinz - bin noch nicht dazu gekommen, hoffe es Sonntag testen zu können! Klaus.
Hallo Karl-Heinz, leider bleibt mit deinem hex die Anzeige "leer"...flashen läuft aber durch. Flashe ich auf den alten Stand zurück, ist wieder alles iO - war iwie zu erwarten :/ EDIT: Mit deinem ersten, falsch generierten file bleibts auch "leer"...merkwürdig. Gruß, Klaus.
:
Bearbeitet durch User
...so, habe die trunk zum laufen gebracht, compiliert und nun läuft die (eigene) hex auch auf dem Tester und alles geht (LiPo Spgsanzeige, Drehencoder), wie es soll. Gruß, Klaus.
Klaus R. schrieb: > leider bleibt mit deinem hex die Anzeige "leer"... Klaus R. schrieb: > ...so, habe die trunk zum laufen gebracht, compiliert und nun läuft die > (eigene) hex auch auf dem Tester und alles geht Das ist aber etwas seltsam. Ich bin bei dem zweiten Beitrag (#6746708) sicher, daß ich die richtige Makefile verwendet habe und auch die richtigen .hex und .eep Dateien hochgeladen hatte. Wenn man die Makefile zum Flashen verwendet, kann man die Dateien ohne Neukompilierung nur mit "make flash ; make eeprom" zum ATmega328 schicken. Nur so kann man also "fremde" Daten zum ATmega328 schicken, vorausgesetzt der Name entspricht dem Projektnamen (hier: mega328_T3_T4_st7565). Mit "make upload" wird vor dem Flashen generell neu kompiliert. In beiden Fällen kann man aber die Daten des ATmega zusätzlich noch einmal mit "make verify" kontrollieren. Bei vorherigem "make upload" sind die fremden Daten aber durch die Neukompilation schon überschrieben.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.