Forum: Mikrocontroller und Digitale Elektronik XMC4700 vs STM32


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.
von großerGregor420 (Gast)


Lesenswert?

Hi

Ich wollte die Tage ausnutzen um in 32bit einzusteigen.
Nun gibt es hier ja unendlich Auswahl, konkret habe ich nun den XMC4700 
ins Auge gefasst.
Mir gefällt die Hardware inkl. Features sehr und der Preisunterschied zu 
zB. XMC4500/4600 ist für meine Anwendung egal.

Nun, wieso ist STM32 von ST hier nun so verbreitet?
Ist die XMC Linie schlechter oder einfach nur nicht so verbreitet?
Hat wer Erfahrung mit dem XMCs in C oder wird da schon eher ein OS 
verwendet?

Ist Code zwischen den Modellen in der XMC4000 Serie portierbar?
Dh. kann man Code für einen XMC4500 zB. auf einen XMC4800 laden?

Ich bin mir nicht sicher inwiefern hier eine Trennung besteht, ist das 
eher eine Serie in der man einfach so "hoch" geht wie man gerade die 
Peripherie benötigt oder ist der Unterschied hier größer?
Mir gefällt auch dass nfineon aus DE ist.

Kann jemand etwas über seinen Workflow mit XMC berichten?
Eher STM oder Infineon?

mfg

von John Doe (Gast)


Lesenswert?

großerGregor420 schrieb:
> Nun, wieso ist STM32 von ST hier nun so verbreitet?

Geschicktes Marketing, hervorragende Verfügbarkeit, auch für Hobbyisten 
günstige Preise in Einzelstückzahlen von der Elektronikklitsche um die 
Ecke und eine Vielzahl an fertigen und billigen Platinchen vom 
Chinamann.

> Ist die XMC Linie schlechter oder einfach nur nicht so verbreitet?
> Hat wer Erfahrung mit dem XMCs in C oder wird da schon eher ein OS
> verwendet?

Was meinst Du mit "C oder eher ein OS"??

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

großerGregor420 schrieb:
> Kann jemand etwas über seinen Workflow mit XMC berichten?
> Eher STM oder Infineon?

XMC ist bei mir schon etwas her; was mit aber damals sehr unangenehm 
aufgefallen ist, ist die Qualität der Dokumentation und das Design der 
Peripherals. Die Dokumentation war extrem schlecht verständlich 
geschrieben und die Peripherals z.T. recht kompliziert und machte einen 
sehr gewachsenen Eindruck.

Da ich für jeden Projekt (wenn möglich) den GCC verwende, war der 
"Workflow" wie üblich.

von Ben S. (bensch123)


Lesenswert?

Torsten R. schrieb:
> XMC ist bei mir schon etwas her; was mit aber damals sehr unangenehm
> aufgefallen ist, ist die Qualität der Dokumentation und das Design der
> Peripherals. Die Dokumentation war extrem schlecht verständlich
> geschrieben und die Peripherals z.T. recht kompliziert und machte einen
> sehr gewachsenen Eindruck.

Das kann ich nur bestätigen. Infineon hat im Allgemeinen einen Hang zu 
unverständlichen Dokumentationen. Ich musste für ein Kundenprojekt mit 
einem XMC arbeiten - nie wieder bitte.

von Jan (Gast)


Lesenswert?

Die ST Peripherie ist aber auch fies designt. Die von NXP soll besser 
sein, da kann W.S. bestimmt was zu sagen ;)

St hat mit dem stm32f103 damals einen Hit gelandet, der extrem 
verbreitet ist und legt seitdem kontinuierlich nach.

Mit der komischen Cube Infrastruktur (Code Generator und auch IDE) soll 
schneller Einstieg ermöglicht werden.

von Ben S. (bensch123)


Lesenswert?

Jan schrieb:
> Die ST Peripherie ist aber auch fies designt.

Inwiefern?

von Blechbieger (Gast)


Lesenswert?

Ben S. schrieb:
> Das kann ich nur bestätigen. Infineon hat im Allgemeinen einen Hang zu
> unverständlichen Dokumentationen. Ich musste für ein Kundenprojekt mit
> einem XMC arbeiten - nie wieder bitte.

Nicht nur die Doku ist schlecht sondern auch der Support. Hingerotzte 
Antworten die die Hälfte der Fragen ignoriert und die andere Hälfte mit 
aus dem unverständlichen Datenblatt kopierten Sätzen beantwortet.

Bei ST dagegen wesentlich besser bis hin zum Besuch eines meiner 
Kollegen eines ST-Labor in Italien zur gemeinsamen Lösungssuche mit dem 
zuständigen Entwickler.

Betraf in beiden Fällen allerdings keine MCUs und Umsätze im niedrigen 
fünfstelligen Bereich (bei Infineon nur potenzielle Umsätze und nach 
dieser Erfahrung wurde das Bauteil auch nicht gewählt).

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

Ben S. schrieb:
> Jan schrieb:
>> Die ST Peripherie ist aber auch fies designt.
>
> Inwiefern?

Naja guck mal beim DMA vorbei bei den Flags.
Warum hat man pro Channel nicht ein Flagregister spendiert, sondern 
presst 4 Channel in ein Register?
Der Offset ist nicht jeweils 8 mehr, sondern 6 mehr.
Grausig!
Aber da schreibt man sich einmal seinen Treiber drum und dann sieht man 
das nie wieder.

Man hat da eben 16Bit HW an einen 32Bit Kern geknotet.

Jan schrieb:
> da kann W.S. bestimmt was zu sagen ;)

Na, bitte keine Trolle anlocken.

von W.S. (Gast)


