[ECOS] Specific needs on stm32

[ECOS] Specific needs on stm32

[Valentin BOUSSON]

Hi all, I'm fresh and new on this mailing list,
and in the world of real embedded systems, actually.

I bought a STM32F4 - DISCOVERY board to play with, and I succeeded to 
compile and run a lot of simple, led / LCD / audio project I found 
online. I was using the Sourcery arm compile chain for that.

But my next ambition is little harder, I would like to adapt one of my 
existing program, based on a plugin-mechanism, on my stm32. So, I was 
looking for an RTOS being able to manage a simple system, in the Flash 
memory, or in an external SD card.




I tried to set up the compilation environnement described in the big pdf 
describing eCos, and on the Download & Installation section on the 
website, I tried all the day, without any result.
Do you have some good links / tuto / advices to share ?


My questions are :
Is it possible to use the compilation chain generated by 
summon-arm-toolchain, to compile eCos itself ?

What about the programs I would like to run on top of eCos ?

If I store my programs in the Flash, how can I reprogram the flash to 
change only the program, and not the kernel ?

IYO, is eCOS the best OS to choose for my project ? // Are its dynamic 
loading mechanism easy to use ?



Thank you by advance :)
Valentin B

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Specific needs on stm32

["Ilija Kocho [Илија Кочо]"]

Hi Valentin



On 20.01.2014 17:12, Valentin BOUSSON wrote:
> Hi all, I'm fresh and new on this mailing list,
> and in the world of real embedded systems, actually.
>
> I bought a STM32F4 - DISCOVERY board to play with, and I succeeded to
> compile and run a lot of simple, led / LCD / audio project I found
> online. I was using the Sourcery arm compile chain for that.
>
> But my next ambition is little harder, I would like to adapt one of my
> existing program, based on a plugin-mechanism, on my stm32. So, I was
> looking for an RTOS being able to manage a simple system, in the Flash
> memory, or in an external SD card.
>
>
>
>
> I tried to set up the compilation environnement described in the big
> pdf describing eCos, and on the Download & Installation section on the
> website, I tried all the day, without any result.
> Do you have some good links / tuto / advices to share ?
>

You need to get eCos from CVS (that I prefer to call "the rolling release").
Here you'll find info how to access CVS
http://ecos.sourceware.org/anoncvs.html

Also you can try eCos arm-eabi GNU tools - test release 4.6.3
http://ecos.sourceware.org/ml/ecos-discuss/2012-06/msg00047.html
that comes with support for hardware floating point.

>
> My questions are :
> Is it possible to use the compilation chain generated by
> summon-arm-toolchain, to compile eCos itself ?

I haven't tried it.

>
> What about the programs I would like to run on top of eCos ?
>

What would you like to run?
With this little information, I can just say that porting POSIX
applications is relatively straight forward.

> If I store my programs in the Flash, how can I reprogram the flash to
> change only the program, and not the kernel ?
>

Kernel is in general being linked with application. However it is
possible to create dynamically loadable libraries.
Also, you can install RedBoot and then use it for loading applications.

> IYO, is eCOS the best OS to choose for my project ? // Are its dynamic
> loading mechanism easy to use ?
>

No one can tell you what's best for your project. But IMHO, eCos is
worth for consideration.
I encourage you to try it.

Have fun

Ilija


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Specific needs on stm32

["Ilija Kocho [Илија Кочо]"]

Valentin

What eCos version are you using? 3.0 doesn't have STMF4 BSP and STMF1
won't work on STMF4.
You need eCos from CVS - look for the link in my previous mail.

After you get eCos from CVS you need to set configtool to use it
(Build->Repository then navigate to CVS repository).
Now you should be able to see STMF4 target(s) in configtool templates.

Ilija


On 24.01.2014 11:32, Valentin BOUSSON wrote:
> Hi !
>
> Thank you for your enducement.
> I read a lot more about the user guide, and it seems really adapted.
>
> As a first step, I am trying to make a simple hello world functionning
> on my stm32f4 discovery , and that's not so easy.
>
> I downloaded the ecos-3.0 via the  "ecos-install.tcl" script, and it
> did well. I add into my PATH the gnu-tools binaries, to use all the
> arm-eabi prefixed tools.
> Then I ran the ecosconfig from a separate folder "work", in which I
> put hello.c and a Makefile created with build_Makefile (and modifying
> the SRCS, OBJS, etc..)
>
> My folder structure is :
> ecos
> ├── ecos-3.0
> │   └── ...
> ├── ecosenv.csh
> ├── ecosenv.sh
> ├── gnutools
> │   └── arm-eabi
> │        └── ...
> └── work
>      ├── app
>      │   ├── hello.c
>      │   ├── Makefile
>      │   └── Make.params
>      ├── my_stm32f4_build
>      │   └── ...
>      ├── my_stm32f4.ecc
>      └── my_stm32f4_install
>           └── ...
>    
> The compilation process is going well, and I have now a hello.o, which
> I can compile into an executable with the following command I have
> adapted.
> /TARGET-/gcc -g -I/BASE_DIR//ecos-work/install/include hello.c -L/BASE_DIR//ecos-work/install/lib -Ttarget.ld -nostdlib
>
>
>
> I think my problem now is very platform-specific because I'm unable to
> make this executable to work neither onto the stm32, neither on a
> simulator (arm-eabi-run ??).
> I used to write my tests with the qstlink2 utility to flash my memory
> in SWD, but the stm23f4 don't react at all, nor reboot. Some leds are
> on but, no idea.
>
> I try to use the official st-util, in order to use a remote gdb, but I
> don't know how to do.
>
>
> In your opinion, I am on the good way with my experiments ?
>
>
> And then, I saw nowhere in the eCos hal/stm32 folders the officials
> BSP, as the management of GPIO, or SDIO, etc...
>
>
> Thanks a lot.
>
> Valentin BOUSSON
>
>
> On 20/01/2014 21:04, "Ilija Kocho [Илија Кочо]" wrote:
>> Hi Valentin
>>
>>
>>
>> On 20.01.2014 17:12, Valentin BOUSSON wrote:
>>> Hi all, I'm fresh and new on this mailing list,
>>> and in the world of real embedded systems, actually.
>>>
>>> I bought a STM32F4 - DISCOVERY board to play with, and I succeeded to
>>> compile and run a lot of simple, led / LCD / audio project I found
>>> online. I was using the Sourcery arm compile chain for that.
>>>
>>> But my next ambition is little harder, I would like to adapt one of my
>>> existing program, based on a plugin-mechanism, on my stm32. So, I was
>>> looking for an RTOS being able to manage a simple system, in the Flash
>>> memory, or in an external SD card.
>>>
>>>
>>>
>>>
>>> I tried to set up the compilation environnement described in the big
>>> pdf describing eCos, and on the Download & Installation section on the
>>> website, I tried all the day, without any result.
>>> Do you have some good links / tuto / advices to share ?
>>>
>> You need to get eCos from CVS (that I prefer to call "the rolling release").
>> Here you'll find info how to access CVS
>> http://ecos.sourceware.org/anoncvs.html
>>
>> Also you can try eCos arm-eabi GNU tools - test release 4.6.3
>> http://ecos.sourceware.org/ml/ecos-discuss/2012-06/msg00047.html
>> that comes with support for hardware floating point.
>>
>>> My questions are :
>>> Is it possible to use the compilation chain generated by
>>> summon-arm-toolchain, to compile eCos itself ?
>> I haven't tried it.
>>
>>> What about the programs I would like to run on top of eCos ?
>>>
>> What would you like to run?
>> With this little information, I can just say that porting POSIX
>> applications is relatively straight forward.
>>
>>> If I store my programs in the Flash, how can I reprogram the flash to
>>> change only the program, and not the kernel ?
>>>
>> Kernel is in general being linked with application. However it is
>> possible to create dynamically loadable libraries.
>> Also, you can install RedBoot and then use it for loading applications.
>>
>>> IYO, is eCOS the best OS to choose for my project ? // Are its dynamic
>>> loading mechanism easy to use ?
>>>
>> No one can tell you what's best for your project. But IMHO, eCos is
>> worth for consideration.
>> I encourage you to try it.
>>
>> Have fun
>>
>> Ilija
>>
>


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Specific needs on stm32

