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 :)
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.
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...
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.
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...
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.
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.
Oops. Da hat sich ja fast alles verändert. Programmierung/Debugging
inclusive. Geht jetzt alles über einen Pin (sieht aus der Ferne ein
bißchen wie SWIM bei den STM8 aus).
Allein letzteres dürfte die Hemmschwelle für Hobbyisten gehörig
steigern, weil wieder ein neuer Programmier/Debug-Adapter benötigt wird.
Axel S. schrieb:> Allein letzteres dürfte die Hemmschwelle für Hobbyisten gehörig> steigern, weil wieder ein neuer Programmier/Debug-Adapter benötigt wird.
Nicht unbedingt. Ich mein (hab nicht nachgeschaut) das AVRISP MKII kann
PDI, könnte sein dass dafür nur ein Firmwareupdate nötig ist.
Im "Instruction Set Summary" werden auch CALL und JMP aufgeführt obwohl
diese Devices nur 4 bzw. 8 KiB Programmspeicher haben, d.h. RCALL und
RJMP genügen würden. Aus gcc-Sicht sind die Dinger elso wie ein z.B.
ein ATmega16 (-mmcu=avr5) zu behandeln?
Zudem gibt es ein Feature, das ich bisher nur bei den Reduced Tinys mit
16 GPRs gesehen habe:
> Entire Flash accessible with all LD/ST instructions.
Bei den RTiny funktioniert progmem so, dass
1) Daten werden nach .progmem.data* gelegt.
2) Auf die Symboladresse wird 0x4000 addiert (bei den o.g. Teilen wäre
der Offset 0x8000).
Das ist dann wesentlich einfacher, weil kein pgm_read verwendet werden
muss, um aus dem Flash zu lesen. Zudem braucht es keine Qualifier wie
__flash, um ohne pgm_read aus dem Flash zu lesen, was insbesondere für
C++ Liebhaber angenehm ist.
Allerdings müsste dann erst ein neues Variablen-Attribut erfunden
werden, weil progmem ja bereits belegt ist...
M. K. schrieb:> Axel S. schrieb:>> Allein letzteres dürfte die Hemmschwelle für Hobbyisten gehörig>> steigern, weil wieder ein neuer Programmier/Debug-Adapter benötigt wird.>> Nicht unbedingt. Ich mein (hab nicht nachgeschaut) das AVRISP MKII kann> PDI, könnte sein dass dafür nur ein Firmwareupdate nötig ist.
Das ist ja der Punkt. Diese neuen Tinies verwenden kein PDI. Bisher
verwendeten die "normalen" Tinies ISP. Die ganz kleinen TPI. Die xMega
PDI. Diese neuen Tinies jetzt UPDI.
Gut möglich, daß Atmel Firmware-Updates für bestehende Adapter heraus
bringt. Das nutzt nur all jenen, die bisher auf usbasp oder sonst einen
Eigenbau gesetzt haben, recht wenig. Und ich glaube auch eher nicht, daß
Atmel Uraltgeräte wie den Dragon oder das AVRISP unterstützen wird.
Johann L. schrieb:>> Entire Flash accessible with all LD/ST instructions.
Das hätten sie mal etwas früher machen sollen. Nicht mal den Xmegas
hatten sie diese nützliche Errungenschaft gegönnt.
@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.)?
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.
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.
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
Nase schrieb:> Ich setze sehr gerne AVRs ein (z.B. verglichen mit ARM/STM), weil die> AVRs m.M.n. so eine wunderschöne aufgeräumte Hardware an Board haben.> Alles ist irgendwie durchdacht, ...
Mmmh, ich dachte immer "wer Atmel kennt, nimmt was anderes"?
Ein Programm, das mehr als ein ein paar hundert Zeilen Maschinencode
benötigt bzw. in C geschrieben wird, ist heutzutage in einem ARM besser
aufgehoben.
Ich bin Ende der 90er von PIC auf AVR umgestiegen.
Und ich war froh, als NXP und ST vernünftige ARM MCUs auf den Markt
gebracht haben.
In den Jahren hat Atmel meine Kunden und mich viel Geld mit
Datenblattschlampereien gekostet. Ich denke da vor allem an die
AT91RM9200 bzw. AVR32AP. Aber auch die AVRs hatten (haben?) Ihre Tücken
(EMV...).
Über die AT89er wollen wir garnicht reden.
Jörg W. schrieb:> Naja, das kann man ja am Ende nur machen, wenn Flash + RAM zusammen> nie mehr als die 64 KiB Adressraum umfassen, die man mit LD erreicht.
Abschaltbar (bei externem RAM) die ersten 32KB vom Flash auf die zweiten
32KB vom Datenadressraum zu mappen würde meist ausreichen. Könnten die
ganzen Strings drin landen, ohne dass man sich eigens drum kümmern muss.
Jörg W. schrieb:> A. K. schrieb:>>>> Entire Flash accessible with all LD/ST instructions.>> Johann L. schrieb:>> Allerdings müsste dann erst ein neues Variablen-Attribut erfunden>> werden, weil progmem ja bereits belegt ist>> Man könnte ja progmem weiter benutzen und die entsprechenden> Funktionen in der Bibliothek passend implementieren. Damit wär'> man dann sogar sourcecodekompatibel.
An der AVR-LibC würd ich da nix ändern. Auf den RTiny funktioniert
progmem ab avr-gcc v7 folgendermaßen:
1
externconstchar__attribute__((__progmem__))str[];
2
3
constchar*pstr(inti)
4
{
5
return&str[i];
6
}
7
8
charget(inti)
9
{
10
returnstr[i];
11
}
Übersetzt mit -Os -mmcu=avrtiny
1
pstr:
2
subi r24,lo8(-(str+16384))
3
sbci r25,hi8(-(str+16384))
4
ret
5
6
get:
7
subi r24,lo8(-(str+16384))
8
sbci r25,hi8(-(str+16384))
9
mov r30,r24
10
mov r31,r25
11
ld r24,Z
12
ret
Die Behandlung verschiebt sich also vom Zugriff zur Adressbestimmung.
Um Bestandscode weiterhin unverändert verwenden zu können, würd ich an
progmem / pgm_read exakt garnix verändern; selbst wenn es durchgehend
und konsistent geändert werden würde werden viele Anwender davon nix
mitbekommen und unbegeistert[tm] sein.
Zudem genügt es beim "normalen" progmem, Definitionen zu attributieren,
während im obigen Beispiel dies (auch) für Deklarationen geschehen muss.
Ein Attribut am Prototyp ist ausreichend.
Für RTiny war die Implementierung naheliegend, und für die o.g. Devices
ist es auch wesentlich einfacher als z.B. __flash.
Am besten wäre wohl ein Attribute mit Argument wie z.B. offset(0x8000)
weil auch andere Speicher wie EEPROM und Fuses in des SRAM-Adressbereich
abgebildet werden. Aber alle Adressbereiche im Compiler zu handhaben
wäre schon umständlich, weil ja alles durch die specs-Files geschleift
werden muss und die Information auch erst mal da sein muß.
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
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.
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.
Lothar schrieb:> Wäre ja mal ein Grund für diese "Bastler" sich 8-Bit Alternativen> anzusehen, für die es keinen Programmer braucht, und das Debugging schon> ewig über SWD geht:
Oder auch Nicht-8-Bit Alternativen.
Marcus H. schrieb:> Über die AT89er wollen wir garnicht reden.
Ja schade drum, die waren so schön problemlos, störsicher und
zuverlässig.
Ich hätte sie gerne noch weiter eingesetzt, aber die Fab für den
AT89C51RE2 ist ja pleite gegangen.
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!).
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% ...
Lothar schrieb:> laut EMITT
Ich finde darunter nur eine türkische Tourismusmesse. Ob man von
solch einer eine sinnvolle Marktanalyse für Micrcontroller erwarten
kann? :-)
Bei ARM wiederum solltest du genau gucken, was alles in solch eine
Analyse reingezählt wird. Wenn du jetzt alle Smartphones mit einem
Cortex-A mit AVRs in einen Topf wirfst … naja, wie war das gleich
mit der Statistik, die man nicht selbst gefälscht hat?
Lothar schrieb:>> Wenn du jetzt alle Smartphones mit einem Cortex-A mit AVRs>> in einen Topf wirfst>> Cortex-A zählen dabei nicht als MCU
Die nicht. Aber die hardwarenahen Cortex-M, -R und älteren ARMs in
diesen Smartphones schon eher. Im Mobilfunk, WLAN, GPS, Bluetooth, ...
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.
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.
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.
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.
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...
Da sind ja viele Neuerungen eingeflossen.
Beim durchscrollen des Datenblatts fällt auch viel positiv auf.
Bis man beim programming landet -> kein ISP -> uninteressant.
Kauf mir doch jetz kein Programmer nur für die kleine Serie oder kommen
auch bald aufgefrischte atmegas raus?
Wie hier schon einer sagte: das Teil sieht aus wie nen CortexM0 mit
etwas atxmega Würzung.
Hm, dass ihr so am ISP hängt?? Ich finde das eher lästig, da gibts doch
deutlich bessere Alternativen. Allein, dass nicht alle Optionen
verfügbar sind (reset-pin), man oft doch irgendwelche
Hardwarevorkehrungen treffen muss, weil die ISP-pins in der Schaltung
anderweitig verwendet werden, weil auf Kleinstplatinen nicht immer Platz
für zusätzliche 4 Kontaktpins samt routing-Platz gibt? Könnte aus meiner
Sicht gerne aufgeräumt werden.
Ich habe die AVRs immer gerne eingesetzt. Reichen in der Leistung in
vielen Fällen völlig aus. Insgesamt gefällt mir die Struktur
Strombedarf (zu hoch) war schon manchmal ein Thema, mit den pico-power
Typen aber ok.
Die grössern Atmels (AVR32 oder XMega) habe ich eh nie angefasst
Inzwischen sind sie (gemessen an der Leistungsfähigkeit und in
Produktionsstückzahlen) einfach auch zu teuer geworden.
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.
UPDI scheint prinzipiell ein recht einfaches Format zu sein. Auf den
ersten Blick sollten sich die Devices über eine einfache USB2TTL-Bridge
programmieren lassen?
Allerdings sieht es so aus, als wenn man per default den 12V-Modus
benötigt, um in den UPDI-Mode zu kommen? Das entsprechende Fuse-Bit für
den low-voltage mode scheint per default gelöscht zu sein?
Das ist Schade.
Der ISP ist eine Infrastruktur, die man schon hat und gerne weiterhin
nutzen können möchte, egal ob in Fertigung oder Bastelkeller.
Warum nicht beides anbieten und ISP per Fuse abschaltbar machen? Dann
sickert die neue Infrastruktur nämlich durch und in der übernächsten
Chipgeneration kräht keiner mehr.
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? :)
H.Joachim S. schrieb:> Hm, dass ihr so am ISP hängt?? Ich finde das eher lästig, da gibts doch> deutlich bessere Alternativen.
Das ist nicht der Punkt.
Sondern daß ISP bekannt ist. Daß die Hardware existiert und nachweisbar
funktioniert. Dito die zugehörige Software. Und es ist ja auch nicht so,
daß es keine Alternativen von Atmel gäbe. PDI, TPI, dW ... such dir was
aus. Jetzt ein weiteres, inkompatibles Verfahren zu verwenden (und zwar
nicht etwa optional sondern ausschließlich) wird schon ein paar Leute
abschrecken. Wenn ich sowieso auf neue Hardware-Tools und neue Toolchain
wechseln soll, dann doch gleich zu Cortex-M und SWD. Kundenbindung sieht
anders aus.
Mw E. schrieb:> Bis man beim programming landet -> kein ISP -> uninteressant.
Versteh ich gar nicht. PDI ist mir idR viel lieber als ISP weil man
dafür nur zwei Pins braucht und damit auch noch gar debuggen kann.
S. R. schrieb:> Der ISP ist eine Infrastruktur, die man schon hat und gerne weiterhin> nutzen können möchte, egal ob in Fertigung oder Bastelkeller.
Der AVRISP MKII kann PDI und mir erscheint UPDI sehr ähnlich zu sein,
ich denke dass es da ein Update geben wird.
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.
M. K. schrieb:> Versteh ich gar nicht. PDI ist mir idR viel lieber als ISP weil man> dafür nur zwei Pins braucht und damit auch noch gar debuggen kann.
Lesen -> Verstehen -> Posten!
Es ist UPDI, das ist inkompatibel zu PDI.
Atmel hat sich was völlig neues ausgedacht zum proggen dieser Tinys.
Wenn es PDI wäre, dann wärs ja kein Problem.
H.Joachim S. schrieb:> Hm, dass ihr so am ISP hängt?
Naja, wenn man zuvor immer noch die billigsten Programmierer für
dreifuffzich aus Chinaland benutzt hat, dann muss man jetzt natürlich
erstmal warten, bis im Reich der Mitte neue Programmierer für
dreiachtzig entstehen, die auch das neue Protokoll können.
Zumindest das Atmel-ICE werden sie garantiert per Firmwareupdate
aufpolieren, das neue Protokoll zu verstehen. Beim AVRISPmkII
könnte ich mir das auch vorstellen, wenngleich Atmel das schon seit
geraumer Zeit gern langfristig loswerden möchte, weil die USB-ICs
abgekündigt sind, die da drin verbaut werden, sodass man die
Produktion der Geräte über kurz oder lang einstellen müssen wird.
Nicht umsonst war schon der Einstiegspreis eine Atmel-ICE in der
einfacheren Version (in der es auch für ISP geeignet ist) in der
gleichen Größenordnung wie der Preis des AVRISPmkII.
Ich finde das jetzt auch nicht so dramatisch, wird aber für den
finanzschwachen Nachwuchs vielleicht ein konkreteres Problem.
ISP hat ja auch Nachteile bei den wenigen Pins.
Habt ihr zur Verfügbarkeit schon was gesagt? Man muss ja hoffen, dass
eine kürzere Errata entstehen wird als zuletzt häufig.
Mw E. schrieb:> Lesen -> Verstehen -> Posten!> Es ist UPDI, das ist inkompatibel zu PDI.
Das empfehle ich dir auch. Ich hab ja nicht geschrieben, dass es
kompatibel ist. Ich schrieb nur, dass es ähnlich ist und weiter oben
schrieb ich, dass ich mir vorstellen kann, dass entsprechende Programmer
ein Firmwareupdate bekommen werden. ;)
Jörg W. schrieb:> Zumindest das Atmel-ICE werden sie garantiert per Firmwareupdate> aufpolieren, das neue Protokoll zu verstehen. Beim AVRISPmkII> könnte ich mir das auch vorstellen
Was ich hierbei gar nicht verstehen kann: Ich hab das Atmel JTAGICE
MKIII und das AVRISP MKII aber nur letzters kann TPI. Daher bin ich mal
gespannt welche Programmer für UPDI ein Update bekommen werden...
Jörg W. schrieb:> H.Joachim S. schrieb:>> Hm, dass ihr so am ISP hängt?>> Naja, wenn man zuvor immer noch die billigsten Programmierer für> dreifuffzich aus Chinaland benutzt hat, dann muss man jetzt natürlich> erstmal warten, bis im Reich der Mitte neue Programmierer für> dreiachtzig entstehen, die auch das neue Protokoll können.
Das ist noch nicht mal die Hälfte des Problems.
Ein ebenso wichtiger Teil ist die Software auf der Host-Seite. Du
arbeitest ja selber an avrdude und simulavr. Die können mittlerweile
(mal mehr, mal weniger gut) mit JTAG, ISP, PDI, dW programmieren und
debuggen. Bevor da UPDI reingehackt ist, fließt noch eine Menge Wasser
die Elbe runter. Vielleicht kommt das auch gar nie.
Aber eher friert die Hölle zu, als daß ich meine Entwicklungsumgebung
auf Windows umstelle (um das Atmel-Studio verwenden zu können). Und nur
um das erwähnt zu haben: für Cortex-M gibt es eine komplette und gut
funktionierende Toolchain für Linux.
M. K. schrieb:> Ich hab das Atmel JTAGICE MKIII
Das Ding hatte für meine Begriffe ein bedauernswert kurzes Leben.
Die einzig gute Nachricht dafür: du kannst dir das PCB Assembly
für ein Atmel-ICE kaufen, das ist recht preiswert (billiger als
ein Drachen), das passt 1:1 in das Gehäuse des JTAGICE3.
Falls UPDI ähnlich zu PDI ist, dann könnte es natürlich gut sein,
dass sie auch das JTAGICE3 aufpeppen.
Axel S. schrieb:> Bevor da UPDI reingehackt ist, fließt noch eine Menge Wasser> die Elbe runter. Vielleicht kommt das auch gar nie.
Hängt natürlich auch davon ab, wie viel Aufwand es wird, d. h. wie
sehr es sich von den anderen Protokollen unterscheidet.
Interessanterweise hat mich diesmal niemand vorher angesprochen.
> Und nur> um das erwähnt zu haben: für Cortex-M gibt es eine komplette und gut> funktionierende Toolchain für Linux.
Die auch für die Atmel-ARMs mit dem Atmel-ICE problemlos funktioniert.
;)
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.
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.
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.
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!
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.
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.
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]
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 …
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.
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.
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).
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 ...
Important: The Atmel-ICE does not support 12V on the UPDI line. In other words, if the UPDI
2
pin has been configured as GPIO or RESET the Atmel-ICE will not be able to enable the UPDI
3
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.
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.
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.
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.
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?
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.
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.
R.B. schrieb:> Via mEDBG Tool (Ev.Kit) nachgeschaut steht die Fuse "SYSCFG0.RSTPINCFG"> initial auf UPDI mode. Alles andere wäre unlogisch, die Angabe im> aktuellen Preliminary Datenblatt sollte man nicht zu ernst nehmen.
Hast Du Dir dabei ein "frisches" Device angeschaut, oder das auf dem
Xplained-board?
Tim . schrieb:> 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.
Tim . schrieb:> Das würde auch mir logisch erscheinen. Das Datenblatt gibt aber an, dass> die entsprechenden Konfigurationsbits einen Default-Zuständ von> 0x00=GPIO mode haben.
Dachte ich auch erst. Allerdings steht dort auch für OSCCFG.FREQSEL 0-0
drin, was für diese Bits als "Reserved" dokumentiert ist.
Kaffeesatzlesen aus der Formulierung "Enabling of the 1-wire interface,
by disabling the reset functionality, is either done by 12V programming
or by fusing the RESET pin to UPDI by setting the RESET Pin
Configuration (RSTPINCFG) bits in FUSE.SYSCFG0." suggeriert, dass der
Auslieferungszustand "Reset" sei.
Damit haben wir nun Indikatoren für alle 3 Varianten zu Wahl: Aus der
SYSCFG0 Beschreibung ergibt sich unlogischerweise GPIO, das Kit sagt
UPDI und obiger Satz sagt Reset. Ist wohl noch zu früh am Morgen, auch
Datasheets brauchen eine Weile, bis sie den Beta-Status verlassen, vor
allem wenn erheblich neu.
Artur V. schrieb:> Macht mal nen Punkt und lasst die Vernunft sprechen.
Na, Vernunft ist doch in dem Zusammenhang kein Argument. Vernünftig wäre
es, gar nicht erst mit Mikrokontrollern anzufangen. Das ist wie eine
Sucht, man kommt kaum wieder weg von den Dingern, wenn man einmal
angefangen hat.
:)
MfG Paul
Artur V. schrieb:> Macht mal nen Punkt und lasst die Vernunft sprechen. Welche MCU kommt> denn mit deaktiviertem Programmierinterface auf den Markt?
12V programming ist anscheinend immer aktiv.
Tim . schrieb:> 12V programming ist anscheinend immer aktiv.
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!
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.
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.
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"
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!
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
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.)
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...
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?
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.
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.
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...
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 …
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.
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.
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.
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.
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.
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 ...
Ich würde gerne mal ein Projekt mit den Dingern umsetzen (weil sie so
niedlich sind), nur frage ich mich, was ich mit 2 verbleibenden Pins (2
für Strom, 4 für Programmer), im Falle des Tiny102, machen soll? Da kann
man einen Sensor anschließen aber Ausgeben über UART z.B. geht dann
nicht mehr. Wie löst ihr das? Stöpselt ihr nach jedem Flash-Vorgang die
Kabel um (vom Programmer zum Sensor oder ähnlich) oder programmiert ihr
den µC einmal und baut ihn dann erst in die Schaltung?
Max M. schrieb:> 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.
Max M. schrieb:> Ich würde gerne mal ein Projekt mit den Dingern umsetzen (weil sie so> niedlich sind), nur frage ich mich, was ich mit 2 verbleibenden Pins (2> für Strom, 4 für Programmer), im Falle des Tiny102, machen soll? Da kann> man einen Sensor anschließen aber Ausgeben über UART z.B. geht dann> nicht mehr. Wie löst ihr das? Stöpselt ihr nach jedem Flash-Vorgang die> Kabel um (vom Programmer zum Sensor oder ähnlich) oder programmiert ihr> den µC einmal und baut ihn dann erst in die Schaltung?
Atmel hat auch dafür eine Lösung, siehe Anhang.
Bei näherer Betrachtung hat Atmel ja wirklich kein Stein auf dem anderen
gelassen. Auch das gesamt GPIO-Module wurde erneuert und durch eines
ersetzt, wie man es von den Cortexen kennt -> Zusatzregister für Set,
Clear und Toggle.
Dadurch werden einzelne Befehle im AVR-Befehlssatz weniger nützlich, wie
z.B. SBI, CBI.
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.
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.
Tim . schrieb:> wie man es von den Cortexen kennt -> Zusatzregister für Set, Clear und> Toggle.
Oder eben von den Xmegas.
temp schrieb:> Obwohl ein JTAGICEMKII und ICD3 schon die Oberklasse darstellt
Naja, ein JTAGICEmkII ist mittlerweile sehr viel mehr als 10 Jahre
alt. Da musste beispielsweise alles noch per RS-232 machbar sein,
das USB-Frontend ist nur eine Alternative dafür, und auch nur
Fullspeed. Das Design des JTAGICEmkII war mächtig auf den von Atmel
selbst gestrickten Debugger des AVR Studio 4.x getrimmt worden, daher
ist es einerseits relativ teuer (Dual-CPU, ein riesiger RAM, der zum
Runterladen der Zeilennummern-Info ins ICE dient), andererseits war
es natürlich in dieser Kombination mit dem Studio 4 relativ schnell,
da bspw. die Abarbeitung eines highlevel-Singlestep komplett im ICE
erfolgen konnte.
Wenn man jedoch einen generischen Debugger benutzen will, der mit diesen
Features einfach mal gar nichts anfangen kann (GDB-Nutzer traf das schon
immer, und seit dem Umstieg auf Visual Studio nun auch Atmel Studio),
dann ist der Overhead des Protokolls in Verbindung mit dem aus heutiger
Sicht langsamen Fullspeed-USB einfach lahm. Die neueren ICEs (JTAGICE3
und Atmel-ICE) machen daher vieles anders, nicht nur ein schnelleres
USB-Interface, und sie unterscheiden sich zwischen AVR und Cortex-M
praktisch kaum noch.
Wenn du also nicht Äpfel mit Birnen vergleichen willst, dann solltest
du also schon einen AVR mit einem Atmel-ICE benutzen, um diese
Kombination dann gegen einen Cortex-M mit x-beliebigem ICE zu halten.
Übrigens finde ich die „alle Welt muss ein HID sein, weil Windows nur
dafür einen generischen Treiber hat(te)“-Philosophie hinter CMSIS-DAP
ausgesprochene Sch***e. Da wird so viel mehr über den Draht gelabert
als bei einem expliziten Frage-Antwort-Protokoll (wie es das JTAGICE3
anfangs noch benutzte), das geht auf keine Kuhhaut. Das ist aber in
erster Linie natürlich Microsofts Schuld, alle anderen Systeme haben
seit Jahr und Tag generische Treiber, sodass der Nutzer nicht extra
für jedes popelige USB-Gerät einen Treiber installieren muss, nur
Windows hat(te) das eben nicht. Dann erklärt man kurzerhand jeden
Krempel zu einem „Human Interface Device“. Diesem Standard (von
Keil für die Cortexe gesetzt) folgen sie aber nun natürlich alle,
Atmel/Microchip genauso wie STM etc.
Jörg W. schrieb:> Diesem Standard (von> Keil für die Cortexe gesetzt) folgen sie aber nun natürlich alle,> Atmel/Microchip genauso wie STM etc.
STM kocht mit dem STLink sein eigenes Sueppchen. Das ist kein HID.
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
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.
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.
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?
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.
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/
Jörg W. schrieb:> OK, wenn ich mal paar Minuten Zeit habe, probier' ich die andere> Richtung mal aus (auch mit OpenOCD).
Ja, geht. Adapter als cmsis-dap wählen, target dann entsprechend
für den STM32.
Gut, wenigstens mal was, was man herstellerübergreifend benutzen
kann, wenngleich vermutlich durch selbige gar nicht beabsichtigt. ;-)
Jörg W. schrieb:> Ich habe gehört, dass Windows solch einen Treiber wohl nun auch endlich> hätte
"WinUSB"; wird sogar für ältere Windows-Versionen bis XP auch über
Windows Update verteilt.
> bin mir aber erstens noch nicht einmal sicher, ob der von Haus aus> aktiv ist
Wo kämen wir denn da hin? Dafür muss das Gerät einen speziellen
"Microsoft OS feature descriptor" bereitstellen.
Immer noch besser als ein Extra-Treiber ...
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!
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.
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.
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.
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.
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.
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:
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 …
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.
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.
Bisher hatte ich mit den XMegas nichts am Hut. Diese neuen Tinys
scheinen aber recht interessant.
Welche Vorteile/Nachteile bringt der "Periodic Timer Interrupt". Der ist
mir neu. Vergleichbar mit dem SysTick der ARMs?
Würde ich den zum Beispiel als Ersatz für den üblichen periodischen
Timer Overflow nehmen, den man für wiederkehrende Aufgaben z.B. Tasten
entprellen verwendet?
Da der Thread gerade wieder hochgekommen ist, gibt es schon irgendwelche
Infos zu den neuen in den Release-Notes vom Atmel Studio 7.0.1645?
- ATmega4808, ATmega4809
- ATtiny1614, ATtiny3214, ATtiny3216, ATtiny3217
Okay, 1614 gibt es, der 3214 dürfte nur mehr Speicher haben.
Aber zum Rest finde ich gar nichts.
Nach dem Studio:
Atmega4808/Atmega4809: 48k FLASH, 6144 Bytes SRAM, 256 Bytes EEPROM
ATtiny3216/ATtiny3217: 32k/2k/256
Hmm, das Include-File von dem ATmega4808 ist interessant.
Das wirft erstmal alles über den Haufen:
PORTB.DIRSET = PIN0_bm + PIN4_bm;
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.
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.
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?
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.
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.
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
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...
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
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!
Jürgen H. schrieb:> Es gibt wohl mittlerweile alternative Programmier-Lösungen für die neuen> Tinys und Megas.>> https://github.com/ElTangas/jtag2updi
Ja, solange Du einen werksfrischen bzw. nicht verstellten (Fuses) IC
verwendest. Ansonsten brauchst Du einen 12V Impuls zum Umstellen.
NACHTRAG: Neue Modelle haben dedizierten UDPI-Pin, da sollte es seltener
(gar nicht?) möglich sein zu verstellen. Aber man schafft es sicher
trotzdem ?
Roger schrieb:> Bernd S. schrieb:>> Auch hier das Problem der Beschaffbarkeit bei niedrigen Versandkosten.>> z.B. 61 Stück bei Digikey für 50€ + MWSt. bei kostenlosem Versand :)>
Ja, klar ;-). Will mal zeigen, worum es mir eigentlich ging :
Beitrag "China PWM-Solarladeregler Innereien"
Sorry, fürs Kapern. Will halt nicht so viele eigene Threads haben, wo
ich dann selber nicht mehr durchsteige, denn irgendwie gehört doch alles
zusammen. Und ich mag keine Datenleichen-Threads ;-)
Bernd_Stein
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!
M. K. schrieb:> Ein 12 bit Timer...das ist ja mal was ganz was neues...>
Ja, zusätzlich zu den zwei 16-Bit Timern. Ein 12-Bit ADC hätte mich
gefreut.
Bernd_Stein
Rolf schrieb:> Bernd S. schrieb:>> Ein 12-Bit ADC hätte mich>> gefreut.>> Irgendwas muss die XMegas ja noch von den XTinys unterscheiden :-)>
Ja, am besten die Anzahl der Pins ;-)
Bernd_Stein
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.
neuer PIC Freund schrieb im Beitrag #5528487:
> Das PicKit4 beherrscht die 12V, was das Atmel ICE nicht kann.
Woraus schlussfolgerst du aus einer Aussage, die da für „MPLAB Snap“
steht, irgendwas für ein Atmel-ICE? Wenn ich mir die Beschreibung zum
„MPLAB Snap“ ansehe, dann sieht das Ding komplett anders aus als ein
Atmel-ICE. Letztlich scheint es ein PicKit4 ohne 12 V zu sein.
Kann man den PicKit 4 mit dem Atmel-Studio benutzen?
Wobei ich ja fürchte, dass es anders herum kommt und Atmel Studio
eingestellt wird.
Macht Sinn für Microchip, zugegeben, nur werde ich mit dem MPLAB-X nicht
warm - unter anderem weil ich JRE nicht haben will.
Und die dem PicKit3 hatte ich so gar keinen Spass, reichlich zickig
deren Kombination aus USB-Treiber, Firmware und Software.
Zum Glück sind die noch lange nicht soweit, gibt erst Beta-Support für
AVR, solange die SAMs nicht auch unterstützt werden wird es wohl
mindestens AS7 geben.
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.
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 …
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.
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?
:)
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.
Bernd S. schrieb:> 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>
Falls das mit der Reichelt Wunschliste die hier im Forum existiert (
siehe Link oben ) generell nicht funktioniert bzw. Reichelt diese gar
nicht nutzt, ist dies die " offizielle " vorgehensweise.
https://www.reichelt.de//70//index.html?ACTION=70&LA=70&PAGE=14
Wer auch an t r e n n b a r e n, Buchsenleisten im 2,54mm Raster für
Stiftleisten interessiert ist, kann ja auch diesen Text nutzen.
Sehr geehrte Damen und Herren,
mir ist aufgefallen dass sie im 2,54mm Raster gar keine trennbaren
Buchsenleisten zum Aufstecken auf Stiftleisten haben.
Um nicht bei verschiedenen Anbietern bestellen zu müssen, würde ich mich
freuen, wenn sie einen oder beide der unten verlinkten
Fischerelektronik-Artikel in ihrem Sortiment aufnehmen würden.
Evtl. sind dann die Artikel MPE 094-1-xxx und MPE 094-2-xxx dagegen
auszutauschen.
Ich denke bei der Anzahl der Pole sollte die höchste bzw. das beste
Preisleistungsverhältnis gewählt werden. Leider ist mir kein anderer
Anbieter bekannt, der Buchsenleisten zum Aufstecken auf Stiftleisten im
2,54mm Raster, in 8mm Höhe, zum trennen anbietet.
Ich bin erstmal nur an der einreihigen Gabelkontakt-Version
interessiert.
https://www.elv.de/buchsenleiste-1-x-20-polig-1.htmlhttps://www.fischerelektronik.de/web_fischer/de_DE/Steckverbinder/G02/Buchsenleisten/$catalogue/fischerData/PG/BL_01/search.xhtmlhttps://www.fischerelektronik.de/web_fischer/de_DE/Steckverbinder/G02/Buchsenleisten/$catalogue/fischerData/PR/BL_11_254/search.xhtml
Mit freundlichen Grüßen
Bitte schön schrieb:> Was macht man mit satten 128 Byte RAM sinnvolles? Die> Hardwaremodule kann man damit sicherlich nicht alle nutzen.
Limitierend sind die Pins, nicht das RAM. Hier gehts nur um die
Auswahlmöglichkeit.
Hallo,
es ging wohl eher um Bernd, weil er den 212er wie warme Semmeln
anpreist. ;-)
Darf ich fragen was die Leute mit so einem Winzling überhaupt machen?
Abgesehen vom Speichermangel liegen die Usart und SPI auf den gleichen
Pins. Man bekäme gerade so Usart mit Software SPI hin. Die 3 Timer
bleiben dann auf der Strecke? Eingangs- und Ausgangspins hat man dann
auch nicht mehr. Man hat eigentlich viele Hardwareinheiten kann sie aber
nicht nutzen. Deswegen die Frage nachdem Sinn der Teile?
Veit D. schrieb:> Hallo,>> es ging wohl eher um Bernd, weil er den 212er wie warme Semmeln> anpreist. ;-)> Darf ich fragen was die Leute mit so einem Winzling überhaupt machen?> Abgesehen vom Speichermangel liegen die Usart und SPI auf den gleichen> Pins.
Das stimmt so nicht. Die Default-Mux vom Usart und die Default-Mux vom
SPI sind unterscheidliche Pins.
Veit D. schrieb:> Man hat eigentlich viele Hardwareinheiten kann sie aber> nicht nutzen.
Natürlich kann man sie nutzen.
Nur eben nicht alle gleichzeitig sondern in einer Auswahl nur das, was
für die meist begrenzte Spezialaufgabe solcher Controllerschaltungen
eben gerade vonnöten ist. Und langen die Pins dafür nicht mehr aus, mein
Gott, dann nehmen wir das nächstgrößere Gehäuse. Immer vom Einsatzzweck
her denken!
Hallo,
okay, ich hatte den Datenblattlink von Bernd geöffnet, der ist von 2017
und veraltet. Im aktuellen Datenblatt sieht man die MUX Möglichkeiten.
Damit wäre das geklärt. :-)
Das man damit nur spezialisierte Sachen machen kann hatte ich schon
geahnt. Meine Frage ging dahin ob jemand paar Bsp. nennen mag damit ich
mir etwas vorstellen kann was mit den wenigen Möglichkeiten praktisch
gemacht wird?
Ich finde einen Riesenvorteil der neuen Tiny1 und Mega0-Serie, dass sie
nun vollständig regulär aufgebaut sind. Bspw. sind die Timertypen TCA,
TCB oder TCD überall gleich wie auch alle andere interne Peripherie.
Damit kann man ohne etwas am Code zu ändern von einem Typ zu einem
anderen Typ wechseln (etwa wenn die Pins nicht reichen ...).
Das war bei den alten ja ein Krampf: jeder hatte da irgendwelche
Besonderheiten.
Sind doch ne Menge nette Sachen dabei:
-Multiplizierer
-einfacher DAC
-zumindest teilweises Pinrouting
-UPDI
-bessere und einheitlichere Timer wurden ja schon genannt
-rechliche Auswahl an internen Referenzspannungen
-event-System
-deutlich aufgebohrte UART
-TWI als master und slave möglich
und noch einiges mehr. Ich finde die gut :-)
H.Joachim S. schrieb:> Sind doch ne Menge nette Sachen dabei:> -Multiplizierer> -einfacher DAC> -zumindest teilweises Pinrouting> -UPDI> -bessere und einheitlichere Timer wurden ja schon genannt> -rechliche Auswahl an internen Referenzspannungen> -event-System> -deutlich aufgebohrte UART> -TWI als master und slave möglich
Am meisten hat mir bisher genutzt (geordnet):
1) die Regularität der Typen (schneller Wechsel)
2) UPDI (keine Bootloader mehr)
3) Pin-Muxing
4) UART mit Half-Duplex intern und bis zu 4 Stück (mega0)
5) Event-System (viele Anwendungen)
6) CCL (Signalmodulationen)
7) getrennter AC und ADC
8) RTC und PIC
Ich finde die Teile richtig gut.
Veit D. schrieb:> Meine Frage ging dahin ob jemand paar Bsp. nennen mag damit ich> mir etwas vorstellen kann was mit den wenigen Möglichkeiten praktisch> gemacht wird?
Überall dort wo nicht viel Platz und eine fest umrissene Spezialaufgabe
zu erledigen ist. Zum Beispiel als Interface zur Vorverarbeitung von
Sensordaten, in kleinen (Stecker)Gehäusen. Der Controller könnte mehrere
analoge Eingangsquellen (bei reicher Referenzspannungs-Auswahl)
digitalisieren und die Daten dann gemeinsam zur Weiterleitung für
längere Entfernung störsicher digital aufbereiten. Oder gleich als
Interface zu einem Funkmodul arbeiten. Super find ich die neuen TCA
Timer mit ihrer Count on Event Funktion: Den Programmlauf unbelastend
zählt das Teil (höher)frequente Impulse sehr genau, der Wert braucht
dann pro fixer Zeiteinheit nur noch ausgelesen werden. Hab ich bei einem
Windsensor im Einsatz. Mit etwas Fantasie ermöglichen diese kleinen
Wunder-ICs so unendlich viel wofür man früher größere Schaltungen
brauchte, da kann man eigentlich nur ins Schwärmen kommen. Nur eine
Bitte: Lasst den Anschluss A0/Reset/UPDI in Ruhe und bei seiner
vordefinierten Funktion als Programmier-Pin! Im Zweifel lieber einen Typ
mit mehr Anschlüssen wählen! Mein "Mädchen für alles" wär ja der
ATTiny1614...
Wilhelm M. schrieb:> Bei mir ist es der Mega4808 im freundlich TQFP-32
Ja der ist natürlich noch besser. Nur etwas schwerer zu löten, teurer
und mit mehr Platzbedarf. Wenns nach der Leistung geht ist das Ende
klarerweise nach oben offen. Am besten wählt man immer nach der Aufgabe
aus.