Neue AVR reihen

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

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

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 ;-)

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

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

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

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

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.

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 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.

heieiei, der Streit um des Kaisers Bart.

Und dabei ist erst Donnerstag...

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.

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.

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. 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/

1

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

2

3

Disassembly of section .text:

4

5

00000000 <__bad_interrupt>:

6

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

7

8

Disassembly of section .vectors:

9

10

00000000 <__vectors>:

11

   0:   00 c0           rjmp    .+0             ; 0x2 <__vectors+0x2>

12

   2:   00 c0           rjmp    .+0             ; 0x4 <__vectors+0x4>

13

...

14

  32:   00 c0           rjmp    .+0             ; 0x34 

15

16

Disassembly of section .init9:

17

18

00000000 <.init9>:

19

   0:   0e 94 00 00     call    0       ; 0x0 <.init9>

20

   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

1. ATtiny Device Family Overview

2

3

Figure 1-1 shows the feature compatible devices in the ATtiny device

4

family, including pin out variants and memory variants.

5

6

Migration within the vertical direction can be done without modifications

7

to the code, as these devices are fully pin and feature compatible.

8

9

16KB                         ATtiny1616   ATtiny1617   

10

11

 8KB             ATtiny814   ATtiny816    ATtiny817   

12

13

 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.

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

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.

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%.

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!