Announcement: there is an English version of this forum on 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.
Das letzte Mal, wo ich XMC angeschaut hatte, bekam man die Header Files nur nach Abnicken einer eckligen Lizenzvereinbarung.
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.
Ganz nebenbei gibts beim XMC keinen Cortex-M7 (soweit mir bekannt). Die wollen da vermutlich, dass man stattdessen auf die eigenen Tricore geht...
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 ...
:
Bearbeitet durch User
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.
Beitrag #6427078 wurde vom Autor gelöscht.
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.
Bei uns sind sie XMC als "problematisch in der Beschaffbarkeit" eingestuft, die STM nicht
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.
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.
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.
:
Bearbeitet durch User
W.S. schrieb: > Dir schwebt also als Kunde ein fachlich inkompetenter > Entwicklungsingenieur vor. Kurzfassung für: W.S.
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.