Neue AVR reihen

[Umbrecht (Gast)]

Hi,

habe vorher im Forum gelesen dass es eine neue Reihe von ATynis gibt.. 
Wo findet man solche Neuigkeiten? Den auf der ATMEL Seite bin ich nicht 
fündig geworden..

mfg
Umbrecht

[Felix Adam (Gast)]

Jetzt wohl bei microchip.com, weil Atmel von denen gekauft wurde.

[Rolf M. (rmagnus)]

Google kaputt?
Hier z.B.: 
http://www.channel-e.de/nachrichten/article/microchip-neue-avr-attiny-mcus.html

Umbrecht schrieb:
> Den auf der ATMEL Seite bin ich nicht fündig geworden..

Die AVRs gehören jetzt zu Microchip:
http://www.microchip.com/promo/tiny1617-mcu-family

[Joachim B. (jar)]

Rolf M. schrieb:
> Google kaputt?
> Hier z.B.:
> http://www.channel-e.de/nachrichten/article/microchip-neue-avr-attiny-mcus.html

nicht mal richtig abschreiben können die:

Die neuen MCUs bieten 16 KB Flash, 256 KB EEPROM! und 2 KB RAM

[Rolf M. (rmagnus)]

Joachim B. schrieb:
> nicht mal richtig abschreiben können die:
>
> Die neuen MCUs bieten 16 KB Flash, 256 KB EEPROM! und 2 KB RAM

Naja, die heutigen Generationen kennen Speichergrößen-Angaben ohne 
Prefix gar nicht mehr. Die wissen gar nicht, dass sowas möglich ist ;-)

[M. (Gast)]

Meine Bestellung eines Vorgängers des genannten 32K Tiny (ein 814er) 
wird erst Ende August ausgeliefert (Bestellung letzten November!). Ich 
wage nicht zu prophezeien wann der aktuellste Tiny mal erhältlich ist.

[Christian M. (Gast)]

Joachim B. schrieb:
> KB

Was ist denn "K" als Präfix? Ich kenne nur "k"...

Gruss Chregu

[Stefan F. (Gast)]

> Was ist denn "K" als Präfix? Ich kenne nur "k"...

k=Kilo
K=Kanne :-)

Dazu kommt, dass man bei Speicherchips nie sicher sein kann, ob die 
jetzt Kilo-Bytes oder Kilo.Bits meinen. Denn auch bei dem B nehmen sie 
es nicht der Groß/Klein-Scheibweise nicht so genau. Und Angaben in 
Kilobits sind in Mode gekommen.

[Ingo L. (corrtexx)]

Stefan U. schrieb:
> Kilobits sind in Mode gekommen.
Logisch, große Zahlen verkaufen sich halt besser, auch wenn der 
Informationsgehalt der Selbe ist...

[Markus (Gast)]

Autor: Christian Müller (Firma: magnetmotor.ch) (chregu)
>Was ist denn "K" als Präfix? Ich kenne nur "k"...

Dann schau dir mal die Definition für kByte und KByte in der Grafik auf 
der rechten Seite an:

https://en.wikipedia.org/wiki/Kilobyte

[Umbrecht (Gast)]

hi,

Rolf M. schrieb:
> Google kaputt?

Nein.

Aber vielen dank für den Link.

mfg
Umbrecht

[Christian M. (Gast)]

Markus schrieb:
> Definition für kByte und KByte

Diesen KiBi-MiBi-Bullshit kann mir gestohlen bleiben! Wegen ein paar 
Marketingler, BW-ler und Tatschscreen-Instant-App-Generatiönler werde 
ich mich da nicht anpassen.

2^10!

Gruss Chregu

[Baldrian (Gast)]

Christian M. schrieb:
> Markus schrieb:
>> Definition für kByte und KByte
>
> Diesen KiBi-MiBi-Bullshit kann mir gestohlen bleiben! Wegen ein paar
> Marketingler, BW-ler und Tatschscreen-Instant-App-Generatiönler werde
> ich mich da nicht anpassen.
>
>
>
> Gruss Chregu

Ist immer wieder nett: eine Unbelehrbarer, der vermutlich Entfernungen 
in Hannoverschen Landmeilen angibt.

Nebenbei: 2^10! ist eine verdammt große Zahl.

[Der Dichter (Gast)]

Christian M. schrieb:
> Diesen KiBi-MiBi-Bullshit kann mir gestohlen bleiben!

KiBi, MiBi, Mimimimimi! :o)

Ein Kilo Byte wiegt nun mal 1024*8 Bit. So what?

[MM (Gast)]

M. schrieb:
> Meine Bestellung eines Vorgängers des genannten 32K Tiny (ein 814er)
> wird erst Ende August ausgeliefert (Bestellung letzten November!). Ich
> wage nicht zu prophezeien wann der aktuellste Tiny mal erhältlich ist.

