Re: [ECOS] cyg_io_lookup() allways returns ENOENT

[Sergei Gavrikov <sergei dot gavrikov at gmail dot com>]

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