AVR atmega328 ausgereizt? Und nun? 32bit?

2x 16 Bit Timer findest du bei vielen 8-Bit AVRs. Nur weil dein 
grottenalter Mega32 die nicht hat, solltest du keine falschen Schlüsse 
ziehen.
Schau mal in Richtung Mega1284. Aber auch viele kleinere Kaliber haben 
mindestens 3 Timer (2 davon 16 Bit).
Dazu 2x UART und/oder 2x SPI sind keine Seltenheit.
Schau dir mal die parametrische Suche auf der Atmel Seite an.

Umsteiger schrieb:
> Nun stelle ich fest, dass ich für
> die Weiterentwicklung des letzten Projektes ZWEI 16-Bit Timer/ Counter
> benötige, die die 8-Bit Prozessoren von AVR scheinbar nicht haben.

Z.B. der ATmega2560 hat 4 16Bit-Timer mit je 3 PWM-Ausgängen.
Als DIP mit 2 16Bit Timern gibt es den ATmega162 und den ATmega1284.

@ Umsteiger (Gast)

>doch_nicht_Umsteiger, jedenfalls jetzt noch nicht.

Vor allem wäre ich mit der Aussage "AVR atmega328 ausgereizt" 
vorsichtig. Denn das hast du mit hoher Wahrscheinlichkeit NICHT! Um die 
AVRs wirklich AUSZUREIZEN muss man schon EINIGES machen.

Wofür brauchst du den 2. 16 Bit Zähler?

Alternativ Xmega-Reihe. Die haben richtig viel Peripherie, sind aber 
hier im Forum scheinbar nicht so beliebt...

Ob es die im Arduinoformat gibt, weiß ich leider nicht.

@ Felix Adam (Firma: SOMTRONIK) (madifaxle)

>Alternativ Xmega-Reihe. Die haben richtig viel Peripherie,

Stimmt, die haben DEUTLICH mehr sind aber dennoch sehr ähnlich in der 
Nutzung.

>sind aber hier im Forum scheinbar nicht so beliebt...

Naja, der Zuwachs an Power ist halt nicht sooo groß wie bei den 32 
Bittern. Ich hab trotzdem einen erfolgreich in einem Projekt eingestzt 
und musste mich nur wenig um den neuen Controller kümmern, der Übergang 
war sehr angenehm.

Beitrag "Re: Viel RAM am kleinen Controller"

>Ob es die im Arduinoformat gibt, weiß ich leider nicht.

AFAIK nein.

Umsteiger schrieb:
> Ich benötige die Timer als Zähler in einem Frequenzumrichter, wie er
> hier im Forum vorgestellt wurde (Axel Jeromin?). Durch den 8 Bit Timer
> läßt sich die Frequenz des Drehfeldes am FU nicht so fein einstellen,
> wie ich es mir gewünscht hätte.

Es ist doch kein Problem aus einem 8 bit Timer einen 16 bit Timer zu 
machen. Du musst doch nur ein wenig Bits schubsen/schieben. Das ist doch 
kein Ding.

Felix A. schrieb:
> Alternativ Xmega-Reihe.

Wobei die Peripherie über große Strecken schon so viel anders ist,
dass man dann auch wirklich gleich auf einen Cortex-M0+ umsteigen
kann.  Im Arduino-Format bekommt man sie dann obendrein ebenfalls.

Umsteiger schrieb:
> Und den ATmega2560 scheint es sogar noch
> als preiswertes Board bei Arduino zu geben.

und der Arduino mighty 1284p ist viel schlanker mit doppelt so viel 
SRAM.

http://www.ebay.de/itm/Mighty-Mini-ATMega1284p-compatible-with-Arduino-/331463717483?hash=item4d2cc6f26b:g:o1IAAOSw34FVDM6K

Für mich interessanter Thread. Mich würde das auch interessieren, auf 
welche 32Bitter man am einfachsten umsteigen kann, wenn man vorher 
Atmegas und XMegas programmiert hat. Wenn es nämlich in Richtung DSP und 
Bildverarbeitung geht, da wird es mit den 8Bittern eng.
...Im Prinzip gibts ja überall ein Datenblatt, das man lesen kann, aber 
mich würde es auch interessieren, welche 32Bitter man am "einfachsten" 
ansprechen kann.

