Auf der elektronica werden wieder neue 8Bitter vorgestellt, Datenblätter sind schon verfügbar: http://www.atmel.com/devices/ATtiny417.aspx http://www.atmel.com/devices/ATtiny814.aspx http://www.atmel.com/devices/ATtiny816.aspx http://www.atmel.com/devices/ATtiny817.aspx
Nett! Scheint so eine Art aufgebohrter ATtiny841 zu sein. Jetzt mit 20 MHz und I²C Master.
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...
Ein 12 bit Timer...das ist ja mal was ganz was neues... Ne, mal Spass beiseite. Die Tinys schauen nett aus
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.
Langsam werden die xmegas wirklich immer obsoleter. Fehlt nur noch eine Tausendfüssler-Version mit dem neuen Kern.
Johann L. schrieb: >> Entire Flash accessible with all LD/ST instructions. Das hätten sie mal etwas früher machen sollen. Nicht mal den Xmegas hatten sie diese nützliche Errungenschaft gegönnt.
Der 814 sieht für mich interessant aus. Ab wann gibt es Preise und Verfügbarkeitsangaben?
@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.)?
Achso, weiter oben steht es ja... sorry (Johann L.)
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é
René H. schrieb: > Der Atmel-ICE kann UPDI. Ich nehme mal an, dass alle neuen "Programmer" > das können. In der Serie ist das schnuppe. Für Bastler ist die Hürde allerdings etwas hoch, dafür eigens einen neuen teuren Programmer/Debugger zu benötigen.
René H. schrieb: > Der Atmel-ICE kann UPDI. Ich nehme mal an, dass alle neuen "Programmer" > das können. Da steht alles drin: http://www.atmel.com/Images/Atmel-42781-Getting-Started-With-ATtiny417-814-816-817_ApplicationNote_AVR42781.pdf
A. K. schrieb: >>> Entire Flash accessible with all LD/ST instructions. > > Das hätten sie mal etwas früher machen sollen. Nicht mal den Xmegas > hatten sie diese nützliche Errungenschaft gegönnt. Naja, das kann man ja am Ende nur machen, wenn Flash + RAM zusammen nie mehr als die 64 KiB Adressraum umfassen, die man mit LD erreicht. Damit fällt sowas für die Xmegas eigentlich von vornherein aus. Johann L. schrieb: > Allerdings müsste dann erst ein neues Variablen-Attribut erfunden > werden, weil progmem ja bereits belegt ist Man könnte ja progmem weiter benutzen und die entsprechenden Funktionen in der Bibliothek passend implementieren. Damit wär' man dann sogar sourcecodekompatibel. Bliebe die Frage, ob Atm^H^H^HMicrochip ihre Jungs in Indien damit betraut, sich um die avr-libc-Anpassungen (und GCC-Anpassungen?) dafür zu kümmern. Bislang sehe ich da noch keine Anzeichen. Vermutlich werden sie IAR rechtzeitig ins Boot genommen haben.
c-hater schrieb: > Auch das Eventsystem und die GlueLogic haben sicher das Potential, Sooo, hier mal ein vorläufiges Datenblatt. Man beachte den Domainnamen. ;) http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42721B-ATtiny-417-814-816-817-Datasheet_Complete.pdf Die Kleber-Logik hat Microchip schon in einigen PICs im Einsatz. Ich bin mal auf die Preise gespannt. Daraus ergibt sich, ob sich projektweise ein Rückschritt vom STM32F0xx rechnet.
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.
> Flash leigt jetzt im RAM-Adressspace
Umgekehrt wäre ebenfalls interessant: Programme laufen im RAM.
Jörg W. schrieb: > A. K. schrieb: >>>> Entire Flash accessible with all LD/ST instructions. > > Johann L. schrieb: >> Allerdings müsste dann erst ein neues Variablen-Attribut erfunden >> werden, weil progmem ja bereits belegt ist > > Man könnte ja progmem weiter benutzen und die entsprechenden > Funktionen in der Bibliothek passend implementieren. Damit wär' > man dann sogar sourcecodekompatibel. An der AVR-LibC würd ich da nix ändern. Auf den RTiny funktioniert progmem ab avr-gcc v7 folgendermaßen:
1 | extern const char __attribute__((__progmem__)) str[]; |
2 | |
3 | const char* pstr (int i) |
4 | {
|
5 | return &str[i]; |
6 | }
|
7 | |
8 | char get (int i) |
9 | {
|
10 | return str[i]; |
11 | }
|
Übersetzt mit -Os -mmcu=avrtiny
1 | pstr: |
2 | subi r24,lo8(-(str+16384)) |
3 | sbci r25,hi8(-(str+16384)) |
4 | ret |
5 | |
6 | get: |
7 | subi r24,lo8(-(str+16384)) |
8 | sbci r25,hi8(-(str+16384)) |
9 | mov r30,r24 |
10 | mov r31,r25 |
11 | ld r24,Z |
12 | ret |
Die Behandlung verschiebt sich also vom Zugriff zur Adressbestimmung. Um Bestandscode weiterhin unverändert verwenden zu können, würd ich an progmem / pgm_read exakt garnix verändern; selbst wenn es durchgehend und konsistent geändert werden würde werden viele Anwender davon nix mitbekommen und unbegeistert[tm] sein. Zudem genügt es beim "normalen" progmem, Definitionen zu attributieren, während im obigen Beispiel dies (auch) für Deklarationen geschehen muss. Ein Attribut am Prototyp ist ausreichend. Für RTiny war die Implementierung naheliegend, und für die o.g. Devices ist es auch wesentlich einfacher als z.B. __flash. Am besten wäre wohl ein Attribute mit Argument wie z.B. offset(0x8000) weil auch andere Speicher wie EEPROM und Fuses in des SRAM-Adressbereich abgebildet werden. Aber alle Adressbereiche im Compiler zu handhaben wäre schon umständlich, weil ja alles durch die specs-Files geschleift werden muss und die Information auch erst mal da sein muß.
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?
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-
Siehe auch hier: http://www.atmel.com/about/news/release.aspx?reference=tcm:26-82053 http://news.silabs.com/press-release/corporate-news/silicon-labs-announces-record-revenue-third-quarter-2016
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.
Immerhin sind diese neuen µC eine deutlich Antwort auf die Frage, ob die 8bit Technologie obsolet ist.
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.
Angehängte Dateien:
-
Building_the_future_with_AVR_MCUs.jpg
81 KB -
Micochip_AVR_Stand.jpg
80 KB -
Evaluation_Kit.jpg
170 KB
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 ...
Steht ja geschrieben im UserGuide-10/2016:
1 | 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.
Angehängte Dateien:
-
syscfg.GIF
56 KB
R.B. schrieb: > Das ist der Normalfall und das ist auch der Auslieferungszustand. Das würde auch mir logisch erscheinen. Das Datenblatt gibt aber an, dass die entsprechenden Konfigurationsbits einen Default-Zuständ von 0x00=GPIO mode haben. Übersehe ich etwas?
R.B. schrieb: > Das ist der Normalfall und das ist auch der Auslieferungszustand. Wo steht eigentlich, was der Auslieferungszustand der Fuses ist?
Axel S. schrieb: > Wenn Microchip schon (vermutlich?) seine Finger da drin hat So eine IC-Entwicklung braucht mindestens zwei Jahre. Du kannst daher völlig vergessen, dass da irgendwas auch nur ansatzweise auf Microchip ausgerichtet worden wäre. Damals hätte bei Atmel noch nicht einmal jemand die Idee gehabt, dass der Laden überhaupt verkauft werden soll (gerade nachgesehen, der "Dialog kauft Atmel"-Thread ist vom September 2015), geschweige denn, dass es ausgerechnet Konkurrent Microchip werden würde. neuer PIC Freund schrieb im Beitrag #4789743: > Steht ja geschrieben im UserGuide-10/2016: Dann erscheint mir diese Variante von UPDI allerdings reichlich kurzsichtig.
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.
Macht mal nen Punkt und lasst die Vernunft sprechen. Welche MCU kommt denn mit deaktiviertem Programmierinterface auf den Markt?
Artur V. schrieb: > Macht mal nen Punkt und lasst die Vernunft sprechen. Na, Vernunft ist doch in dem Zusammenhang kein Argument. Vernünftig wäre es, gar nicht erst mit Mikrokontrollern anzufangen. Das ist wie eine Sucht, man kommt kaum wieder weg von den Dingern, wenn man einmal angefangen hat. :) MfG Paul
Artur V. schrieb: > Macht mal nen Punkt und lasst die Vernunft sprechen. Welche MCU kommt > denn mit deaktiviertem Programmierinterface auf den Markt? 12V programming ist anscheinend immer aktiv.
Tim . schrieb: > 12V programming ist anscheinend immer aktiv. Ja, so wie bei allen Tinies, die schon immer HVSP konnten...
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 …
Kann über das UPDI-Protokoll ein Reset ausgelöst werden?
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.
Artur V. schrieb: > Das sollte den externen Reset-Knopf entbehrlich machen. Klar: da kommt dann ein ATtiny10 dran, der den UPDI-Reset auslöst. :-))
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.
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
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
> tiny817 is not of AVR_TINY architecture, it's actually a xmega2 > according to our classification. It's a XTiny!
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!
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/
Stefan schrieb: > wobei man sich mit einem gratis Upgrade auf einen Jlink aushelfen kann. Gut, den kannte ich noch nicht.
Jörg W. schrieb: > OK, wenn ich mal paar Minuten Zeit habe, probier' ich die andere > Richtung mal aus (auch mit OpenOCD). Ja, geht. Adapter als cmsis-dap wählen, target dann entsprechend für den STM32. Gut, wenigstens mal was, was man herstellerübergreifend benutzen kann, wenngleich vermutlich durch selbige gar nicht beabsichtigt. ;-)
Jörg W. schrieb: > Ich habe gehört, dass Windows solch einen Treiber wohl nun auch endlich > hätte "WinUSB"; wird sogar für ältere Windows-Versionen bis XP auch über Windows Update verteilt. > bin mir aber erstens noch nicht einmal sicher, ob der von Haus aus > aktiv ist Wo kämen wir denn da hin? Dafür muss das Gerät einen speziellen "Microsoft OS feature descriptor" bereitstellen. Immer noch besser als ein Extra-Treiber ...
Beitrag #4832712 wurde von einem Moderator gelöscht.
Die ersten 817 im QFN- Gehäuse sind bei Mouser erhältlich.
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.
Zu ergänzen wären nun noch die neuen 16KB Varianten Tiny1614,1616 und 1617: http://ww1.microchip.com/downloads/en/DeviceDoc/40001893A.pdf
Angehängte Dateien:
-
Tiny1614.jpg
120 KB
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!
Wahrscheinlich einer der letzten die noch von "nur Atmel" entwickelt wurden, also passt der Aufdruck.
unbekannt schrieb: > Wie auf der Produktseite vom 817 angedeutet wird, wird es in Zukunft > auch Tinys mit CAN geben. Das ändert aber leider nichts an der Tatsache, > dass die AT90CAN* mittlerweile auf not recommended for new designs > stehen und es für den 128er keinen wirklichen Ersatz gibt. Letztes Jahr wurden für den AT90CAN Kleinigkeiten im Produktionsprozess geändert, habe aber diese Aussage nirgends gefunden. Haben den AT90CAN in mehreren Produkten im Einsatz (allerdings Kleinserie) und habe derartiges noch nicht vernommen. Auch auf der Produktseite von Microchip steht einfach nur "In Production" und es gibt keinen Hinweis darauf.
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.
Beitrag #5041429 wurde von einem Moderator gelöscht.
Rudolph schrieb: > was mit ARM Kern ohne Microchip/Atmel. Wobei das eine ja mit dem anderen nichts zu tun hat.
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.
Angehängte Dateien:
-
T1614ICE1.jpg
41 KB -
T1614ICE2.jpg
61 KB
Anbei noch ein Einblick in Device-Information und Fuses so wie von AtmelStudio7+Atmel-ICE geliefert.
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:
1 | void SPI_0_init() |
2 | {
|
3 | SPI0.CTRLA = 0 << SPI_CLK2X_bp /* Enable Double Speed: disabled */ |
4 | | 0 << SPI_DORD_bp /* Data Order Setting: disabled */ |
5 | | 1 << SPI_ENABLE_bp /* Enable Module: enabled */ |
6 | | 1 << SPI_MASTER_bp /* SPI module in master mode */ |
7 | | SPI_PRESC_DIV4_gc; /* System Clock / 4 */ |
8 | |
9 | // SPI0.CTRLB = 0 << SPI_BUFEN_bp /* Buffer Mode Enable: disabled */ |
10 | // | 0 << SPI_BUFWR_bp /* Buffer Write Mode: disabled */ |
11 | // | SPI_MODE_0_gc /* SPI Mode 0 */ |
12 | // | 0 << SPI_SSD_bp; /* Slave Select Disable: disabled */ |
13 | |
14 | // SPI0.INTCTRL = 0 << SPI_DREIE_bp /* Data Register Empty Interrupt Enable: disabled */ |
15 | // | 0 << SPI_IE_bp /* Interrupt Enable: disabled */ |
16 | // | 0 << SPI_RXCIE_bp /* Receive Complete Interrupt Enable: disabled */ |
17 | // | 0 << SPI_SSIE_bp /* Slave Select Trigger Interrupt Enable: disabled */ |
18 | // | 0 << SPI_TXCIE_bp; /* Transfer Complete Interrupt Enable: disabled */ |
19 | |
20 | SPI_0_desc.status = SPI_FREE; |
21 | } |
22 | |
23 | void SPI_0_enable() |
24 | {
|
25 | SPI0.CTRLA |= SPI_ENABLE_bm; |
26 | } |
27 | |
28 | void SPI_0_disable() |
29 | {
|
30 | SPI0.CTRLA &= ~SPI_ENABLE_bm; |
31 | } |
Äh, Moment mal, Register per Struktur beschreiben und Defines für Bit-Position und Bit-Maske?
1 | ========================================================================== |
2 | IO Module Instances. Mapped to memory. |
3 | ========================================================================== |
4 | */ |
5 | |
6 | #define VPORTA (*(VPORT_t *) 0x0000) /* Virtual Ports */ |
7 | #define VPORTB (*(VPORT_t *) 0x0004) /* Virtual Ports */ |
8 | #define VPORTC (*(VPORT_t *) 0x0008) /* Virtual Ports */ |
9 | #define RSTCTRL (*(RSTCTRL_t *) 0x0040) /* Reset controller */ |
10 | #define SLPCTRL (*(SLPCTRL_t *) 0x0050) /* Sleep Controller */ |
11 | #define CLKCTRL (*(CLKCTRL_t *) 0x0060) /* Clock controller */ |
12 | #define BOD (*(BOD_t *) 0x0080) /* Bod interface */ |
13 | #define VREF (*(VREF_t *) 0x00A0) /* Voltage reference */ |
14 | #define WDT (*(WDT_t *) 0x0100) /* Watch-Dog Timer */ |
15 | #define CPUINT (*(CPUINT_t *) 0x0110) /* Interrupt Controller */ |
16 | #define CRCSCAN (*(CRCSCAN_t *) 0x0120) /* CRCSCAN */ |
17 | #define RTC (*(RTC_t *) 0x0140) /* Real-Time Counter */ |
18 | #define EVSYS (*(EVSYS_t *) 0x0180) /* Event System */ |
19 | #define CCL (*(CCL_t *) 0x01C0) /* Configurable Custom Logic */ |
20 | #define PORTMUX (*(PORTMUX_t *) 0x0200) /* Port Multiplexer */ |
21 | #define PORTA (*(PORT_t *) 0x0400) /* I/O Ports */ |
22 | #define PORTB (*(PORT_t *) 0x0420) /* I/O Ports */ |
23 | #define PORTC (*(PORT_t *) 0x0440) /* I/O Ports */ |
24 | #define ADC0 (*(ADC_t *) 0x0600) /* Analog to Digital Converter */ |
25 | #define AC0 (*(AC_t *) 0x0670) /* Analog Comparator */ |
26 | #define DAC0 (*(DAC_t *) 0x0680) /* Digital to Analog Converter */ |
27 | #define USART0 (*(USART_t *) 0x0800) /* Universal Synchronous and Asynchronous Receiver and Transmitter */ |
28 | #define TWI0 (*(TWI_t *) 0x0810) /* Two-Wire Interface */ |
29 | #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? :-)
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.
Beitrag #5084669 wurde von einem Moderator gelöscht.
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?
Der Fehlerteufel führt Regie. Das Datenblatt zum 1614/16/17 ist zudem unvollständig. Im Auslieferungszustand ist immer UPDI aktiv!
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...
Angehängte Dateien:
-
ATtiny15__usw.jpg
120 KB
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!
Es gibt wohl mittlerweile alternative Programmier-Lösungen für die neuen Tinys und Megas. https://github.com/ElTangas/jtag2updi
Jürgen H. schrieb: > Es gibt wohl mittlerweile alternative Programmier-Lösungen für die neuen > Tinys und Megas. > > https://github.com/ElTangas/jtag2updi Ja, solange Du einen werksfrischen bzw. nicht verstellten (Fuses) IC verwendest. Ansonsten brauchst Du einen 12V Impuls zum Umstellen. NACHTRAG: Neue Modelle haben dedizierten UDPI-Pin, da sollte es seltener (gar nicht?) möglich sein zu verstellen. Aber man schafft es sicher trotzdem ?
Roger schrieb: > Bernd S. schrieb: >> Auch hier das Problem der Beschaffbarkeit bei niedrigen Versandkosten. > > z.B. 61 Stück bei Digikey für 50€ + MWSt. bei kostenlosem Versand :) > Ja, klar ;-). Will mal zeigen, worum es mir eigentlich ging : Beitrag "China PWM-Solarladeregler Innereien" Sorry, fürs Kapern. Will halt nicht so viele eigene Threads haben, wo ich dann selber nicht mehr durchsteige, denn irgendwie gehört doch alles zusammen. Und ich mag keine Datenleichen-Threads ;-) Bernd_Stein
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
Bernd S. schrieb: > Ein 12-Bit ADC hätte mich > gefreut. Irgendwas muss die XMegas ja noch von den XTinys unterscheiden :-)
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
Angehängte Dateien:
-
Snap_vs_PicKit4.png
30 KB
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.
Angehängte Dateien:
-
AtmeICE_Top.jpg
230 KB -
Pickit4_boost_sw_vpp.jpg
320 KB -
Pickit4_bottom.jpg
240 KB
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 …
200€ für ein gestandenes STK600 liegen nicht in jedermanns Budget.
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.
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.
Ach, als 8-Pinner kann ich den ATtiny 212 empfehlen. 3x16Bit Timer, D/A, A/D, SPI, I2C, USART, UPDI, 20Mhz. Bernd_Stein
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.html https://www.fischerelektronik.de/web_fischer/de_DE/Steckverbinder/G02/Buchsenleisten/$catalogue/fischerData/PG/BL_01/search.xhtml https://www.fischerelektronik.de/web_fischer/de_DE/Steckverbinder/G02/Buchsenleisten/$catalogue/fischerData/PR/BL_11_254/search.xhtml Mit freundlichen Grüßen
Was macht man mit satten 128 Byte RAM sinnvolles? Die Hardwaremodule kann man damit sicherlich nicht alle nutzen.
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.
P. S. Der 412 hätte bei gleicher IC Größe den doppelten Speicher.
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.
Ja das stimmt. "Timer 2" macht keine Sonderlocke mehr. :-)
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...
Ich habe mich schon so daran gewöhnt, dass ich es vergessen habe: interner 20MHz Oszillator.
M. schrieb: > Mein "Mädchen für alles" wär ja der > ATTiny1614... Bei mir ist es der Mega4808 im freundlich TQFP-32.
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.
Thread beobachten
Seitenaufteilung abschalten