Hallo,
hier mal ein Projekt von mir: Ein automatischer Transistortester,
gesteuert von einem ATMega8. Ich habe da auch einen Artikel dazu
erstellt:
http://www.mikrocontroller.net/articles/AVR-Transistortester
Dieses Gerät erkennt Transistoren, Anreicherungs-MOSFETs,
Dioden-Netzwerke und kleine Thyristoren und Triacs automatisch. Bei
Transistoren wird auch noch der Verstärkungsfaktor angezeigt.
Der Tester ermittelt auch automatisch die Anschlüsse des Transistors.
Ist ein recht nützliches Gerät, finde ich. Transistoren mit unbekannten
Pin-Belegungen und unbekannter Funktionstüchtigkeit hat man immer
wieder.
Ich habe das Gerät mit vielen Transistoren und MOSFETs erfolgreich
getestet (genauer: alle, die ich versucht habe wurden auch korrekt
erkannt), darunter auch Leistungstypen wie 2N3773 oder IRFP450.
Verarmungs-FETs werden aber noch nicht unterstützt.
Mich würden mal eure Meinungen und eventuelle Verbesserungsvorschläge
dazu interessieren.

Ich werde das Teil auch mal nachbauen, denn die Schaltung vereint im
Prinzip ja 3 Schaltungen:
- Bauteil identifizieren
- Belegung rausfinden
- Testen

Und es wurde sogar an nahezu alle Transistoren gedacht (wie die mit der
Diode Emitter->Kollektor).

@ Markus
Hast du damit zufällig schonmal einen HOT gemessen (z.B. BU508 oder
ähnliche)? Diese besitzen nämlich oft einen Widerstand zwischen Basis
und Emitter, meist um die 100 Ohm.
Das gleich gilt für viele größere Thyristoren.

Markus F. wrote:
> Mich würden mal eure Meinungen

Schön.

> und eventuelle Verbesserungsvorschläge
> dazu interessieren.

Der Mega8 ist gesockelt? Da die Eingänge, besonders PC0 - PC2, keine
Schutzschaltung haben, würde ich das machen um ihn wenn notwendig
tauschen zu können. Alternativ natürlich eine Schutzschaltung
(Widerstand und BAV99 pro Pin). Ob die deiner Messmethode(n) stören
würde habe ich mir nicht angesehen.

> Hast du damit zufällig schonmal einen HOT gemessen (z.B. BU508 oder
> ähnliche)? Diese besitzen nämlich oft einen Widerstand zwischen Basis
> und Emitter, meist um die 100 Ohm.

Nein, das habe ich noch nicht versucht. Ich schätze aber, dass ein HOT
nicht vernünftig erkannt wird. Darlingtons wie den BD675 habe ich aber
schon mal gemessen. Die Belegung wird korrekt erkannt, allerdings kann
der Verstärkungsfaktor nicht richtig gemessen werden (wegen der internen
Widerstände von B nach E).

Leistungsthyristoren können damit prinzipiell nicht getestet werden,
weil der maximale Teststrom bei gut 7mA liegt. Das liegt unter dem
Haltestrom vieler Thyristoren. Das Bauteil wird dann fälschlicherweise
als NPN-Transistor erkannt. Man könnte mit drei weiteren Widerständen
noch einen weiteren Strombereich für den Test einbauen (z.B. 120 Ohm für
ca. 40mA).
Das dürfte für die meisten Thyristoren und Triacs als Haltestrom
reichen. Damit steigt aber auch das Risiko, empfindliche Bauteile zu
beschädigen.

Das mit der automatischen Abschaltung habe ich eingebaut, um die
Bedienung möglichst komfortabel zu machen: Transistor anschließen, Knopf
drücken, Ergebnis ablesen. Aber ich gebe euch Recht, für dieses Gimmick
ist es schon ein ziemlicher Aufwand.

=> Hannes Jaeger:
Ja, in meinem Aufbau ist der Mega8 gesockelt. Eine Schutzschaltung wäre
noch eine Ergänzung. Allerdings sollte man an PC0...2 keine zusätzlichen
Widerstände anschließen (diese Pins werden während des Tests auch ab und
zu auf Ausgang geschaltet). Widerstände würden das Messergebnis
verfälschen. Denkbar wären aber z.B. eine Surpressordiode und eine
32mA-Sicherung an jedem Pin.
Eigentlich sollten aber sowieso keine eingebauten Transistoren getestet
werden (nur dann besteht die Gefahr einer Beschädigung). Zumindest der
Verstärkungsfaktor kann da nämlich nicht vernünftig ermittelt werden.
Dann könnten auch Kollektor und Emitter falsch erkannt werden.

Warum benutzt Du nicht einfach 3* R6-Batterien und keinen
Spannungsregler?
Dann brauchst Du keine extra Abschaltschaltung.

Stabil muß die Spannung nicht sein, es wird ja das Verhältnis
Kollektorstrom zu Basisstrom gemessen.


Peter

Ich bin gerade dabei die Schaltung aufzubauen:
In dem Schaltplan sind ein paar Fehler/Unschönheiten:
- Du hast D0-3 anstelle von D4-7 am LCD angeschlossen
- An den Reset Pin sollte man entweder einen C gegen Masse, 10k gegen 5V
oder beides anschließen
- Wenn du einen Widerstand zwischen GND und CONTR vom LCD einbaust, wird
der Kontrast besser. Das Display das du verwendet hast, sieht aus wie
das Mini Display von Pollin: Das hat normalerweise einen super Kontrast,
bei dir ist es allerdings ziemlich übersteuert. Häng mal etwa 2k in die
CONTR Leitung. Andere LCDs benötigen etwa 100-1k.
- Ein paar 100nF in der Schaltung würden auch nicht stören.

> Du hast D0-3 anstelle von D4-7 am LCD angeschlossen
Ja, stimmt. Das habe ich übersehen. Es müssen natürlich D4...7 sein, da
habe ich mich vertan
> An den Reset Pin sollte man entweder einen C gegen Masse, 10k gegen 5V
> oder beides anschließen
Auch richtig. Habe ich in meinem Aufbau nicht gemacht, könnte ich aber
nochmal nachrüsten.
Der Kontrast des Displays ist übrigens nicht so viel zu hoch wie es im
Foto aussieht. Und es ist wirklich das LCD von Pollin für 1,95€.

Einen 100nF von Vcc nach GND habe ich auch eingebaut, aber im Schaltplan
vergessen (ist sowieso mein erster Schaltplan in Eagle...)

Ich werde die genannten Dinge mal ändern und dann einen neuen Schaltplan
reinstellen.

Mit der "Batterie-leer-Erkennung" gibt es sowieso ein paar Probleme
(habe ich gerade bei einem Test mit einem Netzgerät bemerkt).
Das ist eben mal wieder das Übliche:
Man baut eine Funktion ein und testet sie. Wenn sie dann läuft ist es ja
prima.
Dann ändert man an dem Programm noch etwas und plötzlich gibt es bei
Dingen Probleme, die vorher 1A geklappt haben. Kennt hier wohl jeder...

So, ich habe den Schaltplan jetzt verbessert. Das Problem mit der
"Batterie leer"-Anzeige ist auch gelöst. Ich habe die neuen Dateien zu
dem Artikel reingestellt.

> Warum benutzt Du nicht einfach 3* R6-Batterien und keinen
> Spannungsregler?
Viele Mosfets brauchen z.B. mindestens 4V am Gate um halbwegs zu
schalten.
Außerdem ist sonst der Teststrom nicht konstant, was den Test von
Thyristoren u.ä. noch unzuverlässiger macht (der Teststrom fällt
natürlich, wenn die Betriebsspannung sinkt). So toll wäre das nicht.

@Alle

Ich habe mir mal eine Platine entworfen für den Transistortester, ich
habe diese Platine so ausgelegt das ich auch ein kleines OLED Display
einsetzen kann. Wenn Markus F. die Erlaubnis geben würde könnte man auch
Bausätze für alle anbieten die selber keine Platinen herstellen können.

Kontakt über das Forum oder thomas [at] heldt [punkt] eu

@Markus F.
ich hatte dich mal angeschrieben wegen der Idee mit den Bausätzen bitte
melde dich doch einfach mal, danke.

Gruß
Thomas

=> Thomas H:
Ich habe dir eine Mail zu der Sache mit den Bausätzen geschickt.

Und noch etwas: Könnte jemand, der den Transistortester schon aufgebaut
hat, einmal versuchen, damit einen P-Kanal-(Anreicherungs)MOSFET zu
testen? Das müsste eigentlich funktionieren, ich habe aber leider keinen
einzigen da, um es ausprobiern zu können.

Eine Testfunktion für Verarmungs-MOSFETs und JFETs werde ich wohl auch
noch einbauen. Erstmal muss ich mir aber solche Bauteile besorgen (ich
habe eine ganze Menge verschiedene NPN-Transistoren und
N-Kanal-Anreicherungs-MOSFETs, aber JFETs und so habe ich kaum).

Markus F. wrote:

> Und noch etwas: Könnte jemand, der den Transistortester schon aufgebaut
> hat, einmal versuchen, damit einen P-Kanal-(Anreicherungs)MOSFET zu
> testen? Das müsste eigentlich funktionieren, ich habe aber leider keinen
> einzigen da, um es ausprobiern zu können.

Habs mal eben ausprobiert: Funktioniert: P-Kanal Mosfet
Bisher hat das Gerät alles richtig erkannt. Die ganz gemeinen Sachen
habe ich allerdings noch nicht ausprobiert...

> Eine Testfunktion für Verarmungs-MOSFETs und JFETs werde ich wohl auch
> noch einbauen.

Wie willst du die messen?
Die brauchen ja normalerweise eine negative Spannung, damit diese
sperren.
Da dies ja nicht geht, müsste man den Sourceanschluss positiver legen
als das Gate, aber wiederum negativer als Drain (zumindest beim Mosfet,
beim JFET ist das egal).
JFETs und Verarmungs-MOSFETs könnte man dadurch unterscheiden, dass das
Gate beim JFET leitet sobald es positiv wird, während beim N-Verarmungs
MOSFET das Gate hochohmig ist. Dafür hat letzteres die Source-Drain
Diode.

Mir ist aber gerade noch eine andere Idee eingefallen:
Und zwar könnte man mit ein paar Tricks die Schwellspannung von Mosfets
messen:
Ich gehe jetzt mal von einem normalen N-Kanal Mosfet aus:
Man legt Source auf GND, Drain über den 680 Ohm Widerstand an 5V und
Gate zunächst auch auf GND.
Anschließend schaltet man das Gate über den 470k Widerstand an 5V und
misst  den Logikpegel an Drain. Sobald dieser auf Low geht, schaltet man
das Gate hochohmig. Dann hat man nämlich gerade den Schaltpunkt
erreicht. Nun misst man die Spannung am Gate.
Das ganze wird zwar alles andere als genau, da man das RC Glied 470k-GS
Kapazität (die man über die Ladezeit auch noch mitmessen könnte) als DA
Wandler missbraucht, aber es wäre ohne Hardwareerweiterung möglich.

> Wie willst du die messen?
> Die brauchen ja normalerweise eine negative Spannung, damit diese
> sperren.

Da hatte ich schon eine Idee:
Der AVR hat ja interne 10k Pullup-Widerstände. Dann baut man eben
zunächst an Gate und Drain damit zwei Spannungsteiler: 10k nach Plus und
680 Ohm nach Masse. Das ergibt dann so 0,36V. Drain kommt auf Plus. Wenn
man einen Verarmungs-MOSFET oder JFET angeschlossen hat, werden Drain
und Source "aufeinander zu", also in Richtung 5V gezogen. Man misst
jetzt die Spannung an Source und speichert sie zwischen.
Dann legt man das Gate fest auf Masse und misst erneut die
Sourcespannung. Wenn dieser Wert kleiner ist als der vorherige, bedeutet
das, dass weniger Strom von Drain nach Source fließt. Es müsste sich
dann also um einen Verarmungs-MOSFET oder JFET handeln.

Okay, man kann mit dieser Methode nicht prüfen, ob der FET ordnungsgemäß
vollständig sperrt, weil die negative Spannung am Gate eben maximal 5V
beträgt, in der Praxis wohl eher 1-2V. Die negative Gate-Sourcespannung
sinkt ja immer weiter, wenn der FET zu sperren beginnt, da Source immer
weiter gegen Masse geht.

=> Benedikt:
Die Messung der Gate-Schwellspannung ist auch eine gute Idee. Sehr genau
wird es mit den AVR-internen ADCs wohl nicht, aber als Schätzeisen
reicht es.

Platz für Erweiterungen ist noch genug: Von den 8kB Flash des Mega8 sind
erst ca. 3,7kB belegt.

Laut mega8 Datenblatt 20-50k.
Im Gegensatz zu den alten AVRs ist der ziemlich konstant (Seite 262: Pin
Pull-up Figure 143. I/O Pin Pull-up Resistor Current vs. Input Voltage
(VCC = 5V))
Der Verlauf ist nahezu eine perfekte Gerade.
Im Vergleich dazu: AT90S2131, Seite 80: Figure 68. Pull-up Resistor
Current vs. Input Voltage)
Da sah die Kurve noch sehr viel Mosfet artiger aus, also mit steigendem
Strom zunehmend in die Sättigung gehend.

> Laut mega8 Datenblatt 20-50k.
Ja, stimmt (habe selbst nochmal nachgesehen). Ich hatte irgendwie 10k in
Erinnerung.
Ist natürlich nicht so toll, weil man fast keine Spannung mehr kriegt,
wenn man den mit einem 680Ohm Widerstand zu einem Spannungsteiler
schaltet.
Ich werde mal versuchen, ob es trotzdem irgendwie klappt damit JFETs und
Verarmungs-MOSFETs zu messen. Dann ist es aber auch langsam gut mit
unterstützten Bauteilen. Je mehr Bauteile unterstützt werden, desto
wahrscheinlicher wied auch eine Falscherkennung.

Ich habe gerade nochmal eine neue Version der Firmware zu dem Artikel
reingestellt.
In der neuen Version werden Thyristoren und Triacs deutlich
zuverlässiger erkannt (vorher habe ich da irgendwie Mist gebaut...).
Kleine Thyristoren sollten jetzt einwandfrei erkannt werden. Bei mir
klappt es auch mit einem Leistungs-Triac (BT136), das ist aber eher
Glückssache.

Außerdem wurden öfter mal die Schutzdioden von MOSFETs nicht erkannt.
Das klappt jetzt auch.
Dann fehlen eigentlich nur noch Verarmungs-MOSFETs und JFETs (wenn
möglich). Und vielleicht noch Gimmicks wie die Messung der
Gate-Schwellspannung, Gatekapazität, Basis-Emitter-Spannung,...
Platz wäre noch genug da, der Controller ist erst knapp halb voll.

Würde das ganze auch noch in einen Mega48 reinpassen?

Momentan noch. Der mega48 hat vermutlich aber keine Zukunft mit all den
geplanten Erweiterungen:

AVR Memory Usage
----------------
Device: atmega48

Program:    3526 bytes (86.1% Full)
(.text + .data + .bootloader)

Data:        348 bytes (68.0% Full)
(.data + .bss + .noinit)

Der viele RAM geht momentan anscheinend für die LCD Strings drauf, die
man in den Flash packen könnte.

Benedikt K. wrote:
> Data:        348 bytes (68.0% Full)
> (.data + .bss + .noinit)
>
> Der viele RAM geht momentan anscheinend für die LCD Strings drauf, die
> man in den Flash packen könnte.
Oder ins EEPROM oder wird das anderweitig verwendet? Hintergrund ist
einfach der, ich hab noch nen paar Mega48 im TQFP hier rumliegen und
würde mir dann ggf ne MiniVersion davon mal basteln (habe zufällig auch
das Mini LCD von Pollin bestellt, ist echt niedlich). Welche Optimierung
hast du den gewählt?

Läubi .. wrote:

> Oder ins EEPROM oder wird das anderweitig verwendet?

So wie ich das sehe ist das noch komplett frei.

> Welche Optimierung hast du den gewählt?

Os. Mit O2 sind es knapp über 90%.

Das dürften 1MHz sein wenn ich die Fusebits richtig interpretiere.

Ja, die ganzen Strings für das LCD könnte man auch ins EEPROM packen.
Würde schon einiges sparen.
Allerdings hat ein Mega48 auch nur ein 256B EEPROM, das könnte knapp
werden, besonders bei eventuellen Erweiterungen. Da bräuchte man dann
schon wieder zwei Versionen der Firmware, eine die alle Strings im
EEPROM hat (für Mega8, der hat 512B EEPROM) und eine die zusätzlich noch
welche im Flash hat (für Mega48). Versuchen könnte ich es aber mal.


=> Stefan:
Ja, der AVR läuft auf internem Oszillator mit 1MHz.

Oder man legt prinzipell erstmal bis zu 256 bytes im EEPRom ab dann
gehts (erstmal) für beide. Mach dir aber nicht zuviele Gedanken deswegen
im Zweifel muß ich mir nochmal nen Mega88 besorgen, hatte nur Gedacht
wen der Mega8 eh nur zur Hälfte voll ist könnte man ja auch den etwas
günstigeren 48er hernehmen. Wenn irgenwelche Zeiten gemessen Werden
sollen wäre aber ein externer Quarz auch schon ne Überlegung wert...

Ich habe mal die Gate Threashold Spannungsmessung mal eingebaut.
Das funktioniert erstaunlich gut, die Werte sind sehr gut
reproduzierbar. Nur bei sehr kleinen Mosfets (BS170 usw.) springen sie
um etwa +/-100mV, da die RC Zeitkonstante sehr klein ist. Hier könnte es
helfen, den AVR schneller laufen zu lassen.
Ebenso sind die Werte sehr großen Toleranzen unterworfen, da die
Schwelle der Ports nicht wirklich konstant ist. Zur Unterscheidung eines
Logiklevel und eines normalen Mosfets sollte es aber durchaus
ausreichen.
Man sieht auch deutlich den Einfluss der Millerkapazität:
Solange die rote Drainspannung konstant bleibt, ist die Gatesource
Spannung eine e-Funktion. Sobald die Drainspannung aber zu sinken
beginnt, geht die Kurvenform eher in Richtung Gerade. Am Ende der Kurve
sieht man deutlich wo das Laden der Gatekapazität abgeschaltet wird und
die ADC Messung anfängt.
Danach kommt der nächste Messzyklus (hier nur um ein Foto vom Oszi
machen zu können).

void measurevgate(void)
{  uint8_t tmpval, tmpval2;
//for(;;)
{
  ADC_PORT=0;
  ADC_DDR=(1<<e)|(1<<b);
  R_DDR = (1<<(2*c));        // Drain: starker pullup, Gate: schwacher pullup + interner pullup
  R_PORT = (1<<(2*c))|(2<<(2*b));  // Drain: starker pullup, Gate: schwacher pullup
  _delay_ms(1);          // gate entladen

  tmpval=(1<<c);
  tmpval2=(1<<(2*c));
  ADC_DDR=(1<<e);          // gate über 470k+pullup langsam laden
  while (ADC_PIN&tmpval);      // warten bis drain auf low
  R_PORT=tmpval2;          // gate ladewiderstand abschalten
  vgate=(unsigned long)ReadADC(b)*78/16;
}
}

Und weils so schön ist: Hier mal die komplette Kurve, wenn der
Gateladevorgang nicht unterbrochen wird.
Man sieht hier den Einfluss der Millerkapazität sehr deutlich: Sobald
die Drainspannung wieder stabil ist, setzt sich die e-Funktion fort.
Eine Messung der Gatekapazität müsste daher bei konstanter Drainspannung
erfolgen. Allerdings würde man dann nicht die Gatesource kapzität,
sondern die Gatesource+Gatedrain Kapazität. Da in der Praxis aber die
Millerkapazität einen stärkeren Einfluss hat, als die Gatekapazität, ist
es sogar gut wenn man diese mitmisst. Wirklich einen konkreten Wert kann
man hier sowieso nicht messen, so ungenau wie alles ist, aber man könnte
die Ladezeit als groben Anhaltswert zum Vergleich von Mosfets verwenden:
Je größer die Ladezeit, desto mehr Energie erfordert die
Gateansteuerung. Vor allem bei hohen Frequenzen ist dieser Wert
interessant.

Und noch ein paar Messwerte:
        gemessen, Datenblatt (min, typ, max)
BSS98:     1.53V, 0.8V, 1.2V, 1.6V
IRF1405:   3.62V, 2.0V,  -  , 4,0V
BS170:     2.45V, 0.8V, 2.1V, 3.0V
BUK555:    1.69V, 1.0V, 1.5V, 2.0V

Der Drainstrom liegt mit etwa 4-5mA etwas höher als die Angaben im
Datenblatt (250µA-1mA), daher die etwas hohen Werte im Vergleich zu den
typ. aus dem Datenblatt.

Markus hat da ein echt schönes Projekt angefangen, das man wunderbar
erweitern kann.

=> Benedikt:
Etwa genau so habe ich mir das mit der Messung der Gatespannung auch
vorgestellt. Als Ausgabewert würde ich aber keine unsigned long nehmen,
unsigned int reicht dicke aus.
Die Oszi-Bilder sind auch schön. Da sieht man wirklich gut, was die
Millerkapazität ausmacht.

=> Läubi:
Wie ich das mit den Strings fürs LCD gemacht habe ist sowieso nicht
ideal. Das kostet nämlich Platz in Flash und RAM. Allein deswagen ändere
ich das nochmal und packe die Strings ins EEPROM.

Und so ungenau wie die Messung der Gatekapazität werden würde, spielen
auch die paar % Toleranz des RC-Oszillators keine große Rolle mehr. Den
Quarz kann man sich also eingentlich auch sparen.

Markus F. wrote:

> Als Ausgabewert würde ich aber keine unsigned long nehmen,
> unsigned int reicht dicke aus.

Der cast auf unsigned long ist notwenig, wegen der Multiplikation mit
78. Das passt nämlich nicht mehr in einen int. Am Ende wird dann wieder
ein int draus:
78/16=4,875
5000mV/1024=4,88

Wobei 78/16 kann man kürzen, dann wird das *39/8 draus, das passt
wiederum (keine Ahnung wieso ich das nicht gesehen habe).

Du verwendest einen Faktor von etwa 4,6 zum Umrechnen vom ADC Wert in
mV, das passt von der Theorie her nicht ganz. Wie kommst du auf diesen
Wert?

PS:
Man kann die ADC Funktion noch etwas optimieren indem man nicht den
Freerunning Modus verwendet:

unsigned int ReadADC(uint8_t mux) {
  //ADC-Wert des angegebenen Kanals auslesen und als unsigned int zurückgegen
  unsigned int adcx = 0;
  ADMUX = mux | (1<<REFS0);
  for(uint8_t j=0;j<32;j++) {  // 32 Messungen; für bessere Genauigkeit
    ADCSRA = (1<<ADEN) | (1<<ADSC) | 5;  // Vorteiler=32
    while (ADCSRA&(1<<ADSC));
    adcx += ADCW;
  }
  adcx /= 32;
  return adcx;
}

Das geht schneller, da wirklich jedes ADC Ergebnis verwendet wird.
Theoretisch könnte man so sogar eine etwas höhere Auflösung von etwa 11
Bits erreichen, wenn der ADC Wert zwischen 2 Werten hin und her
schwankt.

> Du verwendest einen Faktor von etwa 4,6 zum Umrechnen vom ADC Wert in
> mV, das passt von der Theorie her nicht ganz. Wie kommst du auf diesen
> Wert?
Durch Ausprobieren, der eigentlich richtige Wert von 4,88 hat nämlich
etwas falsche Ergebnisse gebracht (keine Ahnung warum).

Das mit dem Free-Run stimmt natürlich auch. Ich wollte das ganze Projekt
sowieso nochmal etwas optimieren. Es ist nämlich wieder mal das passiert
was normalerweise nicht sein sollte:
- Man plant ein überschaubares Projekt
  Erstmal hatte ich nur Testfunktionen für NPN und PNP eingebaut. Der
allererste Aufbau war sigar mit einem Tiny13 und einem CMOS 4024 für die
Widerstände. Ich habe aber sehr schnell gemerkt, dass 1k Flash nie
reichen werden. Also gleich einen Mega8, anstatt nachher noch einen
teuren Tiny85 kaufen zu müssen. Außerdem muss bei dem ATTiny sowieso
RSTDISDL gesetzt werden, um überhaupt 6 Portpins für das LCD zu haben.
Ist auch nicht ideal, weil man dan einen HV-Programmer braucht. Und den
hat ja hier auch nicht jeder (ich habe auch nur einen selbstgebauten,
der nur für 8-und 14-pin AVRs geht).
- Dann fällt einem immer mehr ein, was man noch einbauen könnte, und man
baut das auch sogleich ein
- Nun hat man ein recht großes, unübersichtliches und teilweise auch
nicht optimales Projekt

Irgendwie passiert mir das fast bei jedem Projekt. Bessere Planung würde
da helfen... Der Transistortester ist da noch ein recht harmloses
Beispiel.

Ich habe jetzt nochmal ein neues Archiv reingestellt. Da habe ich den
ADC-Freerun entfernt. Der Test geht jetzt wie erwartet deutlich
schneller.
Außerdem sind die Strings jetzt größtenteils im EEPROM. Also bitte auch
die beiliegende eep-Datei ins EEPROM schreiben.

Auf einem Mega8 ist der Speicher jetzt folgendermaßen belegt:
Program:    3650 bytes (44.6% Full)
Data:         66 bytes (6.4% Full)
EEPROM:      232 bytes (45.3% Full)

Bei einem Mega48 wären es 3682 Bytes Flash (89,9%). Das wird also eng.

Noch eine Frage: Wie sollte ich die Anzeige für die Gate-Schwellspannung
bei MOSFETs dann am besten machen? Im LCD ist da so kein Platz mehr. Im
Frage käme eine Scrollfunktion, also eine weitere Zeile, zu der man per
Taster wechseln kann (auch über den Einschalttaster, dann müsste man ihn
z.B. <0,5s drücken um zu scrollen oder >0,5s um einen neuen Testzyklus
zu starten. Eine Alternative wäre eine Laufschrift in der 2. Zeile. Was
meint ihr ist besser? Oder hat noch wer einen anderen Vorschlag?
(größeres LCD nehmen geht eigentlich nicht...).

Markus F. wrote:

> Noch eine Frage: Wie sollte ich die Anzeige für die Gate-Schwellspannung
> bei MOSFETs dann am besten machen? Im LCD ist da so kein Platz mehr.

Wenn man man die unnötigen Infos entfernt, und den Rest etwas
zusammenpackt, reicht es. Bei mir sieht die Anzeige so aus:
N-Mosfet Qg=1234
GDS=123 Vt=1.23V

> Wenn man man die unnötigen Infos entfernt, und den Rest etwas
> zusammenpackt, reicht es. Bei mir sieht die Anzeige so aus:
> N-Mosfet Qg=1234
> GDS=123 Vt=1.23V

Okay, das ist auch eine Möglichkeit. Ist aber etwas unübersichtlich. Das
ist aber trotzdem eine gute Idee und ich werde es auch erstmal so
machen. Auf alle Fälle ist es besser als scrollen oder Laufschrift.

Ich hatte mir auch erst überlegt einen Taster einzubauen mit dem man bei
dem Ergebnis auf eine 2. Seite wechseln kann.
Die 1. Seite wäre dann die allgemeinen Infos, also Typ + Belegung, die
2. die Basis-Emitter bzw. Gatespannung usw.
Allerdings ist das viel Aufwand, und es sind ja nur die Mosfets bei
denen es wirklich notwendig ist, daher die Kompaktanzeige.

> ich hab mal eine Frage und zwar ist es möglich mit dem Tester auch
> die Durchlaßspannung von LEDs zu ermitteln ?

Ja, bis 2,5V. Ich werde diesen Wert aber nochmal etwas erhöhen, so auf
3,5V bis 4V. Das sollte für fast alle LEDs reichen.
Höher als 4V sollte man aber vermutlich nicht gehen (dann wird die
Wahrscheinlichkeit, dass irgendwelche Bauteile fälschlicherweise als
Diode erkannt werden recht groß).

LEDs werden als Diode angezeigt, mit entsprechender Durchlassspannung
(ca. 2V bei Standard-LEDs).

Das ist ein interessanten Projekt. Ich werde den Tester mal nachbauen.
@Markus: Kannst du den neuen Quelltext zur Verfügung stellen? Unter
http://www.mikrocontroller.net/articles/AVR-Transistortester
findet sich nur das alte Programm. Oder habe ich etwas übersehen?
Harald

Ich habe jetzt den neuen Quelltext reingestellt und den Artikel noch
etwas geändert. Folgende Features sind jetzt neu:

- Erkennung von Verarmungs-MOSFETs und JFETs (n- uns p-Kanal;
größtenteils noch ungetestet, weil ich kaum solche Bauteile habe)
- Messung und Anzeige der Gate-Schwellspannung
- Watchdog, damit der Tester nicht in irgendeiner Endlosschleife
hängenbleibt
- Erkennung von Dioden bis 4V Durchlassspannung (vorher: 2,5V)

Das Programm würde sogar noch in einen Mega48 passen (3970 Bytes).
Messung der Gate-Ladung ist aber noch nicht eingebaut. Da würde der
Mega48 wohl auch nicht mehr reichen (da ist nämlich die Berechnung des
natürlichen Logarithmus (ln) nötig).

Ich werde dann wohl demmächst noch ein paar FETs kaufen. Um den
Transistortester damit auszuprobieren, aber natürlich auch so zum
Basteln...
Folgende Typen habe ich nach einiger Sucherei gefunden:

P-Kanal-JFET: 2N5461 (P-JFETs scheinen sehr selten zu sein)
N-Kanal-Verarmungs-MOSFET: BF980 (ist ein Dual-Gate-Typ und damit auch
allgemein zum Basteln recht interessant; einen anderen, der bei Reichelt
erhältlich ist habe ich auch nicht gefunden)
P-Kanal-Anreicherungs-MOSFET: IRF9540 o.ä. (hier ist die Auswahl recht
groß)
P-Kanal-Verarmungs-MOSFET: ? (sowas gibt es möglicherweise gar nicht,
oder kennt ihr einen?)

Solche FETs scheinen aber allesamt nicht so häufig anzutreffen zu sein,
am ehesten noch die p-Kanal-Anreicherungs-FETs. In einer Kiste voll
Elektronikschrott habe ich kein solches Bauteil gefunden. Immerhin waren
2 N-Kanal-JFETs (BF245) dabei...

Sehe ich das richtig das der ganze linke Teil (Abzüglich der
Blockkondensatoren und dem Taster) nur der Automatischen Abschaltung
dient und auch weggelassen werden kann? Würde meine Schaltung einfach
per Netzteil versorgen.

Hi,

super Projekt, werde ich auf alle Fälle auch nachbauen. Die Hardware ist
elegant einfach.

Ich werde aber auch die automatische Abschaltung weglassen. Für mich tut
es ein zusätzlicher Schalter auch.

Ist es dann nötig die Software anzupassen?

> Ich werde aber auch die automatische Abschaltung weglassen. Für mich tut
> es ein zusätzlicher Schalter auch.

> Ist es dann nötig die Software anzupassen?
Nein, es ist nicht nötig, die Software anzupassen.
An der Hardware muss man dann folgendes ändern:
T1, T2 und T3 entfallen, genauso die Widerstände R7, R8, R9 und R10.
LED1 und C2 entfallen auch. Anstelle von T3 wird einfach eine Brücke
eingesetzt.
Die Pins 12 und 13 (PD6 und PD7) des ATMega8 werden einfach offen
gelassen.
Wer mag, kann auch von Pin 13 des Mega8 noch einen Taster gegen Masse
anschließen. Damit könte man dann einen neuen Testzyklus starten, ohne
den Tester aus- und wieder einschalten zu müssen.

> Wird bei deinem Tester der Leckstrom in die Berechnung des HFE Werte
> einbezogen ?

Nein, bisher noch nicht. Das ist auch nicht ganz so einfach

> Warum? Wenn du den Typ(NPN/PNP) hast, brauchst du die Pins für die
> Widerstände nur auf Eingänge umschalten.
> Danach Spannung messen und durch den Widerstand dividieren.

Das stimmt zwar, die Auflösung der ADCs ist aber zu schlecht, um den
Leckstrom genau messen zu können. Bei 5V Referenz und 10 Bit Auflösung
kann man nur auf ~5mV genau messen. Das entspricht ca. 7,3µA Strom
(durch den 680 Ohm-Widerstand). Bei 50µA Leckstrom wird da nicht viel
angezeigt (ADC-Wert 7; da fallen schon interne Offsets ins Gewicht).
Interessant wird es erst bei einigen 100µA, aber das ist auch für einen
Ge-Transistor schon ein recht hoher Leckstrom.

Sehr genau wird das somit nicht werden, aber einbauen werde ich die
Messung trotzdem mal, schadet ja nicht.

Tja wrote:
> Habe ja mal irgendwo im Forum gelesen, das die AVR intern einen
> Tempsensor verbaut haben.

mmh. Also davon hab ich noch nichts gehört und auch im Datenblatt noch
nicht gesehen. Wenn es aber so sein sollte fänd ich das echt cool.

Es gibt irgendwelche (ich glaub bei den Tinys) modelle, die den
Tempsensor drin haben, der aber nicht wirklich genau ist.

> ATiny25 z.B. haben einen integrierten Temperatursensor.

Ja, den wollte ich sogar schon mal für ein anderes Projekt nehmen. Der
ist wie die ADCs abzufragen (dafür muss man eben ADMUX entsprechend
setzen). Der Ausgabewert ändert sich je °C etwa um 1. Das ist schon
recht ungenau, zudem haben die Sensoren recht große Exemplarstreuungen.
Diese Sensoren sind mal wieder typisch "Kost' nix, taugt nix".

Über Germanium-Transistoren weiß ich allerdings nicht so viel, habe noch
nie einen benutzt (ist nicht meine Zeit...). Mittlerweile sind die ja
auch kaum mehr erhältlich.

Hallo alle zusammen,

die ersten Platinen habe ich bekommen die Bezugsquelle für euch habe ich
mit in den Artikel (unter Hardware) geschrieben um hier mal keine
Werbung zu machen ;)

Die Platine an dich Markus versende ich direkt nach Ostern, vorher
schaffe ich es leider nicht mehr.

Sobald ich den Tester fertig habe mit Gehäuse etc. kommen mal ein paar
weitere Bilder dazu.

Ich wünsche allen ein frohes Osterfest und viele Eier ;)

Thomas

Hallo Markus,

was ich als Zusatzfunktion interessant fände, wäre eine
Leitungstestfunktion noch für Cat5 oder serielle Datenleitungen mit
Erkennung von Kurzschlüssen und Kreuzungen (X-over oder Nullmodem). Man
müßte dann evtl auf einen größeren Mikrocontroller, aber wenn ich mir so
das Bild von der IT-WNS Platine anschaue müßte auch ein 40pin
draufpassen (vorausgesetzt das Routing passt). Wahrscheinlich sollte man
dann noch Adapter haben, aber das wäre glaub das kleiner Übel.

Gruss Chris

Naja das hat dann nicht mehr viel mit nem Transistortester gemein ...

Man könnte sich aber trotzdem selbst mit nem größeren µC nen
"allestester" zusammenschustern, basierend auf dem code hier.

Das Layout der Platine von IT-WNS.de ist doppelseitig. M.E. nach ist das
nicht wirklich nötig und man würde mit einer handvoll Brücken auskommen.

Besser fände ich daher das .sch, dann kann man sich seine Platine selbst
machen.

So einen "Allestester" finde ich eigentlich nicht so sinnvoll. Praktisch
wäre es natürlich, aber man müsste es so machen, dass man auswählen muss
was getestet werden soll. Wäre doch irgendwie ungünstig, wenn ein
defekter Transistor als Cat5 Kabel angezeigt wird...
Zum Test von Kabeln (z.B. Cat5) bräuchte man auch entsprechend viele
Portpins und einen für das jeweilige Kabel passenden Terminator, der
alle Pins des Kabels auf definierte und für jede Ader unterschiedliche
Pegel legt (im einfachsten Fall eine Spannungsteiler-Kette). Außerdem
müsste man Buchsen für RJ45, D-Sub-9, usw. einbauen, je nachdem welche
Kabel unterstützt werden sollen. Meiner Meinung nach wäre ein extra
Tester da sinnvoller.

