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
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?
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.
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
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.
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.
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.
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 !!
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.
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.