Lesenswert?

großerGregor420 schrieb:
> Mir gefällt die Hardware inkl. Features sehr

Mir nicht. Jedenfalls gefällt mir ein "Feature" der XMC's, die ich 
bislang gesehen habe, überhaupt nicht: ROM ab Adresse 0 - und den auch 
noch weitestgehend undokumentiert.

Eigentlich alle anderen Cortexe haben brav Flash ab Adresse 0, womit das 
Bestücken der benutzten Interruptvektoren mit den eigenen Handlern kein 
Problem ist - nur Infineon tanzt aus der Reihe. OK, bei den größeren 
Typen kann man die Tafel verlegen, was das Problem löst - aber mir 
gefällt das trotzdem nicht.

Und zu den STM32: die haben zum großen Teil nur 16 bittige Peripherie 
und in vielen Peripheriecores, die das gebrauchen könnten, keine Fifo's. 
Da muß man zwangsweise auf DMA umsteigen, was die Sache kompliziert. 
Aber relativ gut verfügbar sind die STM32 und wenn man sich mit den 
chinesischen Kompatiblen anfreundet, dann ist das Ganze auch noch 
billig.

Bei NXP hab ich eher den Eindruck, daß die sich zu Höherem berufen 
fühlen und den Kleinkram ihren zugekauften Freescale-Leuten überlassen. 
Und bei denen sind wirklich sehr gemischte Gefühle angesagt: Manche 
Chips sind sowohl preisgünstig als auch hochinteressant und andere sind 
Mist.

W.S.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

Das letzte Mal, wo ich XMC angeschaut hatte, bekam man die Header Files 
nur nach Abnicken einer eckligen Lizenzvereinbarung.

von P. S. (namnyef)


Lesenswert?

Die Peripherie der XMCs ist sehr flexibel, aber dadurch auch sehr 
komplex. Die nicht sonderlich verständliche Doku tut dann ihr übriges. 
Aber alles machbar, wenn man hin- und wieder bereit ist Frustmomente zu 
überwinden :D

Da fand ich Peripherie und Doku der LPC43xx (NXP) deutlich angenehmer.

von Nun. (Gast)


Lesenswert?

Ganz nebenbei gibts beim XMC keinen Cortex-M7 (soweit mir bekannt).
Die wollen da vermutlich, dass man stattdessen auf die eigenen Tricore 
geht...

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

Ich fand die XMC auch ganz furchtbar dokumentiert. Haben wir aus dem 
Grund nicht verwendet und stattdessen einen STM32 genommen. Nebenbei 
haben wir auch noch LPC800 im Einsatz. Irgendwie hab ich das Gefühl 
Infineon wollte mit den Dingern die C167 Kunden dir die Peripherie dort 
schon kannten halten. Für Neueinsteiger ist die Lernkurve doch Recht 
steil.

von Iggi (Gast)


Lesenswert?

Stm32 hat sich bei uns in der Firma bei so gut wie allen Neuprojekten 
durchgesetzt. Der Preis ist eigentlich unschlagbar für das was man 
bekommt. Die Peripherie ist allerdings nicht ohne. Teilweise sind die 
Bezeichnungen in der Doku auch recht unglücklich und verwirrend gewählt. 
Oder wichtige Informationen zu Registern, die man eigentlich im 
Reference Manual erwartet, sind bei einem Controllertyp dann plötzlich 
im Data Sheet zu finden. Nichtsdestotrotz kann man sagen, sobald die 
Hardware erstmal läuft, kann man mit stm32 viel Freude haben.

von Marc (Gast)


Lesenswert?

Infineon bietet mit den Serien XMC1000 und XMC4000 Chips an, die einen 
Grossteil aller Anwendungen in der Industrie (und erst recht im Hobby) 
bedienen können. STM32 bietet das ebenfalls - die Auswahl ist grösser, 
die Preise eher niedriger.
Den Unterschied macht meiner Meinung nach die Entwicklungsumgebung: 
Dave4 von Infineon ist gelungen und ist tatsächlich ein "high 
productivity"-Tool, als das es beworben wird. Man kann mit den Dave-Apps 
in kürzester Zeit die komplexe Peripherie in eigene Programme 
integrieren und nutzen. Auf Registerebene braucht man sich in der Regel 
gar nicht erst zu begeben - das erledigt Dave. Für Fortgeschrittene ist 
es natürlich immer möglich, die XMC-Lib zu verwenden (entspricht der ST 
HAL-Library) oder (wer unbedingt will) die Register direkt beschreiben.
Geeignete Eval-Boards mit integriertem Debugger gibt's bei Infineon zur 
Genüge; bei ST ist die Auswahl allerdings bedeutend grösser, die Preise 
(auch hier) tiefer.
Trotzdem kann ich XMC in Verbindung mit dem kostenlosen Dave4 auch den 
Hobbyanwendern und Einsteigern in die ARM-Welt nur empfehlen. Als 
Umsteiger von der AVR-Welt auf XMC bin ich immer wieder überrascht, wie 
viel produktiver man mit Infineon XMC/Dave4 zum gewünschten Resultat 
kommt.

von Harald A. (embedded)


Lesenswert?

Marc schrieb:
> Man kann mit den Dave-Apps
> in kürzester Zeit die komplexe Peripherie in eigene Programme
> integrieren und nutzen.

Hallo Marc,
wie hast Du Dir die Möglichkeiten der Dave-App und dessen 
Baukasten-Sytem erarbeitet? Ich habe da soweit mal durchgeklickt und ein 
paar Tutorials geschaut. Man merkt regelrecht, dass das sehr 
leistungsfähig ist - allerdings sind mir viele Zusammenhänge nicht klar.
Hast Du weitere Informationsquellen oder Lektüre, die ich vielleicht 
noch nicht gesehen habe?

