mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Neue MCU familie gesucht


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Gerd K. (gerd_knese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

Ich bin auf der Suche nach einer neuen MCU famile.

Bisher habe ich vorwiegend mit MSP430 gearbeitet aber 25 MHz max. Clock 
sind für einige Anwendungen einfach nicht genug Leistung.

Ich habe mich zwischenzeitlich mal am STM32L4 versucht aber mit dem bin 
ich nicht wirklich warm geworden (ARM Cortex ist nicht wirklich 
Einsteigerfreundlich).

Was ich bräuchte wäre ein MSP430 mit min. 100 Mhz. Den gibt es aber 
leider noch nicht.

Anforderungen:
- >= 100 MHz CPU Takt
- Low Power (ähnlich oder besser als MSP430)
- Einfach zu programmieren (also bitte kein ARM Cortex)

Was wäre eurer Meinung nach eine Alternative?

Bin sehr gespannt

Danke
Gerd

Autor: torusle (Gast)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
Was war denn am Cortex so schwierig? Ich finde die sind so einfach zu 
programmieren das es fast schon langweilig ist.

Autor: Gerd K. (gerd_knese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi torusle,

torusle schrieb:
> Was war denn am Cortex so schwierig? Ich finde die sind so einfach zu
> programmieren das es fast schon langweilig ist.

Ich vermute, weil ich bevorzuge alle meine Bibliotheken selber zu 
schreiben und alle Register selber zu kontrollieren, fällt mir lediglich 
der Einstieg sehr schwer. Ich bin halt in mancher Hinsicht ein wenig 
"old school". D.h. die Basics fehlen.

Vieleicht war (wie auch schon in einem anderen Post zum STM32L4 erwähnt) 
die Wahl des STM32L4 zum Einstieg in die ARM Cortex Welt auch die 
falsche Wahl.

Gruss
Gerd

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd K. schrieb:
> - Einfach zu programmieren (also bitte kein ARM Cortex)

Die STM32 sind eher komplex und ohne HAL schwer verdaulich.

Schau Dir mal Nordicsemi NRF52xxx oder Silabs EFM32 an. Die sind 
"stromsparend" und haben IMHO einfacher zu verstehende Peripherials 
verglichen mit STM32.

Cortex-M >100 MHz ist eher auf "Performance" denn "Stromspar" ausgelegt.

Autor: Gerd K. (gerd_knese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Jim M.

Jim M. schrieb:
> Cortex-M >100 MHz ist eher auf "Performance" denn "Stromspar" ausgelegt.

Daher ja der STM32L4. Der L4+ ist recht low power und kann bis zu 120 
MHz.

Gruss
gerd

: Bearbeitet durch User
Autor: torusle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd K. schrieb:
> Ich vermute, weil ich bevorzuge alle meine Bibliotheken selber zu
> schreiben und alle Register selber zu kontrollieren, fällt mir lediglich
> der Einstieg sehr schwer. Ich bin halt in mancher Hinsicht ein wenig
> "old school". D.h. die Basics fehlen.

Ich denke, das ist das Problem. Geht mir ja nicht anders. Wenn ich den 
HAL Code sehe, dann juckt es mich auch in den Fingern den Kram lieber 
für meinen Anwendungsfall neu zu schreiben.

Ich bin mittlerweile aber vernünftig geworden und nutze einfach die HAL. 
Falls dann wirklich mal die Performance nicht reicht kann ich immer noch 
optimieren. Passiert allerdings nie, weil es bislang immer schnell genug 
war.

Ich bin übrigens Fan der LPC17xx MCUs von NXP. Da sind die Peripherie 
Blöcke gut beschrieben und beherrschbar (wenn man von USB und Ethernet 
mal absieht).

Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd K. schrieb:
> - >= 100 MHz CPU Takt
> - Low Power (ähnlich oder besser als MSP430)

beides ist leider nicht leicht miteinander vereinbar.

Ich verwende zwei Plattformen:

1) MSP430G (ohne BS) für periphere, hardware-nahe Anwendungen und
2) den Raspberry (mit Linux) für  komplexe Anwendung,  wo meist auch 
Power verlangt wird.

Reicht die Leistung eines MSP's nicht aus, dann verteile ich die 
Aufgaben oder Last auf mehrere MSP's.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GEKU schrieb:
> Gerd K. schrieb:
>> - >= 100 MHz CPU Takt
>> - Low Power (ähnlich oder besser als MSP430)
>
> beides ist leider nicht leicht miteinander vereinbar.

Äh doch?
Wenn man die Rechenleistung kurz braucht taktet man hoch um danach 
wieder zu schlafen.

@ Gerd K:
Wo hats denn beim L4 Einstieg genau gehapert?
Jede Peripherie ist im RefMan doch ausführlichst erklärt mit 
Schrittanleitungen wie diese zu nutzen ist.
Danach kommen dann die Register und Bitdefinitionen.

Ansonsten immer das gleiche Schema:
Takt einschalten für die Periph
GPIO Einstellen (wenn diese raustelefonieren will)
Periph Einstellen.

Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man könnte auch MCU's mit FPGA's kombinieren.

Schnell Aufgaben lasse ich FPGA's erledigen, komplexe, wie zum Beispiel 
IP Kommunikation vom Raspberry.

Der Raspberry sorgt dann auch die Updatefähigkeiten des FPGA's aus der 
Ferne.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GEKU schrieb:
> Man könnte auch MCU's mit FPGA's kombinieren.

Man könnt jetz auch langsam mal aufhören Murks zu labern ;)
FPGA sind jetz wirklich nix für Lowpower.
Guck dir die Powerstates der L4 an und sei leise.

