ATtiny Typenchaos bei Microchip

OP #7453148
Lesenswert?

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.

#7453173
Lesenswert?

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.

#7453178
Lesenswert?

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.

OP #7453189
Lesenswert?

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.

Moderator Persönliche Seite #7453195
Lesenswert?

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.

#7453215
Lesenswert?

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.

Moderator Persönliche Seite #7453224
Lesenswert?

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.

(Firma: Gast) #7453236
Lesenswert?

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.

Moderator Persönliche Seite #7453239
Lesenswert?

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.
#7453336
Lesenswert?

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  |
Beitrag #7453457 wurde von einem Moderator gelöscht.
Gast #7453745
Lesenswert?

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.

Moderator Persönliche Seite #7453762
Lesenswert?

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.

Gast #7453793
Lesenswert?

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.

Gast #7453802
Lesenswert?

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 %.

OP #7453819
Lesenswert?

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).

Moderator Persönliche Seite #7453828
Lesenswert?

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.

Moderator Persönliche Seite #7453840
Lesenswert?

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).

Gast #7453843
Lesenswert?

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.

#7455912
Lesenswert?

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.

Gast #7455918
Lesenswert?

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.

#7455925
Lesenswert?

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

Beitrag #7455975 wurde von einem Moderator gelöscht.
Gast #7455989
Lesenswert?

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.

#7455991
Lesenswert?

Justnow M. schrieb:

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.
#7456553
Lesenswert?

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)

#7456958
Lesenswert?

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

#7456987
Lesenswert?

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.

#7457881
Lesenswert?

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.

Beitrag #7458199 wurde von einem Moderator gelöscht.
Beitrag #7458213 wurde von einem Moderator gelöscht.
#7458227
Lesenswert?

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.

OP #7458237
Lesenswert?

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.

Moderator Persönliche Seite #7458263
Lesenswert?

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.
#7458312
Lesenswert?

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?

Angehängte Dateien:
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.