von Ben S. (bensch123)


Lesenswert?

Marc schrieb:
> Den Unterschied macht meiner Meinung nach die Entwicklungsumgebung:
> Dave4 von Infineon ist gelungen und ist tatsächlich ein "high
> productivity"-Tool, als das es beworben wird. Man kann mit den Dave-Apps
> in kürzester Zeit die komplexe Peripherie in eigene Programme
> integrieren und nutzen. Auf Registerebene braucht man sich in der Regel
> gar nicht erst zu begeben - das erledigt Dave.

Vielleicht habe ich Dave für einen zu kurzen Zeitrau benutzt, aber der 
Code den der ausgespuckt hat (also der Klickibunti kram) war dermaßen 
langsam, unflexibel und nicht zielführend ...

: Bearbeitet durch User
von Marc (Gast)


Lesenswert?

Hallo Ben S.,
Wie jede API bringt auch die Verwendung der Dave-Apps einen gewissen 
Overhead mit sich.
Hast die in den Compiler-Einstellungen (Project->Active Project 
Settings->Arm gcc Compiler) die Optimierung eingeschaltet? Ich wähle 
meistens "Optimize (-O1)" aus. Tut man das nicht, so hast Du Recht: Dann 
sind einige Funktionen (z.B. das Setzen von Pins) in der Tat etwas 
langsam.

von MOS (Gast)


Lesenswert?

Für STM32 spricht mittlerweile der gd32vf103&Co (auch wenn diese Second 
Source ST nicht gefällt)

von W.S. (Gast)


Lesenswert?

Marc schrieb:
> Den Unterschied macht meiner Meinung nach die Entwicklungsumgebung:
> Dave4 von Infineon ist gelungen und ist tatsächlich ein "high
> productivity"-Tool, als das es beworben wird. Man kann mit den Dave-Apps
> in kürzester Zeit die komplexe Peripherie

Bist du Infineon-Vertreter?

Den Unterschied macht der undokumentierte ROM am Programmanfang aus. 
Damit sind die Cortex-typischen Interrupts nicht von der eigenen 
Firmware belegbar und man ist auf Gedeih und Verderb auf sowas wie Dave 
angewiesen.

Zumindest diese rüde Art, die Kunden an die eigene Firma zu nageln, ist 
für mich ein totaler Showstopper.

W.S.

von Marc (Gast)


Lesenswert?

Hallo W.S.,
aber nein, natürlich ist man nicht an Dave gebunden. Für XMC kann man 
auch Keil oder IAR verwenden. Das von Dave erzeugte Filesystem ist auch 
mit diesen Tools kompilierbar.
Sogar in Dave selber ist man nicht gezwungen, auf Apps zuzugreifen. Ich 
kann auch alles "old style" ohne Apps bewältigen, wenn mir denn die Zeit 
dafür nicht zu schade wäre.
Experten brauchen Dave nicht, die können auch "zu Fuss" gehen. Alle 
anderen sind heilfroh, wenn sie Probleme innert kurzer Zeit lösen 
können, ohne all die Register des Controllers zu kennen und ohne tausend 
Seiten Dokumentation lesen zu müssen.

von W.S. (Gast)


Lesenswert?

Marc schrieb:
> aber nein, natürlich ist man nicht an Dave gebunden. Für XMC kann man
> auch Keil oder IAR verwenden. Das von Dave erzeugte Filesystem ist auch
> mit diesen Tools kompilierbar.

Du widersprichst dir selbst. Wenn man Dave nicht benutzt, dann gibt es 
auch kein von Dave erzeugtes Filesystem.

Aber den eigentlichen Kernpunkt, nämlich den ROM am Anfang hast du glatt 
übergangen.

W.S.

von Marc (Gast)


Lesenswert?

Nein, das ist kein Widerspruch.
Dave ist eine auf Eclipse basierende Entwicklungsumgebung und erstellt 
in jedem Fall ein Filesystem. Falls man Apps verwendet (ein Dave CE 
Projekt erstellt) kann man diese zum eigenen Vorteil nutzen und gelangt 
wesentlich schneller zum Ziel. Von müssen kann aber keine Rede sein.

Es ist eine reine Frage der Effizienz: Entweder man automatisiert die 
Konfiguration des Controllers, oder man erledigt das "von Hand". Für die 
Automatisierung ist der Dave Codegenerator zuständig. Codegeneratoren 
sind überall state-of-the-art, nicht nur bei Infineon. Infineon ist da 
lediglich einen Schritt weiter als die meisten Konkurrenten.
Persönlich arbeite ich nicht mehr mit IDEs, die keine automatische 
Codegeneration zur Verfügung stellen. Das ist zu ineffizient.

von Axel S. (a-za-z0-9)


Lesenswert?

Marc schrieb:

> Dave ist eine auf Eclipse basierende Entwicklungsumgebung und erstellt
> in jedem Fall ein Filesystem.

Das ist der merkwürdigste Gebrauch des Wortes "Filesystem", der mir 
bislang untergekommen ist.

> Falls man Apps verwendet (ein Dave CE
> Projekt erstellt) kann man diese zum eigenen Vorteil nutzen und gelangt
> wesentlich schneller zum Ziel.
>
> Es ist eine reine Frage der Effizienz: Entweder man automatisiert die
> Konfiguration des Controllers, oder man erledigt das "von Hand". Für die
> Automatisierung ist der Dave Codegenerator zuständig.

