Neue 8-Bit Tinys vorgestellt: 417/814/816/817

Nett! Scheint so eine Art aufgebohrter ATtiny841 zu sein. Jetzt mit 20 
MHz und I²C Master.

Interessant ist auch, dass gleichzeitig das Package kleiner wurde 
(VQFN). Scheint ein Shrink zu sein. Bleibt zu hoffen, dass damit die 
Preise sinken, und noch weitere Devices nachfolgen werden.

...vor allem wäre eine Version mit >8kb nett. Wie soll man sonst die 
ganzen Features nutzen?

Edit: Das gleiche Package gibt es doch schon für ATtiny841. Heisst dort 
nur anders. Ist also doch nicht kleiner geworden.

Ein 12 bit Timer...das ist ja mal was ganz was neues...

Ne, mal Spass beiseite. Die Tinys schauen nett aus

Oops. Da hat sich ja fast alles verändert. Programmierung/Debugging 
inclusive. Geht jetzt alles über einen Pin (sieht aus der Ferne ein 
bißchen wie SWIM bei den STM8 aus).

Allein letzteres dürfte die Hemmschwelle für Hobbyisten gehörig 
steigern, weil wieder ein neuer Programmier/Debug-Adapter benötigt wird.

Axel S. schrieb:
> Allein letzteres dürfte die Hemmschwelle für Hobbyisten gehörig
> steigern, weil wieder ein neuer Programmier/Debug-Adapter benötigt wird.

Nicht unbedingt. Ich mein (hab nicht nachgeschaut) das AVRISP MKII kann 
PDI, könnte sein dass dafür nur ein Firmwareupdate nötig ist.

Im "Instruction Set Summary" werden auch CALL und JMP aufgeführt obwohl 
diese Devices nur 4 bzw. 8 KiB Programmspeicher haben, d.h. RCALL und 
RJMP genügen würden.  Aus gcc-Sicht sind die Dinger elso wie ein z.B. 
ein ATmega16 (-mmcu=avr5) zu behandeln?

Zudem gibt es ein Feature, das ich bisher nur bei den Reduced Tinys mit 
16 GPRs gesehen habe:

> Entire Flash accessible with all LD/ST instructions.

Bei den RTiny funktioniert progmem so, dass

1) Daten werden nach .progmem.data* gelegt.

2) Auf die Symboladresse wird 0x4000 addiert (bei den o.g. Teilen wäre
   der Offset 0x8000).

Das ist dann wesentlich einfacher, weil kein pgm_read verwendet werden 
muss, um aus dem Flash zu lesen.  Zudem braucht es keine Qualifier wie 
__flash, um ohne pgm_read aus dem Flash zu lesen, was insbesondere für 
C++ Liebhaber angenehm ist.

Allerdings müsste dann erst ein neues Variablen-Attribut erfunden 
werden, weil progmem ja bereits belegt ist...

M. K. schrieb:
> Axel S. schrieb:
>> Allein letzteres dürfte die Hemmschwelle für Hobbyisten gehörig
>> steigern, weil wieder ein neuer Programmier/Debug-Adapter benötigt wird.
>
> Nicht unbedingt. Ich mein (hab nicht nachgeschaut) das AVRISP MKII kann
> PDI, könnte sein dass dafür nur ein Firmwareupdate nötig ist.

Das ist ja der Punkt. Diese neuen Tinies verwenden kein PDI. Bisher 
verwendeten die "normalen" Tinies ISP. Die ganz kleinen TPI. Die xMega 
PDI. Diese neuen Tinies jetzt UPDI.

Gut möglich, daß Atmel Firmware-Updates für bestehende Adapter heraus 
bringt. Das nutzt nur all jenen, die bisher auf usbasp oder sonst einen 
Eigenbau gesetzt haben, recht wenig. Und ich glaube auch eher nicht, daß 
Atmel Uraltgeräte wie den Dragon oder das AVRISP unterstützen wird.

Johann L. schrieb:
>> Entire Flash accessible with all LD/ST instructions.

Das hätten sie mal etwas früher machen sollen. Nicht mal den Xmegas 
hatten sie diese nützliche Errungenschaft gegönnt.

Der 814 sieht für mich interessant aus. Ab wann gibt es Preise und 
Verfügbarkeitsangaben?

René H. schrieb:
> Der Atmel-ICE kann UPDI. Ich nehme mal an, dass alle neuen "Programmer"
> das können.

In der Serie ist das schnuppe. Für Bastler ist die Hürde allerdings 
etwas hoch, dafür eigens einen neuen teuren Programmer/Debugger zu 
benötigen.

René H. schrieb:
> Der Atmel-ICE kann UPDI. Ich nehme mal an, dass alle neuen "Programmer"
> das können.


Da steht alles drin:

http://www.atmel.com/Images/Atmel-42781-Getting-Started-With-ATtiny417-814-816-817_ApplicationNote_AVR42781.pdf

A. K. schrieb:
>>> Entire Flash accessible with all LD/ST instructions.
>
> Das hätten sie mal etwas früher machen sollen. Nicht mal den Xmegas
> hatten sie diese nützliche Errungenschaft gegönnt.

Naja, das kann man ja am Ende nur machen, wenn Flash + RAM zusammen
nie mehr als die 64 KiB Adressraum umfassen, die man mit LD erreicht.

Damit fällt sowas für die Xmegas eigentlich von vornherein aus.

Johann L. schrieb:
> Allerdings müsste dann erst ein neues Variablen-Attribut erfunden
> werden, weil progmem ja bereits belegt ist

Man könnte ja progmem weiter benutzen und die entsprechenden
Funktionen in der Bibliothek passend implementieren.  Damit wär'
man dann sogar sourcecodekompatibel.

Bliebe die Frage, ob Atm^H^H^HMicrochip ihre Jungs in Indien damit
betraut, sich um die avr-libc-Anpassungen (und GCC-Anpassungen?)
dafür zu kümmern.  Bislang sehe ich da noch keine Anzeichen.
Vermutlich werden sie IAR rechtzeitig ins Boot genommen haben.

c-hater schrieb:
> Auch das Eventsystem und die GlueLogic haben sicher das Potential,

Sooo, hier mal ein vorläufiges Datenblatt. Man beachte den Domainnamen. 
;)
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42721B-ATtiny-417-814-816-817-Datasheet_Complete.pdf

Die Kleber-Logik hat Microchip schon in einigen PICs im Einsatz.

Ich bin mal auf die Preise gespannt. Daraus ergibt sich, ob sich 
projektweise ein Rückschritt vom STM32F0xx rechnet.

Nase schrieb:
> Ich setze sehr gerne AVRs ein (z.B. verglichen mit ARM/STM), weil die
> AVRs m.M.n. so eine wunderschöne aufgeräumte Hardware an Board haben.
> Alles ist irgendwie durchdacht, ...

Mmmh, ich dachte immer "wer Atmel kennt, nimmt was anderes"?

Ein Programm, das mehr als ein ein paar hundert Zeilen Maschinencode 
benötigt bzw. in C geschrieben wird, ist heutzutage in einem ARM besser 
aufgehoben.

Ich bin Ende der 90er von PIC auf AVR umgestiegen.
Und ich war froh, als NXP und ST vernünftige ARM MCUs auf den Markt 
gebracht haben.

In den Jahren hat Atmel meine Kunden und mich viel Geld mit 
Datenblattschlampereien gekostet. Ich denke da vor allem an die 
AT91RM9200 bzw. AVR32AP. Aber auch die AVRs hatten (haben?) Ihre Tücken 
(EMV...).
Über die AT89er wollen wir garnicht reden.

Jörg W. schrieb:
> Naja, das kann man ja am Ende nur machen, wenn Flash + RAM zusammen
> nie mehr als die 64 KiB Adressraum umfassen, die man mit LD erreicht.

Abschaltbar (bei externem RAM) die ersten 32KB vom Flash auf die zweiten 
32KB vom Datenadressraum zu mappen würde meist ausreichen. Könnten die 
ganzen Strings drin landen, ohne dass man sich eigens drum kümmern muss.

Jörg W. schrieb:
> A. K. schrieb:
>>>> Entire Flash accessible with all LD/ST instructions.
>
> Johann L. schrieb:
>> Allerdings müsste dann erst ein neues Variablen-Attribut erfunden
>> werden, weil progmem ja bereits belegt ist
>
> Man könnte ja progmem weiter benutzen und die entsprechenden
> Funktionen in der Bibliothek passend implementieren.  Damit wär'
> man dann sogar sourcecodekompatibel.

An der AVR-LibC würd ich da nix ändern.  Auf den RTiny funktioniert 
progmem ab avr-gcc v7 folgendermaßen:

1

extern const char __attribute__((__progmem__)) str[];

2

3

const char* pstr (int i)

4

{

5

    return &str[i];

6

}

7

8

char get (int i)

9

{

10

    return str[i];

11

}

Übersetzt mit -Os -mmcu=avrtiny

1

pstr:

2

  subi r24,lo8(-(str+16384))

3

  sbci r25,hi8(-(str+16384))

4

  ret

5

6

get:

7

  subi r24,lo8(-(str+16384))

8

  sbci r25,hi8(-(str+16384))

9

  mov r30,r24

10

  mov r31,r25

11

  ld r24,Z

12

  ret

Die Behandlung verschiebt sich also vom Zugriff zur Adressbestimmung.

Um Bestandscode weiterhin unverändert verwenden zu können, würd ich an 
progmem / pgm_read exakt garnix verändern; selbst wenn es durchgehend 
und konsistent geändert werden würde werden viele Anwender davon nix 
mitbekommen und unbegeistert[tm] sein.

Zudem genügt es beim "normalen" progmem, Definitionen zu attributieren, 
während im obigen Beispiel dies (auch) für Deklarationen geschehen muss. 
Ein Attribut am Prototyp ist ausreichend.

Für RTiny war die Implementierung naheliegend, und für die o.g. Devices 
ist es auch wesentlich einfacher als z.B. __flash.

Am besten wäre wohl ein Attribute mit Argument wie z.B. offset(0x8000) 
weil auch andere Speicher wie EEPROM und Fuses in des SRAM-Adressbereich 
abgebildet werden.  Aber alle Adressbereiche im Compiler zu handhaben 
wäre schon umständlich, weil ja alles durch die specs-Files geschleift 
werden muss und die Information auch erst mal da sein muß.

Lothar schrieb:
> Wäre ja mal ein Grund für diese "Bastler" sich 8-Bit Alternativen
> anzusehen, für die es keinen Programmer braucht, und das Debugging schon
> ewig über SWD geht:

Oder auch Nicht-8-Bit Alternativen.

Marcus H. schrieb:
> Über die AT89er wollen wir garnicht reden.

Ja schade drum, die waren so schön problemlos, störsicher und 
zuverlässig.
Ich hätte sie gerne noch weiter eingesetzt, aber die Fab für den 
AT89C51RE2 ist ja pleite gegangen.

Lothar schrieb:
> laut EMITT

Ich finde darunter nur eine türkische Tourismusmesse.  Ob man von
solch einer eine sinnvolle Marktanalyse für Micrcontroller erwarten
kann? :-)

Bei ARM wiederum solltest du genau gucken, was alles in solch eine
Analyse reingezählt wird.  Wenn du jetzt alle Smartphones mit einem
Cortex-A mit AVRs in einen Topf wirfst … naja, wie war das gleich
mit der Statistik, die man nicht selbst gefälscht hat?

Lothar schrieb:
>> Wenn du jetzt alle Smartphones mit einem Cortex-A mit AVRs
>> in einen Topf wirfst
>
> Cortex-A zählen dabei nicht als MCU

Die nicht. Aber die hardwarenahen Cortex-M, -R und älteren ARMs in 
diesen Smartphones schon eher. Im Mobilfunk, WLAN, GPS, Bluetooth, ...

A. K. schrieb:
> In der Serie ist das schnuppe. Für Bastler ist die Hürde allerdings
> etwas hoch, dafür eigens einen neuen teuren Programmer/Debugger zu
> benötigen.

Ich würde da erstmal abwarten statt Angst zu haben, einen neuen Adapter 
kaufen zu müssen. Die Schnittstellen sind ja idR gut beschrieben bei 
Atmel, ich bin mir sicher auch die Bastler-Programmieradapter bzgl. UPDI 
nachziehen werden.

Da sind ja viele Neuerungen eingeflossen.
Beim durchscrollen des Datenblatts fällt auch viel positiv auf.
Bis man beim programming landet -> kein ISP -> uninteressant.
Kauf mir doch jetz kein Programmer nur für die kleine Serie oder kommen 
auch bald aufgefrischte atmegas raus?

Wie hier schon einer sagte: das Teil sieht aus wie nen CortexM0 mit 
etwas atxmega Würzung.

Hm, dass ihr so am ISP hängt?? Ich finde das eher lästig, da gibts doch 
deutlich bessere Alternativen. Allein, dass nicht alle Optionen 
verfügbar sind (reset-pin), man oft doch irgendwelche 
Hardwarevorkehrungen treffen muss, weil die ISP-pins in der Schaltung 
anderweitig verwendet werden, weil auf Kleinstplatinen nicht immer Platz 
für zusätzliche 4 Kontaktpins samt routing-Platz gibt? Könnte aus meiner 
Sicht gerne aufgeräumt werden.

Ich habe die AVRs immer gerne eingesetzt. Reichen in der Leistung in 
vielen Fällen völlig aus. Insgesamt gefällt mir die Struktur
Strombedarf (zu hoch) war schon manchmal ein Thema, mit den pico-power 
Typen aber ok.
Die grössern Atmels (AVR32 oder XMega) habe ich eh nie angefasst
Inzwischen sind sie (gemessen an der Leistungsfähigkeit und in 
Produktionsstückzahlen) einfach auch zu teuer geworden.

