Hallo Ich würde gerne mal wissen an was ihr so stundenlang mal rumgesucht habt. Mein ärgerlichster Fehler war, als ich tagelang rumgesuchte habe, wegen einer Löt-Brücke, die ich übersehen hatte und die ganze Zeit dachte ich hatte das schon überprüft, bis ich zufällig darauf stieß.
Bei mir ein Fehler der sicher vielen schon passiert ist: = statt == Sehr ärgerlich aber fällt oft nicht auf.
och, da gibts so einiges... - in Matlab einen liegenden, statt einen stehenden Vektor produziert - mit 1 statt mit 0 angefangen zu zählen - Stiftleiste defekt: auf Platinen verwende ich oftmals die "Lüfterstecker" (Reichelt: pss 245...), da war mal einer der Drahtstifte unterbrochen. Ich mein, was soll an so nem Dingens, wo maximal 100mA drübergehen, schon kaputt sein. Hab in einem Akt der Verzweiflung nach 2 Tagen Fehlersuche mal den Stecker durchgepiepst -> kaputt - Lötzinnreste unter einem IC haben mal zwei Vias gebrückt - einiges mehr noch
Fehler an einem µC-Board gibt es allermeistens in der Software. Dann sucht man gelegentlich stundenlang. Das muß man sich immer gut vor Augen halten. Elektronik, Halbleiter, sind nur seltenst defekt. Da muß man kaum suchen. Üble Lötbrücken in selbst geätzten Platinen hatte ich auch schon. Da machte der ADC-Port eines µC seltsame Ergebnisse. Z.B. Spannungen von 1/2 UB.
Ob's nun der ärgerlichste war, vermag ich nicht zu sagen, aber zumindest war er sehr ärgerlich. Platine mit einer LiIon-Schutzelektronik in Betrieb genommen. Analog-Frontend ist ein bq29311 von Benchmarq/TI, aber statt dem normalerweise benutzten bq2083 für den Digitalteil habe ich einen ATmega88 genommen, weil der bq2083 "smart battery protocol" zu einem Host (bspw. Notebook) reden will, während ich den Akkupack standalone betreiben möchte. Irgendwie ging alles nicht los, die I²C-Routine hängt sich auf. Getreu Wilhelm Ferkes' Motto sucht man natürlich zuerst den Fehler in der Software. Hoch und runter verglichen mit anderen I²C-Implementierungen, sieht alles OK aus. Also muss es die Hardware sein, irgendwas klemmt den I²C-Bus fest. Als nächstes die Platine (war selbst geätzt), Vias wieder ausgelötet, stückweise gemessen. Nach wie vor ein satter Schluss von einer der beiden Busleitungen nach Vcc (wenige Ω Widerstand). Am Ende war's der Controller. Der hatte durch irgendwas einen Schuss abbekommen. Zwar funktionierte alles noch, aber die Pad-Zelle am besagten I²C-Pin hatte einen Schaden genommen und einen niederohmigen Pfad nach Vcc entwickelt... Controller gewechselt — Firmware läuft.
Solche Sachen können Stunden kosten: 1: M=read('testdaten.txt',-1,-1) 2: k(1)=length(M(:,1);//was normal die x-Achse ist 34: while r ~= k(1) 85: function [a,b,c]=(d,e,f); 86: for i=1:k(1) ... 103: end 104: for j=1:k(1) ... 202: end 203: endfunction 460: [a,b,c]=(d,e,f); 461: end "error in 460: incompatible multiplication" (Der Fehler liegt aber in 104) ..irgendwann testdaten gegen testdaten1 ausgetauscht und nichts ging mehr - und nun suche den Fehler in einem 1000 Zeilen Skript..- vergessen das das Verfahren nur für quadratische Matritzen funktioniert nach j=1:k(2) ging es dann - Wenn man so programmiert das man die Zahlen nicht sieht sondern nur Variablen verwendet, fällt das lange nicht auf.
Den Zweck die Funktion mehrfach aufrufen zu können mit jeweils anderen Parametern ohne die Schleife immer wieder neu hinschreiben zu müssen - man übergibt einfach neue Parameter und ruft die Funktion erneut auf. (scilab ist eine objektorientierte intuitiv erlernbare Sprache - man muss fast nichts wissen, kann alles logisch ableiten) Ich hab früher sehr viel mit Maple gearbeitet - scilab ist einfacher und mächtiger.
Auch doof: Stundenlang mit Fuses und X verschiedenen Quarzen rumprobiert -> Xtal1 + Xtal2 über fast unsichtbaren Lötzinnfaden kurzgeschlossen
Oder dauernd das Programm verändert, Sachen bis auf eine leere Schleife auskommentiert, bis ich merke, dass ich die ganze Zeit das falsche Programm schreibe.
Samuel K. schrieb: > bis ich merke, dass ich die ganze Zeit das falsche > Programm schreibe. Oder beim Flashen von AVRs mittels AVRStudio das falsche Hexfile im Flash-Fenster angewählt, nicht bemerkt und mich gewundert, dass die (kleinen) Änderungen einfach nicht funktionieren wollen ...
Thilo M. schrieb: > Oder beim Flashen von AVRs mittels AVRStudio das falsche Hexfile im > Flash-Fenster angewählt, nicht bemerkt und mich gewundert, dass die > (kleinen) Änderungen einfach nicht funktionieren wollen ... Ja das meinte ich damit. Einfach nur verrückt.
K. Laus schrieb: > = statt == Darum vertauscht man, wenn man gegen Konstanten vergleicht, die Reihenfolge. Dann bekommt man einen Fehler, dass Zuweisung an Konstanten nicht zulässig ist. Das verhindert schon mal einen großen Teil dieser Schusselfehler.
Johannes S. schrieb: > Darum vertauscht man, wenn man gegen Konstanten vergleicht, die > Reihenfolge. Bei Vergleich zweier Variablen funktioniert das aber nicht. Du liest Wert1 und Wert2 ein und vergleichst beide. Da kann man tauschen soviel man will und es wird nichts. Und extra beide in Konstanten umwandeln lohnt sich auch nicht.
K. Laus schrieb: > Bei Vergleich zweier Variablen funktioniert das aber nicht. Deswegen schrieb ich "...einen großen Teil dieser [Fehler]". Man prüft sehr häufig gegen Konstanten. Dass es bei Variablenvergleichen freilich nix nutzt, ist klar. EDIT: konsequente Anwendung dieser Regel sensibilisiert auch, und wenn einem auffällt, dass man gerade nix vertauschen kann, dann fällt einem als Zweites auch ein, dass man peinlich auf das zweite "=" achten sollte. ;)
Johannes S. schrieb: > K. Laus schrieb: >> = statt == > > Darum vertauscht man, wenn man gegen Konstanten vergleicht, die > Reihenfolge. Liest sich bescheuert, ganz ehrlich, da das irgendwie nicht unserer natürlichen Denkweise entspricht. Mittlerweile sollte diesen Fehler auch der allerletzte Compiler ordentlich warnen können, dann braucht man derartige Verrenkungen nicht, sondern muss sich nur die Warnungen angucken. Seit die Compiler das beherrschen, haben mich Fehler dieser Art keine Zeit mehr gekostet. Fieser ist dann schon sowas:
1 | ...
|
2 | int i, j; |
3 | |
4 | ...
|
5 | for (i = 0; i < MAXROWS; i++) { |
6 | ...
|
7 | for (i = 0; i < MAXCOLUMNS; i++) { |
8 | ...
|
9 | dosomething(array[i][j]); |
10 | }
|
11 | }
|
Das zweite hätte natürlich "j" sein müssen. Solange man j gar nicht benutzt oder nicht initialisiert benutzt, kann der Compiler das noch warnen, aber irgendwann habe ich das auch schon geschafft, dass die Randbedingungen keine Warnung mehr gebracht haben. Ist auch ein Grund, warum ich dagegen bin, "aus Prinzip" lokale Variablen zu initialisieren:
1 | ...
|
2 | int i = 0, j = 0; |
Dann nimmt man dem Compiler komplett die Möglichkeit, obigen Fehler selbst im einfachen Fall (wie hier) zu entdecken.
Jörg Wunsch schrieb: > Liest sich bescheuert, ganz ehrlich, da das irgendwie nicht unserer > natürlichen Denkweise entspricht. Schön ist es in der Tat nicht, aber man kann sich daran gewöhnen. Wenn man dem Konstrukt wiederbegegnet, ist die verquere Reihenfolge ein Reiz, der den Genuß des Lesens so empfindlich stört, daß man sofort aufwacht...
Tagelang einen Fehler gesucht noch nicht. Aber immer wieder stolpere ich über die gleichen Dummheiten: Projekt liefert keine vernünftigen Daten weil die Versorgungsspannung nicht eingeschaltet ist. Das Scope zeigt keine brauchbaren Bilder, weil der Tastkopf nicht eingestöpselt ist. Die Daten folgen nicht meinem Drehen am Funktionsgenerator weil in Wirklichkeit ein anderer Sinusgenerator angeschlossen ist. Das Sau-teuere Keithley DMM liefert Messwerte die niemals stimmen können, tun sie auch nicht, da das Multimeter auf Relativmessung eingestellt ist. Das Lötzinn will nicht fließen weil der Lötkolben kalt ist ;-) usw. usf. Das kann dann schon mal 1-2 Stunden dauern bis mir das alles auffällt...
Ansbach Dragoner schrieb: > Das kann dann schon mal 1-2 Stunden dauern bis mir das alles auffällt... Einfach morgens 1-2 Stunden länger schlafen...
Uhu Uhuhu schrieb: > Einfach morgens 1-2 Stunden länger schlafen... Ich schlaf doch schon bis 9. Noch später wäre doch asozial, oder?
Dann ist wohl die Zeit von 5-9 doch etwas zu knapp. Füg halt einfach zwischendrin noch ein paar Stunden ein.
So richtig ärgerlich war mal eine kalte Lötstelle, die auch noch unter einem Display gut versteckt saß. Diese hatte folgende "Features": Nichtleitend bei: - Temperatur: +40 - +65°C (nur in genau diesem Fenster - reproduzierbar!) - Platine liegt auf Bestückungsseite - Platine steht hochkant Leitend bei allen anderen Umgebungsbedingungen, insbesondere: - Durchmessen mit Durchgangsprüfer - Platine liegt auf Lötseite - Kurzzeitig nach derben Flüchen Hat mich damals zwei Tage gekostet - seitdem wird genauestens inspiziert, gerade bei später verdeckten Lötpunkten. Manchmal ist der Weg zum Waaaaahnsinn nicht mehr weit ... Chris - Arghhhh! - D. ;-)
Einen Fehler den ich nie vergesen werde hatte ich am Anfang meiner Lötkarriere: Ich hatte so langsam Übung, und bekam richtig schöne Löstellen hin (für einen Anfänger ist das ja teilweise nicht so leicht...). Es machte auch Spaß, weil ich nicht mehr für jedes Bauteil Minuten brauchte, sondern zügig vorankam. Ich hatte gerade einen 40-Pol DIL-Sockel verlötet, und war begeistert, das alle Lötstellen völlig gleichmäßig waren, sah fast aus wie maschinell bestückt. Dann habe ich meine Platine umgedreht, mir die anderen Lötstellen der schon vorher bestückten Bauelemente angeschaut, wieder umgedreht, die Sockel-Lötstellen bewundert.... Plötzlich kam mir was komisch vor: wieso drehe ich eigentlich die Platine ständig hin und her...? Ihr könnts euch sicher schon denken: die 40 Lötstellen waren zwar wunderschön, aber leider auf der falschen Seite. Die 40 Pins wieder auslöten hat mehr Zeit gekostet, als die Bestückung der kompletten Platine.
Jens Plappert schrieb: > Der Klassiker zum immer wieder Ärgern ist die Tülle vom Stecker > vergessen. Ja das stimmt schön das ich da nicht allein bin :-)
kleine schaltung mit ATTiny aufgebaut und funzt nicht bin fast blöde gewurden moralm der Geschichte man sollte das Ding Programmieren dann gehts auch ;-)
Jens Plappert schrieb: > Der Klassiker zum immer wieder Ärgern ist die Tülle vom Stecker > vergessen. Ohja, da kann ich nur zustimmen! Richtig ärgerlich wenn man in ewiger Fummelarbeit die winzigen Litzen an einen Miniaturstecker pfrimelt, um dann festzustellen dass die Tülle fehlt...
LOL ich auch vorallem schaun ob die Lötspitze sauber ist oder ob der Lötkolben überhaupt an ist man man man
Anfang der 1990-er Jahre, baute ich mein erstes µC-Board aus einem Buch von Elektor nach. Hatte zwar vorher schon einige Eigenkonstruktionen, sogar bevor ich einen PC besaß. Die wurden mit selbst gebauten Hilfsschaltungen direkt in Maschinensprache byteweise programmiert. Aber dieses mal, sollte es was besseres werden, mit PC-Kommunikation über RS232. Den EMON52 kennt sicher der eine oder andere noch. Verwende ich sogar heute noch. Nach Aufbau, lief das Board. Allerdings nicht die RS232-Kommunikation. Statt dem erwarteten Text, erhielt ich immer nur Hieroglyphen auf dem Terminal. Ein Oszi besaß ich zu der Zeit noch nicht. Ich stocherte 3 Wochen im Dunkeln herum. Sandte auch das nach der Buchdiskette selbst gebrannte EPROM an Elektor ein. Und bekam es mit dem Vermerk "OK" vom Autor wieder zurück. Nun, später stellte ich fest, daß sie den µC gleich um den Faktor 2 übertakteten. Es stand auch an einer Stelle im Buch, aber ich nahm es nicht wahr. Die hatten eine merkwürdige Quarzschaltung. Zum Quarz war eine Festinduktivität parallel, die die Grundwelle des 12MHz-Quarzes unterdrücken soll, damit er auf 24MHz schwingt. Irgendwann lötete ich diese Induktivität aus, und dann klappte es. Inzwischen bekam ich auch ein Oszi. Lötete die Induktivität wieder ein, um heraus zu finden, was da wirklich war. Nun, das blöde Ding schwang da irgendwo bei 23,3MHz anstatt 24MHz. Klar, daß da nur Hieroglyphen am Terminal kommen. Ein Forum, so wie hier, hatte man mangels Internet damals auch nicht.
Mein Auto schüttelte sich im Standgas wie ein nasser Hund, so daß ich beim Ampelhalt Gas geben mußte wie ein Narr, damit die Kiste nicht aus- ging. Gab ich Gas, und die Motordrehzahl lag über 2000 U/min war alles in Ordnung. Ich nahm die Kerzen heraus und hielt sie gegen das Licht: alle 4 schön rehbraun und keine Fäden zwischen den Elektroden. Kopfkratz Wieder eingebaut: Gleicher Effekt. Nerven verloren-> Oszillographen geholt ->Stückchen Strippe um das Zündkabel gewickelt -> aha! Kein Zündfunken auf 2 Zylindern. Kerzen erneut ausgebaut und wie ich die eine mit den Elektroden nach unten halte, fällt die mittlere Elektrode auf den Bügel und schließt damit die Kerze kurz! Da bei mir im Auto sog. Doppelfunkenzündspulen eingebaut sind, die immer 2 Zylinder "bedienen", war bei der 2. auch kein Funken. Wenn die Kerze ein Diskus gewesen wäre, hätte ich damit bestimmt einen neuen Weitenrekord erzielt.... ;-) MfG Paul
Paul Baumann schrieb: >fällt die mittlere Elektrode auf den Bügel und schließt >damit die Kerze kurz! Das ist mir neu, daß die Elektroden rein zylinderförmig sind und auch noch lose in der Keramik stecken. Hätte intuitiv angenommen, daß die Elektrode auch leicht konisch ist. Wie der Keramikkörper. Bzw. beide Materialien fest verbunden wären. Interessant, wieder was gelernt! Nur, wie bricht die Elektrode so leicht in 2 Teile???
Wilhelm Ferkes schrieb: > Nur, wie bricht die Elektrode so leicht in 2 Teile??? Das Elektrodenmaterial ist was anderes, als das, aus dem die Kontaktschraube ist.
Meine Lieblingsfehler sind spiegelverkehrte Platinen oder einzelne Bauteile auf denselben. Wenn mir jemand das Lehrgeld zurückerstatten würde... ;)
Wilhelm Ferkes schrieb: > Nur, wie bricht die Elektrode so leicht in 2 Teile??? Gute Frage, hatte ich auch schon bei neuen Kerzen. Zwar nicht sichtbar, aber bei kaltem Motor und niedriger Drehzahl: 3 Töpfe, bei warmem Motor und höherer Drehzahl: 4 Töpfe. Da war auch die Elektrode in der Kerze gebrochen.
Mein persönlicher Favorit: Wollte in meinen Anfängen in C Binärdaten in eine Datei schreiben. Beim Lesen der Daten brach die Lesefunktion immer wieder mit Dateiende ab, bevor alle Bytes gelesen waren. Das Schlimme, der Abbruch erfolgte je nach Daten immer an unterschiedlichen Stellen. Irgendwann schaute ich mal die Datei an, und stellte fest, dass ein Byte mit Dezimalwert 26 vorausging. 26 markiert in Textdateien das Dateiende. Ursache des Verhaltens: ich hatte beim Lesen und Schreiben in die Datei nicht den Binärmodus bei fopen verwendet, sondern den Textmodus (bzw. den Standard, das war der Textmodus). Hat mich einen halben Tag gekostet. Zweiter Kracher: Zu meinen frühen GW-BASIC-Zeiten <in Erinnerungen schwelg> hatte ich mal eine einfache Adressverwaltung in wenigen Stunden am Stück runtergetippt. Dann habe ich eine einfache Passwortabfrage eingebaut. Bei falschem Passwort wurde GW-Basic beendet. Das Resultat dürfte klar sein: Passwort richtig eingegeben: alles OK, Adressverwaltung läuft. Zweiter Versuch: Passwort falsch eingeben - GW-BASIC wurde wie erwartet beendet -- und mein in Stunden geschriebenes, aber nicht gespeichertes Programm war futsch. Seitdem bin ich in Bezug auf Datensicherung _ein wenig_ vorsichtiger. Die Neueingabe ging allerdings relativ schnell, hatte ja vieles noch im Gedächtnis. Dritter Rohrkrepierer: Ich hatte mal ein Z80-System in Rackbauweise entwickelt. Ein erstes Testprogramm sollte ein Bit toggeln (weiß jetzt nicht mehr genau, wie ich mir das ausgedacht hatte). Jedenfalls: Oszi drangehängt -- nichts toggelte, aber andere Beobachtungen legten den Schluss nahe, dass das System wie gewünscht läuft. Nach stundenlangem Suchen hatte ich dann meinem Elektronik-Crack, bei dem ich in den Ferien und nach der Schule arbeitete, angerufen und ihm das Problem geschildert. Während des Telefonats machte es in meinem Gehirn klick: ich hatte das Signal nur einmal getoggelt. Da war natürlich kein Rechteck auf dem Oszi zu erkennen. Vierter Patzer: Eine meiner ersten Maschinen, die ich programmierte, besaß einen Servoantrieb. Dieser drehte ein Bauteil, in welches in einer bestimmten Position seitlich ein Zylinder einfahren konnte. Das bedeutete natürlich Crashgefahr: drehte sich der Antrieb, während der Zylinder ausgefahren war, musste etwas kapuut gehen. OK, also alles in Betrieb genommen, keinerlei Problem. Achse stand, Antrieb war in Regelung. Ich fuhr nun den Zylinder aus und lies ihn in dieser Position. Wollte schnell etwas anderes erledigen. Nach einigen Minuten gabe es in der Maschine seltsame Geräusche, die ich zuerst nicht lokalisieren konnte. Nach einigem Suchen war die Ursache der Geräusche ausgemacht: Der Servoantrieb hatte sich gedreht und dabei die Kolbenstange des Zylinders leicht verbogen. Der Antrieb hatte sich sehr langsam, kaum sichtbar, gedreht, und zwar durch Kontaktprobleme im Geberkreis. Durch die sehr langsame Bewegung hatte ich das Wegdriften jedoch nicht bemerkt. War bislang allerdings die einzige größere Sache. Danach war ich bei den Inbetriebnahmen noch erheblich vorsichtiger. Waren trotzdem wirklich tolle Zeiten damals(TM) um die Jahrtausendwende. ;-)
Uhu Uhuhu schrieb: >Das Elektrodenmaterial ist was anderes, als das, aus dem die >Kontaktschraube ist. Das ist mir schon klar. Da ist bei den relativ neueren Zündkerzen noch eine Widerstandsbahn zur Funkentstörung drin. Seit wenigstens 20 Jahren. Wie die technisch realisiert ist, weiß ich nicht. Habe noch keine solche Zündkerze zerlegt. Bei älteren Kerzen sind Elektrode und Kontaktschraube sehr wohl ein Stück gewesen. Solche, hatte ich schon zerlegt...
>Darum vertauscht man, wenn man gegen Konstanten vergleicht, die >Reihenfolge. Das mache ich nicht. Ich schalte stattdessen die entsprechenden Warnungen ein. Sowas wie if (5 >= i) finde ich irgend wie krank. Ich denke, da macht das Gehirn (meines zumindest) noch viel mehr Fehler. ;-)
Marcus Woletz schrieb: > Sowas wie if (5 >= i) Sowas macht man ja auch gar nicht. Wenn, dann: if (i < 5) ... Mit signed und unsigned Zahlen und Vergleichen kann man noch sehr viel Unfug machen. Der SDCC-Compiler übersetzte mir noch vor 3 Tagen den Vergleich mit einer Variablen unsigned, mit einer Konstanten hingegen signed. Hab nur 3 Minuten gesucht, weil schon was geahnt. Da muß man immer strikt type-casten. Sieht irre aus, kostet ja aber nichts.
Ein neues Bauteil, Datenblattn (AD7147), alles OK. Erst Bauteil zeichnen, Pin 1..24. Dann das QFN Gehäuse zeichnen. Dann Platine machen, fertigen, in Betrieb nehmen, Programmieren, geht nicht. Lange Suche. Ganz lange Suche. Wiso wird das neue Bauteil lauwarm??? Dafür hab ich sicher 2 Tage gebraucht. Verdammt, die Pin-Numerierung 1..24 war von UNTEN im Datenblatt. Und diese QFN-Gehäuse können nicht umgedreht gelötet werden. grrmbl. Neue Platine, neues Glück. Wer lesen tut ist klar im Vorteil.
Markus Müller schrieb: > Verdammt, die Pin-Numerierung 1..24 war von UNTEN im Datenblatt. Ist mir Anfangs mit den SDS-Relais auch so gegangen. Wie kann man auch die Pinbelegung oben auf das Gehäuse drucken, mit der Ansicht von unten auf die Pins? ;-)
Wilhelm Ferkes schrieb: > Marcus Woletz schrieb: > >> Sowas wie if (5 >= i) > > Sowas macht man ja auch gar nicht. Wenn, dann: if (i < 5) ... Dir ist natürlich bewusst, dass die beiden Ausdrücke nicht das gleiche bewirken. ;)
Hab mal ne hübsche zweiseitige Leiterplatte gemacht. Für 8 Signale (+ GND) habe ich D-Sub-Buchse 90° Printmontage an den Rand gesetzt. Der Kunde war zufrieden, alles läuft, aber für die Montage soll die Buchse etwas weiter zurück. Da kamm jemand auf die Idee, alles zu lassen aber eine andere (kürzere) Buchse einzusetzen. Es gibt die ja mit 10,3 und 8,08 mm Abstand Front zu erster Pinreihe. Gesagt/Gertan => sporadisch Fehler (beim Kunde). Die auf GND liegende Metallfront der Buchse kamm jetzt auf blanke Vias der Leiterplatte, nicht immer aber immer öfters. Aber mit Isolierfolie in der Fertigung behebbar. Nur die Suche war etwas langwierig, wer denkt bei einer etwas komplexeren Platine an so eine physikalische Ursache ;) Hans L
Michael Buesch schrieb: > Sowas wie if (5 >= i) Das wäre inverse Logik. Sowas ist aber nicht mehr notwendig: Wenn man das falsch macht: Warnung: Überflüssige Verwendung von = anstelle == Die Idee war mal gut, ist jetzt aber anachronistisch - braucht kein Mensch, also weg damit, wegen Durchfall im Weltall..
Juri, falsch zitiert? Ich habe das nie behauptet. Ich stimme dir voll zu, dass diese "inverse Schreibweise" völliger Bullshit ist, wenn man einen halbwegs modernen Compiler verwendet.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.