Nachteil bei verschiedenen µC

Das kannst du selbst ganz genau beantworten, wenn du die beiden 
Datenblätter miteinander vergleichst. Pinzahl? Pinfunktionen? Taktrate? 
Energiebedarf?, Abmessungen...

Aufwändig wird es wenn eine vorhandene Schaltung für den Attiny2313 
ausgelegt ist und du die für einen Atmega8 umbauen willst.

Wenn du vollkommen frei in der Wahl des µC bist, sehe ich beim Atmega8 
sogar Vorteile: Der Atmega8 hat nämlich einen ADC (mit mehreren 
Eingangskanälen) und der Atmega8 ist das "Arbeitspferd" im 
AVR-Tutorial.

Statt des Mega8 würde ich lieber den Mega88(A) oder Mega168(A) nehmen, 
die sind moderner und konnen mehr, bei weniger Stromverbrauch.

@Travel Rec. (travelrec) Benutzerseite

>Statt des Mega8 würde ich lieber den Mega88(A) oder Mega168(A) nehmen,
>die sind moderner und konnen mehr, bei weniger Stromverbrauch.

Ich behaupte mal, dass 90% der Projekte das nicht benötigen und ebenso 
90% der Hobbybastler die Grenze nicht ausreizen können.

MfG
Falk

aber genau diese 90% müssen sowas unbedingt haben, überlegmal wieviel 
Geld du sparen kannst, wenn eine Schaltung 2W im Jahr weniger braucht 
;-)

ausserdem lieber oversized wenn es nicht zu teuer wird, als beim 
nächsten Software Update undersized

Falk Brunner schrieb:
> Ich behaupte mal, dass 90% der Projekte das nicht benötigen und ebenso
> 90% der Hobbybastler die Grenze nicht ausreizen können.

Daran liegts nicht.

Atmel hat seine MCs in mehreren Stufen gepimt, z.B. die 28-Pinner:

1. AT90S4433
2. ATmega8
3. ATmega48..168
4. ATmega48p...328p

Für neue Projekte liegt es also nahe, einfach die aktuellste Version zu 
nehmen.


Peter

Nur leider sind die Tutorien fast alle auf den ATmega8 getrimmt- und für 
den Anfang ist es doch ganz praktisch, die Sachen "genau so" machen zu 
können und nicht erst nach mühsehligem Datenblattsuchen die Sache "doch 
nocht irgendwie" hinzbekommen, indem alle Registereinstellungen 
durchprobiert werden.

Aber das gilt nur für Anfänger.

Für den Rest stimme ich uneingeschränkt zu (es sei denn, man hat noch 
viele alte Schippse in der Schublade liegen).

Viele Grüße
Nicolas

@Peter Dannegger (peda)

>Für neue Projekte liegt es also nahe, einfach die aktuellste Version zu
>nehmen.

Für Leute, die sich mit der Materie auskennen ja.
Für Anfänger und Nachbauer definitiv nein.

MFG
Falk

@  spess53 (Gast)

>Warum willst du Anfängern Debug-Wire verweigern?

Immer diese Unterstellungen? Bist du Anwalt? ;-)

> Das hat der ATMega8 z.B. definitiv nicht.

Ja, aber denkst du das hilft einem ANFÄNGER großartig, der schon mit ner 
blinkenden LED seine Probleme hat?
Und wie gesagt, die Tutorials sind größtenteils auf den Atmega8 
zugeschnitten. Welcher dafür vollkommen OK ist. Willst du sie 
umschreiben? Im Halbjahresrhytmus, weil es neue Controller gibt? Und 
viele Anfänger habe eh kein Kabel für Debugwire, weil sie erstmal mit 
minimalen Kosten einsteigen wollen. Der Simulator reicht zum Lernen 
erstmal.

MFG
Falk

spess53 schrieb:

> Warum willst du Anfängern Debug-Wire verweigern? Das hat der ATMega8
> z.B. definitiv nicht.

Dann sollte sich mal jemand opfern und das Tut auf Mega88(A)(P) plus 
Dragon umschreiben bzw. ergänzen.

Hier sind alle Erweiterungen aufgelistet. Möge der Anwender entscheiden.

http://www.atmel.com/dyn/resources/prod_documents/doc2553.pdf

