Im neuen Atmel Studio 7 ist ein noch nicht angekündigter ATtiny104
aufgetaucht. Signatur ist 0x1e900B. Was mag es damit auf sich haben?
Dem includefile (Anhang) kann man entnehmen dass es sich um einen
ATtiny10 mit mehr I/O zu handeln scheint. Es gibt 12 GPIO, einen UART
und einen "Voltage level monitor", der neu für die ATtiny zu sein
scheint?
Tim . schrieb:> Im neuen Atmel Studio 7 ist ein noch nicht angekündigter ATtiny104> aufgetaucht. Signatur ist 0x1e900B. Was mag es damit auf sich haben?
Für dieses Jahr waren neue Tinys angekündigt.
Tim . schrieb:> Im neuen Atmel Studio 7 ist ein noch nicht angekündigter ATtiny104> aufgetaucht. Signatur ist 0x1e900B. Was mag es damit auf sich haben?>> Dem includefile (Anhang) kann man entnehmen dass es sich um einen> ATtiny10 mit mehr I/O zu handeln scheint. Es gibt 12 GPIO, einen UART> und einen "Voltage level monitor", der neu für die ATtiny zu sein> scheint?
sehr interessant. Danke für den Hinweis.
Vermutung (bitte prüfen):
Die angehängte Datei lässt auf einen 14-beinigen attiny mit 1kB (flash)
32 byte RAM schließen. Mit 8* ADC, einem Comparator und einem Timer
(16Bit). Damit wäre der Kern günstiger als ein ATtiny13. Ich tippe mal
auf einen sehr günstigen Controller.
Gruß Thomas
Th. B. schrieb:> 32 byte RAM schließen
Also das wäre jetzt aber etwas wenig, findest du nicht?
EDIT: OK, ich seh grad, der Attiny 10 hat auch nur 32 byte SRAM...
Michael K. schrieb:> Th. B. schrieb:>> 32 byte RAM schließen>> Also das wäre jetzt aber etwas wenig, findest du nicht?>> EDIT: OK, ich seh grad, der Attiny 10 hat auch nur 32 byte SRAM...
Wenn man es aus der Perspekive der ATtiny 4/5/9/10 betrachtet, wäre das
eine perfekte Ergänzung. Günstig für kleine Aufgaben aber mit vielen
Anschlüssen. Da stellt sich dann auch die Frage ob der 104 überhaupt per
SPI programmiert wird oder eher wie der attiny10 per TWI.
Ich habe noch ein weiteres Indiz gefunden.
Auf einer offizielen Webseite von Atmel
http://packs.download.atmel.com/
gibt es einen leeren Listeneintrag im Quelltext:
<li id="ATtiny10" class="device device-list-item">
</li>
<li id="ATtiny104" class="device device-list-item">ATtiny104</li>
<li id="ATtiny13" class="device device-list-item">
</li>
Das ist doch kein Zufall das der zwischen ATtiny10 und ATtiny13 liegt?!
Gruß Thomas
Th. B. schrieb:> Das ist doch kein Zufall das der zwischen ATtiny10 und ATtiny13 liegt?!
Nö, das nennt sich alphabetische Reihenfolge. :-)
xXx schrieb:> Lohnt sich der Verzicht auf Speicher ueberhaupt in der Fertigung
Meinst du, die hätten das aus Spaß weggelassen?
Die haben seinerzeit an allen Ecken und Enden gespart, damit sie
den 6-Pinner in ein SOT-23 bekommen. Das sieht man u. a. auch daran,
dass man die Dinger eben nur mit Vcc = 5 V programmieren kann – das
spart Fläche für den Kondensator in der Vpp-Ladungspumpe. Das sieht
man auch daran, dass sie ihm nur den halben Registersatz spendiert
haben. Und eben am winzigen RAM.
Inwiefern es natürlich Sinn hat, einen 14-Pinner mit der Die-Größe
eines SOT-23 auszustatten, ist 'ne andere Frage. Insbesondere ein
klobiges DIL-Gehäuse dürfte dann schon fast so teuer sein wie der
Die da drin, und da ist es fraglich, ob $BASTLER dann nicht lieber
gleich einen ATtiny24 nehmen kann, der ihm 128 Byte SRAM und den
vollen Registersatz bietet.
OK, wenn man sich das Package 12U3 des ATtiny20 ansieht, das ist mit
1,5 x 1,4 mm² natürlich schon hübsch klein, aber dem haben sie
zumindest 128 Byte SRAM spendiert. Es muss wohl schon einen
Millionenkunden geben (dem es auf jeden Cent ankommt), wenn man
unterhalb des ATtiny20 dann noch einen Controller produziert.
A. K. schrieb:> Die 32 Bytes der Winzlinge dürften hauptsächlich für den Stack da sein.
Bei C-Programmen für diese Winzlinge ist ein Blick ins Assemblerlisting
kein Fehler, insbesondere der Stack-Bedarf von ISRs verdient
Aufmerksamkeit.
Ich finde es erstaunlich, was man mit dem gcc aus so wenig SRAM und
Flash herausholen kann.
Als Vergleich mal ein Die-Photo vom PIC10F206. Der liegt mit 0,75kB
Flash und 24 Bytes RAM nicht weit weg. Nur die 16 Register fehlen, die
mindestens so viel Platz fressen dürften wie die 32 Bytes SRAM.
http://www.tayloredge.com/museum/mymuseum/MySilicon/PIC10F206.jpg
Man sieht dort recht gut, dass die 6 Bondpads nicht unerheblich zur
Grösse beitragen. Bei einer 14er ist dann wohl fast die Hälfte vom Die
von Bondpads verbraten - bei vergleichbarer Fabtech (bei neuerer wirds
krasser).
A. K. schrieb:> Die 32 Bytes der Winzlinge dürften hauptsächlich für den Stack da sein.
Und auch dafür sind sie sehr knapp bemessen. Bei verschachtelten
Subroutinen ist ganz schnell Ende. Von dazwischen funkenden Interrupts
gar nicht zu reden...
Icke ®. schrieb:> Und auch dafür sind sie sehr knapp bemessen. Bei verschachtelten> Subroutinen ist ganz schnell Ende. Von dazwischen funkenden Interrupts> gar nicht zu reden...
Klar. Aber die Tin4-10 sehe ich eher in Rollen, in dem man bisher einen
NE555 oder so einsetzte. Mit Programmen, die wahrscheinlich auf eine
Seite passen.
Einsatzbeispiel für solche Winzlinge: Ich habe mal einen Tiny85 als
Taktgenerator eingesetzt. Der liefert einer CDP1802 Platine den
CPU-Takt, den UART-Takt und einen zyklischen Interrupt mit Acknowlege.
Das Programm für die beiden Takte besteht nur aus der Initialisierung
der beiden Timer.
Privat sind diese Teile ziemlich witzlos. Da müssen schon 5stellige
Stückzahlen sein, damit sich das lohnt.
A. K. schrieb:> Einsatzbeispiel für solche Winzlinge: Ich habe mal einen Tiny85 als> Taktgenerator eingesetzt.
Yep, ich habe auch schon einen per Jumper konfigurierbaren ADC-Takt
mit einem ATtiny10 generieren lassen. Wie du schon schriebst: sowas
wie einen 555, aber eben statt eines Potis dann ein Jumperblock. :)
Icke ®. schrieb:> Bastler sind sicher nicht die Zielgruppe.
Das dürfte für alle µCs und alle anderen Elektronikbauteile zutreffen.
Der Bastler als Zielgruppe wird heute eher mit Baugruppen adressiert,
Arduino usw.
Konrad S. schrieb:> Bastler sind sicher nicht die Zielgruppe.>> Das dürfte für alle µCs und alle anderen Elektronikbauteile zutreffen.> Der Bastler als Zielgruppe wird heute eher mit Baugruppen adressiert,> Arduino usw.
Würd ich nun nicht gerade sagen.
Gehört doch nicht viel dazu die platzsparend anzuschließen und zu
programmieren.
Da kauft man doch keinen sperrigen Arduino für viel Geld.
Bastler schrieb:> Stimmt, Mega328 in DIP34 mit USB-Bootloader für zwofufzsch ist> viel zu groß und viel zu teuer und vor allen geht einfach. Macht kein> Spaß!
Ok, das überzeugt natürlich für viele Zwecke. Ich dachte eher an die
größeren Platinen. Und dennoch, so ein winziger Tiny tuts oft genauso-
und ist immer noch viel kleiner und immer noch viel billiger.
Moby schrieb:> so ein winziger Tiny tuts oft genauso-> und ist immer noch viel kleiner und immer noch viel billiger
Wo ist der billig? ATTINY10 mit 1K Flash 32 Byte RAM kostet 80 Cent
Vergleichbarer PIC10F222 kostet die Hälfte
Vergleichbarer 8051 EFM8BB10F2 kostet weniger als die Hälfte
Lothar schrieb:> Vergleichbarer PIC10F222 kostet die Hälfte
Seltensam: wenn ich bei Digikey gucke, dann kostet ein ATtiny10
(in den Stückzahlen, bei denen das relevant wird, also ganze Rollen)
36 Cent, der PIC 10F222 37 Cent.
> Vergleichbarer 8051
Du meinst wirklich, es gäbe 8051, die „vergleichbar“ sind? ;-)
Ansonsten: 28 Cent, wenn man sie auf einer Rolle nimmt. Im Gegensatz
zu den anderen beiden jedoch nicht vorrätig.
Preise für Einzelexemplare sind bei sowas wohl kein Kriterium, denn
jeglicher Versand kostet dann schon mehr.
Lothar schrieb:> Wo ist der billig? ATTINY10 mit 1K Flash 32 Byte RAM kostet 80 Cent>> Vergleichbarer PIC10F222 kostet die Hälfte
Billiger als 2,50€ ...
Jörg W. schrieb:> Du meinst wirklich, es gäbe 8051, die „vergleichbar“ sind? ;-)
Hast recht EFM8BB10F2 dürfte mit 25 MHz und 3-Stage-Pipeline etwas
schneller sein :-)
Lothar schrieb:> Jörg W. schrieb:>> Du meinst wirklich, es gäbe 8051, die „vergleichbar“ sind? ;-)>> Hast recht EFM8BB10F2 dürfte mit 25 MHz und 3-Stage-Pipeline etwas> schneller sein :-)
Aber nur, wenn man einen Programmierer findet, der so masochistisch
ist, im 3. Jahrtausend noch 8051 programmieren zu wollen.
Ich würde es jedenfalls nicht einmal für Geld tun. ;-)
Jörg W. schrieb:> Aber nur, wenn man einen Programmierer findet, der so masochistisch> ist, im 3. Jahrtausend noch 8051 programmieren zu wollen.
Gehört zwar nicht wirklich hierher, aber mit dem Keil Compiler wird ein
8051 heute genau so in C programmiert wie z.B. ein ARM. Soll heißen man
bekommt vom Memory Model nichts mit. Der Stack wird automatisch auf 0x80
gesetzt, Variablen ins interne RAM, Arrays ins externe RAM, static const
in den Flash. Kein PROGMEM wie beim AVR. Kein SFR Banking wie z.B. beim
atmega2560
Tatsächlich ist der Keil 8051 sogar weiter als der Keil ARM, der macht
noch Probleme beim RAM. Beispiel: ein ARM hat 64K RAM und es soll ein
50K Array geben. Tatsächlich hat dieser ARM aber im linearen Adressraum
z.B. nicht zusammenhängende 32K und 2x 16K Blöcke. Das schafft der
Compiler noch nicht automatisch.
Lothar schrieb:> Gehört zwar nicht wirklich hierher, aber mit dem Keil Compiler wird ein> 8051 heute genau so in C programmiert wie z.B. ein ARM.
Das wurde er schon vor 25 Jahren. Das macht trotzdem keine moderne
Architektur aus ihm.
Jörg W. schrieb:> Das wurde er schon vor 25 Jahren. Das macht trotzdem keine moderne> Architektur aus ihm.
Warum bedeutet das jetzt
> masochistische Programmierer
???
Das Ding ist ausgereift.
Es gibt einen Haufen Software.
Er ist ein Industriestandard.
Er erfüllt seinen Zweck.
Was machen "Moderne Architekturen" heute sooo viel besser?
A. K. schrieb:> Klar. Aber die Tin4-10 sehe ich eher in Rollen, in dem man bisher einen> NE555 oder so einsetzte. Mit Programmen, die wahrscheinlich auf eine> Seite passen.
Also der ATtiny10 kann schon etwas mehr:
https://github.com/cpldcpu/u-wire
Moby A. schrieb:> Das Ding ist ausgereift.> Es gibt einen Haufen Software.> Er ist ein Industriestandard.> Er erfüllt seinen Zweck.
Mit diesen Totschlagargumenten bräuchste du keinerlein Innovation
in der Technik.
Leider at Atmel es immer noch nicht geschafft, den Compiler vernünftig
auf den reduced core anzupassen und STS/LDS zu verwenden.
Beitrag "GCC und LDS/STS auf Attiny10"
Studio 7
input:
Tim . schrieb:> Also der ATtiny10 kann schon etwas mehr:>> https://github.com/cpldcpu/u-wire
Da ist dann aber auch schon ein Klimzug includiert ;)
https://cpldcpu.wordpress.com/2014/03/19/%C2%B5-wire-usb-on-an-attiny-10/
Further measures to reduce code size:
I clocked the controller at 12 MHz using the internal RC oscillator
and calibrated from the USB bus timing. The 12 MHz V-USB
implementation
is much smaller than the recommended 12.8 MHz version, but it does not
come with an internal phase locked loop to cope with the more
inaccurate
RC-oscillator timing. Surprisingly I did not observe any timing
errors.
Since the reduced core AVR only support 16 registers, I had to manually
remap numerous registers in V-USB to avoid collisions with GCC.
I removed all handling of the reset signal on the USB-Bus. This means
the
device will not properly re-enumerate when a bus reset is issued. But
this is not a problem if you plug it in after the PC was turned on.
V-USB was completely gutted and integrated into the main loop. It only
support SETUP requests to a single endpoint now. All additional
functions have been removed. This also reduces stack usage as fewer
subroutine calls are required.
I removed the code to support replies from the SRAM. Data can only be
sent
from flash. This is possible since only single byte-replies are
required
to implement the protocol, apart from the fixed USB configuration
replies which are stored in the flash.
Final Stats
Flash: 988 of 1024 bytes used (96.4%)
SRAM: 28 (variables)+2 (stack) of 32 bytes used (93.8%)
This is most likely the most complex firmware ever loaded into an
ATtiny10
Jörg W. schrieb:> Totschlagargumenten
Das Gefühl hab ich, wenn ich
> Programmierer findet, der so masochistisch> ist,> Das wurde er schon vor 25 Jahren. Das macht trotzdem keine moderne> Architektur aus ihm.
höre.
Argumente, die hier fälschlicherweise auf die übliche Abnutzung
materieller Dinge abzielen, mit entsprechend abwertenden Emotionen
belegt sind.
Lothar schrieb:> Hast recht EFM8BB10F2 dürfte mit 25 MHz und 3-Stage-Pipeline etwas> schneller sein :-)
Nicht nur das.
Mit 12Bit ADC, Crossbar, Interruptprioritäten, in C programmierbar usw.
usw. dürfte das die EiWoMiSa unter den kleinen MCs sein.
Wow!
Jörg W. schrieb:> Aber nur, wenn man einen Programmierer findet, der so masochistisch> ist, im 3. Jahrtausend noch 8051 programmieren zu wollen.
Was ist denn an C-Programmierung und wählbaren Interruptprioritäten
masochistisch, weißt Du was besseres?
Der Keil C51 war für mich der Hauptgrund, das ganze Assemblergelumpe
über Bord zu schmeißen.
Ich hab nur mit offenem Mund auf den Output geschaut, wie effizient der
war.
Meine ganzen über Jahre erstellten Assemblerlibs waren ausnahmslos
langsamer und größer.
Auch hat der 8051 den Charme, daß viele Instruktionen keine Flags
ändern, d.h. man kann oft Interrupthandler schreiben, die kein Push/Pop
enthalten, also sauschnell sind.
Nun weiß ich aber immer noch nicht, welche Vorteile eine
Jörg W. schrieb:> moderne> Architektur
für Anwendungen bringt, denen ein bewährter einfacher 8051 oder ein noch
einfacherer Tiny locker gerecht wird ???
Moby schrieb:> für Anwendungen bringt, denen ein bewährter einfacher 8051
Obwohl die kleinen 8051 die kleinen ARM im Preis immer noch deutlich
schlagen, gibt es natürlich schon Anwendungen, wo die Rechenleistung der
kleinen ARM gebraucht wird z.B. bei diesem Synthesizer der im DIP8 einen
44.1KHz Delta-Sigma DAC in Software (ARM Assembler) realisiert:
https://www.adafruit.com/products/2400
Peter D. schrieb:> Was ist denn an C-Programmierung und wählbaren Interruptprioritäten> masochistisch, weißt Du was besseres?
Wählbare Interruptprioritäten auf dem ARM vielleicht sowie ein flacher
Adressraum?
Ehrlich: wie viele konkurrierende Interruptquellen hast du wohl auf
einem 6-Pinner (und um sowas ging's ja). Man kann es der ursprünglichen
AVR-Architektur ja vorwerfen, dass sie sowas nicht hat, aber
interessanterweise ist man damit gar nicht so schlecht gefahren.
Wenn der Markt mit 8051, PIC und HCxx sowas von zufrieden gewesen
wäre, hätte der AVR (und etwas im Schatten der MSP430) wohl vor 15
Jahren keinen solchen Siegeszug einfahren können, wie er es dann
geworden ist: die haben es geschafft, einen gut aufgeteilten
Markt doch recht gründlich aufzumischen. Offenbar gab es für die
Anwender genügend Anreize, auf einen „bewährten Industriestandard“
doch lieber mal zu verzichten und auf ein neues Pferd zu setzen.
Jörg W. schrieb:> Wenn der Markt mit 8051, PIC und HCxx sowas von zufrieden gewesen> wäre, hätte der AVR (und etwas im Schatten der MSP430) wohl vor 15> Jahren keinen solchen Siegeszug einfahren können,
Wann kamen eigentlich die schnellen 8051er mit single-cycle Core auf?
Der ursprüngliche und vor vielen Herstellern eingesetzte 12-cycle Core
von Intel ist ja nicht grad für Tempo bekannt. Das könnte historisch
schon eine Rolle beim Erfolg der AVRs gespielt haben.
A. K. schrieb:> Das könnte historisch schon eine Rolle beim Erfolg der AVRs gespielt> haben.
Vermutlich, aber auch andere Dinge wie Push-Pull-Ausgangsstufen.
Jörg W. schrieb:> Wenn der Markt mit 8051, PIC und HCxx sowas von zufrieden gewesen> wäre, hätte der AVR (und etwas im Schatten der MSP430) wohl vor 15> Jahren keinen solchen Siegeszug einfahren können
Was für ein Siegeszug soll das gewesen sein? Google mal:
EMITT Microcontroller Market and Technology Analysis Report 2008
Schon damals war AVR nach Stückzahlen kaum existent:
8051 19%, H8 17%, 68HC 15%, PIC 12%, ARM 10%, V850 9%, ST8 6%, AVR 3%
Im aktuellen Report (leider nicht frei zugänglich) läuft AVR nur noch
unter sonstige.
Lothar schrieb:> Was für ein Siegeszug soll das gewesen sein?
Bei den Bastlern natürlich. Da wo es auf 'einfach' ankommt und keine
zweckfremden Forderungen gängeln ;-)
Aber Hut ab vor der Bedeutung der 8051er.
Sicher alternativ keine schlechte Wahl.
Jörg W. schrieb:> hätte der AVR (und etwas im Schatten der MSP430) wohl vor 15> Jahren keinen solchen Siegeszug einfahren können
Der AVR hat allein durch den WINAVR im Hobbybereich einen Fuß in die Tür
gekriegt. Und durch den günstigen ISP-Flash, der direkt am früher noch
vorhandenen LPT-Port programmiert werden konnte.
Die jungen Bastler haben ihn dann später in die Firma gepusht.
Die CPU-Architektur war vollkommen nebensächlich.
Nur mit dem IAR-Compiler wäre der AVR sang und klanglos untergegangen.
Die Atmel Flash-8051 mit ISP waren erheblich teurer und der Keil C51
nicht gerade ein Schnäppchen.
Und die kleinen 8051 (20-Pin) bekamen erst viel später ein ISP verpaßt.
Die Atmel 8051 Division hätte den AVR vom Tisch fegen können, wenn sie
gewollt hätte.
Moby schrieb:> Aber Hut ab vor der Bedeutung der 8051er.
Interessant ist aber, dass trotz ehemals grosser Popularität auch mal
welche völlig wegsterben. So wurde der 8051 über den 8048 vom Fairchild
F8 inspiriert, der in den 70ern den Markt von Mikrocontrollern prägte.
Der F8 freilich ist längst völlig tot.
Peter D. schrieb:> Die Atmel 8051 Division hätte den AVR vom Tisch fegen können, wenn sie> gewollt hätte.
Wobei bei den 8051ern wohl gewisse Lizenzen fällig sind oder früher
waren. Ein Motiv Atmels für eine neue Familie dürfte deshalb auch
gewesen sein, sich von solchen Zahlungen zu befreien. Das mag auch bei
den AVR32 Pate gestanden haben, mit weniger Erfolg wie mir scheint.
Generell scheint mir, dass die Marktverbreitung profitiert, wenn in
einer kritischen Phase der Marktentwicklung alle die gleichen
Vorbedingungen haben. ARM stellt selbst keine Chips her und Intel schon
seit langem keine 8051er mehr. Es konkurriert also kein
lizenzpflichtiger Hersteller mit dem Lizenzgeber. Das gilt auch für
banal Erscheinendes wie Namensrechte - die Zahl 8051 ist nicht
schützbar.
Ich vermute mal, daß einfach die Umsätze beim Atmel 8051 hoch genug
waren, um kein Geld mehr reinzustecken.
D.h. es wurde nicht als nötig erachtet, mehr Peripherie (ADC, interner
Takt, BOD usw.) oder gar ein kostenloses 51Studio mit Compiler und
Simulator/Debugger zu entwickeln.
Die Idee vom Herrn Keil, mit den generic Pointern den Programmierer
nicht mit der Architektur zu belasten, fand ich übrigens genial.
Erst wenn weitere Optimierung nötig ist, kann man mit den memory
specific Pointern Hand anlegen.
Die generic Pointer gehen sogar soweit, daß man eigenen Speicher (SPI,
I2C, 1-wire usw.) transparent einbinden kann. Man muß nur einmalig die
Grundfunktionen (Byte/Block schreiben/lesen) implementieren.
Als ich 1995 Fragen hatte, hat mir Herr Keil persönlich geantwortet.
Support ist heutzutage aber mehr ein Fremdwort.
Peter D. schrieb:> Die Idee vom Herrn Keil, mit den generic Pointern den Programmierer> nicht mit der Architektur zu belasten, fand ich übrigens genial.
Hat der das tatsächlich erfunden oder auch bloss abgeguckt? Jedenfalls
sind solche Pointer auch eine wesentliche Erleichterung bei den AVRs.
Hat nur zu lang gebraucht, bis GCC eine mögliche Adressraumtrennung
zuliess. Deren Fehlen war neben der Neugierde ein erheblicher Grund für
mich, mich anderswo unzutun. Keil ist nicht so ganz meine Preisklasse.
Peter D. schrieb:> Der AVR hat allein durch den WINAVR im Hobbybereich einen Fuß in die Tür> gekriegt.
Das kannste knicken. Von den paar Bastlern kann sich kein Hersteller
ernähren, und den GCC haben sie anfangs bei Atmel komplett ignoriert.
Da galt nur IAR als Stein der Weißen, alle relevanten Kunden haben
sich den damals wohl schätzungsweise auch geleistet.
Welch wichtige Rolle der GCC für den AVR spielt, haben sie erst sehr
viel später erkannt – bis dahin wären sie ohne Kunden, die hinreichend
viel von dem Kram kaufen, verhungert gewesen.
Peter D. schrieb:> Ich vermute mal, daß einfach die Umsätze beim Atmel 8051 hoch genug> waren, um kein Geld mehr reinzustecken.
Sie haben sich damals einfach mal überhaupt nicht als Controller-Laden
verstanden. Sie sind als Hersteller von Flash groß geworden. Die
Umorientierung auf Microcontroller als zentrales Element kam dann
erst mit dem neuen Cheffe, aber da war der AVR bereits eine gut
florierende Produktlinie.
Lt. dem Distributor Ineltek war geplant:
Update: Neue Tinys mit neuen Key Features, optimierter BOM und analog
Funktionen ab Q2 2015
6pins: TINY 101 / Tiny 051 (1KB/512B)
8 pins: Tiny 102 / Tiny 052 (1KB/512B)
14 pins: Tiny 804 (8KB)
20 pins: Tiny 806 / Tiny 406 (8KB/4KB)
24pins: Tiny 807 (8KB)
Aber man kennt ja die Diskrepanz zwischen Atmel-Ankündigungen und dem
realen Erscheinen der Produkte auf dem Markt. Und dann kommt jetzt noch
die Dialog-Sache hinzu... Also ich würd mal sagen: Ende offen.
Tim . schrieb:> Leider at Atmel es immer noch nicht geschafft, den Compiler vernünftig> auf den reduced core anzupassen und STS/LDS zu verwenden.
*arrrhg*
Aber ok, der "Support" ist ja von Atmel...
Johann L. schrieb:> Aber ok, der "Support" ist ja von Atmel...
Die werden schon wissen, warum sie den nicht offiziell bei GCC
eingekippt haben.
Das war wohl mal ein checklist item des zuständigen Menschen im
Marketing, dass mit dem Auftauchen der ATtiny10 der GCC-Support
dafür vorliegen solle, hatte ich den Eindruck. Das ist dann mehr
oder minder halbherzig zusammengerödelt worden, jetzt ist das
Häkchen gesetzt, und der diensthabende Inder bekommt keine Zeit mehr
dafür zugestanden, es nochmal neu (und korrekt) zu implementieren.
Abgesehen davon, dass es jemand extern als Hobby tut, dürfte nun wohl
die einzige Chance sein, dass Atmel da nochmal was anfasst, indem
massiv Bugreports dafür dort aufschlagen, die die schlechte Qualität
der Toolchain in diesem Bereich vorführen. Wenn das genügend sind,
dann wird wohl jemand die nötigen Ressourcen dafür einräumen müssen,
das endlich zu reparieren.
Moby A. schrieb:> Johann L. schrieb:>> *arrrhg*>> ... das tut der Compiler-Effizienz wieder mal nicht gut ;-(
Was wenn sie auch in den Assembler entsprechende Bugs einbauen?
Es soll ja eine spezielle Codierung einiger
Tiny-ohne-wertlos-Register-Befehle geben, die vom AVR-Standard
abweichen. Ist das dann auch ein Problem der (falschübersetzten)
Programmiersprache?
Carl D. schrieb:> Was wenn sie auch in den Assembler entsprechende Bugs einbauen?
Naja, so sehr weicht der Tiny-Core in dieser Hinsicht nicht von den
anderen ab, das ist schon noch recht überschaubar, was sich am
Assembler da ändert.
Beim Compiler sieht das jedoch ganz anders aus, da muss man vermutlich
an einigen Stellen anfassen, um so einen stark minimierten Core
nachträglich reinzuflanschen. Johann hat das sicher ein besseres
Gefühl, wieviel Aufwand das ist.
Jörg W. schrieb:> Carl D. schrieb:>> Was wenn sie auch in den Assembler entsprechende Bugs einbauen?>> Naja, so sehr weicht der Tiny-Core in dieser Hinsicht nicht von den> anderen ab, das ist schon noch recht überschaubar, was sich am> Assembler da ändert.
Schon klar, es ging mir eher um die Frage ob der Bug im Tool eine
Unzulänglichkeit der Sprache ist. Du verstehst sicher warum.
Jörg W. schrieb:> Johann L. schrieb:>> Aber ok, der "Support" ist ja von Atmel...>> Die werden schon wissen, warum sie den nicht offiziell bei GCC> eingekippt haben.
Und von wem ist dann der GNU-Support?
> Das ist dann mehr oder minder halbherzig zusammengerödelt worden,> jetzt ist das Häkchen gesetzt, und der diensthabende Inder bekommt> keine Zeit mehr dafür zugestanden, es nochmal neu (und korrekt)> zu implementieren.
D.h. die Inder müssen für jeden Pups um Erlaubnis Fragen? Dann hätt ich
auf so nen Job ehrlich gesagt auch keinen Bock.
Ne zeitlang hatte Atmel Embecosm angeheuert, die wirklich fähige
GCC-Entwickler haben — zumindest hab ich die Aktivität bei Embecosm so
gedeutet. Dabei ging aber vor allem um den C++ Support (libsupc++), aber
diese Initiative scheint auch abgesägt.
Jörg W. schrieb:> Carl D. schrieb:>> Was wenn sie auch in den Assembler entsprechende Bugs einbauen?>> Naja, so sehr weicht der Tiny-Core in dieser Hinsicht nicht von> den anderen ab, das ist schon noch recht überschaubar, was sich> am Assembler da ändert.
Immerhin hatten sie es geschafft LDS/STS falsch zu codieren, d.h. der
Code ist weder auf nem Target noch in nem Simulator getestet worden.
> Beim Compiler sieht das jedoch ganz anders aus, da muss man vermutlich> an einigen Stellen anfassen, um so einen stark minimierten Core> nachträglich reinzuflanschen. Johann hat das sicher ein besseres> Gefühl, wieviel Aufwand das ist.
Viel. Ich jedenfalls hab an dem Support nur was geändert wenn er was
für nich-Tiny zerbröselt hat. M.E. sind die Dinger nicht wirklich
sinnvoll in C nutzbar, zumindest soweit es avr-gcc angeht.
...andererseits würden einige meiner (privaten) C-Projekte, die auf 2KiB
laufen und < 1KiB belegen auch locker dort hinein passen. (Wobei für die
9V -> -700V SMPS nen µC herzunehmen für Hobby ok ist, professionell würd
ich das als Kunstfehler ansehen).
Johann L. schrieb:> Und von wem ist dann der GNU-Support?
Die Frage verstehe ich in diesem Zusammenhang nicht.
> D.h. die Inder müssen für jeden Pups um Erlaubnis Fragen?
Die bekommen ihre Arbeit zugeteilt. Klar haben die auch Manager
dafür, aber großartige Eigeninitiative wird dort wohl weder erwartet
noch gewünscht.
>> Naja, so sehr weicht der Tiny-Core in dieser Hinsicht nicht von>> den anderen ab, das ist schon noch recht überschaubar, was sich>> am Assembler da ändert.>> Immerhin hatten sie es geschafft LDS/STS falsch zu codieren,
Wenn ich mich recht erinnere, haben sie es einfach verschlafen,
die einzig nötige Änderung im Assembler passend und rechtzeitig
einzutüten, nämlich LDS und STS anders zu codieren, wenn man für
die Tiny-Cores assembliert.
Allerding ist dieser Bug doch nun wirklich schon eine Weile
korrigiert, oder?
1
j@uriah 76% avr-as -mmcu=attiny25 -c foo.s
2
j@uriah 77% avr-objdump -d a.out
3
4
a.out: file format elf32-avr
5
6
7
Disassembly of section .text:
8
9
00000000 <.text>:
10
0: 00 91 40 00 lds r16, 0x0040
11
j@uriah 78% avr-as -mmcu=attiny10 -c foo.s
12
j@uriah 79% avr-objdump -d a.out
13
14
a.out: file format elf32-avr
15
16
17
Disassembly of section .text:
18
19
00000000 <.text>:
20
0: 00 a1 lds r16, 64
Ja, ist er.
Ihren eigenen Assembler hatten sie natürlich sehr wohl von
vornherein korrekt abgewandelt.
Ja, es sagt natürlich schon etwas über die Tests aus, dass ihnen
das nicht aufgefallen ist. Irgendein Minimalbeispiel (welches
ohne LDS/STS auskommt) hat man ja damit compilieren können, aber
viel mehr als das nicht.
>> Johann hat das sicher ein besseres>> Gefühl, wieviel Aufwand das ist.>> Viel.
Das war/ist auch mein Eindruck dabei.
> M.E. sind die Dinger nicht wirklich> sinnvoll in C nutzbar, zumindest soweit es avr-gcc angeht.
Ja, was ein wenig schade ist. Für so einen Primitivling mit 512
oder 1024 Byte Flash noch egal, aber man hat sie ja danach bis
4 KiB gebaut.
Johann L. schrieb:> Und warum wird der überhaupt gebondet?
Da fragst du mich zu viel.
Wenn ich mir aber ansehe, dass man für das SOT-23 den halben
Registersatz rausgeworfen hat, dann vermute ich schon, dass der Chip
eines ATtiny10 wirklich so groß ist. Ganz habe ich nie verstanden,
warum die paar Register so viel ausmachen sollen. Dass man
Kondensatoren für die Vpp-Ladungspumpe spart und Programmierung des
Flashs nur noch bei 5 V unterstützt, ist da eher verständlich.
Johann L. schrieb:> Und warum wird der überhaupt debondet? Das braucht doch nur Platz und> ist teuer. Warum nicht einfach BGA wie der Dimple?>
CSP Flip Chip ist nicht unbedingt günstiger als ein SOT232-6 package.
Außerdem vermute ich mal, dass ein ATtiny10-Die schon fast zu klein für
die 6 Balls ist.
Will mal jemand einen auf machen?
Jörg W. schrieb:> Johann L. schrieb:>>> Und von wem ist dann der GNU-Support?>> Die Frage verstehe ich in diesem Zusammenhang nicht.
Na weil du gemeint hast, der Tiny Support im FSF sei nicht von Atmel:
Jörg W. schrieb:> Johann L. schrieb:>> Aber ok, der "Support" ist ja von Atmel...>> Die werden schon wissen, warum sie den nicht offiziell bei GCC> eingekippt haben.
Oder hab ich das falsch verstanden?
http://gcc.gnu.org/gcc-5/changes.html> On AVR, support has been added for the devices ATtiny4/5/9/10/20/40.> This requires Binutils 2.25 or newer.>> D.h. die Inder müssen für jeden Pups um Erlaubnis Fragen?>> Die bekommen ihre Arbeit zugeteilt. Klar haben die auch Manager> dafür, aber großartige Eigeninitiative wird dort wohl weder> erwartet noch gewünscht.
Das ist natürlich die beste Möglichkeit, schlechte Qualität zu
garantieren und die Entwickler zu frustrieren. Und wahrscheinlich auch
nicht ganz unbedeutend für die hohe Fluktuation dort.
Was LDS/STS by Tiny-Support angeht, so stammt der von 2014-10-21:
http://gcc.gnu.org/r216525
und dort:
1
/* AVRTC-579
2
if operand is symbol or constant expression with value > 0xbf
3
return false, otherwise true
4
This check is used to avoid lds/sts instruction with invalid
5
memory access range (valid range 0x40..0xbf). For io operand
6
range 0x0..0x3f, in/out instruction will be generated. */
M.a.W: LDS/STS wird nur verwendet wenn die Adresse zur Compilezeit
bekannt ist (d.h. const_int resp. bzw. weder symbol_ref noch const).
LDS/STS kann 128 Bytes adressieren (0x40-0xbf), so dass LDS/STS bequem
das ganze RAM (32 Bytes) adressieren kann. Der einzige Unterschied ist
.rotata: Soweit ich weiß mappt Tiny den Flash in den Adressbereich von
LD/ST, d.h. .rodata ist kein Teil von .data sondern muss im
Linker-Skript entsprechend allokiert werden und ist nur indirekt
zugreifbar wie Flash in den größeren Devices auch. Die einzigen
Symbole, die nicht per LDS/STS ansprechbar sind liegen also in .rodata.
Eine Erweiterung (z.B. Attribut) wäre erst dann notwendig, wenn LDS/STS
nicht mehr das komplette RAM überdeckt.
Mit der aktuellen Implementierung lässt sich LDS/STS also bestenfalls
dann verwenden, wenn das RAM explizite beschrieben wird:
1
#include<avr/io.h>
2
3
typedefstruct
4
{
5
intx;
6
charc;
7
}ram_t;
8
9
#define RAM (*(ram_t*) RAMSTART)
10
11
intget_x(void)
12
{
13
returnRAM.x;
14
}
1
get_x:
2
lds r24,64
3
lds r25,64+1
4
ret
Da allerdings die Kosten jenseits von Gut und Böse sind und selbst
einfachste Mikrooptimierungen fehlen, ist der erzeugte Code
unterirdisch:
1
intget_value(void)
2
{
3
returnRAM.x-RAM.c;
4
}
1
get_value:
2
ldi r30,lo8(64)
3
ldi r31,0
4
subi r30,lo8(-(2))
5
sbci r31,hi8(-(2))
6
ld r20,Z
7
subi r30,lo8((2))
8
sbci r31,hi8((2))
9
ld r24,Z
10
subi r30,lo8(-(1))
11
sbci r31,hi8(-(1))
12
ld r25,Z
13
subi r30,lo8((1))
14
sbci r31,hi8((1))
15
sub r24,r20
16
sbc r25,__zero_reg__
17
sbrc r20,7
18
inc r25
19
ret
Und ebenfalls übel ist dass LDD und STD entsorgt wurden, d.h. die
einzigen Adressierungsarten sind direkt, indirekt (ohne Offset),
post-increment und pre-decrement.
Die aktuelle Implementierung taugt nicht für viel mehr als für ein Proof
of Concept; ist ja auch ok für eine erste Unterstützng. Allerdings
scheint an einer Verbesserung der Implementierung bis dato kein Bedarf
zu bestehen...
Johann L. schrieb:> Oder hab ich das falsch verstanden?>> http://gcc.gnu.org/gcc-5/changes.html
Ah sorry, der war mir entgangen.
Allerdings hätte ich auch nicht gedacht, dass sie diese eher
unterirdisch schlechte Implementierung wirklich dahin schieben.
Andererseits: ihren Kunden haben sie sie ja schon vorher zugemutet
(in den Patches ihrer AVR-Toolchain).
Nein, die Fluktuation in Indien ist ein generelles Problem. Das geht
dort rein nur nach $$$. Großartiges persönliches Engagement ist da
eher eine ziemliche Ausnahme. Wenn die Firma in der Etage darüber
mehr zahlt, dann geht man eben nach einem Jahr eine Etage höher
arbeiten.
Erstaunlich! Dann lässt man die Reduced-Core AVR wohl doch nicht
sterben. Jetzt müssen nur noch die alten Bugs im AVR-GCC gefixed
werden...
Sieht nach einem automotive-Teil aus - 105°C und 125°C.
Also ich verstehe die negativen Äußerungen betreffend des Tiny 4/5/9/10
und 104ff nicht:
-> Wer kann mir denn sonst einen Controller zeigen, welcher mit 6
Beinchen auf 2,9x2,2mm diese Leistung erbringt?
Soll ich mir jetzt einen Industrial-Controller besorgen, um eine
Akku-Steuerung für Zuhause zu bauen?
Ich finde die kleinen Dinger super und hätte gerne mehr Auswahl < Tiny13
Andreas B. schrieb:> Sind die schon käuflich?
Mouser ist ein guter Früh-Indikator.
Da gibts momentan aber auch noch nix.
Etwas Atmel-Geduld brauchts noch ;-)
Falls jemand einen ATtiny104 ergattern konnte - unten die
AVRdude-Konfiguration, um ihn zu programmieren. TPI über USBASP
funktioniert problemlos.
avrdude.conf
Ich habe angefangen, einen seriellen Bootloader für den ATtiny104 zu
programmieren. Die aktuellen Files sind hier zu finden:
https://github.com/cpldcpu/Gluon
Achtung: Das ist keine fertige Software.
Nachdem ich mich durch etliche Probleme der Toolchain gekämpft habe
(Relocation bug, fehlende includes, etc...), funktioniert es in
Ansätzen. Aber es gibt noch viele Bugs und die Größe ist noch nicht
optimiert. Vielleicht hilft es jemandem bei eigenen Projekten.
Das Ganze liegt erst einmal auf Eis, da mich eine Sinnkrise ereilt hat:
Atmel scheint die ATtiny104 in einem Preisbereich zu positionieren
(>0.45 USD/pc), wo der Nutzen dieses Devices mehr als fraglich
erscheint.
- AVRTiny ist nur sehr begrenzt kompatibel zur AVR Code-Basis.
Zusätzlich ist auch die Peripherie deutlich verändert. Daher ist ohne
größere Änderungen keine Nachnutzung existierender Software möglich.
- Durch erhebliche Bugs in der Toolchain ist die Programmierung in C
sehr stressvoll und ineffizient.
- Bei der Entwicklung in Assembler müssen sich durch die begrenzte
Registeranzahl die AVR-Veteranen auch umgewöhnen.
- Es gibt dutzende bessere Alternativen mit besserer technischer
Performance und geringeren Kosten. z.B. STM8, etliche CM0 Varianten
(Nuvoton, STM, Cypress)
Der ATtiny10 hat durch die kleine Größe einen gewissen Charme. Leider
ist er auch erheblich teurer geworden. Beim ATtiny104 sehe ich im Moment
eher Nachteile.
Tim . schrieb:> Der ATtiny10 hat durch die kleine Größe einen gewissen Charme. Leider> ist er auch erheblich teurer geworden.
Ob da wohl Microchip keine Konkurrenz im eigenen Hause haben möchte?
Schließlich machte der ATtiny10 seinerzeit den Eindruck, als wäre er
sehr wohl genau dafür entwickelt worden, dem pinkompatiblen PIC
Konkurrenz zu sein …
Jörg W. schrieb:> Ob da wohl Microchip keine Konkurrenz im eigenen Hause haben möchte?
Der Preis des ATtiny10 ist schön länger recht hoch. Auf die wirklichen
Auswirkungen des Mergers müssen wir wohl noch ein paar Monate warten.
Könnte mir aber vorstellen, dass es bei den devices mit tiny-core
Auswirkungen gibt.
Thread beobachten
Seitenaufteilung abschalten