UPDI scheint prinzipiell ein recht einfaches Format zu sein. Auf den 
ersten Blick sollten sich die Devices über eine einfache USB2TTL-Bridge 
programmieren lassen?

Allerdings sieht es so aus, als wenn man per default den 12V-Modus 
benötigt, um in den UPDI-Mode zu kommen? Das entsprechende Fuse-Bit für 
den low-voltage mode scheint per default gelöscht zu sein?

Das ist Schade.

Der ISP ist eine Infrastruktur, die man schon hat und gerne weiterhin 
nutzen können möchte, egal ob in Fertigung oder Bastelkeller.

Warum nicht beides anbieten und ISP per Fuse abschaltbar machen? Dann 
sickert die neue Infrastruktur nämlich durch und in der übernächsten 
Chipgeneration kräht keiner mehr.

H.Joachim S. schrieb:
> Hm, dass ihr so am ISP hängt?? Ich finde das eher lästig, da gibts doch
> deutlich bessere Alternativen.

Das ist nicht der Punkt.

Sondern daß ISP bekannt ist. Daß die Hardware existiert und nachweisbar 
funktioniert. Dito die zugehörige Software. Und es ist ja auch nicht so, 
daß es keine Alternativen von Atmel gäbe. PDI, TPI, dW ... such dir was 
aus. Jetzt ein weiteres, inkompatibles Verfahren zu verwenden (und zwar 
nicht etwa optional sondern ausschließlich) wird schon ein paar Leute 
abschrecken. Wenn ich sowieso auf neue Hardware-Tools und neue Toolchain 
wechseln soll, dann doch gleich zu Cortex-M und SWD. Kundenbindung sieht 
anders aus.

Mw E. schrieb:
> Bis man beim programming landet -> kein ISP -> uninteressant.

Versteh ich gar nicht. PDI ist mir idR viel lieber als ISP weil man 
dafür nur zwei Pins braucht und damit auch noch gar debuggen kann.

S. R. schrieb:
> Der ISP ist eine Infrastruktur, die man schon hat und gerne weiterhin
> nutzen können möchte, egal ob in Fertigung oder Bastelkeller.

Der AVRISP MKII kann PDI und mir erscheint UPDI sehr ähnlich zu sein, 
ich denke dass es da ein Update geben wird.

M. K. schrieb:
> Versteh ich gar nicht. PDI ist mir idR viel lieber als ISP weil man
> dafür nur zwei Pins braucht und damit auch noch gar debuggen kann.

Lesen -> Verstehen -> Posten!
Es ist UPDI, das ist inkompatibel zu PDI.
Atmel hat sich was völlig neues ausgedacht zum proggen dieser Tinys.
Wenn es PDI wäre, dann wärs ja kein Problem.

H.Joachim S. schrieb:
> Hm, dass ihr so am ISP hängt?

Naja, wenn man zuvor immer noch die billigsten Programmierer für
dreifuffzich aus Chinaland benutzt hat, dann muss man jetzt natürlich
erstmal warten, bis im Reich der Mitte neue Programmierer für
dreiachtzig entstehen, die auch das neue Protokoll können.

Zumindest das Atmel-ICE werden sie garantiert per Firmwareupdate
aufpolieren, das neue Protokoll zu verstehen.  Beim AVRISPmkII
könnte ich mir das auch vorstellen, wenngleich Atmel das schon seit
geraumer Zeit gern langfristig loswerden möchte, weil die USB-ICs
abgekündigt sind, die da drin verbaut werden, sodass man die
Produktion der Geräte über kurz oder lang einstellen müssen wird.
Nicht umsonst war schon der Einstiegspreis eine Atmel-ICE in der
einfacheren Version (in der es auch für ISP geeignet ist) in der
gleichen Größenordnung wie der Preis des AVRISPmkII.

Ich finde das jetzt auch nicht so dramatisch, wird aber für den 
finanzschwachen Nachwuchs vielleicht ein konkreteres Problem.
ISP hat ja auch Nachteile bei den wenigen Pins.

Habt ihr zur Verfügbarkeit schon was gesagt? Man muss ja hoffen, dass 
eine kürzere Errata entstehen wird als zuletzt häufig.

Mw E. schrieb:
> Lesen -> Verstehen -> Posten!
> Es ist UPDI, das ist inkompatibel zu PDI.

Das empfehle ich dir auch. Ich hab ja nicht geschrieben, dass es 
kompatibel ist. Ich schrieb nur, dass es ähnlich ist und weiter oben 
schrieb ich, dass ich mir vorstellen kann, dass entsprechende Programmer 
ein Firmwareupdate bekommen werden. ;)

Jörg W. schrieb:
> Zumindest das Atmel-ICE werden sie garantiert per Firmwareupdate
> aufpolieren, das neue Protokoll zu verstehen.  Beim AVRISPmkII
> könnte ich mir das auch vorstellen

Was ich hierbei gar nicht verstehen kann: Ich hab das Atmel JTAGICE 
MKIII und das AVRISP MKII aber nur letzters kann TPI. Daher bin ich mal 
gespannt welche Programmer für UPDI ein Update bekommen werden...

Jörg W. schrieb:
> H.Joachim S. schrieb:
>> Hm, dass ihr so am ISP hängt?
>
> Naja, wenn man zuvor immer noch die billigsten Programmierer für
> dreifuffzich aus Chinaland benutzt hat, dann muss man jetzt natürlich
> erstmal warten, bis im Reich der Mitte neue Programmierer für
> dreiachtzig entstehen, die auch das neue Protokoll können.

Das ist noch nicht mal die Hälfte des Problems.

Ein ebenso wichtiger Teil ist die Software auf der Host-Seite. Du 
arbeitest ja selber an avrdude und simulavr. Die können mittlerweile 
(mal mehr, mal weniger gut) mit JTAG, ISP, PDI, dW programmieren und 
debuggen. Bevor da UPDI reingehackt ist, fließt noch eine Menge Wasser 
die Elbe runter. Vielleicht kommt das auch gar nie.

Aber eher friert die Hölle zu, als daß ich meine Entwicklungsumgebung 
auf Windows umstelle (um das Atmel-Studio verwenden zu können). Und nur 
um das erwähnt zu haben: für Cortex-M gibt es eine komplette und gut 
funktionierende Toolchain für Linux.

M. K. schrieb:
> Ich hab das Atmel JTAGICE MKIII

Das Ding hatte für meine Begriffe ein bedauernswert kurzes Leben.

Die einzig gute Nachricht dafür: du kannst dir das PCB Assembly
für ein Atmel-ICE kaufen, das ist recht preiswert (billiger als
ein Drachen), das passt 1:1 in das Gehäuse des JTAGICE3.

Falls UPDI ähnlich zu PDI ist, dann könnte es natürlich gut sein,
dass sie auch das JTAGICE3 aufpeppen.

Axel S. schrieb:

