Hallo, ich habe einen Attiny 13A an dem man ja kein externes Quarz anschließen kann. Ich habe also den internen benutzt doch die SoftUart funktioniert nicht. Ist er falsch eingestellt oder kann dieser ATtiny diese "große" Aufgabe nicht schaffen? Ich bin mit meinem Wissen am Ende und hoffe auf Antwort: Code: $regfile = "ATtiny13A.DAT" $crystal = 9600000 $hwstack = 8 $swstack = 16 $framesize = 32 Open "comb.3:9600,8,n,1" For Output As #1 Open "comb.4:9600,8,n,1" For Input As #2 Dim Empfangen As String * 4 Config Portb.0 = Output Config Portb.1 = Output Do Input #2 , Empfangen If Empfangen = "up" Then 'Portb.1 = 0 'Portb.0 = 1 Print #1 , "Finishes" End If 'If Empfangen = "down" Then 'Portb.0 = 0 'Portb.1 = 1 'End If Loop LG
Toni Nachname schrieb: > $crystal = 9600000 Hast du auch die entsprechende Fuse eingestellt? Sonst läuft dein Controller mir 1,2MHz und die DÜ entsprechend mit 1200 statt 9600Bd. mfg.
Angehängte Dateien:
-
Fuses.png
36 KB
Hallo Thomas, ich habe die Fusebits wie es im Datenblatt steht gesetzt (ich hoffe das ist so richtig mache das sonst mit atmel studio). Vieleicht findest du ja noch einen Fehler. LG
Das Bild gehört aber nicht zu einem Attiny13. Denn da gibt es kein JTAGEN. Sowas hat kein Tiny. Entscheidend ist die CKDIV8-Fuse. Da muss das Häkchen weg. Man kann das auch per Software einstellen. Dabei muss ein bestimmtes Timing eingehalten werden. Für C gibt es dafür eine Headerdatei mit entsprechenden Makros. Ob es das in Bascom gibt, weiss ich nicht. Steht unter "6.3 System Clock Prescaler" im Datenblatt. Wie schon gesagt ich kenne mich mit Bascom nicht aus. Möglich, dass es an etwas anderem liegt. Aber ein falscher Takt ist der mit Abstand häufigste Fehler bei UART-Problemen. mfg.
Oh Entschuldigung ich hab da wohl den falschen Controller drin gehabt aber ich habe CKDIV8 noch drin also mach ich das Häkchen weg läufts? Das wäre ja einfach wenns läuft/ nicht läuft melde ich mich LG
Toni Nachname schrieb: > ich habe einen Attiny 13A an dem man ja kein externes Quarz anschließen > kann. Ich habe also den internen benutzt Nein, hast du nicht. Kannst du garnicht. Einfach deshalb, weil es keinen internen Quarz gibt. Intern gibt's nur einen (recht ungenauen) RC-Oszillator. > doch die SoftUart funktioniert > nicht. Ist er falsch eingestellt oder kann dieser ATtiny diese "große" > Aufgabe nicht schaffen? Natürlich kann er die schaffen. Dazu sind nur zwei Sachen nötig: Eine sinnvolle Konfiguration der Bitrate und eine sinnvolle Kalibrierung des Taktes des RC-Oszillators.
Für UART besteht die Anforderung, dass die Taktfrequenz nicht mehr als etwa 2% vom Soll abweicht. Mit dem internen RC-Oszillator des atiny13 kann es passieren, dass die Abweichung wegen Spannungsabweichung, Exemplarstreuung, früherer Programmierung der Frequenz-fuses usw. größer ist. Um 1% Genaugkeit zu erreichen muss man die Oszillatorfrequenz justieren, dazu sind die oscillator-calbration-fuses zu verstellen. Natürlich kann es auch sein, dass der Takt um den Faktor 8 niedriger ist, denn im Auslieferungszustand ist noch die Teilung des 9600kHz-Taktes eingeschaltet, damit der Chip gemütlich mit ca. 1,2 MHz werkelt.
Peter R. schrieb: > dazu sind die > oscillator-calbration-fuses zu verstellen. Es gibt keine oscillator-calbration-fuses, es gibt das OSCCAL Register, das ist flüchtig und muss im Startupcode geladen werden.
Hallo, ich werde den kleinen dann mal Kalibrieren! Aber wie kann ich denn den internen RC Oszillator checken weil der tiny13A hat ja keinen CKOUT also kann ich das Signal nicht nach draußen leiten. Wenn jmd. einen Rat weiß bitte schreiben aber trotzdem schon mal DANKE:D LG
Toni Nachname schrieb: > Aber wie kann ich denn den > internen RC Oszillator checken weil der tiny13A hat ja keinen CKOUT also > kann ich das Signal nicht nach draußen leiten. Einen Timer laufen lassen, der ein PWM-Signal erzeugt, die Frequenz ist über die Auflösung, und den Vorteiler mit dem Systemtakt verbunden. Wenn die PWM-Ausgänge nicht nutzbar sind, den Timer beim Überlauf einen Interrupt auslösen lassen, und in diesem Interrupt einen Ausgangs-Pin toggeln. Mit freundlichen Grüßen - Martin
Toni Nachname schrieb: > Aber wie kann ich denn den > internen RC Oszillator checken Es gibt Gerüchte, dass Atmel dazu Application Notes veröffentlicht hat. http://www.atmel.com/products/microcontrollers/avr/tinyavr.aspx?tab=documents Dann muss man auf der Seite nur nach "calibration" suchen und wird mehrfach fündig.
Hi Toni... Es gibt mehrere Möglichkeiten: 1.) Du kannst bei "Crystal" den Wert verändern. Das ändert nix am Takt, aber der Umrechnungsfaktor des Compilers für die Baudrate wird dadurch geändert. Wobei der Wert bei "Crystal" jener Wert ist, der nach dem System-Prescaler ansteht. Den System-Prescaler kannst du z.B. unter Bascom so einstellen: Clkpr = 128 Clkpr = 0 Die erste Zeile bleibt immer unverändert. Mit der 2. Zeile stellst du den Teilerfaktor entsprechend dem Datenblatt ein. Im obigen Bsp. läuft er nun mit Teiler 1, also ein Attiny der per Fuse(clkdiv/8) auf 1MHz getaktet war, läuft nun mit 8MHz CPU-Takt, ohne die Fuse zu ändern. 2.) Du kannst statt __Open "comb.3:9600,8,n,1" For Output As #1__ auch __Open "comb.3:9423,8,n,1" For Output As #1___ schreiben, also einen krummen Wert für die Baudrate einsetzen. Das bewirkt dasselbe wie bei 1.) Der Umrechnungsfaktor wird an den krummen CPU-Takt angepasst, so dass de facto eine korrekte Baudrate an den Ausgängen anliegt. 3.) Du kanns über das OSCCAL-Register den Takt des RC-Oszillators kalibrieren. Das ist die "sauberste" Methode, weil damit die Werte im Code und die Baudrate am Port nachher auch identisch sind. Das Kalibrierern geht auch innerhalb des Codes in einer Subroutine und kann durch Einbeziehen einer externen Referenz automatisiert werden. Gruss S.
Toni Nachname schrieb: > Fuses.png Was soll uns dieses zu mehr als 90% weiße Bitmap sagen? Bist du nicht in der Lage, die beiden kleinen inhalttragenden Ausschnitte vernünftig zusammen zu schieben?
Toni Nachname schrieb: > $crystal = 9600000 Taktfrequenz am Tiny 9.6Mhz ?? Der kann intern maximal mit 8Mhz taktet. Stell mal $crystal = 8000000 ein, und alle Fuses kontrollieren dann läufts !
Table 6.1, Page 24 Table 6-1. Device Clocking Options Select Device Clocking Option CKSEL[1:0](1) External Clock (see page 24) 00 Calibrated Internal 4.8/9.6 MHz Oscillator (see page 25) 01, 10 Internal 128 kHz Oscillator (see page 26) 11 --- 9.6MHz --- - es ist ein Tiny13A. Edit: Anhang ist passender, denke ich.
:
Bearbeitet durch User
Toni Nachname schrieb:
> ich werde den kleinen dann mal Kalibrieren!
Lass dich nicht verrückt machen. Der Oszillator ist bei 3V/25°C auf
9,6MHz kalibriert. Unter normalen Betriebsbedingungen klappt es damit
bei 9600Bd auch mit dem UART. Zumal die 9,6MHz durch 9600 glatt teilbar
sind und der systematische Fehler damit 0 ist.
Das musst du natürlich auch berücksichtigen, wenn du den Soft-UART von
woanders übernommen hast. Die Einstellungen dort sind dann zumeist für
8MHz. Der Tiny13 ist so ziemlich der einzige Controller, dessen interner
Oszillator nicht mit 8MHz läuft.
Kontrolliere ob Bascom das hier:1 | Open "comb.3:9600,8,n,1" For Output As #1 |
auch berücksichtigt und richtig rechnet. mfg.
:
Bearbeitet durch User
Thomas Eckmann schrieb: > Lass dich nicht verrückt machen. Der Oszillator ist bei 3V/25°C auf > 9,6MHz kalibriert. Unter normalen Betriebsbedingungen klappt es damit Die harte unbarmherzige Realität jedoch lehrt einen dann doch recht schnell (und zwar genau dann wenn man mal eine Handvoll Platinen damit baut unter der Annahme daß das schon passt) daß es bei den Tinies offenbar übelste Streuungen gibt und Abweichungen von 10% und mehr durchaus keine Seltenheit sind. Abhilfe schafft dann wirklich nur für jedes einzelne Exemplar selbst nochmal einen Kalibrierungswert zu ermitteln, im EEPROM abzulegen und beim Start in das OSCCAL-Register zu schreiben. Bei einem privaten Einzelstück fällt der Zusatzaufwand jedoch nicht so sehr ins Gewicht, man muss aber damit rechnen daß das nötig werden könnte.
Falls du einen USB_to_seriell Adapter am PC hast, versuch mal die Polarität mit "inverted" zu tauschen. Open "comb.3:9600,8,n,1,inverted" For Output As #1
Bernd K. schrieb: > Die harte unbarmherzige Realität jedoch lehrt einen dann doch recht > schnell (und zwar genau dann wenn man mal eine Handvoll Platinen damit > baut unter der Annahme daß das schon passt) daß es bei den Tinies > offenbar übelste Streuungen gibt und Abweichungen von 10% und mehr > durchaus keine Seltenheit sind. Ich weiss ja nicht, mit was für alten Gurken du rumhantierst. Aber die Exemplarstreuungen sind nichts Neues. Und genau deswegen werden sie vom Hersteller kalibriert ausgeliefert. Unter dieser Bedingung, 3V/25°C, müssen die Controller nicht nachkalibriert werden. Du bist hier nicht der einzige, der damit seine Erfahrungen hat. Weicht man von diesen Normalbedingungen ab, ist eine Kalibrierung u.U. erforderlich. mfg.
Hallo, Ich habe jetzt den 4,8 MHz Rc Oszillator mit dem Vorteil er 8 genommen damit läuft der Controller mit dem Tim er ziemlich genau. Werde später weitet experimentieren. Gruss
Hallo, der Timer läuft Prima die Softuart leider überhaupt nicht da kommt absoluter Müll raus! Ich bin so langsam ratlos ich hab beides nebeneinander laufen lassen Timer läuft sehr genau die softuart nicht. Bitte helft mir. Gruss
Toni Nachname schrieb: > Timer läuft sehr genau die softuart nicht. Dann wäre es Zeit, ein Oszilloskop dranzuklemmen. Alternativ einen pinkompatiblen Controller mit besseren Features, also ATtiny25 & Co. nehmen. Dann kannst du statt der Soft-UART die USI nehmen, und selbst einen Quarz könnte er noch bedienen.
Hallo, ich habe ein Oszi dran gehabt sonst könnte ich ja nicht sagen dass es ziemlich genau ist. LG
Thomas Eckmann schrieb: > Ich weiss ja nicht, mit was für alten Gurken du rumhantierst. Aber die > Exemplarstreuungen sind nichts Neues. Und genau deswegen werden sie vom > Hersteller kalibriert ausgeliefert. Unter dieser Bedingung, 3V/25°C, > müssen die Controller nicht nachkalibriert werden. Krasser Blödsinn. Zum einen sind die Kalibrierbedingungen unterschiedlich, für sehr viele Typen wird z.B. auf 5V kalibriert. Beim konkreten Tiny13A sind es allerdings wirklich 3V/25°. Aber: für diese Kalibrierbedingungen verspricht die Werkskalibrierung nur, die Taktabweichung innerhalb von +-10% vom Sollwert zu halten. Siehe Tabelle 18-2 auf Seite 119 des Datenblatts. Und das ist natürlich viel zu viel für UART. Bei 8N1 z.B. kann dann über ein Datenwort die Abweichung schon bis zu einer volle Bitlänge betragen. Natürlich sorgt die Kurve der Normalverteilung dafür, daß für das Gros der Liefermenge die tatsächliche Abweichung weitaus geringer als 10% sein wird, aber man muß halt trotzdem immer damit rechnen, daß es einzelne Exemplare gibt, bei denen die erlaubten 10% tatsächlich fast vollständig ausgenutzt sind. So ist das halt mit der Wahrscheinlichkeit.
c-hater schrieb: > Aber: für diese Kalibrierbedingungen verspricht die Werkskalibrierung > nur, die Taktabweichung innerhalb von +-10% vom Sollwert zu halten. Das ist doch nur, damit es keine Garantiefälle gibt. ;-) In der Praxis habe ich noch keinen AVR erlebt, bei dem man (bei Kalibrierbedingungen natürlich) nicht in der Lage wäre, RS-232 „aus der Dose raus“ zu benutzen. Und ich habe schon einige Exemplare davon in den Fingern gehabt. Für eine Produktentwicklung würde ich mich sicher auch nicht drauf verlassen wollen, aber für eine Labor-Test-Schnittstelle (also nicht kundenrelevant) wäre es selbst in einem Produkt OK.
Jörg Wunsch schrieb: > In der Praxis habe ich noch keinen AVR erlebt, bei dem man (bei > Kalibrierbedingungen natürlich) nicht in der Lage wäre, RS-232 „aus > der Dose raus“ zu benutzen. ? wie bitte ich schon öfter sei es weil der Gegenspieler mit 115k daherkommt und 8 MHz oder 16MHz nicht wirklich passen. Wer keinen krummen Quarz anschliessen will oder mag kann evtl. mit "Trimmung" arbeiten um so ein Gespann doch noch zum Laufen zu bewegen.
Joachim B. schrieb: > sei es weil der Gegenspieler mit 115k daherkommt und 8 MHz oder 16MHz > nicht wirklich passen Das passt nicht nur nicht wirklich, sondern überhaupt nicht. Ob mit oder ohne Quarz. Aber das liegt nicht am Controller. Wenn du auf eine 28er Felge einen 26er Reifen ziehen willst und es nicht passt, ist doch auch nicht das Fahrrad schuld. mfg.
:
Bearbeitet durch User
Thomas Eckmann schrieb: > Das passt nicht nur nicht wirklich, sondern überhaupt nicht. Ob mit oder > ohne Quarz. Aber das liegt nicht am Controller. und was soll mir der Unfug sagen? Jörg Wunsch schrieb: > In der Praxis habe ich noch keinen AVR erlebt, bei dem man (bei > Kalibrierbedingungen natürlich) nicht in der Lage wäre, RS-232 „aus > der Dose raus“ zu benutzen. ich fand dem hier musste mal was hinzugefügt werden. Es gibt AVR wo man nicht in der Lage ist aus der Dose RS232 zu benutzen! nichts weiter.
Joachim B. schrieb: > und was soll mir der Unfug sagen? Was erdreistest du dich. Das ist beileibe kein Unfug. Joachim B. schrieb: > Es gibt AVR wo man nicht in der Lage ist aus der Dose RS232 zu benutzen! Aber nur, weil sie keinen UART haben. Nochmal: Es liegt nicht am Controller, wenn die Rahmenbedingungen nicht passen. mfg.
Joachim B. schrieb: > und was soll mir der Unfug sagen? Dass du Umgangsformen hast, die unter aller Kanone sind. > Es gibt AVR wo man nicht in der Lage ist aus der Dose RS232 zu benutzen! Klar, wenn der systematische Fehler einfach schon zu hoch ist, geht es nicht – auch nicht mit einem Quarz. Bis zu deinem Einwand hatten wir uns jedoch nur über die Parameterstreuungen des internen Taktes unterhalten, also über zufällige Fehler.
Hallo, ich habe jetzt zwei verschiedene ATTiny13A getestet aber bei beiden dass selbe ich bekomme nur irgendeinen Müll in der Konsole angezeigt. Das hab ich bis jetzt versucht: verschiedene interne Frequenzen(am Oszillator), verschiede Baudraten, verschiedene Terminals, verschiedene Usb <-> Uart Converter, verschiedene Progger aber bei allen das selbe Problem! Ich werde jetzt mal den kleinen von meinem Fertig Testboard runter nehmen und auf einem normalen Steckbrett testen. Wenn ihr noch einen Ratschlag habt sagt das ruhig. LG
Toni Nachname schrieb: > ich bekomme nur irgendeinen Müll in der Konsole angezeigt Hast du denn die Implementierung der Soft-UART mal verifiziert? Wenn du schreibst, dass ein Timertakt ordentliche Werte liefert, die Soft-UART jedoch Müll, dann kann es doch eigentlich nur ein Problem mit der Software sein. Hast du denn mal die UART-Bitzeiten mit dem Oszi gemessen?
Hallo, nochmal der kleine Nachtrag: Auf dem Stckbrett das selbe ich denke diese Serie Controller kommt bei mir nicht mehr ins Haus aber trotzdem möchte ich gerne wissen warum eine einfache Softuart bei einem neuen Controller nicht läuft?? LG
Hallo Jörg, dumme Frage aber wie mache ich das? Ich habe den Code mit ein paar Änderrungen(Regfile, Crystal Ports) zum laufen bekommen! Aber denkt ihr dass das bei meinem kleinen der Fehler ist? LG
Toni Nachname schrieb: > Wenn ihr noch einen Ratschlag habt sagt das ruhig. Hör auf, im Nebel zu stochern, sondern geh systematisch vor. Dass dein interner Takt jetzt OK zu sein scheint, ist die eine Sache. Aber mit der Ausgabe auf ein Terminal und dem Resultat, dass irgenein Müll angezeigt wird, kommst du nicht weiter. Lass deinen Controller kontinuierlich 0x55 ausgeben und guck dir das auf dem Oszi an. Bei 9600Bd ergibt das eine Frequenz, 1:1 Rechteck, von 4,8KHz am UART-Ausgang. Nur wenn dem so ist, funktioniert auch deine Datenübertragung. mfg.
:
Bearbeitet durch User
Angehängte Dateien:
-
MAP001.png
2,5 KB -
MAP002.png
2,7 KB -
MAP003.png
2,6 KB
Hallo, ich habe jetzt mal ein paar Fotos von der Dataenübertrageung gemacht. Es wird nur "Text:" übertragen. LG
Wenn die Flanken tatsächlich so flach sind, wie auf den Fotos zu sehen, dann ist es kein Wunder, dass eine RS-232 da nichts entziffern kann. An welcher Stelle ist das denn gemessen?
Jörg Wunsch schrieb: > Dass du Umgangsformen hast, die unter aller Kanone sind. das habe ich hier genauso empfunden: Thomas Eckmann schrieb: > Wenn du auf eine 28er Felge einen 26er Reifen ziehen willst und es nicht > passt, ist doch auch nicht das Fahrrad schuld. will er damit sagen das ich blöd bin? Jörg Wunsch schrieb: > Klar, wenn der systematische Fehler einfach schon zu hoch ist, geht > es nicht – auch nicht mit einem Quarz. Das ist mir klar und steht in keinem Widerspruch das nicht alles out of the Box funktioniert, nicht funktionieren kann. Jörg Wunsch schrieb: > Bis zu deinem Einwand hatten > wir uns jedoch nur über die Parameterstreuungen des internen Taktes > unterhalten, also über zufällige Fehler. tut mir leid das es sich für mich im nachinein wie eine Ausrede anhört, dein Satz war einfach zu allgemein formuliert. Jörg Wunsch schrieb: > In der Praxis habe ich noch keinen AVR erlebt, bei dem man (bei > Kalibrierbedingungen natürlich) nicht in der Lage wäre, RS-232 „aus > der Dose raus“ zu benutzen. trotzdem war das "Gespräch" nützlich weil man mit dem internen + Kalibrierung evtl. den UART hinziehen kann das die Toleranz dann doch noch passt.
:
Bearbeitet durch User
Hallo, es läuft:D ich habe wohl immer die Falschen Einstellungen bei den Fuses getroffen jedenfalls läuft es jetzt:D vielen vielen Dank für eure HILFE. LG
Toni Nachname schrieb: > es läuft:D ich habe wohl immer die Falschen Einstellungen bei den Fuses > getroffen jedenfalls läuft es jetzt: Na, hoffentlich auch stabil. Die Signale auf Bild 2 und 3 sehen ziemlich wacklig aus. Da hat bestimmt der Sturm die Amplituden zerzaust. ;-) MfG Paul
Das erste Bild sieht ja noch brauchbar aus, aber die anderen Beiden sind ja fürchterlich! Was sind das da für 'halbe' Bits. Kann das sein daß da Hardware und Software nicht richtig funktioniert? Sind da 220kOhm Angstwiderstände in den Leitungen? :-) Oder beim Messen mit dem Oszi nur zu weit reingezoomt, und es fehlen die Messpunkte? Mit freundlichen Grüßen - Martin
Joachim B. schrieb: > dein Satz war einfach zu allgemein formuliert. Aber nur, wenn man ihn aus dem Kontext der vorangegangenen Diskussion reißt. Martin Schlüter schrieb: > Oder beim Messen mit dem Oszi nur zu weit reingezoomt, und es fehlen die > Messpunkte? Stimmt, das wird es sein. Schön, dass es nun funktioniert!
Toni Nachname schrieb: > Hallo, > es läuft:D ich habe wohl immer die Falschen Einstellungen bei den Fuses > getroffen jedenfalls läuft es jetzt:D vielen vielen Dank für eure HILFE. > > LG Läuft der Controller denn jetzt mit 9,6MHz? Zwischendurch hattest du ja auch schon einen Teilerfolg mit 4,8MHz vermeldet. Aber Hauptsache es geht jetzt endlich. mfg.
:
Bearbeitet durch User
Hallo Thomas, er läuft jetzt mit 9,6 Mhz habe auch schon die neue Schaltung für den Kleinen fertig läuft auch da prima supi Danke. Mit dem Oszi bin ich Einsteiger und hab da noch nicht so viele Erfahrungen mit aber ich wollte euch die Bilder nicht verenthalten. LG
Jörg Wunsch schrieb: > Für eine Produktentwicklung würde ich mich sicher auch nicht drauf > verlassen wollen Und genau bei sowas ist es mir mal um die Ohren geflogen. Zum Glück konnte ich es elegant per Software wieder gerade biegen, indem ich beim Einschalten für kurze Zeit auf ein genau definiertes Rechtecksignal von 8 Bitlängen low und langer Pause dazwischen am RX gewartet habe (zu erzeugen mit einem PC-USB-Seriell-Adapter in der Produktion) um damit kurzerhand eine automatische Nachkalibrierung beim ersten Einschalten (oder bei Bedarf später jederzeit wieder) durchführen und im EEPROM speichern zu können ohne noch irgendwas an der Hardware ändern zu müssen. Seitdem nur noch Quarz.
Bernd K. schrieb: > Seitdem nur noch Quarz. Gibt auch andere Alternativen, beispielsweise als erstes Zeichen vom Host ein \r erwarten und dessen Timing auswerten. Ist ein bisschen wie die automatische Baudratenerkennung anhand des "AT" bei einem Modem.
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.