mfg

Bahnfahrer schrieb:
> Jörg W. schrieb:
>> dass man dann auch wirklich gleich auf einen Cortex-M0+ umsteigen
>> kann.
>
> Jo, wenn man die Zeit hat, sich in 1001 Seiten ARM-Lektüre einzulesen.

Du übertreibst.  Das Datenblatt eine SAMD20 ist 700 Seiten lang.
Im Gegensatz zum Xmega mit seiner unsäglichen Trennung in XmegaA
und XmegaA1 (welches in vielen Kapiteln so tut, als würde es zum
Thema was schreiben, um dann nur jeweils eine Seite „Schlagzeilen“
zu liefern) und im Gegensatz zur Cortex-Konkurrenz, die ihre Daten
auf ein halbes Dutzend Dokumente verteilt, hat man wenigstens wieder
alles in einem Dokument, wie seinerzeit beim AVR schon.

Wobei mir gar nicht ganz klar ist, warum das eigentlich 700 Seiten
verschlingt, während XmegaA mit 430 auskommt – rein gefühlt finde
ich den XmegaA komplexer.

> Und das ist nur das Datenblatt :-/. Ganz zu schweigen von der völlig
> anderen Architektur.

Was interessiert dich in C die Prozessorarchitektur so großartig?
Ob der Compiler nun zum Addieren einer 32-Bit-Zahl 2 x 4 8-Bit-Register
oder 2 32-Bit-Register beladen muss, kann mir in der Hochsprache recht
egal sein.

Eigentlich interessieren dich in erster Linie die Peripherals, das
Einschalten des richtigen Systemtakts etc. pp.  Das ist bei beiden,
Xmega und SAMDxx, im Vergleich zur Einfachheit des AVR ein ziemlicher
Schritt.

> Jörg W. schrieb:
>> Wobei die Peripherie über große Strecken schon so viel anders ist,
>
> Nicht wirklich.

Finde ich schon.  Nicht unangenehm, aber eben so weit anders,
dass man erstmal wieder für jeden Schritt ins Datenblatt gucken
muss.

> Nur umfangreicher und aufgeräumt, DMA-tauglich und
> Event-System unterstützt. Trotzdem sehr übersichtlich, im positiven
> Sinn.

Genau das ist sie aber bei den SAMDxx ebenfalls.  DMA gibt's erst
ab SAMD21.

Der einzige wirkliche Mehraufwand, den man beim SAMDxx im Vergleich
zu den Xmegas hat ist, dass man sich einen Plan über die so genannten
generic clock generators vorher machen muss, also festlegen, welche
Baugruppe mit welchem Takt arbeitet.

@ Umsteiger (Gast)

>> Wofür brauchst du den 2. 16 Bit Zähler?

>es gibt vermutlich kein Projekt, dass alle Fähigkeiten eines AVR
>gleichzeitig ausreizt,

Darum geht es nicht. Aber darum, aus einer gegebenen Hardware richtig 
viel rauszuholen. Das schafft man vor allem nur mit den richtigen 
Konzepten und Erfahrung.

>Ich benötige die Timer als Zähler in einem Frequenzumrichter, wie er
>hier im Forum vorgestellt wurde (Axel Jeromin?). Durch den 8 Bit Timer
>läßt sich die Frequenz des Drehfeldes am FU nicht so fein einstellen,
>wie ich es mir gewünscht hätte. Ein 16 Bit Timer/Counter wäre da
>hilfreich gewesen.

Kann sein, kann aber auch das falsche bzw. suboptimale Konzept sein. 
Denn ein Umrichter arbeitet meist mit konstanter PWM-Frequenz, damit hat 
man schon mal die grundlegende Zeitbasis (die auch ein 8 Bit TImer 
problemlos erzeugen kann). Den Rest macht man mit cleveren Konzepten, 
hier wahrscheinlich DDS. Damit kann man nahezu unbegrenzt fein die 
Frequenz einstellen.

> Abhilfe scheint ja ein Atmega2560 zu sein, auf einem
> Arduino Board.

Mach mal.

>Sorry noch mal an alle Liebhaber von AVR Prozessoren.

Warum? Du hast keinen beleidigt, nur dich ein wenig weit aus dem Fenster 
gelehnt ;-)