Autor: Gerd K. (gerd_knese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Mw E.

Mw E. schrieb:
> @ Gerd K:
> Wo hats denn beim L4 Einstieg genau gehapert?
> Jede Peripherie ist im RefMan doch ausführlichst erklärt mit
> Schrittanleitungen wie diese zu nutzen ist.
> Danach kommen dann die Register und Bitdefinitionen.
>
> Ansonsten immer das gleiche Schema:
> Takt einschalten für die Periph
> GPIO Einstellen (wenn diese raustelefonieren will)
> Periph Einstellen.

Ja, so hatte ich mir das auch gedacht. Dann hatte ich zuerst mit dem 
CubeMX und Inkompartibilität zur frühen Version des TrueStudios zu 
kämpfen. Ausserdem konnte ich einfach nicht herausfinden, wie die 
dieversen HAL Funktionen zu nutzen sind. Möglicherweise habe ich aber 
auch zu früh aufgegeben.

Welches ist eigentlich die beste IDE für den Einstieg?

Ich denke, ich sollte es nochmal versuchen.

Gruss

Gerd

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Diese HAL nutzt man ja auch nicht, die ist einfach nur gruselig und 
aufgeblasen.

Aus dem CubeMX kann man sich die CMSIS Header ziehen und schon haste 
alle Bits aus dem RefMan zur Verfügung.

Der CubeMX ist ganz gut um die Pinbelegung zu bauen, denn die Peripherie 
IOs kommen an mehr als einem Pin raus.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd K. schrieb:
> Bisher habe ich vorwiegend mit MSP430 gearbeitet aber 25 MHz max. Clock
> sind für einige Anwendungen einfach nicht genug Leistung.

Ich habe gemerkt, daß mangelnde Performance oft an ungenügender 
Programmplanung liegt. Wenn man die Programme nochmal überarbeitet, 
dreht die CPU nur Däumchen, wo sie vorher am Anschlag lief und Tasks 
verzögert hatte. Sehr wichtig ist ein sauberes Profiling, d.h. welche 
Tasks müssen wirklich wie oft ausgeführt werden.
Die Compiler sind zwar schon sehr gut, aber denken können sie noch 
nicht. Daher muß man ihnen auf die Sprünge helfen und z.B. selten 
benötigte Berechnungen aus Schleifen herausziehen und deren Ergebnisse 
zwischenspeichern.

Ich lasse oft einen Timer mitlaufen, der mir die maximale Zeit eines 
Mainloop Durchlaufs in einer Variable speichert, die ich auslesen kann. 
Ich staune oft, wie lächerlich klein dieser Wert ist.

: Bearbeitet durch User
Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man könnte auch MCU's mit FPGA's kombinieren.

Schnell Aufgaben lasse ich FPGA's erledigen, komplexe, wie zum Beispiel 
IP Kommunikation vom Raspberry.

Der Raspberry sorgt dann auch die Updatefähigkeiten des FPGA's aus der 
Ferne.

Mw E. schrieb:
> Guck dir die Powerstates der L4 an und sei leise.

Schaut wirklich gut aus.
Aber wie sieht es mit der Lötarbeiten für "Bastler"?
Was kosten komplette Board?

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FPGAs sind nur für extreme Spezialanwendungen sinnvoll.
Meistens ist ein MC dicke ausreichend.
Ich hab aber auch schon gesehen, daß Leute Relais mit FPGAs ansteuern.

Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> FPGAs sind nur für extreme Spezialanwendungen sinnvoll.

Ist schon auf Grund des Stromverbrauchs nicht sinnvoll.
Außerdem benötigt es neues Knowhow, z.B. VHDL

Da ist der Umstieg auf eine neue Prozessor Familie mit Sicherheit 
leichter.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was an den FPGAs nervt, ist der ständige Generationswechsel. Wir haben 
auch ein Gerät, wo der FPGA nur noch über Broker erhältlich ist. Ob da 
überhaupt ein FPGA nötig war, bezweifle ich, der macht nur über USB ein 
paar DAC-Ausgaben und liest ADCs ein. War eine Fremdentwicklung an einer 
Uni.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GEKU schrieb:
> Aber wie sieht es mit der Lötarbeiten für "Bastler"?

Eigentlich recht gut.
TQFP mit 0,5mm Pinabstand ist noch recht gut zu löten.
Eben nach der Standardmethode "Lötwulzt drüber und dann mit Entlötlitze 
abziehen".

Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Was an den FPGAs nervt, ist der ständige Generationswechsel. Wir
> haben auch ein Gerät, wo der FPGA nur noch über Broker erhältlich ist.
> Ob da überhaupt ein FPGA nötig war, bezweifle ich, der macht nur über
> USB ein paar DAC-Ausgaben und liest ADCs ein. War eine Fremdentwicklung
> an einer Uni.

Solle Mitarbeiter mit akademischer Arbeitsweise hatten wir auch. Da ging 
in erster Linie ums Kennenlernen neuer Produkte und Technologien. Die 
Wirtschaftlichkeit war zweitrangig.

Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> TQFP

Mich haben nur die Ball Grid Arrays abgeschreckt.  Da haben wir für die 
Qualitäts kontrollieren ein Röngengerät benötigt.

TQFP sind kein Problem, die habe ich wohl übersehen.

Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GEKU schrieb:
> TQFP sind kein Problem, die habe ich wohl übersehen

Gibt es das Gehäuse auch für  *STM32L4+*

Autor: M2M (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GEKU schrieb:
> Gibt es das Gehäuse auch für  *STM32L4+*

Ja, 100 und 144 Pin TQFP. Habe direkt bei STM nachgeschaut.

Autor: Irgend W. (Firma: egal) (irgendwer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd K. schrieb:
> Ich vermute, weil ich bevorzuge alle meine Bibliotheken selber zu
> schreiben und alle Register selber zu kontrollieren, fällt mir lediglich
> der Einstieg sehr schwer. Ich bin halt in mancher Hinsicht ein wenig
> "old school". D.h. die Basics fehlen.
>
> Vieleicht war (wie auch schon in einem anderen Post zum STM32L4 erwähnt)
> die Wahl des STM32L4 zum Einstieg in die ARM Cortex Welt auch die
> falsche Wahl.

Wo genau ist dein Problem?
Wirklich bei dem ARM Cortex-M Core?
oder doch eher bei der ST-Herstellerspezifischen Peripherie?

Dir sollte klar sein der der Cortex-M nur den CPU-Kern und einige 
kleiner "Anbauteile" wie den Interruppt handler und den Systick 
einheitlich definiert.
Bei der ganzen Peripherie drumherum kocht jeder Hersteller sein eigenes 
Süppchen. Die ist z.B. bei ST völlig anders als bei NXP die wiederum 
anders ist als bei Atmel usw.

Schau dir eventuell mal den MSP432 an:
https://en.wikipedia.org/wiki/TI_MSP432

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
EFM8 haben bessere Peripherie, sind billiger, und noch einfacher zu 
programmieren. STM8 haben sich inzwischen auch deutlich verbessert.

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke, dass an ARM Cortexe in mancher Hinsicht sogar einfacher 
anzuwenden sind, als 8bit Controller. Zum Beispiel weil sie 32bit Werte 
an einem Stück lesen und schreiben können ohne das Interrupts dazwischen 
funken.

Kompliziert wird die Sache erst durch die Periperie drumherum. Bei STM32 
fällt z.B. auf, dass die meiste Peripherie 16 bit breit angebunden ist.

Versuche mal einen STM32F303. Ich habe hier etwas zusammen geschrieben, 
womit du Dir einen ersten Eindruck verschaffen kannst, wie man den ohne 
Cube HAL programmiert.

http://stefanfrings.de/stm32/stm32f3.html

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir gefallen die Microchip/Atmel SAM controller besser als STM32. Ist 
zwar auch ARM-Cortex, aber die Peripherals sind IMHO viel sauberer.

Autor: 3M (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
> aber die Peripherals sind IMHO viel sauberer

Und Erratas werden in Fünfjahresschüben abgearbeitet.

Da bleibt die Banane lange grün.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd K. schrieb:
> Anforderungen:
> - >= 100 MHz CPU Takt
> - Low Power (ähnlich oder besser als MSP430)
> - Einfach zu programmieren (also bitte kein ARM Cortex)

Mit der Blackfin-Architektur von Analog Devices hatte ich lange Jahre 
gute Laune.
Punkto Leistung pro Stromaufnahme immer noch top, da kommt so mancher 
ARM nicht mit. Ist halt bei der ARM-Core-Flut und (unbegründbarer) 
Second-Source-Paranoia bisschen in die Nische gewandert, auch weil 'DSP' 
drübersteht. Bei allen Stromspar-Komplexitäten die man da ausreizen 
kann, ist der Chip relativ einfach zu programmieren und die 
Dokumentation ist top. Die offiziellen Tools allerdings weniger...

Autor: Gerd K. (gerd_knese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mw E.

Mw E. schrieb:
> Diese HAL nutzt man ja auch nicht, die ist einfach nur gruselig und
> aufgeblasen.
>
> Aus dem CubeMX kann man sich die CMSIS Header ziehen und schon haste
> alle Bits aus dem RefMan zur Verfügung.
>
> Der CubeMX ist ganz gut um die Pinbelegung zu bauen, denn die Peripherie
> IOs kommen an mehr als einem Pin raus.

OK
1. Wie macht man das?
2. Und wie gehts dann weiter?

Gruss
Gerd

Autor: PittyJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verstehe die Probleme nicht so ganz.
Mit dem Arm habe ich doch gar nichts zu tun. Ob da jetzt ein Arm im 
Hintergrund läuft oder ein Mips oder RiscV... das macht doch der 
Compiler für mich. Mit der CPU habe ich doch nichts zu tun.
Ich habe letztens eine Sensorsteuerung zuerst auf einem Arm-A7 mit Linux 
geschrieben, und dann auf Arm-M0 portiert. Letztendlich waren fast nur 
die I2C Zugriffsroutinen anzupassen. Ich hätte auch einen Atmel nehmen 
können.

STM hatte ich auch mal. Da waren die Hardware-Bibliotheken umständlich 
anzusprechen. Aber das hat nichts mit Arm zu tun.
Meine Portierung läuft auf einem NXP-Arm. Die liefern sogar eine 
ROM-Bibliothek mit, die einem ein C-Interface für I2C/UART/etc Zugriff 
bereitstellt. Noch nie so etwas einfaches gehabt.

Autor: Drosius Ingolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin schrieb:
> Mir gefallen die Microchip/Atmel SAM controller besser als STM32. Ist
> zwar auch ARM-Cortex, aber die Peripherals sind IMHO viel sauberer.

Habe ich damals auch gedacht beim Einstieg in die Arm Cortex M Welt. Die 
Doku macht auf den 1. Blick einen tollen Eindruck, aber das Erwachen 
folgt. Allerdings versteht es Atmel, wichtige Infos zu verstecken, 
respektive an Stellen zu erwähnen, auf die man kaum kommt. Deswegen 
hatte ich bei der Treiberprogrammierung des SAM D10D14 einige Probleme. 
So musste ich in  einigen Fällen im Codejungle namens ASF (=HAL) nach 
Antworten suchen, grausam! Auch in amerikanischen Foren hörte man in 
Sachen Atmel Doku oft den Satz: "Documentation sucks". Beim nächsten 
Projekt bin ich auf STM umgestiegen (STM32L431). Die Treiber habe ich in 
wenigen Tagen fertiggestellt ohne jegliche Probleme seitens STM. Seitdem 
nur noch STM! Man bekommt von denen fast zum Selbstkostenpreis die 
Nucleo Evaluationsboards, die Debugger für das SW Interface erhält man 
als chinesischen Nachbau für weniger als 5 €, Atmel verlangt um die 50 € 
für die nackte Platinenversion.

Autor: $$$ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Mit der Blackfin-Architektur von Analog Devices hatte ich lange Jahre
> gute Laune.

Selbiges hier mit TMS320C5XXX von TI.
Besonders schnelle Exemplare mit 300 MHz Takt seit Jahren erhaeltlich.

> Die offiziellen Tools allerdings weniger...

Code Composer ist frei verfuegbar.
Der einzige saure Apfel sind vielleicht die Preise fuer JTAGs
wenn man mit den einfachen FTDI-Adaptern (XDS100) nicht
auskommen will.

Autor: Blackbird (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vor vielen Jahren bin ich von Atmel-Controllern auf EFM32-Controller 
umgestiegen, "gleitend" :) Beruflich und auch privat.
Habe es nicht bereut und mit den EFM32- und EFM8-Controllern und den 
günstigen Developmentboards mehr machen können, als es die 
Atmel-Controller je konnten.

Blackbird

Autor: Uwe M. (drosiusingolf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Blackbird schrieb:
> Vor vielen Jahren bin ich von Atmel-Controllern auf EFM32-Controller
> umgestiegen,

Glückwunsch, aber auch die basieren auf der Arm Cortex M Familie, die 
der Gerd L. leider nicht mag! :-(

Autor: Lothar J. (black-bird)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe M. schrieb:
> Blackbird schrieb:
>> Vor vielen Jahren bin ich von Atmel-Controllern auf EFM32-Controller
>> umgestiegen,
>
> Glückwunsch, aber auch die basieren auf der Arm Cortex M Familie, die
> der Gerd L. leider nicht mag! :-(

Na dann muss er eben auf MSP432 umsteigen und in dieser Liga bleiben.

Blackbird

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PIC32 gibts auch noch. Kein ARM drin, sondern MIPS. Ich bezweifle 
freilich auch, dass wirklich der Kern von Bedeutung ist

Mit dem Drumrum von Microchip (8/16) bin ich allerdings nicht wirklich 
warm geworden.

: Bearbeitet durch User
Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar J. schrieb:
> Na dann muss er eben auf MSP432 umsteigen und in dieser Liga bleiben.

Das ist ein Cortex M4F.

Gerd K. schrieb:
> Ich habe mich zwischenzeitlich mal am STM32L4 versucht aber mit dem bin
> ich nicht wirklich warm geworden (ARM Cortex ist nicht wirklich
> Einsteigerfreundlich).

Wo genau hing es denn beim Kern? Beim NVIC?

Gerd K. schrieb:
> Anforderungen:
> - >= 100 MHz CPU Takt
> - Low Power (ähnlich oder besser als MSP430)

Wie kommen denn diese sehr konträren Anforderungen zu stande? Wieso 
müssen es gleich 100MHz (bei 32Bit) sein, wenn 25MHz (bei einem 
16-Bitter!) nicht mehr ausreichen?

Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> MSP432

hat nichts mehr mit der Architektur des MSP430 zu tun, der sich an die 
PDP11 angelehnt hat.

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lerne bitte korrekt zu zitieren.

GEKU schrieb:
> Christopher J. schrieb:
>> MSP432
>
> hat nichts mehr mit der Architektur des MSP430 zu tun, der sich an die
> PDP11 angelehnt hat.

Ja, denn:

Christopher J. schrieb:
> Das ist ein Cortex M4F.

Stand im übrigen nur eine Zeile darunter.

Autor: I. C. Reader (Gast)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Gerd K. schrieb:
> Ich vermute, weil ich bevorzuge alle meine Bibliotheken selber zu
> schreiben und alle Register selber zu kontrollieren,

Ach so, du bist im letzten Jahrhundert stecken geblieben. Sag das doch 
gleich. Heutzutage benutzt man STM32 mit CubeMX, dad schreiben sich die 
Programme fadt von selbst.

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I. C. Reader schrieb:
> da schreiben sich die Programme fast von selbst.

Aber nur solange man dem
a) Marketing Blabla glaubt,
b) den Zeitwaufwand für das das Lernen von doppelt so viel Doku nicht 
mit zählt (HAL Doku erstzt nicht das Referenzhandbuch),
c) wenn man den Zeitaufwand für Reverse-Enginnering der HAL (mangels 
ordentlicher Doku) nicht mit zählt, und
d) noch nicht mehrfach auf Bugs gestoßen ist, die einem ganze 
Wochenenden gekostet haben (wenn schon triviale Hello-World Projekte 
versagen, denkt man sich seinen Teil).

Ich glaube ja gerne, dass erfahrende STM32 Spezialisten damit gut klar 
kommen. Für mich gibt es aber noch ein Leben jenseits von ST.

Ich bin eher einer der Sorte, die mit Referenzhandbüchern und 
Datenblättern arbeiten. Meine Methode passt eher dazu, dass ich ST nicht 
unbedingt "heiraten" möchte. Auch andere Firmen haben tolle 
Mikrocontroller hervorgebracht.

: Bearbeitet durch User
Autor: Harry L. (mysth)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> b) den Zeitwaufwand für das das Lernen von doppelt so viel Doku nicht
> mit zählt (HAL Doku erstzt nicht das Referenzhandbuch),

Stimmt, das Referenzhandbuch braucht man trotzdm, aber von der doppelten 
Menge Doku kann nicht die Rede sein.

Stefanus F. schrieb:
> c) wenn man den Zeitaufwand für Reverse-Enginnering der HAL (mangels
> ordentlicher Doku) nicht mit zählt

Ordentliche Doku gibts zu Hauf, aber du hast die offenbar nicht 
gefunden.

Jedes Framework benötigt eine Einarbeitung, aber die Zeit ist gut 
investiert, da man die später vielfach einspart, und die Namensgebung 
ist bei HAL weitgehend so konsistent, daß man bereits nach kurzer Zeit 
ganz intuitiv die richtigen Funktionen findet.

Stefanus F. schrieb:
> noch nicht mehrfach auf Bugs gestoßen ist, die einem ganze
> Wochenenden gekostet haben

Und du glaubst wirklich selber weniger Bugs zu produzieren? - ich nicht!

Sieht man u.A. daran, daß du dich immer noch mit so elementaren Dingen 
wie Takt-Konfiguration herum ärgerst, die CubeMX weitgehend fehlerfrei 
auf Knopfdruck generiert, und während die CubeMX-User schon längst an 
ihrer eigentlichen Aufgabe arbeiten.

Wie lange hast du daran herumgefummelt?
Beitrag "STM32 läuft mit Debugger schneller als er soll"

Kratzt das an deiner Programmierer-Ehre, daß eine Software sowas besser 
und schneller kann als du oder bist du nur zu faul oder unfähig Neues zu 
lernen?

Autor: stm32er (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Man sollte eines nicht vergessen: Wenn man einmal alle wichtigen 
Funktionalitäten grob beispielhaft durchgespielt hat (kostet ev. 1 
Woche) dann kann man alle seine Projekte darauf basieren lassen. Ich 
fand es nicht sehr schwer. Es gibt viele Beispiele im Netz. Ich nutzte 
immer die peripheral Lib zum initialisieren und wenn manche 
Funktionalitäten zu langsam waren, habe ich mir die betreffenden 
Register-Operationen einfach aus der Lib kopiert und etwas abgespeckt. 
Geht super!

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Harry L. schrieb:
> Sieht man u.A. daran, daß du dich immer noch mit so elementaren Dingen
> wie Takt-Konfiguration herum ärgerst, die CubeMX weitgehend fehlerfrei
> auf Knopfdruck generiert, und während die CubeMX-User schon längst an
> ihrer eigentlichen Aufgabe arbeiten.
>
> Wie lange hast du daran herumgefummelt?
> Beitrag "STM32 läuft mit Debugger schneller als er soll"

Man soll ja nicht auf Boshaftigkeit was man adäquat durch Dummheit 
erklären kann... Wenn man den "läuft mit Debugger schneller" gelesen und 
verstanden hätte würde man nicht so einen "Angriff" reiten. Das Problem 
hatte rein gar nichts mit CubeMX ja oder nein zu tun und tritt bei einer 
CubeMX generierten Clock-Initialisierung genauso auf.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hach der HAL Fanboy Harry ist wieder da...

Harry L. schrieb:
> Sieht man u.A. daran, daß du dich immer noch mit so elementaren Dingen
> wie Takt-Konfiguration herum ärgerst, die CubeMX weitgehend fehlerfrei
> auf Knopfdruck generiert, und während die CubeMX-User schon längst an
> ihrer eigentlichen Aufgabe arbeiten.
>
> Wie lange hast du daran herumgefummelt?
> Beitrag "STM32 läuft mit Debugger schneller als er soll"
>
> Kratzt das an deiner Programmierer-Ehre, daß eine Software sowas besser
> und schneller kann als du oder bist du nur zu faul oder unfähig Neues zu
> lernen?

Wenn du den Fred ordentlich gelesen hättest, dann hätteste erkannt, dass 
da ein Debugscript zwischengefunkt hat.
Wenn du den Fred ordentlich gelesen hättest, dann hätteste erkannt, dass 
ich da ein Gegenbeispiel gepostet habe mit der CubeMX macht das super 
mit dem Takt.
Nur weil du nicht lesen kannst musste jetz nich auf Stefanus rumhacken.

Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> Das Problem
> hatte rein gar nichts mit CubeMX ja oder nein zu tun

Klar hat das nix damit zu tun, und ads hab ich auch nicht behauptet, 
weil Stefan ja grundsätzlich alles besser kann und besser weis als ST...

Aber trotzdem wird er nicht müde, HAL in Grund und Boden zu schreiben, 
obwohl er davon -nachweislich- überhaupt keine Ahnung hat....

Mw E. schrieb:
> Wenn du den Fred ordentlich gelesen hättest, dann hätteste erkannt, dass
> ich da ein Gegenbeispiel gepostet habe mit der CubeMX macht das super
> mit dem Takt.

Ich kann schon richtig lesen, aber du hast scheinbar 
Verständnis-Probleme mit meinem Beitrag....s.o.

Was seid ihr?
Stefans persönliche Fanboys?

: Bearbeitet durch User
Autor: Ralph S. (jjflash)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
... außer CubeMX gibts ja auch noch libopencm3.

Irgendwie erschließt sich mir aus meiner Sicht der Dinge damit 
Funktionalitäten eines STM32 bei der Durchsicht der Sourcen schneller 
als mit HAL.

Damit ist auch mein bevorzugtes Gespann, Editor + Makefile, schneller am 
funktionieren als mit HAL (was aber wohl zugegebenerweise auch daran 
liegt, dass ich mich mit libopencm3 deutlich länger beschäftigt habe als 
mit HAL).

Grundsätzlich denke ich, wird es einem bei der Einarbeitung in einen 
Abstraktionslayer, genügend Zeit und graue Haare kosten, bis das flüssig 
geht.

libopencm3 kommt mir in gewisser Weise entgegen, weil meine persönliche 
Arbeitsweise lieber mit Zeigern auf Register arbeitet, die ich dann bei 
Bedarf wie im Referenzmanual einfach beschreiben kann und keine struct 
verwenden muss.

Wer lieber mit den structs arbeitet sollte dann die HAL nehmen. Meine 
Glaskugel jedoch sagt mir, dass der TO lieber mit den Zeigern auf 
Register arbeitet (weil er seine Bibliotheken selbst schreiben mag).

Prinzipiell wäre für den TO eben doch noch einmal ein Blick auf ARM 
nicht schlecht, hier aber vielleicht dann doch auf NXP der - aus meiner 
Sicht der Dinge - logischer aufgebauten Peripherie... und das ganze mit 
libopencm3 ?!?

Autor: temp (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Harry L. schrieb:
> Aber trotzdem wird er nicht müde, HAL in Grund und Boden zu schreiben,
> obwohl er davon -nachweislich- überhaupt keine Ahnung hat....

Man braucht nicht viel Ahnung haben um die HAL zu hassen. Wer mal mit 
der StmPerfLib angefangen hat ist sicherlich geheilt. Will man ein altes 
Projekt auf einen neueren Chip portieren bei dem es nur noch HAL gibt, 
schreibt man es neu. Und übermorgen gibt es dann die natürlich viel 
bessere Hallali-Lib bei der man wieder von vorn anfängt. Aber so wie man 
immer mal wieder zum Arzt gehen sollte weil der ja auch leben muss, 
sollte man die STM Ergüsse von Libs auch verwenden damit die 
Praktikanten nicht arbeitslos werden...

Wenn Harry L. die HAL wie Arduino benutzt hat er vielleicht recht. Wie 
man aber die Möglichkeiten z.B. eines HiRes-Timers aus dem STM32F334 auf 
die HAL in leicht verständlicher Form abbilden will erschließt sich mir 
nicht. Ohne das RefMan dazu fast auswendig zu kennen geht da nichts. 
Auch nicht mit der HAL. Die GPIO Funktionen sind ja z.T. noch 
selbsterklärend, die der Spezialtimer nicht. Und wenn man mit dem 
Debugger in die Register schaut muss man sie auch verstanden haben. Da 
investiere ich die Zeit lieber in das Verständniss der RefManuals als in 
diesen Brocken von HAL.

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Harry L. schrieb:
> Und du glaubst wirklich selber weniger Bugs zu produzieren? - ich nicht!

Sicher nicht, aber ich habe meinen selbst erstellten Code besser im 
Griff, als fremden Code.

> Sieht man u.A. daran, daß du dich immer noch mit so elementaren Dingen
> wie Takt-Konfiguration herum ärgerst, die CubeMX weitgehend fehlerfrei
> auf Knopfdruck generiert

Eben nicht. Gleich mein erstes Projekt stürzte bei der 
Takt-Konfiguration ab, weil der Cube Code ein Bit falsch setzte.

Der erste Eindruck zählt. Bei mir war der nicht so gut. Und der zweite 
auch nicht. Und der dritte wieder nicht.

Tatsächlich benutze ich Cube Mx auch ab und zu als Inspiration, aber ich 
verlasse mich nicht darauf.

> Aber trotzdem wird er nicht müde, HAL in Grund und Boden zu schreiben,
> obwohl er davon -nachweislich- überhaupt keine Ahnung hat....

Korrekt, ich habe von der HAL keine Ahnung. Jedenfalls nicht genug, um 
anderen zu erklären, wie man sie richtig benutzt. Ich habe allerdings 
meine drei schlechten Erfahrungen genacht und ich habe auch in völlig 
anderen Umfeldern mit Frameworks Erfahrungen gemacht. Diese Erfahrung 
sagt mir: Benutze Frameworks mit Bedacht und übertreibe es damit nicht.

Tut mir Leid, wenn meine Kommentare nach "Grund und Boden" klingen, so 
schlimm war es nicht gemeint.

: Bearbeitet durch User
Autor: stm32er (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wer mal mit
> der StmPerfLib angefangen hat ist sicherlich geheilt.

findest du die Lib schlecht?

Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Lothar schrieb:
> EFM8 haben bessere Peripherie, sind billiger, und noch einfacher zu
> programmieren. STM8 haben sich inzwischen auch deutlich verbessert.

Ich weiß nicht, wieviel der EFM8 besser als der Vorgänger C8051 ist 
(auch wenn ich schätze, dass es da gar nicht nicht so viel Unterschied 
gibt), aber:

Nach meiner Erfahrung ist STM8 in Bezug auf Codegröße und 
Geschwindigkeit deutlich besser als MCS-51. Einfacher zu programmieren 
sind sie auch. Die Architektur des STM8 passt insbesondere viel besser 
zu C als die meisten anderen Architekturen, die bei µC üblich sind.

Vor einiger Zeit hatte ich Vergleiche mit SDCC 3.7.0 und ein paar 
Benchmarks gemacht.

stdcbench 0.4 c90base Score. Jeweils mit Optimierung auf Geschwindigkeit 
kompiliert (damit liegt die Codegröße bei MCS-51 etwa beim doppelten von 
STM8):

C8051F120@98Mhz: 95
STM8AF5288@16Mhz: 109
STM8S208MB@24Mhz: 147

zum Vergleich: Weitere µC mit SDCC 3.7.0 bzw. GCC 6.3.1:

CY7C68013A@48Mhz: 12
STM32L073RZ@32Mhz: 717
STM32F051R8@48Mhz: 1141
STM32F103RB@36Mhz: 1158
STM32F302R8@64Mhz: 1693

Bei stdcbench 0.4 erhält man für den STM8 mit Cosmic und Raisonance 
ähnliche Scores wie mit SDCC 3.7.0. Aber IAR kann mehr (allerdings auf 
Kosten deutlich höhere Codegröße). Hier ein Ergebnis mit 3.10.1.102:

STM8AF5288@16Mhz: 189

stdcbench erfordert Reentranz, was beim MCS-51 etwas umständlich ist. 
Aber selbst wenn man einen Benchmark nimmt, der ohne auskommt, wie 
Dhrystone 2.1, ist die Codegröße bei MCS-51 ca 30% höher als beim STM8, 
und der Score / Mhz beim STM8 etwa 10 mal so hoch wie beim C8051.

Eigentlich sollte ich die Experimente wohl nochmal mit aktuelleren 
Compilern, mit dem aktuellen stdcbench 0.6, und unter Einbeziehung von 
weiteren Architekturen wiederholen, und dann die Ergebnisse auf eine 
Website stellen.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp Klaus K. schrieb:
> Die Architektur des STM8 passt insbesondere viel besser
> zu C als die meisten anderen Architekturen, die bei µC üblich sind.

Im Ernst jetzt? Das Ding hat eine Akkumulator-Architektur.

Autor: MSP ist gut, (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Wieder soviel Mist von der Fan-Antifraktion.

Natürlich kann man problemlos mit CubeX und HAL den STM32 befeuern. Da 
hat man schnell was am Laufen und kann sich auf die echte 
Problemstellung konzentrieren.
Wer anschließend vor Langeweile umkommt, kann das Ganze scheibchenweise 
von Hand nachbauen und sich seine eigene Makro-HAL gestalten.

Der MSP432 ist zwar auch ein ARM, aber die Peripherie ist gleich dem 
MSP430. Genau für Umsteiger wie dich wurde der entwickelt.

Lass dir von Stefan und seinem Boy nicht so einen Scheiss erzählen. Das 
sind halt keine Teamplayer. 😥

Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Philipp Klaus K. schrieb:
>> Die Architektur des STM8 passt insbesondere viel besser
>> zu C als die meisten anderen Architekturen, die bei µC üblich sind.
>
> Im Ernst jetzt? Das Ding hat eine Akkumulator-Architektur.

Ja. Der STM8 hat einen effizienten Stackpointer-relativen 
Adressierungsmodus. Er hat einen Softwarestack. Einen einheitlichen 
Adressraum. Multiplizierer, Dividierer.

Das macht ihn zu einer besseren Zielarchitektur für C-Compiler als z.B. 
MCS-51, PIC, HC08, S08, Padauk, Z80-Derivate.

: Bearbeitet durch User
Autor: Holm T. (holm)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> I. C. Reader schrieb:
>> da schreiben sich die Programme fast von selbst.
>
> Aber nur solange man dem
> a) Marketing Blabla glaubt,
> b) den Zeitwaufwand für das das Lernen von doppelt so viel Doku nicht
> mit zählt (HAL Doku erstzt nicht das Referenzhandbuch),
> c) wenn man den Zeitaufwand für Reverse-Enginnering der HAL (mangels
> ordentlicher Doku) nicht mit zählt, und
> d) noch nicht mehrfach auf Bugs gestoßen ist, die einem ganze
> Wochenenden gekostet haben (wenn schon triviale Hello-World Projekte
> versagen, denkt man sich seinen Teil).
>
> Ich glaube ja gerne, dass erfahrende STM32 Spezialisten damit gut klar
> kommen. Für mich gibt es aber noch ein Leben jenseits von ST.
>
> Ich bin eher einer der Sorte, die mit Referenzhandbüchern und
> Datenblättern arbeiten. Meine Methode passt eher dazu, dass ich ST nicht
> unbedingt "heiraten" möchte. Auch andere Firmen haben tolle
> Mikrocontroller hervorgebracht.

Genau so sehe ich das auch, ich bin auch der Überzeugung das es keinen 
"besten Controller" gibt mit dem man Alles ultimativ erschlagen bekommt.

Seit C-Compiler für die meisten Mikros problemlos zu haben sind gibts 
doch kaum noch relevante Unterschiede die einen Einsatz 
ermöglichen/verunmöglichen, man kann relativ problemlos nach benötigter 
Leistung skalieren, auch über Typen hinweg. Die größten Unterschiede 
macht dabei IMHO die verfügbare Peripherie oder welches RTOS (falls 
benötigt) benutzt werden kann. Natürlich sollte man keinen 8051 für 
Bildverarbeitung einsetzen wollen..

Früher wurde hier Atmel gehyped, jetzt ist es scheinbar STM..aber auch 
andere Mütter haben schöne Töchter.

Gruß,

Holm

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie steht es eigentlich mit der SDCC Einbindung in Eclipse?

Autor: MSP ist gut, (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
@Holm
Gut erkannt. Die jetzt die HAL verfluchen, haben vor ein paar Wochen 
noch den ARM verflucht. Es ist, wie es ist: Was der Bauer nicht kennt, 
...

@Philipp
Wieviel GP-Register hat der STM8?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Im Ernst jetzt? Das Ding hat eine Akkumulator-Architektur.

Das verhindert lediglich eine schmerzarme Implementierung in 
Compilern-Baukästen wie GCC, die auf Architekturen mit ausreichend 
grossem Registersatz festgelegt sind. Es geht zwar, aber dann landet man 
bei Umgehungslösungen wie Pseudo-Registern im RAM.

An sich ist Codegenerierung für Akkumulator-Architekturen eher einfacher 
als für Register-Architekturen, weil man sich ein paar Gedanken weniger 
machen muss. Es wird vergleichsweise langsamer, aber Tempo ist nicht 
unbedingt das Ziel solcher Architekturen, sondern Hardware-Aufwand.

Interessanter sind die Adressierungsmöglichkeiten. C funktioniert 
besser, wenn die CPU Adressierungsarten relativ zu mindestens 1-2 freien 
und zu Rechnungen fähigen Adressregistern mit voller Adressraumbreite 
sowie zu einem Frame- oder Stackpointer verfügt. STM8S hat das, ebenso 
68HC11/12. Die 8-Bit PICs vor der zweiten Version der PIC18 Architektur 
sowie 8051 können nicht damit dienen, was die Umsetzung komplizierter 
gestaltet.

Hinderlich ist auch eine partielle (STM8S, M16C) oder vollständige (AVR, 
meistens) Adressraumtrennung. Allerdings mittlerweile eher für den 
Programmierer, der sich damit rumärgern muss, als für einen Compiler.

MSP ist gut, schrieb:
> Wieviel GP-Register hat der STM8?

Jenseits kleiner praktisch nur statisch adressierender Programme sind 
Adressregister interessanter als Datenregister. STM8S hat davon 2, plus 
Stackpointer.

: Bearbeitet durch User
Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Wie steht es eigentlich mit der SDCC Einbindung in Eclipse?

Es gibt ein Eclipse-Plugin für SDCC, das wohl manche mit Erfolg 
verwenden (sogar mit Einbindung von on-Target-debugging für STM8 via gdb 
und OpenOCD); andere haben Probleme damit.
Da müsste wohl jemand, der sich mit Eclipse und Java ein bischen 
auskennt drübersehen, und ein paar kleinere Aktualisierungen vornehmen.

Zur Zeit hat wohl Code::Blocks die beste SDCC-Unterstützung, auch wenn 
es auch dort noch Verbesserungspotential gibt.

Philipp

Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MSP ist gut, schrieb:
> @Holm
> Gut erkannt. Die jetzt die HAL verfluchen, haben vor ein paar Wochen
> noch den ARM verflucht. Es ist, wie es ist: Was der Bauer nicht kennt,
> ...
>
> @Philipp
> Wieviel GP-Register hat der STM8?

Es gibt den Akkumulator a und 2 Adressregister x und y (letztere lassen 
sich in vielen Fällen als 16-Bit-GP-Register nutzen, der Zugriff auf Y 
ist aber oft ineffizienter als auf X). Aber durch den effizienten 
Zugriff auf Variablen auf dem Stack ist die geringe Anzahl an Registern 
kein Problem.

Philipp

Autor: Helmut S. (helmuts)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich verstehe gar nicht warum hier STM8 in den Ring geworfen wird. Damit 
hat er ja gegenüber dem MSP430 gar nichts gewonnen. Er fragte ja nach 
deutlich mehr Leistung. Der STM8 kann ihm da nicht helfen. Mehr Leistung 
gibt es bei Cortex-ARM 4 und PIC32. Es gibt noch mehr 32bit Familien 
aber die sind bei weitem nicht so verbreitet.

Autor: MSP ist gut, (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Philipp
Das sehe ich anders. Wie nutzt der C Compiler den STM8? Kann und will 
der Compiler auf GP-Register verzichten?

@Helmut
Genau, daher der Hinweis auf MSP432.

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut S. schrieb:
> Ich verstehe gar nicht warum hier STM8 in den Ring geworfen wird

Weil die Diskussion sich lange vom ursprünglichen Thema entfernt hat. 
Und das ist auch gut so. Die Alternative wäre der Tod des Threads.

Denn:

Helmut S. schrieb:
> Er fragte ja nach
> deutlich mehr Leistung. Der STM8 kann ihm da nicht helfen.

Auch sonst kann ihm da keiner helfen. Zumindest so lange nicht, wie er 
nicht bereit ist, über den Tellerrand hinaus zu sehen. Seine "Argumente" 
gegen Cortex-M deuten jedenfalls ganz stark in diese Richtung.

Autor: 645zre (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich würde hier beim L4 oder so bleiben.

Das bisschen HAL_ erklärt sich von allein ... irgendwann
Zumindest findet man genug Beispiele zu irgendwelchen Themen.

Ja ganz bugfrei ist das nicht.  aber wenn ein Bug auftritt wurde das 
auch SO noch nie verwendet. Frage ist bist du der fehler oder die Lib ^^


Aber im grunde ist das alles recht einfach nutzbar.
Cube haut was nutzbares raus und das kann man wenn man bock hat und 
seine applikation läuft auch gern noch in registern umfrickeln

Wenn ich bei jedem Projekt erst anfangen würde die register zu 
zerlegen...
Wann ist die Anwendung fertig?

wenn es nur ein kleines progrämmchen wäre ... ok vieleicht.

aber wenn ich ein M4F oder M7 nutze laufen da auch zig verschiedene 
applikationen.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp Klaus K. schrieb:
> Nach meiner Erfahrung ist STM8 in Bezug auf Codegröße und
> Geschwindigkeit deutlich besser als MCS-51. Einfacher zu programmieren
> sind sie auch. Die Architektur des STM8 passt insbesondere viel besser
> zu C als die meisten anderen Architekturen, die bei µC üblich sind.

Ich fand den 8051 schon sehr codeeffizient und gut für Steuerungen 
optimiert. Viele Befehle sind nur ein Byte lang. Er hat 8 Register, 
wovon 2 als Datenpointer benutzt werden können. Für Interrupts kann man 
die Registerbank umschalten.
Die Bitbefehle sind auch sehr elegant, man kann z.B. das Carryflag in 
einen Pin laden und umgekehrt (für serielle Protokolle). Man kann bis zu 
128 einzelne Bit-Variablen im RAM anlegen, d.h. auch den RAM sehr 
effizient ausnutzen.
Der Keil C51 war auch sehr gut optimiert. Ich hab z.B. auf dem AT89C2051 
(2kB Flash) auch float verwendet.
Man darf nur nicht den Fehler machen, das Large Model auszuwählen. Dann 
landen alle Variablen default im externen RAM-Bereich, d.h. alles muß 
durch den Flaschenhals DPTR gequetscht werden.

Als ich dann mal den AVR-GCC probierte, paßten alte AT89C2051 Projekte 
nicht mehr in den AT90S2313. Der kann nämlich nichts mehr direkt im RAM 
machen, sondern muß alles erstmal in Register laden. Und auch die 
Bitbefehle sind deutlich eingeschränkt.
Atmel hat das leider erst sehr spät erkannt und dann die 8-Pinner mit 
8kB, die 28-Pinner mit 32kB und die 40-Pinner mit 128kB Flash 
ausgestattet.

Autor: Gerd K. (gerd_knese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

Erstmal ganz herzlichen Dank an alle für eure Anregungen.

Ich werde mir den Hinweis von "I. C. Reader", dass ich Zitat: "im 
letzten Jahrhundert stecken geblieben" bin, sehr zu Herzen nehmen und 
mich intensiver mit den diversen ARM Cortex basierenden MCUs 
beschäftigen.

Herzlichen Dank auch an "Stefanus F.". Der Link zu deiner Seite hat mich 
deutlich weiter gebracht.

Ich denke auch, dass früher oder später der Zug in Richtung HAL gehen 
wird aber ich will zuerst einmal (gem. Stefanus F. Anleitungen) den 
Einstieg in die Materie ohne HAL versuchen.

Übrigens, meine Forderung nach "low power" in Kombination mit 100 MHz 
begründet sich in der Idee, die MCU in einem kleinen Roboter mit 
einfacher VGA Kamera zu nutzen. Da Energie immer ein Problem bei 
Robotern ist -> low power und um was sinnvolles mit der Kamera zu machen 
braucht man schon ein wenig Rechenpower -> 100 MHz.

Ich hoffe, ich darf mich wieder melden, wenn ich auf Probleme stosse?

Gruss
Gerd

: Bearbeitet durch User
Autor: Ralph S. (jjflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für erste Experimente mit STM32L4 kannst du auch den Onlinecompiler auf

www.mbed.com

nutzen.

Hier hast du dann ein komplett lauffähiges Framework. Ein angelegtes 
Projekt kannst du bspw. in ein Makefileprojekt (mit arm-none-eabi-g++) 
exportieren und offline weiter bearbeiten.

Allerdings: mbed frisst schon gehörig Hardwareresourcen.

Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut S. schrieb:
> Ich verstehe gar nicht warum hier STM8 in den Ring geworfen wird. Damit
> hat er ja gegenüber dem MSP430 gar nichts gewonnen. Er fragte ja nach
> deutlich mehr Leistung. Der STM8 kann ihm da nicht helfen. Mehr Leistung
> gibt es bei Cortex-ARM 4 und PIC32. Es gibt noch mehr 32bit Familien
> aber die sind bei weitem nicht so verbreitet.

Der STM8 mag nicht reichen (im Ursprungsbeitrag ist ja eine 
Vervierfachung der Rechenleistung gegenüber dem MSP430 gewünscht). Der 
STM8 dürfte zwar pro Takt deutlich mehr rechnen (nahezu alle wichtigen 
Befehle in einem oder zwei Takten), aber es gibt ihn nur bis 24 Mhz 
Takt.
Was vermutlich in erster Linie daran liegt, dass ST dem STM32 keine 
Konkurrenz machen will.
Aber er wurde halt zusammen mit MCS-51 erwähnt, und die Dikussion 
entfernte sich seither etwas vom ursprünglichen Thema.

Wenn man keinen ARM will, wäre RISC-V eine naheliegende Alternative, 
wenn es auf Rechenleistung ankommt.

: Bearbeitet durch User
Autor: Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MSP ist gut, schrieb:
> @Philipp
> Das sehe ich anders. Wie nutzt der C Compiler den STM8? Kann und will
> der Compiler auf GP-Register verzichten?
>
> @Helmut
> Genau, daher der Hinweis auf MSP432.

Das hängt vom Compiler ab. Die meisten Compiler verwenden ein paar 
Speicheraddressen als Pseudo-GP-Register.

SDCC macht das nicht. Er kommt mit dem 8-Bit Akkumulator a, und den 
beiden 16-Bit-Registern x und y aus; ansonsten landen lokale Variablen 
(auch vom Compiler eingeführte temporäre) auf dem Stack; meist generiert 
SDCC besseren Code als die anderen Compiler (ein etwas älterer 
Vergleich, auch im Hinblick auf Codegröße und Performanz findet sich auf 
http://www.colecovision.eu/stm8/compilers.shtml).

Philipp

Autor: Gerd K. (gerd_knese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mw E.

Gerd K. schrieb:
> Hallo Mw E.
>
> Mw E. schrieb:
>> Diese HAL nutzt man ja auch nicht, die ist einfach nur gruselig und
>> aufgeblasen.
>>
>> Aus dem CubeMX kann man sich die CMSIS Header ziehen und schon haste
>> alle Bits aus dem RefMan zur Verfügung.
>>
>> Der CubeMX ist ganz gut um die Pinbelegung zu bauen, denn die Peripherie
>> IOs kommen an mehr als einem Pin raus.
>
> OK
> 1. Wie macht man das (CMSIS Header ziehen)?
> 2. Und wie gehts dann weiter?

Darf ich die beiden o.g. Fragen nochmal an dich richten?

Gruss
Gerd

: Bearbeitet durch User
Autor: Cyblord -. (cyblord)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Gerd K. schrieb:
>> OK
>> 1. Wie macht man das (CMSIS Header ziehen)?
>> 2. Und wie gehts dann weiter?
>
> Darf ich die beiden o.g. Fragen nochmal an dich richten?

Du kannst keine Header Dateien einbinden? Dann ist die MCU Familie wohl 
nicht dein größtes Problem.
Die Header sind in der StdPeriphLib und HAL lib enthalten und können 
dort einfach rauskopiert (vulgo "ziehen") werden.

Wie es dann weiter geht? Man hat alle Register und Bits und kann diese 
nach Datenblatt setzen und lesen und sein Programm schreiben. Ohne 
StdPeriphLib und ohne HAL.

Manche Fragen verblüffen mich schon ein wenig. Und das nach so vielen 
Jahren bei µC.net.

: Bearbeitet durch User
Autor: blokus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
möchte nur mal Renesas ins Spiel bringen, die bringen vielseitige Chips, 
gute Tools und super saubere Doku!

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Cyblord -. schrieb:
[..]
> Manche Fragen verblüffen mich schon ein wenig. Und das nach so vielen
> Jahren bei µC.net.

..mich nicht mehr. Seit Werkzeugen wie AVR-Studio oder auch Arduinos 
sind
die Leute "rundum sorglos Pakete" gewöhnt und die eigentlichen 
Zusammenhänge werde nicht mehr verstanden. Da wird ein serieller Port 
angeclickt und die IDE hat sich drum zu kümmern das die entsprechenden 
Header eingebunden werden...doch nicht etwa der Programmierer....

Deswegen ist Kommandozeile ja auch "pö!".

Gruß,

Holm

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd K. schrieb:
>> 1. Wie macht man das (CMSIS Header ziehen)?

Du mußt dir bei ST die STM32Cube Firmware für deinen µC suchen. 
Einstiegsseite hier:

https://www.st.com/en/embedded-software/stm32cube-mcu-mpu-packages.html

Für die STM32F4xxx liegt der Krempel z.B. hier:

https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-mcu-mpu-packages/stm32cubef4.html

Dann packst du das Dingens aus. Das Package für die STM32F0 bei mir hat 
dann folgende Struktur:

.../STM32Cube/Repository/STM32Cube_FW_F0_V1.4.0/Drivers/CMSIS/Device/ST/ 
STM32F0xx/Include

Da liegen die Headerfiles, die du suchst.

>> 2. Und wie gehts dann weiter?

Du suchst dir ein Tutorial im Web, das deinen µC unter Verwendung der 
CMSIS Header (sprich: ohne HAL, ohne SPL) programmiert. Da siehst du 
dann, welches Headerfile du einbinden mußt, welches DEFINE du brauchst 
(um den µC festzulegen) und was du außerdem brauchst (Startup-Code, 
Linkerskript).

Ich finde wegen seines Minimalismus das Beispiel von hier:
http://eleceng.dit.ie/frank/arm/BareMetalSTM32F0Discovery/blinky.html

sehr instruktiv. Das Zusammenspiel von Linkerskript und Startupcode 
sieht man besonders gut in dieser Variante:
http://eleceng.dit.ie/frank/arm/BareMetalSTM32F0Discovery/cinit.html

weil hier auch der Startupcode in C geschrieben ist.

Durch Linkerskripte und Startupcode muß man sich halt einmal 
durcharbeiten. Ist aber alles recht geradlinig. Danach kopiert man den 
Krempel nur noch. Oder man verwendet ein Framework wie die schon 
angesprochene libopencm3. Im Prinzip zielt libopencm3 auf den gleichen 
Einsatzzweck wie HAL & Co. Ist aber herstellerunabhängig und kennt auch 
andere Cortex-M (nicht von ST).

Autor: Gerd K. (gerd_knese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Cyblord,
Cyblord -. schrieb:
> Gerd K. schrieb:
>>> OK
>>> 1. Wie macht man das (CMSIS Header ziehen)?
>>> 2. Und wie gehts dann weiter?
>>
>> Darf ich die beiden o.g. Fragen nochmal an dich richten?
>
> Du kannst keine Header Dateien einbinden? Dann ist die MCU Familie wohl
> nicht dein größtes Problem.
> Die Header sind in der StdPeriphLib und HAL lib enthalten und können
> dort einfach rauskopiert (vulgo "ziehen") werden.

Das hier ist alles ein gutes Beispiel dafür, wie wichtig der richtige 
Einstieg in so eine Sache ist. In der Zwischenzeit habe ich selbst 
herausgefunden, was das eigentliche Problem war. Da ich offensichtlich 
über die falsche Seite auf die ST Seiten gelangt bin, bin ich 
fälchlicherweise davon ausgegangen, dass STM32CubeMX das Softwarepaket 
ist, dass ich brauche. Jetzt weis ich aber, dass STM32CubeL4 das 
Softwarepaket incl. all der schönen Beispiele ist und STM32CubeMX nur 
das Konfigurationstool darstellt. Ich war also immer auf der Suche nach 
den vielen tollen Beispielen.


> Wie es dann weiter geht? Man hat alle Register und Bits und kann diese
> nach Datenblatt setzen und lesen und sein Programm schreiben. Ohne
> StdPeriphLib und ohne HAL.

Hier ist das Problem wohl eher, dass mir das "wording" der STM32-Welt 
noch nicht geläufig ist. Aber, dass werde ich schon noch lernen.


> Manche Fragen verblüffen mich schon ein wenig. Und das nach so vielen
> Jahren bei µC.net.

Wieso? Wie schon oben erwähnt, sind es häufig die kleinen Dinge, die 
dich vom Erfolg abhalten. Und für genau solche Fragen ist das Forum doch 
da, oder?

Gruss
Gerd

Autor: Gerd K. (gerd_knese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Axel S.

Axel S. schrieb:
> Gerd K. schrieb:
>>> 1. Wie macht man das (CMSIS Header ziehen)?
>
> Du mußt dir bei ST die STM32Cube Firmware für deinen µC suchen.
> Einstiegsseite hier:
>
> https://www.st.com/en/embedded-software/stm32cube-mcu-mpu-packages.html
>
> Für die STM32F4xxx liegt der Krempel z.B. hier:
>
> 
https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-mcu-mpu-packages/stm32cubef4.html
>
> Dann packst du das Dingens aus. Das Package für die STM32F0 bei mir hat
> dann folgende Struktur:


Danke dir, jetzt bin ich endlich auf der richtigen Fährte. Siehe 
vorheriger Post. Hab's zeitgleich mit deinem Post auch herausgefunden.

Gruss
Gerd

: Bearbeitet durch User
Autor: Veit D. (devil-elec)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Cyblord & Holm

Ich bin dabei etwas anderer Meinung. Wenn eine moderne IDE alles bietet 
und man sich nur noch um sein Programm kümmern muss, dann ist das doch 
prima.

Ansonsten müßte sich jeder Autofahrer mit allen Details vom Motor, 
Getriebe, Elektronik usw. auskennen bevor er überhaupt fahren darf.

Warum darf eine IDE diese Vorarbeit nicht abnehmen?

Ich denke auch das fette µC nur noch auf modernen Wege überhaupt 
programmiert werden können, weil die Hardware sonst gar nicht mehr 
beherschbar ist. Vom verlorenden Überblick ganz zu schweigen.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Veit D. schrieb:

> Ich bin dabei etwas anderer Meinung. Wenn eine moderne IDE alles bietet
> und man sich nur noch um sein Programm kümmern muss, dann ist das doch
> prima.

Klar. Nur wenn man sich darauf verlässt oder verlassen muss, hat man ein 
Problem wenn man mal was selbst machen muss. Und genauso war es dann 
halt auch.

> Ansonsten müßte sich jeder Autofahrer mit allen Details vom Motor,
> Getriebe, Elektronik usw. auskennen bevor er überhaupt fahren darf.

Also diese Analogie hat echt nen riesen Bart. Und JA wenn jemand im 
Autoschrauberforum aufschlägt und extrem Tuning machen will, sollte er 
sich damit mehr auskennen als nur den Schlüssel umzudrehen.

> Warum darf eine IDE diese Vorarbeit nicht abnehmen?
Darf. Aber das Wissen um die Hintergründe schaden nicht. Oder man darf 
eben das bequeme Nest dann nie wieder verlassen.

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja,ja den Autovergleich hört man immer wieder. Aber der hinkt. Ein Auto 
ist dafür gemacht, dass man nur die Bedienung beherrschen muss und nicht 
das Innenleben. Ein raspi hat oft ein Linux mit APIs und LIBs, das ist 
normalerweise der Schnittpunkt zum Anwendungsentwickler. Diese 
Zwischenschicht ist beim nackten Controller nicht vorhanden oder nicht 
Standard. Jeder Hersteller will über seine eigenen Libs die Entwickler 
an sich binden damit sie niemals auf die Idee kommen andere Chips zu 
verwenden. Jemand dem das Ref.Manual eines Controller nicht in Mark und 
Knochen steckt kann ich höchstens als Bastler bezeichnen. Aber jeder hat 
halt seine Meinung.

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
temp schrieb:
> Jemand dem das Ref.Manual eines Controller nicht in Mark und
> Knochen steckt kann ich höchstens als Bastler bezeichnen. Aber jeder hat
> halt seine Meinung.

Ist ja komisch. Andere haben mich Bastler genannt, weil ich lieber mit 
Ref. Manual anstatt Cube HAl arbeite.

Wobei ich mich selbst als Bastler sehe, aber aus anderen Gründen. 
Elektronik ist nämlich nicht mehr mein Job.

MSP ist gut, schrieb:
> Lass dir von Stefan und seinem Boy nicht so einen Scheiss erzählen.
> Das sind halt keine Teamplayer.

Wer ist denn mein "Boy"?

Natürlich darfst du meine Empfehlungen schlecht finden. Daraus 
abzuleiten, dass ich kein Teamplayer sei, finde ich aber unangebracht. 
In der Tat bin ich genau das Gegenteil. Ich habe mich vom Einzelgänger 
über Teamplayer zum Teamleiter hoch gearbeitet.

: Bearbeitet durch User
Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Veit D. schrieb:
> @ Cyblord & Holm
>
> Ich bin dabei etwas anderer Meinung. Wenn eine moderne IDE alles bietet
> und man sich nur noch um sein Programm kümmern muss, dann ist das doch
> prima.
>

Ja.

> Ansonsten müßte sich jeder Autofahrer mit allen Details vom Motor,
> Getriebe, Elektronik usw. auskennen bevor er überhaupt fahren darf.

Niemand verbietet Dir mit einer IDE zu fahren deren Wirkungsweise ..oder 
die des Prozessors Du nicht durchschaust. Du solltest nur dann die 
Klappe halten wenn sich Techniker über die Zündung unterhalten.
>
> Warum darf eine IDE diese Vorarbeit nicht abnehmen?

Du kannst tun und lassen was Du möchtest und Du kannst auch Eggschberde 
sein für Deine IDE..
>
> Ich denke auch das fette µC nur noch auf modernen Wege überhaupt
> programmiert werden können, weil die Hardware sonst gar nicht mehr
> beherschbar ist. Vom verlorenden Überblick ganz zu schweigen.

Käse.

Bei der nächsten IDE füre den nächsten Prozessor ist plötzlich das 
Lenkrad im Kofferraum und die Bremse auf dem Dach, ..und Alle außer Dir 
finden das völlig normal..

Du erhebst (wie Microsoft) die Dunkelheit zum Industriestandard.

Glaubst Du Windows oder Linux wird mit einer IDE gebastelt?

Gruß,

Holm

: Bearbeitet durch User
Autor: Harry L. (mysth)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Holm T. schrieb:
> Glaubst Du Windows oder Linux wird mit einer IDE gebastelt?

Aber selbstverständlich!
Nur, daß da nicht "gebastelt" sondern gearbeitet wird.
Sonst würde wir wohl heute noch mit einer Kommandozeile leben müssen...

Daß du bei Linux-Code auf github meist keine IDE siehst, liegt daran, 
daß jede ernst zu nehmende IDE parallel immer auch ein Makefile 
generiert, mit dem sich der Code auch ohne die IDE weiter nutzen läst. 
(Attolic, CubeIDE & Co natürlich auch)
Das ist einfach der kleinste gemeinsame Nenner der natürlich immer 
funktionieren sollte.
Daraus abzuleiten, daß die Entwickler keine IDE nutzen ist einfach nur 
blauäugig.

Und wenn man "liefern muß" weil einem der Kunde im Nacken sitzt, wird 
der wenig Verständnis dafür haben, wenn du ihm erklärst, daß du erst 
noch 2000 Seite Ref-Manual lesen und verstehen mußt, bevor du mit der 
eigentlichen Arbeit beginnen kannst, während deine Mitbewerber mit Hilfe 
der Hersteller-Tools (HAL & Co) bereits fertig sind.

Natürlich braucht man als Entwickler das Ref-Man - aber zum 
Nachschlagen, wenn man Dinge nicht versteht.

Unglaublich, was manche Leute für vollkommen praxisferne Vorstellungen 
vertreten.

Autor: Holm T. (holm)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Harry L. schrieb:
> Holm T. schrieb:
>> Glaubst Du Windows oder Linux wird mit einer IDE gebastelt?
>
> Aber selbstverständlich!
> Nur, daß da nicht "gebastelt" sondern gearbeitet wird.

Ja nee, is klar.


> Sonst würde wir wohl heute noch mit einer Kommandozeile leben müssen...

Du glaubst wirklich das sich da einer hinsetzt und mit der Maus Buttons 
drückt um einen Buildprozeß zu bewerkstelligen? :-))

>
> Daß du bei Linux-Code auf github meist keine IDE siehst, liegt daran,
> daß jede ernst zu nehmende IDE parallel immer auch ein Makefile
> generiert, mit dem sich der Code auch ohne die IDE weiter nutzen läst.
> (Attolic, CubeIDE & Co natürlich auch)
> Das ist einfach der kleinste gemeinsame Nenner der natürlich immer
> funktionieren sollte.
> Daraus abzuleiten, daß die Entwickler keine IDE nutzen ist einfach nur
> blauäugig.

Deine Vorstellungen sind einfach nur völlig daneben..

>
> Und wenn man "liefern muß" weil einem der Kunde im Nacken sitzt, wird
> der wenig Verständnis dafür haben, wenn du ihm erklärst, daß du erst
> noch 2000 Seite Ref-Manual lesen und verstehen mußt, bevor du mit der
> eigentlichen Arbeit beginnen kannst, während deine Mitbewerber mit Hilfe
> der Hersteller-Tools (HAL & Co) bereits fertig sind.

Nein der Kunde wird begeistert sein das Du die Autopilot-Software seines 
Fahrezeugs mal fix mit drei Buttonclicks und 5 Arduino Sketches 
zusammenkleisterst, ohne das Du begriffen hast was das System überhaupt 
tut..ganz sicher.

>
> Natürlich braucht man als Entwickler das Ref-Man - aber zum
> Nachschlagen, wenn man Dinge nicht versteht.

Du verstehst ja nicht mal wie man Software macht.

>
> Unglaublich, was manche Leute für vollkommen praxisferne Vorstellungen
> vertreten.

Aber exakt!
YMMD!

Gruß,

Holm

: Bearbeitet durch User
Autor: Cyblord -. (cyblord)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Holm T. schrieb:
> Du glaubst wirklich das sich da einer hinsetzt und mit der Maus Buttons
> drückt um einen Buildprozeß zu bewerkstelligen? :-))

Ein dezidierter Buildserver hat mit der Nutzung einer IDE nicht viel zu 
tun. Die IDE muss keinesfalls den Build Prozess übernehmen. Aber es gibt 
genügend andere Aufgaben.

Denkst du die schreiben den Code in Notepad oder wie?

: Bearbeitet durch User
Autor: Holm T. (holm)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Holm T. schrieb:
>> Du glaubst wirklich das sich da einer hinsetzt und mit der Maus Buttons
>> drückt um einen Buildprozeß zu bewerkstelligen? :-))
>
> Ein dezidierter Buildserver hat mit der Nutzung einer IDE nicht viel zu
> tun. Die IDE muss keinesfalls den Build Prozess übernehmen. Aber es gibt
> genügend andere Aufgaben.

Sicher doch. Ich lehne den Kram ja auch nicht rundweg ab, IDEs sind aber 
dann eher kontraproduktiv wenn man mehrere verschiedene Targets zu 
behandeln hat und jede eine eigene Vorstellung davon mitbringt was wo 
wie zu funktionieren hat. Außerdem ist es erwiesenermaßen eine 
Fehlannahme das man damit (wie auch immer) schneller zum Ziel kommt, für 
das Blinky oder Helloworld Programm mag das stimmen, dann hört das aber 
schlagartig auf.

BTW: Notepad kommt auf meiner Entwicklungsumgebung nicht vor.

Gruß,
Holm

Los doch..für die die zu doof sind ohne Kommandozeile und 
Versionsverwaltung klar zu kommen, ich brauche noch Minuspunkte..outet 
Euch!

: Bearbeitet durch User
Autor: Harry L. (mysth)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Holm T. du mußt es ja wissen....

Was du hier äusserst ist reines s/w-Denken.

Es gibt nicht nur Hardcore-Bitscghubser, die selbst einen Button noch 
händisch als Array im Code definieren und die Arduidioten am anderen 
Ende.

Wer sich in der heutigen Zeit bei der Komplexität der Hard- und Software 
den Tools der Hersteller verweigert, sollte mal langsam anfangen, über 
den Ruhestand nachzudenken!

Wer nicht mit der Zeit geht, geht mit der Zeit.

Ich programmiere seit >40J und davon >30 um meine Brötchen zu verdienen. 
Allerdings bin ich nicht in den 90er in einer Zeitschleife hängen 
geblieben, und bilde mich ständig fort.

Den Blödsinn, den du hier verzapfst, kann ich wirklich nicht ernst 
nehmen.

: Bearbeitet durch User
Autor: Cyblord -. (cyblord)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Holm T. schrieb:
> BTW: Notepad kommt auf meiner Entwicklungsumgebung nicht vor.

Es ging ja grad um das Microsoft Beispiel. Denkst du die entwicklen 
unter Linux?

> Los doch..für die die zu doof sind ohne Kommandozeile und
> Versionsverwaltung klar zu kommen, ich brauche noch Minuspunkte..outet
> Euch!

Ich denke der einzige der sich als ewig gestriger outet bist du. Prof. 
Software entwickelt man so ganz sicher nicht. Aber das ist schon so 
offensichtlich dass sie darüber keine weitere Diskussion mehr lohnt.

Autor: Holm T. (holm)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Harry L. schrieb:
> Holm T. du mußt es ja wissen....
>
> Was du hier äusserst ist reines s/w-Denken.
>
> Es gibt nicht nur Hardcore-Bitscghubser, die selbst einen Button noch
> händisch als Array im Code definieren und die Arduidioten am anderen
> Ende.
>
> Wer sich in der heutigen Zeit bei der Komplexität der Hardware den Tools
> der Hersteller verweigert, sollte mal langsam anfangen, über den
> Ruhestand nachzudenken!
>
oha, wie kommst Du nur auf diesen Trichter? Die Tatsache das 
unterscheidliche IDEs von unterschiedlichen Herstellern jeweils 
Einarbeitungszeit benötigt, geht Dir dabei scheinbar nicht auf.
Das ich Unterstützund des Herstellers aber ablehne, hast Du Dir aus den 
Fingern gesogen, ich benutze sehr wohl Bibliotheken und ggf. Tools, aber 
keine IDE die mir die Arbeit eher erschwehrt, weil ich mich um deren 
Befindlichkeiten kümmern muß.

> Wer nicht mit der Zeit geht, geht mit der Zeit.

Ja, Da Du scheinbar Einbahnstraßenprogrammierer bist solltest Du Dir das 
mal hinter die Ohren schreiben.

>
> Ich programmiere seit >40J und davon >30 um meine Brötchen zu verdienen.
> Allerdings bin ich nicht in den 90er in einer Zeitschleife hängen
> geblieben, und bilde mich ständig fort.

Nöö..Du bist nur dabei nicht schlauer geworden und nur noch 
Mausschubser.

>
> Den Blödsinn, den du hier verzapfst, kann ich wirklich nicht ernst
> nehmen.

Dann laß es und schubse Mäuse.

Gruß,

Holm

Autor: Holm T. (holm)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Holm T. schrieb:
>> BTW: Notepad kommt auf meiner Entwicklungsumgebung nicht vor.
>
> Es ging ja grad um das Microsoft Beispiel. Denkst du die entwicklen
> unter Linux?

Selbst Wenn die unter Fenster entwickeln, meinst Du die hätten nicht 
einen für Programmierer brauchbaren Editor?

>
>> Los doch..für die die zu doof sind ohne Kommandozeile und
>> Versionsverwaltung klar zu kommen, ich brauche noch Minuspunkte..outet
>> Euch!
>
> Ich denke der einzige der sich als ewig gestriger outet bist du. Prof.
> Software entwickelt man so ganz sicher nicht. Aber das ist schon so
> offensichtlich dass sie darüber keine weitere Diskussion mehr lohnt.

Na zumindest lebe ich u.A. von der Entwicklung genau dieser 
Sorftware...für Mikrocontroller...

Gruß,
Holm

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Holm T. schrieb:
> Selbst Wenn die unter Fenster entwickeln, meinst Du die hätten nicht
> einen für Programmierer brauchbaren Editor?

Doch. Und zwar als Teil einer IDE. Bei Microsoft würde ich auf Visual 
Studio tippen.

Autor: Harry L. (mysth)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Holm T. schrieb:
> Nöö..Du bist nur dabei nicht schlauer geworden und nur noch
> Mausschubser.
>
>>
>> Den Blödsinn, den du hier verzapfst, kann ich wirklich nicht ernst
>> nehmen.
>
> Dann laß es und schubse Mäuse.

Da ist es wieder; das bereits genannte schwarz/weiß-Denken.

Scheinbar kannst/willst du dir nicht vorstellen, daß man durchaus das 
beste beider Welten kombinieren kann...

An selbst generierten Dogmen fest zu halten war noch nie zielführend.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Holm T. schrieb:
> Na zumindest lebe ich u.A. von der Entwicklung genau dieser
> Sorftware...für Mikrocontroller...

Jaja, ein bisschen Microcontroller Blinky Zeug im 1-Mann Betrieb. Da ist 
es natürlich egal ob du damit VIM frickelst und ob dir 
Versionsverwaltung zu sagt.

Autor: Holm T. (holm)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Holm T. schrieb:
>> Selbst Wenn die unter Fenster entwickeln, meinst Du die hätten nicht
>> einen für Programmierer brauchbaren Editor?
>
> Doch. Und zwar als Teil einer IDE. Bei Microsoft würde ich auf Visual
> Studio tippen.

Es wäre nicht das erste Mal das Microsoft intern die eigenen Produkte 
nicht nutzt, aber ich überlasse das auch gerne Denen. Wozu Notepad 
allerdings gut sein soll, weiß der Teufel, gibts einen dümmeren Editor 
irgendwo? ..ja edlin evtl..

Gruß,

Holm

: Bearbeitet durch User
Autor: Holm T. (holm)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Harry L. schrieb:
> Holm T. schrieb:
>> Nöö..Du bist nur dabei nicht schlauer geworden und nur noch
>> Mausschubser.
>>
>>>
>>> Den Blödsinn, den du hier verzapfst, kann ich wirklich nicht ernst
>>> nehmen.
>>
>> Dann laß es und schubse Mäuse.
>
> Da ist es wieder; das bereits genannte schwarz/weiß-Denken.
>
> Scheinbar kannst/willst du dir nicht vorstellen, daß man durchaus das
> beste beider Welten kombinieren kann...
>

Ach, warst nicht genau Du es der gerade noch diese Meinung vertreten 
hatte?

> An selbst generierten Dogmen fest zu halten war noch nie zielführend.

Zieh Dir mal Deinen alten Latsch selber an.
BTW: auch ich programmiere (für Geld) seit 1991), seit 12 Jahren auf 
eigene Rechnung.

Gruß,

Holm

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Holm T. schrieb:

> Es wäre nicht das erste Mal das Microsoft intern die eigenen Produkte
> nicht nutzt, aber ich überlasse das auch gerne Denen.
ist auch irrelevant für das Thema. Aber eine IDE werden sie nutzen.
Bei Versionsverwaltung sind sie glaube ich vom eigenen CodeSafe weg. 
Aber natürlich nutzen sie trotzdem eine.

> Wozu Notepad
> allerdings gut sein soll, weiß der Teufel, gibts einen dümmeren Editor
> irgendwo? ..ja edlin evtl..

Ach Gottchen, dir ist auch alles recht um dich zu entblöden.

: Bearbeitet durch User
Autor: Holm T. (holm)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Holm T. schrieb:
>
>> Es wäre nicht das erste Mal das Microsoft intern die eigenen Produkte
>> nicht nutzt, aber ich überlasse das auch gerne Denen.
> ist auch irrelevant für das Thema. Aber eine IDE werden sie nutzen.
> Bei Versionsverwaltung sind sie glaube ich vom eigenen CodeSafe weg.
> Aber natürlich sie trotzdem eine.

Wenn der Compiler auf einem Buildhost läuft, ist das schon keine IDE 
mehr, sondern ein Batch System.
>
>> Wozu Notepad
>> allerdings gut sein soll, weiß der Teufel, gibts einen dümmeren Editor
>> irgendwo? ..ja edlin evtl..
>
> Ach Gottchen, dir ist auch alles recht um dich zu entblöden.

Meinst Du? Nimm mir doch mal bitte die Vokabel "entblöden" auseinander 
und erzähle einem Mitteldeutschen was das zu bedeuten haben soll.

Gruß,

Holm

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Cyblord -. schrieb:
>> Holm T. schrieb:
>>
>>> Es wäre nicht das erste Mal das Microsoft intern die eigenen Produkte
>>> nicht nutzt, aber ich überlasse das auch gerne Denen.
>> ist auch irrelevant für das Thema. Aber eine IDE werden sie nutzen.
>> Bei Versionsverwaltung sind sie glaube ich vom eigenen CodeSafe weg.
>> Aber natürlich sie trotzdem eine.
>
> Wenn der Compiler auf einem Buildhost läuft, ist das schon keine IDE
> mehr, sondern ein Batch System.

Dachte ich mir doch. Du weißt ja noch nicht mal was eine IDE ist. 
Nochmal: Eine IDE bleibt eine IDE auch wenn sie NICHT für das bauen 
zuständig ist. Das Bauen erfolgt dann außerhalb. Über einen Buildserver 
oder Batch System oder sonst was. Die IDE darf trotzdem eine IDE 
bleiben. Außerdem nutzt man das auch oft dual, d.h. lokal baut die IDE 
schon, Releases macht der Build Server.

Und jetzt frickel doch einfach auf deiner Kommandozeile weiter und 
erzähle uns nichts vom Pferd wie man in großen Firmen, innerhalb von 
verteilten Teams, Software entwickelt. Du hast jetzt deutlichst gezeigt 
dass du davon keinen Schimmer hast. Es wird nicht mehr besser für dich. 
Glaubs mir.

Autor: Holm T. (holm)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Holm T. schrieb:
>> Cyblord -. schrieb:
>>> Holm T. schrieb:
>>>
>>>> Es wäre nicht das erste Mal das Microsoft intern die eigenen Produkte
>>>> nicht nutzt, aber ich überlasse das auch gerne Denen.
>>> ist auch irrelevant für das Thema. Aber eine IDE werden sie nutzen.
>>> Bei Versionsverwaltung sind sie glaube ich vom eigenen CodeSafe weg.
>>> Aber natürlich sie trotzdem eine.
>>
>> Wenn der Compiler auf einem Buildhost läuft, ist das schon keine IDE
>> mehr, sondern ein Batch System.
>
> Dachte ich mir doch. Du weißt ja noch nicht mal was eine IDE ist.

Soso. Dachtest Du.


> Nochmal: Eine IDE bleibt eine IDE auch wenn sie NICHT für das bauen
> zuständig ist. Das Bauen erfolgt dann außerhalb.

..unterhalb ..oder mehr seitlich?

> Über einen Buildserver
> oder Batch System oder sonst was. Die IDE darf trotzdem eine IDE
> bleiben. Außerdem nutzt man das auch oft dual, d.h. lokal baut die IDE
> schon, Releases macht der Build Server.

Toll. Und was ist jetzt eine IDE? Ist ein PDF Reader, ein grafischer 
Debugger und ein Editor mit Syntax highlighting, der mit einer "F"-Taste 
make und program aufruft, auf einem Desktop evtl. auch eine IDE? ..oder 
fehlt der der Rahmen mit dem Name des Prozessorherstellers oben?
Darf das Fenster des Debuggers auf einem anderen virtuellen Desktop 
liegen als der Editor mit der Source?  ..und das serielle Terminal mit 
deem Output des Targets auf einem Weiteren?


>
> Und jetzt frickel doch einfach auf deiner Kommandozeile weiter und
> erzähle uns nichts vom Pferd wie man in großen Firmen, innerhalb von
> verteilten Teams, Software entwickelt. Du hast jetzt deutlichst gezeigt
> dass du davon keinen Schimmer hast. Es wird nicht mehr besser für dich.
> Glaubs mir.

Labere Du einfach weiter von Dingen die Du gar nicht erfaßt, ich kenne 
schon Viele von dieser Sorte..

Gruß,

Holm

: Bearbeitet durch User
Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es um Leistung geht ist ein Pi Zero oder TI Sitara viel billiger 
als ein STM32 M7 und mit RiscOS auch viel einfacher zu programmieren und 
als uC zu nutzen als mit der HAL und anders als mit Linux gibt es keinen 
Overhead und echte Echtzeit.

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Holm T. schrieb:
> IDEs sind aber dann eher kontraproduktiv wenn man mehrere
> verschiedene Targets zu behandeln hat

Warum das denn?

> Außerdem ist es erwiesenermaßen eine
> Fehlannahme das man damit schneller zum Ziel kommt.

Ich hasse diese Frage, aber jetzt muss ich sie mal stellen: Kannst du 
den Beweis zeigen oder verlinken?

Ich habe den Eindruck, dass du vielleicht Framework mit IDE 
verwechselst.

Ich kenne das so, dass die Softwareentwickler lokal eine IDE benutzen. 
Sie enthalten viele Funktionen, die das Arbeiten beschleunigen und 
Fehler vermeiden. Zum Beispiel:

- Automatische Eingabeergänzung
- Refactoring (Umbenennen, Verschieben und Funktionsparameter im ganzen 
Projekt (oder gar vielen Projekten))
- Syntax Check
- Plausibilitäts-Checks (z.B. wenn du eine Variable liest ohne sie 
vorher zu beschrieben)
- Debugging (wer will das freiwillig an der Kommandozeile tun?)
- Auflösen von Merge-von Konflikten (kennst du nicht, wenn du alleine 
arbeitest)
- Und natürlich die umfangreichen Suchfunktionen

Zur Erstellung einer Lieferung wird aber häufig ein Server mit einer 
stabilen Softwareinstallation und Build Scripten verwendet. Damit 
sichergestellt ist, dass jeder Build für jeden Entwickler 100% 
wiederholbar ist.

: Bearbeitet durch User
Autor: Holm T. (holm)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Die Fragen stellen sich doch so gar nicht. Viele von Euch arbeite nunter 
Windows uncd assoziieren die Arbeit auf dem Desktop mit einer IDE, 
denken damit mit Grausen daran was ihnen MSDOS auf der Kommandozeile zu 
bieten hat.

Wenn ich das als Vorrausetzung der Diskussion ansehe, verstehe ich die 
Empörung.

Die Sache liegt aber anders. Ich benutze nicht etwa einen Bildschirm mit 
einem Propt c:\>. Ich arbeite unter Unix seit den 90ern. Unix wurde 
gemacht von Programmierern für Programmierer und es gibt allerhand Tools 
die die Arbeit von Programmierer erleichtern. Dazu zähöt u.A. das Tool 
make das Buildprozesse automatisiert und Abhänggikeiten von Dateien 
untereinander berücksichtigt, also auch heraus bekommt wan was neu zu 
bauen ist, weil sich eine Komponente geändert hat. Umgebunsvariabeln 
nehmen Pfade auf, Streameditoren können Datenströme editieren, es gibt 
Tools die Quellen autoamtisch anhübschen und es gibt auch 
Compiler-Compiler, Tools zur lexikalischen Analyse und 
Reportgeneratoren.

Merge Konflikte? Ich weiß nicht wie viele Versionskontrollsysteme es 
unter Unix gab/gibt, das fing wohl mit SCCS an..über CVS, Subversion und 
nun git..um die Bekanntesten zu nennen.

Die ganze Funktionalität die Du darstellst ist nicht an eine "IDE" 
gebunden, es ist nur in einer IDE eine Sammlung von Utilities die das 
"unter einem Dach" zur Verfügung stellen will. Es ist mit nichten so, 
das ich auf irgend Etwas davon verzichten müßte, es gibt a) eine 
Grafische Oberfläche auf der das Ganze stattfindet, also auch die 
Kommandozeile(n!) und b) eine Anzahl Tools die nach vordefinierten 
Regeln miteinander Daten austauschen können und auch merken wenn sich 
die bearbeitete Datei (auf der z.B. ein Debugger hockt) geändert hat und 
die neu einlesen.
Diese Komponenten kann man z.B. auch mit Eclipse unter Unix zu einer IDE 
zusammenfassen, sieht dann viereckig aus und auch ein Windws User 
begreift das als IDE. Ich bin aber nicht gezwungen dieses Framework zu 
benutzen das dazu tendiert je nach Gusto des Produzenten unterschiedlich 
zu funktionieren und Konfigurationen an verschiedenen Stellen zu 
verstecken.

Ich habe eine Arbeitsumgebung mit einem mir geeignet erscheinenden 
Editor (vim) der acuh Syntax-higlighting unterstützt und mich bei Bedarf 
aus einer grafischen Benutzeroberfläche anglotzt, wiederkehrende 
Aufgaben wie eben Compilerläufe lassen sich von dort einfach und 
automatisiert aufrufen, der Debugger sieht auch grafich aus und läuft 
aus Platzgründen einen Mausklick entfernt in einem anderen virtuellen 
Desktop. Neben dem Editor(en) habe ich i.A. die Doku des Targets offen 
usw.

Das Ganze ergibt ein Development Environment das hoch optimiert genau 
das tut was ich möchte und was für den gegebenen Zweck sinnvoll ist, 
ohne das ich morgen, wenn ich aus Spaß an einem Z80 oder einem MSP430 
bastele, eine andere Umgebung dafür bemühen müßte. Ich muß mich nichgt 
umgewöhnen und bin deswegen effizient.

Es ist nicht lange her das ich nach einem Build-Environment für AtXmega 
für einen meiner Kunden fragte, er wollte genau das haben was ich habe, 
aber unter Windows. Er wollte die von mir geschriebene Firmware vor Ort 
aus meinen Quellen übersetzen können mit einem einfachen "make", nach 
dem er die erforderlichen Schritte unter AVR-Studio mit dem verglichen 
hatte was ich zu tippern hatte. Schon das Laden eines Hex Files für 
EEPROM und Flash für den Xmega und das nachfolgende Programmieren mit 
AVR Studio ging ihm auf die Nerven ..Zip Archiv downloaden, auspacken, 
AVR Studio anwerfen, Files raussuchen und anclickern und Programmieren, 
anstatt Kommandozeile und "make program", er hats bekommen.

Meine IDE integriert also die Utilities die mein System zur Verfügung 
stellt, azu gehören die Unix Tools aber auch irgendwelche 3rd Party 
Utilities und eigener Kram. Eine IDE als Solche bekomme ich z.B. von TI 
und die kann ich nicht vernünftig nutzen wenn ich keinen TI Prozessor 
sondern einen Arm oder einen AtXmega in der Mache habe, das genau ist 
es, was mir auf den Wcker fällt, weil jeder Hersteller seine eigene 
Suppe kocht. Drittanbieter machen auch immer mal schicke sachen..um dann 
plötzlich und unerwartet von der Bildfläche zu verschwinden. Mein Kram 
verschwindet aber nicht und ich kann das selbe Environment benutzen um 
damit einen 8051 zu behandeln. Da schleifts freilich mit dem Debugger..


BTW: Es gibt Leute die meinen EMACS sei ein hervorragendes 
Betriebssystem, es wäre nur traurig das es Unix zum Booten braucht (ist 
heute nicht mehr so). Ich behaupte hier das ist kein Betriebsssystem, 
das ist ne IDE!
Man kann da Alles machen ohne den Editor zu verlassen. (J sag mal was 
dazu) ..ich benutze ihn nur nicht, war nicht mein Geschmack..

Während ich hier tippere läuft in einem Fenster in der Ecke seit Stunden 
der Buildprozess für FreeBSD auf einem Server eines Kunden..ein Update 
aus den Sourcen, remote mit Subversion vorher auf einem definierten 
Stand gebracht. Wie geht das mit einer IDE?


Gruß,

Holm

: Bearbeitet durch User
Autor: Harry L. (mysth)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Holm T. schrieb:
> Ich arbeite unter Unix seit den 90ern.

Schön für dich!
Andere aber auch - ich z.B.

Holm T. schrieb:
> Ich bin aber nicht gezwungen dieses Framework zu
> benutzen das dazu tendiert je nach Gusto des Produzenten unterschiedlich
> zu funktionieren und Konfigurationen an verschiedenen Stellen zu
> verstecken.

Gerade für das von dir zitierte Eclipse trifft genau das nicht zu.

Eclipse ist nun mal ein komplexer aber prall gefüllter Werkzeugkasten, 
der viel Einarbeitungszeit erfordert, aber wenn man das hinter sich hat, 
hat man eine IDE für alles.

Mit meinem Eclipse entwickel ich aktuell für. STM32, AVR (8bit), Linux 
(x86), Linux (ARM/RPi) etc.

Ist ein wenig wie die gute alte Schreibmaschine im Vergleich zu Word.
Wer mit der Schreibmaschine umgehen kann, ist noch lange nicht in der 
Lage, mit Word komplexe Dokumente mit komplexen Formatierungen zu 
erzeugen - das muß man auch erst lernen - selbst wenn man bereits den 
Literatur-Nobelpreis bekommen hat.

Und das auch und sogar unter Linux.

Holm T. schrieb:
> Meine IDE integriert also die Utilities die mein System zur Verfügung
> stellt, azu gehören die Unix Tools aber auch irgendwelche 3rd Party
> Utilities und eigener Kram. Eine IDE als Solche bekomme ich z.B. von TI
> und die kann ich nicht vernünftig nutzen wenn ich keinen TI Prozessor
> sondern einen Arm oder einen AtXmega in der Mache habe, das genau ist
> es, was mir auf den Wcker fällt, weil jeder Hersteller seine eigene
> Suppe kocht.

s.o.: wenn man Eclipse einmal verstanden hat, ist es kinderleicht, da 
weitere Ziel-Architekturen zu inetgrieren.
Der Weg is dahin kann zugegebenermaßen für den Konsolen-zentrierten User 
steinig sein.

Nur, weil du das nicht kannst, ist das nicht schlecht.

: Bearbeitet durch User
Autor: Holm T. (holm)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Harry L. schrieb:
> Holm T. schrieb:
>> Ich arbeite unter Unix seit den 90ern.
>
> Schön für dich!
> Andere aber auch - ich z.B.
>
> Holm T. schrieb:
>> Ich bin aber nicht gezwungen dieses Framework zu
>> benutzen das dazu tendiert je nach Gusto des Produzenten unterschiedlich
>> zu funktionieren und Konfigurationen an verschiedenen Stellen zu
>> verstecken.
>
> Gerade für das von dir zitierte Eclipse trifft genau das nicht zu.
>
> Eclipse ist nun mal ein komplexer aber prall gefüllter Werkzeugkasten,
> der viel Einarbeitungszeit erfordert, aber wenn man das hinter sich hat,
> hat man eine IDE für alles.
>
> Mit meinem Eclipse entwickel ich aktuell für. STM32, AVR (8bit), Linux
> (x86), Linux (ARM/RPi) etc.


Na dann Glückwunsch, mich hat das Zeug bisher nur genervt.

>
> Ist ein wenig wie die gute alte Schreibmaschine im Vergleich zu Word.
> Wer mit der Schreibmaschine umgehen kann, ist noch lange nicht in der
> Lage, mit Word komplexe Dokumente mit komplexen Formatierungen zu
> erzeugen - das muß man auch erst lernen - selbst wenn man bereits den
> Literatur-Nobelpreis bekommen hat.

:-)
Wie konnten nur Ohne Eclipse IDE vorher komplexe Softwareprojekte 
umgesetzt weren, einfach unverständlich ...

>
> Und das auch und sogar unter Linux.

Das istm ir egal, ich arbeite nicht unter Linux.
>
> Holm T. schrieb:
>> Meine IDE integriert also die Utilities die mein System zur Verfügung
>> stellt, azu gehören die Unix Tools aber auch irgendwelche 3rd Party
>> Utilities und eigener Kram. Eine IDE als Solche bekomme ich z.B. von TI
>> und die kann ich nicht vernünftig nutzen wenn ich keinen TI Prozessor
>> sondern einen Arm oder einen AtXmega in der Mache habe, das genau ist
>> es, was mir auf den Wcker fällt, weil jeder Hersteller seine eigene
>> Suppe kocht.
>
> s.o.: wenn man Eclipse einmal verstanden hat, ist es kinderleicht, da
> weitere Ziel-Architekturen zu inetgrieren.

Sortierst Du die Welt in Eclipse Versteher und Nichtversteher? was gibts 
dara nicht zu verstehen? Mir ist das Ding nur einfach zu fett und die 
Parameter an denen zu schrauben ist, sind mir zu Wgleichmäßig" verteilt.

> Der Weg is dahin kann zugegebenermaßen für den Konsolen-zentrierten User
> steinig sein.
>
> Nur, weil du das nicht kannst, ist das nicht schlecht.

:.s/kannst/willst/

Lerne das zu begreifen.

Gruß,

Holm

: Bearbeitet durch User
Autor: Harry L. (mysth)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Schon lustig, zu sehen, wie dir die Argumente ausgehen, und du versuchst 
mit Neben-Kriegsschauplätzen abzulenken....

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Holm T. schrieb:
> Viele von Euch ... denken damit mit Grausen daran was ihnen
> MSDOS auf der Kommandozeile zu bieten hat.

Also ich nicht, ich hatte bereits unter DOS mit einer waschechten IDE 
gearbeitet.

> Diese Komponenten kann man z.B. auch mit Eclipse unter Unix
> zu einer IDE zusammenfassen

Ob die IDE aus einem Sammelsurium von Plugins oder einem Guss besteht, 
spielt (was den Begriff angeht) doch gar keine Rolle.

> Ich bin aber nicht gezwungen dieses Framework zu benutzen

Ich hatte also Recht, du verwechselst IDE mit Framework. Das sind 
normalerweise zwei völlig unabhängige Sachen. Es gibt wenige Ausnahmen, 
wo eine IDE mit einem Framework fest verheiratet ist. Das sind für mich 
aber Sonderfälle.

> Ich habe eine Arbeitsumgebung mit einem mir
> geeignet erscheinenden Editor (vim)

Offensichtlich ist Dir nicht bewusst, was Refactoring ist, bzw. wie man 
das in diesem Jahrtausend effizient macht. Jedenfalls nicht mit sed 
Scripten.

: Bearbeitet durch User
Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Harry L. schrieb:
> Schon lustig, zu sehen, wie dir die Argumente ausgehen, und du versuchst
> mit Neben-Kriegsschauplätzen abzulenken....

Mir gehen die Argumente nicht aus, aber Du begreifst meine Arbeitsweise 
nicht und denkst ich stecke in der Steinzeit. Da kann ich nicht viel 
machen.
Mach Dein Ding und laß mir meins.

Gruß,

Holm

Autor: Holm T. (holm)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Holm T. schrieb:
>> Viele von Euch ... denken damit mit Grausen daran was ihnen
>> MSDOS auf der Kommandozeile zu bieten hat.
>
> Also ich nicht, ich hatte bereits unter DOS mit einer waschechten IDE
> gearbeitet.
>
Ja, ich kenne Auch Keil und Ähnliches. Willich nicht.

>> Diese Komponenten kann man z.B. auch mit Eclipse unter Unix
>> zu einer IDE zusammenfassen
>
> Ob die IDE aus einem Sammelsurium von Plugins oder einem Guss besteht,
> spielt (was den Begriff angeht) doch gar keine Rolle.

Eben.

>
>> Ich bin aber nicht gezwungen dieses Framework zu benutzen
>
> Ich hatte also Recht, du verwechselst IDE mit Framework. Das sind
> normalerweise zwei völlig unabhängige Sachen. Es gibt wenige Ausnahmen,
> wo eine IDE mit einem Framework fest verheiratet ist. Das sind für mich
> aber Sonderfälle

Du siehst doch aber was passiert, mir wird hier die notwendigkeit eine 
IDE zu benutzen eingetrichtert.
>
>> Ich habe eine Arbeitsumgebung mit einem mir
>> geeignet erscheinenden Editor (vim)
>
> Offensichtlich ist Dir nicht bewusst, was Refactoring ist, bzw. wie man
> das in diesem Jahrtausend effizient macht. Jedenfalls nicht mit sed
> Scripten.

Doch, auch mit denen, aber nicht nur.

Gruß,

Holm

: Bearbeitet durch User
Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Holm T. schrieb:
> Du siehst doch aber was passiert, mir wird hier die notwendigkeit eine
> IDE zu benutzen eingetrichtert.

Jeder kann ja so arbeiten, wie er will. Wenn ich dein Chef wäre, und 
würde bemerken, dass du ganz anders als deine Kollegen arbeitest, würde 
ich deine Leistung prüfen. Wenn die Ok ist, dann würde ich nicht 
eingreifen.

Ich bin von drei aufeinander folgenden Firmen mit Schwerpunkt auf 
Qualitäts- und Effizienz-Verbesserung eingestellt worden. Der Erfolg 
wurde mir jedesmal schriftlich attestiert.

Dabei bin ich stets ein Verfechter der freien Arbeitsmittel-Wahl 
gewesen. Erlaubt ist, was funktioniert und die anderen nicht behindert. 
Ein gewisses Maß an Abstimmung ist also doch nötig, aber bisher mussten 
wir uns noch nie auf eine bestimmte IDE oder Betriebssystem festlegen.

Die Kommandozeile mit Build Script sollte auf jeden Fall immer zumindest 
als Fall-Back Lösung erhalten bleiben. Man macht sich damit 
unabhängiger, was langfristig Zeit und Kosten spart.

Ich kenne allerdings keinen Entwickler, der freiwillig ohne IDE 
arbeitet. Du bist für mich der erste, der sich so äußert.

: Bearbeitet durch User
Autor: Holm T. (holm)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Holm T. schrieb:
>> Du siehst doch aber was passiert, mir wird hier die notwendigkeit eine
>> IDE zu benutzen eingetrichtert.
>
> Jeder kann ja so arbeiten, wie er will. Wenn ich dein Chef wäre, und
> würde bemerken, dass du ganz anders als deine Kollegen arbeitest, würde
> ich deine Leistung prüfen. Wenn die Ok ist, dann würde ich nicht
> eingreifen.

Feine Sache, mein Chef macht das exakt genau so und deswegen arbeite ich 
genau so.

>
> Ich bin von drei aufeinander folgenden Firmen mit Schwerpunkt auf
> Qualitäts- und Effizienz-Verbesserung eingestellt worden. Der Erfolg
> wurde mir jedesmal schriftlich attestiert.

Glückwunsch.
>
> Dabei bin ich stets ein Verfechter der freien Arbeitsmittel-Wahl
> gewesen. Erlaubt ist, was funktioniert und die anderen nicht behindert.
> Ein gewisses Maß an Abstimmung ist also doch nötig, aber bisher mussten
> wir uns noch nie auf eine bestimmte IDE oder Betriebssystem festlegen.
>
> Die Kommandozeile mit Build Script sollte auf jeden Fall immer zumindest
> als Fall-Back Lösung erhalten bleiben. Man macht sich damit
> unabhängiger, was langfristig Zeit und Kosten spart.

Es ist auch Zeit- und Kostensparend das Framework von einem 
vorhergehenden Projekt übernehmen zu können, selbst wenn dieses eine 
andere CPU verwendete.
>
> Ich kenne allerdings keinen Entwickler, der freiwillig ohne IDE
> arbeitet. Du bist für mich der erste, der sich so äußert.

Die Meisten bekommen Windows vorgeschrieben, aber selbst da gibts Leute 
die  meinen ein zusätzliches cygwin zu benötigen. Microsoft baut 
mittlerweile WSL ein und hat vor ein "richtiges" Linux samt Kernel zu 
unterstützen..komisch.

Ich möchte einfach die selbe, vertraute Umgebung zum entwickeln haben, 
egal was gerade das Target ist, ist das so schwer zu verstehen? 
Verschiedene IDEs verschiedener Hersteller unterstützen mich dabei 
nicht, sondern sind eher hinderlich. Warum darf ich also keine 
plattformübergreifenden Tools verwenden wenn mir danach ist?


Mein Chef hat nix dagegen, denn das bin ich seit 12 Jahren selbst und 
bereits in der Firma vorher (die ich jetzt auch bin) habe ich so 
gearbeitet, auch in der Zeit davor als Sysop in der Uni.

Meinst Du ich liege seit 28 Jahren völlig falsch?


Gruß,

Holm

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Wo hats denn beim L4 Einstieg genau gehapert?

Siehe
Beitrag "Einstieg in STM32(L4)"

Offensichtlich ist er noch gar nicht so weit gekommen, dem 
Mikrocontroller zu programmieren, weil er mit der IDE nicht zurecht kam.

Ich schlage vor, die Diskussion zum STM32L4 dort weiter zu führen, wo 
sie begonnen hat (also in eben diesem verlinkten Thread).

Autor: SQA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:

> Die Kommandozeile mit Build Script sollte auf jeden Fall immer zumindest
> als Fall-Back Lösung erhalten bleiben.

Fall-Back Lösung?
Wie testet man seine Software automatisch ohne Build Script?

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
man kann auch die Eclipse IDE aus der Kommandozeile so aufrufen das ein 
oder meherere Projekte automatisch gebaut werden. Ich glaube aber den 
Kommandozeilenbandwurm beherschen nur ein paar Menschen auf diesem 
Planeten...

Beitrag #5876441 wurde vom Autor gelöscht.
Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd K. schrieb:
> Übrigens, meine Forderung nach "low power" in Kombination mit 100 MHz
> begründet sich in der Idee, die MCU in einem kleinen Roboter mit
> einfacher VGA Kamera zu nutzen. Da Energie immer ein Problem bei
> Robotern ist -> low power und um was sinnvolles mit der Kamera zu machen
> braucht man schon ein wenig Rechenpower -> 100 MHz.

Tut mir leid das jetzt mal so direkt sagen zu müssen aber das klingt für 
mich etwas zu sehr nach Bodo Bach ("Ich hätt da gern emal e Problem") ;)

Bei allem was ich als Roboter kenne (sowohl die kleinen Helferlein, die 
Staubsaugen, sowie die großen Teile, die bei VW im Werk Karosserien 
verschweißen) spielen die paar Milliampere von so einem Mikrocontroller 
absolut keine Rolle. Mein kleines chinesisches Helferlein (Xiaomi 
Roborock S50) hat beispielsweise sogar drei Mikrocontroller bzw. 
Mikroprozessoren an Board, ohne dass das jetzt die Ausdauer beim Saugen 
groß beeinflussen würde. Einen STM32 der sich um den Antrieb kümmert, 
einen DSP (ich meine TMS320), welcher sich (wie ich vermute) mit der 
Auswertung des LIDAR beschäftigt und einen Cortex-A auf dem Linux läuft 
und der sich wohl um die ganze Netzwerkkommunikation kümmert (d.h. der 
Zentralregierung meldet wie meine Wohnung aussieht und wie oft die 
gesaugt wird).

Die große Frage ist ja, was genau du mit der VGA-Kamera anstellen 
willst. Willst du ein paar pixelige Bilder machen und die auf SD-Karte 
speichern? Wahrscheinlich nicht aber selbst wenn, dann ist ein Cortex-M 
mit 48MHz dafür immer noch schnell genug. Willst du Bilder/Videos per 
Funk an einen stationären Empfänger senden? Vielleicht schon eher aber 
dafür brauchst du im Prinzip überhaupt keinen Mikrocontroller, ein 
reiner Funksender reicht. Willst du das VGA-Bild in irgendeiner Form 
weiterverarbeiten, z.B. eine Bilderkennung durchführen? Dann ist ein 
Cortex-M eigentlich grundsätzlich die falsche Wahl und du solltest eher 
zu einer Lösung mit Cortex-A, a la Raspberry Pi greifen. Was mir dazu 
noch einfällt (und womit wir endlich wieder beim Thema wären) ist der 
K210 von Kendryte. Das ist ein RISC-V mit "AI-Coprocessor", der speziell 
für Bilderkennung und solche Dinge gedacht ist. Dev-Boards gibts beim 
Ali ab 25€ (inkl. Kamera).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.