Markus F. wrote:
> So einen "Allestester" finde ich eigentlich nicht so sinnvoll. Praktisch
> wäre es natürlich,
Ist finde ich praktisch wenn man keinen so großen Geräte-Fuhrpark hat.
Allerdings bräuchte man auf jeden Fall ein zweites Gerät, damit man auch
verbaute Kabel testen kann. (Sender & Empfänger)

> Zum Test von Kabeln [] bräuchte man auch entsprechend viele Portpins
Oder einen 74HC595 für die Ausgänge und einen 74HC165 für die Eingänge.

> und einen für das jeweilige Kabel passenden Terminator, der
> alle Pins des Kabels auf definierte und für jede Ader unterschiedliche
> Pegel legt (im einfachsten Fall eine Spannungsteiler-Kette).
Das wäre eine Möglichkeit.
Eine andere: Es wird der Reihe nach an die Pins ein High Signal
angelegt, die restlichen Pins fungieren als Masse. Entkopplung durch
Dioden.
Somit erkennt man Unterbrechungen, Vertauschungen, Schlüsse.

> Es wird der Reihe nach an die Pins ein High Signal
> angelegt, die restlichen Pins fungieren als Masse
Damit kann man aber keine Unterbrechungen feststellen, wenn das andere
Ende des Kabels offen bleibt. Oder meinst du, dass man 2 "intelligente"
Geräte (jeweils mit µC) hat? Da wäre dann aber ein "intelligentes"
Testgerät und ein passiver Terminator einfacher.
Das mit den Schieberegistern wäre auch eine Möglichkeit. Allerdings
haben die nur 8 Bit. Da wird man dann wohl je 2 davon brauchen, um z.B.
auch D-Sub-9-Kabel testen zu können.
Ist natürlich Geschmackssache, ob man einen Tester für alles oder
einzelne Tester für jeden Bauteiltyp haben möchte. Kabel und
Transistoren sind aber meiner Meinung nach doch recht unterschiedliche
Teile.
Sonst könnte man ja gleich noch einen LTC2400 (24-bit-ADC),
Spannungsteiler und Shunts zur Strommessung einbauen und hat dann gleich
noch ein 8-Digit-Multimeter...(zumindest in der Theorie, in der Praxis
ist die nutzbare Auflösung geringer).

Markus F. wrote:
> Oder meinst du, dass man 2 "intelligente" Geräte (jeweils mit µC) hat?
Ja, einmal ein µC, für die andere Seite langt ein Schieberegister.

> Da wäre dann aber ein "intelligentes" Testgerät und ein passiver
> Terminator einfacher.
Mhh, und wenn die Adern unterschiedliche Widerstände haben, weil Signal
und Stromkabel zusammenliegen.
Zugegeben ist das die Ausnahme.

> Kabel und Transistoren sind aber meiner Meinung nach doch recht
> unterschiedliche Teile.
Allerdings.
Man könnte den Kabeltester ja parallel entwickeln.

Hallo Markus,
interessantes Projekt. Ich bin dabei alles zusammen zu löten. Auf der
Artikelseite ist allerdings immer noch eine Software vom 17.04.2008
verlinkt. Gibt es die aktuelle Version auch irgendwo?

Die Software ist nicht vom 17.04.2008, sondern vom 21.03.2009. Das
falsche Datum der Dteien in dem Archiv kommt daher, dass ich beim
Erstellen scheinbar eine falsche Systemzeit eingestellt hatte.
Ja,das Messen von Widerständen wäre mit der jetzigen Hardware möglich.
Allerdings haben die ADCs nur eine Auflösung von 10 Bit, also 1024
verschiedene Werte. Da ist ein Billigst-Multimeter besser (meist 2000
verschiedene Anzeigewerte, bzw. sogar 3999, wenn man den negativen
Bereich mitzählt). Außerdem wäre zum Messen von Widerständen eine
Konstantstromquelle
hilfreich. Die ist aber in dieser Hardware nicht vorgesehen, weil sie
zum Halbleiter testen nicht nötig ist.
Man kann Widerstände auch ohne Konstantstromquelle testen, indem man den
zu testenden Widerstand mit einem anderen R als Spannungsteiler
schaltet. Die Genauigkeit wird dann aber am besten, wenn beide
Widerstände etwa gleich groß sind. Bei der Transistortester-Hardware
stehen aber nur 680 Ohm und 470kOhm zur Verfügung. Widerstände wie 10
Ohm oder 33kOhm können damit nur recht unpräzise gemessen werden.

Kurz: Eine Widerstands-Messfunktion wäre denkbar, aber wohl so ungenau,
dass sie wenig hilft. So als nette Zusatzfunktion kann ich es aber mal
einbauen.

Kondensatoren wären auch möglich. Dafür ist aber eine
Logarithmus-Berechnung nötig. Mit der in avr-gcc vorhandenen wird das
Programm so groß, dass es kaum mehr in einen Mega8 passt. Müsste man
wohl in Assembler selbst schreiben (Stichwort:Logarithmusreihe).

Ich hatte sowieso mal vor, noch ein Testgerät für Widerstände und
Kondensatoren zu bauen. Am besten auch noch mit ESR-Messung und Schutz
gegen eventuell vorhandene Spannungen auf dem Kondensator. Dafür wäre
aber ein 16-bit-ADC von Vorteil, und ich habe noch kaum einen halbwegs
schnellen (>10kSps), bezahlbaren (<10€) und auch bei z.B. Reichelt
erhältichen gesehen.
Von der Hardware her dürfte das Ganze dann auch ein gutes Stück
komplexer werden als der Transistortester.

Markus F. wrote:

> Ich hatte sowieso mal vor, noch ein Testgerät für Widerstände und
> Kondensatoren zu bauen. Am besten auch noch mit ESR-Messung und Schutz
> gegen eventuell vorhandene Spannungen auf dem Kondensator. Dafür wäre
> aber ein 16-bit-ADC von Vorteil, und ich habe noch kaum einen halbwegs
> schnellen (>10kSps), bezahlbaren (<10€) und auch bei z.B. Reichelt
> erhältichen gesehen.
> Von der Hardware her dürfte das Ganze dann auch ein gutes Stück
> komplexer werden als der Transistortester.

So eine Idee hatte ich auch mal, ich wollte das ganze aber noch
erweitern so dass es nicht nur RLC einzeln, sondern aus irgendeiner
beliebigen RLC Schaltung RLC einzeln ermitteln kann. Dies ist vor allem
wichtig um parasitäre Cs bei Spulen zu ermitteln.
Theoretisch ist das möglich, die Realisierung dürfte aber recht
kompliziert werden, ohne DSP oder ähnliches nahezu unmöglich.

Ein Ansatz für ein einfaches RLC Meter findet man hier:
http://www.elektor.de/jahrgang/2008/juni/2-euro-rl...
Das muss ich demnächst mal ausprobieren, ob es R+L, bzw. C+R auch
richtig messen kann. Sowas sollte sich auch relativ leicht auf einem µC
(ARM oder ähnliches mit entsprechendem Audio Codec Interface)
realisieren lassen.

Das hier sieht auch gut aus, leider habe ich weder Schaltplan noch sonst
was gefunden. Aber ein 25MHz DSP klingt schonmal vielversprechend:
http://www.elektor.de/jahrgang/1997/april/high-tec...

PS: Weiß jemand wie LCR Meter arbeiten? Mein gekauftes erzeugt einen
Sinus mit 1kHz und etwa 10-20mV. Es kann L+R, bzw. C+R messen und lässt
sich selbst durch einen zusätzlichen C parallel zur Spule nicht
täuschen.

Vielen Dank für das Projekt, habe das gestern nachgebaut und
funktionierte fast auf Anhieb. Es hat sich in der LCD-Initialisierung
ein Fehler eingeschlichen so das mein 2-Zeilen Display nur einzeilig
lief.

Laut dem HD44780 Datasheet (Seite 46, Figure 24 4-Bit Interface) muss 3
mal 0011 auf D7..D4 gesendet werden. In lcd_init() wurde aber
lcd_command(0x03) verwendet. lcd_command sendet aber 2 x 4 Bit. Das
gleiche für die 4 Bit-Initialisierung. Bei mir klappt es so (und das
sollte auch für alle anderen Displays funktionieren):

void lcd_init(void)
{
   LCD_DDR = LCD_DDR | 0x0F | (1<<LCD_RS) | (1<<LCD_EN1);   // Port auf Ausgang schalten
   // muss 3mal hintereinander gesendet werden zur Initialisierung
   _delay_ms(15);
   //lcd_command(0x03);
   LCD_PORT &= 0xF0;
   LCD_PORT |= 0x03;    // D7..D4 = 0x03
   lcd_enable();    // Strobe E
 
   _delay_ms(5);    // according to datasheet: more than 4.1 ms
   lcd_enable();
 
   _delay_ms(1);    // according to datasheet: more than 100 uS
   lcd_enable();
   _delay_ms(1);

   // 4 Bit Modus aktivieren 
   //lcd_command(0x02);
   LCD_PORT &= 0xF0;
   LCD_PORT |= 0x02;
   lcd_enable();
   _delay_ms(1);

   lcd_command(0x28);          // 4Bit / 2 Zeilen / 5x7
   lcd_command(0x0C);         // Display ein / Cursor aus / kein Blinken
   lcd_command(0x06);        // inkrement / kein Scrollen
  lcd_clear();
}

ich habe noch in main.c ein define eingebaut falls kein automatisches
ausschalten verwendet wird (#define AUTOPOWEROFF) in Zeile 8. Falls
AUTOPOWEROFF gesetzt ist, wird der originale Code verwendet. Andernfalls
wird auf ewig auf Tastendruck gewartet um den Test neu zu starten.

Im Anhang der geänderte Code + Makefile + eagle sch und brd für eine
einseitige Platine.

und so sieht es dann aus

=> Armin Diehl:
Stimmt, da habe ich einen Fehler gemacht. Ich nehme halt für jedes
Projekt die gleiche lcd-routines.c und lcd-routines.h her. Bei mir hat
das so auch immer geklappt, aber es scheint LCDs zu geben, die da
Probleme machen.
Danke für den Hinweis!

Noch eine Frage an alle:
Ich habe mal versucht, eine Testfunktion für Widerstände einzubauen (ist
noch nicht in dem zip-Archiv enthalten). Der Messbereich wäre etwa 100
Ohm bis 900 kOhm.
Allerdings werden damit auch viele defekte Halbleiter als Widerstand und
nicht als "defektes Bauteil" erkannt. Ich weiß jetzt nicht, ob die
Testfunktion für Widerstände damit eher sinnvoll oder eher störend ist.

Die Erkennung von funktionierenden Halbleitern ist davon aber nicht
betroffen. Das Testergebnis "Transistor" hat nämlich eine höhere
Priorität als "Widerstand". Sehr leistungsstarke Dioden (z.B.
35A-Gleichrichter) könnten aber als "Widerstand" erkannt werden.

Also ich find ne Widerstandtestfunktion eher nicht soooo sinvoll, ggf
höchstens an nem zusätzlichen ADC Port. Sowas zu testen schafft zur not
jedes Multimeter (wenn man den Verdacht hat der Wid sei defekt).

So, ich habe jetzt mal wieder eine neue Version reingestellt.
Eine "kleine" Version, die auch noch auf einen Mega48 passt. Hier ist
der genannte Fehler mit dem LCD auch schon berichtigt. Diese Version
wird aber kaum mehr erweitert werden, weil in einem Mega48 dafür keim
Platz mehr wäre. Da ich keinen Mega48 zur Hand habe konnte ich sie damit
nicht testen. Sollte aber funktionieren.

Und eine "große" Version, für die dann eben ein Mega8 nötig ist.
Die hat die Widerstands-Testfunktion eingebaut. Das ist bisher auch der
einzige Unterschied zu der "kleinen" Version. In Zukunft kommt evtl.
noch die (ungefähre) Messung der Gate-Ladung bei MOSFETs. Der Fehler bei
der LCD-Ansteuerung ist hier natürlich auch berichtigt.

=> PJ:
So ein "Universaltester" wäre natürlich auch denkbar.
Meiner Meinung nach wäre es dabei aber sinnvoller, für jeden Bauteiltyp
eigene Test-Anschlüsse vorzusehen. Also extra Pins für "Transistor und
andere Halbleiter", "Kondensator", "Spule", ...
Man braucht nämlich für fast jedes Teil andere Test-Hardware": Für
Kondensatoren evtl. Eingangs-Schutzschaltungen, damit der Tester nicht
kaputt geht, wenn man einen geladenen Kondensator anschließt. Um Spulen
zu messen wäre ein Kondensator sinnvoll (=> Schwingkreis). Diesen
Kondesator kann man zum Transistoren testen aber überhaupt nicht
brauchen, usw.

Übrigens: So extrem ungenau ist die Widerstands-Testfunktion nicht. Ich
habe mal testweise einige Widerstände damit gemessen.
Der erste Wert ist das Ergebnis des Transistortesters.
Der zweite Wert in Klammern wurde zum Vergleich mit einem guten
Multimeter ermittelt.

234 Ohm (218,9 Ohm)
996 Ohm (998,2 Ohm)
4288 Ohm (4342,2 Ohm)
9860 Ohm (9927 Ohm)
11968 Ohm (11924 Ohm)
37,7k (38,719k)
149,6k (150,97k)
469,0k (472,04k)


Ich finde die Genauigkeit zwar nicht extrem toll, aber durchaus
brauchbar.
Der Messbereich ist übrigens etwa 100 Ohm bis 900k Ohm.

Hallo
Ich habe mir den Tester nachgebaut, hat auf Anhieb funktioniert.
Es ist die Version ohne Abschaltung. Allerdings funktioniert das
neuerliche Testen nur solange, bis im Display "Timeout" kommt, dann hat
der Taster keine Funktion mehr und man muss Aus und wieder Einschalten.
Ist das gewollt so oder habe ich da was übersehen?

Hubert

Hat sich erledigt. Ein paar Threads weiter oben hat "Armin Diehl" die
Lösung schon geschrieben. Die paar Zeilen im Code dazu und alles läuft
nach Wunsch.

Gratulation und Dank an Markus F., ein wirklich tolles Gerät.

Hubert

Ich habe jetzt nochmal eine verbesserte Version reingestellt.
Die Messung der Gate-Schwellspannung für p-Kanal-Mosfets war nämlich
völlig falsch. Ich hatte nur vorher keine P-Kanal-Mosfets, um das mal
testen zu können. Jetzt habe ich welche, und die Messung der
Gate-Schwellspannung habe ich berichtigt.
Die Messung der Gate-Schwellspannung hat jetzt auch eine Zeitbegrenzung.
Wenn der Mosfet sonst bei der Messung nie zu leiten beginnt, bliebe der
Tester in einer Endlosschleife hängen, bis der Watchdog einen Reset
auslöst. Die mögliche Zeit ist jetzt allerdingsrecht kurz. Für einen
starken Mosfet (IRFP450) mit zusätzlich 6,8nF zwischen Gate und Source
reicht es aber.
Noch mehr Gate-Kapazität haben Mosfets eigentlich nicht. Außer extrem
starke Typen, aber die hat man im Hobby-Bereich ja eher selten.
Wenn diese Zeitbegrenzung anspricht, wird als Gate-Schwellspannung eben
0mV angezeigt. Die Pin-Belegung wird aber trotzdem angezeigt.

Außerdem habe ich das von Armin Diehl genannte Feature (beim Aufbau ohne
automatische Abschaltung kann man den Test auch per Taster neu starten)
eingebaut. In meiner Version ist dafür auch kein define nötig. Man kann
die gleiche Firmware ohne Änderungen für den Tester mit oder ohne
Abschaltung verwenden. Kostet halt ein paar Bytes mehr Flash, aber der
reicht ohnehin noch leicht aus. Auch im Mega48 sind damit noch 184 Bytes
frei, was schon noch für die ein oder andere Fehler-Korrektur reichen
sollte.
Im Mega8 sind in der jetztigen Version (da ist wie gesagt die
Widerstandsmessung drin, im Gegensatz zu der Mega48-Version) noch 3670
Bytes frei. Das reicht noch für eine Menge Erweiterungen.

Mit einem Steckernetzteil könnten am Spannungsteiler mehr als 5V sein
und damit auch am ADC-Eingang. Das sollte damit wohl verhindert werden.

Ich habe das Projekt nachgebaut,und hab ein paar Probleme mit dem
programmieren des ATMEGA8.

Ich nutze diesen Programmer
http://s-huehn.de/elektronik/avr-prog/avr-prog.htm für den
Parallel-Port.Zusammen mit der Software PonyProg2000, ich habe Probleme
damit die "FuseBits" richtig einzustellen.Der Autor des Artikels hat
angegeben das lfuse = 0xc1(C1), hfuse = 0xd9(D9) gesetzt werden
müssen.Als Taktquelle wird ja der interne Oszilator genutzt.Wie setzt
man denn die Fuses in PonyProg Hexadezimal?Ich hab da nur die Checkbox
Auswahlmöglichkeit.Und welchen Taktfrequenz hat der interne
Oszilator?1MHz wie es Standart beim Auslieferungszustand des Atmega8
ist?Oder mehr?

Kann mir da jemand einen Tipp geben wie ich den Atmega8 in diesem Fall
richtig programmiere/vorbereite?
Eignet sich dafür ein anderes Programm besser,was mit meinem
improvisierten Programmer arbeitet?

MfG Thomas

Gib hier www.engbedded.com/fusecalc/  das c1 und d9 ein, dann siehst du
welche Haken du setzen musst.

Hallo Hubert danke für den Tipp,jetzt weis ich wie es geht.Leider hab
ich noch paar Probleme mit dem programmieren des Atmega8 die Adapter aus
Inet fürn parallel Port,wollen nicht so funktionieren.Da muss ich
nochmal genauer schauen,da ich über kein AVR-Board verfüge und nur den
Adapter bauen möchte.

MfG Thomas

Hallo Thomas, welches Betriebsystem nuzt du? Ich kann dir TwinAVR
empfehlen zum Programmieren, auf der Seite ist ne Anleitung wie man das
ganze unter XP einsetzen kann, oder eine PC mit Win98 suchen.

Zum AVRs programmieren kann ich avrdude sehr empfehlen. Das dürfte
eigentlich alle gängigen ISP-Programmer unterstützen.
Ist halt eie Konsolenanwendung. Es gibt aber auch grafische Oberflächen
dafür (finde ich aber eigentlich überflüssig).

Diese Version habe ich in Betrieb, ohne Abschaltung.

Hubert

=> Fetti:
Hast du auch sicher die neue Version runtergeladen?
Vor so gut 2 Wochen habe ich nämlich eine Version reingestellt, bei der
dieser Fehler (mit dem "Timeout") behoben sein sollte.
Ansonsten werde ich das aber noch mal überprüfen.

Ich habe jetzt noch mal die Datei kontrolliert, die ist sicher richtig.
Als Ergänzung habe ich jetzt noch "Halbleitertester" und "Version 1.10"
beim Start im LCD hinzugefügt.

Wahrscheinlich hast du da ein Schaltungsproblem, da es bei mir
einwandfrei funktioniert.

Also wie schon gesagt, bei mir läuft diese Version einwandfrei. Da musst
du einen Wurm in deiner Schaltung haben.
Meine Schaltung im Anhang, ist aber die gleiche wie von Markus F.

=> Fetti:
Du verwendest aber schon einen Taster, oder?
Bei einem Schalter (oder wenn man den Taster lange gedrückt hält) könnte
das mit dem "Timeout" nämlich passieren.
Der Transistortester wartet nämlich, bis der Taster losgelassen wird.
Wenn das nicht passiert (z.B. weil man einen Schalter verwendet und ihn
eingeschaltet lässt), wartet der Tester im Prinzip "bis in alle
Ewigkeit". In diesem Falle also so lange, bis der Watchdog für einen
Reset sorgt. Dann kommt die "Timeout"-Meldung.

=> Jochen:
Ist das LCD auch HD44780-kompatibel? Sonst wird es natürlich nicht
funktionieren.

Hi!

Mal eine Frage zu der Software: ich habe das ganze nun nachgebaut und
wollte aber ein VFD benutzen. Also erstmal die lcd-routines.c/.h
ausgetauscht und alle dort vorhandenen Methoden neu implementiert.
Leider lief überhaupt nichts, weil fest kodiert im Hauptprogramm noch
Befehle an das LCD gesendet wurde (u.a. Zeichendefinitionen, Zeile
setzen, Cursor positionieren, etc). Auch Sonderzeichen wurden hart
ausgegeben anstatt sie z.B. in den lcd spezifischen Quellen zu
definieren.

Eine Anpassung ist damit nicht wirklich möglich, auch der gesamte Code
ist wirklich nicht wartbar:

1. Keine Include Schutz im Header von lcd-routines.h
2. include der <avr/eeprom.h> ohne irgendwas davon zu nutzen. Entfernt
man dies fällt man auf die Nase, weil dieser Include im Main.c gebraucht
und dort nicht inkludiert ist.
3. Warum zum Teufel wird eine F_CPU definiert in der lcd-routines.h? Vor
allem noch mit 8 MHz, wo doch die Readme in dem Packet die Fuses auf 1
MHz internal oscillator definieren. Was denn nun? 8 oder 1 Mhz. Welche
Definition nun die delay Routinen benutzen ist dabei vollkommenes Lotto.
4. Warum wurde die Taktfrequenz nicht in den Projektoptionen angegeben?
Dort sollte das zentral angegeben sein, dann ist auch F_CPU definiert -
aber so versteckt ist das mehr als bösartig.

Sorry, aber ich bin gefrustet über dieses .ZIP file - und das musste mal
raus. Ich werde mich _vllt._ mal ransetzen und das ganze aufräumen und
dann hier reinstellen. Danach sollte es auch einfacher sein, das ganze
auf andere Displays anzupassen.

Gruss

Hi!

Klaus schrieb:
> Warum schreibst Du Dir nicht einfach Dein eigenes Ding?

Weil ich das Rad nicht neu erfinden wollte. Es ist ein (bisher so
scheinendes) gut funktionierendes Projekt, was gepflegt und getestet
ist. Und bisher habe ich auch nur Kritikpunkte am Quellcode, nicht am
Projekt vom Aufbau oder elektronischen Sinne her. Ich war halt nur so am
verzweifeln, da ich wirklich dachte/hoffte das es auch Quellcode-mäßig
gut aufgebaut ist.

Ich will und mag nichts gegen das Projekt sagen, ich wollte es mir
schliesslich nicht umsonst nachbauen. Also von daher nochmal zur
Klarstellung: Das Projekt ist super!

Ich werde mal schauen wie ich das nun mache. Ich denke mal, wenn ich
mich wirklich mal ransetze und den Originalcode aufräume und dann diesen
hier ablege, dann kann ich von dem ausgehend besser das andere Display
einbauen. So haben dann auch andere was davon.

Es hatte nur seinen Charme, da das VFD nur den seriellen Sender bräuchte
als Verbindung, da wäre noch viel frei geblieben.

Grüsse

Hallo,

@Thomas K. (muetze1): ein Problem, daß mir in 90% der Hobby-Projekte
auch begegnet...
Andererseits sind z.B. auch meine Sachen in 99% der Fälle nur für mich
geschrieben und gebaut.

Mein Vorschlag: pass es für Dich an, aufgeräumt oder nicht.
Das ist dann nicht die feine englische Art, Du hast aber ein spielendes
Gerät.

Ob es Dir die Zeit Wert ist, daß ganze Projekt aufzuräumen, universelle
zu gestalten, anderen zur Verfügung zu stellen, das mußt Du natürlich
selbst entscheiden.

Meine Erfahrung: man macht sich viel Arbeit und der erst, der dann das
Ergebnis runterlädt, will irgendwas ändern, was man überhaupt nicht
angedacht hat und man wird angemault. ;-))
Die Mehrheit will zusammenlöten, brennen und benutzen.
Etliche wollen umbauen und ändern, haben aber Zeit/Fähigkeiten/Lust dazu
nicht.
Ganz wenige wollen Ändern und können das auch.
Die machen es dann eben einfach. Oft hört man davon dann garnichts.

PS: ich habe auch so einen Transitortester.
Basiert auf dem Projekt vom Bernhard Schulz.
Software komplett neu geschrieben und etwas erweitert (nicht so
umfangreich wie dieser hier).
Der wird einfach benutzt. Vielleicht brenne ich auch diese Version hier
mal rauf.

Gruß aus Berlin
Michael

Hallo,

@ Hannes Lux (Gast): naja, das Umverdrahten würde ich noch machen... ;-)

Ich kann Dir gern mal meinen ASM-Code für die "Bernhard-Schaltung"
zukommen lassen.
Bei Interesse schick mir einfach eine Mail.
Mehr als löschen kannst Du ihn ja nicht. ;-)

Gruß aus Berlin
Michael

Hannes Lux schrieb:
> (f)liegt hier mit Sicherheit noch irgendwo herum. Vielleicht überwinde
> ich auch irgendwann meinen inneren Schweinehund und installiere mal
> WINAVR. Aber nur vielleicht. ;-)
>
> ...

Hab mich dann vor einiger Zeit auch mal überwunden, tut garnicht weh :D
Also trau dich man muß ASM ja nicht aufgeben ;)

RitschRatsch wrote:

> Sehe ich das richtig, das T2 nur dazu da ist dem Controller zu
> signalisieren, das der Taster gedrückt wurde ?
> Wenn ich diesen nicht brauche (eigene Firmware) kann ich doch einfach
> den Taster statt auf die Basis von T2 auf Masse ziehen, oder?
Ja, genau so kannst du es machen

Und das mit den LCD-Befehlen direkt im Code habe ich gemacht, um Flash
zu sparen.
Und es sind nur 4 Befehle, die direkt in der Form "lcd_command(x)" im
Code stehen.
Zwei davon sind aber schon als Makros definiert ("Line1()" und
"Line2()")
Eine andere setzt den Cursor an eine bestimmte Position und ist auch im
Code kommentiert.
Und noch eine initialisiert das Senden eines Custom-Zeichens (für die
Darstellung einer Diode) an das LCD. Das musst du für ein VFD vermutlich
sowieso ändern.
Natürlich könnte man das auch alles in die lcd-routines.c legen. Aber so
schlimm finde ich diese 4 Befehle in der main.c jetzt auch nicht.

Moin!

Und was ist mit dem anderen Dingen? Womit läuft der MC nun? 8 MHz oder 1
MHz? Muss ich beim aufräumen nun die ganzen Wartezyklen und -befehle um
den Faktor 8 verlängern?

Was ist mit den C++/Header Trennung? Was ist mit der doppelt
Definitionsschutz im Header?

Definiere mir einfach nochmal die nun tatsächliche genutzte MCU
Frequenz. Ich habe mir ein Standard LCD geordert um erstmal den Aufbau
direkt nachvollziehen zu können, da deine Firmware so nicht läuft bei
mir. Ich bekomme keine Anfangasausgabe und da ist nun die Frage ob die
serielle Kommunikation nach der Initialisierung gestört wird oder es ein
Fehler von der VFD Ansteuerung ist (was sich nur auf serielle senden
beschränkt).

Also grundlegend: ich werde es aufräumen, wenn ich das Display erhalten
habe und werde es dann hier einstellen. Dann kann ich gleich mal schauen
ob der Code nicht vllt. an manch offensichtlichen Stellen verkleinert
werden kann.

Grundsätzlich ist die Definition der Funktionen egal. Ob nun in der
lcd-routines.h/.cpp oder in der main.cpp macht hierbei keinen
Unterschied und spart auch kein Flash.

Grüße,
Thomas

Moin!

Nochmal ein Nachtrag: der erste Teil klingt vllt. etwas harsch, das
sollte es aber nicht! Wie ich schon damals geschrieben habe: Das Projekt
will ich mir ja nicht umsonst nachbauen. Ich bräuchte jetzt vor allem
mal eine definitive Info zum Taktfrequenz und dann kann ich mich mal
ranmachen. Ich will ja das alle was davon haben und ich werde auch daran
arbeiten, dass der Code nicht grösser sondern eher kleiner wird.

Grüsse,
Thomas

Thomas K. schrieb:
> Ich bräuchte jetzt vor allem
> mal eine definitive Info zum Taktfrequenz und dann kann ich mich mal

Einfach mal nach "mhz" hier im Thread gesucht und siehe da:
Beitrag "Re: Transistortester mit AVR"

900ss

Oki, danke. Den Beitrag mit der Info habe ich dann übersehen, hatte mich
damals einmal komplett durch den Thread gearbeitet.

Gut, dann weiss ich nun Bescheid und werde schonmal anfangen ein wenig
das ganze in Sachen Display offener zu gestalten. Das wird dann
spannend, wenn ich das Display habe, ob es dann noch alles läuft...

@micha

ich zitiere mal aus dem Artikel:

"LED1 dient dazu, die Spannung an S1 auch im Betrieb hoch genug zu
halten um T2 aufzusteuern"

Die LED dient nicht zur Betriebsanzeige, das macht ja schon das Display
;)

Gruß
Thomas

Sicherheitshalber schreibe ich es hier nochmal:
Die Taktfrequenz ist 1MHz.
=> Thomas K.:
Wo hast du denn die Definition mit den 8MHz gefunden?
Ich habe extra mal alle Dateien aus der neuesten Firmware-Version nach
"8000000" durchsucht und nichts gefunden. Da steht auch 1MHz drin.

Moin!

Die ist im Header von lcd-routines.h. Ich bin nun natürlich hellhörig
geworden, nicht das ich hier an einem alten Stand bastle...

/EDIT: Ich muss mich korrigieren, es ist zwar eine
Taktfrequenzdefinition in der lcd-routines.h enthalten, aber diese
definiert auch 1 MHz. Oh mein Gott, ich habe wirklich einen deutlichen
Augenfehler.

Also, es war tatsächlich 1 MHz, wie ich auf die 8 komme: keine Ahnung.
Vielleicht mit den ganzen Nullen vermanscht, kA.

Also sorry, 8 MHz stand nie zur Debatte. Aber die Stelle der Definition
ist natürlich weiterhin ungeeignet.

Sorry für das Missverständnis. Und ich möchte nochmals drauf hinweisen:
das Projekt ist super und funktioniert auch wirklich gut. Und nochmals
als Hinweis: ich würde es nicht nachbauen bzw. mich ransetzen, wenn ich
es nicht gut finde. Ich mache auch nur Veränderungen vom Code her, die
reine Logik und Funktionalität bleibt bestehen!

Zwischenzeitlich musste ich feststellen, dass es mit einem allgemeinen
LCD Interface der dann auf entsprechende low level LCD Routinen
verweist, ein grösserer Code rauskommt. Von daher werde ich noch eine
Zwischenversion bauen, wo eine feste HD44780 Einbindung enthalten ist.

Grüsse,
Thomas

Moin!

So, ich habe nun nochmal schnell von vorne angefangen und die letzte
Version von hier angepasst. Mein eigentlicher Stand hatte nun doch schon
ein paar Änderungen mit drin, die ich hier erstmal noch keinem antun
will. Ich habe am grundlegenden funktionalen Code nichts gemacht.
Erstmal, was habe ich überhaupt gemacht:

- LCD Routinen in der LCD-Routines.h/.cpp ein wenig verkleinert
- LCD Custom Chars & Omega Zeichencode in lcd-routines.h verschoben
- lcd-routines.h Schutz vor doppelten Definitionen eingebaut
- alle Strings in eine resource.h/.cpp ausgelagert
- eine config.h angelegt. Dort können zentrale Elemente konfiguriert
werden (Strings in EEPROM oder Data, Auto Power Off ja/nein,
Versorgungsspannung messen ja/nein)
- ich habe ein paar goto's entfernt in der main.c und durch Schleifen
ersetzt bzw. manche goto's waren komplett unnötig (z.B. ende)
- bug fix für Abschaltung nach Watchdog Reset: wer keine Abschaltung mit
aufbaut, dessen MC hängt dann im Nirvana & Abschaltung zerschiesst LCD
Kommunikation, da gesamter Port auf 0 gesetzt wurde
- ein paar überflüssige LCD Kommandoaufrufe entfernt

Der gesamte Code macht das gleiche wie zuvor auch und gibt auch das
gleiche wie zuvor aus. Die aktuellen config.h Einstellungen sind wie im
Original.

Ich hoffe Markus kommt mit dem Quellcode so klar in dem Sinne, dass er
damit weiter entwickelt.

Insgesamt ist der Code nun 54 Bytes kleiner geworden (4468 Bytes).

Ansonsten: es fehlt noch die Cursor Positionierung an der einen Stelle,
die habe ich noch nicht entfernt, da diese Version fest mit dem HD44780
Controller arbeitet. Alles andere wäre eine neue Funktion und die würde
wohl die gewonnen Bytes wieder kosten.

Ich werde die Tage die für die LCD noch offenere Version hier hochladen.
Diese wird dann zum einen Treiber für M50530 Mitsubishi, HD44780 von
Hitachi und VFD von Samsung & Futuba über serielle Schnittstelle
enthalten. Auch habe ich Vorbereitungen getroffen für Anpassung in der
Bildschirmausgabe wenn mehr als 16x2 zur Verfügung steht.

Grüsse,
Thomas

Moin!

Würde dann keinen Unterschied mehr machen. Da das Interface dann aber
recht offen ist, kann man leicht ein anderes Display implementieren -
u.a. auch eine allgemeine VT100 oder sogar ANSI Schnittstelle. Ich hatte
dabei vor allem das einfache Interface im Kopf. Die meisten der VFDs von
den o.g. Herstellern die ich habe besitzen eine TTL RS232 Schnittstelle
und sind somit direkt anschliessbar bei gerade mal einem benötigten Pin.
U.a. das zuletzt bei Pollin angebotene VFD von Futuba M162SD05AA ist
dazu gut geeignet.

Ansonsten hier gleich mal eine Aktualisierung. In der vorherigen Version
habe ich doch glatt eine Warnung übersehen (Asche auf mein Haupt). Diese
habe ich entfernt und doch gleich mal die Cursor Positionierung mit
umgestellt. Nun sind wir bei einer Codegröße von 4496 Bytes, also nur
noch eine Ersparnis von 26 Bytes. Aber immerhin kleiner...

Grüsse,
Thomas

Moin!

Und gleich nochmal ein bug fix, der zuvor bei mir nicht aufgefallen war,
dank der Optimierung. Bitte folgende Methode austauschen in der
lcd-routines.c bzw. die Klammern um die ? setzen...

void lcd_cursor(const unsigned char ARow, const unsigned char AColumn)
{
  lcd_command(CMD_SetDDRAMAddress | AColumn | (ARow ? 0x40 : 0x00) );
}

Grüsse,
Thomas

Moin!

Nochwas: Ich wollte die Serienschaltung von Dioden testen und habe 2
Dioden angeschlossen. Anschluss: D1 Anode an Pin 1, D1 Cathode mit D2
Anode an Pin 2 und D2 Cathode an Pin 3. Leider sagt er mir immer
defektes Bauteil und gibt aus, dass er 3 Dioden erkannt hat. Irgendwo
ist da noch der Wurm drin, aber bei meinem Aufbau ist dieses Verhalten
beim Originalcode genauso.

Habe ich was nicht bedacht oder falsch gemacht?

Grüsse,
Thomas

=> Thomas K.:
Du hast recht, wenn man 2 Dioden in serie anschließt, wie du es
beschrieben hast passiert ein Fehler. Das überprüfe ich noch mal.

Zu deinem Code:
- Du hast deine Änderungen englisch kommentiert. Mein Code war aber
deutsch kommentiert. Das ist eher ungünstig.

- Einen extra Define für den Auto-Power-Off wollte ich auch vermeiden.
Es gibt auch einige AVR-User, die sich mit avr-gcc nicht auskennen und
damit den Code nicht selbst kompilieren können. Und es würde ein
unwahrscheinlicher Wust an fertigen hex-Files entstehen, wenn man für
jedes geänderte Define eine hex-File reinstellen würde (mit und
Auto-Off, für Mega48 und Mega8, etc.).

- Meiner Meinung nach ist es sinnlos, die Nutzung des EEPROM zu
deaktivieren. Aus welchem Grund hast du das überhaupt eingebaut?

- In meiner neuesten Code-Version kann man den Tester ohne Änderung mit
oder ohne automatische Abschaltung aufbauen. Hast du auch sicher die
neueste Version verwendet (habe ich am 8. Mai hochgeladen)?
Da wird nämlich nicht mehr der komplette LCD-Port auf 0 gelegt.

- Für Zugriffe auf einzelne Register-Bits hast du immer _BV(Bitname)
verwendet. Ich habe es mit (1<<Bitmane) gemacht.