@ Bahnfahrer (Gast)

>> dass man dann auch wirklich gleich auf einen Cortex-M0+ umsteigen
>> kann.

>Jo, wenn man die Zeit hat, sich in 1001 Seiten ARM-Lektüre einzulesen.
>Und das ist nur das Datenblatt :-/. Ganz zu schweigen von der völlig
>anderen Architektur.

EBEN!

>> Wobei die Peripherie über große Strecken schon so viel anders ist,

>Nicht wirklich. Nur umfangreicher und aufgeräumt, DMA-tauglich und
>Event-System unterstützt. Trotzdem sehr übersichtlich, im positiven
>Sinn.

Meine Rede! Daumen hoch! Beim "Umstieg" vom AVR auf Xmega bekommt man 
ein gutes Stück mehr Leistung für wenig Einarbeitungsaufwand!

Beitrag "Re: AVR atmega328 ausgereizt? Und nun? 32bit?"

@Joachim B. (jar)

>> Und den ATmega2560 scheint es sogar noch
>> als preiswertes Board bei Arduino zu geben.

>und der Arduino mighty 1284p ist viel schlanker mit doppelt so viel
>SRAM.

Der Flash des ATmega2560 ist als Arduino so oder so nicht voll nutzbar. 
Im Normalfall nur die ersten 64kB, bestenfalls 128kB wenn man viel 
Programm hat. 256kB kriegt man nur mit Workarounds hin, keinesfalls 
direkt per Arduino-Style!

Beitrag "Re: Fehlermeldung Arduino C++"

Falk B. schrieb:
> Beim "Umstieg" vom AVR auf Xmega bekommt man ein gutes Stück mehr
> Leistung für wenig Einarbeitungsaufwand!

Naja, Falk, das ist bei den Cortexen aber auch nicht so viel anders,
insbesondere nicht, wenn man bei Atmel bleibt.

Wer den Umstieg von MegaAVR auf Xmega als einfach empfindet, der wird
auch kein Problem mit so einem SAMDxx haben.

Falk B. schrieb:
> Der Flash des ATmega2560 ist als Arduino so oder so nicht voll nutzbar.
> Im Normalfall nur die ersten 64kB, bestenfalls 128kB wenn man viel
> Programm hat.

Ich denke, dass du hier zu sehr verallgemeinerst.

Ja, ein Array muss in C mit dem Datentyp "int" adressierbar sein
(einschließlich Vorzeichen, schließlich ist foo[-1] ein gültiger
Ausdruck), und bei GCC muss das wohl auch alles mit char*-Arithmetik
machbar sein.

Aber das limitiert nur erstmal den Zugriff auf die Daten, nicht den
Code.

> 256kB kriegt man nur mit Workarounds hin, keinesfalls
> direkt per Arduino-Style!

Warum eigentlich nicht?  Programme mit mehr als 128 KiB funktionieren
ja nun schon seit Jahren, warum bei Arduino dann nicht?

@ Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite

>> Beim "Umstieg" vom AVR auf Xmega bekommt man ein gutes Stück mehr
>> Leistung für wenig Einarbeitungsaufwand!

>Naja, Falk, das ist bei den Cortexen aber auch nicht so viel anders,
>insbesondere nicht, wenn man bei Atmel bleibt.

Kann sein, die SAMD hab ich noch nicht angeschaut.

>Wer den Umstieg von MegaAVR auf Xmega als einfach empfindet, der wird
>auch kein Problem mit so einem SAMDxx haben.

Naja, ich hab vor länhgerer Zeit mal mit STM32 rumgespielt, was mich 
dabei am meisten abschreit sind die ELLLLLLENNLAAAANGEN Namen der 
Register und die gefühlt TAUSENDEN Einstellungen, die man selbst für 
einfachse IO-Konfifiguration machen muss!!!

Beispiel gefällig?

https://www.mikrocontroller.net/articles/Datenuebertragung-STM32F4

1

