Hallo Leute! Ich würde mir gerne die Datenblätter von den angeblich neuen ATMEGAS anschauen (ATmega48/88/168). Diese Typen und die Datenblätter waren jedoch auf den Atmel-Homepage nicht zu finden. Ist das Ganze noch streng geheim oder wie? Im neuen Codevision-AVR kann man sie bereits auswählen, was bedeutet, dass es Datenblätter geben muss. Danke Leute! Tschüss. Martin.
Google sagt mir, daß man bei avrfreaks dazu paar Infos finden kann... Sollte genug Info sein, daß man darauf basierend auch den Compiler adaptieren kann.
Lustigerweise gibt's massig Informationen in Russisch über diese Teile. Nur zu: die Mutigen, die sich das alles durchlesen, werden belohnt. :-))
Hallo Joerg! Ich glaube nicht, dass die Informationen reichen. Angeblich sind sie ähnlich wie der Atmega8. Wenn man aber mal in den C-Compiler hineingeht und die Teile auswählt, dann kann man z.B. an dem Timer 0 erkennen, dass sie doch etwas unterschiedlich sind. Martin
Warum reichen die Infos denn nicht? http://sub.chipdoc.ru/html.cgi/txt/ic/Atmel/micros/avr/atmega48_88_168.htm?fid=12 ...finde ich jedenfalls so schlecht nicht. ;-) Würde mir genügen, avr-gcc, avr-binutils und avr-libc anzupassen. (Allerdings muß ich für avr-gcc und avr-binutils andere Leute belästigen sowie für avr-libc warten, bis savannah wieder up & running ist.) Interessant ist schon der Stromverbrauch... der widerlegt die landläufige Meinung, daß AVRs Stromfresser sein müssen.
Tolle Sache. Jetzt muss ich nur noch ein paar Jahre Russisch lernen. (War ein Scherz). Tschüss Martin
>> Jetzt muss ich nur noch ein paar Jahre Russisch lernen.
Jaaa, das wäre zweifellos eine reizvolle Möglichkeit. Du könntest aber
auch das englische Datenblatt am Ende der Seite herunterladen...
Gruß, Frank
Ich weiß Das Runterladen hat vorher nicht funktioniert. Danke für deine Hilfe Tschüss, Martin
Diese ganze Aufregung um fehlende Datenblätter kann ich überhaupt nicht nachvollziehen. Ich habe nämlich die Erfahrung machen müssen, daß es erst dann sinnvoll ist, sich mit neuen ICs zu beschäftigen, wenn diese auch in ausreichenden Produktionsstückzahlen verfügbar sind. Das betrifft nicht nur eventuelle Verfügbarkeitsprobleme, sondern auch das Bekanntsein der gröbsten Bugs, bzw. erstmal das Vorhandensein einer überhaupt lauffähigen Version, die keine kritischen Bugs mehr hat. Ich habe z.B. Muster des DS89C420 rumliegen, die total unbrauchbar sind, da die Befehlsausführung an den Adressen 0x00FF, 0x01FF, 0x02FF usw. falsch sein kann. Und sowas kann man aber keinem C-Compiler beibiegen. In einem anderen Fall hatte ich schon Datenblätter und Muster, aber dann wurde der IC eingestampft. Sowas ist durchaus üblich, daß erstmal Testballons gestartet werden, um an dem Feedback zu sehen, ob man überhaupt genügend davon absetzen könnte. Dagegen ist es aber äußerst unwarscheinlich, daß der Chip zuerst da ist, aber kein Datenblatt. Man lebt einfach viel ruhiger und gesünder, wenn man erst ißt, wenn das Essen auch auf dem Tisch steht. Peter
Also ich verstehe die ganze Aufregung auch noch nicht. Hat die Teile jemand schon mal (zumindest als sample) in der Hand gehabt. Auf dem Papier existieren MEGA48/88/168 und 256 seit Anfang/Mitte des Jahres. Über geplante Aufnahme der Produktion will man bei Atmel aber noch keine Zusagen machen. Die können ja z.Zt. noch nich mal ausreichende sample Mengen vom TINY13 und TINY2313 liefern. Also wozu auch Datenblätter für Produkte die nur auf dem Papier existieren ;-)
@Martin: > Jetzt muss ich nur noch ein paar Jahre Russisch lernen. Naja, das haben wir hierzulande seinerzeit gemacht. ;-) Reicht zusammen mit dem E-Technik-Russisch aus Uni-Zeiten zumindest noch, um das dort zu lesen... Aber das sollte natürlich viel mehr der Hinweis auf das Datenbl^W^Wdie `Preliminary Information' dort sein. Nett, daß man das zwar dort findet aber nicht bei Atmel selbst... @Peter: > Ich habe nämlich die Erfahrung machen müssen, daß es erst dann > sinnvoll ist, sich mit neuen ICs zu beschäftigen, wenn diese auch in > ausreichenden Produktionsstückzahlen verfügbar sind. Aus Anwendersicht hast Du völlig Recht. Aus Sicht eines Compiler-/ Libraryentwicklers jedoch muß man relativ frühzeitig damit beginnen, die neuen Chips mit aufzunehmen, um bei voller Verfügbarkeit derselben dann auch den Compiler parat zu haben. Daß sich am Compiler selbst noch was ändert, ist ohnehin unwahrscheinlich (der muß nur erstmal die neuen -mmcu Strings verkraften und den entsprechenden Prozessorklassen zuordnen), am ehesten ändert sich in den include-Files danach vielleicht noch was. Das ist dann aber schnell noch nachgezogen.
>> Und sowas kann man aber keinem C-Compiler beibiegen. Sag ich doch! Nur Assembler bringts! SCNR Kannst wieder landen, ich habe mir WinAVR schon installiert. ;-) Ansonsten konzentriere ich mich auch lieber auf in der Realität kurzfristig kaufbare Chips, nachdem ich mal 8 Monate auf 'ne Stange (zu bezahlende) Samples ATmega32 gewartet habe, die "nächste Woche" verfügbar sein sollten. Gruß, Frank
Ich wollte deshalb die Datenblätter, um zu erkennen, ob die Prozessoren vielleicht in meine Projekte passen. Außderdem ist von meiner Seite das Interesse an neuen Dingen sehr groß. Aber, wenn es nicht einmal sicher ist, dass diese Bausteine überhaupt produziert werden, ist natürlich die Neugier plötzlich weniger groß. Na ja hab ich auch wieder was dazugelernt Tschüss, Martin
@Frank, "Sag ich doch! Nur Assembler bringts!" Nein der bringt sowas verrücktes auch nicht. Man müßte ja immer einmal falsch assemblieren, dann an 0x00FF, 0x01FE, 0x02FD usw. je nach Befehl 1..3 NOPs einfügen und dann nochmal assemblieren. Bei soviel Handarbeit für jede neue Assemblierung habe ich die Dinger eben lieber weggeschmissen. Peter
@Joerg, "Aus Sicht eines Compiler-/ Libraryentwicklers..." Ja, da mußte ich mich bei den AVRs erstmal stark umgewöhnen. Vom Keil-C51 kannte ich, daß es den Compiler überhaupt nicht interessiert, welches Derivat eingesetzt wurde. Alle waren 100% Code kompatibel, und die neuen SFR-Definitionen waren schnell angepaßt. Natürlich braucht man für die neuen doch einen neuen Compiler, wenn man sie voll ausnutzen will, z.B. beim DS80C390, um die 1kB Stackgröße und 4MB Codegröße auszunutzen. Nach dem Reset startet alle jedoch im normalen 8051-Mode und müssen erst auf die Erweiterungen umgeschaltet werden. Beim AVR gibt es inzwischen 4 verschiedene Haupttypen. Die neuen lassen sich bestimmt da einordnen, also muß man nur einen ähnlichen wählen und die IO-Definitionen anpassen. Das sollte sogar ich könnnen, ohne einen neuen WINAVR runterladen zu müssen. Aber wie gesagt, diese Eier sind ja noch völlig ungelegt. Peter
Du vergißt die Interruptvektortabelle, die bei jeden AVR anders groß ist -- je nachdem, welche Hardware er tatsächlich on board hat. Dadurch braucht's für jeden Controllertyp eine eigene crt.o Datei, und für diese wiederum muß -mmcu jeden Controllertyp explizit übergeben bekommen können. Hat halt alles sein Für und Wider. Die Variantenvielfalt der AVRs ist einfach mal recht groß.
@Peter "Sag ich doch! Nur Assembler bringts!" Ich finde, dass C für viele Dinge ausreichend ist. Man darf natürlich die Vorteile von C nicht vergessen, wie mathematische Funktionen oder die einfache Portierbarkeit auf andere µP usw. Wenn es natürlich auf jeden Taktzyklus ankommt und auf Größe ist man mit Assembler sicher besser beraten, wobei man hier aber schon absoluter Profi sein muss, um alle Hintertürchen zu kennen und entsprechend guten Quellcode erstellen zu können. Es hat halt alles sein Für und Wider wie Frank schon sagte. Tschüs, Martin
@Joerg "Du vergißt die Interruptvektortabelle" die steht doch auch in der entsprechenden "io***.h", läßt sich also leicht editieren. Eine neue AVRGCC.EXE brauchts dazu nicht. Peter
> "Du vergißt die Interruptvektortabelle" > die steht doch auch in der entsprechenden "io***.h", läßt sich also > leicht editieren. Hier irrst Du, Peter. Wie ich schon schrob, steht die Tabelle im crtX.o drin. Was Du im <avr/ioXXX.h> siehst, sind lediglich die Definitionen dafür, damit man aus C oder Assembler symbolisch auf die Vektoren zugreifen kann. Diese Definitionen werden beim Bauen des crtX.o auch benutzt, um die Tabelle aufzubauen, aber in der Tat hat jeder Prozessor ein eigenes crt-File. (crt - C runtime [startup]) Das gehört zwar immer noch alles zum Teil avr-libc, dennoch muß die gesamte Toolchain das passende -mmcu Argument verarbeiten können. Der Compilertreiber z. B. muß auch wissen, welches crtX.o zu welchem -mmcu gehört, da die Option -mmcu ja die langen Atmel-Namen benutzt, die crt-Files aber zugunsten prähysterischer Betriebssysteme mit Krüppeldateisystemen auf 8.3 eingestutzt sind... Solange sich am Befehlssatz gegenüber den existierenden AVRs nichts ändert, sind die Änderungen am Compiler und ggf. den binutils zwar nur peanuts, aber gemacht werden müssen sie trotzdem.
Hat Atmel nicht gross rausposaunt, eine One-Wire-Debug-Schnittstelle beim ATmega88 einzuführen? Davon steht leider nichts drin, nach Debug-Möglichkeiten sucht man vergeblich. Wenigstens welcher Pin später dafür benutzt werden soll, könnte doch veröffentlicht werden. Dann könnte man sich bei Mega8-Projekten schonmal hardwareseitig auf die Nachfolger einstellen. Zu befürchten ist, dass die One-Wire-Debug noch so schlecht funktioniert, dass sie lieber garnicht erwähnt wird. Ansonsten hat sich doch gegenüber dem ATmega8 nicht viel getan, was die Ausstattung angeht. Die Neuerung liegt wohl in der Verbesserung der technischen Daten, Stromverbrauch etc., und die Verfügbarkeit von 16kb im kleinen Gehäuse. Stefan
Sorry, dass ich den alten Thread wieder ausgrabe, aber hat schon jemand eine Bezugsquelle dafür? Ich würde sogar Jörg einen schenken wenn er mir gcc und Konsorten anpasst. :-)
Ich habe vor ca. 2 Wochen unseren Distributor angefragt, ob es bereits Muster gibt. Er wollte mal schauen ... seitdem ist Funkstille. Serienbausteine brauchen wohl noch eine ganze Weile. Stefan
Wieso unten auf der Seite war ein Link und das ist ein Englisches PDF :-) http://sub.chipdoc.ru/pdf/Atmel/AVR/ATmega88_1.pdf?fid=12
@Michael Ich meinte den reelen Chip, nicht das Datenblatt. Das Datenblatt hab ich, liegt ja bei Atmel rum.
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.