Komisch, die PIC-Controller sind im Allgemeinen gut verfügbar.

[Thomas E. (thomase)]

Felix Adam schrieb:
> Jetzt wohl bei microchip.com, weil Atmel von denen gekauft wurde.

Schön zu wissen, dass du das auch schon weisst.

[Joachim B. (jar)]

Christian M. schrieb:
> Joachim B. schrieb:
>> KB
>
> Was ist denn "K" als Präfix? Ich kenne nur "k"...

für 1024 / 2^10?

wenn du KB schon hinterfragst denn doch bitte beim Hersteller!
http://www.microchip.com/promo/tiny1617-mcu-family

[Baldrian (Gast)]

Der Dichter schrieb:
> Christian M. schrieb:
>> Diesen KiBi-MiBi-Bullshit kann mir gestohlen bleiben!
>
> KiBi, MiBi, Mimimimimi! :o)
>
> Ein Kilo Byte wiegt nun mal 1024*8 Bit. So what?

Das ist - wie zu erwarten war- falsch.

[Sascha (Gast)]

Hallo,
ja das Teil 1616 oder 1617 sieht gut aus.
Bis jetzt finde ich die Atxmega8E5 16E5 usw. sehr gut. Nur hört es da 
bei 3,3V auf.

Gruß Sascha

[Christian M. (Gast)]

Baldrian schrieb:
> Nebenbei: 2^10! ist eine verdammt große Zahl.

Ich meinte nicht Fakultät! Ich meinte Ausrufezeichen ohne zu plenken!

Gruss Chregu

[Peter D. (peda)]

Er hat sogar einen PIC-Modus für die Umsteiger vom PIC:
Mit dem CVT-Bit kann man alle Interrupts auf einen Vector zusammen 
verwursten, d.h. man darf sich dann erstmal selber die Interuptquelle 
ausklamüsern.

[Der Dichter (Gast)]

Baldrian schrieb:
> Das ist - wie zu erwarten war- falsch.

Haste nachgewogen?

[Johann L. (gjlayde)]

Interessant finde ich die auch wegen des linearen Adressraums:

Kein Rumgefrickel mit PROGMEM und pgm_read_* oder __flash, einfach 
"normalen" Code schreiben ohne dass unnötig RAM für Konstanten 
verplempert wird!

[Baldrian (Gast)]

Der Dichter schrieb:
> Baldrian schrieb:
>> Das ist - wie zu erwarten war- falsch.
>
> Haste nachgewogen?

Nein. Ausgerechnet.

[Alexander L. (photoniker)]

Baldrian schrieb:
> Der Dichter schrieb:
> Baldrian schrieb:
> Das ist - wie zu erwarten war- falsch.
>
> Haste nachgewogen?
>
> Nein. Ausgerechnet.

Dann erklär ihn doch auch, wie nach SI bzw IEC 1Kilobyte berechnet wird.

Jedenfalls ist aus dem Kontext ersichtlich, was er meint. Plusminus 24 - 
drauf gepfiffen.

[Johann L. (gjlayde)]

heieiei, der Streit um des Kaisers Bart.

Und dabei ist erst Donnerstag...

[Baldrian (Gast)]

Alexander L. schrieb:
> Baldrian schrieb:
>> Der Dichter schrieb:
>> Baldrian schrieb:
>> Das ist - wie zu erwarten war- falsch.
>>
>> Haste nachgewogen?
>>
>> Nein. Ausgerechnet.
>
> Dann erklär ihn doch auch, wie nach SI bzw IEC 1Kilobyte berechnet wird.
>
> Jedenfalls ist aus dem Kontext ersichtlich, was er meint. Plusminus 24 -
> drauf gepfiffen.

Bist du die Pfeife vom USer Der Dichter?

[Timmy (Gast)]

Wenn ein Kilobyte 1024 Bytes sein sollen, dann muss ein Kilogramm auch 
1024 Gramm sein, wenn man konsistent bleiben will.

[Baldrian (Gast)]

Johann L. schrieb:

> heieiei, der Streit um des Kaisers Bart.
>
> Und dabei ist erst Donnerstag...

Kleine Zwischenbemerkung: Dem sehr übersichtlichen Datenblatt von 
Microschip entnehme ich, dass das Ausführung von Code aus dem SRAM nicht 
möglich ist. Schade.

[Umbrecht (Gast)]

hi,

beruhigt euch mal... Das Rad wurde bereits erfunden.. Ihr müsst es nicht 
nochmal machen!!

mfg
Umbrecht

[Dr. No (Gast)]

Peter D. schrieb:
> Er hat sogar einen PIC-Modus für die Umsteiger vom PIC:
> Mit dem CVT-Bit kann man alle Interrupts auf einen Vector zusammen
> verwursten, d.h. man darf sich dann erstmal selber die Interuptquelle
> ausklamüsern.

Naja, ganz so ist das nicht: Es sind dann immerhin noch drei Vektoren. 
Für viele kleine Anwendungen sicherlich ausreichend und auch für 
Nicht-PICer brauchbar.

[Rolf M. (rmagnus)]

Baldrian schrieb:
> 2^10! ist eine verdammt große Zahl.

Baldrian schrieb:
> Christian M. schrieb:
>> Markus schrieb:
>>> Definition für kByte und KByte
>>
>> Diesen KiBi-MiBi-Bullshit kann mir gestohlen bleiben! Wegen ein paar
>> Marketingler, BW-ler und Tatschscreen-Instant-App-Generatiönler werde
>> ich mich da nicht anpassen.
>>
>>
>>
>> Gruss Chregu
>
> Ist immer wieder nett: eine Unbelehrbarer, der vermutlich Entfernungen
> in Hannoverschen Landmeilen angibt.

Ich hätte ja prinzipiell nichts gegen eigene Präfixe für 1024 und derlei 
und sehe auch eine Berechtigung dafür, aber die dämliche Babysprache, 
die dafür leider gewählt wurde, nervt dann doch zu sehr.
Der Meter hätte sich wahrscheinlich gegenüber der "Hannoverschen 
Landmeile" auch nicht durchgesetzt, wenn er bläbläpffrrt genannt worden 
wäre.

[Planlos (Gast)]

Ist doch ganz einfach, das mit den Bytes...

https://xkcd.com/394/

[Christian M. (Gast)]

Rolf M. schrieb:
> Ich hätte ja prinzipiell nichts gegen eigene Präfixe für 1024 und derlei
> und sehe auch eine Berechtigung dafür

Das 1024 hat man damals nicht einfach so gewählt, sondern ist das einzig 
Vernünftige in programmiertechnischer und architektonischer Hinsicht! 
Sollen sich doch die Marketingler einen eigenen Präfix suchen!

Stell Dir mal ein 1kB EEPROM vor, das tatsächlich nur 1000 Bytes hat! 
Und jetzt stell Dir noch das Die vor, wo die 24 Bytes in der Matrix 
fehlen...

Gruss Chregu

[Johann L. (gjlayde)]

Rolf M. schrieb:
> dämliche Babysprache,

Tolles Kriterium. Bei zig 1000 Sprachen auf dem Planeten und noch mehr 
Dialekten, kannst du ja einen Vorschlag machen, der in keiner der 
SPrachen lustig oder ungewohnt klingt oder zu Assoziationen aus komplett 
anderen Themenbereichen Anlass gibt.

[Johann L. (gjlayde)]

Mal noch ein paar Fragen:

Zu ATtiny417 / 814 / 816 / 817:  Im Datenblatt

http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42721C-AVR-ATtiny417-814-816-817-Datasheet_Complete.pdf

sind unter 37. Instruction Set Summary auch JMP und CALL aufgelistet, 
obwohl die ja erst mit Flash > 8 KiB gebraucht werden.  Ist das nur ein 
Tippfehler im Datenblatt oder ist es einfach den Aufwand nicht mehr 
Wert, extra Masken für Cores kleiner Derivate zu machen?

Vielleicht hat ja jemand so ein Device in Hardware verfügbar und kann's 
austesten.

Hat jemand nen Direktlink zum Datenblatt von

* ATtiny1614/6/7
* ATtiny3214/6/7
* ATtiny416

[M. (Gast)]

Johann L. schrieb:
> Ist das nur ein
> Tippfehler im Datenblatt

Vermutlich. Es wäre nicht der erste und einzige.
Studio7 meldet jedenfalls erwartungsgemäß Jmp/Call unsupported...

[Johann L. (gjlayde)]

M. schrieb:
> Johann L. schrieb:
>> Ist das nur ein
>> Tippfehler im Datenblatt
>
> Vermutlich. Es wäre nicht der erste und einzige.
> Studio7 meldet jedenfalls erwartungsgemäß Jmp/Call unsupported...

Alles seeehr seltsam.  Im Device-Support "Atmel ATtiny Series Device 
Support (1.2.118)" (ist vom Format her einfach nur ein ZIP bzw. JAR)

http://packs.download.atmel.com/

$ avr-objdump -d .../gcc/dev/attiny417/avrxmega2/crtattiny417.o:

Disassembly of section .text:

00000000 <__bad_interrupt>:
   0:   0c 94 00 00     jmp     0       ; 0x0 <__bad_interrupt>

Disassembly of section .vectors:

00000000 <__vectors>:
   0:   00 c0           rjmp    .+0             ; 0x2 <__vectors+0x2>
   2:   00 c0           rjmp    .+0             ; 0x4 <__vectors+0x4>