void GPIO_initialisieren(void){

2

3

     /* Senddata (Daten) */

4

     GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;

5

     // Ports als Output definieren

6

     GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_3; // Pins 0,1,2,3 aktivieren

7

     GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; // Output Modus: Push-pull 

8

     GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // Abtastfrequenz auf 2MHz       

9

     GPIO_Init(GPIOC, &GPIO_InitStructure);

10

     // GPIOC Konfiguration übergeben, Pointer auf Struktur mit Config

11

12

     /* Steuerleitung */

13

     GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT; // Port als Output definieren 

14

     GPIO_InitStructure.GPIO_Pin = GPIO_Pin_15; // Pin 15 aktivieren 

15

     GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; // Output Modus: Push-pull 

16

     GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // Abtastfrequenz auf 2MHz       

17

     GPIO_Init(GPIOC, &GPIO_InitStructure);

18

     // GPIOC Konfiguration übergeben, Pointer auf Struktur mit Config

19

20

     /* PS2 -> (Pin 9 -> Daten | Pin 11 -> Clock) */ 

21

     GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN; // Port als Input definieren 

22

     GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP; // Input Modus: Pull-Up 

23

     GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9 | GPIO_Pin_11;

24

     // Pin9 und Pin11 aktivieren

25

     GPIO_Init(GPIOE, &GPIO_InitStructure);

26

     // GPIOE Konfiguration übergeben, Pointer auf Struktur mit Config

27

28

}

Dazu kommt das Elend, wählen zu müssen zwischen den Libs zur Zähmung der 
Hardware, die aber ihrerseits wieder hunderte von Funktionen für alles 
Mögliche und Unmögliche bereitstellt oder dann doch wieder old school 
direkter Registerzugriff. Teufel und Belzebub!

@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite

>> Der Flash des ATmega2560 ist als Arduino so oder so nicht voll nutzbar.
>> Im Normalfall nur die ersten 64kB, bestenfalls 128kB wenn man viel
>> Programm hat.

>Ich denke, dass du hier zu sehr verallgemeinerst.

Nö, ich berichte von meinen Erfahrungen.

>Ja, ein Array muss in C mit dem Datentyp "int" adressierbar sein

Schon klar, da begrezt die größe pro Objekt auf 32kB beim avr gcc. In 
Summe gehen aber trotzdem nur 64kB DATEN, weil man sonst über RAMPX 
adressieren muss. Das geht nur mit Makros und passenden Linkerscripts.

>Aber das limitiert nur erstmal den Zugriff auf die Daten, nicht den
>Code.

Das reicht als Problem.

>> 256kB kriegt man nur mit Workarounds hin, keinesfalls
>> direkt per Arduino-Style!

>Warum eigentlich nicht?  Programme mit mehr als 128 KiB funktionieren
>ja nun schon seit Jahren, warum bei Arduino dann nicht?

Weiß ich nicht, bei meinem Test vor einiger Zeit gab es komische 
Effekte.

https://www.mikrocontroller.net/topic/goto_post/4078527

Vermutlich war es aber ein Problem mit Daten >64kB, nicht mit Programm 
>64kB.

Falk B. schrieb:
> Naja, ich hab vor länhgerer Zeit mal mit STM32 rumgespielt, was mich
> dabei am meisten abschreit sind die ELLLLLLENNLAAAANGEN Namen der
> Register und die gefühlt TAUSENDEN Einstellungen, die man selbst für
> einfachse IO-Konfifiguration machen muss!!!

Wobei ein wesentlicher Eindruck überhaupt erst durch die unsäglich 
kompliziert gestaltete ST Library entsteht.

Einfache Peripherie erlaubt nur einfache Konfigurationen. Komplexe 
Peripherie hingegen erlaubt weit mehr Einsatzbereiche, hat aber 
natürlich auch mehr Konfigurationsoptionen. Das liegt in der Natur der 
Sache.

Nur kann man einen solchen Layer auch eleganter gestalten, als ST das 
tat. Keine umständlichen und verwirrenden Structs als Parameter, sondern 
mehr aber dafür einfach gestaltete Funktionen mit überschaubaren 
Parametern.

@ A. K. (prx)

>Nur kann man einen solchen Layer auch eleganter gestalten, als ST das
>tat. Keine umständlichen und verwirrenden Structs als Parameter, sondern
>mehr aber dafür einfach gestaltete Funktionen mit überschaubaren
>Parametern.

Mag sein. Aber wo liegt denn da der Vorteil, wenn ich die selbe Anzahl 
Parameter in ein Struct anstatt direkt in die Register schreibe? Da muss 
ich fast alles doppelt lernen (oder die Hardware direkt vergessen und 
NUR auf die ST Lib schauen, auch nicht so doll).