Klar. Mit "Malen nach Zahlen" kommt man auch schneller zu einem Bild, 
als wenn man die Malerei erst erlernen würde. OK, es sieht Scheiße aus 
und individuell ist es auch nicht. Aber irgendwas ist ja immer.

> Codegeneratoren sind überall state-of-the-art, nicht nur bei Infineon.

Millionen Fliegen können nicht irren!

von W.S. (Gast)


Lesenswert?

Marc schrieb:
> Nein, das ist kein Widerspruch.
> Dave ist eine...

Also nochmal zum Nachlesen:

Marc schrieb:
> natürlich ist man nicht an Dave gebunden. Für XMC kann man
> auch Keil oder IAR verwenden. Das von Dave erzeugte Filesystem ist auch
> mit diesen Tools kompilierbar.

Wenn man - wie du schriebest - nicht an Dave gebunden ist, dann hat 
man auch kein von Dave erzeugtes Irgendwas (oder Filesystem etc.). 
Soweit klaro?

Das ist der Widerspruch in deinem Beitrag.

Für STM32-Leute hieße das (analog zu deinen Ausführungen) so: Wenn man 
Cube NICHT benutzt, dann gibt es auch keine von Cube erzeugte Datei. 
Und wo keine Datei ist, da kann man auch nichts kompilieren.

Und du bist noch immer nicht auf den ROM am Anfang eingegangen. Das war 
jedoch der eigentliche Punkt.

W.S.

von Nop (Gast)


Lesenswert?

W.S. schrieb:

> Und du bist noch immer nicht auf den ROM am Anfang eingegangen. Das war
> jedoch der eigentliche Punkt.

Mit irgendwelchem undokumentierten Code verbieten sich diese Chips ja 
eigentlich für alle Anwendungen, bei denen etwas zertifiziert werden 
muß, oder?

von Bauform B. (bauformb)


Lesenswert?

W.S. schrieb:
> Den Unterschied macht der undokumentierte ROM am Programmanfang aus.
> Damit sind die Cortex-typischen Interrupts nicht von der eigenen
> Firmware belegbar

Gibt es in der Familie überhaupt einen Cortex-M0, also mit Vektortabelle 
fest auf 0? Bei allen anderen spielt das doch überhaupt keine Rolle?

von F. M. (foxmulder)


Lesenswert?

Nop schrieb:
> verbieten sich diese Chips ja
> eigentlich für alle Anwendungen, bei denen etwas zertifiziert werden
> muß, oder?

Ja dafür braucht es wieder Ucnet.
Die XMC werden in großem Umfang in Medizintechnik und Automotive 
verwendet, kann also doch nicht so schlecht sein.

Beitrag #6427078 wurde vom Autor gelöscht.
von Christopher J. (christopher_j23)


Lesenswert?

Nop schrieb:
> W.S. schrieb:
>
>> Und du bist noch immer nicht auf den ROM am Anfang eingegangen. Das war
>> jedoch der eigentliche Punkt.
>
> Mit irgendwelchem undokumentierten Code verbieten sich diese Chips ja
> eigentlich für alle Anwendungen, bei denen etwas zertifiziert werden
> muß, oder?

Wenn man für sechsstellige Beträge Aufträge in den Raum stellt und noch 
eine NDA unterschreibt gibts bestimmt auch die komplette Doku.

von W.S. (Gast)


Lesenswert?

Bauform B. schrieb:
> Gibt es in der Familie überhaupt einen Cortex-M0, also mit Vektortabelle
> fest auf 0? Bei allen anderen spielt das doch überhaupt keine Rolle?

Ja, Cortex M0 gibt es. Und auch für all die anderen spielt es eine 
Rolle, denn auch da muß erstmal die eigentliche Firmware gestartet 
worden sein, bevor selbige die Chance hat, die Vektortabelle zu 
verlegen.

W.S.

von dummschwaetzer (Gast)


Lesenswert?

Bei uns sind sie XMC als "problematisch in der Beschaffbarkeit" 
eingestuft, die STM nicht

von Bastelhase (Gast)


Lesenswert?

dummschwaetzer schrieb:
> Bei uns sind sie XMC als "problematisch in der Beschaffbarkeit"
> eingestuft, die STM nicht

Hab gerade bei Reichelt und Conrad nachgeschaut, da gibt es keine XMCs. 
STMs gibt es etliche, daher fallen die XMCs schon mal weg.

von F. M. (foxmulder)


Lesenswert?

Bastelhase schrieb:
> daher fallen die XMCs schon mal weg

Ach, Mouser existiert nicht.
lol

von Marc (Gast)


Lesenswert?

Es kommen hier alle möglichen wirren Argumente gegen Infineon und dessen 
Controller zum Vorschein.
Mein Grundargument war eigentlich mehr ökonomischer Natur:
Warum nicht ein Tool verwenden (wie z.B. Dave), mit dem ich einen 
Bruchteil der Zeit  für Firmwareprojekt benötige, als wenn ich mit den 
gängigen nicht auf API-basierenden Tools arbeite? Es kommt ja auch 
niemand mehr auf die Idee, umfangreiche Programme in Assembler zu 
erstellen!
Gegen STM Controller habe ich gar nichts. Mehr gegen deren (derzeitigen) 
Design-Tools. Ich verwende lieber etwas, womit ich doppelt so schnell 
bin und gleichzeitig halb so viel Details der HW kennen muss.
Das war alles!

von Bernd (Gast)


Lesenswert?

Marc schrieb:
> Ich verwende lieber etwas, womit ich doppelt so schnell
> bin und gleichzeitig halb so viel Details der HW kennen muss.
Ich verwende lieber Hardware, die ich zu 100% verstanden habe, als das 
ich später ewig einen Fehler suche, der durch obskure 
Softwarekomponenten entstanden ist, die ich nicht beeinflussen kann...

