Hallo Forum, habe eine Schaltung (siehe Anhang) entworfen und heute zusammengelötet. Nur leider musste ich feststellen, das die Schaltug nicht funktioniert. Als ich dann mit dem Oszi die Ausgänge überprüft habe, welche die Schieberegister (74AC164) steuern, musste ich feststellen das die Ausgänge arbeiten und die Schieberegister gesetzt werden. Nehme ich nun den Tastkopf wieder weg, so läuft gar nicht mehr! Woran könnte sowas liegen? Gemessen habe ich an den Durhkontaktierungen beim ersten 74*164 zwischen Kontakt 5/6 (Clockpulse) und 1/2 (um Register zu laden) und beim zweiten zwischen Kontakt 13/14 (Clear) Das LCD ist noch nicht Angeschlossen wir aber theoretisch schon angesteuert. Die Datei pruefadapter.c ist die aktuell verwendete Software. Die Wartezeiten "zeit(n)" (in ms) sind nur zum Debuggen so lange gewählt. Bin leider etwas ratlos. Einen Schaltplan gibt es leider nicht mehr da ich ein kleines Synchronisationsproblem hatte und die Daten verloren gingen. Habe nur noch die *.brd Datei aus einer Mail fischen können. Bin aber dabei den Schaltplan neu zu zeichnen. Vielen dank im Vorraus...
1. Frage: Selber zusammengelötet? Falls ja, Platine mit Lötstoplack oder ohne? Wenn die ohne ist und es selber gelötet ist, ist mit Sicherheit irgendwo ein kleiner Schluss, bei den Mini-Abständen. 2. Frage: Läuft es nur wenn der Tastkopf an diesen besagten Pins ist, oder läuft es auch, wenn nur die Masse vom Oszi angeschlossen ist?
Hört sich nach einer nicht so idealen Signalqualität auf der Taktleitung an. Die 74AC ... sind schnell und entsprechend empfindlich auf nicht terminierte Leitungen und ein schlechtes Layout (nicht ganz durchgehende Massefläche, teils schlechte Anbindung der Abblockkondensatoren). Die zusätzliche Last durch den Tastkopf kann dann ausreichen um die Flanken langsam genug zu machen oder die Überschwinger zu dämpfen.
Ulrich schrieb: > nicht ganz durchgehende Massefläche Diese hübsche "Massefläche" verdient ihren Namen nicht. Das sind viele kleine Masseinselchen... Da fehlen mindestens noch 137 Durchkontaktierungen. Christopher schrieb: > Nehme ich nun den Tastkopf wieder weg, so läuft gar nicht mehr! Und wie sieht das Signal aus, solange der TK noch dran ist? Siehst du da schon/noch Überschwinger?
Mit deiner Initialisierung der Ports
1 | DDRB = 0x00; //Port als Ausgagn |
2 | DDRD = 0xff; //Port al Eingang |
erreichst du genau das Gegenteil des gewollten, nämlich dass Port B als Eingang und Port D als Ausgang fungiert! Es müsste korrekterweise lauten:
1 | DDRB = 0xff; //Port als Ausgagn |
2 | DDRD = 0x00; //Port al Eingang |
Danke für die Antworten. 1. Also die Platine ist von Beta-Layout gefertigt und mit Lötstopplack 2. Läuft nur wenn der Tastkopf drann ist. Signale sehen sauber aus, Steile Flanke beim anstieg und auch saubere Flanken beim abfallen (leichtes PT2 verhalten) 3. Habe den Takt schon enorm verlangsamt, damit ich überhaupt was sehe an den LEDs 4. Ich denke "DDRx = 0x00;" ist schon richtig denn neber mir liegt ein Testboard mit als Ausgang deklarierten PORT und das mit DDRx = 0x00; 5. Hatte die Schaltung schon mal im kleinformat laufen und damals hat sie super funktioniert darauf hin habe ich dann das große Board designed. Danke für die Hilfe
Christopher schrieb: > 4. Ich denke "DDRx = 0x00;" ist schon richtig denn neber mir liegt ein > Testboard mit als Ausgang deklarierten PORT und das mit DDRx = 0x00; Falsch.
Also, die Masseflächen sind katastrophal. Das sehe ich wie Lothar. Da fehlen ja alle Dukos! Aber selbst mit Dukos hast du keine zusammenhängende Massefläche für die schnellen Taktleitungen. Dann, was ist mit der Aura passiert? Da sind 100pro jede Menge Schlüsse! Z.B. bei "47" auf blau. Ich sehe keinerlei Terminierungen der Taktleitungen! Aber selbst wenn welche da wären, ohne zusammenhängende Massefläche wird das nichts. Ich sehe jetzt keinen Schaltplan, aber ich denke, du solltest das auf einer Vier-Lagen-Platine routen. Serien-Terminierung dürfte eventuell schon ausreichen.
Magnus Müller schrieb: > Christopher schrieb: >> 4. Ich denke "DDRx = 0x00;" ist schon richtig denn neber mir liegt ein >> Testboard mit als Ausgang deklarierten PORT und das mit DDRx = 0x00; > > Falsch. Nachtrag: Lies dir mal dieses Kapitel durch, dann wird dir (hoffentlich) ein Licht aufgehen. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Zugriff_auf_IO-Ports
nachtrag Magnus Müller schrieb: > Es müsste korrekterweise lauten: > DDRB = 0xff; //Port als Ausgagn > DDRD = 0x00; //Port al Eingang du hast natürlich recht aber komisch finde ich, das es trotzdem Funktioniert. Vermutlich schalte ich, wenn der PORT als eingagn deklariert ist über PORTx = 0xff die PULLUPs ein und daher leuchten die LEDs
>2. Läuft nur wenn der Tastkopf drann ist. Signale sehen sauber aus, >Steile Flanke beim anstieg und auch saubere Flanken beim abfallen >(leichtes PT2 verhalten) Ja, solange der Tastkopf mit seiner Streukapazität dran hängt. Typisches Verhalten bei Wellenwiderstandsfehlanpassung durch falsche oder fehlende Terminierung. Route die Taktleitungen mal in Microstriptechnik mit durchgehender Massefläche und Serienterminierungen.
Ina schrieb: > Da > fehlen ja alle Dukos! Dukos = Durchkontaktierungen?! Ina schrieb: > Dann, was ist mit der Aura passiert? Da sind 100pro jede Menge Schlüsse! > Z.B. bei "47" auf blau. Kontakt 47 zu blau ist sauber, das liegt an der Export Funktion von Eagle! Ina schrieb: > Ich sehe keinerlei Terminierungen der Taktleitungen! Aber selbst wenn > welche da wären, ohne zusammenhängende Massefläche wird das nichts. Wenn ich den Steuerpuls verlangsame, brauche ich da zwingend Terminierungen? Welche Terminierungen benutzt man üblicher weise 330 Ohm in Reihe. Kannte terminierungen bisher nur vom CAN-Bus mit je 120 Ohm am Ende der Leitung. Habe die Masse aller 164er nachgemessen und sie war da oder ist in dem Fall Durchgang != Durchgang ?
Christopher schrieb: > du hast natürlich recht aber komisch finde ich, das es trotzdem > Funktioniert. Komisch ist es nicht, dafür aber grenzwertig. > Vermutlich schalte ich, wenn der PORT als eingagn deklariert ist über > PORTx = 0xff die PULLUPs ein und daher leuchten die LEDs So ist es. Allein der angelegte Tastkopf sorgt durch seinen Eingangswiderstand (welcher gegen GND geht) dafür, dass dein Signal beim Abschalten des/der PullUps in Richtung 0V gezogen wird.
Ina schrieb: > Route die Taktleitungen mal in Microstriptechnik mit durchgehender > Massefläche und Serienterminierungen. Microstriptechnik hab ich leider noch nie gehört aber ich Google gerade mal ;)
Irgendwie habe ich das Gefühl, dass sich kaum einer mal ernsthaft den Code angesehen hat....
naja wenn man bei DDRB = 0x00; //Port als Ausgagn DDRD = 0xff; //Port al Eingang ankommt verliert sich irgend wie die Lust weiter zu lesen...
@Dex (Gast): Das mag für Dich zutreffen (was ich in gewissen Grenzen auch nachvollziehen kann). Ich verstehe allerdings nicht warum sich der Rest ausschließlich am Layout aufhängt....
So habe die pruefadapter.c mal korrigiert und getestet. Es läuft eigentlich wie ich mir das vorgestellt habe nur eben nicht auf dem dafür vogesehenen Board :( Wie ist das jetzt mit dem Terminierungswiderstand der Taktleitug? Gibt es da irgendwelche Faustformeln. Zu Microstriptechnik habe ich auch noch nichts brauchbares gefunden. An was für grundregeln hat man sich den da so zu halten Danke an alle LG Chris
>Wenn ich den Steuerpuls verlangsame, brauche ich da zwingend >Terminierungen? Es geht um die Flankensteilheit. >Welche Terminierungen benutzt man üblicher weise 330 Ohm in Reihe. Bei einer 4-Lagenplatine ergibt eine 0,3mm breite Leiterbahn auf der obersten Ebene, in einer Massefläche eingebettet, mit 0,3mm Aura, und gegen eine Massefläche in der zweitobersten Ebene, eine Leitungsimpedanz von rund 80R. Die ATMEGA-Port-Ausgänge haben Impedanzen von rund 30R. Also gibt es immer Fehlanpassungen bei direktem Anschluß. Abhilfe schaffen hier zusätzliche 51R Widerstände, die direkt an die Port-Ausgänge gehängt werden. Damit wird eine Serienterminierung erreicht mit allen ihren segensvollen Auswirkungen. Leider habe ich keinen Schaltplan, kann also nicht sehen, was alles an einer Leitung hängt und wie lange diese ist.
Ina schrieb: > Leider habe ich keinen Schaltplan, kann also nicht sehen, was alles an > einer Leitung hängt und wie lange diese ist. Ich auch nicht mehr das ist ja das Blöde.... Aber evtl. könnte ich das in der *.brd Datei nachmessen?!? Ich versuch das mal und geb dir dann die Eckdaten.
Abstand zu Leiterbahnen und Massefläsche = 0.2032mm
So habe die Taktleitung mal Farblich hervorgehoben. Jetzt bitte nicht vom Stuhl fallen :) sieht ziemlich wüst aus dank Autorouter (schäm) und nach dem was ich jetzt über Reflexion, Wellen, Terminierung und leitungsführung gelesen habe ist das bestimmt nicht die beste Lösung gewesen.
Ohje! Müssen das unbedingt 74AC164-Typen sein? Gehen nicht auch 74HC164er?
Den Eagle-Autorouter kannst du komplett in die Tonne treten. Der ist zu nichts nutze. Allenfalls in einem Z80-System ein Bussystem zum 8*64kBit-Speicher routen. An Cadsofts Stelle würde ich mich schämen, sowas überhaupt anzubieten und dann moch Geld dafür zu nehmen.
Hi Autor: Christopher (Gast) , wenn es doch mit Tastkopf alles funktioniert, könnte man ja einen einbauen. 1Mohm und 10pF vielleicht. .. aber ich würde ja mal am Anschluss 222, das Ende deiner Leitung etwas herumspielen. evt. 10k gegen +UB und 10k gegen Gnd... oder das gleiche mit 3k probieren. Mir scheinen die vielen Bausteine auf der Taktleitung ein wenig viel für den uC zumal die AC Bausteine eh ziemlich bissig sind, wenn diese in Gruppen oder Rudeln auftauchen. evt. kannst du auch in deiner Software die Funktion der Taktleitung invertieren und zwischen uC Pin und der Taktleitung einen 74HC04 (hex Inverter) schalten, bei dem du dann alle 6 Bausteine parallel schaltest. Sozusagen als Treiber. gruss k.
Hi, das sind zu viele Bauteile für die Taktleitung. Jeder Eingang der 74ACer wirkt als "Kapazität" die geladen/entladen werden muss. Außerdem führst du die Taktleitungen immer schön in einer Schleife. Eine alternatives Routing der Taktleitung siehe Anhang (hoffe man versteht es :) ). Außerdem würde ich für so etwas immer einen Buffer, z.B. NC7WZ16P6X ,verwenden. Das Programm habe ich mir noch nicht angeschaut. Werde es gleich aber noch machen. Viele Grüße
Ich habs. Du änderst das Datensignal zur gleichen Zeit wie die aktive Taktflanke. Das geht natürlich schief. Du musst die set-up und hold Zeit beachten. Deshalb zuerst das Datensignal setzen und danach mit dem nächsten Befehl den Takt setzen.
Magnus Müller schrieb: > Es müsste korrekterweise lauten: > > DDRB = 0xff; //Port als Ausgagn > > DDRD = 0x00; //Port al Eingang Und hier ist der Sieger ;) Konnte heute einen neuen Test starten und siehe da es läuft :) Was ein Misst... (schäm) so is das wenn man von Bascom auf C umsteigt. Muss wohl noch mehr Programieren, damit mir sowas gleich auffällt. Konnte das gestern nur zu Hause auf meinem EVAL Board testen und da hängen nur LEDs dran denen ist son dreher scheinbar egal. Aber VIELEN VIELEN DANK anoch mal an alle. Werde mir die vielen Tipps bei meinem nächsten Projekt zu Herzen nehmen. LG Chris
Noch etwas was schon ansatzweise erwähnt wurde und Dir in zukunft Ärger machen kann, wenn Du die Taktzeiten hochschraubst: Es sitzen wirklich verdammt viele (TTL? LVTTL? CMOS?) Eingänge an dem einem Ausgang des Mikrocontrollers - das Signal was Du im 'takt.png'-Bild grün gefärbt hast. Du weißt was der AVR für Ströme sinken/sourcen kann? Du weißt über die Kapazitäten der Eingänge deiner Logigbausteine bescheid? Ab einer gewissen Taktgeschwindigkeit wird der Controller zum Umladen der Eingänge durch den limitierten Strom zu lange brauchen. Leitungstreiber und eine Takttopologie mit mehreren Gruppen und Untergruppen wären angesagt. Die auch schon vorgeschlagene, sternförmige Verteilung des Signals wäre eine schöne Abrundung - ob es gar nötig ist, wie das ebenfalls erwähnte impedanzkontrollierte Führen der Leiterbahn - hängt von der Frequenz des Taktsignals ab.
Es ist lustig, wie hier über Flankensteilheit, Massefläche und Teminierung geschwafelt wird, wobei das eigentliche Problem doch ist, dass er die Ports auf Eingang geschaltet hat und das ganze Teil nur über die Pull-Ups läuft (was natürlich nur klappt, wenn man den Pin z.B. mit dem Tastkopf leicht gegen Masse zieht, damit er nicht oben schweben bleibt) kopfschüttel
@ Arno Nyhm (Gast) >Du weißt was der AVR für Ströme sinken/sourcen kann? 20mA, damit kommt man ein Stückchen. >gewissen Taktgeschwindigkeit wird der Controller zum Umladen der >Eingänge durch den limitierten Strom zu lange brauchen. Ist hier noch lange nicht das Problem. 10 Eingänge schafft er auf jeden Fall, ggf. mehr. >Leitungstreiber und eine Takttopologie mit mehreren Gruppen und >Untergruppen wären angesagt. Nachdenken statt 0815 wäre angesagt. Das ist ein popeliger AVR mit einer Handvoll Schieberegister. Da sollte man die Kirche im Dorf lassen. >wie das ebenfalls erwähnte impedanzkontrollierte Führen der Leiterbahn - >hängt von der Frequenz des Taktsignals ab. Nö, der Anstiegszeit. Siehe Wellenwiderstand. MfG Falk P S Der Dreher mit DDRx kommt vom vielen PIC-Programmieren, dort ist es nämlich genau anders heruma las beim AVR. :-0
>Es ist lustig, wie hier über Flankensteilheit, Massefläche und >Teminierung geschwafelt wird,... Ja klar, welcher Idiot braucht schon durchgehende Masseflächen und Serienterminierungen, gell?
@ Ina (Gast) >Ja klar, welcher Idiot braucht schon durchgehende Masseflächen und >Serienterminierungen, gell? bei Takten mit mehreren Empfängern (multidrop) sollte man das mit der Serienterminierung sein lassen . . .
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.