["Ilija Kocho [Илија Кочо]"]

On 26.02.2014 15:10, BELPHEGOR wrote:
> Hello Ilija,
> (Excuse me to use your mail address directly),
> but I tried to write onto the ecos-discuss@ecos.sourceware.org mail
> address,
> and I didn't see a single mail pass.
> Do you think there is a problem on the whole mailing list ?
>

The cause is text formatting. Your email was formatted in HTML. eCos
mailing lists accept plain text only.
HTML format is usually triggered if there is some text formatting in
your text. It may also be default or set to default on your email client.
You have to set the format to plain text when sending to eCos mailing lists.

>
> By the way, thank you very much for your former help, I gave eCos a
> better try, and I'm working hard for a few days to port my application
> on stm32f4discovery.
>
> Below are the two mails I tried to send, they are obsolete by the way,
> because I succeed to compile the default template for stm32f4discovery
> (with the ROM build option (instead of JTAG), and to build little
> applications that use STM32F4 HAL to make some led blinking, and some
> thread mechanisms.
> That's coool ! :)
>
> I will focus now on having a functional file system in flash, a
> dynamic loading that works, and a printf that scroll over the LCD screen.
> If by chance you know some projects/people that could lead me on this
> way, I would be happier than I am.
>

This mailing list is the right place.
I would recommend you Masa's book. It's available in both paper and PDF.
Ref:
http://www.informit.com/store/embedded-software-development-with-ecos-9780130354730

Ilija


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] STM32F4 and Dynamic loading.

[Valentin BOUSSON]

Hello again,
Thank you for your help.

