Forum: Compiler & IDEs SM32F7 Entwicklung unter Segger Embedded Studio


von Werner A. (gnuopfer)


Lesenswert?

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

von Jojo S. (Gast)


Lesenswert?

Schon CubeMX von STM probiert?

von Dr. Sommer (Gast)


Lesenswert?

Wenn es gar nicht geht, nimm Eclipse + GNU ARM Eclipse Plugin, damit 
geht's (und ist free/opensoße).

von Werner A. (gnuopfer)


Lesenswert?

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.

von Werner A. (gnuopfer)


Lesenswert?

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

von Guest (Gast)


Lesenswert?

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.

von Guest (Gast)


Lesenswert?

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.

von Werner A. (gnuopfer)


Lesenswert?

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 :-)

von Juppeck (Gast)


Lesenswert?

Aber Seggers Emb.Studio kennt nur den J-Link - also ungeeignet für ein 
ST-Disco Board, oder täusche ich mich?

von Dirk (Gast)


Lesenswert?

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.

von Guest (Gast)


Lesenswert?

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.

von Gerhard W. (dd4da) Flattr this


Lesenswert?

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.

von tzhgfhgrhzfghz6453454353453534534533453453 (Gast)


Lesenswert?

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.

von Guest (Gast)


Lesenswert?

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?

von Bernd K. (prof7bit)


Lesenswert?

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....

von Guest (Gast)


Lesenswert?

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.

von Alex E. (tecnologic) Benutzerseite


Lesenswert?

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.

von Gnugnu (Gast)


Lesenswert?

In der anvisierten Konfiguration würde ich WinIdeaOpen empfehlen - 
funktioniert ziemlich P&P, und FreeRTOS Unterstützung ist als Plugin 
bereits drin.

von Guest (Gast)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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?

von gnugnu (Gast)


Lesenswert?

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.

von Guest (Gast)


Lesenswert?

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.

von Johannes S. (Gast)


Lesenswert?

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.

von gnugnu (Gast)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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
von Jo (Gast)


Lesenswert?

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.

von Arc N. (arc)


Lesenswert?

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...

von Gerhard W. (dd4da) Flattr this


Lesenswert?

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.

von Hugo (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.