Announcement: there is an English version of this forum on Im neuen Atmel Studio 7 ist ein noch nicht angekündigter ATtiny104 aufgetaucht. Signatur ist 0x1e900B. Was mag es damit auf sich haben? Dem includefile (Anhang) kann man entnehmen dass es sich um einen ATtiny10 mit mehr I/O zu handeln scheint. Es gibt 12 GPIO, einen UART und einen "Voltage level monitor", der neu für die ATtiny zu sein scheint?
Tim . schrieb: > Im neuen Atmel Studio 7 ist ein noch nicht angekündigter ATtiny104 > aufgetaucht. Signatur ist 0x1e900B. Was mag es damit auf sich haben? Für dieses Jahr waren neue Tinys angekündigt.
Ob das mit dem Besitzerwechsel trotzdem noch kommt sind wir ja mal neugierig......
Moby A. schrieb: > Für dieses Jahr waren neue Tinys angekündigt. Stimmt! Und das hoffentlich nicht nur am unteren Ende. Nun ist das Jahr fast herum...
Tim . schrieb: > Im neuen Atmel Studio 7 ist ein noch nicht angekündigter ATtiny104 > aufgetaucht. Signatur ist 0x1e900B. Was mag es damit auf sich haben? > > Dem includefile (Anhang) kann man entnehmen dass es sich um einen > ATtiny10 mit mehr I/O zu handeln scheint. Es gibt 12 GPIO, einen UART > und einen "Voltage level monitor", der neu für die ATtiny zu sein > scheint? sehr interessant. Danke für den Hinweis. Vermutung (bitte prüfen): Die angehängte Datei lässt auf einen 14-beinigen attiny mit 1kB (flash) 32 byte RAM schließen. Mit 8* ADC, einem Comparator und einem Timer (16Bit). Damit wäre der Kern günstiger als ein ATtiny13. Ich tippe mal auf einen sehr günstigen Controller. Gruß Thomas
Th. B. schrieb: > 32 byte RAM schließen Also das wäre jetzt aber etwas wenig, findest du nicht? EDIT: OK, ich seh grad, der Attiny 10 hat auch nur 32 byte SRAM...
:
Bearbeitet durch User
Michael K. schrieb: > Th. B. schrieb: >> 32 byte RAM schließen > > Also das wäre jetzt aber etwas wenig, findest du nicht? > > EDIT: OK, ich seh grad, der Attiny 10 hat auch nur 32 byte SRAM... Wenn man es aus der Perspekive der ATtiny 4/5/9/10 betrachtet, wäre das eine perfekte Ergänzung. Günstig für kleine Aufgaben aber mit vielen Anschlüssen. Da stellt sich dann auch die Frage ob der 104 überhaupt per SPI programmiert wird oder eher wie der attiny10 per TWI.
Ich habe noch ein weiteres Indiz gefunden. Auf einer offizielen Webseite von Atmel http://packs.download.atmel.com/ gibt es einen leeren Listeneintrag im Quelltext: <li id="ATtiny10" class="device device-list-item"> </li> <li id="ATtiny104" class="device device-list-item">ATtiny104</li> <li id="ATtiny13" class="device device-list-item"> </li> Das ist doch kein Zufall das der zwischen ATtiny10 und ATtiny13 liegt?! Gruß Thomas
Lohnt sich der Verzicht auf Speicher ueberhaupt in der Fertigung oder ist das nur altmodische Spinnerei?
Th. B. schrieb: > Das ist doch kein Zufall das der zwischen ATtiny10 und ATtiny13 liegt?! Nö, das nennt sich alphabetische Reihenfolge. :-) xXx schrieb: > Lohnt sich der Verzicht auf Speicher ueberhaupt in der Fertigung Meinst du, die hätten das aus Spaß weggelassen? Die haben seinerzeit an allen Ecken und Enden gespart, damit sie den 6-Pinner in ein SOT-23 bekommen. Das sieht man u. a. auch daran, dass man die Dinger eben nur mit Vcc = 5 V programmieren kann – das spart Fläche für den Kondensator in der Vpp-Ladungspumpe. Das sieht man auch daran, dass sie ihm nur den halben Registersatz spendiert haben. Und eben am winzigen RAM. Inwiefern es natürlich Sinn hat, einen 14-Pinner mit der Die-Größe eines SOT-23 auszustatten, ist 'ne andere Frage. Insbesondere ein klobiges DIL-Gehäuse dürfte dann schon fast so teuer sein wie der Die da drin, und da ist es fraglich, ob $BASTLER dann nicht lieber gleich einen ATtiny24 nehmen kann, der ihm 128 Byte SRAM und den vollen Registersatz bietet. OK, wenn man sich das Package 12U3 des ATtiny20 ansieht, das ist mit 1,5 x 1,4 mm² natürlich schon hübsch klein, aber dem haben sie zumindest 128 Byte SRAM spendiert. Es muss wohl schon einen Millionenkunden geben (dem es auf jeden Cent ankommt), wenn man unterhalb des ATtiny20 dann noch einen Controller produziert.
A. K. schrieb: > Die 32 Bytes der Winzlinge dürften hauptsächlich für den Stack da sein. Bei C-Programmen für diese Winzlinge ist ein Blick ins Assemblerlisting kein Fehler, insbesondere der Stack-Bedarf von ISRs verdient Aufmerksamkeit. Ich finde es erstaunlich, was man mit dem gcc aus so wenig SRAM und Flash herausholen kann.
Als Vergleich mal ein Die-Photo vom PIC10F206. Der liegt mit 0,75kB Flash und 24 Bytes RAM nicht weit weg. Nur die 16 Register fehlen, die mindestens so viel Platz fressen dürften wie die 32 Bytes SRAM. http://www.tayloredge.com/museum/mymuseum/MySilicon/PIC10F206.jpg Man sieht dort recht gut, dass die 6 Bondpads nicht unerheblich zur Grösse beitragen. Bei einer 14er ist dann wohl fast die Hälfte vom Die von Bondpads verbraten - bei vergleichbarer Fabtech (bei neuerer wirds krasser).
:
Bearbeitet durch User
A. K. schrieb: > Die 32 Bytes der Winzlinge dürften hauptsächlich für den Stack da sein. Und auch dafür sind sie sehr knapp bemessen. Bei verschachtelten Subroutinen ist ganz schnell Ende. Von dazwischen funkenden Interrupts gar nicht zu reden...
Icke ®. schrieb: > Bei verschachtelten Subroutinen ist ganz schnell Ende. So viele Unterprogramme schachtelst du mit 1 KiB Flash nicht. :)
Icke ®. schrieb: > Und auch dafür sind sie sehr knapp bemessen. Bei verschachtelten > Subroutinen ist ganz schnell Ende. Von dazwischen funkenden Interrupts > gar nicht zu reden... Klar. Aber die Tin4-10 sehe ich eher in Rollen, in dem man bisher einen NE555 oder so einsetzte. Mit Programmen, die wahrscheinlich auf eine Seite passen.
Jörg W. schrieb: > So viele Unterprogramme schachtelst du mit 1 KiB Flash nicht. In der Tat, ich würde gleich einen größeren µC verwenden. =8P
Einsatzbeispiel für solche Winzlinge: Ich habe mal einen Tiny85 als Taktgenerator eingesetzt. Der liefert einer CDP1802 Platine den CPU-Takt, den UART-Takt und einen zyklischen Interrupt mit Acknowlege. Das Programm für die beiden Takte besteht nur aus der Initialisierung der beiden Timer. Privat sind diese Teile ziemlich witzlos. Da müssen schon 5stellige Stückzahlen sein, damit sich das lohnt.
:
Bearbeitet durch User
A. K. schrieb: > Privat sind diese Teile ziemlich witzlos. Ja, Bastler sind sicher nicht die Zielgruppe.
A. K. schrieb: > Einsatzbeispiel für solche Winzlinge: Ich habe mal einen Tiny85 als > Taktgenerator eingesetzt. Yep, ich habe auch schon einen per Jumper konfigurierbaren ADC-Takt mit einem ATtiny10 generieren lassen. Wie du schon schriebst: sowas wie einen 555, aber eben statt eines Potis dann ein Jumperblock. :)
Icke ®. schrieb: > Bastler sind sicher nicht die Zielgruppe. Das dürfte für alle µCs und alle anderen Elektronikbauteile zutreffen. Der Bastler als Zielgruppe wird heute eher mit Baugruppen adressiert, Arduino usw.
Konrad S. schrieb: > Bastler sind sicher nicht die Zielgruppe. > > Das dürfte für alle µCs und alle anderen Elektronikbauteile zutreffen. > Der Bastler als Zielgruppe wird heute eher mit Baugruppen adressiert, > Arduino usw. Würd ich nun nicht gerade sagen. Gehört doch nicht viel dazu die platzsparend anzuschließen und zu programmieren. Da kauft man doch keinen sperrigen Arduino für viel Geld.
Stimmt, Mega328 in DIP34 mit USB-Bootloader für zwofufzsch ist viel zu groß und viel zu teuer und vor allen geht einfach. Macht kein Spaß!
Bastler schrieb: > Stimmt, Mega328 in DIP34 mit USB-Bootloader für zwofufzsch ist > viel zu groß und viel zu teuer und vor allen geht einfach. Macht kein > Spaß! Ok, das überzeugt natürlich für viele Zwecke. Ich dachte eher an die größeren Platinen. Und dennoch, so ein winziger Tiny tuts oft genauso- und ist immer noch viel kleiner und immer noch viel billiger.
Moby schrieb: > so ein winziger Tiny tuts oft genauso- > und ist immer noch viel kleiner und immer noch viel billiger Wo ist der billig? ATTINY10 mit 1K Flash 32 Byte RAM kostet 80 Cent Vergleichbarer PIC10F222 kostet die Hälfte Vergleichbarer 8051 EFM8BB10F2 kostet weniger als die Hälfte
Lothar schrieb: > Vergleichbarer PIC10F222 kostet die Hälfte Seltensam: wenn ich bei Digikey gucke, dann kostet ein ATtiny10 (in den Stückzahlen, bei denen das relevant wird, also ganze Rollen) 36 Cent, der PIC 10F222 37 Cent. > Vergleichbarer 8051 Du meinst wirklich, es gäbe 8051, die „vergleichbar“ sind? ;-) Ansonsten: 28 Cent, wenn man sie auf einer Rolle nimmt. Im Gegensatz zu den anderen beiden jedoch nicht vorrätig. Preise für Einzelexemplare sind bei sowas wohl kein Kriterium, denn jeglicher Versand kostet dann schon mehr.
Lothar schrieb: > Wo ist der billig? ATTINY10 mit 1K Flash 32 Byte RAM kostet 80 Cent > > Vergleichbarer PIC10F222 kostet die Hälfte Billiger als 2,50€ ...
Jörg W. schrieb: > Du meinst wirklich, es gäbe 8051, die „vergleichbar“ sind? ;-) Hast recht EFM8BB10F2 dürfte mit 25 MHz und 3-Stage-Pipeline etwas schneller sein :-)
Lothar schrieb: > Jörg W. schrieb: >> Du meinst wirklich, es gäbe 8051, die „vergleichbar“ sind? ;-) > > Hast recht EFM8BB10F2 dürfte mit 25 MHz und 3-Stage-Pipeline etwas > schneller sein :-) Aber nur, wenn man einen Programmierer findet, der so masochistisch ist, im 3. Jahrtausend noch 8051 programmieren zu wollen. Ich würde es jedenfalls nicht einmal für Geld tun. ;-)
Jörg W. schrieb: > Aber nur, wenn man einen Programmierer findet, der so masochistisch > ist, im 3. Jahrtausend noch 8051 programmieren zu wollen. Gehört zwar nicht wirklich hierher, aber mit dem Keil Compiler wird ein 8051 heute genau so in C programmiert wie z.B. ein ARM. Soll heißen man bekommt vom Memory Model nichts mit. Der Stack wird automatisch auf 0x80 gesetzt, Variablen ins interne RAM, Arrays ins externe RAM, static const in den Flash. Kein PROGMEM wie beim AVR. Kein SFR Banking wie z.B. beim atmega2560 Tatsächlich ist der Keil 8051 sogar weiter als der Keil ARM, der macht noch Probleme beim RAM. Beispiel: ein ARM hat 64K RAM und es soll ein 50K Array geben. Tatsächlich hat dieser ARM aber im linearen Adressraum z.B. nicht zusammenhängende 32K und 2x 16K Blöcke. Das schafft der Compiler noch nicht automatisch.
Lothar schrieb: > Gehört zwar nicht wirklich hierher, aber mit dem Keil Compiler wird ein > 8051 heute genau so in C programmiert wie z.B. ein ARM. Das wurde er schon vor 25 Jahren. Das macht trotzdem keine moderne Architektur aus ihm.
Jörg W. schrieb: > Das wurde er schon vor 25 Jahren. Das macht trotzdem keine moderne > Architektur aus ihm. Warum bedeutet das jetzt > masochistische Programmierer ??? Das Ding ist ausgereift. Es gibt einen Haufen Software. Er ist ein Industriestandard. Er erfüllt seinen Zweck. Was machen "Moderne Architekturen" heute sooo viel besser?
Stefan H. schrieb: > Java-Unterstützung ARM hat Java-Unterstützung in Hardware schon lange wieder aufgegeben https://en.wikipedia.org/wiki/Jazelle
A. K. schrieb: > Klar. Aber die Tin4-10 sehe ich eher in Rollen, in dem man bisher einen > NE555 oder so einsetzte. Mit Programmen, die wahrscheinlich auf eine > Seite passen. Also der ATtiny10 kann schon etwas mehr: https://github.com/cpldcpu/u-wire
Moby A. schrieb: > Das Ding ist ausgereift. > Es gibt einen Haufen Software. > Er ist ein Industriestandard. > Er erfüllt seinen Zweck. Mit diesen Totschlagargumenten bräuchste du keinerlein Innovation in der Technik.
Leider at Atmel es immer noch nicht geschafft, den Compiler vernünftig auf den reduced core anzupassen und STS/LDS zu verwenden. Beitrag "GCC und LDS/STS auf Attiny10" Studio 7 input:
1 | volatile uint8_t i=0; |
2 | |
3 | int main(void) |
4 | {
|
5 | while (1) |
6 | {
|
7 | i++; |
8 | }
|
9 | }
|
output:
1 | int main(void) |
2 | {
|
3 | while (1) |
4 | {
|
5 | i++; |
6 | 38: e0 e4 ldi r30, 0x40 ; 64 |
7 | 3a: f0 e0 ldi r31, 0x00 ; 0 |
8 | 3c: 40 81 ld r20, Z |
9 | 3e: 4f 5f subi r20, 0xFF ; 255 |
10 | 40: 40 83 st Z, r20 |
11 | } |
12 | 42: fc |
:
Bearbeitet durch User
Tim . schrieb: > Also der ATtiny10 kann schon etwas mehr: > > https://github.com/cpldcpu/u-wire Da ist dann aber auch schon ein Klimzug includiert ;) https://cpldcpu.wordpress.com/2014/03/19/%C2%B5-wire-usb-on-an-attiny-10/ Further measures to reduce code size: I clocked the controller at 12 MHz using the internal RC oscillator and calibrated from the USB bus timing. The 12 MHz V-USB implementation is much smaller than the recommended 12.8 MHz version, but it does not come with an internal phase locked loop to cope with the more inaccurate RC-oscillator timing. Surprisingly I did not observe any timing errors. Since the reduced core AVR only support 16 registers, I had to manually remap numerous registers in V-USB to avoid collisions with GCC. I removed all handling of the reset signal on the USB-Bus. This means the device will not properly re-enumerate when a bus reset is issued. But this is not a problem if you plug it in after the PC was turned on. V-USB was completely gutted and integrated into the main loop. It only support SETUP requests to a single endpoint now. All additional functions have been removed. This also reduces stack usage as fewer subroutine calls are required. I removed the code to support replies from the SRAM. Data can only be sent from flash. This is possible since only single byte-replies are required to implement the protocol, apart from the fixed USB configuration replies which are stored in the flash. Final Stats Flash: 988 of 1024 bytes used (96.4%) SRAM: 28 (variables)+2 (stack) of 32 bytes used (93.8%) This is most likely the most complex firmware ever loaded into an ATtiny10
:
Bearbeitet durch User
Winfried J. schrieb: > Da ist dann aber auch schon ein Klimzug includiert ;) Hat ja keiner gesagt, dass es einfach ist :)
Jörg W. schrieb: > Totschlagargumenten Das Gefühl hab ich, wenn ich > Programmierer findet, der so masochistisch > ist, > Das wurde er schon vor 25 Jahren. Das macht trotzdem keine moderne > Architektur aus ihm. höre. Argumente, die hier fälschlicherweise auf die übliche Abnutzung materieller Dinge abzielen, mit entsprechend abwertenden Emotionen belegt sind.
Lothar schrieb: > Hast recht EFM8BB10F2 dürfte mit 25 MHz und 3-Stage-Pipeline etwas > schneller sein :-) Nicht nur das. Mit 12Bit ADC, Crossbar, Interruptprioritäten, in C programmierbar usw. usw. dürfte das die EiWoMiSa unter den kleinen MCs sein. Wow!
Tim . schrieb: > Also der ATtiny10 kann schon etwas mehr: Man kriegt auch ein Dutzend Leute in eine Telefonzelle. ;-)
A. K. schrieb: > Man kriegt auch ein Dutzend Leute in eine Telefonzelle. ;-) Mit Asm haben die Leute sogar noch ausreichend Platz drin ;-)
Moby schrieb: > Mit Asm haben die Leute sogar noch ausreichend Platz drin ;-) Ist aber auch keine Lösung. Gibt davon immer weniger: http://de.statista.com/statistik/daten/studie/13158/umfrage/oeffentliche-telefonzellen-in-deutschland-seit-2006/
Jörg W. schrieb: > Aber nur, wenn man einen Programmierer findet, der so masochistisch > ist, im 3. Jahrtausend noch 8051 programmieren zu wollen. Was ist denn an C-Programmierung und wählbaren Interruptprioritäten masochistisch, weißt Du was besseres? Der Keil C51 war für mich der Hauptgrund, das ganze Assemblergelumpe über Bord zu schmeißen. Ich hab nur mit offenem Mund auf den Output geschaut, wie effizient der war. Meine ganzen über Jahre erstellten Assemblerlibs waren ausnahmslos langsamer und größer. Auch hat der 8051 den Charme, daß viele Instruktionen keine Flags ändern, d.h. man kann oft Interrupthandler schreiben, die kein Push/Pop enthalten, also sauschnell sind.
Nun weiß ich aber immer noch nicht, welche Vorteile eine Jörg W. schrieb: > moderne > Architektur für Anwendungen bringt, denen ein bewährter einfacher 8051 oder ein noch einfacherer Tiny locker gerecht wird ???
Moby schrieb: > für Anwendungen bringt, denen ein bewährter einfacher 8051 Obwohl die kleinen 8051 die kleinen ARM im Preis immer noch deutlich schlagen, gibt es natürlich schon Anwendungen, wo die Rechenleistung der kleinen ARM gebraucht wird z.B. bei diesem Synthesizer der im DIP8 einen 44.1KHz Delta-Sigma DAC in Software (ARM Assembler) realisiert: https://www.adafruit.com/products/2400
Peter D. schrieb: > Was ist denn an C-Programmierung und wählbaren Interruptprioritäten > masochistisch, weißt Du was besseres? Wählbare Interruptprioritäten auf dem ARM vielleicht sowie ein flacher Adressraum? Ehrlich: wie viele konkurrierende Interruptquellen hast du wohl auf einem 6-Pinner (und um sowas ging's ja). Man kann es der ursprünglichen AVR-Architektur ja vorwerfen, dass sie sowas nicht hat, aber interessanterweise ist man damit gar nicht so schlecht gefahren. Wenn der Markt mit 8051, PIC und HCxx sowas von zufrieden gewesen wäre, hätte der AVR (und etwas im Schatten der MSP430) wohl vor 15 Jahren keinen solchen Siegeszug einfahren können, wie er es dann geworden ist: die haben es geschafft, einen gut aufgeteilten Markt doch recht gründlich aufzumischen. Offenbar gab es für die Anwender genügend Anreize, auf einen „bewährten Industriestandard“ doch lieber mal zu verzichten und auf ein neues Pferd zu setzen.
Jörg W. schrieb: > Wenn der Markt mit 8051, PIC und HCxx sowas von zufrieden gewesen > wäre, hätte der AVR (und etwas im Schatten der MSP430) wohl vor 15 > Jahren keinen solchen Siegeszug einfahren können, Wann kamen eigentlich die schnellen 8051er mit single-cycle Core auf? Der ursprüngliche und vor vielen Herstellern eingesetzte 12-cycle Core von Intel ist ja nicht grad für Tempo bekannt. Das könnte historisch schon eine Rolle beim Erfolg der AVRs gespielt haben.
A. K. schrieb: > Das könnte historisch schon eine Rolle beim Erfolg der AVRs gespielt > haben. Vermutlich, aber auch andere Dinge wie Push-Pull-Ausgangsstufen.
Jörg W. schrieb: > Wenn der Markt mit 8051, PIC und HCxx sowas von zufrieden gewesen > wäre, hätte der AVR (und etwas im Schatten der MSP430) wohl vor 15 > Jahren keinen solchen Siegeszug einfahren können Was für ein Siegeszug soll das gewesen sein? Google mal: EMITT Microcontroller Market and Technology Analysis Report 2008 Schon damals war AVR nach Stückzahlen kaum existent: 8051 19%, H8 17%, 68HC 15%, PIC 12%, ARM 10%, V850 9%, ST8 6%, AVR 3% Im aktuellen Report (leider nicht frei zugänglich) läuft AVR nur noch unter sonstige.
Lothar schrieb: > Was für ein Siegeszug soll das gewesen sein? Bei den Bastlern natürlich. Da wo es auf 'einfach' ankommt und keine zweckfremden Forderungen gängeln ;-) Aber Hut ab vor der Bedeutung der 8051er. Sicher alternativ keine schlechte Wahl.
Jörg W. schrieb: > hätte der AVR (und etwas im Schatten der MSP430) wohl vor 15 > Jahren keinen solchen Siegeszug einfahren können Der AVR hat allein durch den WINAVR im Hobbybereich einen Fuß in die Tür gekriegt. Und durch den günstigen ISP-Flash, der direkt am früher noch vorhandenen LPT-Port programmiert werden konnte. Die jungen Bastler haben ihn dann später in die Firma gepusht. Die CPU-Architektur war vollkommen nebensächlich. Nur mit dem IAR-Compiler wäre der AVR sang und klanglos untergegangen. Die Atmel Flash-8051 mit ISP waren erheblich teurer und der Keil C51 nicht gerade ein Schnäppchen. Und die kleinen 8051 (20-Pin) bekamen erst viel später ein ISP verpaßt. Die Atmel 8051 Division hätte den AVR vom Tisch fegen können, wenn sie gewollt hätte.
:
Bearbeitet durch User
Moby schrieb: > Aber Hut ab vor der Bedeutung der 8051er. Interessant ist aber, dass trotz ehemals grosser Popularität auch mal welche völlig wegsterben. So wurde der 8051 über den 8048 vom Fairchild F8 inspiriert, der in den 70ern den Markt von Mikrocontrollern prägte. Der F8 freilich ist längst völlig tot.
Peter D. schrieb: > Die Atmel 8051 Division hätte den AVR vom Tisch fegen können, wenn sie > gewollt hätte. Wobei bei den 8051ern wohl gewisse Lizenzen fällig sind oder früher waren. Ein Motiv Atmels für eine neue Familie dürfte deshalb auch gewesen sein, sich von solchen Zahlungen zu befreien. Das mag auch bei den AVR32 Pate gestanden haben, mit weniger Erfolg wie mir scheint. Generell scheint mir, dass die Marktverbreitung profitiert, wenn in einer kritischen Phase der Marktentwicklung alle die gleichen Vorbedingungen haben. ARM stellt selbst keine Chips her und Intel schon seit langem keine 8051er mehr. Es konkurriert also kein lizenzpflichtiger Hersteller mit dem Lizenzgeber. Das gilt auch für banal Erscheinendes wie Namensrechte - die Zahl 8051 ist nicht schützbar.
Ich vermute mal, daß einfach die Umsätze beim Atmel 8051 hoch genug waren, um kein Geld mehr reinzustecken. D.h. es wurde nicht als nötig erachtet, mehr Peripherie (ADC, interner Takt, BOD usw.) oder gar ein kostenloses 51Studio mit Compiler und Simulator/Debugger zu entwickeln. Die Idee vom Herrn Keil, mit den generic Pointern den Programmierer nicht mit der Architektur zu belasten, fand ich übrigens genial. Erst wenn weitere Optimierung nötig ist, kann man mit den memory specific Pointern Hand anlegen. Die generic Pointer gehen sogar soweit, daß man eigenen Speicher (SPI, I2C, 1-wire usw.) transparent einbinden kann. Man muß nur einmalig die Grundfunktionen (Byte/Block schreiben/lesen) implementieren. Als ich 1995 Fragen hatte, hat mir Herr Keil persönlich geantwortet. Support ist heutzutage aber mehr ein Fremdwort.
:
Bearbeitet durch User
Peter D. schrieb: > Die Idee vom Herrn Keil, mit den generic Pointern den Programmierer > nicht mit der Architektur zu belasten, fand ich übrigens genial. Hat der das tatsächlich erfunden oder auch bloss abgeguckt? Jedenfalls sind solche Pointer auch eine wesentliche Erleichterung bei den AVRs. Hat nur zu lang gebraucht, bis GCC eine mögliche Adressraumtrennung zuliess. Deren Fehlen war neben der Neugierde ein erheblicher Grund für mich, mich anderswo unzutun. Keil ist nicht so ganz meine Preisklasse.
Peter D. schrieb: > Der AVR hat allein durch den WINAVR im Hobbybereich einen Fuß in die Tür > gekriegt. Das kannste knicken. Von den paar Bastlern kann sich kein Hersteller ernähren, und den GCC haben sie anfangs bei Atmel komplett ignoriert. Da galt nur IAR als Stein der Weißen, alle relevanten Kunden haben sich den damals wohl schätzungsweise auch geleistet. Welch wichtige Rolle der GCC für den AVR spielt, haben sie erst sehr viel später erkannt – bis dahin wären sie ohne Kunden, die hinreichend viel von dem Kram kaufen, verhungert gewesen. Peter D. schrieb: > Ich vermute mal, daß einfach die Umsätze beim Atmel 8051 hoch genug > waren, um kein Geld mehr reinzustecken. Sie haben sich damals einfach mal überhaupt nicht als Controller-Laden verstanden. Sie sind als Hersteller von Flash groß geworden. Die Umorientierung auf Microcontroller als zentrales Element kam dann erst mit dem neuen Cheffe, aber da war der AVR bereits eine gut florierende Produktlinie.
Was ist jetzt eigentlich mit den angekündigten neuen ATtinies? In diesem Jahr scheint es ja nichts mehr zu werden.
Lt. dem Distributor Ineltek war geplant: Update: Neue Tinys mit neuen Key Features, optimierter BOM und analog Funktionen ab Q2 2015 6pins: TINY 101 / Tiny 051 (1KB/512B) 8 pins: Tiny 102 / Tiny 052 (1KB/512B) 14 pins: Tiny 804 (8KB) 20 pins: Tiny 806 / Tiny 406 (8KB/4KB) 24pins: Tiny 807 (8KB) Aber man kennt ja die Diskrepanz zwischen Atmel-Ankündigungen und dem realen Erscheinen der Produkte auf dem Markt. Und dann kommt jetzt noch die Dialog-Sache hinzu... Also ich würd mal sagen: Ende offen.
Tim . schrieb: > Leider at Atmel es immer noch nicht geschafft, den Compiler vernünftig > auf den reduced core anzupassen und STS/LDS zu verwenden. *arrrhg* Aber ok, der "Support" ist ja von Atmel...
Johann L. schrieb: > Aber ok, der "Support" ist ja von Atmel... Die werden schon wissen, warum sie den nicht offiziell bei GCC eingekippt haben. Das war wohl mal ein checklist item des zuständigen Menschen im Marketing, dass mit dem Auftauchen der ATtiny10 der GCC-Support dafür vorliegen solle, hatte ich den Eindruck. Das ist dann mehr oder minder halbherzig zusammengerödelt worden, jetzt ist das Häkchen gesetzt, und der diensthabende Inder bekommt keine Zeit mehr dafür zugestanden, es nochmal neu (und korrekt) zu implementieren. Abgesehen davon, dass es jemand extern als Hobby tut, dürfte nun wohl die einzige Chance sein, dass Atmel da nochmal was anfasst, indem massiv Bugreports dafür dort aufschlagen, die die schlechte Qualität der Toolchain in diesem Bereich vorführen. Wenn das genügend sind, dann wird wohl jemand die nötigen Ressourcen dafür einräumen müssen, das endlich zu reparieren.
Moby A. schrieb: > Johann L. schrieb: >> *arrrhg* > > ... das tut der Compiler-Effizienz wieder mal nicht gut ;-( Was wenn sie auch in den Assembler entsprechende Bugs einbauen? Es soll ja eine spezielle Codierung einiger Tiny-ohne-wertlos-Register-Befehle geben, die vom AVR-Standard abweichen. Ist das dann auch ein Problem der (falschübersetzten) Programmiersprache?
Carl D. schrieb: > Was wenn sie auch in den Assembler entsprechende Bugs einbauen? Naja, so sehr weicht der Tiny-Core in dieser Hinsicht nicht von den anderen ab, das ist schon noch recht überschaubar, was sich am Assembler da ändert. Beim Compiler sieht das jedoch ganz anders aus, da muss man vermutlich an einigen Stellen anfassen, um so einen stark minimierten Core nachträglich reinzuflanschen. Johann hat das sicher ein besseres Gefühl, wieviel Aufwand das ist.
Jörg W. schrieb: > Carl D. schrieb: >> Was wenn sie auch in den Assembler entsprechende Bugs einbauen? > > Naja, so sehr weicht der Tiny-Core in dieser Hinsicht nicht von den > anderen ab, das ist schon noch recht überschaubar, was sich am > Assembler da ändert. Schon klar, es ging mir eher um die Frage ob der Bug im Tool eine Unzulänglichkeit der Sprache ist. Du verstehst sicher warum.
Jörg W. schrieb: > Johann L. schrieb: >> Aber ok, der "Support" ist ja von Atmel... > > Die werden schon wissen, warum sie den nicht offiziell bei GCC > eingekippt haben. Und von wem ist dann der GNU-Support? > Das ist dann mehr oder minder halbherzig zusammengerödelt worden, > jetzt ist das Häkchen gesetzt, und der diensthabende Inder bekommt > keine Zeit mehr dafür zugestanden, es nochmal neu (und korrekt) > zu implementieren. D.h. die Inder müssen für jeden Pups um Erlaubnis Fragen? Dann hätt ich auf so nen Job ehrlich gesagt auch keinen Bock. Ne zeitlang hatte Atmel Embecosm angeheuert, die wirklich fähige GCC-Entwickler haben — zumindest hab ich die Aktivität bei Embecosm so gedeutet. Dabei ging aber vor allem um den C++ Support (libsupc++), aber diese Initiative scheint auch abgesägt. Jörg W. schrieb: > Carl D. schrieb: >> Was wenn sie auch in den Assembler entsprechende Bugs einbauen? > > Naja, so sehr weicht der Tiny-Core in dieser Hinsicht nicht von > den anderen ab, das ist schon noch recht überschaubar, was sich > am Assembler da ändert. Immerhin hatten sie es geschafft LDS/STS falsch zu codieren, d.h. der Code ist weder auf nem Target noch in nem Simulator getestet worden. > Beim Compiler sieht das jedoch ganz anders aus, da muss man vermutlich > an einigen Stellen anfassen, um so einen stark minimierten Core > nachträglich reinzuflanschen. Johann hat das sicher ein besseres > Gefühl, wieviel Aufwand das ist. Viel. Ich jedenfalls hab an dem Support nur was geändert wenn er was für nich-Tiny zerbröselt hat. M.E. sind die Dinger nicht wirklich sinnvoll in C nutzbar, zumindest soweit es avr-gcc angeht. ...andererseits würden einige meiner (privaten) C-Projekte, die auf 2KiB laufen und < 1KiB belegen auch locker dort hinein passen. (Wobei für die 9V -> -700V SMPS nen µC herzunehmen für Hobby ok ist, professionell würd ich das als Kunstfehler ansehen).
Und warum wird der überhaupt debondet? Das braucht doch nur Platz und ist teuer. Warum nicht einfach BGA wie der Dimple? http://www.golem.de/news/internet-der-dinge-freescale-zeigt-arm-chip-in-dimple-groesse-1402-104854.html
Johann L. schrieb: > Und von wem ist dann der GNU-Support? Die Frage verstehe ich in diesem Zusammenhang nicht. > D.h. die Inder müssen für jeden Pups um Erlaubnis Fragen? Die bekommen ihre Arbeit zugeteilt. Klar haben die auch Manager dafür, aber großartige Eigeninitiative wird dort wohl weder erwartet noch gewünscht. >> Naja, so sehr weicht der Tiny-Core in dieser Hinsicht nicht von >> den anderen ab, das ist schon noch recht überschaubar, was sich >> am Assembler da ändert. > > Immerhin hatten sie es geschafft LDS/STS falsch zu codieren, Wenn ich mich recht erinnere, haben sie es einfach verschlafen, die einzig nötige Änderung im Assembler passend und rechtzeitig einzutüten, nämlich LDS und STS anders zu codieren, wenn man für die Tiny-Cores assembliert. Allerding ist dieser Bug doch nun wirklich schon eine Weile korrigiert, oder?
1 | j@uriah 76% avr-as -mmcu=attiny25 -c foo.s |
2 | j@uriah 77% avr-objdump -d a.out |
3 | |
4 | a.out: file format elf32-avr |
5 | |
6 | |
7 | Disassembly of section .text: |
8 | |
9 | 00000000 <.text>: |
10 | 0: 00 91 40 00 lds r16, 0x0040 |
11 | j@uriah 78% avr-as -mmcu=attiny10 -c foo.s |
12 | j@uriah 79% avr-objdump -d a.out |
13 | |
14 | a.out: file format elf32-avr |
15 | |
16 | |
17 | Disassembly of section .text: |
18 | |
19 | 00000000 <.text>: |
20 | 0: 00 a1 lds r16, 64 |
Ja, ist er. Ihren eigenen Assembler hatten sie natürlich sehr wohl von vornherein korrekt abgewandelt. Ja, es sagt natürlich schon etwas über die Tests aus, dass ihnen das nicht aufgefallen ist. Irgendein Minimalbeispiel (welches ohne LDS/STS auskommt) hat man ja damit compilieren können, aber viel mehr als das nicht. >> Johann hat das sicher ein besseres >> Gefühl, wieviel Aufwand das ist. > > Viel. Das war/ist auch mein Eindruck dabei. > M.E. sind die Dinger nicht wirklich > sinnvoll in C nutzbar, zumindest soweit es avr-gcc angeht. Ja, was ein wenig schade ist. Für so einen Primitivling mit 512 oder 1024 Byte Flash noch egal, aber man hat sie ja danach bis 4 KiB gebaut.
Johann L. schrieb: > Und warum wird der überhaupt gebondet? Da fragst du mich zu viel. Wenn ich mir aber ansehe, dass man für das SOT-23 den halben Registersatz rausgeworfen hat, dann vermute ich schon, dass der Chip eines ATtiny10 wirklich so groß ist. Ganz habe ich nie verstanden, warum die paar Register so viel ausmachen sollen. Dass man Kondensatoren für die Vpp-Ladungspumpe spart und Programmierung des Flashs nur noch bei 5 V unterstützt, ist da eher verständlich.
Johann L. schrieb: > Und warum wird der überhaupt debondet? Das braucht doch nur Platz und > ist teuer. Warum nicht einfach BGA wie der Dimple? > CSP Flip Chip ist nicht unbedingt günstiger als ein SOT232-6 package. Außerdem vermute ich mal, dass ein ATtiny10-Die schon fast zu klein für die 6 Balls ist. Will mal jemand einen auf machen?
:
Bearbeitet durch User
Jörg W. schrieb: > Johann L. schrieb: > >> Und von wem ist dann der GNU-Support? > > Die Frage verstehe ich in diesem Zusammenhang nicht. Na weil du gemeint hast, der Tiny Support im FSF sei nicht von Atmel: Jörg W. schrieb: > Johann L. schrieb: >> Aber ok, der "Support" ist ja von Atmel... > > Die werden schon wissen, warum sie den nicht offiziell bei GCC > eingekippt haben. Oder hab ich das falsch verstanden? http://gcc.gnu.org/gcc-5/changes.html > On AVR, support has been added for the devices ATtiny4/5/9/10/20/40. > This requires Binutils 2.25 or newer. >> D.h. die Inder müssen für jeden Pups um Erlaubnis Fragen? > > Die bekommen ihre Arbeit zugeteilt. Klar haben die auch Manager > dafür, aber großartige Eigeninitiative wird dort wohl weder > erwartet noch gewünscht. Das ist natürlich die beste Möglichkeit, schlechte Qualität zu garantieren und die Entwickler zu frustrieren. Und wahrscheinlich auch nicht ganz unbedeutend für die hohe Fluktuation dort. Was LDS/STS by Tiny-Support angeht, so stammt der von 2014-10-21: http://gcc.gnu.org/r216525 und dort:
1 | /* AVRTC-579
|
2 | if operand is symbol or constant expression with value > 0xbf
|
3 | return false, otherwise true
|
4 | This check is used to avoid lds/sts instruction with invalid
|
5 | memory access range (valid range 0x40..0xbf). For io operand
|
6 | range 0x0..0x3f, in/out instruction will be generated. */
|
7 | |
8 | bool tiny_valid_direct_memory_access_range(rtx op, enum machine_mode mode) |
9 | {
|
10 | rtx x; |
11 | |
12 | if (!AVR_TINY) |
13 | return true; |
14 | |
15 | x = XEXP(op,0); |
16 | |
17 | if (MEM_P(op) && x && (GET_CODE(x) == SYMBOL_REF)) |
18 | return false; |
19 | |
20 | if (MEM_P(op) && x && (CONSTANT_ADDRESS_P (x)) && |
21 | !(IN_RANGE (INTVAL (x), 0, 0xC0 - GET_MODE_SIZE (mode)))) |
22 | return false; |
23 | |
24 | return true; |
25 | }
|
Das ist offenbar von Atmel (bzw. Embecosm) und in der aktuellen Version i.W. genauso drin:
1 | if (AVR_TINY |
2 | && CONSTANT_ADDRESS_P (x)) |
3 | {
|
4 | /* avrtiny's load / store instructions only cover addresses 0..0xbf:
|
5 | IN / OUT range is 0..0x3f and LDS / STS can access 0x40..0xbf. */
|
6 | |
7 | ok = (CONST_INT_P (x) |
8 | && IN_RANGE (INTVAL (x), 0, 0xc0 - GET_MODE_SIZE (mode))); |
9 | }
|
M.a.W: LDS/STS wird nur verwendet wenn die Adresse zur Compilezeit bekannt ist (d.h. const_int resp. bzw. weder symbol_ref noch const). LDS/STS kann 128 Bytes adressieren (0x40-0xbf), so dass LDS/STS bequem das ganze RAM (32 Bytes) adressieren kann. Der einzige Unterschied ist .rotata: Soweit ich weiß mappt Tiny den Flash in den Adressbereich von LD/ST, d.h. .rodata ist kein Teil von .data sondern muss im Linker-Skript entsprechend allokiert werden und ist nur indirekt zugreifbar wie Flash in den größeren Devices auch. Die einzigen Symbole, die nicht per LDS/STS ansprechbar sind liegen also in .rodata. Eine Erweiterung (z.B. Attribut) wäre erst dann notwendig, wenn LDS/STS nicht mehr das komplette RAM überdeckt. Mit der aktuellen Implementierung lässt sich LDS/STS also bestenfalls dann verwenden, wenn das RAM explizite beschrieben wird:
1 | #include <avr/io.h> |
2 | |
3 | typedef struct |
4 | {
|
5 | int x; |
6 | char c; |
7 | } ram_t; |
8 | |
9 | #define RAM (*(ram_t*) RAMSTART)
|
10 | |
11 | int get_x (void) |
12 | {
|
13 | return RAM.x; |
14 | }
|
1 | get_x: |
2 | lds r24,64 |
3 | lds r25,64+1 |
4 | ret |
Da allerdings die Kosten jenseits von Gut und Böse sind und selbst einfachste Mikrooptimierungen fehlen, ist der erzeugte Code unterirdisch:
1 | int get_value (void) |
2 | {
|
3 | return RAM.x - RAM.c; |
4 | }
|
1 | get_value: |
2 | ldi r30,lo8(64) |
3 | ldi r31,0 |
4 | subi r30,lo8(-(2)) |
5 | sbci r31,hi8(-(2)) |
6 | ld r20,Z |
7 | subi r30,lo8((2)) |
8 | sbci r31,hi8((2)) |
9 | ld r24,Z |
10 | subi r30,lo8(-(1)) |
11 | sbci r31,hi8(-(1)) |
12 | ld r25,Z |
13 | subi r30,lo8((1)) |
14 | sbci r31,hi8((1)) |
15 | sub r24,r20 |
16 | sbc r25,__zero_reg__ |
17 | sbrc r20,7 |
18 | inc r25 |
19 | ret |
Und ebenfalls übel ist dass LDD und STD entsorgt wurden, d.h. die einzigen Adressierungsarten sind direkt, indirekt (ohne Offset), post-increment und pre-decrement. Die aktuelle Implementierung taugt nicht für viel mehr als für ein Proof of Concept; ist ja auch ok für eine erste Unterstützng. Allerdings scheint an einer Verbesserung der Implementierung bis dato kein Bedarf zu bestehen...
Johann L. schrieb: > Oder hab ich das falsch verstanden? > > http://gcc.gnu.org/gcc-5/changes.html Ah sorry, der war mir entgangen. Allerdings hätte ich auch nicht gedacht, dass sie diese eher unterirdisch schlechte Implementierung wirklich dahin schieben. Andererseits: ihren Kunden haben sie sie ja schon vorher zugemutet (in den Patches ihrer AVR-Toolchain). Nein, die Fluktuation in Indien ist ein generelles Problem. Das geht dort rein nur nach $$$. Großartiges persönliches Engagement ist da eher eine ziemliche Ausnahme. Wenn die Firma in der Etage darüber mehr zahlt, dann geht man eben nach einem Jahr eine Etage höher arbeiten.
Er ist bald da! http://www.mouser.fi/ProductDetail/Atmel/ATTINY104-SSNR/?qs=%2FPOkb%252biDxRXVrw2KoZlR4A%3D%3D
Erstaunlich! Dann lässt man die Reduced-Core AVR wohl doch nicht sterben. Jetzt müssen nur noch die alten Bugs im AVR-GCC gefixed werden... Sieht nach einem automotive-Teil aus - 105°C und 125°C.
Tim . schrieb: > Jetzt müssen nur noch die alten Bugs im AVR-GCC gefixed werden... Na frisch ans Werk! Die Quellen liegen offen vor dir :-)
Also ich verstehe die negativen Äußerungen betreffend des Tiny 4/5/9/10 und 104ff nicht: -> Wer kann mir denn sonst einen Controller zeigen, welcher mit 6 Beinchen auf 2,9x2,2mm diese Leistung erbringt? Soll ich mir jetzt einen Industrial-Controller besorgen, um eine Akku-Steuerung für Zuhause zu bauen? Ich finde die kleinen Dinger super und hätte gerne mehr Auswahl < Tiny13
So, da sind die neuen Kandidaten: http://www.atmel.com/Images/Atmel-42505-8-bit-AVR-Microcontroller-ATtiny102-ATtiny104_Datasheet.pdf Zu den Vorteilen ihres Einsatzes wie auch der nach wie vor gegebenen Daseinsberechtigung der 8-Bitter: http://www.atmel.com/Images/Atmel-45178-Small-But-Mighty-The-Tiny-Microcontrollers-that-Shall-Prevail_Article.pdf So ein 102er 8-Pin Winzling hat doch jetzt tatsächlich UART, 5 Kanal ADC und 3 (!) eingebaute Spannungsreferenzen bei deutlich verbesserter Taktstabilität des internen 8-Mhz Takts = meist keine externen Bauteile mehr nötig. Damit in dieser Baugröße für noch mehr Einsatzfälle einsetzbar. Genial.
:
Bearbeitet durch User
Andreas B. schrieb: > Sind die schon käuflich? Mouser ist ein guter Früh-Indikator. Da gibts momentan aber auch noch nix. Etwas Atmel-Geduld brauchts noch ;-)
Wer es so gar nicht abwarten kann: Auf der Embedded World werden die ATTINY104-XNANO Boards verteilt. Muss man nur in der Nähe von Nürnberg sein.
Falls jemand einen ATtiny104 ergattern konnte - unten die AVRdude-Konfiguration, um ihn zu programmieren. TPI über USBASP funktioniert problemlos. avrdude.conf
1 | #------------------------------------------------------------ |
2 | # ATtiny104 |
3 | #------------------------------------------------------------ |
4 | |
5 | part parent ".reduced_core_tiny" |
6 | id = "t104"; |
7 | desc = "ATtiny104"; |
8 | signature = 0x1e 0x90 0x0B; |
9 | |
10 | memory "flash" |
11 | size = 1024; |
12 | offset = 0x4000; |
13 | page_size = 16; |
14 | blocksize = 128; |
15 | ; |
16 | ; |
Bitte mach einen Patchtracker bei AVRDUDE dafür auf (oder Bug tracker, mir egal).
OK, danke. Vor dem nächsten Release werde ich auf jeden Fall nochmal einen Sweep über die Bugs und Patches machen.
Ich habe angefangen, einen seriellen Bootloader für den ATtiny104 zu programmieren. Die aktuellen Files sind hier zu finden: https://github.com/cpldcpu/Gluon Achtung: Das ist keine fertige Software. Nachdem ich mich durch etliche Probleme der Toolchain gekämpft habe (Relocation bug, fehlende includes, etc...), funktioniert es in Ansätzen. Aber es gibt noch viele Bugs und die Größe ist noch nicht optimiert. Vielleicht hilft es jemandem bei eigenen Projekten. Das Ganze liegt erst einmal auf Eis, da mich eine Sinnkrise ereilt hat: Atmel scheint die ATtiny104 in einem Preisbereich zu positionieren (>0.45 USD/pc), wo der Nutzen dieses Devices mehr als fraglich erscheint. - AVRTiny ist nur sehr begrenzt kompatibel zur AVR Code-Basis. Zusätzlich ist auch die Peripherie deutlich verändert. Daher ist ohne größere Änderungen keine Nachnutzung existierender Software möglich. - Durch erhebliche Bugs in der Toolchain ist die Programmierung in C sehr stressvoll und ineffizient. - Bei der Entwicklung in Assembler müssen sich durch die begrenzte Registeranzahl die AVR-Veteranen auch umgewöhnen. - Es gibt dutzende bessere Alternativen mit besserer technischer Performance und geringeren Kosten. z.B. STM8, etliche CM0 Varianten (Nuvoton, STM, Cypress) Der ATtiny10 hat durch die kleine Größe einen gewissen Charme. Leider ist er auch erheblich teurer geworden. Beim ATtiny104 sehe ich im Moment eher Nachteile.
:
Bearbeitet durch User
Tim . schrieb: > Der ATtiny10 hat durch die kleine Größe einen gewissen Charme. Leider > ist er auch erheblich teurer geworden. Ob da wohl Microchip keine Konkurrenz im eigenen Hause haben möchte? Schließlich machte der ATtiny10 seinerzeit den Eindruck, als wäre er sehr wohl genau dafür entwickelt worden, dem pinkompatiblen PIC Konkurrenz zu sein …
Jörg W. schrieb: > Ob da wohl Microchip keine Konkurrenz im eigenen Hause haben möchte? Der Preis des ATtiny10 ist schön länger recht hoch. Auf die wirklichen Auswirkungen des Mergers müssen wir wohl noch ein paar Monate warten. Könnte mir aber vorstellen, dass es bei den devices mit tiny-core Auswirkungen gibt.
Wer es noch nicht gelesen hat, das Datenblatt revision B: http://www.atmel.com/devices/ATTINY104.aspx
Übrigens ist der Tiny104 jetzt frei verkäuflich: http://www.mouser.de/Search/Refine.aspx?Keyword=attiny104
Thread beobachten
Seitenaufteilung abschalten
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.