Re: [ECOS] Accessing flash memory

[seebs at plethora dot net (Peter Seebach)]

In message <20060124102206.GK8395@lunn.ch>, Andrew Lunn writes:
>I've never used stdint.h in eCos code. I generally stick to the eCos
>equivelent: cyg_uint32. 

Right.  But if I'm porting a bunch of code that uses the standard types, the
most convenient thing would be to use the existing definitions.

>machine/types is coming from the network stack and so is not a core
>part of eCos. If eCos was to provide <stdint.h> and <stdbool.h>, i
>think it would be in isoinfra which is include in every eCos
>configuration. If you want to edd thiese files to eCos, that is where
>i would suggest you put them.

Even with the network stack, I still don't seem to get that.  But I guess my
real question is:  If I don't happen to already know it's part of the network
stack, how am I supposed to go from "it's in this header" to "here is the
package I add to get it"?

>> 2.  Undefined references for fileno.  No problem, I search the docs.
>> I find a note in the docs that it's in the C stdio library.  ecosconfig list
>> suggests I want "libc_stdio".  I add it.  Nothing changes; I still have
>> undefined references to fieno.

>a quick grep found:

>2004-09-27  Jonathan Larmour  <jifl@eCosCentric.com>

>        * cdl/stdio.cdl (CYGFUN_LIBC_STDIO_OPEN_POSIX_FDFUNCS): New option,
>        to control whether or not fdopen()/fileno() are implemented.
>        Only build fopen/fclose if CYGPKG_LIBC_STDIO_OPEN.

>cdl_option CYGFUN_LIBC_STDIO_OPEN_POSIX_FDFUNCS {
>            display       "POSIX fdopen/fileno functions"
>            active_if     CYGPKG_LIBC_STDIO_FILEIO
>            implements    CYGINT_ISO_STDIO_POSIX_FDFUNCS
>            calculated    1
>            description   "This identifies to the rest of the system
>                           whether the POSIX fdopen() and
>                           fileno() functions are implemented."
>        }

>My guess is you don't have CYGPKG_LIBC_STDIO_FILEIO enabled. 

Okay.  So, uhm.  Will "ecosconfig list" hint at this?

I'm writing about eCos development, and I want to explain to people how to
configure eCos.  If the answer to "how do I find X" is "well, you grep around
for something until you find a reference to it in a cdl_option", that's going
to be a hard sell.

Can this feature be added from ecosconfig, or do I have to go edit the
ecos.ecc file manually?

>> 3.  I want termios (tcsetattr, struct termios).  Where do I look?  Nothing
>> in the documentation says anything but which features are implemented, and
>> which aren't.

>It is in io_serial. It will be disables by default so you need to
>enable it: CYGPKG_IO_SERIAL_TERMIOS. You also need to configure which
>serial port is is to be used on.

Okay.

So, the impression I'm getting is that a lot of these things must be done
by manually editing ecos.ecc, and that the reason I can't find them in
ecosconfig's list of packages is that ecosconfig is just a starting point,
and many configuration options can't be set by it; is that right?

>I guess most people work the other way around. They use the default
>template, or the net template. This has most things enabled and so
>don't run into some of these problems. The linker is quite good at
>leave out what is not needed by an application, so the penalty for
>doing it this way around is not very big. Once you have your
>application working and you find you are short of RAM/ROM you can then
>start disabling things.

Oh!  Okay, that's a very good idea, and makes more sense.

>ecosconfig add/remove just provides the top level of configuration, it
>includes or excludes the big blocks. For the fine level of
>configuration you have to get inside the ecos.ecc. You can either do
>this with a normal text editor, or you the configtool. It does take a
>while to learn what is where if you don't use the default template.

Okay, one of the things I was mistaken about was that I'd previously gotten
the impression that the configtool was a pure GUI wrapper; it didn't offer
anything you couldn't do from ecosconfig.  I get the impression now that
ecosconfig is NOT able to do everything, so I need to use configtool for
some features.

Thanks!  I think I'm getting a better feel for this now.

Hmm.  That leads me to the idea of doing some documentation work; the question
is, is the apparent lack of documentation here a design decision, or just that
no one's had the time or motivation to do it?  I think that adding "this
feature depends on X, Y, and Z" to sections in the manual would help
immensely, and make life much easier on prospective newbie developers.

-s

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