Please, do not top post here
(http://en.wikipedia.org/wiki/Top_posting#Top-posting)

On Sun, Dec 20, 2009 at 09:20:10PM +0100, Bernhard Gebert wrote:
>  Hello Sergei,
> 
> thanks for your fast reply and your information about the general
> handling.
> 
> As I am used to the eCos Configtool, I tried it this way. In the
> "Packages" window, there is a checkbox "Omit hardware packages"
> which I ignored until now.  But, adding the device driver is blocked
> with the info "Add and remove hardware packages by selecting a new
> hardware template." By searching a bit, I found
> http://old.nabble.com/SPI-support-cannot-be-added-for-AT91SAM7X-EK-td21456285.html
> and added CYGPKG_DEVS_CAN_AT91SAM7 to the structure "target
> at91sam7xek".  But the new package does not occur in the package
> window on the selected side, and the io_lookup() does still not
> work.

As I said that target's pkg depends on generic pkg: CYGPKG_IO_CAN. You
must add generic can i/o package first.

> 
> By the way, CYGPKG_IO_SPI and CYGPKG_DEVS_SPI_ARM_AT91 are included
> and visible in the selected packages window.
> 
> Is the template "default" my problem? When I select "all", the
> kernel gets too large for my µC, and all the other variants do not
> look more useful.

No, it is not. The eCos `default' template is well balanced, IMO, the
template is suitable even for your small memory footprint target. And
certainly that eCos `all' template is more bloat and not only for your
target.

It seems for me there is some mess in your config (build) steps.  I'm
sorry, I cannot assist you with `configtool' I do not use it and I
have not your target. I can only be sure that all builds itself okay:

mkdir /tmp/foo && cd /tmp/foo
ecosconfig new at91sam7xek default
ecosconfig add can devs_can_at91sam7
ecosconfig import /dev/stdin <<EOF
cdl_option CYGBLD_IO_CAN_EXTRA_TESTS {
    user_value 1
};
EOF
ecosconfig tree
make -s

That will build a couple of CAN tests under `install/bin' directory.
And the tests are small enougth for the uC:

arm-eabi-size install/bin/*
   text    data     bss     dec     hex filename
  36704    1316   27652   65672   10088 install/bin/can_filter
  35444    1316   27652   64412    fb9c install/bin/can_hdi
  35952    1316   37428   74696   123c8 install/bin/can_load
  36772    1316   27652   65740   100cc install/bin/can_remote
  34940    1316   27644   63900    f99c install/bin/can_tx


I missed one thing. What eCos version do you use? Is that CVS or 3.0
eCos? The above script was done with the latest eCos sources from CVS.
At the least I saw that CAN tests for your target were built smoothly
and they are under 40K for code segment and under 30K for volatile
data. More that all test were built with the default settings, i.e.
without any optimization through CDL options. By other hand I cannot
neither confirm nor refute your ENOENT error having no real hardware.

HIH

Sergei

> Brg, Bernhard
> 
> 
> Sergei Gavrikov schrieb:
> >On Sun, Dec 20, 2009 at 04:30:55PM +0100, Bernhard Gebert wrote:
> >>Hi,
> >>
> >>running my AT91SAM7X256-EK with the eCos configuration from
> >>template "default", I would like to acess the CAN device driver.
> >>As I am not experienced with drivers, I simply called
> >>cyg_io_lookup("/dev/can0",&handle), but I got the ENOENT error.
> >>The
> >
> >Hi Bernhard,
> >
> >Default template has not support for CAN devs. You must add two
> >extra packages: CYGPKG_IO_CAN (generic `can' pkg),
> >CYGPKG_DEVS_CAN_AT91SAM7 (`can' pkg for your target)
> >
> >It seems for me that the minimal steps to configure a build with
> >CAN support for your target are
> >
> >  ecosconfig new at91sam7xek ecosconfig add CYGPKG_IO_CAN
> >  CYGPKG_DEVS_CAN_AT91SAM7
> >
> >or using the package's aliases
> >
> >  ecosconfig new at91sam7xek ecosconfig add can devs_can_at91sam7
> >
> >I believe in that what the same things it's possible to fulfil
> >using eCos GUI configure tool (`configtool').
> >
> >>same result for /dev/tty0, /sev/ser0, /dev/spi0, and so on.  The
> >
> >The same is for other eCos devices, you need either to add or allow
> >the generic i/o package/driver for the device(s) and possible to
> >add the target's specific package (if target has a support for such
> >a kind of the devices).
> >
> >>method of searching for a directory-like string sounds like in
> >>real hich level system with file handling; but my small AT91 runs
> >>everything from ROM without a file system. Is this the problem?
> >
> >Those I/O devices do not claim a FS support.
> >
> >>One more silly question: I did not find a string like "/dev/..."
> >>in the ecos tree, but anyone (the low-level device-driver
> >>can_at91sam7.c?) has to register at the eCos devTable with this
> >>name?!?
> >
> >The eCos documentation is a clue
> >http://ecos.sourceware.org/docs-latest/
> >http://ecos.sourceware.org/docs-latest/ref/io.html
> >
> >HIH
> >
> >Sergei
> >
> >>Thanks in advance, Bernhard
> >
> >
> 

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

Reply via email to