Frank schrieb:> Vielen Dank Stefan, dann lasse ich von den anderen erstmal die Finger> weg.
Das ist, perspektivisch gesehen, sicher keine sehr weise Entscheidung.
Zwar wird MC wohl die klassischen AVR nicht so schnell abkündigen, aber
ihre Preise, die ja schon immer recht hoch waren, werden noch deutlich
weiter steigen und die Verfügbarkeit sinken.
Dazu kommt, dass die neueren AVR oft leistungsfähiger und dabei trotzdem
deutlich günstiger sind.
Außerdem ist der Programmer dafür so billich wie nie, man braucht nur
einen handelsüblichen, spottbilligen USB-RS232-Wandler dafür (und eine
Diode oder einen Widerstand).
Was allerdings teuerer wird, ist Debugging. Dafür kommt ernsthaft nur
der AVRICE3 in Frage und der ist leider exorbitant teuer. Zeitweise gab
es die nackte Platine zu einem akzeptablen Preis, aber diese Zeiten sind
leider auch vorbei.
c-hater schrieb:> Was allerdings teuerer wird, ist Debugging. Dafür kommt ernsthaft nur> der AVRICE3 in Frage und der ist leider exorbitant teuer.
Dem ist (nicht mehr) so, spätestens seit es die günstigen Curiosity Nano
Boards bei Microchip gibt. Mit ca. 16€ ist man dabei! Nennt sich eEDBG.
c-hater schrieb:> Das ist, perspektivisch gesehen, sicher keine sehr weise Entscheidung.
Wieso?
> Zwar wird MC wohl die klassischen AVR nicht so schnell abkündigen, aber> ihre Preise, die ja schon immer recht hoch waren, werden noch deutlich> weiter steigen und die Verfügbarkeit sinken.
Davon gehe ich auch aus. Deswegen würde ich nach diesen klassischen AVR
eher den Sprung auf ARM machen, wenn Bedarf für mehr Leistung besteht.
Die Xmega Serie ist z.B. für mich weder Fleisch noch Fisch. Sie füllt
eine Marktlücke, die niemand füllen muss. Denn sie sind weder so einfach
programmierbar wie die klassischen AVR, noch sind sie so Leistungsstark
wie die billigeren (!) Arm Controller.
Bei den neuen verbesserten ATtinies weiß ich ebenfalls nicht, wo ich die
mental hinstecken soll. Wenn mir ein ATtiny nicht reicht, nehme ich
ATmega. Wenn ATmega nicht reicht, nehme ich ARM. Das sind schon genug
auswahlmöglichkeiten. Warum soll ich mit extra Werkzeuge und Know-How
für diese "Lückenfüller" aneignen?
Profis sehen das sicher anders, aber ich bin Hobby-Programmierer. Ich
habe keine Lust auf unnötige Komplexität und Vielfalt.
Stefan ⛄ F. schrieb:> Wenn ATmega nicht reicht, nehme ich ARM
Hast Du Grafikdisplays pur anzubinden oder welche sind diese Fälle?
Das beißt sich nämlich etwas mit
> Ich habe keine Lust auf unnötige Komplexität und Vielfalt.
Egon schrieb:> Hast Du Grafikdisplays pur anzubinden oder welche sind diese Fälle?
Das war in der Tat der erste Fall wo ich einen ARM verwenden musste.
Der zweite war eine Uhr. Hier bot sich das Blue-Pill Board an, weil da
die RTC bereits mit drin ist. Ja, ich hätte dazu auch einen AVR nehmen
können - wäre aber teurer gewesen.
Die meisten Basteleien mache ich immer noch mit AVR. Ich gehe allerdings
davon aus, dass ich noch das Ende der 8 Bit Controller erleben werde.
c-hater schrieb:> Was allerdings teuerer wird, ist Debugging. Dafür kommt ernsthaft nur> der AVRICE3 in Frage und der ist leider exorbitant teuer. Zeitweise gab> es die nackte Platine zu einem akzeptablen Preis, aber diese Zeiten sind> leider auch vorbei.
Naja, für vieles reicht doch erstmal auch ein PICkit oder ICD, oder?
Stefan ⛄ F. schrieb:> Ich gehe allerdings davon aus, dass ich noch das Ende der 8 Bit> Controller erleben werde.
Ich nicht. Schon lange nicht mehr.
Deshalb, weils ganz einfach langt:
> Die meisten Basteleien mache ich immer noch mit AVR.
Johannes S. schrieb:> die AVR sind hier heilig
Sie reichen für vieles ganz einfach aus, Johannes! Da müsste schon eine
wesentlich einfacher programmierbare Hardware daherkommen. Aber die
Entwicklung geht ja eher in die Gegenrichtung, gell?
Frank schrieb:> Das schaue ich mir mal an.
Schau Dir vor allem die neue AVRxxxDx Generation an. Die stecken alle
anderen AVRs in die Tasche. Ganz heißer Tipp!
Egon schrieb:> Schau Dir vor allem die neue AVRxxxDx Generation an. Die stecken alle> anderen AVRs in die Tasche. Ganz heißer Tipp!
So sieht das aus. Betriebspannungsbereich (bei Maximaltakt) 1.8..5.5V,
bis 16kByte interner SRAM, bis 128kByte Flash, bis zu 56,5 GPIOs (der
halbe taugt leider nur als Eingang).
Und: es gibt den jeweils kleinsten Vetreter bezüglich des Pin-Count als
DIP28. -> Sehr billige Versuchaufbauten sind sehr schnell realisierbar.
Kein Rumgenerve mit dummen Adapterboards, die teuerer sind als der µC
selber.
Stefan F. schrieb:
> Die Xmega Serie ist z.B. für mich weder Fleisch noch Fisch
Ja, die verbanden die Nachteile der ARMs mit den Nachteilen der
klassischen AVR8. Aber die neuen AVR8 tuen das nicht (auch wenn sie in
vielen Aspekten Erben der XMega-Reihe sind).
> Warum soll ich mit extra Werkzeuge und Know-How für diese "Lückenfüller"> aneignen?
Extra Werkzeuge brauchst du nicht, zumindest nicht in Bezug auf
Software. Geht ganz normal mit dem Atmel/MC-Studio. Nur halt einen neues
Interface zur Hardware. So lange man ohne Hardware-Debugging auszukommen
vermag, kostet das weniger als ein Kaffee an der Autobahn-Raststätte
oder im DB-Zug.
Was das Know-How betrifft: Klar ist die Peripherie anders als die der
klassischen AVR8 und man muss was neues lernen, um sie erfolgreich
einsetzen zu können. Aber sie ist immer noch sehr viel einfacher
gestrickt als die ARM-Gegenstücke, also viel einfacher zu erlernen und
zu benutzen.
Stefan ⛄ F. schrieb:> Ich gehe allerdings> davon aus, dass ich noch das Ende der 8 Bit Controller erleben werde.
Das glaube ich ganz sicher nicht und gebe zu bedenken, dass "gestern"
noch eine significante Anzahl von 4-bit uC verbaut wurden/werden und
8-bit uC sicher noch viele Jahrzehnte leben und uns denkbar überleben!
c-hater schrieb:> verbanden die Nachteile der ARMs
... ein oft übesehender Nachteil mit ARM ist die "bescheidene",
vohersehbare/-berechenbare/fixe Interrupt Response Time.
Apollo M. schrieb:> Das glaube ich ganz sicher nicht und gebe zu bedenken, dass "gestern"> noch eine significante Anzahl von 4-bit uC verbaut wurden/werden und> 8-bit uC sicher noch viele Jahrzehnte leben und uns denkbar überleben!
So isses. Wenn an den meisten oder gar allen Eingängen eh' nur ein
veschissenes Bit zu verarbeiten ist, ist ein 8Bit-Controller
(mindestens) genauso gut dafür geeignet, dies zu tun, wie eine
32Bit-Controller.
Hier bringt die typisch potentiell höhere Rechenleistung exakt NULL
Vorteil, die typisch deutlich höheren Latenzen aber dafür oft Nachteile.
Vom typisch höheren Energiebedarf mal ganz zu schweigen...
Also ich denke auch, dass zu dem Zeitpunkt, da ich das Zeitliche segnen
werde, immer noch millionenfach pa. 8Bitter verbaut werden.
c-hater schrieb:> Wenn an den meisten oder gar allen Eingängen eh' nur ein> veschissenes Bit zu verarbeiten ist, ist ein 8Bit-Controller> (mindestens) genauso gut dafür geeignet
Und was ist, wenn das Bit nicht "verschissen ist"?
c-hater schrieb:> Hier bringt die typisch potentiell höhere Rechenleistung exakt NULL> Vorteil, die typisch deutlich höheren Latenzen aber dafür oft Nachteile.> Vom typisch höheren Energiebedarf mal ganz zu schweigen...
Sag das nicht. Vor wenigen Jahren hieß es noch: Was kasperst du mit AVR
herum, ESP Chips sind die Zukunft.
Stefan ⛄ F. schrieb:> Sag das nicht. Vor wenigen Jahren hieß es noch: Was kasperst du mit AVR> herum, ESP Chips sind die Zukunft.
Das hieß es höchstens in der Arduino-Szene. Sprich: hat keinerlei
ernsthafte Bedeutung im RL. Außer halt für Leute, die so arm dran sind,
dass sie ausgerechnet in dieser Szene ihr Geld verdienen müssen.
c-hater schrieb:> Das hieß es höchstens in der Arduino-Szene.
Nee, das war hier auf Mikrocontroller.net. Wir hatten auch mal diese
Phase, wo man für dumm erklärt wurde, wenn man die zusätzliche
Leistungsfähigkeit für weniger Geld nicht nehmen wollte.
Dein völlig valides Argument bezüglich Timing hatte nur wenige Leute
interessiert. Naja, das ist Vergangenheit. Inzwischen sind einige an
I²C, PWM und Lichterketten an ESP8266 verzweifelt. Das sind alles
lösbare Probleme, aber eben doch nicht so einfach, wie auf 8 Bit
Mikrocontrollern. Kostet entsprechend Arbeitszeit und Nerven.
c-hater schrieb:> Extra Werkzeuge brauchst du nicht, zumindest nicht in Bezug auf> Software. Geht ganz normal mit dem Atmel/MC-Studio. Nur halt einen neues> Interface zur Hardware. So lange man ohne Hardware-Debugging auszukommen> vermag, kostet das weniger als ein Kaffee an der Autobahn-Raststätte> oder im DB-Zug.>> Was das Know-How betrifft: Klar ist die Peripherie anders als die der> klassischen AVR8 und man muss was neues lernen, um sie erfolgreich> einsetzen zu können. Aber sie ist immer noch sehr viel einfacher> gestrickt als die ARM-Gegenstücke, also viel einfacher zu erlernen und> zu benutzen.
Und wenn Du dann schon dabei bist, ist der Sprung zu PIC24/dsPIC33 auch
nicht mehr weit. Du sind eher noch einfacher zu programmieren als AVR,
und als 16-Bit Prozessoren für C noch besser geeignet, weil der
C-Standard ja für 16-Bit Maschinen geschrieben wurde und es der Compiler
dann einfacher hat.
fchk
Stefan ⛄ F. schrieb:> Dein völlig valides Argument bezüglich Timing hatte nur wenige Leute> interessiert. Naja, das ist Vergangenheit. Inzwischen sind einige an> I²C, PWM und Lichterketten an ESP8266 verzweifelt. Das sind alles> lösbare Probleme, aber eben doch nicht so einfach, wie auf 8 Bit> Mikrocontrollern. Kostet entsprechend Arbeitszeit und Nerven.
Naja. Ich wage mal die These, daß bei ESP & Co einfach nur mit Kanonen
auf Spatzen geschossen wird, der Großteil der "Anwendungen" sind
einfache Spielereien, die per WLAN/App ein paar LEDs blinken lassen. Die
Leistungsfähigkeit der CPU und des Speichers bleiben ungenutzt. Der
wirkliche Pluspunkt dieser Controller ist die nahtlose und leicht
nutzbare Integration von WLAN und TCP/IP. So wie ein Großteil des IoT
Hypes nur Hipsterspielkram ist. Eine Generation ohne echte Problem
schafft sich welche, damit sie was zu tun hat.
Frank K. schrieb:> Und wenn Du dann schon dabei bist, ist der Sprung zu PIC24/dsPIC33 auch> nicht mehr weit. Du sind eher noch einfacher zu programmieren als AVR,> und als 16-Bit Prozessoren für C noch besser geeignet, weil der> C-Standard ja für 16-Bit Maschinen geschrieben wurde und es der Compiler> dann einfacher hat.
Das interessiert den Anwender eines C-Compilers keine Sekunde! Denn
genau DAFÜR ist der Compiler da! Wie leicht oder "schwer" es der
Compilerbauer hat, ist vollkommen egal! Und selbst ein AVR hat keine
Probleme mit C. Eher die ollen PICs mit ihrer vergurkten
Bank-Architektur. Aber die sind so oder so nur eine Nische und so oder
so nicht die Zukunft.
Frank K. schrieb:> Und wenn Du dann schon dabei bist, ist der Sprung zu PIC24/dsPIC33 auch> nicht mehr weit. Du sind eher noch einfacher zu programmieren als AVR
Nein, das sicher nicht.
> und als 16-Bit Prozessoren für C noch besser geeignet, weil der> C-Standard ja für 16-Bit Maschinen geschrieben wurde und es der Compiler> dann einfacher hat.
Wen interessiert C? Und selbst, wenn C relevant ist, hat's der Compiler
zu bügeln. Genau das ist ja das Versprechen eines Compilers, oder nicht?
Aber klar, viele von diesen PICs sind garnicht schlecht, insbesondere
haben sie teilweise sehr interessante Peripherie, die es so in keinem
AVR8 gibt.
Aber leider: viel ist hier etwas bis teilweise sogar sehr heftig buggy.
Das absolut Beunruhigende ist: seitdem MC Atmel gekauft hat, wird nicht
etwa der Status der PICs besser, nein, MC zieht vielmehr den Status der
AVR auf den lausigen Stand der PICs runter.
c-hater schrieb:> Wen interessiert C?
Alle interessieren sich für C, außer du weißt schon wer.
Aber dieser eine Geisterfahrer mischt sich trotzdem immer wieder
destruktiv ein, wenn das Wort fällt. Als hätte man ihn dadurch gerufen.
c-hater schrieb:> C zieht vielmehr den Status der> AVR auf den lausigen Stand der PICs runter.
Besonders beeindruckend ist der Qualitätsverlust der Dokumentation,
welche immer öfter im priliminary Status (lange) verbleibt!
Stefan ⛄ F. schrieb:> Alle interessieren sich für C, außer du weißt schon wer.
Naja, selnbst diese Idioten sind im Allgemeinen fähig, den relevanten
Teil der Aussage vom (für sie) Irrelevanten zu trennen.
Du bist offensichtlich noch unterhalb dieses Kompetenz-Levels...
c-hater schrieb:> MC zieht vielmehr den Status der AVR auf den lausigen Stand der PICs> runter.
Auf der Fehlerliste zum AVR128DBxx findet sich nichts mit besonderes
hinderlichen Auswirkungen. Ich möchte ja nicht wissen wie die
Fehlerliste manches 32Bitters ausschaut.
