STM32 Umstieg von Coocox zu Eclipse

OP #3717245
Lesenswert?

Hallo zusammen,

ich habe in den letzten Wochen die ersten Schritt mit dem 
STM32F3-Discovery und Coocox gemacht. Da ich aber bisher immer mit 
Ecplipse gearbeitet habe möchte ich den vorhandenen Code übernehmen.
Dazu habe ich Eclipse Luna und das ARM Plug-In installiert.
Den GCC habe ich von Coocox übernommen (4.8.3 20131129).
Über das ARM-Plug-In habe ich mir dann ein Projekt für den F3 erstellt 
und die vorhandenen Sourcen hinzugefügt.
Das compilieren funktiert soweit auch (außer dass das binary fast 
doppelt so groß ist).
Allerdings läuft der F3 nicht auf den vollen 72MHz wie zuvor sondern mit 
viel weniger.
Nun habe ich mich auf die Suche gemacht und herausgefunden dass das ARM 
Plug-In zwar auch die STM32perphlib zurückgreift, diese allerdings nicht 
100%ig der von Coocox entspricht.
Das startup file gibts in eclipse nur noch in C, in Coocox war dieses 
noch in assembler geschrieben, sollte aber soweit kein Problem 
darstellen.
Das einzige was ich gefunden habe war in der "system_stm32f30x.c" in 
SetSysClock():
Anfangs wird das RCC Clock Control Register gesetzt, in der ARM-Plugin 
version fest auf HSE, in der Coocox version läuft das per define.
Auf dem Discovery wird der Takt des STLink µC benutzt, also habe ich die 
Zeile RCC->CR |= ((uint32_t)RCC_CR_HSEON); in RCC->CR |= 
(uint32_t)(RCC_CR_HSEON | RCC_CR_HSEBYP); geändert.
Leider scheint das wohl nicht alles zu sein.

Hat hier noch jemand den Umzug von Coocox zu Eclipse vollzogen und kann 
mal erzählen auf was machen noch achten muss?
Oder hatte vielleicht jemand genau das selbe Problem?

Besten Dank und einen schönen Abend!
Gast #3717261
Lesenswert?

>Hat hier noch jemand den Umzug von Coocox zu Eclipse vollzogen und kann

Es ist völlig Wurst ob du Coocox oder Eclipse nimmst.
ST hat die Standard Peripheral Libs quasi als deprecated
erklärt. Updates gibt es in Zukunft nur noch für dieses
STMCube Geraffel. Das ist so ein Codegenerator. Der erzeugt
aber weder für Coocox noch für Eclipse Projektdateien. Es werden nur
kommerzielle IDEs unterstützt. Irgendwie sind die bei ST im Moment
komplett auf dem falschen Weg. Schade eigentlich.
Gast #3717288
Lesenswert?

@holger:

habe es zwar noch nicht selber probiert aber hatte mich vor ein paar 
Wochen auch mit dem Thema auseinander gesetzt und folgendes gefunden:

"Coocox IDE won't be directly supported by STM32CubeMX but we plan to 
add support for generic Eclipse+GCC IDE (and Coocox is one of them).

In the mean time, you can generate for Atollic, take all the generated 
files (assembly and C code) and import them into your Coocox project.

You will still have to configure in Coocox the target MCU and maybe some 
Define and Include paths."
(Quelle: 
https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/STM32Cube%20and%20CoIDE&currentviews=566)
Gast #3717293
Lesenswert?

>"Coocox IDE won't be directly supported by STM32CubeMX but we plan to
>add support for generic Eclipse+GCC IDE (and Coocox is one of them).

Wann? In zwei Jahren? Haben die z.B. STM32F429 überhaupt schon
eingebunden? Wenn ja hat das schon einige Monate gedauert, wenn
nein...

>In the mean time, you can generate for Atollic, take all the generated
>files (assembly and C code) and import them into your Coocox project.

Nimm mal so ein Projekt was für Atollic erstellt wurde und versuch das
mit Eclipse pur zu übersetzen. Nichts für Anfänger kann man
da nur sagen.
Gast #3717381
Lesenswert?

>Der erzeugt aber weder für Coocox noch für Eclipse Projektdateien.
>Es werden nur kommerzielle IDEs unterstützt.
>Irgendwie sind die bei ST im Moment
>komplett auf dem falschen Weg. Schade eigentlich.
Die Projektdateien braucht man doch gar nicht. Man kann STM32Cube ganz 
normal als Bibliothek benutzen.

Und wenn man mit den Beispielen arbeitet: Die für Atollic erzeugten 
Projekte kann man so fast für Eclipse benutzen. Man muss nur noch die 
Dateien dem Projekt hinzufügen.
Gast #3717411
Lesenswert?

holger schrieb:
> ST hat die Standard Peripheral Libs quasi als deprecated
> erklärt

Das ist doch mal eine gute Meldung. Ich habe mich schon immer gefragt 
warum so was überhaupt verwendet wird. Wenn's einfache Sachen sind, ist 
die Lib eigentlich nicht nötig und wenn es komplizierter wird ist sie 
ohne genaue Kenntnisse der Register wertlos da schlecht dokumentiert. Da 
kann man auch gleich mit den Registern arbeiten.

Selbst bei einfachen Pinwackeln ist die ganze Lib wertlos, wenn es nur 
ein bisschen auf Geschwindigkeit ankommt.

Gut dokumentierte Code-Samples für die etwas anspruchsvolleren Aufgabe 
würden wesentlich mehr helfen als schlechte Libs.

Häufig wird ein Projekt aus verschiedenen Bestandteilen zusammengesetzt 
die nicht alle aus der eigenen Feder kommen. Wenn jedes dieser 
Bestandteile andere Versionen dieser Lib benutzt ist das Chaos perfekt.

Jeder der bisher die Lib verweigert hat, kann sich nun beruhigt zurück 
lehnen und das neue Pferd wohlwollend ignorieren.
OP #3717422
Lesenswert?

Ich denke nicht das es an der Lib liegt, wenn ich das blinkyLED Beispiel 
baue und aufspiele passt das Timing. Allerdings kann ich an dem 
blinkyled einfach keinen Unterschied zu meinem vorhandenen Code 
erkennen!
Erstmal möchte ich das vorhandene im Eclipse am Laufen haben, danach 
werde ich mich mit dem STMCube beschäftigen.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren