Microchip hat ja ganz schnell nen Haufen neuer Typen rausgebracht. Z.B. bei den 8kB 14-Pinnern gibt es allein schon 5 Varianten: - ATtiny84 - ATtiny841 - ATtiny804 - ATtiny814 - ATtiny824 Warum diese Vielfalt, die sehen sich doch alle sehr ähnlich? Hat mal jemand eine Übersicht gefunden, worin die sich überhaupt unterscheiden. Für neue Projekte solte man wohl nur noch den 824 einsetzen.
:
Gesperrt durch Moderator
Peter D. schrieb: > Warum diese Vielfalt, die sehen sich doch alle sehr ähnlich? Wenn dir das nicht klar ist, wie kommst du dann zu diesem Schluss? > Für neue Projekte sollte man wohl nur noch den 824 einsetzen. Das kommt mir ein bisschen übereilt vor.
Peter D. schrieb: > Warum diese Vielfalt, die sehen sich doch alle sehr ähnlich? Man versucht sich so gegen die billigen kundenspezifischen µC aus China zu behaupten.
Peter D. schrieb: > Warum diese Vielfalt, die sehen sich doch alle sehr ähnlich? Ich glaaaube, das ist ein bisschen Firmenphilosophie von Microchip. In Atmel AVRs war früher immer so ziemlich alles an Peripherie drin, was geht. bei PIC gab es immer schon sehr spezielle Typen und Baureihen, die nur genau das an Bord hatten, was man braucht. Und das scheint so langsam auch Richtung AVR zu schwappen. Ist aber nicht unbedingt ein falscher Ansatz, denke ich.
Ich glaube die Testen halt die Chips und schneiden Features weg wenn da etwas nicht ok ist. Wenn man dafür dann schnell einen Namen findet, kann man die auch Verkaufen. Zum Beispiel 10 Timer, hat aber nur 8 geklappt? Na kein Problem, das ding heist dan nich 12310, sondern 1238 :) Zu viel RAM Kaputt am Wafer? Dann abschneiden und verkaufen.
Andras H. schrieb: > Ich glaube die Testen halt die Chips und schneiden Features weg wenn da > etwas nicht ok ist. Nee, bei so kleinen Chips ist das ausgesprochen unwahrscheinlich.
Peter D. schrieb: > Hat mal jemand eine Übersicht gefunden, worin die sich überhaupt > unterscheiden. https://www.microchip.com/content/mchp/en-us/parametric-search.html/716 "Chart View Mode" umstellen All Specifications <- Summary
Ich finde, als Kunde ist man da verunsichert, auf welchen man denn nun setzen soll, damit der nicht gleich wieder abgekündigt wird. Auch sind die neueren Typen oftmals günstiger (Reichelt 84: 1,50€, 814: 0,95€). Ich habe den Eindruck, daß die Entscheider bei Microchip selber nicht richtig wissen, was sie denn nun eigentlich entwickeln wollen. Z.B. der 841 hatte 2 UARTs, die 804, 814 nur noch eine und der 824 dann wieder 2.
Peter D. schrieb: > Ich finde, als Kunde ist man da verunsichert, Bist du für Microchip ein relevanter Kunde?
Andras H. schrieb: > Ich glaube die Testen halt die Chips und schneiden Features weg wenn da > etwas nicht ok ist. Du hast schlicht keine Ahnung von Halbleiterei. Sorry, solche Spekulationen sind wirklich Unfug. Wenn was nicht funktioniert, muss das Product Engineering gucken, was die Ursache des Fehlers ist. Das wird nicht verkauft, denn es könnte ganz schnell eine Zeitbombe werden, die beim Kunden explodiert. Was in der Tat passiert ist, dass Devices mit weniger Flash auch nur weniger Flash auf dem Tester in Betrieb nehmen und Testen – das kostet nämlich vergleichsweise viel Zeit und damit Geld, d.h. ein Chip, bei dem nur ein Viertel des implementierten Flashs getestet werden muss ist in der Tat billiger als der gleiche Chip, bei dem der komplette Flash in Betrieb genommen und getestet worden ist. Natürlich wird dann der nicht getestete Flash (und RAM) auch mit OTP-Fuses tatsächlich abgeklemmt. Bei simplen Peripherals kann ich mir das nicht als Kostenargument vorstellen. Was natürlich (wie auch bei den verkleinerten Flash-Varianten) immer noch als Marketing-Ziel dahinter sein kann: man geht mit einem einzigen Chip (und dessen nicht unerheblichem Entwicklungsaufwand) ins Rennen, bietet aber "abgerüstete" Varianten an, bei denen ebenfalls per OTP-Fuse ein Teil der (bspw. in der Chipfläche aufwändigen) Peripherals deaktiviert werden. Diese werden aus marketingstrategischen Gründen natürlich preiswerter verkauft als die anderen. Sollte dann wirklich mal ein Kunde aufschlagen, der so eine kleinere Variante in 100-Millionen-Stückzahlen haben möchte, kann man nachträglich den Aufwand investieren, tatsächlich noch einen verkleinerten (und damit billigeren) Chip zu bauen und später diesen stattdessen ausliefern.
Jörg W. schrieb: > Du hast schlicht keine Ahnung von Halbleiterei. Sorry, solche > Spekulationen sind wirklich Unfug. Nun, bei flächenmäßig sehr großen Chips wird das wohl schon gemacht, da werden CPUs bei Defekten mit reduzierter Kernanzahl ausgeliefert, oder Speicherbausteine mit reduzierter Kapazität. IBM verwendete halbe 256-kBit-DRAMs für die Bestückung von Teilen des Arbeitsspeichers des AT, die hatten dann die sonst unlogische Kapazität von 128 kBit. Bei Flash-Speichern für USB-Sticks etc. werden defekte Blöcke im Defektmanagement vermerkt, der Chip aber deswegen nicht weggeworfen. Aber, bei so winzigen Krümeln wie µCs wird so etwas definitiv nicht gemacht, da ist die Chipfläche in Relation zur Waferfläche viel zu klein, als daß sich das lohnen würde.
Harald K. schrieb: > IBM verwendete halbe 256-kBit-DRAMs für die Bestückung von Teilen des > Arbeitsspeichers des AT, die hatten dann die sonst unlogische Kapazität > von 128 kBit. Das ist aber ein halbes Jahrhundert her. Heutige Prozessausbeuten liegen um Welten höher als die damaligen. > Bei Flash-Speichern für USB-Sticks etc. werden defekte Blöcke im > Defektmanagement vermerkt, der Chip aber deswegen nicht weggeworfen. Bei NAND-Flash ist das sicher was anderes, da lebt man (wie bei Festplatten) sowieso damit, dass ein bestimmter Anteil nicht funktioniert, und blendet ihn aus. Dafür ist er halt viel billiger als NOR-Flash.
Jörg W. schrieb: > Natürlich wird dann der nicht > getestete Flash (und RAM) auch mit OTP-Fuses tatsächlich abgeklemmt. Doch doch.... Kann mir das schon vorstellen.... Die Chips werden ja wohl hoffentlich einzeln getestet. Und die "OTP-Fuses" werden ja sowieso gesetzt, wie auch der individuelle OSCCAL Wert, die Signatur. So ließe sich der Ausschuß bei Speicherfehlern ca. halbieren. Ich gehe auch davon aus, dass z.B. die Tiny Reihe von t25 über t45 bis t85 alle mit dem identischen Maskensatz gefertigt werden.
Arduino F. schrieb: > Kann mir das schon vorstellen. Ist aber definitiv falsch. Es gibt zwar OTP-Fuses für die Varianten, aber nicht in der Form "obere Hälfte OK" und "untere Hälfte OK". Wie geschrieben, die eigentliche Kostenersparnis entsteht, indem man eine Hälfte (oder drei Viertel) des Flashs gar nicht erst in Betrieb nehmen und testen muss. Flash-Inbetriebnahme ist (zeit)aufwändig und verursacht einen nicht unerheblichen Teil der gesamten Bauteilkosten einer Flash-MCU. Naja, und ob dann irgendwann tatsächlich ein individueller Chip für eine kleinere Variante gefertigt worden ist, kannst du höchstens anhand von Röntgenaufnahmen der ICs aus verschiedenen Jahren feststellen.
Beitrag #7453255 wurde von einem Moderator gelöscht.
Peter D. schrieb: > ...die sehen sich doch alle sehr ähnlich? Ja, wegen SOIC-14. Peter D. schrieb: > Hat mal jemand eine Übersicht gefunden, worin die sich überhaupt > unterscheiden. ATtiny814: TCD DAC (8-bit) ATtiny824: 12-bit differential ADC with Gain Amplifier: 2x, 4x, 8x, 16x
Peter D. schrieb: > Hat mal jemand eine Übersicht gefunden, worin die sich überhaupt > unterscheiden. Hallo, von den aktuellen Controllern hätte ich diese Übersicht anzubieten. Ansonsten gibt es hier ganz unten mit den letzten 3 Downloads Übersichtstabellen was wovon wieviel drin ist. https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/8-bit-mcus
1 | 8 Pin | 14 Pin | 20 Pin | 24 Pin |
2 | ___________|____________|____________|_____________ |
3 | ATtiny202 | ATtiny204 | | |
4 | ATtiny402 | ATtiny404 | ATtiny406 | |
5 | | ATtiny804 | ATtiny806 | ATtiny807 |
6 | | ATtiny1604 | ATtiny1606 | ATtiny1607 |
7 | ___________|____________|____________|_____________ |
8 | ATtiny212 | ATtiny214 | | |
9 | ATtiny412 | ATtiny414 | ATtiny416 | ATtiny417 |
10 | | ATtiny814 | ATtiny816 | ATtiny817 |
11 | | ATtiny1614 | ATtiny1616 | ATtiny1617 |
12 | | | ATtiny3216 | ATtiny3217 |
13 | ___________|____________|____________|_____________ |
14 | | ATtiny424 | ATtiny426 | ATtiny427 |
15 | | ATtiny824 | ATtiny826 | ATtiny827 |
16 | | ATtiny1624 | ATtiny1626 | ATtiny1627 |
17 | | ATtiny3224 | ATtiny3226 | ATtiny3227 |
18 | |
19 | |
20 | 28/32 Pin | 48 Pin |
21 | ___________|____________ |
22 | ATmega808 | ATmega809 |
23 | ATmega1608 | ATmega1609 |
24 | ATmega3208 | ATmega3209 |
25 | ATmega4808 | ATmega4809 (ATmega4809 auch in 40 Pin DIP) |
26 | |
27 | |
28 | 28 Pin | 32 Pin | 48 Pin | 64 Pin |
29 | ___________|____________|____________|_____________ |
30 | AVR32DA28 | AVR32DA32 | AVR32DA48 | |
31 | AVR64DA28 | AVR64DA32 | AVR64DA48 | AVR64DA64 |
32 | AVR128DA28 | AVR128DA32 | AVR128DA48 | AVR128DA64 |
33 | ___________|____________|____________|_____________ |
34 | AVR32DB28 | AVR32DB32 | AVR32DB48 | |
35 | AVR64DB28 | AVR64DB32 | AVR64DB48 | AVR64DB64 |
36 | AVR128DB28 | AVR128DB32 | AVR128DB48 | AVR128DB64 |
37 | |
38 | |
39 | 14 Pin | 20 Pin | 28 Pin | 32Pin |
40 | ___________|____________|____________|_____________ |
41 | AVR16DD14 | AVR16DD20 | AVR16DD28 | AVR16DD32 |
42 | AVR32DD14 | AVR32DD20 | AVR32DD28 | AVR32DD32 |
43 | AVR64DD14 | AVR64DD20 | AVR64DD28 | AVR64DD32 |
44 | |
45 | |
46 | 28 Pin | 32 Pin | 48 Pin | |
47 | ___________|____________|____________| |
48 | AVR64EA28 | AVR64EA32 | AVR64EA48 | |
Arduino F. schrieb: > Kann mir das schon vorstellen.... Ich stell mir auch manchmal vor, dass es Gras regnet. Trotzdem muss ich es kaufen. Veit: features, nicht pins.
Hallo, ja ich weiß, zur groben Einsortierung. ;-) Die Features findet man im Link ganz unten.
:
Bearbeitet durch User
Beitrag #7453457 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > Du hast schlicht keine Ahnung von Halbleiterei. Sorry, solche > Spekulationen sind wirklich Unfug. > > Wenn was nicht funktioniert, muss das Product Engineering gucken, was > die Ursache des Fehlers ist. Das wird nicht verkauft, denn es könnte > ganz schnell eine Zeitbombe werden, die beim Kunden explodiert. > > Was in der Tat passiert ist, dass Devices mit weniger Flash auch nur > weniger Flash auf dem Tester in Betrieb nehmen und Testen – das kostet > nämlich vergleichsweise viel Zeit und damit Geld, d.h. ein Chip, bei dem > nur ein Viertel des implementierten Flashs getestet werden muss ist in > der Tat billiger als der gleiche Chip, bei dem der komplette Flash in > Betrieb genommen und getestet worden ist. In der Tat ist es schwierig den Testumfang zu reduzieren. Digitale Logik wird mittels Scan-Chains getestet. Sprich alle Flops im Design sind wie ein Schieberegister zusätzlich alle in einer Kette verdrahtet. Durch diese Kette können dann Die flops entsprechend vorgeladen werden und arbiträre Werte durch die Logik dazwischen getaktet werden. Diese Scan-Chain insertion macht das Synthesetool. Weitres Tooling generiert aus dieser Netzliste dann ein Pattern, dass man durchtesten muss, um die notwendige Abdeckung zu erreichen. Das macht man in der Regel nur einmal und testet so das Ganze Flip-Flop-Grab in ein paar Millisekunden durch. Bei vielen RAMs sitzt dann tatsächlich ein MBIST (memory built-in self test) Controller mit auf dem Chip, der das RAM durchnudelt. Statistisch, durch die große Fläche bedingt, haben Speicherelemente durchaus mal einen defekt. Standardmäßig macht man das dann bspw. so, dass ein RAM aus 1024 mal 32 bit Worten (also 1024 Zeilen, 32 Spalten) 2 extra Spalten bekommt. Sollte nun irgendwo ein bit kaputt sein, wird die betroffene Spalte durch eine Redundanzspalte ersetzt. Das wird dann beim Test so eingefused. Sobald daber 3 fehler in 3 unterschiedlichen Spalten vorliegen ist es dann vorbei. Je nachdem, wie das getestet wird, wird tatsächlich immer der komplette Speicher getestet. Jörg W. schrieb: > Natürlich wird dann der nicht > getestete Flash (und RAM) auch mit OTP-Fuses tatsächlich abgeklemmt. Das ist in der Tat tatsächlich eher unüblich. Bspw. Die STM32Fxxx Serien haben immer den vollen RAM und FLASH Ausbau. Und den kann man auch nutzen. Muss man teilweise auch, weil zumindest früher sämtliche Linkerskripte von ST falsch waren und diese RAM-Lücke, die da offiziell drin ist, voll verwendet haben. Siehe: Beitrag "SRAM Lücke STM32Fxxx, Linkerskripte falsch" Es ist einfach einfacher reinzuschreiben, dass man den nicht nutzen darf, als das rauszufusen.
M. H. schrieb: >> Natürlich wird dann der nicht >> getestete Flash (und RAM) auch mit OTP-Fuses tatsächlich abgeklemmt. > > Das ist in der Tat tatsächlich eher unüblich. Hat Atmel zumindest so gemacht, und es würde mich wundern, wenn Microchip das nicht übernommen hätte. ;-) Bezüglich RAM-Test magst du Recht haben, davon hatte ich nichts gehört. Das mit dem großen Aufwand bezieht sich auf den Flash, und da wurde mir erklärt, dass eine Reduktion der in Betrieb zu nehmenden Flash-Größe tatsächlich einen geldwerten Vorteil bedeutet. Ich erinnere mich, dass 128 KiB Flash in Betrieb zu nehmen und zu testen irgendwas um die 10 Sekunden gekostet hat damals. Da kann man sich dann ausmalen, wie lange alle MCUs eines 300-mm-Wafer so brauchen, bis sie durch sind.
Jörg W. schrieb: > Bezüglich RAM-Test magst du Recht haben, davon hatte ich nichts gehört. > Das mit dem großen Aufwand bezieht sich auf den Flash, und da wurde mir > erklärt, dass eine Reduktion der in Betrieb zu nehmenden Flash-Größe > tatsächlich einen geldwerten Vorteil bedeutet. Ich erinnere mich, dass > 128 KiB Flash in Betrieb zu nehmen und zu testen irgendwas um die 10 > Sekunden gekostet hat damals. Da kann man sich dann ausmalen, wie lange > alle MCUs eines 300-mm-Wafer so brauchen, bis sie durch sind. Ja. Flash dauert. Der muss zumindest einmal programmiert werden. Auf Wafer-ebene hat man manchmal noch das Glück, dass man mittels UV was löschen kann. Ist aber auch nicht immer gegeben. Meistens haben die NVMs irgendwelche Metalllagen drüber, damit die eben nicht so anfällig sind. Der Hersteller kann zumindest Flash-Zellen nicht nur bool'sch bewerten. In der Regel gibt es da irgendwelche Margin-Tests, bei denen die Ausleseströme und die bitline Amplifier verstellt werden. Und damit kann man tatsächlich Rückschlüsse auf die Restladung und damit auf den Zustand des NVMs machen. Ein Weg hier ist bspw, auf Waferebene schon Firmware oder ein Testpattern zu flashen und dann beim Endmessen, wenn alles verpackt ist (garantiert einige Zeit später), zu schauen, wie gut das Image noch ist.
Jörg W. schrieb: > Das mit dem großen Aufwand bezieht sich auf den Flash, und da wurde mir > erklärt, dass eine Reduktion der in Betrieb zu nehmenden Flash-Größe > tatsächlich einen geldwerten Vorteil bedeutet. So ist es. Aber ungetestet bedeutet halt nicht bei allen Herstellern deaktiviert. Oft ist es das Programmiertool, welches aufpasst, dass der offiziell nicht vorhandene FlashROM nicht doch beschrieben wird. Patcht man das Flashprogramm, ist der volle Speicher verfügbar (auf eigenes Risiko, da vom Hersteller ungetestet). Bei aufwendiger Peripherie wie z.B. CAN, Flexray, Ethernet, lohnt es sich ebenfalls, diese auf dem Wafertest auszusparen. Bei unseren Lieferanten macht das ungefähr 1 % des Endpreises aus. Die Hälfte des Flashs ungetestet lassen spart 10 %.
M. H. schrieb: > Das ist in der Tat tatsächlich eher unüblich. Bspw. Die STM32Fxxx Serien > haben immer den vollen RAM und FLASH Ausbau. Bei den AVRs geht das nicht, da kann man mit dem RJMP Befehl um +/-4kB springen und das wird auch ausgenutzt. Man kann damit also von Flashend in die unteren 4kB springen. Dazu muß aber das Rollover nach 0x0000 an der vorgegebenen Flashgröße erfolgen. Auch die Interruptvektortabelle ist von der Flashgröße abhängig. Die AVRs mit kleinerem Flash unterstützen auch nicht die weiteren Sprungbefehle (JMP, EJMP).
Soul E. schrieb: > Aber ungetestet bedeutet halt nicht bei allen Herstellern deaktiviert. Dann haben sie aber zumindest noch den Aufwand des "flash wakeup" gehabt. Der war/ist bei Atmel in den normalen Flash-Test integriert und wurde bei den kleineren Versionen meines Wissens auch weggelassen. Peter D. schrieb: > Bei den AVRs geht das nicht, da kann man mit dem RJMP Befehl um +/-4kB > springen und das wird auch ausgenutzt. Die entsprechende OTP-Fuse kann ja alles mögliche in der Digitallogik umstellen. so kann sie auch zwischen 24- und 16-Bit-PC umschalten (wenn ein Controller von 256 auf 128 KiB herunter gefuset wird), bis hin zu so Kuriositäten wie der aus historischen Gründen nicht auf den SPI-Pins liegenden ISP-Schnittstelle beim ATmega1281, während sie beim ATmega1280 (gleicher Chip, nur weniger Pins gebondet) auf SPI liegt.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Dann haben sie aber zumindest noch den Aufwand des "flash wakeup" > gehabt. Was ist das?
Stefan F. schrieb: > Jörg W. schrieb: >> Dann haben sie aber zumindest noch den Aufwand des "flash wakeup" >> gehabt. > > Was ist das? Der Flash braucht eine Reihe von Aktionen nach der eigentlichen Fertigung, damit er überhaupt benutzt werden kann. Im Detail kann ich dir die Schritte allerdings auch nicht sagen, wurde mir damals nur so erklärt. Wenn du mal nach "flash memory wakeup" gugelst, findest du zumindest Beiträge bei IEEE und Patente, die sich mit dem Thema befassen (und insbesondere damit, die dafür benötigte Zeit zu reduzieren).
Jörg W. schrieb: > Wenn du mal nach "flash memory wakeup" > gugelst, findest du zumindest Beiträge bei IEEE und Patente, die sich > mit dem Thema befassen Ich habe vieles gefunden, aber nichts was in dem Zusammenhang Sinn ergibt. Deswegen meine Nachfrage. Danke für die Erklärung.
Peter D. schrieb: > Warum diese Vielfalt, die sehen sich doch alle sehr ähnlich? > Hat mal jemand eine Übersicht gefunden, worin die sich überhaupt > unterscheiden. > Für neue Projekte solte man wohl nur noch den 824 einsetzen. Für mich als Hobbyisten ist solche Vielfalt auch überflüssig. Was ist für mich bei AVR am wichtigsten: Flash-Programmspeicher (ich kenne noch 80C31! ), vernünftiger Compiler. Und Peripherie kann man immer extern ergänzen, nur Basis ist wichtig: USART, SPI... Deshalb mache ich fast alles mit einem einzigen Typ: ATMEGA1284P. Das macht auch meine Heim-Logistik einfacher.
:
Bearbeitet durch User
Maxim B. schrieb: > Für mich als Hobbyisten ist solche Vielfalt auch überflüssig. Alls Hobbyist brauchtst Du nicht auf das Geld schauen, da kannst Du einfach das Umbrella Device kaufen. Also den Baustein, wo alle auf dem Chip befindlichen Funktionen auch aktiviert sind. Wenn man 50 Millionen Stück im Jahr verbaut, dann sieht es anders aus. Da sind 0,7ct Einsparung für das Weglassen des zweiten LIN (bzw dessen Wafertest) bares Geld. Bzw für den Chiphersteller entscheidet diese Preisdifferenz, ob man den Auftrag bekommt oder nicht. Dafür legt der gerne ein paar Sachnummern mehr an.
M. H. schrieb: > Das ist in der Tat tatsächlich eher unüblich. Bspw. Die STM32Fxxx Serien > haben immer den vollen RAM und FLASH Ausbau. Und den kann man auch > nutzen. Muss man teilweise auch, weil zumindest früher sämtliche Das war bei den Fxxx in der Tat der Fall. Bei der G0-Reihe ist das teilweise nicht mehr so, da kann man den "als nicht vorhanden" spez. Flash tatsächlich nicht mehr nutzen (oder nur noch teilweise mit einem kleinen Trick). Bei der 256kB-Variante des G0B1 kann man 384kB nutzen, indem man mit dem DUAL_BANK-Bit herumspielt. Es bleiben aber trotzdem immer nur 256kB direkt ansprechbar, und das DUAL_BANK-Bit im Normalbetrieb zu ändern, ist riskant. Da ist also Schluss mit lustig :-( Der Grund ist vmtl., dass auch bei der 256kByte-Variante der Flash-Bereich durchgehend ohne Lücke bleiben soll. Für die neueren Varianten, U5 etc., weiß ich es nicht, aber es wäre nicht überraschend, wenn ST das verriegelt hat, ebenso die extra Peripherie. Es sind lange genug Billig-Versionen vom F10x (offiziell z. B. ohne USB) als "full-featured" F103 verwendet worden, so dass es ST ärgern dürfte ...
H. H. schrieb: > billigen kundenspezifischen µC Waren kundenspezifische Varianten nicht schon immer ein Treiber? Also wenn jemand 2 Mio abnimmt und ein Modul x hinzu möchte
Beitrag #7455975 wurde von einem Moderator gelöscht.
Es gibt immer neuere "bessere" Mikrocontroller. Für Hobbybastler, die 1-2 Projekte im Jahr haben, ist es aber mühsam, sich jedes mal auf den neuesten Stand zu bringen. Oft braucht man auch noch neue Programmieradapter und dafür wiederum neue Software. Insofern finde ich es im Hobby durchaus OK, mal 5-10 Jahre bei dem zu bleiben, was man schon hat und kennt.
Justnow M. schrieb im Beitrag #7455975: > Maxim B. schrieb: >> Deshalb mache ich fast alles mit einem einzigen Typ: ATMEGA1284P > > Gute Strategie. Das vereinfacht in der Entwicklung vieles. > Nur der Typ sollte etwas aktueller sein. Meine Empfehlung: AVR128DB. > Hat viele Vorteile. Jepp, ist seit 2..3 Jahren auch mein primäres AVR8-Target. Downsizing zu irgendwelchen neueren Megas oder Tinys (also den anderen XMega-Erben) ist dann relativ leicht, insbesondere natürlich, wenn man bei der Entwicklung gleich auch die Option zum Downsizing im Hinterkopf hat und halt nicht gerade Peripherie wählt, die es bei den möglichen kleineren Targets nicht (oder nicht in genügender Zahl) gibt. Berücksichtigt man das, ist das Downsizing i.d.R. mit einer Rekonfiguration der Pin-Zuordnung und der Wahl des endgültigen Target erledigt.
Beitrag #7455993 wurde von einem Moderator gelöscht.
Stefan F. schrieb: > Insofern finde ich es im Hobby durchaus OK, mal 5-10 Jahre bei dem zu > bleiben, was man schon hat und kennt. Beim Hobby bin ich seit rund 20 Jahre bei dem, was ich kenne (primär Atmega8 bzw. dessen Nachfolger, aktuell Atmega328P) und das halte ich für völlig OK im Hobby-Bereich. Im Unternehmen sind wir vor geraumer Zeit auf die neuen Atmegas "umgestiegen" (als Ersatz für den Atmega8 und Co z.B. setzen wir heute oft den Atmega3216/7 ein)
Hallo, du meinst den ATtiny 3216/17. :-) Zur Info in die Runde. Es soll noch ein AVRxDU mit nativen USB kommen.
Peter D. schrieb: > Hat mal jemand eine Übersicht gefunden, worin die sich überhaupt > unterscheiden.
Peter D. schrieb: > Microchip hat ja ganz schnell nen Haufen neuer Typen rausgebracht. > Z.B. bei den 8kB 14-Pinnern gibt es allein schon 5 Varianten: > - ATtiny84 > - ATtiny841 > - ATtiny804 > - ATtiny814 > - ATtiny824 > > Warum diese Vielfalt, die sehen sich doch alle sehr ähnlich? > Hat mal jemand eine Übersicht gefunden, worin die sich überhaupt > unterscheiden. > Für neue Projekte solte man wohl nur noch den 824 einsetzen. Der 841 ist einer der wenigen älteren Modelle mit I2C Client Hardware und 2 UARTs. Und es gibt halt verschiedene Ausstattungslinien. Meist gucke ich hier: https://www.mouser.de/pdfDocs/NXP_ATtiny_FS.pdf Nachtrag: Die vorletzte Ziffer bestimmt die Serie, die letzte die Pins - und vorn die Größe des Flash
:
Bearbeitet durch User
ATtiny1614 SOIC-14 Flash: 16 KB SRAM: 2 KB EEPROM: 256 B – One 16-bit Timer/Counter type A (TCA) with three compare channels – Two 16-bit Timer/Counter type B (TCB) with input capture – One 12-bit Timer/Counter type D (TCD) for control applications – One 16-bit Real-Time Counter (RTC) – Two 10-bit Analog-to-Digital Converters (ADCs) – Three 8-bit Digital-to-Analog Converters (DACs), one external channel – Three Analog Comparators (AC) – Multiple voltage references – One USART – One SPI – One I²C – External interrupt on all general purpose pins – Event System – Configurable Custom Logic – Peripheral Touch Controller Aber das "Silicon Errata" ist auch umfangreich.
Uwe D. schrieb: > Der 841 ist einer der wenigen älteren Modelle mit I2C Client Hardware > und 2 UARTs. Wobei dieser I2C-Client meines Wissens nach sogar auschließlich beim 441 und 841 existiert, was das Teil auch im Umfeld der Classic-AVR8 zum Exoten macht. Man vermeidet es im Allgemeinen aber eher, Exoten zu verwenden. Klar, die 441/841 haben eine im Vergleich zu den übrigen Classic-Tinys beindruckende Vielfalt an Peripherie zu bieten. Aber das ist tatsächlich ihr einziger Vorteil. Aber auch nur dann, wenn das Ziel ist, mit möglichst nur einem µC-Typen eine breite Anwendungspalette abzudecken. Und es scheitert auch dann oft dran, dass die Dinger schlicht zu wenige Pins haben. Damit ist es völlig unmöglich, alle eingebaute Peripherie gleichzeitig zu nutzen. Und, viel schlimmer: oft ist es auch unmöglich, die für eine bestimmte Anwendung konkret benötigte Kombination der prinzipiell vorhandenen Peripherie zu benutzen, selbst wenn auch die verfügbare Pinzahl prinzipiell reichen würde. Meine Meinung: Ein Irrweg. Das Problem ist einfach: Wenn schon das Konzept verfolgt wurde, wahlweise möglichst viel verschiedenen Peripherie bei kleinem Pincount zu bieten, dann hätte der Muxer natürlich auch entsprechend leistungsfähig sein müssen. Ich vermute mal, die 441/841 sind nach dem Pflichtenheft eines Großabnehmers entstanden und dieses Pflichtenheft wiederum ist das Extrakt aus der Produkpalette eben dieses Abnehmers. Der Muxer unterstützt alles, was gefordert war, aber leider auch kein bissel mehr.
Angehängte Dateien:
-
ATtiny_difference.png
2,7 KB
Hier mal zusammengefaßt die Unterschiede der 3 neuen ATtiny-Serien. Keine enthält alle Features.
Beitrag #7458199 wurde von einem Moderator gelöscht.
Peter D. schrieb: > Hier mal zusammengefaßt die Unterschiede der 3 neuen ATtiny-Serien. Die Märchenonkels und -Tanten vom Marketing mal wieder :-( Auch die Tiny-2-Familie besitzt nur ein CCL-Modul. Dieses besitzt jedoch 4 LUTs im Gegensatz zu den beiden Vorgänger-Familien mit jeweils 2 LUTs. Grüßle, Volker
Beitrag #7458213 wurde von einem Moderator gelöscht.
Moby A. schrieb im Beitrag #7458213: was soll denn jetzt das einschleimen?
Peter D. schrieb: > Microchip hat ja ganz schnell nen Haufen neuer Typen rausgebracht. > Z.B. bei den 8kB 14-Pinnern gibt es allein schon 5 Varianten: > - ATtiny84 > - ATtiny841 > - ATtiny804 > - ATtiny814 > - ATtiny824 > > Warum diese Vielfalt, die sehen sich doch alle sehr ähnlich? > Hat mal jemand eine Übersicht gefunden, worin die sich überhaupt > unterscheiden. > Für neue Projekte solte man wohl nur noch den 824 einsetzen. Servus, ich finde es spannend, daß sich Leute zuerst nach der Flashgröße richten. Das ist für mich ehrlich gesagt nicht das erste Kriterium. Für mich ist die benötigte und vorhandene interne/externe Peripherie das Kriterium Nr. 1, und die Flash- und RAMgröße wird dann entsprechend der Softwaregröße ausgewählt. Gruß Robert Auf Deine Frage: Am günstigsten dürfte der Attiny804 sein, den besten Timer hat der 814, den besten A/D-Wandler wohl der 824, und der mit der meisten Betriebserfahrung ist der 84er. Den aktuellsten Core haben die 8.4er aus der Attiny -0 -1 -2 Serie.
Robert G. schrieb: > ich finde es spannend, daß sich Leute zuerst nach der Flashgröße > richten. Nö, es ging nur um die Typenvielfalt bei selber Flashgröße und Bauform. Ich befürchte, daß einige der 5 Typen nicht genug nachgefragt werden und wieder hinten runterfallen. Ich bin bereits mit den AT89S8252, AT89C51RE2, P87C751, P89C668 auf die Nase gefallen.
Peter D. schrieb: > Ich befürchte, daß einige der 5 Typen nicht genug nachgefragt werden und > wieder hinten runterfallen. Ist die Frage, welcher Aufwand dahinter steckt, diese Typenvielfalt vorzuhalten. Wenn das initial nur "tied down"-Versionen des gleichen Chips sind (was möglich wäre), dann kostet das Microchip nicht wirklich viel, das so anzubieten.
Beitrag #7458271 wurde von einem Moderator gelöscht.
Beitrag #7458286 wurde von einem Moderator gelöscht.
Beitrag #7458287 wurde von einem Moderator gelöscht.
Beitrag #7458289 wurde von einem Moderator gelöscht.
Beitrag #7458290 wurde von einem Moderator gelöscht.
Beitrag #7458303 wurde von einem Moderator gelöscht.
Beitrag #7458304 wurde von einem Moderator gelöscht.
Beitrag #7458306 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
ATtiny402_Fuses.png
62 KB
Jörg W. schrieb: > Ist die Frage, welcher Aufwand dahinter steckt, diese Typenvielfalt > vorzuhalten. Wenn das initial nur "tied down"-Versionen des gleichen > Chips sind (was möglich wäre), dann kostet das Microchip nicht wirklich > viel, das so anzubieten. Ja, genau, z.B. ATtiny402 hat gar keinen TCD. Und was gibt es dann zu konfigurieren mit dem TCD0CFG?
Beitrag #7458317 wurde von einem Moderator gelöscht.
Beitrag #7458319 wurde von einem Moderator gelöscht.
Beitrag #7458321 wurde von einem Moderator gelöscht.
Beitrag #7458322 wurde von einem Moderator gelöscht.
Beitrag #7458323 wurde von einem Moderator gelöscht.
Beitrag #7458339 wurde von einem Moderator gelöscht.
Beitrag #7458340 wurde von einem Moderator gelöscht.
Beitrag #7458341 wurde von einem Moderator gelöscht.
Beitrag #7458343 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten