Hallo Roland Die 1.13k kann meines Erachtens nur mit großen Schwierigkeiten in Windows kompiliert werden, einige Zeit zurück habe ich im Forum ein Vorschlag gemacht für ein linux mint stick, das hat leider nicht geklappt bei derjenige der es versucht hat mit mint 20, mir ist erst später eingefallen das nicht alle mint Versionen funktionieren. Einziges Problem mit der 19 Version ist das man für avrdude als Root muß starten. Viel Erfolg wenn du es Versuchen willst Gruß Leon Bitte keine negative Bemerkungen von denjenigen die mein Vorschlag nicht begeistern kann.
Roland B. schrieb: > Was könnte noch die Fehlerursache sein ? Das sieht auf jeden Fall nach zu viel Flash-Speicherbedarf aus. Die Vielzahl an Funktionen, die über die Makefile angewählt wurden, führt zusammen mit dem Farbdisplay zu einem großen Speicherbedarf. Man braucht entweder einen besser optimierenden C-Kompiler oder muß in der Makefile Funktionen abwählen (z.B. WITH_SamplingADC). Der avr-gcc aus der WinAVR Umgebung ist sehr alt und optimiert sehr schlecht. Der C-Kompiler (avr-gcc) aus der Arduino Umgebung sollte aber ziemlich aktuell sein und eine gute Optimierung erzielen. Die WinAVR Umgebung ist nach meiner Meinung nicht erforderlich. Man man eben so gut mit einem Terminal Fenster über Kommandos in das mega328_color_kit Verzeichnis wechseln (mit dem Change Directory, cd Kommando) und einfach make aufrufen. Natürlich muß das Verzeichnis der Kommandos der Arduino Umgebung in der PATH Variablen von Windows eingetragen sein (C:\Arduino\hardware\tools\avr\bin), damit die Programme auch gefunden werden. Es fehlt aber nach meinem Kenntnisstand das make.exe Programm in der Arduino Umgebung, das avrdude.exe Programm ist dagegen vorhanden. Das avrdude Programm wird mit einem "make upload" oder "make program" benötigt, wenn das programm zum ATmega328 downgeloaded werden soll. Das fehlende make.exe Programm kann aber über das Cygwin Paket installiert werden.
Hallo @ Leon Danke für diesen Weg- leider kann ich mich mit Linux nicht erwärmen. Habe es schon mehrmals angegangen- @ Karl-Heinz Nach Abwählen von zwei weiteren Optionen leider wieder das gleiche Ergebnis mit "Error:2".Habe auch andere Konfigurationen mit unnötigen Optinen abgewählt- das gleiche Ergebnis. Fast glaube ich , daß mein Windows10 x64 dafür nicht geeignet ist. Hat einer der Tester-Freunde diese Kombination und könnte seine Erfahrungen mitteilen? Viele Grüsse Roland
Hallo Der Tester misst keine Spule auf einem ferritring von 1,7uH Er zeigt nur an es wäre ein Widerstand. Ist das normal?
Roland B. schrieb: > Was könnte noch die Fehlerursache sein ? ... ev. solltest Du nochmal alles "von vorn" beginnen: zuerst was alles jetzt von Vorversuchen noch da ist löschen! 1.) Beginn mit WinAVR-20100110-install. 2.) Füge den Patch von Karl-Heinz avrdude4WinAVR hinzu. 3.) Installiere arduino-1.8.13-windows. 4.) Füge aus dem Installationsverzeichnis *C:\Program Files (x86)\Arduino\hardware\tools\avr alle Ordner und Dateien in Dein Verzeichnis WinAVR-20100110 ein. 5.) Zuletzt noch die zwei Dateien msys-1.0.dll und rm.exe in das Verzeichnis WinAVR-20100110\utils\bin kopieren (vorhandene vorher umbenennen oder überschreiben), womit dann der Compiler ordentlich funktionieren sollte. Im Anhang das System-Info meines PC und die meine WinAVR-Struktur Gruß Horst
Tom schrieb: > zeigt nur an es wäre ein Widerstand. Hallo Tom, welchen Tester mit welchem Firmwarestand? Hast Du im Makefile "WITH_SamplingADC = 1" freigeschaltet und den Parallel-Kondensator benutzt? Gruß Horst
Roland B. schrieb: > leider kann ich mich mit Linux nicht erwärmen. Roland B. schrieb: > daß mein Windows10 x64 dafür nicht geeignet ist. Ohne Worte
Tom schrieb: > Der Tester misst keine Spule auf einem ferritring von 1,7uH > Er zeigt nur an es wäre ein Widerstand. Ist das normal? Mit der direkten Messung von Spulen können Induktivitäten erst ab 10µH erkannt werden. Nur mit der SamplingADC Methode von Pieter-Tjerk können kleinere Induktivitäten gemessen werden. Die Meßmethode benutzt dabei ein völlig anderes Verfahren. Es wird mit einem parallel geschalteten Kondensator ein Schwingkreis gebildet und aus der Resonanzfrequenz die Induktivität berechnet. Die Kapazität des parallel geschalteten Kondensators muß dazu bekannt sein. Deswegen wird als letzter Schritt der Kalibration die Kapazität des Testkondensators gemessen. Natürlich muß auch genau dieser Kondensator (10nF-30nF) der Spule parallel geschaltet werden. Aus dem Abklingverhalten des Schwingkreises kann dann übrigens auch eine Güte berechnet werden. Deshalb ist dieses Verfahren auch für Spulen mit mehr als 10µH interessant. Bei der Messung wird übrigens automatisch erkannt, ob ein Kondensator parallel geschaltet ist oder nicht.
Hallo Horst und an alle anderen Tester-Freunde Vielen Dank für die nochmalige Anleitung. WinAVR wurde jedes Mal nach einem vergeblichen Versuch de- und danach wieder neu installiert. Nachdem akribisch alle Punkte abgearbeitet wurden - wieder Fehlermeldungen (s. Anhang). Es wurden eine map und eine hex erzeugt - eep fehlt- obwohl in der makefile gewählt. @ Peter War der 1. oder der 2. Punkt gemeint? Der 2. drückt nur die Verzweiflung aus, weil mir nichts Neues mehr einfällt. Gruss Roland
Nachtrag zu WinAVR auf Win10-Rechnern: Im Anhang jeweils ein Bildschirm-Auszug der Compiler-Ergebnisse vom Win10- und vom Win7-Rechner. Erkennbar der Geschwindigkeitsvorteil der Win10-Installation gegenüber der des Win7-Rechners, welcher von der Hardware-Ausstattung sogar der neuere und schnellere Rechner ist!?! Auf dem 7er Rechner hab ich die gleichen Daten zum Vergleich auch nochmal mit AVRDUDESS gebrannt. Gruß Horst
Roland B. schrieb: > Es wurden eine map und eine hex erzeugt - > eep fehlt- obwohl in der makefile gewählt. Um der Ursache überhaupt näher zu kommen, kann man die Versionsnummern der beteiligten Programme (make.exe, avr-gcc.exe und avr-objdump.exe) überprüfen. Auf dem Windows Terminal Fenster kann man dazu die Befehle "avr-gcc --version", "avr-objdump --version" und "make --version" eingeben (natürlich ohne die "-Zeichen). Bei mir hat auf dem Windows10 avr-gcc die Version 7.3.0 , avr-objcopy die Version 2.26.2160125 und make ist eine GNU Version mit der Nummer 4.3! Mit diesen Programmversionen läuft die Erstellung von .hex und .eep ohne Fehlermeldung. Wenn das Cygwin Paket installiert ist, kann man auch mit dem Programm which prüfen, unter welchem Pfad die Programme abgelegt sind.
Hallo Horst Karl-Heinz und alle anderen Unterstützer Das ZIP-File mit der WinAVR-Installation hatte ich total übersehen. Erst Deine Frage ließ mich in den vorherigen Posts suchen. Darauf alles in meinem WinAVR-Ordner gelöscht, Deine Installation in diesen kopiert - und es funktioniert. Ich bekomme zwar wieder einen Fehler in der Ausgabe aber sowohl hex- als auch eep-File wurden erzeugt. Auch nach dem Brennen ok. Im Anhang noch die letzte Ausgabe. Vielen Dank. Gruss Roland
Karl-Heinz K. schrieb: > die Versionsnummern > der beteiligten Programme (make.exe, avr-gcc.exe und avr-objdump.exe) > überprüfen. ... meine Versionsnummern sind: Microsoft Windows [Version 10.0.19041.508] avr-gcc (GCC) 7.3.0 GNU objdump (GNU Binutils) 2.26.20160125 GNU Make 3.81 GNU Make 3.80 GNU Make 4.2.1 Funktioniert mit allen drei vorhandenen Make-Versionen mit immer den gleichen Compiler-Ergebnissen. Meine objdump Nummer ist allerdings etwas anders, statt 2.26.2160125 bei Dir ist meine 2.26.20160125? Aber wie es scheint, klappt es ja jetzt bei Roland. Gruß Horst
Roland B. schrieb: > bekomme zwar wieder einen Fehler in der Ausgabe ... hast Du den richtigen Prommer in das Makefile eingetragen?
Horst O. schrieb: > statt 2.26.2160125 bei Dir ist meine 2.26.20160125? Tippfehler? statt 2.26.2160125 bei Dir ist meine 2.26. << Version 20160125 << Datum
Karl-Heinz K. schrieb: > avr-objcopy die Version 2.26.2160125 muß natürlich richtig heißen 2.26.20160125 !
Horst O. schrieb: > Roland B. schrieb: >> bekomme zwar wieder einen Fehler in der Ausgabe > > ... hast Du den richtigen Prommer in das Makefile eingetragen? Der richtige P. ist gesetzt, aber das dürfte keinen Einfluss beim Kompilieren haben -oder? Gebrannt wird mit AVRDUDESS. Gruss Roland
Roland B. schrieb: > richtige P. ist gesetzt ... der Compiler-Aufruf kann mit "Make All" oder "Program" gestartet werden. "Make All" compiliert nach Makefile - Vorgaben, erzeugt alle zugehörigen Dateien und endet dann. Der Start über "Program" ruft nach dem Erzeugen der Brenn-Dateien gleich AVRDUDE mit der nötigen Configuration auf und startet den Brennvorgang. Wenn hierzu Voraussetzungen fehlen (z.B falscher Pfad, Brenner nicht eingeschaltet oder nicht verbunden) kommt es zu Fehlermeldungen. Weiterhin Viel Freude beim Hobby. Gruß Horst
Hallo Horst, Du hast recht. Mir war der Unterschied zwischen "MakeAll" und "Program" nicht bekannt. Nach dem Kompilieren ohne Programmer gab es mit "MakeAll" keine Fehler mehr. Nochmals vielen Dank für den Support. Grüße Roland
Roland B. schrieb: > keine Fehler mehr. ... das ist gut! Jetzt kannst Du in dieser Umgebung ja auch die M-Software von Markus mal testen. Weiterhin viel Erfolg, Gruß Horst
Guten Abend allerseits, Nachdem ich jetzt so manche Windows Updates hinter mich gebracht habe, und fast jedes Mal die GNU avr-gcc Installation mühsam reparieren musste, habe ich mich entschieden, auf Karl-Heinz zu hören (Übrigens: auf Karl-Heinz Kübbeler sollte man immer hören ;-) und jetzt kompiliere ich das TT-Projekt unter WSL, will sagen Windows-Subsystem für Linux (z.Z. in der Version 1), siehe < https://docs.microsoft.com/de-de/windows/wsl/ > Das ist schnell installiert und einfach zu handhaben: WSL-Konsole starten, ins Verzeichnis (im Dateisystem von Windows!) des passenden Makefiles wechseln, "make" oder "make steril" eintippen und SSSSSST, fertig. Nur mit dem Programmieren des Prozessors hapert es (noch?), da WSL1 keine USB Schnittstellen kennt. Ich benutze deshalb zum Programmieren ein MiniPro mit der spezifischen Windows-App, die zu programmierenden Dateien legt WSL eh im Windows Quellverzeichnis ab. Das Gerät kann übrigens praktisch alles brennen, was es so gibt. Jetzt bin ich dabei, für AVR-Projekte einen älteren Rechner mit Ubuntu Linux 20.04 einzurichten. Die Arduino IDE läuft schon, und mit den Erfahrungen von WSL sollte auch das avr-gcc Paket keine große Hürde sein. Ich habe vor, Geany als Editor/IDE zu benutzen, aus diesem Programm kann man das Makefile öffnen und dann mit einem Mausklick make darauf loslassen. Das ist noch komfortabler als das veraltete WinAVR, und vor allen Dingen auf dem neuesten Stand. So, Feierabend für heute.
Marcel D. schrieb: > Nachdem ich jetzt so manche Windows Updates hinter mich gebracht habe, und fast jedes Mal die GNU avr-gcc Installation mühsam reparieren musste ... seit ca. 2 Jahren befasse ich mich jetzt mit diesem tollen Projekt hier, in dieser Zeit ist so einiges an Windows-Updates auf meinen Rechnern erfolgreich durchgeführt worden. Nicht einmal wurde hierdurch meine WinAVR Installation beeinträchtigt. Sie funktioniert bis heute. Auch bin ich den Ratschlägen von Karl-Heinz bezgl. der Erneuerung der Compiler-Umgebung gefolgt und habe dazu die passenden Dateien aus der Arduino-Software benutzt. Meine AVR-Umgebung erzeugt damit passende Dateien für meine div. Transistor(Componenten) Tester und ich bin damit sehr zufrieden. Jeder sollte hier nach seinen Bedürfnissen die für ihn jeweils passenden Betriebs-Systeme und Rechner verwenden. Wichtig ist, das in diesem Forum weiterhin allen so gute und freundliche Hilfe zuteil wird und wir uns daran erfreuen können. Dazu wünsche ich uns allen gute Gesundheit und Durchhaltevermögen in diesen momentan etwas schwierigeren Zeiten! Gruß Horst
Horst O. schrieb: > Marcel D. schrieb: > Nachdem ich jetzt so manche Windows Updates hinter mich gebracht habe, > und fast jedes Mal die GNU avr-gcc Installation mühsam reparieren musste Verstehe ich nicht. Karl-Heinz versucht Euch das Leben leichter zu machen und quetscht seit Jahren alles in den winzigen 328p, änderungen im MakeFile sind quasi Standard und ihr seid nur am meckern. Warum bequemt sich denn niemand mal eine Platine mit einem anderen µC zu machen, dann ist Platz und Ihr könnt Euch austoben. Aber nein, da wird rumgejammert das der Compiler in Windows nicht optimal arbeitet. Und auch das ist gefühlte 70x hier beschrieben. Mit Linux will niemand zurecht kommen. Warum baut denn niemand mal eine aktuelle ISO zusammen auf der schon alle läuft? Horst O. schrieb: > Jeder sollte hier nach seinen Bedürfnissen die für ihn jeweils passenden > Betriebs-Systeme und Rechner verwenden. Ja, aber Du siehst doch, das nicht mal das funktioniert, obwohl irgendwie 100x beschrieben. > Marcel D. schrieb: >> und fast jedes Mal die GNU avr-gcc Installation mühsam reparieren musste Man sieht aber doch, wenn man sich damit beschäftigt, es geht. > Marcel D. schrieb: >> VirtualBox und Linux. Halbe Stunde Arbeit und kostet vielleicht 10GB Platz. Ist sehr einfach.
:
Bearbeitet durch User
Peter ⛄ W. schrieb: > ... Warum baut denn niemand mal eine aktuelle ISO zusammen auf der schon alle läuft? > > > VirtualBox und Linux. Halbe Stunde Arbeit und kostet vielleicht 10GB > Platz. > Ist sehr einfach. Hallo Peter, auch eine Frage die bereits gestellt wurde! Deine Antwort im Fazit: Ist sehr einfach. Dann scheinst Du ja zu den Experten selbst zu gehören und könntest mal konstruktiv hier was beitragen und eben diese ISO-Datei jetzt liefern!!! Gruß Horst
Horst O. schrieb: > und eben diese ISO-Datei jetzt liefern!!! Aus welchem Grund sollte ich das tun? Bei mir läuft es. Bei Karl-Heinz ebenfalls. und ich bin mir sicher das wir beide nicht hexen können.
Horst O. schrieb: > und könntest mal konstruktiv hier was beitragen Das haben zig andere und ich in diesem Forum schon x-Mal getan. Man könnte zum Beispiel das Wiki mal aktualisieren, interessiert aber wohl niemanden mehr, ist ja einfacher andere machen zu lassen. derri z.B macht das seit es die erste Version gibt. Beitrag "Re: Transistortester AVR"
:
Bearbeitet durch User
Horst O. schrieb: > jedes Mal die GNU avr-gcc Installation mühsam reparieren musste ... Vielleicht liegt das daran, dass ich viel mit neuer Software herumspiele und deshalb auch mal was kaputtinstalliere. Aber geschenkt. Es ist gut zu wissen dass das gute alte WinAVR stabil läuft, wenn man es in Ruhe lässt. > Jeder sollte hier nach seinen Bedürfnissen die für ihn jeweils passenden Betriebs-Systeme und Rechner verwenden. Klar, sehe ich auch so. Ich wollte nur eine Alternative aufzeigen. > Wichtig ist, das in diesem Forum weiterhin allen so gute und freundliche Hilfe zuteil wird und wir uns daran erfreuen können. Da schliesse ich mich voll und ganz an! Im übrigen habe ich heute Abend meinen Ubuntu-Rechner noch mal überarbeitet, und Geany läuft jetzt wie geplant. Und wenn das Makefile in Geany geöffnet ist, startet der Compilerlauf entweder auf Knopfdruck (Shift+F9) oder mit 2 Mausklicks (da war ich wohl zu voreilig, als ich schrieb mit einem Klick). Ich habe die Installation dokumentiert, und wenn Interesse besteht, bin ich gerne bereit, einen entsprechenden Beitrag zu verfassen. Damit, wie gesagt, "Jeder hier nach seinen Bedürfnissen die für ihn jeweils passenden Betriebs-Systeme und Rechner verwenden kann". Bei mir läuft die Standard-Installation von GNU-avr-gcc also jetzt auch unter der grafischen Linux-Oberfläche. Gruss, Derri 8-)
Marcel D. schrieb: > Ich habe die Installation dokumentiert, und > wenn Interesse besteht, bin ich gerne bereit, einen entsprechenden > Beitrag zu verfassen. Hau das doch einfach in's Wiki, da gehört es hin. 5 Beiträge weiter und der Nächste fragt wie es geht. Oder damit auch Horst zufriedenist, mach' 'ne ISO oder ein .tar draus.
:
Bearbeitet durch User
Peter ⛄ W. schrieb: > Hau das doch einfach in's Wiki, da gehört es hin. Werd' ich machen, OK. Ein .tar wird's wohl kaum tun,oder? Es müssen ein paar Sachen installiert werden. Da genügt m. E. das Auspacken eines tar-Archivs nicht. Für eine ISO fehlt mir das Know-How. Aber die manuelle Installationsprozedur ist relativ einfach. Es reicht, Geany zu installieren (in aktuellen Ubuntu Distros ein Klacks), die Sourcen aus dem SVN in ein Unterverzeichnis in home zu kopieren und dann ein paar Kommandozeilen in der Bash einzutippen. Bei mir hat das ganze ca. eine halbe Stunde gedauert. Gruß, derri
Beitrag #6437659 wurde vom Autor gelöscht.
Da haste Dir ja was vor genommen. Marcel D. schrieb: > Ein .tar wird's wohl kaum tun,oder? Doch, einfach, so kann man prima Backups machen. Mit einem Live System booten, auspacken nach /dev/sdxx ,Grub installiern, fertig. grub-install /dev/sda Nur erklär' das mal einem Windows Nutzer. Marcel D. schrieb: > Für eine ISO fehlt mir das Know-How. Auch nicht wirklich kompliziert. Der "richtige" Weg: https://wiki.ubuntuusers.de/LiveCD_manuell_remastern/ Der einfachere Weg https://wiki.ubuntuusers.de/ISO_Master/ /Anhang !! Wichtig: Denke daran das Du den cache leerst und keine Passwörter hinterlaesst. Das ISO muss "sauber" sein. Also sowas wie Gast als root auf eine einzige Partition anlegen und Passwort "passwort". Kann ja dann jeder selbst aendern. Ist aber auch als ISO fuer windows Nutzer nicht so einfach. Einfachste wäre ein Linux in eine Virtuelle Maschine zu bauen. Das vdi file irgenwo hoch laden. Das kann dann jeder auf jedem System nutzen. Kopieren, starten, fertig. KUbuntu 20.04 LTS (live), frisch installiert braucht 10GB (9,21GB). Gepackt (zip) 3,56. Das musste ja irgendwo hochladen. Marcel D. schrieb: > Aber die manuelle Installationsprozedur ist relativ einfach. Es reicht, > Geany zu installieren Mach mal 'ne Anleitung, ich probiere das auf einem frischen System.
:
Bearbeitet durch User
Gibt's noch alternative Quellen für M644er Boards? Bei AliExpress sind alle ausverkauft (bis auf den Bohrmaschinenverkäufer).
Wilhelm K. schrieb: > Gibt's noch alternative Quellen für M644er Boards? ihhBähh 38.- vom freundlichen Chinesen.
Hardy F. schrieb: > Und was ist mit dem ? Ich will nicht unbedingt beim letzten Chinesen kaufen. Peter ⛄ W. schrieb: > ihhBähh 38.- vom freundlichen Chinesen. Freundlich aber unverschämt. Aber ich glaube es ist eh besser auf SMD zu verzichten, zwecks Modding/Reparatur. Ein ordentlich geätztes Board wäre aber nicht verkehrt. Ich finde aber keinen Bausatz mit 64KB MCU. Empfohlen wird oben ein M644 (da aktueller Stand), also kein M328 mehr. Wenn ich mir einen solchen Bausatz hole (https://www.aliexpress.com/item/32829086802.html), kann ich da einfach einen M644 drauf packen und/oder muss die Schaltung auch verändert werden?
:
Bearbeitet durch User
Wilhelm K. schrieb: > Freundlich aber unverschämt. Keine Arme, keine Kekse. Wilhelm K. schrieb: > kann ich da einfach > einen M644 drauf packen und/oder muss die Schaltung auch verändert > werden? Hat ca. 8 Sekunden suchen gekostet. /Anhang Peter ⛄ W. schrieb: > ist ja einfacher andere machen zu lassen.
Ja, habe ich verwechselt mit dem 324. Was mich vom Hiland zum TC1 bringt. Den soll es angeblich auch als 644 geben. Das wäre natürlich der Bringer und man könnte sich den nachträglichen MCU Wechsel sparen. Ich konnte aber bisher keinen finden. Gibt's da irgendwelche konkreten Merkmale, woran man die erkennen kann?
Wilhelm K. schrieb: > Den soll es angeblich auch als 644 geben. > ... meine kürzlich gelieferten TC-1 und T7 sind im innern absolut gleich und hatten auch beide den ATMega324PA eingebaut. Beide sind nun auf den ATMega644 umgerüstet und so modifiziert das die K-H Software 1.13 und auch die Markus Software 1.4x funktioniert. Gruß Horst
Und wenn der dort ausverkauft ist, gibt es ihn hier für ~19€: https://de.aliexpress.com/item/32933439013.html
Horst O. schrieb: > so modifiziert das die > K-H Software 1.13 und auch die Markus Software 1.4x funktioniert. ... die wichtigste Hardware-Modifikation beruht auf der TC-1-Mod von Markus, bei der das zusätzlich vorhandene Power-Control-IC durch eine kleine 2 Transistor Lochraster-Schaltung ersetzt wird. Nur so kann die "Standard-Software" auf diesen Clones erst wieder funktionieren. Die Firmware-Anpassungen der Karl-Heinz Software stützte sich auf Hinweisen vom EEV-Blog Mitglied indman. Vielen Dank dafür. Horst
Transistortester-lover schrieb: > Hier den Hiland M644 für ~15€ incl. Versandkosten: > https://de.aliexpress.com/i/32912063006.html Danke, anscheinend werden die tagesaktuell eingestellt (oder die Suchfunktion spinnt). Horst O. schrieb: > Beide sind nun auf den ATMega644 umgerüstet Ja, deinen Mod habe ich im eevblog schon gesehen. Genau da will ich hin. Notfalls hole ich mir den 644 auch separat. Wie hast Du den ausgelötet? Jeden SMD Fuß einzeln, der Reihe nach erhitzt/angehoben oder Heißluftpistole? Den neuen einlöten ist wahrscheinlich ein Kinderspiel. Hast Du die billigen Spannungsregler (74 oder 78 irgendwas) auch ausgewechselt? Horst O. schrieb: > ... die wichtigste Hardware-Modifikation beruht auf der TC-1-Mod von > Markus, bei der das zusätzlich vorhandene Power-Control-IC durch eine > kleine 2 Transistor Lochraster-Schaltung ersetzt wird. Nur so kann die > "Standard-Software" auf diesen Clones erst wieder funktionieren. Oder alternative U4 Firmware via UART.
:
Bearbeitet durch User
Peter ⛄ W. schrieb: > Mach mal 'ne Anleitung, ich probiere das auf einem frischen System. Ja, ist in Arbeit. Ich habe die Installation auf einem (fast) frischen Ubuntu 20.04 probeweise durchgeführt und, bis auf avrdude, auch getestet. Geany war bereits via Ubuntu-"Software" App installiert. Im Endeffekt läuft es auf ein halbes Dutzend "sudo apt ..." Kommandos in der bash hinaus. Habe inzwischen mein WSL (Windows Subsystem for Linux) auf Version 2 gebracht, und darin läuft die avr-gcc Toolchain wie geschmiert. Avrdude muss ich noch testen, aber ich bin skeptisch in Bezug auf die USB-Unterstützung. Mal sehen. Rechne mal gegen Ende der Woche mit einem Ergebnis. Gruss, derri
Horst O, du hattest hier deine 3 Geräte aufgelistet: Beitrag "Re: Transistortester AVR" Wie ist die ESR-Messgenauigkeit bei Kondensatoren? Gibt es da Unterschiede zwischen den 3 Geräten? Davon unabhängige Frage: Ich würde gerne Kondensatoren mit sehr niedrigen ESR weiterhin vergleichen können. Diese zeigen aber bei den üblichen Tester wie den T4 einfach .00 als ESR an. Welche Möglichkeiten gäbe es noch mit dem Transistortester?
Transistortester-lover schrieb: > Unterschiede zwischen den 3 Geräten ... prinzipiell sind immer (geringe) Unterschiede zu erwarten: 1. Die Bauteil-Toleranzen der an der Messung beteiligten Widerstände. 2. Die Toleranzen der Referenz-Spannungen, a) die interne, b) die externe, c) die Spannung des Betriebsspannungsreglers. 3. Unterschiede bei der Kalibrierung (z.B. Kontaktdruck der [ausgeleierten]ZIF Kontakte. 4. Programmversionen (Karl-Heinz 1.1x, Markus 1.4x) Die ESR-Messung in diesem niederohmigen Bereich wie generell Widerstandsbestimmung im Bereich von 10tel Ohm ist sehr schwierig und eigentlich mit dem Transistortester nur annähernd zu erfassen. Karl-Heinz hat zu dieser Thematik schon öfter geschrieben. Zu Deinem Vorhaben der Vergleichbarkeit: Schalte in eine der Messleitungen einen Dir bekannten Widerstand (ca. 0,5 Ohm) in Reihe, für die vergleichende Messung durch und subtrahiere den festen Wert. Mach mehrere Messungen, denn Du wirst feststellen, das die Werte streuen.
Wilhelm K. schrieb: > Wie hast Du den ausgelötet? Hallo Wilhelm, zuerst trenne ich die Lötpins direkt am TQFP-Gehäuse mit einem Teppichmesser ab. Jetzt kann ich die Pinreste von jedem einzelnen PAD ablöten. Anschließend kommt die Entfernung des überflüssigen Lötzinns mittels Endlötlitze von den Pads. Dann Säubern mit geeignetem Lösungsmittel, fixieren des Mega644 zunächst mit einem Eck-Pinn und dabei sorgfältig ausrichten, dann den gegenübeliegenden Pin anlöten, jetzt sind 's nur noch 42. Danach habe ich mit der gleichen Methode den 8poligen U4 entfernt und dort die schon vorher auf einem kleinen Stück Lochraster angefertigte 2Transistor-Lösung des TC-1-MOD von Markus angeschlossen. Vor den Arbeiten am Controller habe ich allerdings erst den Start-Taster entfernt. Seine Lötstellen auf der Platine haben den richtigen Abstand für die von anderen Clones schon bekannten Taster-Drehgeber. Der Dregeber benötigt für seinen GND-Anschluss noch eine kleine 1mm Bohrung für welche auf der Platine schon eine Markierung an der richtigen Stelle vorhanden ist. Weiter muß noch eine Leiterbahn vom Tasteranschluss zum Drehgeber-Anschluss durchtrennt werden und der andere Drehgeber-Anschluss auf Vorder-und Hinterseite der Platine von seinen jeweiligen 4 dünnen Masse-Verbindungen befreit werden. Von den Drehgeber-Anschlüssen führen je ein 1kOhm Widerstand zum VCC Anschluß und ein 10kOhm zu den Steuerpins des Controllers (PB5;Pin1 und PB6;Pin2). Zusätzlich habe ich seitlich im Gehäuse einen Durchbruch für drei weitere Anschlüsse vorgesehen, die den Ausgang (PD4;Pin13) des Frequenzgenerators bzw. PWM-Generators, den Eingang für die Frequenzmessung (PB0;Pin40) und eine GND-Verbindung zur Verfügung stellt. Gruß Horst P.S. Die Spannungsregler habe ich (noch) nicht getauscht.
:
Bearbeitet durch User
Beitrag #6440109 wurde vom Autor gelöscht.
Marcel D. schrieb: > Im Endeffekt läuft es auf ein halbes Dutzend "sudo apt ..." Kommandos in > der bash hinaus. Machste n Script zum Download. Oder installierst alles zusammen, also "sudo apt install A + B + C +... Marcel D. schrieb: > Habe inzwischen mein WSL (Windows Subsystem for Linux) auf Version 2 > gebracht Warum nimmst Du keine Virtuelle Maschine? https://www.virtualbox.org/ Das ist doch viel einfacher. Eine Datei kopieren und es laeuft auf allen Systemen. Versteif Dich nicht auf Windows 10. Was ist mit denen die Win XP,7 nutzen, Linux, oder OSX ? Versuch ein mini-Ubuntu mit irgendeiner einfachen Oberflaeche wie LXDE, dann bekommste das auf vielleicht 1GB gedrueckt. Marcel D. schrieb: > ich bin skeptisch in Bezug auf die > USB-Unterstützung. In einer VM laeft das. Ich check das mal grob und schreib Dir 'ne PN. Muss ja nicht hier sein.
Hallo zusammen, ich verliere langsam den Überblick der Varianten und Modifikationen :) Horst O. schrieb: > fixieren des Mega644 Sehe ich es richtig, ein LCR-T7 mit ATmega324P wird auf ATmega644 umgerüstet? Ist das dann ein LCR-TC1 oder nun M644? In welchem Bezug steht der TC1 Schaltplan. Sorry für die doofe Frage. Horst O. schrieb: > 2Transistor-Lösung des TC-1-MOD von Markus wo finde ich den Abschnitt? bzw. Unterschied zum STC15L104W. Ich habe hier einen unveränderten T7 mit IR, welche per default nicht geht. Das würde ich gerne ändern und entsprechend modden. Nur auf was... :) Danke schon mal.
Mister A. schrieb: > Hallo zusammen, > ich verliere langsam den Überblick der Varianten und Modifikationen :) Aktualisiert doch das Wiki mit Eurem Wissen. Das ist doch wichtig !!
Drüber geflogen und mal grob ruminstalliert. Die virtuelle Platte sollte so 15GB haben. Mache ich beim nächsten Test. Belegt sind ca. 7½GB Gepackt ist das File etwa 3,8GB gross. Wenn jeman weiss wo ich das hochladen kann...
:
Bearbeitet durch User
Horst O. schrieb: > ... meine kürzlich gelieferten TC-1 und T7 sind im innern absolut gleich > und hatten auch beide den ATMega324PA eingebaut. > > Beide sind nun auf den ATMega644 umgerüstet und so modifiziert das die > K-H Software 1.13 und auch die Markus Software 1.4x funktioniert. ... in meinem weiter oben auf dieser Seite befindlichen Beitrag schrieb ich es schon: TC-1 und T7 sind gleich, lediglich die äußere Bedruckung ist anders. Auch die Frontfolie ist anders: Der T7 hat für den Taster einen Durchbruch in der Folie, beim TC1 bedeckt die Folie den Taster. Ev. hat meine Schreibweise TC-1 statt TC1 zu Verwirrung geführt, es ist aber immer dann der "Multi-funktion Tester - TC1" gemeint. Wer seinen Tester modifizeiren will tut gut daran, die ausführlichen Dokumentationen von Karl-Heinz und Markus zu lesen: https://www.mikrocontroller.net/svnbrowser/transistortester/ Hier durch Klick auf Download GNU tarball das ganze Paket von Doku, Hardware, Software und bootloaders herunterladen und entpacken (z.B. mit 7-Zip) Gruß Horst
Horst O. schrieb: > Beide sind nun auf den ATMega644 umgerüstet Vielen Dank für den ausführlichen Worklog. Ich dachte schon, Du hättest mich übersehen. Ist gut geworden. 64K mit Farbdisplay. Kann man nicht kaufen... Mister A. schrieb: > ich verliere langsam den Überblick der Varianten und Modifikationen :) Vielleicht hilft diese Übersicht etwas (TableClonesEn.pdf). https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg3267562/#msg3267562 (zwei Posts runter scrollen. Das Forum ist etwas buggy). Die jeweiligen Hardwarefeatures kannst Du z.B. in der Anleitung (ctester-1.41m.pdf, Kapitel 7) nachschlagen. https://github.com/madires/Transistortester-Warehouse/tree/master/Documentation/German Ich schwanke derzeit zwischen GM328A(32K), Hiland644(64K) oder LCR-T7/TC-1(32K). Am besten gefällt mir vom Hardwarelayout eigentlich der GM328A. Lediglich die 32KB Speicher machen mir Sorgen. Ich weiß nicht, ob und wann man an dessen Grenzen stößt. Man liest meist, dass man dann einfach etwas ausschalten soll. Das will ich aber eigentlich nicht. Im Gegenteil, ich möchte noch IR dran haben und farbig soll es auch sein. Ich glaube, ich werfe erst mal den Compiler an (ja, Linux!), um ein Gefühl dafür zu bekommen, was da rein, bzw. nicht rein passt.
Wilhelm K. schrieb: > Vielleicht hilft diese Übersicht etwas (TableClonesEn.pdf). > https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg3267562/#msg3267562 Schon peinlich das man sich hier die Anleitung aus einem Australischen Forum holen muss.
Mister A. schrieb: > Ich habe hier einen unveränderten T7 mit IR, welche per default nicht > geht ... bedeutet das, Dein T7 arbeitet ansonsten korrekt, nur empfängt er keine Infrarot-Signale von beliebigen Fernbedienungen und zeigt deren Codierung? Falls dem so ist, sollte es genügen, den IR-Empfänger auszutauschen. Gruß Horst
Wilhelm K. schrieb: > Lediglich die 32KB Speicher machen mir Sorgen. Ich weiß > nicht, ob und wann man an dessen Grenzen stößt. Also mal ehrlch. Die Dinger kosten 15.-. Dann nimmt man halt zwei und die Sorgen sind weg. Seit mindestens 5 Jahren ist bekannt das der mega328p nicht ausreicht. Warum setzt sich denn niemand mal hin und baut das auf einen groesseren µC um? Die Eagle Layouts sind doch da, die Software ist offen und auf einem mega1280 (glaub ich) lief das vor zig Jahren schon. Wilhelm K. schrieb: > Ich weiß > nicht, ob und wann man an dessen Grenzen stößt. Der war vor 5 Jahren schon auf das letzte Bit ausgereizt.
Wilhelm K. schrieb: > ich möchte noch IR dran haben und farbig soll es > auch sein. ... im eevblog hat ja jemand seinen "Hiland 644" umgebaut, aber meines Erachtens führt das nicht zum Ziel, alle (mir) bisher bekannten Clones dieses Types haben diesen hFE-Fehler, was für mich auch der Grund war, mal den TC1 und T7 zu ordern, in der Hoffnung, einen mit Mega644 zu erwischen ... Wenn Du sicher sein willst, das wirklich alles läuft, bleibt mE nur der Selbstbau mit einem austauschbaren 40poler. Aber selbst da kannst Du auf Exemplare stoßen, die dieses Fehlverhalten zeigen. Ich habe insgesammt 6 Exemplare, davon hatten 3 die Endung 20U in der Bezeichnung und genau die machen diese Probleme auch. In den kommenden Tagen werde ich mal den ATmega 1284 auf meinem Lochraster testen. Bis dahin, Gruß Horst
Ich habe eine kleine VM für Windows erstellt (VirtualBox). Man arbeitet nur mit der Shell und Samba. https://dl.dropboxusercontent.com/s/cig509t8be53f68/AlpineAVR-VirtualBox-Maniaxx-v1.0.1.7z (69MB) Die VM benötigt das Standard Host-only Netz (192.168.56.0/24). Die Gast IP ist fest (192.168.56.3). Toolchain ist vorinstalliert. Einen Patch für die alten Atmel binutils-avr (mit gepatchter 'avr-size') habe ich nicht gefunden. Daher müssen derzeit manuell im Makefile die avr-size custom Parameter entfernt werden (habe ich dabei geschrieben). Wenn nötig, kann man da evtl. was machen. Erst mal schauen, ob das überhaupt jemanden interessiert.
:
Bearbeitet durch User
Wilhelm K. schrieb: > Ich habe eine kleine VM für Windows erstellt Lieb gemeint, aber meinst du ein klickibunti Windows Nutzer, der "mal eben" ein Update machen möchte, will sich damit auseiandersetzen? Es geht doch drum es einfach zu machen.
Horst O. schrieb: > Mister A. schrieb: >> Ich habe hier einen unveränderten T7 mit IR, welche per default nicht >> geht > > ... bedeutet das, Dein T7 arbeitet ansonsten korrekt, nur empfängt er > keine Infrarot-Signale von beliebigen Fernbedienungen und zeigt deren > Codierung? > > Falls dem so ist, sollte es genügen, den IR-Empfänger auszutauschen. > > Gruß Horst Richtig. Funktioniert astrein, nur der IR wollte noch nie was erkennen. Darauf kommt man nicht, dass er schon neu kaputt war :) Danke für den Tipp, das hilft.
Horst O. schrieb: > In den kommenden Tagen werde ich mal den ATmega 1284 auf meinem > Lochraster testen. Ich habe gerade mal die config.h überflogen. Die ist standardmäßig auf den 328 ausgelegt und wenn ich das richtig sehe, ist fast alles aktiviert (Farbe, IR, alle Testmodi). Was genau spricht denn maßgebend für 64KB+ Versionen? Ich sehe in erster Linie Benutzer, die ihre Fonts nicht rein bekommen. Peter ⛄ W. schrieb: > Es geht doch drum es einfach zu machen. Das ist ja das Schöne, es ist einfach.
Zeitgemäß wäre ja ein Online-Codegenerator. Eine Webseite, auf der man einstellt welche Hardware man hat und welche Funktionen gewünscht sind, und dann rattert das Ding los und spuckt das passende Hexfile aus. Abhängigkeiten und Speicherüberläufe könnten ja automatisch berücksichtigt werden. (Mir ist vor einiger Zeit mal ein "Mbed"-Evalboard vor die Füße gefallen. Die hatten tatsächlich diese kranke Idee -- der Editor lief im Webbrauser und kompiliert wurde online. Big Brother is debugging you ;-)
Horst O. schrieb: > alle (mir) bisher bekannten Clones > dieses Types haben diesen hFE-Fehler Wo kann man dazu bitte näheres lesen ? Danke.
Wilhelm K. schrieb: > Peter ⛄ W. schrieb: >> Es geht doch drum es einfach zu machen. > Das ist ja das Schöne, es ist einfach. Da wirst Du dann wohl Recht haben. Spare ich mir die Arbeit. Soul E. schrieb: > Die hatten tatsächlich diese kranke Idee Findest Du?
:
Bearbeitet durch User
Peter ⛄ W. schrieb: > Da wirst Du dann wohl Recht haben. Spare ich mir die Arbeit. Ich habe kein Recht eingefordert, noch schließe ich aus, dass deine Umsetzung besser ist. Vielfalt ist in der OSS Freiheit und nicht Konkurrenz. Zumindest sehe ich das so.
:
Bearbeitet durch User
Beitrag #6442138 wurde vom Autor gelöscht.
Hardy F. schrieb: > Horst O. schrieb: >> alle (mir) bisher bekannten Clones >> dieses Types haben diesen hFE-Fehler > > Wo kann man dazu bitte näheres lesen ? > > Danke. Würde mich auch interessieren.
Hardy F. schrieb: > Wo kann man dazu bitte näheres lesen ? Horst O. schrieb: > Hallo hier ins Forum, > > ... beim Test der CT-Version 1.36 von Markus Reschke ist mir > aufgefallen, daß die hFE-Messung im Hiland 644M stark von der mit 328er > Clones abweicht. > > Zuerst vermutete ich Hardware-Probleme - aber nach Umstellung auf > TT-Version 1.13 von Karl-Heinz Kübbeler sind die Ergebnisse vergleichbar > mit denen der 328er Clones. > > Im Anhang ist eine Tabelle mit Messergebnissen versch. Transistoren auf > 4 Vergleichs-Geräten und den Werten eines (alten) Kurven-Schreibers zur > Plausibilitätsprüfung. > > Gruß Horst ... der erste Beitrag zu diesem Thema ist der link oben, zum einfachen finden noch das Datum: 21.07.2019 02:08 (bei mir springt die Foren-SW bei einer solchen Suche immer nur zum Seitenanfang und die Seiten sind lang...). Die Sache zieht sich dann noch über etliche Beiträge. Gruß Horst
Peter ⛄ W. schrieb: > Würde mich auch interessieren. ... Du hast doch selbst seinerzeit nach den beteiligten Transistoren und deren Daten gefragt, und später Dich noch über den "Doppelpost" beklagt ... Bei den 44poligen TQFP-Gehäusen des Mega644 die ich im "Hiland" und auch im T7 und TC1 eingebaut habe, waren sowol die Typen mit der 20 in der Bezeichnung als auch die ohne 20 von diesem Problem betroffen. Im eevblog forum hat jemand bei einem "Hiland"-Umbau auch dieses "Problem" https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg3230610/#msg3230610 Gruß Horst
:
Bearbeitet durch User
Wilhelm K. schrieb: > Ich habe gerade mal die config.h überflogen. Hallo Wilhelm, wenn Du mit der config.h den Tester anpasst, benutzt Du sicher die m-Software? Aber grade da gibt es so viele Zusatz-Funktionen, um die alle gleichzeitig zu nutzen, zumal mit größeren Color-Displays, wird auch der 644er schon langsam voll. Gruß Horst
Aber das sind meist nur Plus/Extra Versionen, erweiterte Freq-Bereiche, One-Wire, E-Checks und Servo. Von den deaktivierten Funktionen interessieren mich eigentlich nur 'SW_CAP_LEAKAGE' und 'HW_IR_RECEIVER'. Gut, die E-Checks sehen bestimmt cool aus, aber letztlich habe ich mir das schlimmer vorgestellt. Die wichtigsten Grundfunktionen stehen in nichts nach (sofern ich nichts übersehen habe). GM328A deactivated features (1.41m):
1 | //#define HW_FREQ_COUNTER_EXT
|
2 | //#define HW_EVENT_COUNTER
|
3 | //#define HW_IR_RECEIVER
|
4 | //#define SW_PWM_PLUS
|
5 | //#define SW_IR_RX_EXTRA
|
6 | //#define SW_IR_TRANSMITTER
|
7 | //#define SW_IR_TX_EXTRA
|
8 | //#define SW_SERVO
|
9 | //#define SW_DS18B20 (OneWire temperature sensor)
|
10 | //#define ONEWIRE_READ_ROM
|
11 | //#define SW_ONEWIRE_SCAN
|
12 | //#define SW_CAP_LEAKAGE (capacitor leakage check)
|
13 | //#define SW_MONITOR_R /* just R */
|
14 | //#define SW_MONITOR_C /* just C plus ESR */
|
15 | //#define SW_MONITOR_L /* just L */
|
16 | //#define SW_MONITOR_RCL /* R plus L, or C plus ESR */
|
17 | //#define SW_MONITOR_RL /* R plus L */
|
18 | //#define SW_DHTXX
|
19 | //#define SW_R_E24_5_T /* E24 5% tolerance, text */
|
20 | //#define SW_R_E24_5_CC /* E24 5% tolerance, color-code */
|
21 | //#define SW_R_E24_1_T /* E24 1% tolerance, text */
|
22 | //#define SW_R_E24_1_CC /* E24 1% tolerance, color-code */
|
23 | //#define SW_R_E96_T /* E96 1% tolerance, text */
|
24 | //#define SW_R_E96_CC /* E96 1% tolerance, color-code */
|
25 | //#define SW_C_E6_T /* E6 20% tolerance, text */
|
26 | //#define SW_C_E12_T /* E12 10% tolerance, text */
|
27 | //#define SW_L_E6_T /* E6 20% tolerance, text */
|
28 | //#define SW_L_E12_T /* E12 10% tolerance, text */
|
Wilhelm K. schrieb: > Die wichtigsten Grundfunktionen ... habe das grad mal compiliert: Device: atmega328 Program: 31704 bytes (96.8% Full) (.text + .data + .bootloader) Data: 257 bytes (12.5% Full) (.data + .bss + .noinit) EEPROM: 796 bytes (77.7% Full) (.eeprom) es ist mit 'SW_CAP_LEAKAGE' und 'HW_IR_RECEIVER' falls Du einen I/O Pin für den fest instal. IR-Receiver über hast, falls der 3pol. Mess-Eingang für IR-Rec. benutzt wird, lässt Du 'HW_IR_RECEIVER' weg und aktivierst '#define SW_IR_RECEIVER', das Compiler-Ergebnis ist dann gleich. Welchen Tester benutzt Du? Gruß Horst
:
Bearbeitet durch User
Mein obiges Beispiel bezieht sich auf den GM328A (ich habe noch keinen hier), also das unangetastete 'ComponentTester-1.41m.tgz' Archiv plus die "HW-Optionen" aus Kapitel 7.0.1 aus der 'ctester-1.41m.pdf'. Mit dem 'HW_IR_RECEIVER' habe ich mich vertan (sollte 'SW_IR_RECEIVER' sein). Kollidiert auch beim Kompilieren. Die reine, unangetastete config.h ergibt bei mir:
1 | text data bss dec hex filename |
2 | 30270 0 226 30496 7720 ComponentTester |
Mit den o.g. HW-Optionen für den GM328A (geplatzt):
1 | text data bss dec hex filename |
2 | 32661 0 235 32896 8080 ComponentTester |
Plus SW_CAP_LEAKAGE (geplatzt):
1 | text data bss dec hex filename |
2 | 33280 0 235 33515 82eb ComponentTester |
Das zweite ist recht knapp. Vielleicht kann ich da noch was mit Compilerflags oder anderer Toolchain raus holen (neu ist nicht immer besser). Sind die Werte bei dir ungefähr identisch? Du nimmst doch wahrscheinlich Ubuntu oder WinAVR. Ubuntu benutzt die alten binutils-avr 2.26, dafür mit Atmel Patches (daher auch die Prozentanzeige. Die Patches werden vom binutils Upstream abgelehnt). Meine Toolchain: gcc-avr-9.2.0 binutils-avr-2.35.1 avr-libc-2.0.0 Edit: Wenn ich link-time-optimization (für den obigen worst case, mit GM328A HW-Optionen und SW_CAP_LEAKAGE) einschalte, komme ich auf:
1 | text data bss dec hex filename |
2 | 32318 0 233 32551 7f27 ComponentTester |
Und das passt dann. Madires hat das im Makefile bereits eingetragen (CFLAGS += -flto), aber auskommentiert. Ich vermute mal, das funktioniert unter Windows nicht. Das sind in diesem Fall 964 Bytes weniger.
:
Bearbeitet durch User
Wilhelm K. schrieb: > Sind die Werte bei dir ungefähr identisch unveränderte m1.41 Version. Device: atmega328 Program: 26584 bytes (81.1% Full) (.text + .data + .bootloader) Data: 227 bytes (11.1% Full) (.data + .bss + .noinit) EEPROM: 747 bytes (72.9% Full) (.eeprom) Prozess beendet. Code:0 Dauer:00:08 ohne Extras m1.41 Version, ohne 'SW_OPTO_COUPLER', da zus. Adapter benötigt. Device: atmega328 Program: 31976 bytes (97.6% Full) (.text + .data + .bootloader) Data: 257 bytes (12.5% Full) (.data + .bss + .noinit) EEPROM: 806 bytes (78.7% Full) (.eeprom) Prozess beendet. Code:0 Dauer:00:07 ohne Extras m1.41 Version mit 'SW_OPTO_COUPLER' Device: atmega328 Program: 32876 bytes (100.3% Full) (.text + .data + .bootloader) Data: 257 bytes (12.5% Full) (.data + .bss + .noinit) EEPROM: 849 bytes (82.9% Full) (.eeprom) Meine Compiler-Umgebung ist WinAVR-20100110, avr-gcc-7.3.0 - erstellt so wie weiter oben auf dieser Seite beschrieben. Zum besseren Vergleich hänge ich mal meine Makefile, config.h und config_328.h als conf.zip an Gruß Horst
Mit deiner conf komme ich auf:
1 | text data bss dec hex filename |
2 | 35425 6 249 35680 8b60 CT_m_�_D18B20_COLOR_KIT |
Eher ernüchternd, passt ja nicht mal. Was sind denn deine Werte? Kein Wunder, dass Ubuntu noch die alten Versionen benutzt. Die rotzen wahrscheinlich alles weg.
:
Bearbeitet durch User
... guter Tip, mit 'CFLAGS += -flto' werden die Dateien nochmal kürzer! Mein 'avr-gcc-7.3.0' stammt aus der Arduino-Installation. Der Name stammte noch von einer beta Vorversion, kann man ja leicht ändern ;-) ohne Extras m1.41 Version mit 'SW_OPTO_COUPLER' Device: atmega328 Program: 32204 bytes (98.3% Full) (.text + .data + .bootloader) Data: 255 bytes (12.5% Full) (.data + .bss + .noinit) EEPROM: 849 bytes (82.9% Full) (.eeprom) Prozess beendet. Code:0 Dauer:00:08 Muß jetzt mal ins Bett. Gruß Horst
Horst O. schrieb: > unveränderte m1.41 Version. > Device: atmega328 > Program: 26584 bytes (81.1% Full) Sieht hier genau so (übel) aus:
1 | text data bss dec hex filename |
2 | 29234 0 224 29458 7312 ComponentTester |
Die alten Toolchains sind wahrscheinlich hochoptimiert von AVR. Kommen die neuen nicht mit. Oder ich mache irgendwas falsch. Ich teste morgen mal die Arduino Toolchain.
:
Bearbeitet durch User
Wilhelm K. schrieb: > Die alten Toolchains sind wahrscheinlich hochoptimiert von AVR ... hast Du denn nur den Linux-Rechner, wie Du siehst funktioniert die "alte" WinAVR-20100110 Umgebung, mit den Arduino-Files aufgepeppt immer noch sehr gut? Nochmal meine Ergebnisse der unveränderten m1.41, aber jetzt mit dem 'CFLAGS += -flto': Device: atmega328 Program: 26636 bytes (81.3% Full) (.text + .data + .bootloader) Data: 228 bytes (11.1% Full) (.data + .bss + .noinit) EEPROM: 757 bytes (73.9% Full) (.eeprom) Müder Gruß Horst
Horst O. schrieb: > 2Transistor-Lösung des TC-1-MOD von Markus Kannst du mal bitte dazu einen Link schicken oder ein pdf hochladen, ich finde dazu nichts.
Apollo M. schrieb: > Kannst du mal bitte dazu einen Link schicken oder ein pdf hochladen, ich > finde dazu nichts. https://github.com/madires/Transistortester-Warehouse/raw/master/Hardware/TC1-Mod.kicad.tgz https://github.com/madires/Transistortester-Warehouse/blob/master/Documentation/German/ctester-1.41m.pdf Man kann aber auch alternativ einfach eine andere Firmware via UART in den Controller flashen. https://github.com/atar-axis/tc1-u4
:
Bearbeitet durch User
SEHR informative Zusammenfassung! Meinen angestaubten LCR T1 muss ich dann auch mal mit neuen Funktionen und vor Allem dem Drehencoder versorgen... Danke!
Ich habe noch einige Compiler getestet (mit default config.h). GCC9 war übel (+3KB), GCC10 noch schlechter (noch mal +150bytes), GCC11 wird das AVR Backend in Zukunft gar nicht mehr unterstützen, llvm12-git +11KB (37KB). Der ist aber noch in früher Entwicklungsphase. Und zuletzt die Arduino Toolchain. Und die bringt 26580 Bytes. 4 Bytes weniger als WinAVR (vermutlich wegen binutils 2.35+Atmel). Arch hat einen aktuellen avr-size Patch. Horst O. schrieb: > Nochmal meine Ergebnisse der unveränderten m1.41, aber jetzt mit dem > 'CFLAGS += -flto': > > Device: atmega328 > Program: 26636 bytes (81.3% Full) Das ist aber diesmal nicht besser geworden (vorher hattest Du 26584 Bytes).
:
Bearbeitet durch User
Wilhelm K. schrieb: > Das ist aber diesmal nicht besser geworden ... ja, hab ich hinterher auch gesehen, aber wie auch immer, Du bist ja jetzt auf dem richtigen Weg - weiterhin viel Erfolg! Gruß Horst
Man kriegt auch sämtliche Plus/Extra/Fancy Klamotten in 32KB rein, wenn man 8x8 Fonts und 24x24 Symbols nimmt.
Wilhelm K. schrieb: > Man kriegt auch sämtliche Plus/Extra/Fancy Klamotten in 32KB rein, wenn > man 8x8 Fonts und 24x24 Symbols nimmt. ... das halte ich für unrealistisch: 8x8-24x24 Device: atmega328 Program: 40652 bytes (124.1% Full) (.text + .data + .bootloader) Data: 271 bytes (13.2% Full) (.data + .bss + .noinit) EEPROM: 1419 bytes (138.6% Full) (.eeprom) Prozess beendet. Code:0 Dauer:00:07 10x16-30x32 Device: atmega328 Program: 44122 bytes (134.6% Full) (.text + .data + .bootloader) Data: 271 bytes (13.2% Full) (.data + .bss + .noinit) EEPROM: 1419 bytes (138.6% Full) (.eeprom) Gruß Horst
:
Bearbeitet durch User
Ich meine ja nicht alles, sondern wirklich nur die extra/fancy Sachen (pwm fancy, e-checks, passive monitoring, cap leakage). Also jene Funktionen, die die Grundfunktionen erweitern. Der exotische Kram wie Servos, One-wire, usw. nicht. Dann komme ich auf 31.4KB. Zumindest ist genug Platz vorhanden, um alles wichtige (und mehr) rein zu bekommen. Irgendwo hieß es mal, 64KB sei "zeitgemäß" oder "aktueller Stand". Das sehe ich nicht so, da die 64KB Geräte neben ihres vernachlässigbaren Mehrspeichers relevantere Hardwaredefizite aufweisen. Ich sehe das wie Madires, der GM328A ist keine schlechte Wahl.
:
Bearbeitet durch User
Wie kann es sein, dass die beiden Werte kollidieren? Platz ist doch genug vorhanden. Alte Software? Ist zu dem LCR-4 Tester eigentlich ein Schaltbild verfügbar?
Hans B. schrieb: > Wie kann es sein, dass die beiden Werte kollidieren? > Platz ist doch genug vorhanden. Alte Software? > > Ist zu dem LCR-4 Tester eigentlich ein Schaltbild verfügbar? ... fehlerhafte Cina-Software. Schaltbilder im Anhang: Es sind Unterschiede in der Portbelegung zum Display. Neuere "T4" haben statt der zwei Dioden in der Spannungsversorgung zum Display einen Spannungsteiler aus 220 und 330 Ohm, um auf 3.3 Volt für's Anzeigemodul zu kommen. Es ist dazu angepasste Software in den bekannten Quellen. Gruß Horst
Hallo Horst, vielen Dank für die Schaltbilder. Das erste Schaltbild scheint zu passen, denn die beiden Kontaktreihen meines TEXTOOL-Sockels sind parallel geschaltet. Ein weiterer Softwarefehler: Zwei antiparallel geschaltete Dioden (1N4148) werden mit den jeweiligen korrekten Spannungen antiparallel in Serie dargestellt. Kann ja nicht sein, denn zwei antiparallel in Serie geschaltete 1N4148 bilden einen nahezu unendlich hohen Widerstand. > Es ist dazu angepasste Software in den bekannten Quellen. Mir sind keine Quellen bekannt. Zumal hier keine Softwareversion angezeigt wird. Oder kann man dem Tester die Softwareversion irgendwie entlocken? Würde mich zudem wundern, wenn die Chinesen aktuelle Geräte mit einer veralteten Software ausliefern würden. Denn das Gerät kam erst gestern "frisch" aus China. Gruß Hans
Horst O. schrieb: > die ausführlichen > Dokumentationen von Karl-Heinz und Markus zu lesen: > > https://www.mikrocontroller.net/svnbrowser/transistortester/ > > Hier durch Klick auf Download GNU tarball das ganze Paket von Doku, > Hardware, Software und bootloaders herunterladen und entpacken (z.B. mit > 7-Zip) ... hier findest Du die benötigten Unterlagen. Es ist allerdings nötig, die ISP-Schnittstelle beim "T4" nachzurüsten und die geeignete Software-Umgebung auf Deinem PC bereit zu stellen, wenn Du ein anderes (funktionierendes) Programm in den Tester laden willst. Gruß Horst
Hans B. schrieb: > Zwei antiparallel geschaltete Dioden > (1N4148) werden mit den jeweiligen korrekten Spannungen antiparallel in > Serie dargestellt. Kann ja nicht sein, denn zwei antiparallel in Serie > geschaltete 1N4148 bilden einen nahezu unendlich hohen Widerstand. Das verstehe ich jetzt leider nicht. Ich sehe da beide Male 2 Dioden von VCC nach VDD in Reihe. Also ist VDD = VCC - (2 * UF). Also je nach IF ca. 2 * 0,5 V bis 2 * 0,92 V.
Hendrik schrieb: > Das verstehe ich jetzt leider nicht. ... Hans schildert mE einen weiteren Software Fehler. Gruß Horst
Hans B. schrieb: > vielen Dank für die Schaltbilder. Das erste Schaltbild scheint zu > passen, denn die beiden Kontaktreihen meines TEXTOOL-Sockels sind > parallel geschaltet. Auweia Hans B. schrieb: > Ein weiterer Softwarefehler: Zwei antiparallel geschaltete Dioden > (1N4148) werden mit den jeweiligen korrekten Spannungen antiparallel in > Serie dargestellt. ? Hans B. schrieb: > Kann ja nicht sein, denn zwei antiparallel in Serie > geschaltete 1N4148 bilden einen nahezu unendlich hohen Widerstand. ? Kann mir mal jemand Bildchen malen, dass auch ich das verstehe ? Hans B. schrieb: > Würde mich zudem wundern, wenn die Chinesen aktuelle Geräte mit einer > veralteten Software ausliefern würden. Denn das Gerät kam erst gestern > "frisch" aus China. Ja nee, iss klar. Mal in's Wiki geguckt ? Hendrik schrieb: > Das verstehe ich jetzt leider nicht. Da bist Du nicht allein.
:
Bearbeitet durch User
Horst O. schrieb: > Hendrik schrieb: >> Das verstehe ich jetzt leider nicht. > > ... Hans schildert mE einen weiteren Software Fehler. > > Gruß Horst Ich finde das rotzfrech. Karl-Heinz reisst sich den Arsch auf und Ihr seid NUR am rummeckern. Ist die Software so schlimm, dass da ständig irgendwelche Fehler drin sind ? Denn genau so wird das hin gestellt und das ist gelinde gesagt Scheisse. Die Software ist OpenSource, warum behebt Ihr diesen Fehler dann nicht? ;Wenn es denn einer ist. Heisst ja mE also selbst kein Plan.
Peter ⛄ W. schrieb: > Ich finde das rotzfrech Hallo Peter, Du solltest Deine Ausdrucksweise zügeln! Niemand hier hat was gegen die Software von Karl-Heinz oder Markus gesagt. Die Arbeit dieser beiden Leistungsträger wird ganz im Gegenteil immer wieder gelobt und gewürdigt. Was denkst Du, warum es hier immer wieder darum geht, die K-H-oder M-Orginalsoftware in die billigen China-Clones zu brennen? In den Geräten steckt mehr und mehr eben nicht die "pure" K-H-SW, sondern in der Grafikausgabe und auch in den Funktionen von den Chinesen abgeänderte und oft fehlerbehaftete Software, die lediglich auf den älteren Versionen von Karl-Heinz beruhen und längst nicht alle Möglichkeiten mehr eingebaut haben. Im Beitrag von Hans B. zeigt er ja ein Bild von der "missglückten" Grafik. Solche Ausgaben wirst Du in keiner Software von Karl-Heinz oder Markus finden. Daher auch meine Aussage: ... fehlerhafte China-Software. Gruß Horst
Peter ⛄ W. schrieb: > Ist die Software so schlimm, dass da ständig > irgendwelche Fehler drin sind ? Der Fehler mit den Dioden sollte schon etwas genauer beschrieben werden. Die Diodenmessung hat schon einige Tücken weil auch zwei antiparallel geschaltete Dioden erkannt werden sollen. Die Darstellung des Ergebnis ist vielleicht nicht immer optimal. So wird beispielsweise eine Zenerdiode als zwei Dioden dargestellt. Zwei antiparallele Dioden können dann gemessen werden, wenn drei Testports angeschlossen sind oder es sich um Zenerdioden mit niedriger Spannung handelt. Die original "k" Software benutzt für die Darstellung der Dioden eine Pseudo-Grafik in einer Textzeile in der Form "1->|-3-|<-2" mit der Spannungsangabe ohne Vorzeichen in der nächsten Zeile. Einige chinesische Versionen haben versucht, für die Darstellung der Diodenmessung eine grafische Darstellung zu benutzen. Da bin ich natürlich nicht sicher, daß alle Fälle berücksichtigt sind.
Karl-Heinz K. schrieb: > Der Fehler mit den Dioden sollte schon etwas genauer beschrieben werden. Ganz einfach: Man kann nicht zwei Dioden gegeneinander in Serie verschaltet darstellen (angeschlossen an zwei Anschlusspins) und die beiden Spannungen dazu schreiben. Denn die beiden Spannungen kann man so nicht ermitteln. Real waren zwei 1N4148 antiparallel eingesteckt.
Karl-Heinz K. schrieb: > Die Darstellung des Ergebnis ist vielleicht nicht immer optimal. > So wird beispielsweise eine Zenerdiode als zwei Dioden dargestellt. Das habe ich hier auch gesehen (solange die Zenerspannung unter 5V liegt), das ist aber für mich trotzdem stimmig. Im Gegensatz zu dem oben beschriebenen Sachverhalt.
Hans B. schrieb: > Man kann nicht zwei Dioden gegeneinander in Serie > verschaltet darstellen (angeschlossen an zwei Anschlusspins) Das kommt bei der "k" Software auch nicht vor. Zwei Dioden werden immer mit 3 Anschlusspins dargestellt. Bei Zenerdioden oder zwei antiparallel geschalteten Dioden sind die äußeren Pinnummern gleich.
Karl-Heinz K. schrieb: > Der Fehler mit den Dioden sollte schon etwas genauer beschrieben werden. Hab' ich mich bisschen blöde ausgedrückt. Peter ⛄ W. schrieb: > Ist die Software so schlimm, dass da ständig > irgendwelche Fehler drin sind ? Denn genau so wird das hin gestellt.
Karl-Heinz K. schrieb: > 3 Anschlusspins dargestellt. Bei Zenerdioden oder zwei antiparallel > geschalteten Dioden sind die äußeren Pinnummern gleich. ...muss einem erstmal auffallen - vom UI besser wäre sie in der realen Schaltung darzustellen und dann D1 und D2 zu benennen und darunter entsprechend D1: … / D2: … anzugeben. Aber das ist natürlich konstruktive Kritik auf hohem Niveau :) Klaus.
Horst O. schrieb: > Du solltest Deine Ausdrucksweise zügeln! Sonst was ? Dir steht frei das einem Moderator zu melden, dazu befindet sich unten ein Link. extra dafür gemacht. /Edit Die Bewertungs-option ist Dein Ding, ne ?! Klaus R. schrieb: > besser wäre sie in der realen Schaltung darzustellen und dann D1 und D2 zu > benennen.... Vieles kann man machen. Aber welchen Sinn macht es antiparallel geschaltete Dioden zu messen? Hans B. schrieb: > Im Gegensatz zu dem oben beschriebenen Sachverhalt. Kannst Du bitte mal erklären was antiparallel in Serie geschaltete Dioden sein sollen? Vielleicht malst Du ein Bild, damit das verständlich ist.
:
Bearbeitet durch User
Ist das so schwer sich sowas vorzustellen? Siehe Anhang. Schön wäre natülich ein Screenshot des Bugs in der China-SW. Letztendlich bedeutet das doch aber, dass die Graphikbibliotheken der Chinageräte von denen hier im Forum (Karl-Heinz bzw Markus) abweichen?
Hans B. schrieb: > Denn die beiden Spannungen kann man so > nicht ermitteln. Es geht ja nicht darum, wie die Spannungen ermittelt werden sondern nur um eine Darstellung. So wie es dargestellt ist, ist es vielleicht nicht sehr übersichtlich. Das gebe ich unumwunden zu. Aber dann soll jemand einen Vorschlag machen, wie die verschiedenen Variationen mit einem 2x16 Zeichen Display dargestellt werden können. Natürlich kann man auf einem graphischen Display vieles anders machen. Aber die Darstellung der verschiedener Konstellationen kostet dann auf jeden Fall mehr Platz im Flash als die derzeitige Lösung. Wenn man verstanden hat, wie die Darstellung gemeint ist, ist auch die Zuordnung der Schwellspannungen (bzw. Zenerspannung) möglich.
Karl-Heinz K. schrieb: > mit einem 2x16 Zeichen Display dargestellt werden können. ...vll sollte man sich davon einfach mal verabschieden? Oder es dort dann halt "behilfsmäßig" lassen? Neue Möglichkeiten, neue Features - Willkommen in der Welt der Grafik-LCDs :) [für die, die meinen 2x16 sei "cool"] Klaus.
Soul E. schrieb: > Ist das so schwer sich sowas vorzustellen? Offensichtlich hat da manch einer seine Schwierigkeiten. > Siehe Anhang. Danke, genau das war gemeint. > Schön wäre natülich ein Screenshot des Bugs in der China-SW. OK, s. Foto. Man beachte auch die beiden Dioden im Textool-Sockel. Die beiden Reihen des Textool-Sockels sind hier parallel geschaltet. Peter ⛄ W. schrieb: > Aber welchen Sinn macht es antiparallel geschaltete Dioden zu messen? Vielleicht will man einfach mal alles ausprobieren?
Klaus R. schrieb: > für die, die meinen 2x16 sei > "cool" Die "k" Software ist die einzige Möglichkeit, eine aktuelle Software auf dem "Ur-Transistortester" von Markus Frejek zu installieren. Die Ur-Version hatte nun mal nur ein 2x16 Zeichen Text-Display. Auch heute noch braucht eine Variante mit 2x16 oder 4x20 Zeichen Display deutlich weniger Speicher als irgendeine Grafik-Version. So kann man den Speicher des Mega328 für mehr Testfunktionen nutzen. Der Speichermangel beim Mega328 wird bei Farb-Graphikdisplays besonders deutlich. Bisher habe ich mich dazu entschlossen, die Unterstützung für alte Versionen aufzugeben. Nach meinem Kenntnisstand wird der ATmega8 der Urversion und auch der ATmega168 bei der "m" Version nicht mehr unterstützt.
...Farbdisplays halte ich für unnötigen Overkill, außer man nutzt die Möglichkeiten sinnvoll - sehe da aber kaum Anwendungsfälle -> Braucht man aber nicht. Grafik LCD ist (erstmal) vollkommen ausreichend. Schön wäre natürlich wenn man die "netten" Zusatzfunktionen in einen 32er mit "normalem" Grafik-LCD bekäme, so als eierlegende Wollmilchsau für den Werkzeugkoffer bzw. im kleinen Heimlabor für "mal eben schnell" (bevor man auf der Maloche die großen Klopper nutzt) - V/A Messung würde dann evtl. noch fehlen...). Könnte ich mir sogar im (kleinen) Pultgehäuse mit LiPo gut vorstellen... Nun, ich schweife ab...aber das ist ja nicht ungewöhnlich hier :) Klaus.
LCD_GRAPHIC (mit FONT_8X8, SYMBOLS_24X24) braucht 3KB, LCD_COLOR 1KB. Ohne SW_SERVO, OneWire, SW_IR_RX_EXTRA, SW_IR_TX_EXTRA passt alles in 32K. Grafik und Farbe kosten demnach gerade mal 4KB (gegenüber LCD_TEXT). Mit großen Fonts und Symbolen 8KB.
:
Bearbeitet durch User
Soul E. schrieb: > Ist das so schwer sich sowas vorzustellen? Siehe Anhang. Ja ist es. Wo ist das denn antiparallel? Du hast das Bild doch selbst anti seriell benannt, also stell mich jetzt nicht al Vollpfosten hin. Hans B. schrieb: > Soul E. schrieb: >> Ist das so schwer sich sowas vorzustellen? > Offensichtlich hat da manch einer seine Schwierigkeiten. Nö, Antiparallel in Serie ist einfach Unsinn. Nächstes Mal richtig benennen, dann versteht man Dich auch. Daher hatte ich mindestens 3x nachgefragt und nicht nur ich. Karl-Heinz K. schrieb: > Der Fehler mit den Dioden sollte schon etwas genauer beschrieben werden. Hans B. schrieb: > Peter ⛄ W. schrieb: >> Aber welchen Sinn macht es antiparallel geschaltete Dioden zu messen? > Vielleicht will man einfach mal alles ausprobieren? Ist ja SO auch verständlich. Klaus R. schrieb: > ...Farbdisplays halte ich für unnötigen Overkill Nö, warum ? Fänd' ich cool.
:
Bearbeitet durch User
Hans hat zwar die falsche Formulierung erwischt (oder von seinem Telefon untergeschoben bekommen), aber es sollte doch klar sein was gemeint war. Karl-Heinz K. hat aber einen guten Grund für diese an sich falsche Darstellung der antiparallelen Konfiguration benannt: nämlich dann wenn man mit einer Zeile im Dotmatrix-Display auskommen muss. Der Chinese hatte jedoch die volle Graphik-Power zur Verfügung, der hätte es besser machen können.
Von Anzeige stand da nie was. Ist ja nu geklärt und alle sind glücklich. Soul E. schrieb: > Hans hat zwar die falsche Formulierung erwischt (oder von seinem Telefon Mag sein, dann kontrolliert man trotzdem was man abschickt und reagiert auf Nachfragen, dafür ist die Vorschau, Bildfunktion und das Forum da.
:
Bearbeitet durch User
Hans B. schrieb: > OK, s. Foto. Man beachte auch die beiden Dioden im Textool-Sockel. > Die beiden Reihen des Textool-Sockels sind hier parallel geschaltet. Der Fehler ist, daß der dritte Pin falsch ist. k bzw. m-Firmware geben das als 1 > 2 < 1 aus. Bei der modifizierten Firmware des Clone-Herstellers können wir leider nichts ändern, da wir den Source dafür nicht haben. Und über die Darstellung in Reihe kann man wunderbar streiten. Eine alternative Ausgabe für Grafikanzeigen ließe sich als Option einbauen. Ob das dann aber verständlicher oder übersichtlicher wird, ist eine andere Frage. Man kann es halt nicht allen recht machen. >:)
madires schrieb: > Bei der modifizierten Firmware des > Clone-Herstellers können wir leider nichts ändern, da wir den Source > dafür nicht haben. Wer bist denn Du ?
Peter ⛄ W. schrieb: > madires schrieb: >> Bei der modifizierten Firmware des >> Clone-Herstellers können wir leider nichts ändern, da wir den Source >> dafür nicht haben. > > Wer bist denn Du ? Das, mein Freund, ist der Autor der m-Software, wenn mich nicht alles täuscht. Derri
:
Bearbeitet durch User
Hans B. schrieb: > Peter ⛄ W. schrieb: >> Aber welchen Sinn macht es antiparallel geschaltete Dioden zu messen? > Vielleicht will man einfach mal alles ausprobieren? Im zweiten Bild 'ne Kiste (Hardware scheint gleich), die den Job besser macht. Gleiche Dioden, gleich gesteckt. Dafür kann die Kiste die Batteriespannung nicht vernünftig anzeigen (9V aus Konstanter). 7.7V statt 9V sind mal schon eine heftige Hausnummer. Das sollte besser gehen.
Da muss der chinesische Clone-Hersteller wohl mal den Batterie-Offset anpassen. Das Traurige am ganzen Thema ist, daß viele von denen die OSHW-Firmware modifizieren, den Source nicht veröffentlichen und das dann noch als eigenes Werk ausgeben. Ist zum Teil der chinesischen Kultur geschuldet, die ein anderes Verständnis zur Urheberschaft hat. Das Kopieren/Nachmachen wird als Ehrung des Originals und dessen Schöpfer betrachtet. Allerdings sollten sie sich trotzdem an internationale Normen halten, wenn sie global handeln. Auf der Projektseite gibt es deshalb einen freundlichen Text in Chinesisch, der darauf und auch auf ein paar andere Dinge hinweist. Bisher hat sich aber leider noch kein einziger der Clone-Hersteller in China gemeldet. TL;DR: Nimm die k oder m-Firmware.
Markus R. schrieb: > Nimm die k oder m-Firmware Was ist der Unterschied? Im Wiki habe ich nichts gefunden. Markus R. schrieb: > Allerdings sollten sie sich trotzdem an internationale > Normen halten, wenn sie global handeln. Wo kein Kläger da kein Richter. Massenklage bei deutschen ebay, ali und Amazon Händlern mal angefangen.
Peter ⛄ W. schrieb: > Wo kein Kläger da kein Richter. Massenklage bei deutschen ebay, ali und > Amazon Händlern mal angefangen. Es gibt auch keinen Klagegrund, da nicht klar ist, ob und wer Rechte besitzt. Also spart euch diesen immer wieder hochgewürgten Unfug.
Peter ⛄ W. schrieb: > Was ist der Unterschied? (zwischen "k" und "m") Die PDF Doku ist für die "k" Version geschrieben. Die aktuelle k-Version befindet sich im Archiv im Software/trunk Verzeichnis und hat Unterverzeichnisse mit angepasster Makefile für zahlreiche Hardware-Versionen. Ältere k-Versionen findet man im Verzeichnis Software/tags. Alle "m"-Versionen finded man im Software/Markus Ordner. In den tgz Dateien sind Informationen für die jeweiligen Erweiterungen und Abweichungen enthalten. Die "k"-Version unterstützt alle älteren Tester, auch solche mit ATmega8. Natürlich sind bei den Prozessoren mit weniger als 32k Speicher die Funktionen eingeschränkt. Die m-Version muß in der config.h an den jeweiligen Tester angepasst werden. Der Quellcode ist besser strukturiert und unterstützt nur ATmega328 oder ATmega644/1284 Prozessoren. Hier sind zahlreiche Erweiterungen wie der Test von IR-Fernbedienungen eingebaut worden. Für alle Erweiterungen und Abweichungen sollte man die README bzw. README.de Datei aus dem tgz Archiv der m-Version lesen.
Hallo Allerseits! Könnte mir bitte jemand kurz helfen? Ich habe vor einigen Jahren den Transistortester aus dieser Sammelbestellung aufgebaut: Beitrag "Sammelbestellung Transistortester" Das Teil lief die ganze Zeit ohne Probleme, für meinen Anwendungszweck ausreichend. Nun wollte ich mal Induktivitäten kleiner als mH messen und das funktionierte leider nicht so recht. Ich habe hier aber gelesen, dass es mit einer neuren Version wohl gehen soll. Also dachte ich, ich update mal die Software auf den letzten Stand für diese alte Hardware. Ich habe mir dazu die Dateien aus dem SVN heruntergeladen und die hex und eep aus dem Verzeichnis mega328_dogm auf den Controller gespielt. Das sollte ja eigentlich passen. Tut es aber nicht. Das Display zeigt nichts mehr an. Flashe ich die alte Version (die vorher drauf war) wieder drauf, geht alles wieder. Was mache ich falsch? Wenn es an den Dateien liegt, könnte mir bitte jemand die beiden Dateien neu kompilieren und schicken, oder hier posten? Ich stehe mit dem alten WinAVR etwas auf Kriegsfuß... Die Makefile-Optionen sollten wohl: CFLAGS += -DLCD_DOGM CFLAGS += -DSTRIP_GRID_BOARD # CFLAGS += -DWITH_UART sein... Achja, Prozessor ist ein ATMEGA328P Danke! Gruß, Helge
Hi Helge, hab das mal nach Deinen spärlichen Angaben kompiliert. Gruß Horst
Hallo Horst! Vielen Dank für die schnelle Hilfe, diese Version funktioniert :) Gruß, Helge
Helge T. schrieb: > diese Version funktioniert :) ... falls Du andere oder zusätzliche Optionen noch einfügen möchtest (es ist ja noch Platz), nutze das beigefügte Makefile und lade es hoch, dann kann ich nochmal nachbessern. Ebenso könnte ich Dir eine mit der Arduino Umgebung aufgepeppte WINAVR-Struktur zukommen lassen, damit Du auch damit wieder auf aktuellem Stand bist? Gruß Horst
Hallo Horst, ich hab mir mal das Makefile angesehen. Viel mehr kann man für die alte Hardware ja nicht mehr einschalten. Passt schon, danke! Bzgl. WinAVR: Ich pack mir das nochmal auf ein Windows in einer VM, um zu schauen, ob ich mir damait die Firmware für den Bauteiltester selbst kompilieren kann. Produktiv brauche ich das nicht (mehr) und für die zwei/drei mal, die ich was damit kompiliere, reicht das, wenn ich das in der VM machen kann. Da stört es dann auch nicht, wenn es noch unter Windows XP läuft ;) Weiter oben hattest Du ja schon mal einen Abzug vom WinAVR-Verzeichnis zum Download hochgespielt. Ich hab mir das mal runtergeladen, um zu sehen, wie sehr sich das dann von meiner WinAVR-Standard-Installation unterscheidet. Trotzdem nochmal vielen Dank für das Hilfsangebot! Gruß, Helge
Juri schrieb: > Es gibt auch keinen Klagegrund, da nicht klar ist, ob und wer Rechte > besitzt. > > Also spart euch diesen immer wieder hochgewürgten Unfug. Dafür hat man die Justiz erfunden. Und ist ein guter Gedanke, warum etwas ändern wenn alle Anderen es auch so machen. Ganz im Sinne des GNU-Projekts.
Hallo zusammen, endlich Zeit für geplante Projekte... Die letzte Version des TT aus Beitrag "Re: Transistortester AVR" Beitrag "Re: Transistortester AVR" soll bestückt werden. Die PCBs (old-papa Rev. 4b) scheinen noch ein paar Änderungen bekommen zu haben. Beim zusammenstellen der Einkaufsliste sind mir die Unterschiede aufgefallen. Getauft habe ich es nun folglich als Rev 4c. Gibt es dazu was dokumentiertes, oder kann mir jemand bei den Fragezeichen in beigefügter BOM helfen? Auf den Kopierer legen und durchleuchten könnte ich es frühestens in gut einer Woche. Bis dahin suche ich nach Ersatz für a) die Spannungsreferenz und b) den Charger und möchte die Bestellung langsam fertig machen. Die beiden Teile kosten ein Vermögen. Nun drehe ich an Alternativen (siehe aufgeführte Positionen in der BOM) was ich verbauen, zusammenlöten könnte.
Hallo zusammen. Sorry vielmals wenn die Frage schon gestellt wurde, aber der Thread ist wirklich extrem lang geworden und ich konnte in der Masse keine Infos zu dem Gerät finden: https://www.amazon.de/dp/B07MH3LPSZ/ Mir gefällt das Layout von dem extrem gut (kann da bestehende Messleitungen mit nutzen). Hat jemand das schonmal offen gehabt und kann eine Aussage dazu treffen ob man da die aktuelle Firmware flashen kann? Ist das überhaupt die hier diskutierte Firmware oder könnte das etwas ganz anderes sein?
Mister A. schrieb: > beigefügter BOM Was zum Geier ist BOM? Manuel schrieb: > ob man da die aktuelle Firmware flashen kann? Warum denn nicht ? Manuel schrieb: > Ist das überhaupt die hier diskutierte Firmware Ja sicher, die werden kaum was eigenes schreiben, ist doch einfacher wenn man kopieren kann. Manuel schrieb: > Mir gefällt das Layout von dem extrem gut Garnicht, ziemlich kitschig und nicht im Sinne des Erfinders. Allein diese Steckbuchsen....
Peter ⛄ W. schrieb: > Garnicht, ziemlich kitschig und nicht im Sinne des Erfinders. Allein > diese Steckbuchsen.... Die 4mm-Buchsen sind gerade was ich brauche und wegen der direkten Bauteile-Kontaktierung stimme ich zu. Muss ich testen wie mir das gefällt. Vielleicht ist das aber auch gar nicht so schlecht. Wenn die Federkraft ausreichend hoch ist, wäre das ja sogar einfacher. Man spart sich das Betätigen des Hebelchens.
...ne das wird nicht gut klappen. Aber das Pultgehäuse finde ich gut. Der ist halt auch nur "fast" perfekt, aber nah dran - da gebe ich dir Recht. Klaus.
Klaus R. schrieb: > Der ist halt auch nur "fast" perfekt, aber nah dran - da gebe ich dir > Recht. Hast Du den? Hast Du da schon mal rein geguckt?
...nein, leider nicht. Ich habe den LCR T4 und der ist iO. Nur suche ich länger schon nach einer Variante, die meine Wünsche erfüllt. Selber machen lohnt aber auch wieder nicht... Mir wäre wichtig: - Grafik LCD s/w - Pultgehäuse - LiPo integriert - Textool * - 4mm oder JST Buchsen für "eigene Kabel" - Gut erreichbare SMD Testfelder ("ganz vorne am Gehäuserand") * - Drehencoder * - IR Empfänger im textool einsetzbar *(?) - robuster und "etwas" leistungsfähiger Ausgang für FGen * *) so noch nicht in der Kombi gesehen... Klaus.
Klaus R. schrieb: > ...ne das wird nicht gut klappen. Aber das Pultgehäuse finde ich gut. > Der ist halt auch nur "fast" perfekt, aber nah dran - da gebe ich dir > Recht. Selbst wenn: So einen ZIF-Sockel kann ich ggf. auch nachrüsten wenn es denn nötig wird. Aber der erste Schritt wird in jedem Fall rauszufinden wie man die Firmware kompilieren muss das sie auf dem Gerät läuft. Was für Features ich dann ggf. nachrüste entscheide ich dann. Gruß Manuel
Klaus R. schrieb: > *) so noch nicht in der Kombi gesehen... Und was spricht dagegen das zu bauen? Asko hat mit Sicherheit noch die Eagle Dateien, Platinen kosten Pfennigskram und Gehäuse gibt es auch jede Menge. Diese Pinzette finde ich cool, sollte man aber irgendwie integrieren und nicht mit Steckern machen, sonst muss man das ja immer wieder abgleichen. Von den 4mm Buchsen halte ich aus dem Grund auch nichts. Das Gerät lässt sich so gut und einfach justieren, da wäre es schade die Funktion wegen der Buchsen "kaputt" zu machen.
Machen denn die Zuleitungen so viel aus, dass eine Neukalibrierung nötig wäre? Wenn dann wohl bestenfalls beim ESR und wenn ich den brauche, dann messe ich das entsprechende Bauteil direkt am Gerät. Oder man merkt sich wie viel man abziehen muss. Mache ich bei meinem Multimeter auch so wenn ich Widerstände messe. Die Messleitungen haben ja nicht 0 Ohm und einen Nullpunktabgleich hat mein Multimeter nicht. Ich benötige die SMD-Pinzette vor allem um diverse SMD-Kerkos zu sortieren. Aufschrift haben die ja nicht.
Ja! Die Messleitungen haben nicht nur einen Widerstand, sondern auch Kapazität und Induktivität. Zusätzlicher Widerstand kann um die 0.x Ohm sein, und Kapazität ist ca. 3pF pro 10cm Kabellänge. Die Induktiviät dürfte bei ein paar nH pro 10cm liegen, und ist damit vernachlässigbar klein.
Manuel schrieb: > Ich benötige die SMD-Pinzette vor allem um diverse SMD-Kerkos zu > sortieren. Aufschrift haben die ja nicht. Naja, dafür muss man ja nix abgleichen. Zumindest sollte mann dan die Leitungen einlöten und ordentliche Klemmen besorgen. Der freundliche Chinese bietet öfters 4-Wire-Klemmen für kleines Geld an, die sind ganz brauchbar. So "kennst" Du dann nach einer Weile Deine Werte. Schick' Asko mal 'ne PN, der freut sich wenn er helfen kann. Findest Du hier im Thread irgendwo.
:
Bearbeitet durch User
Also meine Agilent U1782B ist spezifiziert mit <0,7 pF offen und <1,2 µH geschlossen. Das Ding ist keine Raketentechnik: Dreiadriges geschirmtes Kabel, Plus, Minus, Guard. Schirm ist geräteseitig mit Guard verbunden. Die beiden Pinzettenhälften bestehen aus FR4 Leiterplatten. Jeweils eine Lage Leitung zur Spitze, die andere Lage Guard (Plus) bzw Schirm (Minus).
Hallo, dieser Thread ist ja schon sehr lang und ich habe wirklich versucht darin eine Antwort auf folgende Frage zu finden: Wie funktioniert die Widerstandsmessung mit 0,01 Ohm Auflösung genau? In der Beschreibung wird die Nullmessung gezeigt. Also externe 680 Ohm Pull-Up werden von einem Pin auf Masse gezogen und die Spannung an letzterem gemessen. Werden damit dann nur die Widerstände der Ports von 19-22 Ohm bestimmt oder steckt da noch mehr hinter? Soweit ich das sehe entsprechen 20 Ohm etwa 150 mV, also 140 LSB des ADC bei 1.1 V Referenz. Die 0,01 Ohm wären dann aber 0,06 LSB. Wird diese Auflösung dann durch starkes Oversampling erreicht?
Manuel schrieb: > ob man da die aktuelle Firmware flashen kann? Kann schwierig werden, weil: Fast alle aktuelle chinesische Nachbauten benutzen fest eingelötete SMD Komponenten und haben (natürlich) keinen ISP-Anschluss zur Programmierung des Prozessors, damit niemand ihre Kopie kopieren kann. Außerdem ist i. A. der Flash-Speicher gegen Auslesen gesperrt, so dass man nicht einmal einen ausgelöteten Chip auslesen kann, um die Software zu erforschen. Nicht im Sinne von Open Source. > Ist das überhaupt die hier diskutierte Firmware oder könnte das etwas > ganz anderes sein? Was "ganz anderes" ist es sicher nicht. Das Bildschirmfoto, obwohl ähnlich, entspricht im Detail keinem meiner beiden Geräte. Aber selbst wenn die Hardware möglicherweise "im Prinzip" kompatibel ist, so ist die Firmware doch zumindest angepasst worden. Es ist gut möglich, dass auch die Anschlussbelegung des Prozessors geändert wurde. Auch das wäre eine Art Kopierschutz. Man müsste dann schon die Hardware "reverse engineeren", um ein Schaltbild zu erstellen, damit man die Kompatibilität überprüfen könnte. Mmmmh? Sorry für die späte Antwort. Gruß, derri
Stefan schrieb: > Werden damit dann nur die Widerstände der Ports von 19-22 Ohm bestimmt > oder steckt da noch mehr hinter? Natürlich werden auch die Kabel und Kontaktwiderstände mit gemessen. Die ESR-Messung mit der Auflösung 0.01 Ohm funktioniert leider nicht besonders gut, da das "Rauschen" in den Einzelwerten fehlt. Auch das teilweise Parallelschalten des 470k Widerstandes bringt leider keine deutliche Verbesserung. Man könnte also nur den Meßstrom durch kleinere Widerstandswerte als 680 Ohm verbessern. Das wäre dann aber eine Änderung der Schaltung.
Ok, Beim "Forward reference measurement" fallen dann aber doch nur die Widerstände in den Ausgangsstufen (19-22 Ohm), der Leiterbahnen (mOhm) sowie der 680 Ohm Widerstand ins Gewicht. Die Kabel und Kontaktwiderstände tragen meiner Ansicht nach nur bei der eigentlichen Messung bei. Oder verstehe ich das Verfahren immer noch so grundlegend falsch? Mich wunderte die Angabe, dass man die ESR Methode 2 auch bei Widerständen anwendet. Dazu ist es ja nicht nötig irgendetwas zu entladen/aufzuladen oder den Samplezeitpunkt in die Mitte einer Flanke zu legen. Bei Letzterem würde man ja unnötigerweise die Induktivität mitmessen. Oder arbeitet die Widerstandsmessung am Ende auch mit diesen Pulsen anstatt konstant 5 V anzulegen?
Stefan schrieb: > Oder arbeitet die > Widerstandsmessung am Ende auch mit diesen Pulsen anstatt konstant 5 V > anzulegen? Ja, bei der "k"-Version wird die ESR Messung mit der Auflösung 0.01 Ohm nur bei Widerständen unter 10 Ohm ohne festgestellte Induktivität angewendet. Die ESR Messung verwendet generell nur kurze Strompulse mit wechselnder Polarität, was für die Messung der Kondensatoren erforderlich ist. Die kurzen Pulse schaden auch bei Widerständen nicht weiter, so daß auf eine getrennte Funktion mit höherer Auflösung für Widerstände verzichtet wurde. Bei Induktivitäten wird nur die normale Widerstandsmessung mit 0.1 Ohm Auflösung versucht. Auch bei diesen Resultaten ist Vorsicht angebracht. Es kann vorkommen, daß diese Widerstandswerte zu hoch angezeigt werden weil die Wartezeit nicht lange genug war.
Vielen Dank für deine Erklärungen. Ich glaube jetzt habe ich es verstanden. Es ist sehr faszinierend wie viel man mit diesen doch recht einfachen Mitteln machen kann. PS: Ich überlege momentan eine Widerstandsmessung mit einem STM32 zu machen. Diese haben zwar einen höherauflösenderen, schnelleren ADC (12 Bit, mehrere MS/s) aber auch ein paar Nachteile. Zum Einen hat man keine 5 V zur Verfügung um die gegen Masse gemessene Spannung zu vergrößern. Vor allem aber scheint es nicht möglich an einem Pin den ADC zu verwenden und gleichzeitig den Pullup/Pulldown zu aktivieren. Man muss also auf der Platine einen weiteren Prozessorpin verbinden um PullUps/Pulldowns dazu schalten zu können. Für 3 Kanäle fällt die doppelte Anzahl Pins nicht so sehr ins Gewicht, bei meiner Anwendung leider schon...
Marcel D. schrieb: > Was "ganz anderes" ist es sicher nicht. Das Bildschirmfoto, obwohl > ähnlich, entspricht im Detail keinem meiner beiden Geräte. Aber selbst > wenn die Hardware möglicherweise "im Prinzip" kompatibel ist, so ist die > Firmware doch zumindest angepasst worden. Ärgerlich. Worst-Case wäre wohl wenn da nichtmal ein Atmel drinsteckt und das LCD nicht kompatibel ist. Aber ich werde sehen was kommt. Lieferung angeblich morgen. Nach einem kurzen Testlauf wird das Ding sowieso erstmal zerlegt. Marcel D. schrieb: > Es ist gut möglich, dass auch > die Anschlussbelegung des Prozessors geändert wurde. Auch das wäre eine > Art Kopierschutz. Man müsste dann schon die Hardware "reverse > engineeren", um ein Schaltbild zu erstellen, damit man die > Kompatibilität überprüfen könnte. Mmmmh? Allzu komplex ist die Original-Schaltung ja nicht. Wenn die Schaltung ähnlich einfach ist wie das Original, dann sollte rauszeichnen kein Problem sein. Und eine andere Pinbelegung ist ja nichts was man nicht im Quellcode patchen könnte.
Manuel schrieb: > Nach einem kurzen Testlauf wird das Ding > sowieso erstmal zerlegt. Deine Postings haben mich neugierig gemacht. Kleine Suche nach einem Handbuch, und siehe, jemand hat sich schon mal die Mühe gemacht, das Gerät zu zerlegen. Und das Handbuch hat er auch noch fotografiert. https://www.eevblog.com/forum/testgear/bside-esr02-pro-transistor-tester-%28teardown-quick-test%29/ Fazit: Prozessor atmega328P TQFP, 8 MHz, Batterie 9 V Block. Ob die Pinbelegung übereinstimmt bedarf der Nachprüfung!, ein ISP-Programmieranschluss fehlt :-( Ein User schrieb : I find it a quite neat interpretation of the original "Komponententester" by Karl-Heinz Kübbeler. Es lebe die internationale Zusammenarbeit :-) derri
:
Bearbeitet durch User
... weitere Infos, ebenfalls aus dem eevblog-forum, hier auch mit SW und Schaltbild. Gruß Horst
Horst O. schrieb: > ... weitere Infos, ebenfalls aus dem eevblog-forum, hier auch mit SW und > Schaltbild. Prima! Ich war wohl zu skeptisch. Es ist definitiv ein Transistortester nach Frejek/Reschke/Kübbeler, wenn auch mit einigen Anpassungen, wie z. B. U4. Und offensichtlich läuft die hier besprochene Firmware! Nach einem Blick in das Schaltbild muss ich mich korrigieren, ein I(C)SP-Anschluss ist doch vorhanden. Allerdings kann ich die Verbindung von Pin 17 des Prozessors (PB5, SCK) nach Pin 4/J6 auf dem Foto der Leiterplatte nicht nachvollziehen. Da besteht noch Klärungsbedarf. Statt dessen ist Pin 4/J6 mit Pin 25 des Prozessors PC2) verbunden. Die rot eingezeichneten Beschriftungen im Foto DTU-1701(ICSP).jpg sind jedenfalls korrekt. Aber das kann Manuel ja vielleicht klären? Vorsicht ist hier jedenfalls geboten, weil die Ports PB3, PB5 und PB5 über Widerstände 680/470K mit den Testpins verbunden sind. Beim Programmieren des Prozessors darf deshalb an den Testpins nichts angeschlossen sein. Gruß, derri
Na das macht doch Hoffnung das ich ohne allzu großen Aufwand da direkt die Open-Source Firmware reinbekomme! Folglich wird der erste Mod der saubere Einbau einer ISP-Buchse, denn es wird sicher in Zukunft noch Updates geben und die will ich dann ohne Verrenkungen flashen können. Ich kenne das Projekt hier im Detail nicht und weiß nicht wie wichtig das Menü ist. Aber da die beiden Taster wohl gleich belegt sein sollen wäre ein zweiter ganz praktikabler Mod einen der Taster rauszuwerfen und da stattdessen einen Encoder zu verbauen. Den Button im Encoder kann ich dann ja wieder mit dem verbleibenden Taster parallel schalten. Macht es eigentlich Sinn die Eingänge zu schützen? In der Projekt-Doku gibt es ja zwei Varianten für eine Absicherung. Die einfachste wäre die Dioden-Lösung. Oder eben ein möglichst kleines Relais. Sinnvoll oder unnötiger Aufwand? Das man einen Kondensator vor dem Messen entladen soll ist ja im Prinzip keine Neuigkeit. Das gilt auch für wesentlich teurere LCR-Messgeräte.
Manuel schrieb: > Macht es eigentlich Sinn die Eingänge zu schützen? In der Projekt-Doku > gibt es ja zwei Varianten für eine Absicherung. Die einfachste wäre die > Dioden-Lösung. Oder eben ein möglichst kleines Relais. Sinnvoll oder > unnötiger Aufwand? Der Moritz hatte doch mal eine Platine angeboten mit Miniaturrelais und DOG-M Display. Ist aber schon lange her.
:
Bearbeitet durch User
Manuel schrieb: > Sinnvoll oder > unnötiger Aufwand? Manuel schrieb: > Macht es eigentlich Sinn die Eingänge zu schützen? In der Projekt-Doku > gibt es ja zwei Varianten für eine Absicherung. Die einfachste wäre die > Dioden-Lösung. Oder eben ein möglichst kleines Relais. Sinnvoll oder > unnötiger Aufwand? Der Nachteil der Relais-Lösung ist ein erhöhter Stromverbrauch während der Messung. Die Diodenlösung hat deutlich weniger Schutzfunktion und ich habe schon den Ausfall der Zusatzdioden erlebt ohne daß ich die Ursache dafür wusste. Ein Teil des Dioden-Arrays hatte da einen Kurzschluß gebildet. Es gibt nach meiner Auffassung keinen wirksamen Schutz gegen einen Kondensator mit hoher Restspannung und hoher Kapazität. Dafür müssten zur Strombegrenzung Widerstände für die Testport-Anschlüsse geschaltet werden, was wegen den vielfältigen Meßaufgaben nicht möglich ist. Deshalb lieber beim Messen von Kondensatoren vorsichtig sein und im Falle des Falles den ATmega328 austauschen.
Asko B. schrieb: > Der Moritz hatte doch mal eine Platine angeboten mit Miniaturrelais > und DOG-M Display. Du hast nicht zufällig einen Link auf das Posting parat? Mich würde vor allem interessieren was das für ein Relais war. Wenn ich da was nachrüsten sollte, dann sowieso auf einer kleinen Lochrasterplatine. Messgerät ist tatsächlich heute gekommen. Ich werde aber frühestens morgen, eher am Wochenende dazu kommen mich mehr in der Tiefe damit zu befassen. Auf dem Foto ist ja auch eine unbestückte Pinleiste zu sehen. Weil im EEVBlog-Forum aber eine Seite später Positionen an der Platine gezeigt werden, wo man ISP anschließen kann, frage ich mich ob man wirklich so viel Glück hat, dass hier die ISP-Pins rausgeführt sind. Und wenn nicht, was dann da rausgeführt ist. Zur Messpinzette kann ich schonmal sagen: Die macht einen durchaus brauchbaren Eindruck. Ich habe mal eine Widerstandsmessung gemacht und komme auf ca. 0,3 Ohm beim direkten Verbinden der zwei Messspitzen. Kapazität mit meinem Multimeter nicht messbar. Angezeigt wird 0,02nF aber in dem Bereich sind das eher Schätzwerte. Für den Zweck, SMD-Kerkos zu sortieren, sollte die eigentlich brauchbar sein.
Karl-Heinz K. schrieb: > Deshalb lieber beim Messen von Kondensatoren vorsichtig sein und im > Falle des Falles den ATmega328 austauschen. OK. Wäre im Falle des Falles auch kein Beinbruch. Ist mit Heißluft ja schnell draußen.
Manuel schrieb: > OK. Wäre im Falle des Falles auch kein Beinbruch. Ist mit Heißluft ja > schnell draußen. Naja, bei so einem Viel-Füssler hab ich (Ich) so meine Not. Deswegen hatte ich mal ... lang ist es her ... die Idee solch ein ATMega644 auf ne Adapterplatine zu pinnen und das ganze dann doch steckbar zu machen. So, für den Notfall. ;-) In meiner Kramkiste liegt noch ein Bausatz von Moritz. Das wollte mal ein Bekannter haben, und hat sich dann doch für einen fertigen Tester aus China entschieden. Ich selber habe dann mal angefangen ein Layout mit solch einem Relais zu zeichnen. Dann wurden aber die fertigen Transistortester aus China preiswerter als die selbstgebauten, und ich hab einfach nicht weitergemacht. Ich hänge mal ein Bild an, hoffentlich kann man die Beschriftung sauber lesen.
Horst O. schrieb: > Schaltbild ... mir ist ein Unterschied zwischen den Platinenfotos und dem Schaltbild aufgefallen: Die Verbindungen von J6 führen nicht zu den ISP-, sondern zu den Probe-Anschlüssen. Eventuell existieren unterschiedliche Platinenversionen? Gruß Horst
Horst O. schrieb: > Die Verbindungen von J6 führen nicht zu den > ISP-, sondern zu den Probe-Anschlüssen. Ja Horst, Du hast recht. J6 ist KEIN ISP-Anschluss! Er ist wohl eher für Erweiterungen gedacht. Gruß, derri
Gibt tatsächlich (mindestens) zwei Revisionen der Platine. Ich vergleiche die später noch genauer, aber die drei unteren Pins sind bei mir nicht die Testanschlüsse sondern sehen verdächtig wie direkte Zuführung für ISP aus. Eine gesteckte 6-Pin Stiftleiste stört nicht beim Schließen des Gehäuses. Damit ist auch geklärt wie die Firmware in den Chip kommen kann.
Manuel schrieb: > Gibt tatsächlich (mindestens) zwei Revisionen der Platine. > > Ich vergleiche die später noch genauer, aber die drei unteren Pins sind > bei mir nicht die Testanschlüsse sondern sehen verdächtig wie direkte > Zuführung für ISP aus. Eine gesteckte 6-Pin Stiftleiste stört nicht beim > Schließen des Gehäuses. Damit ist auch geklärt wie die Firmware in den > Chip kommen kann. Dann würde ich mal sagen: Glück gehabt! derri
Wie bekomme ich die Meldung "Not calibrated!" weg? Selbstttest mit kurzgeschlossenen Eingängen habe ich durchgeführt. Läuft auch bis zum Ende durch. Nach dem Selbsttest geht der Tester in den "Standardmodus". Zeigt an das kein Teil gefunden wurde und die Meldung "Not calibrated!" ist, trotz durchgeführtem Selbsttest, noch da.
Vergesst die Frage. Ich hätte mir das mit der Kalibrierung mal genauer durchlesen sollen. Mit zwei Kondensatoren (10 nF und 100 nF) wurde die Kalibrierung nun auch erfolgreich durchgeführt. Wie bekomme ich nun noch nicht benötigte Einträge aus dem Menü? Ich habe da noch "10 bit PWM" und "f-Generator". Vielleicht auch noch weitere die raus müssten. Wo findet man da eine Übersicht wie man nicht nutzbare Funktionen im Makefile rausbekommt? Bei einigen habe ich schonmal gesehen das die einen TSOP in die 3 Testanschlüsse stecken und dann Fernbedienungen testen. Bei mir werden aber immer zwei gegeneinander gerichtete Dioden angezeigt. Was muss noch rein für diese IR-Test-Funktion?
Zwischenstand ist, dass meine selbst gebaute Firmware einwandfrei auf dem "BSIDE ESR02 Pro" läuft. Ich würde das jetzt gerne besser auf die Hardware anpassen. Also Menüeinträge raus die mit der "Werkskonfiguration" der Hardware keine Funktion haben. Mit der Original-Firmware hatte ich übrigens auch die Meldung wegen fehlender Kalibrierung. Inklusive Hinweis das man weitere Infos auf mikrocontroller.net findet.
Manuel schrieb: > Inklusive Hinweis das man weitere Infos auf mikrocontroller.net findet. 🤣🤣🤣👌🏼 Klaus.
Manuel schrieb: > Wie bekomme ich nun noch nicht benötigte Einträge aus dem Menü? Soweit ich weiß, kann man keine einzelnen Einträge aus dem Menü löschen. Aber du kannst die Zusatzfunktionen, wie "10 bit PWM" und "f-Generator" und "Frequenz" aus dem Menü werfen, indem du den Schalter "CFLAGS += -DWITH_MENU" im Makefile mit einem # auskommentierst (siehe Seite 41 in der Beschreibung ttester-de.pdf, Version 1.13k). Welche Auswirkungen auf die Funktionswahl diese Maßnahme sonst noch hat, weiß ich jetzt nicht genau, aber alle aktivierten automatischen Funktionen sollten weiterhin funktionieren. Da dein Gerät keinen Impulsdrehgeber hat, ist das Menü u. U. verzichtbar. Es ist ja jetzt schnell mal ausprobiert. Im Übrigen vielen Dank für deine "Forschungsarbeit". Deine Ergebnisse machen das Gerät sicher für den Einen oder Anderen interessanter. Gruß, derri.
Manuel schrieb: > "10 bit PWM" und "f-Generator" ... f-Generator und 10 bit PWM funktionieren über den Testpin 2 und können normal genutzt werden, der Eingang zum Frequenz-Zähler ist noch frei - zusätzliche Buchse und auch die Funktion ist möglich. Die Infrarot-Funktionen sind nur mit der M-Software möglich. Gruß Horst
:
Bearbeitet durch User
Hallo Manuel und alle am BSIDE interessierten Mitleser, ... ein besonderer Schaltungsteil, welcher so in keinem mir bekannten Transistortester-Nachbau vorkommt, ist der Komparator U4 mit dem nachgeschalteten NPN-Trans Q4 und es scheint so, als werde zum Schutz des Displays vor Überspannung der Ground vom Controller U5, der Spannungsreferenz U2, dem LDO-Regler U1 und dem Display weggeschaltet!? Die Schaltschwelle von U4 liegt allerdings bei ca. 5,7 Volt, beim Tausch von R7 mit R12 ergeben sich ca. 3,3 Volt, jeweils bezogen auf UBat von 9Volt. Statt den gesammten Strom des Controllers über Q4 zu schalten, könnte doch ebenso nur die GND-Verbindung zum Q3 geöffnet werden??? Vielleicht kann Manuel ja die Schaltung seines Gerätes hierauf mal untersuchen (Abweichung Schaltplan Printversion?) Den Plan hänge ich nochmal mit an. Gruß Horst
:
Bearbeitet durch User
Horst O. schrieb: > Vielleicht kann Manuel ja die Schaltung seines Gerätes hierauf mal > untersuchen (Abweichung Schaltplan Printversion?) Kann ich mal schauen. Was genau interessiert dich? Um ehrlich zu sein habe ich bisher die Platine noch nichtmal raus gehabt. Umrüsten auf die aktuelle Firmware aus dem SVN ist wirklich einfach. Makefile liefere ich noch nach und ein paar Fotos. Ich hab dann einfach das Makefile in den Source-Tree gelegt, mit "make" kompiliert und danach mit "make upload" geflasht. Die Stiftleiste hatte ich nur in die Platine gesteckt und etwas mit dem Finger verkantet. Nach dem Flashen dann Stiftleiste wieder raus und Deckel drauf. Fertig. Die 4mm-Buchsen am "BSIDE ESR02 Pro" sind etwas kurz geraten. Die gängigen Hirschmann Stapelstecker (unisoliert) kontaktieren gut und lassen sich auch gut stecken. Das erlaubt schonmal den Einsatz meiner ganzen Messleitungen. Bisschen Bedenken hatte ich, dass die Federkraft der Stecker etwas leidet (Buchsen scheinen mir minimal zu eng). Hat sich aber soweit nicht bestätigt. Stecker sitzen auch nach mehrfachem Nutzen im BSIDE noch genau so stramm in anderen Messgeräten. Die Messleitungen von meinem Multimeter gehen etwas stramm rein. Was da etwas "aneckt" ist das Kunststoff des Sicherheitssteckers. Messen ist aber möglich. Ein Hirschmann Sicherheitsstecker kontaktiert in der Buchse vom "BSIDE ESR02 Pro" gar nicht. Der Stecker kann nicht tief genug gesteckt werden (stößt am Grund der Buchse an) und bekommt so keinen Kontakt.
Mal noch eine Frage unabhängig vom Gerät: Wenn ich einen Kondensator zwischen T1 und T3 messe, dann geht das Gerät automatisch in den "Dauer-Kondensator-Messmodus". Bei Messung zwischen T1 und T2 oder T2 und T3 wird nur einmal gemessen. Kann ich die einmalige Messung auch zwischen T1 und T3 haben? Ich würde den "Dauer-Modus" lieber nur aus dem Menü wählen. Bin ggf. auch für einen Tipp dankbar wo das codiert ist. Nervt mich nämlich so sehr das ich mir das ggf. lokal patchen würde.
Ich habe mir jetzt erstmal einen "Arbeits-Fork" gezogen. Wenn jemand auch eine Arbeitskopie braucht: Der Befehl den ich verwendet habe steht in der Repository-Beschreibung. Ich habe Binaries ausgefiltert weil GIT sich zum Speichern von Binaries generell weniger gut eignet. Hier das Makefile das ich verwende: https://github.com/M-Reimer/transistortester/blob/master/mega328_BSIDE_ESR02_Pro/Makefile Es handelt sich um das Makefile aus dem EEVBlog-Forum das ich für den aktuellen Stand des Codes angepasst habe. Und hier der Fix den ich haben wollte (kein automatisches "Dauer-Kondensatormessen"): https://github.com/M-Reimer/transistortester/commit/03fc8be4aed9789e35985a10bcc26f8e2e021c43 Ich deaktiviere dieses automatische Einschalten der Funktion wenn das Menü aktiv ist. In dem Fall kann man das Feature nämlich bei Bedarf manuell starten. So kann ich Kondensatoren nun da stecken wo es mechanisch gerade passt und habe immer die gleiche Messlogik dabei. Änderungen können gerne übernommen werden. Credits für das Makefile gehen aber an https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg1495258/#msg1495258
Ich habe mir 2011 den Transistortester mit Atmega8 gebaut und er hat 9 Jahre lang gut funktioniert. Jetzt hat er wohl Alzheimer, zeigt Dioden an, wenn man einen Widerstand messen will, Elkos werden nur mit der Hälfte der eigentlichen Werte gemessen, kleine Kondensatoren sind auch Dioden ... https://www.mikrocontroller.net/articles/AVR-Transistortester Ich wollte jetzt erst mal die Firmware neu aufspielen, kann ich bei dem alten Teil auch eine neue Version nehmen, z.B. https://www.mikrocontroller.net/svnbrowser/transistortester/Software/trunk/mega8/ die Version 813 Danke.
Ich habe jetzt mal eine neue Firmware aufgespielt, da tut sich gar nichts, nur die alte Transistortester_orig funktioniert, ich habe alle Lötstellen nachgelötet, Batteriespannungs ist ok und stabil, auch die 5V nach dem Regler. Was könnte die Ursache sein?
Einer der Pins für Testanschlüsse "geschossen"? Wenn es nicht allzu aufwändig ist, würde ich zuerst versuchen den Atmega zu wechseln.
bingo schrieb: > Was könnte die Ursache sein? Wenn die ursprüngliche Schaltung von Markus Frejek nicht modifiziert wurde, muß in der Makefile die Option PULLUP_DISABLE abgeschaltet werden und die Quellen neu übersetzt werden. Sonst muß ein Widerstand mit etwa 27k von Pin 13 nach VCC (5V) nachgerüstet werden. Falls der ATmega8 gegen einen ATmega328 ausgetauscht wird, sollte außerdem der 100nF Kondensator an AREF (Pin 21) entfernt werden oder gegen einen 1nF Kondensator ausgetauscht werden. Der Zugewinn an Fähigkeiten durch den Prozessortausch ist deutlich.
Hardware und Software sind 9 Jahre alt (es ist ein Atmega8 in SMD), da hat sich nichts geändert, alles nachgelötet, neu geflasht, auch die Fuses, trotzdem hat sich am Fehler nichts geändert. Sehr merkwürdig. Ich werde mir wohl einen der neueren TT besorgen müssen.
Peter ⛄ W. schrieb: > Quarz vergammelt. Da gibt es keinen Quarz https://www.mikrocontroller.net/wikifiles/1/11/AVR-Transistortester_neu.zip
gibt es eine Uebersicht kompatibler Fertiggeraete und Anbieter? Das TableClonesEn.pdf kenne ich, scheinen nur asiatische Nachbauten zu sein? Ich moechte nicht basteln sondern suche ein kompatibles Fertiggeraet. Danke
...und was suchst du, was die nicht können? Was ist mit BSIDE ESR02 Pro? Klaus.
Klaus R. schrieb: > ...und was suchst du, was die nicht können? ein funktionierendes Geraet out of the box. Soll heissen, dass die fuer AVR-Transistortester beschriebene Funktionalitaet vorhanden ist, voll kompatibel ohne irgendwelche Basteleien; also insbesondere upgrade-faehig ohne Klimmzuege, gerne auch dokumentiert die verwendete config fuer eigene Updates. Zufaellig bin ich an Z-Dioden bis 35V interessiert und eingebauter Vref-Quelle, das koennen die meisten Asia-Clones nicht laut Liste. Ausserdem moechte ich neben R,C,L,T zu messen auch folgende Features nutzen (nur die gelistet, die Hardwareanforderungen formulieren laut config.h) - HW_FREQ_COUNTER_EXT - HW_EVENT_COUNTER, EVENT_COUNTER_TRIGGER_OUT - SW_SQUAREWAVE - SW_SERVO Dafuer brauche ich ein Geraet, dass diese Features hardware-seitig unterstuetzt (also insbesondere additional keys (e.g. rotary encoder) and a display with more than 5 lines) und ein passend konfiguriertes Image aufnehmen kann. > Was ist mit BSIDE ESR02 Pro? Ja, was ist damit? Welche Hardware ist da verbaut, ist es kompatibel zur aktuellen Software, upgrade-faehig, bekannte Limits? Oder was ganz anderes? Die gefundenen Angebote und YT-reviews sagen dazu gar nichts. Fuer mich ist der Tester ein Werkzeug, kein Hobby. Ich finde es prima, dass dieses Projekt so offen ist; allerdings fehlt mir zum Einstieg ein Ueberblick, welche Nachbauten vollwertig sind und welche verbastelt (davon ist hier ja auch zu lesen). Gibt es nur die Asia-Clones oder auch andere? Welche Geraete werden aktiv unterstuetzt oder sind zumindest als funktionierend bekannt? Eine Uebersicht waere zum Einstieg neben dem vorhandenen guten Manual sehr hilfreich
hamburger schrieb: > Die gefundenen Angebote und YT-reviews sagen dazu gar nichts. ... > Eine Uebersicht waere zum Einstieg neben dem vorhandenen guten Manual > sehr hilfreich Fast alle Nachbauten kommen aus Asien und, wie du selbst bemerkt hast, oft ohne ausreichende Dokumentation. Woher soll also so eine Übersicht kommen. Im Prinzip könnte jeder Besitzer die Funktionalität seines Nachbaus in eine große Liste eintragen. Aber wer sagt, dass die unterschiedlichen Anbieter ihre Versionen nicht von Zeit zu Zeit aktualisieren ohne dieses zu dokumentieren. Jeder angemeldete Nutzer kann einen Artikel schreiben. Wenn du dich anmeldest, kannst du mit der Liste beginnen.
:
Bearbeitet durch User
Die Chinateile vermehren sich, indem ein Händler, der ein neues Geschäft wittert, sich so ein Ding bestellt und das von einem Dienstleister analysieren und duplizieren lässt. Dabei entstehen Fehler, es kommt aber auch vor das derjenige der die Schaltung aufnimmt eine gute Idee hat und das Konzept verbessert. So hast Du dann einen ganzen Baum von Geräten, die auf den gleichen Namen hören ("TL866A", "NanoVNA", ...), irgendwie vom gleichen Design abstammen, aber auf komplett unterschiedlichen Fertigungsdaten beruhen. D.h. selbst wenn Du den auf dem Angebotsfoto genau gleich aussehenden Transistortester bestellst, dann muss der noch lange nicht mit den gleichen Gerberdaten produziert und mit den gleichen Bauteiltoleranzen bestückt sein.
hamburger schrieb: > Zufaellig bin ich an Z-Dioden bis 35V interessiert und eingebauter > Vref-Quelle, das koennen die meisten Asia-Clones nicht laut Liste. > Ausserdem moechte ich neben R,C,L,T zu messen auch folgende Features > nutzen (nur die gelistet, die Hardwareanforderungen formulieren laut > config.h) > - HW_FREQ_COUNTER_EXT > - HW_EVENT_COUNTER, EVENT_COUNTER_TRIGGER_OUT > - SW_SQUAREWAVE > - SW_SERVO > Dafuer brauche ich ein Geraet, dass diese Features hardware-seitig > unterstuetzt (also insbesondere additional keys (e.g. rotary encoder) > and a display with more than 5 lines) und ein passend konfiguriertes > Image aufnehmen kann. ... diesen Forderungen kommt das Gerät mit der Bezeichnung Hiland M644 am nächsten. Es wird aber mit einer 1_12er k-Version geliefert, die so nicht all Deine Vorgaben erfüllt. Du beschreibst Eigenschaften der aktuellen m-Version, welche Du dann in geeigneter Software-Umgebung konfigurieren und über ein (nicht handelsübliches) Verbindungskabel in den Controller brennen musst. Auch hat das Gerät kein Gehäuse - Du siehst also, ein klein wenig muss schon noch Hand angelegt werden. Andererseits ist über das Gerät hier im Forum und ebenso im englischsprachigen eevblog-Forum schon sehr viel veröffentlicht worden. Seltsamerweise haben alle Geräte, die in einem Gehäuse geliefert werden, auch zumeist keinen Dreh-Tast-Schalter. Wer die Wahl hat... Gruß Horst
:
Bearbeitet durch User
Horst O. schrieb: > ... diesen Forderungen kommt das Gerät mit der Bezeichnung Hiland M644 > am nächsten. immerhin, das war vorhin auch mein Fazit nach 2 Tagen Rumsuchen zu diesem Thema. Die Order ist schon erfolgt. isp-Programmer und verschiedene avr toolchains habe ich hier noch. Angefangen hatte das, weil ein Kollege davon geschwaermt hatte, dass die Chinesen mal etwas richtig Tolles erfunden haben... Vielleicht waere eine kurze Zusammenfassung im ersten Post ganz hilfreich? Was ist daran so schwer? Hier eine knappe Beschreibung&Linkliste zum Kopieren (von madires) : https://www.heise.de/forum/heise-online/Kommentare/Messgeraete-fuer-Maker/Transistortester/posting-37962730/show/ Dazu noch ein Verweis auf die TableClonesEN.pdf https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg3267562/#msg3267562 und die CLONES Datei aus dem m-sourcetree. Dann waere der Einstiegspfad schon deutlich gezeichnet, falls das hier gewuenscht ist.
...Alter Falter, du hast nen ganz schön pissigen Ton am Hals. Aber nicht die Eier angemeldet zu sein Klaus.
:
Bearbeitet durch User
Hmm, es bedarf Mut ("Eier") um sich in einem Forum zu registrieren? Manche Teilnehmer dieses langen Threads haben ja offenbar viel Zeit in das Gerät und die Foren-Beschickung gesteckt. Warum das Gerät nach Jahren noch in so einem Huddel-Status ist .. darf man schon fragen.
Leser_77 schrieb: > Manche Teilnehmer dieses langen Threads haben ja offenbar viel Zeit in > das Gerät und die Foren-Beschickung gesteckt. Warum das Gerät nach > Jahren noch in so einem Huddel-Status ist .. darf man schon fragen. Umgekehrt wird ein Schuh draus! Der Huddelstatus, wenn er denn existiert, ist keineswegs den vielen konstruktiven Beiträgen anzukreiden, als vielmehr den unzähligen chaotischen Nachbauten aus Fernost, die alles andere als einheitliche Merkmale aufweisen. Wer sich im Forum kundig macht, wird schnell herausfinden, dass die Firmware durchaus strukturiert ist. Es ist respektlos, angesichts der beiden hauptsächlichen Softwareautoren kubi48 und madires, die viel Zeit und Arbeit in die Weiterentwicklung des Geräts gesteckt haben und es so zu einem weltweiten Erfolg (von Alaska bis Neuseeland) getragen haben, hier von Huddel zu quaken. derri
Hallo zusammen Ich habe hier den T4 V2 (glaube ich zumindest). ISP ist angelötet und funktioniert. Ich habe viel im Forum gelesen, auch Wiki und Doku. Aber sicher nicht alles ;-) (mehrere Stunden, ihr wisst ja... Viel Infos) Das Display wird mit T4 V2 angesteuert, aber es ist nichts sinnvolles lesbar. (siehe angehängte Fotos)
1 | CFLAGS += -DLCD_ST7565_Y_START=32 |
funktioniert, siehe transistortester2.jpg, also Pinbelegung dürfte wohl stimmen. Ich musste
1 | LCD_ST7565_RESISTOR_RATIO = 3 |
anpassen, damit wird das Display überhaupt lesbar. Die Displayspannung wird mit 2 4148 Dioden erstellt. Software habe ich aus dem SVN, ich habe die Trunk Version genommen, und darin mega328_T4_v2_st7565. Kann mir jemand einen Tipp geben, und die Suche abzukürzen? Ansonsten wäre meine nächste Idee, ein Hello World zu machen um die Display Ansteuerung zu testen.... mfg Andreas
Andreas B. schrieb: > Die Displayspannung wird mit 2 4148 Dioden erstellt. Hallo Andreas, die neueren T4-Modelle haben einen Widerstandsteiler statt der Dioden, versuche doch mal die FW-Version "mega328_T3_T4_st7565". Gruß Horst
Horst O. schrieb: > Andreas B. schrieb: > versuche doch mal die FW-Version "mega328_T3_T4_st7565". Ganz vergessen zu schreiben: dann bleibt das Display komplett hell, also ich vermute es wird nicht initialisiert... mfg Andreas
... läuft den das Programm ansonsten richtig: Bei einer LED an den Testanschlüssen sollte die nach dem Einschalten ein paar mal kurz blinken? Hänge mal 'ne funktionierende FW von mir an. Gruß Horst
:
Bearbeitet durch User
Horst O. schrieb: > ... läuft den das Programm ansonsten richtig: > > Bei einer LED an den Testanschlüssen sollte die nach dem Einschalten ein > paar mal kurz blinken? > > Gruß Horst Das ist aber auch mein "Testzenario". Damit kann man schon einiges an Fehlern ausschließen. (Funktion ja, Anzeige negativ) Marcel D. schrieb: > Wer sich im Forum kundig macht, wird schnell herausfinden, dass die > Firmware durchaus strukturiert ist. Es ist respektlos, angesichts der > beiden hauptsächlichen Softwareautoren kubi48 und madires, die viel Zeit > und Arbeit in die Weiterentwicklung des Geräts gesteckt haben und es so > zu einem weltweiten Erfolg (von Alaska bis Neuseeland) getragen haben, > hier von Huddel zu quaken. Dazu kein Kommentar ... Klaus R. schrieb: > ...und was suchst du, was die nicht können? Es wäre wirklich mal Zeit eine "Liste zu erstellen". Gruss Asko
Horst O. schrieb: > ... läuft den das Programm ansonsten richtig: > > Bei einer LED an den Testanschlüssen sollte die nach dem Einschalten ein > paar mal kurz blinken? Nein. Die LED Blinkt nicht. > > Hänge mal 'ne funktionierende FW von mir an. Danke! Ich habe diese geflasht mit:
1 | avrdude -c usbtiny -B 1.0 -p m328p -P usb -U flash:w:./mega328_T4_v2_st7565.hex:a |
2 | avrdude -c usbtiny -B 1.0 -p m328p -P usb -U eeprom:w:./mega328_T4_v2_st7565.eep:a |
Läuft! :-) Danke viel mal für die schnelle Hilfe! Nur warum lief der trunk nicht? ---> Fehler Analyse: Fehler gefunden... Anfängerfehler bzw. eben nicht, aus Gewohnheit "make flash" ausgeführt. Das schreibt wirklich nur das Flash... "make upload" wäre wohl besser gewesen. EEProm wurde nicht geschrieben, wäre aber nötig gewesen. Jetzt läuft auch der Trunk! Und die Firmware ist wie erwartet besser, z.B. bei einer Induktion wird auch der Widerstand angezeigt ;-) Nur die Darstellung der Chinesen fand ich schöner... Mal schauen, lässt sich noch einiges konfigurieren habe ich gesehen, und ggf. passe ich selbst noch was an, sind ja noch fast 3kByte flash frei ;-) mfg Andreas
Andreas B. schrieb: > Mal schauen, ... ev. gefällt Dir ja auch die m-software, habe das aktuelle Paket mal angehangen. Relativ einfach ist auch die Nachrüstung eines Tast-Dregebers, der die Funktionalität noch erheblich steigert. Viel Spass beim Testen. Gruß Horst
Danke Horst, ich habe mich für den Trunk entschieden. Ich habe die Schrift angepasst, und jetzt finde ich es recht gut lesbar. Kalibrieren hat jetzt geklappt, die Messung scheint jetzt sehr genau zu sein. Auch verglichen mit der chinesischen Firmware. (ESR=15Ω bei einem KerKo bei der Chinesischen Firmware, 0.68Ω bei dieser hier, 98nF bei chin., 100.1nF, leicht schwankend, bei dieser) Danke an alle die, die diese Algos implementiert und verfeinert haben! Die Darstellung sieht bei der Chinesischen Firmware aufgeräumter aus. Das Thema wurde hier ja auch schon angesprochen. Schlussendlich ist es auch Geschmacks- und Gewöhnungssache. z.B. beim FET hätten mit der kleineren Schriftart alle Informationen auf einem Screen Platz, statt dem Wechsel. Aktuell habe ich aber gerade keine Zeit - der Aufwand hier darf nicht unterschätzt werden, denn einfach nur anpassen geht nicht, sonst wirds nichts mehr mit HD44780, oder was auch sonst noch unterstützt wird. (das war für die Chinesen sicher kein Thema, einfach rausschmeissen...) Aktuell ist die Abstraktion nicht genügend vorhanden (ein Teil ist vorhanden). Und genau in den Details Steckt der Aufwand ;-) mfg Andreas
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.