von Harald A. (embedded)


Lesenswert?

Marc schrieb:
> Es kommen hier alle möglichen wirren Argumente gegen Infineon und dessen
> Controller zum Vorschein.
> Mein Grundargument war eigentlich mehr ökonomischer Natur

Ich finde deine Beiträge grundsätzlich gut, ich hatte ja gefragt, ob Du 
Infos zu weiterführender Lektüre hast. Leider hast Du darauf nicht 
geantwortet.

Die gibt es für die STM zwar auch nicht direkt vom Hersteller, 
allerdings sind die Produkte aufgrund der Verbreitung von 
verschiedensten Quellen sehr gut dokumentiert. Kann man von den XMC 
nicht gerade behaupten, daher die Frage.

von Marc (Gast)


Lesenswert?

Hallo Harald,

leider hast Du recht: Infineon tut zu wenig, um XMC und Dave unter die 
Leute zu bringen. Eigentlich wäre das Tool wie geschaffen sein auch für 
die Maker-Szene, die sich am Ergebnis zu orientieren pflegt und den 
Controller/IDE als blosses Werkzeug versteht, das einfach und effektiv 
sin soll, damit die Projekte zügiger umgesetzt werden können.
Hier ein paar Links, die dir weiterhelfen:

https://www.infineon.com/dgdl/Infineon-DAVE_Quick_Start-GS-v02_00-EN.pdf?fileId=5546d4624cb7f111014d059f7b8c712d
https://www.youtube.com/watch?v=s9qgiaxKZrM
https://www.youtube.com/watch?v=zzxLz4jeAqc
https://www.youtube.com/watch?v=pjxkByoaHNI

Natürlich findest Du auch auf den Infineon-Foren und auf der Infineon 
Homepage einiges an Infos. Google hilft auch weiter.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

Gibt es inzwischen die Header-Files ohne unsaeglich Lizenzvereinbarung ?

von MaWin (Gast)


Lesenswert?

W.S. schrieb:
> Bist du Infineon-Vertreter?

Klingt eindeutig danach.

Und zwar von der Sorte, der die Werbebroschüren gelesen hat, aber noch 
nie ein einziges Projekt damit umgesetzt hat.

Marc schrieb:
> Warum nicht ein Tool verwenden (wie z.B. Dave), mit dem ich einen
> Bruchteil der Zeit  für Firmwareprojekt benötige, als wenn ich mit den
> gängigen nicht auf API-basierenden Tools arbeite?

Weil die Tools so grottenschlecht sind, dass nur Kinderspielzeug bei 
rauskommt, ist mit ST CubeMX (auch im Eclipse--Rotz) und Arduino ja auch 
nicht anders.

Jedes ernsthafte uC Programm muss die Resourcen dermassen geschickt 
ineinander verzahnen, dass der generierte code schon mal unbrauchbarer 
Müll ist.

Und an statt Konfigurationsregister erst komplex und unlogisch 
durcheinanderzuwürfeln, damit man hinterher Tools benötigt, die einem 
die richtige Belegung - auch nicht klar und deutlich zeigen, sondern 
noch intransparenter hinter einer Schicht verstecken, könnte man es ja 
auch mal mit ordentlicher Struktur in Hardware und Doku versuchen.

Es gibt viele bessere und billigere Prozessoren, vergesst XMC.

Marc schrieb:
> Ich verwende lieber etwas, womit ich doppelt so schnell bin und
> gleichzeitig halb so viel Details der HW kennen muss.

Also einen einfachere Hardwarearchitektur mit besserer Doku. Schade, 
dass Infineon so was nicht hat.

von Marc (Gast)


Lesenswert?

Ich kann MaWins generelle Ablehnung dieser Tools nicht ganz 
nachvollziehen. Nicht jeder ist Experte in der Programmierung von 
Controllern, die meisten Anwender haben auch weder Zeit noch Lust, es zu 
werden. Damit auch diese die Stärken eines 32bit-Prozessors für sich 
nutzen können, sind eben diese Tools gedacht. Ein Experte (wie MaWin 
einer zu sein scheint) mag die Nase rümpfen und andere Werkzeuge 
bevorzugen. Das ist sein gutes Recht. Nur: Wenn er für jedes Projekt die 
x-fache Zeit benötigt, dann wird er sich sicherlich nicht auf das 
nächste Qualifikationsgespräch mit seinem Vorgesetzen freuen.

von W.S. (Gast)


Lesenswert?

Ich muß das mal auseinandernehmen:

Marc schrieb:
> Ich kann MaWins generelle Ablehnung dieser Tools nicht ganz
> nachvollziehen.

Ich schon. Denn derartige Tools sind nur für 2 Ziele gedacht und 
gemacht:
1. Bindung des Kunden. Jemand der ohne so ein Tool keinen Fuß auf den 
Teppich kriegt, wird schlichtweg nicht wechseln können.
2. Workarounds liefern für schlecht gestaltete Hardware.

> Nicht jeder ist Experte in der Programmierung von
> Controllern, die meisten Anwender haben auch weder Zeit noch Lust, es zu
> werden.

Wer nicht Experte ist für IRGEND EINEN JOB, der muß entweder dazulernen 
oder er ist für den Job ungeeignet. Punkt.

