This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: What is the reason to...


Yes, if it's the case, that the drivers only are linked in the application, if they are realy needed, then there is no reason to don't include the CYGPKG_IO_*'s and if the CYGPKG_IO_*'s do control, if the drivers are linked to the applications, then they shouldn't be marked as "hardware"...

But i don't know how it is...

Gábor Török schrieb:
I think it is the same issue CYGPKG_IO_USB and CYGPKG_IO_USB_SLAVE,
which are also marked as hadware packages and not included in the
templates.

On Fri, Nov 7, 2008 at 7:20 PM, oliver munz @ s p e a g <munz@speag.ch> wrote:
In this case templates like:

target at91sam7sek {
  alias { "Atmel AT91SAM7SEK evaluation board" at91_at91sam7sek }
  packages { CYGPKG_HAL_ARM
                 CYGPKG_HAL_ARM_AT91
                 CYGPKG_HAL_ARM_AT91SAM7
                 CYGPKG_HAL_ARM_AT91SAM7SEK
                 CYGPKG_IO_SERIAL_ARM_AT91
                 CYGPKG_DEVS_FLASH_AT91
                 CYGPKG_DEVS_SPI_ARM_AT91
                 CYGPKG_DEVICES_WATCHDOG_ARM_AT91WDTC
                 CYGPKG_DEVS_USB_AT91
      }
      description "
      The at91sam7sek target provides the packages needed to run eCos on an
      Atmel AT91SAM7S-EK evaluation board."
}

should be changed?

They are missing the CYGPKG_IO_SPI and so on...

Thanks Oliver

Bart Veer schrieb:
"Oliver" == oliver munz @ s p e a g <munz@speag.ch> writes:

   Oliver> mark CYGPKG_IO_SPI as HARDWARE?
   Oliver> I think Generic SPI or I2C and so one should be loadable
   Oliver> whitout an template. Can we change this?

The problem here is that other drivers such as the wallclock or
dataflash are likely to depend on the SPI/I2C bus being available. On
some platforms there may even be platform HAL dependencies on the bus.
Now, by convention you can enable flash support on a given platform
simply by e.g. "ecosconfig add flash" and everything sorts itself out.
If the SPI or I2C bus driver was not automatically part of the
configuration then that would stop working.

If you want the SPI or I2C support to be automatically available when
needed, working within the limitations of current CDL, then the
generic SPI or I2C packages have to be part of the target definition
in ecos.db. That means they have to be hardware packages.

Also, in most cases the expectation is that the generic SPI and I2C
packages will only be usable if the target definition also specifies a
device driver appropriate for the hardware. So if you are adding SPI
or I2C support to a target then you have to edit the ecos.db target
entry anyway, and adding two packages instead of one is no big deal.

Now, both the generic SPI and I2C packages have been carefully
designed to ensure that they add zero overhead to the application if
nothing actually uses the SPI or I2C bus. Any unused functionality
gets eliminated at link-time by linker garbage collection. Hence the
only real overhead is at build-time: ecosconfig or the configtool may
take a little longer to run, and a couple more files get compiled.
Neither is likely to be noticed by users unless they sit down with a
stopwatch.

Bart






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]