Hallo zusammen, ich verzeifel fast am ATmega48. Ich versuche folgendes Programm für den ATmega48 anzupassen und trotzdem läuft es bis jetzt nicht. Ich hab nur die Register des INT0 angepasst. Vielleicht hat jemand Erfahrung mit dem portieren und kann mir sagen, was noch alles geändert werden muss... aus den Appnotes von Atmel wird man nicht wirklich schlau. Gruß, Bastian
Drucke dir die Listen: - Interrupt-sources und - Register Summary aus und nimm dann beim Vergleichen Bleistift und Textmarker. Ich bin immernoch der Meinung, dass die Entwickler der Megax8-Serie besoffen waren... Prost & guten Rutsch... ...
Gast
#272075
>dass die Entwickler der Megax8-Serie besoffen waren...
Das auf jedenfall.
Und derjenige der das Datenblatt geschrieben hat auch: Fast alle
Assembler Beispiele funktionieren nicht, da häufig out durch STS
ersetzt werden muss, aber eben nicht immer.
Ohne das passende Makro ist das per Assembler kaum möglich.
Den mega48 programmiere ich daher nur in C.
Davon abgesehen ist der interne RC Oszillator miserabel.
Während der des mega8 +/-2% hatte, hat der des mega48 +/-10%.
Selbst mit einer Kalibrierung ist nicht sehr viel zu erreichen:
Beim mega8 im Klimaschrank bei konstant 40°C schwankt der Wert auf
einem Frequenzzähler mit 1s Messintervall um etwa +/-60ppm.
Beim mega48 um etwa das 10 fache: +/-5000ppm !
Was die Sache mit dem Oszillator bei neueren AVRs anbelangt, da hat sich ElmChan schonmal drüber ausgelassen: http://elm-chan.org/docs/avr/jitter.html Man braucht den japanischen Text nicht zu verstehen, die Bilder rechts sind auch so deutlich genug. Hmm, Stromsparen auf Kosten der Stabilität? Da war doch noch was... Ja, richtig, da hatte jemand Probleme, einen ATTiny13 seriell an einen anderen Controller anzuhängen. Nun, wenn der Takt so aussieht, wundert mich nichts mehr. Gruss Jadeclaw.
Gast
#272077
Die Seite kenne ich. Ich hatte eine Schaltung bei der ich einen vollen 8bit Port und den UART brauchte. Daher habe ich den Oszillator gestern so genau kalibriert. Unkalibriert (also mit dem OSCCAL Wert für 3,3V) lief der UART. Mit exakt 8MHz nicht. Nur wenn der der Oszillator etwa 0,5% schneller läuft kommen die Daten fehlerfrei an.
Danke erstmal für die Antworten. Leider bekomme ich langsam das Gefühl, daß es nicht wirklich gut war von PIC nach AVR zu wechseln. Die Dokus des ATmega8 und 48 sind echt der letzte Sch***ß! Die verstreuen die Informationen über die gesamte Doku,so daß ich erstmal stundenlang suchen muss,bis ich die finde. Bei Microchip sind die schön nach Thema geordnet. Ok, nun zu eueren Postings: @HanneS: Das mit dem Ausdrucken ist ne gute Idee,werd ich sofort machen. Aaaaber, ich war der Meinung, daß ich alle notwendigen Register geändert hab und auch die neue Lage der Bits beachtet habe. Werd das aber trotzdem nochmal checken und dann Code posten. @Benedikt: Ich muss doch STS statt OUT nutzen, wenn die Register im extended I/O liegen,oder?!? Gibt es irgendwo genauere Infos dazu? Gruß, Bastian
Gast
#272079
Wenn die Register im extended Bereich liegen, dann STS, ansonsten OUT oder STS Register+0x20, wert Bei Atmel gibt es irgendwo eine AppNote mit passenden Makros die selbst entscheiden wann welcher Befehl benötigt wird.
Gast
#272080
Besonders zu beachten ist auch, daß das interne RAM nun ab 0x100 beginnt. Da hatte ich mal Probleme.
@Michael: Mist, das hatte ich ganz übersehen. Aber nachdem ich versucht habe das anzupassen, funktioniert das immer noch nicht :( Wahrscheinlich ist es einfacher den ganzen Scheiß einfach neu zu schreiben. MfG, Bastian
Gast
#272082
Wenn's bei mir nicht will, füge ich immer eine Endlosschleife ein, die nur einen Portpin 'toggled' und suche die Stelle, ab wo das dann nicht mehr klappt. Neu zu schreiben, ist zu aufwendig; man muß ganz penibel die Stelle suchen, wo die Bits in den IO-Registern umgerührt wurden. Siehe oben: HanneS. Und plötzlich läuft dann alles, wie gewünscht :-)
Gast
#272083
Hi, ich möchte demnächst auch mehrere Atmega 88 oder 168 kaufen. Sind da die gleichen Probleme wie mit dem Atmega 48? Wenn ja, dann wäre ja eher abzuraten, oder? Gruß Florian
Satz mit X: Xundes Neues Jahr... Ich habe auch einige Mega48 und Mega168 liegen, aber noch nix damit gemacht. Blöd ist ja, dass ausgerechnet die Register, die man oft im Interrupt (wo es auf kurze Routine ankommt) braucht, im Ext.I/O liegen und dadurch die ISRs unnötig verlangsamen. Wenn man also die "neuen Features" nicht braucht und das größere Gehäuse des Mega16 nicht stört, dann kommt man mit Mega8535 und Mega16 besser weg... Klar, wir werden dieses bescheuerte Chipdesign nicht ändern, aber ATMEL hat sich mit dieser "Innovation" eigentlich lächerlich gemacht. Schade eigentlich, denn ansonsten mag ich die AVRs. ...
@Florian: ATMega 88 und 168 sind praktisch gleich mit dem 48er, haben halt mehr Speicher. Zwei Dinge, die mir wichtig wären, sind einerseits der drastisch reduzierte Stromverbrauch, zum anderen der PinChange-Interrupt/Wake-Up auf jeden Portpin. Beides fehlt dem ATMega8/16/32. Aber. das besoffene Design hat einen Grund: ""The ATmega48/88/168 is a complex microcontroller with more peripheral units than can be supported within the 64 location reserved in Opcode for the IN and OUT instructions."" Richtig, die Portadresse ist Teil des IN/OUT-OpCodes. Trotzdem, die Peripherie hätte wirklich etwas sinnvoller angeordnet werden können, z.B. alles, was im ATMega8 schon drin ist, auch hier auf die gleichen Adressen legen. Bis auf die Tatsache, das PonyProg mit diesen Teilen nicht umgehen kann und ich gerade zu faul bin, mir einen anderen Programmieradapter zu kaufen/bauen, sehe ich eigentlich keinen Grund, diese Teile nicht einzusetzen. Gruss Jadeclaw.
Klar, die MegaX8 brauchen (wie Mega128) mehr als 64 Bytes I/O. Also ist Extended-I/O schon sinnvoll. Aber warum lässt man im bitweise ansprechbaren I/O und im normalen I/O soviele Adressen ungenutzt?? Das meinte ich, als ich die MegaX8er Serie "schlechtredete". Das Teil ist einfach nur halbherzig entwickelt worden, da hätte man sehr Vieles besser machen können. Was mich auch noch etwas am DIL28 stört, ist das Pinout. Wenn man UART nutzen will, braucht man auch einen Quarz. Nutzt man aber Quarz und UART, hat man keinen kompletten 8-Bit-Port mehr. Schade eigentlich, habe ich schon vermisst. ...
Gast
#272087
> Wenn man UART nutzen will, braucht man auch einen Quarz. >Nutzt man aber Quarz und UART, hat man keinen kompletten 8-Bit-Port mehr. Genau, und der einzige kleine uC mit 8bit Port ist der tiny2313. Aber der hat für vieles zuwenig RAM. Daher bleibt oft nur der mega8515 übrig. Wobei man eigentlich beim Betrieb im Innenbereich meistens keine extremen Temperaturscwankungen hat, und man daher den internen Oszillator des mega8 nehmen könnte. Was aber beim mega48 nicht geht, da dessen Oszillator eine Fehlentwicklung ist.
Gast
#272088
Hm, wenn das Pony Programm den µC nicht kennt, und der Programmieradapter falsch ist, was könnte man dann noch nehmen? Gibts da andere Möglichkeiten? Weiß zufällig jemand, wo man diese Teile in TQFP32 Gehäuse bekommt? Gruß Florian
Ja. http://www.der-hammer.info/hvprog/index.htm Den will ich mir dann doch mal bauen. Da dieser identisch zum Programmieradapter des STK500 ist, geht dann auch das Programmieren direkt aus dem AVRStudio heraus. Und man bekommt auch total zerkonfigurierte Controller wieder in den Griff (HV-Parallel/Seriell-Mode). ATMega8 / 88 in TQFP gibt's hier: http://www.elektro-nix.de/pi1074897291.htm?categoryId=3 @Hannes: T6963-Display und Quarz gleichzeitig ist schon das Problem. Entweder Qarz weglassen oder die Displayanschlüsse über sämtliche Ports verteilen, je nachdem, was sonst entbehrlich ist. Gepaart mit einer mehr oder weniger scheußlichen Bitschubserei. Ich glaube, ich gönn' mir mal ein paar 8535, für den Programmer brauch' ich eh einen. Gruss Jadeclaw.
> @Hannes: T6963-Display und Quarz gleichzeitig ist schon das Problem. Eben... - Siehe Bild. Ist Mega8 mit T6963C-LCD und angestecktem MAX232, der mangels Quarz nur als Ladungspumpe für das LCD (-9V) taugt. Die serielle Verbindung ist mangels Quarz nicht wirklich brauchbar. Die Quarzpins sind allerdings vom LCD belegt (Data). Nachrüstung des Quarzes ist also nur schwierig möglich. Nunja, war eh nur ein Spielprojekt... ...
Angehängte Dateien:
-
BigLCD02.jpg
(34 KB)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.