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
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"??
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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?
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 ...
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.
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.
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.
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.
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.
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!
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.
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?
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?
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.
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.
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.
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.
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!
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
