Welche Low Cost 32 Bit MCU Familie?

[Tim . (cpldcpu)]

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?

[Stefan F. (Gast)]

Zwar nicht besonders billig, aber ich empfinde die STM32L0 Serie als den 
nächsten logischen Schritt nach 8 Bit Mikrocontrollern.

[Tim . (cpldcpu)]

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.

[Harry L. (mysth)]

Moby A. schrieb im Beitrag #7423534:
> Controller nach
> vorhandenem Knowhow

Und was willst du dann in diesem Forum?

[Motopick (motopick)]

4 8 bit PICs schaffen locker auch 32 bit!
Und vermutlich ist man in einem Viertel der Zeit fertig.

[Mampf F. (mampf)]

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.

[Harry L. (mysth)]

Mampf F. schrieb:
> TSSOP20 ist
> halt schon fast wieder unangenehm zu bestücken.

Mit Lötpaste und Heißluft eigentlich kein Hexenwerk.

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Ich verwende gerne die STM32 mit 0.8mm Pitch im LPFQ32 Gehäuse.

[Bauform B. (bauformb)]

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 ;)

[Mampf F. (mampf)]

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 🙈

[DSGV-Violator (Gast)]

> 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

[Ralph S. (jjflash)]

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.

[Mampf F. (mampf)]

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.

[Monk (Gast)]

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.

[Mampf F. (mampf)]

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.

[Ralph S. (jjflash)]

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.

[DSGV-Violator (Gast)]

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.

[Mampf F. (mampf)]

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 🙈

[J. S. (jojos)]

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.

[Chris D. (myfairtux) (Moderator)]

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.

[Veit D. (devil-elec)]

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?

[J. S. (jojos)]

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.

[Veit D. (devil-elec)]

Danke.

[Georg M. (g_m)]

ARM®Cortex® im SO-8:

https://www.reichelt.de/arm-cortex-m0-mikrocontroller-32-kb-flash-so-8-stm32c011j6m6-p352808.html

[Mampf F. (mampf)]

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.

[Mampf F. (mampf)]

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 🥳

[Abdul K. (ehydra)]

Ich halte das für relativ witzlos, wenn man nur 6 Pins I/O hat.

[DSGV-Violator (Gast)]

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.

[Frank M. (ukw) (Moderator)]

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.

[Mi N. (msx)]

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.

[DSGV-Violator (Gast)]

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.

[Mi N. (msx)]

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 ;-)

[Ralph S. (jjflash)]

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.

[Ralph S. (jjflash)]

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)

[DSGV-Violator (Gast)]

> 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?!

[Harald K. (kirnbichler)]

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.

[Mi N. (msx)]

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.

[Ralph S. (jjflash)]

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ß

[Mi N. (msx)]

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.

[Frank M. (ukw) (Moderator)]

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.

[Monk (Gast)]

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.

[Frank M. (ukw) (Moderator)]

Steve van de Grens schrieb:
> Hoffentlich bleibt das so.

Bisher habe ich weder Fakes noch Clones von den F4x1 gesehen noch davon 
gehört.

[DSGV-Violator (Gast)]

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

[Andreas B. (bitverdreher)]

Der LPC865 sieht schick aus. Gibts auch schon bei Mouser. Nur ein DB 
gibt es noch nicht. :-(

[Harald K. (kirnbichler)]

ARM im 8poligen DIP ist übrigens gar nicht so neu:

https://www.nxp.com/part/LPC810M021FN8#/

[J. S. (jojos)]

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.

[J. S. (jojos)]

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?

[Andreas B. (bitverdreher)]

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.

[Mampf F. (mampf)]

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]

[Harry L. (mysth)]

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.

[Mampf F. (mampf)]

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?

[Harry L. (mysth)]

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.

[Frank M. (ukw) (Moderator)]

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.

[Mampf F. (mampf)]

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 :)

[Ralph S. (jjflash)]

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.

[Rene K. (xdraconix)]

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.

[Andreas B. (bitverdreher)]

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.

[Falk B. (falk)]

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.

[Rene K. (xdraconix)]

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.

[Mampf F. (mampf)]

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

[Harald K. (kirnbichler)]

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 ...

[C-hater (c-hater)]

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.

[Harald K. (kirnbichler)]

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.

[J. S. (jojos)]

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.

[C-hater (c-hater)]

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.

[Stefan F. (Gast)]

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.

[C-hater (c-hater)]

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...

[Stefan F. (Gast)]

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.

[C-hater (c-hater)]

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?

[C-hater (c-hater)]

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?

[Stefan F. (Gast)]

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.

[C-hater (c-hater)]

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...

[Stefan F. (Gast)]

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.

[C-hater (c-hater)]

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..

[Stefan F. (Gast)]

> 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.

[C-hater (c-hater)]

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...

[Harald K. (kirnbichler)]

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.

[Christoph M. (mchris)]

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

[Tim . (cpldcpu)]

Schafft es hier wirklich niemand mehr, objektiv über aktuelle 
MCU-Familien zu diskutieren?

