Hi, habe heute mein Transistortester auch zusammengebaut und mit der Version 0.96 geflasht. Vielen Dank an alle Beteiligten, vor allem aber Karl-Heinz für seine Mühen. Allerdings gibt es da noch ein Problem. Nachdem ich einmal den Taster betätige, wird wie gewünscht ein Test durchgeführt. Unabhängig davon, ob nun etwas an den Pins hängt oder nicht, startet das Gerät anschließend aber ununterbrochen neue Tests, anstatt sich nach erfolgreicher Erkennung (bzw. der Anzeige, dass nichts erkannt wurde), abzuschalten. Irgendwann (habe bisher leider noch kein System entdeckt) funktioniert es dann aber doch und das Gerät wird deaktiviert. Ich nehme an, dass es sich um ein Problem mit der Hardware handeln muss, da anderenfalls bestimmt schon jemand ähnliche Probleme festgestellt hätte. Hat jemand eine Idee bzw. einen Tipp wo man den Fehler suchen könnte? Ich denke einmal, dass es im Bereich der Abschalt-Automatik Probleme gibt. Habe aber auf die Schnelle nichts finden können. Habe die Platine so bestückt wie sie von Asko B. zuletzt (im Beitrag vom 23.05.2012 19:39) hochgeladen wurde. Danke vielmals!
Hallo Karol, die Funktion, die Du beschrieben hast, ist so bei meinen Standard-Programmfiles vorgesehen. Das ist eine Serienmessung, die aber per Makefile Option auch abgeschaltet werden kann. Man muß den Eintrag "CFLAGS += -DPOWER_OFF=5" auf "CFLAGS += -DPOWER_OFF" ändern, um die alte Funktion zu bekommen. Man kann aber auch so jederzeit auch abschalten, wenn man während der Ergebnisanzeige den Taster gedrückt läßt, bis die Time out Meldung erscheint und dann den Taster losläßt. Mit der vorbesetzten Konfiguration schaltet der Tester nach 5 aufeinanderfolgenden Leermessungen oder 10 aufeinanderfolgenden Messungen mit Bauteil ab. Grüße Karl-Heinz
Alles klar, vielen Dank für deine Ausführungen. Hatte nachdem ich einige Stunden mit dem Aufbau beschäftigt war, einfach nur die im Archiv vorhandenen ".hex" und ".eep" geflasht und mich nicht weiter mit den Makefiles beschäftigt. Habe das Ganze jetzt mit der von dir genannten Änderung selbst kompiliert und es funktioniert in der Tat wie erwartet. Da dies mein erstes Gerät ist, wusste ich halt einfach nicht wie das normale Verhalten ist. Mir erscheint die Meldung, dass kein Teil gefunden wurde, allerdings etwas zu lang. Vielleicht wäre in zukünftigen Versionen eine Timeout Konstante direkt im Makefile eine nützliche Option. Vielen Dank noch einmal für die schnelle Hilfe.
Wie heißt das Teil denn jetzt eigentlich? Bauteiltester Transistortester ... ??? Ich finde, man sollte sich mal auf einen Namen einigen. Transistortester passt ja dank KH (Großes Lob!) nicht mehr so ganz.
Hi Cristian Ich habe auf die Leiterplatte "Component-Test" geschrieben. weil das Geraet ja mehr als R´s und C`s erkennt. Das Geraet ist beinahe genial. Sowas haette ich vor 30 Jahren haben wollen... Ich kann nur eins sagen... Karl-Heinz mache weiter so. Gruss Asko.
Hallo Transistortester Freunde, es ist soweit, endlich habe ich es einmal geschafft, das SVN Archiv mit meiner Testversion sowie der überarbeiteten Dokumentation zu füllen. Ich bin noch nicht ganz fertig, aber für diese Nacht reicht es mir. Als Besonderheit ist die Doku jetzt auch wieder in deutscher Sprache verfügbar. Die englische Version versuche ich auch mit zu pflegen. Die komplette Entwicklungs-Umgebung für die Erstellung der PDF-Dateien ist im Unterverzeichnis Doku/trunk/pdftex . Den Verzeichnisbaum kann man mit http://www.mikrocontroller.net/svnbrowser/transistortester/ anschauen. Wer Lust hat, kann jetzt die Beschreibung auch in anderen Sprachen umschreiben, ich kann leider nur Deutsch und ein wenig Englisch! Grüße Karl-Heinz
Hallo Transistortester Freunde, ich habe ganz vergessen zu erwähnen, daß es auch eine kurze Zusammenfassung der Projektweiterführung unter der Adresse http://www.mikrocontroller.net/articles/AVR_Transistortester gibt. Hier ist auch der Aufbau des SVN Archivs erläutert. Falls hier noch wichtige Ergänzungen und Korrekturen gewünscht werden, sollte man sich bei mir melden. Ich möchte es aber bei einer Zusammenfassung belassen und die Einzelheiten weiter in den pdf-Dateien belassen. Der letzte Entwicklungs-Stand sowie die neueste (dazu passende) pdf-Dokumentation befinden sich jeweils in den trunk Pfaden. Grüße Karl-Heinz
Hallo Karl-Heinz, ich werd mir das PDF gleich mal durchlesen. Wenn du mir Schreibzugriff aufs SVN gibst, dann liefer ich anschließend auch eine korrigierte Fassung (Rechtschreibung, Zeichensetzung, etc.) ein ;)
Apropos SVN! Kann mal jemand ´ne kurze DL-Anleitung geben, stehe auf´m Schlauch, da meine PDFs 5k groß sind und daher nicht funzen.
Lad dir den gesamten Tarball aus dem entsprechenden Ordner und öffne die PDF dann daraus. Oder hol dir das komplette svn via svn checkout svn://mikrocontroller.net/transistortester ./ (aber das ist sicherlich n bisschen Overkill) Wie man das PDF direkt öffnet hab ich vorhin auch nicht herausgefunden...
Mathias B. schrieb: > Lad dir den gesamten Tarball aus dem entsprechenden Ordner und öffne die > PDF dann daraus. > Oder hol dir das komplette svn via svn checkout > svn://mikrocontroller.net/transistortester ./ (aber das ist sicherlich n > bisschen Overkill) > > Wie man das PDF direkt öffnet hab ich vorhin auch nicht > herausgefunden... Hallo Mathias, Ich bin ja auch ziemlich neu mit dem Umgang von SVN. Eine einzelne Datei kann man mit svn cat herausholen. Zum Beispiel die letzte Version der deutschen Doku mit: "svn cat svn://www.mikrocontroller.net/transistortester/Doku/trunk/pdftex/german/ ttester.pdf > transistortester.pdf" Mit svn checkout kann man nur Verzeichnisse, aber auch Unterverzeichnisse herausholen. Ich muß noch herausfinden wie ich Benutzer für den Schreibzugriff (svn commit) freigeben kann. Bei Änderungen sollten natürlich die .tex Files geändert werden, nicht die pdf Files. Das pdf kann dann im german Unterverzeichnis (bzw. english) per make erstellt werden, wenn man pdflatex und andere Tools installiert hat. Grüße Karl-Heinz
Hallo Karl, kannst Du nicht einfach die Doku in Ger und Eng hier posten? Ich habe auch Probs mit SVN. LG Dirk
...so, hier is'! War ein wenig umständlich, hatte da auch meine Last herauszufinden wie ich das Teil zum lesen bekomme. Frage an Karl-Heinz: Der Tester mist bis runter 35pF, wenn ich eine Diode messe, wieso kann "dann" bis runter auf 1pF gemessen werden? Gruß Michael
Michael D. schrieb: > ...so, hier is'! War ein wenig umständlich, hatte da auch meine Last > herauszufinden wie ich das Teil zum lesen bekomme. > > Frage an Karl-Heinz: > Der Tester mist bis runter 35pF, wenn ich eine Diode messe, wieso kann > "dann" bis runter auf 1pF gemessen werden? > > Gruß Michael Hallo Michael, weil der Tester dann nicht mehr zwischen angeschlossenem Bauteil und leeren Anschlüssen unterscheiden muß. Messen kann der Tester bis 1pF, aber ist es wirklich ein Bauteil oder nur nahe zusammenliegende Test-Anschlüsse? Ich hatte inzwischen zum Testen mein Windows 7 hochgefahren, weil mich die Zugangsmöglichkeit zum SVN-Archiv unter Windows interessiert hat. Ich habe von heise.de den Tortoise SVN client für den Internet Explorer heruntergeladen und installiert. Es hat soweit funktioniert. Bei mir erschien dabei auch ein Fenster mit Spendenaufruf.?! Aber der Zugriff über svn://... funktioniert. Man kann sich im Verzeichnisbaum bewegen und ohne Probleme die PDF Doku lesen. Grüße Karl-Heinz
Na ja, nun hat es doch gefunzt! Einfach im Hauptverzeichnis auf "Download GNU tarball" und hat man ca. 3...4MB komprimierte Daten in einem Zug auf der Platte, die kann man in Ruhe entpacken und die Spreu vom (Hefe-)Weizen trennen. Für den Firefox soll´s ja ein SVN-Plugin geben, allerdings befinde ich mich bei dessen Installation in einer Endlosschleife mit dem Resultat Null, da man das TortoiseSVN dazu benötigt. Gucke mir daher mal auf Heise den Tipp an.
Hallo Ich bin per Zufall auf die Seite gelangt als ich Bauteiletester suchte. Interessanter Transistortester! Vor lauter Querlinks, weiß ich jetzt nicht mehr wo ich bin, bzw. welche die Ursprungsseite war. Autor: Dirk Willner verkauft scheinbar Platinen , Autor: Karl-Heinz Kübbeler programiert, Markus Frejek hats erfunden ? könnte mich jemand aufklären. Leider habe ich keine Möglichkeit, Platinen zu ätzen, geschwiege denn den Chip zu programmieren. Wäre es möglich die passenden Bauteile, zum zusammenbauen käuflich zu erwerben? (auch ohne Gehäuse oder Platine) Im Forum finde ich keine Angaben zu Preise oder Bestell-links. Vielen Dank
Andreas Wein schrieb: > Autor: Dirk Willner verkauft scheinbar Platinen , > Autor: Karl-Heinz Kübbeler programiert, > Markus Frejek hats erfunden So ungefähr stimmt das schon. Dirk Willner organisiert halt die Sammelbestellungen. Die Platine wurde hier im Thread - mehr oder weniger gemeinsam - entwickelt. Andreas Wein schrieb: > Wäre es möglich die passenden Bauteile, zum zusammenbauen käuflich zu > erwerben? (auch ohne Gehäuse oder Platine) Die Sammelbestellungen werden seit einiger Zeit hier (Beitrag "Info Platinen Bauteiletester / Transistortester") organisiert. Wenn ich das richtig sehe, ist noch etwas zu haben. Welche Bauteile du benötigst, wurde hier im Thread besprochen. Alternativ kannst du das auch dem Schaltplan bzw. dem Platinen-Layout entnehmen. Finden tust du die Teile dann z.B. bei Reichelt.
Neue Infos unter: Markt Beitrag "Info Platinen Bauteiletester / Transistortester" Dirk
Hello to all Transistortester friends. I want to thank "Mr. Karl-Heinz Kübbeler" for this great work and all his help. Best regards Smaeel
Angehängte Dateien:
-
Bestueckung.png
16 KB
Hallo Neue Platinenversion - Version 5.2.2 Neue Version - neues Glueck, oder so aehnlich. Im Layout hab ich die Pads fuer Widerstande und Kondensatoren groesser gemacht. Die Spannungsanschluesse sind jetzt 5,08 mm auseinander, so das jetzt ein Steckverbinder oder aehnliches raufpasst. Die Bauelementeseite hat jetzt von Hause aus eine durchgehende Masseflaeche. Die wichtigste Sache ist jedoch, das man jetzt alternativ auch einen LM7805 bestuecken kann. Die Befestigung vom Display ist auch gleich die Befestigung vom Spannungsregler. Dadurch wurde aber ein weiterer Leiterzug auf der Bauelementeseite notwendig, der dann auch unbedingt von der Bauelementeseite verloetet werden muss. Beim einsatz eines MCP 1702 bleibt alles beim alten. Sicherheitshalber sollte man den 7805 auf der Platinenseite isolieren weil dort drunter die Pads fuer den Low-drop Regler liegen. Jetzt kann man also als Spannungsregler verwenden: 1. MCP 1702 5V (TO92) 2. LM 78L05 (TO92) 3. LM7805 (TO220) 4. Schaltregler wie Traco 1-2450 Die Kondensatoren sind jetzt nur noch im 2,54 mm-Raster zu bestuecken. Das TO220-Gehaeuse vom 7805 schluckte zu viel Platz. Im Dateianhang sind wieder die Eagle-Boardfiles, PDF´s, PNG´s und die Bauteilliste. Gruss Asko.
Hallo Asko, Der Regler ist ja Kilometer weit weg von der Einspeisung, sollte schon in der Nähe sein! Für die Abschaltung, sollte auch ein mindensten 500mA Transistor werkeln, der BC5xx ist da etwas unterdimensioniert. Den Starttaster solltest du etwas weiter nach rechts setzen, sonst kommst du evtl. mit deinen SMD-Adaptern in's Gehege. Ein paar Testpins mehr, spendet mehr Flexibilität für versch. Bauteilgrössen, Widerstände, Kondensatoren, Dioden etc... Gruß Michael
Michael D. schrieb: > Der Regler ist ja Kilometer weit weg von der Einspeisung, sollte schon > in der Nähe sein! Das war er vorher schon und brachte keine Einschraenkungen. > Für die Abschaltung, sollte auch ein mindensten 500mA Transistor > werkeln, der BC5xx ist da etwas unterdimensioniert. Meines wissens nach vertraegt der Transistor 500mA. Uebrigens mal ne frage: Welche Zimmerbeleuchtung willst Du damit steuern ?? > Den Starttaster solltest du etwas weiter nach rechts setzen, sonst > kommst du evtl. mit deinen SMD-Adaptern in's Gehege. Die Adapter plaziert man sowieso extern am Gehaeuse, somit sehe ich da kein Problem. Aber der Hinweis ist nicht von der Hand zu weisen. > Ein paar Testpins mehr, spendet mehr Flexibilität für versch. > Bauteilgrössen, Widerstände, Kondensatoren, Dioden etc... ...echtes Argument... Ich hatte fuer mich persoenlich vor sowieso einen Adapter zu verwenden, um ausgeleierte Steckanschluesse zu umgehen. Was aber bis jetzt noch niemanden aufgefallen ist, das die Praezisionspannungsquelle "vor" der Siebdrossel angeschlossen ist. Gruss Asko.
Asko B. schrieb: > Was aber bis jetzt noch niemanden aufgefallen ist, das die > Praezisionspannungsquelle "vor" der Siebdrossel angeschlossen ist. Das wundert mich nicht, bei dem Zeichnungschaos ;-)
Hallo Jörn Ausschlaggebender Punkt ist aber das Layout gewesen. Der Schaltplan ist zugegebenermassen nicht der schoenste. Aber die Funktion ist ja entscheidend. Wenn nun spikes auf der Versorgungsspannung vom ATmega auftreten wirken die sich nicht auf die Versorgungsspannung von der Praezisionsspannungsquelle aus. Stabilisiert ist sie ja bereits durch den Spannungsregler. Auch ist die entfernung vom Spannungsregler zum Batterieanschluss kein Thema, dort ist eh nur die Selbsthalteschaltung und die muss nicht stabilisiert sein. Die stabilisierten 5V gehen direkt an den µC, kuerzer duerfte kaum moeglich sein. Bullet-Proof wird man das wohl in der groesse nicht hinkriegen. Gruss Asko.
hallo Asko, ich kann den Rotz mal wieder nicht öffnen, da Eagle6-Ver. denke ich mal. Einen aktuellen Schaltplan hast du leider nicht beigefügt, ich gehe mal von dem aus, was ich auf schon auf der FB habe. Also wenn der oder ein BC557 vor dem Regler verbaut ist... @Asko > Meines wissens nach vertraegt der Transistor 500mA. > Uebrigens mal ne frage: Welche Zimmerbeleuchtung willst Du > damit steuern ?? ...dann haben wir aber ein Problem! Der BC557 kann einen Kollektorstrom von 200mA abhaben, bei 625mW Verlustleistung kommt der aber ordentlich in's schwitzen, wenn dann noch optional die Beleuchtung zugeschaltet werden soll wird's sau-eng. Wir gehen mal inkl. Reserve von 100mA und 5V Spannung aus, da sind wir schon bei ca.500mW, bei 60mA kommen wir immernoch auf ca.300mW Verlustleistung...und nu? Gruß Michael
Hallo, schön das an dem Transistortester weiterentwickelt wird. Ich habe mir 2009 das ursprüngliche Gerät gebaut. Dafür hatte ich ein Direkt-Toner freundliches einseitiges Layout entwickelt. Das ganze ist sehr minimalistisch gehalten. Wenn man noch die Platinenrückseite schützt, kann man das Gerät direkt so verwenden: - Platz für den 9V-Block - zwei Testsockel (normal und Präzisionsbuchsen) - einseitig mit nur nur drei Drahtbrücken - LF50CV(empfohlen) oder 7805 , aber eben ohne Quarz, ohne Programmieranschluss und nicht auf ein Standardgehäuse eingepasst. Insgesamt ist das Layout nicht sehr hübsch, da ich damals noch nicht so fit in Eagle war und ich habe jetzt auch nicht alle Schweinereien beseitigt. Es steht zur freien Verwendung, viel Spaß damit. Aetzmaske und Co gibts hier: http://www.keinschnickschnack.de/wp-content/uploads/2011/12/Transistortester-atmega8-Reichelt-Display.zip Ich habe es nochmal kurz überarbeitet und einen passenden Reichelt.de Bestellkorb angelegt unter: https://secure.reichelt.de/index.html?;ACTION=20;LA=5010;AWKID=595527;PROVID=2084 Die Präzisionskontakteleiste SPL32 ist Sockel für den 28pin mega8 und 3 Pins sind für den Testsockel. Gleiches gilt für die normale Buchsenleiste, ein Teil fürs LCD, der andere für den zweiten Testsockel. Es lehnt sich an das alte Projekt an und Karl-Heinz Firmware sollte damit laufen.
Michael D. schrieb: > ich kann den Rotz mal wieder nicht öffnen, da Eagle6-Ver. denke ich mal. Hi Mike, lad dir die kostenlose eagle vers. 6.2.1 herunter, damit kannst du zumindest die Version 6 ansehen.
Hallo, 100mA dürften ausreichen. Allerdings fällt am Transistor weit weniger als 1V ab. Verlustleistungstechnisch also kein Problem. Gruß
U. K. schrieb: > Hallo, > > 100mA dürften ausreichen. Allerdings fällt am Transistor weit weniger > als 1V ab. Verlustleistungstechnisch also kein Problem. > > Gruß Was willst du uns jetzt damit sagen???
Michael D. schrieb: > Wir gehen mal inkl. Reserve von 100mA und 5V Spannung aus, da sind wir > > schon bei ca.500mW, bei 60mA kommen wir immernoch auf ca.300mW > > Verlustleistung...und nu? Dass Du damit falsch liegst...
Ich habe den Tester nun mal nachgebaut (nach Schaltplan der SVN Doku) und muss sagen das Teil ist Klasse! Funktioniert auf Anhieb fehlerfrei. Nur die Anzeigetexte hab ich etwas an meinen Geschmack angepasst und die Zeit in der das Messergebnis angezeigt wird erheblich verlängert. Aber das ist eben mein persönlicher Geschmack. :) Vielen Dank für die tolle Arbeit die da drin steckt. Gruß Uli
Hi Asko, ich hab gerade einen dicken Hals (nicht deinetwegen ;-) ) und hab als Entspannung mal deine letzte Schaltung etwas begradigt. (Eagle 6.x) Es wurden nur die Bauteile im .sch verschoben und das Display hat jetzt "richtige" Anschlüsse für die Beleuchtung, sonst weiter nix. @ Karl-heinz Hast du schon Ergebnisse mit der Referez 4040?? Fühle dich durch meine Frage aber nicht gedrängt. Gute Dinge brauchen meist etwas Zeit ;-)
Hello I found a bug in Makefile. There is ANZ_MESS define but in code there is ANZ_MES, so this define is not working correctly.
Hallo Jörn Das freut mich aber, das Du nicht wegen mir einen dicken Hals hast. ;-) Hoffentlich hat das nix mit un-Gesundheit zu tun. Deinen Schaltplan hab ich noch nicht angesehen. Mein Rechner will das 7z nichmehr extrahieren. Da muss ich erst mal schauen. Seit ich in Ungarn war, meckert klein&weich sowieso ich haette eine unregistrierte Betriebssystemversion. Ich habe mich gestern abend im Hotelzimmer auch ein wenig "abgelenkt". Nun ist die Version 5.2.3 fast fertig. Der Starttaster ist jetzt ganz an den Rand gerueckt, wie Michael es vorgeschlagen hatte. Somit duerfte auch ein Testadapter nicht mehr im wege sein. Zu den zusaetzlichen Messanschluessen: Ist es evtl. sinnvoll zB. drei Anschluesse im 5mm-Raster dazuzupacken um vielleicht zusaetzlich noch Schraubklemmenanschluesse aufzuloeten ??? Die wuerde ich einfach "druntersetzen". Wer die nicht moechte, koennte ja den Leiterplattenstreifen an dieser Stelle einfach absaegen. Karl-Heinz hatte vorgeschlagen auch einen stehenden Wannenstecker verwenden zu koennen. Das ist jetzt moeglich. Damit der aber auch bei nicht durchkontaktierten Leiterplatten noch loetbar ist, mussten drei zusaetzliche Vias her. Die man dann auch verloeten muss. Bei verwendung eines gewinkelten Wannensteckers sind die nicht unbedingt noetig. Zwei Vias waren aber schon vorher noetig. Es schadet jedoch nichts wenn man sie zusaetzlich mit verloetet. Leider sind die Leiterzuege jetzt nicht mehr so kurz wie vorher. Die Abblock-Kondensatoren moechte ich noch universeller machen. So das man wahlweise 2,5mm oder 5mm Kondensatoren einsetzen kann. Die Leiterplatte ist unwesentlich breiter geworden. Jetzt guckt der Kuehlkoerper eines TO220-Gehaeuses des Spannungsreglers nicht mehr ueber die Leiterplatte ueber. Auf der anderen Seite entstand Platz fuer einen zusaetzlichen Leiterzug (wegen dem ISP-Stecker). Gruss Asko.
Jörn Paschedag schrieb: > Hast du schon Ergebnisse mit der Referez 4040?? Fühle dich durch meine > Frage aber nicht gedrängt. Gute Dinge brauchen meist etwas Zeit Hallo Jörn, leider bin ich noch nicht dazu gekommen. Ich habe noch etwas an der Widerstandsmessung verbessert, meine letzte Testversion habe ich als Update ins SVN Archiv gestellt. Ich konnte die Messung mit den 470k Widerständen verbessern, indem ich einen Offset von 700 Ohm zum Ergebnis hinzufüge. Erklären kann ich die Maßnahme zwar nicht so richtig, aber wenn ich gleichzeitig die Grenze für die Messungen mit den 680 Ohm Widerständen von 28kOhm auf 20kOhm senke, erziele ich besonders mit dem ATmega8 bessere Ergebnisse. Die Ergebnisse im mittleren Widerstandsbereich (10k bis 100k) sind ohne AUTOSCALE_ADC Funktion deutlich besser, wie man in den letzten pdf-Dokus sehen kann. Als nächste Aktion habe ich vor die Kapazitätsmessung noch einmal zu überprüfen, da ich mit einem neuen RCL-Meter hoffentlich bessere Vergleichswerte als mit meinem bisherigen Multimeter messen kann. Grüße Karl-Heinz
Engy schrieb: > Hello I found a bug in Makefile. There is ANZ_MESS define but in code > there is ANZ_MES, so this define is not working correctly. This error is corrected in the last SVN version (trunk path). The source code is corrected now. Thank you for your hint. Karl-Heinz
Asko B. schrieb: > Die Leiterplatte Mannomann, jetzt mach doch wegen dieser popligen Leiterplatte nicht so ein Faß auf. Bei den paar Standardbauteilen ist das nun wirklich nichts besonderes. Da muss man nicht nächtelang diskutieren, nur weil eine Leiterbahn 2mm weiter links liegt.
Hallo, ich versuche diesen Code mit dem AVRStudio 5 zum Laufen zu bringen. Da ich aber so gut wie keine Erfahrung mit C habe, ist das natürlich etwas schwierig. Nun bin ich so weit, daß ich die Konfigurationseinstellungen mit einer eigenen Funktion integriert habe. Außerdem fehlte für das Studio anscheinend noch eine header datei, die ich eingefügt habe (inttypes.h). Nun bin ich aber mit meinem Latein am Ende, u.z. bekomme ich zu allen Definitionen in Transistortester.h die Fehlermeldung "redefinition of xxx" und dazu die Warnung "previous definition of xxx was here", wobei der pointer auf die selbe Stelle zeigt. Kann mir jemand helfen? Bruno
Angehängte Dateien:
-
Tester_V1.3.jpg
710 KB
I upgrade my previous version of this component tester. Here are changes: 1. Replaced 78L05 with precision LDO Regulator MCP1702-5002E 2. Added 8MHz crystal with two 22pF SMD capacitors... 3. Added external voltage reference (package TO-92) 4. Some esthetic changes :-) My layout is still without ISP connect before I don´t need it, I programming microcontroller in external programmer...
*My layout is still without ISP connector because I don´t need it...* Sorry for mistakes Tomas Starcok
Bruno M. schrieb: > ich versuche diesen Code mit dem AVRStudio 5 zum Laufen zu bringen. Hallo Bruno, leider kenne ich mich nicht so gut mit Windows aus, weiß aber von mindestens einem Benutzer, das es mit WINAVR gehen soll. Wichtig ist für meine Makefile, das sie sich in einem Unterverzeichnis des Quellcodeverzeichnis befindet. Wenn ich den englischsprachigen Benutzer richtig verstanden habe, hat er in der avrdude Kommandozeile make aufgerufen. Bei den Bedienoberflächen weiß man nie so recht, welche Intelligenz einem wieder hilfreich im Wege steht! Grüße Karl-Heinz
Hallo Bruno, Das Problem mit dem Studio5 hatte ich und Andere auch, daher sind wir wieder auf die 4,19 mit allen Upgrades gegangen. Im Studio 4,19, welches ich benutze, wird ein neues Projekt (muß "Transistortester" heißen) angelegt. Das Studio generiert darauf hin ein neues Makefile, welches wir aber nicht benutzen können, da ja gerade von diesem, die ganzen Einstellungen der Soft abhängt! Nach dem laden der Source u. Header-Files, muß bei "Other Files" das Makefile von Karl-Heinz geladen werden, auch schon allein wegen dem Editieren. Vor dem Kompilieren muß noch der Pfad des Makefiles von Karl-Heinz angegeben werden, Beispiel: PROJEKT--> CONFIGURATION OPTIONS--> USE EXTERNAL MAKEFILE...und dann den Pfad angeben, es sollte dann ohne Probleme Kompilieren, wenn der richtige "MCU" im Makefile angegeben ist. Hallo Karl-Heinz, ich habe inzwischen mein 2. Board mit der Abschaltung aufgebaut. Nach anfänglich massiven Schwierigkeiten, das Teil zum messen zu bewegen, ist es fast jeden Tag in gebrauch. Ich muß sagen, mein 9V Akku, hält mit der automatischen Abschaltung, eine Ewigkeit! Was etwas Probleme bereitet, ist "manchmal" die hohe Luftfeuchtigkeit, die dann anstatt das Bauteil, gemessen wird. Das kann daran liegen, das mein Layout etwas kompakter als das Vorherige ausgefallen ist und die Leiterbahnen eben auch etwas enger aneinander liegen. Gruß Michael
Hallo Karl-Heinz, hallo Michael, herzlichen Dank für die Antworten! Das Problem mit dem Makefile habe ich (scheinbar?) durch Einbinden einer h-Datei mit allen Konfigurationen gelöst. Zumindest bekomme ich dazu keine Fehlermeldungen. Was AVRStudio 5 betrifft, so hätte ich das gerne vermieden, da ich auf meinem alten PC auch immer mit Studio 4 gearbeitet habe. Auf meinem neuen PC mit Win7 64bit hatte ich aber bei der Installation Probleme und deswegen bin ich umgestiegen. Habt Ihr dazu auch andere Erfahrungen? Gruß Bruno
Michael D. schrieb: > Was etwas Probleme bereitet, ist "manchmal" die hohe Luftfeuchtigkeit, > die dann anstatt das Bauteil, gemessen wird. Das kann daran liegen, das > mein Layout etwas kompakter als das Vorherige ausgefallen ist und die > Leiterbahnen eben auch etwas enger aneinander liegen. Hallo Michael, wenn das Problem mit der Feuchtigkeit fortbesteht, könntest Du gelegentlich vielleicht mit einem Isolierspray nachhelfen. Ich würde die bestückte Platine trockenföhnen und dann einsprühen. Ohne eigene Erfahrung würde ich z.B. das Teslanol T7 Spray (Reich..) für geeignet halten. Konntest Du identifizieren, woran die massiven Schwierigkeiten bei der Inbetriebnahme lagen? Grüße Karl-Heinz
Man, Karl-Heinz...du hast Recht!!! Ausgerechnet bei dieser Platine, hatte ich keinen Schutzlack verwendet, der auf dem Vorgängermodel aber vorhanden ist, daher tritt das Problem bei dem alten Layout nicht auf! Ich verwende für die Leiterseite normaler Weise "Plastik70", der auch lötbar ist und keine Kriechströme erzeugt. > Konntest Du identifizieren, woran die massiven Schwierigkeiten bei der > Inbetriebnahme lagen? Selbstverständlich...nach 3 Tagen, hatte ich endlich herausgefunden, warum sich das Gerät einen Wolf mist und dann auf dem Display "Cell" ausgibt. Das war aber bei anderen Prozessoren eben nicht der Fall, die sind dann meistens hängen geblieben, also war das lokalisieren des Fehlers um so schwieriger. Nach zig mal ein und auslöten gewisser Komponenten, die jetzt nicht wichtig waren, für die Funktion, sieht die Platine nicht mehr so schön aus :-((( Der Übeltäter war der Regler, da muß man aber erstmal drauf kommen, denn die Pinausgabe des AVR's, hatte statt 50Hz, mehrere Kiloherz ausgegeben, was ich mir mal garnicht erklären konnte! Kurzum, ein 220µF Elko (zusätzlich zum 100nF)nach der Regelung, hatte das Problem schlagartig gelöst! Da ich mich fragte, wo denn diese Frequenz herkommen kann, kam ich mal auf die Idee, die Spannungsversorgung zu überprüfen und zwar nicht nach und vor der Batterie oder Netzteil, sondern mal eben direkt nach dem Regler! Das "Ding" hat geschwungen wie verrückt, da kommt man ja erstmal nicht drauf, da die Schaltung ja ansich korrekt aufgebaut ist, der AVR, das aber mal garnicht mag. Mein alter Aufbau hat eben auch einen 220µF Elko nach dem Regler drinnen, hatte ich aber nicht vermutet, das das der Grund dafür sein könnte. Ich muß los...Gruß Michael
Hallo Michael, aufgrund Deines Kommentars habe ich meinen alten PC angeschmissen und meinen bereits abgeänderten Code im Studio 4 getestet. Ergebnis: Gleiches Fehlerbild! Dann habe ich den von Dir beschriebenen Weg versucht und tatsächlich, der Debugger ist durchgelaufen. Danach habe ich das selbe Prozedere im Studio 5 versucht, aber leider ohne Erfolg. Das Programm blieb schon am Makefile Line1, Column1 mit der Fehlermeldung "***missing separator. Stop." hängen. Gruß Bruno
So, wieder da... Bruno M. schrieb: > Hallo Michael, > > aufgrund Deines Kommentars habe ich meinen alten PC angeschmissen und > meinen bereits abgeänderten Code im Studio 4 getestet. Ergebnis: > Gleiches Fehlerbild! > > Dann habe ich den von Dir beschriebenen Weg versucht und tatsächlich, > der Debugger ist durchgelaufen. Na also, geht doch... > > Danach habe ich das selbe Prozedere im Studio 5 versucht, aber leider > ohne Erfolg. Das Programm blieb schon am Makefile Line1, Column1 mit der > Fehlermeldung "***missing separator. Stop." hängen. Was will er denn mit einem Separator? Ich sag' ja, die 5er Version ist"Scheiße"!!! Ich bin froh, das ich bei dem 4.19er Studio gerade so zurecht komme und jetzt kommt Atmel mit einem neuen Rotz, wo nichts mehr passt! Ich frage mich, was die sich dabei gedacht haben?!? Der Jörn, z.B., hatte da auch massive Probleme mit dem Studio5, sogar das 6er hatte er mal installiert und nach einigen Nächten der Verzweiflung wieder runter geschmissen, weil die Endungen von bestimmten Codes z.B. nicht mehr ASM heissen dürfen usw.... > > Gruß Bruno Gruß Michael
Tomas Starcok schrieb: > I upgrade my previous version of this component tester. Here are > changes So please can post your changed eagle-files Thank You
in der Transistortester.h fehlt ein include guard. Wie es scheint wird sie 2mal includiert. schreibt mal am anfang #ifndef _TRANSISTORTESTER_H #define _TRANSISTORTESTER_H und am ende #endif // _TRANSISTORTESTER_H rein.
Peter II schrieb: > in der Transistortester.h fehlt ein include guard. Wie es scheint wird > sie 2mal includiert. Hallo Peter, Die Datei Transistortester.h wird ausschließlich in main.c ein einziges Mal includiert. Bitte meine Makefile verwenden, keine Automatik von irgendwelchen Bedienoberflächen! Grüße Karl-Heinz
Hello To Karl-Heinz: It would be possible to display the SW version on LCD after power on ? The current version of SW in tester would be displayed for 500ms immediately after power on, for example. I think it is practical to show the version of software at the beginning... Best regards Tomas Starcok
Hallo Karl-Heinz, wie schon weiter oben berichtet, hatte ich große Probleme Deinen Code im Studio 5 zum Laufen zu bringen. Es ging weder mit Deinem Makefile, da ich bei der Fehlermeldung "***missing separator. Stop." nicht weiter kam, noch ging es mit einem Standard Makefile, wobei ich alle Konfigurationen in die config.c übernommen habe. Damit hatte ich zuletzt mehrere Fehlermeldungen wie: D:\Documents\Elektronik\Mikroprozessoren\GCC\Projekte\Transistortester\D ebug/.././ReadADC.s(17,1): R_AVR_13_PCREL against symbol `wait10ms' defined in .text section in wait1000ms.o Diese Fehlermeldungen waren alle ähnlich und bezogen sich auf ReadADC.S. Nun habe ich gelesen, daß ReadADC.c die gleichen Funktionen hat und habe deshalb versuchsweise RedADC.c genommen, statt ReadADC.S und siehe da es läuft. Für mich stellt sich jetzt die Frage, wie sich das auf die Funktion des Gerätes auswirkt? Ein reines Geschwindigkeitsproblem? Oder hast Du etwa eine Erklärung für die Probleme? Gruß Bruno
Bruno M. schrieb: > Damit hatte ich zuletzt > mehrere Fehlermeldungen wie: > > D:\Documents\Elektronik\Mikroprozessoren\GCC\Projekte\Transistortester\D > ebug/.././ReadADC.s(17,1): R_AVR_13_PCREL against symbol `wait10ms' > defined in .text section in wait1000ms.o > > Diese Fehlermeldungen waren alle ähnlich und bezogen sich auf ReadADC.S. > Nun habe ich gelesen, daß ReadADC.c die gleichen Funktionen hat und habe > deshalb versuchsweise RedADC.c genommen, statt ReadADC.S und siehe da es > läuft. > > Für mich stellt sich jetzt die Frage, wie sich das auf die Funktion des > Gerätes auswirkt? Ein reines Geschwindigkeitsproblem? Oder hast Du etwa > eine Erklärung für die Probleme? Hallo Bruno, zunächst kann ich wegen der Befürchtung eines Geschwindigkeitsproblem beruhigen. Die Assembler Version wurde nur wegen Platzproblemen beim ATmega8 eingeführt. Beim Beginn meiner Arbeit hatte ich auch den Ehrgeiz, eine Version für einen ATmega48 übersetzen zu können. Die Assembler Routine von ReadADC spart bei einem ATmega168 80 Bytes Code (Flash Speicher). Ich entwickle unter (Ubuntu-) Linux mit einer avr-gcc Version 4.5.3 . Mit dieser Version bekomme ich nicht einmal Warnmeldungen beim Übersetzen von ReadADC . Eine mögliche Ursache für die Schwierigkeiten könnte ein rcall / call Problem sein. Wegen des größeren Adressraumes des ATmega168 kann ein rcall nur eingeschränkt benutzt werden. Der rcall ist ein Unterprogrammaufruf mit 2 Byte Code. Der call ist ebenfalls ein Unterprogrammaufruf aber mit 4 Byte Code, bei dem die Zieladresse dafür im gesamten Speicherbereich liegen kann. Die Zieladresse wait10ms ist eine externe Adresse. Möglicherweise mag Deine Compilerversion keine kurze Adressierung für externe Adressen. Die Vorgehensweise ist auch riskant, da sich ja erst beim Binden der übersetzten Objekt-Module (.o) herausstellt, ob die kurze Adressierung überhaupt möglich ist. Du kannst ja mal prüfen, ob sich die Fehlermeldungen alle auf rcall Befehle beziehen. In diesem Fall kann man bei allen "rcall wait..." Aufrufe und dem "rcall __udivmodhi4" Aufruf das r entfernen (call statt rcall). Dadurch wird dann 18 Byte mehr Code verbraucht, es verbleiben aber immer noch 62 Byte weniger als bei der C-Version. Dummerweise kennt der ATmega8 den call Befehl nicht, für eine universelle Assemblerfunktion müßte der Code mit #IF Abfragen angepaßt werden. Falls mein Tipp nicht zutreffend ist, bräuchte ich mehr Informationen: Für welchen Zielprozessor (ATmega8 oder ATmega168) wird übersetzt? Welche Compiler Version wird benutzt? Auch die vollständige Fehlerliste wäre nützlich. Um das Forum hier nicht vollzustopfen, kann man mich auch direkt unter meiner Email Adresse (1. Seite PDF-Doku) erreichen. Grüße Karl-Heinz
Karl-Heinz Kübbeler schrieb: >In diesem Fall kann man bei allen "rcall wait..." Aufrufe und >dem "rcall __udivmodhi4" Aufruf das r entfernen (call statt rcall). Alle Achtung, Volltreffer!! Nun läuft der Code ohne Probleme. Herzlichen Dank, Bruno
Angehängte Dateien:
-
Aufbau.jpg
600 KB
Zuerst allen Mitarbeitern bei der Programmerstellung DANKE! für das tolle Messgerät! Passend zu dem aktuellen Projekt habe ich meine Aufbau-Variante beschreiben. Diese besteht aus Schaltplan, einseitigem PDF-Layout zum Selbermachen, Bestückungsplan mit Bauteilliste, der Einbaubeschreibung ins Gehäuse und Tipps dazu. Zum Schluss mein Weg, wie eine eigene Software-Variante (*.hex und *.eep) mit AVR Studio 4.18 erzeugt und in den ATmega168 programmiert werden kann. Um diesen Thread nicht unnötig aufzublähen,findet sich alles unter Beitrag "Transistortester AVR - Hardware" Für Interessierte das Foto von meinem Aufbau. Karl-Anton
Hi, ich habe heute erst angefangen die Platine aus der Sammelbestellung zu bestücken. Ich muß sagen das die Platine eine echte Pfuscher Platine ist. Das man sich so etwas antun muß .... Nicht durchkontaktiert, die Komponentenabstände zu klein oder zu groß, der Schutzlack taugt nichts, die Lötpads sind teilweise zu klein, die Bohrlöcher für das Poti sind zu klein. Jetzt habe ich mir die Platine versaut, weil ein Lötpunkt so klein war das er kein Lötzinn angenommen hat. Ich kann die Platine wegwerfen. Dann noch die teilweise falsche Bestückungsmaske... Ich bin echt bedient.... Jetzt habe ich zwei Stunden verschwendet, ich hatte noch nie so eine Kackplatine am Start... Grüße Matthias
Hi, orange hand schrieb: > ich hatte > noch nie so eine Kackplatine am Start... Ja, ich muss auch sagen, dass ich schon bessere Platinen verarbeitet habe. "Interessant" wurde es, als ich die Steckerleiste fürs Display nochmal entfernen musste. Aber am Ende tut sie dann doch was sie soll. Mit freundlichen Grüßen, Karol Babioch
Wie jetzt, Ihr habt PCBs machen lassen und die haben keine Durchkontaktierungen ?
> Wie jetzt, Ihr habt PCBs machen lassen und die haben keine > Durchkontaktierungen ? Naja, darüber wurde vor der Bestellung nicht gesprochen. Ich bin davon ausgegangen, das die Platine durchkontaktiert wird und der Schutzlack Standardspezifikationen entspricht. Sonst hätte man auch gleich selber ätzen können. Wer geht denn schon davon aus das ein Platinenhersteller die Platine nicht durchkontaktiert und so einen weichen und dünnen Schutzlack aufträgt. Der Schutzlack ist so dünn, das man von einem Lötpunkt ausgehend das Lötzinn direkt weiter über die Massefläche ziehen kann. Das wäre ja nicht so schlimm, wenn die Pads das Lötzinn besser aufnehmen würden. In meinem Fall konnte ich einen Widerstand nicht festlöten, da das Lötzinn nicht auf dem Pad halten wollte. Es perlte immer nach oben ab. Ich habe dann versucht durch längeres Draufhalten und hin un her bewegen, das Lötzinn auf das Pad zu bekommen. Dabei bin ich dann abgerutscht und habe dadurch eine Brücke zwischen der Massefläche und einem anderen Pad erzeugt. Ich muss mal sehen ob ich das wieder hin bekomme. Auch vom Konzept her ist es doch Pfusch wenn man Komponenten auf einer doppelseitig ausgelegten Platine von oben und unten löten muß. Der Sockel für den uProzessor kann dann nicht korrekt aufliegen, da dann kein Platz mehr zum Löten von oben vorhanden ist. Dazu hätte man die Pads an der Stelle größer gestalten müssen. Dann noch die 6 Pin Buchse für den Programmer. Wie soll man bitte das verdeckte Mittelpin von oben vernünftig anlöten ? Ne, das kann ich leider nur als Pfusch bezeichnen. Ich hätte lieber 5 EUR mehr bezahlt und dafür eine vernünftige Platine im Industriestandard gehabt. Grüße Matthias
orange hand schrieb: > Wer geht denn schon davon aus das ein Platinenhersteller > die Platine nicht durchkontaktiert War für mich keine Überraschung, weil Oliver S. schrieb: > Die wären im Gegensatz zum Platinenbelichter auch durchkontaktiert und > mit Bestückungsdruck. orange hand schrieb: > Ich hätte lieber 5 > EUR mehr bezahlt und dafür eine vernünftige Platine im Industriestandard > gehabt. Ja, wäre weniger Fummelei gewesen.
> Die wären im Gegensatz zum Platinenbelichter auch durchkontaktiert und > mit Bestückungsdruck. Ja, habe ich wohl nicht gelesen, oder realisiert.... Wie auch immer, die Platine hat für mich einen billigen China Charakter. Werde zukünftig besser aufpassen bei solchen Aktionen. Schlimm, das wir deutschen auch schon anfangen zu pfuschen, sei es aus Unkenntnis oder Geiz ..... Grüße Matthias
Schlimm ist vor allen Dingen, das "wir Deutschen" nie selbst Schuld haben, sondern versuchen die eigene Dummheit anderen in die Schuhe zu schieben.
Hi Jörn, es geht hier nicht um Dummheit oder jemand anderem die Schuld in die Schuhe zu schieben. Es geht hier um die Erwartungshaltung. Mir war nicht klar das die Leute mit derartigem Pfusch zu frieden sind. Ich dachte immer das auch hier im Forum ein gewisser Perfektionismus vorherrscht, doch da wurde ich eines besseren belehrt. Dies impliziert, das man am besten alles selbst macht.. Grüße Matthias
Hi orange_hand, erst wollte ich schreiben: "Ich habs kommen sehen" (zusammen mit noch jemand aus dem Forum). Die Antwort wäre dann gewesen: "Hinterher sind immer alle schlauer". Dies ist ein ziemlich langer Fred und betreffs der hardware müßte man wohl ab dem oberen Drittel dieses Freds nachlesen was alles über das für und wider die hardware geschrieben wurde. Auch ich hab zum ersten mal vom Platinenbelichter gehört und auch das er keine Durchkontaktierungen macht. Auch das Konzept mit dem Display auf dem Rücken wurde besprochen, ebenso wurden hier größere Platinen vorgestellt, wo das Display auf der gleichen Seite ist. Mike 0815 hatte hier z.B. eine einseitige Platine vorgestellt und bei ihm waren die Pads nicht zu klein für die Bohrungen. Aber jeder der bestellt hat, hat die Platine vorher gesehen und der Dirk ist mit den Bestellungen kaum nach gekommen und imo (ich les das jetzt nicht nochmals nach) waren die Ersten mit der Platine zufrieden. Bin gespannt, was andere Benutzer der Platine schreiben.
Jörn, ich denke ich muß einfach meine Erwartungshaltung runter schrauben. Bei den Projekten die ich bisher gemacht habe (in eimen anderen Forum), gab es derartige Probleme nicht. Das waren allerdings auch viel größere Platinen, da hätte man bei derartiger Qualität spätestens nach zwei Stunden den Hammer genommen.... Das lag dort wahrscheinlich an der Erwartungshaltung der Macher, die sich mit meiner deckt. Es ist nur so das mir gestern echt die Hutschnur hochgegangen ist... Grüße Matthias
orange hand schrieb: > ich muß einfach meine Erwartungshaltung runter schrauben. Ich denke, die überwiegende Erwartungshaltung hier war: Hauptsache billig
Und nicht zu vergessen, so schnell wie möglich. Deswegen wurde das Layout auch nichts. Gut Ding will Weile haben, das sagte schon meine UrOma.
Mit einem Glashaarradierer war da nichts zu machen? "Nimmt kein Zinn an" habe ich schon lange nicht mehr gehört (20Jahre), Flux oder in Schnaps aufgelöstest Kolophonium als Flussmittel sollte zur Not auch gehen, oder?. Andererseits ist es schon bedenklich, das soetwas (bezogen auf die Qualität der Platinen)überhaupt vertrieben wird. Macht doch mal ein - zwei scharfe, helle, kleine Fotos. (Bildformate :) ) Gruß AR
Moin und "huch", Also, ich hatte bisher nur Positive Rückmeldungen. PM oder Forum. Ich habe 5 Teile gelötet ohne Probleme! Vias waren --noch-- nicht vorgesehen. Lötkolben ist auch ein Faktor!!! (Löttemp.) Bei 70µ Kupfer und Lötschutzlack, ist der Preis Top. Wenn wirklich der Eine oder Andere Probleme hat.. Werde ich gerne den Platinen-Belichter mailen, zwecks Ersatz. Antworten bitte per PM. LG Dirk
Wenn die Pads zu klein sind oder die Bauteile nicht passen, liegt das nicht am Belichter, sondern am bescheidenen Layout. Das musste ja alles ratz fatz gehen und wirklich diskutiert oder verbessert wurde hier ja nicht. Natürlich macht man die Pads größer, wenn man doch weiss das das Bleifrei verzinnt wird. Irgendwer hat eine Platine gemacht und die musste dann vervielfältigt werden und das möglichst schnell und billig ohne das da auch nur eine mal ein Auge drauf geworfen hat. Und dann wundert man sich das sowas dabei raus kommt. Und das man Platinen mit DuKos bei einem Hersteller machen lässt, der keine DuKos machen kann ist doch wohl mehr als nur blöd. Wer billig kauft, kauft zwei mal. Damit keine Missverständnisse aufkommen. Der Platinenbelicher.de macht prima Platinen, wenn das Layout stimmt, das weiß ich aus Erfahrung und ich würde ihn jederzeit weiterempfehlen. Das er keine Durchkontaktierungen machen kann steht ja auf seiner Seite.
@Jörn > erst wollte ich schreiben: "Ich habs kommen sehen" (zusammen mit noch > jemand aus dem Forum). ich glaube, das war ich... ;-) > Die Antwort wäre dann gewesen: "Hinterher sind immer alle schlauer". leider... @orange_hand und NEIN! Diese Art von Ansprüchen, sehe ich als gerechtfertigt! Da ich und noch "Jemand" aus dem Forum :-) es eben genauso sehen, das dieses Projekt ein (vorsichtig ausgedrückt) professionelles Layout beansprucht und verdient! Leider wurde darüber zu wenig Diskutiert und eingegangen. Ich will Askos Arbeit bezüglich seines Layout's nicht schlecht reden, er hatte sein bestes gegeben und man sollte ihm auch nicht die Schuld dafür geben, nur wurden diverse Vorschläge eben nicht umgesetzt. Das "Ding" genommen und ab in die Produktion, das war nicht genug durchdacht, jetzt ist der Ärger da... Unter Anderem war auch der Grund dafür, die angehende Unübersichtlichkeit des Threads! Wenn ich mich an ein Layout mache, dauert das Stunden, Tage oder sogar Wochen und trotzdem findet man selbst oder "Andere" immernoch ein paar Ecken u. Kanten, die es zu glätten gilt. Gruß Michael
Nu macht mal halblang: Wenn jemandem die Platine nicht gefällt, hätte er sich nicht bestellen müssen. Jedenfalls wurde das Layout hier zig-mal gepostet. Jeder konnte sich das vorher ansehen. Wenn man selbst dazu zu faul ist, darf man sich hinterher nicht beschweren. Dass es nicht besonders geschickt ist, unter einem Wannenstecker eine Durchführung anzubringen die gelötet werden muss, ist ein Fehler, der in kürzester Zeit auffällt. Bei einer IC Fassung kann man geteilter Meinung sein. Erstens kann man auch ohne Sockel arbeiten und zweitens kann man vernünftige (gedrehte) Fassungen durchaus auf beiden Seiten löten. Dass über das Design der Platine zu wenig diskutiert wurde, kann ich ebenfalls nicht nachvollziehen. Teilweise ging es tagelang nur noch um die Platine und die Frage, ob man da jetzt noch einen Pimmel verändern sollte oder nicht. Dabei muss man berücksichtigen, dass wir hier von einer absolut simplen Platine mit einer handvoll Bauteile reden. Alle Bauteile im 2,54mm Raster. Also im Grunde absolut anspruchslos. Natürlich kann man Tage und Wochen an einer Platine zubringen, wenn einem langweilig ist. Oder wenn es eben ein anspruchsvolles Design ist. Für den Vorgänger hab ich mir auch ein eigenes Layout gemacht weil mir keines, das ich irgendwo gefunden habe, gefallen hat. Das war in 2 Stunden in 2 Varianten für unterschiedliche Displayanschlüsse und ISP-Anschluss fertig. Für die Platinenprofis, die hier jetzt ihre nachträglichen Kommentare abgeben, sollte das auch kein Problem sein. Und wenn man nicht löten kann, dann ist das halt auch so eine Sache... Im Zweifelsfall ist dann eben die Platine Schuld. Viele Grüße
moin, der "Pimmel" z.B., wäre in diesem Fall, der ISP-Stecker gewesen. Platz für ein 10-Pol wäre vorhanden und eigendlich sollte dieser von den Probpins getrennt werden, wegen den Parasitären... Ein einseitiges Layout, was jetzt "keine Tage" gedauert hat ;-), wurde hier bereits gepostet(Ver.6.1.0) Oder, das 10.3, würde dann nicht mehr veröffentlich. Gruß Michael
Hi,
Ich habe gestern die Platine fertig gelötet, bis auf die Anschlüsse zum
Display. Diese muss ich vorher noch prüfen, ob mein Display sich 1:1
anschließen lässt. Und auch gestern ging es mit dem Löten nicht
wesentlich besser.
> Und wenn man nicht löten kann, dann ist das halt auch so eine Sache...
Diesen Kommentar kann ich nicht auf mich beziehen, da ich in dem letzten
Jahr mehrere Projekte (3 Synthesizer + Netzgerät) zusammengebaut habe.
Jeder hatte jeweils mehr als 500 Bauteile. Die Geräte liefen all auf
Anhieb, ohne jegliches Problem. Ich benutze einen Markenlötkolben und
generell nur hochwertiges Werkzeug mit dem man vernünftig arbeiten kann.
Daran kann‘s dann ja wohl nicht liegen. Von daher trifft der Kommentar
nicht auf mich zu. Ich denke auch einige andere hier im Forum haben
ähnliche Erfahrungen gemacht, oder gar nicht erst die Platine geordert,
da sie diese Schwierigkeiten vorausgesehen haben.
Und ja, einen gedrehten Sockel kann man von beiden Seiten Löten, wenn
die Pads auf der Oberseite groß genug ausgelegt sind und genug Platz zum
Löten vorhanden ist. Ansonsten ergibt sich der Perleffekt und man erhält
dann eine kugelförmige Lötstelle. Diese mag sogar noch leiten, aber ich
sehe es als Pfusch an. Sorry, aber ich habe hier einen höheren Anspruch
an meine Arbeit. Würde ein Lehrling so ein Werkstück einem Meister
vorlegen, dann würde er es um die Ohren gehauen bekommen.
Wie auch immer, ich habe daraus gelernt und werde dieses Wissen beim
nächsten Mal in meine Entscheidung einfließen lassen :-)
Jetzt habe ich noch eine Frage zum Programmieren des uControllers, denn
das habe ich noch nie gemacht. Welche Optionen / Parameter (Fuses) muss
man setzen ?
Grüße
Matthias
orange hand schrieb: >> Und wenn man nicht löten kann, dann ist das halt auch so eine Sache... > Diesen Kommentar kann ich nicht auf mich beziehen, orange hand schrieb: > Ich habe dann versucht durch längeres Draufhalten > und hin un her bewegen, das Lötzinn auf das Pad zu bekommen. Dabei bin > ich dann abgerutscht ??? > Ich benutze einen Markenlötkolben und > generell nur hochwertiges Werkzeug mit dem man vernünftig arbeiten kann. orange hand schrieb: > Wie soll man bitte das verdeckte Mittelpin von oben > vernünftig anlöten ? Mit vernünftigen Werkzeug geht auch das. orange hand schrieb: > die Bohrlöcher für das Poti sind zu klein. Was kann man da bloß tun?
orange hand schrieb: > Jetzt habe ich noch eine Frage zum Programmieren des uControllers, denn > das habe ich noch nie gemacht. Welche Optionen / Parameter (Fuses) muss > man setzen ? Hallo Matthias, das Setzen der Fuses wird von der Makefile gesteuert in Abhängigkeit von Prozessor-Modell, Taktrate und Quarzbetrieb. Bei Quarz Betrieb gibt es noch zwei Möglichkeiten: Full swing Betrieb oder low power Betrieb. Aufruf für full swing Betrieb: make fuses-crystal Aufruf für low power Betrieb: make fuses-crystal-lp Voraussetzung ist ein funktionsfähiges avrdude Programm. Wenn man unter Windows Bedienoberflächen nutzen möchte, kann man die Hex-Werte für das lower Byte der Fuses (lfuse) und für das high Byte der Fuses (hfuse) aus der Makefile auslesen z.B für ATmega168: ifeq ($(PARTNO),m168) MCU = atmega168 ifeq ($(OP_MHZ),1) # RC operation ,CLK 1MHz FUSES_INT = -U lfuse:w:0x62:m -U hfuse:w:0xdc:m # -U efuse:w:0xf9:m # Operation with 8MHz crystal and /8 divider , full swing crystal FUSES_CRY = -U lfuse:w:0x77:m -U hfuse:w:0xdc:m # -U efuse:w:0xf9:m # Operation with 8MHz crystal and /8 divider , low power FUSES_CRY_L = -U lfuse:w:0x7f:m -U hfuse:w:0xdc:m # -U efuse:w:0xf9:m else # RC operation ,CLK 8MHz FUSES_INT = -U lfuse:w:0xe2:m -U hfuse:w:0xdc:m # -U efuse:w:0xf9:m # Operation with 8MHz crystal and /1 divider , full swing crystal FUSES_CRY = -U lfuse:w:0xf7:m -U hfuse:w:0xdc:m # -U efuse:w:0xf9:m # Operation with 8MHz crystal and /1 divider , low power FUSES_CRY_L = -U lfuse:w:0xff:m -U hfuse:w:0xdc:m # -U efuse:w:0xf9:m endif endif Ich hoffe, das ich das nicht weiter kommentieren muß. Die Reihenfolge der if Abfrage bezieht sich auf den trunk-Zweig in SVN-Archiv, das letzte 0.97k Release hatte die Reihenfolge (1 MHz und 8 MHz) noch anders herum. Die Reihenfolge mußte wegen Test des 16 MHz Betriebs vertauscht werden! Grüße Karl-Heinz
Danke Karl Heinz, welche Betriebsart empfiehlst Du für den Batteriebetrieb, low power oder ist der full swing auch möglich ? In meinem Falle verwende ich - µC ATmega 168 - Schwingquarz 8 MHz HC49U Bedeutet also folgende Konfiguration: full swing: - lfuse = 0xf7 - hfuse = 0xdc - efuse = 0xf9 oder low power: - lfuse = 0xff - hfuse = 0xdc - efuse = 0xf9 Da ich mich noch gar nicht mit der Entwicklungsumgebung und dem Programmieren beschäftigt habe, muss ich mir erstmal einen Überblick verschaffen. Vielleicht erklärt sich ja auch jemand bereit mir einfach einen uController im Austausch oder gegen Bezahlung zu programmieren. Ich wollte mich nicht unbedingt in alle "bit and bobs" einlesen, wenn es nicht sein muss. Grüße Matthias
Hallo Karl-Heinz, ich habe mir eben mal die letzte Firmware Version aus dem Archiv herunter geladen und die ReadMe.txt gelesen. Wenn ich das richtig verstanden habe, dann könnte ich einfach die version aus dem Default Ordner auf meinen 168 laden, denn diese enthält offensichtlich die Konfiguration, die ich benötige. Ist mein Verständnis richtig ? Grüße Matthias
Hallo Mathias, ja, das hast Du richtig verstanden, der default Ordner enthält vorerst immer die Konfiguration für einen ATmega168 mit 8 MHz Quarz. Lediglich die Kalibration auf das individuelle Exemplar für die Kapazitätsmessung kann man noch durchführen. Wenn man eine AVR Entwicklungsumgebung hat, werden dazu die Parameter in der Makefile angepaßt und mit make neu übersetzt. Im trunk Zweig (Entwicklungsversion) sind in der PDF-Doku die Messabweichungen verschiedener Exemplare graphisch dargestellt. Derzeit bin ich dabei auch mehrere ATmega168A zu vergleichen. Grüße Karl-Heinz
orange hand schrieb: > Ich wollte mich nicht unbedingt in alle "bit and bobs" einlesen, wenn es > nicht sein muss. Nochmal Hallo Matthias, der Full swing Betrieb des Quarzes arbeitet etwas störsicherer, der low power Betrieb spart etwas Strom. Auf die Funktion hat das im allgemeinen keinen Einfluß. Da ich noch mit Rechnern großgeworden bin, die mit einer Befehlszeile bedient werden, komme ich bestens mit der Linux Umgebung klar. Wo es sinvoll ist, arbeite ich nach wie vor mit der Befehlszeile. Fenster-Bedienoberflächen benutze ich nur da, wo es notwendig ist. Die Software-Entwicklung ist ein zyklischer Prozeß, der aus Editieren, Übersetzen und Programm Laden besteht. Das klappt über die Befehlswiederholung auf Kommandozeilenebene prima. Ich habe auch die Nebenarbeiten wie Fuses setzen in die universelle Makefile integriert. Die Makefiles in den default, mega8_auto und mega8_selftest Zweigen unterscheiden sich nur durch den gewählten Zielprozessor und die Optionen. Ich könnte also auch im default Zweig für einen ATmega8 konfigurieren. Wenn ich hier aber die anderen Optionen nicht gleichzeitig verändere, reicht der Speicher des Zielprozessors nicht. Im übrigen sind die übersetzten Codes für die verschiedenen Prozessoren nicht kompatibel. Es wird aber der gleiche Quellcode (C und Assembler) verwendet. Wenn nötig, passt sich der Code über Preprozessor-Anweisungen dann selbst an. Das ist auch der Grund, warum die Makefiles in Unterverzeichnissen liegen. Der gemeinsame Quellcode befindet sich aus jedem dieser Unterverzeichnisse eine Ordnerebene höher. Das Versenden eines fertig programmierten ATmega168 würde ich nur in Ausnahmefällen übernehmen. Die Entwicklung ist ja immer noch nicht abgeschlossen, sonst käme ich nachher gar nicht mehr zum Weiterentwickeln. Wenn man überhaupt nicht mit Linux arbeiten will, weiß ich das es einige Nutzer geschafft haben, zumindestens den Übersetzungsvorgang mit meiner Makefile unter AVR Studio zu machen. Ob irgendeiner auch das Programm avrdude zum Laden des Programms in den ATmega unter Windows nutzt und ob das klappt, weiß ich nicht. Vielleicht meldet sich ja Mal ein Windows Nutzer. Grüße Karl-Heinz
Hallo Matthias, unter Beitrag "Re: Transistortester AVR - Hardware" im PDF-Dokument (am Ende) http://www.mikrocontroller.net/attachment/150186/_Transistortester-Hardware.pdf habe ich beschrieben, wie es bei mir (unter Windows XP) mit AVR Studio 4.18 und dem preiswerten USB-Programmer ALL-AVR geklappt hat. Grüße Karl-Anton
Hallo Karl-Anton, Hallo Matthias, das Programm avrdude soll eigentlich auch unter Windows laufen, ich weiß nur nicht welche Version. Wenn das der Fall ist, müßte man eigentlich auch auf einer Windows Kommandozeile "make upload" oder "make fuses-crystal-lp" aufrufen können. Das Programmieren der richtigen Fuses wird dann von der Makefile gesteuert. Das Programm avrdude prüft vor dem Laden von Daten, ob der richtige Prozessor gewählt wurde. Da vor dem "make upload" immer automatisch ein "make" gemacht wird, kann man praktisch nichts falsch machen. Die Programmierdaten werden immer entsprechend dem gewählten Prozessor neu erzeugt. Jede Änderung der Makefile erzwingt eine Neuübersetzung. Wenn der Prozessor falsch gewählt wurde, verweigert avrdude das Laden der Daten. Gefährlich ist nur, wenn man mit "make fuses-crystal-lp" einen Quarzbetrieb wählt, wenn kein Quarz angeschlossen ist. Ich suche also jemanden, der auch mit Windows die volle Funktionalität der Makefile geprüft hat. Im übrigen habe ich im SVN Archiv die Version 0.98k eingestellt. Diesmal habe ich nach den Änderungen nicht ganz so gründlich einen Vollcheck gemacht wie sonst . Grüße Karl-Heinz
Danke Karl-Anton und Karl-Heinz für die Hinweise. Ich werde es mal ausprobieren, vielleicht bekomme ich es ja hin :-) Grüße Matthias
Hi @ all, auch ich hatte schon vor langer Zeit geplant den Transistortester nachzubauen. Allerdings die erste Version von Markus. Die Platine hatte ich mir schon geätzt und nun wollte ich den ATMEGA 8 brennen und auf meiner selbstgebauten Entwicklungsumgebung testen. Die hex-Datei ließ sich ohne Problem brennen, bei der eep-Datei hatte ich Probleme, angeblich wäre sie zu groß. Nun muss ich aber vorweg sagen, dass ich eigentlich nur mit der Software BASCOM arbeite und damit meine Projekte programmiere. Aber auch mit dieser Software kann man fertig compilierte Dateien auf einen µC brennen. Nachdem das Brennen der eep.Datei also nicht erfolgreich war, besuchte ich hier im Forum diese Seite und musste feststellen, dass dieses ursprüngliche Projekt weitergepflegt und auch weiterentwickelt wurde. Ich werde also nun die erste Platine schrotten und mir die neueste Version herstellen. Den ATMEGA 168 habe ich mir gestern bei meinem Händler bestellt, ich denke, dass ich die nächste Woche loslegen kann. Meine Erfahrungen und ggf. Änderungen werde ich natürlich mit der Kamera festhalten und hier ins Forum setzen. Grüße Michael
Michael Klein schrieb: > Ich werde also nun die erste Platine schrotten und mir die neueste > Version herstellen. Hallo Michael, man muß die alte Platine nicht wegschmeißen. Auch die neue Software läuft auf dem alten Entwurf. Auch den ATmega8 kann man problemlos durch einen ATmega168 ersetzen! Es sind überhaupt keine Modifikationen absolut notwendig, um die neue Software zum laufen zu bringen. Dazu müssen einige Optionen in der Makefile anders als im Standard vordefiniert gesetzt werden. Sinnvoll sind aber folgende Modifikationen, die man im Hardware-Kapitel der PDF-Doku nachlesen kann. Den 8 MHz Quarz hatte ich bei meiner alten Platine einfach auf der Lötseite an die Pins gefrickelt. Die 22 pF Kondensatoren hatte ich weggelassen, funktioniert aber trotzdem. Der Quarz-Betrieb ist allerdings nicht zwingend erforderlich! Er wird ohnehin nur für die Kondensatormessung gebraucht. Grüße Karl-Heinz
moin, @Matthias Ich hatte mal zwecks Studio-Kompilat, eine kleine Anleitung hier beschrieben, weiß gerade nicht wo... Wenn du nicht zurecht kommst, schicke mir eine PN, dann sehen wir weiter. @Michael Mit Bascom die EEP auf den Prozessor zu bannen wird nicht funktionieren, da Bascom diese verfälscht überträgt!!! Dieses Problem hatten wir schon oft. Ich kann dir den XtremBurner empfehlen, der ist unabhängig und schreibt die Daten korrekt in's Flash/EEprom. Gruß Michael
Hallo Karl-Heinz, das Übersetzen deines Programms 098k im DOS-Fenster mit "make" im Ordner default funktioniert problemlos. Fuses Orginalzustand mit AVR-Studio ausgelesen: Extended: 0xF9 Soll: 0xF9 High: 0xDF 0xDC Low: 0x62 0xFF Wenn ich versuche, die fuses mit avrdude zu setzen, bekomme ich folgende Antwort. Aufruf im DOS-Fenster: make fuses-crystal-lp => make fuses-crystal-lp D:\All-Elektronik\AVR-Studio4\ATmega168\ttester_098k\default>m lp avrdude -c avrisp2 -B 10.0 -p m168 -P usb -U lfuse:w:0xff:m - avrdude: usbdev_open(): did not find any USB device "usb" make: *** [fuses-crystal-lp] Error 1 D:\All-Elektronik\AVR-Studio4\ATmega168\ttester_098k\default> Wo muss ich meinen Programmer/USB festlegen? (ALL-AVR (= AVRISP mkII)) Nachdem das fuse-Brennen mit avrdude fehlgeschlagen war, habe ich diese mit AVR studio gesetzt und auch das Programm damit übertragen => alles ok! Karl-Anton
Karl-Anton D. schrieb: > Wo muss ich meinen Programmer/USB festlegen? (ALL-AVR (= AVRISP mkII)) Hallo Karl-Anton, von der Makefile ist alles richtig konfiguriert. Der Aufruf: avrdude -c avrisp2 -B 10.0 -p m168 -P usb -U lfuse:w:0xff:m ... gibt den richtigen Programmer mit -c avrisp2 an. Auch das Interface (Port) ist mit -P usb richtig angegeben. Im avrdude Tutorial http://www.wiki.elektronik-projekt.de/mikrocontroller/avr/avrdude_tutorial ist davon die Rede, daß LibUSB installiert sein muß. Liegt es vielleicht daran? Aus dem Tutorial geht auch nicht deutlich hervor, in welcher Reihenfolge was installiert werden muß. Ich selbst benutze ja Linux, aber auch bei Ubuntu lief avrdude nicht auf Anhieb. Grüße Karl-Heinz
Hallo Karl-Heinz, danke für die Hinweise. Die Installation von LibUSB lass ich lieber sein, da ich ja keine Probleme habe. Nach der Beschreibung muss man einiges deinstalliern, dann wieder neu installiern, neuen USB-Treiber laden... Am Ende geht bei mir dann weder USB-Tastatur noch USB-Maus und ich möchte auf diesem Rechner keinen Backup einspielen und dann wieder alles aktualisieren! Karl-Anton
Karl-Anton D. schrieb: > Die Installation von LibUSB lass ich lieber sein, da ich ja keine > Probleme habe. Hallo Karl-Anton, leider konnte ich es nicht lassen, das bei meinem Windows 7 doch auszuprobieren. Wenn ich in einem cycwin Konsolen-Fenster avrdude wie hier angegeben aufrufe: avrdude -p m168 -c avrisp2 -P usb -v bekam ich auch die "did not find any USB device" Fehlermeldung. Ich habe dann libusb-win32-bin-1.2.6.0 aus dem Internet geladen. Im ausgepackten Verzeichnis habe ich den "libusb-win32 Inf-Wizard" ausgeführt (Doppelklick). Mein Diamex ALL-AVR war dabei schon eingesteckt (USB). Danach geht ein Fenster auf, wobei eine Auswahlliste von USB-Geräten erscheint, für die eine .inf Datei angelegt werden soll. Hier habe ich meinen Programmer (Klone von AVR ISP MK2) ausgewählt und weiterinstallieren lassen. Danach brachte der oben angeführte avrdude Aufruf die gewünschten Informationen über die Programmereinstellungen und die ID des angeschlossenen ATmega168A. Eine Gewähr kann ich natürlich nicht geben. Grüße Karl-Heinz
Moin, das hört sich ja gut an, dass ich die alte Platine doch noch nutzen kann. Die Kondensatormessung hätte ich doch schon gerne mit drin gehabt, den ATMEGA 168 bekomme ich wohl nächste Woche. Zum XtremBurner konnte ich zuerst nichts finden, unter XtremeBurner fand ich dann was im Netzt. Jetzt muss ich nur sehen wie ich das alles mit meinem selbstgebauten Parallelportprogrammer machen kann. Und welche Software ich dann auch noch zusätzlich installieren muss. Das ist nämlich auch der Grund, warum ich gleich die fertigen Dateien auf den ATMEGA 168 brennen wollte. Mit den Makefile Dateien kenne ich mich nämlich auch nicht aus, müsste ich mich dann auch noch reinlesen. Kennt jemand eine Software mit der ich den ATMEGA direkt per Parallelportprogrammer brennen kann? Meine Entwicklungsumgebung ist ja auch selber gebaut und läuft in Verbindung mit meinem Programmer unter BASCOM prima. schönen Sonntag Michael
Hallo Michael, die Programmer-Software "PonyProg2000 2.7c beta" kann man auf seriell oder parallel umstellen (läuft bei mir unter XP). Der ATmega 168 ist dabei, der ATmega 168A nicht. Ob es eine neuere Versionen gibt, habe ich nicht nachgeprüft. Karl-Anton
Angehängte Dateien:
-
eXtremeBurnerAVRSetupV1.1.png
27 KB -
eXtremeBurnerAVRSetupV1.1-01.png
57 KB -
MyAVR-PROG-Tool.png
130 KB
na dann wollen wir mal auspacken... den eXtremburner1.1 z.B. gibt's hier: http://extremeelectronics.co.in/avr-tutorials/gui-software-for-usbasp-based-usb-avr-programmers/ Soweit runterscrollen, bis deine gewünschte Version (u.A. auch Linux ist dabei) zum Download erscheint. Es gibt noch eine 1.2 u. 1.3 Version, diese gehen dir aber auf die Nerven, wenn du die HEX neu kompiliert hast, wird immer nachgefragt, ob sie neu geladen werden soll. Bei der 1.1, geht es mit einem Button manuell von statten! Der eXtrem unterstützt nur USB-ASP, den gibt's bei Ebay für um die 3€, für das Geld baut man keinen selbst. Da wäre noch das myAVR ProgTool V 1.37 und unterstützt mehrere Programmer. Welche das sind ist im Screenshot zu sehen. Ich selbst, habe beides installiert und funktioniert einwandfrei! Du brauchst jetzt nicht unbedingt den Mega168 um C's zu messen, das geht mit dem M8 auch wunderbar! Bei bedarf, kann ich mein Kompilat hier hoch laden. Unterstützt wird Low-Drop-Regler und die Abschaltung, ansonsten sind "fast"alle Futures aktiviert(was relevant und wichtig ist). Gruß Michael
Angehängte Dateien:
-
transistortester.png
87 KB
Hallo Michael, das hast du ja sehr ausführlich beschrieben. Ich werde mir mal die Softwares runterladen und in Verbindung mit meinem Programmer testen. Für mich ist eigentlich die Kondensatormessung eher unwichtig, da ich ein Kapazitätsmessgerät habe. Wie du geschrieben hast, werden nicht alle Typen des ATMEGA 168 unterstützt. Welchen nehmen wir denn hier für dieses Projekt? Auch bei Reichelt habe ich verschiedene Typen finden können. Als Anhang habe ich mal meinen aktuellen Schaltplan angehängt, der ist eigentlich soweit mit dem Ur-Schaltplan von Markus identisch. Nur die Bauteilewerte muss ich noch überprüfen. Sollte ich diese Woche noch Aufträge reinbekommen und muss dann eh Platinen herstellen, dann werde ich mir dann doch das neuere Layout nehmen. Das wäre dann Version 5.2.1.? Dann wäre ich auch für die Zukunft gewappnet, falls es Updates und Erneuerungen gibt. Den ISP Anschluss lasse ich aber weg, den ATMEGA kann ich ja auch auf meiner Umgebung brennen. Gruß und nochmals Danke für die vielen Informationen Michael
moin Michael, bei Reichelt werde ich diesen hier bestellen: http://www.reichelt.de/Atmel-ATMega-AVRs/ATMEGA-168-20DIP/index.html?;ACTION=3;LA=2;ARTICLE=58324;GROUPID=2959;artnr=ATMEGA+168-20DIP;SID=12T3Xy4n8AAAIAABT0PlU8bccc99f6b44db843b9cfaa778ef89c9 ist die 20DIP-Ausführung, ansonsten gibt es ja noch die SMD-Ausführung im TQFP-32, ansonsten kenne ich keine. Das ist ja auch wurscht, die gehen ja alle. > Wie du geschrieben hast, werden nicht alle Typen des ATMEGA 168 > unterstützt. Das habe nie geschrieben!?! Den ISP-Connector würde ich auf jeden Fall mit einbauen, du wirst es bereuen, wenn nicht! Allerdings würde ich dafür Jumper vorsehen, (so habe ich es gemacht) damit die Messungen nicht verfälscht werden. Wenn du keine Kondensator-Messung brauchst, dann würde der Mega8 ja voll ausreichen. Das Future kann man nämlich per Makefile abschalten. Schaltplan: Vor dem LF-Fuffzich, fehlt ein Elko oder wenigstens im Layout optional vorsehen! Siehe hier: Beitrag "Re: Transistortester AVR" Gruß Michael Gruß Michael
Michael Klein schrieb: > Als Anhang habe ich mal meinen aktuellen Schaltplan angehängt, der ist > eigentlich soweit mit dem Ur-Schaltplan von Markus identisch. Nur die > Bauteilewerte muss ich noch überprüfen. Hallo Michael, den R4 würde ich kleiner wählen die Verbindung von PD6 (12) nach C4 würde ich nicht direkt, sondern über einen Widerstand machen. den C4 kann man auf 10nF verringern. der C3 am AREF Pin sollte auf 1nF verkleinert werden. Pin PD7 sollte mit einem Pullup Widerstand versehen sein. Zusätzliche 100nF Kondensatoren direkt an den Versorgungs-Pins des ATmega können nicht schaden. Den Quarz kann man weglassen, wenn die Kondensatormessung unwichtig ist. Ich hoffe, daß ich jetzt nichts wichtiges vergessen habe. Wenn man die Kondensatormessung in der Software per Option wegläßt, misst der Tester auch keine Sperrschichtkapazität von Dioden und auch keine Gatekapazität bei MOSFETs. Kann Dein Kondensatormessgerät das überhaupt? Mein LCR-Meter kann es nicht! Grüße Karl-Heinz
Hallo Michael, entschuldige, wenn ich nörgle. Für T1 würde ich statt dem 100mA Transistor BC557 den stärkeren BC327/328 nehmen. Um die Auflösung der Kontrasteinstellung zu verbessern, zwischen R12 und +5V einen zusätzlichen 22 k Widerstand einfügen. C2 wie bei den Beispielen im Hersteller-Datenblatt auf 10uF erhöhen, die low-drop-Regler neigen zum Schwingen. Falls möglich den 100nF C1 als SMD direkt unter dem IC-Sockel bei Pin 7 und 8/22 auf der Lötseite platzieren. Falls Du doch einen ISP-Sockel (10 oder 6-polig) vorsiehst, parallel zum Taster einen Jumper für den Programmier-Modus schalten. Ganz gründliche Leute setzen vor den AVCC-Eingang eine Siebdrossel von 10uH mit Abblockkondensator von 100nF. Denk auch darüber nach, ob Du Portpin PC3 für RS232 Ausgabe nach außen führen willst. Es sollte aber auch ohne diese Ergänzungen gehen... Karl-Anton
oder nimm das hier, ist erprobt, aufgebaut und alles druff! Ausser der RS232 Anschluß, kann man ja noch irgendwo hin quetschen. Statt dem BD140(war wohl etwas oversized) kann man auch, wie Karl-Anton schon erwähnte, den z.B. BC327 einsetzen Gruß Michael
Angehängte Dateien:
Hallo Michael Klein Die Version 5.2.1 ist zwar nicht mehr aktuell funktioniert aber trotzdem. Aber selbst in der letzten Version 5.2.3 ist der LF50 nicht vorgesehen, weil der Elkos am Ein- und am Ausgang benoetigt. Aber das laesst sich sicher einfach realisieren. Du kannst jedoch auch das von Karl-Anton oder Michael D. vorgeschlagene Layout benutzen. Funktionieren tuen sie alle gleich. Mehr moechte ich heute nicht schreiben, die Kirchturmuhr gongt schon maximalanzahl. Gruss Asko.
Michael D. schrieb: > oder nimm das hier, ist erprobt, aufgebaut und alles druff! > Ausser der RS232 Anschluß, kann man ja noch irgendwo hin quetschen. Super Idee bei einem PDF einfach mal eine UART dazu zu basteln. Warum postest Du nicht Deine Eagle Files ?
Das PDF ist eh nicht zu gebrauchen, weil es voller Kurzschlüsse ist.
Moin Freunde, aus beruflichen Gründen komme ich leider nicht dazu den Thread mehrmals täglich weiterzuverfolgen. Deshalb bin ich heute morgen mal etwas früher aufgestanden. Schließlich bekomme ich ja von euch täglich so viele Informationen. Mit der Ponyprog Software konnte ich leider meinen Programmer nicht ansprechen, deshalb überlege ich mir ob ich mir nicht doch einen dieser USB Programmer zulegen soll. Ist ja auch etwas zeitgemäßer. Ich habe mich mal wegen dem Problem BASCOM / fremde eep-Dateien einlesen per Google schlau gemacht und eine Lösung gefunden. Man soll die *.eep einfach umbenennen in *.hex. Das habe ich gemacht und es hat funktioniert. Wenn ich den Änderungen sowie Ergänzungen von Karl-Heinz und Karl-Anton vornehmen würde, müsste ich an meiner momentanen Platine auch "kosmetische" Änderungen vornehmen. Leiterbahnen auftrennen, neue Verbindungen legen usw. Die Platinenversion von Michael ist bestimmt nicht schlecht aber SMD möchte ich vermeiden. Ich denke, ich werde deshalb wenn ich eh wieder Platinen herstelle das aktuelle Board V 5.2.3 herstellen. (Danke Asko) Zum Board V 5.2.3 hätte ich aber noch eine Anmerkung. Soweit ich weiss, sollen die beiden Lastkapazitäten am Quartz möglich dicht und gleichmäßig am Quartz liegen, also beide Leiterbahnen möglichst die gleiche Länge haben. Ansonsten finde ich das Layout sehr ausgereift. Ich werde dann statt dem 7805 den MCP1702 nehmen. @ Karl-Heinz: Die Sperrschichtkapazität von Dioden und die Gatekapazität bei MOSFETs soll mein Komponententester dann doch schon können. Mein Kapazitätsmessgerät kann das natürlich auch nicht messen, genau wie dein LCR Meter. Gruß Michael
Angehängte Dateien:
-
Comptester-Mod-01.jpg
110 KB
moin, @Barney > Super Idee bei einem PDF einfach mal eine UART dazu zu basteln. Warum > postest Du nicht Deine Eagle Files ? Weil bei meinem letzten Post, sich keiner dafür interessierte und da viel Zeit drin steckt... da wollte ich erstmal die Resonanz abwarten. @Peter W. > Das PDF ist eh nicht zu gebrauchen, weil es voller Kurzschlüsse ist. Der war gut... :-))) @Michael Klein Modifiziere doch erstmal deine alte Schaltung! Es müssen keine Leiterbahnen durchtrennt werden oder sonstiges. Ergänzt werden ein Quarz und 2x 22pF. Desweiteren wird nur noch der 100nF gegen einen 1nF getauscht oder kann auch weggelassen werden, muß aber im Makefile angegeben werden! Dann funktioniert das Teil, wie andere auch. Askos Layout ist eine Double-Layer Version, meine ist einseitig mit ein paar Brücken. Die SMD-Brocken sind nur die C's und können ohne große Veränderungen gegen bedrahtete getauscht werden, ausser C6/10nF. Der kann aber ein wenig verrückt werden, dann kann auch dieser als bedrahtete Version verbaut werden. Gruß Michael
Hallo Die Version 5.2.3 ist wie die Vorgaengervarianten eigentlich auch eine einseitige Platine. Nur fuer den ISP_Anschluss ist die zweite Leiterseite beutzt. Der ISP-Anschluss funktioniert also bei einseitiger Platine nicht. Da noch genuegend Platz auf der Oberseite vorhanden war hab ich noch die Leiterzuege fuer Taster, Led auf der Oberseite gedoppelt. Auch sind alle Leitungen zu den Messwiderstaenden und Messpins doppelt. Doppelt haelt nun mal besser. Funktionieren wuerde sie ebend auch einseitig. Aber ebend ohne ISP. Dann kam noch die wahlweise Bestueckung der Spannungsregler dazu. Da waere dann ein einziger kurzer Schaltdraht anzuloeten (bei 7805er). Beim MCP 1702 nicht notwendig. Die 5 Via´s neben dem ISP-Wannenstecker sind extra so gross gewaehlt, das man sie bequem mit einem Stueck Draht herstellen kann, selbst wenn man die Platine als Einzelstueck zu Hause selbst macht und keine Durchkontaktierungen selbst fertigen kann. (Ich bin da von mir selbst ausgegangen) Jetzt Passt auch ein stehender Wannenstecker, deswegen sind es jetzt auch 5 statt vorher 2 Via´s. Der Taster hat jetzt den Platz mit der Led getauscht, so das es kein Problem mit einem Messadapter geben sollte. Auch kann man jetzt die 100nF-Abblockkondensatoren im 2,5 oder wahlweise im 5mm Raster bestuecken. Ich empfehle unbedingt eine Praezisionsfassung mit gedrehten Kontakten fuer den AtMega. Entgegen der "normalen" Vorgehensweise, die Widerstaende zu erst aufzuloeten, empfehle ich die Fassung fuer den AtMega zu erst aufzuloeten. Dann kommt man naemlich noch prima an die Kontakte zum anloeten der Oberseite. An die Widerstaende kommt man danach immernoch gut ran. Selbst wenn es ein billigloetkolben aus dem Baumarkt ist. Die Dinger zum Dachrinnenloeten sollte man jedoch nicht verwenden. ;-) Den Schaltplan habe ich immer noch nicht aufgeraeumt. Schande ueber mich... Aber durch die ganzen Aenderungen und tests ist er total unaufgeraeumt. Bei Dieser kleinen Platine ist ja ein Schaltplan schon fast ueberfluessig. Eigentlich sollte der Bestueckungsplan ausreichen. Die 22pF am Quarz haben mir selbst eigentlich auch nicht so richtig gefallen. Ich haette sie auch gerne symmetrisch und naeher am Quarz gehabt. Aber dann haette ich die Leiterzugbreite und Isolationsabstaende verkleinern muessen. Und genau das wollte ich nicht. Ich wollte es auch mit meinen eigenen technischen Moeglichkeiten sauber hinbekommen. Und SMD´s wollte ich sowieso nicht verwenden. Die Idee einen Jumper zu benutzen um die Einschaltautomatik zu ueberbruecken (beim flashen) finde ich nicht schlecht. Mal abwarten was noch fuer Vorschlaege kommen, oder gar fehlermeldungen. Irgendjeman schrieb mal, man kann ewig vor selbst so einer kleinen Platine sitzen und findet immer noch etwas zu aendern. Dem kann ich nur zustimmen. Das die Loetpads bei der von Dirk organisierten Platine so klein sind, hat mich auch gewundert. Ich war der Meinung die groesser gemacht zu haben. Aber vielleicht lag es auch am Wandel von Eagle-->Target--->Platinenbelichter. Gruss Asko.
Zusatz Wer eine doppelseitige durchkontaktierte Platine der Version 5.2.2 oder 5.2.3 verwendet, !UND! einen LM7805 im TO220-Gehaeuse verwendet, sollte die Loetpads fuer den MCP 1702 unter der Kuehlflaeche des LM7805 isolieren. Es koennte zu kurzschluessen kommen ! Bei Reglern mit TO92-Gehaeuse wie LM78L05 oder MCP 1702 ist das nicht notwendig. Gruss Asko.
Barney Geroellheimer schrieb: > Wenig Sinnvoll einen 1A Regler hinter einen 100mA Transistor zu > schalten. Und wenn man nunmal nur einen 7805 und keinen 78L05 da hat? Soll ja mal vorkommen.
Michael D. schrieb: > @Peter W. >> Das PDF ist eh nicht zu gebrauchen, weil es voller Kurzschlüsse ist. > Der war gut... :-))) Findest Du ? Ich nicht. Wofuer postest Du unnuetze Unterlagen, oder soll man die ganzen Bruecken rauskratzen ? Christian F. schrieb: > Und wenn man nunmal nur einen 7805 und keinen 78L05 da hat? Soll ja mal > vorkommen. Super Begruendung. Aber was wenn ich nur einen TO3 "rumliegen" habe ? Also passt doch bitte das Layout auch fuer einen TO3 an, denn den habe ich gerade rumliegen. Und ach ja, statt dem BC557 muss ich einen FET IRF2345 nehmen, weil ich keinen BC557 habe und ueberhaupt ist mir das Display mit Controller zu teuer, ich mochete eins ohne nehmen, also bitte auch auf einen brauchbaren AVR einigen.
Peter W. schrieb: > Super Begruendung. Aber was wenn ich nur einen TO3 "rumliegen" habe ? > Also passt doch bitte das Layout auch fuer einen TO3 an, denn den habe > ich gerade rumliegen. Und ach ja, statt dem BC557 muss ich einen FET > IRF2345 nehmen, weil ich keinen BC557 habe und ueberhaupt ist mir das > Display mit Controller zu teuer, ich mochete eins ohne nehmen, also > bitte auch auf einen brauchbaren AVR einigen. So wars nicht gemeint. Ich wollte nur Asko danken, dass er das gesagt hat und dass dieser* Kommentar eben Quatsch ist. * Barney Geroellheimer schrieb: > Wenig Sinnvoll einen 1A Regler hinter einen 100mA Transistor zu > schalten.
man Peter, komm mal wieder runter, hast du einen schlechten Tag oder was? Ich dachte, du machst Spass... Ich habe mir eben noch mal das PDF vom Bottom-Layer angeschaut und eben erst gesehen, das da noch der "Dummy-Layer" für das Display mit reingerutscht ist, also das falsche File gepostet. Da hätte ja mal Jemand sagen können, das da was nicht stimmt, dann hätte ich es korrigiert!!!
Michael D. schrieb: > Da hätte ja mal Jemand sagen können, das da was nicht stimmt, dann hätte > ich es korrigiert!!! Genau das habe ich getan.
Super, auch mein Tester läuft prima und das mit einer einfachen Lochrasterplatine im Standardgehäuse. Herzlichen Dank an Karl-Heinz. Trotzdem wäre ich noch für Ratschläge zu 2 Problemen dankbar. 1. Wenn ich die Spannung einschalte ist die LED dunkel. Nach Drücken des Tasters geht die LED an. So weit OK. Das Problem ist aber, daß sie nicht mehr ausgeht. Das gleiche Verhalten zeigt sich auch schon ohne Microcontroller. Ich gehe mal davon aus, es ist einer der 3 Transistoren, aber welcher und warum? 2. Ich schaffe es nicht, mit AVRStudio 6 das EEPROM zu brennen. Der Flash funktioniert. Beim EEPROM kommt jedesmal eine Fehlermeldung, daß er einen bestimmten Speicherplatz erwartet, aber einen anderen gefunden hat.Die genaue Fehlermeldung habe ich im Moment nicht vorliegen, da ich mit Ponyprog erfolgreich war. Damit allerdings nur wenn die Fuses im Originalzustand sind. Fuses programmieren kann ich wiederum nur anschließend mit dem Studio. Wahrscheinlich liegt das daran, daß mein ATMega168A bei Ponyprog nicht enthalten ist. Natürlich gehe ich an den funktionierenden Controller nicht mehr dran und bei meinem Reservecontroller scheine ich bei der Testerei mit Ponyprog die Fuses so verstellt zu haben, daß er normal nicht mehr ansprechbar ist.
Bruno M. schrieb: > Super, auch mein Tester läuft prima und das mit einer einfachen > Lochrasterplatine im Standardgehäuse. Kannst du bitte dein Layout posten? Ich habe auch vor mir den Tester auf Lochraster aufzubauen und vllt. ist dein Layout ja besser als meins? Danke Christian
Christian F. schrieb: > Kannst du bitte dein Layout posten? > Ich habe auch vor mir den Tester auf Lochraster aufzubauen und vllt. ist > dein Layout ja besser als meins? > Gerne, aber es wird noch etwas dauern, da ich bei der praktischen Umsetzung vom Ursprungskonzept doch etwas abgewichen bin. Muß ich also neu zeichnen, was ich aber sowieso vorhatte.
So, mein Controller läuft wieder. Alle Low-Fuses waren auf 0 gestellt! Ein erneuter Programmierversuch gab wieder die gleiche Fehlermeldung beim verify:
1 | Verifying EEPROM...Failed! address=0x0000 expected=0x01 actual=0x4f |
Ich habe mir dann mal angesehen, was er programmiert hat und im Vergleich dazu die Ursprungsdatei(siehe Anlage). Hat jemand eine Erklärung??
Was für einen Programmer benutzt du denn? und lies mal hier: Beitrag "Re: Transistortester AVR" alles erprobt u. funktioniert! Gruß Michael @Peter bei dir weiß man nie, ob du gerade Spass machst oder es ernst meinst... Mit der Schreiberei ist das immer so eine Sache, manches kann falsch rüber kommen, wenn du weißt, was ich meine?!? Gruß Michael
Bruno M. schrieb: > Ein erneuter Programmierversuch gab wieder die gleiche Fehlermeldung > beim verify: > Verifying EEPROM...Failed! address=0x0000 expected=0x01 actual=0x4f Hallo Bruno, wenn Du Dir diesen Thread ganz am Anfang durchliest oder auch das Vorwort bei meiner PDF-Doku, wirst Du sehen, daß genau dieses Problem der Grund war, warum ich überhaupt mit dem Verändern der Software des Transistortesters angefangen hatte. Ich konnte mit meinem Diamex ALL-AVR Brenner nicht das EEprom eines ATmega8 beschreiben! Als Lösung hatte ich damals den Code so verändert, daß ich ohne EEprom auskomme. Diese Fähigkeit gibt es auch noch bei der aktuellen Software. Dazu muß in der Makefile die Zeile CFLAGS += -DUSE_EEPROM auskommentiert werden und natürlich neu kompiliert werden. Nachdem ich den selben Diamex Brenner unter Linux mit avrdude betreibe, habe ich dieses Problem nicht mehr. Ob avrdude unter Windows fehlerfrei läuft, weiß ich nicht genau. Es liegt also auf jeden Fall nicht an der Hardware oder den Prozessoren. Siehe auch Beitrag "Re: Transistortester AVR" ! Die wahrscheinlichste Ursache für die Erscheinung mit der nicht ausgehenden LED-Beleuchtung des LCDs ist eine Hochfrequenz-Schwingung vom PNP-Transistor. Ich würde die Basis-Emitter Strecke mit einem Kondensator von 1 nF bis etwa 10 nF abblocken. Grüße Karl-Heinz
Danke für die Infos! Da ich ja schon einen m168A erfolgreich programmiert habe, hake ich das Thema vorerst ab. Karl-Heinz Kübbeler schrieb: > Die wahrscheinlichste Ursache für die Erscheinung mit der nicht > ausgehenden LED-Beleuchtung des LCDs ist eine Hochfrequenz-Schwingung > vom PNP-Transistor. Ich würde die Basis-Emitter Strecke mit einem > Kondensator von 1 nF bis etwa 10 nF abblocken. Da habe ich mich offensichtlich nicht klar genug ausgedrückt. Ich meine nicht die LED des LCDs, sondern die Anzeige der Spannungsversorgung.
Bruno M. schrieb: > Da habe ich mich offensichtlich nicht klar genug ausgedrückt. Ich meine > nicht die LED des LCDs, sondern die Anzeige der Spannungsversorgung. Hallo Bruno, da der Fehler auch ohne ATmega auftritt, gehe ich davon aus, daß die Basis von T1 (BC547) irgendwie über einen Widerstand von VCC Strom bekommt. Ob das ein Isolationsproblem oder ein Verdrahtungsfehler (Lochraster) ist, kann ich nicht sagen. T1 ist der Transistor mit der LED am Kollektor. Bitte überprüfen! Wenn der Taster noch nicht gedrückt wurde, ist VCC 0V. Wenn einmal eingeschaltet wurde (Taster), bleibt die VCC für immer eingeschaltet wenn die T1 Basis von VCC Strom bekommt. Grüße Karl-Heinz
Karl-Heinz Kübbeler schrieb: > Ob das ein Isolationsproblem oder ein Verdrahtungsfehler (Lochraster) > ist, kann ich nicht sagen. T1 ist der Transistor mit der LED am > Kollektor. Problem gelöst! Eine Leiterbahn war nicht entsprechend durchgetrennt. Danke für die Hilfe. Gruß Bruno
Angehängte Dateien:
-
Platine.png
190 KB -
SANY0093.JPG
130 KB -
SANY0094.JPG
230 KB
Christian F. schrieb: > > Kannst du bitte dein Layout posten? > Ich habe auch vor mir den Tester auf Lochraster aufzubauen und vllt. ist > dein Layout ja besser als meins? > Anliegend das Layout und zwei Bilder. Gruß Bruno
Kann es sein, dass das hier eine Kopie des AVR Transistor-Testers / Komponenten-Testers ist, eventuell mit veränderter Firmware von den Chinesen? http://www.ebay.at/itm/NEWEST-AVR-Transistor-Tester-meter-NPN-PNP-MOSFET-diode-triac-resistor-capacitor-/180942061357?pt=LH_DefaultDomain_0&hash=item2a20fcbf2d#ht_17438wt_1165
Das ist er ! Es war mir von Anfang an klar, das er bald dort zu finden sein würde...
Geänderte Firmware? Ha, ha, wenn man Resistor so falsch schreibt, wie auf dem Display zu sehen ist, dann ist mind. eine weitere Revision fällig!
Moin, das ist ja wohl wirklich eine Frechheit. Da machen sich Leute hier im Forum sehr viel Mühe und investieren ihr Freizeit in ein Projekt und dann kommt jemand und schlägt Kapital daraus. Ich habe mir die Auktion angeschaut und auch gleich den Shop dieses Händlers besucht. Mir scheint, da wurden auch noch andere Projekte von privaten Elektronikseiten und Ideen aus Foren einfach geklaut und nachgebaut. Wollen wir doch nur hoffen, dass diese Kopie bei weitem schlechter ist als die momentane Version von unseren Machern hier im Forum. Dann bleibt wenigstens bei denen, die sich diesen billigen Chinaschrott gekauft haben die Erinnerung, dass es mal wieder eine Fehlinvestition war. Grüße Michael
Assemblino schrieb: > Ebay-Artikel Nr. 180942061357 "Angebot ist beendet, da Artikel nicht mehr verfügbar" Vorhin stand da noch "10 verfügbar" Komisch
hallo, die Firmware für den AVR-Transistortester kann man ja da runterladen: -> http://frickelpower.bplaced.net/ctest/index.php?pglang=de Wenn man die runterlädt bekommt man die Version vom Dezember 2010. gibt es eine aktuellere Version auf der Basis des Atmega8? Gruss
Bastler schrieb: > gibt es eine aktuellere Version auf der Basis des Atmega8? Hallo, ja, die Eigenschaften der weiterentwickelten Version sind unter der Adresse http://www.mikrocontroller.net/articles/AVR_Transistortester kurz beschrieben. Die letzten Softwareversionen sowie die PDF-Dokumentationen sind im dort angegebenen svn Archiv zu finden. Es gibt drei Unterverzeichnisse mit Programm-Daten: atmega8_selftest ATmega8 Version mit Selbsttest atmega8_auto ATmega8 Version mit Autoscale ADC Funktion, ohne Selbsttest default ATmega168 Version mit allen Funktionen Grüße Karl-Heinz
Angehängte Dateien:
-
MBR-Dual-Diode-01.jpg
130 KB -
MBR-Dual-Diode-02.jpg
140 KB -
MBR-Dual-Diode-03.jpg
150 KB
Hallo Karl-Heinz, ich glaube, da ist in der SW ein kleiner Bug?!? Es werden keine Dual-Dioden erkannt, statt dessen wird ein Widerstandswert ausgegeben, der jetzt nicht so hilfreich ist. Anbei mal ein paar Pics. Gemessen wurde mit der 2 verschiedenen Comptestern mit der Mega8 Bestückung und deiner aktuellen SW. Ich meine, diese Rectifiers schon früher mal gemessen zu haben, allerdings mit der alten Software und "Diese" als richtig erkannt wurden. Kann das mal Jemand prüfen? Gruß Michael
Na ja, zumindest bei den dualen Dioden, wo die Pinbelegung ersichtlich ist, wäre das hinnehmbar, oder? Wundern tät´s mich nur dann, wenn ein hfe-Wert etc. angezeigt würde! :D
>Na ja, zumindest bei den dualen Dioden, wo die Pinbelegung ersichtlich >ist, wäre das hinnehmbar, oder? Noe, in der Originalversion von Markus funktioniert es doch. Aber mal eine Frage am Rande. Was genau ist an dieser Version denn nun "besser" ? Aus dem Wiki ist nicht viel ersichtlich, da steht im Prinzip das gleiche drin wie im Wiki von Markus und den Thread mag ich jetzt auch nicht mehr komplett lesen. Vielleicht kann mich mal jemand ueberzeugen, warum ich mir eine neue Platine machen sollte.
Das mit den Dualdioden habe ich gerade auch probiert. Bei mir tritt das nur bei Dioden mit einer Durchlassspannung von <0,47V auf und , ich habe nur welche mit gemeinsamer Kathode, wenn die Kathode in der Mitte, also 2 ist. Lege ich die Kathode auf die Seite, 1 oder 3, wird richtig angezeigt.
@ Peter W Keiner soll dich überzeugen! Warum auch? Das "alte" Layout/Platine tut es Ja. Der Gedanke war nur eine einfache Platine für ALLE zu erstellen. Ich habe mit vielen hier im Forum an dem Layout mitgearbeitet (12%) und heraus kam eine wirklich schöne und einfach zu bestückende...! Ergo: brauchts du nicht aber viele sind dankbar für die Mühe, die einige geleistet haben. Lg Dirk PS: Ich habe immer noch Anfragen, z.B aus Ungarn, Ö-Reich, CZ uva.
Es ging mir weniger um die Platine als um die Software. Was genau ist daran nun besser ? Ich meine dieser Thread ist ja nun Ellenlang, dass muss ja irgendeinen Grund haben. Und es wird ja noch immer an der Software gebastelt. Was kann die denn nun besser als die Originale von Markus, ausser das sie zusaetzlich seltsame Zeichen im Display zeigt ?
Sehr hilfreiche Antwort, da waere ich ohne Deinen Kommentar nicht drauf gekommen. Danke.
Peter W. schrieb: > Ich meine dieser Thread ist ja nun Ellenlang, dass muss ja irgendeinen > Grund haben. Ist das so schwer zu erkennen? Das große Interesse am Tester und einige, vermutlich trollgesteuerte, Anfragen bestimmen die Threadlänge! ;-)
Peter W. schrieb: > Es ging mir weniger um die Platine als um die Software. Was genau ist > daran nun besser ? Der Meßbereich für Kondensatoren ist auf derzeit 25pF bis 40mF erweitert. Widerstände werden einigermaßen genau von ca. 1 Ohm bis etwa 50 MOhm gemessen (Auflösung der Anzeige 0,1 Ohm). Der Verstärkungsfaktor von Darlington-Transistoren wird bis über 65000 gemessen. Die Kapazität von Dioden in Sperrichtung wird automatisch bestimmt. Am besten liest man aufmerksam die PDF-Doku im SVN-Archiv um den Aufwand bei der Softwareentwicklung abschätzen zu können! Das WIKI http://www.mikrocontroller.net/articles/AVR_Transistortester ist bewußt kurz gehalten, die Meßverfahren sind in deutsch und englisch im PDF dokumentiert! Sogar ein Vergleich der Meßergebnisse zwischen alter Version und der neuen ist graphisch dargestellt. Grüße Karl-Heinz
Karl-Heinz Kübbeler schrieb: > Der Meßbereich für Kondensatoren ist auf derzeit 25pF bis 40mF > erweitert. > Widerstände werden einigermaßen genau von ca. 1 Ohm bis etwa 50 MOhm > gemessen (Auflösung der Anzeige 0,1 Ohm). > Der Verstärkungsfaktor von Darlington-Transistoren wird bis über 65000 > gemessen. > Die Kapazität von Dioden in Sperrichtung wird automatisch bestimmt. Genau das wollte ich wissen, vielen Dank. Eine "Messbereichsterweiterung" oder "genauere" Messwerte brauche ich nicht, dass machen Messgeraete besser. Ich dachte dieser "Bauteiletester" hat neue Komponenten bekommen, dass waere ein Grund gewesen zu aktualisieren.
zum Beispiel: 1. Die seltsamen Zeichen--> Symbole, sparen Speicherplatz im µC! 2. Die Genauigkeit ist um Einiges verbessert worden, durch den externen Takt (Quarz) 3. Die Widerstandsmessung geht bis unter 1 Ohm 4. Kapazitätsmessung geht jetzt ab ca. 35pF bis ... ..wahrscheinlich geht noch mehr, ausser der BUG, den ich ja weiter oben beschrieben habe. Die Platine hat sich, bis auf kleine Erweiterungen, die für die Funktion im Moment unbedeutend sind, kaum verändert. die SW funktioniert auch mit der alten Version! Das alte Layout ist bis auf Kleinigkeiten, wie Quarz und dessen C's, ebenfalls nachrüstbar. Siehe hier: Beitrag "Re: Transistortester AVR" Der 100nF am AREF-Pin, sollte noch gegen einen 1nF getauscht werden. Die externe Referenz ist ein Future, das in der Soft noch nicht implementiert ist, ob der Anton da was gemacht hat, weiß ich im Moment nicht. UART ist noch möglich... Gruß Michael
oh, Karl-Heinz war schneller :-( Hallo Karl-Heinz, Das hier gelesen? Beitrag "Re: Transistortester AVR" Gruß Michael
Michael D. schrieb: > Hallo Karl-Heinz, > ich glaube, da ist in der SW ein kleiner Bug?!? > Es werden keine Dual-Dioden erkannt, statt dessen wird ein > Widerstandswert ausgegeben, der jetzt nicht so hilfreich ist. Hallo Michael, es werden schon auch Dual-Dioden erkannt. Wenn ich z.B. einen Brückengleichrichter prüfe, habe ich im Prinzip auch eine Dual-Diode, wenn ich die beiden Wechselspannungseingänge anschließe. Trotzdem muß ja irgend etwas schief gehen. Wird dann eine einzelne Diode der Dualdiode erkannt? Wenn ja, welche Parameter werden gemessen? Ist der Kapazitätswert in Sperr-Richtung vielleicht besonders hoch? Grüße Karl-Heinz
Moin, langsam runterfahren! Es ist ein BAUTEILETESTER und nicht ein MESSGERÄT! Was bisher von vielen, und besonders von K.H. ermöglicht wurde ist doch einmalig. Da ja auch die Chinies das Teil nachbauen!!! Bitte Ruhe. Es klappt alles. Dirk
Dirk Willner schrieb: > Es ist ein BAUTEILETESTER und nicht ein MESSGERÄT! Eben und das scheinen hier viele nicht zu begreifen, wie z.B. >2. Die Genauigkeit ist um Einiges verbessert worden, durch den externen >Takt (Quarz) >3. Die Widerstandsmessung geht bis unter 1 Ohm Wenn ich allein schon Genauigkeit lese.... Und logisch bauen die das nach, Du siehst doch das es weg geht wie warme Semmeln. Ich an Markus Stelle haette da laengst den Daumen drauf gedrueckt.
Ob Markus, Asko, K.H., Ich, alle die mitgwirkt haben.. Einen Gebrauch-Muster-Schutz oder Patent ist teuer... Es ist ein GUI-Projekt. Das soll es auch bleiben. Was möglich ist, nur die Software von K.H zu schützen, das ist Geistiges Eigentum. Mehr geht nach Recht nicht. Dirk
Hallo Michael, > es werden schon auch Dual-Dioden erkannt. Wenn ich z.B. einen > Brückengleichrichter prüfe, habe ich im Prinzip auch eine Dual-Diode, > wenn ich die beiden Wechselspannungseingänge anschließe. > Trotzdem muß ja irgend etwas schief gehen. Ja, und was, eine Idee? > Wird dann eine einzelne Diode der Dualdiode erkannt? Ja, wird. > Wenn ja, welche Parameter werden gemessen? > Ist der Kapazitätswert in Sperr-Richtung vielleicht besonders hoch? Nein, die Kapazität beträgt 0pF und manchmal 7pF. Bei der MBR20100CT wird z.B. 485mV / 0pF angezeigt, wenn ich nur eine Anode u. Kathode in die Probpins stecke. Gruß Michael
Michael D. schrieb: > Nein, die Kapazität beträgt 0pF und manchmal 7pF. > > Bei der MBR20100CT wird z.B. 485mV / 0pF angezeigt, wenn ich nur eine > Anode u. Kathode in die Probpins stecke. Hallo Michael, leider habe ich derzeit noch keine Idee. Aus dem Springen der Kapazitätsanzeige von 0 auf 7 pF lese ich, daß Du den Tester noch bei 1 MHz Takt betreibst. Das Wechseln auf 8 MHz ist durch Umprogrammieren der fuses möglich, dafür braucht es keinen Quarz! Da ich keine Schottky Dualdioden vorrätig habe, kann ich den Effekt leider nicht selber testen. Das muß ich leider aufschieben. Ich werde das in die Fehlerliste aufnehmen. Grüße Karl-Heinz
Hallo Karl-Heinz, Der Mega8 taktet mit externen Takt die Anzeige springt nicht von 0 auf 7pF. Das passiert nur, wenn ich die Diode umstecke. Benutze ich den linken u. mittigen Pin, werden 0pF angezeigt, auch wenn ich das Bauteil herum drehe, was ja auch ok so ist. Messe ich mitte Pin u. rechten Pin, werden 7pF angezeigt, egal wie rum ich den Probanten drehe. Also entweder habe ich was kapazives am rechten Probpin, was ich bezweifle, da ich die Leiterbahnseite mit Lack überzogen habe oder der Mega8 hat am Messpin ein internes Problem!?! Bei Gelegenheit werde ich den M8 mal austauschen, mal sehen, wie sich das dann verhält. Ich konnte endlich einen Lieferanten für den Mega328 ausfindig machen und habe mal gleich einen Sack voll bestellt, müsste nächste Woche eintreffen. Werde den dann auch mal in den Sockel stecken und testen, werde dann berichten. Hattest du diesen schon getestet? Gruß Michael
Michael D. schrieb: > Ich konnte endlich einen Lieferanten für den Mega328 ausfindig machen > und habe mal gleich einen Sack voll bestellt, müsste nächste Woche > eintreffen. > Werde den dann auch mal in den Sockel stecken und testen, werde dann > berichten. Hattest du diesen schon getestet? Hallo Michael, den Mega328 hatte ich auch mal getestet, er verhält sich ähnlich wie der ATmega168. Intensiver beschäftigt habe ich mich mit den mega168, mega168A und den mega168PA Prozessoren. Jeweils drei Exemplare habe ich auf die Unterschiede bei der Kondensatormessung untersucht. Bei allen drei Reihen sind Unterschiede bei der Messung kleinerer Kondensatoren (< 40 µF) festzustellen. Der Nulloffset der Kapazitätsmessung ist mit der Vorversion der 0.99k im trunk Zweig des svn Archivs http://www.mikrocontroller.net/svnbrowser/transistortester/Software/trunk/ im Selbsttest-Zweig abzugleichen. Allerdings wird derzeit nur ein Mittelwert aller drei Pin-Kombinationen berücksichtigt. Ich hatte bei einer Kombination eine Abweichung von 2 pF, die ich in der Software zusätzlich ausgleiche. Vielleicht muß man die Nulloffsets doch für die einzelnen Pin-Kombination berücksichtigen. Allerdings ist der Platz im EEprom schon knapp. Man kann zwar Texte aus dem EEprom in den Flash Speicher verschieben, dann wird es aber für den ATmega8 im Flash Speicher eng. In der letzten Version hatte ich für den ATmega168 auch eine Korrekturkomponente für die Kondensatormessung eingebaut, die von der Anstiegsgeschwindigkeit der Spannung abhängig ist. Hier muß ich noch untersuchen, ob dieses Verhalten für den ATmega328P gleich ist. Näheres zu den durchgeführten Meßreihen kann man in der PDF-Doku (im trunk Zweig) nachlesen inklusive der graphischen Darstellung der Meßfehler. Grüße Karl-Heinz
Peter W. schrieb: > Eine "Messbereichsterweiterung" oder "genauere" Messwerte brauche ich > nicht, dass machen Messgeraete besser. Hallo Peter, leider kann ich es mir nicht verkneifen, Dich doch mal zu fragen, wie Du mit Deinen Meßgeräten die Gatekapazität eines MOSFETS oder die Kapazität einer Diode in Sperr-Richtung misst. Hast Du das schon mal versucht? Hast Du schon mal versucht einen Kondensator mit mehr als 20 mF zu messen, oder einen Widerstand mit mehr als 20 MOhm ? Ich bin nach wie vor selbst begeistert von der Leistungsfähigkeit des TransistorTesters. Aber wenn einer nicht will, habe ich auch nicht vor, den zu überzeugen! Grüße Karl-Heinz
Dirk Willner schrieb: > Einen Gebrauch-Muster-Schutz oder Patent ist teuer... Wer hat denn davon geredet das Ganze in irgendeiner Form zu schützen? Auch wenn ich auf die Schnelle keine expliziten Lizenerklärungen finden konnte, war doch der Grundgedanke des Projekts - so behaupte ich jetzt einfach mal - die "freie" Entwicklung. Wie kommst du also auf diesen Dampfer? Dirk Willner schrieb: > Es ist ein GUI-Projekt. Und wofür steht GUI hier? Die gängige Abkürzung für "Graphical User Interface" ergibt in diesem Zusammenhang keinen Sinn. Eine andere ist mir in diesem Kontext nicht bekannt und konnte ich auch nicht finden. Dirk Willner schrieb: > Was möglich ist, nur die Software von K.H zu schützen, das ist Geistiges > Eigentum. Vielleicht reagiere ich ja beim Begriff "Geistiges Eigentum" ein wenig zu allergisch, aber was genau gibt es denn hier schützenswertes? Gerade aus Sicht von Karl-Heinz, der ja im Wesentlichen "nur" die Software von Markus Frejek pflegt. Damit möchte ich keineswegs Karl-Heinz bzw. seine geleistete Arbeit abwerten. Ganz im Gegenteil: Karl-Heinz leistet hier großartige Arbeit und das bleibt hoffentlich in absehbarer Zeit auch so ;). Aber jeden Firlefanz als "geistiges Eigentum" zu bezeichnen, halte ich für problematisch und mitunter als einen Grund für die vielen Patent- und Rechtsstreite in der Branche, die niemand anderem Schaden als uns - dem Verbraucher.
Karl-Heinz Kübbeler schrieb: > Ich bin nach wie vor selbst begeistert von der Leistungsfähigkeit des > TransistorTesters. > Aber wenn einer nicht will, habe ich auch nicht vor, den zu überzeugen! > Entspann Dich. Die meisten finden das Projekt und die Arbeit hier super. Das ist ja auch schon an den vielen Rückmeldungen zu erkennen. Mit so wenig Hardwareaufwand so viel erreichen. Dazu kommen noch die vielen stillen Mitleser und Nachabauer. Leider ist es in dem Forum hier üblich, dass man kein Thema aufmachen kann ohne dass spätestens mit dem 3. Beitrag einer meckert. Aber so ist das eben, in der Pubertät ... Herzlichen Dank und viele Grüße
Angehängte Dateien:
-
Tester_001k.jpg
220 KB -
Tester_002k.jpg
220 KB -
Tester_003k.jpg
210 KB
Das mit dem Meckern ist so ein Problem. Mir ist etwas durch Zufall aufgefallen. Ein Poti angesteckt, Schleifer in der Mitte. In einer bestimmten Schleiferstellung ist in der Anzeige Pin 1 und 2 vertauscht. Mich stört das nicht sonderlich aber vielleicht kann Karl-Heinz was damit anfangen.
Hubert G. schrieb: > Mir ist etwas durch Zufall aufgefallen. > Ein Poti angesteckt, Schleifer in der Mitte. In einer bestimmten > Schleiferstellung ist in der Anzeige Pin 1 und 2 vertauscht. Hallo Hubert, es kann durchaus vorkommen, daß in der Nähe der Endstellung mal etwas vertauscht wird. Bei der Widerstandsmessung werden separat drei Widerstände gemessen: Pin 1:2, Pin 2:3 und Pin 1:3 . Für die Anzeige muß der größte weggelassen werden. Das sollte für Dein Beispiel immer die Kombination 1:3 sein. Wenn aber in Deinem Beispiel die 2:3 als größter Widerstand gemessen wird, kommt es zu dem Tester_01k Beispiel. Zur Kontrolle könntest Du in diesem Fehlerfall einfach den Pin 1 lösen und den dann angezeigten Widerstandswert mit dem im Fehlerfall angezeigten 1:3 Widerstand vergleichen. Wenn der 2:3 Widerstand größer oder gleich ist, ist der Fehler erklärt. Abhilfe ist nur möglich, wenn die Meßfehler weiter minimiert werden. Man sieht an der Summe der beiden angezeigten Widerstände, daß die Messung nicht ganz stabil ist. Eigentlich sollte die Summe in allen Beispielen den gleichen Wert ergeben. Bisher wird in der Software der Innenwiderstand der Port-Ausgänge nur als Mittelwert für alle Ports berücksichtigt. Wenn man die Innenwiderstände für die Port-Ausgänge einzeln berücksichtigen wollte, kann man das Programm nicht mehr auf einem ATmega8 laufen lassen. Solch einen Beitrag im Thread betrachte ich nicht als Meckern. Ich bin nach wie vor an Fehlerbeschreibungen und Auffälligkeiten bei der Benutzung der Tester-Software interessiert. Ich kann beim besten Willen nicht alles testen. Ich bin also auf das Melden von Problemfällen angewiesen. Grüße Karl-Heinz
Karl-Heinz Kübbeler schrieb: > Wenn man die > Innenwiderstände für die Port-Ausgänge einzeln berücksichtigen wollte, > kann man das Programm nicht mehr auf einem ATmega8 laufen lassen. Könnte man das nicht trotzdem als Option einführen? Entweder so:
1 | #ifdef __ATMEGA8__
|
2 | #define bla DURCHSCHNITT
|
3 | #elif __ATMEGA168__
|
4 | #define bla1 xx
|
5 | #define bla2 yy
|
6 | #endif
|
Oder vllt. auch wenn mehr als 8kB vorhanden sind. (Das wird doch auch in einem Define mitgeliefert?)
Angehängte Dateien:
-
Atmega328p-01.png
93 KB
Hallo Karl-Heinz, > In der letzten Version hatte ich für den ATmega168 auch eine > Korrekturkomponente für die Kondensatormessung eingebaut, die von der > Anstiegsgeschwindigkeit der Spannung abhängig ist. Hier muß ich noch > untersuchen, ob dieses Verhalten für den ATmega328P gleich ist. Dieselbe Korrektur ist doch auch für den Mega8 vorhanden?!? Ich habe diese schon in Anspruch genommen und im Makefile editiert, oder sehe ich das falsch? Jetzt habe ich allerdings noch ein anderes Problem: Es lassen sich mit deinem Makefile alle µC kompilieren ausser der Mega328. Nach einer kleinen Suche im Makefile habe ich einen kleinen Fehler entdeckt. Da wird der m328p ohne "p" initialisiert und das Studio pöpelt, das es die MCU nicht kennt: ----------------------------------- ifeq ($(PARTNO),m328p) MCU = atmega328p ----------------------------------- Das "p" habe ich mal ergänzt, jetzt wird der Prozessor zwar erkannt aber irgendwie scheint es hier Probleme mit den lcd-routines zu geben. Könntest du das fixen? Ich habe da mal keinen Plan... Anbei mal ein Pic von der Fehlermeldung. Es dreht sich hier immer um deine letzte SW-Version! Gruß Michael
Christian F. schrieb: > Könnte man das nicht trotzdem als Option einführen? > Entweder so:#ifdef __ATMEGA8__ > #define bla DURCHSCHNITT > #elif __ATMEGA168__ > #define bla1 xx > #define bla2 yy > #endif Hallo Christian, die Schwierigkeit besteht darin die individuellen Port-Widerstände zu bestimmen. Es müssen für 3 C-Ports und für 3 B-Ports jeweils die Schaltwiderstände nach VCC und GND bestimmt werden. Das sind 12 Widerstandwerte! Dazu kommt auch noch das Problem, daß nur die C-Port Widerstände so einigermaßen genau bestimmt werden können, wenn man annimmt, daß die B-Port Werte wohl gleich sind. Es ist ja das Ziel, daß der ATmega die notwendigen Messungen selbst macht. Inwieweit der jeweilige Widerstandswert auch noch stromabhängig ist, ist auch nicht bekannt. Im übrigen bestimmt die letzte trunk Version den Innenwiderstand per Makefile Option AUTO_CAL als Teil der Selbsttest-Routine schon selbst, allerdings nur die Mittelwerte zur VCC und zur GND Seite hin. Dafür fehlen dem ATmega8 allerdings mindestens 400 Bytes flash. Grüße Karl-Heinz
Hallo, wenn der ATmega 8 mit seinen 8K an die Grenzen stößt, wäre es nach meiner Meinung an der Zeit, ihn mit einer letzten stabilen Version einzufrieren und mit dem ATmega 168 (A) weiterzumachen. Beim 168'er war bei der Version 098K im Flash mit 58% noch genug Platz für Ergänzungen. Was ist die mehrheitliche Meinung dazu? Karl-Anton
Karl-Anton D. schrieb: > Was ist die mehrheitliche Meinung dazu? Von meiner Seite aus gibt es da keine Einwände. Aber da werden sich sicherlich genug andere finden, die damit nicht zufrieden sein werden ;).
Karl-Heinz Kübbeler schrieb: > Im übrigen bestimmt die letzte trunk Version den Innenwiderstand per > Makefile Option AUTO_CAL als Teil der Selbsttest-Routine schon selbst, > allerdings nur die Mittelwerte zur VCC und zur GND Seite hin. > Dafür fehlen dem ATmega8 allerdings mindestens 400 Bytes flash. Ahhh. Ich dachte die müsste man selbst irgendwie messen und eintragen. Was spräche dagegen es beim Mega8 so zu machen wie bisher und bei den größeren eben "richtig"?
Michael D. schrieb: > Nach einer kleinen Suche im Makefile habe ich einen kleinen Fehler > entdeckt. Da wird der m328p ohne "p" initialisiert und das Studio > pöpelt, das es die MCU nicht kennt: > ----------------------------------- > ifeq ($(PARTNO),m328p) > MCU = atmega328p Hallo Michael, das war so beabsichtigt in der Makefile. Der Code ist unabhängig von der PicoPower Version (-P), die sich soweit ich weiß nur durch Flags BODS und BODSE unterscheiden, die hier in der Software nicht benutzt werden. Die Unterscheidung in der Makefile war nur wegen der unterschiedlichen Prozessor-ID notwändig. Ein einfaches Unterscheiden der -P Varianten in der Software (config.h) würde den Quellcode aufblähen und damit die Wartung erschweren. Vielleicht finde ich ja noch eine akzeptable Lösung. Die Linux-Umgebung hatte mit der bisherigen Lösung jedenfalls keine Probleme. Grüße Karl-Heinz
Michael D. schrieb: > Das "p" habe ich mal ergänzt, jetzt wird der Prozessor zwar erkannt aber > irgendwie scheint es hier Probleme mit den lcd-routines zu geben. Hallo Michael, die vertretbare Lösung ist gefunden! die letzte Softwareänderung im trunc svn Archiv enthält die notwändigen Änderungen, damit die Picopower Versionen (-P) richtig in der Makefile gesetzt werden können. Das betrifft nicht nur den ATmega328P sondern auch die anderen Mitglieder der Processor-Familie also auch den ATmega168P ! Grüße Karl-Heinz
Angehängte Dateien:
-
Atmega328p-02.png
62 KB
Das aufblähen ist natürlich nicht so vorteilhaft. Dummerweise kennt mein Studio4.19 keinen atmega328 sondern nur den "p" wie auf dem Pic zu sehen ist! Es werden da alle "Known" AVR-Typen aufgelistet, ausser der m328, sehr komisch Vielleicht weiß Jemand abhilfe ? Gruß Michael EDIT: Die letzte Sofwareänderung war am 09.06.2012 ! Hast du da zwischenzeitlich was geändert u. ich hab's nicht mitbekommen? Aber trotzdem hätte ich gerne den m328. Das kann doch nicht sein, das da die Pico-Variante vorhanden ist und die normale Ausführung nicht?
jetzt habe ich die aktuelle Soft aus dem Trunk runtergeladen und wieder ins Studio gepackt. Die m328p Variante ist im Makefile korrigiert (von dir?), beim kompilieren habe ich dieselben 7 Errors wie vorher, siehe hier: Beitrag "Re: Transistortester AVR" da stimmt was mit den lcd-routines nicht. Ich bekomme gleich nen Anfall :-( ich geh' jetzt mal auf die Suche nach dem m328 ohne "p" für's Studio, muß ja irgendwo zu finden sein... EDIT: Bei deiner Versionsvergabe blicke ich jetzt nicht mehr durch. Könntest du die irgendwo noch in deiner Software unterbringen? Vielleicht im Makefile, wäre eine Idee!?! Gruß Michael
Michael D. schrieb: > Die m328p Variante ist im Makefile korrigiert > (von dir?), beim kompilieren habe ich dieselben 7 Errors wie vorher, Ausversehen war in der config.h das P klein geschrieben, deswegen funktionierte es nicht! Entschuldigung Karl-Heinz
Michael D. schrieb: > Aber trotzdem hätte ich gerne den m328. Das kann doch nicht sein, das da > die Pico-Variante vorhanden ist und die normale Ausführung nicht? Hallo Michael, in der Transistortester Software kann man natürlich auch einen ATmega328 (PARTNO = m328) wählen, wenn man einen ATmega328P-PU besitzt, muß man in der Makefile aber PARTNO = m328p wählen. Ich weiß nicht, ob es überhaupt eine andere Version des mega328 im DIP-28S Gehäuse tatsächlich gibt. Definiert im Handbuch ist zwar auch ein ATmega328, ich habe aber derzeit noch keinen in die Hände bekommen. Was das AVR-Studio macht, weiß ich leider nicht. Unter Linux bekomme ich einen ATmega328 übersetzt, ob ich die Daten mit avrdude auch in einen ATmega328 geladen bekomme, konnte ich nicht testen. Grüße Karl-Heinz
Michael D. schrieb: > EDIT: > Bei deiner Versionsvergabe blicke ich jetzt nicht mehr durch. > Könntest du die irgendwo noch in deiner Software unterbringen? > Vielleicht im Makefile, wäre eine Idee!?! der trunk Zweig ist eigentlich die Entwickler-Variante. Hier lade ich wichtige Entwicklungsschritte hoch. Ich bemühe mich, die Doku und die Software einigermaßen konsistent zu halten, das ist aber hier nicht in allen Fällen möglich. Dafür sind die Testserien zu zeitaufwändig. Wenn man stabile Verhältnisse mit Versionsnummern haben möchte, muß man auf ein neues tag Release warten. Wenn ich daran denke, trage ich die Änderungen in die changelog.txt im tag Verzeichnis ein. Grüße Karl-Heinz
Angehängte Dateien:
-
Atmega328-03.png
94 KB -
Atmega328-04.png
35 KB
mit deinem Makefile klappt ja alles im AV-Studio4.19 soweit. Ich darf hier garnicht erzählen, was ich jetzt alles angestellt habe... Jedenfalls, was für die Anderen hier, die mit dem Studio arbeiten evtl. hilfreich wäre ist der Pfad verschiedener Toolchains! Ich habe natürlich ettliche hier auf der Platte :-( Angeben war die gcc.exe u.make.exe von WinAvr20090313, die eigendlich immer zuverlässig ihren Dienst getan hatte, nur nicht hier. Jetzt habe ich mal die originale Toolchain in den Pfaden angegeben und bekomme den Mega328 "endlich" kompiliert. Anbei 2 Pics, wie das aussieht. Unter "Project Options" und dem Button "Custom Options" wird der Pfad der externen Toolchain angegeben, also gcc.exe, make.exe. Ich denke mal, wenn meine Lieferung eingetroffen ist, das es Mega328(Dip28) ohne "p" sind, ich lass mich mal überraschen und werde dann berichten. Der bestellte Typ ist von einem deutschen Lieferanten und ist um einges günstiger als der Mega168, nur mal so am Rande... Gruß Michael
Super und Danke. Wann kommt der XMega? (:-))) Spass beiseite. Ich hatte auch Probs. zu proggen. Mega8 klappt und der Mega168 wollte nicht. Aber die letzten 2 male klappte es. Frag mich nicht warum. Dirk
Michael D. schrieb: > Der bestellte Typ ist von einem deutschen Lieferanten und ist um einges > günstiger als der Mega168, nur mal so am Rande... Hallo Michael, gerade habe ich auch die ATmega328 ohne P entdeckt, und mir mal ein paar bestellt. Die Warnungen beim Übersetzten wegen dem const uint16_t * habe ich bei mir auch, der Update des EEproms für die Autokalibration funktioniert aber trotzdem. Der Abgleich läuft beim Selbsttest automatisch, wenn man ab Test 7 nicht mehr mit dem Start-Taster vorzeitig die Wiederholungen abbricht. Es sollte im Test 9 (Kapazitäts-Nullwert) die Testeinrichtung so sein, wie später Kondensatoren gemessen werden sollen. Wenn die Versionsnummer ausgegeben wird, kann noch der 50 Hz Generator laufen (am Ende der Zeile 1 wird 50 Hz angezeigt). Der 50 Hz Generator läuft 1 Minute, wenn er nicht durch längeres Drücken des Start-Tasters abgebrochen wird. Der 50 Hz Generator ist aber jetzt auch per Makefile-Option abwählbar. Grüße Karl-Heinz
Angehängte Dateien:
-
Atmega328p-05.png
75 KB
> Hallo Michael, > gerade habe ich auch die ATmega328 ohne P entdeckt, und mir mal ein paar > bestellt. Jawoll, dann können wir(natürlich du) den ja ohne Bedenken vollstopfen! ;-) Der Haupt-u.EEprom-Speicher ist ja 4x größer als beim Mega8, da geht was... > Die Warnungen beim Übersetzten wegen dem const uint16_t * habe ich bei > mir auch, der Update des EEproms für die Autokalibration funktioniert > aber trotzdem. Der Abgleich läuft beim Selbsttest automatisch, wenn man > ab Test 7 nicht mehr mit dem Start-Taster vorzeitig die Wiederholungen > abbricht. Da bin ich ja beruhigt, das auch bei dir die Warnings auftauchen! Allerdings wird die "p" Variante auf keinen Fall kompiliert, egal welche Toolchain (gcc, make) ich einsetze, habe da jetzt alles durch. Jetzt wird nicht mehr an den "lcd-routines" gemeckert sondern "ReadCapacity" (4 Errors) Ich glaube, das liegt jetzt an der Software? > Es sollte im Test 9 (Kapazitäts-Nullwert) die Testeinrichtung so sein, > wie später Kondensatoren gemessen werden sollen. > Wenn die Versionsnummer ausgegeben wird, kann noch der 50 Hz Generator > laufen (am Ende der Zeile 1 wird 50 Hz angezeigt). > Der 50 Hz Generator läuft 1 Minute, wenn er nicht durch längeres Drücken > des Start-Tasters abgebrochen wird. > Der 50 Hz Generator ist aber jetzt auch per Makefile-Option abwählbar. Für was läuft der denn??? Ist der für die Messungen relevant? Und noch mal ein Pic von der Fehlermeldung mit "p" Gruß Michael
Michael D. schrieb: > Jetzt wird nicht mehr an den "lcd-routines" gemeckert sondern > "ReadCapacity" (4 Errors) > Ich glaube, das liegt jetzt an der Software? Hallo Michael, kann ich nicht glauben, ich habe im Anhang den trunk Zweig mit konfiguriertem m328p beigepackt. Die Korrektur Beitrag "Re: Transistortester AVR" hattest Du hoffentlich mitbekommen. Der Fehler würde dann entstehen, wenn in der config.h die Prozessor abhängigen Zuweisungen nicht richtig gemacht werden. Michael D. schrieb: >> Der 50 Hz Generator ist aber jetzt auch per Makefile-Option abwählbar. > Für was läuft der denn??? Ist der für die Messungen relevant? Der 50 Hz Generator ist nur zur Überprüfung dee Verzögerungszeiten des ATmega mit einem Zähler oder Oszilloskop. Hier können die Warteschleifen und der Frequenzgenerator (Quarz oder RC) überprüft werden. Zeitfehler beeinflussen die Kondensatormessung. Wenn man sowieso keine Möglichkeit hat nachzumessen, kann man den Generator per Option weglassen. Grüße Karl-Heinz
Karl-Heinz Kübbeler schrieb: > Solch einen Beitrag im Thread betrachte ich nicht als Meckern. Ich bin > nach wie vor an Fehlerbeschreibungen und Auffälligkeiten bei der > Benutzung der Tester-Software interessiert. Ich kann beim besten Willen > nicht alles testen. Ich bin also auf das Melden von Problemfällen > angewiesen. Wenn es für das Verhalten mit einem Poti eine logische Erklärung gibt, dann ist das OK. Deine Erklärung könnte auch die Lösung für das Fehlverhalten bei Duo-Schottkydioden sein. Diese haben einen gewissen Leckstrom und werden auf Grund dessen als Poti interpretiert. Duodioden ohne messbaren Leckstrom werden einwandfrei angezeigt. Das Gerät wird von mir als "Tester" benutzt, den ich auf keinen Fall missen möchte. Aber es wird jedes Ergebnis kritisch betrachtet und falls unklar mit Gegenmessungen bestätigt. Danke für deine großartige Arbeit. MfG Hubert
Angehängte Dateien:
-
Atmega328p-06.png
95 KB
Moin Karl-Heinz, > Hallo Michael, > kann ich nicht glauben, ich habe im Anhang den trunk Zweig mit > konfiguriertem m328p beigepackt. Die Korrektur > Beitrag "Re: Transistortester AVR" hattest Du > hoffentlich mitbekommen. Der Fehler würde dann entstehen, wenn in der > config.h die Prozessor abhängigen Zuweisungen nicht richtig gemacht > werden. hm, natürlich nicht! Jetzt weiß ich's aber... ich konnte es natürlich nicht lassen und habe gleich mal das Makefile für den m328p ausgetauscht und siehe da, das "p" Model wird kompiliert! Jetzt ist alles hübsch. Siehe Pic! @Hubert > Deine Erklärung könnte auch die Lösung für das Fehlverhalten bei > Duo-Schottkydioden sein. Diese haben einen gewissen Leckstrom und werden > auf Grund dessen als Poti interpretiert. Duodioden ohne messbaren > Leckstrom werden einwandfrei angezeigt. Dem kann ich nur zustimmen! Andere Duo-Dioden, also "Nicht-Shottky" werden einwandfrei auch als solche erkannt. Gruß Michael
So, Mega328 ist soeben eingetroffen! Es sind, wie erwartet, Exemplare ohne "p". Einen habe ich gleich ausgepackt und geflasht! Fuses gesetzt auf LF=FC u. HF=D9. Extendet u. Lock sind auf 0xFF geblieben. Erster Test hat soweit funtionert. Da habe ich doch gleich mal die Shottky-Dual eingesetzt, selbes Verhalten wie beim Mega8! Manchmal schlägt die Initialisierung vom Display fehl(obere Reihe Balken sichtbar), könnte sein, das da noch ein Delay rein muß? Als nächstes wird manchmal statt 14pF oder 0pF eben 14nF oder 0nF angezeigt, was beim Mega8 nie der Fall ist. Gruß Michael
Hallo Karl-Heinz, Ich wollte den Transistortester mit einem ATmega8 nachbauen, jedoch habe ich beim Durchforsten des Threads den Überblick verloren. Könntest Du bitte den neuesten Schaltplan und die neuesten Programmdateien posten? Vielen Dank im Voraus Gruß olli
ab dem 31.07.2012 gibt's gleich 2 Schaltpläne und Layout. Software ist gerade mal 4 Posts über dir! Man trägt noch den M8 in's Makefile ein, editiert den Rest weg, der nicht rein passt (ist alles im Makefile dokumentiert) und dann sollte es laufen. Gruß Michael
olli schrieb: > Hallo Karl-Heinz, > > Ich wollte den Transistortester mit einem ATmega8 nachbauen, > jedoch habe ich beim Durchforsten des Threads den Überblick > verloren. Könntest Du bitte den neuesten Schaltplan und die > neuesten Programmdateien posten? > Hallo Olli, die letzte Software gibt es jetzt immer im svn Archiv (Subversion), das Wiki http://www.mikrocontroller.net/articles/AVR_Transistortester gibt die Informationen dazu. Der trunk Zweig ist immer der letzte Entwicklungsstand, der zwar die allerletzten Verbesserungsversuche enthält, aber auch eher Fehler enthalten kann. Der tags Zweig enthält gepackte Dateien für eine herausgegebene Version. Zugriff auf den gesamten Pfad (Doku und Software) ist unter Linux mit "svn checkout svn://www.mikrocontroller.net/transistortester" zu erreichen. Unter Windows gibt es für den Zugriff ein Plugin für den Firefox Browser mit der Bezeichnung "Tortoise SVN", den ich mal probeweise vom Heise Server installiert hatte. Für den ATmega8 gibt es derzeit immer zwei Unterverzeichnisse (mega8_auto und mega8_selftest) die zwei Varianten für den ATmega8 als Makefile und fertige Programmierdaten enthalten. Wenn man eine lauffähige Entwicklungsumgebung besitzt, kann man in der jeweiligen Makefile seine Änderungen vornehmen, oder auch ein weiteres Unterverzeichnis mit einer veränderten Makefile anlegen. Den kommentierten aktuellen Schaltplan findet man in der PDF-Dokumentation. Empfohlen wird allerdings nicht mehr der ATmega8 sondern der ATmega168 oder auch der ATmega328! Grüße Karl-Heinz
Hallo Karl-Heinz, hab mir jetzt die .pdf-Datei runtergeladen, ist gut erklärt und versteht sogar einer wie ich, der sich noch nicht so gut mit dem Ganzen auskennt. Hab leider nur den ATmega8 da und wollte es dann gerade mit dem µC machen. Gibt es da eigentlich Einschränkungen? Gruß olli
olli schrieb: > Hab leider nur den ATmega8 da und wollte es > dann gerade mit dem µC machen. > Gibt es da eigentlich Einschränkungen? Leider ja, es sind nicht mehr alle Funktionen gleichzeitig in den Flash-Speicher zu bekommen. Dies ist der Grund für die beiden Versionen mega8_auto und mega8_selftest. Die mega8_auto benutzt die AUTOSCALE_ADC Funktion, kann aber nicht mehr gleichzeitig die Selbsttest-Routine benutzen. Im letzten Entwicklerzweig trunk ist zu der Selbsttest-Routine eine wählbare Kalibrierfunktion dazugekommen. Hier wird der Innenwiderstand der Port-Ausgänge bestimmt und für spätere Messungen im EEprom festgehalten. Das gleiche gilt auch für den Nullwert bei der Kondensatormessung. Ohne diesen Abgleich sind nur Schätzwerte in der Software berücksichtigt. Derzeit kann die Kalibrierfunktion wegen Speichermangel aber nicht für den ATmega8 gewählt werden. Ein ATmega168 oder auch ein ATmega328 ist auch wegen Vorteilen bei der AUTOSCALE_ADC Funktion die bessere Wahl. Nebenbei bemerkt sind ja auch noch weitere Verbesserungen geplant. Grüße Karl-Heinz
hello Mr. Karl-Heinz and all. Request the addition of a function I know that distinction of Dorain and Source is impossible for Junction-FET(JFET). If possible, please add the measurement function of Idss. Idss is the current from Dorain to Source, which short-circuited Gate with Source. I think that since measurement voltage of Transistor Tester is low, so only small FET is measurable. But Isdd is a good parameter which gets to know the characteristic of small JFET. And, Idss of small JFET is well used as a constant current device. Thank you for your consideration.
Nobuyuki Nagashima schrieb: > Request the addition of a function > > I know that distinction of Dorain and Source is impossible for > Junction-FET(JFET). If possible, please add the measurement function of > Idss. Hallo Friends of the TransistorTester, Hallo Nobuyuki Nagashima, the new Version 0.99k is ready on the svn archive, but this requested function is only in the "to do" list. This request was too late for this release. The major new function of this release is the AUTO_CAL option for the selftest section. AUTO_CAL eliminates the zero offset for capacity measurement and with a external capacitor connected to pin 1 and pin 3 the offset voltage of the analog comparator can be respected. The measurement results to more stable capacity measurement results (up to 40 µF) to the variance of the ATmega exemplars. Detailed tests are added to the PDF documentation in the section capacity measurement. Regards Karl-Heinz
Hallo Karl-Heinz, jetzt wollte ich mal deine neue Soft(099k) testen, da bekomme ich bei der Auswahl des Mega328, wieder die Fehlermeldung: "Device does not have EEPROM available." Wo soll denn das EEPROM ausgeschaltet sein? Habe da nichts gefunden... Beim "Mega328p" fast dasselbe Problem, nur das hier ausserdem wieder die "lcd-routines.o" als error ausgegeben werden! :-((( Im Log habe ich gelesen, das die Soft 16MHz-Aussentakt unterstützt. Ich nehme mal an, das du das schon getestet hast? Bleiben die Messungen stabil und lohnt es sich den Quarz zu tauschen? Im Log steht nichts vom nF/ pF Anzeigeproblem, welches ich weiter oben angegeben hatte, hast du es vergessen zu fixen? Gruß Michael
Ich noch mal... > jetzt wollte ich mal deine neue Soft(099k) testen, da bekomme ich bei > der Auswahl des Mega328, wieder die Fehlermeldung: > "Device does not have EEPROM available." > Wo soll denn das EEPROM ausgeschaltet sein? Habe da nichts gefunden... > Beim "Mega328p" fast dasselbe Problem, nur das hier ausserdem wieder > die "lcd-routines.o" als error ausgegeben werden! :-((( Vergess' das!!! Mein Studio4.19 hat mal wieder rumgezickt und wollte partou nicht auf die angegebene, aktuelle "Toolchain" greifen! Jetzt bin ich mal kurz mit dem Hammer dran ;-) Gruß Michael achso, das Duodioden-Problem besteht noch?
Michael D. schrieb: > Hallo Karl-Heinz, > jetzt wollte ich mal deine neue Soft(099k) testen, da bekomme ich bei > der Auswahl des Mega328, wieder die Fehlermeldung: > > "Device does not have EEPROM available." > Wo soll denn das EEPROM ausgeschaltet sein? Habe da nichts gefunden... > > Beim "Mega328p" fast dasselbe Problem, nur das hier ausserdem wieder > die "lcd-routines.o" als error ausgegeben werden! :-((( > Hallo Michael, leider gebe ich keine Unterstützung für die Verwendung vom AVR-Studio. Ich empfehle Linux oder cycwin (bildet linux shell unter Windows ab). Die Oberfläche macht nur zusätzliche Probleme! > Im Log habe ich gelesen, das die Soft 16MHz-Aussentakt unterstützt. Ich > nehme mal an, das du das schon getestet hast? Bleiben die Messungen > stabil und lohnt es sich den Quarz zu tauschen? Ja, das habe ich getestet. Es funktioniert, ich habe aber keine Vorteile bemerkt. Die internen Berechnungen dürften schneller werden. Ansonsten spielt es keine Rolle ob der Prozessor schneller oder langsamer auf das Ende der ADC-Lesung oder auf den Ablauf einer 10ms Wartezeit wartet. Der Geschwindigkeitsvorteil ist so gering, daß er unbemerkt bleibt. Die Auflösungs-Verbesserung bei der Kondensatormessung scheitert an der pF Darstellung. Ich glaube auch, daß das Meßverfahren keine Dezimalstelle mehr hergibt. Da war ich eher daran interessiert, die Meßabweichungen von mehr als 5% von einem Atmega Exemplar zu nächsten zu beseitigen (AUTO_CAL Option). Die Versuche, den ADC schneller zu takten (250 kHz statt 125 kHz) haben ergeben, daß die Genauigkeit wie im Handbuch abgegeben leidet. > > Im Log steht nichts vom nF/ pF Anzeigeproblem, welches ich weiter oben > angegeben hatte, hast du es vergessen zu fixen? > > Der Fehler ist bei mir bei weit über 500 Kondensatormessungen für die PDF-Diagramme in der Doku nie aufgefallen. Wenn Du auch Probleme bei der Initialisierung des LCD hast, könnte das Problem auch an der Anbindung des LCD Liegen. Michael D. schrieb: > achso, das Duodioden-Problem besteht noch? Ich gehe auch davon aus, daß diese Duodioden ein Reststrom Problem haben und sich deshalb nicht messen lassen. Wieviele Exemplare hattest Du getestet? Ich habe inzwischen keine neue Materialbestellung unternommen, habe also noch keine 20A Doppeldioden zum testen. Das Nachprüfen kann auch zum Ergebnis haben, daß diese Leistungsdioden nicht in allen Fällen getestet werden können. Auch für viele Tyristoren oder Triacs reicht der verfügbare Meßstrom von ungefähr 6 mA nicht. Grüße Karl-Heinz
Hallo Karl-Heinz, > Der Fehler ist bei mir bei weit über 500 Kondensatormessungen für die > PDF-Diagramme in der Doku nie aufgefallen. Bei der reinen Kondensatormessung tritt dieser Fehler nicht auf! Nur bei den besagten Duo-Shottky-Dioden. > Wenn Du auch > Probleme bei der Initialisierung des LCD hast, könnte das Problem > auch an der Anbindung des LCD Liegen. Ab u. zu tritt dieser Effekt tatsächlich auf, aber nur beim Mega328! Beim Mega8/88 ist das noch nie vorgekommen. Es tritt auch nur bei den Duo-Leistungsdioden auf, quasi nach der Messung, aber auch nicht immer. > Ich gehe auch davon aus, daß diese Duodioden ein Reststrom Problem haben > und sich deshalb nicht messen lassen. Wieviele Exemplare hattest Du > getestet? Ich habe inzwischen keine neue Materialbestellung unternommen, > habe also noch keine 20A Doppeldioden zum testen. Ich habe ettliche getestet, die meisten sind aus ausgeschlachteten SNT's hier ein Teil der gestesten Exemplare Duo-Shottky: Beitrag "Re: Transistortester AVR" und hier das beschriebene Problem pF / nf: Beitrag "Re: Transistortester AVR" Gruß Michael EDIT: Eben habe ich einen MOS-FET 45N03LT getestet, da wird eine Kapazität von 2168pF gemessen, das scheint mir ein bißchen viel?!? Ich habe darauf hin mal das Datenblatt consoltiert und angegeben sind Input-cap. 600pF und Output-cap. 290pF Gruß Michael
Michael D. schrieb: > EDIT: Eben habe ich einen MOS-FET 45N03LT getestet, da wird eine > Kapazität von 2168pF gemessen, das scheint mir ein bißchen viel?!? > Ich habe darauf hin mal das Datenblatt consoltiert und angegeben sind > Input-cap. 600pF und Output-cap. 290pF Hallo Michael, das Datenblatt von Philips für den 45N03LT zeigt in Abbildung 11 den Kapazitätsverlauf über die VDS Spannung. Bei Spannung nahe 0V ergibt sich ein Ciss von etwa 1500pF. Da ist doch der Transistortester gar nicht so weit weg. Der mißt ja die Gesamtkapazität ohne VDS Spannung. Da die Kapazität hier spannungsabhängig ist, kann man nie so präzise Werte erwarten wie bei richtigen Kondensatoren. Wie wäre es, wenn Du mir von Deinen Duo-Dioden ein oder zwei zum Testen zur Verfügung stellst? Du kannst Dich ja mal per eMail melden. Karl-Heinz
So, heute mal ein wenig sonne getankt, das Wetter war ja genial... Hallo Karl-Heinz, > das Datenblatt von Philips für den 45N03LT zeigt in Abbildung 11 den > Kapazitätsverlauf über die VDS Spannung. > Bei Spannung nahe 0V ergibt sich ein Ciss von etwa 1500pF. > Da ist doch der Transistortester gar nicht so weit weg. Ok, ich hatte es auch nur mal fix überflogen. :-( > Der mißt ja die Gesamtkapazität ohne VDS Spannung. Das wollte ich wissen ;-) > Da die Kapazität hier spannungsabhängig ist, kann man nie > so präzise Werte erwarten wie bei richtigen Kondensatoren. Das sehe ich ein. > Wie wäre es, wenn Du mir von Deinen Duo-Dioden ein oder > zwei zum Testen zur Verfügung stellst? > Du kannst Dich ja mal per eMail melden. Selbstverständlich, kannst du von mir haben. Die bestehenden sind fast alle verplant. In der nächstan Zeit erwarte ich wieder ein paar SNT's zum schlachten, da lege ich ein paar für dich zurück. Woran liegt das denn, das beim Mega328 manchmal das Display nicht richtig initialisiert wird? Gruß Michael
Michael D. schrieb: > Woran liegt das denn, das beim Mega328 manchmal das Display nicht > richtig initialisiert wird? Hallo Michael, das habe ich selbst bisher nicht beobachten können. Ich habe sowohl Mega328 als auch Mega328P mit jeweils 3 Exemplaren gestestet, allerdings meistens mit meinem blauen 4x20 LCD. Ich werde bei Gelegenheit noch mal mit einem grünen 2x16 LCD testen. Mal sehen, ob ich dann etwas feststellen kann. Es wäre hilfreich, wenn Du Dein verwendetes LCD beschreibst. Grüße Karl-Heinz
Hallo Karl-Heinz, ich habe mehrere Exemplare von 2x16 mit u. ohne LED-Bel. Displaytech 162D(Reichelt), HJ1602A(LED), alle HD44780 kompatibel. Bei beiden trat das Initialisierungsproblem auf! Jetzt hatte ich aber glatt die extendet Fuses beim Mega328 vergessen zu setzen, stand auf 0xFF. Diese sind ja für den Brown-out zuständig. Ich habe die jetzt mal auf "enabled" gesetzt, also 0xFC (brown-out 4,3V). Komischerweise treten jetzt keine Ini-Probleme am Display auf, wie kann das sein? Was hat der Brown-out mit der Initialisierung des Display's zutun? Gruß Michael
Michael D. schrieb: > Hallo Karl-Heinz, > ich habe mehrere Exemplare von 2x16 mit u. ohne LED-Bel. > Displaytech 162D(Reichelt), HJ1602A(LED), alle HD44780 kompatibel. > Bei beiden trat das Initialisierungsproblem auf! > > Jetzt hatte ich aber glatt die extendet Fuses beim Mega328 vergessen zu > setzen, stand auf 0xFF. Diese sind ja für den Brown-out zuständig. > Ich habe die jetzt mal auf "enabled" gesetzt, also 0xFC (brown-out > 4,3V). > Komischerweise treten jetzt keine Ini-Probleme am Display auf, wie kann > das sein? Was hat der Brown-out mit der Initialisierung des Display's > zutun? > Hallo Michael, jetzt wird der Fehler doch klarer. Normalerweise hat der ATmega eine Start-Verzögerungszeit von 65 ms. Ohne den "Brown out" level startet der ATmega aber schon bei unter 2V. Der Display-Controller ist für einen Spannungsbereich von 4,5V bis 5V ausgelegt. Der Display-Controller braucht aber selbst auch eine Initialisierungszeit von 10 ms nach Überschreiten der 4,5V. Wenn jetzt die VCC Spannung langsam steigt, hat der ATmega seine Verzögerungszeit schon abgearbeitet bevor die 4,5V (+10ms) überschritten sind und versucht schon Befehle an den LCD-Controller abzusetzen, wenn dieser noch nicht bereit ist. Hast Du bei Deiner Hardware zusätzliche Elkos in der VCC Versorgung? Ich selbst habe nur die 100nF Kondensatoren bestückt, wahrscheinlich deshalb tritt der Fehler bei mir nicht auf. Das Setzen des Brown out levels auf 4,3 V vermeidet den Fehler, weil hierdurch der ATmega bis zum Überschreiten der "Brown out" Spannung auf Reset festgehalten wird. Grüße Karl-Heinz
eieiei, > Hast Du bei Deiner Hardware zusätzliche Elkos in der VCC Versorgung? > Ich selbst habe nur die 100nF Kondensatoren bestückt, wahrscheinlich > deshalb tritt der Fehler bei mir nicht auf. Und ja, ich habe 220µF an den Ausgang kleben müssen, da mein LDO(LM2940) geschwungen hat wie ein FG und das konnte der µC nicht kompensieren! Nur so konnte ich vorerst das Schwingen unterdrücken. Jetzt ist aber auch klar, das der Elko den Ausgang des LDO emens belastet. Wahrscheinlich wäre ein LC oder RC-Filter die bessere Wahl gewesen. Vielleicht setze ich das noch um, mal schauen welche Frequenz da ihr unwesen treibt! LDO's neigen sowieso dazu zu schwingen. > Das Setzen des Brown out levels auf 4,3 V vermeidet den Fehler, weil > hierdurch der ATmega bis zum Überschreiten der "Brown out" Spannung auf > Reset festgehalten wird. Oha, da kann man mal sehen, was das bewirkt. Ich wußte garnicht, das auf diese Weise eine Verzögerung eintritt und der Reset um diese bestehen bleibt. Ich hatte diese Fuseeinstellung völlig falsch interpretiert, jetzt bin ich um Einiges schlauer, danke für den Hinweis! Gruß Michael EDIT: Jetzt würde mich aber auch interessieren, wie das Schwingverhalten von anderen LDO's in der Comptesterschaltung ist. Hat das mal Jemand gemessen und würde das mal preis geben?
Michael D. schrieb: > EDIT: Jetzt würde mich aber auch interessieren, wie das Schwingverhalten > von anderen LDO's in der Comptesterschaltung ist. Hat das mal Jemand > gemessen und würde das mal preis geben? Hallo Michael, mit dem MCP 1702-5002 Regler und den 100nF Kondensatoren sehe ich eine Einschwingzeit von etwa 1,5 ms bis zur stabilen 5V. Ein Überschwingen oder Schwingneigung ist nicht erkennbar. Verwendete Platine: DG2BRS V5.2.1 Grüße Karl-Heinz
Hi Karl, It can you add an option to the makefile in order to include the eeprom data on the .hex file ? What i mean is to provide an option to chenage this line: HEX_FLASH_FLAGS = -R .eeprom -R .fuse -R .lock -R .signature as this : HEX_FLASH_FLAGS = --change-section-lma .eeprom=0x2000 -R .fuse -R .lock -R .signature for atmega8 HEX_FLASH_FLAGS = --change-section-lma .eeprom=0x4000 -R .fuse -R .lock -R .signature for atmega168 and HEX_FLASH_FLAGS = --change-section-lma .eeprom=0x8000 -R .fuse -R .lock -R .signature for atmega328 if not an option a commented line ready to uncomment would be great... tnks
Hallo Karl-Heinz, ich habe den Komponententester soweit erfolgreich aufgebaut und zwar zuerst mit einem ATMEGA 8 und gestern mit einem ATMEGA 168 (Platine V 5.2.3). Alle Bauteilewerte habe ich nach deiner Doku V.99 angepasst. In dem heruntergelöadenen Ordner V.99 sind ja die beiden Dateien TransistorTester.hex sowie TransistorTester.eep enthalten. Diese sind ja für den ATMEGA 168 schon vorbereitet? Sind dort nun alle Funktionen enthalten oder muss ich unbedingt mit AVR Studio und AVR Dude noch Einstellungen und Veränderungen vornehmen? Unnötige Schritte wollte ich mir sparen, da ich hier zum Programmieren / Brennen nur ein bescheidenes Equipment habe. schönen Sonntag Michael
Michael Klein schrieb: > Sind dort nun alle Funktionen > enthalten oder muss ich unbedingt mit AVR Studio und AVR Dude noch > Einstellungen und Veränderungen vornehmen? Unnötige Schritte wollte ich > mir sparen, da ich hier zum Programmieren / Brennen nur ein bescheidenes > Equipment habe. Hallo Michael, die .hex Datei im default Ordner ist für den flash Speicher eines ATmega168 konfiguriert, entsprechend die .eep für den EEprom Speicher. Die Fuses müssen aber noch gesetzt werden, da die vorkonfigurierten Dateien für 8 MHz Betrieb übersetzt sind und die ATmega für 1 MHz Betrieb ausgeliefert werden. Wenn ein 8 MHz Quarz bestückt ist, sollte natürlich auch der Quarz-Betrieb eingestellt werden. Die Hex Werte für die Fuses sind für den ATmega168: lfuse=0xf7, hfuse=0xdc und efuse=0xf9 (full swing crystal) oder lfuse=0xff für low power crystal Betrieb. Für die Kalibration sollte einmal der Selbsttest durchlaufen. Selbsttest Nummer 10, 11 erfordert einen Kondensator (kein Elko) 100nF < C < 10µF. Grüße Karl-Heinz
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.