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.
Beitrag #6958049 wurde von einem Moderator gelöscht.
> 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.
Die neuen DX AVRs sind ja auch nicht ganz uninteressant. Der AVR128DB64 packt ganz schön viel ein und hat eine schnelle UPDI Debug Schnittstelle.
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.
Der Titel vom Thread sollte doch lauten : "Wann gibts mal wieder AVR 8-Bitter?" (Zu kaufen) Dieses Jahr scheint da nämlich Ebbe zu sein..
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.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Laut Meinung des TE nicht, denn der hat ja auch kein AES. Ok, dann muss ich das wohl akzeptieren. Wofür brauche ich AES?
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.
Servus, also ich hab Neuigkeiten! Also ab Montag den 31.01 sollen die neuen 8Bitter kommen. Aber nicht von Atmel sondern von Microchip!
Michael Linz schrieb: > Aber nicht von Atmel sondern von Microchip! Das sind die diversen AVR-Dx aber auch alle schon …
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.
Microchip wartet gerade bestimmt Sehnsüchtig auf Ideen der Bastler um deren Chips in DIP zu fertigen. Die Fabs haben ja gerade nichts anderes zu tun.
Angehängte Dateien:
-
ID_163663_orig.jpg
160 KB
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.
Ben B. schrieb: > 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. Bei USB gibts PIC24, dsPIC33 und PIC32 in SDIP28. https://www.microchip.com/en-us/product/PIC32MX270F256B FS Host, Device und OTG. 50 MHz, 256k Flash, 64k RAM. Alles da. Kaufbar. https://www.mouser.de/ProductDetail/Microchip-Technology/PIC32MX270F256B-50I-SP?qs=sGAEpiMZZMtXHE36kCvv31%2FWuqN0rWph4vqIXdTjnZw%3D Leute ohne Scheuklappen haben keine Probleme, was passendes zu finden. fchk
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.
MaWin schrieb: > Heute ist alles nichts, was nicht smart IoT ist. ohje, eine neue Querdenkermutation.
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.
Man könnte auch die zu langen Leiterbahnen mit Kapton abkleben. Oder mit einem dicken Edding eine Linie quer drüber malen, Lötstopmaske für Arme ;-)
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.
Angehängte Dateien:
-
20180812_Prozessor.jpg
130 KB
[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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
Man bezahlt Chipfläche. Ein 32Biter benötigt nicht viel mehr Platz als ein 8Bitter. Eine Ausgangsstufe für einen 40mA IO ist oft viel größer
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.
Angehängte Dateien:
-
Bild_2022-01-31_141252.png
190 KB
Jörg W. schrieb: > 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. Es gibt auch "Lochraster" speziell für SMD Beispiel1: https://www.komputer.de/wordpress/archives/861 Beispiel2: https://www.henri.de/bauelemente/bauelemente-mechanische/platinen/lochrasterplatinen/14586/smd-platine-lochraster-100x160mm-fuer-smd-bauteile-epoxyd-euronorm-europaformat.html Wobei ich gerne Normale Lochraster verwende und einfach die >Lötaugen "Halbiere" (Siehe Bild)
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?
Michael M. schrieb: > 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? Skalpell ;-) Wenn es scharf genug ist, reicht es das Skalpell gut Aufzudrücken, dann den 2ten Schnitt ebenfalls Aufdrücken und Kippen. Das so quasi ausgestanzte Leiterbahn Stück springt dann weg ohne großes "herumtun" Auf die Weise kann ich bis zu 3 Pins auf eine Leiterbahn bringen. Alternativ geht auch das: https://www.pjaonemus.com/index.php?main_page=product_info&products_id=624493 Oder aus dem Forum hier: Beitrag "Verbesserte Lochraster-Platinen für direktes Auflöten von SOIC-Bauteilen"
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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.html http://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
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.