STM32F4 CoOS

Moritz M. Gast #2803718
Lesenswert?
• ▲
▼ 
Hallo,

ist es möglich das CoCox CoOS auf einem STM32F4 Controller zu laufen zu 
bringen. Auf der Website steht es ist für Cortex M0  M3  M4 ausgelegt. 
Allerdings ist kein einziger STM32F4 Controller unter den Supported 
Devices aufgeführt. Ich meine ich hätte mal ein Bsp. für STM32F4 gesehen 
allerdings finde ich das nicht wieder.

Moritz
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Moritz M. Gast #2803901
Lesenswert?
• ▲
▼ 
Hallo nochmal!

Ich hab mich jetzt um entschieden ich möchte doch lieber mit FreeRTOS 
arbeiten, da CoOS von den STM32F4 anscheinend nicht unterstützt wird. 
Hat jemand ein Bsp. Projekt mit dem STM32F4Discovery und FreeRTOS?

Moritz
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Fritz Gast #2803957
Lesenswert?
• ▲
▼ 
Ich habe ein STM32F4.. discovery mit den CoOs laufen.
Habe das noch nicht ausführlich getestet, aber wenn man z. B. floating 
point nur in einer task verwendet, soltte das auch ohne Änderung des 
CoOs Kernels funktionieren, sonst sollte alles gleich zu den Cortex M3 
sein.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
frame Gast #2804155
Lesenswert?
• ▲
▼ 
Vor ca. einem Vierteljahr war auf dem Cocox-Forum noch ein Thread zu 
finden, daß CoOs nicht läuft, wenn man Optimierungen einschaltet (also 
alles größer als -O0).
Das ist nicht unbedingt ein Zeichen von Stabilität und Robustheit.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
(prx) A. K. #2804172
Lesenswert?
• ▲
▼ 
Ich hatte mal in den Quellcode reingesehen, als das Dings noch relativ 
frisch war, und erstaunt festgestellt, dass darin überhaupt kein 
"volatile" auftauchte. Das erschien mir bei einem präemptiven 
Realtime-Kernel als etwas sportlich. Eine entsprechende Anfrage lief auf 
"das ist schon richtig so" raus, ohne nähere Erläuterung. Mein Fazit 
war, dass sie damit etwas auf Risiko arbeiten und hoffen müssen, dass 
ihnen der Compiler nicht irgendwann einen Strich durch die Rechnung 
macht.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
frame Gast #2804601
Lesenswert?
• ▲
▼ 
Und ich hatte auf den Cocox-Forumbeitrag "Hilfe, CoOs läuft mit 
Optimierung nicht mehr" vorgeschlagen, ggf. ein paar 'volatile' 
vorzusehen.
Die Antwort war so ähnlich...

Ich hatte nicht den Eindruck, daß jenes CoOs eine hohe Priorität 
hatte/hat.
Die CoIDE ist zwar besser, für meinen Geschmack aber zu weit 
runtergestutzt.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter Gast #2874559
Lesenswert?
• ▲
▼ 
>ps:-für Weihnachten geeignet --
Hehehe, für so was braucht man natürlich unbedingt ein RTOS... ;o)

Hey, hat jemand ein gutes, elegantes und effizientes 
CoIDE-Beispielprojekt, wie man beim STM32F4Discovery z.B die USART3 mit 
printf() und scanf() verheiratet? Ich habe etwas aus den gefundene 
Beispielen zusammen gewurstelt, bin mir aber sicher das man das besser 
machen könnte.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
vampire Gast #2874758
Lesenswert?
• ▲
▼ 
probier mal dies!
stdio muss "exclude from build"
dann:(ist so in usart.c)
/**
  * @brief  Retargets the C library printf function to the USART.
  * @param  None
  * @retval None
  */
PUTCHAR_PROTOTYPE
{
  /* Place your implementation of fputc here */
  /* e.g. write a character to the USART */
  USART_SendData(Open_USART, (uint8_t) ch);

  /* Loop until the end of transmission */
  while (USART_GetFlagStatus(Open_USART, USART_FLAG_TC) == RESET)
  {}

  return ch;
}
Angehängte Dateien:
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Guest Gast #2874815
Lesenswert?
• ▲
▼ 
Wie wäre es alternativ mit emIDE (emide.org) und einer entsprechenden 
embOS Cortex M Trial Version (segger.com)?

Da ist dann ein Startprojekt für STM32F4 direkt drin und man muss sich 
nicht mit irgendwelchem Bastelkram rumärgern.

