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
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 ;-)
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.
> 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.
Stefan U. schrieb: > Kilobits sind in Mode gekommen. Logisch, große Zahlen verkaufen sich halt besser, auch wenn der Informationsgehalt der Selbe ist...
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
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
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.
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?
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.
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
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.
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
Baldrian schrieb: > Nebenbei: 2^10! ist eine verdammt große Zahl. Ich meinte nicht Fakultät! Ich meinte Ausrufezeichen ohne zu plenken! Gruss Chregu
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!
:
Bearbeitet durch User
Der Dichter schrieb: > Baldrian schrieb: >> Das ist - wie zu erwarten war- falsch. > > Haste nachgewogen? Nein. Ausgerechnet.
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.
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?
Wenn ein Kilobyte 1024 Bytes sein sollen, dann muss ein Kilogramm auch 1024 Gramm sein, wenn man konsistent bleiben will.
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.
hi, beruhigt euch mal... Das Rad wurde bereits erfunden.. Ihr müsst es nicht nochmal machen!! mfg Umbrecht
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.
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: > 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
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.
:
Bearbeitet durch User
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
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...
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
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).
Beitrag #5016592 wurde von einem Moderator gelöscht.
Beitrag #5016616 wurde von einem Moderator gelöscht.
Beitrag #5016624 wurde von einem Moderator gelöscht.
Beitrag #5016631 wurde von einem Moderator gelöscht.
Beitrag #5016647 wurde von einem Moderator gelöscht.
Beitrag #5016652 wurde von einem Moderator gelöscht.
Beitrag #5016657 wurde von einem Moderator gelöscht.
Beitrag #5016659 wurde von einem Moderator gelöscht.
Beitrag #5016664 wurde von einem Moderator gelöscht.
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!
:
Bearbeitet durch User
Bitte 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.