> Bevor da UPDI reingehackt ist, fließt noch eine Menge Wasser
> die Elbe runter. Vielleicht kommt das auch gar nie.

Hängt natürlich auch davon ab, wie viel Aufwand es wird, d. h. wie
sehr es sich von den anderen Protokollen unterscheidet.

Interessanterweise hat mich diesmal niemand vorher angesprochen.

> Und nur
> um das erwähnt zu haben: für Cortex-M gibt es eine komplette und gut
> funktionierende Toolchain für Linux.

Die auch für die Atmel-ARMs mit dem Atmel-ICE problemlos funktioniert. 
;)

Lothar schrieb:
> ISP = In-System-Programming bezeichnet üblicherweise

Je nachdem, wer die „Üblichkeit“ so festlegt.

Bei Atmel hieß das, was PIC ICP nennt, eben von Anfang an ISP.  Da
sie die ersten waren, die sowas überhaupt angeboten haben, kannst du
nun schlecht mit „Üblichkeiten“ anderer Hersteller argumentieren.

Lieber Lothar, du faselst. Ich kann nichts dafür, dass Atmel sich 
entschlossen hat, dieses Verfahren "ISP" und nicht "SPI" zu nennen, und 
leider hatte bisher keiner meiner PCs dafür einen Anschluss. Ein AVR 
kann (ohne Bootloader oder externen Programmer) nicht per RS232 
programmiert werden.

neuer PIC Freund schrieb im Beitrag #4789224:
> Die 12V am Reset hört sich ganz nach microchip an.

Hatten AVRs auch früher schon, high voltage programming.

> Da gebe ich dem
> Pickit eine größere Chance als den Fischl-Anhängern.

Es gibt zwar die Möglichkeit, per Fuse das UPDI zu aktivieren,
aber im Auslieferungszustand scheint man in der Tat 12 V zu
benötigen.

Offensichtlich hat man beim Design des Atmel-ICE schon sowas
vorgesehen, denn das ist unter „Tools“ gelistet.  (Der alte STK600
auch, aber dass der +12 V kann, ist klar.)

Das dürfte allerdings die Chancen, dass man ein AVRISPmkII per
Softwareupdate dazu befähigen kann, mit diesen Teilen umzugehen,
zunichte machen.  Die „Fischl-Anhänger“ werden da wohl schon eher
in der Lage sein, dem USBasp noch eine Ladungspumpe dranzuhängen …

neuer PIC Freund schrieb im Beitrag #4789315:
> Dies mit dem Faktum, dass ich nur eine Spule sehe (die für den
> Boostconverter fehlt),

Dafür reicht auch 'ne Ladungspumpe.

> machen meine Hoffnung zunichte, dass der ICE 12V
> kann.

Zumindest ist er unter „Tools“ gelistet.

neuer PIC Freund schrieb im Beitrag #4789224:
> Die 12V am Reset hört sich ganz nach microchip an. Da gebe ich dem
> Pickit eine größere Chance als den Fischl-Anhängern.

Der Gedanke kam mir auch schon. Wenn Microchip schon (vermutlich?) seine 
Finger da drin hat - warum machen sie das Ganze nicht einfach kompatibel 
zu den PICs und dem PICkit?

Andererseits spricht genau das dafür, daß Microchip wohl doch keine 
Aktie an UPDI hat, sondern daß das allein auf Atmels Mist gewachsen ist.

Was die Sache nicht verständlicher macht. Angesichts der Marktlage 
sollte jedem Hersteller klar sein, daß es einfacher ist, existierende 
Kunden bei der Stange zu halten, als Kunden von anderen Plattformen zu 
gewinnen. Zumal die neuen Tinies ja immer noch den 8-Bit AVR Kern 
verwenden und folglich die Clientel der ATtiny/mega/xMega Anwender 
ansprechen sollen. Der Wechsel zu einem komplett neuen Programmier / 
Debug-Interface ist da schon einigermaßen disruptiv.

Wenn man hingegen die neuen ATtinies kompatibel zum PICkit gemacht 
hätte, dann wären wohl durchaus ein paar PICler bereit gewesen, sich 
diese Plattform wenigstens mal anzusehen. Zumal man die kleinen PICs ja 
ohnehin nur in C programmieren will. Die Architekturunterschiede 
bezüglich des CPU-Kerns wären eher kein Hinderungsgrund gewesen ...

neuer PIC Freund schrieb im Beitrag #4789743:
> Damit ist mein ICE als Dominator raus. Entweder komm ich gar nicht ran,
> oder wenn es mir nach einem Resetpin schreit, werden die Tinies OTP. Das
> ist eher Kundenabschreckung als Kundenbindung.

Microchip lässt grüssen. UPDI erinnert etwas an die Programmiertechnik 
von deren älteren 8-Bittern. Es hat auch wie dort den hässlichen 
Nebeneffekt, dass andere Bausteine, die ebenfalls an der Reset-Leitung 
hängen, mit 12V zurecht kommen müssen. Man kann zwar den Pin alternativ 
fest als UPDI konfigurieren, dann braucht es keine 12V, aber zur Welt 
kommt er so nicht, was ein Henne-Ei-Problem aufwirft und Reset 
deaktiviert.

Per Firmware nachrüstbar ist das dank der 12V-Technik allenfalls für 
Programmer und ICEs, die bisher HVP konnten. Und auch nur dann, wenn 
deren 12V-Pinlogik auch bidirektionale Datenkommunikation darüber 
erlaubt, was bisher m.W. nie nötig war.

R.B. schrieb:
> Das ist der Normalfall und das ist auch der Auslieferungszustand.

Das würde auch mir logisch erscheinen. Das Datenblatt gibt aber an, dass 
die entsprechenden Konfigurationsbits einen Default-Zuständ von 
0x00=GPIO mode haben.

Übersehe ich etwas?

R.B. schrieb:
> Das ist der Normalfall und das ist auch der Auslieferungszustand.

Wo steht eigentlich, was der Auslieferungszustand der Fuses ist?

Axel S. schrieb:
> Wenn Microchip schon (vermutlich?) seine Finger da drin hat

So eine IC-Entwicklung braucht mindestens zwei Jahre.

Du kannst daher völlig vergessen, dass da irgendwas auch nur ansatzweise
auf Microchip ausgerichtet worden wäre.  Damals hätte bei Atmel noch
nicht einmal jemand die Idee gehabt, dass der Laden überhaupt verkauft
werden soll (gerade nachgesehen, der "Dialog kauft Atmel"-Thread ist
vom September 2015), geschweige denn, dass es ausgerechnet Konkurrent
Microchip werden würde.

neuer PIC Freund schrieb im Beitrag #4789743:
> Steht ja geschrieben im UserGuide-10/2016:

Dann erscheint mir diese Variante von UPDI allerdings reichlich
kurzsichtig.

R.B. schrieb:
> Via mEDBG Tool (Ev.Kit) nachgeschaut steht die Fuse "SYSCFG0.RSTPINCFG"
> initial auf UPDI mode. Alles andere wäre unlogisch, die Angabe im
> aktuellen Preliminary Datenblatt sollte man nicht zu ernst nehmen.