A. K. schrieb:
> Nur kann man einen solchen Layer auch eleganter gestalten, als ST das
> tat.

Man kann es mit ASF natürlich auch genauso kompliziert machen. ;-)

Falk B. schrieb:
> Vermutlich war es aber ein Problem mit Daten >64kB, nicht mit Programm
> >64kB.

Gut, das verstehe ich.  Ehrlich gesagt, bei mehr als 64 KiB ist
mit einfachen 16-bit-Zeigern eben einfach Schluss.  Das ist was, wo
der ARM einen Systemvorteil hat.

Mehr Code hingegen bekommt man (seit Björn Haase das für Bosch
gebraucht hat und entsprechen Hand an den Compiler gelegt hat)
problemlos auch in einem AVR unter.

Falk B. schrieb:
> Der Flash des ATmega2560 ist als Arduino so oder so nicht voll nutzbar.
> Im Normalfall nur die ersten 64kB, bestenfalls 128kB wenn man viel
> Programm hat. 256kB kriegt man nur mit Workarounds hin, keinesfalls
> direkt per Arduino-Style!

jain, ich weiss
nix Arduino, Atmel Studio, einen m2560 mit Display bestellt, Bildershow 
programmiert und als ich über 64k kam ging nix mehr soll normal sein lt. 
Verkäufer, ich habe es dann bei 64k Bilder belassen, hat mich nicht so 
interessiert.


Jörg W. schrieb:
> Ich denke, dass du hier zu sehr verallgemeinerst.
>
> Ja, ein Array muss in C mit dem Datentyp "int" adressierbar sein
> (einschließlich Vorzeichen, schließlich ist foo[-1] ein gültiger
> Ausdruck), und bei GCC muss das wohl auch alles mit char*-Arithmetik
> machbar sein.
>
> Aber das limitiert nur erstmal den Zugriff auf die Daten, nicht den
> Code.

s.o. beim mighty mini in der Arduino IDE kratze ich grad an der 64k 
"Grenze"? aber bis jetzt habe ich noch nix bemerkt ausser

die fastLED Lib für ws2812b mag den m1284p nicht, alle Timings waren 10% 
zu lahm, eine ws2812b braucht ja 24 Bit a 1,5µs macht in Summe 30µs, mit 
dem m328p klappt das derselbe Code im m1284p braucht 33µs für eine LED 
ist also 10% zu lahm (kein Wunder bei 3 Adressbytes statt 2 
Adressbytes), ich habe in delay.h also eingefügt if defined _1284p_ 
F_CPU x9L/10L
ich gauckel dem 10% weniger Takt vor und das Timing passt.

Der Autor von fastLED wollte nix machen weil der mighty kein offizieller 
Arduino ist.....

na egal.

Oh weh schrieb:
> Michael K. schrieb:
>> Du musst doch nur ein wenig Bits schubsen/schieben. Das ist doch kein
>> Ding.
>
> Jetzt ist mein Interesse geweckt. Jedes mal in einer ISR an einer
> Variablen rum fummeln oder was?

Zum Beispiel. Man könnte zum Beispiel in der ISR für den OVF eine 
Variable bis 255 hoch zählen und nach dem 256. OVF dann entsprechend 
reagieren.

Jörg W. schrieb:
> Wobei mir gar nicht ganz klar ist, warum das eigentlich 700 Seiten
> verschlingt, während XmegaA mit 430 auskommt – rein gefühlt finde
> ich den XmegaA komplexer.

So so, rein gefühlt also ;-)

Falk B. schrieb:

1

 /* Senddata (Daten) */

2

      GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;

3

      // Ports als Output definieren

4

      GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2  | GPIO_Pin_3; // Pins 0,1,2,3 aktivieren

5

      GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; // Output Modus: Push-pull

6

      GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // Abtastfrequenz auf 2MHz

7

      GPIO_Init(GPIOC, &GPIO_InitStructure);

8

      // GPIOC Konfiguration übergeben, Pointer auf Struktur mit Config

9

10

      /* Steuerleitung */

11

      GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT; // Port als Output  definieren

12

      GPIO_InitStructure.GPIO_Pin = GPIO_Pin_15; // Pin 15 aktivieren

