Guten Morgen Zusammen, ich schraube derzeit an einer Schaltung welche als Baudratenkonverter agiert. Sie nimmt Daten vom PC mit 38400 Baud entgegen und reicht diese an ein Endgerät weiter welches es mit der Baudrate nicht so genau nimmt da es auf dem eingebauten RC-Oszillator des im Selbigen verbauten ATMega läuft. Ohne die Schaltung kommt am PC abhängig vom Endgerät nur Kauderwelsch an. Die Schaltung besteht aus 2 Stück ATTiny2313, einer nimmt Daten vom PC entgegen und reicht sie an das Endgerät weiter, der zweite macht es genau andersherum. Um mich auf die Baudrate des Endgerätes einzustellen vermesse ich das Startbit welches nach Senden eines bestimmten Kommandos vom Endgerät zurückkommt. Das Programm auf den Tinys funktioniert wunderbar, das Ganze funktioniert so wie erwartet, bis auf ein mittelschweres Problem: Die Schaltung läuft beim Einschalten nicht immer an bzw. das Programm bleibt hängen - was genau es nun ist habe ich noch nicht ganz raus. Von 10 Einschaltvorgängen klappen nur gefühlte 7-8 vernünftig. Aktiviere ich den BOD (und sei es auch nur mit 1.8V) wird es noch schlechter. Die Spannung an den Controllern habe ich mir schon auf dem Oszilloskop angeschaut, Sie hat zwar einen leichten Rippel, sackt aber auf höchstens 4,7V zusammen. Die Fuses des ersten Controllers sind auf "Ext. Crystal Osc. 8..." eingestellt und CKOUT ist aktiv, beim zweiten ist die Taktquelle "Ext. Clock" gesetzt. Programme und Schaltung hängen an, hat jemand nen Tipp für mich? Was habe ich übersehen? Edith: Die Kommentare im Programm für Eva könnten etwas wirr sein, da es eine abgewandelte Kopie von Adam ist. Die muss ich noch anpassen.
Angehängte Dateien:
-
PCB.png
20 KB -
Schematic.png
52 KB
:
Bearbeitet durch User
J. L. schrieb: > Spannung an den Controllern habe ich mir schon auf dem Oszilloskop > angeschaut, Sie hat zwar einen leichten Rippel, sackt aber auf höchstens > 4,7V zusammen. Wo kommt die her? Mal eine alternative Spannungsquelle ausprobiert?
Der Quarz ist ausgeschlachtet und das sind die dazugehörigen Kondensatoren. Ich habe Testweise jeweils weitere 12 pF parallel angelötet, hat keine Verbesserung gebracht. Die Info fehlte im Schaltplan leider.
Ripple auf der Spannungsversorgung kann den Oszillator stören und zu unberechenbarem Verhalten des Mikros bzw. des Programms führen. Projekt verwandt mit deiner Anwendung: http://spritesmods.com/?art=autobaud Viel Erfolg bei der Lösung - lass die Welt wissen, woran es liegt/lag!
A. K. schrieb: > Wo kommt die her? Mal eine alternative Spannungsquelle ausprobiert? Als Spannungsquelle dient ein altes 5V-Steckernetzteil, am Labornetzteil sieht es aber nicht anders aus. Ich versuche gleich nochmal den GND-Anschluss näher an den Quaz zu bringen.
J. L. schrieb: > Ich versuche gleich nochmal den > GND-Anschluss näher an den Quaz zu bringen. Vor allem sollte GND für die Quarz Kondensatoren nicht wie in deinem Layout quer über die Platine geführt werden und noch für andres verwendet werden.
Guest schrieb: > Vor allem sollte GND für die Quarz Kondensatoren nicht wie in deinem > Layout quer über die Platine geführt werden und noch für andres > verwendet werden. Ich habe den GND vom Netzteil mittlerweile direkt zwischen die Kondensatoren am Netzteil gelötet, noch kürzer kann der Weg nun nicht mehr werden. Besserung hat es nicht gebracht. Ich mache mir nochmal Gedanken über ein anderes, lochrasterfähiges Layout.
hast Du mal testweise die Abblockkondensator direkt an pin 10 und 20 geloetet? Im Layout sind die ziemlich weit weg.
asdf schrieb: > hast Du mal testweise die Abblockkondensator direkt an pin 10 und 20 > geloetet? Im Layout sind die ziemlich weit weg. Habe ich vorhin auch mal versucht, jeweils einen 100nF-Kondensator quer über die beiden Controller. Keine Besserung. Normalerweise setze ich die Kondensatoren eigentlich unter den Controller in den Sockel.
J. L. schrieb: > Die Schaltung läuft beim Einschalten nicht immer an bzw. das Programm > bleibt hängen Du hast doch 3 LEDs, setze die an verschiedenen Stellen und grenze so den Punkt ein, wo das Programm stehen bleibt. Ich hätte das besser mit einem MC gemacht, d.h. die 2. UART in Software. Oder nen ATmega164 genommen. Kommunikation zwischen 2 MCs ist oft recht kompliziert. Wenn man sich da kein gutes Protokoll ausgedacht hat, kann es schnell zu Blockierungen kommen. Und jedes Gerät kann Störimpulse beim Ein-/Ausschalten auf der RS-232 erzeugen. Das Protokoll sollte daher mit beliebiger Einschaltreihenfolge von PC, Konverter und Endgerät klarkommen bzw. nach Abbrüchen wieder aufsetzen können. Das Layout sieht o.k. aus.
Peter Dannegger schrieb: > Du hast doch 3 LEDs, setze die an verschiedenen Stellen und grenze so > den Punkt ein, wo das Programm stehen bleibt. Dafür sind sie auch mehr oder weniger da. Die grüne LED ist die Heartbeat-LED und soll mit 0,5 Hz blinken. Die gelbe LED zeigt an das der Controller Daten sendet (Sendeinterrupt). Die rote LED zeigt an das der Controller Daten via UART empfangen hat, aber noch auf Abschluss des jeweiligen Kommandos bzw. Strings (Carriage Return) wartet. In meinem Fall bleibt mal beim einen, mal beim anderen Controller die LED entweder aus oder ist dauerhaft an. Peter Dannegger schrieb: > Kommunikation zwischen 2 MCs ist oft recht kompliziert. Wenn man sich da > kein gutes Protokoll ausgedacht hat, kann es schnell zu Blockierungen > kommen. Eine wirkliche Kommunikation zwischen den beiden Controllern gibt es abgesehen von der ATTN- und der ACK-Leitung nicht. Adam setzt "ATTN" wenn er einen bestimmten String empfangen hat und leitet ihn daraufhin an das Endgerät weiter. Dadurch das ATTN gesetzt ist weiß Eva nun das ein neues Startbit zu vermessen ist. Eva setzt ACK sobald sie das ATTN erkannt hat, Adam setzt daraufhin das ATTN zurück. Ansonsten spielen die beiden Controller einfach nur Buffer für krude Baudraten.
Ich muss meinen alten Thred leider nochmal ausgraben, da sich mein Problem leider noch immer hat nicht lösen lassen. Ich habe mittlerweile eine neue, geätzte Platine mit großzügigen Masseflächen, die 100nF Kondensatoren sind durch die neue Platine näher an den Controllern und auch einen neuen Quarz habe ich mittlerweile verbaut - diesmal jedoch mit 12 MHz. Als Lastkapazitäten habe ich mittlerweile 10 pF, 22 pF und 32 pF durch - am Anlaufverhalten ändern sie alle nichts. Was ich mittlerweile herausgefunden habe: Das Problem tritt nur auf wenn ich die CKOUT-Fuse setze um den Takt an meinem zweiten Controller weiterzureichen. Es spielt dabei keine Rolle ob am anderen Ende wirklich ein Controller sitzt oder nicht, selbst wenn ich den Pin des Hauptcontrollers wegbiege so das das CKOUT-Signal ins Leere läuft, läuft der Controller nicht an. Um auszuschließen das der Fehler durch das Programm hervorgerufen wird habe ich selbiges auch schon soweit abgespeckt das nurnoch die grüne Blink-LED angesteuert wird - das Fehlerbild bleibt das gleiche. Hat noch jemand Ideen?
J. L. schrieb: > Das Problem tritt nur auf wenn > ich die CKOUT-Fuse setze um den Takt an meinem zweiten Controller > weiterzureichen. Hast Du Port D2 auch als Ausgang definiert? MfG Paul
Paul Baumann schrieb: > Hast Du Port D2 auch als Ausgang definiert? Egal ob ich PD2 auf Ausgang oder setze oder nicht, das Verhalten ändert sich nicht.
Vorsichtige Frage: Hast Du immer nur den Gleichen benutzt, oder auch mal einen Neuen/Anderen Kontroller? MfG Paul
Zeig mal das Blinkprogramm. Mach mal an SCK einen Pullup (10k), nicht daß er durch Noise in den Programmiermodus springt.
Paul Baumann schrieb: > Vorsichtige Frage: Hast Du immer nur den Gleichen benutzt, oder auch > mal einen Neuen/Anderen Kontroller? Natürlich verschiedene, letztes Jahr bei Pollin gekauft. Peter Dannegger schrieb: > Zeig mal das Blinkprogramm. Kommt gleich.
So, hier im Anhang mein Minimalprogramm. Verhalten: CKOUT an und BOD aus: Controller läuft, LED blinkt CKOUT aus und BOD an: Controller läuft, LED blinkt CKOUT an und BOD an : Controller hängt, LED blinkt nicht und ist auch nicht an. Die Auslöseschwelle des BOD hat keinen Einfluss - egal ob 4,3 oder 1,8V - der Controller läuft nicht an. Ein Pullup an SCK hat keine Verbesserung gebracht (auch nicht bei entferntem, zweitem Controller). Edit: Bevor Fragen kommen: Die Versorgungsspannung ist auf dem Scope betrachtet sauber.
:
Bearbeitet durch User
Sind 16 MHz nicht etwas viel für die ..V-Version des ATTiny2313?
Warum eigentlich nicht ein Controller mit 2x UART ? Würde das nicht viel erleichtern ? :)
So: erstmal Asche auf mein Haupt... Nach einem genauen Blick auf den Controller habe ich hier die neue A-Version des 2313 vor mir und nicht die alte Version ohne A. Bekannt ist mir das die A-Version zwei neue Interruptvektoren hat und die Startadresse für das Programm daher bei 0x15 liegen muss und nicht bei 0x13, das habe ich daher direkt korrigiert. Hat aber leider keine Verbesserung gebracht. Ich habe allerdings noch einen letzten 2313 ohne "A" und ohne V (also die alte, schnelle Version) in meinem Fundus gefunden und ihn prompt in die Schaltung gesteckt - funktioniert auf Anhieb in allen Konfigurationsvarianten einwandfrei. Ich frage mich jetzt nur: was ist an der neuen Version so anders das sie in meiner Schaltung nicht mehr funktionieren mag? Die Appnote AVR533 habe ich schon durchgescrollt, so wie ich das sehe betreffen mich eigentlich nur die zwei neuen Interruptvektoren. Dieter Frohnapfel schrieb: > Sind 16 MHz nicht etwas viel für die ..V-Version des ATTiny2313? Ich habe die "nicht V"-Version. Matthias I. schrieb: > Warum eigentlich nicht ein Controller mit 2x UART ? Ich hatte einfach keinen passenden Vorrätig.
:
Bearbeitet durch User
Wenn Du nicht die V-Version hast, warum includierst Du dann iot2313v ? Ich nehme an, der Generator orientiert sich an Deiner Prozessorwahl - oder?
Dieter Frohnapfel schrieb: > Wenn Du nicht die V-Version hast, warum includierst Du dann iot2313v ? > Ich nehme an, der Generator orientiert sich an Deiner Prozessorwahl - > oder? Es mag etwas wirr klingen, aber das "v" hat nichts zu bedeuten - alle Include-Dateien haben das "v" am Ende. Selbst die Datei für den ATTiny2313A heißt "iot2313Av.h" - von dem gibt es laut Datenblatt nicht mal ne "v"-Version. Der Prozessortyp wird in den Projekteigenschaften angegeben, wobei ich dort nur den 2313 und nicht den 2313A angeben kann. Ich jedoch manuell die Startadresse des Programmes angeben um die zwei neuen Interruptvektoren der A-Version zu umschiffen. Aber selbst wenn ich das Programm an Adresse 0x15 starten lasse funktioniert es auf dem 2313A nicht. Aus der Appnote AVR533 (Unterschiede zwischen dem 2313 und dem 2313A) sind für mich aber keine Änderungen ersichtlich die zu dem beschriebenen Verhalten führen könnten. Abgesehen von der veränderten Startadresse.
:
Bearbeitet durch User
J. L. schrieb: > Der Quarz ist ausgeschlachtet und das sind die dazugehörigen > Kondensatoren. Ich habe Testweise jeweils weitere 12 pF parallel > angelötet, hat keine Verbesserung gebracht. Quarze sind mechanische Bauteile und gehen daher bei mechanischer Misshandlung (runterwerfen, zu lange und heiß Löten...) gerne kaputt. Vorschlag: Alten Quarz wegschmeißen und einen neuen Quarz oder ,noch besser, einen neuen Quarzoszillator einbauen. Hier ein paar Cent sparen zu wollen ist den Ärger nicht wert.
Schreiber schrieb: > Quarze sind mechanische Bauteile und gehen daher bei mechanischer > Misshandlung (runterwerfen, zu lange und heiß Löten...) gerne kaputt. > > Vorschlag: Alten Quarz wegschmeißen und einen neuen Quarz oder ,noch > besser, einen neuen Quarzoszillator einbauen. Ich zitiere mich dazu mal selbst: J. L. schrieb: > einen neuen Quarz habe ich mittlerweile > verbaut - diesmal jedoch mit 12 MHz. Als Lastkapazitäten habe ich > mittlerweile 10 pF, 22 pF und 32 pF durch - am Anlaufverhalten ändern > sie alle nichts. Einen neuen Quarz habe ich also schon verbaut. Und wie ebenfalls schon geschrieben: Das Problem tritt merkwürdeigerweise nur bei der A-Version des 2313 auf, bei der alten Version ohne A funktioniert es einwandfrei. Auch der alte ausgelötete 16MHz'ler funktioniert an dem alten 2313 einwandfrei. Ich verstehe nur nicht warum, laut der Appnote AVR533 sind nur zwei neue Interuptvektoren und einige neue Knfigurationsregister/Bits hinzugekommen. Davon fasse ich in meinem Programm jedoch nichts an.
:
Bearbeitet durch User
J. L. schrieb: > Einen neuen Quarz habe ich also schon verbaut. ok. J. L. schrieb: > Und wie ebenfalls schon > geschrieben: Das Problem tritt merkwürdeigerweise nur bei der A-Version > des 2313 auf, bei der alten Version ohne A funktioniert es einwandfrei. dann "erklär" dem Compiler doch mal, dass du einen 2313A und keinen von den alten 2313 verwendest. J. L. schrieb: > Ich verstehe nur nicht warum, laut der Appnote AVR533 sind nur zwei neue > Interuptvektoren und einige neue Knfigurationsregister/Bits > hinzugekommen. Davon fasse ich in meinem Programm jedoch nichts an. du nicht, aber weiß der Compiler, dass es diese Register und Interruptvektoren gibt und was er mit ihnen anfangen soll?!
J. L. schrieb: > Der Prozessortyp wird in den Projekteigenschaften angegeben, wobei ich > dort nur den 2313 und nicht den 2313A angeben kann. entv. hilft ein Update vom Compiler?
Schreiber schrieb: > du nicht, aber weiß der Compiler, dass es diese Register und > Interruptvektoren gibt und was er mit ihnen anfangen soll?! Die beiden zusätzlichen Vektoren sind nur relevant, wenn man die entsprechenden Interrupts auch aktiviert. Andernfalls werden die Vektoren nicht verwendet und anderweitiger Code an dieser Stelle stört nicht. Der Compiler fasst keine Registerbits an, es sei denn man fordert ihn dazu auf. Zusätzliche Bits sind mit einem alten Compiler zwar nicht symbolisch verwendbar, stören aber auch nicht. Andernfalls wäre die A Version nicht als Ersatz in bestehender Produktion verwendbar: "The ATtiny2313A is a functionally identical, drop-in replacement for the ATtiny2313."
:
Bearbeitet durch User
Schreiber schrieb: > du nicht, aber weiß der Compiler, dass es diese Register und > Interruptvektoren gibt und was er mit ihnen anfangen soll?! Selbst wenn ich die iot2313Av.h inkludiere bleibt das Verhalten gleich, ich wüsste auch nicht was sich ändern sollte. Die "neuen" Register waren vorher schon als Reserved gekennzeichnet und durften durch den Compiler nicht genutzt werden. Hätte er es getan hätte er sich eh schon längst von selbst disqualifiziert. Selbst wenn ich die neuen Register nicht bespiele müsste das Programm also kompatibel sein. Die neuen Register bieten nur neue Funktionen, sind aber von der "neuen Belegung" (sofern es sie vorher schon gab) kompatibel zu der "alten Belegung". Zumindest wenn ich mich nicht verlesen habe. A. K. schrieb: > Die Vektoren sind nur relevant, wenn man die entsprechenden Interrupts > auch aktiviert. Stimmt, das war mir völlig entfallen. Aber ja, beim Assembler-Programmieren ohne Interrupts hat man ja auch einfach bei 0x00 angefangen ohne zu Springen. Daher macht es dann auch keinen Unterschied ob ich den Start des Programms auf 0x13 lasse oder ihn auf 0x15 verschiebe.
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.