Ich schaue mir den Code jetzt erstmal an. So direkt werde ich das aber
nicht übernehmen. Das wird mir aus den genannten Gründen dann zu
chaotisch.
Gut finde ich aber die bessere Ordnung bei den Header-Files. Das werde
ich auf jeden Fall übernehmen.

Moin!

Markus F. schrieb:
> => Thomas K.:
> Du hast recht, wenn man 2 Dioden in serie anschließt, wie du es
> beschrieben hast passiert ein Fehler. Das überprüfe ich noch mal.

Gut, ich dachte schon ich habe da einen Fehler drin.

Markus F. schrieb:
> - Du hast deine Änderungen englisch kommentiert. Mein Code war aber
> deutsch kommentiert. Das ist eher ungünstig.

Werde ich beim nächsten mal eindeutschen. Bin ich so gewöhnt...

Markus F. schrieb:
> - Einen extra Define für den Auto-Power-Off wollte ich auch vermeiden.
> Es gibt auch einige AVR-User, die sich mit avr-gcc nicht auskennen und
> damit den Code nicht selbst kompilieren können. Und es würde ein
> unwahrscheinlicher Wust an fertigen hex-Files entstehen, wenn man für
> jedes geänderte Define eine hex-File reinstellen würde (mit und
> Auto-Off, für Mega48 und Mega8, etc.).

Standardmässig ist alles an wie beim alten, das kann ja auch so bleiben
und so sollten auch die Hex und EEP files sein. Alle die nicht selbst
kompilieren können, nehmen den Stand und alles ist beim alten. Jeder der
aber compilieren wird auch Änderungen machen können, sonst bräuchte er
es nicht zu compilieren. Dann wird er auch mit den Defines umgehen
können.

Markus F. schrieb:
> - Meiner Meinung nach ist es sinnlos, die Nutzung des EEPROM zu
> deaktivieren. Aus welchem Grund hast du das überhaupt eingebaut?

Da ich im Hinterkopf hatte den EEPROM beim Tester anderweitig zu nutzen.
Aber diese Änderung wurde vom anderen Stand übernommen, von daher ist
der nichts was man übernehmen müsste.

Markus F. schrieb:
> - In meiner neuesten Code-Version kann man den Tester ohne Änderung mit
> oder ohne automatische Abschaltung aufbauen. Hast du auch sicher die
> neueste Version verwendet (habe ich am 8. Mai hochgeladen)?
> Da wird nämlich nicht mehr der komplette LCD-Port auf 0 gelegt.

Ich werde nochmals genau schauen, anscheinend habe ich da dann wirklich
eine alte Version. Ich werde mich diesbezüglich nochmal schlau machen.

Markus F. schrieb:
> - Für Zugriffe auf einzelne Register-Bits hast du immer _BV(Bitname)
> verwendet. Ich habe es mit (1<<Bitmane) gemacht.

Ist nur eine Schreibweise - auch persönliches empfinden. Ich habe meist
beim Lesen nebenbei, wenn ich den Code mir durchschaue, das ist eine
persönliche Macke. Hat keinen Vor- oder Nachteil, braucht auch nicht
übernommen zu werden.

Markus F. schrieb:
> Ich schaue mir den Code jetzt erstmal an. So direkt werde ich das aber
> nicht übernehmen.

Klar, es ist dein Code und vor allem dein Projekt! Es war ja auch nur
ein Vorschlag von mir.

Grüsse,
Thomas

Ich habe wieder mal eine neue Version reingestellt.
Folgende Änderungen habe ich darin gemacht:
- den genannten Fehler mit den 2 Dioden in Reihe behoben
- die LCD-Ansteuerung "übersichtlicher" gemacht (Makros zum Cursor
positionieren statt einem direkten lcd_command())
- die Includes für die Header-Dateien geändert (so ist es
übersichtlicher)
- Taktfrequenz (F_CPU) in den Projektoptionen definiert, nicht mehr im
Code
- Und das meiner Meinung nach Wichtigste: Es gibt keine separaten
Versionen für den Mega8 und Mega48 mehr. Das war auch in der Wartung
umständlich.
Die Version für den Mega8 unterstützt zusätzlich die Messung von
Widerständen, daher ist sie ein Stück größer.
Die jeweilige Version wählt man beim Kompilieren einfach über den in den
Projektoptionen oder im Makefile festgelegten AVR-Typen aus. Einfacher
geht es eigentlich nicht.

Das Programm ist dadurch etwas größer geworden, aber nicht um viel:
Mega48:
  Flash: 3988 Byte
  EEPROM: 254 Byte
Mega8:
  Flash: 4584 Byte
  EEPROM: 267 Byte

Moin!

Ich kann dir empfehlen zumindest die lcd_send() zu übernehmen, da deine
Version mit der extra Variablen und mehrfachen Zugriff auf den Port
codetechnisch grösser ist. Auch die Nibble Aufteilung kann "on-the-fly"
passieren, dass bekommt der gcc noch besser optimiert.

Ich habe bei einer Version an der ich gerade gebastelt noch eine
Änderung, vllt. auch Verbesserung eingebaut, welche sich vllt. auch für
deine Version eignet: Ich zeige fest in der 2. Zeile als erste 3 Zeichen
die Belegung an. Dabei ist es so, dass ich einen Punkt (HD44780 code
0xA5) für jeden Pin anzeige (Immer die gleiche Pin-Reihenfolge: 123) und
die entsprechenden Stellen dann mit der jeweiligen Funktion
überschreibe. Im Endeffekt für den Nutzer sieht er immer an den ersten 3
Zeichen der zweiten Zeile die Belegung von Pin 1 bis 3.

Beispiel Diode an 2-3: ".AK" und an 1-3: "A.K" etc.
Transistor: "BCE" bzw. "ECB", etc
Doppeldiode: "AAK", "KAA", etc

Erstes Zeichen ist immer Pin 1, zweites Pin 2, etc. Der (auf dem Display
mittige) Punkt gibt an "unbelegt", alles andere ist dann der jeweilige
Bezeichner.

Falls du dies übernehmen möchtest, hier ein Codeschnipsel, es ist soweit
immer das gleiche und die hier verwendeten Funktionen kennst du ja aus
meinem Stand von zuvor:

        // "Diode"
      lcd_WriteResource(resDiode);

        // 2. Zeile, Belegung
      lcd_Line2();
      lcd_WriteResource(resPinTemplate);
      lcd_cursor(1, diodes[0].Anode);   
      lcd_data('A');
      lcd_cursor(1, diodes[0].Cathode);   
      lcd_data('K');

        // 2. Zeile Uf
      lcd_cursor(1, 4);   
      lcd_WriteResource(resUf);   //"Uf="
      ....

Wobei resPinTemplate so definiert ist (für HD44780):

char resPinTemplate[] RESMEMMOD = {0xa5, 0xa5, 0xa5, 0x00};

(der Speichermodifizierer ist bei dir dann fest EEMEM, bekannt aus der
Version zuvor...)

Das ergibt einen schnelleren Überblick, vor allem da es für jedes
Bauelement einheitlich ist.

Auch habe ich bei Doppeldioden die Ausgabe von Uf für beide Dioden
hinzugefügt, da sie eh beide ermittelt werden. Durch die Nutzung der
zuvor genannte Pinbelegung ist noch genügend Platz für beide Uf.

Ich werde meine Ableitung davon mal weiterbasteln und nicht hier
hochladen bzw. angeben, weil sonst kommt es mit deiner Version zu zuviel
durcheinander und es ist dein Projekt.

Grüsse,
Thomas

Moin!

Gar nicht - denn es gibt sonst, wie Markus F. schon bemerkte, zuviele
verschiedene Versionen und Nachfragen von Usern werden dadurch nur
unnötig erschwert. Auch schon die Compilerdefines des originalen Projekt
würden halt zu Unstimmigkeiten führen. Bei grösserem Interesse würde ich
das vielleicht auf meinen Blog veröffentlichen, damit es dann örtlich
gut getrennt wäre - aber das müsste ich dann entscheiden und auch
nochmal mit Markus abstimmen. Er hat noch immer die geistigen
Eigentumsrechte und kann entscheiden was man darf und nicht darf im
öffentlichen Raum.

Aber bis dahin habe ich noch etwas zu basteln, noch ist es nicht fertig.

Grüsse,
Thomas

Ich finde es schon in Ordnung, wenn hier jemand den Code verändert und
"seine" Version davon veröffentlicht. Das soll ja schließlich auch ein
offenes Projekt sein.
Ungünstig wäre es nur - wie Thomas K. schon geschrieben hat - wenn jede
Version dann hier im Forum landet. Da geht dann auch schnell der
Überblick verloren.

Die lcd_send() schaue ich mir auch nochmal an.
Und die Idee, die Display-Anzeige so zu machen, wie du es beschrieben
hast, hatte ich auch schon mal. Das spart natürlich eine Menge Platz im
LCD. Allerdings sind die Ausgaben dann für Leute, die mit dem Tester
noch wenig Erfahrung haben, ziemlich schwierig zu lesen. Da ist eine
Angabe wie "B=2;C=1;E=3" deutlich besser verständlich als "CBE". Deshalb
habe ich mich damals dagegen entschieden.
Wie ist eigentlich eure Meinung dazu? Welche Darstellungsart gefällt
euch besser?

Moin!

Gerade wegen der Zuornung mit den Pins hatte ich mir wegen des
Verständnisses als erstes auch überlegt es ganz rechts im Display
anzuzeigen und dann aber so, dass in der 1. Zeile "123" steht und
darunter dann in der zweiten Stelle der Spalte entsprechend die
Beschreibung wie oben genannt. Wäre vllt. eine Mischlösung welches die
Lesbarkeit erhöht und gleichzeitig den LCD Platz effizient ausnutzt.

"Diode        123"
"Uf=345mV     A K"

Grüsse,
Thomas

=> Thomas K.:
Ich habe jetzt die lcd_send() etwa nach deinem Vorschlag übernommen.
Das Programm wird dadurch wirklich ein wenig kompakter (um 8 Bytes).

Moin!

Falls du noch mehr einsparen willst, ich habe ja nun noch etwas weiter
gearbeitet. Du bekommst deinen Code noch kleiner, wenn du den
Ausgabeteil, welcher nun ja mit if () else if () else if () etc.
arbeitet umstellst auf einen switch. Dein end: Label wird dabei zum
default Zweig des switches. Dies kann der C++ Compiler durch eine
Sprungtabelle noch besser optimieren als das if/else if/.... Gleiches
gilt für die Diodenanzahl Unterscheidung.

Als Hinweis muss ich gleich mal sagen: ich weiss nicht, ob er die
Sprungtabelle aufbaut mit den jetzt definierten Konstanten. Die Frage
ist, ob der Compiler das so richtig erkennt - ich habe in meiner Version
an der Stelle schon einen enum, den kann er dadurch bestens optimieren
und weiss auch sofort um die Sprungtabelle.

  // Bauteile
typedef enum 
{ 
  ptNone, 
  ptDiode, 
  ptTransistor, 
  ptFET, 
  ptTriac, 
  ptThyristor, 
#ifdef UseM8
  ptResistor 
#endif
} PartType;

Ansonsten noch ein Tipp: Der SetCursor() Präprozessor define enthält bei
der Zusammenstellung des Befehls ein +, dies ist aber die falscher
Operation, da dadurch der Befehl an sich sogar zerstört werden kann.
Alle Werte sollten mit binärem Oder verbunden werden.

Und nochwas zu dem zerstörten LCD Port: Wenn man die Abschaltung nicht
aufbaut und er von einem Watchdog Reset wieder neustartet, dann versucht
dein Code den Tester abzuschalten, was aber dadurch nicht gelingt. Zum
einen könnte er einfach erneut testen, er eh nicht abgeschaltet werden
kann. Zumindest wird dort der gesamte ON_PORT und ON_DDR auf 0 gesetzt,
das wiederrum zerschiesst wie zuvor gesehen die LCD Steuerung. Bisher
sorgt aber das return 0 bei dir im Code, dass er im Datennirvana landet.

Ok, das soll's erstmal gewesen sein.

Grüsse,
Thomas

=> Thomas K.:
Zu der Sache mit dem Abschalten nach einem Watchdog-Reset:
Ein Watchdog-Reset tritt im Normalbetrieb nicht auf.

Wenn man den Tester ohne automatische Abschaltung aufbaut, kommt er im
Code über den Punkt hinaus, an dem er sich normalerweise abgeschaltet
hätte.
Dann deaktiviert er den Watchdog und geht in eine Endlosschleife, in der
er auf einen neuen Druck auf die Start-Taste wartet oder bis man die
Betriebsspannung abschaltet.

Ich habe den Watchdog nur aus einem Grund eingebaut:
Wenn der Tester zwischendurch irgendwo hängen bleibt, würde er nie an
den Punkt kommen, an dem er sich wieder abschaltet. Damit würde er sich
natürlich nicht mehr abschalten. Wenn man den Tester mit der
automatischen Abschaltung hat, muss man dann also kurz den Strom
wegnehmen (Batterie abklemmen). Das nervt natürlich, wenn der Tester in
einem Gehäuse eingebaut ist: Gehäuse öffnen, Batterie abklemmen und
wieder anklemmen, Gehäuse wieder verschließen.

Meiner Meinung nach ist eine Abschaltung des Testers nach einem
Watchdog-Reset am sinnvollsten.
Wenn er nach einem Reset attomatisch einen neuen Testzyklus beginnt,
könnte er damit auch in einer "Endlosschleife" bleiben.
Aber du hast natürlich Recht, es ist eigentlich sinnlos, dafür den
kompletten Port auf 0 zu setzen. Das werde ich noch ändern und dann mit
der nächsten Version hochladen.

Und was ist an dem "+" im SetCursor-Makro so schlimm?
Man lönnte damit natürlich die uint8_t für lcd_command() überschreiten.
Das passiert aber nur, wenn man einen unsinnig hohen Wert für x oder y
einsetzt. Das ist aber sowieso Schwachsinn, weil das LCD ja nur 2 Zeilen
zu je 16 Zeichen hat.

=> Fur:
Das Prinzip, nach dem dieser Tester arbeitet, habe ich in dem Artikel
(siehe ganz oben im Thread) eigentlich schon erklärt.

Markus F. schrieb:

> Und was ist an dem "+" im SetCursor-Makro so schlimm?
> Man lönnte damit natürlich die uint8_t für lcd_command() überschreiten.
> Das passiert aber nur, wenn man einen unsinnig hohen Wert für x oder y
> einsetzt. Das ist aber sowieso Schwachsinn, weil das LCD ja nur 2 Zeilen
> zu je 16 Zeichen hat.

So ist es. Allerdings macht ein | anstelle des + den Code nicht größer,
die Software aber etwas Fehlersicherer, denn egal welchen Wert man für x
oder y angibt, der Befehl macht nichts anderes als die Adresse zu
setzen.
Eine x Position von z.B. 129 würde mit + zu dem Befehl 1 führen, was das
das Display löschen würde. Ebenso könnte man auch das Displays resetten
oder ähnliches.

Moin!

Markus F. schrieb:
> => Thomas K.:
> Zu der Sache mit dem Abschalten nach einem Watchdog-Reset:
> Ein Watchdog-Reset tritt im Normalbetrieb nicht auf.

Steht ausser Frage - er ist ja ein Mittel für den "Notfall".

> Wenn man den Tester ohne automatische Abschaltung aufbaut, kommt er im
> Code über den Punkt hinaus, an dem er sich normalerweise abgeschaltet
> hätte.

Richtig und landet im "return 0" und das bringt ihn in's Datennirvana,
weil ein Rückkehr von main() auf dem MC nicht vorgesehen ist. Von daher
ist es bisher undefiniert was der StartupCode des gcc macht, da er der
Aufrufer von main ist und die Kontrolle zurück bekommt.

> Und was ist an dem "+" im SetCursor-Makro so schlimm?

Was ist an einem Oder so schlimm? Nun ja, das Oder würde zumindest dafür
sorgen, dass die x und y Koordinaten zumindest nochmals deutlich grösser
und noch unsinniger werden müssten bis es auswirkungen hat. Um das
Kommando zusammen zu bauen ist der zu nutzende Operator ein binäres
Oder. Ein + Operator ist hier nicht gesucht und einfach nur die falsche
Wahl. Im ersten tun macht er gleiches, beim zweiten Durchlauf schon
wieder nicht mehr, von daher ist er hier nicht gesucht/benötigt. Es ist
einfach nur eine Frage des richtigen Operators.

Grundlegend: es ist nur ein Hinweis - was du machst und vor allem wie
bleibt natürlich dir überlassen. Grundlegend um die Gefahr weisst du und
ich denke du kannst auch nachvollziehen.

Grüsse,
Thomas

Der KS0070 ist nicht 100%ig HD44780 kompatibel. Die Timings (u.a. beim
Init) sind unterschiedlich. Dadurch kann es zu solchen Problemen
kommen...

Versuche vielleicht mal, die Wartezeit in lcd_enable() zu erhöhen.
Mit der Wartezeit von 1µs soll es ab und zu mal Probleme geben.
Du musste eben ausprobieren, welcher Wert dafür gut ist. Tendenziell
gilt da aber: Lieber etwas zu lang als zu kurz warten.

=> Frank:
Ich habe das jetzt nochmal mit 20µs Wartezeit und für den Mega8
kompiliert.
Die hex- und eep-Datei hänge ich hier mal an.
Es wäre schön, wenn du hier schreiben könntest ob es damit klappt.

Hallo,

und vielen Dank für das Projekt. Nun ist auch bei mir ein Nachbau
entstanden.
Die Schaltung habe ich soweit modifiziert, dass man den Tester sowohl
über Batterie als auch extern versorgen kann.
Ein Problem habe ich aber noch mit der Anzeige. Ich habe mit 2 Displays
getestet (Art-Nr. 120 545 und 120 469 von Pollin, beide HDD44780
kompatibel), aber die Anzeige bleibt leer. Der AVR lebt jedoch, denn im
Batteriebetrieb kann man sehr schön die automatische Abschaltung
beobachten. Getestet habe ich mit verschiedenen Versionsständen.

Vielen Dank schon mal für die Unterstützung.

PS: Gibt es irgendwelche Gründe (Forenregeln o.ä.), weshalb keine
Eagle-SCH- und -BRD-Files gepostet werden? Wegen kleiner Änderungen den
Schaltplan abzuzeichnen, ist ja nicht unbedingt der Sinn der Sache.

PPS: Ein eigenes Testprogramm konnte ich noch nicht schreiben, dazu
müssen erst mal AVR-Studio und GCC laufen.

Michael L. schrieb:

> Ein Problem habe ich aber noch mit der Anzeige. Ich habe mit 2 Displays
> getestet (Art-Nr. 120 545 und 120 469 von Pollin, beide HDD44780
> kompatibel), aber die Anzeige bleibt leer.

Die Init ist nicht ganz vollständig:
In Zeile 69 der lcd-routines.c, nach dem 3 maligen Senden von 0x02 fehlt
noch folgender Code:

LCD_PORT = (LCD_PORT & 0xF0 & ~(1<<LCD_RS)) | 0x02;
_delay_ms(1);
lcd_enable();
_delay_ms(1);

Damit wird der Bus auf 4bit eingestellt.

> PS: Gibt es irgendwelche Gründe (Forenregeln o.ä.), weshalb keine
> Eagle-SCH- und -BRD-Files gepostet werden? Wegen kleiner Änderungen den
> Schaltplan abzuzeichnen, ist ja nicht unbedingt der Sinn der Sache.

Ja: Nicht jeder hat Eagle installiert. Als Zugabe in einem kompletten
Projekt spricht nichts dagegen, aber wenn man mal schnell nur einen
Schaltplan zeigen möchte, dann ist ein Bild die beste Wahl, denn das
kann jeder ohne Zusatzsoftware direkt im Browser anschauen.

=> Benedikt:
Danke für den Hinweis. Ich habe das jetzt mal in die "offizielle"
Version aus dem Artikel übernommen. Diesen Fehler habe ich einfach
übersehen.

Eine BRD-Datei dazu habe ich nicht. Ich habe auch noch nie mit Eagle
eine Platine erstellt.

=> misser:
UJT's are not supported until now.
Darlington transistors are supported. But the tester doesn't show that
it is a darlington.
Transistors with internal diodes are supported. If a diode ist found, a
little diode icon is shown in the LCD.

Perhaps I will add support for UJT's soon. But first I must get some...

Hallo Benedikt und Markus,

danke für die schnelle Reaktion. Schneller als ich Zeit fand, WinAVR zu
installieren, war schon eine neue Version hochgeladen. Aber auch mit der
hatte ich leider noch keinen Erfolg. :-(

So werde ich mich nun erst mal selbst ans Eingemachte herantasten.

Die Eagle-Dateien könnte ich zur Verfügung stellen. Ich hätte sie ja
fast schon als ZIP in den Artikel eingefügt, kann aber den Abschnitt
Download nicht bearbeiten. Irgendwas ist da bei den letzten beiden
Abschnitten kaputt.

Grüße.
Michael

=> Michael L.:
Das Display 120545 von Pollin verwende ich auch. Bei mir funktioniert es
damit aber anstandslos.
Überprüfe vielleicht nochmal folgende Dinge:

- Ist das LCD auch richtig angeschlossen und kriegt es auch Spannung?
Diese Displays haben nämlich einen Kontaktabstand von gerade mal ca.
1mm. Da kann schnell mal eine Lötbrücke entstehen.
- Hast du die Fusebits des Controllers richtig gesetzt?
- Hast du auch die .eep-Datei ins EEPROM geflasht? (ganz wichtig!)

Meinen Tester habe ich auch mit diesem LCD aufgebaut und da hatte ich
noch keine Probleme.

Benedikt K. schrieb:
> Michael L. schrieb:
>
> Die Init ist nicht ganz vollständig:
> In Zeile 69 der lcd-routines.c, nach dem 3 maligen Senden von 0x02 fehlt
> noch folgender Code:
>
>

> LCD_PORT = (LCD_PORT & 0xF0 & ~(1<<LCD_RS)) | 0x02;
> _delay_ms(1);
> lcd_enable();
> _delay_ms(1);
> 

>
> Damit wird der Bus auf 4bit eingestellt.

Hi Benedikt, kannst Du bitte mal die ganze Funktion LCD_Init posten?
Ich bin mir nicht sicher ob ich den richtigen Code habe.

Thanx
netdieter

Benedikt K. schrieb:
>

> void lcd_init(void)
> {
>   LCD_DDR = LCD_DDR | 0x0F | (1<<LCD_RS) | (1<<LCD_EN1);   // Port auf
> Ausgang schalten
>   // muss 3mal hintereinander gesendet werden zur Initialisierung
>   _delay_ms(15);
>   LCD_PORT = (LCD_PORT & 0xF0 & ~(1<<LCD_RS)) | 0x03;
>   lcd_enable();
>   _delay_ms(5);
> 
>   lcd_enable();
>   _delay_ms(1);
> 
>   lcd_enable();
>   _delay_ms(1);
> 
>   // auf 4bit Modus umschalten
>   LCD_PORT = (LCD_PORT & 0xF0 & ~(1<<LCD_RS)) | 0x02;
>   lcd_enable();
>   _delay_ms(1);
> 
>   // 4Bit / 2 Zeilen / 5x7
>   lcd_command(CMD_SetIFOptions | 0x08);
> 
>   // Display ein / Cursor aus / kein Blinken
>   lcd_command(CMD_SetDisplayAndCursor | 0x04);
> 
>   // inkrement / kein Scrollen
>   lcd_command(CMD_SetEntryMode | 0x02);
>   lcd_clear();
> }
> 

Wie ich vermutet habe. Ich habe nicht die aktuellen Sourcen.

Sind den die Source aus dem Forum nicht mehr aktuell?
http://www.mikrocontroller.net/articles/AVR-Transistortester

Daher hatte ich meine.

Gruß
netdieter

Doch, das war die Version von dort. Ich habe das ganze geringfügig
angepasst, so dass es eher der Version aus dem Datenblatt entspricht.

Je nach Controller gibt es geringe Unterschiede in der Initialisierung
(vor allem was den von mir eingefügten Befehl angeht), aber obige
Version sollte bei allen 44780 kompatiblen LCDs funktionieren.

Benedikt K. schrieb:
> Doch, das war die Version von dort. Ich habe das ganze geringfügig
> angepasst, so dass es eher der Version aus dem Datenblatt entspricht.
>
> Je nach Controller gibt es geringe Unterschiede in der Initialisierung
> (vor allem was den von mir eingefügten Befehl angeht), aber obige
> Version sollte bei allen 44780 kompatiblen LCDs funktionieren.

 lcd_command(CMD_SetIFOptions | 0x08);

  // Display ein / Cursor aus / kein Blinken
  lcd_command(CMD_SetDisplayAndCursor | 0x04);

  // inkrement / kein Scrollen    
  lcd_command(CMD_SetEntryMode | 0x02);  

Die defines sind aber noch nicht im Header eingepflegt :-(

Doch, in den lcd-routines.h. Zumindest waren die das vor einer halben
Stunde noch.

Dann muss ich mir nochmal den neuen Code holen.
Meiner ist schon 3 Wochen alt. ;-)

Hallo Markus,

die Anzeige funktioniert nun doch. Ich muss nur den Pin für den Kontrast
fast auf GND ziehen, dann zeigt das 120545 auch was an. Nur bei dem
120469 habe ich wohl Pech gehabt, das zeigt erst wenn ich es ganz auf
GND schwach etwas an. Wie es scheint habe ich da wohl ein Modell mit
erweitertem Temperaturbereich erwischt, heißt also noch eine negative
Spannung erzeugen, damit ich richtig was sehen kann. Aber da muss ich
wohl durch, denn es ist wesentlich größer, hat Beleuchtung und einen
wesentlich längeren Folienleiter (wichtig für den Gehäuseeinbau).

Danke für die Tipps, obwohl ich sagen muss, das 1mm-Pin-Raster ist nicht
wirklich eine Herausforderung. Sowas kann ich noch löten, ohne alles mit
Zinn zuzukleistern. :-D Und ich brate auch nicht auf dem Folienleiter
herum, sowas finde ich bäh! Dafür gibt's doch passende Buchsen.

Morgen werde ich aber erst mal ein wenig testen. :-)

Ich fand das 1mm-Raster auch nicht schlimm, nachdem ich herausgefunden
habe wie man sowas am besten anschließt. Ich habe dann den Folienleiter
abgelötet und es mit Kupferlackdraht angeschlossen. Geht auch ganz gut,
aber so eine Folienleiter-Buchse ist natürlich eleganter.

Und die negative Spannung für dein anderes LCD kannst du einfach mit
einer Ladungspumpe erzeugen. Das ist ganz einfach, aber anscheinend gar
nicht so bekannt. Deshalb füge ich hier noch einen kleinen Schaltplan
bei.
Funktionsprinzip sollte eigentlich klar sein.

Ich finde diese LCDs mit weitem Temperaturbereich fast besser als die
"normalen" Typen. Die haben meist einen viel besseren Kontrast. Dafür
würde ich den Nachteil mit der negativen Spannung schon in Kauf nehmen.
Für meinen Tester hatte ich leider gerade kein solches LCD zur Hand.
Außerdem passt das kleine LCD gut in das Gehäuse, das ich auch gerade
noch so rumliegen hatte...

Danke für die Schaltung, so hatte ich die auch in Erinnerung. Dazu noch
ein 555 und fertig. Das kann ich dann gleich mit in den Schaltplan und
ins Layout übernehmen und würde die Files zur Verfügung stellen, wenn du
nichts dagegen hast.

Inzwischen habe ich mit dem kleinen LCD mal kurz getestet, habe einen
NPN-Transistor angeklemmt, aber das Ergebnis gibt mir Rätsel auf.

B an 2 und E+C an 1+3 bzw. 3+1
ergibt eine Doppeldiode CA mit A=2 und K1,2 = 1,3

B an 1 und E+C an 2+3 bzw. 3+2
B an 3 und E+C an 1+2 bzw. 2+1
ergibt einen NPN mit h_fe zwischen 765 und 770

Je nach Meßgerät (habe mit 3 anderen geprüft) sollte der Transistor aber
nur eine h_fe von 240..270 haben.

Die Verdrahtung der Testanschlüsse habe ich durchgemessen, habe auch
noch mit einem 2. Mega8 getestet.

Das ist zwar nur nicht mein erstes µC-Projekt, doch das erste mit AVR.
Darum bin ich im Moment noch nicht weiter gekommen, obwohl ich schon mal
einen Blick in den Code geworfen habe. Vielleicht hast du ja eventuell
noch eine Idee, was es sein könnte?

Was für einen Transistor hast du denn eigentlich verwendet?
Solche Probleme hatte ich nämlich bisher noch nicht (außer natürlich
ganz zu beginn des Projekts...)
Ich habe gerade einen 2N3773 und einen TIP31 je in allen 6 möglichen
Kombinationen angeschlossen. Es hat jedes Mal funktioniert.

Übrigens: Ein extra NE555 ist doch eigentlich überflüssig.
Der AVR hat noch viele freie I/O-Pins. Und die Timer werden auch nicht
benutzt. Das Rechteck-Signal könnte also auch der AVR selbst erzeugen.

Hallo Markus,

ich habe den Fehler gefunden, ein Kügelchen Zinn hatte Pin 16 nach Masse
gebrückt.

Das muss irgendwann während der ersten erfolglosen Versuche mit der
LCD-Initialisierung da hin geraten sein. Denn nach dem Löten hatte ich
da keine Verbindung gemessen, und beim späteren prüfen der Verdrahtung
habe ich erst mal nur von den Test-Pins gegen die IC-Pins gemessen.

Sorry, war also mein Fehler. Aber vlt. erspart es ja zukünftige
Nachfragen, könnte man ja im Artikel unter Fehlersuche aufnehmen, wenn
es Sinn macht.

Das Rechtecksignal im AVR erzeugen macht natürlich Sinn. Ich war wohl zu
sehr in mein Problem vertieft.


Danke nochmals.

=> Michael L.:
Schön, dass dein Tester jetzt auch funktioniert ;)
Und ich habe jetzt im Artikel einen Abschnitt "Fehlersuche" eingefügt,
wo ich die (meiner Meinung nach) häufigsten Fehlerquellen aufgeführt
habe.

Hallo Markus,

um das Rechtecksignal auf einem der freien Pins auszugeben, müsste man
aber mit einem Interrupt arbeiten, jedenfalls wenn man nicht die schon
benutzten Pins umsortieren will. Ich wollte PC4 verwenden. Oder habe ich
da was übersehen? Sind da Probleme in deiner SW zu erwarten?

Heute Abend werde ich mal Schaltplan und Layout erweitern und testen,
wie groß die beiden Cs sein müssen.

Michael L. schrieb:

> um das Rechtecksignal auf einem der freien Pins auszugeben, müsste man
> aber mit einem Interrupt arbeiten, jedenfalls wenn man nicht die schon
> benutzten Pins umsortieren will.

Wenn man den mega48 verwendet, reicht es PD5 frei zu machen, dann kann
man den OC0B Ausgang nutzen. Ich denke das dürfte die beste Lösung sein.

> Heute Abend werde ich mal Schaltplan und Layout erweitern und testen,
> wie groß die beiden Cs sein müssen.

Als Frequenz würde ich etwa 50-100kHz verwenden, dann reichen für C1
etwa 100nF und 1µF für C2.

Benedikt K. schrieb:

> Wenn man den mega48 verwendet, reicht es PD5 frei zu machen, dann kann
> man den OC0B Ausgang nutzen. Ich denke das dürfte die beste Lösung sein.

Dann ist das ganze aber nicht mehr mit der bisherigen Lösung kompatibel.

> Als Frequenz würde ich etwa 50-100kHz verwenden, dann reichen für C1
> etwa 100nF und 1µF für C2.

Schon klar, je höher f, desto kleiner C. Aber ganz so hoch wäre ich mit
der Frequenz nicht gegangen (rein gefühlsmäßig), doch ich habe da auch
wenig Erfahrungen.

> Wenn man den mega48 verwendet, reicht es PD5 frei zu machen, dann kann
> man den OC0B Ausgang nutzen. Ich denke das dürfte die beste Lösung sein.

Also PC3 wäre z.B. noch komplett frei.
Man könnte doch einfach einen Timer verwenden und den Pin bei jedem
Timer-Interrupt toggeln. Nicht ganz so elegant, aber mit der jetzigen
Version kompatibel.
Und die Frequenz spielt kaum eine Rolle. Ich habe so eine Ladungspumpe
auch schon mal mit ein paar MHz betrieben (einfach CKOUT vom AVR
verwendet). Geht auch...
Und 50-100kHz sind eigentlich noch nicht so viel. Normale
Schaltnetzteile liegen in einem ähnlichen Bereich, z.T. sogar darüber.
Diese Frequenz ist für eine Ladungspumpe ganz gut. Die Belastung durch
den Kontrast-Anschluss ist ja eh minimal.

=> misser:
I also already thought about showing the base-emitter voltage.
But I didn't need it until now. Sometimes it really could be useful, and
so I will try it soon. The voltages are already being measured but they
are not shown in the display. So it shouldn't be a big thing to add
this.

Markus F. schrieb:

> Also PC3 wäre z.B. noch komplett frei.
> Man könnte doch einfach einen Timer verwenden und den Pin bei jedem
> Timer-Interrupt toggeln. Nicht ganz so elegant, aber mit der jetzigen
> Version kompatibel.

So hatte ich mir das mit dem Timer gedacht. Allerdings würde ich PC4 als
Ausgang für das Rechtecksignal vorschlagen, und PC3 als 4. Test-Pin
freihalten (PB6 und PB7 sind auch noch frei). Ich hätte da noch so eine
Idee, z.B. könnte man den 4. Test-Pin für die Prüfung
Gleichrichterbrücken verwenden. Das soll aber nicht heißen, dass du das
auf jeden Fall machen musst. ;-)

misser schrieb:
> ==> Thanks Markus,
>   I don't mean to show the base-emitter voltage on the LCD exactly , but
> only : "Si" or "Ge" or "Dt" like this : "PNP Ge" for bipolar of
> germanium; or "NPN Dt" for bipolar darlington (so darligton transistor
> will be not supported only but shown also )....and with  new soft that
> support UJT : AVR-transistortester will be realy fantastic ...Thank you
> very much Markus .

I think, V_be would be better, because there are not so hard bounds
between Ge and Si. I found some Ge with more than 0.5V in my part boxes.

Yesterday I tested a darligton (TIP120), but h_fe = 0 was shown. A
problem may be, there are 2 R and a D inside.

I know that the hFE of darlingtons in most cases can not be measured.
They have an internal pulldown resistor at the base pin (several 10
kiloohms). Then, with the 470k test resistor in the tester, there isn't
enough base voltage to switch the darlington.
The internal diodes are no problem.

Naja, der 4. Test-Pin hilft auch nur für Gleichrichterbrücken und
Dual-Gate-FETs etwas. Das lohnt sich dann eigentlich nicht.
Brückengleichrichter kann man ja auch durch Test der einzelnen Dioden
überfrüfen. Dauert natürlich etwas länger.
Außerdem ist bei einem Gleichrichter auch die Durchbruchspannung
wichtig.
Das ist die Spannung, bei der die Dioden in "Rückwärts-Richtung" zu
leiten beginnen. Wenn man den Teststrom gering hält (einige zig µA) kann
man diese Spannung ohne Gefahr für die Dioden überprüfen.
Aber sowas kann man in den Transistortester so nicht integrieren.

Testweise habe ich so eine Schaltung aber schon mal aufgebaut:
Ein kleiner Spannungswandler liefert eine hohe Spannung (in meinem Fall
2700 Volt). Diese Spannung wird über einen entsprechend großen
Widerstand (ich habe 45Megaohm verwendet; also max. 60µA Strom und damit
auch vollkommen ungefährlich bei Berührung) an die zu testende Diode
angelegt.
Dann kann über einen sehr hochohmigen Spannungsteiler die parallel zu
der Diode anliegende Spannung gemessen werden. Das ist die
Durchbruchspannung.

Aus naheliegenden Gründen wird das aber nicht in den Transistortester
eingebaut...
Kurz: Ich halte das mit dem Test von Gleichrichtern für nicht so
besonders nützlich.

Ideen sind ja dazu da, dass man mal darüber diskutiert.

BTW: Bei der Dioden-Messung wird jetzt auch nicht Durchbruchspannung
ermittelt. Die ist ja auch wurscht, wenn man nur wissen will, was für
ein Teil man vor sich hat und wie die Pinbelegung ist.

Ich habe jetzt die Messung der Basis-Emitter-Spannung eingebaut und die
neue Version damit auch schon hochgeladen.
Außerdem ist da noch die Erkennung von Darlington-Transistoren etwas
verbessert. Vorher konnte es bei bestimmten Anschlussreihenfolgen
passieren, dass die internen Schutzdioden (wegen der ebenfalls
vorhandenen internen Widerstände) nicht erkannt wurden.
Ich habe die neue Version wieder mit einer ganzen Menge Bauteile
getestet und keine Probleme festgestellt.

=> misser:
Now I added the support for showing the base-emitter-voltage!

Hallo Markus,

ich hab da mal was vorbereitet, ist aber der Stand vom 29.06.09. Das du
schon wieder was neues gemacht hast, hab ich gerade erst gesehen. Kannst
ja mal reinschauen, wenn du willst.

Zur allgemeinen Information:
Ich hatte ein Display mit erweitertem Temperaturbereich (Pollin 120
469), und wollte das gern einsetzen.

Mit der weiter oben schon gezeigten Schaltung (mit C1 = 4,7µ und C2 =
22µ) bekomme ich mit der geänderten SW an PC4 bei knapp 2 kHz
Rechtecksignal -3 .. -4 V je nach Belastung. Diese habe ich über einen
10k Trimmer an Vo des Displays gelegt, den R nach Vcc und die Verbindung
nach GND weggelassen. Ich  bin jetzt sehr zufrieden.

Bevor anderweitig Fragen oder Zweifel kommen, wegen der nur 2 kHz. Das
läuft über Interrupt, und bremst sonst die Bauteilerkennung zunehmend
aus.

> How about darlington : it's possible to show  h_FE=----  instead of :
> h_FE=0 to mean that's too high ( 800 to 80000 ) !!

The hFE is not too high.
The Problem while measuring the hFE is that most darlingtons (for
example BD675) habe internal resistors from base to emitter. At the
BD675, this resistor is only 8.0 kOhms.
The tester has a resistor of 470kOhms to measure the hFE.
So there will only be 0.084 volts at the base. But the darlington starts
switching at above 1 volt...
With the 470k resistor, almost no darlington will reach the conducting
state.
For this test, a much lower resistor is needed. For example 5 kOhms.
That would allow 1mA of base current.
But then comes another problem: The BD675 (just an example) has an hFE
of about 750. So, 1mA of base current would result in 750mA of collector
current.
Of course, the I/O pin of an AVR cannot deliver this current. For this,
external power transistord would be needed.
Also, a much stronger power supply is necessary for this. A normal 9v
battery can not deliver 0.75 amperes.
And there are darlingtons with an eve higher hFE. So the tester should
be capable of delivering about 3 amps.
And I don't think it would be good if something wents wrong and the
tester puts 3 amps through a little SMD transistor...

I would say: Be happy if the pin assignment, the type (NPN/PNP) and the
base-emitter-voltage is measured, and test the hfe manually, if
necessary.

Du solltest dir eine neue Version des AVR-Studio herunterladen.
Es gehört ein Haken bei SPI Enable, die anderen Haken gehören weg. Der
Rest passt.

So, hier ist mein Nachbau zur Begutachtung ...

Basisversion von Markus mit folgenden Erweiterungen:
- Versorgung über Batterie oder Steckernetzteil
- negative Hilfsspannung für LCD über Rechecksignal aus PC4

Es stehen auch fertige Eagle-Dateien zur Nachnutzung bereit.

Falls Interesse besteht, werde ich die Erweiterungen auf der
Projektseite dokumentieren, und Markus zu überreden versuchen, die
notwendigen Ergänzungen in seinen Code zu übernehmen. Diese sollten mit
der bisherigen Schaltung kompatibel sein, so das es nicht notwendig
wäre, mehrere Versionen zu pflegen.

@Michael L.
Schöner Aufbau.
Könntest du eine Foto von innen machen?
Mich würde interessieren, wie du das LCD befestigt hast.

=> Benedikt
Foto geht im Moment nicht, ich kann es nachreichen, dauert aber noch ein
paar Tage. ;) Das LCD habe ich ganz einfach seitlich mit Heißkleber von
innen an die Oberschale geklebt (ein gängiges SD10).

