Hallo zusammen, ich bastele momentan an einer LED-Matrix mit zwei MAX6954 als LED-Treibern und einem Mega32 als Controller. Den Takt erhält der Mega über einen 15.36 MHz Quarzoszillator. (Grund für die Frequenz: Damit kann ich Millisekunden-genaue Timer-Interrupts erzeugen um z.B. auch mal ne Uhr anzeigen zu können oder die Programmabläufe genau zu steuern) Aufgebaut ist das Ganze auf einer Punktrasterplatine, alles händisch verdrahtet. Die SPI-Leitungen zwischen Mega32 und den beiden MAX6954 sind direkt an den jeweiligen Pins des AVR über einen 2.2k Widerstand geführt (1k waren keine mehr in der Bastelkiste). Die MAX6954 sind parallel angeschlossen, keine Daisy-Chain. Die MAX6954 werden über den Hardware-SPI befeuert, mit Ausnahme des CS Signals, das erzeuge ich per Hand. Die CS-Leitungen zu den MAX6954 gehen von jeweils einem eigenen Pin am Mega32 weg und haben auch jeweils einen eigenen, externen Pullup. (Gedanke war, dass die CS-Leitungen während der Programmierung stabil auf High gezogen werden damit die MAX6954 in der Zeit den Datenverkehr auf dem SPI-Bus schön ignorieren...) Nun habe ich beim Aufbau der Platine ein wenig gepennt (oder war zu gutgläubig...) und habe dussligerweise die Zuleitung vom Quarzoszillator quer über die SPI-Leitungen geführt. Scheinbar koppelt nun das Taktsignal ziemlich heftig in die SPI-Leitungen ein, dadurch klappt die Kommunikation mit den MAX6954 nur alle Jubeljahre mal. Die grundsätzliche Frage: Wie kriegt man das Problem am Besten in den Griff? Ich habe verschiedene Ideen und würde gern eure Meinung dazu hören: - Die Widerstände aus den SPI-Leitungen raus. Dadurch sollten die Leitungen "stabil" auf Masse gezogen werden können und die Kommunikation sollte passen. Das erscheint mir als die einfachste Lösung, widerspricht aber der Appnote von Atmel. Kann man das trotzdem so machen? Während der Programmierung sollten die MAX6954 ja eigentlich "weghören". - Quarzoszillator "umziehen" um die gekreuzten Leitungen "abzuschaffen". Problem dabei ist, dass es auf der Platine ziemlich eng zugeht. Ich könnte höchstens versuchen, den Quarzoszi unter dem Mega32 im IC-Sockel zu versenken, aber auch das wird knapp vom Platz her. Ich bin mir ausserdem nicht sicher, ob der Oszi dort überhaupt sitzen "darf". - Den Oszillator abschaffen und durch nen SMD-Quarz nebst Kondensatoren ersetzen. Den Quarz würde ich dann auf die Platinenunterseite zwischen die Prozessorpins "pappen". Dafür müsste ich aber erstmal wieder die Bauteile bestellen/besorgen... :/ Danke und Grüße, Shuzz P.S.: Ich versuche später nochmal ein Foto einzustellen, mal sehen ob meine Frau so freundlich ist und daheim kurz die Knipse in die Hand nimmt... ;)
Hallo, also der Oszillator sollte so nahe wie sinvoll möglich zum Takt-Eingang des µCs. Außerdem Versorgung des µC und des Oszillators(direkt am Oszill.) mit 100nF absieben. Die 2K2-Widerstände sind evtl. zu hoch. (mit welcher Frequenz betreibst du die SPI??) Falls der SPI-Clock im MHz-Bereich, sollten die Widerstände eher 100 Ohm sein! (nötig sind sie nicht!) Außerdem solltest du jeden MAX-Treiber direkt an den Versorgungspins zum Massepin mit 100nF Keramik (evtl. mit 22µF parallel) absieben. µC-Masse getrennt von MAX-Treiber-Masse zu der Masse-Zuleitung legen - ansonsten dick auslegen. PS: Wieso schließt du dei MAXe parallel an??? was soll das bringen? Gruß Alex
Christian T. schrieb: > Ich versuche später nochmal ein Foto einzustellen Schon mal was von Schaltplänen gehört? Das bringt mehr als irgendwelche Fotos.
@ Christian T. (shuzz) >Den Takt erhält der Mega über einen 15.36 MHz Quarzoszillator. (Grund >für die Frequenz: Damit kann ich Millisekunden-genaue Timer-Interrupts >erzeugen um z.B. auch mal ne Uhr anzeigen zu können oder die >Programmabläufe genau zu steuern) Kann man auch mit anderen Frequenzen. >Die SPI-Leitungen zwischen Mega32 und den beiden MAX6954 sind direkt an >den jeweiligen Pins des AVR über einen 2.2k Widerstand geführt Was heißt über? In Reihe 2k2? Das ist unsinnig bis kontraproduktiv. Die werden direkt angeschlossen. >keine mehr in der Bastelkiste). Die MAX6954 sind parallel angeschlossen, >keine Daisy-Chain. Logisch. >von jeweils einem eigenen Pin am Mega32 weg und haben auch jeweils einen >eigenen, externen Pullup. (Gedanke war, dass die CS-Leitungen während >der Programmierung stabil auf High gezogen werden damit die MAX6954 in >der Zeit den Datenverkehr auf dem SPI-Bus schön ignorieren...) Ist OK. >Nun habe ich beim Aufbau der Platine ein wenig gepennt (oder war zu >gutgläubig...) und habe dussligerweise die Zuleitung vom Quarzoszillator >quer über die SPI-Leitungen geführt. >Scheinbar koppelt nun das Taktsignal ziemlich heftig in die >SPI-Leitungen ein, dadurch klappt die Kommunikation mit den MAX6954 nur >alle Jubeljahre mal. Kann sein, muss nicht. Ich tippe eher auf deine 2k2 Längswiderstände, mit denen du dir "schöne" Tiefpässe gebaut hast. Takte dein SPI mal langsamer. >- Die Widerstände aus den SPI-Leitungen raus. Auf jeden Fall. > Dadurch sollten die >Leitungen "stabil" auf Masse gezogen werden können und die Kommunikation >sollte passen. Das erscheint mir als die einfachste Lösung, widerspricht >aber der Appnote von Atmel. Die kann man leicht missverstehen. > Kann man das trotzdem so machen? Während der >Programmierung sollten die MAX6954 ja eigentlich "weghören". Tun sie auch, wenn CS per externem Pull-Up auf High gezogen ist. >- Quarzoszillator "umziehen" um die gekreuzten Leitungen "abzuschaffen". Möglich, aber eher unwahrscheinlich. Sooooo empfindlich ist ein gepufferter Oszillatorausgang nicht. >- Den Oszillator abschaffen und durch nen SMD-Quarz nebst Kondensatoren >ersetzen. Bringt nix. >P.S.: Ich versuche später nochmal ein Foto einzustellen, Ist Unsinn, siehe Netiquette. Ein Schaltplan ist das Mittel der Wahl. MfG Falk
Danke für die bisherigen Kommentare. Schaltplan hab ich momenten nicht zur Hand, kann den relevanten Teil aber heute Abend mal zeichnen. Ein Foto wollte ich nur einstellen damit man die Leitunsführung besser sieht, auf dem Schaltplan ist ja am Ende sowieso alles ordentlich. ;) Langsamer takten kann ich den SPI nicht, der läuft bereits mit nem Vorteiler von 128, bei der verwendeten Clock macht das dann ca. 120kHz. Aus Interesse: Was genau ist an der Atmel-Appnote denn mißverständlich? Offenbar habe ich es mißverstanden, bin mir aber nicht sicher wo der Denkfehler liegt... Danke und Grüße, Christian
@ Christian T. (shuzz) >Langsamer takten kann ich den SPI nicht, der läuft bereits mit nem >Vorteiler von 128, bei der verwendeten Clock macht das dann ca. 120kHz. Ok, dann liegt das Problem woanders. Sind alle Ausgänge vom SPI als Ausgänge geschaltet? Das muss man manuell machen, nicht wie beim UART, wo es automatisch mit der Aktivierung passiert. >Aus Interesse: Was genau ist an der Atmel-Appnote denn mißverständlich? Welche? Link? MfG Falk
Link auf die Appnote findet sich sogar hier im ISP-Artikel: http://www.mikrocontroller.net/articles/AVR_In_System_Programmer#ISP-Pins_am_AVR_auch_f.C3.BCr_andere_Zwecke_nutzen Appnote Direktlink: http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Aber wie auch immer, ich hab die Widerlinge rausgenommen und nun geht's... Danke für die Hilfe!
Beziehst du dich auf Seite 6? Vergiss das einfach, keine Ahnung, was die da schreiben. Der Text deutet darauf hin, dass sie externe SPI Geräte meinen; die Überschrift einfach "generelle Benutzung der IOs"... Wichtig ist der Punkt: Damit ISP funktioniert, muss die externe Hardware das in Ruhe lassen. Das tut dein SPI Gerät, solange sein CS inaktiv ist.
@ Christian T. (shuzz) >Aber wie auch immer, ich hab die Widerlinge rausgenommen und nun >geht's... Vielleicht waren es ja auch deutlich mehr als 2k2, dann wäre das erklärbar.
Die Appnote bezieht sich auf mögliche Kollisionen zwischen SPI und ISP. Welche Leitungen von Kollisionen betroffen sein können hängt nun davon ab, in welchem Modus SPI betrieben wird. So ist ein Widerstand in SCK in diesem Zusammenhang nur dann sinnvoll, wenn der AVR durch einen externen SPI-Master angesprochen wird, denn nur dann kann ein Konflikt zwischen diesem SCK treibenden Master und dem ebenfalls SCK treibenden ISP auftreten. Ist der AVR hingegen selbst der Master, dann ist ein Konflikt ausgeschlossen. Das gleiche gilt für MOSI. Bei MISO kann ein Konflikt nur auftreten, wenn diese Leitung vom Slave in der ISP-Phase aktiv treibend sein kann. Das ist beispielsweise bei Porterweiterungen (Inputs) mit Schieberegistern der Fall, wenn der Datenausgang des Schieberegisters nicht deaktivierbar ist. Komplexe SPI-Slaves mit CS-Leitung deaktivieren jedoch ihren Datenausgang wenn CS inaktiv ist. Daher muss nur über schwache externe(!) Pullups an allen relevanten CS Leitungen sichergestellt sein, dass CS während Reset inaktiv ist. Manche SPI-Slaves haben die bereits an Bord.
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.