Wenn man nicht zu kompliziert arbeitet dann sind die Controller doch 
direkt kompatibel. Nur in wenigen Fällen hat sich viel intern geändert, 
und das kann man anhand der mirgration notes nachvollziehen. Nen "alten" 
Controller würde ich nur nehmen, wenn man ein altes Projekt 1:1 
nachbauen will und sich nicht um Details kümmern möchte (so plane ich es 
zB gerade für den AVR-Transistortester).

@A. K. (prx)

>Dann sollte sich mal jemand opfern und das Tut auf Mega88(A)(P) plus
>Dragon umschreiben bzw. ergänzen.

Dann geh mal mit gutem Beispiel vorran! Aber bitte auch solide TESTEN!!!

MFG
Falk

Martin Gerken schrieb:
> Wenn man nicht zu kompliziert arbeitet dann sind die Controller doch
> direkt kompatibel.

Ach ja? Fängt doch schon bei den anders benannten (und teilweise auch 
anders anzusprechenden, Stichwort URSEL) USART-Registern an. USART 
dürfte bei vielen mit eines der ersten Dinge sein, die sie zum Laufen 
bringen wollen.

Andreas

@  Andreas Ferber (aferber)

>Ach ja? Fängt doch schon bei den anders benannten (und teilweise auch
>anders anzusprechenden, Stichwort URSEL) USART-Registern an. USART
>dürfte bei vielen mit eines der ersten Dinge sein, die sie zum Laufen
>bringen wollen.

Stimmt, hier hat Atmel eher gebastelt. Eine orthogonale Strktur ist das 
nicht. Und warum? Um ein paar Hunder Gatter un ein paar um Chipfläche zu 
sparen?!? Dort ist der MSP430 deutlich besser. Dort ist z.B. Timer 0 in 
alles Derivaten identisch, oder?

MFG
Falk

Falk Brunner schrieb:
>>Ach ja? Fängt doch schon bei den anders benannten (und teilweise auch
>>anders anzusprechenden, Stichwort URSEL) USART-Registern an. USART
>>dürfte bei vielen mit eines der ersten Dinge sein, die sie zum Laufen
>>bringen wollen.
> Stimmt, hier hat Atmel eher gebastelt. Eine orthogonale Strktur ist das
> nicht. Und warum? Um ein paar Hunder Gatter un ein paar um Chipfläche zu
> sparen?!?

Die Register gehen beim ATmega8 genau bis 0x3f, sind also komplett mit 
IN/OUT verwendbar. Für nur ein Register mehr (das man hier durch die 
Doppelbelegung gespart hat) hätte man ein zusätzliches Adressbit 
gebraucht, und hätte genau ein Register gehabt, bei dem IN/OUT nicht 
mehr geht. OK, beim ATmega8 gibt es noch ein paar reservierte Register, 
die sind aber beim ATmega16 alle in Verwendung.

Beim ATmega88 brauchte man dann sowieso mehr Register, daher wurde die 
Doppelbelegung aufgelöst (und das freiwerdende Bit in UCSRC/UCSR0C 
konnte man auch gut gebrauchen).

Generell sieht das beim ATmega88 alles etwas "weitsichtiger" aus, 
exemplarisch z.B. die Benennung der USART-Register jeweils mit "0" drin, 
obwohl es nur einen USART gibt. Das macht dann die spätere Portierung 
auf Controller mit mehreren USARTs einfacher.

Andreas

@  Andreas Ferber (aferber)

>Die Register gehen beim ATmega8 genau bis 0x3f, sind also komplett mit
>IN/OUT verwendbar. Für nur ein Register mehr (das man hier durch die
>Doppelbelegung gespart hat) hätte man ein zusätzliches Adressbit
>gebraucht, und hätte genau ein Register gehabt, bei dem IN/OUT nicht
>mehr geht. OK, beim ATmega8 gibt es noch ein paar reservierte Register,
>die sind aber beim ATmega16 alle in Verwendung.

Einen Mirkocontroller entwirft man nciht als Einzelexemplar, sondern als 
Familie. Und da ist etwas Planung und Strategie nicht von Nachteil.

>Beim ATmega88 brauchte man dann sowieso mehr Register, daher wurde die
>Doppelbelegung aufgelöst (und das freiwerdende Bit in UCSRC/UCSR0C
>konnte man auch gut gebrauchen).

Das ist Bastlerdenken. Eben um diese paar Gatter einzusparen.

