Forum: Projekte & Code Transistortester AVR

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

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.

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"

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.

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

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.

Gibt's noch alternative Quellen für M644er Boards? Bei AliExpress sind 
alle ausverkauft (bis auf den Bohrmaschinenverkäufer).

Wilhelm K. schrieb:
> (bis auf den Bohrmaschinenverkäufer)

Und was ist mit dem ?

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?

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

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.

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

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.

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...

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.

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.

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?

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.

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

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

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.

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.

... 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.

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

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).

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

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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

So isses! :)

Und ab jetzt auch mit Account.

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:
> 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.

Karl-Heinz K. schrieb:

Danke Dir

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.

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:
> Was zum Geier ist BOM?
https://en.m.wikipedia.org/wiki/Bill_of_materials

...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:
> *) 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.

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.

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.

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.

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

Nice! Sehr nahe am perfekten Gerät...Danke für die Infos!

Klaus.

... 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

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.

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.