Hallo, welche AVRs (Tiny,Mega) sind noch per SPI mit den einfachen Adaptern, ohne richtigen "Programmer" (UPDI etc.) zu programmieren, wie der ATMEGA8, oder der ATTINY2313? Bei Microchip finde ich keine Übersicht, die das enthält z.B: AVR® MCU Peripherals Quick Reference Card https://ww1.microchip.com/downloads/en/DeviceDoc/30010135E.pdf oder https://www.microchip.com/en-us/parametric-search/chartno_716 Muss ich dafür jedes DB öffnen und nachsehen? Vilen Dank für Eure Hilfe
8 Pins: ATtiny 13, 15, 25, 45, 85 14 Pins: ATtiny 24, 44, 84, 441, 841 20 Pins: ATtiny 261, 461, 861, 2313, 4313 28 Pins: ATmega 8, 48, 88, 168, 328, 328PB 40 Pins: ATmega 16, 32, 164, 324, 644, 1284, 8515, 8535 64 Pins: ATmega 64, 128, 640, 1280, 1281, 2560, 2561 Vermutlich gibt es noch ein paar mehr.
Vielen Dank Stefan, dann lasse ich von den anderen erstmal die Finger weg.
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?
Danke für die Hinweise. Ich dachte, das wären aufwendige, teure Programmer. Das schaue ich mir mal an.
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.
Stefan ⛄ F. schrieb: > Kostet entsprechend Arbeitszeit und Nerven. Die eigentliche Bezahlung der hohen Rechenleistung (bei günstigen Preisen).
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.
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.