STM32 ohne CMSIS aber mit den includes etc. in CoIDE

[Markus M. (adrock)]

Hi,

ich arbeite mich gerade in den STM32F10x ein (CoIDE) und es ist (im 
Gegensatz zum 8-Bit AVR Tiny, Mega und auch XMega) quasi eine Art 
Befreiung, wie einfach bzw. logisch viele Sachen sind.

Mit dem CMSIS werde ich eigentlich aber nicht so richtig warm (bzw. habe 
als ASM Veteran den Fehler gemacht, mir den daraus generierten ASM-Code 
anzuschauen :-) und würde gerne darauf verzichten (in der Tat Blinkt 
meine LED auch schon ohne).

Worauf ich aber nicht verzichten will sind aber die ganzen Definitionen 
etc. aus den Includes.

Die Includes (z.B. stm32f10x.h) bekomme ich aber nur in mein Projekt, 
wenn ich zumindest im CoIDE die CMSIS Core/Boot Komponente mit in das 
Projekt nehme.

Ist diese Vorgehensweise OK, also das CMSIS für das Startup zu nehmen 
und danach dann daran vorbei zu Programmieren?

Was hat es mit den Komponenten unter Peripheral.COX auf sich? Sind die 
als Alternativen zu verstehen?

Grüße
Markus

[Steffen R. (steffen_rose)]

Ich nehme an, Du willst das CMSIS nutzen, aber auf die 
Peripherie-Library verzichten. Das ist unproblematisch.

[Random .. (thorstendb)]

Hi,

die "CMSIS" solltest du auf jeden Fall behalten, denn das ist "nur" das 
Format des Headerfiles und einige schlanke Funktionen (i.e. NVIC_xxx() 
sowie Compiler Intrinsics) in der core_cmx.h und core_cmInstr.h

CMSIS Startup sind die beiden Files startup_device.s(oder .c, Toolchain 
- abhängig) und system_device.c/system_device.h, die solltest du auf 
jeden Fall verwenden, sie nehmen einem einiges an Arbeit ab.

Die SystemInit() Funktion aus system_device.c wird aus dem 
startup_device.s/.c (Reset-Handler) aufgerufen, bevor __main() gestartet 
wird.


Alles andere sind die Hersteller Driverlibraries. Ärgerlich, dass das 
immer in einen Topf geworfen wird.

Es gibt auch CMSIS Driver (vgl. MDK-ARM: RTE-System), dies sind 
standardisierte Treiber für Middleware (Ethernet, USB, GLCD, ...)

Minimalprojekt:
- startup_device.s (oder .c, je nach Toolchain)
- system_device.c und system_device.h
- main.c
--> #include "device.h"
("device" entspricht deiner MCU, i.e. "STM32F10x")


VG,
/th.

[Steffen R. (steffen_rose)]

Random ... schrieb:
> Die SystemInit() Funktion aus system_device.c wird aus dem
> startup_device.s/.c aufgerufen, bevor __main() gestartet wird.

Nicht bei CooCox. Liegt aber daran, dass sie auch ihr eigenes Startup 
File nutzen, welches nicht dem Original CMSIS Paket beiliegt.
(unter CooCox als CMSIS Boot geführt)

[Random .. (thorstendb)]

Steffen Rose schrieb:
> Random ... schrieb:
>> Die SystemInit() Funktion aus system_device.c wird aus dem
>> startup_device.s/.c aufgerufen, bevor __main() gestartet wird.
>
> Nicht bei CooCox. Liegt aber daran, dass sie auch ihr eigenes Startup
> File nutzen, welches nicht dem Original CMSIS Paket beiliegt.
> (unter CooCox als CMSIS Boot geführt)

**grummel**
CMSIS war mal dazu gedacht, die vielen verschiedenen Süppchen zu 
vereinheitlichen ...

Hab mal reingeschaut. Schaut alles soweit nach CMSIS Standard aus, mit 
gcc C startup file. Vllt nur Kleinigkeiten verändert / angepasst.

[Steffen R. (steffen_rose)]

Hab mal die angehangen, auf die ich mich bezog (STM32F4).
Kann natürlich sein, dass beim angefragten STM32F1 CooCox nicht so weit 
abgeschweift ist.

Die Datei ist nun auch schon ein halbes Jahr alt. Wäre natürlich schön, 
wenn man sich wieder näher an das "Original" anpasst. Speziell wegen des 
SystemInit() Aufrufes.

[Random .. (thorstendb)]

Steffen Rose schrieb:
> Speziell wegen des SystemInit() Aufrufes.

Kannst du im Reset Handler hinzufügen, falls es per-main sein soll. Oder 
einfach an den Beginn der main() Funktion.

Die SystemInit() kümmert sich idR. um das PLL Clock-Setup, per default 
meisst auf max. Clock.

Beim armcc schaut das so aus, allerdings ist das asm startup:

; Reset handler
Reset_Handler   PROC
                EXPORT  Reset_Handler             [WEAK]
                IMPORT  __main
                IMPORT  SystemInit
                LDR     R0, =SystemInit
                BLX     R0               
                LDR     R0, =__main
                BX      R0
                ENDP

[Steffen R. (steffen_rose)]

Klar kann man es per Hand hinzufügen.

Wir verkaufen Sourcecode und da ist es von Vorteil, wenn es alle 
Compiler gleich machen. Vereinfacht auch die Dokumentation und die 
Tests, wenn man nicht jeden Compiler getrennt betrachten muss.

(OK, ist unsauber ausgedrückt. Ist eher die Distribution, die ihr 
eigenes Süppchen kocht.)

[Random .. (thorstendb)]

Steffen Rose schrieb:
> Wir verkaufen Sourcecode

hast du dir mal CMSIS Pack angeschaut?
http://www.keil.com/pack/doc/CMSIS/Pack/html/index.html

[Steffen R. (steffen_rose)]

Worauf willst Du hinaus?

Wir verkaufen nicht das CMSIS und/oder zugehörige Packs, sondern 
Prozessorunabhängige Protokollsoftware. Die Packs hat der Kunde bereits 
selbst vorhanden. Und hat ähnliche Fragestellungen wie der TO. Und die 
pauschale Aussage zum Sollzustand (wie in deinem ersten Posting, welches 
ich ansonsten gut finde) spiegelt nicht den Istzustand wieder.

Und die Kunden kennen sich häufig selbst nicht mit der Umgebung aus. 
Anstatt sich an Keil, Atollic, IAR, CooCox, CrossWorks und wie sie alle 
heißen zu wenden, fragen sie eher uns. Und wir müssen dann die 
Unterschiede der jeweiligen Umgebungen kennen. Dies wäre einfacher, wenn 
der Grundgedanke von CMSIS eingehalten würde, wie du es oben auch 
beschreibst.

[Markus M. (adrock)]

Hi,

ich merke schon - wie in fast allen CMSIS Threads - das ist kein so 
einfaches Thema ;-)

Aber meine grundsätzliche Frage ist damit eigentlich auch schon 
beantwortet. Die Systeminit-Sachen neu zu erfinen hatte ich auch nicht 
vor. Dann ist das so also gängige Praxis.

Die Peripherie-Lib bietet eine Abstraktion die ich für meine Anwendung 
nicht benötige und ist somit unnötiger Overhead.

Vielen Dank
Markus

[W.S. (Gast)]

Markus M. schrieb:
> Die Includes (z.B. stm32f10x.h) bekomme ich aber nur in mein Projekt,
> wenn ich zumindest im CoIDE die CMSIS Core/Boot Komponente mit in das
> Projekt nehme.

Kenn ich. Ebenso ist es dann nötig, den dazu passenden Startupcode zu 
nehmen, dazu die St-Lib und und und. Für mich ist sowas zum Ersticken - 
und deshalb mache ich sowas ganz anders.

Ich mach mir mein Startupfile und meine Headerfiles selber, und zwar 
genau für DEN µC, den ich gerade benutze. Also nicht ein stm32f10x.h 
sondern z.B. ein STM32F103ZET6.h und dort nur wirklich genau das hinein, 
was der konkrete µC drin hat. Gerade bei ST ist es eine ewige Krätze, 
daß in den Manuals immerzu nach wabbligen Kriterien unterschieden wird: 
Ein Absatz gilt für "low density devices" aber nicht für "high density 
devices" und ein dritter für 'middle..' und zu welchem device Typ der 
konkrete µC gerade zählt (geht auch nach Größe des installierten 
Flashes), muß man jedesmal wieder nachschlagen oder man klebt sich nen 
weiteren Spickzettel auf den Schreibtisch..

Kurzum, die Doku von ST geht mit auf die Nerven und wenn man dazu noch 
das Gedöns aus den von ST gelieferten Headerfiles inclusive der dort 
hart eincodierten CMSIS-Headerfiles dazunimmt, kommt Brechreiz auf.

Also: ich mache mir diese Files selber und ich verkneife mir dabei 
dieses häßliche struct Gewusel mit tonnenweisen padding bytes, sondern 
verpasse eben jedem verdammten HW-Register ein separates #define und 
einen Namen genau wie im HW-Manual. Das ist m.E. immer noch das Beste, 
weil am wenigsten problemanfällig. Und dazu rate ich dir auch. Ist am 
Anfang natürlich etwas Arbeit (nix für Leute, die essen ohne kauen 
wollen), aber wer copy&paste aus PDF beherrscht, dem fällt das leicht.

Es gibt aber bei den F103ern m.E. 2 Ausnahmen, wo in den Systemregistern 
ne Namensgleichheit zu Registern in Peripheriecores auftritt.

W.S.

[Ingo (Gast)]

Und ich wette du nutzt ein Linuxderivat?

[Steffen R. (steffen_rose)]

Ich nehme die ST Header, da ich sehr häufig die Derivate wechseln muss.