Hi, Hat jemand Erfahrung damit ein STM32F7xx Projekt unter dem Segger Embedded Studio zu bauen ? Leider gibt es kein passendes CPU Support Package von dafür. Es sollte aber technisch dennoch möglich sein, da der "nackte" GNU Compiler die CPU ja unterstützt. mfg
Wenn es gar nicht geht, nimm Eclipse + GNU ARM Eclipse Plugin, damit geht's (und ist free/opensoße).
Dr. Sommer schrieb: > Wenn es gar nicht geht, nimm Eclipse + GNU ARM Eclipse Plugin, damit > geht's (und ist free/opensoße). Ich weiss dass es damit grundsätzlich geht, aber Eclipse-basierte IDEs sind keine Alternative.
Jojo S. schrieb: > Schon CubeMX von STM probiert? CubeMX ist OK um die korrekte Initialisierung der HW abzuschreiben, besonders der Clock-Tree ist praktisch. Der generierte Code ist von der Struktur her aber unbrauchbar wenn man Fremd-produkte, z.b. anderes RTOS, einbinden muss. (so will z.B. jeder die Hoheit über den Systick-INT) Darunter leiden aber fast alle Code-Generatoren. mfg
Werner A. schrieb: > Hi, > > Hat jemand Erfahrung damit ein STM32F7xx Projekt unter dem Segger > Embedded Studio zu bauen ? > Leider gibt es kein passendes CPU Support Package von dafür. Es sollte > aber technisch dennoch möglich sein, da der "nackte" GNU Compiler die > CPU ja unterstützt. > > mfg Ja, habe ich ;-). Ein STM32F7xx Package gibt es tatsächlich noch nicht aber auch ohne das konnte ich problemlos damit arbeiten. Man kann sich z.B. das STM32F4 Package nehmen, eben das Linker File anpassen und die Device spezifischen CMSIS Dateien vom ST benutzen. In der embOS Cortex-M SES Trial Version ist ein Board Support Package für das ST STM32756G-Evalboard enthalten. Das kann man einfach als Grundlage nehmen: https://www.segger.com/cortex-m--ses.html. Ich werde aber auch gleich die Kollegen bitten ein STM32F7xx Package zu erstellen.
Ich habe gerade mit dem Kollegen gesprochen. Wir haben das STM32F7xx Package schon fertig und müssen das nur noch online stellen. Ich denke das wird heute noch erledigt.
Hallo, Spät, aber doch: Danke für den tip mir der embos trail version. Es gibt ja eh alles irgendwo, man muss es nur finden :-)
Aber Seggers Emb.Studio kennt nur den J-Link - also ungeeignet für ein ST-Disco Board, oder täusche ich mich?
Juppeck schrieb: > Aber Seggers Emb.Studio kennt nur den J-Link - also ungeeignet für > ein ST-Disco Board, oder täusche ich mich? Für die Disco Boards gibt es neuerdings J-Link Firmware. Das sollte also kein Problem sein.
Dirk schrieb: > Juppeck schrieb: >> Aber Seggers Emb.Studio kennt nur den J-Link - also ungeeignet für >> ein ST-Disco Board, oder täusche ich mich? > > Für die Disco Boards gibt es neuerdings J-Link Firmware. Das sollte also > kein Problem sein. Richtig, das ist kein Problem mehr: https://www.segger.com/pr-jlink-st-link.html https://www.segger.com/jlink-st-link.html Wir würden uns auch über Feedback zu Embedded Studio hier freuen.
Guest schrieb: > Dirk schrieb: >> Juppeck schrieb: >>> Aber Seggers Emb.Studio kennt nur den J-Link - also ungeeignet für >>> ein ST-Disco Board, oder täusche ich mich? >> >> Für die Disco Boards gibt es neuerdings J-Link Firmware. Das sollte also >> kein Problem sein. ---Snipp --- > Wir würden uns auch über Feedback zu Embedded Studio hier freuen. Nun, dem will ich nun folge leisten und meine Erfahrung mit Embedded-Studio abgeben. Ich habe das STM32F746 Discovery Board mit einigen freien Tools versucht zu programmieren und kann sagen, dass die Eclipse IDE's einfach grottenübel sind. Das liegt im wesentlichen an der völlig undurchsichtigen und sehr umständlichen Projektkonfiguration und das nicht nachvollziehbare Verhalten der IDE beim Debuggen. Ich dachte dass es wohl kaum eine IDE gibt, die so schlecht ist, wie Eclipse in Verbindung mit einem Microcontroller und Hardware Debugger. Ich habe mich getäuscht und daran ist Embedded Studio von Segger schuld. Fast alle Applikation die mit Hilfe von QT entwickelt werden, zeigen alle die gleichen Schwächen auf einer Windows-Plattform. Sie passen optisch gar nicht in die Umgebung, was den Wiedererkennungswert der Bedienelemente und deren Funktionalität zum Teufel schickt. Leute, was soll denn das? Keine Skalierung der GUI und der Fonts - es bedeutet dass bei der Darstellung man bei FULL-HD Klötzchen- Grafiken Schluss ist und die GUI-Elemente sich der Größe der Auflösung nicht anpassen. Es ist daher unmöglich einen 2K oder gar 4K Monitor sinnvoll einsetzbar - es sei denn man hat einen Display von 48" oder gar 60" und keinen 27" oder sogar nur 24" Monitor. Das Problem ist auf einem Mac auch nicht anders, nennt sich eben nur "Retina". nun kommt noch dazu dass es keine Unterstützung für "freeRTOS" gibt, womit man beim Debuggen nicht sehen kann, welcher Thread gerade geblockt, rennt oder gestoppt ist - vom verbrauchten und verfügbaren Heap mal ganz abgesehen. Getoppt wird dies nur noch durch den exklusiven Support des J-LINK als Debugger. Ich möchte keine IDE verwenden, die mich auf nur einen Debugger beschränkt. Nicht dass ich keinen echten J-Link besitze, sondern weil es die Einsatzfähigkeit darauf beschränkt. Ich benutze eine freie Toolchain um der Freiheits willen und lasse mich dann auf nur eine Debugger ein - welchen Sinn soll dies ergeben? Manchmal ist es einfach besser man lässt ein Projekt in der Schublade verschwinden, anstatt es nur halbherzig anzugehen. Angesichts der wirklich guten Produkte aus dem Hause Segger, überrascht und enttäuscht mich dieses Ergebnis wirklich. Mein Tipp für eine freie IDE wäre emBitz. Sie unterstützt freeRTOS und lässt auch einige andere Debugger zu (J-Link, ST-Link, openOCD, generic) und benutzt ebenfalls ein GCC-C Compiler. Es können fremde Projekt aus Eclipse und Keil importiert werden. Sie ist auch auf den drei Plattformen verfügbar und benutzt wohl auch QT. Für den Import aus CubeMX gibt es ein Konverter-Programm, dass für emBlocks gemacht wurde und durch die nahe Verwandtschaft zwischen emBitz und emBlocks ebenfalls einsetzbar ist. Der F7-Chip-bug lässt sich leider auch hier nicht so einfach umgehen. Eine frei verfügbare Lösung dafür habe ich bisher nicht gefunden. Atollic und Keil haben dies mit einen mir unbekannten Work-around entschärft, aber leider schweigen sie, wie dies gemacht wurde.
Gerhard W. schrieb: > F7-Chip-bug welcher Bug? Ich arbeite mit OpenSTM + FreeRTOS FreeRTOS hat hierfür brauchbare funktionen um freien HEAP / stack und laufende Tasks rauszufinden. Hier muss man nur die richtigen variablen kennen. Dann geht das zur laufzeit ( via HTTP debugseite ) oder im debugger.
Gerhard W. schrieb: > Getoppt wird dies nur noch durch den exklusiven > Support des J-LINK als Debugger. Ich möchte keine IDE verwenden, die > mich auf nur einen Debugger beschränkt. Wie kommst du darauf das SEGGER Embedded Studio Freeware sei? Es ist kostenlos für - Evaluation purposes - Non-profit educational purposes Aber natürlich möchte SEGGER damit Geld verdienen. Also wieso sollten sie dann andere Debug Probes unterstützen? Die Tools von SEGGER sind für den professionellen Einsatz gedacht und da macht es heutzutage für viele Firmen Sinn alles aus einer Hand zu bekommen, also IDE, Compiler, Debug Proble, Middleware, Production Tools, usw... Das ist für Hobbyisten natürlich doof aber und konstruktive Kritik ist nie verkehrt aber du musst das mal aus deren Sicht sehen. Ich finde es eher nett das Hobbyisten das kostenlos benutzen dürfen. > nun kommt noch dazu dass es keine Unterstützung für "freeRTOS" gibt, rofl...Glaubst du es ist der Job von SEGGER solchen Spielzeugkram wie FreeRTOS zu unterstützen? Davon abgesehen das sie ihr eigenes RTOS haben. Als nächstes beschwerst du dich darüber das du bei Porsche keinen Smart kaufen kannst?
Guest schrieb: >> nun kommt noch dazu dass es keine Unterstützung für "freeRTOS" gibt, > rofl...Glaubst du es ist der Job von SEGGER solchen Spielzeugkram wie > FreeRTOS zu unterstützen? Davon abgesehen das sie ihr eigenes RTOS > haben. Bullshit. Ich seh ja noch das Argument ein daß sie keine fremden Debug-Probes unterstützen wollen (-> Kerngeschäft), aber was ihre Kunden für Software damit entwickeln das wird ihnen wohl ziemlich egal sein. > Spielzeugkram ohne Worte....
Also FreeRTOS wird z.B. bei Segger von Ozone unterstützt: https://www.segger.com/ozone.html Siehe "OS-Aware debugging". Es gibt also schon eine FreeRTOS Unterstützung.
Man könnte sich auch etwas mit den Tools beschäftigen. Dann würde einem Auffallen das Segger Embedded Studio ein Rowley Crossworks ist! Dementsprechend kann man auch die Java-Script Datei für FreeRTOS mit ins Projekt packen und hat OS Awareness. Einfach mal nach FreeRTOS support für Crossworks googlen.
In der anvisierten Konfiguration würde ich WinIdeaOpen empfehlen - funktioniert ziemlich P&P, und FreeRTOS Unterstützung ist als Plugin bereits drin.
Bernd K. schrieb: > Bullshit. Ich seh ja noch das Argument ein daß sie keine fremden > Debug-Probes unterstützen wollen (-> Kerngeschäft), aber was ihre Kunden > für Software damit entwickeln das wird ihnen wohl ziemlich egal sein. > Nein, natürlich ist es nicht egal ob Kunden FreeRTOS einsetzen oder Geld bei SEGGER lassen um eine embOS Lizenz zu erwerben. Das Kerngeschäft ist nicht alleine der J-Link sondern mit der Middleware wird auch Geld verdient ;-). Wie gesagt, man muss da ganz start Hobbyisten und Firmen unterscheiden. Letztere werden eher selten FreeRTOS in einem kommerziellen Produkt einsetzen. >> Spielzeugkram > > ohne Worte.... Das sollte gar nicht wertend gemeint sein. FreeRTOS ist ein tolles Projekt für Hobbyisten und wird wie du ja selber geschrieben hast sogar netterweise von Segger teilweise unterstützt. Aber das ist halt nicht für den kommerziellen Einsatz gedacht aber für genau den Bereich verkauft Segger seine Produkte. Tec N. schrieb: > Man könnte sich auch etwas mit den Tools beschäftigen. Dann würde einem > Auffallen das Segger Embedded Studio ein Rowley Crossworks ist! > Dementsprechend kann man auch die Java-Script Datei für FreeRTOS mit ins > Projekt packen und hat OS Awareness. Full ACK! Das sollte mittlerweile kein Geheimnis mehr sein ;-). Finde ich auch gut, weil damit Embedded Studio auf etwas zuverlässigem aufbaut. > Einfach mal nach FreeRTOS support für Crossworks googlen. Oder einfach mal die Jungs von Segger nett fragen, bis jetzt haben die mir immer top weiter geholfen.
Guest schrieb: > Aber das ist halt nicht > für den kommerziellen Einsatz gedacht Sagt wer? Zeig bitte mal die Stelle auf der FreeRTOS Webseite auf der geschrieben steht dass es nicht für kommerziellen Einsatz gedacht ist?
Guest schrieb: >>> Spielzeugkram >> >> ohne Worte.... > Das sollte gar nicht wertend gemeint sein. FreeRTOS ist ein tolles > Projekt für Hobbyisten und wird wie du ja selber geschrieben hast sogar > netterweise von Segger teilweise unterstützt. Aber das ist halt nicht > für den kommerziellen Einsatz gedacht aber für genau den Bereich > verkauft Segger seine Produkte. Selbst wenn FreeRTOS ursprünglich nicht für einen kommerziellen Einsatz gedacht gewesen sein sollte - es gibt mehr als genügend Sysetme im Feld, die beweisen, dass es das problemlos kann. FreeRTOS hat eine sehr gut und professionell durchdachte Architektur und verbindet minimale Footprintdaten mit sehr guter Effizienz und einer absoult ausreichenden Robustheit. Ich habe in mittlerweile sicher 6 Jahren Erfahrung mit FreeRTOS auf mindestens 10 Plattformen keinerlei Probleme feststellen können, die FreeRTOS zuzuscheriben gewesen wären, und ich kenne keiner Features "kommerzieller" OS, die ich bei FreeRTOS vermissen würde. Alle damit entwickelten Systeme bewähren sich 24/7 im Feld. Der einzige Fehler bei FreeRTOS ist, dass es Open Source ist und damit den Markt für Leute austrocknet, die mit vergleichbarer Technologie gutes Geld verdienen wollen und auch sollten.
Bernd K. schrieb: > Sagt wer? Zeig bitte mal die Stelle auf der FreeRTOS Webseite auf der > geschrieben steht dass es nicht für kommerziellen Einsatz gedacht ist? Sage ich. Natürlich steht das nicht auf der FreeRTOS Webseite, wieso sollte das auch!?? Sagen wir einfach mal ich arbeite in dem Bereich seit ein paar mehr Jahren ;-). Wie gesagt es geht nicht darum FreeRTOS schlecht zu machen und es wird wahrscheinlich auch vereinzelt Firmen geben, die FreeRTOS in ihren Produkten einsetzen aber ein Vergleich von FreeRTOS mit einem kommerziellen RTOS ist ein Vergleich von Äpfeln und Birnen. > Ich habe in mittlerweile sicher 6 Jahren Erfahrung mit > FreeRTOS auf mindestens 10 Plattformen keinerlei Probleme feststellen > können, die FreeRTOS zuzuscheriben gewesen wären, und ich kenne keiner > Features "kommerzieller" OS, die ich bei FreeRTOS vermissen würde. Und was wäre gewesen wenn du ein Problem gehabt hättest? An welchen Support hättest du dich gewendet? Was wäre gewesen wenn das Problem ein Show Stopper gewesen wäre? Board Support Packages für alle deine Hardware war schon mit dabei oder hast du die selber erstellt? Hast du dich selber eingearbeitet oder hattest du eine Schulung? D.h. du hast wahrscheinlich Zeit und da du bestimmt nicht kostenlos arbeitest auch Geld investiert. Man ist also sehr schnell in einem Bereich in dem ein kommerzielles RTOS günstiger ist.
Der Macher von FreeRTos lebt ja auch nicht von Luft und Liebe, der verkauft auch gerne seine Bücher, bietet Schulungen an und hat auch kommerzielle OpenRTOS und SafeRTOS Ableger im Programm. Support bietet eine grosse Nutzergemeinschaft, die ist bei der Größe schon sehr leistungsfähig. Und beim Support kochen Segger/Keil auch nur mit Wasser, mein AG hatte einen Show Stopper und der Support stand Achsel zuckend da.
Guest schrieb: >> Ich habe in mittlerweile sicher 6 Jahren Erfahrung mit >> FreeRTOS auf mindestens 10 Plattformen keinerlei Probleme feststellen >> können, die FreeRTOS zuzuscheriben gewesen wären, und ich kenne keiner >> Features "kommerzieller" OS, die ich bei FreeRTOS vermissen würde. > > Und was wäre gewesen wenn du ein Problem gehabt hättest? An welchen > Support hättest du dich gewendet? Was wäre gewesen wenn das Problem ein > Show Stopper gewesen wäre? Board Support Packages für alle deine > Hardware war schon mit dabei oder hast du die selber erstellt? Hast du > dich selber eingearbeitet oder hattest du eine Schulung? D.h. du hast > wahrscheinlich Zeit und da du bestimmt nicht kostenlos arbeitest auch > Geld investiert. Man ist also sehr schnell in einem Bereich in dem ein > kommerzielles RTOS günstiger ist. Zunächst mal habe ich glaube ich klar gut gemacht, dass ich kein Freund von Open Source bin. Allerdings ist FreeRTOS so gut und sauber geschrieben und dokumentiert, dass die Einarbeitungszeit der eines kommerziellen RTOS gegenüber nicht länger ausfällt UND man sich durch Quellcodeanalyse im Prinzip selber supporten kann (von der sehr aktiven Benutzercommunity mal abgesehen). Ich kann also meinen Auftraggebern gegenüber die höheren Kosten für Softwarelizenzen nicht rechtfertigen. Dazu kommt, dass die eigene Lernkurve ab dem zweiten Port rapide abflacht; mittlerweile dauert eine Portierung auf eine neue Plattform nur noch ein paar Mannstunden. BSP haben mit RTOS nichts zu tun, wie Du sicher selber weißt. FreeRTOS kommt mit contributed ports für alle relevanten Prozessorkerne; da Cortex Prozessoren bereits eine komplette OS Unterstützung im Kern haben und die meisten Anfragen nach Cortex kommen, kann man auf einen millionenfach bewährten port zurückgreifen. Ich finde das auch nicht gut, aber Richard Barry hat sich dazu entschlossen, sein RTOS in Open Source Lizenz anzubieten, und damit hat er den Markt komplett ruiniert. Aber das ändert nichts an der Tatsache, dass FreeRTOS verdammt gut ist und für umme zu haben ist, und da Geld die Welt regiert, schaffe zumindestens ich es nicht mehr, iregndeinem Kunden eine kommerzielle Variante schmackhaft zu machen, außer es kommen Dinge wie Haftungsfragen in den Raum, die man bei kommerziellen Produkten an den Lieferanten der Software abwälzen kann.
Guest schrieb: > Sage ich. Ach Du bist Entwickler von FreeRTOS so daß Du weißt was die bei der Entwicklung beabsichtigt haben? > Natürlich steht das nicht auf der FreeRTOS Webseite, wieso > sollte das auch!?? Wo sonst soll denn bitteschön stehen wofür es gedacht ist? Wer sonst außer den Entwicklern wüsste denn am besten was sie selbst mit dessen Entwicklung beabsichtigt haben?
:
Bearbeitet durch User
Johannes S. schrieb: > Der Macher von FreeRTos lebt ja auch nicht von Luft und Liebe, der > verkauft auch gerne seine Bücher, bietet Schulungen an und hat auch > kommerzielle OpenRTOS und SafeRTOS Ableger im Programm. Ne, OpenRTOS/SafeRTOS sind von Wittenstein und gerade SafeRTOS hat mit FreeRTOS nichts mehr zu tun ausser das es die gleiche API benutzt. Das ist komplett neu geschrieben worden. gnugnu schrieb: > Allerdings ist FreeRTOS so gut und sauber > geschrieben und dokumentiert, dass die Einarbeitungszeit der eines > kommerziellen RTOS gegenüber nicht länger ausfällt UND man sich durch > Quellcodeanalyse im Prinzip selber supporten kann Aha, also für dich ist das gleiche, ob ich ein ausführliches Manual habe oder mir im Quellcode die Sachen selber zusammen reimen muss? Natürlich kommst du mit Letzterem auch ans Ziel aber das kostet mehr Zeit und Geld. Das ist so als wenn du sagen würdest du könntest in einer Werkstatt das Auto komplett mit einem einfachen Schraubendreher reparieren anstatt das Hazet Werkzeug zu benutzen. Beides funktioniert aber Letzteres macht mehr Spaß und spart Zeit und Geld. Die meisten Firmen wollen ihre Applikation entwicklen und nicht erst die nötigen Werkzeuge. gnugnu schrieb: > BSP haben mit RTOS nichts zu tun, wie Du sicher selber weißt. FreeRTOS > kommt mit contributed ports für alle relevanten Prozessorkerne; da > Cortex Prozessoren bereits eine komplette OS Unterstützung im Kern haben > und die meisten Anfragen nach Cortex kommen, kann man auf einen > millionenfach bewährten port zurückgreifen. Der Begriff BSP ist leider nicht eindeutig definiert, daher reden wir hier anscheinend von zwei verschiedenen Sachen. Wenn ich mit einer Entwickung anfange habe ich entweder eine Custom Hardware oder ein Evalboard. Ich möchte jetzt vom Hersteller ein RTOS Projekt für meine Wunsch IDE bekommen, das out of the box funktioniert. Das habe ich so bis jetzt nur bei embOS gesehen. Ich glaube du redest von RTOS Portierungen auf verschiedene Cores/Compiler. Was mache ich denn bei FreeRTOS wenn mein Core/Compiler noch nicht unterstützt wird? Ich weißt nicht mit welchem Core/Compiler ich in 10 Jahren arbeiten werde. Das selber portieren? Das kostet schon wieder Zeit und Geld. Bei z.B. Segger bestell ich das einfach und bekomme es nach zwei Wochen komplett fertig und getestet geliefert. Bernd K. schrieb: > Ach Du bist Entwickler von FreeRTOS so daß Du weißt was die bei der > Entwicklung beabsichtigt haben? Dafür muss ich kein Entwickler bei FreeRTOS sein. Wenn es das wäre bräuchte es kein OpenRTOS geben ;-). Wie gesagt wir müssen uns nicht um FreeRTOS streiten, es ging mir nicht darum es per se schlecht zu machen. Natürlich macht es Spaß sich darin einzuarbeiten oder selber BSPs zu erstellen aber das kostet halt Zeit und damit im professionellen Einsatz Geld! Mehr wollte ich nicht sagen.
Jo schrieb: > Johannes S. schrieb: >> Der Macher von FreeRTos lebt ja auch nicht von Luft und Liebe, der >> verkauft auch gerne seine Bücher, bietet Schulungen an und hat auch >> kommerzielle OpenRTOS und SafeRTOS Ableger im Programm. > > Ne, OpenRTOS/SafeRTOS sind von Wittenstein und gerade SafeRTOS hat mit > FreeRTOS nichts mehr zu tun ausser das es die gleiche API benutzt. Das > ist komplett neu geschrieben worden. SAFERTOS: Das hat seinen Grund... OPENRTOS "Developed for release under a modified GPL license, FreeRTOS is completely free to download. Updates and ports are simultaneously released by WITTENSTEIN as OPENRTOS, with full commercial support and licensing." https://www.highintegritysystems.com/openrtos/ Und von dem Unternehmen hinter FreeRTOS: "OpenRTOS and SafeRTOS are provided under license from Real Time Engineers Ltd by WITTENSTEIN high integrity systems (a global engineering and safety company). Please contact WITTENSTEIN directly for queries relating to these products." http://www.freertos.org/RTOS-contact-and-support.html > Der Begriff BSP ist leider nicht eindeutig definiert, daher reden wir > hier anscheinend von zwei verschiedenen Sachen. Wenn ich mit einer > Entwickung anfange habe ich entweder eine Custom Hardware oder ein > Evalboard. Ich möchte jetzt vom Hersteller ein RTOS Projekt für meine > Wunsch IDE bekommen, das out of the box funktioniert. Das habe ich so > bis jetzt nur bei embOS gesehen. Welcher Microcontroller-Hersteller bietet denn z.Z. keine fertigen BSPs für FreeRTOS an? ST -> ist in CubeMX integriert NXP -> BSPs und Beispiele sind mir zumindest für LPC und iMX bekannt Microchip -> PIC32 und andere in MPLAB X integriert Renesas -> u.a. direkt von FreeRTOS, Compiler: Renesas (llvm/clang), IAR, gcc TI -> keine Ahnung, gab/gibt(?) Stellaris mit SafeRTOS im ROM...
tzhgfhgrhzfghz6453454353453534534533453453 schrieb: > Gerhard W. schrieb: >> F7-Chip-bug > > welcher Bug? > Na der Bug, der dafür sorgt, dass der Debugger immer im ISR landet, ob gleich kein Breakpoint gesetzt wurde. Ab der r0p2 core des M7 soll der Bug angeblich gefixt sein - im r0p1 core jedenfalls nicht. Dazu findet man bei Keil und Segger ein paar Infos dazu. http://forum.segger.com/index.php?page=Thread&threadID=2819 Bis auf Keil in Verbindung mit einem ULINK2 oder J-Link habe ich noch kein Debugger gesehen der dass Problem umschifft. Es soll angeblich auch mit einem modifizierten gdbserver unter Atollic/GCC funktionieren; sogar in Verbindung mit einem ST-link. Ob es stimmt weiß ich nicht - ich habe kein Atollic. Ob ein Crossworks das Problem gelöst hat, werde ich am Wochenende probieren und herausfinden. Seggers SGS in Verbindung mit einem zum J-Link umgeflashten ST-LINK/2, auf einem ST32F746Disco bzw. 746-Nucelo-144 war der Fehler leider noch ungelöst. Mit einem externen J-LINK habe ich es bisher noch nicht probiert da ich dazu die Board modifizieren muss und genau dazu hab ich derzeit überhaupt kein Bock. > Ich arbeite mit OpenSTM + FreeRTOS > > FreeRTOS hat hierfür brauchbare funktionen um freien HEAP / stack und > laufende Tasks rauszufinden. Und ja, es gibt auch noch andere Wege sich diese Info anzeigen zu lassen - ist mir aber zu umständlich. Sowas können plug-in's erledigen. freeRTOS: Ich bin sehr überrascht welch Emotionen ein freeRTOS auslösen kann. Das dieser Umstand gleich einen Glaubenskrieg auslösen würde , hatte ich nicht auf dem Radar. Ich möchte halt nicht für ein kommerzielles RTOS zahlen müssen und greife daher auf freeRTOS zurück. Welches RTOS nun besser sein mag ist doch relativ und abhängig von den zu verfolgenden Projektprioritäten und Zielen. Es fährt auch nicht jeder mit einem Maybach. Auf dem Acker wäre Der wohl genauso ungeeignet, wie ein Traktor auf der Autobahn. Wohl alles eine Frage der Verhältnismäßigkeiten und was der Kunde für sein Projekt zahlen will.
Gerhard W. schrieb: > Ich bin sehr überrascht welch Emotionen ein freeRTOS auslösen kann. Das > dieser Umstand gleich einen Glaubenskrieg auslösen würde , hatte ich > nicht auf dem Radar. Finde ich auch überraschend. Wobei ich sagen muss das SEGGER embOS bei mir gar keine Emotionen auslöst. Wenn wir schon bei den Autovergleichen sind war das bei mir mit embOS immer so als wenn ich mich in einen VW Golf oder Polo reinsetzen würde. Man findet sich in jedem embOS Port sofort zurecht und es funktioniert einfach (was ich persönlich sehr schätze).
Bitte 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.