Hast Du Dir dabei ein "frisches" Device angeschaut, oder das auf dem 
Xplained-board?

Tim  . schrieb:
> Das würde auch mir logisch erscheinen. Das Datenblatt gibt aber an, dass
> die entsprechenden Konfigurationsbits einen Default-Zuständ von
> 0x00=GPIO mode haben.

Dachte ich auch erst. Allerdings steht dort auch für OSCCFG.FREQSEL 0-0 
drin, was für diese Bits als "Reserved" dokumentiert ist.

Kaffeesatzlesen aus der Formulierung "Enabling of the 1-wire interface, 
by disabling the reset functionality, is either done by 12V programming 
or by fusing the RESET pin to UPDI by setting the RESET Pin 
Configuration (RSTPINCFG) bits in FUSE.SYSCFG0." suggeriert, dass der 
Auslieferungszustand "Reset" sei.

Damit haben wir nun Indikatoren für alle 3 Varianten zu Wahl: Aus der 
SYSCFG0 Beschreibung ergibt sich unlogischerweise GPIO, das Kit sagt 
UPDI und obiger Satz sagt Reset. Ist wohl noch zu früh am Morgen, auch 
Datasheets brauchen eine Weile, bis sie den Beta-Status verlassen, vor 
allem wenn erheblich neu.

Artur V. schrieb:
> Macht mal nen Punkt und lasst die Vernunft sprechen.

Na, Vernunft ist doch in dem Zusammenhang kein Argument. Vernünftig wäre 
es, gar nicht erst mit Mikrokontrollern anzufangen. Das ist wie eine 
Sucht, man kommt kaum wieder weg von den Dingern, wenn man einmal 
angefangen hat.

:)

MfG Paul

Artur V. schrieb:
> Macht mal nen Punkt und lasst die Vernunft sprechen. Welche MCU kommt
> denn mit deaktiviertem Programmierinterface auf den Markt?

12V programming ist anscheinend immer aktiv.

Tim  . schrieb:
> 12V programming ist anscheinend immer aktiv.

Ja, so wie bei allen Tinies, die schon immer HVSP konnten...

Artur V. schrieb:
> Tim  . schrieb:
>> 12V programming ist anscheinend immer aktiv.
>
> In den Pin-Modi GPIO und RESET. Ein 12V Pulse (empfohlen nach
> Device-Reset) versetzt den Chip/den Pin bis zum nächsten POR in den
> UPDI-Mode.

Das heißt aber, man kann auch extern einen 12-V-Impuls anlegen
und danach dann mit dem Atmel-ICE programmieren.

Falls der Chip sich verbreitet, wird es garantiert über kurz oder
lang Derivate eines USBasp geben, die den 12-V-Impuls mit einer
Ladungspumpe erzeugen … wenn die dann erst Verbreitung gefunden
haben, werden sich chinesische Hersteller finden, die sowas für
10 Euro verticken. ;-)

> Rudolf W. schrieb:
>> Wenn die alten Zöpfe ISP, PDI, TPI usw.
>> endlich mal und auf Dauer durch ein einziges, wie im Namen schon
>> ersichtlich 'Unified' Protokoll mit 2 nötigen Datenpins ersetzt weden
>> kann das nur gut sein.
>
> EIN Datenpin ist nun nur noch nötig!

PDI hat gar kein Datenpin gebraucht. ;-)  Es hat schon immer über
/RESET und TEST gearbeitet, die man allerdings bei den Xmegas nicht
für was anderes umher fusen kann.

Artur V. schrieb:
> Hier eine Bestätigung von Atmel zur UPDI Voreinstellung:

Danke.

Sonst hätten sie ja auch ein ernsthaftes Problem, weil der STK600
dann das einzige Tool gewesen wäre, was bereits existiert und damit
umgehen kann.  Der STK600 ist wiederum relativ wenig verbreite, und
einen (erfahrungsgemäß ebenfalls nicht ganz billigen) Adapter für
die Fassung bzw. Routing-Karte wird er außerdem noch benötigen.

So kann es wenigstens das Atmel-ICE, was immer noch einigermaßen
günstig im Preis ist – natürlich auch nur, bis man sich mal
ausgesperrt hat … aber wenn man nur wenige Pins opfern will für
die Programmier- und Debugschnittstelle, muss man wohl oder übel
immer Kompromisse eingehen.  (Bei den ARMs sind die beiden Leitungen
für SWD halt auch de facto abgeschrieben.)

Artur V. schrieb:
> Die günstigste Debug/Programmiermöglichkeit der (noch gar nicht
> erhältlichen) Chips dürfte im Augenblick das schon käufliche 817er
> Xplained Mini sein.

Weißt du denn, ob sie HV-Programmierung unterstützen?

Artur V. schrieb:
> Ein 12V Puls nach POR auf den Resetpin sollte aber nicht das große
> Problem sein

Ja, gut, die Variante hat man ohnehin immer.

Aber irgendeine „offizielle“ Strategie sollte Atmel, ähm, Microchip
ja wohl auch haben.

Artur V. schrieb:
> Es geht ja nun auch wirklich nur um den Fall, daß man unbedingt den
> einen UPDI Pin noch als Reset

Wenn ich mir überlege, wie oft ich während einer Entwicklung so auf
den Reset-Knopf drücke, dann wundere ich mich schon, dass dieser
plötzlich entbehrlich sein sollte …

Kann über das UPDI-Protokoll ein Reset ausgelöst werden?

Artur V. schrieb:
> Das sollte den externen Reset-Knopf entbehrlich machen.

Klar: da kommt dann ein ATtiny10 dran, der den UPDI-Reset auslöst. :-))

Artur V. schrieb:
> Wie meinst Du das, Jörg?

Wie soll ich sonst einen Reset-Taster implementieren?

Klar kann man das auch über einen Programmer machen, aber ich will
ja nicht jedesmal überall beim Test einen Programmer (+ PC)
mitschleppen.

Wenn ich den Pin auf Extern-Reset konfiguriere, komme ich jedoch
nachher mit dem (normalen) Programmer nicht mehr 'ran (nur noch mit
dem 12-V-Impuls).  Das ist ja noch mieser als debugWIRE.

Artur V. schrieb:
> Inwieweit dieses Konfiguration für die Entwicklungsphase Deiner Projekte
> zwingend ist müsstest Du einmal näher ausführen.

Naja, das war jetzt eher theoretisierend.  Ich werde wohl über kurz
oder lang nicht viel mit Tinys am Hut haben.  Unsere Projekte sind
allesamt größer.

Trotzdem finde ich es irgendwie ungeschickt, dass man nun immer
einen HV-Programmer parat haben muss, wenn man einen simplen
Reset-Button haben möchte und trotzdem noch die Programmierschnittstelle
offen lassen will.  Das kenne ich sonst bei keiner Plattform, mit der
ich bislang gearbeitet habe.

Ich würde gerne mal ein Projekt mit den Dingern umsetzen (weil sie so 
niedlich sind), nur frage ich mich, was ich mit 2 verbleibenden Pins (2 
für Strom, 4 für Programmer), im Falle des Tiny102, machen soll? Da kann 
man einen Sensor anschließen aber Ausgeben über UART z.B. geht dann 
nicht mehr. Wie löst ihr das? Stöpselt ihr nach jedem Flash-Vorgang die 
Kabel um (vom Programmer zum Sensor oder ähnlich) oder programmiert ihr 
den µC einmal und baut ihn dann erst in die Schaltung?

Max M. schrieb:
> Ich würde gerne mal ein Projekt mit den Dingern umsetzen (weil sie so
> niedlich sind), nur frage ich mich, was ich mit 2 verbleibenden Pins (2
> für Strom, 4 für Programmer), im Falle des Tiny102, machen soll? Da kann
> man einen Sensor anschließen aber Ausgeben über UART z.B. geht dann
> nicht mehr. Wie löst ihr das? Stöpselt ihr nach jedem Flash-Vorgang die
> Kabel um (vom Programmer zum Sensor oder ähnlich) oder programmiert ihr
> den µC einmal und baut ihn dann erst in die Schaltung?

Atmel hat auch dafür eine Lösung, siehe Anhang.

Bei näherer Betrachtung hat Atmel ja wirklich kein Stein auf dem anderen 
gelassen. Auch das gesamt GPIO-Module wurde erneuert und durch eines 
ersetzt, wie man es von den Cortexen kennt -> Zusatzregister für Set, 
Clear und Toggle.

Dadurch werden einzelne Befehle im AVR-Befehlssatz weniger nützlich, wie 
z.B. SBI, CBI.

Tim  . schrieb:
> wie man es von den Cortexen kennt -> Zusatzregister für Set, Clear und
> Toggle.

Oder eben von den Xmegas.

temp schrieb:
> Obwohl ein JTAGICEMKII und ICD3 schon die Oberklasse darstellt

Naja, ein JTAGICEmkII ist mittlerweile sehr viel mehr als 10 Jahre
alt.  Da musste beispielsweise alles noch per RS-232 machbar sein,
das USB-Frontend ist nur eine Alternative dafür, und auch nur
Fullspeed.  Das Design des JTAGICEmkII war mächtig auf den von Atmel
selbst gestrickten Debugger des AVR Studio 4.x getrimmt worden, daher
ist es einerseits relativ teuer (Dual-CPU, ein riesiger RAM, der zum
Runterladen der Zeilennummern-Info ins ICE dient), andererseits war
es natürlich in dieser Kombination mit dem Studio 4 relativ schnell,
da bspw. die Abarbeitung eines highlevel-Singlestep komplett im ICE
erfolgen konnte.

Wenn man jedoch einen generischen Debugger benutzen will, der mit diesen
Features einfach mal gar nichts anfangen kann (GDB-Nutzer traf das schon
immer, und seit dem Umstieg auf Visual Studio nun auch Atmel Studio),
dann ist der Overhead des Protokolls in Verbindung mit dem aus heutiger
Sicht langsamen Fullspeed-USB einfach lahm.  Die neueren ICEs (JTAGICE3
und Atmel-ICE) machen daher vieles anders, nicht nur ein schnelleres
USB-Interface, und sie unterscheiden sich zwischen AVR und Cortex-M
praktisch kaum noch.

Wenn du also nicht Äpfel mit Birnen vergleichen willst, dann solltest
du also schon einen AVR mit einem Atmel-ICE benutzen, um diese
Kombination dann gegen einen Cortex-M mit x-beliebigem ICE zu halten.

Übrigens finde ich die „alle Welt muss ein HID sein, weil Windows nur
dafür einen generischen Treiber hat(te)“-Philosophie hinter CMSIS-DAP
ausgesprochene Sch***e.  Da wird so viel mehr über den Draht gelabert
als bei einem expliziten Frage-Antwort-Protokoll (wie es das JTAGICE3
anfangs noch benutzte), das geht auf keine Kuhhaut.  Das ist aber in
erster Linie natürlich Microsofts Schuld, alle anderen Systeme haben
seit Jahr und Tag generische Treiber, sodass der Nutzer nicht extra
für jedes popelige USB-Gerät einen Treiber installieren muss, nur
Windows hat(te) das eben nicht.  Dann erklärt man kurzerhand jeden
Krempel zu einem „Human Interface Device“.  Diesem Standard (von
Keil für die Cortexe gesetzt) folgen sie aber nun natürlich alle,
Atmel/Microchip genauso wie STM etc.

Jörg W. schrieb:
> Diesem Standard (von
> Keil für die Cortexe gesetzt) folgen sie aber nun natürlich alle,
> Atmel/Microchip genauso wie STM etc.

STM kocht mit dem STLink sein eigenes Sueppchen. Das ist kein HID.

Jörg W. schrieb:
> Tim  . schrieb:
>> wie man es von den Cortexen kennt -> Zusatzregister für Set, Clear und
>> Toggle.
>
> Oder eben von den Xmegas.

Laut Atmochip handelt es sich bei diesen Tinys intern um XMegas:

http://lists.gnu.org/archive/html/avr-gcc-list/2016-11/msg00002.html

Uwe B. schrieb:

> STM kocht mit dem STLink sein eigenes Sueppchen. Das ist kein HID.

Ja, stimmt, die brauchen dann auch unter Windows wieder ihren eigenen
Treiber.

Wäre interessant, inwiefern man ein Atmel-ICE an einem STM32 oder
ein STlink an einem Atmel-Cortex-M benutzen kann. ;-)  Am Ende sprechen
ja beide SWD … aber OK, da kommen wir jetzt arg vom Thema ab.

Jörg W. schrieb:
> STlink an einem Atmel-Cortex-M

Dass geht mit OpenOCD.

Uwe B. schrieb:
> Jörg W. schrieb:
>> STlink an einem Atmel-Cortex-M
>
> Dass geht mit OpenOCD.

OK, wenn ich mal paar Minuten Zeit habe, probier' ich die andere
Richtung mal aus (auch mit OpenOCD).

Hätte ja auch sein können, dass sie nachschauen, welche Device-ID
da dran hängt.

temp schrieb:

> Ich verstehe zwar deine Argumentation, kann dem aber nicht komplett
> zustimmen. Die HID-Debugger dürften wohl in der Minderzahl sein.

Wenn ich mir die Bewegung in OpenOCD so ansehe, zweifle ich daran.

> Alle
> Cortex-Evalboards von ST, NXP, Freescale, Infinion, Atmel sind entweder
> von Haus aus jlink oder lassen sich so einrichten.

Atmel?  Die haben den Segger lediglich mit eigenem Aufkleber verkauft,
aber integriert haben sie den nie.  Seit sie integrierte Debugger auf
den Boards haben, ist das HID.  Nennt sich dort EDBG, und ist praktisch
gleiche Firmware wie das Atmel-ICE.  Backend ist dabei jeweils ein
spezieller UC3.

> In Windows 10 sind auch generische CDC Treiber enthalten,

Ja, 15 Jahre, nachdem es alle anderen Betriebssysteme konnten.

Gepaart mit der reichlich zähen Kundenakzeptanz von Windows 10 überhaupt
hilft das dann nicht mehr viel.  Inzwischen haben die Kunden eben die
Flucht ergriffen und bauen lieber HIDs.

Für den Debugger geht's außerdem nicht um CDC, sondern um einen
generischen USB-Treiber im OS, also letztlich das, was libusb als API
nach oben abstrahiert.  Ich habe gehört, dass Windows solch einen
Treiber wohl nun auch endlich hätte, bin mir aber erstens noch nicht
einmal sicher, ob der von Haus aus aktiv ist, und zweitens waren sie
eben auch hier mindestens ein Jahrzehnt zu spät.  „Andere Systeme“
meint dabei übrigens keineswegs nur Linux oder Opensource überhaupt,
auch Solaris und OSX haben seit jeher einen generischen USB-Treiber.
Damit kann man eben ein vendor specific device bauen und dann ohne
zusätzliche Installation von Treibern eigene Software (für die
Anbindung des Debuggers) darüber setzen.

Stefan schrieb:
> wobei man sich mit einem gratis Upgrade auf einen Jlink aushelfen kann.

Gut, den kannte ich noch nicht.

Jörg W. schrieb:
> OK, wenn ich mal paar Minuten Zeit habe, probier' ich die andere
> Richtung mal aus (auch mit OpenOCD).

Ja, geht.  Adapter als cmsis-dap wählen, target dann entsprechend
für den STM32.

Gut, wenigstens mal was, was man herstellerübergreifend benutzen
kann, wenngleich vermutlich durch selbige gar nicht beabsichtigt. ;-)

Jörg W. schrieb:
> Ich habe gehört, dass Windows solch einen Treiber wohl nun auch endlich
> hätte

"WinUSB"; wird sogar für ältere Windows-Versionen bis XP auch über 
Windows Update verteilt.

> bin mir aber erstens noch nicht einmal sicher, ob der von Haus aus
> aktiv ist

Wo kämen wir denn da hin? Dafür muss das Gerät einen speziellen 
"Microsoft OS feature descriptor" bereitstellen.

Immer noch besser als ein Extra-Treiber ...

Die ersten 817 im QFN- Gehäuse sind bei Mouser erhältlich.

Wahrscheinlich einer der letzten die noch von "nur Atmel" entwickelt 
wurden, also passt der Aufdruck.

unbekannt schrieb:
> Wie auf der Produktseite vom 817 angedeutet wird, wird es in Zukunft
> auch Tinys mit CAN geben. Das ändert aber leider nichts an der Tatsache,
> dass die AT90CAN* mittlerweile auf not recommended for new designs
> stehen und es für den 128er keinen wirklichen Ersatz gibt.

Letztes Jahr wurden für den AT90CAN Kleinigkeiten im Produktionsprozess 
geändert, habe aber diese Aussage nirgends gefunden.

Haben den AT90CAN in mehreren Produkten im Einsatz (allerdings 
Kleinserie) und habe derartiges noch nicht vernommen. Auch auf der 
Produktseite von Microchip steht einfach nur "In Production" und es gibt 
keinen Hinweis darauf.

Rudolph schrieb:
> was mit ARM Kern ohne Microchip/Atmel.

Wobei das eine ja mit dem anderen nichts zu tun hat.

Rudolph schrieb:

> Ja nun, ich mag Atmel eigentlich so an sich, so der Level an
> Dokumentation und wie das dokumentiert ist, vor allem auch das
> Atmel-Studio.

Die Dokumentation finde ich bei Atmel besser als bei vielen anderen.
Außer beim Xmega hat man dort alles in einem einzigen Datenblatt drin.

Atmel Studio nehme ich nicht, obwohl ich seit vielen Jahren mit
diversen Atmel-Controllern arbeite (auch beruflich).  Da wir ohnehin
multiplattformfähig sein wollen, läuft das alles über Makefiles.
Auf Hersteller-spezifische IDEs kann man gern verzichten, dann muss
man nicht jedesmal alles neu lernen.

> Nur haben die einfach nichts was ich als richtiges Upgrade zu den AVR
> gebrauchen könnte, da ich CAN brauche und nicht so viele Pins.
> Die M7 von Atmel haben bei 64 Pins nur einen CAN, sonst gibt es nur M3
> mit 100 Pins aufwärts, A5 und den M0 C21 der mir wiederrum als Upgrade
> zu lahm ist.

Ich hätte gerade die M0+ natürlich als Upgrade von AVR aus im Blick
gehabt.  Sind halt noch nicht so übermäßig komplex, bieten dennoch
einiges mehr als AVR.

CAN habe ich aber noch nie benötigt, daher ist mein Blick da ein
anderer.

> So sieht das aber bei Atmel schon ein paar Jahre aus, ohne das sich da
> irgendwas tun würde, ist sowieso insgesamt eher Stillstand zu
> beobachten.

Naja, Stillstand nicht, denn die Cortex-M0+-Linie hat dann doch
einiges an Fahrt aufgenommen, und dort wäre ja auch dein 2xCAN kein
Problem.  Bei den anderen Cores setzt man aber wohl in der Tat eher
auf größere Gehäuse.

Rudolph schrieb:
> Warum haben die sowas nur vor 15 Jahren noch nicht gemacht? :-)

Weil sie damals (ok, vor 20 Jahren) noch nicht wussten, dass sowas
mal gebraucht würde.  Daher haben sie IN, OUT, SBI und CBI mit jeweils
unterschiedlicher Adressierungsreichweite, dafür extrem schnell,
gebaut.  Das brauchte einfach einen sehr komprimieren Adressraum, denn
zu viele Bits konnten sie für die Direktadresse sich nicht leisten.

Das, was du hier bei den neuen Tinys siehst, ist ja am Ende das
Xmega-Modell.  Das ist nun auch schon (vom Design her) mehr als 10
Jahre alt, da wussten sie das dann schon …

Bisher hatte ich mit den XMegas nichts am Hut. Diese neuen Tinys 
scheinen aber recht interessant.
Welche Vorteile/Nachteile bringt der "Periodic Timer Interrupt". Der ist 
mir neu. Vergleichbar mit dem SysTick der ARMs?
Würde ich den zum Beispiel als Ersatz für den üblichen periodischen 
Timer Overflow nehmen, den man für wiederkehrende Aufgaben z.B. Tasten 
entprellen verwendet?

Da der Thread gerade wieder hochgekommen ist, gibt es schon irgendwelche 
Infos zu den neuen in den Release-Notes vom Atmel Studio 7.0.1645?

- ATmega4808, ATmega4809
- ATtiny1614, ATtiny3214, ATtiny3216, ATtiny3217

Okay, 1614 gibt es, der 3214 dürfte nur mehr Speicher haben.
Aber zum Rest finde ich gar nichts.

Nach dem Studio:
Atmega4808/Atmega4809: 48k FLASH, 6144 Bytes SRAM, 256 Bytes EEPROM
ATtiny3216/ATtiny3217: 32k/2k/256

Hmm, das Include-File von dem ATmega4808 ist interessant.
Das wirft erstmal alles über den Haufen:

PORTB.DIRSET = PIN0_bm + PIN4_bm;

M. schrieb:
> Geduld, Geduld. Die sind doch noch nichtmal offiziell angekündigt.

Da die kein ISO-CAN-FD haben warte ich da auch nicht drauf. :-)

Aber die Programmierung so umzukrempeln finde ich schon bemerkenswert.
Und die Includes verraten schon so einiges.

Mich würde da sowas immer mal interessieren, für welchen Grosskunden das 
entwickelt wird, in welcher Waschmaschine das landet.

Roger schrieb:
> Im Auslieferungszustand ist immer UPDI aktiv!

Wäre ja auch extrem verwunderlich, wenn dem nicht so wäre.  Irgendwie
muss man die Teile ja programmieren können.

Hallo zusammen,

da ich einen ATMEL AVR im 20-SOIC Gehäuse gesucht hatte, welcher seine 
Versorgungsspannungsanschlüsse an Pin1 & Pin20 haben soll, bin ich auf 
diesen Thread gestossen.

Konnte schon jemand mittels AVR-Studio 7.0 und dem ATMEL-ICE den 
ATtiny816 programmieren ?

Am günstigsten ( Bauteil + Versand ) könnte ich diesen bei ELPRO.org 
bekommen, aber das würde sich erst lohnen, wenn der Bestellwert über 15€ 
liegen würde ( Dann 5,95€ Versand, sonst 9,95€ ).

Außerdem wäre es toll, wenn die auch noch das Atmel *ATtiny416 Xplained 
Nano* Board hätten. Eine eMail diesbezüglich habe ich bereits 
abgeschickt
( ulrike.koegel@elpro.org ).

https://www.elpro.org/de/home/110679-attiny-816-snr.html

Am liebsten wäre mir natürlich alles bei Reichelt zu bekommen. Deshalb 
möchte ich mal an die Reichelt Wunschliste erinnern damit dort die 
beiden Einträge unterstützt werden.

Atmel ATtiny816 SNR
Atmel ATtiny416 Xplained Nano

https://www.mikrocontroller.net/articles/Reichelt-Wishlist


Bernd_Stein

Roger schrieb:
> Du kannst schon mit dem Nachfolger ATTiny1616 basteln!
>
Auch hier das Problem der Beschaffbarkeit bei niedrigen Versandkosten.
Zusätzlich haben ihn meine Lieblingsversender ( Reichelt, ELPRO ) nicht.
Zum anderen taucht er im AVR-Studio 7.0.1188 nicht auf.

Da ich bei diesen Versionen die Käfer auf den Rücken drehen müsste, 
damit diese in ein bestehendes Layout passen würden ( Orginal Pin1=GND & 
Pin20=Vcc ) und z.B. den ATtiny1634 oder ATtiny40 noch zusätzlich um 
180° drehen müsste ( Pin10=GND & Pin11=Vcc ), bin ich mir schon mal 
ziemlich sicher, das der Orginale µC keiner von ATMEL ist. Schlauerweise 
haben die Schlitzaugen dieses IC abgeschliffen.

Hätte ich die Funktion ( Bauteil anklicken. Siehe Anhang ) schon vorher 
gekannt, hätte ich mir das Tippsen hier sparen können, um herauszufinden 
ob der ATtiny816 mit dem ATMEL-ICE programmierbar ist.


Bernd_Stein

Es gibt wohl mittlerweile alternative Programmier-Lösungen für die neuen 
Tinys und Megas.

https://github.com/ElTangas/jtag2updi

Jürgen H. schrieb:
> Es gibt wohl mittlerweile alternative Programmier-Lösungen für die neuen
> Tinys und Megas.
>
> https://github.com/ElTangas/jtag2updi

Ja, solange Du einen werksfrischen bzw. nicht verstellten (Fuses) IC 
verwendest. Ansonsten brauchst Du einen 12V Impuls zum Umstellen.

NACHTRAG: Neue Modelle haben dedizierten UDPI-Pin, da sollte es seltener 
(gar nicht?) möglich sein zu verstellen. Aber man schafft es sicher 
trotzdem ?

Roger schrieb:
> Bernd S. schrieb:
>> Auch hier das Problem der Beschaffbarkeit bei niedrigen Versandkosten.
>
> z.B. 61 Stück bei Digikey für 50€ + MWSt. bei kostenlosem Versand :)
>
Ja, klar ;-). Will mal zeigen, worum es mir eigentlich ging :

Beitrag "China PWM-Solarladeregler Innereien"

Sorry, fürs Kapern. Will halt nicht so viele eigene Threads haben, wo 
ich dann selber nicht mehr durchsteige, denn irgendwie gehört doch alles 
zusammen. Und ich mag keine Datenleichen-Threads ;-)

Bernd_Stein

M. K. schrieb:
> Ein 12 bit Timer...das ist ja mal was ganz was neues...
>
Ja, zusätzlich zu den zwei 16-Bit Timern. Ein 12-Bit ADC hätte mich 
gefreut.

Bernd_Stein

Rolf schrieb:
> Bernd S. schrieb:
>> Ein 12-Bit ADC hätte mich
>> gefreut.
>
> Irgendwas muss die XMegas ja noch von den XTinys unterscheiden :-)
>
Ja, am besten die Anzahl der Pins ;-)


Bernd_Stein

neuer PIC Freund schrieb im Beitrag #5528487:
> Das PicKit4 beherrscht die 12V, was das Atmel ICE nicht kann.

Woraus schlussfolgerst du aus einer Aussage, die da für „MPLAB Snap“ 
steht, irgendwas für ein Atmel-ICE?  Wenn ich mir die Beschreibung zum 
„MPLAB Snap“ ansehe, dann sieht das Ding komplett anders aus als ein 
Atmel-ICE. Letztlich scheint es ein PicKit4 ohne 12 V zu sein.

Kann man den PicKit 4 mit dem Atmel-Studio benutzen?

Wobei ich ja fürchte, dass es anders herum kommt und Atmel Studio 
eingestellt wird.
Macht Sinn für Microchip, zugegeben, nur werde ich mit dem MPLAB-X nicht 
warm - unter anderem weil ich JRE nicht haben will.
Und die dem PicKit3 hatte ich so gar keinen Spass, reichlich zickig 
deren Kombination aus USB-Treiber, Firmware und Software.

Zum Glück sind die noch lange nicht soweit, gibt erst Beta-Support für 
AVR, solange die SAMs nicht auch unterstützt werden wird es wohl 
mindestens AS7 geben.