Ja, ich weiss, wahrscheinlich sind alle schon weitergezogen und arbeiten
nur noch mit 32 Bit, auch wenns nur ein LED-Blinker ist. Trotzdem frage
ich mich seit mittlerweile Jahren, ob da nochmal irgendwas kommt. Der
Höhepunkt war ja der xmega mit USB+AES+CRC32 in Hardware und die 120nA
RTC vom xmega E. Seitdem sind viele neue 8-Bitter erschienen, aber mit
AES oder USB ist meiner Kenntnis nach überhaupt nichts nachgerückt und
das CRC-Modul der neuen ist ein Witz.
Habe ich was übersehen, oder ist das Pferd wirklich schon längst tot und
es geht quasi nur noch rückwärts?
Tot, wird auch nicht wiederauferstehen.
Es gibt keinen Grund mehr für neuentwicklungen auf basis vom AVR, neben
RISC-V, 8051 wenn es billig sein soll, und natürlich ARM
Zieh doch einfach weiter, was hält dich ab?
Jan schrieb:> auch wenns nur ein LED-Blinker ist.
Dafür braucht man nicht mal 8 Bit und niemand wird, ausser zu
Testzwecken, einen STM32 oder auch AVR zum Blinken einer LED benutzen.
Jan schrieb:> aber mit> AES oder USB ist meiner Kenntnis nach überhaupt nichts nachgerückt
Warum auch? Entweder braucht man USB und/oder AES und bedient sich bei
der breiten Familie der grossen PIC oder STM32 oder man braucht es eben
nicht. Warum sollte sich Microchip auch AVR Konkurrenz ins eigene Haus
holen? Ich habe ein bisschen was mit XMega gemacht - eher zu
Demonstrationszwecken - aber die ganze Nummer ist m.M.n. 'too little,
too late'.
Ein paar nette kleine Tinies und Megas sind ja vor nicht allzu langer
Zeit erschienen.
> Habe ich was übersehen, oder ist das Pferd wirklich schon längst tot und
es geht quasi nur noch rückwärts?
Jo, ist halt Freitag und nicht Donnerstag
Btw. Es gibt neuere gute AVR - und stell Dir vor es gibt auch
Datenblätter darüber.
Jan schrieb:> ist das Pferd wirklich schon längst tot
XMega ist tot, aber AVR128DA ist eine neue Serie.
Allerdings nicht konkurrenzfähig gegen moderne chinesische Controller,
wie SinoWealth, die 100mA Ausgänge, eingebaute LCD Multiplextreiber
haben, andere Modelle die an 1.5V Batterie laufen können oder an 5 bis
24V per eingebautem Spannungsregler.
Auch wenn man vielleicht über USB streiten kann, Hardware AES ist
heutzutage ein Ding, was einfach sein muss. Grad wenn man der abstrusen
Meinung ist, kabelgebunden wäre von gestern. Und da gibts soweit ich
weiss seit dem xmegaA*U nichts neues mehr.
Ich habe mir die neuen alle angeschaut, aber so richtig gut sind die
doch alle nicht. Eher Modellpflege. Eigentlich hätte ich gehofft, es
käme endlich mal ein neuer xmega raus. Von mir aus können die den ja
gerne anders benennen... DA... DB... DAB+? hrhr
Jan schrieb:> Ich habe mir die neuen alle angeschaut, aber so richtig gut sind die> doch alle nicht
Willst Du hier rumtrollen?
Was gut genug ist definiert die Anwendung. Mit den neuen Dx Typen haben
sich die Einsatzgebiete nochmal drastisch vergrößert.
Wie gesagt, ohne AES geht das heutzutage nicht mehr. Und auch wenn man
AES relativ gut in Software nachbauen kann, so ist spätestens beim oft
nötigen TRNG Schluss. Bei den 32 Bittern ist sowas Standard.
MaWin schrieb:> Allerdings nicht konkurrenzfähig gegen moderne chinesische Controller,> wie SinoWealth, die 100mA Ausgänge, eingebaute LCD Multiplextreiber> haben, andere Modelle die an 1.5V Batterie laufen können oder an 5 bis> 24V per eingebautem Spannungsregler.
Die pure Hardware ist eben auch nicht alles. Sie sollte so auch
gebraucht, auch leicht verfügbar, auch so gut mit einer
Entwicklungsumgebung unterstützt, auch so gut dokumentiert, auch so
einfach programmierbar sein. Eine jahrzehntelang entwickelte vorhandene
Codebasis tut ihr übriges. Alles in allem- ziemlich wenig Konkurrenz für
Microchip finde ich.
Jan schrieb:> Bei den 32 Bittern ist sowas Standard.
Eben - also warum noch mal das Rad neu erfinden? Einen wirklichen
Unterschied gibts ja nicht zwischen der Programmierung eines STM32 und
eines XMega. Kochen alle mit Wasser. Deswegen lohnt es sich auch nicht,
sich dagegen zu sperren.
Urs H. schrieb:> Die pure Hardware ist eben auch nicht alles. Sie sollte so auch> gebraucht, auch leicht verfügbar, auch so gut mit einer> Entwicklungsumgebung unterstützt, auch so gut dokumentiert, auch so> einfach programmierbar sein. Eine jahrzehntelang entwickelte vorhandene> Codebasis tut ihr übriges
Daher basieren die chinesischen Controller meistens auf 8051.
Das ist zwar kein Arduino-Kinderspielzeug, aber meist professionell
integriert, siehe Keil
Und von den Datenblättern mit Beispieln könnte sich Atmel/Microchip mal
eine Scheibe abschneiden.
http://www.stcmcudata.com/datasheet/stc/STC-AD-PDF/STC12C2052AD-english.pdf
Jan schrieb:> Wie gesagt, ohne AES geht das heutzutage nicht mehr. Und auch wenn man> AES relativ gut in Software nachbauen kann, so ist spätestens beim oft> nötigen TRNG Schluss.
Warum sollte man sowas auf einen 8-Bitter brauchen? Und wenn man was mit
Funk machen will nimmt man was das schon Funk hat.
MaWin schrieb:> Und von den Datenblättern mit Beispieln könnte sich Atmel/Microchip mal> eine Scheibe abschneiden.>> http://www.stcmcudata.com/datasheet/stc/STC-AD-PDF/STC12C2052AD-english.pdf
Da kann man sich mit den übersichtlichen Datenblättern eines AVRs im
Hinterkopf höchstens mit Grausen abwenden! Danke für das Beispiel.
Karl schrieb:> Warum sollte man sowas [AES] auf einen 8-Bitter brauchen?
Das wird uns Jan sicher noch ausführlich erläutern.
Jan schrieb:> Wie gesagt, ohne AES geht das heutzutage nicht mehr
Ähhm. Nein. Wenn ich AES brauche, dann auch Ethernet und USB und das
ganze Gedöhns, das in einem 32-Bitter typischerweise drin ist.
Was die Originalfrage angeht: gar nicht mehr, fürchte ich. Alle neuen
AVR setzen bspw. auf UPDI und den geänderten Befehlssatz. Wenn man neue
Hard- und Software-Tools braucht, kann man die Architektur auch gleich
wechseln. Naja. Ich mach es jedenfalls so. YMMV.
Bei xMEGA ist mit AVR Schluß. Weiter geht es mit Cortex-M. Und RISC-V.
Axel S. schrieb:> Alle neuen> AVR setzen bspw. auf UPDI
Ein großer Fortschritt.
Z.B. sehr günstig mit einem CuriosityNano zu programmieren und zu
debuggen.
> den geänderten Befehlssatz
Da hat sich kaum was geändert. Bei den Peripherie-Modulen schaut das
zunächst etwas anders- bei Programmierung in üblichem C samt zugehöriger
Bibliotheken genauso aus.
> Wenn man neue> Hard- und Software-Tools braucht
Die Programmierung läuft sehr vorteilhaft über UPDI oder bei den schon
angesprochenen (17€) CuriosityNanos gleich über USB. Bei der Software
selber hat sich nur der Name geändert.
> Was die Originalfrage angeht: gar nicht mehr, fürchte ich.
Die Befürchtungen sind aber gegenstandslos. Seit der Übernahme von Atmel
sind fortlaufend neue und bessere AVRs erschienen bzw. sind in der
Pipeline!
> Weiter geht es mit Cortex-M. Und RISC-V.
Gerne. Wo aber in einer Vielzahl von Fällen PICs und AVRs ausreichen
geht es ebenso damit weiter!
Urs H. schrieb:>> Alle neuen>> AVR setzen bspw. auf UPDI>> Ein großer Fortschritt.
Nun ja. Ich mochte "richtiges" JTAG persönlich mehr, aber das kostet
halt 4 Pins, daher kann man das nur bei Vielpinnern sinnvoll machen.
> Die Programmierung läuft sehr vorteilhaft über UPDI oder bei den schon> angesprochenen (17€) CuriosityNanos gleich über USB.
Da hat sich allerdings gegenüber den EDBG/mEDBG aus Atmel-Zeiten nichts
grundsätzlich geändert (XPlained XPlainedPro XPlainedMini). Nur der
Formfaktor ist jetzt schmaler geworden. Die XPlainedMini mit ihrem
Lochrasterboard fand ich für einfache Dinge ganz nützlich.
Ach, und der EDBG-Chip ist inzwischen kein UC3 mehr (war wohl dessen
letzte übrig gebliebene Applikation), sondern ein SAMD21.
Jörg W. schrieb:> Ach, und der EDBG-Chip ist inzwischen kein UC3 mehr (war wohl dessen> letzte übrig gebliebene Applikation), sondern ein SAMD21.
Ja, ein ATSAMD21E18A-U um genau zu sein, der das Evaluieren eines AVRs
als dem ursprünglichen Zweck der CuriosityNanos so komfortabel macht.
Aber dieser Teil gibt eben auch einen vorzüglich kleinen und bezahlbaren
Debugger ab.
> Ich mochte "richtiges" JTAG persönlich mehr, aber das kostet> halt 4 Pins
Und mit UPDI geht das alles jetzt auf nur 1 Leitung (fast) ganz
genauso...
Da kommt doch höchstens etwas Wehmut auf wenn das ursprünglich nicht so
billige JTAGICEmk2 Inventar jetzt in der Ecke verstaubt. Aktuell werden
gar Preise über 300€ verlangt- einfach irre.
> Nur der> Formfaktor ist jetzt schmaler geworden.
Und für den der es besonders schmal aber noch uneingeschränkt
bastlertauglich mag gibts die neuen AVR Dx-Typen 28pinnig sogar noch in
DIP!
Urs H. schrieb:> Ja, ein ATSAMD21E18A-U um genau zu sein, der das Evaluieren eines AVRs> als dem ursprünglichen Zweck der CuriosityNanos so komfortabel macht.> Aber dieser Teil gibt eben auch einen vorzüglich kleinen und bezahlbaren> Debugger ab.
Das ging allerdings mit dem UC3 schon genauso. Also kein Grund für
besondere Lobpreisungen.
>> Ich mochte "richtiges" JTAG persönlich mehr, aber das kostet>> halt 4 Pins>> Und mit UPDI geht das alles jetzt auf nur 1 Leitung (fast) ganz> genauso...
Naja, boundary scan und chaining nicht.
Aber OK, hat man selten gebraucht. Ging aber mit den ATmegas wirklich
(anders als beispielsweise mit MSP430, die konnte man nicht in eine JTAG
chain setzen).
Eine 2-MCU-Platine mit einem ATmega16 und einem ATmega2560 an nur einem
einzigen JTAG hatte ich jedenfalls schon mal.
> Da kommt doch höchstens etwas Wehmut auf wenn das ursprünglich nicht so> billige JTAGICEmk2 Inventar jetzt in der Ecke verstaubt.
Das AtmelICE war ursprünglich genauso billig wie dazumals der Dragon:
das nackte PCB kostete was um die 38 Euro. Und das konnte / kann alles,
von JTAG bis *PDI.
Seit der Microchip-Übernahme haben sich dessen Preise allerdings
verdoppelt.
Im Gegensatz zu den Onboard-Debuggern hat so ein Standalone-Tool halt
noch Schutzschaltung und Pegelwandler mit drauf.
Also für sowas wie einen LED-Blinker sind die 8-Bit-AVRs klasse. Hab ich
gerade letztens erst für einen Kumpel gebaut, zwei Blink-Kanäle mit
Sperrfunktion. Wenn man das in rein-Hardware aufbauen will, braucht man
mindestens einen NE556 und 1..2 Transistoren extra für die Sperre - wozu
wenn man alles in einem einzelnen 8-Pin-IC haben kann? Das einzige was
geringfügig stört, ist der 7805 für die 5V und Logik-Level-FETs für die
LED-Ausgänge (sollte ein paar Ampere aushalten, damit im Fehlerfall die
Sicherung draufgeht und nicht die Platine), und das ist ja noch lange
nicht das Ende von dem, was diese kleinen Controller können.
Worüber ich mich aber wirklich gefreut hätte, wäre ein
bastelfreundlicher AVR mit USB- oder LAN-Schnittstelle gewesen. Also
irgend ein DIP-Gehäuse, sowas wie ein ATMega1284 vielleicht. RS232 ist
zwar cool und man bekommt alles irgendwie dran-adaptiert, aber in
Hardware wäre toll gewesen.
OT: Gibts eigentlich ARM-Cortex M3 mit LAN onboard?
Ben B. schrieb:> Worüber ich mich aber wirklich gefreut hätte, wäre ein> bastelfreundlicher AVR mit USB- oder LAN-Schnittstelle gewesen.
Naja, ein QFP sollte man inzwischen als Bastler schon mal löten können,
das ist ja kein Kunststück. Damit bist du mit USB problemlos im Boot.
> OT: Gibts eigentlich ARM-Cortex M3 mit LAN onboard?
Ausreichend. Aber der Transceiver ist typischerweise extern, also du
bekommst da MII- oder RMII-Signale rausgereicht.
Jan schrieb:> Wie gesagt, ohne AES geht das heutzutage nicht mehr.
Quatsch, es gibt viele Anwendungen, die mit Verschlüsselung nichts am
Hut haben.
> Bei den 32 Bittern ist sowas Standard.
Eben deswegen nimmt man bei Bedarf 32 Bit Mikrocontroller. Ich sehe
keinen vernünftigen Grund, es nicht so zu tun.
Jörg W. schrieb:> Naja, ein QFP sollte man inzwischen als Bastler schon mal löten können,> das ist ja kein Kunststück. Damit bist du mit USB problemlos im Boot.
Und für Grobmotoriker und Steckbrettfans gibt es Breakout Boards.
Ich habe bisher immer mit DIP oder fertigen Modulen gearbeitet. Zur
Probe habe ich mal die gezeigten Breakout Boards mit 100 Pin Chips
ausprobiert.
Damit bin ich sehr schlecht zurecht gekommen. Der Chip rutsche mir beim
Löten immer ein bisschen weg. Das Zinn lief über unter das IC und
bildete dort Brücken. Nach vielen Korrekturversuchen (mit Heißluft)
lösten sich dann auch noch einige Leiterbahnen von der Platine.
Danach habe 32 Pin auf genau passenden (nicht universellen) Platinen
versucht, das klappte auf Anhieb tadellos.
Worauf ich hinaus wollte: Ich glaube diese Universal-Platinen taugen
prinzipiell nicht gut. Wenn man dann auch noch (so wie ich) billigen
Scheiß von Aliexpress kauft, dann wird es besonders schwierig.
Stefan ⛄ F. schrieb:> Der Chip rutsche mir beim Löten immer ein bisschen weg.
Erst zwei Ecken fixieren.
Aber das Breakout-Board ist Mist, man braucht eins für die passende
Größe. Leiterzüge unter dem IC sind Käse, weil man dort ggf. sich
bildende Zinnbrücken nicht wieder raus bekommt. Wenn die Leiterzüge an
den IC-Pins enden, kannst du Zinnbrücken allemal mit Entlötlitze
entfernen.
Jan schrieb:> Hardware AES ist heutzutage ein Ding, was einfach sein muss.
Wofür braucht man das in einer elektrischen Zahnbürste, Mikrowelle,
Induktionskochplatte, Dildo...?
Der klassische AVR ist tot. Und das ist auch gut so, die Nachteile
dieser damaligen Typen sind doch offenbar: Untaugliche
Programmierschnittstelle, sechs Pins, Taktproblematik ("verfuset"), kein
Debugging. Wollte man Debuggen, brauchte es noch mehr Pins. Die
Peripherie war beschränkt, man konnte weder die Pins der Peripherie
zuordnen, noch einfache Dinge wie Invertierung der UART-Pegel vornehmen.
Die Timer waren immer zu knapp, umständlich zu bedienen und generell hat
man eigentlich immer etwas vermisst, was andere Controller
selbstverständlich beherrschen. Beispielsweise fehlende
Interrupt-Prioritäten - der AVR war bei seinem Erscheinen selbst dem
ollen 8051 unterlegen. Am schlimmsten war es aber, dass man die
Taktquelle im laufenden Betrieb nicht ändern konnte und die Teile keine
eingebaute PLL für den RC-Oszillator hatten.
Mit den xmega wurden viele dieser Nachteile beseitigt, ja, aber das Ding
wurde dadurch noch hakeliger und so teuer, dass man gleich was
vernünftiges einsetzen konnte.
Microchip hat sich diesen Problemen angenommen und neue AVR entwickelt,
die im Prinzip wie PIC18F mit anderer CPU sind. Praktisch alle Punkte,
die ich an den klassischen AVR wie mega8 bemängelte sind damit gelöst
und die Teile kosten weniger als einen Euro. Wohingegen so ein mistiger
mega zu Atmel-Zeiten das dreifache kostete.
Was genau bemängelt ihr daher? Seid froh, dass die diese Teile überhaupt
soweit überarbeitet haben, dass man die heute sinnvoll nutzen kann.
Microchip hätte die genauso gut ganz abkündigen können.
Michael schrieb:> Der klassische AVR ist tot.
Was ist denn der kalssische AVR? Der At1200? Ein ATmega8?
> Und das ist auch gut so, die Nachteile> dieser damaligen Typen sind doch offenbar: Untaugliche> Programmierschnittstelle, sechs Pins, Taktproblematik ("verfuset"), kein> Debugging. Wollte man Debuggen, brauchte es noch mehr Pins. Die> Peripherie war beschränkt, man konnte weder die Pins der Peripherie> zuordnen, noch einfache Dinge wie Invertierung der UART-Pegel vornehmen.> Die Timer waren immer zu knapp, umständlich zu bedienen und generell hat> man eigentlich immer etwas vermisst, was andere Controller> selbstverständlich beherrschen. Beispielsweise fehlende> Interrupt-Prioritäten - der AVR war bei seinem Erscheinen selbst dem> ollen 8051 unterlegen. Am schlimmsten war es aber, dass man die> Taktquelle im laufenden Betrieb nicht ändern konnte und die Teile keine> eingebaute PLL für den RC-Oszillator hatten.
Man Gott! Wenn das alles nur zur Häfte stimmen würde, wären die AVRs in
wenigen Jahren wieder vom Markt verschwunden. Die Realität sieht anders
aus.
> Microchip hat sich diesen Problemen angenommen und neue AVR entwickelt,> die im Prinzip wie PIC18F mit anderer CPU sind. Praktisch alle Punkte,> die ich an den klassischen AVR wie mega8 bemängelte sind damit gelöst> und die Teile kosten weniger als einen Euro. Wohingegen so ein mistiger> mega zu Atmel-Zeiten das dreifache kostete.
[ ] Du weißt, wie Inflation und Preisentwicklung im Halbleiterbereich
funktionieren.
> Was genau bemängelt ihr daher? Seid froh, dass die diese Teile überhaupt> soweit überarbeitet haben, dass man die heute sinnvoll nutzen kann.> Microchip hätte die genauso gut ganz abkündigen können.
Wozu hätten sie dann Atmel für nicht ganz wenig geld kaufen sollen? OK,
Atmel baute mehr als nur die AVRs.
Alles in allem die prinzipielle Fragestellung des OP eher fragwürdig.
Mein Gott, es gibt HUNDERTE verschiedener AVRs, tausende verschiedener
anderer Mikrocontroller, von winzig bis Schlachtschiff. Da ist für jeden
was dabei! Die Gejammer, "ich will was neues" ist reine Langeweile und
Übersättiung, kein realer Bedarf. Aber auch der neueste Schrei bei 8
oder 32 Bit wird den Mikrocontroller NICHT neu erfinden. Wozu auch? Es
gibt sie und sie funktionieren tadellos!
Michael schrieb:> Microchip hat sich diesen Problemen angenommen und neue AVR entwickelt,> die im Prinzip wie PIC18F mit anderer CPU sind.
Nein. Das sind XMega, bei denen die größten Nachteile der XMega behoben
und einiges eingespart wurde. Insbesondere solche Sachen, bei deren
Notwendigkeit man heute sowieso eher einen 32Bitter benutzen würde.
> Der klassische AVR ist tot.
Nein, noch lange nicht. Er beginnt gerade zu sterben, aber dieses
Sterben wird sich mindestens noch zehn Jahre hinziehen, wenn nicht sogar
20. Eine kommerzielle Neuentwicklung würde ich damit heute auch nicht
mehr starten, aber für sehr viele Hobbyprojekte ist er sicher immer noch
gut genug. Insbesondere dann, wenn Equipment und KnowHow bereits
vorliegen, möglicherweise auch noch Hardware-Bestände.
Stefan ⛄ F. schrieb:> Zur> Probe habe ich mal die gezeigten Breakout Boards mit 100 Pin Chips> ausprobiert.
Ja, das ist Mist.
Es dürfen nur die jeweiligen Pads lötbar sein, alles andere muß unter
den Lötstop.
Falk B. schrieb:> Was ist denn der kalssische AVR? Der At1200? Ein ATmega8?
Als der Hype bei den Hobbybastlern losging, waren es ATmega8/16/32.
Falk B. schrieb:> Man Gott! Wenn das alles nur zur Häfte stimmen würde, wären die AVRs in> wenigen Jahren wieder vom Markt verschwunden. Die Realität sieht anders> aus.
Wo habe ich etwas falsches beschrieben? In Bezug beispielsweise zu einem
ATmega16?
Falk B. schrieb:> [ ] Du weißt, wie Inflation und Preisentwicklung im Halbleiterbereich> funktionieren.
Ich weiß vor allem, dass ich über die Produktlebenszeit halbwegs
kalkulierbare Preise brauche - und Atmel seinerzeit war hier schlicht
und ergreifend deutlich teurer als seine Mitbewerber.
Falk B. schrieb:> Wozu hätten sie dann Atmel für nicht ganz wenig geld kaufen sollen? OK,> Atmel baute mehr als nur die AVRs.
Ich vermute wegen deren starken Engagement bei den Funkgeschichten. Die
ARM-Controller, welche Microchip zuvor nicht anbot, dürften sicherlich
auch eine Rolle gespielt haben.
c-hater schrieb:> Nein. Das sind XMega
Wenn du das sagst. Jedenfalls sind die Teile jetzt benutzbar und könnten
gut eingesetzt werden, wenn sie verfügbar wären. Aber was wird auch noch
werden...
Murmeltier schrieb:> Jan schrieb:>>> Hardware AES ist heutzutage ein Ding, was einfach sein muss.>> Wofür braucht man das in einer elektrischen Zahnbürste, Mikrowelle,> Induktionskochplatte, Dildo...?
Fur die WiFi Connection.
Heute ist alles nichts, was nicht smart IoT ist.
Deine Zahnbürste muss sich im Büro melden, wenn du die heute morgen
nicht benutzt hast,
deine Induktionskochplatte muss vom Rauchmelder automatisch abschaltbar
sein
und die Mikrowelle wird pro Benutzung für 1 EUR geleast, da muss auch
eine Elektronik zum Server drin sein die überprüft ob du bezahlt hast.
Wenn ich solche Mutiformat Adabter verwende, nehme ich Unverzinnte,
dafür Vergoldet. Gibts auch für billig von CN.
Dan nur dort Lötpaste drauf wo der IC auch Pins hat.
Hatte noch nie ein Kurzschlussproblem damit.
Alternativ geht auch es vorher mit Lötstopp zu Sichern wo keine Pins
(unter IC) sind dann gehen auch die Billig-billig von CN die nur
verzinnt sind.
Jan schrieb:> USB+AES+CRC32
Da schließe ich mich den anderen Beiträgen an. Wenn das notwendig ist,
wird man oft auch die Leistung/Komfort von einem STM32 haben wollen.
Natürlich würde man es irgendwie mit 8-Bit & ASM schaffen, aber sinnvoll
ist das nicht (mehr).
In der ATtiny Welt hat sich einiges getan, z.B. umfangreiches Debugging,
QTouch, asynchrone Timer, I2C UART SPI nativ, großer Flash, ...
Das finde ich ganz fantastisch! Meistens brauche ich nur ein paar Pins
aber viel Peripherie, z.B. 5 Touchbuttons, I2C Lichtsensor, 3-4 PWM
Kanäle. Da musste früher entweder der große Chip ran, oder alles in
Software improvisiert werden, was dann am Speicherplatz scheitert. Jetzt
geht das alles auf 14 Pin SOIC.
[OFFTOPIC]
Stefan ⛄ F. schrieb:> Ich habe bisher immer mit DIP oder fertigen Modulen gearbeitet. Zur> Probe habe ich mal die gezeigten Breakout Boards mit 100 Pin Chips> ausprobiert.>> Damit bin ich sehr schlecht zurecht gekommen. Der Chip rutsche mir beim> Löten immer ein bisschen weg. Das Zinn lief über unter das IC und> bildete dort Brücken. Nach vielen Korrekturversuchen (mit Heißluft)> lösten sich dann auch noch einige Leiterbahnen von der Platine.
[ ... ]
> Worauf ich hinaus wollte: Ich glaube diese Universal-Platinen taugen> prinzipiell nicht gut. Wenn man dann auch noch (so wie ich) billigen> Scheiß von Aliexpress kauft, dann wird es besonders schwierig.Peter D. schrieb:> Stefan ⛄ F. schrieb:>> Zur>> Probe habe ich mal die gezeigten Breakout Boards mit 100 Pin Chips>> ausprobiert.>> Ja, das ist Mist.> Es dürfen nur die jeweiligen Pads lötbar sein, alles andere muß unter> den Lötstop.
Ach was, das geht super mit ganz normalem Lötkolben. Man muss nur
Geduld, viel Licht (ggflls. eine Kosmetik-Lupe) und viel Flußmittel
haben. (Das auf dem Bild ist kein AVR.)
Jörg W. schrieb:> Stefan ⛄ F. schrieb:>> Der Chip rutsche mir beim Löten immer ein bisschen weg.>> Erst zwei Ecken fixieren.
So ist es. Der Rest lötet sich fast von selbst.
Man kann das Lötzinn wunderbar über die langen Pads nach innen laufen
lassen.
Oder alternativ drag soldering, siehe Youtube:
https://www.youtube.com/watch?v=wUyetZ5RtPs
Michael schrieb:> der AVR war bei seinem Erscheinen selbst dem> ollen 8051 unterlegen.
Geschickterweise hatte Atmel mit dem AT90S8515 einen zum 8051
pinkompatiben Controller angeboten, sodaß man sich recht einfach vom
Gegenteil überzeugen konnte.
selm schrieb:> Geschickterweise hatte Atmel mit dem AT90S8515 einen zum 8051> pinkompatiben Controller angeboten, sodaß man sich recht einfach vom> Gegenteil überzeugen konnte.
Ich hatte damals versucht, einige Projekte mit dem AT89C2051 auf
ATtiny2313 zu portieren, um den externen Quarz und Reset einzusparen und
bin damit regelmäßig gescheitert. Der AVR brauchte deutlich mehr Flash
und der ATtiny4313 kam erst viele Jahre später.
Ich hatte allerdings auch den Keil C51 (Version 1995) benutzt. Der
AVG-GCC war zwar nicht schlecht, aber wohl nicht vergleichbar
hinsichtlich Codeeffizienz.
Peter D. schrieb:> Ich hatte damals versucht, einige Projekte mit dem AT89C2051 auf> ATtiny2313 zu portieren, um den externen Quarz und Reset einzusparen und> bin damit regelmäßig gescheitert. Der AVR brauchte deutlich mehr Flash> und der ATtiny4313 kam erst viele Jahre später.> Ich hatte allerdings auch den Keil C51 (Version 1995) benutzt. Der> AVG-GCC war zwar nicht schlecht, aber wohl nicht vergleichbar> hinsichtlich Codeeffizienz.
Tja, Asm rules...
Mein Gott, maximal lächerliche 2k Code. Das ist definitiv in Asm sehr
gut beherrschbar. Wenn man's halt wirklich kann und es nicht nur als
ungeliebte "Erweiterung" für einen verschissenen C-Compiler sieht...
c-hater schrieb:> Mein Gott, maximal lächerliche 2k Code. Das ist definitiv in Asm sehr> gut beherrschbar.
Wie gesagt, für den C51 war das auch sehr gut beherrschbar, selbst float
hatte ich oft auf dem AT89C2051/4051 benutzt.
Auch die generic Pointer machten das Programmieren sehr bequem. Um
Flash, data oder xdata mußte man sich nicht kümmern.
Die AT89C2051/4051 sind sogar immer noch gut beschaffbar, sogar in der
jetzigen Chipkrise. Das sind quasi die einzigen MCs, wo unsere
Zulieferer noch nie nach Ersatz gefragt haben.
Leider sind die Produkte damit am Auslaufen, die Programmierer wollen 32
Bitter. Und deren Preise gehen jetzt durch die Decke.
Peter D. schrieb:> Wie gesagt, für den C51 war das auch sehr gut beherrschbar, selbst float> hatte ich oft auf dem AT89C2051/4051 benutzt.> Auch die generic Pointer machten das Programmieren sehr bequem. Um> Flash, data oder xdata mußte man sich nicht kümmern.
Naja, mit xdata hat man auf einem Tiny2313 eher nicht zu tun und die
"Flash-Problematik" ist definitiv in Assembler oft weitaus effizienter
abbildbar als mit den abstrusen Hacks des avr-gcc. Zumindest leichter
lesbar (ohne abstruses Syntax-Geschwalle) auf jeden Fall...
> Die AT89C2051/4051 sind sogar immer noch gut beschaffbar, sogar in der> jetzigen Chipkrise. Das sind quasi die einzigen MCs, wo unsere> Zulieferer noch nie nach Ersatz gefragt haben.
Das sollte einem zu denken geben. Da haben die Lieferketten wohl einen
ziemlichen Überbestand angehäuft. Jetzt zwar ein Vorteil, aber
spätestens wenn wieder alles normal läuft, werden sämtliche Nodes der
Kette (bis hin zu den Quellen) wohl ihre diesbezügliche Strategie
überdenken...
c-hater schrieb:> Das sollte einem zu denken geben. Da haben die Lieferketten wohl einen> ziemlichen Überbestand angehäuft.
So alt wie die AT89C2051 sind (1993), wird es wohl eher sein, daß immer
noch Anwender sehr große Stückzahlen abnehmen. Atmel hatte damals sehr
attraktive Preise gegenüber den üblichen OTP-MCs und war lange der
einzige Anbieter von günstigen Flash-MCs. Ich meine, ein EPROM-87C51 mit
Fenster hat um die 100,-DM gekostet.
Peter D. schrieb:> Der AVR brauchte deutlich mehr Flash> und der ATtiny4313 kam erst viele Jahre später.
Die ersten AVR-Compiler haben bei einer ISR zum Beispiel alle Register
auf den Stack geschoben, was recht verschwenderisch war. Keil hat
einfach einen anderen Registersatz aktiviert, usw.
Meinen 2051 Code habe ich mit einem IAR gut auf den AT90S2313 portieren
können. FP war nur 1K groß, ISR-Aufrufe besser optimiert und wenn alles
zu grob wirkte, wurde ASM verwendet.
Zudem war ISP deutlich angenehmer, als den 2051 immer wieder in ein
Programiergerät zu stecken.
Der 2313 war erheblich schneller und hat richtige PP-Ausgänge!
Die neueren AVRs mit UPDI sind gut und auch günstig, wenn man sich auf
das beschränkt, was wirklich gebraucht wird. AES gehört nicht dazu.
Murmeltier schrieb:> Jan schrieb:>> Hardware AES ist heutzutage ein Ding, was einfach sein muss.>> Wofür braucht man das in einer elektrischen Zahnbürste, Mikrowelle,> Induktionskochplatte, Dildo...?
Also GERADE im Gildo hätte ich bitte AES! scnr
Klar, es gibt Millionen Anwendungen, die mit einem isoliertem µC
auskommen und wenn die Gesamtanwendung den einen µC nicht verlässt,
braucht es auch kein AES. Ich meinte aber über die anderen Millionen
Anwendungen, die mit anderen µCs kommunizieren wollen. Sei es über Funk,
über USB oder wenns nur für Firmware-Updates ist.
AES ist einfach so wichtig wie DMA. Braucht man nicht immer, aber wenn,
dann ist es ungemein praktisch, sowas zu haben.
selm schrieb:> FP war nur 1K groß
Beim C51 und beim AVR-GCC auch. Aber sprintf/sscanf mit FP-Support
kostet nochmal extra.
selm schrieb:> Die ersten AVR-Compiler haben bei einer ISR zum Beispiel alle Register> auf den Stack geschoben, was recht verschwenderisch war.
Welcher soll das sein?
Der AVR-GCC sichert entweder die verwendeten oder bei einem externen
Funktionsaufruf nur die zerstörbaren Register, sowie R0,R1.
selm schrieb:> Keil hat> einfach einen anderen Registersatz aktiviert, usw.
Nur, wenn man es extra so definiert. Es muß aber nicht unbedingt
besseren Code ergeben, daher habe ich es nie verwendet.
Jan schrieb:> braucht es auch kein AES. Ich meinte aber über die anderen Millionen> Anwendungen, die mit anderen µCs kommunizieren wollen. Sei es über Funk,> über USB oder wenns nur für Firmware-Updates ist.
Nun lass mal die Kirche im Dorf.
Das ist doch Unfug.
> AES ist einfach so wichtig wie DMA.
Genau. Für die vielen Anwendungen denen ein AVR ausreicht gleichermaßen
unwichtig.
AES kann aber auch selber nach guten Unterlagen leicht schreiben und
lässt sich in ein paar kB an FLASH erledigen. In einem DSPIC B.L.
Programm mit AES schaffte der uC immerhin an die 33kB/s Durchsatz. Damit
kann man oft leben. Bei einem PIC18F8722 schaffte der immerhin auch noch
um die 5kB/s. Also, wenn AES nicht in HW existiert, ist Selbsthilfe
immer noch eine Möglichkeit. Und wer wirklich einen uC mit eingebauten
AES braucht, muß halt nach solchen Ausschau halten.
Nachtrag: Ich hätte lieber HW CRC16 auf meiner Wunschliste
Ich hatte noch nie den Fall, dass eine Mikrocontrolleranwendung explizit
einen 8-(oder 4-, 16- oder 32-)Bit-Controller oder sogar konkret einen
AVR gefordert hätte.
Typische Anforderungen fallen vielmehr unter die folgenden Kriterien:
- Rechenleistung
- Baugröße
- Preis
- Stromverbrauch
- integrierter Speicher (Flash, RAM)
- integrierte Peripherie
- je nach Anwendung auch noch ein paar mehr
Die Controllerfamilie (AVR, MSP430, STM32 usw.) ist für mich höchstens
insofern von Bedeutung, dass, wenn ich unter Zeitdruck stehe, lieber
einen Controller verwende, mit dem (und dessen Entwicklungsumgebung) ich
bereits Erfahrungen gesammelt habe.
Deswegen würde ich die Frage umformulieren und aufteilen in:
- Wann gibt's mal wieder neue µC mit mehr Rechenleistung?
- Wann gibt's mal wieder neue µC mit mit weniger Stromverbrauch?
- Wann gibt's mal wieder neue µC mit mit mehr Speicher?
- usw.
Bzgl. ALU- und Bus-Bitbreite und Hardwareeinheiten für Multiplikation
und/oder Division, FP-Arithmetik, AES usw. habe ich keine Anforderungen.
Wenn der Controller die gestellte Aufgabe mit der geforderten
Geschwindigkeit ausführt, spielt es für mich keine Rolle, ob er dies mit
einer ausreichend hochgetakteten 4-Bit-CPU, einer 32-Bit-CPU oder mit
zusätzlichen Hardwarebeschleunigern erreicht.
Ich habe in der Vergangenheit viele Dinge mit AVRs realisiert und
verwende sie auch heute noch gerne. Der Hauptgrund, der mich damals zum
Einstieg in die AVR-Familie bewegt hat, war die Kombination aus billig,
klein, Flash-programmierbar, relativ viel RAM und frei verfügbarer
Open-Source-Toolchain. Diese Kriterien erfüllen mittlerweile aber auch
mehrere andere Controllerfamilien, so dass ich die AVRs zwar noch nutze,
aber nicht mehr an ihnen "klebe".
Yalu X. schrieb:> aber nicht mehr an ihnen "klebe".
Zur "Klebstärke" trägt aber auch maßgeblich mangelnde Erfahrung +
Qualifizierung des Entwicklers bei. Beide entscheiden die Flexibilität
bei der Auswahl maßgeblich. Gerade wenn letztere arg beschränkt ist.
Also gerade die größeren AVRs haben recht viel RAM, z.B. 16kB beim
ATMega1284. Ich hatte eigentlich noch nie das Problem, wirklich zu wenig
RAM zu haben.
Genau das Gleiche mit der Rechenleistung. Wenn man die AVRs in Assembler
programmiert, werden sehr viele Instruktionen in nur einem Takt
ausgeführt. Bei 20 MHz erreichen die Dinger bis zu 20 MIPS. Zum
Vergleich, der C64 erreicht 0,02, der Z80 mit 2,5Mhz erreicht 0,625, der
Motorola 68000 mit 8 Mhz schafft 1 MIPS, ein Intel 486DX2-66 kommt auf
54 MIPS. Wenn man das runterrechnet hat man ungefähr die Rechenleistung
eines 486ers mit 25 MHz und das ist schon gar nicht so wenig.
Wo ich schon eher an die Grenzen gelaufen bin ist halt die Konnektivität
zu USB oder LAN und die großen bastelfreundlichen AVRs haben meistens
auch keinen schnell laufenden Timer mit PLL, so daß sie bei PWM mit
hoher Frequenz oder Gegentakt-Konfiguration mit 20..40kHz keine hohe
Auflösung mehr erreichen.
Gibts für den ARM-Cortex M3 eigentlich 'ne gute Toolchain und
Programmer, was für den Bastler kostenlos verfügbar ist und nicht
künstlich beschnitten würde um möglichst viel Geld herauszuquetschen?
Also ich meine ohne Limitierung auf ein paar kB Flash oder x Zeilen
Quellcode... Welcher Compiler wird da meistens verwendet, werde wohl
nicht drum herum kommen, dafür irgendwann C zu lernen.
Ben B. schrieb:> Gibts für den ARM-Cortex M3 eigentlich 'ne gute Toolchain und> Programmer, was für den Bastler kostenlos verfügbar ist
Ja klar gibt's dafür auch einen GCC, eventuell auch schon einen Clang
(weiß ich jetzt nicht ganz genau). Übrigens für alle Cortexe, also M0
bis M7. Programmierung und GDB-Server via OpenOCD.
LordAda schrieb:> Ein 32Biter benötigt nicht viel mehr Platz als ein 8Bitter. Eine> Ausgangsstufe für einen 40mA IO ist oft viel größer
Größer als der reine CPU-Kern vielleicht, aber dann nicht eine sondern
alle Ausgangsstufen. Einen maßgeblichen Flächenanteil nehmen aber RAM
und Flash ein. Ansonsten ist der größere Chipflächenverbrauch eines AVR
eher eine Frage der viel gröberen Technologie (darum sind die "A"
devices ja auch billiger, denn es sind "die shrinks"). Auf der
Gegenseite hat man mit kleinen Technologien halt üblicherweise viel
stärker limitierte Betriebsspannungen (wenngleich es inzwischen auch
ausreichend Cortex-M mit 5 V gibt) und vor allem höhere Leckströme. Ein
AVR ohne Takt braucht ja praktisch gar nichts.
8 Bits are Forever schrieb:> Der AVR128DB64> packt ganz schön viel ein und hat eine schnelle UPDI Debug> Schnittstelle.
Gibt es von anderen Herstelleren auch µC mit integriertem OpAmp?
Ben B. schrieb:> Also gerade die größeren AVRs haben recht viel RAM, z.B. 16kB beim> ATMega1284. Ich hatte eigentlich noch nie das Problem, wirklich zu wenig> RAM zu haben.
Die Lösung für zuviel RAM heißt MicroPython ... wenn LED blinken MB an
RAM braucht.
Ben B. schrieb:> Gibts für den ARM-Cortex M3 eigentlich 'ne gute Toolchain und> Programmer, was für den Bastler kostenlos verfügbar ist und nicht> künstlich beschnitten würde um möglichst viel Geld herauszuquetschen?
STM Cube oder so jedoch viel Spaß einen STM32 aktuell aufzutreiben.
Ben B. schrieb:> ARM-Cortex M3 … Programmer
Ganz vergessen: als Programmer taugt dort jeder MPSSE-fähige FTDI. Die
sind zwar als nackte Chips auch gerade Mangelware, aber Demo- und
Breakout-Boards damit bekommt man noch.
Ansonsten, wer schon ein AtmelICE vom AVR hat, kann selbiges mit OpenOCD
beliebig für Cortex-M (auch anderer Hersteller) benutzen.
Ben B. schrieb:> Also gerade die größeren AVRs haben recht viel RAM, z.B. 16kB> beim ATMega1284. Ich hatte eigentlich noch nie das Problem,> wirklich zu wenig RAM zu haben.
Ich war dagegen schon mehrfach traurig, nicht genug RAM zur Verfügung zu
haben. Ein AVR mit 64 KB RAM wäre für einige Retro-Projekte (z.B.
Videosignal mit höherer Auflösung, CP/M) sehr angenehm.
Klar kann man einen 32-Bitter nehmen, aber dann muss man ja nicht mehr
nachdenken. Es gibt zum Beispiel coole Projekte, einen Raspberry Pi als
Amiga-Beschleuniger zu benutzen... aber dann kann man eigentlich auch
den Amiga weglassen.
> Wenn man das runterrechnet hat man ungefähr die Rechenleistung> eines 486ers mit 25 MHz und das ist schon gar nicht so wenig.
Ein AVR-MIPS schafft aber deutlich weniger als ein i486-MIPS.
Ben B. schrieb:> Gibts für den ARM-Cortex M3 eigentlich 'ne gute Toolchain und> Programmer, was für den Bastler kostenlos verfügbar ist und nicht> künstlich beschnitten würde um möglichst viel Geld herauszuquetschen?
Die STM32 Cube IDE kostet gar nichts. Sie basiert auf GCC, hat keine
Einschränkungen. ST-Link Adapter bekommst du zusammen mit Evaluation
Board (ohne Gehäuse) ab 15 Euro. Man kann sie auch ohne das Evaluation
Board nutzen.
Bei Aliexpress bekommst du ST-Link Klone ab 3 Euro.
Ben B. schrieb:> Wenn man die AVRs in Assembler> programmiert, werden sehr viele Instruktionen in nur einem Takt> ausgeführt.
Auch wenn man sie in C programmiert. Die Ausführungszeit einer
Instruktion verändert sich nicht.
> Bei 20 MHz erreichen die Dinger bis zu 20 MIPS. Zum Vergleich,> der C64 erreicht 0,02
Der C64 läuft mit knapp 1MHz, die durchschnittliche Ausführungzeit einer
Instruktion liegt bei 3 Takten. Rechnen kannst du selber.
Ja, ich habe auch gesehen, daß das auf Wikipedia steht. Da wird aber ein
ausgewachsenes Benchmark-Programm zitiert. Das wird für den AVR auch ein
viel spärlicheres Ergebnis liefern als deine 20 MIPS. Insofern
vergleichst du Äpfel mit Birnen.
> Ich war dagegen schon mehrfach traurig, nicht genug RAM zur> Verfügung zu haben. Ein AVR mit 64 KB RAM wäre für einige> Retro-Projekte (z.B. Videosignal mit höherer Auflösung, CP/M)> sehr angenehm.
Gut, für solche Spezialfälle hast Du Recht, für hohe Auflösung bei
solchen Dingen ist der AVR nicht gemacht. Da hatten ja viele
Computersysteme ihre Probleme mit, der C64 hat da auch recht viel mit
seinen Grafikmodi getrickst was Pixel-Stretching oder die
Farbzellen-Limitierung bei den HiRes- oder MultiColor-Modi angeht. Der
konnte 16kB RAM für die Pixeldaten verwenden, aber nur 1kB für die
Farbinformation, glaube sogar nur 4kBit wenn ich mich recht erinnere.
> Ein AVR-MIPS schafft aber deutlich weniger als ein i486-MIPS.
Das ist anwendungsspezifisch oder eine Frage, wie man es misst. Wenn man
beim AVR z.B. alle seine Register mit festen Werten lädt, lutscht der
das mit vollen 20 MIPS durch. Im praktischen Programm wird er seine
theoretische Leistung natürlich nicht konstant erreichen, weil immer mal
ein paar Instruktionen mit mehreren Takten dabei sind, aber das Problem
hat der 486er auch. Vor allem wenn er Dinge aus dem RAM nachladen muß
oder seine Pipeline verwerfen muß. Darunter leiden alle CISC-Systeme
mehr oder weniger stark, der AVR als RISC-Prozessor hat da weniger
Probleme mit.
Wegen meiner ARM-Cortex-Ansätze... Ich überlege halt immer wieder mal,
mich in diese 32Bitter einzuarbeiten, für die Fälle wo die AVRs nicht
reichen oder nicht mehr sinnvoll sind. Mir wurde der M3 als Einstieg
empfohlen, die sollen ja alle so ihre Stolpersteine haben, die
ARM-Einsteiger Probleme bereiten. Daß man die Dinger im Moment nicht
bekommt ... schade, aber kann ich nichts dran ändern. Ich würde auch
gerne einen besseren Programmer haben, bei der steigenden Komplexität
der Architektur und der Programme wäre ein on-Chip-Debugging sehr
sinnvoll. Vielleicht sollte ich mir mal ein "Einsteiger-Set"
zusammenstellen lassen und/oder sowas von jemandem hier im Forum kaufen,
der evtl. einen passenden Programmer abgeben möchte oder so.
Wegen den Gehäuseformen... ich bastle sehr gerne Prototypen auf
Lochraster und bin da auch recht fit drin, daher sind ICs im DIP-Gehäuse
gerne gesehen. Natürlich kann man SMD-ICs mit Adapterplatinen "passend"
machen, bzw. es gibt eine Grenze wo die ICs für Lochraster einfach
zuviele Pins bekommen... sieht aber meiner Meinung immer nicht so toll
aus. Klar, der Trend geht immer mehr zu SMD bzw. die Fertigung eigener
Platinen. Ich habe da auch schon gute Versuche unternommen, aber
Lochrasteraufbauten bleiben trotzdem beliebt. Man braucht halt nicht
erst CAD-Layout entwerfen, den Laser anschmeißen um das Layout auf die
Platine zu brennen oder gar noch Toner-Transfer mit modernen
Spardruckern zu probieren (das hat mit keinem meiner Drucker in den
letzten 20 Jahren gut funktioniert), kein Rumplantschen mit Ätzlösung.
Sondern man kann sich ein Stück Platine schnappen, Lötkolben heiß,
Lötzinn, Silberdraht und schon kann's losgehen. Man kann so viele
Bauteile von alten Platinen schlachten und sie kostenlos recyclen... bei
SMD geht das alles nicht bzw. nicht sinnvoll wenns keine ICs oder
besonderen Bauteile sind, vieles bekommt man gar nicht so leicht
unbeschadet abgelötet.
Ben B. schrieb:> kein Rumplantschen mit Ätzlösung.
Mache ich auch nur noch, wenn ich "same day delivery" brauche.
Ansonsten gibt's doch genügend Varianten mittlerweile, erschwinglich
fertige Platinen zu bestellen.
> Man kann so viele> Bauteile von alten Platinen schlachten und sie kostenlos recyclen.
Bei interessantem Kram mache ich das auch bei SMD, aber für Hühnerfutter
macht sich wohl keiner mehr die Mühe.
Lochraster mochte ich irgendwie nie. Weiß auch nicht, warum.
Patrick L. schrieb:> Wobei ich gerne Normale Lochraster verwende und einfach die >Lötaugen> "Halbiere" (Siehe Bild)
EINFACH? Mit welchem Werkzeug halbierst du denn die Leiterbahn?
Ob Lochraster oder nicht, oder ganz gleich wie man seine "Real World"
Beschaltung macht, haben kleine uC Module aller Art große praktische
Vorteile. Die kleinen Module wie ESP32/8266, NANO, Pro-Mini, die
Teensies und was es sonst noch alles gibt, erlauben ein weites Spektrum
an zeitgemässen Anwendungen.
Da finde ich es also gut, daß es so eine große Auswahl gibt. Man kommt
bei Einzelstücken und Laboreintagsfliegen sehr schnell, billig und
effizient zum Ziel etwas auf die Beine zu stellen. Was mich betrifft bin
ich "Happy" mit diesem Trend der schon vor vielen Jahren begonnen hat.
Da gilt wirklich "Jedes Tierchen sein Pläsierchen".
Ein großer Grund, weil 8-Bitter zum Teil weg gedrängt werden ist der
Trend, Geräte aller Art verbindbar zu machen, weil es zur Zeit Mode ist,
alles mit dem Handie bedienen zu wollen und um (ungewollt) Hackern Tür
und Tor nebst Haus zu öffnen:-) solange wir "Connectivity" von unseren
Gadgets erwarten, ist natürlich entsprechend fähige uC HW gefragt. Da
muß sich der bescheidene 8-bitter mit immer weniger Rampenlicht begnügen
da die ESPs der Welt ihn von der Bühne mehr und mehr verdrängen
(wollen?).
Was mich betrifft, der wenig Interesse an Stack "Connectivity" hat,
finde ich immer noch viele Anwendungsmöglichkeiten für meine PICs, AVRs
und was sonst noch rumfleucht. Die modernen uC sind im Vergleich zu
1980er HW wesentlich performanter und ich habe noch nie "Show Stoppers"
erleben müssen. Die Reale Welt funktioniert immer noch weitgehend im
ms-s Takt und nicht immer immer im ns Takt. Die High-Tech Gadgets der
Amazonen, Google und Apple sind nicht repräsentativ für die
verbleibenden Milliarden an einfacheren täglich gebrauchten
Gerätschaften wie man sie immer noch in der täglichen Welt findet.
Die Vernetzung und Verbundenheit von alles kann seine eigenen Risiken
beherbergen da immer mehr Wölfe im Schafspelz die vernetzte Umwelt
unsicherer machen, wie man immer wieder leider feststellen muß.
Anstatt daß sich uC nur auf die HW konzentriert, müssen heutzutage oft
komplexe Kommunikation Stacks unterstützt werden, die leistungsfähigere
uC voraussetzen und oft empfindliche Sicherheitsschwächen aufweisen.
Es ist die "verbundene" Infrastruktur die die Ansprüche so hochtreibt,
daß vieles nur noch verbunden und mit Unterstützung aus der Wolke
funktioniert. Ich ziehe aber unabhängige Technik in meinen Leben vor,
wenn es wichtig für much ist. Und das, wiederum öffnet Türen für
bescheidener uC Plattformen.
Die Bottom Line ist, daß unsere Digitaltechnik jetzt einer Caesur
zugrunde liegt, die das "Wie" fundamental ändert. Was mich betrifft,
kann ein "Zuviel" davon, auch nicht unbedingt von wirklichen Nutzen
sein. Es fragt sich ob man sich nutzbringend unnötig mit Gadgets
zumüllen soll.
So ziemlich jede Reklame für neuzeitliche Produkte trompetet im
Vordergrund die Connectivity. Man hat offensichtlich das (kommerzielle)
Interesse diesen Modus Operandi zu fördern und durchzusetzen. 5G kommt
nicht von ungefähr und man hat sehr genaue Vorstellungen davon was man
damit machen will. Daß wir dabei immer gläserner werden, geht in dem
ganzen Trubel leicht verloren. Die Menschheit lädt sich ironischerweise
ihre Aufseher freiwillig und kostenfrei für die Aufseher ein. Die
Aufseher der Vergangenheit wären jetzt bestimmt neidisch. Früher mußte
man mit großen Kostenaufwand and Technik, Personal operieren, heutzutage
tun es ihre Subjekte von Interesse selber. Was könnte schöner sein auf
Erden als Informationsagentur zu werden...
So much for microcontroller philosophy...
Gerhard O. schrieb:> Ein großer Grund, weil 8-Bitter zum Teil weg gedrängt werden ist der> Trend, Geräte aller Art verbindbar zu machen, weil es zur Zeit Mode ist,> alles mit dem Handie bedienen zu wollen und um (ungewollt) Hackern Tür> und Tor nebst Haus zu öffnen:-)
Genau. Die Vollidioten WOLLEN gehackt werden, bzw. mehmen das
zumindest billigend in Kauf. Ist halt so...
Aber das ist ja nur die halbe Wahrheit. Die kleinen 8Bitter können die
"Sicherheit" tatsächlich aus Gründen von Rechenzeit und Speicherplatz
nicht leisten.
Aber die Verwendung eines µC, der hinreichende Resourcen bietet und auf
dem sich deshalb die entsprechenden Protokolle real umsetzen lassen, ist
natürlich nicht die Lösung. Denn die Resourcen sind nicht das einzige
Problem, die Implementierungen der Protokolle sind das andere. Und jede
Erfahrung lehrt: der OpenSource-Gammel ist hochgradig mit
Sicherheitslücken durchseucht (allerdings ist es beim CS-Bereich kaum
anders, nur haben die Bastler darauf halt keinen Zugriff).
Das Problem ist also im Kern C/C++. Diese Sprachen sind die, in denen
die relevanten Komponenten programmiert sind. Und diese Sprachen sind
halt per Design INHÄRENT UNSICHER, wodurch eben diese
Sicherheitslücken oft entstehen, wenn auch nicht immer. Manche Lücke hat
mit der Sprache rein garnichts zu tun. Die allermeisten aber schon...
c-hater schrieb:> Das Problem ist also im Kern C/C++
Also? Du tust so als hättest du in dem Absatz darüber erklärt, warum
C/C++ der Kern des Problems sei, doch das hast du nicht getan. Auch
nicht darunter. Aber mache dir keine Mühe, dein sinnloses Bashing wird
durch ständige Wiederholung nicht besser.
c-hater schrieb:> diese Sprachen sind halt per Design INHÄRENT UNSICHER
Damit deine Welt besser ist, programmierst du in Assembler. Tsss
Keine Programmiersprache wird und von Sicherheitslücken befreien.
Stefan ⛄ F. schrieb:> Also? Du tust so als hättest du in dem Absatz darüber erklärt, warum> C/C++ der Kern des Problems sei, doch das hast du nicht getan.
Doch, weil halt die relevanten Teile in eben diesen Sprachen
programmiert wurden. Zu hoch für dich, die Kausalität zu erkennen?
> Damit deine Welt besser ist, programmierst du in Assembler.
Nicht sowas, nein. Aber auch nicht in C oder C++, denn das ist kaum
sicherer als Asm. Genau das ist, was diese Flitzpipen von
C/C++-Apologeten nie kapieren (oder zumindest nicht zugeben wollen)...
Ben B. schrieb:> Wegen meiner ARM-Cortex-Ansätze... Ich überlege halt immer wieder mal,> mich in diese 32Bitter einzuarbeiten, für die Fälle wo die AVRs nicht> reichen oder nicht mehr sinnvoll sind.
Ich hatte ja hier
Beitrag "Re: Wann gibts mal wieder neue gute AVR 8-Bitter?"PIC32MX als mögliche Alternative genannt. Gut, das ist MIPS und nicht
ARM, aber das ist wie Coke vs. Pepsi - von der Leistungsfähigkeit in
ähnlichen Größenordnungen. Und ganz real als SDIP kaufbar. Komplett
debugbar mit PICKIT3 ohne Verfusing-Gefahr oder so.
Normal nimmt man C für sowas, aber MIPS-Assember wurde früher oft in
Uni-Lehrveranstaltungen gelehrt, weil diese Architektur relativ typisch
für den RISC-Ansatz ist.
https://minnie.tuhs.org/CompArch/Resources/mips_quick_tutorial.htmlhttp://www.inf.fu-berlin.de/lehre/SS00/19502-V/spimdoku.pdf
Die Hürde für den Einstieg liegt bei 20€ für einen PicKIT3-Clone und
3-5€ für den Chip. Den Rest gibts bei Microchip zum kostenlosen
Download.
fchk