Und die meisten Anwender müssen sich sehr wohl den/die für ein geplantes 
Projekt in Frage kommenden Controller sehr genau anschauen und dabei 
deren eingebaute Peripherie gründlich auf Eignung abklopfen, bevor 
damit die Entwicklung gestartet wird, sonst ist nämlich das 
Auf-Die-Fresse-Fallen später angesagt. Ob man dazu Lust hat oder 
nicht, ist nebensächlich. Ob man sich dafür die Zeit nimmt oder nicht, 
ist hingegen sehr wichtig und entscheidet über den Erfolg.


> Damit auch diese die Stärken eines 32bit-Prozessors für sich
> nutzen können, sind eben diese Tools gedacht.

Dir schwebt also als Kunde ein fachlich inkompetenter 
Entwicklungsingenieur vor.

Nun, gut zu wissen.

Ich habe schon vor Jahren die XMC's mir näher angeschaut und danach aus 
gutem Grund auf meine persönliche schwarze Liste gesetzt. Fühle mich 
durch dich bestätigt.

W.S.

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

Wir haben sogar einen Mal wieder aus einem Design geworfen weil das Ding 
derart schlecht dokumentiert war das wir nichtmal das can Modul 
ordentlich zum laufen gebracht haben bzw. der von DAVE generierte Code 
voller Bugs war. Die Familie skaliert auch nicht nach oben. Da sind die 
TriCores im Weg.

von Axel S. (a-za-z0-9)


Lesenswert?

W.S. schrieb:
> Dir schwebt also als Kunde ein fachlich inkompetenter
> Entwicklungsingenieur vor.
>
> Nun, gut zu wissen.

LOL. Erinnert mich an ein Meeting mit dem Vertriebler einer Firma, die 
hoffte, unser Lieferant zu werden. Mein Teamleiter faßte nachher das 
Meeting gegenüber unserem Chef so zusammen: "Deren Zielgruppe sind 
inkompetente Idioten mit viel Geld". Die Welt ändert sich nicht.

von Marc (Gast)


Lesenswert?

Ich vermute mal, dass die Firma tatsächlich euer Lieferant wurde;)

von babam (Gast)


Lesenswert?

Ich habe sowohl STM32 mit CubeMX als auch schon XMC mit dem Dave 
programmiert und würde sagen ich kenne beide Tools.

Grundsätzlich finde ich die Dave Umgebung sogar angenehmer.

Bei STM ist es ja so, dass man erst im Cube etwas konfiguriert und dann 
wird ein Projekt exportiert, das man anschließend mit der IDE öffnet.
Mir ist aber aufgefallen, dass mit jedem neuen exportieren (nachdem man 
was im CubeMX geändert hat), die main.c immer wieder leer ist.
Auch wenn man z.B. irgendwelche hardware-Querverlinkungen zwischen 
Hardwaremodulen machen will, bei CubeMX das immer nur per Drop-Down Feld 
angezeigt wird.

Bei Dave ist es so, dass das CubeMX und die IDE direkt verschmolzen 
sind. Man zieht sich dann "Apps" zusammen, wie z.B. Uart oder Timer und 
kann sogar z.B. Interrupt-Verbindungen oder so direkt grafisch aufzeigen 
lassen im Tool.
Was viele nicht wissen, wenn man im Dave auf die interne Hilfe geht, 
findet man hunderte gut dokumentierte Codebeispiele für jedes beliebige 
Peripheral - sind allerdings wie gesagt in der Hilfe versteckt und habe 
damit quasi alles gelöst bekommen bisher.

von babam (Gast)


Lesenswert?

Aber ja ich kann verstehen, wieso viele hier ST mehr mögen - privat 
arbeite ich dann auch tendenziell eher mit STM32 als mit XMC.
Man findet viele billige Boards im Internet + es ist eine große 
Community dahinter. Bei XMC kriegt man die Boards oder Bausteine immer 
erst über Mouser & co.

Was die Dokumentation angeht würde ich sagen, sind die User-Manuals von 
ST sowie XMC beide gleich gut / schlecht.
Manche Passagen sind einfacher zu lesen und manche schwerer. Das kann 
von der einen Peripherie zur nächsten recht unterschiedlich sein. Je 
nachdem welche Person es ursprünglich mal geschrieben hat.

Wirklich auf Registerebene musste ich bei beiden Controllern aber noch 
nicht gehen. Eher um die HW ein bisschen zu verstehen, um entsprechend 
die Konfigurationen im CubeMX/Dave zu verstehen.

von Harald A. (embedded)


Lesenswert?

babam schrieb:
> Wirklich auf Registerebene musste ich bei beiden Controllern aber
> noch nicht gehen. Eher um die HW ein bisschen zu verstehen

Das klingt jetzt ein ganz klein wenig nach User „babam“ = „Marc“. Nun 
ja, vielleicht Zufall.

Versuche mal anhand der vorhandenen Doku bzw. vorkonfigurierten Module 
in Dave einen 32bit Capture zu realisieren. Dazu muss man nämlich die 
auf 16bit ausgelegte HW kaskadieren und die Fallstricke kennen. Sage 
jetzt bitte keiner, dass 32bit Capture zu exotisch sei. Zur vernünftigen 
Erfassung von kleineren Frequenzen per Zeitmessung ist das m.E. nach 
State-of-the-Art.

Oder synchronisiere mal die PWM-Outputs (meinetwegen 16bit) mit dem 
AD-Wandler mit den Dave-Apps. Vielleicht ist das alles ja ganz einfach. 
Dokumentation/Beispiele/Verbreitung würden helfen.

Oder wie wäre es mit der Einbindung gemultiplexter ADC-Eingänge (von der 
HW unterstützt!) per Dave-App.

: Bearbeitet durch User
von allesKäse (Gast)


Lesenswert?

