mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Neuer ATtiny104?


Autor: Tim    (cpldcpu)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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?

Autor: Moby AVR (moby-project) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Max D. (max_d)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ob das mit dem Besitzerwechsel trotzdem noch kommt sind wir ja mal 
neugierig......

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moby A. schrieb:

> Für dieses Jahr waren neue Tinys angekündigt.

Stimmt! Und das hoffentlich nicht nur am unteren Ende.

Nun ist das Jahr fast herum...

Autor: Th. Baum (thbaum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

: Bearbeitet durch User
Autor: Ulrich F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso?
Der Assemblerfraktion wirds reichen....

Autor: Th. Baum (thbaum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Moby AVR (moby-project) Benutzerseite
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Ulrich F. schrieb:
> Wieso?
> Der Assemblerfraktion wirds reichen....

Genau so schauts aus.

Autor: Th. Baum (thbaum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die 32 Bytes der Winzlinge dürften hauptsächlich für den Stack da sein.

Autor: xXx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lohnt sich der Verzicht auf Speicher ueberhaupt in der Fertigung oder 
ist das nur altmodische Spinnerei?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Konrad S. (maybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/MySilico...

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

: Bearbeitet durch User
Autor: Icke ®. (49636b65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Bei verschachtelten Subroutinen ist ganz schnell Ende.

So viele Unterprogramme schachtelst du mit 1 KiB Flash nicht. :)

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Icke ®. (49636b65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> So viele Unterprogramme schachtelst du mit 1 KiB Flash nicht.

In der Tat, ich würde gleich einen größeren µC verwenden. =8P

Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Icke ®. (49636b65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Privat sind diese Teile ziemlich witzlos.

Ja, Bastler sind sicher nicht die Zielgruppe.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :)

Autor: Konrad S. (maybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Moby (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß!

Autor: Moby (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Lothar (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Moby AVR (moby-project) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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€ ...

Autor: Lothar (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 :-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Lothar (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Moby AVR (moby-project) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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?

Autor: Stefan Helmert (Firma: dm2sh) (stefan_helmert)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Moby A. schrieb:
> Was machen "Moderne Architekturen" heute sooo viel besser?

Java-Unterstützung

Autor: Lothar (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Stefan H. schrieb:
> Java-Unterstützung

ARM hat Java-Unterstützung in Hardware schon lange wieder aufgegeben

https://en.wikipedia.org/wiki/Jazelle

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Stefan H. schrieb:
> Java-Unterstützung

Bei einem Controller mit 32 Bytes RAM. Klar.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
volatile uint8_t i=0;

int main(void)
{
    while (1) 
    {
    i++;
    }
} 

output:
int main(void)
{
    while (1) 
    {
    i++;
  38:  e0 e4         ldi  r30, 0x40  ; 64
  3a:  f0 e0         ldi  r31, 0x00  ; 0
  3c:  40 81         ld  r20, Z
  3e:  4f 5f         subi  r20, 0xFF  ; 255
  40:  40 83         st  Z, r20
    }
  42:  fc


: Bearbeitet durch User
Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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-wi...


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

: Bearbeitet durch User
Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Winfried J. schrieb:
> Da ist dann aber auch schon ein Klimzug includiert ;)

Hat ja keiner gesagt, dass es einfach ist :)

Autor: Moby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tim  . schrieb:
> Also der ATtiny10 kann schon etwas mehr:

Man kriegt auch ein Dutzend Leute in eine Telefonzelle. ;-)

Autor: Moby (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
A. K. schrieb:
> Man kriegt auch ein Dutzend Leute in eine Telefonzelle. ;-)

Mit Asm haben die Leute sogar noch ausreichend Platz drin ;-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moby schrieb:
> Mit Asm haben die Leute sogar noch ausreichend Platz drin ;-)

Ist aber auch keine Lösung. Gibt davon immer weniger:
http://de.statista.com/statistik/daten/studie/1315...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Moby (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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 ???

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Moby (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist jetzt eigentlich mit den angekündigten neuen ATtinies? In diesem 
Jahr scheint es ja nichts mehr zu werden.

Autor: Moby AVR (moby-project) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Moby AVR (moby-project) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> *arrrhg*

... das tut der Compiler-Effizienz wieder mal nicht gut ;-(

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Carl Drexler (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Carl Drexler (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:
> Du verstehst sicher warum.

Man muss ja nicht auf jeden Trollversuch anspringen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und warum wird der überhaupt debondet?  Das braucht doch nur Platz und 
ist teuer.  Warum nicht einfach BGA wie der Dimple?

http://www.golem.de/news/internet-der-dinge-freesc...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?
j@uriah 76% avr-as -mmcu=attiny25 -c foo.s
j@uriah 77% avr-objdump -d a.out

a.out:     file format elf32-avr


Disassembly of section .text:

00000000 <.text>:
   0:   00 91 40 00     lds     r16, 0x0040
j@uriah 78% avr-as -mmcu=attiny10 -c foo.s
j@uriah 79% avr-objdump -d a.out

a.out:     file format elf32-avr


Disassembly of section .text:

00000000 <.text>:
   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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
 
/* AVRTC-579
   if operand is symbol or constant expression with value > 0xbf
   return false, otherwise true
   This check is used to avoid lds/sts instruction with invalid
   memory access range (valid range 0x40..0xbf). For io operand
   range 0x0..0x3f, in/out instruction will be generated.  */

bool tiny_valid_direct_memory_access_range(rtx op, enum machine_mode mode)
{
  rtx x;

  if (!AVR_TINY)
    return true;

  x = XEXP(op,0);

  if (MEM_P(op) && x && (GET_CODE(x) == SYMBOL_REF))
    return false;

  if (MEM_P(op) && x && (CONSTANT_ADDRESS_P (x)) &&
     !(IN_RANGE (INTVAL (x), 0, 0xC0 - GET_MODE_SIZE (mode))))
    return false;

  return true;
}
 
Das ist offenbar von Atmel (bzw. Embecosm) und in der aktuellen Version 
i.W. genauso drin:
 
  if (AVR_TINY
      && CONSTANT_ADDRESS_P (x))
    {
      /* avrtiny's load / store instructions only cover addresses 0..0xbf:
         IN / OUT range is 0..0x3f and LDS / STS can access 0x40..0xbf.  */

      ok = (CONST_INT_P (x)
            && IN_RANGE (INTVAL (x), 0, 0xc0 - GET_MODE_SIZE (mode)));
    }
 
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:
#include <avr/io.h>

typedef struct
{
    int x;
    char c;
} ram_t;

#define RAM  (*(ram_t*) RAMSTART)

int get_x (void)
{
    return RAM.x;
}
 
get_x:
  lds r24,64
  lds r25,64+1
  ret

Da allerdings die Kosten jenseits von Gut und Böse sind und selbst 
einfachste Mikrooptimierungen fehlen, ist der erzeugte Code 
unterirdisch:
int get_value (void)
{
    return RAM.x - RAM.c;
}
  
get_value:
  ldi r30,lo8(64)
  ldi r31,0
  subi r30,lo8(-(2))
  sbci r31,hi8(-(2))
  ld r20,Z
  subi r30,lo8((2))
  sbci r31,hi8((2))
  ld r24,Z
  subi r30,lo8(-(1))
  sbci r31,hi8(-(1))
  ld r25,Z
  subi r30,lo8((1))
  sbci r31,hi8((1))
  sub r24,r20
  sbc r25,__zero_reg__
  sbrc r20,7
  inc r25
  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...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Th. Baum (thbaum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Tim  . schrieb:
> Jetzt müssen nur noch die alten Bugs im AVR-GCC gefixed werden...

Na frisch ans Werk! Die Quellen liegen offen vor dir :-)

Autor: GuterGast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Moby AVR (moby-project) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, da sind die neuen Kandidaten:

http://www.atmel.com/Images/Atmel-42505-8-bit-AVR-...

Zu den Vorteilen ihres Einsatzes wie auch der nach wie vor gegebenen 
Daseinsberechtigung der 8-Bitter:

http://www.atmel.com/Images/Atmel-45178-Small-But-...

So ein 102er 8-Pin Winzling hat doch jetzt tatsächlich UART, 5 Kanal ADC 
und 3 (!) eingebaute Spannungsreferenzen bei deutlich verbesserter 
Taktstabilität des internen 8-Mhz Takts = meist keine externen Bauteile 
mehr nötig. Damit in dieser Baugröße für noch mehr Einsatzfälle 
einsetzbar. Genial.

: Bearbeitet durch User
Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Haben will! (tiny102)
Sind die schon käuflich?

Gruß
Andreas

Autor: Moby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: FuerBastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer es so gar nicht abwarten kann: Auf der Embedded World werden die 
ATTINY104-XNANO Boards verteilt. Muss man nur in der Nähe von Nürnberg 
sein.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls jemand einen ATtiny104 ergattern konnte - unten die 
AVRdude-Konfiguration, um ihn zu programmieren. TPI über USBASP 
funktioniert problemlos.

avrdude.conf
#------------------------------------------------------------
# ATtiny104
#------------------------------------------------------------

part parent ".reduced_core_tiny"
    id    = "t104";
    desc  = "ATtiny104";
    signature = 0x1e 0x90 0x0B;

    memory "flash"
        size    = 1024;
        offset    = 0x4000;
        page_size = 16;
        blocksize = 128;
    ;
;

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte mach einen Patchtracker bei AVRDUDE dafür auf (oder Bug tracker,
mir egal).

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Done. ATtiny841 gibts gleich dazu - das fehlte auch noch.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, danke.  Vor dem nächsten Release werde ich auf jeden Fall nochmal
einen Sweep über die Bugs und Patches machen.

Autor: Tim    (cpldcpu)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 …

Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Holger L. (max5v)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer es noch nicht gelesen hat, das Datenblatt revision B:
http://www.atmel.com/devices/ATTINY104.aspx

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Übrigens ist der Tiny104 jetzt frei verkäuflich:

http://www.mouser.de/Search/Refine.aspx?Keyword=attiny104

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.