[Andreas B. (bitverdreher)]

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.

[J. S. (jojos)]

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.

[Andreas B. (bitverdreher)]

Danke! Das mit dem SCT cookbook ist ein guter Tip. Das werde ich mir bei 
Gelegenheit mal reinziehen.

[Christoph M. (mchris)]

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.

[Tim . (cpldcpu)]

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...

[Mampf F. (mampf)]

So oft bin ich wohl noch nie zitiert worden 😂

[Harald K. (kirnbichler)]

Ach, irgendwann weht dieser Pesthauch über jeden hinweg - mich hats auch 
schon erwischt.
Würde Andreas noch aktiv an der Forensoftware arbeiten, ließen sich die 
"moby"-Postings recht leicht reduzieren (man müsste nur bei den ersten X 
Beiträgen von neuen Benutzern irgendein Captcha lösen lassen und eine 
gewisse Zwangspause zwischen Einzelbeiträgen einbauen, die erst nach Y 
Beiträgen verschwindet. Heise online beispielsweise erlaubt nur einen 
Beitrag pro Minute, würde man für Neulinge diese Pause auf fünf Minuten 
erhöhen, wäre kein großer Schaden angerichtet - außer, daß "moby" es 
nicht mehr so leicht hat, seine Sülze abzukippen).

[Harald K. (kirnbichler)]

Moby A. schrieb im Beitrag #7435792:
> Werd hier Moderator.

Moderatoren haben keinen Einfluss auf die Forensoftware. Ich werd' nicht 
darauf eingehen, woher ich das weiß.

[Falk B. (falk)]

Sollte man die Diskussionen nicht einfach schließen. Allein um unserem 
Patienten keine weitere Spielwiese zu bieten?

[Ralph S. (jjflash)]

Falk B. schrieb:
> Sollte man die Diskussionen nicht einfach schließen. Allein um unserem
> Patienten keine weitere Spielwiese zu bieten?

Guter Ansatz ! Leider würde dann eine (aber eher unwahrscheinliche) 
Diskussion um einen Low-cost 32-Bit Controller auch nicht mehr möglich 
sein.

[Ingo W. (uebrig)]

Ralph S. schrieb:
> Leider würde dann eine (aber eher unwahrscheinliche)
> Diskussion um einen Low-cost 32-Bit Controller auch nicht mehr möglich
> sein.

Außerdem könnte er dies auch als Erfolgserlebnis empfinden.

[Arduino F. (Firma: Gast) (arduinof)]

Falk B. schrieb:
> Sollte man die Diskussionen nicht einfach schließen.
Das ist eine Abhilfe.

Falk B. schrieb:
> Allein um unserem
> Patienten keine weitere Spielwiese zu bieten?
Das ganze Forum schließen...
Dann hat der Frosch im Brunnen sein Ziel erreicht.

[Falk B. (falk)]

Arduino F. schrieb:
> Dann hat der Frosch im Brunnen sein Ziel erreicht.

Hast du einen Storch oder ähnliches Frosch-Gegenmittel? ;-)

[Arduino F. (Firma: Gast) (arduinof)]

Falk B. schrieb:
> Hast du einen Storch oder ähnliches Frosch-Gegenmittel? ;-)
Keine legalen.

Der Betreiber könnte eine einstweilige Verfügung erwirken.
Würde dann bis Haft gehen.... evtl. auch Klappse.

[Mampf F. (mampf)]

Ingo W. schrieb:
> Außerdem könnte er dies auch als Erfolgserlebnis empfinden.

Das ist quatsch ... Entweder ihr lasst den Post oder ihr kickt den User.

Denn, ein Skript, das kuckt, wann ein eigener Post gelöscht wurde und 
ihn dann gleich vollautomatisch neu postet - zB mittels Python + 
Selenium - ist in windeseile programmiert.

Kann man beliebig ausbauen^^

[Heinrich K. (minrich)]

"So" ärgert es den moby-troll aber viel besser, schöner, umfassender.

Wann immer er seinen Müll hier ablädt, zzzzzzzapp, ab damit in den Müll.

Sein Aufruf zum Strassenkampf, zur konterrevolutionären Massenbewegung 
der armen, ausgebeuteten Arbeiter, brennende Hörsääle, Rudi Dutschke am 
Mikrofon...

..wegen seines "Hausverbots" im mc.net

...all das bleibt aus. Es kümmert keinen. Dann ist moby halt gesperrt 
und bleibt halt gesperrt.

[Arduino F. (Firma: Gast) (arduinof)]

Mampf F. schrieb:
> oder ihr kickt den User.
Offensichtlich liegt dein Erkenntnislevel bei bestenfalls 10% in dieser 
konkreten Sache.

[Andreas B. (bitverdreher)]

Warum macht man der Thread nicht einfach mal zu?
Moby fuehrt doch eh nur noch Selbstgespraeche.

[J. S. (jojos)]

Klassischer Honeypot. Wird teuer für ihn.