www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Nachteil bei verschiedenen µC


Autor: Koray (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Forum,

ich habe mir letztens ein paar Informationen geben lassen bezüglich der 
µC. Für meine Zwecke wurde der Attiny2313 empfohlen. Jetzt lautet meine 
Frage was für ein Nachteil würde es haben, wenn ich lieber einen 
stärkeren µC (z.B. Atmega8) nehme, ausser der Preisunterschied

Gruß
Koray

Autor: Stefan B. (stefan) Benutzerseite
Datum:

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

Autor: Koray (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alles klar, danke für die info

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: Marcus B. (raketenfred)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Walter Tarpan (nicolas)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Für Anfänger und Nachbauer definitiv nein.

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

MfG Spess

Autor: Falk Brunner (falk)
Datum:

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

Autor: A. K. (prx)
Datum:

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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier sind alle Erweiterungen aufgelistet. Möge der Anwender entscheiden.

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

Autor: Martin Gerken (mager)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: MarkusB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ATmega8, 16, 32, 128.. würde ich aus einem Grund nicht mehr verwenden. 
Bei dieser Generation herrscht noch ein ziemliches Chaos bei den 
Registern

Das mag im Einzelfall keine Rolle spielen, aber wenn man sich eine 
Library schreiben will, die auch für anderen AVR Funktioniert, fängt man 
doch ziemlich das Fluchen an, weil man mit einer regelrechten #if 
defined() Orgie nicht nur die unterschiedlichen Registernamen zuordnen 
muss sondern teilweise auch verschiedene Codesegmente braucht.

Wer schonmal versucht hat, eine universelle USART Routine zu schreiben, 
weiß, wovon ich rede. Da sind die Xmega ein echter Segen

Autor: Andreas Ferber (aferber)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: MarkusB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> 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?!?
Gebastelt sicher nicht. Ist einfach historisch gewachsen. Atmel hat wohl 
versucht, zu den älteren Modellen möglichst kompatibel zu sein. 
Stichwort ATmega128 und PortF ist das glaube ich, bei dem ein Register 
aus der Reihe schlägt

> Dort ist der MSP430 deutlich besser. Dort ist z.B. Timer 0 in
> alles Derivaten identisch, oder?

Ich weiß nicht, wie es bei den MSP430 ist, aber bei den Xmega hat Atmel 
eindeutig gelernt und gnadenlos aufgeräumt. Viel strukturierter geht es 
eigentlich kaum noch

Autor: Andreas Ferber (aferber)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: A. K. (prx)
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:

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

Autor: Andreas Ferber (aferber)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: A. K. (prx)
Datum:

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

Autor: MarkusB (Gast)
Datum:

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

Weil das ein 32 Bit Controller ist, den nicht jeder braucht? Und bevor 
ich mich mit ARM rumschlage nehm ich erstmal die Xmega. Die sind auch 
aufgeräumt

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eheheh, wusst ichs doch.
Wird nur drauf eingehauen.
Ihr banausen.

Anstatt den Artikel STM32 mal zu lesen...

Autor: Falk Brunner (falk)
Datum:

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

Autor: Streitsüchtig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wollte schon immer mal bei dem Streit AVR - STM32 mitmachen. Also 
mal mein Beitrag hierzu:

Markus Müller schrieb:
> Wiso nimmt man nicht einfach einen STM32.
>
>...
>
> Aus Erfahrung kann ich nur den empfehlen. Egal was man für ein Problem
>
> hat, der deckt alles ab.



Warum man nicht den STM32 nehmen sollte?

Erstmal sollte man das nicht tun, weil du stääändig bei jedem Thread wo 
man auch nur im Entferntesten vom STM32 sprechen könnte, deinen 
Marketinggenerator rausholst und los sabbelst. Das geht einem sowas von 
auf die Eier.

Dann möchte ich das mal aus einer etwas anderen Perspektive beleuchten.

Ich bin Fotograf. Leidenschaftlich hoch 10 und so.. Jo.

Warum ich nach wie vor eine DSLR von Anno keine Ahnung besitze? Weil ich 
damit das machen kann was ich will. Fotos. Sicher es gibt neue Kameras 
die haben weniger Rauschen und viel mehr Bilder/s und sogar 
Videofunktion! Toll! Wirklich!

Brauch ich aber nich. Ich kenne meine Kamera. Meine Kamera kennt mich. 
Funktioniert. Schön.

Der Nachteil gegenüber etwas "besserem" ist doch meist auch der 
Funktionsumfang und damit das Unbekannte oder Ungewohnte.

Du kannst nem schlechten Fotomann ne Mamiya in die Hand drücken und er 
wird schlechtere Fotos machen als mit jedem Aldi Teil.

Bei ucs ist das ganze nicht anders. Warum sollte er, wenn jemand ihm 
einen ATtiny(!) empfiehlt, einen 32-bit Prozessor verwenden mit 
Funktionen die beim Reifenwechsel anfangen und kurz vorm Beglücken der 
Ehefrau enden?

Ich kann dieses undifferenzierte gelaber einfach nicht ab.

Es kommt IMMER darauf an was man schon kann und was man machen möchte.

Autor: Markus Müller (mmvisual)
Datum:

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

Autor: Stefan Wimmer (wswbln)
Datum:

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

Autor: Andreas K. (derandi)
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:

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

Autor: MarkusB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nur nicht jeder braucht einen 32 Bit Controller mit 40 IO und mehr. 
Viele BRAUCHEN vielleicht mal einen kleinen Controller im 8 Pin SSOP 
Gehäuse, selbst wenn ein STM32 mit 128kB Flash genauso teuer ist wie der 
8 Pin µC mit 1kB.

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)

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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

Autor: MarkusB (Gast)
Datum:

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

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

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

Autor: MarkusB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris D. schrieb:
> Interessant ist er auf jeden Fall :-)

Zweifellos. Ich hab mir gerade mal einen raus gepickt und überflogen. 
Was mich schon auf den ersten Blick gestört hat war, dass da zwar stand 
"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"

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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

Autor: A. K. (prx)
Datum:

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

Autor: MarkusB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Hmm. Ich komme bei den "A" Typen auf 4 verschiedene: Die TCs, den
> Watchdog und zwei Sorten RTCs.

Ich hab ja nur die T/C gezählt. Mit RTC, Watchdog usw kommt ich auch auf 
10 oder 11 Timer. Aber ich hab für Marketing Gewäsch nix übrig

War halt typisch. Ich lese auf der Webseite in der Übersicht "blablabla 
12 Timer blablabla". Woah, 12 Timer? Geil. Dann ein Blick ins 
Datenblatt... Ich weiß, die Aussage ist korrekt, aber halt doof.

Autor: Markus Müller (mmvisual)
Datum:

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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

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.