Ich überfliege gerade mal das DB eines Tiny 214/414/614. Alle Achtung was die Dinger alles können. Die stecken einen gewöhnlichen Mega locker in die Tasche was Peripherie angeht.. Allein was der ADC schon alles kann, z.B.Sample Accumulation, 115kS/s, WindowComparator... Weiter ist ein DAC an Bord. Sie besitzen einen Hardware-Multiply, 20MHz RC-OSC, RTC, USART, TWI, SPI, 2x16Bit Timer, 12x Bit Timer, Event-System und n Two-Level Interrupt Controller. Das Ganze im bestlerfreundlichen SO-14 :-O Ich habe grade ein kleines Projekt mit einem 441/841 gehabt und war da schon echt überrascht, aber die Neuen können ja nochmal deutlich mehr.
Klingt echt gut, aber wo hast du die Infos gefunden (Datenblatt)?
Ingo L. schrieb: > Ich überfliege gerade mal das DB eines Tiny 214/414/614. Alle Achtung > was die Dinger alles können. Die stecken einen gewöhnlichen Mega locker > in die Tasche was Peripherie angeht. Selbst der ganz kleine Tiny10 (mein Freund), wenn man kaum Pins braucht, günstig und klein.
F. F. schrieb: > Selbst der ganz kleine Tiny10 (mein Freund), wenn man kaum Pins braucht, > günstig und klein. Der Bursche ist leider nur eingeschränkt mit dem GCC beherschbar, wegen seines fehlenden SRAMs. Bin da vor einigen Jahren mal auf den Bauch gefallen. Der Compiler meckert nicht, der Code der ausgeführt wurde entsprach nicht dem was ich programmiert hatte. Ob sich das inzwischen geändert hat weiß ich nicht. Die Dinger sind mit Vorsicht zu behandeln wenn es um den GCC geht. Habs damals dann in ASM gemacht.
Ingo L. schrieb: > wegen > seines fehlenden SRAMs Der ATtiny10 hat doch 32Byte SRAM? Oder meinst du einen anderen Controller?
Beitrag #5140751 wurde von einem Moderator gelöscht.
Ja meint er. Einige Tinys haben das nicht. Ich habe ja explizit vom Tiny 10 geschrieben.
Max M. schrieb: > Der ATtiny10 hat doch 32Byte SRAM? Oder meinst du einen anderen > Controller? Ja, den meine ich. Aber hat der nicht irgendwie nur eingeschränkte GCC Unterstützung, war zumindest vor einigen Jahren so...
:
Bearbeitet durch User
Ingo L. schrieb: > Tiny 214/414/614. Alle Achtung was die Dinger alles können Die sind wohl als Konkurrenz zu den EFM8 gedacht. Aber die EFM8 sind immer noch billiger und haben bessere und mehr ADC/DAC DMA und mehr Timer. Davon abgesehen dass die EFM8 mit Bootloader sind und kein Programmer erforderlich ist.
Lothar schrieb: > Die sind wohl als Konkurrenz zu den EFM8 gedacht Kannte ich garnicht! Sehen ähnlich aus. Ganz soviel Peripherie scheinen sie aber nicht zu haben. Und auch "nur" halb soviel RAM. Gibts dafür auch ne IDE?
Ingo L. schrieb: > Gibts dafür > auch ne IDE? Vom Hersteller gibt es das Simplicity Studio mit Keil 8051 C-Compiler Lizenz (ohne Codegrößenbeschränkung). Lothar schrieb: > Davon abgesehen dass die EFM8 mit Bootloader sind und kein > Programmer erforderlich ist. Ist das so? Wusste ich gar nicht, ich hab dafür einen Programmer mit C2 Interface benötigt. (sowas hier http://www.ebay.de/itm/C8051F-MCU-Emulator-U-EC6-USB-Debug-Adapter-JTAG-C2-Mode-with-Cable-/281861263288?hash=item41a03d8fb8:g:XVcAAOSwLzdWTZ-6)
:
Bearbeitet durch User
Ich hab mir nen Muster vom Tiny1634 schicken lassen, die sind auch nicht übel ;)
Leider scheint die Verfügbarkeit noch nicht sonderlich hoch zu sein bei den x14 :(.
:
Bearbeitet durch User
Ingo L. schrieb: >> Die sind wohl als Konkurrenz zu den EFM8 gedacht > Kannte ich garnicht! Sehen ähnlich aus. Ganz soviel Peripherie scheinen > sie aber nicht zu haben. Und auch "nur" halb soviel RAM Die EFM8 gibt es bis 4K RAM und 64K Flash. Was für Peripherie gibt es nicht? Gibt sogar nativ USB mit Charger, Touch, RTC Max M. schrieb: >> Davon abgesehen dass die EFM8 mit Bootloader sind und kein >> Programmer erforderlich ist. > > Ist das so? Wusste ich gar nicht, ich hab dafür einen Programmer mit C2 Für die werkseitigen UART und USB Bootloader gibt es mittlerweile sogar ein Python-Skript: http://fishpepper.de/2016/10/15/efm8-bootloader-flash-tool-efm8load-py/ Statt C2 geht übrigens auch SWD z.B. mit J-Link braucht nur einen anderen Treiber.
Ingo L. schrieb: > Der Bursche ist leider nur eingeschränkt mit dem GCC beherschbar, wegen > seines fehlenden SRAMs. Das Problem sind eher die 16 fehlenden Register und der geänderte Befehlssatz.
Ingo L. schrieb: > DAC im SO-14 Das finde ich auch nicht gut. Auch dass es nun offenbar gar keine DIP mehr geben soll.
Mit all dem was sie können sind sie auch noch richtig klein (die x16er Varianten sind schon deutlich klobiger da breiter) und bleiben im Pinabstand richtig gut lötbar. Bislang gibt es bei den Tiny x14ern aber leider nur Muster zu erwerben.
Lothar schrieb: > Das finde ich auch nicht gut. Auch dass es nun offenbar gar keine DIP > mehr geben soll. Das finde ich auch zum Kotzen. Erhöht einfach nur den Aufwand für den ersten Prototypen auf Lochraster bzw. Streifenleiter. Aber wird wohl immer mehr zum Dauerzustand werden. Was soll's: Wird halt der Mehraufwand eingepreist und fertig. Wenn sich dadurch dann in der Gesamtbilanz die Waage zugunsten der Konkurrenz neigt, ist das nicht unser Problem, sondern das Problem von Microchip... OK, die werden ganz sicher nicht daran Pleite gehen, wenn wir wechseln. Wenn aber viele Mittelständler aus diesem Grund wechseln, könnte ihnen das wahrscheinlich schon ein wenig wehtun. Es geht ja eigentlich nicht um die paar DIP-Exemplare, sondern auch um die dann NICHT verkauften Inkarnationen im SMD-Package für die Serie. Und die Seriengrößen von vielen Mittelständlern zusammen läppern sich doch ganz schön... Aber klar: solche Entscheidungen fällen BWLer. Die haben naturgemäß keinerlei Ahnung von der Sache und deswegen ist ihnen auch nicht klar, dass sie sich da einfach mal die Zukunft absägen. BWLer können bekanntermaßen ja nur bis zur nächsten Quartalsbilanz denken... Ich weiß jetzt nicht, was es kostet, ein paar Tausend ohnehin produzierte Chips auf ohnehin vorhandenen Packaging-Anlagen in ein DIP-Gehäuse zu packen, sehr viel kann das aber wohl nicht sein. Die paar Dollars wollen diese blinden BWL-Wichser halt sparen. Ich wage vorherzusagen, dass das ein typischer Fall von "ich spare mich zu Tode" werden wird...
Die CCL ist ja der Hit in dieser Klasse. 28. CCL – Configurable Custom Logic 28.1 Features • Glue logic for general purpose PCB design • Up to two Programmable LookUp Tables LUT[1:0] • Combinatorial Logic Functions: Any logic expression which is a function of up to three inputs. • Sequential Logic Functions: Gated D Flip-Flop, JK Flip-Flop, gated D Latch, RS Latch • Flexible Lookup Table Inputs Selection: – I/Os – Events – Subsequent LUT Output – Internal Peripherals • Analog Comparator • Timer/Counters • USART • SPI • Clocked by system clock or other peripherals • Output can be connected to IO pins or Event System • Optional synchronizer, filter, or edge detector available on each LUT output
c-hater schrieb: > Es geht ja eigentlich nicht um die paar DIP-Exemplare, > sondern auch um die dann NICHT verkauften Inkarnationen > im SMD-Package für die Serie. rofl Gleich mal bei diversen Hersteller anrufen das die den Laden dicht machen können weil es deren Teile nicht als DIP gibt.
c-hater schrieb: > Das finde ich auch zum Kotzen. Erhöht einfach nur den Aufwand für den > ersten Prototypen auf Lochraster bzw. Streifenleiter. Also ich hab für SO einen Sockel (für 28 Pin SO) fürs Breadboard. Sowas sollte sich eigentlich auch jeder Mittelständler leisten können wenn ich als Einzelunternehmen mir das leisten kann.
Ingo Less schrieb: > Also ich finde SO nicht so schlimm. QFN wäre schlimmer Das ist unwichtig. Der Punkt ist: du brauchst erstmal einen Adapter für den Prototypen. Und dieser Adapter kostet gelegentlich sogar mehr als der verschissene Chip selber... Auf jeden Fall sehr viel mehr, als ein Aufpreis für den Chip in DIP vom Hersteller kosten würde. Denn der verfügt ja definitiv bereits über die nötigen Fertigungsanlagen. Soll er also gerne den Sonderwunsch DIP-Package mit einem entsprechenden Aufpreis auf Grund der geringen nachgefragten Stückzahl versehen, das wäre sinnvoller BWLer-Einsatz. Aber das Produkt trotz bereits vorhandener Fertigungskapzitäten einfach garnicht anzubieten, ist echt ziemlich unsinnig.
c-hater schrieb: > Das ist unwichtig. Der Punkt ist: du brauchst erstmal einen Adapter für > den Prototypen. Und dieser Adapter kostet gelegentlich sogar mehr als > der verschissene Chip selber... Ja, so SOIC-Adapterplatinen kosten ja...was?...so 5-10 Euro...daran wird ein Prototyp sicher scheitern...
Beitrag #5141286 wurde vom Autor gelöscht.
Simpel schrieb: > Die CCL ist ja der Hit in dieser Klasse Alles vom EFM8 abgeschaut: https://www.silabs.com/whitepapers/how-configurable-logic-revolutionizes-small-microcontroller-applications
c-hater schrieb: > Der Punkt ist: du brauchst erstmal einen Adapter für > den Prototypen. Ja und? Dann baust du dir das eben. Ich habe für die Tiny10 eine Platine mit Nullkraftsockel gebaut, damit kann ich die HV und auch normal programmieren und erst danach löte ich die in eine Schaltung. Gerade wenn man kommerziell entwickelt, dann sollte das doch keine allzu große Rolle spielen.
http://www.ebay.de/itm/Samsung-SA-100QFP-Testsockel-Set-5-teilig-A19-4654-/222101794654?epid=1248492092&hash=item33b64c6f5e:g:PqQAAOSwn1RXI0Mn Das war der teuerste Sockel. Wenn du selbst lötest, dann geht es auch günstiger. http://www.ebay.de/itm/IC51-1004-827-YAMAICHI-Testsockel-QFP-100-polig-A29-5091-/321850520164?hash=item4aefc93264:g:zf0AAOSw0JpV5ZWz Wenn dich das schon umhaut, dann machst du was falsch mit deinem Gewerbe.
Ich war am Anfang auch gegen SMD, weil ich schon mit den THT Bauteilen Probleme hatte. Ein bisschen Übung, Heißluft und die Welt ist schön. Da lohnt es sich schon fast wieder Platinen zu machen.
Lothar schrieb: > Alles vom EFM8 abgeschaut Falls Du es noch nicht mitbekommen hast, hier gehts um die neuen Tinys... Ein AVRler wird doch einen Teufel tun ohne Not auf eine andere Architektur umzusteigen. Ein EFM8 jedenfalls zwingt ganz sicher nicht dazu :) Den Ruf nach DIP kann ich auch nur recht bedingt nachvollziegen. Zum einen bleiben die neuen Tinys durchaus weiter hobby-tauglich handhabbar. Zum anderen ermöglicht SO14 noch kleinere Platinen. Die Xmegas mit denen die neuen Tinys verwandt sind kommen längst nur noch in SMD-Bauformen. Zu beachten ist bei den neuen Tinys die neue 3-Pin Programmier/Debug Schnittstelle UPDI.
mu.s schrieb: > Zu beachten ist bei den neuen Tinys die neue 3-Pin Programmier/Debug > Schnittstelle UPDI. Die alten hatten TPI. DebugWire funktionierte bei mir nie so recht, musste immer wieder anders raus, als es beschrieben war. Vielleicht haben die das ja mit der neuen Schnittstelle im Griff? Aber gibt es ja wohl nur auf dem Papier, die neuen Dinger. Irgendwann 2018 sollen die, laut Atmel, kommen.
M. K. schrieb: > c-hater schrieb: >> Das ist unwichtig. Der Punkt ist: du brauchst erstmal einen Adapter für >> den Prototypen. Und dieser Adapter kostet gelegentlich sogar mehr als >> der verschissene Chip selber... > > Ja, so SOIC-Adapterplatinen kosten ja...was?...so 5-10 Euro...daran wird > ein Prototyp sicher scheitern... Heutzutage kosten solche SOIC/QFP-Adapter fast nichts mehr, wenn man sie rechtzeitig vorher aus China fertig oder bei einem PCB-Service bestellt. Alle anderen halbwegs belieten Chips gibt es fix und fertig als Module aus China. Ich empfand den Wegfall von DIP und den Umstieg auf 3.3V anfangs auch als Drama, aber seitdem es für jeden Sch*** ein Breadboard-Modul aus China gibt, ist mir das egal geworden. Die Zeiten, wo man 15-19 EUR für einen QFP-Adapter bezahlen musste sind endgültig vorbei.
:
Bearbeitet durch User
F. F. schrieb: > Aber gibt es ja wohl nur auf dem Papier, die neuen Dinger. > Irgendwann 2018 sollen die, laut Atmel, kommen. Nein, die 814er sind längst erhältlich, auch die 1614er kann man schon kaufen. TU S. schrieb: > Ich empfand den Wegfall von DIP Na von DIP-Wegfall kann bei den AVRs (im Gegensatz zu vielen anderen und neueren MCUs) ja gerade keine Rede sein. Immerhin werden hier viele Typen auch weiterhin in diesem Gehäuse angeboten.
Mal ne Frage: gibt es wirklich so viele Entwickler die professionelle Protoypen am Breadboard bzw. auf Loch/Streifenraster aufbauen? Ich betreibe das ganze nur als Hobby, aber hab nur meine ersten 3 Platinen auf Lochraster augebaut. Ab einer gewissen Komplexität war mir das ganze Verdrahten einfach viel zu (Zeit-)aufwändig, sodass ich sehr schnell auf PCB (Tonertransfer) und SMD umgestiegen bin, finde das deutlich angenehmer zu verarbeiten, auch von Hand. Und mit dem Ätzen bin ich auch deutlich schneller fertig, als wenn ich die Verdrahtung von Hand mache.
Ich habe mir spezielle Lochstreifenraster machen lassen und mache da auch SMD drauf. So kann ich aber auch noch mal ein THT Bauteil (z,B, ein Poti) drauf machen. Aber auch auf normalen Lochstreifenrasterplatinen kann man bedingt mit SMD arbeiten. Das andere ist mir zu aufwändig. Obwohl wir hier einen Artikel hatten, nachdem habe ich einen Nutzen für ganz kleine Platinchen erstellt und die mit Thermotransfer hergestellt. War natürlich schöner. Denke die Profis machen das eh anders.
Gerd schrieb: > Mal ne Frage: > gibt es wirklich so viele Entwickler die professionelle > Protoypen am Breadboard bzw. auf Loch/Streifenraster aufbauen? > Ich betreibe das ganze nur als Hobby, aber hab nur meine ersten > 3 Platinen auf Lochraster augebaut. Ab einer gewissen Komplexität > war mir das ganze Verdrahten einfach viel zu (Zeit-)aufwändig, sodass > ich sehr schnell auf PCB (Tonertransfer) und SMD umgestiegen bin, > finde das deutlich angenehmer zu verarbeiten, auch von Hand. > Und mit dem Ätzen bin ich auch deutlich schneller fertig, als wenn > ich die Verdrahtung von Hand mache. Die Breadboard-Aufbauten mache ich auch nur bei relativ einfachen Projekten. Wenns komplizierter/Komplexer wird gibts auch bei mir ein extra PCB dafür aus den von dir schon genannten Gründen. Daher sehe ich das Problem auch nicht, den der Wegfall der DIP-Technologie bringen soll.
Hallo: ich habe hier http://ww1.microchip.com/downloads/en/DeviceDoc/40001912A.pdf ein Datenblatt über eine neue Reihe von MCUs gefunden, (c) Datum ist 2017. Nach dem ersten Überlesen klingt das interessant... Hat jemand so eine MCU schon mal in freier Wildbahn angetroffen? Kann man die (schon) kaufen? Wenn ja, wo (Standard-Läden haben nichts...)? Ist das ein Indiz dafür, das Microchip die Atmel-Sachen dann doch aktiv weiterentwickelt? RFC. /sigma9
sigma9 schrieb: > Microchip die Atmel-Sachen dann doch aktiv weiterentwickelt? Das ist schwer anzunehmen. Man kauf kein Unternehmen wie Atmel für zig Millionen und versenkt es dann. Mircochip hat damit nur zwei Fliegen mit einer Klappe geschlagen: Ein Konkurrent weniger und das Portfolio erweitert.
sigma9 schrieb: > Microchip die Atmel-Sachen dann doch aktiv weiterentwickelt? Die Datenblätter jedenfalls werden proaktiv zurückentwickelt. SCNR
Johann L. schrieb: > Die Datenblätter jedenfalls werden proaktiv zurückentwickelt. > > SCNR Hmm. Das ist für mich wirklich interessant. Kannst du bitte nur ein oder zwei konkrete Beispiele liefern, die dir derart negativ aufgefallen sind? Das würde mir einiges an Arbeit ersparen. Bitte auch mit den Links zu "alter" (guter) Version und "zurückentwickelter" Version. Wenn die gute Version nicht mehr im Web erreichbar ist, kein Ding, einfach irgendwas hinschreiben, was den Sachverhalt klarstellt. TIA
F. F. schrieb: > Guck sie dir doch an! Bunter, aber weniger ausführlich. Genau die Arbeit wollte ich mir ja gerade ersparen... Und was das "weniger ausführlich" betrifft: 'drauf geschissen. Solange nur alle relevanten Fakten erhalten bleiben, kann ich auf verbale Weitschweifigkeit problemlos verzichten. Allerdings: Ich kenne die "historischen" Datenblätter der AVR8 doch ziemlich gut, sogar so gut, dass ich darin nur noch relativ selten wirklich etwas lesen muss (Nachschlagen muss ich natürlich trotzdem ständig, ich bin ja kein Computer). Ich kann mich jedenfalls nicht erinnern, dass die Beschreibungen sich durch exorbitante Weitschweifigkeit ausgezeichnet hätten, die waren im Gegenteil doch immer schon recht kurz und knackig, manchmal vielleicht sogar schon etwas zu kurz (insbesondere bezüglich des Taktsystems und des Analogteils). Ich kann mir nicht vorstellen, wie man diese DBs noch nennenswert kürzen könnte, ohne unverzichtbare Informationen über den Jordan zu fegen. Genau deswegen suche ich ja nach konkreten Hinweisen, wo das passiert ist, ohne sie selbst suchen zu müssen... Da Johann L. nach eigenem Bekunden ja sowas gefunden haben will, sollte es für ihn kein Problem darstellen, eben diese Fundstellen zu veröffentlichen. Ich habe ihn nur nett gebeten, eben dies zu tun...
c-hater schrieb: > Da Johann L. nach eigenem Bekunden ja sowas gefunden haben will, sollte > es für ihn kein Problem darstellen, eben diese Fundstellen zu > veröffentlichen. Ich habe ihn nur nett gebeten, eben dies zu tun... Das soll er mal machen. Ich hatte über die neuen Controller "nur mal drüber geguckt" und eher das Gefühl, dass es "schmaler" ausfällt. Klar für dich und für jeden, der das Durcharbeiten schon einmal hinter sich hat, sucht nur noch die nötigen Sachen raus und braucht keine Erklärung mehr drum rum. Da das Prinzip doch irgendwie immer gleich ist, liest sich dann ein anderes Datenblatt dann auch leichter.
Angehängte Dateien:
-
mmap-atmel.png
9,8 KB -
mmap-michip.png
22 KB
Hier z.B. 2 Grafiken in gleicher Zoom-Stufe. Gezeigt ist das Speicherlayout vergleichbarer µCs: ATtiny41x/81x einerseits und ATtiny161x andererseits. Das eine ist gut lesbar, bei dem anderen ist kann man nur raten, ob APPEND (sic!) bei 8FFF oder BFFF ist. Die unterschiedlichen Adressbereiche für LPM resp. LD* sind nicht mehr ersichtlich. Es ist zwar später ausgetextet, aber warum entfernt man das? In den "alten" Dokumenten ist auch ganz nett, dass Querverbindungen zwischen einzelnen Funktion-Units verlinkt werden. Bei den "neuen" wurden viele dieser Verlinkungen einfach entfernt. Und das alles ohne Not — wenn Microchip Atmet übernimmt, dann doch auch die Dokument- und Grafikquellen. Insgesamt ist das neue Datenblatt ca 70 Seiten kürzer: Das letzte wesentliche Kapitel endete einst auf Seite 558, jetzt auf Seite 485.. Das sind mehr als 70 Seiten bzw. 13%. Vielleicht ja nur neu formatiert oder unwichtige Links entfernt... aber damit 70 Seiten wegschrumpfen? So verschwenderisch sieht der alte Seitenspiegel eigentlich nicht aus. Wirklich intensiv hab ich mich mit diesen neuen µCs nicht auseinandergesetzt, eben nur soweit, wie es für die neue Architektur in Binutils / GCC erforderlich war. Die Information sollte dann aber bitte verlässlich sein, immerhin sind Tools ein netter Bug-Multiplikator. Da bin ich dann gleich darüber gestolpert, dass Microchip schreibt: >> Vertical migration [also z.B. von ATtiny81x zu Attiny16x] >> can be done upwards without code modification. Und die Vektorgröße als 2 spezifiziert, d.h. Vektor no. 1 liegt an Adresse 0x2 von ATtiny21x bis ATtiny161x. Anfrage bei Microchip ergab, dass die Vektor-Adresse in Bytes angegeben sei. Und das Statement über Binärkompatibilität sei ein Tribut ans Marketing und würd sich ja ganz nett machen :-)
Johann L. schrieb: > Das eine ist gut lesbar, bei dem anderen ist kann man nur raten, ob > APPEND (sic!) bei 8FFF oder BFFF ist. Schon mal die Zoomfunktion des Readers benutzt? Johann L. schrieb: > In den "alten" Dokumenten ist auch ganz nett, dass Querverbindungen > zwischen einzelnen Funktion-Units verlinkt werden. Ist doch aktuell immer noch so oder was genau meinst du? Klar, mir hat das alte Design von Atmel bzgl. der Datenblätter auch besser gefallen, das blaue Logo war/ist beim Lesen ein angenehmer Kontrast aber bzgl. Informationsgehalt finde ich die neuen Datenblätter von Microchip bzgl. der AVRs genauso gut wie die alten Datenblätter von Atmel. Das Design ist bei Microchip halt anders, daran muss man sich halt erst gewöhnen.
Morgen, c-hater schrieb: > Kannst du bitte nur ein oder > zwei konkrete Beispiele liefern, die dir derart negativ aufgefallen > sind? ja z.B. ATmega328PB die Registerbeschreibungen für die neuen zusätzlichen Timer 3 und 4 sind teilweise völlig falsch. Da hat irgend jemand vom Timer 1 den Text kopiert und nicht angepasst. T 3/4 haben auch noch einen anderen größeren Funktionsumfang als der T 1, von daher ist das Teil ein richtiges Rätselraten....
Toralf W. schrieb: > Morgen, > > c-hater schrieb: >> Kannst du bitte nur ein oder >> zwei konkrete Beispiele liefern, die dir derart negativ aufgefallen >> sind? > > ja z.B. ATmega328PB die Registerbeschreibungen für die neuen > zusätzlichen Timer 3 und 4 sind teilweise völlig falsch. Da hat irgend > jemand vom Timer 1 den Text kopiert und nicht angepasst. T 3/4 haben > auch noch einen anderen größeren Funktionsumfang als der T 1, von daher > ist das Teil ein richtiges Rätselraten.... So etwas ist mir auch schon aufgefallen. Teilweise stimmen auch Bezeichner nicht. Da fehlen dann z.B. die 0 weil der Bezeichner eigentlich TIMSK0 heißen muss, im Datenblatt aber nur TIMSK steht. Ich mein aber, das Problem gabs schon früher. Anmerkung: TIMSK hab ich mir jetzt nur einfallen lassen da mir der konkrete Bezeichner, bei dem ich über besagtes Problem gestolpert bin, nicht mehr einfällt. EDIT: Ich habs gefunden. Datashett vom Atmega328P: Nicht TIMSK1 war sondern ein Bit in TIMSK1: Beim Register steht TOIE, tatsächlich heißt es aber TOIE1 (der avr-gcc meckerte, dass er TOIE nicht kannte). Noch besser sind die OCIEA und OCIEB. Da beginnt dann quasi das Raten wo die 1 hinkommt. War aber schon zu Atmel-Zeiten ein "Problem" ;)
:
Bearbeitet durch User
Is mir auch schon aufgefallen zB beim m644p DB. Beim T0 steht in der Registerbeschreibung CS[2:0]. In der Tabelle steht dann CA2 CA1 CS0. Lernt tippen...
Mw E. schrieb: > Is mir auch schon aufgefallen zB beim m644p DB. > Beim T0 steht in der Registerbeschreibung CS[2:0]. > In der Tabelle steht dann CA2 CA1 CS0. > Lernt tippen... Und tatsächlich heißen die Bits wahrscheinlich CS02, CS01 und CS00, oder?
Ingo L. schrieb: > Ich überfliege gerade mal das DB eines Tiny 214/414/614. Sehe ich das richtig, daß die Register nicht mehr über LD/ST erreicht werden? In Assembler sieht man ja oft, daß R1..R29 in einer Loop genullt werden. Das geht dann nicht mehr.
M. K. schrieb: > Johann L. schrieb: >> Das eine ist gut lesbar, bei dem anderen ist kann man nur raten, ob >> APPEND (sic!) bei 8FFF oder BFFF ist. > > Schon mal die Zoomfunktion des Readers benutzt? Ja. Diese Funktion ist mir bekannt. Sie skaliert allerdings Grafiken und Fließtext, so dass der Fließtext dann inadäquat groß wird. Das alte Dokument hat hier ein deutlich besseres Layout / Typographie, un dohne Not wurde da was verschlimmbessert. > Johann L. schrieb: >> In den "alten" Dokumenten ist auch ganz nett, dass Querverbindungen >> zwischen einzelnen Funktion-Units verlinkt werden. > > Ist doch aktuell immer noch so oder was genau meinst du? Teilweise ja, aber es wurden auch Links entsorgt; warum auch immer. Ein Beispiel unter vielen: An Ende von "6.6 User Row": Atmel: >> Related Links >> Memory Map on page 22 >> NVMCTRL - Non Volatile Memory Controller on page 62 >> UPDI - Unified Program and Debug Interface on page 503 Microchip: >> Related Links >> NVMCTRL - Non Volatile Memory Controller >> UPDI - Unified Program and Debug Interface Zunächst fällt auf, dass ein Link entsorgt wurde; und das ist nicht die einzige Stelle. Dann fehlen die Seitenzahlen, was in einer Print-Version überaus lästig ist, nicht unülich ist, auch die Kapitel-Numerierung anzugeben, was hier problemlos möglich wäre da die Links nicht im Fließtext stehen sondern in einer abgesetzten Liste nach der Prosa.. Entweder verwenden die ein Tool, das das nicht kann (sehr unwahrscheinlich) oder jemand hat ein paar Bucks bekommen, um die Dokumente zu "überarbeiten" und globale Konfigurationen "optimiert". Für Seitenspiegel und Branding / Corporate Identity kann man das erwarten, wobei Microchip wohl auch die Rechte an "Atmel" als Marke erworben hat und einfach weiter hätte verwenden können. > bzgl. Informationsgehalt finde ich die neuen Datenblätter von > Microchip bzgl. der AVRs genauso gut wie die alten Datenblätter von > Atmel. Ja, die Datenblätter sind sehr gut im Vergleich zu anderen Herstellern. Ich finde nur die Richtung irritierend, in der sich die Qualität entwickelt.
:
Bearbeitet durch User
Peter D. schrieb: > Ingo L. schrieb: >> Ich überfliege gerade mal das DB eines Tiny 214/414/614. > > Sehe ich das richtig, daß die Register nicht mehr über LD/ST erreicht > werden? > In Assembler sieht man ja oft, daß R1..R29 in einer Loop genullt werden. Oft? M.E: kein großer Verlust. Wozu sollte man alle Register nullen müssen? Und für einen Taskwechsel kommt's eher auf's Timing an, da will man lieber ohne Schleife arbeiten und etwas längeren Code tolerieren.
Angehängte Dateien:
Johann L. schrieb: > Ja. Diese Funktion ist mir bekannt. Sie skaliert allerdings Grafiken > und Fließtext, so dass der Fließtext dann inadäquat groß wird. Ich hab mal rein gezoomt und finde die Skalierung des Textes ist völlig OK, siehe Anhang. Da sehe ich nicht wirklich ein Problem. Johann L. schrieb: > Zunächst fällt auf, dass ein Link entsorgt wurde; und das ist nicht die > einzige Stelle. Dann fehlen die Seitenzahlen, was in einer > Print-Version überaus lästig ist, nicht unülich ist, auch die > Kapitel-Numerierung anzugeben, was hier problemlos möglich wäre da die > Links nicht im Fließtext stehen sondern in einer abgesetzten Liste nach > der Prosa.. Yo, ein Link wurde entfernt. Finde ich aber auch nicht wirklich schlimm, ganz im Gegenteil. Der Link würde nämlich nur auf den Kapitelanfang verweisen. Das ist etwas, was ich in den Atmel Datenblättern bisher immer ziemlich überflüssig fand. Dass keine Seitenzahlen bzw. Kapitel angegeben sind, da, finde ich, hast du recht. Für ne gedruckte Version ist das relativ blöd. Auf der anderen Seite: Wer druckt heute noch 500 Seiten Datenblätter aus? Ein wirklicher Verlust ist das IMO nicht.
M. K. schrieb: > Johann L. schrieb: >> Ja. Diese Funktion ist mir bekannt. Sie skaliert allerdings Grafiken >> und Fließtext, so dass der Fließtext dann inadäquat groß wird. > > Ich hab mal rein gezoomt und finde die Skalierung des Textes ist völlig > OK, siehe Anhang. Da sehe ich nicht wirklich ein Problem. Und wie groß ist denn der folgende Fließtext? Der Text in der Grafik ist kein Fließtext sondern Grafik.
Johann L. schrieb: > Der Text in der Grafik ist kein Fließtext sondern Grafik. Öhm, nein. Der ist auch Text (kannst du markieren und kopieren ;)). Wenn man natürlich das Dokument mit 200% Zoomstufe öffnet hat selbstverständlich auch der nachfolgende Fließtext 200% Zoomstufe aber genau das hat man mit dem Zoom ja auch gewollt.
:
Bearbeitet durch User
M. K. schrieb: > man natürlich das Dokument mit 200% Zoomstufe öffnet hat > selbstverständlich auch der nachfolgende Fließtext 200% Zoomstufe aber > genau das hat man mit dem Zoom ja auch gewollt. Die Antort eines Technokraten :-/
Johann L. schrieb: > Die Antort eines Technokraten :-/ Naja, wenn ich die Handlupe auf dem Schreibtisch über das ausgedruckte Datenblatt halte wird auch nicht nur Grafik vergrößert sondern schlicht alles vor der Linse.
M. K. schrieb: > Johann L. schrieb: >> Die Antort eines Technokraten :-/ > > Naja, wenn ich die Handlupe auf dem Schreibtisch über das ausgedruckte > Datenblatt halte wird auch nicht nur Grafik vergrößert sondern schlicht > alles vor der Linse. Ein Dokument mit gutem Layout macht es erst garnicht erforderlich, eine Lupr für eine Grafik verwenden zu müssen. Betrachtet man das Dokument am Bildschirm, ist ein Layout vorzuziehen, dass nicht dauern eine Reskalierung zwischen Grafik und Fließtexten oder enderen Elementern erfordert um deren Lesbarkeit / optimale Darstellung zu gewährleisten. Aber lassen wir das, Typographie und Layout sind hier einerseits Off-Topic, zum anderen kann ich mich des Eindrucks nicht erwehren, dass du absichtlich nicht verstehen willst, was ich zum Layout anmerkte.
Johann L. schrieb: > Aber lassen wir das, Typographie und Layout sind hier einerseits > Off-Topic, zum anderen kann ich mich des Eindrucks nicht erwehren, dass > du absichtlich nicht verstehen willst, was ich zum Layout anmerkte. Ich verstehe schon, was du meintest, ich sehe da nur kein Problem drin weil man, meiner Meinung nach, eh nicht sooo oft da rumzoomt. Da redest du dir, denke ich, nur etwas ein. Aber ich bin ja auch auf deiner Seite, ich fand die Atmel Datasheets auch besser bzgl. Optik. ;)
M. K. schrieb: > Aber ich bin ja auch auf deiner Seite, > ich fand die Atmel Datasheets auch besser bzgl. Optik. Und es war definitiv mehr nützliche Information drin. Zum Beispiel vermisse ich die schönen Tabellen zur UART-Initialisierung nach Taktfrequenz (auch wenn sich das jeder ausrechnen kann). Aber um mal zum Thema zurückzukommen: Die x14 Tinys sind echt geile Teile :)
M. schrieb: > Und es war definitiv mehr nützliche Information drin. > Zum Beispiel vermisse ich die schönen Tabellen zur UART-Initialisierung > nach Taktfrequenz (auch wenn sich das jeder ausrechnen kann). Nicht nur ausrechnen, wer zum Rechnen zu faul ist schaut einfach in ein Datasheet rein, in dem die Tabelle drin ist ;) M. schrieb: > Aber um mal zum Thema zurückzukommen: Die x14 Tinys sind echt geile > Teile :) Finde ich auch, sehen höchst interessant aus.
Beitrag #5143787 wurde von einem Moderator gelöscht.
Hi Habt ihr eigentlich alle ein Jahr geschlafen? Das erste Datenblatt dieser ATTinys stammt von *09/16*. Da stand schon alles wesentliche zu diesen AVRs drin. Warum tun jetzt alle auf einmal so überrascht? MfG Spess
Also ich komme mit dem neuen Datenblatt überhaupt nicht mehr klar, insbesonde mit dem Memory Map. Wo startet denn nun das Programm im Flash, an 0x0000 oder 0x0800? Was ist bei Verwendung des Bootloaders, muß ich dann die Applikation umcompilieren auf Resetvektor = BOOTEND? Muß ich dann die Interruptvektortabelle umstellen? Bei den alten AVRs startet ja die Applikation immer an 0x0000, d.h. die hat gar nicht interessiert, ob ein Bootloader vorhanden ist oder nicht. Es scheint so, der neue AVR braucht zwingend eine neu compilierte Applikation für den Start mit Bootloader und in der Init-Section muß das IVSEL gesetzt werden.
Beitrag #5143876 wurde von einem Moderator gelöscht.
spess53 schrieb: > Habt ihr eigentlich alle ein Jahr geschlafen? Das erste Datenblatt > dieser ATTinys stammt von *09/16*. Da stand schon alles wesentliche zu > diesen AVRs drin. Also ich bekomme nicht jede Veröffentlichung mit, daher darf mich sowas schon überraschen. Vor allem da die Chips erst jetzt verfügbar werden. Peter D. schrieb: > Wo startet denn nun das Programm im Flash, an 0x0000 oder 0x0800? Bei welchem AVR startet das Program bei 0x0000? Fällt mir spontan mal keiner ein (oder ich steh grad auf dem Schlauch und seh nicht was du meinst). Der Bootloader ist aber IMO gewandert, der war immer ganz am Ende, ist jetzt an den Anfang des Flash-Speichers gewandert. Welchen Vorteil das hat...darüber hab ich mir noch keine Gedanken gemacht.
spess53 schrieb: > Hi > >>Bei welchem AVR startet das Program bei 0x0000? > > Eigentlich alle außer diesen ATTinys. > > MfG Spess Öhm, die MM des Atmegas 328 (hab ich grad offen) sieht quasi identisch aus mit dem dieser Attinys mit dem Unterschied, dass der Bootloader beim Atmega328 am Ende des Flashspeichers ist während er bei diesen Attinys am Anfang des Flashspeichers ist. Erst kommen die Arbeitsregister, dann die IO Register, dann die ext. IO Register usw.
Peter D. schrieb: > Wo startet denn nun das Programm im Flash, an 0x0000 oder 0x0800? Flash-Adressen starteb bei 0x0, und die Sicht auf's Flash im RAM-Adressbereich strtet bei 0x8000 (nicht: 0x0800). Wenn also per LPM von Adresse A gelesen wird, dann wird per LDS von Adresse A+0x8000 gelesen. Um all das brauchst du dich aber nicht zu kümmern, vorausgesetzt zu setzt Tools ein, die das unterstützten. Zum Beispiel kümmert sich das default Linkerskript für diese Familie (-mmcu=avrxmega3) automatisch darum. Im Compiler "beachtet" man das dadurch, dass man komplett auf __flash und progmem und pgm_read_xxx verzichtet. Es scheint aber so, dass es nach 20 Jahren getrennter Adress-Spaces kaum mehr jemandem möglich ist, in dieser Kategorie zu denken :-/
Hi >Erst kommen die Arbeitsregister, dann die IO Register, dann die ext. IO >Register usw. Die Zählen eigentlich zu RAM und nicht zum Flash. Haben auf das Programm keinen Eifluss. Und ein AVR ohne dieses Bootloadergedödel startet immer bei Flashadresse 0x0000 (außer der hier genannten ATTinys). Mit Bootloader started das Programm auf den mit BOOTSZ1/0 festgelegten Adressen. MfG Spess
Ah ja, jetzt seh ichs...hm, OK. Ist ne Änderung...hat das Vor-/Nachteile für "uns"?
Johann L. schrieb: > Peter D. schrieb: >> Wo startet denn nun das Programm im Flash, an 0x0000 oder 0x0800? > > Flash-Adressen startet bei 0x0, und die Sicht auf's Flash im > RAM-Adressbereich startet bei 0x8000 (nicht: 0x0800). > > Wenn also per LPM von Adresse A gelesen wird, dann wird per LDS von > Adresse A+0x8000 gelesen. Das hatte ich etwas missverständlich ausgedrückt. Besser: Wenn LPM Z von Adresse A liest (weil Z-Reg den den Wert A hat) dann liest LD Z von Adresse A-0x8000. Um also von der gleichen Zelle wie LPM zu lesen, muss bei LD ein Offset von 0x8000 zur Adresse hinzuaddiert werden, nicht abgezogen. Bei 16-Bit Adressen und 0x8000 ist das zwar egal, aber bei einem Offset von 0x4000 (wie z.B. bei ATtiny40) nicht mehr. Außerdem behandeln die Tools die Adressen intern als 32 Bit. Nachteil hat das keinen. Der Vorteil ist ein linearer Adressraum, d.h. man braucht z.B. in C keine Named Address Spaces wie __flash um auf's Flash zuzugreifen. Vorteile bringt das auch in C++, denn erstens kennt C++ keine Named AS (auch C nur als nicht-Standard Erweiterung), und zweitens ist es technisch nicht möglich, vtables per LPM zuzugreifen, siehe z.B. Erklärung in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745#c13 Mit linearem Speicher kann .rodata im Flash bleiben und brauch nicht ins RAM kopiert zu werden. Auf Sprachebene (C, C++, Assembler) bekommt man davon nichts mit, auch nicht von der Addition von 0x8000 für avrxmega3 bzw. von 0x4000 für avrtiny: Das erledigt das ld Skript zur Link-Time. Zudem hat man mehr Adressierungsarten zur Verfügung: Nicht nur Z und Z+, sondern alle erlaubten Adressierungen von LD*. Bei
1 | extern const char val; |
braucht also nicht erst die Adresse nach Z geladen zu werden, sondern der Wert kann einfach per LDS gelesen werden, und ld Sktipt addiert 0x8000 auf Symbol "val". Der Code ist also einfach "LDS val", und falls "val" zur Compile-Time bekannt ist, deht's noch effizienter (wie etwa mich __flash vs. pgm_read_xxx: letzteres ich nicht transparent).
Ja, man muß vieles erst herauslesen. Mit Bootloader muß man den Start der Applikation auf BOOTEND.Fuse*256 linken und die Applikation muß IVSEL setzen. Die Applikation muß also genau wissen, wie groß der Bootloader ist. Das ist schon umständlicher und fehlerträchtiger, als mit Bootloader am Ende.
Peter D. schrieb: > Die Applikation muß also genau wissen, wie groß der Bootloader ist. > Das ist schon umständlicher und fehlerträchtiger, als mit Bootloader am > Ende. Bei den EFM8 ist der werkseitige Bootloader in der letzten Flash-Page die durch ein Security-Bit vor dem versehentlichen Überschreiben geschützt ist.
Angehängte Dateien:
-
memory-map.png
36 KB
Lothar schrieb: > Bei den EFM8 Der interessiert hier aber nicht. Mach einen EFM8-Thread mit Vergleich zum hier diskutierten MC auf, aber sei Dir nicht zu sicher, daß Dein geliebter EFM8 dann technisch überlegen abschneidet :) spess53 schrieb: > Und ein AVR ohne dieses Bootloadergedödel startet immer > bei Flashadresse 0x0000 (außer der hier genannten ATTinys) Nochmal zur Klarstellung: ALLE AVRs und auch diese hier starten bei Flashadresse 0x0000. Im Gegensatz zu den anderen liegt der für einen Bootloader nutzbare Speicherbereich bei den neuen Tinys aber VOR und nicht hinter dem Hauptprogramm. Eingeblendet ist der Flashbereich in der Memory-Map ab 0x8000 (siehe Grafik).
Nun wollte ich auch mal was damit machen, einige Schachen sind schon sehr interessant. Und verfügbar sind sie auch. Aber womit flashen? STK600 will ich mir nur dafür nicht erst noch anschaffen, die AVRs sind auf dem sterbenden Ast bei mir. Der Dragon kanns auch nicht (obwohl das eigenlich mit nem Softwareupdate machbar sein sollte?). Dann habe ich noch den JTAG MKII, auch Fehlanzeige. AVR ICE kann es auch, aber auch den habe ich nicht. Muss man wirklich paar 100 Euros ausgeben, um mit den Dingern zu reden? Es gibt doch bestimmt irgendwas keines schnuckliges für ein paar Euronen? Muss auch nichts professionelles sein, ich will erstmal nur Spielen damit.
Die Xplained - Bords haben einen Programmer und Debugger an Bord und kosten nun wirklich kein Vermögen. z.B. https://eu.mouser.com/ProductDetail/Microchip-Technology-Atmel/ATTINY817-XMINI?qs=%2fha2pyFadugwUL%2fXaGVndfKkHprM9Ti6o5nc2klILAGHpneqwarZoA%3d%3d Irgendwo hier im Forum fand sich auch schon der Hinweis, welche Kleinigkeit in der Konfiguration des Atmel-Studios geändert werden muss, damit auch andere Typen programmiert werden können.
Peter D. schrieb: > Sehe ich das richtig, daß die Register nicht mehr über LD/ST erreicht > werden? Ja. Ist aber nix wirklich neues, war bei den ATXMega schon immer so und ist bei einigen neueren Tinys auch schon eine ganze Weile so. Atmel bzw MC haben hier einfach erkannt, dass dieses Feature höchst verzichtbar ist. > In Assembler sieht man ja oft, daß R1..R29 in einer Loop genullt werden. Ich hab' so einen Unsinn noch nie gesehen und ich habe, weiß Gott, schon sehr viel Assembler gesehen. Wozu sollte das auch gut sein? Es ist langsam und es erledigt mit an Sicherheit grenzender Wahrscheinlichlichkeit weit überwiegend völlig unnütze Arbeit. Was allerdings durchaus schonmal vorkam, war die Nutzung dieses Features zum Laden bestimmter Gruppen von Registern mit Werten aus dem RAM oder Flash. Sowas müsste dann natürlich umgeschrieben werden.
Jürgen H. schrieb: > Die Xplained - Bords haben einen Programmer und Debugger an Bord und > kosten nun wirklich kein Vermögen. > z.B. > https://eu.mouser.com/ProductDetail/Microchip-Technology-Atmel/ATTINY817-XMINI?qs=%2fha2pyFadugwUL%2fXaGVndfKkHprM9Ti6o5nc2klILAGHpneqwarZoA%3d%3d > > Irgendwo hier im Forum fand sich auch schon der Hinweis, welche > Kleinigkeit in der Konfiguration des Atmel-Studios geändert werden muss, > damit auch andere Typen programmiert werden können. Jo, den hatte ich auch gefunden und irgendwie das Gefühl, dass der nur für den 817 funktioniert. Und für externe Chips auch nur mit Gebastel. Aber ist schon einen Versuch wert. Trotzdem irgendwie Wildwuchs diese Programmier/debug-Schnittstellen. Das macht ST besser.
H.Joachim S. schrieb: > Trotzdem irgendwie Wildwuchs diese Programmier/debug-Schnittstellen. > Das macht ST besser. Gnade der späten Geburt? SWD ist nur der letzte Schuß bei ST. Vorher gab es ST6 und ST7 und STM8 (SWIM) und wahrscheinlich noch viel mehr, das ich nicht kenne. Und die sind auch alle untereinander inkompatibel und verlangen danach, daß man immer neue Hardware kauft ...
Ingo L. schrieb: > Allein was der ADC schon > alles kann Was er leider verlernt hat: Den Free Running Mode! Konversionen nur noch manuell ausgelöst oder event-gesteuert :(
:
Wiederhergestellt durch Moderator
Franz schrieb: > Was er leider verlernt hat: Den Free Running Mode! Nach dem Init starten und dann im ISR immer wieder die nächste Wandlung anschubsen ist ein quasi-Free Running Mode ;)
Axel S. schrieb: > SWD ist nur der letzte Schuß bei ST. SWD kommt von ARM, nicht von ST. Axel S. schrieb: > und verlangen danach, daß man > immer neue Hardware kauft ... Die SWD-Debugger kosten praktisch so gut wie gar nichts. M. K. schrieb: > Franz schrieb: >> Was er leider verlernt hat: Den Free Running Mode! > > Nach dem Init starten und dann im ISR immer wieder die nächste Wandlung > anschubsen ist ein quasi-Free Running Mode ;) So etwas macht man aus gutem Grund in Hardware: Jitter, Interrupt Priorities, Systemlast etc.
Wieder ein Beweis, das Microchip die AVR nicht einstampft. Entgegen allen Unkenrufen. Die haben Atmel wirklich nicht gekauft, um den AVR-Bastlern die Luft abzudrehen, auch wenn das viele hier immer noch glauben. Das wird solange weitergeführt, solange das gekauft wird. Und weil AVRs hauptsächlich in der Industrie verwendet werden, kann das noch lange sein. Daran werden auch die lästigen STM32-Hypester daran nichts ändern.
M. K. schrieb: > Franz schrieb: > Was er leider verlernt hat: Den Free Running Mode! > > Nach dem Init starten und dann im ISR immer wieder die nächste Wandlung > anschubsen ist ein quasi-Free Running Mode ;) Leider resultiert daraus ein Haufen zusätzlicher Code. Bislang bin ich immer ohne Interruptverwendung ausgekommen.
:
Wiederhergestellt durch Moderator
Hat jemand das ATtiny817 Xplained Mini am laufen und andere Typen damit beschreibselt?
Franz schrieb: > Leider resultiert daraus ein Haufen zusätzlicher Code. Bislang bin ich > immer ohne Interruptverwendung ausgekommen. Du lässt den ADC im Free Running Mode laufen und pollst ständig? Ist das nicht irgendwie Quatsch? Oder pollst du dann nur wenn du einen Wert brauchst? Aber wozu dann im Free Running Mode laufen lassen? Wenn ich den Free Running Mode nutze dann fange ich die/alle Werte des ADCs in der ISR ab, soviel zusätzlicher Code wird das nicht.
H.Joachim S. schrieb: > Hat jemand das ATtiny817 Xplained Mini am laufen und andere Typen > damit > beschreibselt? Keine Ahnung, ob das klappt: https://github.com/mraardvark/pyupdi
> Muss man wirklich paar 100 Euros ausgeben, um mit den Dingern zu reden? Bis Ende des Monats gibt es von Microchip ein Angebot - 50 % Ermäßigung auf Atmel ICE. Komplettset kostet dann 65 USD, Versand aus UK. Atmel-ICE 50% off - Use Coupon Code :TP1747 Expires : 28-Feb-2018 https://www.microchipdirect.com/product/search/all/ATATMEL-ICE
M. K. schrieb: > Oder pollst du dann nur wenn du einen Wert > brauchst? Ganz genau. Wenn im Hauptprogramm benötigt. Dazu braucht es mit Free Running Mode dann weder ständiges Anstoßen noch Interrupt.
:
Wiederhergestellt durch Moderator
Antitroller schrieb: > H.Joachim S. schrieb: > Hat jemand das ATtiny817 Xplained Mini am laufen und andere Typen damit > beschreibselt? Sollte problemlos machbar sein da sich die UPDI Schnittstelle vom verbauten 817 abkoppeln lässt. Bequemer und mit Debugging Möglichkeit ists natürlich mit nem Atmel-ICE.
:
Wiederhergestellt durch Moderator
Franz schrieb: > Antitroller schrieb: >> H.Joachim S. schrieb: >> Hat jemand das ATtiny817 Xplained Mini am laufen und andere Typen damit >> beschreibselt? > > Sollte problemlos machbar sein da sich die UPDI Schnittstelle vom > verbauten 817 abkoppeln lässt. > Bequemer und mit Debugging Möglichkeit ists natürlich mit nem Atmel-ICE. Wieso zitierst Du mich? Im Übrigen war das keine Antwort auf seine Frage...
Norbert T. schrieb: >> Muss man wirklich paar 100 Euros ausgeben, um mit den Dingern zu reden? > > Bis Ende des Monats gibt es von Microchip ein Angebot - 50 % Ermäßigung > auf Atmel ICE. Komplettset kostet dann 65 USD, Versand aus UK. > > Atmel-ICE > 50% off - Use Coupon Code :TP1747 Expires : 28-Feb-2018 > > https://www.microchipdirect.com/product/search/all/ATATMEL-ICE Das ist doch mal super, direkt bestellt. Vielen Dank für den Tip.
Beitrag #5331569 wurde von einem Moderator gelöscht.
Antitroller schrieb im Beitrag #5331569: > H.Joachim S. schrieb: >> Das ist doch mal super, direkt bestellt. > > Das hat nochmal genau wen interessiert? Also mein Posting war das nicht, vermutlich vom Franz...
Beitrag #5331588 wurde vom Autor gelöscht.
Beitrag #5331642 wurde von einem Moderator gelöscht.
@Franz: Okay, ich habe Deine Beiträge wiederhergestellt. Der Typ, der hier den gleichnamigen Nick "Antitroller" verwendete, muss aber nach der IP-Adresse zu urteilen, zumindest Dein Nachbar sein oder auf derselben Straße wohnen. Deinen letzten Beitrag habe ich dennoch gelöscht. Persönliche Beleidigungen müssen nicht sein.
Für die "Nachbildung" des unverständlicherweise gestrichenen simplen ADC Free Running Mode kann wie erwähnt das Event-System herhalten, wenn denn eine zeitlich passende Event-Quelle zur Verfügung steht. Um z. B. das RTC_OVF Event mit passend initialisiertem RTC Interrupt zu nutzen wäre für dieses der Wert 8 in eines der 4 vorhandenen Asynchronous Channel Generator Selection Register zu schreiben (z. B. ASYNCCH0) und dessen zugeordnete fixe Nummer (=3) dann in das ADC0 gehörige Asynchronous User Channel Selelection Register ASYNCUSER1. Mit der gesetzten Eventsteuerungs-Freigabe STARTEI im ADC Event Control Register EVCTRL sollte das Sampling/die Conversion dann im Takt des RTC_OVF ausgelöst werden- wenn ich die ganze Eventlogik jetzt hier richtig verstanden habe. Puh. Einfach geht anders :(
Hi >Für die "Nachbildung" des unverständlicherweise gestrichenen simplen ADC >Free Running Mode kann wie erwähnt das Event-System herhalten, ... Wieso eigentlich gestrichen? Datenblatt S.355: 30. ADC - Analog to Digital Converter 30.1 Features ... • Free running or Single Conversion mode ... MfG Spess
Hi Spess, ich fürchte das ist nicht das Datenblatt zum ATTiny 1614/16/17... Was mich aber nach wie vor stutzig macht ist die Erwähnung des Modes im Errata Abschnitt.
Franz schrieb: > Hi Spess, ich fürchte das ist nicht das Datenblatt zum ATTiny > 1614/16/17... > Was mich aber nach wie vor stutzig macht ist die Erwähnung des Modes im > Errata Abschnitt. Im Datenblatt zum 814 steht das aber noch drin. Nicht nur bei den Features, sondern auch das Bit für den Modus (CTRLA->FREERUN) Hat jemand einen 16er zum Ausprobieren da und kann einfach mal das im 814er noch vorhandene Bit setzen?
Es scheint sich um einen Fehler im Datenblatt zu handeln. Im Debugger gibts das FREERUN-Bit und es lässt sich ändern. Ich bin erleichtert :)
Franz schrieb: > Es scheint sich um einen Fehler im Datenblatt zu handeln. Im > Debugger > gibts das FREERUN-Bit und es lässt sich ändern. Ich bin erleichtert :) Na also... ;)
Doctor What schrieb: > Im Datenblatt zum 814 steht das aber noch drin. Ettliche Passagen zum Freerun inkl. eines Graphen sind im Datenblatt zum 1614 wie zielgerichtet entfernt?!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.