[ECOS] POSIX main thread

Szentirmai Gergely reg@t-online.hu
Wed Apr 15 07:00:00 GMT 2009



Sergei Gavrikov írta:
> On Sun, Apr 12, 2009 at 08:28:59PM +0300, Sergei Gavrikov wrote:
>> Please, stop a top posting: http://en.wikipedia.org/wiki/Top_posting
>> Here use: http://en.wikipedia.org/wiki/Top_posting#Bottom-posting
>>
>> On Sun, Apr 12, 2009 at 05:21:49PM +0200, Szentirmai Gergely wrote:
>>> Hello
>>>
>>> POSIX compatibility, not Linux compat. I'm not using the command line  
>>> ecos config, rather than the configtool GUI. In the ISO C startup  
>> Szentirmai, I belive in that what anyone can do the same using eCos GUI
>> (configtool) what anybody did get with `ecosconfig'. eCos documentation
>> talks about.
> 
> Okay, there is no splash at `configtool' start as 'Read eCos Doc First',
> See the "screenshots" the below (and you will understand why you find no
> assistance (help) with configtool on the list). Let eCos veterans excuse
> the below guide
> 

My problem was not the usage of configtool, but thanks anyway, it lead 
me to the solution. I added fatfs to my existing ecos config, which 
previously had a POSIX compat layer, which changed the type headers in 
some package options. When I removed it, there were error during 
compilation, it did not find files in install/posix/ etc. (because the 
header options were changed previously). That's why I beleived that 
something is depending on POSIX.
I removed the user-values manually from my ecc file, and now it can be 
compiled without POSIX compat.

Thank you for your help, and your patience!
Gergely Szentirmai