MFG
Falk

Falk Brunner schrieb:
> Einen Mirkocontroller entwirft man nciht als Einzelexemplar, sondern als
> Familie.

Was zu Anfang leider versäumt wurde.
Man sieht deutlich, wie verschiedene Köche in dem AVR-Brei rumgerührt 
haben.

Und bei den Timern ist immer noch kein System zu erkennen.
Die ATmega haben z.B. keinen Dead Time Generator und keine PLL und die 
ATtiny fast nur 8 oder 10Bit Timer.


Peter

Peter Dannegger schrieb:

> Die ATmega haben z.B. keinen Dead Time Generator

Dafür gibt's ja die AT90PWM. Aber stimmt schon - ist ziemlich viel 
Kleinklein. Hier ein Spezialteil, dort ein Spezialteil.

Wiso nimmt man nicht einfach einen STM32.
Da gibts diese Pheriperieunterschiede nicht. Über 110 Varianten und die 
Pheriperie ist in allen gleich.
Das ist ein ausgereifter Controllertyp.
Aus Erfahrung kann ich nur den empfehlen. Egal was man für ein Problem 
hat, der deckt alles ab.

Falk Brunner schrieb:
> Einen Mirkocontroller entwirft man nciht als Einzelexemplar, sondern als
> Familie. Und da ist etwas Planung und Strategie nicht von Nachteil.

Halte mal die Registermap des AT90S8515 neben die vom ATmega16. Im 
Detail gibt es natürlich Änderungen, im großen und ganzen sind die 
Registeradressen aber lange stabil geblieben.

An Register wie UBRRH hat damals noch keiner gedacht, vermutlich weil 
niemand damit gerechnet hat, dass 8 Bit-Mikrocontroller irgendwann mal 
mit deutlich über 8 MHz laufen würden.

>>Beim ATmega88 brauchte man dann sowieso mehr Register, daher wurde die
>>Doppelbelegung aufgelöst (und das freiwerdende Bit in UCSRC/UCSR0C
>>konnte man auch gut gebrauchen).
> Das ist Bastlerdenken. Eben um diese paar Gatter einzusparen.

Auf mich macht das nicht den Eindruck, als wäre es um ein paar Gatter 
gegangen. Man hat solange wie möglich versucht, mit dem durch die 
Befehlsarchitektur vorgegebenen Limit von 64 Adressen hinzukommen (auch 
wenn es kein "hartes" Limit war, da die IO-Register schon immer auch 
Memory Mapped erreichbar waren, allerdings weniger performant).

Erst als durch immer mehr Peripherie das absolut nicht mehr haltbar war, 
hat man eine generelle Erweiterung und Neuaufteilung des IO-Adressraumes 
vorgenommen, dabei sind dann nicht mehr viele Register an ihrem alten 
Platz geblieben, und es wurde (auch und gerade in den Bereichen <= 0x1f 
für SBI/CBI und <= 0x3f für IN/OUT) reichlich Freiraum geschaffen für 
spätere Erweiterungen. Seitdem ist der IO-Space dann wieder relativ 
stabil geblieben.

Andreas

Markus Müller schrieb:
> Wiso nimmt man nicht einfach einen STM32.

Den kannte eben 1997 noch keiner.
MCs werden ja nicht erst seit 2010 eingesetzt.


> Egal was man für ein Problem
> hat, der deckt alles ab.

Leider nicht.
Die 6 .. 28 Pinner und 1,8 .. 5,5V deckt er nicht ab.


Peter

@  Andreas Ferber (aferber)

>An Register wie UBRRH hat damals noch keiner gedacht, vermutlich weil
>niemand damit gerechnet hat, dass 8 Bit-Mikrocontroller irgendwann mal
>mit deutlich über 8 MHz laufen würden.

Klar, weil ja selbst die UrAVRs schon 20 MHz konnten . . .

>Auf mich macht das nicht den Eindruck, als wäre es um ein paar Gatter
>gegangen.

Auf mich schon.

> Man hat solange wie möglich versucht, mit dem durch die
>Befehlsarchitektur vorgegebenen Limit von 64 Adressen hinzukommen (auch
>wenn es kein "hartes" Limit war, da die IO-Register schon immer auch
>Memory Mapped erreichbar waren, allerdings weniger performant).

