Hallo Mikrokontrollergemeinde, ich habe ein Problem mit dem Umstieg vom leider abgekündigten AT90S2313 auf den ATtiny2313. Aber erst mal die Vorgeschichte, bevor ich konkret zu meinem Problem komme: mit einem AT90S2313 habe ich eine 128 Kanal Phasenanschnittssteuerung weiterentwickelt, die ihren Ursprung im Elektor-Magazin hat. Da der AT90S2313 z.B. in den USA und Kanada schon nicht mehr verfügbar ist und auch bei uns irgendwann die Segel streicht, möchte ich den Sourcecode für den ATtiny2313 angleichen. Mit AVRStudio 4 wird der Code wunderbar kompiliert (ich nutze den AT90S2313-Code nur mit tn2313def.inc, in der ja schon Register, wie USR usw. schon in UCSRA usw. zur Kompatibilität umbenannt werden). Nach dem flashen des ATtiny bootet der auch schön und die Status-LED leuchtet korrekt. Mein Problem liegt jetzt bei der Kommunikation mit dem Computer: Die ist über die RS232-Schnittstelle und dem UART der Atmels (jetzt ja USART) realisiert. Es wird ein 6 Byte-Frame vom PC gesendet und vom Controller gecheckt. Wenn die 6 Bytes je 7 Daten-Bits und ein Bit für den Framestart haben, dann ist es korrekt und es wird die Adresse (über Schalter an PD3,PD4,PD5,PD6) mit vier Bits aus dem ersten Byte verglichen. Wenn das alles passt, soll die LED blinken und die internen Routinen werden mit neuen Daten gefüttert. Nun blinkt die LED nur hin und wieder und zwar auch zu falschen Adressen. Es wird auch nur murks in die Routinen geschickt, da irgendwann plötzlich eine angeschlossene Lampe wild blinkt. Meine Frage an euch: was muss ich im Sourcecode für Änderungen für den ATtiny2313 machen, damit die RS232-Kommunikation richtig läuft? Die Daten von Atmel haben mir nicht wirklich weitergeholfen, da ich in Assembler eher ein Anfänger bin und meine Hauptarbeit in der Windowssoftware liegt... Der ATtiny2313 läuft auf externem Quartztakt mit 8MHz, habe auch den internen Takt erfolglos versucht - scheint also leider wirklich am Quelltext zu liegen. wäre toll, wenn sich einer mal den Sourcecode im Anhang ansehen und mir ein paar Tipps geben könnte :) wer noch mehr Infos braucht: das PC_DIMMER-Projekt liegt auf http://www.pcdimmer.de
Sorry, ich habe den AT90S2313-Sourcecode mit angehängt, statt des ATtiny2313-Codes, aber einfach ".include "2313def.inc" durch ".include "tn2313def.inc" ersetzt denken - sonst sind die Codes ja identisch, da ich keine Unstimmigkeiten gefunden habe. :-/ tschüss, Christian
Mit "Daten von Atmel" meinte ich genau dieses Dokument... da steht letztendlich nur drin, dass im Tiny2313 neue Register drin sind, die alten nur neu heißen, aber sonst identisch angesprochen werden. Am Watchdog haben sie was getunt und die UART durch die neue USART ersetzt. Deswegen habe ich doch hier gepostet :) Ich kann keine, für mich relevanten Daten aus dem Dokument ersehen. Alle Interrupts und Pins sind am gleichen Platz geblieben - ich verstehe nicht, warum der Tiny2313 mein RS232-Frame nicht richtig umsetzt... gute Nacht, Christian :)
guten Morgen :) ist das nicht ungerecht, so früh aufstehen zu müssen - und das am Samstag vor Pfingsten? versuch doch probehalber mal, was zu senden, dann wirst du sehen, ob zumindest der Baudratenkram stimmt. Ich habe bis jetzt ein Projekt von 2313 auf Tiny2313 umgestellt. Änderungen: UCSRA/B, UCSRC, UBRRH/L. Wenn ich mich recht erinnere, war an den Interruptvektoren auch was zu drehen. Zu guter Letzt: es gibt eine fuse CKDIV8, die kann dir auch jedes timing kaputtmachen :-)
Tja, senden klappt ja, aber völlig unkontrolliert. Die Receive LED soll ja bei jedem korrekt empfangenen RS232-Frame blinken, was sie mit dem Tiny2313 aber nur dann macht, wenn ich wie irre Frames mit meinem Programm verschicke. Also stimmt da was nicht. Die Änderungen (UCSRA/B, etc.) sind dahingehend doch nicht nötig, dass sie in der tn2313def.inc bereits drin sind. Wenn ich USR usw. schreibe, wird das automtisch durch diese Datei korrigiert... Was muss ich denn an den Interruptverktoren ändern? Kann ich überhaupt wie gewohnt die Pins abfragen (PD0-PDx)?? An der Taktteilung wird es nicht liegen - habe sie mit AVRProg 1.40 auf vollen 8MHz externen XTAL-Takt geschaltet! bis denn, Christian
Hallo, hat denn keiner einen anderen Tipp für mich? Wenigstens einen Ansatz, was ich im Quelltext falsch habe? Im Internet scheint es (noch) keine konkreten Infos zum ATtiny2313 zu geben, sodass ich nur hier Infos erhoffen kann :D Vielleicht hat ja auch einer einen fertigen Sourcecode (egal wofür) für nen ATtiny2313, wo ich mal schauen kann, wie man ne USART für den Tiny aufbaut, oder wie die Source aussieht. besten Dank und schönen Abend noch, Christian :)
also hier mal der noch nicht fertige code für mein zprog der läuft mit einem externen 15 MHz takt. ich denke mal das das dumme ckdiv8 fuse ist... wie hast du den tiny mit avrprog programmiert (taucht in der 1.4 nicht auf)
Nun, erst mal besten Dank für den Code! :) Werde da mal reinschaun. Mit Klaus Leidingers AVR910-Programmer habe ich einfach den ATtiny2313 als ATtiny26 beschrieben (letzte Einstellung in AVRProg 1.40. Damit klappts offensichtlich (kam jedenfalls keine Fehlermeldung g) ansonsten habe ich auch avrdude, aber dafür bin ich zu bequem ich kann allerdings mit AVRProg die ckdiv8-Fuse NICHT explizit ausschalten, allerdings müsste doch mit dem Umschalten auf externen XTAL-Takt diese Taktteilung doch weg sein!? Also, ich schau mir den Sourcecode mal an, vielleicht finde ich ja dann das Problem ;) nochmals danke! Christian
das ist es ja wenn du das fuse nicht wegbekommst, geht das auch mit dem externen Quarz nicht. die teilt den takt immer (hab mich da auch gewundert, ... , aber es es so) also wirst du dann doch avrdude oder ähnliches nehmen und die fuse wegmachen müssen. (oder die 8x mit in die taktung einrechnen) wenn du noch ein paar widerstände und zdioden und ein hw uart am pc hast, dann bau dir ein si prog und nimm ponyprog das ist zwar auch etwas umständlich aber geht immer noch. ODER du nimmst ein terminalprogramm wie z.B. hyperterminal und ein gerät, dass eine uart-spi bridge hat (der "new universal command" müsste auch gehen - der ist schon drin) und gibst die spi-programm befehle per hand ein. (deshalb will diesen befehl unbedingt in meinen programmer einbauen - pc software ist schneller aktualisiert als die programmer firmware - und der programmer kann dann auch eeproms und so 'n zeug beschreiben.) viel erfolg
Den Clock Prescaler kann man zur Laufzeit umstellen. So läuft der Tiny2313 mit vollem Takt: ldi r16,$80 out CLKPR,r16 clr r16 out CLKPR,r16 Gruß Thomas
Das werde ich gleich mal testen! Besten Dank! :) Ich habe es mittlerweile auch geschafft, dass mein RS232 Rahmen komplett gelesen wird und die Receive-LED richtig blinkt, aber die ZeroCrossing-Detection-Routine läuft irgendwie nicht... das wird dann ja wohl am Takt liegen... mal sehen Bis denn, Christian
hmm, wenn ich die obigen vier Zeilen in die Reset-Routine (nur beim booten) reinbau, dann klappt der RS232-Empfang wieder nicht. Nur wenn ich wie wild Daten verschicke, dann klappts irgendwann ich lade mir nochmal ne andere Doku zum ATtiny2313 - ich dachte Attiny2313 und AT90S2313 wären bis auf Zusatzregister kompatibel - so ein Mist... ich geb bald auf, Christian
naja du musst natürlich wieder die frequenzeinstellung im code anpassen! sonst gehts nicht!
mein Code ist ja für 8MHz, ich habe nen externen 8MHz Quarz dran. Ohne Taktteilung müsste dann doch für den Code die richtige Frequenz anliegen... Delphi zu programmieren ist leichter als Assembler, oder? lach ich tüftel noch ein bisschen rum, falls aber sich einer erbarmt und mir meinen Quelltext anpasst....... :D bis denn, danke nochmal für die Hilfe. Chris
Salve,
das hier ist jetzt kein wirklich konstruktiver Beitrag, aber ich wollte
nur mal bescheidsagen, daß ich meinen alten ("Crystal") Dimmer (auch
mit RS232) ohne irgendwelche Änderungen auf den Tiny übertragen konnte.
Das einzige, was ich machen mußte, war die Low-Fuse so einstellen, daß
er sich wie der alte 2313 verhält. Der Code ist identisch, auch das
alte 2313 Includefile hab ich so drin gelassen.
Das neueste Release unterstützt den ATtiny2313 daher offiziell:
http://sourceforge.net/project/showfiles.php?group_id=80137&package_id=81709
Es wundert mich, daß es bei Dir nicht funktioniert. Bei mir läuft der
Tiny inzwischen seit Wochen ohne irgendwelche Unterschiede (RS232
klappt einwandfrei, IR-Eingang und Nullerkennung ebenfalls) zum alten
2313.
Wie ist denn Deine Low-Fuse eingestellt?
Mir fällt grad was ein... hat der Tiny nicht auch zwei RX-Puffer? Da
muß man die I/O-Register in einer festgelegten Reihenfolge auslesen.
Nur so als Idee... hab Deinen Source jetzt nicht angesehen.
Viel Erfolg bei der Suche!
Mark
Hi Mikrocontrollergemeinde, nachdem ich seit Mai diesen Jahres erneut stundenlang wieder über meinem Problem mit dem Tiny2313 gesessen habe, bin ich endlich auf die Lösung gekommen. Da andere Leute sicher auch mal zu diesem Problem kommen werden, möchte ich nun hier kurz erläutern, wie ich meinen AT90S2313 Code unter dem ATTiny2313 zum laufen bekommen habe. Das Problem waren die Fusebits, die laut doc4298.pdf von Atmel angeglichen werden müssen. Es lag, wie schon vermutet, an dem ClockDiv, der den 8MHz Takt auf 1MHz runterschraubt. Allerdings war ich bis eben nicht in der Lage, diese mit AVRdude zu verändern. Vorgehensweise: 1) Textdatei mit Notepad erstellen und "0xDC" bzw. "11011100" eintragen (CLKDIV wech und CLKSEL AT90S2313 kompatibel machen). 2) Datei nicht als ANSI, sondern als Unicode(!!!)-Datei abspeichern (hier: "attiny2313patch"). Darauf bin ich erst SEEEHR spät gekommen. 3) in der Kommandozeile von Windows folgenden Befehl eingeben: "avrdude -p t2313 -c avr910 -C avrdude.conf -P com1 -U lfuse:w:attiny2313patch" 4) Freuen, dass alles so einfach war und keiner das gesagt hat. Ich hoffe, das hilft verzweifelten Suchern, wie ich einer war g PS: im Anhang hängt eine Zip-File, in der AVRdude und eine kleine Batchfile drin sind, mit denen man den Tiny2313 patchen kann. beste Grüße und nochmals danke an alle Ideengeber, Christian Nöding endlich ist dieser Thread (jedenfalls für mich) "CLOSED"
Fuse setzen geht auch einfacher. zB: low=0x9F, hi=0xC9: avrdude .... -U lfuse:w:0x9f:m -U hfuse:w:0xc9:m
Das hatte bei mir nicht hingehauen, da er immer motzte, dass die Datei(?) in einem ungültigen Zustand war. Er nam die 0xc9 nicht als Hex-Wert, sondern als Dateiname. Oder ändert das ":m" dahinter was? Das hatte ich nicht versucht. Das kann ich beim nächsten Flashen mal probieren :) Danke für den Tipp! tschö, Christian
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.