I encounter anotger problem that could signify the end between eCos and 
I for my project... :(
After having some simple examples working, i tried to make one using 
Dynamic ELF loading (dlopen).

So I tried first to compile eCos from the template stm32f4discovery +  
posix (that compiles), and then adding the package "Dynamic Loder". A 
conflict is resolved, setting the header to <cyg/loader/dlfcn>,
but then with no more conflict the command Build / Library crash and 
doesn't want to compile "services/loader/current/src/loader.cxx"


Do you see what does it come from ? I see in the traces some undefined 
macros, but It doesn't seems to be the main problem.

By the way, I have seen through experimentations in order to resolve 
this issue, a difference between CYGPKG_HAL_CORTEXM and CYGPKG_HAL_ARM.
So I would know : doesn't a cortexm platform be considered as an ARM one 
? Why not ? Is it a cause of my problem ?


Cheers, and thank you again.

Valentin BOUSSON




end of traces :
==========

In file included from 
~/ecos/packages/services/loader/current/src/loader.cxx:65:
~/ecos_tests/ecos_install/include/cyg/loader/loader.hxx:351: error: 
invalid use of incomplete type ‘struct Cyg_LoadObject_Proc’
~/ecos_tests/ecos_install/include/cyg/loader/loader.hxx:77: error: 
forward declaration of ‘struct Cyg_LoadObject_Proc’
make[1]: Leaving directory `~/ecos_tests/ecos_build/services/loader/current'
~/ecos_tests/ecos_install/include/cyg/loader/loader.hxx: In constructor 
‘Cyg_LoadObject::Cyg_LoadObject()’:
make: Leaving directory `~/ecos_tests/ecos_build'
~/ecos_tests/ecos_install/include/cyg/loader/loader.hxx:357: error: type 
‘Cyg_LoadObject_Proc’ is not a direct base of ‘Cyg_LoadObject’

~/ecos_tests/ecos_install/include/cyg/loader/loader.hxx: In constructor 
‘Cyg_LoadObject::Cyg_LoadObject(Cyg_LoaderStream&, cyg_uint32, 
Cyg_LoaderMemAlloc*, Cyg_LoaderMemBlock*)’:
~/ecos_tests/ecos_install/include/cyg/loader/loader.hxx:365: error: type 
‘Cyg_LoadObject_Proc’ is not a direct base of ‘Cyg_LoadObject’
In file included from 
~/ecos/packages/services/loader/current/src/dload.cxx:66:
~/ecos_tests/ecos_install/include/cyg/loader/loader.hxx:351: error: 
invalid use of incomplete type ‘struct Cyg_LoadObject_Proc’
~/ecos_tests/ecos_install/include/cyg/loader/loader.hxx:77: error: 
forward declaration of ‘struct Cyg_LoadObject_Proc’
~/ecos_tests/ecos_install/include/cyg/loader/loader.hxx: In constructor 
‘Cyg_LoadObject::Cyg_LoadObject()’:
~/ecos_tests/ecos_install/include/cyg/loader/loader.hxx:357: error: type 
‘Cyg_LoadObject_Proc’ is not a direct base of ‘Cyg_LoadObject’
~/ecos_tests/ecos_install/include/cyg/loader/loader.hxx: In constructor 
‘Cyg_LoadObject::Cyg_LoadObject(Cyg_LoaderStream&, cyg_uint32, 
Cyg_LoaderMemAlloc*, Cyg_LoaderMemBlock*)’:
~/ecos_tests/ecos_install/include/cyg/loader/loader.hxx:365: error: type 
‘Cyg_LoadObject_Proc’ is not a direct base of ‘Cyg_LoadObject’
~/ecos/packages/services/loader/current/src/loader.cxx: In constructor 
‘Cyg_Loader::Cyg_Loader(Cyg_LoaderMemAlloc*)’:
~/ecos/packages/services/loader/current/src/loader.cxx:126: error: no 
matching function for call to 
‘Cyg_CList_T<Cyg_LoadObject>::add_head(Cyg_LoadObject*&)’
~/ecos_tests/ecos_install/include/cyg/infra/clist.hxx:173: note: 
candidates are: void Cyg_CList::add_head(Cyg_DNode*)
~/ecos/packages/services/loader/current/src/loader.cxx:128: error: 
‘class Cyg_LoadObject’ has no member named ‘get_error’
~/ecos/packages/services/loader/current/src/loader.cxx: In member 
function ‘cyg_code Cyg_Loader::load(Cyg_LoaderStream&, cyg_uint32, 
Cyg_LoadObject**)’:
~/ecos/packages/services/loader/current/src/loader.cxx:160: error: 
‘class Cyg_LoadObject’ has no member named ‘get_error’
~/ecos/packages/services/loader/current/src/loader.cxx:168: error: no 
matching function for call to 
‘Cyg_CList_T<Cyg_LoadObject>::add_tail(Cyg_LoadObject*&)’
~/ecos_tests/ecos_install/include/cyg/infra/clist.hxx:209: note: 
candidates are: void Cyg_CList::add_tail(Cyg_DNode*)
~/ecos/packages/services/loader/current/src/loader.cxx:175: error: 
‘class Cyg_LoadObject’ has no member named ‘get_error’
~/ecos/packages/services/loader/current/src/loader.cxx:186: error: 
‘class Cyg_LoadObject’ has no member named ‘get_error’
~/ecos/packages/services/loader/current/src/loader.cxx:193: error: no 
matching function for call to 
‘Cyg_CList_T<Cyg_LoadObject>::remove(Cyg_LoadObject*&)’
~/ecos_tests/ecos_install/include/cyg/infra/clist.hxx:258: note: 
candidates are: void Cyg_CList::remove(Cyg_DNode*)
~/ecos/packages/services/loader/current/src/loader.cxx: In member 
function ‘CYG_ADDRESS Cyg_Loader::hash_lookup_addr(const char*)’:
~/ecos/packages/services/loader/current/src/loader.cxx:253: error: 
‘class Cyg_LoadObject’ has no member named ‘hash_lookup_addr’
~/ecos/packages/services/loader/current/src/loader.cxx:258: error: 
‘class Cyg_LoadObject’ has no member named ‘get_next’
~/ecos/packages/services/loader/current/src/loader.cxx: In constructor 
‘Cyg_LoadObject_Base::Cyg_LoadObject_Base(Cyg_LoaderStream&, cyg_uint32, 
Cyg_LoaderMemAlloc*)’:
~/ecos/packages/services/loader/current/src/loader.cxx:331: error: 
‘CYG_ELF_MACHINE’ was not declared in this scope
~/ecos/packages/services/loader/current/src/dload.cxx: In function 
‘void* dlsym(void*, const char*)’:
~/ecos/packages/services/loader/current/src/dload.cxx:178: error: ‘class 
Cyg_LoadObject’ has no member named ‘symbol’
make[1]: *** [src/dload.o.d] Error 1
make[1]: *** Waiting for unfinished jobs....
~/ecos/packages/services/loader/current/src/loader.cxx: In member 
function ‘void Cyg_LoadObject::relocate()’:
~/ecos/packages/services/loader/current/src/loader.cxx:767: error: ‘rel’ 
was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:770: error: 
‘relsize’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:770: error: 
‘error’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:770: error: 
‘relent’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:773: error: 
‘apply_rel’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:777: error: 
‘error’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:777: error: 
‘rela’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:780: error: 
‘relasize’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:780: error: 
‘relaent’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:784: error: 
‘apply_rela’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx: In member 
function ‘void Cyg_LoadObject::relocate_plt()’:
~/ecos/packages/services/loader/current/src/loader.cxx:797: error: 
‘pltrel’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:799: error: 
‘jmprel’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:800: error: 
‘pltrelsz’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:800: error: 
‘error’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:803: error: 
‘apply_rel’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:807: error: 
‘error’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:807: error: 
‘pltrel’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:809: error: 
‘jmprel’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:810: error: 
‘pltrelsz’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx:814: error: 
‘apply_rela’ was not declared in this scope
~/ecos/packages/services/loader/current/src/loader.cxx: In member 
function ‘virtual cyg_code Cyg_LoaderStream_File::seek(CYG_ADDRWORD)’:
~/ecos/packages/services/loader/current/src/loader.cxx:1045: warning: 
comparison between signed and unsigned integer expressions
make[1]: *** [src/loader.o.d] Error 1
make: *** [build] Error 2

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: STM32F4 and Dynamic loading.

[John Dallaway]

Hi Valentin

On 27/02/14 12:49, Valentin BOUSSON wrote:

> I encounter another problem that could signify the end between eCos
> and I for my project... :(
> After having some simple examples working, i tried to make one using
> Dynamic ELF loading (dlopen).

The dynamic library loader package (CYGPKG_LOADER) is experimental code
and has not be touched for many years. Would the object file loader
package (CYGPKG_OBJLOADER) meet your requirements? Ref:

  http://ecos.sourceware.org/ml/ecos-discuss/2013-05/msg00036.html

I hope this helps...

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: STM32F4 and Dynamic loading.

[Valentin BOUSSON]

Hi John,
Actually, yes it could be sufficient for my project, and digging around 
my problem, I tried to compile the CYGPKG_OBJLOADER package too.
And this is with this one I have a conflict problems :

This package requires CYGINT_SERVICES_OBJLOAD_RELOCATOR == 1,
which is implemented by :
- CYGBLD_OBJLOADER_ARCHITECTURE_{POWERPC,I386,ARM}

The problem now is the template for stm32f4discovery seems to "inherit" 
from CYGPKG_HAL_CORTEXM while CYGBLD_OBJLOADER_ARCHITECTURE_ARM is 
calculated from CYGPKG_HAL_ARM only.

Is there a structural incompatibility between HAL_ARM and HAL_CORTEXM ? 
Or that's a thing I can modify/hack in the ecos.


Or (I don't hope so, I'm still a beginner) do I have to implement 
something to create the CYGBLD_OBJLOADER_ARCHITECTURE_CORTEXM ?
:-)


Thanks,



On 27/02/2014 18:12, John Dallaway wrote:
 > Hi Valentin
 >
 > On 27/02/14 12:49, Valentin BOUSSON wrote:
 >
 >> I encounter another problem that could signify the end between eCos
 >> and I for my project... :(
 >> After having some simple examples working, i tried to make one using
 >> Dynamic ELF loading (dlopen).
 >
 > The dynamic library loader package (CYGPKG_LOADER) is experimental code
 > and has not be touched for many years. Would the object file loader
 > package (CYGPKG_OBJLOADER) meet your requirements? Ref:
 >
 > http://ecos.sourceware.org/ml/ecos-discuss/2013-05/msg00036.html
 >
 > I hope this helps...
 >
 > John Dallaway
 > eCos maintainer
 > http://www.dallaway.org.uk/john
 >


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: STM32F4 and Dynamic loading.

[John Dallaway]

Hi Valentin

On 28/02/14 10:15, Valentin BOUSSON wrote:

> Actually, yes it could be sufficient for my project, and digging around
> my problem, I tried to compile the CYGPKG_OBJLOADER package too.
> And this is with this one I have a conflict problems :
> 
> This package requires CYGINT_SERVICES_OBJLOAD_RELOCATOR == 1,
> which is implemented by :
> - CYGBLD_OBJLOADER_ARCHITECTURE_{POWERPC,I386,ARM}
> 
> The problem now is the template for stm32f4discovery seems to "inherit"
> from CYGPKG_HAL_CORTEXM while CYGBLD_OBJLOADER_ARCHITECTURE_ARM is
> calculated from CYGPKG_HAL_ARM only.
> 
> Is there a structural incompatibility between HAL_ARM and HAL_CORTEXM ?
> Or that's a thing I can modify/hack in the ecos.
> 
> Or (I don't hope so, I'm still a beginner) do I have to implement
> something to create the CYGBLD_OBJLOADER_ARCHITECTURE_CORTEXM ?

Good question. It depends whether relocate_arm.c supports the various
relocation types used with Cortex-M targets. The code calls CYG_ASSERT
if it encounters relocation types it does not support, so you might try
experimenting with cdl_option CYGBLD_OBJLOADER_ARCHITECTURE_ARM modified
as follows and see if it works:

    calculated CYGPKG_HAL_ARM || CYGPKG_HAL_CORTEXM

Of course, you should enable CYGDBG_USE_ASSERTS.

If you decide to experiment, please report back to the ecos-discuss list.

I hope this helps...

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Specific needs on stm32

["Ilija Kocho [Илија Кочо]"]

Hi Valentin



On 20.01.2014 17:12, Valentin BOUSSON wrote:
> Hi all, I'm fresh and new on this mailing list,
> and in the world of real embedded systems, actually.
>
> I bought a STM32F4 - DISCOVERY board to play with, and I succeeded to
> compile and run a lot of simple, led / LCD / audio project I found
> online. I was using the Sourcery arm compile chain for that.
>
> But my next ambition is little harder, I would like to adapt one of my
> existing program, based on a plugin-mechanism, on my stm32. So, I was
> looking for an RTOS being able to manage a simple system, in the Flash
> memory, or in an external SD card.
>
>
>
>
> I tried to set up the compilation environnement described in the big
> pdf describing eCos, and on the Download & Installation section on the
> website, I tried all the day, without any result.
> Do you have some good links / tuto / advices to share ?
>

You need to get eCos from CVS (that I prefer to call "the rolling release").
Here you'll find info how to access CVS
http://ecos.sourceware.org/anoncvs.html

Also you can try eCos arm-eabi GNU tools - test release 4.6.3
http://ecos.sourceware.org/ml/ecos-discuss/2012-06/msg00047.html
that comes with support for hardware floating point.

>
> My questions are :
> Is it possible to use the compilation chain generated by
> summon-arm-toolchain, to compile eCos itself ?

I haven't tried it.

>
> What about the programs I would like to run on top of eCos ?
>

What would you like to run?
With this little information, I can just say that porting POSIX
applications is relatively straight forward.

> If I store my programs in the Flash, how can I reprogram the flash to
> change only the program, and not the kernel ?
>

Kernel is in general being linked with application. However it is
possible to create dynamically loadable libraries.
Also, you can install RedBoot and then use it for loading applications.

> IYO, is eCOS the best OS to choose for my project ? // Are its dynamic
> loading mechanism easy to use ?
>

No one can tell you what's best for your project. But IMHO, eCos is
worth for consideration.
I encourage you to try it.

Have fun

Ilija


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss