Transistortester mit AVR

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

1

void measurevgate(void)

2

{  uint8_t tmpval, tmpval2;

3

//for(;;)

4

{

5

  ADC_PORT=0;

6

  ADC_DDR=(1<<e)|(1<<b);

7

  R_DDR = (1<<(2*c));        // Drain: starker pullup, Gate: schwacher pullup + interner pullup

8

  R_PORT = (1<<(2*c))|(2<<(2*b));  // Drain: starker pullup, Gate: schwacher pullup

9

  _delay_ms(1);          // gate entladen

10

11

  tmpval=(1<<c);

12

  tmpval2=(1<<(2*c));

13

  ADC_DDR=(1<<e);          // gate über 470k+pullup langsam laden

14

  while (ADC_PIN&tmpval);      // warten bis drain auf low

15

  R_PORT=tmpval2;          // gate ladewiderstand abschalten

16

  vgate=(unsigned long)ReadADC(b)*78/16;

17

}

18

}

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:

1

unsigned int ReadADC(uint8_t mux) {

2

  //ADC-Wert des angegebenen Kanals auslesen und als unsigned int zurückgegen

3

  unsigned int adcx = 0;

4

  ADMUX = mux | (1<<REFS0);

5

  for(uint8_t j=0;j<32;j++) {  // 32 Messungen; für bessere Genauigkeit

6

    ADCSRA = (1<<ADEN) | (1<<ADSC) | 5;  // Vorteiler=32

7

    while (ADCSRA&(1<<ADSC));

8

    adcx += ADCW;

9

  }

10

  adcx /= 32;

11

  return adcx;

12

}

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-rlc-meter.497170.lynkx
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-tech-lrc-meter-(1).61600.lynkx

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

1

void lcd_init(void)

2

{

3

   LCD_DDR = LCD_DDR | 0x0F | (1<<LCD_RS) | (1<<LCD_EN1);   // Port auf Ausgang schalten

4

   // muss 3mal hintereinander gesendet werden zur Initialisierung

5

   _delay_ms(15);

6

   //lcd_command(0x03);

7

   LCD_PORT &= 0xF0;

8

   LCD_PORT |= 0x03;    // D7..D4 = 0x03

9

   lcd_enable();    // Strobe E

10

11

   _delay_ms(5);    // according to datasheet: more than 4.1 ms

12

   lcd_enable();

13

14

   _delay_ms(1);    // according to datasheet: more than 100 uS

15

   lcd_enable();

16

   _delay_ms(1);

17

18

   // 4 Bit Modus aktivieren 

19

   //lcd_command(0x02);

20

   LCD_PORT &= 0xF0;

21

   LCD_PORT |= 0x02;

22

   lcd_enable();

23

   _delay_ms(1);

24

25

   lcd_command(0x28);          // 4Bit / 2 Zeilen / 5x7

26

   lcd_command(0x0C);         // Display ein / Cursor aus / kein Blinken

27

   lcd_command(0x06);        // inkrement / kein Scrollen

28

  lcd_clear();

29

}

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

1

void lcd_cursor(const unsigned char ARow, const unsigned char AColumn)

2

{

3

  lcd_command(CMD_SetDDRAMAddress | AColumn | (ARow ? 0x40 : 0x00) );

4

}

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:

1

        // "Diode"

2

      lcd_WriteResource(resDiode);

3

4

        // 2. Zeile, Belegung

5

      lcd_Line2();

6

      lcd_WriteResource(resPinTemplate);

7

      lcd_cursor(1, diodes[0].Anode);   

8

      lcd_data('A');

9

      lcd_cursor(1, diodes[0].Cathode);   

10

      lcd_data('K');

11

12

        // 2. Zeile Uf

13

      lcd_cursor(1, 4);   

14

      lcd_WriteResource(resUf);   //"Uf="

15

      ....

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

1

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.

1

  // Bauteile

2

typedef enum 

3

{ 

4

  ptNone, 

5

  ptDiode, 

6

  ptTransistor, 

7

  ptFET, 

8

  ptTriac, 

9

  ptThyristor, 

10

#ifdef UseM8

11

  ptResistor 

12

#endif

13

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

1

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

2

_delay_ms(1);

3

lcd_enable();

4

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

1

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

2

> _delay_ms(1);

3

> lcd_enable();

4

> _delay_ms(1);

5

>

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

1

> void lcd_init(void)

2

> {

3

>   LCD_DDR = LCD_DDR | 0x0F | (1<<LCD_RS) | (1<<LCD_EN1);   // Port auf

4

> Ausgang schalten

5

>   // muss 3mal hintereinander gesendet werden zur Initialisierung

6

>   _delay_ms(15);

7

>   LCD_PORT = (LCD_PORT & 0xF0 & ~(1<<LCD_RS)) | 0x03;

8

>   lcd_enable();

9

>   _delay_ms(5);

10

> 

11

>   lcd_enable();

12

>   _delay_ms(1);

13

> 

14

>   lcd_enable();

15

>   _delay_ms(1);

16

> 

17

>   // auf 4bit Modus umschalten

18

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

19

>   lcd_enable();

20

>   _delay_ms(1);

21

> 

22

>   // 4Bit / 2 Zeilen / 5x7

23

>   lcd_command(CMD_SetIFOptions | 0x08);

24

> 

25

>   // Display ein / Cursor aus / kein Blinken

26

>   lcd_command(CMD_SetDisplayAndCursor | 0x04);

27

> 

28

>   // inkrement / kein Scrollen

29

>   lcd_command(CMD_SetEntryMode | 0x02);

30

>   lcd_clear();

31

> }

32

>

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.

1

 lcd_command(CMD_SetIFOptions | 0x08);

2

3

  // Display ein / Cursor aus / kein Blinken

4

  lcd_command(CMD_SetDisplayAndCursor | 0x04);

5