> configtool
>   Build
>     Templates
>       ST STM3210E EVAL board
>     OK
> 
>   Build
>     Packages
>       Available packages
>         CRC support
>           Add
>         File IO
>           Add
>         Block cache and access library
>           Add
>         Linux compatiblility
>           Add
>         FAT Filesystem
>           Add
>       Use theses packages
>         ISO environment startup/termination
>           Remove
>     OK 
>     Resolve config?
>       Continue
> 
>   File
>     Save as
>       fatfs
>     OK
> 
>   Build
>     Generate Build Tree
> 
>   Build
>     Library
> 
>   Build
>     Tests
> 
> 
> $ arm-eabi-size fatfs_install/tests/fs/fat/v3_0/tests/fatfs1 
>    text	   data	    bss	    dec	    hex	filename
>   34036	    944	   6276	  41256	   a128	fatfs_install/tests/fs/fat/v3_0/tests/fatfs1
> 
> It was happiness that I had no need to guide you via a forest of the
> pulled-down options :-)
> 
> 
> Sergei
> 
> 
>> I did show you in previous post that eCos FS_FAT is not depend on POSIX
>> package. It requires CYGPKG_BLOCK_LIB package and this package depends
>> on CYGPKG_LINUX_COMPAT (I guess on some compatible headers).
>>
>>> section, I have found abelity to define the calling mode of main(), and  
>>> the default stacksize. My coniguration is to call main() from  
>>> cyg_user_start context. This way ecos does not allocate stack for  
>>> starting main. This way, the
>> Is it so exactly? eCos iself stands up the main() thread (it is declared
>> as a weak function). By default, it does nothing (returns immediately),
>> if do not have own one. Even more, you can remove an eCos package
>> CYGPKG_ISO_STARTUP from your configuration. Try to remove it. As I could
>> understand you try to reduce any overhead from eCos+fatfs.
>>
>> Just to demo (without the STACK_SIZE dances). I will use stm3210e target
>> to finalize example: eCos+fatfs-main ("minus main"). Once again, I
>> belive in that what you will be able to get it with `configtool' too
>> (see what I add and see what I remove and do the same using GUI).
>>
>> $ ecosconfig new stm3210e default
>> $ ecosconfig add crc fileio CYGPKG_BLOCK_LIB CYGPKG_LINUX_COMPAT fatfs
>> U CYGBLD_ISO_FNMATCH_HEADER, new inferred value <cyg/fileio/fnmatch.h>
>> U CYGBLD_ISO_DIRENT_HEADER, new inferred value <cyg/fileio/dirent.h>
>> U CYGBLD_ISO_OPEN_MAX_HEADER, new inferred value <cyg/fileio/limits.h>
>> U CYGBLD_ISO_NAME_MAX_HEADER, new inferred value <cyg/fileio/limits.h>
>> $ ecosconfig remove CYGPKG_LIBC_STARTUP
>> $ ecosconfig check
>> Target: stm3210e_eval
>> Template: default
>> Added:
>>  CYGPKG_CRC
>>  CYGPKG_IO_FILEIO
>>  CYGPKG_BLOCK_LIB
>>  CYGPKG_LINUX_COMPAT
>>  CYGPKG_FS_FAT
>> Removed:
>>  CYGPKG_LIBC_STARTUP
>> No conflicts
>>
>> ...
>>
>> $ make -s -C fs/fat/v3_0 tests
>> $ arm-eabi-size install/tests/fs/fat/v3_0/tests/fatfs1
>>     text   data	    bss	    dec	    hex	filename
>>   34052	    944	   6276	  41272	   a138	install/tests/fs/fat/v3_0/tests/fatfs1
>>
>> I checked that there are a lot of fatfs entries in the executable (it's
>> too long list to paste here)
>>
>> $ arm-eabi-nm install/tests/fs/fat/v3_0/tests/fatfs1 | grep fatfs
>> ...
>> 6800a734 T fatfs_write_data
>> 6800b1fc T fatfs_write_dir_entry
>>
>> $ arm-eabi-nm install/tests/fs/fat/v3_0/tests/fatfs1 | grep fatfs | wc -l
>> 54
>>
>> As you can see it was possible to get eCos+fatfs-main with an unbeat
>> size. Try to get it with `configtool'. You have to get something I have
>> got. There are menus to add/remove packages in `configtool'. And, it
>> seems for me that you must read eCos documentation. For reference about
>> ISO main() startup read eCos reference:
>> http://ecos.sourceware.org/docs-latest/ref/c-and-math-library-overview.html
>> http://ecos.sourceware.org/docs-latest/ref/c-library-startup.html.
>>
>>
>> Sergei
>>
>>
>>> CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE   option is disabled. So, I can't set 
>>> the value (in the GUI of course). 
>>>
>>> When I use POSIX layer, pthread.cxx allocates a stack whether there is a  
>>> main() function, or not. The size of this stack is depending on  
>>> CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE and PTHREAD_STACK_MINIMUM.
>>>
>>> PTHREAD_STACK_MINIMUM is given, but I think  
>>> CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE  should be active even if there is a  
>>> POSIX compatibility layer added.
>>>
>>> Thank you!
>>> Gergely Szentirmai
>>>
>>> Sergei Gavrikov írta:
>>>> On Fri, Apr 10, 2009 at 08:03:29PM +0200, Szentirmai Gergely wrote:
>>>>   
>>>>> Hello
>>>>>
>>>>> I had to add POSIX compatibility to my project, because FAT support 
>>>>> is  depending on it. It's ok, but I don't need POSIX compat to create 
>>>>> a  thread, and call main(). It eats 8k from my SRAM, and that hurts 
>>>>> much!
>>>>>     
>>>> Hm. POSIX compat or LINUX compat? It's possible do not include posix
>>>> package to buid eCos `fatfs1' test
>>>>
>>>> ecosconfig new <target>
>>>> ecosconfig add CYGPKG_LINUX_COMPAT
>>>> ecosconfig add CYGPKG_BLOCK_LIB
>>>> ecosconfig add fileio fatfs
>>>> ecosconfig tree
>>>> make -s
>>>> make -s -C fs/fat/current/ tests
>>>>
>>>> The fatfs1's size is
>>>>
>>>> arm-eabi-size install/tests/fs/fat/current/tests/fatfs1    text	   
>>>> data	    bss	    dec	    hex	filename
>>>>   48088	    956	  15148	  64192	   fac0	install/tests/fs/fat/current/tests/fatfs1
>>>>
>>>>
>>>>   
>>>>> As I see from the source pthread.cxx there is no upportunitiy to 
>>>>> disable  this feature.
>>>>>
>>>>> Would not be it usefull? Or there is a reason, why it is not 
>>>>> available.  As a secound option, I would make a 
>>>>> main_thread_stack_size option in  posix thread configuration in the 
>>>>> cdl.
>>>>>
>>>>>     
>>>> If your main() will be just a paleholder, decrease it's stack. If you
>>>> import the below, for example, before to type 'ecosconfig tree'
>>>>
>>>> cdl_option CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE {
>>>>     user_value 128;
>>>> };
>>>>
>>>> you will decrease .bss. It's just an example! Unfortunately, AFAIK,
>>>> FATFS will suck in any case, you can think, I will decrease .bss, and
>>>> all will be okay, but FATFS sucks a heap too
>>>>
>>>> arm-eabi-nm install/tests/fs/fat/current/tests/fatfs1 | grep alloc
>>>>            ...
>>>> 68010aa4 T cyg_fd_alloc
>>>> 68010b1c T cyg_file_alloc
>>>> 68013dd0 D cygmem_memalloc_heaps
>>>> 6800cc94 T fatfs_node_alloc
>>>> 6800f9d0 T malloc
>>>>
>>>> Yet another "reserve" to decrease amount of used RAM is to decrease
>>>> CYGNUM_FILEIO_NFILE value.
>>>>
>>>>
>>>> Sergei
>>>>
>>>>   
> 

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



More information about the Ecos-discuss mailing list