ATMega2560 - was kommt danach ?

Stefan U. schrieb:
> Danach komen Xmega Controller, die haben allerdings 32 Bit

Nö. XMega arbeiten mit der AVR8 Architektur, sind allerdings legal höher 
zu takten und haben neue Peripherie. Innendrin werkelt aber der AVR8 
Kern und z.B. der gute alte AVR-GCC baut die Programme.
Zu teuer sind sie m.E. aber wirklich.

Benjamin S. schrieb:
> Zur Zeit nutze ich einen ATMega2560 und habe z.B. bei LCD Anwendungen
> immer mit der Geschwindigkeit und dem Speicher zu kämpfen.

Ja, für Grafik-Displays ist der AVR schlecht geeignet. Da sollte man 
schon >64kB Daten adressieren können.
Gängig sind dafür die ARM-Cortex von NXP oder ST.
Welches GLCD möchtest Du denn ansteuern?

Mir macht GLCD-Programmierung keinen Spaß. Ständig gibt es 
Änderungswünsche. Dem einen gefällt die Menüaufteilung nicht, dem 
anderen die Farben, dem nächsten die Schriftarten usw. Mit GLCD kann man 
es niemandem recht machen.
Gefühlt gehen 99% der Entwicklungszeit für das GUI drauf und nur 1% für 
die eigentliche Gerätefunktion.

@  Benjamin S. (benjamin_s316)

>nachdem ich nun einige Jahre mit allen möglichen AVRs verbracht habe
>stoßen die Applikationen immer öfter an Grenzen.

Wirklich? Hast du mal versucht herauszufinden, woran das liegt? Ist die 
CPU WIRKLICH zu langsam und der Speicher WIRKLICH zu klein, oder liegt 
es eher an deiner Programmierung?

>Zur Zeit nutze ich einen ATMega2560 und habe z.B. bei LCD Anwendungen
>immer mit der Geschwindigkeit und dem Speicher zu kämpfen.

Was macht denn deine LCD-Anwendung? Echtzeitdarstellung komplexer Daten?

>Nun ist die Frage, was kommt danach und wo kann man sinnvoll anknüpfen ?
>Generell würde ich gerne Speicher und Geschwindigkeit mindestens
>verdoppeln.

ATXmega wäre eine Option, wenn man nicht großartig "umschulen" will. In 
Anbetracht der heute verfüghbaren 32 Bit uCs ist der aber eher ein 
Kompromiss.

>Bedeutet das zwingend den Umstieg auf 32Bit

Zwingend nicht, aber es ist in vielen Fällen sinnvoll, WENN du wirklich 
deutlich mehr CPU-Leitung brauchst und deine Software die vorhandene 
Hardware schon gut auslastet.

>und was ändert sich dann,
>z.B. mit den AT32UC.. Prozessoren. Würde die gleiche Software in C (AVR
>Studio), natürlich mit Portanpassungen, auch darauf laufen ?

Wenn sie halbwegs gescheit strukturiert ist, ja.

Peter D. schrieb:
> Gängig sind dafür die ARM-Cortex von NXP oder ST.

… oder halt die von Atmel.  Vorteil für den AVR-Umsteiger, so er
sich zuvor an Atmel Studio gewöhnt hatte: er kann mit der gleichen
Umgebung weitermachen.

Jörg W. schrieb:
> Vorteil für den AVR-Umsteiger, so er
> sich zuvor an Atmel Studio gewöhnt hatte: er kann mit der gleichen
> Umgebung weitermachen.

Stimmt, die Microchip-Cortex gibt es auch.

Schade, daß die Luminary/TI-Cortex aussterben.
"Not Recommended for New Designs (NRND)"
Das integrierte PHY fand ich sehr bequem fürs Layout.

MaWin schrieb:
> Linux

Moment mal: ein Prozessor, der ein VM-Betriebssystem fahren kann,
ist dann aber schon mal eine völlig andere Nummer.

Er wollte den Controller wechseln.  Auf solchen läuft kein full
featured OS, welches virtual memory benötigt.  Wäre aber für den
Zweck auch gar nicht nötig.

Route_66 schrieb:
> Grafik?

Ja, es wird ein TFT Display angesteuert. Erst waren es nur ein paar 
Buttons, jetzt kommen Bilder usw. dazu, was die ganze Sache etwas 
langsam macht.


Peter D. schrieb:
> Mir macht GLCD-Programmierung keinen Spaß. Ständig gibt es
> Änderungswünsche. Dem einen gefällt die Menüaufteilung nicht, dem
> anderen die Farben, dem nächsten die Schriftarten usw. Mit GLCD kann man
> es niemandem recht machen.
> Gefühlt gehen 99% der Entwicklungszeit für das GUI drauf und nur 1% für
> die eigentliche Gerätefunktion.

