This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Accessing flash memory
- From: seebs at plethora dot net (Peter Seebach)
- To: ecos-discuss at sources dot redhat dot com
- Date: Tue, 24 Jan 2006 06:02:14 -0600
- Subject: Re: [ECOS] Accessing flash memory
- Reply-to: 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