STM32F4 CoOS

Gast #2803718 
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 Langsamer Modus Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Melden Danke
Gast 
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 Melden Danke
Gast 
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 Melden Danke
Gast 
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 Melden Danke 
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 Melden Danke
Gast 
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 Melden Danke 
@vampire => Danke für das CleanUp! ;o)

Ich bin mir nicht sicher, ob es die FPU-Register beim Taskwechsel 
gesichert werden. Falls sich jemand damit auskennt, darf er gerne einen 
Blick darauf werfen... (ich bin echt ein NewBee mit ARM, muss mich da 
erst noch einarbeiten...)
Antwort Zitieren Bearbeiten Löschen Melden Danke
Gast 
>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 Melden Danke
Gast 
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 Melden Danke
Gast 
den Ordner UART fügst Du ein(in deinen Ordner des jeweiligen 
Programms/refresh). Dann unter Configuration add --> include Path --
UART;
-das war's !
Antwort Zitieren Bearbeiten Löschen Melden Danke
Gast 
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 Melden Danke
Gast 
>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 Melden Danke
Gast 
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 Melden Danke 
@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 Melden Danke
Gast 
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 Melden Danke
Gast 
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 Melden Danke 
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 Melden Danke 
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 Melden Danke 
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 Melden Danke
Gast 
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 Melden Danke 
>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 Melden Danke 
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 Melden Danke
Gast 
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 Melden Danke 
@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 Melden Danke 
>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 Melden Danke
Gast 
ich hab' dein OS nochmal aufgesetzt mit UART.
Da ist noch ein kleiner Bug drin, aber aus Zeitmangel(arbeite mit 
Hochdruck an einem Projekt) suche ich den nicht --
läuft aber durch
(achte mal auf die Linker-Einstellungen);
Angehängte Dateien:
Antwort Zitieren Bearbeiten Löschen Melden Danke 
@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 Melden Danke
Gast 
wenn Du
http://www.coocox.org/forum/topic.php?id=1821
konsequent befolgst, bekommst Du einen error:
multiple compil. usw.;
dann musst Du printf.c aus der stdio excluden;
Kommt Dir das bekannt vor?

Poste doch bitte mal einen screenshot deiner com-Ausgabe!
- ( z.B. bei Hyperterminal) Taste Druck/S-Abf --> einfügen z.B. in 
"paint" aus "Zubehör" und "speichern als" z.B. *.png;
Antwort Zitieren Bearbeiten Löschen Melden Danke
Gast 
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 Melden Danke
Gast 
ich glaube, es ist an der Zeit, auch die CooCox-Forengemeinde mit einem 
funktionierenden CoOS auf F4D(mit printf) zu beglücken.
Aber, das ist deine Sache --
Antwort Zitieren Bearbeiten Löschen Melden Danke
Gast 
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 Melden Danke
Gast 
Peter S. schrieb:
> Anbei mal meine erste "offizielle" Version: STM32F4_Discovery_CoOS_V01

Hast du die Sourcen angepaßt, dass auch die FPU in allen tasks verwendet 
werden kann?
Also die entsprechenden pushs, pops und das was dafür laut FPU-Manual 
notwendig ist eingebettet?
Antwort Zitieren Bearbeiten Löschen Melden Danke 
>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 Melden Danke 
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 Melden Danke
Gast 
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 Melden Danke 
@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 Melden Danke
Thread beobachten

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 14 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.