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
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
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.
Hallo, Moritz M. schrieb: > Ich meine ich hätte mal ein Bsp. für STM32F4 gesehen > > allerdings finde ich das nicht wieder. es wird der STM32F4x (Cortex M4 Family) STM32F405RG, STM32F407IG STM32F407VG, STM32F407ZG STM32F415RG, STM32F417VE unterstützt. Plus 25 Test-Anwendungen! Gruß G.G.
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.
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.
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.
Hallo Allerseits. Hat jemand CoOs oder FreeRtos auf dem STM32F4Discovery-Board am laufen, bzw. könnte jemand ein Beispiel-Projekt zur Verfügung stellen? Idealerweise als CoDIE Projekt (www.coocox.org), das wäre echt super!
Ich habe übers WE noch etwas mit CoIde und CoOS und meinem STM32F4 Discovery herumgespielt, anbei ein erster Wurf mit laufähigem CoOS auf dem STM32F4. Feedbacks, Korrekturen und Verbesserungsvorschläge sind stets willkommen...
ein schlankes OS; Thomas Winkler schrieb: > Cool, danke für die Arbeit! schließ' mich an! angehängt: --> ohne Warnungen und mit #define HSE_VALUE ((uint32_t)8000000) ps:-für Weihnachten geeignet -- ;)
@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...)
>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.
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;
}
den Ordner UART fügst Du ein(in deinen Ordner des jeweiligen Programms/refresh). Dann unter Configuration add --> include Path -- UART; -das war's !
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.
>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!
>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?
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));
}
}
@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'
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).
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();
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
@Vampire
Ich krieg das ganze nicht mehr durch den Linker, könntest Du eventuell
mal einen Blick auf das ganze werfen? Ich stehe irgendwo auf dem
Schlauch.
@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?
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
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?
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 --
>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!
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
========================================================================
=
Der linker gibt dir doch so schöne Suchbegriffe. Damit kann man z.B. das finden: http://stackoverflow.com/questions/9752000/exidx-start-and-exidx-end-what-do-they-do
>Der linker gibt dir doch so schöne Suchbegriffe. >Damit kann man z.B. das finden: >http://stackoverflow.com/questions/9752000/exidx-s... Schön und gut, aber ich musste mich noch nie mit Linker-scrips rumschlagen! Auch mit der Hilfe des angegeben Links weiss ich nicht, was bei meinem Projekt nicht ok ist, bzw. wo ich suchen soll!
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....
@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?
Das ist ein Problem wenn Du den Quellcode vermischst. Hab kein CoIDE, kann dazu auch nichts weiter sagen.
halte Dich hierran; http://www.coocox.org/forum/topic.php?id=1821 ist STM32F4: Beginers guide & solutions to printf() and floating points
>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)
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);
@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!
freut mich, wenn jetzt alles läuft! mein Discovery sieht etwas anders aus. Haste mal geguckt? Beitrag "Re: ST-Discovery-Net-IO Anfang" Und die COM-Port Ausgabe geht?(Bei mir ist der usb/ser Wandler defekt --)
> Haste mal geguckt? Ja, hab ich mir auch natürlich auch angeguckt, ist ein ganz nettes und umfangreiches Projekt! ;o) Die Lösung aus dem Coocox Forum scheint auch zu funktionieren: http://www.coocox.org/forum/topic.php?id=1821 ...der Code wird aber einige kByte grösser! Welche würdest Du empfehlen?
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;
>Poste doch bitte mal einen screenshot deiner com-Ausgabe! Ich hatte noch vergessen USART_SendData() im PrinChar() einzusetzen. Nun kämpfe ich mit dem Problem, dass \n am Stringende weggefressen wird: Beitrag "GCC ARM: Problem mit "\n" am Stringende"
>na, wie war's in der Höhle der Löwen?
Bin schlauer geworden... ;o)
-
Anbei schon wieder ein Update, da tut die Terminalausgabe wie
erwartet...
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 --
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 --
>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? Anbei mal meine erste "offizielle" Version: STM32F4_Discovery_CoOS_V01
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" --
Ich habe hier noch einen kleinen "Leckerbissen" für Dich. Matz'es mp3-Player auf CoIDE. Beitrag "STM32F4 Discovery MP3 Player - komplett mit Code"
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?
>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.
@Vampire
>Stell's doch erstmal in's dortige Forum ein.
Habe nicht rausgefunden, wie man dort Datein Uploaded. Link?
ich auch nicht -- Hab auch keine Lust, mich bei irgentwelchen Filesharings anzumelden.
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.
INFO: Das aktuelle Projekt habe ich in der Codesammlung abgelegt: => Beitrag "STM32F4Discovery mit CooCox CoOS-RTOS und printf"
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 ---
@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!
Peter S. schrieb: > Ich werde nicht ganz schlau, was Du mit dem letzten Post sagen willst? > Fehlt da eventuell noch ein Link oder Attachment? Nein, nur das ich momentan faulenze -- !
http://www.armkits.com/product/DM-STF4BB.asp genau diese Funktionen hat mein selfmade Board auch! Nur, es sitzt oben auf, da das Discovery auf einem Open407V-D steckt. Davon sind auch die Kamera und das Display.
Falls noch jemand auf der Suche nach einer kostenlosen IDE ist http://www.emblocks.org Unterstützt auch schon das neuste 32F429IDISCOVERY von ST Im Forum gibt es dafür auch schon 2 Beispiele von ST
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.