Die Architektur war auch am Anfang größer, als es die verfügbaren Typen 
waren. Allein schon das Ganze Gemache mit 22 Bit PC etc.

>spätere Erweiterungen. Seitdem ist der IO-Space dann wieder relativ
>stabil geblieben.

Ja, relativ.

Aber was solls. Das Problem hat Atmel erkannt und wie man hört bei dem 
Xmegas ausgeräumt. Eine Baustelle für Programmierer weniger.

MFG
Falk

@  Markus Müller (mmvisual)

>Wiso nimmt man nicht einfach einen STM32.

Weil trotz der gewissen Macken der AVR immer noch ein sehr schöner 
Mikrocontroller ist.
Und deine neue Religion Zeit braucht, viele Anhänger um sich zu scharren 
;-)

>Aus Erfahrung kann ich nur den empfehlen. Egal was man für ein Problem
>hat, der deckt alles ab.

Kaum. Die Wunderschraube, die auf M3 bis M100 passt gibt es nicht. Auch 
nicht als Mikrocontroller ;-)

MFG
Falk

Peter Dannegger schrieb:

> Die 6 .. 28 Pinner und 1,8 .. 5,5V deckt er nicht ab.

Cortex-M0 Controller mit 2,5-5,5V sind immerhin angekündigt (NuMicro). 
Und da sage noch einer, 5V wäre tot ;-).

eheheh, wusst ichs doch.
Wird nur drauf eingehauen.
Ihr banausen.

Anstatt den Artikel STM32 mal zu lesen...

@  Markus Müller (mmvisual)

>Anstatt den Artikel STM32 mal zu lesen...

Klar, die Barbaren kann man nicht so leicht zum Evangelium bekehren, 
Revernd Müller ;-)

Ja, Falk, Du hast auch einiges zu dem STM Artikel beigetragen, vielen 
Dank!

Sorry, ich bin nun mal leidenschaftlich vom STM32 überzeugt...

Irgend jemand muss ja den Gegenpol zum AVR spielen.

Markus Müller schrieb:
> Irgend jemand muss ja den Gegenpol zum AVR spielen.

...den gibt's doch schon in Form von 8051, PIC, MSP430, STR7, MB90Fxxx, 
R8/R16, AT91, AT32, TMS470 und viele andere mehr.

Ein weiteres "Gegenpölchen" im Strudel der Controller wird's da so 
schnell nicht reissen...

"Nimm doch statt einem Tiny einen STM32"
Klar, kein Problem, ist in einer halben Stunde auf den neuen µC 
migriert, Hardware und Software hat man vorgehalten, Einarbeitung in die 
Programmierumgebung würd ich mit 5-10 Minuten ansetzen.

Wer von euch kann schon mit MS Word richtig umgehen?
Ich würd mal sagen 95% aller User können den vollen Funktionsumfang von 
Word garnicht nutzen.
Analog dazu Photoshop. Ein Füllhorn voller toller Werkzeuge, von denen 
keiner weiß wozu sie alle gut sind.

Ich kenne die PICs gut.
Jeder PIC hat eine andere Pheriperie drin, irgend welche Bits sind 
anders, andere Position, mehr oder weniger Funktionen, selbst bei den 
neuen PIC24.
Jedesmal muss man das Datenblatt wieder neu studieren was denn jetzt 
schon wieder anders ist. Wenn man viel entwickelt ist das doch nervig, 
lästig und Zeitintensiv.
Hingegen beim STM32 ist die Pheriperie durchgängig gleich. Punkt. Einmal 
ins Datenblatt geschaut und gelernt, für alle Derivate anwendbar.

Da oben diskutiert wurde was das für eine schlechte Atmel-Angelegenheit 
ist, konnte ich es nicht verkneifen den STM32 mit in diese Diskussion zu 
werfen.
Nach wie vor bin ich der Meinung, dass es leichter ist einmal den 
STM32/Cortex/ST FW-Lib zu kapieren als jedes mal, wenn man einen 
anderen AVR braucht wieder neu das Datenblatt zu studieren.

Ich hatte in den letzten 20 Jahren schon einige durchgemacht, Z80, 
68HC11, AT90CAN128, AVR, PIC, dsPIC, M16C, LPC2294, LPC2368. Den C166 
wollte ich mal, ist aber schwer beschaffbar. Aber alle haben irgend 
welche "Macken".

