Hallo zusammen, habe eine komische Entdeckung gemacht. Mein aktuelles Projekt befasst sich mit der Digitalisierung von Brückenspannungen von Kraftmessdosen. Diese werden per Bluetooth an einen Rechner geschickt. Funktioniert einwandfrei - allerdings nur solange ich die Schaltung am STK500 betreibe, also die Spannungsversorgung durch den ISP erledigen lasse. Ich hatte jedoch auch eine "normale", eigene Spannungsversorgung mittels eines 7805 vorgesehen. Wenn ich diese nutze gibt mir der AD Wandler (AD7193) scheinbar zufällige Werte aus. Das Programm auf meinem ATMega scheint einwandfrei zu laufen. Ich kann den AD7193 ansprechen und bspw. GPIOs setzen. Sobald ich das Board am STK500 betreibe funktioniert alles einwandfrei. Habe mir schon die Versorgungsspannungen am Oszi angeschaut, sieht unverdächtig glatt alles aus. Auch am ISP selbst habe ich GND und 5V vom Labornetzteil kommend angelegt, gleicher Random Effekt. Ich bin reif fürs Wochenende ?!?! Danke für jeden Hinweis. Grüße
Angehängte Dateien:
-
systemPowerBoard.jpg
170 KB -
systemPowerSchematic.jpg
17 KB
Sicherungsflicker schrieb: > Selbes Bezugspotential? Hab extra - seit dem ich dieses Verhalten entdeckt habe - immer GND nochmal extra verbunden. Eben habe ich 5V an den VTARGET Pin des STK500 die 5V vom Labornetzteil angelegt ,GND verbunden und den ISP Stecker. Selbes Random Verhalten.
Wenn Du Informationen auf einem professionelleren Niveau gibst erhöhst Du auch die Wahrscheinlichkeit qualifizierterer Hilfestellung. Falls Du zur Formulierung Informationen brauchst: http://www.tty1.net/smart-questions_de.html#beprecise
@Grrrr Danke für diesen sachdienlichen Hinweis, dazu folgendes: >Beschreibe die Symptome deines Fehlers oder Problems sorgfältig und klar. Wenn ich diese (Anm.: autarke Spannungsversorgung) nutze, gibt mir der AD Wandler (AD7193) scheinbar zufällige Werte aus. >Beschreibe die Umgebung, in der es auftaucht (Maschine, Betriebssystem, >Applikation, was auch immer). Nenne auch die verwendete Distribution mit >Versionsnummer (z.B. "Fedora Core 4", "Slackware 9.1", etc.). Mein aktuelles Projekt befasst sich mit der Digitalisierung von Brückenspannungen von Kraftmessdosen. Diese werden per Bluetooth an einen Rechner geschickt. Funktioniert einwandfrei - allerdings nur solange ich die Schaltung am STK500 betreibe, also die Spannungsversorgung durch den ISP erledigen lasse. Zusatz: ATMega328PA - AD-Wandler AD7193 - Bluetooth Modul BTM-222 >Beschreibe, welche Versuche du unternommen hast, um das Problem zu >verstehen, bevor du gefragt hast. Das Programm auf meinem ATMega scheint einwandfrei zu laufen. Ich kann den AD7193 ansprechen und bspw. GPIOs setzen. Sobald ich das Board am STK500 betreibe, funktioniert alles einwandfrei. >Beschreibe, welche Versuche du unternommen hast, um das Problem zu lösen, >bevor du gefragt hast. Habe mir schon die Versorgungsspannungen am Oszi angeschaut, sieht unverdächtig glatt alles aus. Auch am ISP selbst habe ich GND und 5V vom Labornetzteil kommend angelegt, gleicher Random Effekt. Hab extra - seit dem ich dieses Verhalten entdeckt habe - immer GND nochmal extra verbunden. Eben habe ich 5V an den VTARGET Pin des STK500 die 5V vom Labornetzteil angelegt ,GND verbunden und den ISP Stecker. Selbes Random Verhalten. >Beschreibe die letzten Änderungen an deinem Computer oder deinen >Softwareeinstellungen, die dir relevant erscheinen. keine ---- Es sieht so aus, ich habe eine Platine, die einwandfrei funktioniert, wenn sie ihre Spannung vom STK500 bezieht. Lege ich eine Spannung in gleicher Höhe (5V, GND) an den selben Pins der ISP Schnittstelle an, zeigen alle Komponenten meiner Schaltung richtige Funktion, außer der A/D Wandler. Dieser kommuniziert zwar weiterhin mit meinem ATMega328PA, aber übermittelt scheinbar zufällige Spannungswerte, wohingegen er dies bei einer Versorgung durch das STK500 (welches an einem gewöhnlichen 12V Netzteil hängt) nicht tut und valide Werte übermittelt. Zuerst hatte ich auch auf ein ungleiches Bezugspotential getippt, allerdings muss ich das mittlerweile ausschließen. Nun habe ich keinen guten Einfall mehr. Viele Grüße und Danke für eure Hilfe.
Was liegt denn am Eingang Deiner autarken Spannungsversorgung an (X2)?
Wie sieht denn die Referenzspannung aus, in beiden Versorgungsfällen?
Ago schrieb: > Wie sieht denn die Referenzspannung aus, in beiden Versorgungsfällen? Ich habe am STK500 5,0V eingestellt, ebenso am Labornetzteil. Der 7805, der auf der Platine sitzt erzeugt mir ja die 5V Systemspannung. Auf dem hochgeladenen Schematic kann man sehenn, wie die Verschaltung dazu ist. Auf der Platine sitzt der ISP ganz rechts, direkt daneben der Schraubterminal für die externe Spannungsversorgung. Am ISP sitzt rechts oben, in dieser Ansicht, an Pin2 die Versorgungsspannung von 5V.
S. G. schrieb: > Der 7805, > der auf der Platine sitzt erzeugt mir ja die 5V Systemspannung. Was denn, ich denke, du speist 5 V ein? Wofür soll dann der 7805 gut sein, der braucht doch noch weitere 3 V für sich?! > Auf dem > hochgeladenen Schematic [...] Aua, Schaltplan und Layout als JPEG, dann lass das mal nicht den Falk sehen, → Bildformate Die Artefakte tun ja den Augen weh.
Jörg Wunsch schrieb: > Aua, Schaltplan und Layout als JPEG, dann lass das mal nicht den Falk > sehen, → Bildformate Die Artefakte tun ja den Augen weh. Ja sorry, tut mir auch weh. Das war das fixeste, was ich mit Windows Bordmitteln erzeugen konnte.
Ich meinte die Referenzspannung am ADC, mess' die bitte mal (beide, Vin+ und Vin-). Da kann ich am Layout nicht ganz folgen wo die her kommmt.
S. G. schrieb: > Ja sorry, tut mir auch weh. Das war das fixeste, was ich mit Windows > Bordmitteln erzeugen konnte. Nö, die Ausrede zählt nicht. Du möchtest ja auch, dass andere sich die Mühe machen, sich mit deinem Problem zu befassen, dann darfst du dir auch als Vorleistung die Mühe machen, ein PNG zu erzeugen. Kost' ja nicht die Welt, im Zweifelsfalle installierst du dir mal einen Gimp, den kann man immer mal gebrauchen. Zum Thema: bleibt dir wohl nicht viel anderes übrig, als das Stück für Stück zu debuggen. SPI-Bus mitschneiden und gucken, ob der ADC tatsächlich den Mist liefert, oder ob der Controller Mist interpretiert. Halt alles zwischen den beiden Varianten Stück für Stück vergleichen. Ist lästig, aber jemand, der von dir ein paar hundert Kilometer entfernt sitzt, wird das erst recht nicht finden können.
Jörg Wunsch schrieb: > S. G. schrieb: > >> Ja sorry, tut mir auch weh. Das war das fixeste, was ich mit Windows >> Bordmitteln erzeugen konnte. > > Nö, die Ausrede zählt nicht. Du möchtest ja auch, dass andere sich > die Mühe machen, sich mit deinem Problem zu befassen, dann darfst du > dir auch als Vorleistung die Mühe machen, ein PNG zu erzeugen. Kost' > ja nicht die Welt, im Zweifelsfalle installierst du dir mal einen > Gimp, den kann man immer mal gebrauchen. > > Zum Thema: bleibt dir wohl nicht viel anderes übrig, als das Stück > für Stück zu debuggen. SPI-Bus mitschneiden und gucken, ob der > ADC tatsächlich den Mist liefert, oder ob der Controller Mist > interpretiert. Halt alles zwischen den beiden Varianten Stück für > Stück vergleichen. Ist lästig, aber jemand, der von dir ein paar > hundert Kilometer entfernt sitzt, wird das erst recht nicht finden > können. Alles klar, ist angekommen. Ich hätte natürlich ein qualitativ und quantitativ weitaus besseres GIF Format nehmen können. Ich hatte eigentlich nicht mein Problem hier schildern wollen, um viele beliebig interpretierbare Hinweise zu erhalten. Ich meine nicht erst lernen zu müssen, wie man am Besten debuggt, aber danke für die Hinweise. Meine Intention war, dass es gerade im Zusammenhang mit dem STK500 vielleicht schon zu solchen Vorkommnissen gekommen ist. Aber gut, demnach also nicht. Dann werde ich mich ab Montag wieder meinem Problem widmen und Kommunikation darüber besser unterlassen. Das scheint für alle Beteiligten zielführender zu sein. Bisher war das in diesem Forum meist konstruktiver in dieser Hinsicht meiner. Vielen Dank und viele Grüße. @Ago VRef kommt direkt von VDD
S. G. schrieb: > Meine Intention war, dass es gerade im Zusammenhang mit dem STK500 > vielleicht schon zu solchen Vorkommnissen gekommen ist. Aber gut, > demnach also nicht. Nö, wenn überhaupt, dann sollte der STK500 eher die qualitativ schlechtere Versorgungsspannung liefern, da das ja nur ein simpler LM317 ist. > Dann werde ich mich ab Montag wieder meinem Problem > widmen und Kommunikation darüber besser unterlassen. Das scheint für > alle Beteiligten zielführender zu sein. Kannst du nicht einfach den Forentroll vom Dienst ignorieren? Alle anderen haben doch versucht, dir zu helfen.
Jörg Wunsch schrieb: > S. G. schrieb: > >> Meine Intention war, dass es gerade im Zusammenhang mit dem STK500 >> vielleicht schon zu solchen Vorkommnissen gekommen ist. Aber gut, >> demnach also nicht. > > Nö, wenn überhaupt, dann sollte der STK500 eher die qualitativ > schlechtere Versorgungsspannung liefern, da das ja nur ein simpler > LM317 ist. Eben, auf solche Ideen hatte ich gehofft. Ich sehe das auch so. Am Montag werde ich mal den Strang debuggen. Hatte heute mit den Hardwareverbindungen der Strumzuführungen angefangen. Heute war erst mal Ofen aus... > >> Dann werde ich mich ab Montag wieder meinem Problem >> widmen und Kommunikation darüber besser unterlassen. Das scheint für >> alle Beteiligten zielführender zu sein. > > Kannst du nicht einfach den Forentroll vom Dienst ignorieren? Alle > anderen haben doch versucht, dir zu helfen. grummel...na wahrscheinlich hast du Recht
Schon mal die Spannung am 7805 nachgemessen? Du weißt, dass der Eingang vom 7805 min. ca 8V benötigt?
S. G. schrieb: > Am > Montag werde ich mal den Strang debuggen. Lass uns mal wissen, was es denn war. mikrocontroller.net hat ja ein gutes Ranking bei Gugel, dann finden bei Bedarf andere Leute auch mal die Auflösung.
Simon K. schrieb: > Schon mal die Spannung am 7805 nachgemessen? Du weißt, dass der Eingang > vom 7805 min. ca 8V benötigt? Beidesmal Ja (mit Oszi). Der 7805 liefert genau 5V, annehmbar glatt (hab das Rauschen nicht extra quantifiziert, aber es sieht so aus, wie man es erwartet.)
S. G. schrieb: > Der 7805 liefert genau 5V Dumme Nachfrage die Kerkos nahe genug am 7805? 1.Evtl. schwingt irgendwas ? Ein paar Abblock-Keramikkondensatoren sind nie schädlich. 2.Wer Funk kennt, nimmt Kabel. Evtl. Standortprobleme durch Fremdeinstrahlung?
Angehängte Dateien:
-
Zwischenablage.png
16 KB -
vorher.jpg
250 KB -
nachher.jpg
240 KB
Hallo Leute, ich konnte das Problem heute lösen. Nachdem ich mir alle SPI Signale nochmal mit dem Oszi anngeschaut habe, stellte ich auf MISO ein Verhalten fest, das ich als große Kapazität interpretieren würde. Siehe auch vorher.jpg. Die Lösung musste also irgendwo in der Schaltung des STK500 stecken, denn dann (wenn ich den ISP Konnektor draufgesetzt hatte) sah MISO einwandfrei aus. Ich hab mir daher mal das Schematic zum STK500 hergenommen ( zu bekommen unter http://www.avrfreaks.net/modules/FreaksFiles/files/155/STK500_Schematics.pdf) und auf Seite 8 findet sich der spannende Teil mit der Beschreibung des MISO Signals zwischen dem Konnektor und dem "Atmel Programmier IC". Da findet sich ein 1kOhm PullUp. Den habe ich bei mir auch reingesetzt und sofort funktioniert die Schaltung am Labornetzteil mit Einspeisung über den 7805 einwandfrei. Programmieren funktioniert genauso weiterhin ohne Probleme, wie nicht anders zu erwarten.
Glückwunsch erstmal, dass du's gefunden hast. Ganz ist mir die Ursache aber noch nicht klar. Die Doppelfunktion von DOUT/nRDY beim AD7193 scheint mir reichlich verwurschtelt (zumal die Signaldiagramme den Anschein erwecken, als würde dieser Pin wirklich hochohmig, wenn er "nichts zu sagen hat"), aber eigentlich sollte sich doch der SPI-Master nicht um den Zustand von MISO kümmern, solange kein SPI-Transfer läuft, und während des SPI-Transfers sollte wiederum DOUT/nRDY einen definierten Pegel haben. Würde denn ein interner Pullup am MISO-Pin im AVR nicht auch genügen?
Eigentlich sollte das stimmen. Ein interner 1kOhm PullUp sollte den gleichen Effekt haben. Teilweise sieht die Übertragung sogar schlimmer aus, sodass anscheinend Mist interpretiert wird beim Master. Ich müsste mal schauen, wie meine SPI Schnittstelle initialisiert wird. An sich müsste aber MISO als Eingang doch eh mit einem internen PullUp beschaltet sein und somit hochohmig sein. Ich schau mal im Code nach. Nutze den Code von Fabian Greif und seiner CAN Bibliothek. Ja dies DOUT Funktionalität hat TI eingeführt, um das Pollen über den Bus zu minimieren. Man müsste sonst laufend ein Register abfragen, das mit dem DREADY Bit. So zieht man ADC_CS auf low und wartet bis DOUT auch auf low geht. Da habe ich eine solche Polling/Warte-Routine, die das macht, dann über SPI den Wert einliest und ADC_CS wieder high setzt.
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.