...
  32:   00 c0           rjmp    .+0             ; 0x34 

Disassembly of section .init9:

00000000 <.init9>:
   0:   0e 94 00 00     call    0       ; 0x0 <.init9>
   4:   0c 94 00 00     jmp     0       ; 0x0 <.init9>

Da stehen also explizit CALL und JMP, und die Große der .vector-Einträgs 
sind wie zu erwarten 2 Bytes.

Um so erstaunlicher, weil die avr-libc in crt1/gcrt1.S Makros XJMP bzw. 
XCALL verwendet, welche wiederum von avr-gcc's Builtin-Define 
__AVR_HAVE_JMP_CALL__ abhängen.

Da haben die Jungs also von Hand irgendwas gepatcht, einen sauberen 
Support in den Tools scheint es nicht wirklich zu geben (von 
suboptimalen ld-Skripts mal ganz abgesehen).

Die Idee von JMP / CALL ist wohl folgende, siehe Datenblatt wie oben 
verlinkt

1. ATtiny Device Family Overview

Figure 1-1 shows the feature compatible devices in the ATtiny device
family, including pin out variants and memory variants.

Migration within the vertical direction can be done without modifications
to the code, as these devices are fully pin and feature compatible.

16KB                         ATtiny1616   ATtiny1617   

 8KB             ATtiny814   ATtiny816    ATtiny817   

 4KB                                      ATtiny417

"without modifications to the code" verstehe ich als binärkompatibel, 
aber allein wegen der unterschiedlichen Vector-Layouts kann das schon 
nicht funktionieren.  Weiters zeigt "6.2 Memory Map", dass bei ATtiny41x 
RAM bei 3F00 beginnt, bei ATtiny81x hingegen bei 3E00.  Es ist also auch 
nicht möglich, von einem ATtiny81x auf einen ATtiny41x zu wechseln 
selbst wenn RAM und Flash und EEPROM in das kleinere Device passen.

[D.J. P. (djlinux)]

Johann L. schrieb:
> "without modifications to the code" verstehe ich als binärkompatibel...

Ich verstehe das so:
Vorhandener "Sourcecode" ohne Änderung für neue CPU/MCU kompilieren und 
es läuft.
Vorhandenes "Binary" läuft nicht auf neuer CPU/MCU.

Grüsse DJ

[M. (Gast)]

Johann L. schrieb:
> "without modifications to the code" verstehe ich als binärkompatibel

Das meint Code vor Neuassemblierung/Kompilierung und code-kompatibel 
innerhalb einer Zeile. Es ist also durchaus

> möglich, von einem ATtiny81x auf einen ATtiny41x zu wechseln
> selbst wenn RAM und Flash und EEPROM in das kleinere Device passen

Pro Zeile sind die Tinys nicht pin- und pro Spalte nicht 
feature-kompatibel. Letzteres bezieht sich bei Tiny417 vs. 814/16/17 nur 
auf Flash/SRAM Größe, bei den Tiny16xx kommt weitere Peripherie hinzu 
(die Intvektor-Tab ändert sich demzufolge dort).

[Joachim B. (jar)]

Bernd T. schrieb im Beitrag #5016631:
> Und jeder der die Technik versteht und die Hintergrüpnde wird weiterhin
> das K als 1024 annehmen.

nur nicht die BWL Marketing Fuzzis die uns Festplatten und Flashspeicher 
als vielfache von 1000 verkaufen!

Da kommt ne Menge -% zusammen wenn das MB nicht mehr 1024 x 1024 Byte 
ist.

[Rolf M. (rmagnus)]

Joachim B. schrieb:
> Bernd T. schrieb:
>> Und jeder der die Technik versteht und die Hintergrüpnde wird weiterhin
>> das K als 1024 annehmen.
>
> nur nicht die BWL Marketing Fuzzis die uns Festplatten und Flashspeicher
> als vielfache von 1000 verkaufen!

Derartige Tricks werden aber nicht nur da genutzt. Bei den 
Röhrenfernsehern z.B. war es auch üblich, als Bilddiagonale nicht die 
vom Bild, sondern die der kompletten Bildröhre anzugeben. Und der 
"4k"-Fernseher hat eigentlich auch nur 3,75k. Man braucht also nicht mal 
irgendwelche Mebibytes und Gibibits, um die Zahlen zu tunen.

> Da kommt ne Menge -% zusammen wenn das MB nicht mehr 1024 x 1024 Byte
> ist.

Wobei das heute ja nicht mehr MB, sondern schon TB sind. Da sind's dann 
schon ca. 10%.

[Joachim B. (jar)]

Rolf M. schrieb:
> Wobei das heute ja nicht mehr MB, sondern schon TB sind. Da sind's dann
> schon ca. 10%.

klar meine 3TB WDpassport ultra haben nur 2,7x TB immerhin 300GB 
weniger!