mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATMega2560 - was kommt danach ?


Autor: Benjamin S. (benjamin_s316)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Moin,

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

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

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

Bedeutet das zwingend den Umstieg auf 32Bit 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 ?

Danke

Benjamin

Autor: Route_66 (Gast)
Datum:

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

Grafik?

Autor: matrixstorm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ATxMega - z.B. ATxMega384C3 ?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In der Atmega Serie ist der 2560 das Ende der Fahnenstange.

Danach komen Xmega Controller, die haben allerdings 32 Bit und etwas 
komplexere Hardware. Bevor du dich mit denen beschäftigst, würde ich 
allerdings eher zum Wechsel auf ARM basierte Controller raten. Ich 
vermute nämlich, dass die Xmega Serie bald aussterben oder noch teurer 
wird, als sie jetzt schon ist.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

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

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Echt nur 8 bit? Dann hat mich jemand veräppelt.

Wie dem auch sei, würde ich trotzdem eher ARM als Xmega verwenden, der 
Grund bleibt der selbe.

: Bearbeitet durch User
Autor: Peter Dannegger (peda)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benjamin S. schrieb:
> ATMega2560 - was kommt danach ?

Die anderen sind schon seit jahrzehnten beim ARM.

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

Kostet auch nicht viel mehr, und es gibt ihn softwarekompatibel von 
dutzenden Herstellern.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Benjamin S. (benjamin_s316)
Datum:

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

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Moment mal: ein Prozessor, der ein VM-Betriebssystem fahren kann,
> ist dann aber schon mal eine völlig andere Nummer.

Nö, mit Cortex-M4 kann man auch µC-Linux laufen lassen. Das geht dann 
logischerweise ohne virtuellen Speicher, weil der M4 keine MMU hat.

Der Haken ist, daß auch dieses Linux noch ziemlich fett ist und 
speichermäßig nicht mit dem onchip-RAM/ROM auskommt. Man muß es in 
externes RAM laden und den Code dann auch von dort aus laufen lassen. 
Das ist dementsprechend lahm, etwa einen Faktor 8 langsamer als 
Programmausführung aus dem onchip-ROM.

Sinnvoller wäre es natürlich, gleich ein RTOS zu nehmen. Wenn 
Geschwindigkeit aber egal ist, dann hat µC-Linux den Vorteil, daß man 
viele zumindest kleinere Linuxprogramme mehr oder weniger unverändert 
laufen lassen kann, wodurch man einen riesigen Softwarepool hat.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Andreas K. (andreasmc)
Datum:

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

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Die Frage ist eben nur, was wirklich Sinn hat.  Ein RTOS auf einem
> Controller ist OK, aber Linux nur um des Linux Willen?

Schrieb ich - wegen des Softwarepools. Spart also Entwicklungszeit.

> (Mal von
> den Problemen mit der GPL ganz abgesehen: welche Firma im
> Embedded-Bereich würde schon freiwillig ihren Kunden alle Quellcodes
> mitgeben wollen?)

Bei Routerfirmen ist das völlig normal, ohne daß die daran 
pleitegegangen wären. 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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

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.