Der einzige Nachteil des STM32F107xx ist, dass der kein SDIO mit drin 
hat.

Es soll sogar Leute geben, die 6-Pin AVRs als adaptive Spannungsregler 
einsetzen. Und die kosten nicht mal mehr, als ein Spannungsregler...

MarkusB schrieb:

> Andere arbeiten seit Jahren mit AVR, brauchen etwas mehr Leistung,
> wollen aber nicht das gesamte Equipment (Programmer, IDE...) wegwerfen
> und neu kaufen. Dann schaut man sich halt erstmal die Xmega an.
>
> Vielleicht sind die Xmega doppelt so teuer wie die STM32, aber für das
> bei der Entwicklungsumgebung eingesparten Geld kann man nen ganzen
> Haufen Xmega kaufen (nicht alle arbeiten mit dem GCC)

Das ist ein Grund. Ein weiterer ist die Erfahrung, die man mit der 
bisher eingesetzten Familie hat. Jeder Controller hat seine "Macken" und 
man arbeitet sich nicht in eine neue Familie ein, nur weil dort der 
passende Typ 50 Cent günstiger wäre (es sei denn, man hat sehr hohe 
Stückzahlen).

Wir arbeiten hier z.B. fast ausschließlich mit AVRs - die kennen wir aus 
dem FF und bisher sind sie für uns vollkommen ausreichend.

Es kommen zu den (relativ kleinen) Beträgen der neuen Software/Hardware 
also noch die Einarbeitungszeit + Risiken + Bibliotheksanpassung bei der 
Umstellung.

> Also lass stecken. Wer mit dem STM32 arbeiten will wird schon von
> alleine drauf kommen

Interessant ist er auf jeden Fall :-)

Chris D.

MarkusB schrieb:
>> Es soll sogar Leute geben, die 6-Pin AVRs als adaptive Spannungsregler
>> einsetzen. Und die kosten nicht mal mehr, als ein Spannungsregler...
>
> Das würde mich interessieren. Gibts dazu was online?

Nö, aber bei mir auf dem Labortisch ;-).

MarkusB schrieb:

> "Bis zu 12 Timer", aber beim zweiten Blick entpuppt sich das dann in
> "ja, 2 Timer können das, 3 können das, einer ist der Watchdog, ein
> andere Systick usw"

Yep, Watchdogs und RTCs mit den übrigens Timern in einen Topf zu werfen 
ist keine gute Idee. Ist aber nur die Zählweise, das Marketinggewäsch 
auf Seite 1 vom Datasheet.

Wenn man diesen Unfug abzieht bleiben bei den nicht 
funktionsspezifischen Timern 3 Varianten übrig:
(1) Ein paar ganz einfache ohne externe Funktion.
(2) Die universellen mit capture/PWM/...
(3) Ein paar von (2) haben zusätzlich motor control PWM features, sind 
aber sonst identisch.

Den Systick hat man mit dem Cortex-Core immer drin, da kann ST nix für.

> Bei dem Xmega: "acht 16 Bit Timer, alle können das selbe, Punkt Ende".

Hmm. Ich komme bei den "A" Typen auf 4 verschiedene: Die TCs, den 
Watchdog und zwei Sorten RTCs.

Moment mal. Der STM32F103xF / STM32F103xG hat 14 Timer*.

Davon:
- 2 mit Motion Control (4 Ausgänge + 4 negierte Ausgänge)
- 2 Interne vollwertige Timer (nur ohne Pins nach aussen)
- 10 mit 1..4 nach aussen geführten Pins.

Im Artikel STM32 steht was mit 16 Timern, woher die Zahl kommt weiß 
ich nicht, im Product Selector von ST kann auch nur 14 eingegeben 
werden. Ich habs mal im Artikel richtig gestellt.

*(Systic, RTC und WDG nicht mitgerechnet)

Sehr geehrter Herr Müller,

kannst Du jetzt vielleicht mal langsam mit Deinem STM-Gespamme aufhören? 
Jeder dritte Thread in dem es um direkte Fragen zu Controllern geht, 
wird von Dir gekapert, um Deinen ach so tollen Controller hervorzuheben. 
Wir wissen es inzwischen! Wenn Du wieder etwas Neues in den 
Datenblättern gefunden hast, behalt´s für Dich. Wir können selber lesen.

Hochachtungsvoll!