13

      GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; // Output Modus:  Push-pull

14

      GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // Abtastfrequenz  auf 2MHz

15

      GPIO_Init(GPIOC, &GPIO_InitStructure);

16

      // GPIOC Konfiguration übergeben, Pointer auf Struktur mit Config

Schlechtes Beispiel. Die zweite Hälfte des Codes hättest du dir sparen 
können, wenn du Pin15 gleich mit in den oberen Teil verodert hättest.

Uwe Bonnes schrieb:
> Gibt es inzwischen einen XMEGA mit Can Controller? Vor einigen
> Electronicas habe ich die Atmel Leute danach gefragt, und als Antwort
> bekommen: Das wird nicht passieren! Fuer mich war es da aus mit den
> (x)AVRs.

Wir werden dich vermissen....

Uwe Bonnes schrieb:
> Gibt es inzwischen einen XMEGA mit Can Controller?

Was heißt „inzwischen“?  An den Xmegas macht keiner mehr was, sie
treiben nun vor allem ihre ARMs weiter.  Bei denen gibt's genügend
mit CAN.

Ehrlich gesagt habe ich ohnehin nie verstanden, wieso man die XMegas auf 
den Markt bringen musste. Preislich nicht attraktiv, von der Gehäuseform 
für viele Bastler uninteressant, eingeschränkter Spannungsbereich, dafür 
ein paar Peripherie-Verbesserungen.

Wenn man schon die ganzen Nachteile in Bezug auf Preis, Spannungsbereich 
und Gehäuseform schluckt, kann man auch gleich auf 32Bit-Controller 
umsteigen.

@ Gastino G. (gastino)

>Ehrlich gesagt habe ich ohnehin nie verstanden, wieso man die XMegas auf
>den Markt bringen musste.

Aufgebohrte AVRs halt.

> Preislich nicht attraktiv,

Relativ.

> von der Gehäuseform für viele Bastler uninteressant,

Das war NIE die Zielgruppe!

> eingeschränkter Spannungsbereich,

Haben fast alle modernen Controller.

> dafür ein paar Peripherie-Verbesserungen.

Ein "paar"?

>Wenn man schon die ganzen Nachteile in Bezug auf Preis, Spannungsbereich
>und Gehäuseform schluckt, kann man auch gleich auf 32Bit-Controller
>umsteigen.

Ansichtssache.

Gastino G. schrieb:
> Ehrlich gesagt habe ich ohnehin nie verstanden, wieso man die XMegas auf
> den Markt bringen musste.

Als der XMega designed wurde, war der Siegeszug der ARMs noch nicht so 
absehbar wie er es heute ist.
Aus der Sicht der Halbleiterfirmen sind die ARMs ja ein zweischneidiges 
Schwert: einerseits haben sie (fast) alle die ARM-Architektur lizensiert 
und verdienen mit daran, andererseits ist die Marge seitdem sicher 
deutlich zurückgegangen. Da ist es schon verständlich, wenn einige 
Firmen versuchten, mit einer eigenen Architektur dagegenzuhalten. Nur 
rechnet sich das eben nicht mehr, wenn mittlerweile 32Bit ARMs günstiger 
als viele firmenspezifische 8-Bitter verkauft werden.

Gruß, Stefan

Gastino G. schrieb:

> von der Gehäuseform
> für viele Bastler uninteressant, eingeschränkter Spannungsbereich, dafür
> ein paar Peripherie-Verbesserungen.

Also SMD und 3,3V sind heute auch bei Bastlern verbreitet. Da wehren 
sich nur noch ein paar ewig gestrige. DAS ist sicher kein Argument.

5V Controller machen heute spätestens bei der Anbindung an andere 
Bausteine Probleme. Die sind nämlich auch alle 3,3V. Dann geht das 
fluchen und pfuschen mit Serienwiderständen, Pegelwandlern, 
Spannungsteilern und Z-Dioden los.

Cyblord -. schrieb:
> 5V Controller machen heute spätestens bei der Anbindung an andere
> Bausteine Probleme.

Wobei das nun eher kein Argument ist: solange es die AVRs gibt, konnte
man sie schon immer auch mit 3,3 V betreiben.  Teils musste man
dafür die „L“-Versionen nehmen, damit sie dafür auch spezifiziert
waren, aber gegeben hat es das seit dem AT90S1200.