W.S. schrieb:
> Dir schwebt also als Kunde ein fachlich inkompetenter
> Entwicklungsingenieur vor.

Kurzfassung für: W.S.

von Axel S. (a-za-z0-9)


Lesenswert?

babam schrieb:
> Ich habe sowohl STM32 mit CubeMX als auch schon XMC mit dem Dave
> programmiert und würde sagen ich kenne beide Tools.
>
> Grundsätzlich finde ich die Dave Umgebung sogar angenehmer.
>
> Bei STM ist es ja so, dass man erst im Cube etwas konfiguriert und dann
> wird ein Projekt exportiert, das man anschließend mit der IDE öffnet.

Nein. Das ist nicht "bei STM" so, sondern "bei CubeMX". Kein Mensch 
zwingt dich dazu, CubeMX zu benutzen. Denn selbstverständlich gilt alles 
zu Dave gesagte sinngemäß auch für CubeMX.

> Mir ist aber aufgefallen, dass mit jedem neuen exportieren (nachdem man
> was im CubeMX geändert hat), die main.c immer wieder leer ist.

You're holding it wrong. Du hast ernsthaft noch nicht den Knopf in 
CubeMX gefunden, daß es beim Neugenerieren deinen Code nicht anfassen 
soll?

> Bei Dave ist es so, dass das CubeMX und die IDE direkt verschmolzen
> sind. Man zieht sich dann "Apps" zusammen, wie z.B. Uart oder Timer und
> kann sogar z.B. Interrupt-Verbindungen oder so direkt grafisch aufzeigen
> lassen im Tool.

Toll. Ich hatte mich schon gewundert, was "Apps" sein sollen. Was soll 
der Scheiß, die vorhandenen, bekannten, herstellerübergreifenden und bei 
Cortex-M in vielen Bereichen (z.B. NVIC) sogar standardisierten 
Abstraktionen gegen herstellerspezifische Abstraktionen a'la "Apps" 
einzutauschen? Ach so, Kundenbindung. War ja klar.

babam schrieb:
> Wirklich auf Registerebene musste ich bei beiden Controllern aber
> noch nicht gehen.

Es ist genau anders herum. Die Register sind das, was ist. Die Register 
sind das, worüber man so oder so gehen muß. Was soll der Unsinn, da 
jetzt eine weitere Abstraktionsebene drüber zu legen? Die Frage stellt 
sich genau anders herum: wenn man die Register ohnehin hat und sämtliche 
Dokumentation dazu auch ... warum sollte man dann über HAL oder Cube 
oder Dave gehen?

Und ja, die Register muß man so oder so kennen. Spätestens dann, wenn 
man den Krempel mal debuggen will.

> Eher um die HW ein bisschen zu verstehen, um entsprechend
> die Konfigurationen im CubeMX/Dave zu verstehen.

Siehst du! Diese Abstraktionslayer sind gar nicht hilfreich. Sie fügen 
Komplexität hinzu. Und oft sind sie schlechter dokumentiert als das, was 
sie zu abstrahieren vorgeben.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

Marc schrieb:
> Ich kann MaWins generelle Ablehnung dieser Tools nicht ganz
> nachvollziehen. Nicht jeder ist Experte in der Programmierung von
> Controllern, die meisten Anwender haben auch weder Zeit noch Lust, es zu
> werden.

Ich schon. Wenn Du Software-Entwicklung nicht beruflich machst (kein 
Experte bis), dann mögen diese Tools vielleicht hilfreich sein.

Wenn Du das beruflich machst, dann wird der Controller meist nach 
anderen Kriterien ausgesucht, und nicht ob die IDE / Code-Generator ganz 
nett ist. Da kommt es auch nicht selten vor, dass mehr als ein 
Controller im Projekt eingesetzt werden.

Da möchtest Du nicht 3 verschiedene Eclipse Varianten mit 
unterschiedlichen, auf XML basierenden build Systemen. Da möchtest Du 
1-2 Compiler und ein build system, dass von Deinem CI System bedient 
werden kann (sprich von der Kommandozeile aus bedienbar ist) und von 
Deiner Quellcode-Verwaltung vor dem checkin mal gebaut werden kann.

Da arbeitet man auch selten noch alleine und da möchte ich die 
Änderungen an der build Konfiguration in der Quellcode-Verwaltung, die 
mein Kollege vor seinem Urlaub gemacht hat, nachvollziehen können und 
keine 2000 Zeilen-Änderung an einer riesigen XML-Datei sehen. Hast Du 
mal versucht unit tests in so ein Klickibunti-Monster zu integrieren 
(klar, geht das. Ist ja nur Eclipse, ist aber kein Spaß und skaliert 
auch nicht)?

> Damit auch diese die Stärken eines 32bit-Prozessors für sich
> nutzen können, sind eben diese Tools gedacht.

Nein, diese Tools sind für eine flache Lernkurve gedacht. Mit einem 
Klick hier und da, bekomme ich etwas funktionierendes hin und lerne 
schon mal den Controller kennen. Die Hardware wirst Du damit nicht 
optimal ausnutzen können.

> Nur: Wenn er für jedes Projekt die
> x-fache Zeit benötigt, dann wird er sich sicherlich nicht auf das
> nächste Qualifikationsgespräch mit seinem Vorgesetzen freuen.

Wird er! Wenn die Dokumentation und das peripheral design eines 
Controllers vernünftig ist, wird er schnell zum Ziel kommen und 
testbaren, lesbaren, wartbaren, portablen Code produzieren, der auch 
noch baubar ist, wenn Dave das XML Datei-Formart geändert hat und 
Infineon aufgekauft und zerschlagen wurde. Sein Vorgesetzter wird ihm 
Dankbar sein (ok, hier sind die Pferde mit meiner Phantasie 
durchgegangen ;-), dass der bestehende Code leicht auf den Controller 
der Konkurrenz portierbar ist.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Torsten R. schrieb:
> Ich schon.

Also Torsten, es hat garantiert wenig Zweck, mit einem Bauernfänger 
diskutieren zu wollen. Der einzige Nutzen besteht darin, daß all die 
Leute, die hier mitlesen, sehen können, wie es in der Realität läuft. 
Das hilft dann hoffentlich dem einen oder anderen, von so einem 
Bauernfänger nicht hereingelegt zu werden.

W.S.

von Christopher J. (christopher_j23)


Lesenswert?

Torsten R. schrieb:
> Nein, diese Tools sind für eine flache Lernkurve gedacht. Mit einem
> Klick hier und da, bekomme ich etwas funktionierendes hin und lerne
> schon mal den Controller kennen. Die Hardware wirst Du damit nicht
> optimal ausnutzen können.

Richtig, diese Tools sind dafür gedacht einem Schlipsträger zeigen zu 
können "wie einfach doch alles ist". Gewissermaßen ist das Arduino für 
"Profis".

Der Vendor-Lockin-Effekt ist aber doch das, was eigentlich zählt. Einmal 
Dave, immer Dave. Die Komplexität wird vom Controller in die 
(herstellerspezifische) Entwicklungsumgebung verlagert. Der Zukauf von 
Cypress passt da für mich genau in dieses Schema, da deren 
PSoC-Controller schließlich auch nur durch die herstellerspezifische IDE 
ihr wahres (gar nicht so geringes) Potential entfalten können.

Das Endstadium ist dann eine Symbiose aus Dave und Dave-Ingenieuren. Der 
Dave-Ingenieur kann nichts anderes außer Dave (aber das dafür leidlich 
gut). Der Dave-Ingenieur wird also firmenintern stets Dave promoten, da 
er sich ja seinen eigenen Ast nicht absägen will und der Dave-Hersteller 
freut sich über ein Quasimonopol gegenüber seinem Kunden.

von F. M. (foxmulder)


Lesenswert?

Wie schaut es eigentlich mit STM32 vs LPC aus?
Kann irgendwer berichten, der beruflich/privat mit NXP arbeitet?
Mir sind vor kurzem die LPC84x ins Auge gefallen, oder die LPC5500.

Mir gefällt, dass der Hersteller aus Europa ist, zumal die Chips recht 
billig sind, die LPC84x kosten ja nur knapp 2 Euro.

Wie schaut es mit der Toolchain und Dokumentation aus?

mfg

von Harald (Gast)


Lesenswert?

A. K. schrieb:
> Wie schaut es mit der Toolchain und Dokumentation aus?

Ich arbeite mit Prozessoren aus beiden Familien. Im Großen und Ganzen 
gibt es bei beiden Familien Vor- und Nachteile, die sich meiner Meinung 
nach die Waage halten. Toolchain bei LPC ebenfalls Eclipse-basierend, 
also sehr ähnlich. Dokumentation finde ich bei beiden gut und 
ausreichend, tendenziell findet man für die STM32 etwas mehr Support im 
Netz. Was ich bei dem LPC sehr gut finde ist der bei vielen Derivaten 
werkseitig eingebaute USB-Bootloader (z.B. LPC11U35 oder LPC11U68). Das 
Device taucht als Memorystick auf, firmware.bin drauf und los gehts.

von Johannes S. (jojos)


Lesenswert?

Die 'kleinen' LPC812/824 habe ich benutzt für Funknodes mit RFM69, die 
finde ich sehr gut. Einfach, überschaubar, mit MCUXpresso IDE und dem 
LPCLink(2) war das debuggen auch immer sehr einfach weil es wirklich 
Plug&Play war. Die Doku zu den Teilen ist sehr gut, Counter sind bei LPC 
auch fast alle 32 Bit. Dazu das Pinmap Feature mit dem Funktionen auf 
beliebige IO Pins gelegt werden können (mit wenigen Einschränkungen). 
Für den LPC1347 gab es ein Breakout Board von einem CCC Projekt, das war 
auch besser als die Arduinos aber da waren hier noch alle der Meinung 
das 8 Bitter genug sind und irgendwie waren die LPC der Zeit voraus. 
Jetzt haben die STM32 massiv aufgeholt und ihr agressives Marketing 
funktioniert. Aber Tools wie STMCubeMX sind kontinuierlich 
weiterentwickelt worden und mittlerweile ein wertvolle Hilfe geworden. 
Auch wenn man den Codegenerator nicht mag, kann man damit die Pins 
verplanen und sieht welche Features man in den Interfaces konfigurieren 
kann. Dazu die Clockconfiguration, Strombedarfsberechnung und weiteren 
neuen Features. Wie weit NXP da ist weiss ich nicht, habe da jetzt schon 
länger nicht mehr reingeguckt. Der LPC845 liegt hier auch noch rum und 
wartet auf einen Einsatz. Das LPC845BRK ist auch preislich 
konkurenzfähig, aber hier hat der kaum Beachtung gefunden.
Dann empfiehlt hier jemand häufig den LPC4088, der ist aber auch schon 
in die Jahre gekommen (Autor oder Chip? vermutlich beide :) ) Aber 
gerade bei dem Einsatz für Grafik oder Ethernet sehe ich bei STM 
deutlich mehr Power. Und die kaufen die Anbieter für Grafiklibs und 
versuchen damit anderen das Wasser abzugraben.

: Bearbeitet durch User

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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