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. Texas Instruments MSPM0 als MSP430 Ersatz: https://www.ti.com/microcontrollers-mcus-processors/arm-based-microcontrollers/arm-cortex-m0-mcus/overview.html STM mit STM32C0 als STM8 Ersatz: https://www.st.com/en/microcontrollers-microprocessors/stm32c0-series.html Die STM8S sind anscheinend jetzt NFND Bei NXP gibt es schon länger die LPC800: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/lpc800-arm-cortex-m0-plus-/low-cost-microcontrollers-mcus-based-on-arm-cortex-m0-plus-core:LPC80X Dann natürlch der sehr interessante RISC-V CH32V003 von WCH aus China: http://www.wch-ic.com/products/CH32V003.html Dann hätten wir den Puya PY32F002 als low cost CM0 mit <$0.10 https://www.puyasemi.com/cpzx3/info_271_aid_247_kid_246.html Welche habe ich hier vergessen?
:
Gesperrt durch Moderator
Zwar nicht besonders billig, aber ich empfinde die STM32L0 Serie als den nächsten logischen Schritt nach 8 Bit Mikrocontrollern.
Stefan F. schrieb: > Zwar nicht besonders billig, aber ich empfinde die STM32L0 Serie > als den > nächsten logischen Schritt nach 8 Bit Mikrocontrollern. Ja, die kann immerhin beim Energieverbrauch mit den 8bittern mithalten. Das ist bisher bei den meisten 8bit replacements noch der größte Pferdefuss.
Beitrag #7423293 wurde von einem Moderator gelöscht.
Beitrag #7423295 wurde von einem Moderator gelöscht.
Beitrag #7423298 wurde von einem Moderator gelöscht.
Beitrag #7423304 wurde von einem Moderator gelöscht.
Beitrag #7423311 wurde von einem Moderator gelöscht.
Beitrag #7423322 wurde von einem Moderator gelöscht.
Beitrag #7423534 wurde von einem Moderator gelöscht.
Moby A. schrieb im Beitrag #7423534: > Controller nach > vorhandenem Knowhow Und was willst du dann in diesem Forum?
Beitrag #7423554 wurde von einem Moderator gelöscht.
Beitrag #7423584 wurde von einem Moderator gelöscht.
Beitrag #7423593 wurde vom Autor gelöscht.
Beitrag #7423615 wurde von einem Moderator gelöscht.
Beitrag #7423642 wurde von einem Moderator gelöscht.
Beitrag #7423683 wurde von einem Moderator gelöscht.
Beitrag #7423718 wurde von einem Moderator gelöscht.
Stefan F. schrieb: > 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.
:
Bearbeitet durch User
Mampf F. schrieb: > TSSOP20 ist > halt schon fast wieder unangenehm zu bestücken. Mit Lötpaste und Heißluft eigentlich kein Hexenwerk.
Mampf F. schrieb: > 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 ;)
:
Bearbeitet durch User
Beitrag #7423841 wurde von einem Moderator gelöscht.
Beitrag #7423863 wurde von einem Moderator gelöscht.
Bauform B. schrieb: > Ideal zum sanften Wechsel, auch, weil er nur 8K RAM, kein DMA und keine > I2C-Hardware hat. Aber 32 Bit ;) 😂 Danke für den Tipp, aber ich fühle mich jetzt schon zu alt, eine komplett neue CPU Architektur zu lernen - meine letzte war wohl Risc-V^^. Was hatten die PIC32 - ich denke einen MIPS? 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 😂 Sorry für das Geschwafel 🙈
:
Bearbeitet durch User
> Welche habe ich hier vergessen? 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. https://www.ti.com/de-de/microcontrollers-mcus-processors/msp430-microcontrollers/overview.html https://de.wikipedia.org/wiki/TI_MSP430 https://www.mikrocontroller.net/articles/Kategorie:MSP430
Mampf F. schrieb: > 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.
Ralph S. schrieb: > 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Steve van de Grens schrieb: > 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.
Mampf F. schrieb: > 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.
Ralph S. schrieb: > 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.
Ralph S. schrieb: > 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. Ein EPROM Simulator, sozusagen 😊 Das waren noch Zeiten ... 🥰 Ralph S. schrieb: > 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 🙈
:
Bearbeitet durch User
Mampf F. schrieb: > 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.
J. S. schrieb: > 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.
Beitrag #7424007 wurde von einem Moderator gelöscht.
Beitrag #7424108 wurde von einem Moderator gelöscht.
Beitrag #7424135 wurde von einem Moderator gelöscht.
Beitrag #7424149 wurde von einem Moderator gelöscht.
Hallo, 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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
ARM®Cortex® im SO-8: https://www.reichelt.de/arm-cortex-m0-mikrocontroller-32-kb-flash-so-8-stm32c011j6m6-p352808.html
Veit D. schrieb: > 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.
Georg M. schrieb: > ARM®Cortex® im SO-8: > > https://www.reichelt.de/arm-cortex-m0-mikrocontroller-32-kb-flash-so-8-stm32c011j6m6-p352808.html Oh! 😍😍😍 Finally! 32Bit in einem SO Gehäuse 🥳
Beitrag #7424202 wurde von einem Moderator gelöscht.
Beitrag #7424203 wurde von einem Moderator gelöscht.
Beitrag #7424232 wurde von einem Moderator gelöscht.
Ich halte das für relativ witzlos, wenn man nur 6 Pins I/O hat.
Abdul K. schrieb: > 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.
Abdul K. schrieb: > Ich halte das für relativ witzlos, wenn man nur 6 Pins I/O hat. Dann nimm den für 1,30 EUR im TSSOP-20: https://www.reichelt.de/arm-cortex-m0-mikrocontroller-32-bit-3v-16-kb-tssop-20-stm-32f030f4p6-p168428.html * 48 MHz * 16Kb Flash * 4 KB RAM * 5 Timer * 15 I/Os * 5 Kanal DMA * 1 I²C * 1 SPI * 11 ADC * 1 USART P.S. Gibts für denselben Preis auch mit 32 KB Flash und 8 KB RAM - allerdings dann im LQFP-32 Gehäuse: https://www.reichelt.de/arm-cortex-m0-mikrocontroller-32-bit-3v-32-kb-lqfp-32-stm32-f030k6t6-p351967.html Beide sind auch auf Lager - im Gegensatz zum STM32C011.
:
Bearbeitet durch Moderator
DSGV-Violator schrieb: > Abdul K. schrieb: >> 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.
Beitrag #7424366 wurde von einem Moderator gelöscht.
Mi N. schrieb: > DSGV-Violator schrieb: >> Abdul K. schrieb: >>> 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.
DSGV-Violator schrieb: > Sososo, mehr digitale MIPS und MHz für "analoge Interpolation", als wenn > die 12 bit nicht schon genug Rauschen enthalten. Gut, Du weißt nicht wovon ich rede. Aber das kann ruhig auch so bleiben. DSGV-Violator schrieb: > Ich hab noch nie Software gesehen, Was Du nicht kennst, gibt es folglich nicht. Da bist Du hier gut aufgehoben ;-)
Beitrag #7424429 wurde von einem Moderator gelöscht.
Beitrag #7424455 wurde von einem Moderator gelöscht.
Mampf F. schrieb: > 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. DSGV-Violator schrieb: > 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.
Frank M. schrieb: > Dann nimm den für 1,30 EUR im TSSOP-20: > https://www.reichelt.de/arm-cortex-m0-mikrocontroller-32-bit-3v-16-kb-tssop-20-stm-32f030f4p6-p168428.html :-) grüß dich Frank. Deinen Preis kann ich bei LCSC kontern (auch ein F030, allerdings LQFP-48, dafür mit 64 kByte Flash): https://www.lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_STMicroelectronics-STM32F030C8T6TR_C40053.html Ich habe mir 30 Stck. für insgesamt 17 Dollar gekauft (neben 10 Stck. F072 und 100 Stck. Padauk PFS154 - 8 Bit halt)
Beitrag #7424467 wurde von einem Moderator gelöscht.
> 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?!
DSGV-Violator schrieb: > Jaja die Klassische Grundschülertaktik, wenn ich dem Lehrer nicht > erkläre was ich meine, kann der mir auch keinen Fehler nachweisen. Nun, Du hast hier auch schon sehr merkwürdige Thesen verbreitet: DSGV-Violator schrieb: > ein Linux/Windows fähiger 32++ bit Prozessor ist per se ineffizient.
Beitrag #7424564 wurde von einem Moderator gelöscht.
DSGV-Violator schrieb: > Jaja die Klassische Grundschülertaktik, wenn ich dem Lehrer nicht > erkläre was ich meine, kann der mir auch keinen Fehler nachweisen. Sag mal, machst Du hier einen auf MaWin oder Falk B. oder Laberkopp? Empfindest Dich als Lehrer und bist voll destruktiv? Lass stecken! Ralph S. schrieb: > 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. Veit D. schrieb: > 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.
Beitrag #7424583 wurde von einem Moderator gelöscht.
Mi N. schrieb: > 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ß
Beitrag #7424609 wurde von einem Moderator gelöscht.
Ralph S. schrieb: > 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.
Beitrag #7424616 wurde von einem Moderator gelöscht.
Beitrag #7424623 wurde von einem Moderator gelöscht.
Beitrag #7424634 wurde von einem Moderator gelöscht.
Beitrag #7424660 wurde von einem Moderator gelöscht.
Ralph S. schrieb: > 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.
Frank M. schrieb: > auch schon, um keine Fakes beim Ali untergejubelt zu bekommen. Hoffentlich bleibt das so. Die schlechten F103 Fakes sind extrem nervig. Man weiß vorher nie, welche Variante geliefert wird.
Steve van de Grens schrieb: > Hoffentlich bleibt das so. Bisher habe ich weder Fakes noch Clones von den F4x1 gesehen noch davon gehört.
Beitrag #7424701 wurde von einem Moderator gelöscht.
Mi N. schrieb: > 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
Beitrag #7424715 wurde von einem Moderator gelöscht.
Beitrag #7424726 wurde von einem Moderator gelöscht.
Beitrag #7424760 wurde von einem Moderator gelöscht.
Beitrag #7424861 wurde von einem Moderator gelöscht.
Beitrag #7424886 wurde von einem Moderator gelöscht.
Beitrag #7424915 wurde von einem Moderator gelöscht.
Beitrag #7425085 wurde von einem Moderator gelöscht.
Beitrag #7425136 wurde von einem Moderator gelöscht.
Beitrag #7425153 wurde von einem Moderator gelöscht.
Beitrag #7425157 wurde von einem Moderator gelöscht.
Beitrag #7425158 wurde von einem Moderator gelöscht.
Beitrag #7425160 wurde von einem Moderator gelöscht.
Beitrag #7425161 wurde von einem Moderator gelöscht.
Beitrag #7425162 wurde von einem Moderator gelöscht.
Beitrag #7425169 wurde von einem Moderator gelöscht.
Beitrag #7425171 wurde von einem Moderator gelöscht.
Beitrag #7425173 wurde von einem Moderator gelöscht.
Beitrag #7425228 wurde von einem Moderator gelöscht.
Beitrag #7425232 wurde von einem Moderator gelöscht.
Beitrag #7425299 wurde von einem Moderator gelöscht.
Andreas B. schrieb: > Nur ein DB > gibt es noch nicht. :-( bei NXP gibts die schon: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/lpc800-arm-cortex-m0-plus-/low-cost-microcontrollers-mcus-based-on-arm-cortex-m0-plus-cores:LPC86X?fpsp=1&#documentation 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.
Harald K. schrieb: > https://www.nxp.com/part/LPC810M021FN8#/ 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?
:
Bearbeitet durch User
J. S. schrieb: > bei NXP gibts die schon: 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. J. S. schrieb: > 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.
:
Bearbeitet durch User
Beitrag #7425343 wurde von einem Moderator gelöscht.
Beitrag #7425348 wurde von einem Moderator gelöscht.
Beitrag #7425360 wurde von einem Moderator gelöscht.
Beitrag #7425364 wurde von einem Moderator gelöscht.
Beitrag #7425411 wurde von einem Moderator gelöscht.
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. [Mod: Zitat aus gelöschtem Beitrag entfernt]
:
Bearbeitet durch Moderator
Mampf F. schrieb: > und dann muss man nur noch 3h nach "__enable_irq()" > suchen, bis alles einschließlich der Interrupts funktioniert. Muss man nicht! Das macht man auch via CubeMX. "__enable_irq" hab ich noch nie für sich verwendet.
Harry L. schrieb: > Mampf F. schrieb: >> und dann muss man nur noch 3h nach "__enable_irq()" >> suchen, bis alles einschließlich der Interrupts funktioniert. > > Muss man nicht! > Das macht man auch via CubeMX. > "__enable_irq" hab ich noch nie für sich verwendet. Danke für den Hinweis! Wieso hat der übereifrige Moderator meinen Beitrag gelöscht?
Mampf F. schrieb: > Wieso hat der übereifrige Moderator meinen Beitrag gelöscht? Vermutlich, weil du Wasser auf die Mühlen von diesem Missionar gegossen hast.
Mampf F. schrieb: > 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.
Beitrag #7425481 wurde von einem Moderator gelöscht.
Frank M. schrieb: > 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 lese keine Mails - da kommt nur Spam ;-) Ok, alles klar. Vielen dank :)
Beitrag #7425554 wurde von einem Moderator gelöscht.
Beitrag #7425564 wurde von einem Moderator gelöscht.
Beitrag #7425590 wurde von einem Moderator gelöscht.
Beitrag #7425605 wurde von einem Moderator gelöscht.
Beitrag #7425611 wurde von einem Moderator gelöscht.
Beitrag #7425624 wurde von einem Moderator gelöscht.
Beitrag #7425673 wurde von einem Moderator gelöscht.
Beitrag #7425765 wurde von einem Moderator gelöscht.
Beitrag #7425802 wurde von einem Moderator gelöscht.
Beitrag #7425813 wurde vom Autor gelöscht.
Beitrag #7425816 wurde von einem Moderator gelöscht.
Mi N. schrieb: > 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 ;-) :-) mit "Platzhirsch" meinte ich schlichtweg Preis und Stückzahl und nicht die Leistungsfähigkeit.
Beitrag #7426224 wurde von einem Moderator gelöscht.
Beitrag #7426289 wurde von einem Moderator gelöscht.
Beitrag #7426304 wurde von einem Moderator gelöscht.
Beitrag #7426308 wurde von einem Moderator gelöscht.
Beitrag #7426441 wurde von einem Moderator gelöscht.
Beitrag #7426456 wurde von einem Moderator gelöscht.
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.
Rene K. schrieb: > Endlich keine aufwendigen Statemaschine mehr 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.
Rene K. schrieb: > 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.
Falk B. schrieb: > Rene K. schrieb: >> 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. Aber so ist das Leben, es dreht sich weiter.
:
Bearbeitet durch User
Beitrag #7426515 wurde von einem Moderator gelöscht.
Beitrag #7426529 wurde von einem Moderator gelöscht.
Beitrag #7426582 wurde von einem Moderator gelöscht.
Beitrag #7426583 wurde vom Autor gelöscht.
dejavu 🤔 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 ...
Beitrag #7426632 wurde von einem Moderator gelöscht.
Beitrag #7426668 wurde von einem Moderator gelöscht.
Beitrag #7426686 wurde von einem Moderator gelöscht.
Beitrag #7426689 wurde von einem Moderator gelöscht.
Beitrag #7426697 wurde von einem Moderator gelöscht.
Harald K. schrieb: > 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.
Beitrag #7426723 wurde von einem Moderator gelöscht.
C-hater schrieb: > 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.
Beitrag #7426767 wurde von einem Moderator gelöscht.
Beitrag #7426800 wurde von einem Moderator gelöscht.
Beitrag #7426820 wurde von einem Moderator gelöscht.
Beitrag #7426843 wurde von einem Moderator gelöscht.
Beitrag #7426952 wurde von einem Moderator gelöscht.
Beitrag #7427021 wurde von einem Moderator gelöscht.
Andreas B. schrieb: > J. S. schrieb: >> bei NXP gibts die schon: > > 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.
Harald K. schrieb: > 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.
C-hater schrieb: > Arme, hilflose Würstchen .. die gnadenlos scheitern Fühlst du dich besser, wenn du dich so äußerst? Ich finde, es liegt auf dem gleichen Niveau, wie jemandem aus nächster Nähe ins Gesicht zu rülpsen.
Stefan F. schrieb: > C-hater schrieb: >> 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...
C-hater schrieb: > was wahr ist, muss wahr bleiben und gesagt werden > Jeder darf seine Meinung haben und die auch äußern. Aber die Würde des Menschen muss dabei gewahrt bleiben. Steht so im Grundgesetz. Lass dir das mal von Percy erklären. Dass dir deine eigene Würde nichts wert ist, hast du zur genüge gezeigt. Dennoch musst du die der anderen wahren.
Stefan F. schrieb: > Aber die Würde des Menschen muss dabei gewahrt bleiben. Hmm... Wie kann man unter Wahrung der Menschenwürde sagen, dasss der Mensch offensichtlich eine idiotische Meinung geäußert hat?
Stefan F. schrieb: > Dass dir deine eigene Würde nichts wert ist, hast du zur genüge gezeigt. ??? Das ist spannend. Wie kommst du zu dieser Meinung?
C-hater schrieb: > 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.
Stefan F. schrieb: > 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...
C-hater schrieb: > Wenn "idiotisch" nunmal ein offensichtlicher und nachweislicher > Fakt ist und kein bloßes Gefühl, wie soll man dann damit umgehen? "idiotisch" ist aber kein Fakt, sondern eine Wertung. Sogar eine sehr gefühlsmäßige.
Stefan F. schrieb: > C-hater schrieb: >> Wenn "idiotisch" nunmal ein offensichtlicher und nachweislicher >> Fakt ist und kein bloßes Gefühl, wie soll man dann damit umgehen? > > "idiotisch" ist aber kein Fakt, sondern eine Wertung. Sogar eine sehr > gefühlsmäßige. Das sagst du. Aber frag' mal jemanden, der sich wirklich auskennt..
> 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. Mir fällt das auch viel zu oft schwer.
Harald K. schrieb: > Und bleibt trotzdem Spaghetticode. Das ist nicht zu bestreiten. Liegt halt daran, dass das Target mit diesem "Spaghetti-Code" das Optimum seiner Leistungsfähigkeit erreicht. Deswegen produzieren auch optimierende Compiler oft genau das...
C-hater schrieb: > Das glaube ich nicht. Das klingt vielmehr wie die typische > Schutzbehauptung derjenigen, die's halt nicht checken... Scheibts, und folgt mit maßloser Selbstüberschätzung, den eigenen Spaghetticode betreffend. C-hater schrieb: > 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.
Angehängte Dateien:
-
Atmega_vers_Pipico_VGA.png
250 KB
c-hater schrieb >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). Der Einfachheit halber kannst du das als Arduino-Library kriegen: https://forum.arduino.cc/t/vga-library-for-arduino-uno-and-atmega328/308936 Im Ergebnis ergibt sich allerdings ein kleiner Unterschied (auch bei aller Programmierkunst) https://www.youtube.com/watch?v=mrThmFlgV_s
Schafft es hier wirklich niemand mehr, objektiv über aktuelle MCU-Familien zu diskutieren?
J. S. schrieb: > beim LPC865 wurde der SCT > wegoptimiert Mal ganz wertlos gefragt: Hattest Du mal eine Anwendung oder Idee dazu? Ich hatte mich mit den SCTs nie beschäftigt. Tim . schrieb: > 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.
:
Bearbeitet durch User
Andreas B. schrieb: > 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 WS2812 LED 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.
:
Bearbeitet durch User
Danke! Das mit dem SCT cookbook ist ein guter Tip. Das werde ich mir bei Gelegenheit mal reinziehen.
Tim . (cpldcpu) >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.
Christoph M. schrieb: > Tim . (cpldcpu) >>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...
Beitrag #7431930 wurde von einem Moderator gelöscht.
Beitrag #7432087 wurde von einem Moderator gelöscht.
Beitrag #7432104 wurde von einem Moderator gelöscht.
Beitrag #7432207 wurde von einem Moderator gelöscht.
Beitrag #7432243 wurde von einem Moderator gelöscht.
Beitrag #7432269 wurde von einem Moderator gelöscht.
Beitrag #7432407 wurde von einem Moderator gelöscht.
Beitrag #7432451 wurde von einem Moderator gelöscht.
Beitrag #7432458 wurde von einem Moderator gelöscht.
Beitrag #7432510 wurde von einem Moderator gelöscht.
Beitrag #7432519 wurde von einem Moderator gelöscht.
Beitrag #7432558 wurde von einem Moderator gelöscht.
Beitrag #7432697 wurde von einem Moderator gelöscht.
Beitrag #7432703 wurde von einem Moderator gelöscht.
Beitrag #7432712 wurde von einem Moderator gelöscht.
Beitrag #7432746 wurde von einem Moderator gelöscht.
Beitrag #7432763 wurde von einem Moderator gelöscht.
Beitrag #7432831 wurde von einem Moderator gelöscht.
Beitrag #7433313 wurde von einem Moderator gelöscht.
Beitrag #7433326 wurde von einem Moderator gelöscht.
Beitrag #7433344 wurde von einem Moderator gelöscht.
Beitrag #7433754 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten