www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATmega48/88/168


Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lustigerweise gibt's massig Informationen in Russisch über diese
Teile.  Nur zu: die Mutigen, die sich das alles durchlesen, werden
belohnt. :-))

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum reichen die Infos denn nicht?

http://sub.chipdoc.ru/html.cgi/txt/ic/Atmel/micros...

...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.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tolle Sache.

Jetzt muss ich nur noch ein paar Jahre Russisch lernen.
(War ein Scherz).

Tschüss
Martin

Autor: Frank Linde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß
Das Runterladen hat vorher nicht funktioniert.

Danke für deine Hilfe
Tschüss, Martin

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mmerten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Frank Linde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>  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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> "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.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fritz Ganter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-)

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Franck (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fritz Ganter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael

Ich meinte den reelen Chip, nicht das Datenblatt. Das Datenblatt hab
ich, liegt ja bei Atmel rum.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.