Das kann ich 1000% nachvollziehen !! Es wird ein 3.2" TFT (ILI9341) mit 
Touch angesteuert. Es funktionert, aber ist schon alles sehr am Limit.

Falk B. schrieb:
> Wirklich? Hast du mal versucht herauszufinden, woran das liegt? Ist die
> CPU WIRKLICH zu langsam und der Speicher WIRKLICH zu klein, oder liegt
> es eher an deiner Programmierung?

Die Programmierung ist sicherlich nicht optimal, aber schon ok. Manchmal 
ist es auch bequemlichkeit, z.B. ganzes Display und zeichnen lassen, 
anstatt Teilbereiche zu löschen. CPU Geschwindigkeit hängt auch bei 
Signalerzeugung, Ansteuerung für VCOs. Da darf es gerne etwas mehr sein.

MaWin schrieb:
> Willst du nicht auch mal auf einen Prozessor wechseln, der Video und
> Graphik, Linux und Ethernet kann ?

Eigentlich nicht. Das meiste sind Standalone Geräte mit einer festen 
Aufgabe und ich bin frih das ich den C-Code komplett selbst schreibe und 
überblicke, wenn ich da noch Linux dazwischen hätte wäre das zu viel. 
Schnittstellen brauche ich auch nicht so viele.

Falk B. schrieb:
> Zwingend nicht, aber es ist in vielen Fällen sinnvoll, WENN du wirklich
> deutlich mehr CPU-Leitung brauchst und deine Software die vorhandene
> Hardware schon gut auslastet.

Ich werde auf die 32 Bit von ATmel umsteigen, komme mit dem AVR Studio 
ganz gut klar.

Danke für eure Hilfe !!

Nop schrieb:
> Nö, mit Cortex-M4 kann man auch µC-Linux laufen lassen.

Klar, man kann auch auf einem AVR ein CP/M laufen lassen.

Die Frage ist eben nur, was wirklich Sinn hat.  Ein RTOS auf einem
Controller ist OK, aber Linux nur um des Linux Willen?  (Mal von
den Problemen mit der GPL ganz abgesehen: welche Firma im
Embedded-Bereich würde schon freiwillig ihren Kunden alle Quellcodes
mitgeben wollen?)

Man bekäme sicher auch ein V7 UNIX auf einen Cortex M4 portiert, das
brauchte noch keinen VM …

@ Benjamin S. (benjamin_s316)


>Die Programmierung ist sicherlich nicht optimal, aber schon ok.

Wie hast du das festgestellt? Hast du GEMESSEN? Hast du die kritischen 
Funktionen WIRKLICH gefunden? Oder ist das alles nur Bauchgefühl?

https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung

> Manchmal
>ist es auch bequemlichkeit, z.B. ganzes Display und zeichnen lassen,
>anstatt Teilbereiche zu löschen.

Da geht es schon los.

>CPU Geschwindigkeit hängt auch bei
>Signalerzeugung, Ansteuerung für VCOs. Da darf es gerne etwas mehr sein.

Was für Signale werden denn da erzeugt? Eine VCO ANsteuerung klingt auch 
nicht nach einem CPU-Killer.

>Ich werde auf die 32 Bit von ATmel umsteigen, komme mit dem AVR Studio
>ganz gut klar.

Vorsicht! Einige Serien sind abgekündigt und nicht für neue Designs 
empfohlen!

Falk B. schrieb:
>> Ich werde auf die 32 Bit von ATmel umsteigen, komme mit dem AVR Studio
>>>ganz gut klar.
>
> Vorsicht! Einige Serien sind abgekündigt und nicht für neue Designs
> empfohlen!

Da er einen Nachfolger für einen AVR sucht, würde ich an seiner Stelle
nicht mit den Cortex-M4 ins Rennen gehen, sondern eher mit den M0+
(SAMD21, SAML21 etc.).  Die haben eine etwas moderner anmutende
Peripherie als die alten Boliden (SAM4E etc.).

Stefan U. schrieb:
> In der Atmega Serie ist der 2560 das Ende der Fahnenstange.

Man sollte allerdings die kleine Anomalie im Auge behalten, dass der 
Atmega1284 doppelt soviel RAM (16 kByte statt 8 kByte) und 20 statt 16 
Mhz hat, dafür allerdings nur halb so viel FLASH und weniger Pins.

Nop schrieb:

> Zudem unterliegt zwar das Linux der GPL, das gilt
> aber nicht für die darauf aufsetzenden, selbstgeschriebenen
> Applikationen, in denen dann das Knowhow stecken kann.

Ich vermute, der TE hatte aber eine andere Klasse von Geräten im Blick
als solche, bei denen man das Knoffhoff nur in den Applikationen
hat.