mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Neue 8-Bit Tinys vorgestellt: 417/814/816/817


Autor: Atmel8BitNews (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert

Autor: Tim  . (cpldcpu)
Datum:

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

Autor: Atmel8BitNews (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schön sind die vielen XMega Features wie Event-System, CustomLogic oder 
DAC die jetzt in die Tinys gepackt wurden. Interessant auch das 
Port-Multiplexing, der Memory-Selbsttest und neue Referenzspannungen für 
den ADC. Und es gibt noch einiges mehr zu entdecken. Ganz schön fett 
geworden, die Kleinen :)

Autor: Tim  . (cpldcpu)
Datum:

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

: Bearbeitet durch User
Autor: Atmel8BitNews (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tim  . schrieb:
> ...vor allem wäre eine Version mit >8kb nett. Wie soll man sonst die
> ganzen Features nutzen?

Naja irgendwo muß ja noch eine glaubwürdige Grenze zur Mega/Xmega 
Familie gezogen bleiben. Man ist immerhin mit nur einem Design flexibler 
für viel mehr Anwendungsfälle geworden...

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein 12 bit Timer...das ist ja mal was ganz was neues...

Ne, mal Spass beiseite. Die Tinys schauen nett aus

Autor: c-hater (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Atmel8BitNews schrieb:

[...]

Am interessantesten ist wohl, dass diese Tinys scheinbar endlich in 
Hardware multiplizieren können, zumindest tauchen die 
Multiplikationsbefehle im Instruction Set Summary auf.

Es hat mich schon immer genervt, einen Mega nur deswegen einsetzen zu 
müssen, weil die Tinys mangels Hardwaremultiplikation schlicht nicht 
schnell genug für eine geplante Anwendung waren, in jeder anderen 
Hinsicht aber völlig ausgereicht hätten.

Auch das Eventsystem und die GlueLogic haben sicher das Potential, das 
Einsatzgebiet der Tinys massiv zu erweitern und Sachen möglich zu 
machen, die bisher entweder garnicht gingen oder nur mit Hilfe 
zusätzlicher Hardware.

Ziemlich schick.

Autor: Nase (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die können ja schon bald mehr, als die ATmegas :-)

Allerdings bilde ich mir ein, dass nun jemand anderes am Reißbrett 
stand. Abgesehen von der AVR-ALU hat die Organisation der Peripherie 
nicht mehr viel mit dem Rest der AVR-Welt zu tun. Fühlt sich eher an, 
wie ein ARM, den man dann entkernt hat und mit dem AVR-Core verwoben 
hat.

Ich bin wirklich mal auf das Erratum der ersten Bausteine gespannt. 
Wenns jetzt wirklich unter Federführung von Microchip entwickelt wurde, 
sollte ja jede Peripherie-Einheit mindestens einen Silicon-Bug haben...

Autor: Nase (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Nase schrieb:
> Abgesehen von der AVR-ALU hat die Organisation der Peripherie
> nicht mehr viel mit dem Rest der AVR-Welt zu tun. Fühlt sich eher an,
> wie ein ARM, den man dann entkernt hat und mit dem AVR-Core verwoben
> hat.
Also nicht dass ich das jetzt pauschal negativ werte.

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, an vielen Stellen spürt man förmlich, 
wie sich jemand Gedanken um die Bits und Register gemacht hat, um mit 
den wenigen verfügbaren SFRs noch das Maximale rauszuholen.
Schönes Beispiel ist der UART: Anfangs habe ich mich gefragt, wieso 
dessen Interrupts so seltsam verteilt sind (TXC latcht nach dem 
Stopp-Bit aber nur mit leerem Puffer, UDR steht sofort dauerhaft an 
usw.) Wenn man sie dann mal benutzt, ergibt alles Sinn.
Vieles war auch orthogonal (die Timer funktionieren alle ähnlich usw.)

Ich hab ein bisschen Angst, dass hier jetzt großflächig umgebaut wird 
und dieser aufgeräumte Aspekt der AVR verloren geht. Wie eingangs 
erwähnt, mag ich deshalb ARMs nicht so gerne: Alles verteilt sich 
gefühlt über eine Flut von dünnbesetzten SFRs und ich hab ständig das 
Gefühl, irgendwo was vergessen zu haben.

Autor: ui (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Nase schrieb:
> Wenns jetzt wirklich unter Federführung von Microchip entwickelt wurde,
> sollte ja jede Peripherie-Einheit mindestens einen Silicon-Bug haben...

Unter dem Aspekt das die Übernahme dieses Jahr im April war, glaub ich 
kaum dass die innerhalb von 6 Monaten nen neuen Chip gestampft haben.

Autor: Axel S. (a-za-z0-9)
Datum:

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

Autor: M. K. (sylaina)
Datum:

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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

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

: Bearbeitet durch User
Autor: Axel S. (a-za-z0-9)
Datum:

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

Autor: ASM Superprofi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Langsam werden die xmegas wirklich immer obsoleter. Fehlt nur noch eine 
Tausendfüssler-Version mit dem neuen Kern.

Autor: A. K. (prx)
Datum:

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

Autor: Chris F. (chfreund) Benutzerseite
Datum:

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

Autor: Basti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.K. Ohne mich lange damit beschäftigen zu wollen, entfallen jetzt die 
PGM Funktionen aus der AVR C-lib? Da RAM und Flash am selben (wenigstens 
virtuell) Bus sind (like CortexM etc.)?

Autor: Basti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, weiter oben steht es ja... sorry (Johann L.)

Autor: René H. (Firma: Herr) (hb9frh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Diese neuen Tinies jetzt UPDI

Der Atmel-ICE kann UPDI. Ich nehme mal an, dass alle neuen "Programmer" 
das können.

Grüsse,
René

Autor: A. K. (prx)
Datum:

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

Autor: Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite
Datum:

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

Autor: JK (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wenn man sich das Datenblatt ansieht, dann fällt auf, dass diese Familie 
ein klarer Schritt in Richtung Cortex M0 ist...
Pin Remap
Atomarer Zugriff auf Portbits, mit Set und Clear-Registern
Eventsystem
IRQ Controller
SysTick aka Real Time Counter
Non Volatile Memory Controller: Flash leigt jetzt im RAM-Adressspace

Autor: Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite
Datum:

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

Autor: A. K. (prx)
Datum:

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

: Bearbeitet durch User
Autor: Bernd (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
> Flash leigt jetzt im RAM-Adressspace

Umgekehrt wäre ebenfalls interessant: Programme laufen im RAM.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
extern const char __attribute__((__progmem__)) str[];

const char* pstr (int i)
{
    return &str[i];
}

char get (int i)
{
    return str[i];
}

Übersetzt mit -Os -mmcu=avrtiny
pstr:
  subi r24,lo8(-(str+16384))
  sbci r25,hi8(-(str+16384))
  ret

get:
  subi r24,lo8(-(str+16384))
  sbci r25,hi8(-(str+16384))
  mov r30,r24
  mov r31,r25
  ld r24,Z
  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ß.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Für Bastler ist die Hürde allerdings etwas hoch, dafür eigens einen
> neuen teuren Programmer/Debugger zu benötigen

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:

http://www.silabs.com/products/mcu/8-bit/Pages/8-bit-microcontrollers.aspx

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Wäre ja mal ein Grund für diese "Bastler" sich 8-Bit Alternativen
> anzusehen

Er nun wieder ;-)
Aber irgendwie hat Lothar Recht, obwohl ich eher Cortex-M0 favorisieren 
würde als mich auf 'verpickte' AVRs einzulassen.

Autor: Hartmut Göttl (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Lothar schrieb:
> Wäre ja mal ein Grund für diese "Bastler" sich 8-Bit Alternativen
> anzusehen,

Aber woher denn. Eine MCU wählt man doch nicht aufgrund dieser oder 
jener Programmiermethode. Hier gehts um die "aufgeräumten Aspekte" der 
AVRs, Lothar. Hier gehts um eine populäre ausgereifte Architektur mit 
viel Doku und entwickelter Software, Lothar. Eine inzwischen und nicht 
ohne Grund riesengroß gewordene Familie, in der man sich über Nachwuchs 
immer freut! Die man solange möglich nicht hoppladihopp mal hierhin mal 
dorthin verlässt. Das wäre unklug, Lothar.

Autor: A. K. (prx)
Datum:

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

Autor: Peter D. (peda)
Datum:

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

Autor: Nase (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcus H. schrieb:
> 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.
Nunja, ich frage mich auch manchmal, wieso ich Zeit in einen Algorithmus 
auf einem AVR investiere anstatt einfach einen größeren/schnelleren ARM 
zu nehmen.

Andererseits ist mir bei ARM halt die Anlaufschwelle oft irgendwie 
unbequem. Das geht augenscheinlich auch vielen anderen so: Nicht umsonst 
gibts ja Peripheral-Libraries oder solche Codegenerator-Unfälle wie 
"DAVE" (Infineon). Für viele Anwendungen ist mir das schlicht 
"unbequem"-komplex. Wenn das alles mal läuft in einem größeren Projekt, 
dann ist auch Debugging (hier im Gegensatz zum AVR) einfach traumhaft. 
Aber bis es mal läuft... naja, greif ich doch wieder zum AVR.

Das meine ich auch tatsächlich völlig subjektiv: Ich bin in der Lage, 
Datenblätter zu lesen und sehe mich auch in der Lage, einen ARM vom 
bare-metal zu beleben. Aber es ist einfach unbequem (Clock-System, 
Startup, Pin-Routing, ...) verglichen mit AVR z.B., bei dem man nicht 
viel vergessen kann und mit ein paar wenigen Registern die Peripherie 
vollständig im Griff hat.


Ansonsten finde ich, wie Hartmut auch, dass die AVR-Peripherie wirklich 
viel Schönes hat. Ich hab mich schon in vielen Dingen daran angelehnt, 
wenn ich z.B. in VHDL arbeite. Meinen UART habe ich in VHDL mit 
denselben Registern aufgebaut, wie beim AVR - das ist einfach ein 
schönes sauberes und eindeutiges "API" (siehe Grütze vom 16550!).

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hartmut Göttl schrieb:
> Hier gehts um eine populäre ausgereifte Architektur mit
> viel Doku und entwickelter Software

So populär dass AVR in der Industrie laut EMITT 3% Marktanteil nach 
Stückzahlen hat und 8051 und ARM jeweils 30% ...

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Wenn du jetzt alle Smartphones mit einem Cortex-A mit AVRs
> in einen Topf wirfst

Cortex-A zählen dabei nicht als MCU - obwohl diese durchaus auch Bare 
Metal als MCU eingesetzt werden:

http://emittsolutions.com/section/market-analysis/market-analysis-microcontroller.html

Und auch im Bereich Smartphones kommen Sensoren oft mit 8051 - nicht mit 
Cortex-M0 Hardfault oder gar AVR:

https://www.elektormagazine.com/news/a-gas-sensor-in-every-smartphone-but-with-an-8051-

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: A. K. (prx)
Datum:

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

: Bearbeitet durch User
Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nase schrieb:
> Für viele Anwendungen ist mir das schlicht
> "unbequem"-komplex. Wenn das alles mal läuft in einem größeren Projekt,
> dann ist auch Debugging (hier im Gegensatz zum AVR) einfach traumhaft.
> Aber bis es mal läuft... naja, greif ich doch wieder zum AVR.

So sehe ich das auch. Wenn aber wie hier an den AVRs immer weiter 
herumgetrickst wird, werden sie undurchschaubarer. Anfang des Jahres - 
glaube ich - gab es hier eine Diskussion über B-Typen der ATmega328. 
Wurden die nicht wieder zurückgepfiffen bzw. preislich angehoben?

Hurra - bei diesen neuen Typen gibt es jetzt eine höhere Priorität für 
einen einzigen Interruptvektor. Der 8051 hat da schon mehr zu bieten und 
bei den Cortex-M0 gab und gibt es immer 4 Prioritätsebenen für alle 
ISR-Vektoren frei nach Bedarf. Nur so, um einen Punkt herauszugreifen.

> Aber bis es mal läuft... naja, greif ich doch wieder zum AVR.

Das ist aber nicht in Stein gemeißelt. Mal sehen, wie sich die Preise 
entwickeln.

Autor: Nase (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
m.n. schrieb:
>> Aber bis es mal läuft... naja, greif ich doch wieder zum AVR.
>
> Das ist aber nicht in Stein gemeißelt. Mal sehen, wie sich die Preise
> entwickeln.
Ist halt ein persönlicher, subjektiver Eindruck.
Ich fühl mich auf ARM stets unwohl, weil ich ständig das Gefühl habe, 
dass meine Anwendung gerade "irgendwie" läuft weil ich den ARM 
einigermaßen sinnvoll parametrisiert habe.
Beim AVR und seiner Architektur ist dieser Punkt mit "Jetzt ist alles 
richtig" deutlich einfacher zu sehen, das beruhigt mich.

Autor: M. K. (sylaina)
Datum:

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

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Immerhin sind diese neuen µC eine deutlich Antwort auf die Frage, ob die 
8bit Technologie obsolet ist.

Autor: borg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf der Elektronika gab es schon ein deutliches Rebranding Richtung 
Microchip. Die AVR wurden nur relativ versteckt und direkt neben PICs 
dargestellt. Bin mal gespannt, wir sich das entwickelt.

Autor: borg (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Der klassische Microchip TinyAVR.

Autor: unbekannt (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hi,

Ich habe mich vorgestern auf der Electronica mit jemandem von 
Atmel/Microchip über die Zukunft der AVRs unterhalten.
Die neuen Tinys haben, wie hier richtig steht, viele Features von den 
XMegas bekommen und es sollen in der Zukunft noch mehr werden.

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.

Zur weiteren Zukunft hieß es sinngemäß: wir glauben an AVR, sie werden 
nicht sterben.

Von anderer Stelle habe ich allerdings mitbekommen, dass die 
Atmel-übernahme halbwegs Mitarbeiter-unfreundlich ablaufen soll - in 
Richtung Tricksereien, damit der Betriebsrat nicht beißen kann und 
ähnliches...

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

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

Autor: H.Joachim S. (crazyhorse)
Datum:

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

Autor: Rudolf W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Wie hier schon einer sagte: das Teil sieht aus wie nen CortexM0 mit
> etwas atxmega Würzung.

Naja wenn, dann höchstens umgekehrt.
Die Teile sind tatsächlich kleine, abgespeckte Xmegas.
Die bereits bekannten, niedrigen Preise machen die neuen Tinys noch 
interessanter.

Autor: Tim  . (cpldcpu)
Datum:

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

Autor: S. R. (svenska)
Datum:

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

Autor: Ullrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die grafische Online Konfigurationshilfe Atmel.Start lässt sich nun auch 
erstmals mit den neuen Tinys verwenden. Das dazu passende 817er Eval.Kit 
ist bereits erhältlich.

c-hater schrieb:
> Am interessantesten ist wohl, dass diese Tinys scheinbar endlich in
> Hardware multiplizieren können

Streiche das 'scheinbar' !

unbekannt schrieb:
> Zur weiteren Zukunft hieß es sinngemäß: wir glauben an AVR, sie werden
> nicht sterben.

Wer behauptet denn sowas?  :)

Autor: Axel S. (a-za-z0-9)
Datum:

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

Autor: M. K. (sylaina)
Datum:

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

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich wenigstens einen meiner Programmer (z.B. den ISPmkII) weiter 
verwenden kann, werde ich deise Chips sicher verwenden. Aber wenn die 
nur deswegen wieder 50 Euro für einen neuen Programmer ausgeben müsste, 
dann würde ich es bleiben lassen.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Konstantin F. (Firma: "Konniemara") (konstantin-2)
Datum:

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

Autor: M. K. (sylaina)
Datum:

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

Autor: Axel S. (a-za-z0-9)
Datum:

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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Rudolf W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
>
> Zumindest das Atmel-ICE werden sie garantiert per Firmwareupdate
> aufpolieren, das neue Protokoll zu verstehen.

Der ist dafür offiziell vorgesehen und es ist jedem, der auf längere 
Sicht mit den AVRs (und ggf. mit Atmel-ARM) weiterarbeitet wirklich 
anzuraten, sich diesen Alleskönner zuzulegen. So ein Teil war (ist?) 
schon für 40€ zu erstehen. 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. Beim ICE3 ist UPDI-Support übrigens auch schon 
dokumentiert.

Autor: Lothar (Gast)
Datum:

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

Mal zur Klarstellung: ISP = In-System-Programming bezeichnet 
üblicherweise ein Flashen über eine Standard-PC-Schnittstelle z.B. RS232 
und nicht wie bei den AVR das Flashen mit einem Spezial-Programmer über 
eine Art SPI sowas heisst üblicherweise ICP = In-Circuit-Programming. 
Daher braucht man für ISP bei anderen Mikrocontrollern als AVR auch 
keine "Infrastruktur" sondern nur ein Nullmodem-Kabel oder 
USB-seriell-Kabel.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Artur V. (Gast)
Datum:
Angehängte Dateien:

Bewertung
4 lesenswert
nicht lesenswert
Anbei ein Eindruck vom AVR-"Stand" bei Microchip.
Der Tiny817 konnte dort seine Fähigkeiten in einer Sprachrekorder-App 
erfolgreich unter Beweis stellen. Unten drunter waren die kostenlosen 
Evaluation-Kits zu ergattern :)

Wen es interessiert, die Beschriftung des ATtiny817 auf den Xplained 
Minis lautet wie folgt:

Atmel
AT817F
638B TW
AF3KPA

Die Device-Signature lautet 0x1E9320.
Revision: A, NVM Version: 0, OCD Version: 0, Metal revision: 01.

Zum Thema Programmierung wollte ich noch anmerken, daß die Tinys jetzt 
auch über eine Boot-Loader Sektion im Flash verfügen!

Autor: S. R. (svenska)
Datum:

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

Autor: Brummbär (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> nicht per RS232 programmiert werden.

Die Welt dreht sich - die meisten Notebooks und PCs haben bereits seit 
längerem kein RS232 mehr. Direkt ohne zusätzliche Hardware liesse sich 
also nur per USB programmieren. Außer du setzt auf Ethernet oder gar 
WLAN.

Autor: neuer PIC Freund (Gast)
Datum:

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

[Träum]

Neu: Pickit4 kann alles bisherige schneller und die neuen ATtinys.

[/Träum]

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

: Bearbeitet durch Moderator
Autor: neuer PIC Freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HVPP hatte ich mal zum Test laufen. Der Speed war schon toll. 1.4 
Sekunden, um von SD-Card den vollständigen Speicher eines ATMega32 neu 
zu programmieren und verifizieren. Aber mit 16 Leitungen zu wackeln + 
12V am Reset + evtl. Takt sind halt nur für Serienproduktion geeignet, 
nicht für ISP. "12V" ist das Komplementärwort zu "verfusen"; die meisten 
kennen nur eins von beiden. Und meine USBasp schaffen höchsten 1k5/Sec.

Habe mal gerade meinen Atmel-ICE begutachtet. Auf dem PCB sind 7 fette 
Bauteile. Könnten Zenerdioden oder Supressordioden sein (steht da 
vielleicht 5V drauf?). Laut Pinout sind von den 10 Pins 2 GND und Pin7 
unbeschaltet. D.h. die restlichen Pins haben dieses Bauteil gegen GND im 
Signalweg. Dies mit dem Faktum, dass ich nur eine Spule sehe (die für 
den Boostconverter fehlt), machen meine Hoffnung zunichte, dass der ICE 
12V kann.

Ansonsten finde ich das Konzept knuffig. Ein Pin mit hoher Spannung und 
1/2 Pins mit hoher Geschwindigkeit -> kleine Stecker und aussperren 
unmöglich.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: neuer PIC Freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Dioden sind mit E2 gelabelt. Passt zu 5.6/6.2V Zenerdioden. Somit 
egal, ob die Spannung mit Kondensator oder Spule aufpoliert wird.

Vielleicht gibt es dann die Teile mit RSTPINCFG = 0x1 zu kaufen. Und wer 
einen Reset-Pin haben möchte, muss diesen erst umprogrammieren (wenn eh 
schon programmiert wird).

Autor: Axel S. (a-za-z0-9)
Datum:

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

Autor: neuer PIC Freund (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Steht ja geschrieben im UserGuide-10/2016:
Important:  The Atmel-ICE does not support 12V on the UPDI line. In other words, if the UPDI
pin has been configured as GPIO or RESET the Atmel-ICE will not be able to enable the UPDI
interface.

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.

Also muss bald ein Debugger folgen, der UPDI und 12V beherrscht. 
Ansonsten braucht man sich die Teile, auch wenn die Peri yeah ist, nicht 
anzusehen.

Schade

Bezüglich Kern ist die Sache ganz einfach: Der beste Makroassembler 
namens "C" filtert alles für meinen Kern. Ob der nun AVR, PIC, STM8, RX 
oder Cortex Mx heisst, ist doch schon Nebensache. Wenn er für die 
Peripherie ausreicht, entscheidet eher die Klicki-Bunti-IDE.

Autor: A. K. (prx)
Datum:

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

Autor: R.B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
neuer PIC Freund schrieb im Beitrag #4789743:
> Steht ja geschrieben im UserGuide-10/2016:
> Important:  The Atmel-ICE does not support 12V on the UPDI line. In
> other words, if the UPDI
> pin has been configured as GPIO or RESET the Atmel-ICE will not be able
> to enable the UPDI
> interface.
>
> 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.

Mag Deinen Reset-Pin nicht so recht als überlebenswichtig einstufen. Ein 
Reset lässt sich doch auch auf andere Weise auslösen.
Die Möglichkeit der Umwidmung des Pins wäre eher eine zusätzliche 
Option. Alles nichts neues, siehe ISP/SPIEN.

Autor: R.B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Man kann zwar den Pin alternativ
> fest als UPDI konfigurieren, dann braucht es keine 12V

Das ist der Normalfall und das ist auch der Auslieferungszustand.

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

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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R.B. schrieb:
> Das ist der Normalfall und das ist auch der Auslieferungszustand.

Wo steht eigentlich, was der Auslieferungszustand der Fuses ist?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: R.B. (Gast)
Datum:

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

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.

Autor: Tim  . (cpldcpu)
Datum:

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

Autor: R.B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tim  . schrieb:
> Hast Du Dir dabei ein "frisches" Device angeschaut, oder das auf dem
> Xplained-board?

R.B. schrieb:
> Via mEDBG Tool (Ev.Kit) nachgeschaut

Frische Ware ist noch nicht erhältlich.

Autor: A. K. (prx)
Datum:

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

: Bearbeitet durch User
Autor: Artur V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Macht mal nen Punkt und lasst die Vernunft sprechen. Welche MCU kommt 
denn mit deaktiviertem Programmierinterface auf den Markt?

Autor: Paul B. (paul_baumann)
Datum:

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

Autor: Tim  . (cpldcpu)
Datum:

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

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

Bewertung
0 lesenswert
nicht lesenswert
Tim  . schrieb:
> 12V programming ist anscheinend immer aktiv.

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

Autor: Artur V. (Gast)
Datum:

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

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

Für die Default-UPDI Betriebsart Fuse Einstellung ab Werk spricht auch

"The UPDI pin is primarily a programming and debugging pin, which can be 
fused to have an alternative function (/RESET or GPIO)" siehe Atmel-ICE 
User Guide S.41.

Der Atmel-ICE Programmer dürfte die neuen Tinys trotz des hier schon 
angemerkten fehlenden 12V Supports wohl kaum offiziell unterstützen, 
wenn der Chip ab Werk nicht mit schon gesetzter UPDI-Fuse käme.

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!

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Artur V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
>
> Übersehe ich etwas?

Ja.

Du übersiehst, daß "Reset"-Werte natürlich keine (bis zur Änderung via 
UPDI dauerhaften) Fuse Default Einstellungen sind sondern nur die 
Reset-Werte der zugehörigen Register:

"The configuration and calibration values stored in the fuses
are written to their respective target registers at the end of the 
start-up sequence" (Datenblatt S.26)


Jörg W. schrieb:
> Das heißt aber, man kann auch extern einen 12-V-Impuls anlegen
> und danach dann mit dem Atmel-ICE programmieren.

So würde ich das auch sehen.
Für den Fall, daß der Reset-Pin im GPIO/Output Mode Hardware ansteuert 
ist übrigens ein Timer vorgesehen der ab Reset den Output-Modus 8.8ms 
deaktiviert. In dieser Zeit kann dann (für die MCU) komplikationsfrei 
der 12V Puls erfolgen.

> PDI hat gar kein Datenpin gebraucht. ;-)  Es hat schon immer über
> /RESET und TEST gearbeitet,

Idee der neuen Chips scheint zu sein, möglichst alle Pins irgendwie für 
die App verwenden zu können. Das verlangt nun "nur" noch 12V 
Verträglichkeit für angeschlossene Peripherie an einem = dem Reset-Pin, 
wenn man diesen nicht dauerhaft zur Programmierung/Debugging freihalten 
kann/möchte.

Autor: R.B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Knut B. schrieb:
> Ja, so wie bei allen Tinies, die schon immer HVSP konnten...

bei dem man aber auf mehr Pins Rücksicht nehmen mußte, was oft zur Folge 
hatte: Auslöten! Da ist man doch jetzt mit nur noch einem Anschluß 
deutlich flexibler.

Übrigens auch nett: Unabhängige Messung der Taktfrequenz via UPID.
"It is possible to use the UPDI to get a accurate measurement of the 
system clock frequency, by using the UPDI event connected to TCB with 
Input Capture capabilities"

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Artur V. schrieb:
> 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.
> Übersehe ich etwas?
>
> Ja.
>
> Du übersiehst, daß "Reset"-Werte natürlich keine (bis zur Änderung via
> UPDI dauerhaften) Fuse Default Einstellungen sind sondern nur die
> Reset-Werte der zugehörigen Register

oder statt der 0en gehören einfach fusetypische Xen unten drunter wie 
beim nächstfolgenden SYSCFG1 auch!

Nase schrieb:
> Ich hab ein bisschen Angst, dass hier jetzt großflächig umgebaut wird

schon passiert

> und dieser aufgeräumte Aspekt der AVR verloren geht

ja man sollte die Dinge besser einfach halten. Hat ja keiner ein Problem 
wenn mehr nutzbare Peripherie dazukommt. Aber wie kompliziert die dann 
zu konfigurieren ist! Schönes Beispiel ist USART. Wer zum Teufel braucht 
die ganzen Modi ? In 99% der Anwendungsfälle langt das klassische 8N1- 
der Rest der Möglichkeiten ist zwar schön für das eine Prozent, 
verkompliziert aber die restlichen 99% sinnlos. Statt dessen sollte man 
lieber mal fixe Standard-Baudwerte im Klartext wählbar machen und der MC 
kümmert sich anhand seines Takts selbst um die Setup-Details. RX-seitig 
könnte ein Automodus zur Erkennung dienen. DAS wär mal ein Fortschritt!

Autor: Artur V. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hier eine Bestätigung von Atmel zur UPDI Voreinstellung:

"Our internal IC design confirms that the default state of 
RSTPINCFG[1:0] is UPDI mode. We filed a bug in datasheet. This will be 
fixed in the next version of datasheet."

Quelle http://www.avrfreaks.net/comment/2029926#comment-2029926

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Artur V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> weil der STK600
> dann das einzige Tool gewesen wäre, was bereits existiert und damit
> umgehen kann.

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. Der 817 dort lässt sich abklemmen...

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Artur V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> 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?

Nein, mangels 12V direkt nicht. Ein 12V Puls nach POR auf den Resetpin 
sollte aber nicht das große Problem sein, am Board ist alles zugänglich.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Artur V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Aber irgendeine „offizielle“ Strategie sollte Atmel, ähm, Microchip
> ja wohl auch haben.

Ach ich denke schon, daß die noch sichtbar wird. Spätestens Made in 
China machts dann möglich. Es geht ja nun auch wirklich nur um den Fall, 
daß man unbedingt den einen UPDI Pin noch als Reset oder allerletzten IO 
braucht...

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann über das UPDI-Protokoll ein Reset ausgelöst werden?

Autor: Artur V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Kann über das UPDI-Protokoll ein Reset ausgelöst werden?

"Universal Program Debug Interface (UPDI) Reset
The UPDI contains a separate reset source that is used to reset the 
device during external programming
and debugging. The reset source is accessible only from external 
debuggers and programmers. The
UPDI reset will reset all logic except the UPDI itself, TCD pin override 
settings and BOD settings. See
UPDI chapter on how to generate a UPDI reset request" DB S.98

Das sollte den externen Reset-Knopf entbehrlich machen.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Artur V. schrieb:
> Das sollte den externen Reset-Knopf entbehrlich machen.

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

Autor: Artur V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Artur V. schrieb:
>> Das sollte den externen Reset-Knopf entbehrlich machen.
>
> Klar: da kommt dann ein ATtiny10 dran, der den UPDI-Reset auslöst. :-))

Wie meinst Du das, Jörg?
Der Programmer (ob Atmel-ICE, ICE3 oder das Dev.Kit) löst den Reset am 
UPDI Pin angeschlossen und über UPDI bei Bedarf doch allein aus.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

: Bearbeitet durch Moderator
Autor: Artur V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als Du davon sprachst

Jörg W. schrieb:
> wie oft ich während einer Entwicklung so auf
> den Reset-Knopf drücke

ging ich davon aus, daß zur Entwicklung natürlich auch ein Programmer 
anwesend ist. Entwicklung allein mit Reset-Taster statt Programmer 
kannte ich so noch nicht :)

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

Genau. Für diesen Spezialfall ist noch keine "offizielle" Lösung in 
Sicht.
Sagte ich bereits. Inwieweit dieses Konfiguration für die 
Entwicklungsphase Deiner Projekte zwingend ist müsstest Du einmal 
näher ausführen. Ein Reset lässt sich ja ohnehin auf vielerlei Wegen 
herbeiführen.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

: Bearbeitet durch Moderator
Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> einen HV-Programmer parat haben

Es braucht doch nur den 12V Puls auf den Pin.

> einen simplen Reset-Button

könnte man gleich für den Puls zweckentfremden: Ein Jumper wechselt 
zwischen Masse und extern für den Zweck anzuschließende 12V ...

Autor: Max M. (maxmicr)
Datum:

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

: Bearbeitet durch User
Autor: Hartmut Göttl (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Max M. schrieb:
> was ich mit 2 verbleibenden Pins (2
> für Strom, 4 für Programmer), im Falle des Tiny102,

Hier gehts zwar gerade um andere Tinys mit anderem Programmierinterface, 
das TPI beim kleinsten Tiny102 braucht aber nur 3 Pins, bleiben also 3 
übrig.

> Da kann
> man einen Sensor anschließen aber Ausgeben über UART z.B. geht dann
> nicht mehr.

Doch, geht sogar noch. PB1=ADC5, PB2/3 TX/RX sind just die 3 freien 
Pins.

> programmiert ihr
> den µC einmal und baut ihn dann erst in die Schaltung?

Nicht so optimal bei SMD. Für PA1/2 empfiehlt sich hochohmiger Anschluß 
in der App oder eben Jumper, dann lassen sich beim 102 durchaus TPI und 
Anwendung unter einen Hut bringen.

Autor: Hartmut Göttl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hartmut Göttl schrieb:
> Für PA1/2

PA0/PA1 meinte ich. Reset würde ich nicht antasten.

Autor: M. K. (sylaina)
Datum:
Angehängte Dateien:

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

Autor: Tim  . (cpldcpu)
Datum:

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

Autor: temp (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich verwende hin und wieder auch noch Tiny's wie den 841. Aber wenn sich 
der gesamte Workflow bei einem Paradigmenwechsel genauso zäh anfühlt wie 
bisher bei Atmel/Microchip, dann kann mir das gestohlen bleiben. Wenn 
man mal ein paar Wochen nur Cortex programmiert und gedebuggt hat 
(jlink) und muss danach mal wieder AVRs oder PICs benutzen, fühlt man 
sich wie in die Steinzeit versetzt. Obwohl ein JTAGICEMKII und ICD3 
schon die Oberklasse darstellt, ist es einfach nur grottig. Bei den PICs 
noch schlimmer als bei den AVRs. Sollte Atmel/Microchip es aber mit dem 
neuen Interface hinbekommen, dass man bei jedem Einzelschritt im 
Debugger nicht eine Kaffeepause einlegen muss, legen sie an 
Attraktivität wieder zu. Auch das Starten und Stoppen einer Debugsession 
ist eine Zeit die darüber entscheiden kann ob die Arbeit Spaß macht oder 
nicht. Warum sich gerade bei den PICs nicht mehr Leute aufregen wundert 
mich schon lange.

Autor: Ecki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tim  . schrieb:
> Dadurch werden einzelne Befehle im AVR-Befehlssatz weniger nützlich, wie
> z.B. SBI, CBI.

Warum?
Die Ports sind trotzdem (auch) in genau der gleichen Weise ansprechbar. 
Nennt sich jetzt nur Virtual Ports. Wie gehabt SBI/CBI friendly am 
Anfang der Peripherie IO Map. Im Unterschied zum Xmega sind sie den 
Ports fix zugeordnet, insofern scheint die Bezeichnung "Virtual" etwas 
irreführend.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

: Bearbeitet durch Moderator
Autor: Uwe B. (Firma: TU Darmstadt) (uwebonnes)
Datum:

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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

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

Woraus liest du das? Etwa aus diesem

>tiny817 is not of AVR_TINY architecture, it's actually a xmega2 according >to our 
classification.

Satz?

MfG Spess

Autor: Ecki (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> tiny817 is not of AVR_TINY architecture, it's actually a xmega2
> according to our classification.

It's a XTiny!

Autor: Lukas (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ecki schrieb:
>> tiny817 is not of AVR_TINY architecture, it's actually a xmega2
>> according to our classification.
>
> It's a XTiny!

It's rather a Xiny!

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Uwe B. (Firma: TU Darmstadt) (uwebonnes)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> STlink an einem Atmel-Cortex-M

Dass geht mit OpenOCD.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ü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.

Ich verstehe zwar deine Argumentation, kann dem aber nicht komplett 
zustimmen. Die HID-Debugger dürften wohl in der Minderzahl sein. Alle 
Cortex-Evalboards von ST, NXP, Freescale, Infinion, Atmel sind entweder 
von Haus aus jlink oder lassen sich so einrichten. Und das ist kein HID. 
In Windows 10 sind auch generische CDC Treiber enthalten, die keine 
separate inf-Datei mehr benötigen. Deshalb verstehe ich das Geschrei 
nicht ganz.
Kann noch jemand bestätigen, das das Atmel ICE so deutlich schneller 
ist, dass sich eine Neuanschaffung lohnt? Welche Kommandozeilentool 
laufen damit außer atprogramm?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
temp schrieb:
> Kann noch jemand bestätigen, das das Atmel ICE so deutlich schneller
> ist, dass sich eine Neuanschaffung lohnt? Welche Kommandozeilentool
> laufen damit außer atprogramm?

ich sehe bei mir schon eine gefühlt schnellere Reaktion/Flash (wobei 
auch viel ausmacht ob man ein SSD Drive eingebaut hat wenn es um die 
Atmel Studio Entwicklung geht, allein da gehen schon viele Clicks 
flott).


Jörg W. schrieb:
>> 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.

Hi Jörg

ja einerseits, wobei man sich mit einem gratis Upgrade auf einen Jlink 
aushelfen kann.

http://blog.atmel.com/2016/02/24/segger-firmware-upgrade-brings-j-link-to-atmel-xplained-kits/

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Gut, den kannte ich noch nicht.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Clemens L. (c_l)
Datum:

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

Autor: Max (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> OK, da kommen wir jetzt arg vom Thema ab

Wie wahr, wie wahr :(

Beitrag #4832712 wurde von einem Moderator gelöscht.
Autor: Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Die ersten 817 im QFN- Gehäuse sind bei Mouser erhältlich.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Knut B. schrieb:
> Die ersten 817 im QFN- Gehäuse sind bei Mouser erhältlich.

Viele Typen der Reihe sollen erst ab Mitte Mai lieferbar sein.

Autor: M. (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Zu ergänzen wären nun noch die neuen 16KB Varianten Tiny1614,1616 und 
1617:
http://ww1.microchip.com/downloads/en/DeviceDoc/40001893A.pdf

Autor: Quant (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ein 3217 wird es wohl auch noch geben.

Autor: Atmel8BitNews (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
M. schrieb:
> Zu ergänzen wären nun noch die neuen 16KB Varianten Tiny1614,1616
> und
> 1617

... und daß ein Tiny1614 nun sogar schon erhältlich ist (siehe Bild).
Man beachte auch den weiter bestehenden, alten Firmenaufdruck!

Autor: Chris F. (chfreund) Benutzerseite
Datum:

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

Autor: H. K. (spearfish)
Datum:

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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
H. K. schrieb:
> 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.

tja das kommt davon wenn man die Ware bei einem nicht offiziellen 
Distributor kauft, dem ist alles nach dem Kauf Wurscht. Wir kaufen zb. 
bei EBV ein, und bekomme jede Produktänderung automatisch.

Trotzdem reicht es einfach mal die Atmel.com (oder jetzt microchip.com) 
Seite zu begnügen und sich für Produktupdates registrieren lassen.
Ohne Registrierung gibt es diese Info trotzdem, Du mußt aber selbst 
aktiv werden und regelmäßig schauen. zb. hier
http://www.atmel.com/about/quality/pcn-eol/pcn-eol-notifications.aspx

Da steht sogar dann auch der Grund
To improve ontime delivery performance by qualifying both ASEKH and ATP 
Assembly site. ATK assembly site will no longer have manufacturing
support to assemble selected AT90CAN Catalog Part Numbers.

Das sagt aber auch schon vieles, dass Microchip - obwohl die alte 
Assembly Location die Produkte nicht mehr produzieren kann, wird dennoch 
in diese alten MCU invstiert und gleich zwei neue Assembly Locations 
qualifiziert. Und das war 6Monate nach der Übernahme von Atmel.

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
unbekannt schrieb:
> Wie auf der Produktseite vom 817 angedeutet wird, wird es in Zukunft
> auch Tinys mit CAN geben.

Hmm, wo denn, wie denn? Ich könnte auch noch was unter dem ATMega16M1 
einsetzen.

Ach ja, ein Traum wären ja 32MHz+ AVR mit 44 oder 64 Pins und 2x CAN-FD. 
:-)
Oh ja, mit 0,5mm Pin-Abständen natürlich.

Aber nun ja, wird es nicht geben fürchte ich und so sehe ich für die 
ständig näher rückende Zukunft was mit ARM Kern ohne Microchip/Atmel.
ARM heisst zwar quasi automatisch weniger Kontrolle und mehr fremde 
Software, aber irgendwann muss man da wohl durch, wenigstens gibt es die 
Option sich da raus zu graben.

Beitrag #5041429 wurde von einem Moderator gelöscht.
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudolph schrieb:
> was mit ARM Kern ohne Microchip/Atmel.

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

Autor: Rudolph (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Jörg W. schrieb:
>> was mit ARM Kern ohne Microchip/Atmel.
>
> Wobei das eine ja mit dem anderen nichts zu tun hat.

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.
Und Atmel, bzw. Microchip hat ja auch ARM im Sortiment.

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

Der Aufwand zu was komplett anderem zu wechseln ist hoch, der Nutzen 
reicht da bisher nicht, durch andere Anforderungen wie ISO CAN-FD wird 
sich das aber ändern und Atmel ist dann leider raus.

Bei Microchip direkt brauche ich auch gar nicht zu schauen, weder will 
ich ernsthaft mit MPLAB arbeiten müssen, noch will ich mich mit 
kastrieren Compilern zufrieden geben wenn es anderswo GCC für lau gibt.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Atmel8BitNews (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anbei noch ein Einblick in Device-Information und Fuses so wie von 
AtmelStudio7+Atmel-ICE geliefert.

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir gerade mal ein Beispiel aus dem START angesehen:
"OLED1 XPlained PRO tiny817"

Den OLED Treiber wollte ich mir ansehen, in dem Projekt ist ein 
"ssd1306.c" zu finden.

Viel interessanter fand ich aber, was in "spi_basic.c" zu finden ist:
void SPI_0_init()
{
  SPI0.CTRLA = 0 << SPI_CLK2X_bp    /* Enable Double Speed: disabled */
               | 0 << SPI_DORD_bp   /* Data Order Setting: disabled */
               | 1 << SPI_ENABLE_bp /* Enable Module: enabled */
               | 1 << SPI_MASTER_bp /* SPI module in master mode */
               | SPI_PRESC_DIV4_gc; /* System Clock / 4 */

  // SPI0.CTRLB = 0 << SPI_BUFEN_bp /* Buffer Mode Enable: disabled */
  //     | 0 << SPI_BUFWR_bp /* Buffer Write Mode: disabled */
  //     | SPI_MODE_0_gc /* SPI Mode 0 */
  //     | 0 << SPI_SSD_bp; /* Slave Select Disable: disabled */

  // SPI0.INTCTRL = 0 << SPI_DREIE_bp /* Data Register Empty Interrupt Enable: disabled */
  //     | 0 << SPI_IE_bp /* Interrupt Enable: disabled */
  //     | 0 << SPI_RXCIE_bp /* Receive Complete Interrupt Enable: disabled */
  //     | 0 << SPI_SSIE_bp /* Slave Select Trigger Interrupt Enable: disabled */
  //     | 0 << SPI_TXCIE_bp; /* Transfer Complete Interrupt Enable: disabled */

  SPI_0_desc.status = SPI_FREE;
}

void SPI_0_enable()
{
  SPI0.CTRLA |= SPI_ENABLE_bm;
}

void SPI_0_disable()
{
  SPI0.CTRLA &= ~SPI_ENABLE_bm;
}

Äh, Moment mal, Register per Struktur beschreiben und Defines für 
Bit-Position und Bit-Maske?

==========================================================================
IO Module Instances. Mapped to memory.
==========================================================================
*/

#define VPORTA              (*(VPORT_t *) 0x0000) /* Virtual Ports */
#define VPORTB              (*(VPORT_t *) 0x0004) /* Virtual Ports */
#define VPORTC              (*(VPORT_t *) 0x0008) /* Virtual Ports */
#define RSTCTRL           (*(RSTCTRL_t *) 0x0040) /* Reset controller */
#define SLPCTRL           (*(SLPCTRL_t *) 0x0050) /* Sleep Controller */
#define CLKCTRL           (*(CLKCTRL_t *) 0x0060) /* Clock controller */
#define BOD                   (*(BOD_t *) 0x0080) /* Bod interface */
#define VREF                 (*(VREF_t *) 0x00A0) /* Voltage reference */
#define WDT                   (*(WDT_t *) 0x0100) /* Watch-Dog Timer */
#define CPUINT             (*(CPUINT_t *) 0x0110) /* Interrupt Controller */
#define CRCSCAN           (*(CRCSCAN_t *) 0x0120) /* CRCSCAN */
#define RTC                   (*(RTC_t *) 0x0140) /* Real-Time Counter */
#define EVSYS               (*(EVSYS_t *) 0x0180) /* Event System */
#define CCL                   (*(CCL_t *) 0x01C0) /* Configurable Custom Logic */
#define PORTMUX           (*(PORTMUX_t *) 0x0200) /* Port Multiplexer */
#define PORTA                (*(PORT_t *) 0x0400) /* I/O Ports */
#define PORTB                (*(PORT_t *) 0x0420) /* I/O Ports */
#define PORTC                (*(PORT_t *) 0x0440) /* I/O Ports */
#define ADC0                  (*(ADC_t *) 0x0600) /* Analog to Digital Converter */
#define AC0                    (*(AC_t *) 0x0670) /* Analog Comparator */
#define DAC0                  (*(DAC_t *) 0x0680) /* Digital to Analog Converter */
#define USART0              (*(USART_t *) 0x0800) /* Universal Synchronous and Asynchronous Receiver and Transmitter */
#define TWI0                  (*(TWI_t *) 0x0810) /* Two-Wire Interface */
#define SPI0                  (*(SPI_t *) 0x0820) /* Serial Peripheral Interface */

Woa, Periphery Module mit Basis-Adresse?

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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

: Bearbeitet durch Moderator
Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> 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 …

Ah okay, wenn es einen Xmega mit CAN gegeben hätte, wäre mir das also 
schon früher aufgefallen. :-)

Tja, hoffen wir mal, dass da noch einiges nach kommt.

Beitrag #5084669 wurde von einem Moderator gelöscht.
Autor: M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
neuer PIC Freund schrieb im Beitrag #4789315:
> machen meine Hoffnung zunichte, dass der ICE
> 12V kann

Dem scheint nicht so zu sein.
Das neueste Atmel-Studio Update7.0.1645 bringt für den ICE im 
Device-Programming Fenster unter Interface Settings eine spezielle 12V 
UPDI Aktivation mit.

Autor: Jürgen H. (calor)
Datum:

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

Autor: Rudolph R. (rudolph)
Datum:

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

Autor: M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen H. schrieb:
> 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?

Das ist halt der Interrupt der eingebauten RTC.
Nutzbar im Sleep-Modus. Wegen der eingeschränkten Clock-Möglichkeiten 
(intern/extern 32kHz) eher für kleine Frequenzen wie eben die Uhrzeit 
geeignet. Ich setze das Teil als gröberen Sekunden-Systick für 
allgemeine Aufgaben ein. Das Int-Flag muß manuell zurückgesetzt werden!

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

Geduld, Geduld. Die sind doch noch nichtmal offiziell angekündigt.
Der geniale 1614 hat immerhin inzwischen den Sample-Status verlassen und 
ist jetzt problemlos und günstig erhältlich.

Autor: Rudolph R. (rudolph)
Datum:

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

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallihallo,
hat jemand ne Ahnung warum in den Datenblättern zu ATTINY814 (S.29) und 
1614 (S.30) die Fuses für UDPI unterschiedlich gesetzt sein müssen? Oder 
hat sich da nur der Fehlerteufel eingeschlichen? Ich hab schon ne Mail 
an Microchip geschrieben, aber noch keine Antwort erhalten. Weiss jemand 
wie der Auslieferungszustand beim ATTINY1614 ist?

Autor: Roger (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Der Fehlerteufel führt Regie.
Das Datenblatt zum 1614/16/17 ist zudem unvollständig.
Im Auslieferungszustand ist immer UPDI aktiv!

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Roger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei den neuen Mega4809 lässt sich das gleich gar nicht mehr 
konfigurieren, die haben einen bleibenden UPDI Pin, was ich für sehr 
sinnvoll finde. Das hätte man auch bei den neuen Tinys machen sollen zum 
Preis etwas weniger Flexibilität, dafür mit unkaputtbarer 
Programmierfähigkeit ohne die Notwendigkeit von speziellen HV 
Programmern für den (verfusten) Ernstfall.

Autor: Bernd S. (bernd_stein)
Datum:
Angehängte Dateien:

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

: Bearbeitet durch User
Autor: Roger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd S. schrieb:
> Konnte schon jemand mittels AVR-Studio 7.0 und dem ATMEL-ICE den
> ATtiny816 programmieren ?

Du kannst schon mit dem Nachfolger ATTiny1616 basteln!
Das würde ich dringend empfehlen, der baugleiche Chip ist kaum teurer, 
bietet aber deutlich mehr! Das Programmieren/Debuggen mit Atmel-ICE via 
UPDI ist über jeden Zweifel erhaben.

> Am liebsten wäre mir natürlich alles bei Reichelt zu bekommen.

Reichelt würde mich schon sehr überraschen wenn sie künftig schneller 
auf neue Chips reagieren würden...

Autor: Bernd S. (bernd_stein)
Datum:
Angehängte Dateien:

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

Autor: Roger (Gast)
Datum:

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

Wenn weniger Pins langen dann aber unbedingt den 1614er nehmen, da ist 
das Gehäuse viel schmaler!

> Zum anderen taucht er im AVR-Studio 7.0.1188 nicht auf.

Nichts einfacher als das: Die aktuelle Version 7.0.1645 installieren!

Autor: Jürgen H. (calor)
Datum:

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

https://github.com/ElTangas/jtag2updi

Autor: Uwe D. (monkye)
Datum:

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

: Bearbeitet durch User
Autor: Bernd S. (bernd_stein)
Datum:

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

Autor: Roger (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Roger schrieb:
> Der Fehlerteufel führt Regie.
> Das Datenblatt zum 1614/16/17 ist zudem unvollständig.

Offensichtlich ist der "Datasheet Preliminary" Status bei Microchip 
jetzt ein Dauerzustand zur Entschuldigung enthaltener Fehler und 
Unvollständigkeiten. Wer im genannten Datenblatt Dinge vermißt empfehle 
ich immer gleich das Datenblatt zu den kompatiblen 8KB Varianten 
814/816/817 zur Hand zu nehmen!

Autor: Bernd S. (bernd_stein)
Datum:

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

Autor: Rolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd S. schrieb:
> Ein 12-Bit ADC hätte mich
> gefreut.

Irgendwas muss die XMegas ja noch von den XTinys unterscheiden :-)

Autor: Bernd S. (bernd_stein)
Datum:

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

Autor: neuer PIC Freund (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nun scheint es offiziell zu werden. Das PicKit4 beherrscht die 12V, was 
das Atmel ICE nicht kann.

D.h. für Speed den ICE, zum Fusen das PicKit4.

Hoffentlich geht der Preis des 4er nicht durch die Decke, wie einst beim 
ICE.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Rudolph R. (rudolph)
Datum:

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

Autor: neuer PIC Freund (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das Atmel ICE hat 10 Pins. 1xNC + 2xGND macht 7 Pins für Signale. Alle 7 
Pins sind über die Dioden (E2) gegen GND geführt.

Beim PK4 vermute ich hinter U11, L2 und D4 einen Boostconverter für 
SW_VPP.

Während Pin5, Pin6, Pin7 und Pin8 beim PK4 durch D7, D10, D8 und D9 
"geerdet" werden (E2, selber marking code wie beim ICE), erfährt Pin4 
(UPDI) eine Sonderbehandlung.

Pin1 von U28 (g9a) ist mit Pin4 des PK4 verbunden. Pin2@U28 führt nach 
D6. Zudem liegt SW_VPP an Pin8@U28 an.

Damit wird vermutlich der 12V-Impuls generiert, der im snap-Dokument als 
"UPDI/HV" gekennzeichnet ist. Hierbei interpretier ich das HV als "high 
voltage".

Das hat auch nichts mit dem Snap-Dingens zu tun (kenne ich auch erst 
seit ein paar Minuten). Lediglich die Bezeichnung mit HV habe ich hier 
erstmals gesehen. Es war halt die Frage offen, mit welchem Tool aus dem 
Hause Microchip kann man die Sparvariante des UPDI "entfusen". Die 
Hoffnung wächst zugunsten des Pickit4.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
neuer PIC Freund schrieb im Beitrag #5529413:
> Es war halt die Frage offen, mit welchem Tool aus dem Hause Microchip
> kann man die Sparvariante des UPDI "entfusen".

Außer dir sehe ich niemanden, der diese Frage hatte.  Alle anderen
würden vermutlich stattdessen auf die gestandenen Atmel-Tools setzen …

Autor: neuer PIC Freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
200€ für ein gestandenes STK600 liegen nicht in jedermanns Budget.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
neuer PIC Freund schrieb im Beitrag #5529639:
> 200€ für ein gestandenes STK600 liegen nicht in jedermanns Budget.

Auf der anderen Seite benötigt "jedermann" auch nicht unbedingt HV prog.
Wenn mir das mal passiert ist habe ich den Controlle eben raus 
geschnitten und einen neuen eingebaut.
Irgendwo habe ich zwar noch Dragons rumliegen, aber egal.
Das hat in den letzten 12 Jahren keine 20 Euro gekostet, aber viel Zeit 
gespart.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Wenn mir das mal passiert ist habe ich den Controlle eben raus
> geschnitten und einen neuen eingebaut.

Oder man speist halt kurzzeitig einen Takt extern ein.
Warum bieten die günstigen Programmer eigentlich so eine Funktion nicht? 
:)

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Oder man speist halt kurzzeitig einen Takt extern ein.

Das hilft dir gar nichts, UPDI ist ohnehin selbstgetaktet. Wenn du dir 
aber /RESET wegdefiniert hast, weil du es als IO-Pin benutzen möchtest, 
dann hilft nur die HV-Version.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
neuer PIC Freund schrieb im Beitrag #5529639:
> 200€ für ein gestandenes STK600 liegen nicht in jedermanns Budget.

Dann kauf dir das Atmel-ICE-PCBA für 50 Euro:

https://www.reichelt.de/debugger-programmer-for-arm-cortex-m-and-avr-atmel-ice-pcba-p190409.html?r=1

Das ist der komplette Programmer, nur halt ohne Kabelsatz und Gehäuse.

Autor: Bernd S. (bernd_stein)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ach, als 8-Pinner kann ich den ATtiny 212 empfehlen.

3x16Bit Timer, D/A, A/D, SPI, I2C, USART, UPDI, 20Mhz.


Bernd_Stein

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.