Hallo Leute, bislang dachte ich, der ATmega328PB würde für meine Belange ausreichen. Stelle aber gerade fest, dass ich doch etwas mehr brauche (noch ein UART, gerne 12-Bit Auflösung, mehr Timer mit besseren Capture-Möglichkeiten). Am naheliegendsten wäre also der Übergang zu einem ATXMega, etwa ATXMega32A4, ein TQFP44 lässt sich auch noch ganz gut löten. Frage zur Portierung (abgesehen von der anderen Modellierung in den Header-Files): wie (un)ähnlich sind sich die I2C- (und auch SPI- und Uart)-Module? Danke für sachdienliche Hinweise.
Die Peripheriemodule unterscheiden sich erheblich, ein Blick in die zugehörige Register-Doku zeigt, daß man um eine weitgehende Neuprogrammierung nicht herumkommt. Solltest Du etwas "höher", z.B. mit Bascom programmieren relativiert sich die Sache natürlich. Tipp zum Xmega: Nicht die A4 sondern die A4U Typen wählen, die sind neuer und ausgereifter da fehlerfreier.
Das gilt für alle AtXmegas, immer die -U Varuanten nehmen, also A1U, A3U, A4U... Auch niedlich sind die E5, die haben zwar kein USB, sind aber sehr klein und haben unheimlich flexible Timer und Custom Logic.
Nicht zu vergessen sind ganz neue, zusätzlich vorhandene Ansteuer- Möglichkeiten der neuen Peripherie via DMA und Event-System.
Normalerweise kapselt man seine Hardwarefunktionen. Dann fällt die Portierung leichter. Von Anfang an angewöhnen. Die Xmegas sind toll, nur leider stimmt das Preis / Leistungsverhältnis nicht. Für Hobby aber egal.
Nils N. schrieb: > Normalerweise kapselt man seine Hardwarefunktionen. Dann fällt die > Portierung leichter. Von Anfang an angewöhnen. Nennt sich dann Arduino und ist ja Böse Böse.
Hans schrieb: > Nils N. schrieb: >> Normalerweise kapselt man seine Hardwarefunktionen. Dann fällt die >> Portierung leichter. Von Anfang an angewöhnen. > > Nennt sich dann Arduino und ist ja Böse Böse. Profis nehmen C, denn C ist ja portabel. Wann, wenn nicht in solcheinem Fall, soll denn die "portabilität" von C zum Zuge kommen? Also einfach neu kompilieren...
Hast du denn einen Programmieradapter und Debugger für den Xmega? Wenn nicht, dann vergleiche mal die Kosten mit anderen Alternativen, zum Beispiel Programmieradapter/Debugger: https://www.amazon.de/ST-Link-Programming-H%C2%A8%C2%B9lle-Emulator-Downloader/dp/B01F37YMJ4/ref=sr_1_4?ie=UTF8&qid=1518288132&sr=8-4&keywords=st-link&dpID=413TMVd4l1L&preST=_SY300_QL70_&dpSrc=srch Ein kleiner µC Board dazu: https://www.amazon.de/Gazechimp-Minimum-System-Development-Arduino/dp/B01N4E8RTE/ref=sr_1_fkmr0_2?s=ce-de&ie=UTF8&qid=1518288149&sr=1-2-fkmr0&keywords=stm32f103+baord Ein großer (aber noch nicht der größte) aus der selben Serie: https://www.amazon.de/Waveshare-STM32F103-STM32F103VET6-Cortex-M3-Development/dp/B00KM6XNRE/ref=sr_1_8?s=ce-de&ie=UTF8&qid=1518288169&sr=1-8&keywords=stm32f103vet6 Bei Aliexpress gibt es diese Dinger noch billiger.
Hans schrieb: > Nennt sich dann Arduino und ist ja Böse Böse. Nein, das nennt sich vernünftige Hochsprache. Arduino ist teurer, sperriger und langsamer.
Stefan U. schrieb: > Hast du denn einen Programmieradapter und Debugger für den Xmega? > Wenn nicht, dann vergleiche mal die Kosten den Adapter kauft man einmal (momentan mal auf Microchip schauen, es gibt reichlich Rabatt für den Atmel-ICE). Ein vorhandener AVR ISP mk2 (ab 20€) langt auch erstmal zum Programmieren. Viel entscheidender ist doch der Aufwand zum Umstieg auf eine andere und keinesfalls einfachere MC-Plattform. Das macht man nur wenn es sein muß! Den Bastler interessiert dann auch nicht, daß ein Xmega etwas mehr kostet.
Die XMegas sind auch nur in den Apotheken so teuer. Bei richtigen Lieferanten bekommt man die auch recht günstig. Da der Markt aber gerade in den letzten Jahren stark fluktuiert, lohnt sich immer, vor einem Projektstart noch mal die Preise einzuholen.
Einfach neu kompilieren reicht bei der Portierung von Mega nach XMega aber nicht, auch dann nicht, wenn man in C programmiert. Da viele Peripherien komplett anders aufgebaut sind, wegen des DMA ganz andere Flags zum Einsatz kommen, die man bei Nichtverwendung des DMA mitunter händisch löschen muss, wird es ohne erneuten Einstieg in den Projektcode nicht funktionieren. Bestimmte Funktionen werden sicher ohne Modifkation einfach laufen, aber auch hier kann man aufgrund des anderen Kerns noch weiter optimieren, um beispielsweise Laufzeit zu sparen.
SPI schrieb: > Einfach neu kompilieren reicht bei der Portierung von Mega nach XMega > aber nicht, auch dann nicht, wenn man in C programmiert. Das hat auch niemand behauptet. Trotzdem ist es wesentlich einfacher und simpler, wenn man nur wenige Zeilen ändern muss - anstatt den ganzen Assembler überarbeiten zu müssen. Normalerweise kapselt man ja die Hardware Funktionen, z.B. in SPI_Send(..); odr InitHardware(); etc.
Danke für die Antworten. Mir erscheinen die XMegas nach wie vor sehr interessant und auch die Portierung sollte kein Hexenwerk sein (C++), allerdings ist es mir doch im Moment zu viel Aufwand. Die andere Alternative ist der AtMega324PB, der hat durch seine zusätzlichen Pins nicht das Problem, dass bestimmte HW-Features wegen Überlappung nicht nutzbar sind.
Randy B. schrieb: > allerdings ist es mir doch > im Moment zu viel Aufwand. Mach es! Es lohnt sich, du lernst portierbaren Code zu schreiben und du lernst das portieren selber.
Randy B. schrieb: > Die andere > Alternative ist der AtMega324PB, der hat durch seine zusätzlichen Pins > nicht das Problem, dass bestimmte HW-Features wegen Überlappung nicht > nutzbar sind Leider aber jenes schlecht erhältlich zu sein. Mehr ADU-Auflösung wie eingangs erwünscht ist auch nicht drin. Nils N. schrieb: > Es lohnt sich, du lernst portierbaren Code zu schreiben und du > lernst das portieren selber. Was und ob sich etwas lohnt hängt doch sehr vom Einzelfall ab. Meistens will man doch mit bestehenden Mitteln einfach nur ein größeres Projekt realisiert wissen. Portierbarer Code nutzt auch nicht neue Hardware-Funktionen, wie sie die XMegas mitbringen. Je portierbarer desto hardware-ferner, langsamer, unflexibler.
Robert schrieb: > Randy B. schrieb: >> Die andere >> Alternative ist der AtMega324PB, der hat durch seine zusätzlichen Pins >> nicht das Problem, dass bestimmte HW-Features wegen Überlappung nicht >> nutzbar sind > > Leider aber jenes schlecht erhältlich zu sein. Bei digikey zu bekommen. > Mehr ADU-Auflösung wie > eingangs erwünscht ist auch nicht drin. Das stimmt, wäre aber auch nur ein nice-to-have. > > Nils N. schrieb: >> Es lohnt sich, du lernst portierbaren Code zu schreiben und du >> lernst das portieren selber. Den habe ich ;-) Möchte ich aber neue Features benutzen (DMA, Events, CaptureChannels), dann muss ich auch die in meine HW-Abtraktionen einbauen, und das kostet dann doch mehr Arbeit, als ich momentan aufwenden möchte.
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.