Hallo Leute, mein Mega32 ist voll, jetzt suche ich einen pin und register kompatiblen Chip mit mehr Speicher, leider werde ich bei der AVR-Auflistung nicht schlau. Ich suche im TQFP-Design....weiß da jemand was? Vielen Dank.
Auf auf die Gefahr hin, daß ich jetzt gehauen werde und an das Datenblat verwiesen werde: Besagte Chips sind auch Register-Kompatibel? Also meine mühsam angesammelte Bascom/Assembler Routine für RS232 etc kann übernommen werden?
>Auf auf die Gefahr hin, daß ich jetzt gehauen werde und an das Datenblat >verwiesen werde: Besagte Chips sind auch Register-Kompatibel? Hiermit erledigt;) Es ist doch nicht zu viel verlangt dort in Register Summary selber zu vergleichen, oder? Die sind nicht Register kompatibel.
Also die neue Atmel Seite ist ganz großer Mist, man findet rein garnichts. Und dann diese winzige Schlüsselloch-Ansicht auf nem 1920-er Monitor. Skalieren ist wohl ein Fremdwort für Atmel. Hier der Link: http://www.atmel.com/dyn/resources/prod_documents/doc8001.pdf Ich hab ihn nur deshalb finden können, weil ich weiß, daß es ihn früher gab. Ein Neuling hat absolut keine Chance, irgendwas zu finden. Und noch dazu die völlig unsinnige Unterscheidung Tiny und Mega, sind beides 100% AVRs, die Tiny habe nur weniger Pins. Das ist mit Abstand die schlechteste Webseite. Schäm dich, Atmel! Peter
Hallo Max (Gast) , ich denke, du machst einen Gedankenfehler! Die bisherigen Aussagen bezüglich M644 oder gar M1284 sind erstmal vollkommen richtig. Diese sind Pinkompatibel. >Besagte Chips sind auch Register-Kompatibel? Also meine >mühsam angesammelte Bascom/Assembler Routine für RS232 etc kann >übernommen werden? Da kann man nur sagen, dass diese Ersatztypen eben nicht vollkommen Registerkompatibel sind. Für deine Bascom Programme ist das kein Problem, da du diese Quelltexte ja einfach neu kompilieren kannst. Bei ASM mit einem Assemblercompiler verhält es sich genauso. problematisch wird es erst dann, wenn du nur ein HEX-File hast, welches für einen anderen MC compiliert wurde, oder wenn dein ASM.Code z.B. ein Inline Code ist oder du dir dein Assmbler selbst assemblert hatst. Gruss Klaus p.s. Es gibt da auch solche Infosheets von Atmel bezüglich der Migration.
Ich habe im Bascom direkt register angesprochen (naja, der die Software mal erstellt hat wohl eher;) ) Sowas zb: Reset Ucr.3 Reset Ucr.4 Ucsrb.txen = 1 Ucsrb.txen = 1 If Ucsra.rxc = 1 Then Get_byte = Udr Jetzt stellt sich die Frage, ob das so einfach übernommen werden kann...
Normalerweise (unterstreiche das Wort doppelt) müsste es genügen, wenn Du am Anfang des Bascom-Programmes den neuen Prozessor einträgst. Dann müsste nämlich Bascom die Registeradressen entsprechend umhängen. Vorrausgesetzt Du verwendest eine Version von Bascom, die den neuen Prozessor schon kennt und die für ihn nötige Parameterdatei mitgebracht hat. Du wirst aber nicht umhin kommen, es einfach auszuprobieren und dann zu schauen, was eventuell nicht funktioniert. Man nennt das auch Debugging. ;-) Gruß Trööt.
Die Register heissen in den Größeren Controllern auch anders. So wird aus UDR im mega32 ein UDR0 im mega644.
Peter Dannegger schrieb: > Und noch dazu die völlig unsinnige Unterscheidung Tiny und Mega, sind > beides 100% AVRs, die Tiny habe nur weniger Pins. Die Namen als solche sind sicher Marketing-Geklapper. Es gibt aus meiner Sicht aber schon deutliche Unterschiede. Tinys haben keine Hardware-Multiplikation, keinen UART (vom 2313 einmal abgesehen) und auch keine separaten SPI/TWI-Schnittstellen, sondern ein Universal-seriell-Dingsbums, und auch vergleichsweise wenig SRAM. Dass grundsätzliche Struktur und der Befehlssatz vom kleinsten Tiny bis zum größten Mega praktisch gleich sind, ändert nichts daran, dass es doch deutlich unterschiedliche Einsatzbereiche für diese beiden "Familien" gibt. Zur ursprünglichen Frage: Atmel würde sicher den Controllern nicht unterschiedliche Namen geben, wenn sie identisch wären. Irgendwelche Unterschiede wird es schon geben.
Hallo Autor: Max (Gast) , ich habe hier mal das Gefühl, dass die beteiligten Redner nicht soviel über Bascom wissen. natürlich sind solche Zugriffe wie Reset Ucr.3" sehr systemnah und werden beim Umstieg evt. Probleme machen. Insbesondere für die Timer gab es einige Umbenennungen. Allerdings sollte es auch für dich möglich sein, im Vergleich der Datenblätter die entsprechenden Befehle abzuändern. Gruss Klaus .. du kannst ja beim compilieren mal einfach nen anderen processor angeben. Dann bekommst du ja die fehlermeldungen.
Klaus De lisson schrieb: > ich habe hier mal das Gefühl, dass die beteiligten Redner > nicht soviel über Bascom wissen. > > natürlich sind solche Zugriffe wie Reset Ucr.3" sehr systemnah > und werden beim Umstieg evt. Probleme machen. ...und das gilt für alle Compiler, das ist kein BASCOM-spezifisches Problem. Nur wenn man die Bibliotheken benutzt, "weiß" der Compiler, was man mit der Hardware machen will und kann sich darauf einstellen. Man kann nicht beides haben: Extrem hardwarenah programmieren und von der Hardware abstrahieren. Selbst innerhalb einer Linie (z.B. ATMEGA48/88/168/328) sind die Controller nicht immer binär-kompatibel. Da bin ich reingefallen, als ich ein ATMEGA88-Compilat auf einem ATMEGA328 ausführen lassen wollte. Weil mehr als 8kB mit dem rjmp-Befehl nicht abzudecken sind, sind ab dem ATMEGA168 die Einträge für die Interruptvektoren nämlich doppelt so groß. Und damit ändert sich natürlich auch deren Position im Speicher. Es bleibt einem leider nichts anderes übrig, die Datenblätter genau zu vergleichen, wenn man einen Controller durch einen anderen ersetzen will.
Hi >Es bleibt einem leider nichts anderes übrig, die Datenblätter genau zu >vergleichen, wenn man einen Controller durch einen anderen ersetzen >will. Oder, wenn vorhanden, die 'Migration Notes' zu konsultieren. MfG Spess
Max schrieb: > Sowas zb: > Reset Ucr.3 > Reset Ucr.4 > Ucsrb.txen = 1 > Ucsrb.txen = 1 > If Ucsra.rxc = 1 Then Get_byte = Udr Wenn BASCOM doch schon Bitnamen unterstützt (txen, ...) warum sollte man dann noch so Sachen wie "Reset Ucr.3" schreiben?
Max schrieb: > Mh, wie würdest du es denn dann schreiben? genauso wie zb beim: Ucsrb.txen = 1 nur halt: Ucr.wasweisich = 0 mit set u. reset waehre i vorsichtig, speziell in arrays macht bascom probleme damit und da sucht man stunden wenn du immer registernamen verwendet hast sollte die prozesseorumstellung quasi problemlos funktionieren viel erfolg vlG Charly
Also aus Reset Ucr.3 wird denn Ucr.3=0 (0 Ist doch reset,oder)?
Andre Leute würden den Hardware-Krams sauber wegkapseln und müssten dann nicht an 100 Stellen im Programm suchen, ob noch irgendwo irgendwelche Register vergessen wurden...
FAST richtig die 3 hat auch einen Namen im Register, das spart die spaeter das nachguggen und iss f. 'fremde' auch besser lesbar also nochmal: Ucr.NameVonBit3 = 0 vlG Charly
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.