Klar die Trial Version läuft nur 12 Stunden nach Reset wenn man mehr als 
drei Tasks erzeugt, aber mit drei Tasks kommt man schon ziemlich weit.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter Gast #2874960
Lesenswert?
• ▲
▼ 
>probier mal dies!
Entspricht im Prinzip den Beispielen, die ich gefunden habe. Gibt es nix 
pfannenfertiges mit schöner RX- und TX-ISR? Wo z.B. jedes RX-Char wieder 
TX-seitig als "Echo" ausgegeben wird.

>stdio muss "exclude from build"
Wie? Was? Warum?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
vampire Gast #2874999
Lesenswert?
• ▲
▼ 
void USARTx_IRQHANDLER(void)
{
  if(USART_GetITStatus(Open_USART, USART_IT_RXNE) != RESET)
  {
      //USART_ClearITPendingBit(USART2,USART_IT_RXNE);
    printf("\n\rUSART Hyperterminal Interrupts Receive a word: 
%c\n\r",USART_ReceiveData(Open_USART));
  }
}
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter S. #2875026
Lesenswert?
• ▲
▼ 
@vampire  Danke, ich versuche das ganze zusammen zu puzzeln...

Gibt es kein vollständiges Beispiel, auch mit RX-ISR?

Was bedeutet NVIC in Deinem UART Beispiel? Habe noch ein Problem mit 
compilieren es fehlt noch die Definition für NVIC_InitTypeDef

[cc] C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\UART\usart.c:83:3: 
error: unknown type name 'NVIC_InitTypeDef'
Antwort Zitieren Bearbeiten Löschen Beitrag melden
abc Gast #2875048
Lesenswert?
• ▲
▼ 
Peter S. schrieb:
>>Klar die Trial Version läuft nur 12 Stunden nach Reset wenn man mehr als
>>drei Tasks erzeugt, aber mit drei Tasks kommt man schon ziemlich weit.
> Das ist schon mal zwei grosse Nachteile!

Häh!?
Wo sind da zwei große Nachteile?
Wenn überhaupt dann einer.

Aber doch mal ganz ehrlich, entweder ich mache was beruflich mit einem 
OS, dann werde ich bestimmt kein FreeRTOS oder so nehmen oder ich mache 
etwas zuhause zum Basteln und da komme ich in der Regel mit drei Tasks 
aus (viele Sachen kann man ja dann auch in embOS Software Timern 
erledigen).
Antwort Zitieren Bearbeiten Löschen Beitrag melden
vampire Gast #2875052
Lesenswert?
• ▲
▼ 
mein CoOS ist nichtmehr orginal, da ich bereits "mp3.play" usw. drin 
habe .
Such mal Ordner cmsis.lib ,  da misc.c und misc.h ;
Da muss NVIC_Init drin sein ?!
nicht vergessen:
Configuration --> add  --> cmsis.lib  ;

und in der main
USART_Configuration();
  USART_NVIC_Config();
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Claudius Z. #2875127
Lesenswert?
• ▲
▼ 
Also, fuers Protokoll:

Vor einigen Monaten hatte ich FreeRTOS 7.1 auf einem STM32F407 in 
Betrieb genommen (Nicht auf dem Discovery board, sondern einem aus China 
mit Ethernet, LCD & Co). Ging ohne Schwierigkeiten und Einschraenkungen.

Floats: Wird in der FreeRTOS Mailinglist diskutiert; sollte gehen, wenn 
du die richtigen Bibliotheken verwendest (z.B. Gnuarm hat die dabei, 
CodeSourcery damals noch nicht)

Gruess
zeuz
Antwort Zitieren Bearbeiten Löschen Beitrag melden
K. D. #2875245
Lesenswert?
• ▲
▼ 
Moritz M. schrieb:
> ist es möglich das CoCox CoOS auf einem STM32F4 Controller zu laufen zu
> bringen. Auf der Website steht es ist für Cortex M0  M3  M4 ausgelegt.
> Allerdings ist kein einziger STM32F4 Controller unter den Supported
> Devices aufgeführt. Ich meine ich hätte mal ein Bsp. für STM32F4 gesehen
> allerdings finde ich das nicht wieder.

Ich darf darauf hinweisen, dass seit dem letzten Update auch die STM32F4 
unterstüzt werden. Eine vollständige Liste findet man hier:
http://www.coocox.org/CooCox_CoIDE.htm

Relevanter Auszug: STM32F405RG, STM32F407IG, STM32F407VG, STM32F407ZG, 
STM32F415RG, STM32F417VE
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Claudius Z. #2875275
Lesenswert?
• ▲
▼ 
Peter S. schrieb:
> @Claudius
>>FreeRTOS 7.1 auf einem STM32F407
> Unter CooIDE 1.5.1? Könntest Du das Projekt posten, mir mailen oder
> einen Link darauf posten?

Nein. Ich habe nie verstanden, weshalb fuer jedes System eine andere 
Entwicklungsumgebung verwendet werden muss. Deshalb:

- Eclipse als UI
- GCC+make+GDB zum Kompilieren und Debuggen
- OpenOCD zum Programmieren

Speziell fuer ARM-Systeme eignet sich noch:
- Gnuarm Plugin fuer Eclipse, verbessert die Discovery-Funktionalitaet


Sonst entwickle ich meist fuer Win/Linux, weshalb ich Eclipse schon 
kannte.
CooIDE habe ich mir kurz angeschaut, war aber zu Projektbeginn noch im 
Entwurfsstadium. Gibt es hier Leute, die von Eclipse auf CooIDE 
umgestiegen sind?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
vampire Gast #2875360
Lesenswert?
• ▲
▼ 
an Claudius Z. (bbczeuz)
was den Eclipse als Editor mit Compileraufruf,Build-handling und 
debugger-aufruf so vielseitig macht, ist seine Plattform-Unabhängigkeit.
Hier wird versucht, alles mit einer " IDE " zu erschlagen.
Was Eclipse so verkompliziert in der Einrichtung ist genau dieses.
Hat man's endlich geschafft, wird man den Teufel tun und wechseln;
Noch dazu ist "ATOLLIC" und "CooCox" ja auch eclipse-basierend.
Wärend sich ersteres selbst ins "Aus" stellt, ist CoIDE noch unbegrenzt.

Claudius Z. schrieb:
> Gibt es hier Leute, die von Eclipse auf CooIDE
> umgestiegen sind?

Ja, ich!
Mein alter Rechner ging in die ewigen Jagdgründe, und den neuen wollte 
ich nicht gleich zupflastern.
Zunächst habe ich aber mit dem guten, alten Programmers-Notepad und 
CS-Lite gearbeitet. Doch das makefile -Aufsetzen ist fehleranfällig.
CoIDE macht's da leichter --
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter S. #2875469
Lesenswert?
• ▲
▼ 
>Moritz M. schrieb:
>> ist es möglich das CoCox CoOS auf einem STM32F4 Controller zu laufen zu
>> bringen. Auf der Website steht es ist für Cortex M0  M3  M4 ausgelegt.
>> Allerdings ist kein einziger STM32F4 Controller unter den Supported
>> Devices aufgeführt. Ich meine ich hätte mal ein Bsp. für STM32F4 gesehen
>> allerdings finde ich das nicht wieder.
>
>Ich darf darauf hinweisen, dass seit dem letzten Update auch die STM32F4
>unterstüzt werden. Eine vollständige Liste findet man hier:
>http://www.coocox.org/CooCox_CoIDE.htm

Diese Unterstützung bezieht sich auf die IDE/Compiler/Library/Debugger- 
Toolchain, nicht auf das Betriebssytem CoOS!
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter S. #2875526
Lesenswert?
• ▲
▼ 
Hat niemand eine Idee, wieso mein Built schief läuft? (Projekt gezippt, 
ca. 6 Posts weiter oben)

=======================================================================
GCC HOME: C:\CooCox\gcc\bin
compile:
    [mkdir] Created dir: 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\Debug\bin
    [mkdir] Created dir: 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\Debug\obj
       [cc] 27 total files to be compiled.
       [cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 
-mfloat-abi=softfp -mthumb -Wall -ffunction-sections -std=c99 -O1 -c 
-D__FPU_USED -DSTM32F4XX -DUSE_STDPERIPH_DRIVER -D__ASSEMBLY__ 
-DSTM32F407VG -IC:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs 
-IC:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\cmsis 
-IC:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel 
-IC:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\portable 
-IC:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\cmsis_boot 
-IC:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\cmsis_lib 
-IC:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\cmsis_lib\include 
-IC:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\UART 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\kernelHeap. 
c  C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\core.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\timer.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\utility.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\cmsis_lib\source\stm32f 
4xx_usart.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\task.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\cmsis_boot\startup\star 
tup_stm32f4xx.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\serviceReq. 
c  C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\main.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\cmsis_lib\source\stm32f 
4xx_rcc.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\mbox.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\mm.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\time.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\event.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\cmsis_lib\source\stm32f 
4xx_gpio.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\cmsis_boot\system_stm32 
f4xx.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\syscalls\syscalls.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\example\IOToggle.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\portable\GCC\port. 
c  C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\queue.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\mutex.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\flag.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\portable\arch.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\cmsis_lib\source\misc.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\sem.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\CoOS\kernel\hook.c 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\UART\usart.c
       [cc] 
C:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs\UART\usart.c:107:0: 
warning: ignoring #pragma import  [-Wunknown-pragmas]
       [cc] Starting link
       [cc] arm-none-eabi-gcc -O1 -nostartfiles 
-Wl,-Map=STM32F4_Discovery_CoOs.map -mcpu=cortex-m4 -mthumb 
-LC:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs -Wl,--gc-sections 
-Wl,-TC:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs/link.ld -g -o 
STM32F4_Discovery_CoOs.elf ..\obj\kernelHeap.o ..\obj\core.o 
..\obj\timer.o ..\obj\utility.o ..\obj\stm32f4xx_usart.o ..\obj\task.o 
..\obj\startup_stm32f4xx.o ..\obj\serviceReq.o ..\obj\main.o 
..\obj\stm32f4xx_rcc.o ..\obj\mbox.o ..\obj\mm.o ..\obj\time.o 
..\obj\event.o ..\obj\stm32f4xx_gpio.o ..\obj\system_stm32f4xx.o 
..\obj\syscalls.o ..\obj\IOToggle.o ..\obj\port.o ..\obj\queue.o 
..\obj\mutex.o ..\obj\flag.o ..\obj\arch.o ..\obj\misc.o ..\obj\sem.o 
..\obj\hook.o ..\obj\usart.o -L..\.. -lm
       [cc] 
c:/coocox/gcc/bin/../lib/gcc/arm-none-eabi/4.6.2/armv7e-m\libgcc.a(unwin 
d-arm.o):  In function `get_eit_entry':
       [cc] unwind-arm.c:(.text+0x144): undefined reference to 
`__exidx_start'
       [cc] unwind-arm.c:(.text+0x148): undefined reference to 
`__exidx_end'
       [cc] collect2: ld returned 1 exit status

BUILD FAILED
Total time: 3 seconds
======================================================================== 
=
Antwort Zitieren Bearbeiten Löschen Beitrag melden
hp-freund Gast #2875585
Lesenswert?
• ▲
▼ 
In deiner Datei link.ld gibt es den Abschnitt:

1
    .ARM.exidx :

2
    {

3
        *(.ARM.exidx* .gnu.linkonce.armexidx.*)

4
    } > rom


ändere den zu:

1
    .ARM.exidx :

2
    {

3
        __exidx_start = .;

4
        *(.ARM.exidx* .gnu.linkonce.armexidx.*)

5
        __exidx_end = .;

6
    } > rom


dann solte es passen....
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter S. #2875603
Lesenswert?
• ▲
▼ 
@hp-freund
Ja so tut es, => vielen Dank!
Aber ist es wirklich nötig, mit CoIDE am Linker-Script herumspielen zu 
müssen oder ist das ein Bug von CoIDE?

Vampire hat mir weiter oben erklärt, ich solle den Ordner [stdio] bzw. 
das darin enthaltene "printf.c" vom built excludieren. Ich habe 
inzwischen festgestellt, dass der built auch ohne Linker-Script 
Anpassung durchläuft, wenn ich "stdio/printf.c" doch nicht von build 
excludiere.

Hab also nun zwei Lösungen, welches ist die bessere?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter S. #2875640
Lesenswert?
• ▲
▼ 
>Das ist ein Problem wenn Du den Quellcode vermischst.
>Hab kein CoIDE, kann dazu auch nichts weiter sagen.

Wie gesagt, setze ich mich erst seit einer knappen Woche mit ARM 
auseinander und versuche mir etwas zusammen zu puzzeln. Kann daher 
leider nicht immer beurteilen, was jetzt wirklich dazugehört bzw. was 
wirklich benötigt wird. Aber ich danke allen, die mir dabei hilfreiche 
Tipps geben! ;o)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter S. #2875801
Lesenswert?
• ▲
▼ 
@vampire ==> Danke für alles!
>ich hab' dein OS nochmal aufgesetzt mit UART.
>Da ist noch ein kleiner Bug drin...

Was für einen Bug meinst Du? Ich habe noch folgende Kleinigkeiten 
angepasst, denke aber, dass der hier gepostete Zwischenstand nun soweit 
gut funktionieren müsste. (Siehe beigefügtes zip-File)

- Im main() habe ich SystemInit() eingefügt, nun läuft das Board
  auch wirklich mit 168MHz.

- Die CPU-Frequenc musste auch im OsConf.h angepasst werden:
  #define CFG_CPU_FREQ (168000000)
  Nun stimmen auch die Task-Delays (10ms Tick)

- Im "uart.h" definiere ich für die USART3,
  TX auf GPIO_D8 statt GPIO_C10 (da Konflikt mit SCLK zu CS43L22)
  RX auf GPIO_D9 atatt GPIO_C11
  Ist aber nicht relevant, da ohnehin die USART2 verwendet wird!

- Im "uart.c" habe ich /* Use no semihosting */ auskommentiert (#if 0)
  da "#pragma import(__use_no_semihosting)" Warnings generiert, bzw.
  der Compiler dieses #pragma nicht kennt. Weiss aber nicht, ob das
  nun ok ist???

- Ebenfalls im "uart.c" habe ich den "USARTx_IRQHANDLER(void)"
  eingefügt, um die empfangenen Zeichen als Echo wieder Richtung
  TX zu senden.

- In der Projekt-Configuration habe ich auf -OS umgestellt mit -std=c99

=> Weitere Feedbacks, Korrekturen und Verbesserungsvorschläge sind
   stets willkommen!
Angehängte Dateien:
Antwort Zitieren Bearbeiten Löschen Beitrag melden
vampire Gast #2876720
Lesenswert?
• ▲
▼ 
und Du weist nun sicherlich, das der Ärger nur durch die fehlerhafte
<COMMON> --> Retarget printf entstanden ist?
Vergleich mal printf.c --> void PrintChar() , die angeboten wird mit 
deiner neuen, selbst erstellten --
Antwort Zitieren Bearbeiten Löschen Beitrag melden
vampire Gast #2877545
Lesenswert?
• ▲
▼ 
Peter S. schrieb:
>>ich glaube, es ist an der Zeit, auch die CooCox-Forengemeinde mit einem
>>funktionierenden CoOS auf F4D(mit printf) zu beglücken.
> Kann ich/würde ich gerne machen, aber wie und wo?

Stell's doch erstmal in's dortige Forum ein.
Damit solltest Du deinen Beitrag geleistet haben :)

Hier im Forum wäre die Codesammlung(Wiki) ein Platz zum "Überwintern" --
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter S. #2877729
Lesenswert?
• ▲
▼ 
>Hast du die Sourcen angepaßt, dass auch die FPU in allen tasks verwendet
>werden kann?
Nein, ich habe den aktuellen CoOS SourceCode unverändert übernommen. Die 
HW-FPU wird womöglich nicht laufen, wenn FPU-Berechnungen in 
verschiedenen Tasks statt finden. Es sei, der normale Interrupt-Handler 
erledigt dies bereits in der Tick-Timer ISR?

Ich kenne mich da noch zuwenig aus, wäre super, falls sich da einer 
reinknien mag.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter S. #2878343
Lesenswert?
• ▲
▼ 
Nein, ich glaube CoIDE hinterlässt kein Makefile, zumindest habe ich 
keines gefunden. Es gibt aber ein "build.xml" und "link.ld". Zudem habe 
ich den Output der Build-Konsole in ein txt-File gepackt, ich denke 
darin findest Du alle Informationen um Dir selber ein Makefile zu 
stricken!

Oder verwende doch einfach CoIDE, falls ein MS-Windows System greifbar 
ist.
Angehängte Dateien:
Antwort Zitieren Bearbeiten Löschen Beitrag melden
vampire Gast #2879062
Lesenswert?
• ▲
▼ 
ich hatte doch weiter oben schon erwähnt:
ST-Discovery NET-IO Anfang
da ist auch ein µSD-Slot drauf. Die 4 GB einer Karte habe ich wahllos 
mit
*.mp3 Files meiner Sammlung aus einem früheren Leben als aktiver Musiker 
befüllt. Dazu noch einige Bilder -

-nachdem ich mp3-chibi auf CoIDE angepasst habe, sitze ich nun hier und 
staune, was sich da alles angesammelt hat.
Als Slideshow mit Musikuntermalung ---
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter S. #2879113
Lesenswert?
• ▲
▼ 
@vampire:
Ich werde nicht ganz schlau, was Du mit dem letzten Post sagen willst?
Fehlt da eventuell noch ein Link oder Attachment?

Ich habe mir heute ein STF4BB Erweiterungs-Board zu STM32F4-Discovery 
bestellt. => http://www.armkits.com/product/DM-STF4BB.asp

Ich denke das ist die ideale Ergänzung zu Deinem "ST-Discovery NET-IO" 
(RS232, Ethernet, SD-Slot) und werde dann sicher Dein Projekt dort drauf 
spitzen! Leider kommt das Erweiterungs-Board wohl erst auf ende Monat!
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren