Die Evolution der Simply-AVR Controller schreitet auch 2015 weiter voran. Mit neuen innovativen Features und den gewohnt niedrigen Einstiegshürden. 8-Bit bleibt für den Bastler das Mittel der Wahl in allen Projekten, die keine 32 Bit Power benötigen. Einen interessanten Überblick zu den Neuerungen bietet Euch vorab A.Riedenauer im neuen CC2-TV, Folge 146. Ab kommenden Dienstag dann auch mehr Information direkt von Atmel auf der Electronica!
Wird solcherart Werbebeiträge hier toleriert? Ich find die Artikel ohne Autorenbezug usw. schon ziemlich grenzwertig und bekomme allmählich den Eindruck, dass in diesem Hobbyistenforum schon ziemlich viel Herstellerbeeinflussung steckt...
@BastiDerBastler: Wo ist das Werbung? Da fehlen doch Links für. Und ganz im Gegenteil, wenn ich "Moby" als Autor lese, filtere ich schon sofort aus und lese manchmal doch mal, um wieder einmal mehr zu Bestätigen: "Ah, irgend was Trolliges zu Atmel und wie geil 8 Bit für alles doch sind.". Per Definition also Antiwerbung, simple Provokation. Im Usenet hätte man dazu plonk gesagt.
:
Bearbeitet durch User
>8-Bit bleibt für den Bastler das Mittel der Wahl in allen Projekten, die >keine 32 Bit Power benötigen. Nö, man kann auch die 8Bit Aufgaben mit 32Bit Power bewältigen.
Dirk K. schrieb: > filtere ich schon sofort > aus und lese manchmal schon mal Irgendwie inkonsequent ;-) BastiDerBastler schrieb: > dass in diesem Hobbyistenforum schon ziemlich viel > Herstellerbeeinflussung steckt Ach woher denn. Eher Fakten und Tatsachen. Und dazu zählen auch ganz subjektive Erfahrungen ;-)
Also, was ist denn jetzt neu an den neuen ATTinies? Mitbekommen habe ich: - Hardware multiplier - Echte I²C, SPI, UART statt USI. (Hat der ATtiny841 aber auch schon) - RC-Oscillator mit hoherer frequenz und 1.5% genauigkeit
Moby schrieb: > Irgendwie inkonsequent ;-) In der Tat, das ist richtig. Ich hoffe immer wieder, auch was Konstruktives zu lesen. ;)
Dirk K. schrieb: > auch was > Konstruktives zu lesen In diesem Fall: Schau/hör Dir mal was Konstruktives an. Immerhin von keinem Bastler sondern von einem ausgewiesenem Fachmann ;-)
Moby schrieb: > Einen interessanten Überblick zu den > Neuerungen bietet Euch vorab A.Riedenauer im neuen CC2-TV, Folge 146 Habe ich mir jetzt extra angesehen :-) Zitat 1 : "eure 8-bit Prozessoren die Ihr da habt, die Teenies, die kleinen" Zitat 2 : "auch von Atmel gibt's ja da einige schöne Sachen wie die Cortex M0"
Lothar schrieb: > Zitat 1 : "eure 8-bit Prozessoren die Ihr da habt, die Teenies, die > kleinen" ... die jeden Z80 in die Tasche stecken. Und schon mit dem konnte man allerhand konstruieren! Lothar schrieb: > Zitat 2 : "auch von Atmel gibt's ja da einige schöne Sachen wie die > Cortex M0" Es mag Einsatzfälle geben wo die "schön" sind. Ansonsten bringt 8-Bit auch weiterhin Kosten+Stromverbrauchs-Vorteile.
holger schrieb: > Nö, man kann auch die 8Bit Aufgaben mit 32Bit Power bewältigen. Man kann auch jeden Tag mit nem 38-Tonner zur Arbeit fahren anstatt mit dem Auto. Man weiss nämlich nie wann einen die Frau anruft dass man aufm Nachhauseweg noch kurz was einkaufen soll. Man kann nie genug Platz im Kofferraum haben. Deshalb: Auf jeden popeligen Sensor nen zünftigen Quad-Core mit Kühler und Lüfter und das Gehäuse nicht 6mm sondern 6cm.
Moby schrieb: >> Zitat 1 : "eure 8-bit Prozessoren die Ihr da habt, die Teenies, die >> kleinen" Damit ist das Niveau der Sendung gemeint, der Frager hat keine Ahnung, ist nicht vorbereitet, und der "Fachmann" ... Moby schrieb: > ... die jeden Z80 in die Tasche stecken. Und schon mit dem konnte man > allerhand konstruieren! Wer den Z80 einfach findet, braucht zum ARM nichts mehr zu sagen. Und Zilog macht inzwischen auf 8051 : "Zilog’s new Z8051 product family"
Lothar schrieb: > Wer den Z80 einfach findet Nicht einfach Lothar- in die Tasche stecken meint leistungsmäßig. Und viel einfacher sind die AVRs dann auch noch ;-) Lothar schrieb: > Damit ist das Niveau der Sendung gemeint, Passt schon, Lothar. Alle wesentlichen Vorteile der 8 Bitter werden glasklar angesprochen- das ist jedenfalls meine Wahrnehmung.
Ich finde die 8bittter haben durchaus noch ihre Daseinsberechtigung. Es gibt so viele kleine Schaltungen wo es echt nicht mehr bedarf. Demnach sind auch Weiterendwickelungen der 8bitter durchaus gerechtfertigt. Zumal ich auch vermute das Firmen wie Atmel die teile längst nichtmehr bauen würden wenn sie die nicht verkaufen könnten.
AFAIK ist auch ne FPU mit Double Precision ab sofort verbaut! SCNR Ingo
Neue Entwicklungstools? Den Atmel-ICE benutze ich seit März. :-) PTC klingt schonmal gut. Mal schauen, wann man sowas wie einen Mega88PB (?) bekommen kann.
War das die Sendung mit dem Typ von MSC (oder Ineltek)? Habe ich nicht lange ausgehalten, der Herr Rudolph war schon anstrengend...
H.Joachim Seifert schrieb: > War das die Sendung mit dem Typ von MSC (oder Ineltek)? > Habe ich nicht lange ausgehalten, der Herr Rudolph war schon > anstrengend... Ich sehe das eigentlich auch nie, aber geil ist schon, alles was die da anfassen klappt erstmal nicht. Wie viele Jahrtausende gibt es diese Sendung? Auch früher kriegte der Typ kaum was auf Anhieb auf die Reihe. Mittlerweile ganz lustig.
Irgendwie sind die Hosts unprofessionell. Sind wir mal ehrlich: 8 bit ist legalicy. 32 bit gibts mitlerweile für 50ct (cortex m0) mit deutlich mehr flash und ram, mit super stromverbrauch usw... nxp,st,ifx,.. haben selbst ernannte 8bit killer rausgebrach. Außerdem wachsen die Anforderungen eher als dass sie weniger werden. Aber tot gesagte leben länger.
Ich arbeite viel mit 32 Bittern. Oft greife ich aber immer noch zu einem AVR oder PIC. Weil ich das DIP18 oder DIP28 Gehäuse mag. Wie der rechnet ist mir egal.
BastiDerBastler schrieb: > Wird solcherart Werbebeiträge hier toleriert? Ich find die Artikel ohne > Autorenbezug usw. schon ziemlich grenzwertig und bekomme allmählich den > Eindruck, dass in diesem Hobbyistenforum schon ziemlich viel > Herstellerbeeinflussung steckt... Vielleicht ist das nur die Antwort auf die Frage im anderen Thread Beitrag "Preise ATMega328AU"
Two cents schrieb: > 8 bit ist legalicy. 32 bit gibts mitlerweile für 50ct 8 bit ist erst legacy wenn es 32 bitter gibt : * die es in den selben Gehäuseformen gibt wie jetzige 8 bit * die weniger kosten als ein genauso kleiner 8 bitter * die genauso wenig (oder weniger) Strom verbrauchen * die genauso wenig Aufwand bei der Programmierung erfordern * wenn keine 8 bitter mehr produziert werden Dann wären sie legacy, vorher nicht. 32 bit mag für den Hobbybastler interessant sein weil er dem Irrglauben unterliegt immer mehr "power" zu brauchen als für die konkrete Aufgabe ausreichend ist, weil der Hobbybastler bei kleinen Stückzahlen nicht auf den Preis achten muss, weil er keinerlei Vorgaben hat was Gehäuseformen angeht, weil er Zeit hat bis zum Abwinken. In der Industrie jedoch wird auf den Preis geschaut, auf die konkret benötigten Anforderungen, da kostet jeder zusätzliche Quadratmillimeter Platine und zusätzliches Hühnerfutter, jede unnötige Schraube wird wegrationalisiert und plötzlich größere Gehäuse für Geräte die früher mal kleiner waren zu benötigen und den x-fachen Entwicklungsaufwand sind vollkommen inakzeptabel.
F. Fo schrieb: > alles was die da > anfassen klappt erstmal nicht Wie im wirklichen Leben auch- gerade das macht die Sendung so authentisch, auch wenn man sicher über die beteiligten Personen geteilter Meinung sein kann (Herr Rudolph platziert zuviel persönlichen Frust drin für meinen Geschmack). Two cents schrieb: > haben selbst ernannte 8bit killer Genau, selbst ernannte. Wunschdenken der Marketingabteilung. Zum Thema Stromverbrauch AVR (vs. ARM) gibt es auf der Electronica eine nette Demo zu bestaunen: "Atmel AVR MCUs are superior in terms of power consumption and any battery-driven application fits the AVR MCU better than any ARM-based MCU. The demo shows the AVR MCU with a wireless connection running off of a battery. It also has a graphical display to show power consumption data.
Was ist denn jetzt neu and den neuen ATtinies? Hat jemand mehr Informationen?
> "Atmel AVR MCUs are superior in terms of power consumption and > any battery-driven application fits the AVR MCU better than any > ARM-based MCU. The demo shows the AVR MCU with a wireless > connection running off of a battery. It also has a graphical display to > show power consumption data. > Wunschdenken der Marketingabteilung.
Daß 32-Bit niemals an den möglichen niedrigen Stromverbrauch von 8-Bittern herankommen kann ist nicht nur logisch, sondern nachweisbar. Daß 32-Bitter die 8-Bitter auf breiter Front "killen" würden dagegen nicht. Ein paar Gründe finden sich weiter oben...
Bernd K. schrieb: > 32 bit mag für den Hobbybastler interessant sein weil er dem Irrglauben > unterliegt immer mehr "power" zu brauchen als für die konkrete Aufgabe > ausreichend ist Wobei man aber daran denken muß, daß "fortschrittlichere" höhersprachige/OOP Programmierung (die die Dinge bekanntlicherweise sehr viel einfacher macht ;-) zunehmend mehr Hardware-Ressourcen verpulvert. Bedenkliche Beispiele sind zuhauf gerade auf dem PC zu bewundern. Auf meinem Atmel-Studio PC (man möchte meinen mit Gigaherz Doppelkern und SSD schnell genug) braucht allein die About-Info Box zum gnädigen Erscheinen bis zu 10 Sekunden. Eine unheilvolle Entwicklung.
32 Bernd K. schrieb: > Two cents schrieb: > > 8 bit ist legalicy. 32 bit gibts mitlerweile für 50ct > > 8 bit ist erst legacy wenn es 32 bitter gibt : > > * die es in den selben Gehäuseformen gibt wie jetzige 8 bit Xmc1100? > * die weniger kosten als ein genauso kleiner 8 bitter Xmc1100? 25ct @100k zu teuer? > * die genauso wenig (oder weniger) Strom verbrauchen Energy Micro? > * die genauso wenig Aufwand bei der Programmierung erfordern Dave apps sind zum zusammenklicken. Ich halte aber nix davon. > * wenn keine 8 bitter mehr produziert werden Totgesagte Leben länger. Ich glaube dass die mind. Noch 20 Jahre geben wird. > 32 bit mag für den Hobbybastler interessant sein weil er dem Irrglauben > unterliegt immer mehr "power" zu brauchen als für die konkrete Aufgabe > ausreichend ist, weil der Hobbybastler bei kleinen Stückzahlen nicht auf > den Preis achten muss, weil er keinerlei Vorgaben hat was Gehäuseformen > angeht, weil er Zeit hat bis zum Abwinken. Richtig. Time is money. Und nix kostet mehr geld festzustellen dass man zuwenig Flash hat. Mit den neuen Mcus kann man mehr features integrieren und kommt zum Soc. Z.b. den 5v ldo zu 3.3v nutzen spart 10ct. Konkrete Alernativen: Mkl05 von freescale, (guter mix von allem) Energy micro für ultra low power Xmc1100 für 5V replacements und wenn super preis sensitiv. Zudem haben alle super schnelle und genaue Adcs. Infineon hat tolle Timer. Um zu provozieren: Klar braucht man eine Mücke nicht mit ner Kanone abschiesen, aber viel hilft auch viel. Wenn du im supermarkt ein gut aussehendes Steak und eines über dem mhd hast. Wo greifst du zu?
Moby schrieb: > Two cents schrieb: >> Ich glaube dass die mind. Noch 20 Jahre geben >> wird. > > Na warum wohl? Ganz einfach: Es gibts langlebige Produkte und die wollen noch versorgt werden. Sei es die Heizungssteuerung, die nachproduziert wird oder ein Ersatzteil für einen Garentoröffner. Da übersteigen die Redesignkosten die MCU kosten. Aber für neudesigns 8bitter zu verbauen, wäre meines erachtens eine unkluge Entscheidung. (Ich schrieb oben als TwoCents)
Two cents schrieb: > Wenn du im supermarkt ein gut aussehendes Steak und eines über dem mhd > hast. Wo greifst du zu? Natürlich bei dem über dem MHD. Weil ich erstens nicht zu den dummen 08/15-Konsumenten gehöre denen man einreden kann das die Ware mit der Sekunde schlecht wird in der sie das MDH erreicht und zweitens weil es sehr viel billiger ist. Selbiges ist sinngemäß auf Mikrocontroller übertragbar.
Moby, Du bist herzlich dazu eingeladen, die Softwaremonster in ASM neu zu programmieren. Wir würden Dir alle danken! Ich gehe zwar nicht davon aus, dass Du zu meinen Lebzeiten noch fertig wirst, aber denke halt an die Folgegenerationen. Ich sag dazu nur, dass es einen Unterschied macht, ob man eine kleine Superloop-Anwendung programmiert (im Desktop unmöglich, bei Mikrocontrollern nach wie vor Stand der Technik), oder moderne Desktopentwicklung betreibt. Viele, die damals solche Software in Basic für DOS zusammengefrickelt haben, schön mit PutPixel und so, verstehen überhaupt nicht, dass Softwareentwicklung für den Desktop inzwischen ein wenig aufwändiger geworden ist, wegen der Systeme und wegen der erwarteten Funktionalität. Ich gehe zudem konform damit, dass man nicht mit Kanonen auf Spatzen schießen sollte. Aber eine Aufgabe sollte auf ihrer abstrakten Ebene optimal gelöst werden und dann die Hardware solange heruntergeschraubt werden, bis es nicht mehr geht, ohne die Lösung ihrer Struktur zu berauben. Man sollte die Software in ihrer Struktur nicht den Hardwaregegebenheiten anpassen müssen, weil man dann das Grundgerüst ständig ändern muss, nicht nur die Verkleidung.
Michael H. schrieb: > Ganz einfach: Es gibts langlebige Produkte und die wollen noch versorgt > werden Nö. Es gibt in erster Linie Produkte bei denen 8-Bit Power ausreicht! Daß 8-Bit prinzipiell weniger Strom benötigt, weniger Chipfläche und damit weniger Kosten verursacht ist ein Gesetz der Logik welches auch in Hundert Jahren noch gilt. Entscheidend ist: Was verlangt mein Projekt?
Two cents schrieb: >> * die es in den selben Gehäuseformen gibt wie jetzige 8 bit > Xmc1100? Gibts den auch im SOT-23 Gehäuse?
VomGlaubenAbgefallener schrieb: > Viele ... verstehen > überhaupt nicht, dass Softwareentwicklung für den Desktop inzwischen ein > wenig aufwändiger geworden ist, wegen der Systeme und wegen der > erwarteten Funktionalität. Die Funktionalität allein würde einen Bruchteil der heute verbrauchten Ressourcen erfordern! Nein, es sind die Programmiermethoden und die aufgeblasenen Systemarchitekturen, die eine About-Info Box bis zu 10 Sekunden verzögern (und noch sehr viel mehr). Nun kennt man ja die Windows Geschichte und die Alternativlosigkeit bei der "modernen" Desktop-Entwicklung, nachder die ganze Software-Landschaft auf schonungslosen Hardwareverbrauch ausgerichtet ist. Aber man muß mit dieser Vergeudungsmentalität ja nicht auch noch auf die MCUs einprügeln.
Der Punkt ist, dass Systeme immer komplexer werden. -Hat vor 5 Jahren eine USART Schnittstelle gereicht, wird heute Ethernet gefordert. -Hat man früher alles in 'ner Mainloop gemacht, ist ein einfaches OS gefordert. -Hat früher ein 8 Bit ADC für Staunen gesorgt, sind bekommt man heute kaum was unter 12 Bit. -Hat früher eine einfache PWM gereicht, musst du heute komplexe Waveforms generieren. (HRTIM von ST ganz schön). Und das alles in Assembler, wie oben erwähnt zu machen um jedes Bit zu sparen. Dann viel Spass. Wenn man nur 'ne LED Blinken lassen soll, keine Thema. Aber wieso verwendest Du dann keinen NE555? Der tuts doch auch. Wenn ich die Boardkosten bei uns anschaue: Der MCU geht unter. (Branche: Leistungselektronik). Ich glaube es dauert weniger als 2 Jahre, dann gibts die ersten Computernetzteile für Consumer, die komplett digital geregelt sind für ein paar Euro. Der Trend geht immer richtung integration, denn damit kann man sparen. Ziel ist es für mich immer, einen SOC zu schaffen. One does it all.
Moby schrieb: > VomGlaubenAbgefallener schrieb: >> Viele ... verstehen >> überhaupt nicht, dass Softwareentwicklung für den Desktop inzwischen ein >> wenig aufwändiger geworden ist, wegen der Systeme und wegen der >> erwarteten Funktionalität. > > Die Funktionalität allein würde einen Bruchteil der heute verbrauchten > Ressourcen erfordern! Nein, es sind die Programmiermethoden und die > aufgeblasenen Systemarchitekturen, die eine About-Info Box bis zu 10 > Sekunden verzögern (und noch sehr viel mehr). Um eines klarzustellen: Ich hasse auch diese Mentalität für alles ein HAL zu schaffen. Das muss wirklich nicht sein. Makros tuns auch. Aber das ist die entscheidung des Softwareentwicklers, nicht der der Hardware. >Aber man muß mit > dieser Vergeudungsmentalität ja nicht auch noch auf die MCUs einprügeln. Ja richtig, 100% Zustimmung. Aber trotzdem muss man nicht die ältesten Knochen verbauen. Und trotzdem hilft es, ein OS zu haben, wo eine kleine Änderung schnell umgesetzt werden kann. Es macht keinen Sinn, sich in der Softwarearchitektur Leistung duch inflexibilität einzukaufen. Beispiel: Angenommen du brauchst eine funktion die 1x pro Stunde aufgerufen wird. Stell dir vor du hast 100x dieser Funktionen: Wie übersichtlich ist dann deine Mainloop?
Michael H. schrieb: > Wenn man nur 'ne LED Blinken lassen soll, keine Thema. Aber wieso > verwendest Du dann keinen NE555? Der tuts doch auch. Wenn ich noch ne winzige Kleinigkeit mehr als Blinken benötige aber kein Platz mehr auf der Platine ist, noch nicht mal mehr ein einziger Transistor draufpasst, was nehm ich dann?
1. Es gibt auch "schlanke" Desktops http://www.menuetos.de 2. Rindersteaks dürfen ruhig etwas abgelagert sein ....
Moby schrieb: > Daß 8-Bit prinzipiell weniger Strom benötigt, weniger Chipfläche und > damit weniger Kosten verursacht ist ein Gesetz der Logik Das wäre so wenn 8-bit und 32-bit im selbsten LP-CMOS Prozess gefertigt würden. Tatsächlich werden AVR in 150nm gefertigt und ARM in 90nm oder 45nm und verbrauchen prinzipiell weniger uA/MHz. Dazu kommt noch dass ARM alle Befehle in 1 Zyklus verarbeitet, somit ist bei Batterie-Anwendungen die Zeit außerhalb des Sleep-Mode deutlich kürzer als beim AVR. Schliesslich ist, wie schon mehrfach erwähnt, die ARM Architektur um einiges älter als AVR, und kann auch mit <10k Gatter implementiert werden, was heute wo es aufs Strom sparen ankommt wieder entdeckt wurde und als M0+ Innovation verkauft wird.
Lothar schrieb: > Das wäre so wenn 8-bit und 32-bit im selbsten LP-CMOS Prozess gefertigt > würden. Die neuen 8-Bit gehen da aber auch weiter runter. Ansonsten sag ich mal nur: Leckströme ;-) Michael H. schrieb: > Beispiel: Angenommen du brauchst eine funktion die 1x pro Stunde > aufgerufen wird. Stell dir vor du hast 100x dieser Funktionen: Wie > übersichtlich ist dann deine Mainloop? Dafür brauchts aber kein ausgewachsenes OS (mit dem die Dinge ja auch nur komplexer werden). Diese Funktionalität ist doch in einem übergeordneten Timerint schnell zur Verfügung gestellt. Lothar schrieb: > Dazu kommt noch dass ARM alle Befehle in 1 Zyklus verarbeitet, somit ist > bei Batterie-Anwendungen die Zeit außerhalb des Sleep-Mode deutlich > kürzer als beim AVR Bei AVR benötigt vieles ja auch nur 1 Clock.
Two cents schrieb: > Und nix kostet mehr geld festzustellen dass man > zuwenig Flash hat. Nix kostet mehr festzustellen daß ein Projekt ewig nicht fertig wird. Mit der Verwendung von Asm ist man beim Flashverbrauch meist auf der sicheren Seite ;-)
Wir sollten jetzt vielleicht mal die About-Box herausnehmen, ich denke mal, die wird im Hintergrund noch irgendwelche Plugin-Listen abgrasen um von allem schön die Versionsnummern usw. darzustellen, dafür müssen Plugins geladen werden, die um Ressourcen zu sparen überhaupt nicht geladen wurden (lazy load usw. usf.). Hast Du denn mal eine Software in diesen Ausmaßen mit was weiß ich nicht wievielen Entwicklern verantwortet? Du sprichst hier nur von aufgeblasenen Techniken, OO machst Du schlecht. Dass diese Techniken mit normaler MCU-Programmierung eigentlich überhaupt nix am Hut haben lässt Du aber irgendwie unter den Tisch fallen. Selbst in der schlechtesten HAL-Bibliothek sehe ich diese Techniken nicht. Da wird nur mit den Techniken gearbeitet, die in der Desktop-Entwicklung schon lange aus gutem Grund vermieden werden. Ich habe den Eindruck, dass die Embedded-Landschaft in der Hinsicht ohne Grund auf der Stelle tritt. Und wenn ich hier von Makros als Lösung lese, kriege ich doch das Kotzen. Makros sind eine Ausgeburt des Schlechten. Halten sich an keine Namespaces, müllen den globalen Namespace zu, werden gerne zu unverständlichsten Konstrukten zusammengezimmert usw. usf. Ich wünschte mir, die ganzen Bibliotheken würden mal auf den aktuellen Stand von C++ gebracht, mit Templates, constexpr, user defined literals usw.. Auf einmal würde die MCU-Software übersichtlich werden... Wohlgemerkt ohne Klassenhierarchien und unnötigen Ballast. Einfach die Codegenerierungs-Möglichkeiten ausnutzen.
Bernd K. schrieb: > Wenn ich noch ne winzige Kleinigkeit mehr als Blinken benötige aber > kein Platz mehr auf der Platine ist, noch nicht mal mehr ein einziger > Transistor draufpasst, was nehm ich dann? Ja was nimmst Du denn jetzt? Bernd K. schrieb: > Gibts den auch im SOT-23 Gehäuse? Gibt es sogar noch kleiner als WLCSP 2x2mm ist aber nicht Bastler-freundlich.
Lothar schrieb: >> Gibts den auch im SOT-23 Gehäuse? > > Gibt es sogar noch kleiner als WLCSP 2x2mm ist aber nicht > Bastler-freundlich. Das stellt extremst höhere (teurere) Anforderungen an den Fertigungsprozess -> inakzeptabel. Nächster Vorschlag bitte.
VomGlaubenAbgefallener schrieb: > Du sprichst hier nur von > aufgeblasenen Techniken, > Wir sollten jetzt vielleicht mal die About-Box herausnehmen, Auf keinen Fall! Besser läßt sich der Kontrast von simpler Funktionalität zu aufgeblasenem Software-Aufwand im Hintergrund ja gar nicht herausarbeiten ;-)
VomGlaubenAbgefallener schrieb: > Selbst in der schlechtesten > HAL-Bibliothek sehe ich diese Techniken nicht. Atmel ASF :-)
VomGlaubenAbgefallener schrieb: > Hast Du denn mal eine Software in diesen Ausmaßen mit was weiß ich nicht > wievielen Entwicklern verantwortet? Du sprichst hier nur von > aufgeblasenen Techniken, Das "Wie entwickeln" muss mich als Anwender nicht interessieren. Was zählt ist das Ergebnis. Wenn das darin besteht auf schon eine simple Info-Box warten zu müssen muß das "Wie entwickeln" hinterfragt werden, nicht die Anwender-Erwartungen.
Mit anderen Worten: Du hast eigentlich überhaupt gar keine Ahnung, ob das beobachtete Verhalten von den genannten Entwicklungstechniken stammt. Du verstehst wahrscheinlich noch nichtmal, was in der About-Box überhaupt passiert, das zu Verzögerungen führen könnte. Du überbewertest zudem die Relevanz, weil praktisch niemand jemals diese About-Box anklickt, was auch dazu führen könnte, dass man da als Entwickler nicht allzu viel Hirnschmalz reinsteckt (Vielleicht wird die aktuellste Version und die Updates aus dem Internet bezogen und der Entwickler hatte kein Bock auf eine asynchrone UI extra dafür). Sehr wahrscheinlich dauert es noch nichtmal 10 Sekunden, sondern Du übertreibst, um die Diskussion zu färben. Im Prinzip weißt Du eigentlich überhaupt nix, aber hast viel heiße Lust abgelassen! Weil DU bist der Anwender, DU bist King! Hehehe. Lustig hier.
Oh, gar nicht lustig hier, wenn Entwicklerehren getroffen werden! Natürlich sind jedwede Verzögerung, auch der Mega/Gigabyteweise Speicherbedarf höherer Natur, nur bloß nicht durch die Art der Programmierung bedingt. Und Du hast recht, King ist der Anwender, nicht der Programmierer der Gott spielen möchte.
King ist der Programmierer, der seine Entwicklungszeit auf relevante Dinge konzentriert.
VomGlaubenAbgefallener schrieb: > King ist der Programmierer, der seine Entwicklungszeit auf > relevante Dinge konzentriert. Das könnte sehr zum Problem aufgeblasener, ineffizienter Codes und Systenarchitekturen beitragen.
Junge, einerseits gehst Du hier total auf die effiziente Lösung von Problemen ein, das würde einen zu dem Schluss verleiten, dass Dich die Lösung solcher Probleme interessiert, und Du Dir gerne Gedanken darüber machst, das Technische also im Blick hast. Aber argumentieren tust Du hier ohne irgendeine technische Substanz, ja gar mit dem Übergehen aller Argumente. Das ist so ein bisschen schizophren. Oder halt trollig ;) Und ich lade Dich hiermit nocheinmal dazu ein, eine effiziente, unaufgeblasene Systemarchitektur, ein solches Betriebssystem und die dazugehörige Software zu entwickeln, beziehungsweise ein Unternehmen dafür zu gründen. Viele, auch ich, wären daran interessiert. Bis Du damit fertig bist, komme ich aber auch gut mit dem zurecht, was derzeit zur Verfügung steht. Mir kommen manche Dinge auch suboptimal vor, aber da ich tatsächlich Erfahrung in der Richtung habe, im Gegensatz zu Dir, bin ich da eben etwas verständnisvoller eingestellt. Für einen außenstehenden kann man eigentlich nur das Argument machen: Wenn x unabhängige Lösungen in Ergebnis y im Gegensatz zum gewünschten Ergebnis z enden, dann scheint da etwas zu sein, das z verhindert. Oder alle aus einem selbst sind Idioten... Wähle selbst!
Moby schrieb: > den gewohnt niedrigen Einstiegshürden Diese Hürden sind wohl nicht niedrig genug: Beitrag "AVRISP mkii Schritt für Schritt Anweisung"
VomGlaubenAbgefallener schrieb: > eine effiziente, > unaufgeblasene Systemarchitektur, ein solches Betriebssystem und die > dazugehörige Software zu entwickeln Schon mal RISCOS angesehen? In 1987 für den ersten ARM entwickelt, dann lange brach gelegen, seit 2012 enorm weiterentwickelt. Die Schnelligkeit vom Desktop im Vergleich zu Linux ist beeindruckend und selbst Cortex A sind damit als uC einsetzbar, GPIO bis 20 MHz Ansonsten, warum nicht das GUI auf einem Windows-IPC lassen und einen Cortex M über USB als uC?
Ich persönlich befürworte effiziente Software, weil sie einfach auch Energie spart. Anwendungsprogramme, die auf einem OS laufen in Assembler zu programmieren ist meiner Meinung nach aber unsinnig in der heutigen Zeit. Bei einer objektorientierten Hochsprache kann ich C++ oder Java nehmen, allerdings verbraucht Java bedeutend mehr Rechenleistung für die gleiche Aufgabe wie C++. Und meiner Beobachtung nach sind die ganzen langsamen Benutzeroberflächen in Java geschrieben. Für viele kleinen Aufgaben wird kaum Rechenleistung benötigt. Wieso soll man dafür einen Leistungsstarken µC verbauen? Die 8 Bitter werden ja offensichtlich auf den "alten" Anlagen produziert. Wäre das nicht mehr der Fall müssten die Kosten für die neuen Anlagen steigen, da sie nur kürzer produzieren können, bis die Technologie überholt ist. Ein paar Vorteile, die ich in 8 Bittern gegen über 32 Bittern sehe ist die geringere Komplexität, womit weniger Fehler beim Entwickeln entstehen. Da muss man nämlich Teil gut aufpassen, wenn man Funktionen verwenden möchte, die eigentlich gar nicht oder nur mit Tricks funktionieren. Auch Sicherheitskritische Anwendungen dürften sich auf einem 8 Bitter besser auf Fehlerfreiheit überprüfen lassen, als auf einem 32 Bitter. Gruß Kai
Lothar schrieb: > Diese Hürden sind wohl nicht niedrig genug: IchGlaubeEsNicht schrieb: > Du brauchst bestimmt auch eine Anleitung, um dir deine Hosen mit der > Kneifzange anzuziehen. > > Eigentlich kommen selbst Toastbrote mit dem AVR-Studio 4 AVRISP mkii > problemlos zurecht. VomGlaubenAbgefallener schrieb: > Mir kommen manche Dinge auch suboptimal vor Das gibt mir Hoffnung. VomGlaubenAbgefallener schrieb: > aber > da ich tatsächlich Erfahrung in der Richtung habe, im Gegensatz zu Dir, > bin ich da eben etwas verständnisvoller eingestellt Für Suboptimales ist kein Verständnis angebracht, es gilt es zu verbessern. VomGlaubenAbgefallener schrieb: > Und ich lade Dich hiermit nocheinmal dazu ein, eine effiziente, > unaufgeblasene Systemarchitektur, ein solches Betriebssystem und die > dazugehörige Software zu entwickeln Danke, sehr großzügig. Für meine Haussteuerung ist mir das im Großen und Ganzen auch gelungen. Softwareentwicklung ist aber aufwendig. Da wird keiner allein die Revolution aus dem Stand hervorzaubern. Aber man darf und muß Fehlentwicklungen hinterfragen. Insbesondere wenn sie auch im MCU-Bereich drohen Fuß zu fassen. Lothar schrieb: > Ansonsten, warum nicht das GUI auf einem Windows-IPC lassen und einen > Cortex M über USB als uC? Du meine Güte, Lothar! Nennst Du das eine einfache, kleine, stromsparende Lösung? Viel eher dann doch bitte so: Michael H. schrieb: > Der Trend geht immer richtung integration, denn damit > kann man sparen. Ziel ist es für mich immer, einen SOC zu schaffen. Ziel muß sein, Hardware fortlaufend zu verkleinern und -meine Meinung- immer mehr grundlegende Softwarefunktionen in intelligenterer Hardware abzubilden und so die vorherrschende Konfiguritis einzudämmen.
Kai S. schrieb: > Ein paar Vorteile, die ich in 8 Bittern gegen über 32 Bittern sehe ist > die geringere Komplexität, Das ist schlicht DER Vorteil und mit diesem Pfund wird 8-Bit auch immer wuchern. Kai S. schrieb: > sind die ganzen > langsamen Benutzeroberflächen in Java geschrieben Ein Beispiel wie allein mit der Programmiermethode Ressourcen verbraten werden.
Moby schrieb: > Ziel muß sein, Hardware fortlaufend zu verkleinern Im Consumer-Bereich mag das zutreffen, obwohl dadurch hauptsächlich Elektroschrott produziert wird, weil nichts mehr repariert werden kann. In der Industrie sollte eine Platine noch reparabel sein. Moby schrieb: > immer mehr grundlegende Softwarefunktionen in intelligenterer Hardware > abzubilden Der Trend geht aber in die andere Richtung, statt USART, SPI, I2C etc. Hardware-Controller dann Serial Engines und ROM-Treiber, weil das mittlerweile schneller und stromsparender ist. Moby schrieb: > Nennst Du das eine einfache, kleine, stromsparende Lösung? Für viele Leute ist es genau das, weil viele Win/VB sowieso kennen. Stromsparend ist es auch, der IPC ist ausgeschaltet und der Cortex M steuert oder schläft. Wenn einer kommt und das GUI sehen will, schaltet er den IPC ein. Dasselbe Prinzip gibt es schon lange im Consumer-Bereich: wenn man das iPad nicht anfasst, schläft der Cortex A und der Cortex M liest die Sensoren aus.
Nicht zerrupfen, was nicht zerrupft gehört. Ob einem etwas suboptimal vorkommt oder ob es suboptimal ist, hängt von den Dingen ab, die man nicht bedacht hat. Derjenige, der das implementiert hat, hatte mit großer Sicherheit im Verlaufe der Entwicklung mehr zu bedenken und zu beachten, als einem mit einem flüchtigen Blick in den Sinn kommt.
was auch immer jetzt schon weider diese Threat ausufert... Ich fand es interessant das es bei den Attinys auch neues gibt, verfolge nicht immer was es neues gibt, nutze meist meinen Atmega oder Xmega128A3U oder A4U und stoße daher eher durch Zufall auf Neuigkeiten. Und was haben manche hier eigentlich für ein PRoblem mit klar plazierter Werbung!?!? RAfft ihr eigentlich nicht, das dieses Forum durchseucht ist mit Wirtschaftlichen Interessen!! Die Eigentlich Werbung findet ganz unbemerkt statt, damit die Schlaumeier dan ganz unbewusst aufsaugen und sich auch noch eibliden können sie hätten eine Freien willen und wären nicht beeinflusst! Ich kenne kein anderes Forum welches so Wirtschaftlich Interessen geschuldet ist wie das mikrocontroller.net ah doch SEX Foren :-) Da läuft das gleiche ab, und niemand merkts :-)
Was ist denn eigentlich gerade die Fehlentwicklung? Dass Leute sich lieber erstmal auf einem großen µC anfangen und bei fertiger Lösung runterskalieren? Dass Leute lieber ein sicheres Layout haben, als für jedes Experiment ein eigenes Layout zu routen und in Auftrag zu geben? Zu Anfang waren wir ja noch bei About-Boxen...
VomGlaubenAbgefallener schrieb: > Nicht zerrupfen, was nicht zerrupft gehört. Ob einem etwas > suboptimal > vorkommt oder ob es suboptimal ist, hängt von den Dingen ab, die man > nicht bedacht hat. Derjenige, der das implementiert hat, hatte mit > großer Sicherheit im Verlaufe der Entwicklung mehr zu bedenken und zu > beachten, als einem mit einem flüchtigen Blick in den Sinn kommt. Schön. Klassische Entwicklersicht. Die ist dem Anwender aber wurscht. Der erwartet eine flotte Lösung. Keine Info-Box, die sich Zeit lässt. Mein Gott, wir schreiben 2014 ;-( Lothar schrieb: > Dasselbe Prinzip gibt es schon lange im Consumer-Bereich: wenn man das > iPad nicht anfasst, schläft der Cortex A und der Cortex M liest die > Sensoren aus. Mal davon abgesehen, daß zum Steuern/Sensor-Auslesen ein kleiner AVR langt. Und die Visualisierung übernehmen transportable Displays. Immer öfter wird man nicht mal mehr darauf schauen weil immer mehr immer besser automatisiert ist.
Mir als Anwender ist die About-Box herzlich egal. Ansonsten finde ich Visual Studio sehr gut, was anderes ist doch Atmel-Studio auch nicht? Mit etwas Arbeit kann man sich sogar Eclipse benutzbar machen, nur das mit den eng mit der Software verwobenen Workspaces stört mich etwas. Welche Teile stören Dich denn bei der produktiven Arbeit? Oder schaust Du vor jedem Arbeitsgang erstmal in die About-Box, damit Du sicher bist, dass die Version noch die gleiche ist? Bist Du denn jetzt schonmal auf all meine Theorien eingegangen, warum die About-Box träge sein könnte und warum es sich nicht lohnt dafür die optimale Lösung zu finden? uswusf...
Timo schrieb: > durchseucht ist mit > Wirtschaftlichen Interessen! Muß ich aber entschieden von mir weisen! Mit AVR macht man als Bastler einfach gute Erfahrungen. Verbunden mit dem Gefühl, für viele Problemstellungen das beste Werkzeug zu haben. VomGlaubenAbgefallener schrieb: > Was ist denn eigentlich gerade die Fehlentwicklung? Die nennt sich 32-Bit / ARM + womöglich noch fette OOP für (sehr viele) Problemstellungen, die ein kleiner 8-Bitter schon locker bewältigt. VomGlaubenAbgefallener schrieb: > Dass Leute sich > lieber erstmal auf einem großen µC anfangen und bei fertiger Lösung > runterskalieren? Wer so vorgehen möchte soll das tun. Ich würde lieber gleich auf die fertige Lösung (µC) zielen. VomGlaubenAbgefallener schrieb: > Dass Leute lieber ein sicheres Layout haben, als für jedes Experiment > ein eigenes Layout zu routen und in Auftrag zu geben? Dafür langt aber in sehr vielen Fällen schon ein AVR. Mit nur einem, sichereren Layout wird man allerdings meist die optimale Lösung verfehlen- wenngleich es alles in allem wirtschaftlicher sein kann.
Warum eigentlich dann nicht 16 bit? Die meisten Anwengen auf dem AVR nutzen effektiv 16 bit. Selbst der standard-datentyp von AVR-GCC ist 16 bit. Ich vermute, dass eine 16 Bit CPU für die meisten Probleme das theoretische Optimum an energie- und codeeffizienz darstellt.
VomGlaubenAbgefallener schrieb: > Mir als Anwender ist die About-Box herzlich egal VomGlaubenAbgefallener schrieb: > Bist Du denn jetzt schonmal auf > all meine Theorien eingegangen, warum die About-Box träge sein könnte > und warum es sich nicht lohnt dafür die optimale Lösung zu finden? Die interessieren mich aber nicht. Die billige Box hat sofort dazusein. Sie sollte nur illustrieren, daß ... Moby schrieb: > Besser läßt sich der Kontrast von simpler > Funktionalität zu aufgeblasenem Software-Aufwand im Hintergrund ja gar > nicht herausarbeiten ;-) Basta. VomGlaubenAbgefallener schrieb: > Welche Teile stören Dich denn bei der produktiven Arbeit? Daß der Speed anno 2014 größer sein könnte? Daß auf meiner SSD mehr Platz übrig sein könnte? Dr. N. Rokpop schrieb: > Ich vermute, dass eine 16 Bit CPU für die meisten Probleme das > theoretische Optimum an energie- und codeeffizienz darstellt. Und ich bei 8 Bit! Die 16er sind doch schon längst out ;-)
Kai S. schrieb: > Ein paar Vorteile, die ich in 8 Bittern gegen über 32 Bittern sehe ist > die geringere Komplexität, womit weniger Fehler beim Entwickeln > entstehen. Wie jeder weiss der mit beiden gearbeitet hat ist 8-bit aus Prinzip komplexer als 32-bit: kein gemeinsamer logischer Adressraum für Flash/RAM/Peripherie, 16-bit Adresspointer, 8-bit Multiplikation, High/Lowbyte bei 10-bit ADC usw. Dazu ist AVR in sich inkompatibel, schon mal versucht ein Programm mit Flash-IAP vom Tiny auf den Mega zu portieren? Moby schrieb: > Mit AVR macht man als Bastler einfach gute Erfahrungen. Hast Du hier schon mal Projekte von Dir vorgestellt? Dr. N. Rokpop schrieb: > Warum eigentlich dann nicht 16 bit? 1. AVR ist schon verkappt 16-bit mit Verrenkungen, siehe oben 2. Es gab ja mal erfolgreiche 16-bit z.B. 68HC12 aber die können preislich bei weitem nicht mehr mit 32-bit mithalten
Du sagst ja bloß dass die Box billig ist... Offenbar ist sie das aber nicht, und wir können beide im Moment nur raten, warum das so ist... :) Und das bei einer Sache, die total irrelevant ist... Zeitverschwendung. >> Welche Teile stören Dich denn bei der produktiven Arbeit? >Daß der Speed anno 2014 größer sein könnte? >Daß auf meiner SSD mehr Platz übrig sein könnte? Wer direkt den richtigen µC für das Problem benutzen will, der kümmert sich bei seiner SSD also darum, dass sie unnütz überdimensioniert ist? Welcher Speed?
Lothar schrieb: > ist 8-bit aus Prinzip > komplexer als 32-bit Nun wirst Du aber albern. Wenn es 32 Bits für Berechnungen usw. bedarf nimmt man halt eínen 32-Bitter. Lothar schrieb: > Dazu ist AVR in sich inkompatibel Genauso Quatsch. Paß den I/O Zugriff an und gut ist. Lothar schrieb: > Hast Du hier schon mal Projekte von Dir vorgestellt? Nein. Bei einer Haussteuerung ist vieles zu speziell, gerne gebe ich aber Anregungen zum Thema ;-)
Für die 32biter wäre es eigentlich echt schön, wenn es so günstige DIP Adapter gäbe.
UserBla13333443 schrieb: > Für die 32biter wäre es eigentlich echt schön, wenn es so günstige DIP > Adapter gäbe. Was willst du denn mit einem 32-Bit Controller? Du findest ja nicht mal einen DIP-Adapter im Internet.
Natürlich ist seine optimale Lösung ziemlich speziell. Deshalb schreibt sich ja auch jeder seine optimale Lösung und lästert über die suboptimalen Werkzeuge, die er wie auch jeder andere dazu verwenden muss und die sich überhaupt nur aufgrund der eigenen Erhabenheit dazu verwenden lassen, das eigene Problem zu lösen.
Neue AVR-Tiny Generation, neue B-ATMegas, neue Entwicklungstools altes Gelaber Werdet Ihr denn nie müde, immer die gleichen Phrasen und Worthülsen abzusondern?
An einem Sonntag müssen sich die Gemüter eben erhitzen, lass uns das doch! :)
Achim schrieb: > Was willst du denn mit einem 32-Bit Controller? Du findest ja nicht mal > einen DIP-Adapter im Internet. lol, du meinst die Dinger wo man löten muss? Macht wenig Sinn, wenn ich es löten könnte würde ich kein Adapter brauchen. Ich meine ein Adapter wo man das Ding einfach drauf stecken kann. Davon gibt es nur sehr wenige und zu teuer...
VomGlaubenAbgefallener schrieb: > lästert über die > suboptimalen Werkzeuge, die er wie auch jeder andere dazu verwenden muss Falsch. AVR+Asm ist das optimale Werkzeug für sehr vieles- darüber habe ich auch nicht gelästert ;-) Über das AVR Studio lässt sich ja streiten. Ist jedenfalls ein ganz schöner Klotz geworden. Auf die neue Atmel Hardware bin ich jedenfalls gespannt- mal sehen was noch so auf der Messe in Erfahrung zu bringen ist.
Warum muss es eigentlich immer in diesen Fanboy Kriegen enden? Fakt ist, beide Systeme haben ihre Vor und Nachteile. Für einfach I/O Geschichten ohne Grafischer Oberfläche reicht ein AVR idr. aus. Klar gibt es Anwendungen, in denen eine Grafische Oberfläche oder eine sehr Komplexe Rechnung notwendig ist. Hier spielt dann auch ein ARM seine Stärken aus. Aber die AVRs von vorne herein als schlecht darzustellen ist auch falsch. So schön kompatibel untereinander sind die ARMs aber auch nicht, wie es manch hier immer darstellen. Der Kern ist bei allen gleich, das stimmt, aber bei der Peripherie hört die Gemeinsamkeit schon auf. Hier kocht dann jeder Hersteller sein eigenes Süppchen, was eigentlich schade ist. Hier wäre zumindest eine Art mini Betriebssystem/Bootloader interessant, das einfache Standard Hardwarefunktionen wie einen UART Sende und Empfangsbuffer und eine System Zeit variable zur Verfügung stellt und für die entsprechend unterschiedlichen Controller die Hardwareinitialisierung vornimmt. Beide Seiten haben ihre Vor und Nachteile, die AVRs sind einfach gehalten, dadurch leicht zu erlernen und man kommt sehr schnell zu den ersten Erfolgserlebnissen. Die ARMs haben einen Einheitlichen Adressraum und viel Rechenleistung. Je nach Modell entsprechen viel Peripherie, in die man sich aber bei jedem Hersteller erneut einarbeiten muss... Eines haben aber beide Gemeinsam, AVR vs ARM gehört nicht zum Thema dieses Threads, es geht um die neuen Tiny's bzw auch neue Mega's. Das Video war sehr interessant, die USI Schnittstelle war ja meistens auch der große Kritikpunkt an den Tinys, obwohl sie eine mächtige Schnittstelle ist. Der Hardware Q-Touch Controller war auch nur eine Frage der Zeit, bis er zu den Tiny und Megas kommt, des gerade die sind für I/O Aufgaben bestens geeignet. Multiplizierer ist auch schön.... und hab ich das richtig verstanden, die Tinys und Megas bekommen ein Eventsystem? oder war das nur ein Beispiel von dem Typen?
UserBla13333443 schrieb: > Für die 32biter wäre es eigentlich echt schön, wenn es so günstige DIP > Adapter gäbe. Es gibt 32-bit uC in DIP: LPC810 in DIP-8 und LPC1114 in DIP-28 Dann gibt es noch SO-16 und SO-20
UserBla13333443 schrieb: > Also ich benutze Code::Blocks für AVR. Muß ich mal gucken. Danke für den Tipp. Robin E. schrieb: > Eines haben aber beide Gemeinsam, AVR vs ARM gehört nicht zum Thema > dieses Threads Och man muß doch nicht immer so in Schubladen denken. Alles hängt mit allem zusammen und heute ist Sonntag, da gehts nicht so genau ;-)
Wo ist denn dieser Flamewar? Ging doch erstmal um klare Werbebeiträge von Gastnutzern und dann um und anschließend einerseits um 8Bit vs. 32Bit und dann noch um Softwarekomplexitätsfragen in Desktop-Apps, also bei Dingen, von denen der OP offen zugegeben hat, dass er keine Ahnung hat. Hersteller-Wars sind doch total öde... Ich könnte mir vorstellen, dass ich demnächst mal zum Spaß als Pseudofragen verpackte Werbebotschaften loswerde. Wer mich sponsorn will, der melde sich bitte bei mir! Sichere Werbefläche, wird nix moderiert hier!
Ich glaube 32 Bit Mikrocontroller werden in naher Zukunft verdrängt werden, durch 64 Bit ARM Systemen wo direkt Linux drauf läuft mit Echtzeit Modulen. 32 Bit ohne Linux ist so was wie 16 Bit. Eine Zwischenlösung die sich nicht wirklich lohnt.
VomGlaubenAbgefallener schrieb: > dann noch um Softwarekomplexitätsfragen in Desktop-Apps, also > bei Dingen, von denen der OP offen zugegeben hat, dass er keine Ahnung > hat. Ha ha, da lenken also höhere Mächte das ruckelnde Geschehen? Da mach aber eher ich mir ernsthaft Gedanken ob Du weißt, wie ein PC funktioniert ;-)
Zelda44 schrieb: > Ich glaube 32 Bit Mikrocontroller werden in naher Zukunft verdrängt > werden, durch 64 Bit ARM Systemen wo direkt Linux drauf läuft mit > Echtzeit Modulen. > > 32 Bit ohne Linux ist so was wie 16 Bit. Eine Zwischenlösung die sich > nicht wirklich lohnt. Absolut. Und die Schere zwischen 8-Bit LowEnd für einfache Ansprüche und xx-Bit für Performancebedürftiges /die Lücke dazwischen wird immer größer.
Interessant. Wie eine technische Größe, wie die Bitbreite, beim Homo sapiens zu ideologischen Trennlinien führt :D Erinnert mich an die Physik der Atome. Alle Atome bestehen im Kern aus Protonen und Neutronen, aber die unterschiedliche Anzahl erzeugt völlig sich unterschiedlich verhaltende Elemente.
Alexa98 schrieb: > ideologischen Trennlinien Über Ideologien könnte man ja noch streiten- über jene Fakten, die 8-bittige / AVR MCUs so erfolgreich machen aber nicht ;-)
Alexa98 schrieb: > Alle Atome bestehen im Kern aus > Protonen und Neutronen, aber die unterschiedliche Anzahl erzeugt völlig > sich unterschiedlich verhaltende Elemente. Aber fast alle wollen 8 Außenelektronen haben.
Moby schrieb: > Fakten, die 8-bittige / AVR MCUs so erfolgreich machen Die Verkaufszahlen sagen anderes. Nr. 1 ist immer noch 8051 und Nr. 2 ist Cortex M0, AVR <1% nur noch unter sonstiges. http://www.emittsolutions.com/section/market-analysis/market_analysis_microcontroller.html
Kai S. schrieb: > Alexa98 schrieb: >> Alle Atome bestehen im Kern aus >> Protonen und Neutronen, aber die unterschiedliche Anzahl erzeugt völlig >> sich unterschiedlich verhaltende Elemente. > > Aber fast alle wollen 8 Außenelektronen haben. Und ganz besonders die, die im Kern 8 Protonen haben :-))
Lothar schrieb: > http://www.emittsolutions.com/section/market-analysis/market_analysis_microcontroller.html Sorry, hab gerade keine 2200 Dollar zur Hand ;-) Der Markt für die 8-Bitter und ihre typischen Applikationen bleibt aber unverändert stark und dort spielt Atmel weiter vorne mit. http://articles.sae.org/13295/
8-bit Controller wären technisch eigentlich schon lange obsolet. Die Peripherie (>100 kGates) von Atmel uCs ist um ein vielfaches größer als der Kern (5-10 kGates). Letztendlich ist ein Cortex M0 ( ca 12 kGates) mit vergleichbarer Peripherie nicht größer, stromhungriger oder teurer, aber dafür deutlich leistungsfähiger.
Was ist denn an Atmel so toll? Die Zahlen waren nicht sehr gut, andere Firmen in dem Sektor laufen besser. Ein 130 nm CMOS Prozess ist auch keine Rocket-Sciene. Damit können sie die Controller noch mit 5V Betreiben. Die Störsicherheit und 5V Kompatibilität wird damit zum Hauptvorteil der AVRs erhoben. Die ganzen Cortexe werden in 65 nm und 90 nm gefertigt. Damit verbrauchen sie weniger Strom und sind von der Fläche her kleiner, so dass die Kosten trotz der höheren Komplexität geringer ausfallen. Theoretische Vergleiche, wie "Moby" sie anstellt, sind damit völlig hinfällig.
TB schrieb: > 8-bit Controller wären technisch eigentlich schon lange obsolet. Die > Peripherie (>100 kGates) von Atmel uCs ist um ein vielfaches größer als > der Kern (5-10 kGates). Letztendlich ist ein Cortex M0 ( ca 12 kGates) > mit vergleichbarer Peripherie nicht größer, stromhungriger oder teurer, > aber dafür deutlich leistungsfähiger. Einen "deutlich leistungsfähigeren" tauscht man nicht unbedingt gegen einen komplexeren Kern- insbesondere wenn diese Leistung gar nicht gefragt ist. AVR punktet mit Einfachheit, auch wenn dieser zentrale Vorteil hier in manche Köpfe partout nicht hineinwill. Dazu die weiter sehr günstigen, einfach beherrschbaren Programmiertools, ein großer Softwarepool. Größer, stromhungriger und teurer wird 32-Bit im Querschnitt immer sein, auch wenn dieser Nachteil schrumpfend bzw. auch aufgrund der Herstellungsweise inzwischen nicht mehr so bedeutend sein mag. Dr. N. Rokpop schrieb: > Ein 130 nm CMOS Prozess ist auch keine Rocket-Sciene. Damit können sie > die Controller noch mit 5V Betreiben. Die Störsicherheit und 5V > Kompatibilität wird damit zum Hauptvorteil der AVRs erhoben. Hauptvorteil: siehe oben! Störsicherheit und 5V sind natürlich weiterhin nette Gimmicks. Dazu bleibt natürlich noch die Vielfalt an bastlerfreundlichen Gehäusen zu erwähnen.
Moby schrieb: > Einen "deutlich leistungsfähigeren" Ups, Einen "weniger leistungsfähigeren" muß es natürlich heißen...
Moby, wenn ein 32 bit Controller für dich zu komplex ist, ist das ja noch deine persönliche Meinung, aber die restlichen Aussagen sind einfach falsch.
Meine Religion ist die beste, wieso versteht ihr das alle nicht?
hier haben jetzt auch lange zeit AVRs eingesetzt.. vorher PIC dann lnge Zeit AVR .. und neuerdings auch Cortex M0 alles in allem nur aus einem Grund: der preis aktuell ist es so das ein 32K STMF030 nur halb so teuer ist wie ein AVR mega88 bei mehr flash wird das noch lustiger .. ja es ist was neues und auch mehr entwicklungsaufwand .. aber das sind oft einmalige mehrausgaben die man über einen gewissen zeitraum mit stückzahlen wieder gut macht
Sind AVRs weniger Komplex als Cortex-M0? Meines Erachtens nur dann wenn man sich an die ganzen Workarounds und Besonderheiten des AVRs schon gewöhnt hat! Bespiele: - Kein Gemeinsamer Addressraum im AVR: Ziemliches Gewürge bei Daten die im Flash und nur dort gespeichert werden sollen vs einem einfachen const/constexpr - Fuses vs Konfiguration im Startup Code (der dadurch natürlich umfangreicher wird). Wer mal einen AVR verfust hat, weiß schon warum sich das Fuse Konzept nicht durchgesetzt hat. - Debugging: Entweder ist ein ganzer Port für JTAG weg, oder man hat das Gewese mit debugWire - Fuse Dw an, Debuggen und dann nach genau vorherbestimmten Verfahren dW Fuse wieder aus. Dagegen ist swd ein Kinderspiel. Ausserdem gibts noch Semihosting als großen Bonus obendrauf. - größer 8 Bit ADCs, Timer usw sind kein Problem auf 32 Bit -> kein sonst wo verteiltes MSB. Auch die Konfiguration sind i.D.R sinnvoller zusammengefasst (ist ja genug Platz im Addressraum vorhanden) - die Timer Auswahl ist bei den Cortex M0 sowohl größer als auch Flexibler als die sonst anzutreffende Auswahl aus 2*8Bit + 16 Bit: Man muss Timer seltener Doppelt nutzen, was eine nicht zu vernachlässigende Quelle für Codekomplexität ist. usw
TB schrieb: > wenn ein 32 bit Controller für dich zu komplex ist Nicht "für mich zu" komplex aber eben komplexer als konkret vielleicht nötig! Ist das nun klar genug? TB schrieb: > aber die restlichen Aussagen sind > einfach falsch Was natürlich einfach nur falsch ist... A. K. schrieb: > Meine Religion ist die beste Nur wer nichts weiß muß alles glauben... Die einfachen AVRs kenne ich- das Konfigurations-Gewürge bei ARM auch. 23567987654 schrieb: > ja es ist was neues und auch mehr entwicklungsaufwand .. Mehr Entwicklungsaufwand, also wohl doch etwas komplexer... > aber das sind oft einmalige mehrausgaben die man über einen gewissen > zeitraum mit stückzahlen wieder gut macht > alles in allem nur aus einem Grund: der preis Im Grundsatz sind bei 8-Bit Projekten aber weiter 8-bittige Controller günstiger. Die Experten mögen sich dazu mal das Beispiel zu Gemüte führen welches im Video gebracht wird! Scelumbro schrieb: > wenn man sich an die ganzen Workarounds und > Besonderheiten des AVRs Welche Workarounds bitte? Und was AVR-"Besonderheiten" anbetrifft dürften die von den komplexen ARM-Besonderheiten locker in den Schatten gestellt werden ;-) Scelumbro schrieb: > im AVR: Ziemliches Gewürge bei Daten Wenn man diesen mit >=32Bit Daten (undoder OOP) traktiert vielleicht. Aber sind das klassische 8-Bit Projekte, auf die ich mich hier die ganze Zeit beziehe? Scelumbro schrieb: > Fuses vs Konfiguration im Startup Code Fuses ersetzen Startup-Code. Das ist prinzipiell eine gute Sache. Verfusen? Muß man das? Scelumbro schrieb: > Debugging: Entweder ist ein ganzer Port für JTAG weg, oder man hat das > Gewese mit debugWire - Fuse Dw an, Debuggen und dann nach genau > vorherbestimmten Verfahren dW Fuse wieder aus. Papperlapapp. Die neuen Xmegas nutzten 2 Pin PDI Debugging, das funktioniert ganz hervorragend. debugWire, JTAG geht bei bei den anderen AVRs natürlich genauso, auch wenn letzteres zugegebenerweise 4 Pins braucht (daß dann der restliche Port blockiert wäre ist Quatsch). Scelumbro schrieb: > größer 8 Bit ADCs, Timer usw sind kein Problem auf 32 Bit -> kein > sonst wo verteiltes MSB. Xmega hat 12-bittig bis 16 ADCs, habe mit den Timern nie ein Problem gehabt und das MSB, mein Gott, wird halt in einer zweiten Instruktion eingelesen so überhaupt benötigt. Scelumbro schrieb: > Auch die Konfiguration sind i.D.R sinnvoller > zusammengefasst (ist ja genug Platz im Addressraum vorhanden) Der Xmega ist diesbezüglich auch etwas geordneter- was nicht heißt das bei den anderen das Chaos ausgebrochen wäre. Soviel Ressourcen gibts ja nicht... Scelumbro schrieb: > die Timer Auswahl ist bei den Cortex M0 sowohl größer als auch > Flexibler als die sonst anzutreffende Auswahl aus 2*8Bit + 16 Bit: Ja, sie mag flexibler sein- aber Flexibilität ist auch der Motor jeglicher Komplexität. Und ich bin froh daß AVRs diese Flexibilität nicht haben. Bei den 8-Bit Projekten kommt man gut mit dem Vorhandenen aus (bei den XMegas nochmals erweitert). Also alles in allem- wer die AVRs mit großen Datenmengen und hohen Performanceansprüchen traktiert wird scheitern und soll gefälligst den Controller nehmen der passt. Aber da gibt es ja noch Millionen einfacher bis mittlerer Projekte auf die das nicht zutrifft- und da braucht man eben nicht mit den berühmten Kanonen auf Spatzen zu schießen. Eventuell machen das aber inzwischen die Chinesen- und die hochgeschätzten deutschen Herrschaften nur noch Höherwertigeres ;-) Gut, ehe ich hier die letzten 32-bittigen Hasen überzeuge, die für ARM jahrelang studiert haben und nun vor teurem Industrie-Equipment sitzen... Schaun mer mal was Atmel auf der Electronica bietet und lassen sichtbare Fakten sprechen ;-)
Moby schrieb: > Scelumbro schrieb: >> im AVR: Ziemliches Gewürge bei Daten > > Wenn man diesen mit >=32Bit Daten (undoder OOP) traktiert vielleicht. > Aber sind das klassische 8-Bit Projekte, auf die ich mich hier die ganze > Zeit beziehe? Scelumbro schrieb wirklich: > Kein Gemeinsamer Addressraum im AVR: Ziemliches Gewürge bei Daten die > im Flash und nur dort gespeichert werden sollen vs einem einfachen > const/constexpr Hast du diesen Absatz nicht verstanden oder verkürzt du ihn absichtlich sinnentstellend? Gerade bei kleinen uC mit wenig RAM sind doch LUT im Flash für irgendwelche Berechnungen, Zeichensätze, Konfigurationsdaten und so weiter wichtig. Hier ist der getrennte Addressraum ein klarer Nachteil. Zum Thema OOP: Wer weiß wie, kann sauberers C++ ohne signifikanten Overhead auch auf kleinen uC anbringen. Hier sind jede Menge Vorurteile im Spiel. Insbesondere Templates können Code sehr kompakt und dennoch sauber OOP machen.
Moby schrieb: > Mehr Entwicklungsaufwand, also wohl doch etwas komplexer... in dem sinne AVR <-> ARM cortex M .. JA ABER .. es sind auch weitaus mehr features vorhanden da lob ich mir die 2-3 register mehraufwand in dem sinne sind die "8bitter projekte" wohl sowas wie temeraturmessung , led blinker ??? ehy sorry das ist klar das es , wenn man denn die erfahrung hat .... , mit einem AVR wohl schneller zu realisieren geht. so gesehen wenn man brauchbar programmiert kann man 95% des alten source auf einem cortex M wiederverwerten. die 5% anpassungen an den neuen chip lass ich mal so stehen... im umkehrschluss bietet mir der cortex mehr features/möglichkeiten mehr flash als ein gleichteurer AVR nicht umsonst bietet atmel auch einen cortex M0(+) an .. der ist sogar bei doppelt so viel flash etwas günstiger als ein 8bit AVR .. kurioserweise ... der AVR an sich ist ja nicht schlecht ... aber ein xmega ist ebenso beknackt zu konfigurieren wie ein cortex M wenn man sich das gefuddel mit den STM/NXP/... Libs mal abgewöhnt hat und direkt registerzugriffe beibringt ( macht man beim AVR ja auch so .. ) dann hat der Cortex plötzlich gar nicht mehr so viel zeug zum konfigurieren das einzige was wirklich nachteilig ist ist die umgewöhnung durch die features/Registeranzahl des Cortex M der AVR ist da etwas einfacher gestrickt .. JA .. kann aber auch weniger ( ISR prio/ usw ... ) das darf man nicht vergessen.. wenn man sich aber einmal an den cortex gewöhnt hat .. ist man damit genau so schnell .. und hat den vorteil das man den µC sogar etwas günstiger bekommt :-) bei stückzahlen von >100000 sind das auch mal eben ein paar tausend
husten schrieb im Beitrag > und hat den vorteil das man den µC sogar etwas günstiger bekommt :-) bei > stückzahlen von >100000 sind das auch mal eben ein paar tausend Ist das wirklich so? Bei grossen Stückzahlen zählt einzig und allein der Preis. Denn es ist praktisch egal, was die Softwareentwicklung kostet. Diese Kosten gehen bei grossen Stückzahlen komplett unter. Hier bei mikrocontroller.net heisst es oft, die AVRs wären teurer als die 32-bitter. Für Bastler vielleicht, aber ganz bestimmt nicht für die Industrie. Die Atmels werden hergestellt (und auch noch weiter entwickelt), weil es Firmen gibt, welche sie in Millionenstückzahl kaufen. Sooo schlecht können sie also nicht sein. Mir scheint, einigen von euch klugscheissenden Hobbyfricklern ist nicht klar wie Marktwirtschaft funktioniert. MfG Ulli
Scelumbro schrieb: > Gerade bei kleinen uC mit wenig RAM sind doch LUT im Flash für > irgendwelche Berechnungen, Zeichensätze, Konfigurationsdaten und so > weiter wichtig. Hier ist der getrennte Addressraum ein klarer Nachteil. Na vielleicht in ressourcefressender Hochsprache. In Asm lädst Du einfach Z mit dem Pointer und liest dann mit LPM den Flashbereich lustig aus. Easy. Vielmehr ist hier die Hochsprachen-Programmierung inkl. intransparenter Libs der "klare Nachteil" ;-) husten schrieb: > in dem sinne sind die "8bitter projekte" wohl sowas wie temeraturmessung > , led blinker ??? Nicht nur das... Da geht mehr als der studierte 32-Bit C++ Experte heute glauben mag weil er es wohl nicht mehr kennt bzw. für möglich hält. Nach einigen 10K Asm Code Erfahrung und im praktischen Einsatz flutscht das Programmieren nur so... Da erkennt man plötzlich, was sich mit ein bischen System und Überlegung alles in Asm auf die Beine stellen läßt- immer noch und gerade deshalb fern jeder AVR-Leistungsgrenze ;-) husten schrieb: > wenn man sich aber einmal an den cortex gewöhnt hat .. > ist man damit genau so schnell .. Ja ja- wenn entsprechend Zeit in die Lernkurve geflossen ist, man dann mit OOP oder dicken C-Libs hantiert deren Interfaces langwierig studiert wurden, dann gehts genauso schnell- nur das es dann ohne 32-Bit Brummer wirklich nicht mehr geht ;-)
@Moby Magst du ein ARM Cortex nicht mal mit Assembler ausprobieren? Es gibt viele Bücher zum ARM Assembler.
Mann mann mobby... all die Zeit, in der Du Dich sinnvoll beschäftigen könntest.
Uli schrieb: > Ist das wirklich so? > Bei grossen Stückzahlen zählt einzig und allein der Preis. Denn es ist > praktisch egal, was die Softwareentwicklung kostet. Diese Kosten gehen > bei grossen Stückzahlen komplett unter. ..ja Ich kenne nur grobe Zahlen... Stk wirbt ja auch damit : 32k Flash für 32ct.. bei > 100000 stk klappt das auch. atmel hat eine kuriose Preispolitik... Der mega88pa war damit um 1,75x teurer als ein stm32f0 mit 32k Flash Ich selbst war das extrem überrascht..
http://www.digikey.de/product-search/de?x=20&y=23&lang=de&site=de&KeyWords=stm32f030c6t6 http://www.digikey.de/product-detail/de/ATMEGA88PA-AU/ATMEGA88PA-AU-ND/1886228
husten schrieb: > in dem sinne sind die "8bitter projekte" wohl sowas wie temeraturmessung > , led blinker ??? ehy sorry das ist klar das es , wenn man denn die > erfahrung hat .... , mit einem AVR wohl schneller zu realisieren geht. Mal ne Kostprobe von hobby Moby: Beitrag "Analoger Sensor (LM335) mit Operationsverstärker + AVR Asm-Code"
Pausenclown schrieb: > Mal ne Kostprobe von hobby Moby: > Beitrag "Analoger Sensor (LM335) mit Operationsverstärker + AVR > Asm-Code" gibt viel verrückteres zeug mit AVRs.. brauch ich nur bei uns in der firma gucken ... darum gehts doch aber nicht .. JA klar gehen auch komplexe sachen mit AVR 8bittern ... damit das zeug aber konkurenzfähig bleibt .. geht das nur über den preis ... und da muss Atmel nunmal nachbessern ... es kann nicht sein das ein 32bitter mit mehr features und mehr flash deutlich weniger kostet als ein mega88pa ... JA klar werden die 8biiter noch verkauft... abr auch nur bei denen wo die produkte fertig durchentwickelt sind... neuentwicklungen weren dagegen oft mit cortex m oder ähnlichem gemacht
Pausenclown schrieb: > Mal ne Kostprobe von hobby Moby: > Beitrag "Analoger Sensor (LM335) mit Operationsverstärker + AVR > Asm-Code" Funktioniert blendend. Nix vorzuweisen, hat wohl wirklich nur zum Pausenclown gereicht ;-)
23567987654 schrieb: > Pausenclown schrieb: >> Mal ne Kostprobe von hobby Moby: >> Beitrag "Analoger Sensor (LM335) mit Operationsverstärker + AVR >> Asm-Code" > > gibt viel verrückteres zeug mit AVRs.. Was ist daran verrückt? Eine hinreichende, möglichst simple Problemlösung mit vorhandenem Material- ganz Moby eben. Imponierende Hochglanzparameter sind überflüssig - so wie ein ARM in 8-Bit Projekten ;-) > und da muss Atmel nunmal nachbessern ... > > es kann nicht sein das ein 32bitter mit mehr features und mehr flash > deutlich weniger kostet als ein mega88pa ... Atmel wird schon wissen warum und wie sie sich ihre Brötchen am besten verdienen. Mein Bastler-Kommentar dazu lautet immer: Einfachheit ist populär. Populäres kostet mehr.
Pausenclown schrieb: > Mal ne Kostprobe von hobby Moby Wenn das derselbe Moby ist, wieso postet er dann dort angemeldet und hier als Gast? Ausserdem hat sich die Diskussion mittlerweile doch erschöpft und Fakten werden ohnehin von beiden Seiten ignoriert :-)
Moby schrieb: > Imponierende Hochglanzparameter sind überflüssig - so wie ein ARM > in 8-Bit Projekten ;-) Was ist an einem ARM-MCU denn Hochglanz? Das sind ganz stinknormale Standarddinger. Wenn du richtig trve 8 Bit wärst, würdest du sowieso nicht so einen neumodischen Firlefanz wie AVR verwenden, sondern zumindest den bewährten 8051 - natürlich nur die originalen von Intel. Die Hardcore-Oldschooler verwenden dann ein 6502-Derivat, z.B. den W65C134S von WDC.
Hier fehlt ein Schloss vor dem thread. Immer wieder lustig, wie unbehelligt ein mittelmäßiger Vertriebler seine billige marketingsprech-Logik hier mit dankbaren Technikerseelen trainieren kann...
Moby schrieb: > Eine hinreichende, möglichst simple > Problemlösung mit vorhandenem Material- ganz Moby eben. Und Fieber wird mit dem Finger im ... gemessen. ;-)))
Lothar schrieb: > Wenn das derselbe Moby ist, wieso postet er dann dort angemeldet und > hier als Gast? > > Ausserdem hat sich die Diskussion mittlerweile doch erschöpft und Fakten > werden ohnehin von beiden Seiten ignoriert :-) Von Dir aber auch. Und mach Dir keine Sorgen, der Moby ist derselbe ;-) fred schrieb: > Immer wieder lustig, wie > unbehelligt ein mittelmäßiger Vertriebler seine billige > marketingsprech-Logik hier mit dankbaren Technikerseelen trainieren > kann... Echt erheiternd! Danke für den Joke! Mal einer der nicht so bierernst daherkommt. Schließen würd ich den Thread aber noch nicht, wollte hier morgen noch ein paar frische Fakten aus München posten ;-)
greg schrieb: > Die Hardcore-Oldschooler verwenden dann ein 6502-Derivat ARM ist ein 6502-Derivat :-) greg schrieb: > den bewährten 8051 The 8051 MCU: ARM’s nemesis on the Internet of Things? http://www.embedded.com/electronics-blogs/cole-bin/4426602/The-8051-MCU--ARM-s-nemesis-on-the-Internet-of-Things-
Auch wenn einige die Meinung vertreten das die 32bitter wieder verschwinden... Wenn ... Dann nicht sofort... Der Zug ist abgefahren.... Außerdem was bringt das für die Hersteller... - mehr mcu je wafer - mehr Geld je wafer
Fürs Protokoll: Moby hat hier des öfteren - auch von Moderatoren - Schelte bezogen weil er einen ARM Thread nach dem anderen gekapert hat. Zu Recht, mir geht das Geseiere auch auf den Senkel. Ihm wurde mehrfach geraten dafür einen eigenen Thread zu eröffnen. Jetzt TE hat die Absicht von Atmel, neue AVRs herauszubringen, in einem eigenen Thread verkündet. Und was machen die ARM Fanboys? Der STM32-liebende Mod jedenfalls macht sich rar. Zum Thema: Dieses USI Dingens war bislang der Grund weshalb ich keine ATtiny verwende. Ich bin bei dem Versuch den als SPI Slave zu betreiben kläglich gescheitert. Nun wäre nur noch interessant zu wissen ab wann Atmel gedenkt diese neuen Typen auszuliefern. Zum Vergleich: Wenn ich mich recht entsinne lagen zwischen der Ankündigung der m48/m88/m168 und der Auslieferung fast zwei Jahre.
Stefan schrieb: > Jetzt TE hat die Absicht von Atmel, neue AVRs herauszubringen, in einem > eigenen Thread verkündet. Und was machen die ARM Fanboys? Er hat eröffnet mit :-) Moby schrieb: > 8-Bit bleibt für den Bastler das Mittel der Wahl in allen Projekten, die > keine 32 Bit Power benötigen
Der Satz ist sicherlich etwas plakativ aber ich finde ihn nicht abwegig. Und für Mobys Verhältnisse ist er geradezu versöhnlich ;). Aber man kann doch nicht auf ihn einschlagen und dann selbst genau das tun was man ihm vorwirft. PS: Hatte ich schon erwähnt daß die STM32F411 richtig toll sind? QFN48 mit 100MHz, 3x Uarts, 5x SPI (I2S), 3x I2C und 12Bit ADC. Natürlich ab Lager verfügbar. PPS: Ganz vergessen: ;)
Stefan schrieb: > Dieses USI Dingens war bislang der Grund weshalb ich keine ATtiny > verwende. Ich bin bei dem Versuch den als SPI Slave zu betreiben > kläglich gescheitert. Probiers mal mit der Library hier: http://www.jtronics.de/avr-projekte/library-i2c-twi-slave-usi.html damit gehts zuverlässig. Edit: vergiss es, hab aus irgend nem Grund I2C gelesen und nicht SPI, war wohl ein Freud'scher Verleser.
:
Bearbeitet durch User
Stefan schrieb: > Aber man kann doch nicht auf ihn einschlagen No Problem. Ich schlag zurück. Da machen es einem die wunderbaren Eigenschaften des AVR wirklich einfach. Stefan schrieb: > STM32F411 richtig toll sind? QFN48 > mit 100MHz, 3x Uarts, 5x SPI (I2S), 3x I2C und 12Bit ADC QFN48? Wer soll das löten? 100MHz? Wer braucht diese Power? Hat den Strom? 3 Uarts? Zu wenig. Xmega bietet bis zu 8. 3x I2C? Da langt doch 1x 12 Bit ADC? Für Xmega nix besonderes. Stefan schrieb: > Nun wäre nur noch interessant zu wissen ab wann Atmel gedenkt diese > neuen Typen auszuliefern. Das ist DIE zentrale Frage bei Atmel. Ich werd die Typen heute löchern ;-)
Stefan schrieb: > Ich bin bei dem Versuch den als SPI Slave zu betreiben > kläglich gescheitert. Ja, das SPI der AVR ist ganz großer Mist. Es hat keinen Sendepuffer. Als Slave ist es daher unmöglich, Bytes lückenlos zu senden, ohne das der Master lange Gedenkpausen einlegen muß. Und das I2C der ATmega hat einen schweren Bug, kann daher nicht als Multimaster eingesetzt werden. Aber auch bei Störungen auf dem Bus hängt es sich leicht auf. Ich habe aber keine Hoffnung, daß diese erheblichen Mängel in den neuen AVRs gefixt werden.
Moby schrieb: > Die Funktionalität allein würde einen Bruchteil der heute verbrauchten > Ressourcen erfordern! Nein, es sind die Programmiermethoden und die > aufgeblasenen Systemarchitekturen, die eine About-Info Box bis zu 10 > Sekunden verzögern (und noch sehr viel mehr). Nun kennt man ja die > Windows Geschichte und die Alternativlosigkeit bei der "modernen" > Desktop-Entwicklung, nachder die ganze Software-Landschaft auf > schonungslosen Hardwareverbrauch ausgerichtet ist. Aber man muß mit > dieser Vergeudungsmentalität ja nicht auch noch auf die MCUs einprügeln. Witzig, hier (im Auftrag von Atmel?) dick Werbung für Atmel 8-Bit CPUs machen und fette Architekturen verdammen, dabei aber vergessen, dass uns Atmel mit Studio 5ff ein richtig fettes faules Ei gelegt hat. Wenn die Firma des heiligen 8-Bit Grals selber nicht dran glaubt und meint, man braucht mehrere Gigabyte an verkommener Microsoft-IDE um ein paar Kilobyte an Speicher in AVRs zu programmieren, dann kann man dieses Gelaber über Vergeudungsmentalität nicht ganz ernst nehmen. Komm wieder wenn Atmel es geschafft hat diesen Dreck von Studio zu entsorgen.
Mark 99 schrieb: > dabei aber vergessen, dass uns > Atmel mit Studio 5ff ein richtig fettes faules Ei gelegt hat. Full ACK! Diese Speichervergeudung! Ich komm mit dem Nachstopfen von RAM-Riegeln schon gar nicht mehr hinterher
Peter Dannegger schrieb: > Und das I2C der ATmega hat einen schweren Bug, kann daher nicht als > Multimaster eingesetzt werden. Aber auch bei Störungen auf dem Bus hängt > es sich leicht auf. Also sorry, ich hab den I2C Bus sowohl beim Mega als auch Xmega schon in jahrelangem Dauereinsatz und da hängt sich nix auf!!! Große Klagen diesbezüglich hab ich auch hier noch nicht vernommen. > Ich habe aber keine Hoffnung, daß diese erheblichen Mängel in den neuen > AVRs gefixt werden. Du hast doch meines Wissens nach die Xmegas noch gar nicht probiert !? Mark 99 schrieb: > Atmel mit Studio 5ff ein richtig fettes faules Ei gelegt hat. Das Ei ist nicht faul, sondern funktioniert zunächst mal wie es soll. Tatsächlich ist leider fett- aber einem geschenkten Gaul ...
Moby schrieb: > QFN48? Wer soll das löten? Ein lötofen.... Der kann das 24/7 in millionen Stückzahlen.. Hobby lasse ich bewusst weg bei diesem Thema. Der größere Teil nutzt fertige boards. Und die paar die wirklich noch pcbs machen und selbst löten können gerne die AVR in DIP nutzen. Die 5000stk im Jahr fallen auch noch irgendwo vom Band... Der Rest nutzt eben mlf,qfn,tqfp....
Moby schrieb: > Also sorry, ich hab den I2C Bus sowohl beim Mega als auch Xmega schon in > jahrelangem Dauereinsatz und da hängt sich nix auf!!! Was nicht beweist, daß er nicht störempfindlich ist. Versuch mal I2C außerhalb der Platine und mit Hotplug von Slaves. Moby schrieb: > Du hast doch meines Wissens nach die Xmegas noch gar nicht probiert !? Um die geht es hier ja auch nicht, sondern um ATtiny und ATmega.
Peter Dannegger schrieb: > Was nicht beweist, daß er nicht störempfindlich ist. Jedenfalls hinreichend störfest um bei üblichen Bastler-Designkünsten nicht auszufallen ;-) > Versuch mal I2C außerhalb der Platine und mit Hotplug von Slaves. Hotplug von Slaves? Mir war nicht bekannt das sowas am I2C überhaupt zulässig ist. Für was braucht man das? I2C ist ein In-curcuit bus ... mghc schrieb: > Moby schrieb: > QFN48? Wer soll das löten? > > Ein lötofen.... Der kann das 24/7 in millionen Stückzahlen.. Wobei wir wieder beim teuren Equipment der Industrie wären... Fürs Hobby uninteressant. TQFP wie bei den Xmegas ist ja noch lötbar. Ich empfehle den kleinen E5!
Moby schrieb: > QFN48? Wer soll das löten? > 100MHz? Wer braucht diese Power? Hat den Strom? > 3 Uarts? Zu wenig. Xmega bietet bis zu 8. > 3x I2C? Da langt doch 1x > 12 Bit ADC? Für Xmega nix besonderes. Du legst dir deine Argumente auch schön zu recht. 100 MHz Takt ist zuviel, aber 8 UARTs braucht die Welt (Wozu eigentlich?).
Peter Dannegger schrieb: > Und das I2C der ATmega hat einen schweren Bug, kann daher nicht als > Multimaster eingesetzt werden. Aber auch bei Störungen auf dem Bus hängt > es sich leicht auf. Hmmm....der I2C vom STM32F1xx ist auch nicht die Wucht. Da muß man auch ein paar MCU-Zyklen spendieren, um sich um die Fehler herumzunavigieren. Bugs gibt es überall... Allerdings gibt es bei den AVRs etwas, was ich bei den STM32 wirklich vermisse: EEPROM. Der geht schön einfach und lebt viele Zyklen. Bei den STM32 ist die EEPROM-Emulation etwas aufwendiger, so daß ich meinen Projekten lieber ein I2C-EEPROM spendiere.
Also mich hätten ja jetzt auch Infos zu neuen Tinys und Megas interessiert wie es der Threadtitel suggeriert. Vielleicht könnte Moby ja noch einen Thread aufmachen, und die ARM Fraktion hält sich einfach mal zurück?
Scelumbro schrieb: > Du legst dir deine Argumente auch schön zu recht. 100 MHz Takt ist > zuviel, aber 8 UARTs braucht die Welt (Wozu eigentlich?). Nix schön zurechtgelegt. 100 Mhz sind für die typischen 8-Bit Projekte schlicht überflüssig im Quadrat. UARTS sind eine dermaßen von Universalschnittstelle, davon kann man nicht genug haben! Aufwendigere I/O wie Netzwerkanbindung, Massenspeicher oder Display lagert der geneigte Bastler auf Fertigmodule aus ;-)
cyblord ---- schrieb: > noch einen Thread aufmachen Also eigentlich sollte der Eröffnungspost nur eine Info sein. Eine frühe Vorabinfo dank CC2. Ich fürchte sehr viel mehr wird so schnell noch nicht zu berichten sein. Wenn ich mir den schleppenden Marktzugang der Xmegas damals vergegenwärtige kann es nur noch Jahre dauern ;-) Aber schaun mer mal.
Moby schrieb: > Wenn ich mir den schleppenden Marktzugang der Xmegas damals > vergegenwärtige kann es nur noch Jahre dauern ;-) Die Xmega haben zu viele Nachteile (kein CAN, nicht 5V tolerant usw.), die werden die standard AVRs nie einholen können. Da nehm ich doch lieber gleich nen Cortex. Die Nuvoton M0 sollen lt. Datenblatt sogar direkt an 5V laufen können.
Walter Tarpan schrieb: > Allerdings gibt es bei den AVRs etwas, was ich bei den STM32 wirklich > vermisse: EEPROM. Der geht schön einfach und lebt viele Zyklen. Bei den > STM32 ist die EEPROM-Emulation etwas aufwendiger, so daß ich meinen > Projekten lieber ein I2C-EEPROM spendiere. Die STM32L haben "richtiges" EEPROM, falls du es wirklich benötigst.
Walter Tarpan schrieb: > Bei den STM32 ist die EEPROM-Emulation etwas aufwendiger Die LPC haben fast alle EEPROM Moby schrieb: > QFN48? Wer soll das löten? Die LPC gibt es auch als DIP oder SO
QFP32 bspw. ist auch nicht so schwer zu löten. 0.8mm Pinabstand ist doch ganz locker. Es gibt eine gute Auswahl an ARM-Chips in diesem Gehäuse und Adapterplatinchen gibt es für Centbeträge.
Auch in meiner prä-ARM Zeit war QFN mein Lieblingsgehäuse. Meine letzte AVR (SMS) Platine war mit einem ATmega48PA-MMH bestückt. Das war vor zwei Jahren schätze ich. Den habe ich nach einem Redesign durch einen LPC1112FHI ersetzt. Die löte ich natürlich alle von Hand. Geht schneller als TQFP.
Peter Dannegger schrieb: > Die Xmega haben zu viele Nachteile (kein CAN, nicht 5V tolerant usw.), > die werden die standard AVRs nie einholen können. Bei mir haben sie das schon. Neue Projekte laufen bis auf wenige Ausnahmen mit XMEGA und 3.3V. Sämtliche Peripherie am Markt (seielle Flashs, serielle RAMs, Netzwerk-Controller, MEMS-Sensoren, USB-Brücken, TFT-Displays...) läuft mit 3.3V, da gibt es dann nur noch eine Vcc auf dem Board. Die Vielseitigkeit der XMEGAs reduzieren die Anzahl der verwendeten und zu lagernden MCUs deutlich. Wo ich beim Mega und Tiny noch 10 verschiedene Chips brauchte, um verschiedenste Aufgaben zu lösen, brauche ich jetzt nur noch 2, den A3U für pinhungrige Sachen und den E5 für Kleinkram. Und das alles läuft zur Not auch mal an 2 NiMH-Akkus...
@Peter: Nun hätt ich aber schon gern noch was zu den Hotplug Fähigkeiten des I2C erfahren... Travelrec kann ich eigentlich nur beipflichten, über kurz oder lang stemmt die Xmega-Reihe das ganze 8 Bit AVR Programm alleine, 5V wird ja immer seltener benötigt. Allerdings wird nun 2015 erstmal an der Mega/Tiny Front nachgezogen. Die vorgesehene hardwaretechnische Aufrüstung beider Reihen startet ab sofort mit dem Mega-PB (168er,88er), später mit neuen Tinys, wobei mir Atmel heute zu letzteren noch keine Einzelheiten verraten wollte, erst auf der winterlichen Embedded soll es soweit sein. Weiteres am späten Abend.
Zumindest das Summary Datenblatt vom ATmega48PB/88PB/168PB ist bei Atmel jetzt Online zu finden: www.atmel.com/Images/Atmel-42176-ATmega48PB-88PB-168PB_Datasheet_Summary .pdf
Viel erfährt man da ja nicht, aber ein weiteres neues Feature ist das die jetzt eine "Unique Device ID" haben, nach der Register-Übersicht ist die 64 Bit breit.
Moby schrieb: > Wobei wir wieder beim teuren Equipment der Industrie wären... Fürs Hobby > uninteressant. ok .. aber wenn ich Hersteller wäre ... was interessiert mich da mehr : a: 5000 µCs im Jahr für bastler ... b: 50000000 µCs für die industrie ...
23567987654 schrieb: > Moby schrieb: >> Wobei wir wieder beim teuren Equipment der Industrie wären... Fürs Hobby >> uninteressant. > > ok .. > aber wenn ich Hersteller wäre ... > was interessiert mich da mehr : > a: 5000 µCs im Jahr für bastler ... > b: 50000000 µCs für die industrie ... Muss ja ein tolles Produkt sein, dass man davon 50 Mio. Stück verkaufen kann :D Finde ich nicht sehr realistisch. 5000 klingt schon besser. Sind ja nicht alles Milliarden schwere Konzerne mit Millionen von Kunden.
OnePiece443 schrieb: > Muss ja ein tolles Produkt sein, dass man davon 50 Mio. Stück verkaufen > kann :D Yup, sowas wie nen ATMega88 zum Beispiel.
OnePiece443 schrieb: > Muss ja ein tolles Produkt sein, dass man davon 50 Mio. Stück verkaufen > kann :D > Finde ich nicht sehr realistisch. 5000 klingt schon besser. > Sind ja nicht alles Milliarden schwere Konzerne mit Millionen von > Kunden. ironie? mal ehrlich .. 5000 µC im jahr herstellen und überleben? bei 1€ je stk haben die umsatz von 5000€ im jahr? millionen von kunden nicht .. aber wenn man weiß wo überall so ein µC drin ist ... wo ich arbeite sind aktuell 200.000 bis 250.000 µC pro jahr im einsatz tendenz steigend ... andere firmen , automotive und Co liegend a deutlich drüber ...
Rudolph schrieb: > Zumindest das Summary Datenblatt vom ATmega48PB/88PB/168PB ist bei Atmel > jetzt Online zu finden: > www.atmel.com/Images/Atmel-42176-ATmega48PB-88PB-168PB_Datasheet_Summary .pdf aber anscheinend kein DIP Gehäuse mehr
Ein Mega648 wäre auch nicht schlecht. ;))
Was mich so gar nicht begeistern will, ist das neue Entwicklungsboard: http://store.atmel.com/PartDetail.aspx?q=p:10500404;c:100113#tc:description Das PCB USB-Stecker grauenhaft sind, sollte sich doch inzwischen herumgesprochen haben?
Schreck schrieb: > aber anscheinend kein DIP Gehäuse mehr Haha, stimmt, wurde auch mal Zeit. :-) Was mir bei den ganzen AVRs noch fehlt ist das mal die Gehäuse schrumpfen, auf TQFP mit 0,5mm Pitch. Die QFN sind einfach blöd für einfache Designs mit zwei Lagen.
Warum nicht TSSOP? Finde das Format für die ganzen CM0 sehr praktisch.
Hat die Hälfte von euch Leuten ein Lötofen Zuhause? Und das funktioniert einfach so? Anders kann ich mir die Begeisterung für Formate anders als DIP nicht wirklich erklären.
ff schrieb: > Warum nicht TSSOP? Yup, wäre auch nett. Auf ein kleineres TQFP könnte man nur leichter drauf umsteigen, etwas schrumpfen, fertig. :-)
OnePiece443 schrieb: > Hat die Hälfte von euch Leuten ein Lötofen Zuhause? Wofür? Die TQFP mit 0,8 mm Pitch sind doch quasi riesig, von den Dingern habe ich schon Hunderte von Hand gelötet. QFN ist da schon blöder, erstmal spart das im Layout gar keinen Platz weil man nicht nach innen routen kann und beim Löten von Hand hat man schlechte Karten das Pad Innen mit anzulöten.
Schreck schrieb: > aber anscheinend kein DIP Gehäuse mehr ARM in DIP und SO von 4KB bis 32KB Flash: LPC810 DIP-8, LPC812 SO-20, LPC1110 SO-20, LPC1114 DIP-28
OnePiece443 schrieb: > Hat die Hälfte von euch Leuten ein Lötofen Zuhause? Und das funktioniert > einfach so? > Anders kann ich mir die Begeisterung für Formate anders als DIP nicht > wirklich erklären. Eine Nummer kleiner als DIP (zum Beispiel SOIC) ist meiner Meinung nach für den Hobbyisten noch einfacher zu verarbeiten als DIP da man keine Löcher bohren muss und das Ding ist schneller gelötet (und notfalls sogar wieder ausgelötet) als DIP. SOIC ist meiner Meinung nach der Sweet-Spot in Puncto Hobbyistenfreundlichkeit, das ist gewissermaßen das DIP der SMD-Technik und wer noch gute Augen (oder geeignete optische Hilfsmittel) und ne halbwegs ruhige Hand hat kann nach etwas Übung auch noch eine Nummer kleiner gehen. Und das alles immer noch am heimischen Küchentisch wenns sein muss.
:
Bearbeitet durch User
(T)QFP mit 0.8mm bekommt man doch selbst mit einem miserablen Baumarkthobel noch gelötet - Flussmittelstift o.ä. vorausgesetzt, aber das ist sowieso Pflicht.
Angehängte Dateien:
-
atmel.jpg
2,4 MB -
AtmelStudio.png
360 KB -
avrtasche.jpg
280 KB -
demo1.jpg
230 KB -
demo2.jpg
180 KB -
demo3.jpg
210 KB -
XplainedMini.jpg
1,2 MB
ff schrieb: > Was mich so gar nicht begeistern will, ist das neue Entwicklungsboard: > > http://store.atmel.com/PartDetail.aspx?q=p:10500404;c:100113#tc:description > > Das PCB USB-Stecker grauenhaft sind, sollte sich doch inzwischen > herumgesprochen haben? Keine Bange, da ist tatsächlich eine Mini-USB Buchse drauf. Das Board enthält einen Debugger, nötig ist nur ein USB-Kabel zum Rechner. Die Pinleisten sollen Arduino-kompatibel sein. Anbei ein Foto der Platine und wie sich das Ganze im (neuen! V6.2.1502SP1) Atmel-Studio darstellt. Das Board wurde heute auf der Electronica gratis verteilt, soll aber mit unter 10 Euro auch nicht teuer werden ;-) Die neue AVR Hardware stand heute noch nicht im Mittelpunkt. Im Ramen einer Demo zum Stromverbrauch (siehe Bilder) wurde nebenbei die neue Mega-PB Reihe vorgeführt und gezeigt: Schlafend (und das ist die Standardtätigkeit zukünftiger IOT Devices) schlägt das 8 Bit- jedes ARM System! Die ersten Infos sind ja nun schneller online gewesen als ich dachte (beim Xmega konnte man ja noch ne ganze Weile nach der Messe warten) und so kann ich eigentlich nicht mehr viel ergänzen. Die auf 130nm geshrinkten B-Chips enthalten neue PTC-Hardware (256-channel capacitive touch and proximity sensing) für Anäherungs/Berührungstasten-Detektion, einen zusätzlichen Extended Standby Modus und eine UART-taugliche, quarzlose Takterzeugung, ziehen aber aktiv minimal mehr Strom. Alles in allem nur eine Auffrischung der Reihe. Deutlich stärker sollen die Tinys nächstes Jahr wachsen, um im Vergleich zu MCUs anderer Hersteller noch weiter an Attraktivität zu gewinnen. Da aber von den Tinys heute noch nichts genaueres auf der Messe zu hören war verweise ich da nochmal auf die CC2-Sendung 146 und folgende. Lohnt sich! Zugegebenermaßen war heute auf den Ständen der großen ARM-Lizenznehmer (z.B. ST und NXP) deutlich mehr Musik als am beschaulichen Atmel-Stand (Bild). Man muß dem Hype aber trotzdem nicht nachgeben- wenn man die reellen Bedürfnisse seiner typischen 8-Bit Applikation weiter fest im Blick behält ;-)
Der Atmel-Stand so genau so aus wie auf der Embedded World. Daher bin ich gar nicht erst dort hin gegangen. Naja, muss ich dann in den nächsten Tagen mal machen.
ff schrieb: > Naja, muss ich dann in den > nächsten Tagen mal machen. Jo. Lohnt sich immer! Seh gerade daß die PA-Typen auch schon einen Extended Standby hatten... Dafür kann man aber nun noch die USART- Start of Frame Detection ergänzen.
Gibt's eigentlich eine Overclocker-Szene mit und rund um Atmel 8-Bitter? Da lässt sich bestimmt noch einiges rausholen! Lustig wären auch transparente Packages mit LED auf dem Die!
> Im Ramen einer Demo zum Stromverbrauch (siehe Bilder) wurde nebenbei die > neue Mega-PB Reihe vorgeführt und gezeigt: Schlafend (und das ist die > Standardtätigkeit zukünftiger IOT Devices) schlägt das 8 Bit- jedes ARM > System! nö ! STM32L053 Cortex M0+ 64KB Flash, 8KB SRAM, 2KB EEPROM, LCD, USB, ADC, DAC • Ultra-low-power platform – 1.65 V to 3.6 V power supply – -40 to 125 °C temperature range – 0.27 µA Standby mode (2 wakeup pins) – 0.4 µA Stop mode (16 wakeup lines) – 0.8 µA Stop mode + RTC + 8 KB RAM retention – 139 µA/MHz Run mode at 32 MHz ATmega48PB/88PB/168PB 16 Kbytes Flash, 1KB SRAM, 512 Bytes EEPROM, ADC - Temp. Range (deg C): -40 to 85 - Power Consumption at 1MHz, 1.8V, 25°C - Active Mode: 0.35mA - Power-down Mode: 0.4µA - Power-save Mode: <1.0µA (Including 32kHz RTC)
Leider muß ich hier noch was korrigieren: Bei "Hardware QTouch Acquisition" heißt es weiterhin NO! Da bin ich falsch informiert woden- zumindest gilt das noch für die 48er-168er PB-Serie. Der Touch-Channels derer gibt es nun aber 16 statt zuvor 12. Angeblich soll auch der ADC-Speed erhöht worden sein was aus dem vorläufigen Datenblatt aber bislang nicht ersichtlich ist. Und noch ein wichtiges Detail: Die Max. I/O-Pins erhöhen sich von 23 auf 27 ...
Werden sie sich auch preislich den kleinen M0(+) nähern? Aktuell schaut's da ja etwas düster aus... Im Moment ist der mega88 teurer als die 32k CM0 derivate von stm, nxp, infineon...
BastiDerBastler schrieb: > Gibt's eigentlich eine Overclocker-Szene mit und rund um Atmel > 8-Bitter? Da lässt sich bestimmt noch einiges rausholen! Da hast Du Recht. Insbesondere die neuen Xmegas vertragen deutlich mehr als die nominellen 32 MHz. 40 sind locker drin, es gibt auch Berichte über das Doppelte und mehr. Für sehr vieles langen doch aber die 2Mhz vom Start weg.
Bernd K. schrieb: > Eine Nummer kleiner als DIP (zum Beispiel SOIC) ist meiner Meinung nach > für den Hobbyisten noch einfacher zu verarbeiten als DIP da man keine > Löcher bohren muss und das Ding ist schneller gelötet (und notfalls > sogar wieder ausgelötet) als DIP. Das Problem ist weniger die Löterei an den SMD-Packages, sondern vielmehr die Platinenherstellung. Klar, wenn man die Fähigkeiten und Gerätschaften hat, um richtige Platinen zu ätzen, ist das Zeug super. Wenn man seine Schaltungen auf Lochraster aufbauen will, sind diese SMD-Packages aber extrem nervig. Klar, man kann Breakout-Boards nutzen, aber die nehmen halt noch weit mehr Platz weg als ein IC-Sockel mit eingestecktem Chip.
Gregor Ottmann schrieb: > Das Problem ist weniger die Löterei an den SMD-Packages, sondern > vielmehr die Platinenherstellung. Klar, wenn man die Fähigkeiten und > Gerätschaften hat, um richtige Platinen zu ätzen, ist das Zeug super. So günstig wie heute ist man noch nie an Platinen gekommen: OSH Park, Platinensammler, China 1USD PCBs. Man muss sich halt nur gedulden und mehr als Entwickler und weniger als Bastler arbeiten. > Wenn man seine Schaltungen auf Lochraster aufbauen will, sind diese > SMD-Packages aber extrem nervig. Klar, man kann Breakout-Boards nutzen, > aber die nehmen halt noch weit mehr Platz weg als ein IC-Sockel mit > eingestecktem Chip. Der Platzverbrauch fürs Prototyping ist doch eigentlich egal? Dafür gibt es übrigens auch die ganzen günstigen Devboards.
Tim schrieb: > Man muss sich halt nur gedulden und > mehr als Entwickler und weniger als Bastler arbeiten. Das ist genau der Punkt: Ich bin Hobbybastler, kein Entwickler. Wenn ich gerade Lust habe, irgendwas zu löten, möchte ich keine 5 Wochen warten, bis Seeedstudio liefert. Und ich möchte keine 15-20 Euro für 10 Platinen ausgeben, wenn ich nur ein Einzelstück zusammenfrickeln wollte. Mir ist schon klar, dass das Argument weder für Berufselektroniker noch für die wirklich ambitionierten Bastler zählt. Für Leute wie mich, und von denen gibt es sicher noch ein paar mehr, ist THT aber einfach super. Ich will meine eigenen Schaltungen zusammenstecken, ich will mit Breadboards Prototypen basteln und ich will dabei die selben Komponenten benutzen, die ich anschließend auf meinen Lochrasterkunstwerken verbaue. Ich werde sicherlich einen Weg finden, das irgendwie auch weiterhin zu tun - aber ich finde es halt schade, dass ich dafür zukünftig unnötig klobige Breakouts werde benutzen müssen.
:
Bearbeitet durch User
Die Änderungen sind ja doch sehr zaghaft, viel heiße Luft um fast nichts. Ich hätte da schon deutliche Verbesserungen erwartet, z.B.: 4 Programmierpins sind heutzutage zu viel, 1..2 Pins sollten reichen. Und die Fusebits sind auch antiquarisch, Umschalten der Taktquelle zur Laufzeit könnnen andere schon lange. Und natürlich gepuffertes Slave-SPI, damit endlich auch benutzbar. Und CAN, UART auch ab 8-Pinner. 12bit ADC wäre auch nicht schlecht. Da wir CAN (fast) immer benötigen, ist unser standard AVR notgedrungen der AT90CAN128. Ist zwar alt, aber gut beschaffbare Lagerware. Die neueren ATmega64M1 waren zum Zeitpunkt der Entscheidung immer noch nur sporadisch zu erhalten.
:
Bearbeitet durch User
Moby schrieb: > Die Evolution der Simply-AVR Controller schreitet auch 2015 weiter > voran. > Mit neuen innovativen Features und den gewohnt niedrigen > Einstiegshürden. Ein gruseliger Gruß aus der ATMEL Marketingabteilung :-( Innovation ist eine BWL-Umschreibung für alten Wein in neuen Schläuchen. Ansonsten finde ich es gut, dass es abseits von ARM auch noch andere lebende Architekturen gibt. Monokultur war noch nie gut.
Peter Dannegger schrieb: > Und natürlich gepuffertes Slave-SPI, damit endlich auch benutzbar. Ich schließe mich heftig mit dem Kopf nickend an.
Peter Dannegger schrieb: > Umschalten der Taktquelle zur Laufzeit könnnen andere schon lange. Wofür ein Umschalten der Quelle? Das man den Takt zur Laufzeit auf einen Teiler 1/2/4/8/16/32/64/128/256 einstellen kann ist doch schon sehr schick. > Da wir CAN (fast) immer benötigen, ist unser standard AVR notgedrungen > der AT90CAN128. Ich benutze den 90CAN32 und den 16M1. Während der 90CAN32 etwas angestaubt ist, ist mir der 16M1 dann wieder eher zu klein. Richtig gut gefallen würde mir ein 164M1 oder auch 164C1 weil ich den PSC sowieso nicht benötige, aber dann bitte auch mit zwei 16Bit Zählern drin. Alternativ wäre der AVR32UC3C264C zu nennen, mit dem habe ich mich aber einfach mangels Druck nicht weiter beschäftigt und ein AVR ist das ja auch nicht mehr wirklich. Beispiele zu den UC3C zu finden und sich daran zu orientieren ist auch nicht so einfach, die Teile scheint kaum wer zu benutzen. Sonst hat Atmel eben nur die SAM4E mit 100 Pins und im SAM5A ist auch CAN drin, beides keine Alternativen für mich. Auch schon nicht, weil es keine Automotive ARMs von Atmel gibt, also das auf einer normalen Version zu entwickeln und bei Bedarf auf Automotive zu wechseln ist da genauso wenig gegeben wie beim STM32.
Rudolph schrieb: > Wofür ein Umschalten der Quelle? Hast Du ne Ahnung, was für ein Streß das ist, wenn erst beim Kunden in China rauskommt, daß die Fusebits in der Produktion falsch gesetzt wurden? Und man kann sich nicht mehr versehentlich aussperren, wenn er immer zuerst mit den internen 1MHz losrennt.
Schön wäre auch ein AVR mit 2 CAN. Es kommt durchaus nicht selten vor, daß man im Redesign 2 Module auf eine Platine reduzieren kann. Dann wäre es schön, wenn man einfach beide Firmwaren zusammen kopiert und der CAN-Master immer noch denkt, er spricht mit 2 Baugruppen, also keine Änderung benötigt.
@ Peter Dannegger (peda) >Hast Du ne Ahnung, was für ein Streß das ist, wenn erst beim Kunden in >China rauskommt, daß die Fusebits in der Produktion falsch gesetzt >wurden? Dann hat du eine schlechte Produktion und einen mangelhaften Funktionstest. >Und man kann sich nicht mehr versehentlich aussperren, wenn er immer >zuerst mit den internen 1MHz losrennt. Aus dieser Bastlerphase sollten zumindest die Profis lange raus sein.
Peter Dannegger schrieb: > Hast Du ne Ahnung, was für ein Streß das ist, wenn erst beim Kunden in > China rauskommt, daß die Fusebits in der Produktion falsch gesetzt > wurden? Nein, zum Glück nicht. Bandende Kontrolle und so? :-) Peter Dannegger schrieb: > Schön wäre auch ein AVR mit 2 CAN. Der AVR32UC3C264C hat zwei und Ethernet und USB und geht bis 60MHz hoch und hat bis 512k FLASH, dazu es auch noch Versionen mit mehr Pins. >Dann wäre es schön, wenn man einfach beide Firmwaren zusammen kopiert >und der CAN-Master immer noch denkt, er spricht mit 2 Baugruppen, >also keine Änderung benötigt. Häh? Ist doch erstmal egal, ob eine Botschaft von 1, 2 oder drölf Baugruppen empfangen wird. Genauso wie nicht festzustellen ist, woher eine Botschaft kommt, fünf Botschaften können von 1-5 Teilnehmern kommen.
Falk Brunner schrieb: > Dann hat du eine schlechte Produktion und einen mangelhaften > Funktionstest. Falsche Fuses müssen sich nicht beim Test bemerkbar machen. Z.B. Quarz im Power-Save kann manchmal nicht anschwingen oder instabil sein. Fehlendes Brownout kann vergeßlichen EEPROM bewirken. Neue Firmware enthält jetzt immer auch einen Fusetest und bei Fehler blinken z.B. LEDs. Eine Konfiguration zur Laufzeit wäre trotzdem schöner und bequemer. Dann könnte man z.B. erstmal einen Bootloader auf alle AVRs brennen und später die für die Applikation nötigen Fuses setzen.
:
Bearbeitet durch User
Hier mal ein cooles Produkt wo ein ATmega32U4 zum Einsatz kommt. Es muss nicht immer ein ARM sein, auch nicht bei kommerziellen Produkten. https://www.indiegogo.com/projects/mooltipass-open-source-offline-password-keeper http://hackaday.com/2014/11/04/developed-on-hackaday-crowdfunding-campaign-start/
Und hier nun auch das erste große Datenblatt: http://www.atmel.com/Images/Atmel-42176-ATmega48PB-88PB-168PB_Datasheet.pdf
Peter Dannegger schrieb: > Hast Du ne Ahnung, was für ein Streß das ist, wenn erst beim Kunden in > China rauskommt, daß die Fusebits in der Produktion falsch gesetzt > wurden? Also wir testen unser Zeug zumindest soweit daß wir wissen daß es wenigstens überhaupt funktioniert bevor es in Serie geht. Wie soll das überhaupt anders funktionieren? > Und man kann sich nicht mehr versehentlich aussperren, wenn er immer > zuerst mit den internen 1MHz losrennt. Dann hat man halt 50 Cent geschrottet, holt man sich nen neuen und macht es das zweite Mal richtig. Ist mir auch schon passiert. Weit häufiger jedoch zerschießt man ein Bauteil auf die althergebrachte Weise (unter Abgabe von Rauchzeichen), das gehört einfach dazu.
:
Bearbeitet durch User
Steffen H. schrieb: > Schlafend (und das ist die >> Standardtätigkeit zukünftiger IOT Devices) schlägt das 8 Bit- jedes ARM >> System! > > nö ! Doch! Wenngleich der PB-Typ hier nun nicht der Vorreiter ist sondern ein Mega-PA Typ mit 100nA sleeping. Damit und weiteren Vorteilen der 8-Bitter gegenüber ARM, sowie mit einem Ausblick auf die Marktentwicklung (ein Wahnsinn, welche Marktanteile die 32er den 8-Bittern da in Zukunft abnehmen ;-) befaßt sich ein Dokument von Atmel- die ja bekanntermaßen beide Familien im Auge haben: http://www.atmel.com/Images/45107A-Choosing-a-MCU-Fredriksen_Article_103114.pdf
Und hier noch ein aktueller Blog-Beitrag zur gleichen Thematik: blog.atmel.com/2014/12/05/8-or-32-bit-that-is-the-question/
der neue L4 von ST hat nachgelegt. Im Sleep Mode nur noch 45nA. Deinen Blog kannst Du Dir schenken. Den Mega-PA gibt es noch nicht, den L4 gibt es aber schon und im Februar 2015 für alle verfügbar. Der L4 ist im übrigen ein Low Power Cortex-M4.
Nur mal so schrieb: > Den Mega-PA gibt es noch nicht Du meinst PB? Mega 88-PA hab ich die letzten Wochen 100 Stück verbaut. > kannst Du Dir schenken Nicht schon wieder :-( die Diskussion ist doch 1000 Mal bis zum Ende geführt worden, man steigt nicht mal eben zum Spaß auf ne komplett andere Architektur um und fängt dort quasi wieder bei 0 an wenn man sich umfangreiche Erfahrungen und Skills und Libraries und Tools für AVR aufgebaut hat.
> Nicht schon wieder :-( die Diskussion ist doch 1000 Mal bis zum Ende > geführt worden, man steigt nicht mal eben zum Spaß auf ne komplett > andere Architektur um und fängt dort quasi wieder bei 0 an wenn man sich > umfangreiche Erfahrungen und Skills und Libraries und Tools für AVR > aufgebaut hat. natürlich hatten wir die Diskussion schon und die wird auch weiter gehen, so lange Moby mit seiner dämlichen Art und Weise die Überlegenheit der 8-Bit Technik zu schau stellt. 8Bit MCU's sind schon lange nicht mehr überlegen und von Atmel schon gar nicht. Die Welt von Moby was MCU's betrifft ist sehr klein und an seiner stelle würde ich auf 4Bit über gehen ( EPSON). Die sind noch einfacher zu programmieren noch günstiger und was den Strom im Sleep betrifft unschlagbar ( 20nA ).
Nur mal so schrieb: > Den Mega-PA gibt es noch nicht Da bist Du aber, nur mal so, schlecht informiert ;-) Nur mal so schrieb: > dämlichen Art und Weise die > Überlegenheit der 8-Bit Technik zu schau stellt Hier gehts nicht um Überlegenheit, sondern um richtigen Controllereinsatz für den richtigen Zweck. Kann aber sein, daß schon ein nüchterner Vergleich, wie ihn Atmel hier anstellt, für manchen 32Bit Fan die blanke Zumutung darstellt. Einfach nur dämlich, sag ich dazu ;-)
> Hier gehts nicht um Überlegenheit, sondern um richtigen > Controllereinsatz für den richtigen Zweck. kannst Du doch gar nicht entscheiden, Deine Welt hört doch bei 8Bit auf. Wenn Du wirklich eine richtige Entscheidung treffen willt. musst Du mit dem Teilen schonmal gearbeitet haben. Was von Dir kommt ist reines Marketing geblubber, mehr nicht.
Nur mal so schrieb: > Deine Welt hört doch bei 8Bit auf > Marketing geblubber, Schon klar, irgendwie muß man sich ja gegen die Faktenlage abschirmen ;-) Ich empfehle Dir mal eine Erweiterung des Blickfeldes 'nach unten' in die 8-Bit Welt. Fang schon mal mit den AVR-Controllern an, da fehlt Dir glaub ich irgendwie noch die Übersicht. Nur mal so schrieb: > an seiner stelle würde ich > auf 4Bit über gehen ( EPSON) Soviel zur baldigen Ablösung von 8-Bit ;-) 8Bit Simplizität ist einfach für viele Problemstellungen optimal ohne zuviele Kompromisse zu machen. In dem Zusammenhang sind auch die hohen Zuwachsraten bei den 8-Bittern in den kommenden Jahren nur eines: folgerichtig!
> Ich empfehle Dir mal eine Erweiterung des Blickfeldes 'nach unten' in > die 8-Bit Welt. Fang schon mal mit den AVR-Controllern an, da fehlt Dir > glaub ich irgendwie noch die Übersicht. ich habe mit AVR schon programmiert, als an Dich noch nicht zu Denken war, halte Dich also etwas zurück. Die Teile sind heute noch in Projekten drin, werden aber nach und nach entfernt und durch billigere CM0+ ersetzt. Atmel hat mir persönlich nichts mehr zu bieten. Das machen andere besser, billiger und vor allem schneller.
Nur mal so, verlangt ja keiner daß Du mir glaubst. Aber so eine kühl rationale Gegenüberstellung der Architekturen, von Fachleuten verfasst die beide Welten im Blick haben sollten, könntest Du ja schon mal zur Kenntnis nehmen. Nur mal so schrieb: > Atmel hat mir persönlich nichts mehr zu bieten. Das kann und will ich nicht ändern. Du aber bist auch nicht die Welt.
Nur mal so schrieb: > ich habe mit AVR schon programmiert, als an Dich noch nicht zu Denken > war Wenigstens etwas Humor haste noch ;-)
Nur mal so schrieb: > Atmel hat mir persönlich nichts mehr zu bieten. Das machen andere > besser, billiger und vor allem schneller. Dann hab ich zwei Fragen an dich: 1) Wieso diskutierst du in einem Thread mit, in dem es ganz klar um die Weiterentwicklungen der 8-Bitter Serien von Atmel geht? 2) Solltest du die Weiterentwicklungen nicht begrüßen, wenn dadurch neue Produkte entstehen, die für dich wieder interessant werden könnten? Zum Bitkrieg: Wer in dem Umfeld professionel unterwegs ist nimmt einfach das, was bei seine Voraussetzungen den besten Kompromiss darstellt. Mit einiger Erfahrung schaut der sich dann sicher nicht mehr jeden möglichen Typ bei einer Auswahl für sein Projekt an. Wenn er gut ist wird er aber bei Neu- oder Weiterentwicklungen sicherlich mal einen Blick drauf werfen, ob es interessant ist. Sonst ist er halt einfach nur ein mittelmäßiger Entwickler und die Welt geht auch nicht unter. Gruß Kai PS: Ich bin mal auf den Einzug der 64 µCs gespannt, dann haben die 32-Bitter entweder einen Zweifrontenkrieg zu führen oder sie geraten in Vergessenheit wie die 16-Bitter und werden einfach nur noch von den Leuten benutzt, die sie brauchen, ohne das der Rest der Welt sich darum kümmert.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.