=> Esko
Die Grabber sind Art-Nr. 830 265 (0,75€) von Pollin. Eigentlich hatte
ich ja kleinere (830 263 für 0,50€) gestellt, aber die auf dem Bild
geliefert bekommen. :(

Michael L. schrieb:

> Die Grabber sind Art-Nr. 830 265 (0,75€) von Pollin. Eigentlich hatte
> ich ja kleinere (830 263 für 0,50€) gestellt, aber die auf dem Bild
> geliefert bekommen. :(

Die Teile sind Preis/Leistungsmäßig wirklich gut (also mechanisch
durchaus brauchbar). Allerdings kam es mir so vor, als wenn das Metall
schon leicht oxidiert wäre, denn manchmal bekomme ich mit denen erst
nach etwas Wackeln/Schieben des Klemmhackens einen 100%igen Kontakt.

=> misser:
Your way of showing the components in the LCD is also a good
possibility.
Someone else here wrote something similar. Perhaps I will try it soon.

And the reason for that the BU2508DF couldn't be tested is simple:
This transistor has a 33 ohm resistor from base to emitter.
This resistor creates a voltage divider with the tester's 680 ohm
resistor. So, there are only 0.23 volts at the base. Not enough to
switch the transistor.
Those transistors unfortunately couldn't be tested with this transistor
tester.
With three additional resistors in the tester, this would be possible.
They could be 125 ohms. This would cause 40 milliamperes of current, the
maximum an AVR I/O pin can deliver continuosly.
At the BU2508DF, this would mean 1.04 volts of base voltage, which is
enough to switch the transistor.
But then there is a risk of damaging very sensitive parts (for example
low current LEDs) with those 40mA.
So I think is's better to keep the two resistors (680 ohms and
470kOhms). This works for most components. And the about 7.5mA of
current the 680 ohm resistor allows can hardly damage any component, I
think.

P.S.: You can also simply write in English. Most people here can read
and write English. You don't have to write everything in English and
German...

Hallo zuasammen.

Leider kann ich meine Schaltung nicht aktivieren. Habe mal den Plan
angehängt.
Wenn ich auf den Schalter taste, dann lässt Q2 keine Spannung durch :-((

Woran kann das liegen ?

R8 ist falsch angeschlossen, der gehört an die Basis des Transistors,
nicht an den Emitter...

Richard schrieb:
> kann es sein, dass man den AT-mega8 lieber nicht in der Schaltung
> programmieren sollte (mit den 680 Ohm Widerständen)?

Jeder einigermaßen ordentliche Programmer hat mit 680 Ohm Widerständen
keine Probleme.
Von daher dürfte es eigentlich keine Probleme geben, außer bei
irgendwelchen direkt am LPT mit Serienwiderständen Programmern.

Yes, this really works!
But the hFE of most optocouplers is very low. Usually it is between 0.1
and 6, so it couldn't be measured well.
But it works for a simple test (is the optocoupler working or not...)

Vielleicht kann man solche Tips in einer Art Betriebsanleitung
zusammenfassen.

Ich wollte mal Fragen, ob jemand schon die Messung der Gatekapazität
eingebaut hat und bereit wäre diese zu veröffentlichen.

Habe den ganzen Code auf ein 20x4 Display ( Betrieben mit 3xLi.ion Akkus
+ Stepdownwandler +Summer +Einzelzellenüberwachung) umgeschrieben,
weshalb nun etwas mehr Platz auf dem Display vorhanden ist.


Gruß Alex

=> misser:
Thanks for your good description about the error with the transistors
with internal diodes.
But I wrote the explanation for this some posts before:
The BU508 has a low resistance between base and emitter (I didnÄt find a
value in the datasheets, but I think ist is below 100 ohms).
Because of this resistor, the BU508 can't be switched by the 680 ohm
resistor. So,it will always be detected as 2 diodes, or as a broken
part.
I'm sorry, but with the existing hardware there is no way to solve this
problem.

If there is a high (or infinite) restistance between base and emitter,
the pin assignment is detected correctly. I tested it with a BD675
darlington. This transistor has an internal diode (collector to emitter)
and an 8,12kOhm resistor from base to emitter. The pin assignment was
detected correctly in all 6 possibilities.

I know that drain and source of JFETs are often detected incorrectly
(drain=source and source=drain). But somewhere I red that drain and
source of JFETs are (almost) equal, so it ist impossible to detect them.
I also know the detection of triacs doesn't always work. But I had only
relatively large triacs (BT136 and BT139) for testing. I thought they
just need to much gate current.
The MAC97A is a small triac with just 5mA of gate current. But the
problem is that there are many ways to switch a triac. That needs some
more testing. After getting some small triacs I will try to solve this
problem...

But the detection of MOSFETs (enhancement and depletion mode) worked
fine in all my attempts. Could you please say the type of MOSFET that
caused errors?

Ich habe jetzt mal die Messung der Gate-Kapazität mit eingebaut.
Der Messbereich ist 0...655nF mit 0,01nF Auflösung.
Allerdings werden nur Mosfets bis ca. 120nF zuverlässig erkannt, darüber
wird er (fälschlicherweise) als NPN-Transistor erkannt, da die
Gate-Ladezeit zu hoch wird.
120nF haben aber allenfalls richtig dicke IGBTs (die in der
"Brick-Bauform", also INT-A-PAK o.ä.), mit meist über 1000V und deutich
über 200A Belastbarkeit. Solche Monster werden eben nicht mehr
zuverlässig erkannt...

Die Genauigkeit ist allerdings nicht besonders hoch (vielleicht +/-
10%).
Durch Abstimmung der Berechnungsfaktoren (Defines oben im Code) auf den
verwendeten AVR und die verwendeten Widerstände kann die Genauigkeit
aber verbessert werden.
Dazu einen MOSFET mit geringer Gate-Kapazität anschließen. Von Gate nach
Source wird noch ein präziser Kondensator mit ca. 100nF geschaltet.
Nun muss ein Messwert von etwas über 100nF angezeigt werden. Wenn nicht,
kann es an den Defines richtig justiert werden.

Ich stelle dier Version erstmal nur hier rein. Wenn ihr sie so gut
findet, werde ich sie auch in die "offizielle" Version übernehmen und
den Artikel entsprechend ändern.

Ich habe mir gestern die neue Version geladen und bin weiterhin
begeistert.
Beim Vergleich von zwei Geräten, aufgebaut mit 20% Widerständen, nichts
ausgemessen, unterscheiden sich die angezeigten Werte nur minimal.

Nochmals vielen Dank an Markus das er dieses klasse Projekt hier herein
gestellt hat.

Hubert

Hubert G. schrieb:
> aufgebaut mit 20% Widerständen
Gibts solche tatsächlich oder ist das eine Spezialanfertigung?

Auf Vorrat kaufe ich mir nur noch 1%, weil die paar Cent/100Stück
wirklich irrelevant sind.

@Alexander Schmidt
Die Widerstände haben einen silbernen Toleranzring, sind also 10%.
Ich habe aber tatsächlich noch etliche Widerstände ohne Toleranzring
herumliegen.

Es gibt mal wieder was neues...
Die Messung der Gate-Kapazität ist jetzt auch in der "offiziellen"
Version und ich habe das Funktionsprinzip auch im Artikel beschrieben.

Und der Messbereich der Widerstandsmessung wurde nach unten hin
erweitert.
Nun können Widerstände ab 5 Ohm gemessen werden. Vorher waren es min.
165 Ohm.
Die obere Grenze von 910kOhm ist so geblieben. Vielleicht versuche ich
auch noch mal, die zu erhöhen.
Die Erhöhung wäre ja kein Problem, aber danach muss man wieder alles
testen, ob es dadurch zu Fehlerkennungen kommt. Das mache ich aber
demnächst mal.

Und die Messung der Dioden-Durchlassspannung wurde auch verbessert. Ich
habe nämlich vorher nicht berücksichtigt, dass an einem auf "low"
gelegten AVR-Pin nicht ganz 0V anliegen. Mit dem 680-Ohm-Widerstand
gegen Plus steigt die Spannung auf immerhin 100mV, was für einen
beträchtlichen Messfehler sorgt.
Jetzt wird die Spannung am Low-Pin eben auch gemessen und von der
Spannung am Pin, der über 680 Ohm auf Plus gelegt wird abgezogen. Damit
ist dieser Fehler kompensiert.
Diese Änderung war für die Widerstandsmessung übrigens auch wíchtig.
Ich habe dann auch noch mal mit vielen verschiedenen Widersränden die
Widerstandsmessung getestet.
Links steht der wert, den der Transistortester ermittelt hat, Daneben
(in Klammern) der mit einem Multimeter gemessene Wert:

9 (10) Ohm
11 (12) Ohm
17 (18) Ohm
21 (21,5) Ohm
38 (39) Ohm
97 (98,5) Ohm
215 (218) Ohm
657 (667) Ohm
978 (994) Ohm
2632 (2672) Ohm
4274 (4338) Ohm
5399 (5517) Ohm
9860 (9947) Ohm
11968 (12069) Ohm
15497 (15330) Ohm
18121 (18126) Ohm

19,1k (19,9k) Ohm
20,6k (21,6k) Ohm
31,8k (32,6k) Ohm
37,7k (38,6k) Ohm
45,8k (46,5k) Ohm
78,2k (79,1k) Ohm
97,6k (98,9k) Ohm
195,9k (197,7k) Ohm
463,6k (467,9k) Ohm
694,1k (705,9k) Ohm

Fast im gesamten Messbereich ist die Genauigkeit besser als +/- 5%,
häufig sogar besser als +/- 2%.
Damit ist die Widerstands-Messfunktion natürlich kein Ersatz für ein
gutes Multimeter. Dafür war sie aber auch gar nicht gedacht...
Um mal schnell einen Widerstand ungefähr zu bestimmen, ist sie aber
recht praktisch, finde ich.

Hallo Markus,

ich habe das Problem, dass mir der Tester ab und zu anstatt eines
Mos-E-Fet einen Mos-D-Fet anzeigt.  Dieser Fehler tritt auf, wenn ich
Pin 1 an Gate, Pin2 an Source und Pin3 an Drain habe. Wenn ich diese
Belegung ändere, dann zeigt mir das Gerät wieder alles korrekt an. Wie
kann das sein?

Außerdem besteht das Problem, dass er mir ab und zu einen Widerstand
(z.B 190k) an Stelle eines Transistors oder einer Diode anzeigt.

Habe mein Layout schon mehrmals angeschaut (Lochraster), aber keinen
Fehler finden können. Wenn ich die Funktion der Widerstandsmessung
ausdokumentiere, dann läuft die Geschichte gut (das Problem mit dem
Mos-E und Mos-D Fet besteht dennoch).


Gruß Alex

=> Alexander Sewergin:
Hast du auch die neue Version der Firmware, die ich gestern auf die
Artikel-Seite hochgeladen habe?
Mit der würde es mich ziemlich wundern, wenn eine Diode als Widerstand
erkannt wird. Da werden Widerstände nämlich in beide Richtungen
getestet, und nur wenn die Ergebnisse un unter 10% nach oben oder unten
abweichen wird es als "Widerstand" akzeptiert.
Auch mit einer sehr starken Diode (1600V/35A Brückengleichrichter)
konnte ich keine Probleme feststellen. Wenn man einen Widerstand
parallel zu der Diode legt, passiert über ca. 30kOhm gar nichts. Von
etwa 200 Ohm bis 30kOhm wird es als "2 Dioden antiparallel" erkannt,
unter ca. 200 Ohm als Widerstand (weil die an der Diode anfallende
Spannung nicht mehr reicht, um sie zum leiten zu bringen). Einen
Widerstand von 190kOhm hat der Tester da aber nie angezeigt

Das Problem, dass ein Mos-E-Fet als Mos-D-Fet erkannt wird tritt auf,
wenn man einen Widerstand von unter 33kOhm von Drain nach Source legt.
Dann passiert es unabhängig von der Belegung.
Mit welchem Mosfet-Typen hattest du denn die Probleme. Ich konnte es mit
IRF540, IRFIZ44N und IRFD024 nämlich nicht feststellen.
Nur mit einem Elko von einigen µF oder einem Widerstand von unter 33kOhm
von Drain nach Source konnte ich das Problem feststellen.

Hast du auch die Flussmittelreste vom Löten zwischen den Test-Pins
entfernt? Ich vermute nämlich mal, dass es daran liegt. Flussmittel ist
nämlich auch ein wenig leitfähig, möglicherweise stark genug um zu den
genannten Problemen zu führen.

Hallo allerseits,

ich habe mal meine Erweiterung der Software für LCD mit erweitertem
Temperaturbereich (negative Kontrastspannung) in Markus aktuelle Version
eingebaut.

Alles weitere in der Schaltung bzw. in meinem alten Beitrag:
Beitrag "Re: Transistortester mit AVR"

@ Markus F.
Kannst du evtl. mal über die Änderung drüberschauen? In meiner ersten
Version hatte ich vor den zeitkritischen Stellen noch nicht den
Interrupt vorrübergehend abgeschaltet. Zwar hatte es wohl kaum
Auswirkungen, aber ist sicher schon so. Ich hoffe, jetzt alle und v.a.
die richtigen Stellen gefunden zu haben.

Falls jemand die Version nachgebaut und verifiziert hat, könnte man die
Erweiterung ja im Artikel übernehmen.

=> Michael L.:
Der Code sieht eigentlich ganz gut aus. Was mir daran aber nicht so
gefällt, sind die vielen AND- und OR-Befehle für den WAVE_PIN.
Damit bekommt man das Problem, dass das Programm nicht mehr in einen
ATMega48 passt. Für die Mega48-Version könnte man diese Funktion
natürlich rausnehmen.
Das würde aber für einen riesigen Salat von #ifdef-Blöcken sorgen, oder
man macht gleich eine eigene CheckPins-Funktion für den Mega48. So
richtig optimal ist das aber beides nicht. Und ehe man eine extra
CheckPins-Funktion macht, kann man auch gleich wieder eine komplett
eigene Version der Firmware für den Mega48 machen.
So hatte ich es anfangs, und es macht wenig Spaß eine Änderung (z.B.
Bugs beheben oder neue Features) in beide Firmware-Versionen zu machen
und danach auch beide wieder komplett zu testen. Deshalb habe ich dann
alles in eine Version gepackt, und durch simple Änderung des
Zielcontrollers (über den Compiler-Parameter) wird die richtige Firmware
für den jeweiligen Controller erstellt. Das finde ich ganz praktisch so
und ich würde auch nur ungern wieder zu der vorherigen, umständlichen
Methode wechseln.

Bitte verstehe das nicht falsch, aber ein kompletter Test der Firmware
(mit ca. 100 Bauteilen und verschiedener Pin-Reihenfolge) dauert auch so
schon über eine Stunde. Und so einen Test mache ich nach jeder größeren
Änderung des Programms, und dabei treten meist auch einige Bugs auf, die
dann behoben werden. Diese Korrektur könnte aber wieder an anderer
Stelle einen Fehler geschaffen haben (ist mir schon mehrmals passiert),
also kann man dann schon wieder fast von vorne anfangen zu testen...
Mit der jetzigen Firmware reichen dann zumindest in der Mega48-Version
ein paar Stichproben aus, da beide Firmware-Versionen fast identisch
sind, die Mega8-Version unterstützt nur mehr Bauteile.
Eine extra Version für den Mega48 würde aber bei jeder Änderung auch da
einen kompletten Test erfordern, und das macht wenig Spaß.

Lange Rede, kurzer Sinn: Ich würde das mit der Ladungspumpe an PC4
anders lösen:
In dem Timer-Interrupt wird jedes Mal PC4 auf Ausgang gesetzt.
In einer globalen Variable wird der vorherige Status des Pins (high oder
low) gespeichert, dann wird der jeweils andere Status gesetzt und die
globale Variable entsprechend geändert.
So etwa:

uint8_t WaveVal; //Global; vorheriger Pin-Status

ISR(TIMER0_OVF_vect)
{
  DDRC |= (1<<WAVE_PIN);
  if(WaveVal == 1) {
    PORTC &= ~(1<<WAVE_PIN);
    WaveVal = 0;
  } else {
    PORTC |= (1<<WAVE_PIN);
    WaveVal = 1;
  }
}

Natürlich ist diese Lösung weniger elegant, dafür aber recht kompakt und
(wenn es nicht mehr reinpasst) auch mit ein paar wenigen #ifdef's aus
der Mega48-Version zu entfernen.
Der große Nachteil ist eben, dass kein sauberer Rechteck mit genau 50%
Tastverhältnis an PC4 rauskommt. DDRC wird ja in der CheckPins-Funktion
auch regelmäßig umgeschaltet. Und da der Interrupt mehr Zyklen braucht,
wird die Genauigkeit bei zeitkritischen Messungen (z.B. Gate-Kapazität)
schlechter. (Da der Interrupt aber konstant viele Zyklen verbraucht,
kann ma diesen Fehler aber auch herausrechnen.)
Funktionieren würde es so vermutlich schon. Die meiste Zeit verbringt
der Tester eh mit Warten oder ADCs auslesen, und währenddessen wird das
DDR von der CheckPins-Funktion nicht umgeschaltet. Genug Spannung für
das LCD dürfte an der Ladungspumpe auf jeden Fall entstehen.

=> Alle:
Übrigens bin ich gerade dabei, eine Testfunktion für Kondensatoren
einzubauen. Der Messbereich wird wohl so 0,2nF bis 1000µF. Ganz fertig
ist es aber noch nicht...

Markus F. schrieb:
>
> => Alle:
> Übrigens bin ich gerade dabei, eine Testfunktion für Kondensatoren
> einzubauen. Der Messbereich wird wohl so 0,2nF bis 1000µF. Ganz fertig
> ist es aber noch nicht...

suuper idee, baust du eine vorschaltung um wie hier ?

[Beitrag "LC-METER / LC-Messgerät ATmega8 Assembler"]

[Beitrag "LC-Messgerät"]

[Beitrag "Re: LC-Meter Frage"]

oder was eigenes ?

> suuper idee, baust du eine vorschaltung um wie hier ?
Nein, das geht mit der jetzigen Hardware...
Der Kondensator wird über einen Widerstand (680 Ohm oder 470kOhm)
langsam geladen. Dabei wird die Zeit gemessen, bis der Portpin, an dem
der Kondensator hängt, von 0 aus 1 schaltet. Das passiert bei recht
genau 3,6V. Daraus kässt sich dann die Kapazität berechnen.
Wirklich exakt ist die Messung damit natürlich nicht, aber um die
Kapazität ungefähr zu bestimmen reicht es aus.


Die Kapatitätsmessung ist jetzt soweit fertig und funktioniert auch ganz
gut. In dem anhehängten Archiv sind wie üblich der Sourcecode und auch
die hex- und eep-Dateien für den AVR.
Die Kapazitätsmessung ist aber nur in der ATMega8-Version enthalten.
Der Messbereich ist, wie schon angekündigt, ca. 0,2nF bis 1000µF. Noch
größere Kondensatoren werden als 2 antiparallele Dioden erkannt. Meiner
Meinung nach ist der Messbereich bis 1000µF aber ausreichend.
Und bitte Kondensatoren vor dem Anschließen an den Tester entladen, beim
Anschließen geladener Kondensatoren könnte der Controller beschädigt
werden...

=>  Markus F.:

Ich werde mir noch mal Gedanken machen, wie man den Code durch
geschickte Verwendung eines Macros für den Mega48 kastrieren kann, ohne
den Code zu unübersichtlich zu machen.

Aber evtl. kannst du die Version für den Mega48 eh recht bald beerdigen,
wenn immer mehr Features hinzukommen, die nur beim Mega8 drin sind. Denn
für die 5-10 Cent, die man mit dem Mega48 spart, lohnt sich zum Einen
der Aufwand deinerseits wohl kaum noch, eine Minimalversion zu
generieren. Und auf der anderen Seite wird wohl bald der Speicher auf
auf dem Mega48 ausgehen, wenn noch weitere Anpassungen und Korrekturen
gemacht werden müssen.

Habe gerade getestet, bei mir zeigt die Kondensatormessung immer um etwa
10% zu viel an. Spielt da vielleicht schon die Toleranz in der
Oszillatorfrequenz eine Rolle?
Ansonst bin ich mehr als nur zufrieden mit dem Gerät. Es fehlt nur das
wie im Anhang.

Hubert

warum auch immer, funktioniert bei mir nciht, mal wird als "2
antiparallele Dioden" erkannt, mal "kein, unbekann ....", aber nie als
C.

Getestet in jeder test pin kombination mit 100nf styroflex, 2.2µF,
3.3µF, 10µF <- elkos. Jedesmal natürlich C abgeklemmt, kurzgeschlossen.

Habe deine hex/eep genommen und reinprogged, hardware ist 1:1 die deine
version (ext. versorgung 5V)

Transistor test und wiederstand test funktionieren ohne probleme.

Thomas R. schrieb:
> warum auch immer, funktioniert bei mir nciht, mal wird als "2
> antiparallele Dioden" erkannt, mal "kein, unbekann ....", aber nie als
> C.
>
> Getestet in jeder test pin kombination mit 100nf styroflex, 2.2µF,
> 3.3µF, 10µF <- elkos. Jedesmal natürlich C abgeklemmt, kurzgeschlossen.
>
> Habe deine hex/eep genommen und reinprogged, hardware ist 1:1 die deine
> version (ext. versorgung 5V)
>
> Transistor test und wiederstand test funktionieren ohne probleme.

Hat sich erledigt, der atmega8 den ich drin hatte reagiert jetzt gar
nicht mehr. Ein neues programmier und schon geht, C test natürlich auch.

=> misser:
> The tester cannot until now detect the transistor with internal
> diode like BU508D correctly (or simply a transistor BC550+diode between
> C and E)
I tried a BC547C (npn) and BC558C (pnp) with a diode between C and E,
and it worked as it should work (the tester shows NPN/PNP with a hFE of
~500, ~700mV Uf, and the correct pin assignment, and it also shows the
diode icon to signalize that the transistor has an internal diode).

For detection of bigger capacitors the detection of diodes must be
changed, because capacitors above 1000µF are currently being detected as
two antiparallel diodes.
Perhaps I'll try this soon...

"it should be selected with great precision by using good ohmeter"
If the problem was REALLY in resistors precision, it is no good to
select from 5% resistors because they will change real resistance during
time, by temperature change etc... You can simply get new (not used)
resistor, measure it, then solder it's pins and measure again (warm and
cold). You see all.:(

PS: I'm from Russia, so my English poor enough and with errors. But my
German is simply hirrific.

Yes, there were some problems with 2 antiparallel diodes, especially
with LEDs. Sometimes they were detected as a resistor.

I've fixed this now, and I also extended the capacity range to about
10mF. So now it is from 0.2nF to 10mF. This should really be enough.
Above ~5000µF, the reading starts getting inaccurate; at 10mF I had
about 10% error.

If the voltage of two antiparallel diodes is above 3.6 volts, it may
still be detected as a resistor. But I don't think this causes problems.

After  misser (Gast) message about resistor's precision I want to ask
the honourable author Markus F.(5volt):
Is it really need to use resistors 680 ohm and 470 kohm  with
better tolerance 1% instead of 5% or not?
And what about 78L05? It's precision is 5% or 10%.
I've modified original scheme for use LP2951 - it's plenty nice for
precise voltage adjustment and plus very low-drop voltage - less 0.6 V
(typically < 0.2 V in this device) (78L05 - near 1.5 V). Better for
battery use.
Plus Shutdown(Power-off) & Alarm inside.

To misser (Gast):
I can't write "autocalibration" in the soft. It need minimum one
parameter with reliable accuracy. So without hardware modification it is
impossible, I  think. The simplest way in my opinion - accurately set
Vcc and use it with precise resistors as Vref source. But is it really
necessary? Stable soft better, because measurements are rough, for
precise we must set emitter current for bipolar transistors, threshold
current for MOSFET, etc. Trying to do this - makes monster device, not
this little, simple, but very useful tester (thanks to Markus F.).

To Markus F. (5volt):
It seems to me, that your 10% error - negligible, electrolites have
accuracy +- 10% in the best case, usually - -+20%. May be "error" in
fact - real capacitance in it's tolerance.

=> misser: Yes, this is a good idea. But the limit for measurung wirh
the 680 ohm resistor is about 18k ohms, and not 6k ohms. I will try
this...

=> Serge S.: I have tested two 3300µF capacitors. Each of them reads
about 3400µF, a multimeter says ~3500µF. But both capacitors in parallel
read only ~6200µF, but it should be 6800µF (2*3400µF). This error can't
be caused by capactior tolerances.


Und: Ja, Elkos werden malchmal falsch herum geladen. Allerdings nur mit
maximal 5V, was bei den kurzen Testzeiten eigentlich kein Problem
darstellt. Nur bei längerer Falschpolung mit 5V bzw. Falschpolung mit
höheren Spannungen wird die isolierende Oxidschicht im Elko deutlich
geschädigt bis zerstört.

==> Markus F.
Simplest minds about the phenomenon
3400µF + 3400µF = 6200µF

1. Capacitors were not fully discharged before measurement of their sum.

2. Self-polarization of capacitors. I've seen in my practice of
TV-repair:
capacitor was discharged by my own hands, but less as 1 minute after it
had about 0.5 V without any external charge. But it was on high-voltage
capacitor (about 100 V). For low voltages I haven't such experience. But
may be the case...

3. Self-training: I've seen as some seconds after turning voltage on
electrolytic C had very big leakage current, then it decreases to
acceptable but big value in less than 30 sec. Bad quality, long time of
storage and so on... Very long time of storage (about 5-6 years) in my
case. But after about hour under voltage (with current limiting
resistor) it became to look good enough. After this I made special panel
for capacitor's training/testing.
Big leakage seems as big capacitance in simple testers. After little
training leakage became less and it seems as capacitance decrease.

Hint: multimeter's measurement of C is very rough. I have MY-68 -
multimeter and VC-6013 capacitance-meter. The difference in 20% of C to
any side between them is usual thing for electrolytes.
Don't worry about this. Your device is TESTER, not a precise bridge for
sertification measurements and with $1,000,000 price.

Some about other things...
I have a question: Is it really need to use resistors 680 ohm and 470
kohm  with tolerance 1% instead of 5% or not? What is your opinion as
author?

Hi,
Ich bedanke mich bei Markus F. (5volt) für sein tolles Projekt
und bei Armin Diehl (ardiehl) für die Board-Vorarbeit.

Ich hab den TT(eigentlich ist es schon ein Bauteiltester)
auch mal als ein Wochenendprojekt nachgebaut.
Na ja, eigentlich ist das Bestücken in paar Minuten getan.

Ich hab das Board aus
Beitrag "Re: Transistortester mit AVR"
nachgeroutet und meinem LCD ohne Hintergrundbeleuchtung angepasst.
Die Leiterbahnen sind etwas dünner, Masseflächen wurden nachgearbeitet
und es sind 4 Drahtbrücken auf dem Board. Gleichrichter fand ein
Rundgleichricher Anwendung.

Und weil ich immer etwas zurückgebe, wenn ich was kostenlos bekomme,
anbei mal meine Versionsunterlagen. Darin befindet u.a eine Exelliste
mit den Reichelt-Bauteil-Bestellnummern und eine PDF mit den
Fusebit-Haken für die Ponyprog. Fans.

Wigbert

Rudolf schrieb:
> Zumal möchte ich eine Frage die oben gestellt wurde aufgreifen:
>
> I have a question: Is it really need to use resistors 680 ohm and 470
> kohm  with tolerance 1% instead of 5% or not?

Mal ganz ehrlich, ein 1% Widerstand kostet als Einzelstück ganze 8Cent
bei Reichelt (Ein 5% übrigens 10Cent). Pro Tester macht der
Preisunterschied nur einige Cents aus.

Sich darüber den Kopf zu zerbrechen macht nur bei großen Stückzahlen
Sinn, weswegen man bei allen die diese Frage stellen, glauben muss sie
wollen den Tester ab kupfern und professionell in großen Zahlen an den
Mann bringen, wobei sie noch nicht mal in der Lage sind so eine einfache
Frage selbst zu beantworten.

Ich glaube weniger dass es hier um die 2 ¢ Preisunterschied geht, als um
den Aufwand die 1% Widerstände zu besorgen. 5%er hat jeder in der
Grabbelkiste, 1% nicht unbeding.

Just my 2 ¢

Werner

Hi,
ich glaub , ein geschickter Displayeinkauf ist gerade bei
Mehrfachnachbau interessant.
Mein Display gab es mal auf der HAM-Radio für 1 Euro und der
Kontrast ist Zufriedenstellend, denke ich.
Für den Reset R hab ich auch ein Bastelkisten R verwendet,
ansonsten alle anderen 1% Typen.

Wigbert

Oh.
In my case - 2 problems:
1. It's simply very difficult to find precise resistors, and delivery
costs ~$10. May be I don't know where to look for in my counry.
2. I would know the durability of identification algorithm vs resistors
tolerance/precision. But it's very difficult for calculations, I know.
And so I would know more simple thing: precision of 680 ohm & 470 kohm
in author's realization for simplest orientation - what MUST work
stable.
The Vcc and internal Vref precision are interesting too.

Such many questions... :)

Die Toleranz der Widerstände ist nicht so entscheidend. Über 10% sollte
sie aber nicht sein.
Am besten sind natürlich 1%-Widerstände, damit wird eben die
Messgenauigkeit am besten. Widerstände mit unter 1% Toleranz sind aber
auch wieder übertrieben, weil die Genauigkeit der ADCs selbst nicht so
hoch ist.

In English:
The tolerance of the resistors is not really important, but it sholdn't
be above 10%.
Of course, with less resistor tolerance the accurary of the measurements
becomes better. But there is no need for using resistors with tolerances
below 1%, because the ADCs of the µC also have internal tolerances.
1% resistors are best, bur 5% or 10% also work without problems, only
the accuracy becomes a bit worse.

=> misser:
You have to load the custom char first.
For the diode icon, this is done in the following lines:

LCDLoadCustomChar();  //Custom-Zeichen
lcd_eep_string(DiodeIcon); //Diodensymbol in LCD laden

You must also do this for all your other custom chars.

=> Alle:
Ich habe jetzt (in dem angehängten Archiv) auch das Problem gelöst, dass
zwei antiparallele Dioden als Widerstand erkannt werden. Sogar wenn ich
zu den 2 Dioden noch einen 22k-Widerstand parallel schalte, wird das
Ganze noch als Diode erkannt.
Ich habe sogar mal zwei 1600V/35A Brückengleichrichter antiparallel
geschaltet (+ an - und - an +; AC-Anschlüsse unbeschaltet). Auch das
wurde noch als "2 Dioden antiparallel" erkannt...


I solved the problem that 2 antiparallel diodes were detected as a
resistor. It even worked when I put a 22k resistor parallel to the two
diodes. This was still detected as 2 antiparallel diodes.

Serge S. schrieb:
> 1. It's simply very difficult to find precise resistors, and delivery
> costs ~$10. May be I don't know where to look for in my counry.

Ok availability  is really a point.
May I ask you where you live?


Werner B. schrieb:
> Ich glaube weniger dass es hier um die 2 ¢ Preisunterschied geht, als um
> den Aufwand die 1% Widerstände zu besorgen. 5%er hat jeder in der
> Grabbelkiste, 1% nicht unbeding.

Hmm. Bei mir ist es genau umgekehrt, ich kaufe fast nur noch 1%, weil
bei den kleinen Mengen der Preisunterschied egal ist und so die
Lagerhaltung einfacher ist.

Hab mir diesen tollen Tester auch mal aufgebaut.
Vielen Dank an Markus für dieses geniale Projekt.

Gruß
Andreas

Markus F. (5volt)
>But there is no need for using resistors with tolerances
>below 1%, because the ADCs of the µC also have internal tolerances.
Yes, exactly! And this internal tolerance is -10%..+5% for ATmega8 (by
datasheet: 2.3 V...2.56 V...2.7 V min nominal max - internal Vref).
Just this fact slightly surprises me: from one side - precise resistors,
but from other side - NOT so precise ADC. It will be consequent to use
the same criteria for both parts. We can use 5% resistors and internal
Vref - total precision will be ~5-10%, or we can use 1% resistors and
somewhat as TL431 as Vref source - and precision will be ~1% with a
little additional regulation.
I mean voltage and current measurement precision, not the resulting
calculated values of hFE, R, C and so on...

Alexander Schmidt (esko)
>May I ask you where you live?
No problem. Russian Federation, Vladimir - normal district center. The
main difficulty in fact is that I didn't find around such boys as me:
programmer in work hours and radio-amateur as hobby at home. I suppose
I'll find this precise resistors some time, but by some reasons (see
upper) I don't want to run and jump around this point.