ATtiny-Übersicht

ATtiny-Übersicht

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.208
58
48
Hennigsdorf
Sprachen
BascomAVR, Assembler
LotadaC hat eine neue Ressource erstellt:

ATtiny-Übersicht - Übersicht/Vergleich aller (mir bekannten) ATtinies

Den Anhang 7030 betrachten
Hier eine erste Vorab-Version meiner Übersicht.
Korrekturen und Vorschläge gern im Diskussions-Thread.
Weitere Informationen zu dieser Ressource...


Gerüchteküche:
ATtiny051/101 (0,5/1kB Flash, 6 Beine)
ATtiny052/102 (0,5/1kB Flash, 8 Beine)
ATtiny804 (8kB, 14 Beine)
ATtiny104 (1kB, 14 Beine <--???)
ATtiny406/806 (4/8kB, 20 Beine)
ATtiny807 (8kB, 24 Beine)

hmm... werd wohl mal mit meiner Liste weitermachen müssen...
Hat noch irgendwer was für mich?
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.208
58
48
Hennigsdorf
Sprachen
BascomAVR, Assembler
So, auf den ersten Blick:
ATtiny102/104
Es scheint sich im denselben Kern zu handeln - einmal als 8Beiner, einmal als 14Beiner.
  • 1K Flash
  • 32 Bytes SRAM
  • kein Eeprom
  • nur 16 Rechenregister
  • bis 12MHz extern
  • ein 16Bit Timer mit 2xPWM, 1x ICP mit den üblichen Modi eines 16bitters
  • 1x UART
  • Programmierung via TPI
  • 10bit-ADC (single ended)
  • AC mit ACO-Pin
  • kein SPI (kann aber durch den UART emuliert werden)
Obwohl die UART-Register im 0x1F-Adressraum liegen, scheinen sie nicht direct bit accessible zu sein.
Der Counter-Eingang (T0), der Input-Capture-Pin und die OC-Pins können auf Beine Remapped werden, die nur der 104 hat (auch beim 102???)
Im Register Description wird auch bezüglich der Beine nicht unterschieden - hat man beim 102 Zugriff auf die nicht angeschlossenen Beine?
SPM/LPM gibts nicht, der Flash ist in den "SRAM" remapped - interessant fand ich:
Constant tables can be allocated within the entire address space of program memory by using load/store instructions. Since program memory can not be accessed directly, it has been mapped to the data memory.
Lesen kenn ich, aber schreiben??
Ok, das DB ist preliminary...

Meine Meinung: als 102 ist der Tiny in der 8er-Klasse recht interessant - 'n ADC-Controller mit UART und 2-Kanal-PWM-Timer.
In der 14er-Klasse kommt er mMn aber nicht an den 441/841 ran

btw lassen sich die TPI-Tinies sehr schön HV-Flashen, was effektiv einen weiteren Pin schaffen kann...
 
Zuletzt bearbeitet:

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.208
58
48
Hennigsdorf
Sprachen
BascomAVR, Assembler
Oha (II)
ATtiny814/816/(1616)/417/817/(1617)
  • 4/8/(16)k Flash
  • 256/512/(??) Bytes SRAM
  • 128Bytes Eeprom
  • wie beim 102/104 in unterschiedlichen Beinzahlen ..4->14 Beine, ..6->20 Beine, ..7->24Beine
  • zur Laufzeit änderbare Clocksource (glaub ich) inklusive internem 32kHz ULP-Oszillator
  • 16Bit-TimerA mit drei OutputCompares, kann in zwei 8Bit-Timer mit je 3 OC-Units geteilt werden
  • 16Bit-TimerB mit einem Input Capture Unit und diversen neuen Timermodi (zB Pulslängenmessung)
  • 12Bit-TimerD mit zwei OC-Units (PWM mit DeadTime), zwei IC-Units, Dithering, externer Taktquelle bis 32MHz
  • 16Bit-RTC (über externen 32786Hz oder internen ULP), ein Compare Unit
  • 1 x UART
  • 1 x SPI
  • 1 x TWI (Master/Slave)
  • Event-System, zwei Kanäle, die Hardware verketten kann
  • Analog Comperator mit ACO und programmierbarer Hysterese
  • 10Bit-ADC (single ended) mit Akkumulation von 2^n Samples (n=0..6), optionaler "Fenster-Komperatormodus", Temperatursensor, programmierbare Inputcapitance
  • 8Bit-DAC
  • integrierter Peripheral Touch Controller
  • Programmierinterface UPDI (??)
