mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Neue Tiny x14 können richtig was


Autor: Ingo Less (corrtexx)
Datum:

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

Autor: Adam P. (adamap)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt echt gut, aber wo hast du die Infos gefunden (Datenblatt)?

Autor: nicht Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: F. Fo (foldi)
Datum:

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

Autor: Ingo Less (corrtexx)
Datum:

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

Autor: Max MMM (maxmicr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: F. Fo (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja meint er. Einige Tinys haben das nicht. Ich habe ja explizit vom Tiny 
10 geschrieben.

Autor: Ingo Less (corrtexx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Lothar (Gast)
Datum:

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

Autor: Ingo Less (corrtexx)
Datum:

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

Autor: Max MMM (maxmicr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
Ebay-Artikel Nr. 281861263288)

: Bearbeitet durch User
Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mir nen Muster vom Tiny1634 schicken lassen, die sind auch nicht 
übel ;)

Autor: Ingo Less (corrtexx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider scheint die Verfügbarkeit noch nicht sonderlich hoch zu sein bei 
den x14 :(.

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

Bewertung
0 lesenswert
nicht lesenswert
Die x14 sind einfach nur xmegas in kleinerem Gehäuse.

Autor: Timmy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
äh ne doch nicht

Autor: Lothar (Gast)
Datum:

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

Statt C2 geht übrigens auch SWD z.B. mit J-Link braucht nur einen 
anderen Treiber.

Autor: Ingo Less (corrtexx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Was für Peripherie gibt es
> nicht?
DAC im SO-14, 2x 16Bit Timer z.B.

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Lothar (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Ingo L. schrieb:
> DAC im SO-14

Das finde ich auch nicht gut. Auch dass es nun offenbar gar keine DIP 
mehr geben soll.

Autor: M. (Gast)
Datum:

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

Autor: c-hater (Gast)
Datum:

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

Autor: Ingo Less (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Also ich finde SO nicht so schlimm. QFN wäre schlimmer

Autor: Simpel (Gast)
Datum:

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

Autor: Rudolph R. (rudolph)
Datum:

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

Autor: M. Köhler (sylaina)
Datum:

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

Autor: c-hater (Gast)
Datum:

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

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simpel schrieb:
> Die CCL ist ja der Hit in dieser Klasse

Alles vom EFM8 abgeschaut:

https://www.silabs.com/whitepapers/how-configurabl...

Autor: F. Fo (foldi)
Datum:

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

Autor: F. Fo (foldi)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ebay-Artikel Nr. 222101794654

Das war der teuerste Sockel.


Wenn du selbst lötest, dann geht es auch günstiger.
Ebay-Artikel Nr. 321850520164

Wenn dich das schon umhaut, dann machst du was falsch mit deinem 
Gewerbe.

Autor: F. Fo (foldi)
Datum:

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

Autor: mu.s (Gast)
Datum:

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

Autor: F. Fo (foldi)
Datum:

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

Autor: TU Student (student0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: mu.s (Gast)
Datum:

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

Autor: Gerd (Gast)
Datum:

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

Autor: F. Fo (foldi)
Datum:

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

Autor: M. Köhler (sylaina)
Datum:

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

Autor: sigma9 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo:

ich habe hier

http://ww1.microchip.com/downloads/en/DeviceDoc/40...

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

Autor: Christian Müller (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hatten wir doch erst grad? Oder?

Gruss Chregu

Autor: Hubert G. (hubertg)
Datum:

Bewertung
1 lesenswert
nicht lesenswert

Autor: M. Köhler (sylaina)
Datum:

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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
sigma9 schrieb:
> Microchip die Atmel-Sachen dann doch aktiv weiterentwickelt?

Die Datenblätter jedenfalls werden proaktiv zurückentwickelt.

SCNR

Autor: F. Fo (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jau!

Autor: c-hater (Gast)
Datum:

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

Autor: F. Fo (foldi)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Guck sie dir doch an! Bunter, aber weniger ausführlich.

Autor: c-hater (Gast)
Datum:

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

Autor: F. Fo (foldi)
Datum:

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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:
Angehängte Dateien:

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

Autor: M. Köhler (sylaina)
Datum:

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

Autor: Toralf Wilhelm (willi)
Datum:

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

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Mw En (Firma: fritzler-avr.de) (fritzler)
Datum:

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

Autor: M. Köhler (sylaina)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Johann L. (gjlayde) Benutzerseite
Datum:

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

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

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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

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

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Johann L. (gjlayde) Benutzerseite
Datum:

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

Autor: M. Köhler (sylaina)
Datum:

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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

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

Autor: M. Köhler (sylaina)
Datum:

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

Autor: M. (Gast)
Datum:

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

Autor: M. Köhler (sylaina)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.
Autor: spess53 (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.
Autor: M. Köhler (sylaina)
Datum:

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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Bei welchem AVR startet das Program bei 0x0000?

Eigentlich alle außer diesen ATTinys.

MfG Spess

Autor: M. Köhler (sylaina)
Datum:

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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

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

Autor: spess53 (Gast)
Datum:

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

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah ja, jetzt seh ichs...hm, OK. Ist ne Änderung...hat das Vor-/Nachteile 
für "uns"?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Lothar (Gast)
Datum:

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

Autor: M. (Gast)
Datum:
Angehängte Dateien:

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.