Nachdem lange über "das Ende" der 8 Bit Microcontroller sinniert wurde, ist es dieses Jahr anscheinend wirklich soweit, dass mehrere Firmen gezielt neue Microcontroller auf den Markt bringen, um 8 Bitter (und 16 bitter) zu vedrängen.
Von asiatischen Firmen waren schon länger CM0 Controller im STM8S003 Footprint verfügbar, z.B. von Nuvoton. Der Trend hat sich über die Zeit verstärkt.
Neu ist, das STM, TI und auch NXP neuerdings für direkten Ersatz ihrer alten Familien mit 32 bit controllern werben und dafür neue Low-Cost Familien vorgestellt haben.
Zwar nicht besonders billig, aber ich empfinde die STM32L0 Serie
als den
nächsten logischen Schritt nach 8 Bit Mikrocontrollern.
Hab die STM32L011 auch schon hier und da im Einsatz. Zuletzt als Ersatz für einen ATTiny84 weil ich das Plus an Rechenleistung gebraucht hatte (kleine DSP Anwendung).
Schade finde ich es nur, dass es kein SO14 oder so gibt. TSSOP20 ist halt schon fast wieder unangenehm zu bestücken.
Packages der ATTtinys mit 32Bit Performance (gerne auch Risc-V!) wäre toll.
Schade finde ich es nur, dass es kein SO14 oder so gibt.
PIC32MM064GPL028: 28 Pins, wahlweise als DIL (2.54mm), SOIC (1.27mm), SSOP (0.65mm), QFN (0.65mm) und als Krönung UQFN mit 0.4mm, also doppelt so viele Pins wie SO14 auf einem Viertel der Fläche.
Ideal zum sanften Wechsel, auch, weil er nur 8K RAM, kein DMA und keine I2C-Hardware hat. Aber 32 Bit ;)
PIC hab ich eh immer gehasst ... Damals als ich schon gut Erfahrungen mit AVRs und deren Luxus gesammelt hatte, musste ich auf einen PIC16F84 zurücksteigen 🤢
(Ich bin quasi nicht alt genug, um die PICs liebengelernt zu haben^^)
Lustigerweise fing dann die IHK an, den PIC in den Lehrplan aufzunehmen ... Also als er schon total veraltet war 😂
Hinsichlich Low- und unzerverlässiger Power kann man sich die mit nichtflüchtigen FRAM Speicher arbeitenden MSP430FR5969 anschauen.
Jaja ist 16bit, aber irgendwo muß ja die Effizienz herkommen und ein Linux/Windows fähiger 32++ bit Prozessor ist per se ineffizient.
Deshalb setzt ja beispielsweise Medizintechnik auf die gut bekannten Controller aus dem letzten Jahrtausend, die eben ohne SchnickSchnackBug laufen ohne Ende.
Lustigerweise fing dann die IHK an, den PIC in den Lehrplan aufzunehmen
... Also als er schon total veraltet war 😂
Im Lehrplan war der PIC Controller nie. Er wurde bei den praktischen Prüfungen als fertig programmierter Chip verwendet und kein Prüfunbgsteilnehmer wußte wirklich (obwohl der Code offen gelegt war) was das Teil macht. Er wurde einfach nur verbaut.
Zudem war im Anzeigeeinschub der Prüfungen ein PIC verbaut.
Heute setzt die Abschlußprüfung Teil 1 (nach 1,5 Jahren Ausbildung) tatsächlich auf einen Arduino Uno. Aber auch hier wird nur mit einem fertig programmierten Arduino gearbeitet. Während der Ausbildung selbst wird an manchen Berufsschulen für den Berufszweig EGS mit Arduino Uno gearbeitet.
Während der Ausbildung zum Physiklaboranten kommen Auszubildende in der Berufsschule zunehmend auch mit Arduino in Kontakt, hier heißt die Hardware "SenseBox" und arbeitet mit einem Atmel SAMD21 Derivat, so dass das Teil wie ein Arduino Zero programmiert werden kann. Schwerpunkt hier ist ganz klar das Auslesen diverser Sensoren mittels I2C. Hier dürfte jedoch die IHK nicht federführend gewesen sein.
Im Lehrplan war der PIC Controller nie. Er wurde bei den praktischen
Prüfungen als fertig programmierter Chip verwendet und kein
Prüfunbgsteilnehmer wußte wirklich (obwohl der Code offen gelegt war)
was das Teil macht. Er wurde einfach nur verbaut.
Vielen Dank für die Korrektur!
Ich konnte mich nur daran erinnern, das ein damaliger Ausbilder diesbezüglich über die IHK geschimpft hat und die Lehrwerkstatt mit AVRs eigentlich schon viel weiter war und sie sich dann in PICs einarbeiten mussten - oder eher einarbeiten werden müssen ...
Ich hab aber nie geprüft, ob das dann auch wirklich so gekommen ist.
Zu meiner Ausbildungs-Zeit waren Z80 und 8031 mit Eproms angesagt. Danach habe ich mich sehr über µC mit integriertem Flash gefreut. Das war damals für mich ein gewaltiger Sprung nach vorne. Danach die Möglichkeit, (ohne Simulator) zu Debuggen.
32 Bit löst bei mir wesentlich weniger Begeisterung aus. Ist halt da, kann man nehmen.
Zu meiner Ausbildungs-Zeit waren Z80 und 8031 mit Eproms angesagt.
Das war auch mein erster Mikrocontroller 🥰
Danach habe ich mich sehr über µC mit integriertem Flash gefreut. Das
war damals für mich ein gewaltiger Sprung nach vorne.
AT89S51 🤤
Danach die Möglichkeit, (ohne Simulator) zu Debuggen.
Jau, bis auf die AVRs. Hab ich nie verstanden, wieso das immer proprietär geblieben ist. OpenOCD scheint AVRs zu kennen aber nur "preliminary and incomplete".
Einer der Gründe, wieso ich dazu tendiere, Cortex M0 zu benutzen, wenn ich AVRs benutzen könnte. Auf Debugging möchte ich nicht mehr verzichte.
32 Bit löst bei mir wesentlich weniger Begeisterung aus. Ist halt da,
kann man nehmen.
Ist halt nur eine konsequente Weiterentwicklung und keine echte Neuerung wie damals.
Ist halt nur eine konsequente Weiterentwicklung und keine echte Neuerung
wie damals.
Na ja. Die FPU eines Cortex M4F ist schon eine Neuerung (für mich). Berechne mal ein Apfelmännchen auf einem STM32F103 und dann auf einem STM32F4xx.
Die Unterschiede sind gewaltig.
Für das Handling der Chips gebe ich dir allerdings Recht. In Circuit Programmierung (über Adapter oder Bootloader) mit und ohne Debugmöglichkeit war hier wohl die letzte große Neuerung und die gibt es wohl mit dem 89S51 und der PIC-Serie seit Jahrzehnten.
Eine wirkliche "Neuerung" hier dürfte schlicht der Preis sein. Heute sind selbst "teure" Entwicklungstools und Programmer preislich für jeden Hobbiesten erschwinglich. Während meiner Ausbildung waren die mit mehren tausend D-Mark schier unerschwinglich und nicht wenige haben sich - am Beispiel eines 80C31 - mit einem Monitorprogramm im Controller begnügt, der ein Programm im RAM abgelegt hat und dort wurde dann das Programm ausgeführt. Für den Bau eines Gerätes wurde dann die Startadresse und die Referenzen des Programms geändert und ein EPROM gebrannt. Lange ist es her und gut, dass diese Zeiten vorbei sind.
Eine wirkliche "Neuerung" hier dürfte schlicht der Preis sein. Heute
sind selbst "teure" Entwicklungstools und Programmer preislich für jeden
Hobbiesten erschwinglich. Während meiner Ausbildung waren die mit mehren
tausend D-Mark schier unerschwinglich
Das ist aber lange her, selbst zu "D-Mark-Zeiten". Die D-Mark war erst 1.1.2002 Geschichte, aber ich meine das ich bereits 1996 mit kostenlosen Assembler für PIC und später AVR unterwegs war.
Das die Entwicklungstool (sofern man diese legal und nicht als "Raubkopie" nutzen wollte) ein Heidengeld kosteten betraf aber nicht nur die assembler/Compiler für Mikro-Controller, auch PC-Compiler waren teuer, und deren Hardwareansprüche waren auch nicht ohne. Ja, man konnte sich mit Compiler auf Diskette durch die Lernphase quälen, aber eigentlich brauchte man für sowas eine Festplatte, die dann auch mal 800-1000 DM kostete.
Der Gnu-Kram kam meines Wissens ca 1996 (CygWin) "in die Arena" und dessen Bedienung war auf dem PC auch nicht ohne, so dass man sich dann wie davor doch mit den erwähnten "Kopien unter Freunden" oder PC-Pool an der Bildungseinrichtung behalf.
am
Beispiel eines 80C31 - mit einem Monitorprogramm im Controller begnügt,
der ein Programm im RAM abgelegt hat und dort wurde dann das Programm
ausgeführt.
Ich hatte mich damals mit einem RAM wie 62256 beholfen, das ich über den Parallel-Port quasi "programmieren" konnte. Anschließend konnte man quasi umschalten (mit ein paar 245er) und der 8031er hat es dann als Programmspeicher benutzt.
Na ja. Die FPU eines Cortex M4F ist schon eine Neuerung (für mich).
Berechne mal ein Apfelmännchen auf einem STM32F103 und dann auf einem
STM32F4xx.
Die FPU im M4 ist schon sehr praktisch, insbesondere für digitale Signalverarbeitung. Kann man sich sparen mit Fix-Punkt zu jonglieren und einfach stur floats nehmen.
Ok zugegeben, ich kann mich erinnern, wie überrascht ich war, als ich die FPU fand 🙈
Ok zugegeben, ich kann mich erinnern, wie überrascht ich war, als ich
die FPU fand 🙈
und ich war enttäuscht die in meinem damaligen Liebling LPC1769 nicht zu finden. Alles drin mit Ethernet, USB, viel Speicher und 120 MHz, aber NXP hatte für das Paradepferd 'nur' einen M3 Core spendiert.
Aber der war damit auch eher high end als low cost.
Die L0 oder C0 werden sicher für kleine Anwendungen als 8 Bit Ersatz interessant sein, die Großkunden bekommen ja bessere Preise als so normal auf den Websites der Distributoren angezeigt wird. Und das man dann die gleichen Entwicklungswerkzeuge von C0 bis H7 verwenden kann, das dürfte für die Entwickler auch ein Argument sein.
dann die gleichen Entwicklungswerkzeuge von C0 bis H7 verwenden kann,
das dürfte für die Entwickler auch ein Argument sein.
Das war für uns ein wichtiger Grund, in die STM-32-Bit-Familie zu wechseln.
Es hilft mir nichts, wenn ich immer den für den Anwendung optimalen Controller habe, aber mich in neue Controller und vor allem neue Werkzeuge einarbeiten müsste. Bei Großserien mag das sinnvoll sein, aber bei unseren Klein- und Mittelserien spielen die Entwicklungskosten eine große Rolle - dafür tritt der Controllerpreis in den Hintergrund, zumal die Elektronik eher "schmückendes Beiwerk" (preisbezogen) ist. Bei STM habe ich eine enorme und trotzdem fein abgestimmte Bandbreite an Leistungsstufen, aus denen ich auswählen kann.
Natürlich begibt man sich damit in eine Abhängigkeit. Allerdings sind unsere Lagerbestände an Controllern groß (mehrere Jahre - Chipkrise? Was ist das? ;-), so dass eine "Umentwicklung" bestehender Platinen Zeit hätte. Die Hardwareschnittstellen in der Software sind sauber gekapselt, so dass nur diese neu geschrieben werden müssten.
jetzt muss ich hier auch einmal eine absolut offene Frage stellen.
Irgendwie scheint sich das ja alles im Forum aufzuteilen in
8 Bit > AVR
32 Bit > STM
und noch etwas TI MSP430
was ich so mitbekommen habe.
Warum ist bei 32 Bit STM dominant und nicht die AVR SAM? Beide nutzen ARM Kerne. Was macht STM so beliebt? Was machen die besser bzw. anders?
Zusatzfrage.
Bei STM steht doch die komplette C++ STL zur Verfügung, richtig?
Steht die auch bei den AVR SAM Controller zur Verfügung?
Renesas spielt in dem Forum keine Rolle?
AVR SAM kamen deutlich später, da gab es die Bluepill Boards mit originalen STM32F103 schon lange für 2,50 €. Dazu die breite Unterstützung mit kostenloser Software. Am ehesten konnte da noch NXP mit den LPC mit den günstigen LPCXpresso Boards gegenhalten, aber die IDE hatte anfangs auch Limits was Codegröße in der kostenlosen Version anging. Das wurde zwar relativ schnell abgeschafft, aber da hatte STM schon Demoboards für 10 € oder die auf Messen auch kostenlos verteilt. Mit Speck fängt man Mäuse...
Und C++ incl. STL konnte man dank gcc auch früh auf den Cortex-M nutzen.
Warum ist bei 32 Bit STM dominant und nicht die AVR SAM? Beide nutzen
ARM Kerne. Was macht STM so beliebt? Was machen die besser bzw. anders?
Zusatzfrage.
Mmmhmmm gute Frage ... Ich kann mich erinnern, dass ich AT91SAM7S64 gerne benutzt hab. Das waren ARM7TDMI, wenn ich mich richtig erinnere 🤔
Die ersten STM32 hab ich mit dem F103 benutzt - damals hatte ich noch kein BluePill.
Glaub mein allererstes STM32 Projekt war ein MP3-Player mit STM32F429. Ich denke, Hauptgrund war die Möglichkeit externes SDRAM zu benutzen - da gab es glaub ich damals von Atmel nichts äquivalentes. Und weil ich dann CubeMX und die Toolchain schon kannte, bin ich dann für immer da hängen geblieben und hab die nächsten kleineren Projekte dann ebenfalls mit STM32 (F103) gebastelt.
Ich halte das für relativ witzlos, wenn man nur 6 Pins I/O hat.
Als standalone Controller wahrscheinlich zu wenig, für ein bisserl Sensorik (erweiterung, abgesetztes Modul) im controller-network könnte es reichen: 4 analog in (12 bit) und einmal I2C-slave raus.
Aber was will man mit 32 bit, wenn in der Gesamt-Applikation ein (dickerer) Master nötig ist.
Ich halte das für relativ witzlos, wenn man nur 6 Pins I/O hat.
Als standalone Controller wahrscheinlich zu wenig, für ein bisserl
Sensorik (erweiterung, abgesetztes Modul) im controller-network könnte
es reichen: 4 analog in (12 bit) und einmal I2C-slave raus.
Aber was will man mit 32 bit, wenn in der Gesamt-Applikation ein
(dickerer) Master nötig ist.
Mir würde ein Quadraturdekoder mit IIC-Schnittstelle einfallen. Vielleicht sogar noch mit analoger Interpolation, da kann man die Geschwindigkeit schon gut gebrauchen.
Es gibt ja auch eine 20-pol. Version, auf der man sein Programm entwickeln und anschließend abmagern kann. Es kann sich schon lohnen, auch wenn man nur 5% der Hardware verwendet.
Schnelle Timer und gutes Debugging, ein 8 Bitter kann das so nicht bieten.
Und wer weiss, was das Teil endgültig kostet, wenn es in Stückzahl verfügbar sein wird.
Ich halte das für relativ witzlos, wenn man nur 6 Pins I/O hat.
Als standalone Controller wahrscheinlich zu wenig, für ein bisserl
Sensorik (erweiterung, abgesetztes Modul) im controller-network könnte
es reichen: 4 analog in (12 bit) und einmal I2C-slave raus.
Aber was will man mit 32 bit, wenn in der Gesamt-Applikation ein
(dickerer) Master nötig ist.
Mir würde ein Quadraturdekoder mit IIC-Schnittstelle einfallen.
Vielleicht sogar noch mit analoger Interpolation, da kann man die
Geschwindigkeit schon gut gebrauchen.
Sososo, mehr digitale MIPS und MHz für "analoge Interpolation", als wenn die 12 bit nicht schon genug Rauschen enthalten.
auf der man sein Programm
entwickeln und anschließend abmagern kann. Es kann sich schon lohnen,
auch wenn man nur 5% der Hardware verwendet.
Ich hab noch nie Software gesehen, die abmagert, eher das Gegenteil: Da ein Exception handler mehr, dort eine neue Bibliothek und Statuslog-Meldungen kann man nicht genug haben, das Controlling verlangt mehr Statistik, der Verkauf will alles in kleine Lizenzpakete mit dicken Lizenzmanager zerhackt und verkauft sehen ...
Schnelle Timer und gutes Debugging, ein 8 Bitter kann das so nicht
bieten.
Mumpitz,
Wenn die Peripherals nicht leistungsfähig genug sind und die Taktfrequenz mau, dann liegt das nicht an der Registerbreite des Cores sondern an der benutzten Halbleitertechnologie. Und jeder der tatsächlich mit FPGAs gearbeitet hat, kann bestätigen, das geringe registerbreiten ein Garant für hohe Taktraten sind. So gibt es FPGA Implementierungen des 1 MHz C64, die mit 100 MHz laufen. Und das auf "alten", kleinen, LowCost, FPGAS (Spartan-6) : https://www.heise.de/news/Retro-Computing-6502-mit-100-MHz-6223820.html
Dagegen erreichen 32bit microblazes auf der selben FPGA-Architektur irgendwas in hohen zweistelligen MHz-Bereich.
Und wer weiss, was das Teil endgültig kostet, wenn es in Stückzahl
verfügbar sein wird.
Dem Stundensatz eines Programmieres ist es egal wieviel der Chip in Stückzahlen kostet. Bei hoher Nachfrage wie bei populären Familien, geht der Stundensatz eher in die Höhe.
Ich hatte mich damals mit einem RAM wie 62256 beholfen, das ich über den
Parallel-Port quasi "programmieren" konnte. Anschließend konnte man
quasi umschalten (mit ein paar 245er) und der 8031er hat es dann als
Programmspeicher benutzt.
Das habe ich auch gemacht, allerdings hatte ich das RAM mittels RS232 und ein daran angeschlossenes Schieberegister bedient. Als zweite "Entwicklungsplatine" hatte ich dann einen 80C31 Controller, der anstelle des EPROMS eben genau die Schaltung des Simulators ansprach. Auf einer IDC Steckverbindung habe ich dann die I/O Pins nach außen geführt, der Quarz für den Controller war steckbar. Entwickelt habe ich auf einem selbstgeschriebenen, tabellengesteuerten Assembler. Der war in erster Version mit Turbo Pascal 3.0 programmiert, später mit 4.0 für den ich dann eine eigene IDE mit Fullscreeneditor geschrieben hatte. Hat gut funktioniert und ich habe damit lange gewerkelt und darauf an der Technikerschule meine Arbeiten gemacht gehabt.
a, man konnte
sich mit Compiler auf Diskette durch die Lernphase quälen, aber
eigentlich brauchte man für sowas eine Festplatte, die dann auch mal
800-1000 DM kostete.
Meine erste Festplatte (20 MByte) hatte ich 1986 für einen Schneider PC1512 (der auf 640 kByte Ram aufgestockt war) gekauft. Festplatte und Festplattencontroller haben zusammen 870.- DM gekostet (weiß ich noch sehr genau). Damals haben viele gesagt: "Die Platte wird nie voll" ! Das war ein großer Irrtum.
Gut, Du weißt nicht wovon ich rede. Aber das kann ruhig auch so bleiben.
Jaja die Klassische Grundschülertaktik, wenn ich dem Lehrer nicht erkläre was ich meine, kann der mir auch keinen Fehler nachweisen.
Was Du nicht kennst, gibt es folglich nicht.
Da bist Du hier gut aufgehoben ;-)
Du könntest ja auch ein qualifiziertes Anschauungsbeispiel aus deiner Programmierpraxis geben. Oder auch nur wieder"heiße Luft rausgelassen" um hier den coolen Macker auf dem Schulhof zu geben?!
Deinen Preis kann ich bei LCSC kontern (auch ein
F030, allerdings LQFP-48, dafür mit 64 kByte Flash):
Nur schade, daß man davon 40 Pins abkneifen muß, um einen 8-Pinner zu erhalten ;-) Aber bezüglich Preis/Leistung und Lieferbarkeit schon richtig gut.
Die 32 Bitter lassen sich sehr gut debuggen. Für kleine Anwendungen würde ich mir dennoch die neueren AVRs (Tiny) ansehen. Die sind von der Programmierung überschaubar (Debugger ist entbehrlich), sind vom abs. Preis gesehen günstig und laufen von 1,x - 5,x V.
Warum ist bei 32 Bit STM dominant und nicht die AVR SAM? Beide nutzen
ARM Kerne. Was macht STM so beliebt? Was machen die besser bzw. anders?
Anfangs hatte ich ein AT91SAM7S-EK Board mit SAM-ICE von Segger. Der µC konnte mit diversen Renesas Controllern H8S, H8SX, SH2A überhaupt nicht konkurrieren.
Anschließend ist für mich das F407 Discovery-Board als Einstig ausschlaggebend gewesen. Für wenig Geld eine schnelle CPU + ST-Link. Es ist aber zunächst wiederholt in der Ecke gelandet.
Nicht schön aber lehrreich war, daß mein Controller wohl etwas "ausschüssig" war. Programme stürzen an diversen Stellen einfach ab. Irgendwann hatte ich dann die für 168 MHz typ. 5 Wartezyklen auf 7 erhöht und das Teil lief endlich stabil.
Der STM32F407 war überall für wenig Geld erhältlich und anschließend gab es keinen Grund mehr, auf andere Hersteller umzusteigen.
Der STM32F407 war überall für wenig Geld erhältlich und anschließend gab
es keinen Grund mehr, auf andere Hersteller umzusteigen.
Leider müßte dein "war" groß geschrieben werden, denn mittlerweile kostet das 407 Board so um die 20.-€ (ebay).
Der neue "Platzhirsch" dürften hier dann wohl die Blackpills mit F401 oder F411 sein, die es dann zwischen 6 und 10 Euro gibt (auch wenn 401 / 411 mit dem 407 leistungsmäßig nicht mithalten können).
Die Blackboards sind gut, allerdings gefällt mir nicht, dass Boot0 / Boot1 nicht so ohne weiteres erreichbar sind (über Pins) und ein externes Auslösen des Bootmodus des Controllers somit nicht möglich ist und der Bootmodus immer über die Tasten aktiviert werden muß
Der neue "Platzhirsch" dürften hier dann wohl die Blackpills mit F401
oder F411 sein
Ohne Vergrößerungsbrille betrachtet sind das eher die Kaninchen.
"Hirsche" beginnen mit STM32H7.. und laufen mit ca. 0,5 GHz.
Aber gut - nicht immer übertreiben ;-)
Was man derzeit nicht unterschlagen darf: Wenn es fix und fertig sein soll, kann auch ein Pico-Board (RP2040) eine schnelle Lösung bringen. Allerdings gehen die Meinungen über die passende Entwicklungsumgebung etwas auseinander. Selber stehe ich auf Luxus und verwende einen Segger Jlink.
Der neue "Platzhirsch" dürften hier dann wohl die Blackpills mit F401
oder F411 sein,
Beim Ali gibt es die ab ca. 3,50 EUR, die 411er sind etwas teurer. Ich habe sie damals noch für unter 3 EUR bekommen und kann nur sagen: Die Blackpills sind sehr flott und üppig ausgestattet. Gegenüber dem Bluepill (mit STM32F103) haben sie nur einen Nachteil: kein CAN. Wenn man CAN nicht braucht, würde ich immer zum Blackpill greifen - auch schon, um keine Fakes beim Ali untergejubelt zu bekommen.
Sag mal, machst Du hier einen auf MaWin oder Falk B. oder Laberkopp?
Empfindest Dich als Lehrer und bist voll destruktiv? Lass stecken!
Personen die wie Falk 20++ Jahre Berufserfahrung im Bereich embedded haben sind aber die Stütze dieses Forums.
Wenn du deren Erfahrung hier verbannst, verbleibt nur ein Kindergarten für Scriptkidies. Die gabs auch zu 8bit zeiten, nannte man Lamer und wurde älter aber nicht smarter:
https://www.youtube.com/watch?v=GXAiBpIz2_I
Der 845 war schon gut, aber die LPC haben ja wenig Beachtung in der Bastlerwelt gefunden. Ausser beim TO, der hat mal die WS LED damit angesteuert, habe ich mal für den 824 nachgebaut. Und dabei viel geflucht weil der gegenüber dem 812 einen zusätzlichen MUX für die SCT hat und der default nicht kompatibel ist. Und die Beispiele im Cookbook von NXP Kraut und Rüben sind.
wird aber schon lange nicht mehr produziert. Dafür gibts die jetzt in Mikroskopisch kleinen Gehäusen.
Wie auch z.B. die STM32F4 in Gehäusen mit Ballgrid und wenigen mm Kantenlänge. Da frage ich mich wo man soviel Power auf so kleinem Raum braucht, und die Multilayer Platinen dafür sind doch auch recht teuer?
Ah, Danke, war zu blöd zum suchen.
Ja das stört mich auch bei den 84x, weil die völlig anders als die 82x sind. Aber spätestens mit dem 86x wird es Zeit, sich das mal näher anzuschauen. Die sollen den 84x ja recht ähnlich sein.
Wie auch z.B. die STM32F4 in Gehäusen mit Ballgrid und wenigen mm
Kantenlänge. Da frage ich mich wo man soviel Power auf so kleinem Raum
braucht, und die Multilayer Platinen dafür sind doch auch recht teuer?
Da wird der gemeine Baster früher oder später nicht mehr dran vorbeikommen.
Als ich mit den STM32 angefangen hatte, fand ich das überhaupt nicht einfach.
Aber glaub das war noch, bevor ich CubeMX gefunden hatte - oder vlt gabs das noch nicht.
Damals alles mit CMSIS alleine gemacht und PLL Initialisierung war echt undurchsichtig und so.
Mittlerweile klickt man sich das in Cube zusammen und drückt auf den Generierungsknopf und dann muss man nur noch 3h nach "__enable_irq()" suchen, bis alles einschließlich der Interrupts funktioniert.
Also STMicro versucht schon, die Komplexität in ihrem HAL zu verstecken.
Wieso hat der übereifrige Moderator meinen Beitrag gelöscht?
Weil Du auf einen gelöschten Beitrag mit einem Zitat aus dem gelöschten Beitrag geantwortet hast. Diese Begründung wurde Dir auch per E-Mail zugesandt. Vielleicht hast Du diese noch nicht gelesen ;-)
Ich habe nun Deinen Beitrag wieder hergestellt, das Zitag aber entfernt.
Bitte unterlasst es einfach, auf die Beiträge eines Users mit Hausverbot überhaupt zu antworten. Das hat sowieso keinen Zweck. Moby nimmt prinzipiell keine Argumente von anderen an. Da ist sogar Beton flexibler. Danke.
Weil Du auf einen gelöschten Beitrag mit einem Zitat aus dem gelöschten
Beitrag geantwortet hast. Diese Begründung wurde Dir auch per E-Mail
zugesandt. Vielleicht hast Du diese noch nicht gelesen ;-)
Die 32Bit waren für mich persönlich kein großer Sprung, von AVR8 auf STM32. Nur die Einarbeitung in die Register / IDE, die ja nun ein großer Unterschied waren - hat man beim AVR noch im Studio die Taktung per Fusebits gemacht - würden sie halt per Register programmiert. Leistung hatten im Grunde beide genug.
Was allerdings für mich ein wirklich großer Sprung in der letzten Zeit war: Multicore! Endlich keine aufwendigen Statemaschine mehr - wenn man zwei extrem Zeitkritischen Dinge zu verarbeiten hatte - mir persönlich hat das extrem geholfen.
Hmm, also ich finde statemachines eigentlich nicht aufwendig. Man kann sehr übersichtlich damit programmieren.
Mit multicores habe ich mich noch nicht beschäftigt. Mir kommt das aber aufwendiger vor. Das ist aber vermutlich nur Gewöhnungssache.
Was allerdings für mich ein wirklich großer Sprung in der letzten Zeit
war: Multicore! Endlich keine aufwendigen Statemaschine mehr - wenn man
zwei extrem Zeitkritischen Dinge zu verarbeiten hatte - mir persönlich
hat das extrem geholfen.
Weil du State Machines nie verstanden hast? Die Welt hat auch vor Multi-Core CPUs ziemlich gut funktioniert und Leute haben VERDAMMT performante Dinge programmiert.
Was allerdings für mich ein wirklich großer Sprung in der letzten Zeit
war: Multicore! Endlich keine aufwendigen Statemaschine mehr - wenn man
zwei extrem Zeitkritischen Dinge zu verarbeiten hatte - mir persönlich
hat das extrem geholfen.
Weil du State Machines nie verstanden hast? Die Welt hat auch vor
Multi-Core CPUs ziemlich gut funktioniert und Leute haben VERDAMMT
performante Dinge programmiert.
Nein nein, das habe ich ja nicht gesagt. Ich habe den Sinn, die Funktionsweise von State Machines verstanden und selbstverständlich auch angewandt. Ich habe gesagt, das 2 Kerne die Arbeit in dieser Hinsicht viel einfacher gestalten.
Das dies viel mit Faulheit und weniger Komplexität zusammenhängt, ist mir durchaus bewusst. Ich habe die AVR8 Welt auch extrem lange aufrecht erhalten bis ich überhaupt zum STM32 gewechselt bin, ebenso der Faulheit mich in eine neue IDE und Resourcen einzuarbeiten.
Ich zitier mal nichts, was gleich wieder vom Mod gelöscht wird^^
Multicore wie Propeller?
Das war ein Obskurikum, dem ich mich immer komplett verweigert hatte, weil ich kein obskures Zeugs lernen möchte sondern etwas, das standard ist und ich auch in Zukunft noch brauchen kann 😁
Wobei, dann müsste ich mich langsam mal mit Arduino anfreunden 🤔 duck-und-weg
Multicore ist zumindest in Form von zwei Kernen recht erfolgreich im µC-Segment gelandet, nämlich mit dem RP2040, der auf dem "Raspberry Pi Pico" und zunehmend mehr anderen Platinen verbaut wird. Der kombiniert zwei Cortex-M0+-Kerne und ist dank des QFN-Gehäuses auch noch halbwegs handhabbar, wenn man eigene Platinendesigns anfertigen möchte. Mit einem recht geringen Preis (Reichelt: 1.10 EUR) ist das Ding auch noch ziemlich günstig.
Und wie etliche interessante Projekte mit dem RP2040 zeigen, ist das Dual-Core-Design nichts, was die meisten Leute komplett überfordert. Sicher, etliches von dem, was viele "Maker" mit dem RP2040 anstellen, könnte auch mit irgendeinem banalen Attiny erledigt werden, aber einiges eben doch nicht, wie z.B. die Ansteuerung eines HDMI-/DVI-Monitors ...
Da spielt natürlich auch die leistungsfähige programmierbare Peripherie ("PIO") eine Rolle, aber die Kombination davon, mit ordentlich viel RAM lässt auch für die Zukunft viele spannende Entwicklungen erwarten.
Gewiss, der eine oder andere frustrierte (weil er sonst nichts anderes kann) 8-Bit-Assemblerprogrammierer wird mit viel Aufwand auch noch das eine oder andere spannende Projekt mit einem Attiny zustandebekommen (immerhin: Auch die Dinger können schnell genug sein, um z.B. ein Low-Speed-USB-Device komplett per Bitbanging nachzubilden, wie V-Usb auf dem Tiny85 zeigt), aber die Grenze des Erreichbaren ist bei diesen Dingern deutlich näher.
Und wenn man nicht nur darauf achtet, das System mit der absolut geringsten Rechenleistung zu verwenden, sondern auch auf den Preis blickt, und die Möglichkeiten, die ein neuzeitliches Entwicklungssystem bietet, und nicht wochen- bis monatelang in mehr oder weniger unwartbarem Assemblerspaghetticode herumstochern will, dann kann so ein "fetter ARM", der kaum mehr kostet als so ein Attiny, doch sehr attraktiv sein. Selbst wenn man all' die Performance nicht braucht, das Ding hat einfach schon mal viel mehr I/O-Leitungen ...
Gewiss, der eine oder andere frustrierte (weil er sonst nichts anderes
kann) 8-Bit-Assemblerprogrammierer wird mit viel Aufwand auch noch das
eine oder andere spannende Projekt mit einem Attiny zustandebekommen
(immerhin: Auch die Dinger können schnell genug sein, um z.B. ein
Low-Speed-USB-Device komplett per Bitbanging nachzubilden, wie V-Usb auf
dem Tiny85 zeigt), aber die Grenze des Erreichbaren ist bei diesen
Dingern deutlich näher.
Also bitte...
VGA geht sogar mit den AVR8 ohne weitere Logik. Wenn man sich auf SW-Text-Modi beschränkt (und eine leichte Übertaktung in Kauf nimmt).
und nicht wochen- bis monatelang in mehr oder weniger
unwartbarem Assemblerspaghetticode herumstochern will
Das fällt nur denen schwer, die halt kein Asm können. Gut dokumentierter Assemblercode IST wartbar und gut verständlich. Wenn man halt die Sprache kann. Das ist halt wie bei jeder anderen Sprache auch...
Der Schwerpunkt ist halt eine wirklich gute Dokumentation. Schwachsinnige Pseudo-Doku á la Doxygen ist regelmäßig nicht hilfreich. Da steht im Kern nur, was auch in der Deklaration steht. Wirklich wichtig zum Verständnis ist aber das Konzept. Ich gebe zu, dass das gerade bei einer optimierten Umsetzung in Asm oft nicht ganz einfach zu verstehen ist. Umso wichtiger ist halt die Dokumentationen.
Gut dokumentierter Assemblercode IST wartbar und gut verständlich.
Und bleibt trotzdem Spaghetticode. Mit viel Aufwand kann man versuchen, den irgendwie wartbar zu erhalten, aber ohne sehr gründlich gepflegter Dokumentation ist da nichts zu löten.
Und auch "gut dokumentierter" Assemblercode ist im wesentlichen nur von demjenigen wartbar, der ihn verbrochen^h^h^h^hgeschrieben hat, nicht aber von anderen, denn dazu müsste die Dokumentation nicht nur gut, sondern exzellent sein.
An Selbstüberschätzung leidet hier niemand, wie?
Hochsprachen haben den gigantischen Vorteil, daß standardisierte Programmstrukturen klar lesbar sind und nicht vom individuellen Schreib- und Codierstil des Programmierers abhängen. Somit kann von anderen (oder einem selbst ausreichend lange zuvor) geschriebener Code recht leicht verstanden werden, sofern der Programmierer nicht allzuviel Aufwand bei der Obfuscation getrieben hat.
Ich habe ausreichend lange in Assembler programmiert und auch fremden Binärcode disassembliert, um zu wissen, daß Spaghetti in den Magen, nicht aber ins Programm gehören.
Ah, Danke, war zu blöd zum suchen.
Ja das stört mich auch bei den 84x, weil die völlig anders als die 82x
sind. Aber spätestens mit dem 86x wird es Zeit, sich das mal näher
anzuschauen. Die sollen den 84x ja recht ähnlich sein.
Habe jetzt mal in das Datenblatt geschaut, beim LPC865 wurde der SCT wegoptimiert. Damit ist das ein 0815 Controller wie viele andere, schade.
Ich habe ausreichend lange in Assembler programmiert und auch fremden
Binärcode disassembliert, um zu wissen, daß Spaghetti in den Magen,
nicht aber ins Programm gehören.
Das glaube ich nicht. Das klingt vielmehr wie die typische Schutzbehauptung derjenigen, die's halt nicht checken...
Das sind typisch übrigens auch die, die gnadenlos scheitern, wenn sie das Disassemblat eines von einem modernen Compilers generierten Codes analysieren sollen. Arme, hilflose Würstchen in der Weite der binären Logik...
Tipp für solche armen Würstchen: die Doku steckt im Code des verwendeten Compilers. Nur ist das leider keine Doku mit der Qualität, wie sie z.B. für meine Asm-Projekte Standard ist. Da ist genau erklärt, was, wie und warum optimiert wurde. Bei Compiler-Produkten musst du das "reverse" erschließen. Das kannst du nur, wenn du den Compiler kennst und das Target.
Du kennst aber nix. Da brauchst du dich nicht darüber zu wundern, dass du nix kapierst.
Arme, hilflose Würstchen .. die gnadenlos scheitern
Fühlst du dich besser, wenn du dich so äußerst?
Nicht wirklich. Das berührt mich in etwa wie der berühmte Sack Reis in China. Die Sache ist einfach: was wahr ist, muss wahr bleiben und gesagt werden (zumindest, wenn es gefragt wurde).
Und genau das ist hier passiert. Einer, der offensichtlich nicht wirklich Ahnung hat, hat sich bemüssigt gefühlt, eine Wertung abzugeben. Ich habe meine Wertung dagegen gesetzt.
Dass sowas "Wattebällchen-mäßig" nicht gut für den Unwissenden ausgeht, liegt in der Natur der Sache. Er hätte sich auch einfach seine idiotische Wertung verkneifen können, und dann hätte es auch den Gegenwind nicht gegeben.
So einfach ist das. Jeder darf seine Meinung haben und die auch äußern. Das finde ich gut. Aber man muss dann auch die Gegenmeinung einstecken können...
Wie kann man unter Wahrung der Menschenwürde sagen, dasss der
Mensch offensichtlich eine idiotische Meinung geäußert hat?
Zum Beispiel "Ich bin ganz anderer Meinung, und zwar ..."
Die Wertung "idiotisch" muss nicht dabei sein. Bleibe einfach bei den Fakten, ohne Gefühle.
Dass dir deine eigene Würde nichts wert ist, hast du zur genüge gezeigt.
Das ist spannend. Wie kommst du zu dieser Meinung?
Weil du dich sehr schlecht benimmst. In geschätzt jedem zweiten Beitrag äußerst du dich auf beleidigende Weise.
Deine oft indirekte Art " diese Idioten" anstelle von " Du Idiot" macht es nicht besser. Es bleibt dabei, dass du Personen beleidigst. Oft sogar ganze Gruppen in einem weiten Rundum-Schlag.
Wie gesagt finde ich dich wegen diesem Benehmen sehr unangenehm, auch wenn deine Aussagen gerade ganz anderen Personen galten.
Die Wertung "idiotisch" muss nicht dabei sein. Bleibe einfach bei den
Fakten, ohne Gefühle.
Ooops. Hier haben wir ein Problem. Wenn "idiotisch" nunmal ein offensichtlicher und nachweislicher Fakt ist und kein bloßes Gefühl, wie soll man dann damit umgehen? OK, man könnte sich stundenlang damit beschäftigen, weniger "aufregende" Synonyme für "idiotisch" zu finden... Aber warum sollte man sich diesen Aufwand antun? Der Fakt bleibt doch Fakt?
Weil du dich sehr schlecht benimmst.
Aha. Wenn man sich "schlecht benimmt" gibt man seine eigene Würde auf?
Das ist Bullshit! Es ist vielmehr im Gegenteil so: Wenn man den Arsch in der Hose hat, auch unliebsame Wahrheiten offen zu verkünden, nur dann bewahrt man die eigene Würde.
Wer das nicht kann, ist ein Arschkriecher. Und davon haben wir, weiß Gott, VIEL mehr als genug...
Hier und im RL...
Und ich bewahre meine Würde ebenfalls hier und im RL...
Mit der entsprechenden Kompetenz kann man sich das leisten...
Wenn man sich "schlecht benimmt" gibt man seine eigene Würde auf?
So sehe ich das jedenfalls.
Das ist Bullshit!
Das ist wieder so eine gefühlsmäßige Wertung. Versuche mal, deine Wertungen ganz weg zu lassen. Dann ist das mit dem Gefühl automatisch auch kein Problem mehr.
Wer das nicht kann, ist ein Arschkriecher
Das ist wieder eine unzulässige Beleidigung.
Sage einfach:
Ich sehe das anders
Ich denke, das ist falsch
Du hast da wohl etwas missverstanden
Oder in ganz harten Fällen:
Das ist falsch / das stimmt so nicht
Ohne Wertung. Kein Idiot, kein Bullshit, kein Arschkriecher. Diese beleidigenden Begriffe sind weder Notwendig noch angebracht, um Fakten zu diskutieren.
Deswegen produzieren auch optimierende Compiler oft genau das...
Der Unterschied, den Du zu begreifen Dich weigerst: Den Code aber, den der Compiler auswirft, den wartet niemand. Den muss man zwar bei der Fehlersuche verstehen können, aber niemand, der noch seine drei Muscheln beieinander hat, käme auf die Idee, das als Grundlage für ein zu wartendes Programm zu verwenden.
Schafft es hier wirklich niemand mehr, objektiv über aktuelle
MCU-Familien zu diskutieren?
So etwas artet sowieso in einem Glaubenskrieg aus. Ähnlich wie die Frage nach dem besten OS, der Programmiersprache oder dem verwendeten EDA.
So gesehen ist die Frage des TO eigentlich prädestiniert für ausschweifende Threads.
Mal ganz wertlos gefragt: Hattest Du mal eine Anwendung oder Idee dazu?
Ich hatte mich mit den SCTs nie beschäftigt.
Den LPC824 für die Ansteuerung von WS2812LED benutzt. SPI schiebt ein Bit raus, SCT macht abhängig vom Pegel 0/1 die Bitfolge für die WS.
Dann einen RC5 Sender, da wird der 38 kHz Träger und die Modulation in der SCT Hardware gemacht, funktioniert auch sehr gut.
Eine weitere Anwendung die ich immer mal aufbauen wollte ist ein geregelter Step Up Wandler. Das war vor langer Zeit in der make Zeitschrift, eine Taschenlampe mit 10 W LED. Da wurde noch der (nicht mehr lieferbare) LPC800, verwendet. Mit wenigen Teilen eine Lampe mit ein paar Zusatzfunktionen.
Dann gibt es noch das SCT Cookbook mit weiteren Anwendungen.
Der SCT ist auch noch in anderen LPC Serien drin. Im LPCXpresso war eine grafische Konfiguration der Statmemachines drin, die ist in MCUXpresso rausgeflogen.
Schafft es hier wirklich niemand mehr, objektiv über aktuelle
MCU-Familien zu diskutieren?
Apropos: Ich überlege, wie man eine Multicoreplatine bauen könnte.
Der PiPico hat 2 Kerne und der oben genannte Preis lag bei ~1,10€, d.h. 55 Cent pro Kern.
Der große Nachteil: Kein floating Point.
Im Moment finde ich die STM32G4 Serie interessant, die liegen aber laut Digikey bei ~6€, also viel teurer als der PiPico.
Schafft es hier wirklich niemand mehr, objektiv über aktuelle
MCU-Familien zu diskutieren?
Apropos: Ich überlege, wie man eine Multicoreplatine bauen könnte.
Der PiPico hat 2 Kerne und der oben genannte Preis lag bei ~1,10€, d.h.
55 Cent pro Kern.
Ja, und man kann ihn sehr schön übertakten. Im Bezug auf MIPS/cent light der RP2040 ziemlich gut. Der Ch32V203 ist hier übrigens auch ziemlich interessant, da er für <0.50EUR zu haben ist.
Der große Nachteil: Kein floating Point.
Naja, immerhin hat der RP2040 FP unterstützung per Library aus dem ROM. Wenn man ehrlich ist, gibt es auch nicht viele embedded-Anwendungen, wo FP wirklich notwendig ist. Meist ist es doch eher die Bequemlichkeit.
Im Moment finde ich die STM32G4 Serie interessant, die liegen aber laut
Digikey bei ~6€, also viel teurer als der PiPico.
Ja, die STM32G serie sieht ziemlich gelungen aus. Der STM32G030 ist inzwischen ja auch endlich erhältlich...