Gastino G. schrieb:
> Ehrlich gesagt habe ich ohnehin nie verstanden, wieso man die XMegas auf
> den Markt bringen musste.

So schlecht war deren Idee ja nicht, sie haben nur am ersten Exemplar
so lange herumfummeln müssen, bis er endlich wirklich serienreif war,
dass er zu diesem Zeitpunkt dann tatsächlich schon fast technisch
überholt war.

Cyblord -. schrieb:

> Also SMD und 3,3V sind heute auch bei Bastlern verbreitet. Da wehren
> sich nur noch ein paar ewig gestrige. DAS ist sicher kein Argument.

Doch, ein im Vergleich zu den ATmegas eingeschränkter Spannungsbereich 
ist immer ein Argument. Auch mit den ATmegas neueren Datums kann ich 
problemlos mit 3,3 V arbeiten. Aber eben auch mit 5 V, wenn notwendig.

Und SMD hat für mich als Bastler den großen Nachteil, dass ich es nicht 
mehr stecken kann. Es fallen also Lochraster-Lösungen (evtl. mit Sockel) 
weg - für jeden Controller braucht man eine Adapter-Platine oder gleich 
eine fertige Platine.
Und wenn man dann noch das Problem hat, dass das "gute" AVR Studio 7 in 
Verbindung mit dem Atmel ICE ziemlich zuverlässig AVRs in 
Mini-Ziegelsteine verwandelt, lernt man DIP-Gehäuse noch mehr zu 
schätzen, die man im STK600 einfach wiederbeleben kann.

Fakt ist, dass sowohl beim Spannungsbereich und bei der Gehäuseform 
Einschränkungen gegenüber den ATmegas bestehen. Und Einschränkungen sind 
eben fast immer ein Nachteil.
Wenn ich mit denen leben muss oder kann, dann kann ich auch gleich auf 
32-Bitter umsteigen. Das mag bei kommerziellen Projekten noch etwas 
anders sein, wo jeder Cent Einsparung wichtig ist, aber für mich als 
Bastler ist der Xmega völlig uninteressant.

> 5V Controller machen heute spätestens bei der Anbindung an andere
> Bausteine Probleme. Die sind nämlich auch alle 3,3V. Dann geht das
> fluchen und pfuschen mit Serienwiderständen, Pegelwandlern,
> Spannungsteilern und Z-Dioden los.

Also ich habe hier noch etliche 5 V-Bausteine herumliegen.

Also ich finde auch, dass die ATXMegas schon ihre Berechtigung haben 
aber klar, es gibt auch viele Alternativen.

c-hater schrieb:
> In C wird das z.B. relevant, sobald man Funktionszeiger benutzt.

Ja, und?  Das ist doch trotzdem seit fast einem Jahrzehnt gelöst,
seit Björn Haase die Trampolines eingeführt hat (die er ja als Idee
auch nur aus dem H8 recyclet hat, so ich mich erinnere).

Insofern verstehe ich nicht, warum nun ausgerechnet Arduino das
wieder als Problem haben sollte.

Das einzige wirkliche Thema waren Daten in großen Mengen, da man dort
manuell Hand anlegen musste, um das Zeug mit ELPM einzulesen.

Jörg W. schrieb:
> Ja, und?

Du glaubst doch nicht im ernst, dass jemand, der sich c-hater nennt, 
dieser Sprache auch nur einen Funken Existenzberechtigung zugestehen 
wird?

Michael K. schrieb:
> Jörg W. schrieb:
>> Ja, und?
>
> Du glaubst doch nicht im ernst, dass jemand, der sich c-hater nennt,
> dieser Sprache auch nur einen Funken Existenzberechtigung zugestehen
> wird?

Das nicht, aber er braucht sich auch nicht zu Dingen zu äußern, in
denen er sich ja ganz offensichtlich nicht auskennt.

Jörg W. schrieb:
> Das nicht, aber er braucht sich auch nicht zu Dingen zu äußern, in
> denen er sich ja ganz offensichtlich nicht auskennt.

Das ist eben das, was einen Hater auszeichnet: Er meint, seinen Senf 
auch dazu geben zu müssen, ohne davon Ahnung zu haben.