Das Datenblatt ist ... ähm ... sehr ... ähm ... gewöhnungsbedürftig, die Hardwarearchitektur auch...
Es findet sich kein Register Summary, keine Assembler-Codes (aber immerhin 'n Instruction Set) - riecht irgendwie alles sehr nach PIC...

(Der PTC-Teil ist im Datenblatt wie üblich quasi gar nicht dokumentiert, man soll den QTouch-Composer verwenden, und das dann irgendwie mit seinem Code "linken" - wie geht sowas ( @Dirk - insbesondere mit ASM)?)

Die 16KByte-Flash-Versionen sind nicht konkret genannt, tauchen aber im Device Family Overview auf. Außerdem deutet die zwei Byte breite IVT darauf hin...
 
Zuletzt bearbeitet:

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.208
58
48
Hennigsdorf
Sprachen
BascomAVR, Assembler
riecht irgendwie alles sehr nach PIC
Stimmt natürlich nicht, es handelt sich vielmehr um diverse Module, die aus den XMega stammen - man könnte den Tiny81x also als XTiny bezeichnen.

Heute hat mir das Atmel Studio ein Device-Pack-Update vorgeschlagen (bzw ich habs endlich mal gemacht); dabei sind mir zwei Tinies aufgefallen:
ATtiny80 und ATtiny840.
Wenn man damit ein Projekt erstellt, paßt das I/O-Fenster irgendwie nicht ganz zur automatisch eingebundenen Definitionsdatei, spekulieren könnte man...
ATtiny80:
  • Signatur 0x1E9314
  • 8k Flash
  • 1024 Bytes SRAM
  • 512 Bytes Eeprom
  • 1AC (mit einstellbarer Hysterese)
  • drei oder vier (??) Ports (A, B, C voll; D mit 4 Pins), für C gibt's 'n High Drive Enable Bit
  • SPI
  • TC0 8bit (2 OCs)
  • TC1 16bit
  • TC2 8bit, async
  • USART (1 ??)
  • Custom Logic
  • QTouch (QTRIP in der IVT)
  • TWI
abweichend/ergänzend beim Tiny840:
  • Signatur 0x1E93C3
  • PortB und PortD voll, PortC nur 7 Pins (ohne high drive Hinweis)
  • die drei Timer mit je zwei OC-Units und Output-Compare-MUX
  • USART0
  • PTC-Interrupts
  • kein TWI
  • TC3-Adressen in der IVT
Irgendwie paßt da einiges nicht wirklich zusammen, der 80 erinnert irgendwie an Tiny20 und 40 (auch wegen QTRIP, der PTC soll ja dort letztendlich nicht integriert worden sein (möglicherweise auch nur aus irgendwelchen Gründen deaktiviert). Als Programmer schlägt das Studio unter anderem den AVRisp mkII vor (also keine UPDI). Möglicherweise ein nicht realisierter Ansatz, bevor die XTinies kamen??

Der 840 hingegen sieht schon eher nach den XTinies aus, eventuell 'ne Vorabversion der korrekten Devices?
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.208
58
48
Hennigsdorf
Sprachen
BascomAVR, Assembler
10Bit-ADC (single ended) mit Akkumulation von 2^n Samples (n=0..6), optionaler "Fenster-Komperatormodus", Temperatursensor, programmierbare Inputcapitance
Hatte vergessen dazuzuschreiben, daß er gegenüber den non-X-ADCs mal eben um Faktor 7,5 schneller getaktet werden darf. Damit sollten 115kSps/s bei 10bit drin sein, bei 8bit sogar 150.
(Es gibt ja diverse Projekte, die 'n simples "Oszilloskop auf Basis eines konventionellen (SPI-) AVR zum Ziel haben - ein X-AVR wäre … geeigneter...)
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)