Hallo!
Ich vermute Software, kenne aber "Cäh" gar nicht.![]()
Hallo!
Ich vermute Software, kenne aber "Cäh" gar nicht.![]()
MfG (Mit feinem Grübeln) Wir unterstützen dich bei deinen Projekten, aber wir entwickeln sie nicht für dich. (radbruch) "Irgendwas" geht "irgendwie" immer...(Rabenauge) Machs - und berichte.(oberallgeier) Man weißt wie, aber nie warum. Gut zu wissen, was man nicht weiß. Zuerst messen, danach fragen. Was heute geht, wurde gestern gebastelt. http://www.youtube.com/watch?v=qOAnVO3y2u8 Danke!
Hast du kontrolliert ob der Ausgang auch als Ausgang programmiert sind.
Wenn du nur den PullUp ein und ausschaltest könnte es zu so einem Verhalten kommen.
Ja, hab ich kontrolliert. Auch die Platine wurde mehrfach geputzt und auf verbliebene Kurzschlussbrücken mit einer Lupe kontrolliert. Das Neckische daran ist, dass die Erscheinung a) zufällig und b) auch nach Wechsel auf einen fabrikfrischen Controller auftritt. Das Oszilloskop zeigt auch brav an, dass im Fehlerfall die Ausgangspinne high bleiben, obwohl die Software sie auf low setzen sollte :-/
Das vermute ich auch, aber ich habe fast "ALLES" mehrfach kontrolliert und finde nix. Das Problem tauchte auch erst vor einer Weile auf. UND - Softwarefehler sollten eigentlich immer reproduzierbare Fehler zeigen - dieser hier ist wirklich zufällig und nicht reproduzierbar ; - (
Ciao sagt der JoeamBerg
Ich könnte nur allgemein sagen, dass solche Softwarefehler ich nur wegen durch ISR veränderte, vorher nicht zwischengespeicherte und danach restaurierte Registerinhalte kenne, falls Interrupts auftretten ...
Es wäre auch Stapelüberlauf und sonst alles auserhalb des Programmcodes möglich.
MfG (Mit feinem Grübeln) Wir unterstützen dich bei deinen Projekten, aber wir entwickeln sie nicht für dich. (radbruch) "Irgendwas" geht "irgendwie" immer...(Rabenauge) Machs - und berichte.(oberallgeier) Man weißt wie, aber nie warum. Gut zu wissen, was man nicht weiß. Zuerst messen, danach fragen. Was heute geht, wurde gestern gebastelt. http://www.youtube.com/watch?v=qOAnVO3y2u8 Danke!
Softwarefehler müssen nicht immer reproduzierbar sein. Einflüsse von außen, wie Sensoren, können das ganze schon beeinflussen.
Danke Hubert.G, danke PICture. Mein oben gezeigter Code hatte seit Jahren und stundenlang funktioniert bei meinen Fahrdingern, egal ob Dottie, MiniD0 oder ein namenloser Versuchsträger. Mit m168 und m328 und m328P. Nur jetzt - gings eben nicht wie "immer". Dabei ist dieser Code mit Beispielen wie z.B. dem C-Testprogramm der RNControl weitgehend deckungsgleich. Aber die Beispiele waren natürlich nicht so voll von Interrupts wie das MiniD0 jetzt ist - und daran KÖNNTE es gelegen haben. Und damits richtig verwirrend war, kam die Fehlfunktion AUSSCHLIEßLICH auf den Ports 1Y-2Y meiner L293D.
Festgestellt hatte ich jedenfalls, dass der L293D bei Softwarebeispielen für Gleichstrommotoren mit Bürsten für den Motorstop eigentlich immer beide Schalteingängen 1A/2A oder 3A/4A auf low oder high gezogen werden. Das entspricht der Funktionstabelle des L293D im Datenblatt von TI (L293, L293D QUADRUPLE HALF-H DRIVERS, Doc SLRS008C − SEPTEMBER 1986 − REVISED NOVEMBER 2004, Seite 9). Hatte bei mir aber nicht einwandfrei funktioniert - bei zwei verschiedenen L293D, einer davon fabrikfrisch.
Gelöst habe ich es jetzt so, dass ich für den Motorstop den PWM-Port auf low ziehe. Und so geht es - bisher in rund zwei Dutzend Testfahrten ohne den geringsten Fehler.
Ciao sagt der JoeamBerg
Gratulation ! Dein Erfolg freut mich wahnsinnig, weil ich mit meinem Wissen (k.A. über "Cäh") schon am Ende war.![]()
MfG (Mit feinem Grübeln) Wir unterstützen dich bei deinen Projekten, aber wir entwickeln sie nicht für dich. (radbruch) "Irgendwas" geht "irgendwie" immer...(Rabenauge) Machs - und berichte.(oberallgeier) Man weißt wie, aber nie warum. Gut zu wissen, was man nicht weiß. Zuerst messen, danach fragen. Was heute geht, wurde gestern gebastelt. http://www.youtube.com/watch?v=qOAnVO3y2u8 Danke!
Lesezeichen