Wenn ich mir die I/O Multiplexing Tabelle vom AVR32DD14 anschaue, habe ich das Gefühl, dass diese SOIC-14 Variante als Abfallprodukt entworfen wurde. Z.B.: TCA: WO0 WO1 WO2³ TCD: WOD³ WOC³ ADC: AIN4 AIN5 AIN6 AIN7 AIN29 AIN30 AIN31 AC: AINN2 AINP3 AINN3 AINP4 ³Alternate pin positions.
Georg M. schrieb: > habe ich das Gefühl Möchtest Du hier über Deine Gefühle diskutieren? Meins sagt mir das ist ein schönes Update zu Typen wie dem Tiny1614. Und ebenso wie dieser trotz SMD Größe sehr angenehm lötbar.
Hallo, solche Aussagen von Georg bringen nichts. Bspw. ganze CPU und GPU Serien bestehen aus "Downgrades" durch systematische Defekte während der Produktion. Sind die deshalb alle Minderwertig? Bezieht sich übrigens auf fast die gesamte Halbleiterproduktion. Also auch Mosfets usw. usw.. Solange die Specs eingehalten werden, und das müssen sie, ist doch alles gut. Den einzigen Nachteil dabei hat der Hersteller der ein nicht vollwertig funktionierenden "Chip" nicht zum vollen Preis verkaufen kann. Ganz entsorgen muss er ihn aber auch nicht. Vorteil für die Kunden mit mehr Auswahl. Also sind wir doch lieber froh das es so gemacht wird wie es gemacht wird.
Veit D. schrieb: > Bspw. ganze CPU und GPU Serien bestehen aus "Downgrades" durch > systematische Defekte während der Produktion. Mag bei diesen sein, bei Controllern eher nicht. Was allerdings ganz und gar üblich ist: nur einen Teil des Speichers im Controller zur Nutzung freizugeben und auf diese Weise die kleineren MCUs realisieren. Die können dann auch billiger verkauft werden – nicht nur, weil der Hersteller mit den größeren Exemplaren mehr Geld scheffeln will, sondern auch, weil die Kosten für die Inbetriebnahme und den Test des Flashs einen substanziellen Anteil an den Gesamtkosten ausmachen. Muss man also nur ein Viertel des eigentlich implementierten Flashs testen, wird der Chip deutlich billiger. Sollten sich später die kleineren Exemplare in hinreichend großen Stückzahlen verkaufen, kann man sich als Hersteller allemal noch überlegen, ob man den Aufwand für Design und Charakterisierung investiert, einen real kleineren Chip dafür zusammenzuschieben. Aus Sicht des Kunden bleibt sich das ja gleich. Ist aber nicht immer so: den ATtiny48 konnte man beispielsweise in einem kleineren QFN-Gehäuse anbieten als den ATtiny88, weil der Chip wirklich kleiner war. Allerdings sind diese "runter gestrickten" Varianten von ATmega48/88 ohnehin erst später aufgrund von Kundennachfrage geschaffen worden.
Hallo, ich kann mir nicht vorstellen das es bei µC gar nicht gemacht wird. Wäre ja schon etwas Wahnsinn wegen kleinen Defekten ganze "Chips" zu entsorgen. Aber egal, wir wissen was gemeint ist.
Veit D. schrieb: > ich kann mir nicht vorstellen das es bei µC gar nicht gemacht wird Wie ich schon schrieb: der Test des Flashs selbst ist ein so teurer Schritt, dass man bei den kleineren Devices lieber einfach weniger testet (und dann die Fuses entsprechend setzt). Bei Ausbeuten in der Größenordnung von 80 oder 90 % lohnt es nicht, den restlichen paar Prozent noch groß Aufwand hinterher zu werfen.
Hallo, naja Moment. Man kann ja nur von vorn herein weniger testen wenn man schon vorm Testen weiß das der Flash oder was weiß ich Defekte hat. Das ist eine andere Herangehensweise wie im Vergleich pauschal wegwerfen. Während der Produktion mit den vielen Tests zwischendurch fallen die Daten an ob, welche und wo Defekte sind. Das heißt der Tester weiß vorher schon was er testen muss und was nicht. Damit fallen keine zusätzlichen sinnlosen Tests an. So wird ein Schuh daraus. Außerdem denke ich wir reden hier über Details wo es sehr darauf ankommt wie man auf bestimmte Dinge schaut und was man sonst so darüber weiß. Man läuft Gefahr trotz Wissen darüber komplett aneinander vorbeizureden. Ein zwei Missverständnisse können zum sinnlosen Streit oder heftige Diskussionen führen. Das hatte ich schon bei älteren Threads zu solchen Themen bemerkt auch in anderen Foren. Da treffen sich Leute die sich in der Branche auskennen, jeder weiß was anderes, jeder hat hier und da den Überblick und trotzdem redet man erstmal lang und breit aneinander vorbei. Das will ich nicht das bringt nichts. Sowas kann man nur Offline besprechen.
Georg M. schrieb: > I/O Multiplexing [...] Abfallprodukt Magst du das mal eben erläutern? I/O Multiplexing heißt ausdrücklich nicht "Oh, der Pin ist zwar Schrott, aber da kann sich der Anwender ja was anderes drauf konfigurieren". Ja, es gab in der Vergangenheit Probleme mit dem Multiplexer, z.B. war eine alternative Beschaltung nicht komplett durch verdrahtet. Passiert. Aber grundsätzlich ist das kein Schrott.
Veit D. schrieb: > Während der Produktion mit den vielen Tests zwischendurch fallen die > Daten an ob, welche und wo Defekte sind. Bei Flash nicht. Der ist während der Produktion noch nicht groß auswertbar, weil er am Ende in einem wohl recht aufwändigen Verfahren "aufgeweckt" werden muss, bevor man überhaupt weiß, was darin geht.
Thomas schrieb: > Magst du das mal eben erläutern? Wenn der dritte PWM-Kanal nur als "alternate pin positions" verfügbar ist, dann entsteht der Verdacht, dass der Chip und das Gehäuse nicht zueinanderpassen, dass gar kein Chip (Die) speziell für die 14-Pin-Variante entworfen und produziert wird.
Georg M. schrieb: > dass gar kein Chip (Die) speziell für die 14-Pin-Variante entworfen und > produziert wird. Ja klar, glaubst du, die produzieren für jede Pinanzahl einen eigenen Chip? Das wäre viel zu teuer. Kuriosum sind in der Hinsicht die ATmega1280/1281. Da der ATmega1281 in der Linie von ATmega103 und ATmega128 liegt, hat er seine ISP-Pins nicht auf den SPI-Pins, sondern auf separaten PDI/PDO (gedoppelt mit den Pins von UART0). Bei den 100-Pin-Varianten dagegen wollte man die Standard-SPI-Pins benutzen. Dementsprechend hat die interne OTP-Fuse nicht nur die JTAGID zwischen beiden Varianten umgeschaltet, sondern auch das Routing für die Programmierpins. Beim ATmega128RFA1 (der den MCU-Core des ATmega1281 benutzt) mussten wir uns dann entscheiden, welche der Varianten wir nehmen wollen. Wir haben uns gegen die ATmega103-Kompatibilität entschieden :-), d.h. er wird normal über die SPI-Pins programmiert.
Georg M. schrieb: > speziell für die > 14-Pin-Variante müssen bei einem leistungsfähigeren Chip natürlicherweise die meisten Kompromisse bei der Belegung der begrenzten Pinanzahl gemacht werden. Wär Dir statt dessen ein minderwertigerer Chip lieber? P.S. Die DD Serie bietet übrigens erstmalig bis 64KB Flash-Speicher in einem winzigen SOIC-14 bei einem AVR.
:
Bearbeitet durch User
Hab mal welche bestellt. Mal gucken, ob sie mehr oder weniger Fehler als die DA/DB-Serie haben ;-)
Ein paar ergänzende Frage zur AVR DD Serie: 1. Welche Entwicklungsumgebung nutzt man hier am ehesten? Konkretes Szenario: Ich habe einen C-Sourcecode, besser einen Arduino code für den Atmega328 und möchte diesen auf den AVRxxDD14 portieren. Bis dato hatte ich VScode und platformio benutzt. Leider hinkt platformio beim Dx core etwas hinterher und mein gewünschtes Device AVR32DD14 wird (noch) nicht unterstützt wohl aber der AVR64DD14. Weiss jemand, ob ich den Device-Eintrag in der platformio.ini auch nutzen kann? Vorweg: ich würde auch den AVR64DD14 nutzen - den gibt es aber aktuell bei meinem Lieblings-Distri nicht - deshalb der AVR32DD14. Auf Arduino zurück will ich aber ungern wechseln. Eher kann ich mir ein Umstieg auf C-code ohne Arduino libs vorstellen. Nur welche IDE nutzen? Bleibt ja nur das Microchip/ Atmel Studio. Wie sieht es bei euch hier aus? Was nutzt ihr für die AVR Dx Serie? Danke für eure Rückmeldungen. @Moderator: Bitte ggf. den Beitrag verschieben: Z.B: hier Beitrag "neue AVR-µCs: Entwicklungsumgebung", Danke
:
Bearbeitet durch User
Heinz K. schrieb: > etwas hinterher und mein gewünschtes Device AVR32DD14 wird (noch) nicht > unterstützt wohl aber der AVR64DD14. Weiss jemand, ob ich den > Device-Eintrag in der platformio.ini auch nutzen kann? Die beiden dürften sich wirklich nur in den Speichergrößen unterscheiden, da solltest du problemlos einen Clone vom 64er für den 32er selbst zurecht feilen können. Habe bei einem früheren Brötchengeber auch mal platformio gemacht, die Beschreibungsdateien sind ja nun keine Raketenwissenschaft. > Was nutzt ihr für die AVR Dx Serie? Das, was ich sonst auch für alles andere benutze: Emacs, ist doch klar. :-) 'ne IDE sollte doch nun wirklich nicht an konkrete Devices gebunden sein. Wichtiger ist es halt, dass die Toolchain das Device unterstützt, die du benutzt.
Heinz K. schrieb: > Nur welche IDE nutzen? Jede, die du hinreichend konfiguriert bekommst. > Bleibt ja nur das Microchip/ Atmel Studio. Nein, eigentlich eher nicht. Denn MC will das Atmel-Erbe über kurz oder lang beerdigen. Wennschon eine (für dich) neue Welt, dann heißt sie: MPLAB-X. So Scheiße dieser Dreck auch ist. Aber wenn man nicht Atmel-Studio-Komfort-vorbelastet ist, ist er wohl sogar akzeptabel. Man weiß dann einfach nicht, wie schön und einfach die Sache sein könnte, wenn irgendwer mal darüber nachgedacht hätte, wie ein brauchbares GUI aussehen müsste...
Jörg W. schrieb: > > Das, was ich sonst auch für alles andere benutze: Emacs, ist doch klar. > :-) > 'ne IDE sollte doch nun wirklich nicht an konkrete Devices gebunden > sein. Wichtiger ist es halt, dass die Toolchain das Device unterstützt, > die du benutzt. Ja, genau. BTW: Wie du das mit Emacs gemacht hast, würde mich auch mal interessieren;-) Ansonsten versuche ich den Vorschlag von Ob S. -> MPLAB-X
Heinz K. schrieb: > Wie du das mit Emacs gemacht hast, würde mich auch mal interessieren;-) Was denn genau? Man schreibt den Code im Editor, für die Cross-Referenz gibt es Cscope, und mit ein paar Tasten kann man "make" oder den Debugger anwerfen. OK, für letzteres hätte ich für diese neueren AVRs noch keine Lösung, AVaRICE unterstützt die bislang nicht (und ich habe vermutlich auch nicht mehr den Enthusiasmus, das noch einzubauen).
Wichtig ist ja erst mal, dass deine Toolchain das Device unterstützt. GCC unterstützt AVRxxDD14 ab v13.3, AVR-LibC ab v2.2.1 https://gcc.gnu.org/gcc-13/changes.html#avr https://github.com/avrdudes/avr-libc/blob/16b742119eaed8d966929033b1ad325faea89798/NEWS#L1-L179 Für ältere Versionen gibt es Device-Packs wie beschrieben in https://gcc.gnu.org/wiki/avr-gcc#atpack Zu beachten ist dabei, dass specs-Files nicht zu 100% von der GCC-Version unabhängig sind. Atmochip unterstützt soweit ich weiß maximal GCC v7 in den Packs. Zudem liefern atpacks auch keine 100%igen Unterstützung weil Teile der AVR-LibC.h wie boot.h, power.h, wdt.h teils explicite #ifdef mcu enthalten. Unterstützung von FLMAP gibt's ab GCC v14, was aber nur für den AVR64 relevant ist; bei kleineren Flash-Größen passt ja der ganze ≤ 32 KiB Flash in den RAM-Adressraum. https://gcc.gnu.org/gcc-14/changes.html#avr Bei Flash ≤ 32 KiB wiederum, mach es einen Unterschied, ob man GCC ≤ v7 verwendet oder GCC ≥ v8: Bis v7: .rodata liegt im RAM, Devices gehören zu avrxmega2. Ab v8: .rodata liegt im Flash. Devices gehören zu avrxmega3. Man braucht also kein Gehampel wie pgm_read_xxx. https://gcc.gnu.org/gcc-8/changes.html#avr Unterstützung für Compact Vector Table wird es ab AVR-LibC v2.3 / GCC v15 geben; dürfte für so reichlich ausgestattete Devices aber kaum von Interesse sein. https://gcc.gnu.org/gcc-15/changes.html#avr
Jörg W. schrieb: > Da der ATmega1281 in > der Linie von ATmega103 und ATmega128 liegt, hat er seine ISP-Pins nicht > auf den SPI-Pins, sondern auf separaten PDI/PDO (gedoppelt mit den Pins > von UART0). Das betrifft auch die anderen AVRs im TQFP-64, z.B. AT90CAN32, 64, 128, ATmega2561. Ich finde das ganz praktisch, man kann dann über die ISP-Pins eine Debug-UART an den PC anschließen. Ich hab mir dafür auch einen Isolator mit HCPL2232 gebastelt und bis zu 3000V benutzt. Die M103C Fuse haben aber nur der ATmega64, ATmega128 und der ATmega128A.
:
Bearbeitet durch User
Jörg W. schrieb: > Ist aber nicht immer so: den ATtiny48 konnte man beispielsweise in einem > kleineren QFN-Gehäuse anbieten als den ATtiny88, weil der Chip wirklich > kleiner war. Auch die ATtiny25/45/58 gibt es in verschiedenen Gehäusen, d.h. die Chips sind unterschiedlich groß (ATtiny25-20SSN: S8S1, ATtiny45-20XU: 8X).
Heinz K. schrieb: > Auf Arduino zurück will ich aber ungern wechseln. Eher kann ich mir ein > Umstieg auf C-code ohne Arduino libs vorstellen. Nur welche IDE nutzen? > Bleibt ja nur das Microchip/ Atmel Studio. Wie sieht es bei euch hier > aus? Was nutzt ihr für die AVR Dx Serie? - Arduino IDE 2.x - Microchip Studio - ATmega 4809 - AVR DB - AVR EA
Veit D. schrieb: > Heinz K. schrieb: >> Auf Arduino zurück will ich aber ungern wechseln. Eher kann ich mir ein >> Umstieg auf C-code ohne Arduino libs vorstellen. Nur welche IDE nutzen? >> Bleibt ja nur das Microchip/ Atmel Studio. Wie sieht es bei euch hier >> aus? Was nutzt ihr für die AVR Dx Serie? > > - Arduino IDE 2.x > - Microchip Studio > - ATmega 4809 > - AVR DB > - AVR EA Die letzten 3 genannten sind andere AVR Controller keine IDE‘s. Oder wie ist das gemeint? Ich habe gerade geschaut und für meine Anwendung würde auch der Attiny3216 reichen. Nur da fängt das Chaos an. Irgendwie schafft es MC immer wieder keine einheitliche Produktfamilie aufzuziehen. Beispiel Taktfrequenz: Attiny 1 Series: 20Mhz für Vcc > 4,5V und 10Mhz für Vcc> 2,7V Avr Dx: 24Mhz Was soll die geringe Taktung bei 3.3V Betrieb in der heutigen Zeit? Die ganzen ARM Cores takten ab 48 MHz ohne Einschränkungen und verbrauchen auch nicht mehr Strom als die ganzen MC AVR Controller. Leider sind mir die STM Controller zu komplex, sonst wäre ich schon längst auf die umgestiegen.Programmierung ohne HAL ist möglich aber recht aufwändig. Deshalb fand ich die AVR DX Reihe eigentlich ganz gut. Leistungsfähig aber noch gut auf Registerebene beherrschbar. UPDI bei MC ist auch so eine Sache. Programmierung hierüber ist möglich mit einfachen Adaptern. Fürs Debugging muss man tief in die Tasche greifen . Bei ARM M Cores ist das alles seit Jahren standardisiert.
Johann L. schrieb: > Wichtig ist ja erst mal, dass deine Toolchain das Device unterstützt. Danke, Johann. Das war eine super Übersicht der Änderungen! Danke auch an alle anderen für die Infos. Ich denke ich komme jetzt etwas weiter.
Heinz K. schrieb: > Die ganzen ARM Cores takten ab 48 MHz ohne Einschränkungen Keineswegs "ohne Einschränkungen". Oft schafft der Flash das dann nur mit Waitstates, d.h. "ohne Einschränkungen" kannst du den vollen Takt nur nutzen, wenn du das Programm aus dem RAM arbeiten lässt (was ein AVR nicht kann). Den CPU-Core auf Geschwindigkeit zu bekommen, ist im Vergleich dazu das kleinere Problem.
Heinz K. schrieb: > Ich habe gerade geschaut und für meine Anwendung würde auch der > Attiny3216 reichen. Nur da fängt das Chaos an. Irgendwie schafft es MC > immer wieder keine einheitliche Produktfamilie aufzuziehen. Das nervt mich auch total, diese Inflation an ständig neuen Typen und Namensgebungen. Und dann sind es oft nur minimale Änderungen (Inkompatibilitäten), so daß es schwerfällt, einen geeigneten Typ zu finden. Bei den klassischen Tiny/Mega war alles noch aus einem Guß, nur der ATtiny861 fiel etwas aus dem Rahmen mit seinen Timern. Warum die Unterscheidung Tiny/Mega notwendig war, habe ich allerdings damals schon nicht verstanden. Der ATtiny48/88 hat 4 IO-Pins mehr als der ATmega48/88 und deshalb heißt er winzig? Da diese "netten Spielereien" der neuen Typen nicht wirklich einen Quantensprung für meine Anwendungen bringen, bleibe ich daher bei den klassischen Tiny/Mega. Da kenne ich alle Eigenheiten und habe schon erprobte Libs für alles. Ich brauche mich also nicht auf Bugs und sonstige Überraschungen einzulassen. Wenn ein Programm logisch läuft, dann läuft es auch real.
Peter D. schrieb: > Warum die Unterscheidung Tiny/Mega notwendig war, habe ich allerdings > damals schon nicht verstanden. Der CPU Core macht den Unterschied. Allerdings waren die ATmega8 und Nachfolger gar keine "richtigen Mega", was man beispielsweise am fehlenden JTAG sehen konnte. Der ATtiny48/88 wurde wohl dann für einen Großkunden extra von den Mega-Varianten abgespeckt, indem man den Multiplizierer rausgenommen hat und damit den Chip kleiner bekam.
Peter D. schrieb: > Das nervt mich auch total, diese Inflation an ständig neuen Typen und > Namensgebungen. Ja, da frage ich mich auch oft, was die BWLer(?) sich dabei gedacht haben (oder eben auch nicht)... Peter D. schrieb: > Da diese "netten Spielereien" der neuen Typen nicht wirklich einen > Quantensprung für meine Anwendungen bringen, Naja, sie haben m.E.n. schon drastische Vorteile: mehr u. deutlich komplexere/flexiblere Peripherie, wesentlich niedrigerer Preis bei größeren Speichern, fortgeschrittener Interrupt Controller, teils Betrieb bis zur maximalen Taktfrequenz bis herunter zu 1,8 V Vdd; um nur zu nennen, was mir gerade einfällt. Falls das alles für einen nicht relevant sein sollte, kann man natürlich auch bei den "alten" AVRs bleiben und spart sich den Umstiegsaufwand, es gibt ja auch einige Fallstricke bei den neuen (manuelles Löschen der Interrupt Flags z.B.). Ist nur die Frage, wie lange MC die alten noch produziert bzw. ob sie evtl. noch verteuert werden.
Johannes F. schrieb: > manuelles Löschen der Interrupt Flags z.B. Yup, darüber bin ich auch schon gestolpert …
Veit D. schrieb: > kann mir nicht vorstellen das es bei µC gar nicht gemacht wird. Die Strukturgrößen bei MCUs sind meist deutlich fetter und damit der Yield erheblich besser in einer längst abgeschriebenen Fab. Zudem sind die Dies viel kleiner. Auf einem Wafer liegen erheblich mehr MCUs als z.B. I7 CPUs. Also viel mehr MCUs bei viel besserer Ausbeute. Ist ein Unterschied ob ich 1% der Cent MCUs wegwerfe oder 30% der hochpreisigen CPUs.
Heinz K. schrieb: > Veit D. schrieb: >> Heinz K. schrieb: >>> Auf Arduino zurück will ich aber ungern wechseln. Eher kann ich mir ein >>> Umstieg auf C-code ohne Arduino libs vorstellen. Nur welche IDE nutzen? >>> Bleibt ja nur das Microchip/ Atmel Studio. Wie sieht es bei euch hier >>> aus? Was nutzt ihr für die AVR Dx Serie? >> >> - Arduino IDE 2.x >> - Microchip Studio >> - ATmega 4809 >> - AVR DB >> - AVR EA > > Die letzten 3 genannten sind andere AVR Controller keine IDE‘s. Oder wie > ist das gemeint? Du hast nach Controller und IDE gefragt, die man so verwendet. > Ich habe gerade geschaut und für meine Anwendung würde auch der > Attiny3216 reichen. Nur da fängt das Chaos an. Irgendwie schafft es MC > immer wieder keine einheitliche Produktfamilie aufzuziehen. Beispiel What? Es gibt eine ATtiny 0 Serie, 1 Serie und 2 Serie. Erkennbar an der vorletzten Ziffer. Bsp. 0er Serie: ATtiny406, 806 und 1616 Bsp. 1er Serie: ATtiny416, 1617 und 3217 Bsp. 2er Serie: ATtiny427, 1627 und 3227 Die 2er Serie ist die Neue die den neuen AVRs ähnlich ist. Bsp. 3227, kann man mit 3V mit 16MHz betreiben. Wenn der Eingangstakt (intern/extern) höher ist, muss man ihn runterteilen, man gewinnt also nichts. Manual Table 33-12. Gilt für 25°C. Eigentlich sind es mit 3V nur 10MHz im größeren Temperaturbereich.
Veit D. schrieb: > ATtiny 0 Serie, 1 Serie und 2 Serie Ja, die (neuen) ATtinys sind schon ziemlich systematisch benannt. Die letzte Ziffer kennzeichnet die Pin-Anzahl, die vorletzte die Serie und die ersten ein oder zwei die Flashgröße. Wobei die Unterschiede zwischen den Serien sich IMHO hauptsächlich in den verschiedenen Peripherieeinheiten widerspiegeln: Serie 0 ist da sehr abgespeckt (Low-Cost-Serie), Serie 1 hat z.B. einen 8-bit-DAC und 10-bit-ADC, Serie 2 keinen DAC, dafür aber einen 12-bit-ADC u.a.
Hatte mich einmal vertippt. Bsp. 0er Serie: ATtiny406, 806 und 1606
Veit D. schrieb: > Heinz K. schrieb: >> Veit D. schrieb: >>> Heinz K. schrieb: >> Ich habe gerade geschaut und für meine Anwendung würde auch der >> Attiny3216 reichen. Nur da fängt das Chaos an. Irgendwie schafft es MC >> immer wieder keine einheitliche Produktfamilie aufzuziehen. Beispiel > > What? > Es gibt eine ATtiny 0 Serie, 1 Serie und 2 Serie. > Erkennbar an der vorletzten Ziffer. Ja, da hast Du recht. Es gibt da auch eine tolle Übersicht auf technology.com. Ich meinte auch eher über die einzelnen Familien hinweg also z. B. Attiny 0/ 1/ 2 Series vs AVR Dx. > 10MHz im größeren Temperaturbereich. Genau das meine ich nur 10Mhz garantiert bei 3V. Andere Controller gehen da locker bis 48mhz oder höher (STM32, SAMD). Das Thema Waitstates bei Stm32 ist mir bekannt. Trotzdem sind die deutlich schneller. Wenn jetzt die Frage aufkommt warum mir 10MHz zu knapp erscheinen. Da gibt es mehrere Anwendungsfälle. Z.b Grafik-Display- Ansteuerung, Signalverarbeitung etc. Ich stehe übrigens nicht auf dem Standpunkt bei den alten AVRs zu bleiben. Die Entwicklung geht halt weiter.
Ich will auch nicht nur über die AVRs meckern. Gut ist z.B. dass diese immer noch echten EEPROM beinhalten. Bei STM32 geht das nur mit Emulation im Flash. Da ich gerade auch EEPROM zur Config-Speicherung nutze ist das ein klarer Vorteil. Auch das Multivoltage I/O Feature der AVR Dx Serie finde ich Klasse. Ebenso Klasse ist der Portmultiplexer den Atmel/ MC bereits in den SAMD Devices seit vielen Jahren erfolgreich eingesetzt hat.
Heinz K. schrieb: > Genau das meine ich nur 10Mhz garantiert bei 3V. Andere Controller gehen > da locker bis 48mhz oder höher (STM32, SAMD). Dafür haben AVR eben einen größeren Versorgungsspannungsbereich bis 5,5 V. Man kann eben nicht alles haben. Ohne es genau zu wissen, vermute ich mal stark, dass maximale Taktfrequenz und Vcc-Bereichsgröße konkurrierende Parameter sind. Heinz K. schrieb: > Wenn jetzt > die Frage aufkommt warum mir 10MHz zu knapp erscheinen. Da gibt es > mehrere Anwendungsfälle. Z.b Grafik-Display- Ansteuerung, > Signalverarbeitung etc. Das sind auch Anwendungsfälle, für die AVRs (meiner bescheidenen Einschätzung nach) einfach nicht konzipiert sind bzw. für die es besser geeignete Alternativen gibt. AVRs (u.a. 8-bit-MCUs wie PIC12/16/18) sind eher was für Steuerungsaufgaben, bei denen es mehr auf analoge Peripherie wie MVIO oder 5-V-Betrieb (der bessere Störimmunität als 3,3V bietet) ankommt als auf Rechenleistung. Wenn dagegen schnell gerechnet werden soll, bieten sich heute 32-bit-MCUs wie ARM Cortex M an, à la STM32 oder RP2040, allein schon wegen Registerbreite und Befehlssatz.
Heinz K. schrieb: > Was soll die geringe Taktung bei 3.3V Betrieb in der heutigen Zeit? Kosten, Kosten, Kosten. Die Tinys sind halt die Billich-Linie. Früher(tm) bekamen sie einen abgespeckten Core und abgespeckte Timer, heute wird halt z.B. die eingebaute Ladungspumpe eingespart, die es bei den Dx gibt. Wer den hohen Takt auch bei geringer Spannung braucht, nimmt halt einen Dx und gut isses. Wird ja schließlich niemand dazu gezwungen, einen Tiny zu verbauen.
Hallo, warum soll ein ATtiny ein Grafikdisplay nicht ansteuern können? Abgesehen vom Speicher. Ansonsten stellt sich die Frage, warum man dann an einem ATtiny festhält. Oder was man unter einem Grafikdisplay versteht. Das ist ein breites Feld. s/w, farbig, grafisch programmierbar usw. Alternativ zum ATtiny ein AVR128DB, brauchst sowieso viel Speicher für das Display. Der kann ab 1,8V mit 24MHz takten. Steht zwar nicht im Klartext im Manual, aber es gibt keine Einschränkung, deswegen kann er das. Nur wenn die PLL genutzt wird werden 3V notwendig. Oder nimmst ein "ESP32 mit Display" bzw. "Display mit ESP32". ;-) Haste sogar noch WiFi und Touchscreen frei Haus. Du musst dir erstmal ein Konzept erstellen welche Hardware du wirklich brauchst. Du hast viel zu viele Unbekannte im Spiel.
Veit D. schrieb: > warum soll ein ATtiny ein Grafikdisplay nicht ansteuern können? Weil das sehr rechenintensiv sein kann, man denke an Animationen, komplexe geometrische Objekte etc., da kommt anspruchsvolle Mathematik ins Spiel. Dafür werden AVRs ab einem gewissen Niveau einfach zu „langsam“, wenn es auf flüssige „Bewegungen“ und Reaktionszeit etc. ankommt.
:
Bearbeitet durch User
Johannes F. schrieb: > Weil das sehr rechenintensiv sein kann, man denke an Animationen, > komplexe geometrische Objekte etc., da kommt anspruchsvolle Mathematik > ins Spiel. Dafür werden AVRs ab einem gewissen Niveau einfach zu > „langsam“, wenn es auf flüssige „Bewegungen“ und Reaktionszeit etc. > ankommt. Schau dir einfach mal die Demos aus der Zeit der 8Bit-Homecomputer an. Da kannst du teilweise recht aufwendige Grafik sehen. Und deren µP waren meist mit weniger als 2MHz angetrieben und hatten einen wesentlich ineffizienteren Befehlssatz als die AVR8. Das Problem ist einfach nur die Universalität. Diese Demos enthielten meist sehr viel vorberechneten Kram. Und der Speicher, die großen Grafik-Demos haben immer wieder Daten und Code nachgeladen. Aber: Grafikdisplay bedeutet ja nicht zwingend, dass da drauf unbedingt aufwendige Animationen laufen müssen. Text und einfache GUI-Elemente genügen ja für die meisten Anwendungsfälle auch. Und das ist mit AVRs definitiv in absolut akzeptabler Geschwindigkeit möglich. Jedenfalls für Leute, die wirklich programmieren können...
Ob S. schrieb: > Diese Demos enthielten > meist sehr viel vorberechneten Kram. Eben ... Ob S. schrieb: > Grafikdisplay bedeutet ja nicht zwingend, dass da drauf unbedingt > aufwendige Animationen laufen müssen. Nicht zwingend, aber falls doch, dann gibt es dafür halt geeignetere MCUs als AVR; mit einem Vielfachen jeweils an RAM, Registerbreite, F_CPU, für ähnlich wenig Geld. Ob S. schrieb: > Jedenfalls für > Leute, die wirklich programmieren können... Keine Frage, es ist natürlich eine interessante Herausforderung bzw. Lernübung, LCD-Grafik auf AVR zu implementieren; vorzugsweise natürlich dann in Assembler, um das Maximum an Effizienz herauskitzeln zu können. Gibt ein gutes Buch dazu von Manfred Schwabl-Schmidt.
Heinz K. schrieb: > Das Thema Waitstates bei Stm32 ist mir bekannt. Trotzdem sind die > deutlich schneller. Sicher ist ein ARM-Core bereits an sich in manchen Dingen schneller, beispielsweise weil er einen barrel shifter hat. Aber generell: beim AVR würde es dir nichts nützen, wenn der Core schneller rattern kann, als es der Flash hergibt. Er hat keinen Cache und kann keinen Code aus dem RAM ausführen. Damit bist du an die Geschwindigkeit des Flashs gebunden. Bei ARM sieht das eben anders aus, herstellerübergreifend. Erstens kann man dort immer auch Code aus dem RAM ausführen, der läuft dann immer full speed. RAM ist zwar teurer, aber man kann ja beispielsweise schnelle ISRs da reinlegen. Außerdem haben die allermeisten ARMs noch Cache, damit ist man zumindest in einem begrenzten Bereich (kleine Schleife oder sowas) wieder auf full speed. Kommt noch dazu, dass üblicherweise der Flash bei Cortex-M auch noch breiter ist als die Befehlsbreite, sodass man sehr oft mit einem Lesezyklus zwei Befehle liest. Geht beim AVR auch nicht. (Und lös dich mal von "STM32" – die allermeisten dieser Aussagen treffen herstellerunabhängig für jeden Cortex-M zu.)
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.