Hallo, die Suche über TI liefert hier relativ ältere Beträge und bei Fragen wie "Welchen µC / Umstieg AVR zu ARM / Erfahrung mit TI?..." wird zum größten Teil STM32 vorgeschlagen. Momentan arbeite ich selbst mit dem STM32F407/-F107 mit Keil und dies gefällt mir auch sehr gut. Ich stelle die Frage einfach nur aus Interesse, denn irgendwie seltsam das STM32 so verbreitet ist und TI Boards eher nicht. Hat hier überhaupt jemand Erfahrungen mit TI DevKit's mit ARM Controllern gemacht? Grüße apneofreak
Christian K. schrieb: > irgendwie seltsam das STM32 so verbreitet ist und TI Boards eher nicht. Da fehlt irgendwie eine klare Linie. Cortex M0(+) gibt es nicht, weil der mit MSP430 konkurrieren würde. M3 war Stellaris. Die aktuelle Webseite hat keine Informationen mehr, außer einem Link auf ein Dokument "Transitioning Designs From Stellaris® LM3S Microcontrollers to Tiva™ C Series Microcontrollers". M4 war bisher Tiva C (TM4C12x). Allerdings wird es keine Neuentwicklungen mehr geben. MSP432 ist M4 mit MSP430-Peripherie. Das ist die Zukunft, aber in der Gegenwart gibt es erst einmal nur zwei Modelle. (Der Gründ für den Wechsel ist wahrscheinlich, dass MSP430 erfolgreicher als alle ARMs von TI ist.)
Frei nach den Gebrüdern Grimm: Es war einmal vor langer Zeit eine sehr innovative Firma namens "Luminary Micro", die tolle Controller mit einer guten Entwicklungsumgebung anbot. Diese wurde von TI aufgekauft um auch mit dem damals rasant beschleunigenden ARM-Zug mitfahren zu können. Als Optimist hoffte ich auf Produkte, die das Beste beider Welten (ARM Cortex + MSP430) vereinen... Vermutlich stammen die Beiträge zu TI aus dieser Zeit, als TI noch die aufgekauften LM3S-irgendwas Controller anbot. Wie gesagt, tolle Teile mit guter Peripherie. Doch dann begann plötzlich die böse Abkündigungspolitik, Distributoren wurden nervös und viele Devices waren praktisch über Nacht schlecht erhältlich oder NRND. Der TI Support versuchte zu beruhigen, von "Missverständnissen" war die Rede, pinkompatible Alternativen wurden versprochen. Und wem der Kunde nicht abgesprungen ist, der wartet bestimmt noch heute... Für unsere Firma war das der Grund zum Wechsel, da es durch die Abkündigungspolitik zu neuen Boardlayouts und Verzögerungen kam. Wir haben verschiedene Alternativen evaluiert (Freescale, NXP, Energy Micro...) und sind dann bei STM hängen geblieben. Die Libraries / Doku von ST hat mich nicht ganz überzeugt, die (anfangs etwas holprige) Einbindung in Matlab / Simulink war ausschlaggebend.
Da gibt es zudem noch einen leichten Hang zur Hochpreisipolitik. Die Eval-boards sind ok, aber Controllerpreise liegen meist über den Vergleichbaren der Konkurenz.
Okay, danke für eure Antworten. Mal sehen wie sich TI so in der Praxis anstellt. Im Auge hab ich das CC2650 Wireless MCU LaunchPad. Grüße und noch einen schönen Feiertag!
Christian K. schrieb: > Okay, danke für eure Antworten. > Mal sehen wie sich TI so in der Praxis anstellt. Im Auge hab ich das > CC2650 Wireless MCU LaunchPad. Ahh, tue es nicht, wenn Dir etwas an Deinem Verstand liegt. Wenn Du was mit Bluetooth LE machen möchtest, dann guck Dir lieber den nrf52 von Nordic an. Die Software-"Archtiktur" von TI ist wirklich gruselig!
Torsten, du hast vollkommen Recht..gruselig! Ein Mitstudent hat mir das Devboard ausgeliehen und ich konnte den CC2650 testen. Die Hardware lass ich mal außen vor, da ich neben BT und bissle I²C nicht mehr gemacht habe. Im Vergleich zu anderen IDE's (KEIL, AVR-Studio) ist Code Composer Studio einfach lahm (und damit meine ich nicht nur die Geschwindigkeit). Das nervt unheimlich beim Arbeiten. Dazu kommen noch gelegentliche Abstürze und andere Probleme. Wie zum Beispiel Anfangs bei der Erst-Installation, falls man nicht auf Default-Partition installiert (c:\). Die Beispiel Projekte laufen dann nämlich nicht. Sobald man diese, aus dem noch lahmeren Resource Explorer importieren will, suchen diese im Default Pfad (c:\) mehrere abhängige Dateien zum Erstellen des Projektes. Diese liegen ja nun woanders! Also fängt man an, zu googlen, die Projekte manuell zu importieren usw. bis man dann doch neu installiert weil man Anfangs keinen Plan und Nerv mehr hat. Für Neueinsteiger recht mieß. Weiter geht es dann mit dem "Video Browser" im welchen man die Tutorial Videos abspielen kann, also parallel zum Programm. Macht man nun einen Build bei laufendem Video, so verabschiedet sich das ganze Programm. Deshalb lieber im Browser Youtube nutzen und vorher mal save ;) ! Hat man nun den nervigen Anfang überlebt, so kann man dann trotzdem mit der IDE arbeiten. Wie gesagt im Vergleich verliert sie. Die Tutorial-Videos, das Wiki und Training sind schon sehr gut und hilfreich. Was mir ansonsten an TI gefallen hat, sind die ausführlichen Datasheet's zur Hardware und viele zusätzliche Informationen. Falls ich bald Zeit finde, teste ich noch IAR mit dem Kit.
Torsten R. schrieb: > Die Software-"Archtiktur" von TI ist wirklich gruselig! Torsten, du hast vollkommen Recht..gruselig! Ein Mitstudent hat mir das Devboard ausgeliehen und ich konnte den CC2650 testen. Die Hardware lass ich mal außen vor, da ich neben BT und bissle I²C nicht mehr gemacht habe. Im Vergleich zu anderen IDE's (KEIL, AVR-Studio) ist Code Composer Studio einfach lahm (und damit meine ich nicht nur die Geschwindigkeit). Das nervt unheimlich beim Arbeiten. Dazu kommen noch gelegentliche Abstürze und andere Probleme. Wie zum Beispiel Anfangs bei der Erst-Installation, falls man nicht auf Default-Partition installiert (c:\). Die Beispiel Projekte laufen dann nämlich nicht. Sobald man diese, aus dem noch lahmeren Resource Explorer importieren will, suchen diese im Default Pfad (c:\) mehrere abhängige Dateien zum Erstellen des Projektes. Diese liegen ja nun woanders! Also fängt man an, zu googlen, die Projekte manuell zu importieren usw. bis man dann doch neu installiert weil man Anfangs keinen Plan und Nerv mehr hat. Für Neueinsteiger recht mieß. Weiter geht es dann mit dem "Video Browser" im welchen man die Tutorial Videos abspielen kann, also parallel zum Programm. Macht man nun einen Build bei laufendem Video, so verabschiedet sich das ganze Programm. Deshalb lieber im Browser Youtube nutzen und vorher mal save ;) ! Hat man nun den nervigen Anfang überlebt, so kann man dann trotzdem mit der IDE arbeiten. Wie gesagt im Vergleich verliert sie. Die Tutorial-Videos, das Wiki und Training sind schon sehr gut und hilfreich. Was mir ansonsten an TI gefallen hat, sind die ausführlichen Datasheet's zur Hardware und viele zusätzliche Informationen. Falls ich bald Zeit finde, teste ich noch IAR mit dem Kit.
Christian K. schrieb: > Im Vergleich zu anderen IDE's (KEIL, AVR-Studio) ist Code Composer > Studio einfach lahm (und damit meine ich nicht nur die Geschwindigkeit). Naja, ich würde präferieren, wenn mir der Hersteller die Wahl der IDE selbst überlässt und vor allem, ob ich überhaupt eine nutzen möchte. Es soll ja schon vorgekommen sein, dass in einem Projekt mehrere Controller verwendet werden und dann möchte ich ungern verschiedenste Versionen von Eclipse benutzen müssen. TI ist aber nicht einmal in der Lage zu beschreiben, wie man bei deren Architektur ein Projekt aufsetzt. Die einzige Information die man bekommt, ist: "Nimm ein Beispiel und ändere das, bis es bei Dir passt". Und wenn die ihr SDK auf eine neue Version heben, dann geht das Spiel von vorne los. Das "übliche" Vorgehen, wenn man die Version einer Library von 2.1 auf 2.2 ändert, ist das man den include und library path ändert und die Software dann einmal neu baut. Nicht so bei TI. Ich habe 2 Wochen gebraucht um einen Fehler in deren SDK zu finden (https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/t/532290#pi239031350=1). Ich habe im Forum gebettelt und gefleht. Ich habe nach kommerziellem Support gefragt, nix. Nicht mal irgend ein "Ups, tut uns leid, wird gefixed", nach dem ich den Fehler gefunden hatte.
Torsten R. schrieb: > Das "übliche" Vorgehen, wenn man die Version einer > Library von 2.1 auf 2.2 ändert... Tja, so ist es eben. Aber da ist man bei TI ja nicht allein. Schau bloß mal, wie viele Leute die ST-Lib benutzen oder irgend ein CMSIS-Gedöns ihres Lieblings-Herstellers. Krass wird sowas bei Chips, die eine abartige HW-Konstruktion haben (XMC), wo man auf die Tools des Herstellers angewiesen ist. Ich mach da lieber mein Ding für mich, verlasse mich auf keinerlei Hersteller-Lib, Hersteller-Startup und so. Auf lange Sicht ist das hilfreich, denn wenn man sein eigenes Zeugs hat, ist man unabhängig von den Faxen der Hersteller. Bei den Stellaris hatte mich geärgert, daß sie nur einen Einmal-Bootlader enthielten, also einen, der nicht resident im ROM steht, sondern im Flash und der folglich beim allerersten Flashen verloren geht. Da hatten mir damals die Nuvoton-Chips schon besser gefallen, denn die haben einen separaten Flash für nen Bootlader eigener Wahl vorgesehen. Aber die Europa-Politik von Nuvoton (nur Atlantik und das auch nur halbherzig) war und ist keine ernsthafte Basis. W.S.
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.