* What is the reason to... @ 2008-11-04 14:46 oliver munz @ s p e a g 2008-11-04 18:57 ` Bart Veer 0 siblings, 1 reply; 14+ messages in thread From: oliver munz @ s p e a g @ 2008-11-04 14:46 UTC (permalink / raw) To: ecos-devel mark CYGPKG_IO_SPI as HARDWARE? I think Generic SPI or I2C and so one should be loadable whitout an template. Can we change this? Thanks ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to... 2008-11-04 14:46 What is the reason to oliver munz @ s p e a g @ 2008-11-04 18:57 ` Bart Veer 2008-11-07 18:20 ` oliver munz @ s p e a g 2008-11-18 17:16 ` Jonathan Larmour 0 siblings, 2 replies; 14+ messages in thread From: Bart Veer @ 2008-11-04 18:57 UTC (permalink / raw) To: munz; +Cc: ecos-devel >>>>> "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 -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to... 2008-11-04 18:57 ` Bart Veer @ 2008-11-07 18:20 ` oliver munz @ s p e a g 2008-11-08 21:40 ` Gábor Török ` (2 more replies) 2008-11-18 17:16 ` Jonathan Larmour 1 sibling, 3 replies; 14+ messages in thread From: oliver munz @ s p e a g @ 2008-11-07 18:20 UTC (permalink / raw) To: Bart Veer; +Cc: ecos-devel 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 > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to... 2008-11-07 18:20 ` oliver munz @ s p e a g @ 2008-11-08 21:40 ` Gábor Török 2008-11-08 23:25 ` Oliver Munz @ SNR 2008-11-09 13:46 ` Bart Veer 2008-11-09 13:35 ` Bart Veer 2008-11-23 21:43 ` Bart Veer 2 siblings, 2 replies; 14+ messages in thread From: Gábor Török @ 2008-11-08 21:40 UTC (permalink / raw) To: munz, ecos-devel 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 >> >> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to... 2008-11-08 21:40 ` Gábor Török @ 2008-11-08 23:25 ` Oliver Munz @ SNR 2008-11-09 11:08 ` Gary Thomas 2008-11-09 13:46 ` Bart Veer 1 sibling, 1 reply; 14+ messages in thread From: Oliver Munz @ SNR @ 2008-11-08 23:25 UTC (permalink / raw) To: Gábor Török; +Cc: ecos-devel 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 >>> >>> >>> > > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to... 2008-11-08 23:25 ` Oliver Munz @ SNR @ 2008-11-09 11:08 ` Gary Thomas 2008-11-09 13:52 ` Bart Veer 0 siblings, 1 reply; 14+ messages in thread From: Gary Thomas @ 2008-11-09 11:08 UTC (permalink / raw) To: oli; +Cc: Gábor Török, ecos-devel Oliver Munz @ SNR wrote: > 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... The reason things are done this way is to allow building a configuration with minimal drivers included. The hardware drivers (e.g. CYGPKG_DEVS_SPI_ARM_AT91) are designed such that they will be disabled unless the corresponding generic layer is present (CYGPKG_IO_SPI). Thus in the default configuration SPI will be disabled. Adding CYGPKG_IO_SPI enables the whole SPI framework, including the platform drivers. > 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 >>>> >>>> >>>> >> >> >> -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to... 2008-11-09 11:08 ` Gary Thomas @ 2008-11-09 13:52 ` Bart Veer 0 siblings, 0 replies; 14+ messages in thread From: Bart Veer @ 2008-11-09 13:52 UTC (permalink / raw) To: Gary Thomas; +Cc: oli, tgabor84, ecos-devel >>>>> "Gary" == Gary Thomas <gary@mlbassoc.com> writes: Gary> Oliver Munz @ SNR wrote: >> 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... Gary> The reason things are done this way is to allow building a Gary> configuration with minimal drivers included. The hardware Gary> drivers (e.g. CYGPKG_DEVS_SPI_ARM_AT91) are designed such Gary> that they will be disabled unless the corresponding generic Gary> layer is present (CYGPKG_IO_SPI). Thus in the default Gary> configuration SPI will be disabled. Gary> Adding CYGPKG_IO_SPI enables the whole SPI framework, Gary> including the platform drivers. No. What you are describing is true for some types of device, e.g. ethernet and flash. It is not true for SPI or I2C. Those depend on link-time elimination of unwanted functionality, as opposed to configure-time adding of desired functionality. A key difference is that SPI and I2C are buses that may be needed by other bits of the port, including the platform HAL. Hence to keep things simple for users the generic code must be included in the configuration by default. Bart -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to... 2008-11-08 21:40 ` Gábor Török 2008-11-08 23:25 ` Oliver Munz @ SNR @ 2008-11-09 13:46 ` Bart Veer 2008-11-09 15:34 ` Frank Pagliughi 1 sibling, 1 reply; 14+ messages in thread From: Bart Veer @ 2008-11-09 13:46 UTC (permalink / raw) To: Gábor Török; +Cc: munz, ecos-devel >>>>> "tgabor84" == =?ISO-8859-1?Q?G=E1bor T=F6r=F6k?= <tgabor84@gmail.com> writes: tgabor84> I think it is the same issue CYGPKG_IO_USB and tgabor84> CYGPKG_IO_USB_SLAVE, which are also marked as hadware tgabor84> packages and not included in the templates. CYGPKG_IO_USB and CYGPKG_IO_USB_SLAVE are included in the target definitions for some targets, e.g. assabet, corresponding to the boards for which slave-side USB first became available. The reasoning is the same as for SPI and I2C: if the application does not use the functionality then it gets eliminated at link-time. Again I do not know if this works properly with more recent drivers. Also, USB is somewhat more complicated than SPI. Side issue: please be careful with terminology. A template is a hardware-independent description of functionality, e.g. "default", "redboot", or "net". Templates live in separate files below the templates/ subdirectory of the eCos repository. A target definition describes a hardware target, i.e. a specific board. Target definitions live in the ecos.db file. The combination of a target definition and a template gives an initial configuration. Bart -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to... 2008-11-09 13:46 ` Bart Veer @ 2008-11-09 15:34 ` Frank Pagliughi 0 siblings, 0 replies; 14+ messages in thread From: Frank Pagliughi @ 2008-11-09 15:34 UTC (permalink / raw) To: Bart Veer; +Cc: Gábor Török, munz, ecos-devel I also think that our views on the issue are affected by which configuration editor we use. If I'm not mistaken, when using the command-line editor you can just "add" the drivers into your configuration, but if you use the GUI configtool, you can't add the packages and must edit "ecos.db" to get these drivers. And then you must manage a non-standard database file when upgrading from CVS. So people, like me, who tend to use the GUI configtool would have more of a reason to want to see theese drivers included in the target definition. - Frank Pagliughi Bart Veer wrote: >>>>>> tgabor84> I think it is the same issue CYGPKG_IO_USB and >>>>>> tgabor84> CYGPKG_IO_USB_SLAVE, which are also marked as hadware >>>>>> tgabor84> packages and not included in the templates. >>>>>> >>>>>> CYGPKG_IO_USB and CYGPKG_IO_USB_SLAVE are included in the target >>>>>> definitions for some targets, e.g. assabet, corresponding to the >>>>>> boards for which slave-side USB first became available. The reasoning >>>>>> is the same as for SPI and I2C: if the application does not use the >>>>>> functionality then it gets eliminated at link-time. Again I do not >>>>>> know if this works properly with more recent drivers. Also, USB is >>>>>> somewhat more complicated than SPI. >>>>>> >>>>>> Side issue: please be careful with terminology. A template is a >>>>>> hardware-independent description of functionality, e.g. "default", >>>>>> "redboot", or "net". Templates live in separate files below the >>>>>> templates/ subdirectory of the eCos repository. A target definition >>>>>> describes a hardware target, i.e. a specific board. Target definitions >>>>>> live in the ecos.db file. The combination of a target definition and a >>>>>> template gives an initial configuration. >>>>>> >>>>>> Bart >>>>>> >>>>>> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to... 2008-11-07 18:20 ` oliver munz @ s p e a g 2008-11-08 21:40 ` Gábor Török @ 2008-11-09 13:35 ` Bart Veer 2008-11-23 21:43 ` Bart Veer 2 siblings, 0 replies; 14+ messages in thread From: Bart Veer @ 2008-11-09 13:35 UTC (permalink / raw) To: munz; +Cc: ecos-devel >>>>> "Oliver" == oliver munz @ s p e a g <munz@speag.ch> writes: Oliver> In this case templates like: Oliver> target at91sam7sek { Oliver> alias { "Atmel AT91SAM7SEK evaluation board" at91_at91sam7sek } Oliver> packages { CYGPKG_HAL_ARM Oliver> CYGPKG_HAL_ARM_AT91 Oliver> CYGPKG_HAL_ARM_AT91SAM7 Oliver> CYGPKG_HAL_ARM_AT91SAM7SEK Oliver> CYGPKG_IO_SERIAL_ARM_AT91 Oliver> CYGPKG_DEVS_FLASH_AT91 Oliver> CYGPKG_DEVS_SPI_ARM_AT91 Oliver> CYGPKG_DEVICES_WATCHDOG_ARM_AT91WDTC Oliver> CYGPKG_DEVS_USB_AT91 Oliver> } Oliver> description " Oliver> The at91sam7sek target provides the packages needed to run eCos Oliver> on an Oliver> Atmel AT91SAM7S-EK evaluation board." Oliver> } Oliver> should be changed? Oliver> They are missing the CYGPKG_IO_SPI and so on... I believe they should be changed. From http://ecos.sourceware.org/docs-latest/ref/spi-porting.html: "If there is already an SPI bus driver for the target hardware then both that driver and this generic SPI package CYGPKG_IO_SPI should be included in the ecos.db target entry." I do not know all the inner details of the AT91 SPI driver so there may be unexpected side effects. Bart -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to... 2008-11-07 18:20 ` oliver munz @ s p e a g 2008-11-08 21:40 ` Gábor Török 2008-11-09 13:35 ` Bart Veer @ 2008-11-23 21:43 ` Bart Veer 2 siblings, 0 replies; 14+ messages in thread From: Bart Veer @ 2008-11-23 21:43 UTC (permalink / raw) To: munz; +Cc: ecos-devel >>>>> "Oliver" == oliver munz @ s p e a g <munz@speag.ch> writes: Oliver> In this case templates like: Oliver> target at91sam7sek { Oliver> alias { "Atmel AT91SAM7SEK evaluation board" at91_at91sam7sek } Oliver> packages { CYGPKG_HAL_ARM Oliver> CYGPKG_HAL_ARM_AT91 Oliver> CYGPKG_HAL_ARM_AT91SAM7 Oliver> CYGPKG_HAL_ARM_AT91SAM7SEK Oliver> CYGPKG_IO_SERIAL_ARM_AT91 Oliver> CYGPKG_DEVS_FLASH_AT91 Oliver> CYGPKG_DEVS_SPI_ARM_AT91 Oliver> CYGPKG_DEVICES_WATCHDOG_ARM_AT91WDTC Oliver> CYGPKG_DEVS_USB_AT91 Oliver> } Oliver> description " Oliver> The at91sam7sek target provides the packages needed to run eCos Oliver> on an Oliver> Atmel AT91SAM7S-EK evaluation board." Oliver> } Oliver> should be changed? Oliver> They are missing the CYGPKG_IO_SPI and so on... As per http://ecos.sourceware.org/ml/ecos-devel/2008-11/msg00012.html, yes. However it looks like other changes are needed. If you just add CYGPKG_IO_SPI to the target definition (not template, that is something else) then you end up with SPI driver code even in executables that do not use SPI. Just build the default config, then do an objdump of install/tests/kernel/current/tm_basic, and you'll see the spi functions. Changing spi_at91.cdl, removing the -library=libextras.a from the compile spi_at91_init.cxx, sorts out that problem. However I don't have a suitable board handy right now so I cannot check that everything still works. So somebody needs to do some experimenting and provide a patch. Bart -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to... 2008-11-04 18:57 ` Bart Veer 2008-11-07 18:20 ` oliver munz @ s p e a g @ 2008-11-18 17:16 ` Jonathan Larmour 2008-11-18 18:39 ` Bart Veer 1 sibling, 1 reply; 14+ messages in thread From: Jonathan Larmour @ 2008-11-18 17:16 UTC (permalink / raw) To: Bart Veer; +Cc: munz, ecos-devel Bart Veer wrote: >>>>>> "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. I've said this before and will just take the opportunity to say it again: the 'hardware' attribute just gets in the way. You can't have packages in the target definition that aren't 'hardware', and you can't add packages which are marked as 'hardware', so there is a wholly artificial division between packages. I would prefer the whole 'hardware' attribute was dropped and give platform developers, and application developers the ability to control their own hardware configuration without having to edit repository files. It should be possible for the HAL developers to list any driver packages appropriate for their hardware in the target definition; and possible for app developers to add/remove from that as needed. There's always been plug-in modules, expansion buses etc., nevermind modern configurable hardware, so assuming hardware is static seems archaic. I suspect it has cost people more wasted time and confusion than it has ever saved. I've had to jump through these hoops, and not seen any benefit. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to... 2008-11-18 17:16 ` Jonathan Larmour @ 2008-11-18 18:39 ` Bart Veer 2008-11-18 18:45 ` Jonathan Larmour 0 siblings, 1 reply; 14+ messages in thread From: Bart Veer @ 2008-11-18 18:39 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-devel >>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes: Jifl> Bart Veer wrote: >>>>>>> "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. Jifl> I've said this before and will just take the opportunity to Jifl> say it again: the 'hardware' attribute just gets in the way. Jifl> You can't have packages in the target definition that aren't Jifl> 'hardware', and you can't add packages which are marked as Jifl> 'hardware', so there is a wholly artificial division between Jifl> packages. Jifl> I would prefer the whole 'hardware' attribute was dropped Jifl> and give platform developers, and application developers the Jifl> ability to control their own hardware configuration without Jifl> having to edit repository files. It should be possible for Jifl> the HAL developers to list any driver packages appropriate Jifl> for their hardware in the target definition; and possible Jifl> for app developers to add/remove from that as needed. Jifl> There's always been plug-in modules, expansion buses etc., Jifl> nevermind modern configurable hardware, so assuming hardware Jifl> is static seems archaic. Jifl> I suspect it has cost people more wasted time and confusion Jifl> than it has ever saved. I've had to jump through these Jifl> hoops, and not seen any benefit. The hardware attribute is an extremely poor substitute for what I had planned in the original design of the configuration system, but in my opinion right now is not the right time to have that discussion. The SPI and I2C subsystems work just fine when developers follow the documentation, although admittedly it would have been useful if there had been reference driver implementations checked in at the same time as the generic packages. AFAIK nobody is planning any further work on the host-side tools before 3.0, so the hardware attribute will stay for the foreseeable future. Bart -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to... 2008-11-18 18:39 ` Bart Veer @ 2008-11-18 18:45 ` Jonathan Larmour 0 siblings, 0 replies; 14+ messages in thread From: Jonathan Larmour @ 2008-11-18 18:45 UTC (permalink / raw) To: Bart Veer; +Cc: ecos-devel Bart Veer wrote: > > The hardware attribute is an extremely poor substitute for what I had > planned in the original design of the configuration system, but in my > opinion right now is not the right time to have that discussion. Yes I wasn't proposing changing it now. Just mentioning while it was on-topic. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2008-11-23 21:43 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-11-04 14:46 What is the reason to oliver munz @ s p e a g 2008-11-04 18:57 ` Bart Veer 2008-11-07 18:20 ` oliver munz @ s p e a g 2008-11-08 21:40 ` Gábor Török 2008-11-08 23:25 ` Oliver Munz @ SNR 2008-11-09 11:08 ` Gary Thomas 2008-11-09 13:52 ` Bart Veer 2008-11-09 13:46 ` Bart Veer 2008-11-09 15:34 ` Frank Pagliughi 2008-11-09 13:35 ` Bart Veer 2008-11-23 21:43 ` Bart Veer 2008-11-18 17:16 ` Jonathan Larmour 2008-11-18 18:39 ` Bart Veer 2008-11-18 18:45 ` Jonathan Larmour
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).