Marcus, thank you very much for not giving up trying to help me.
Your hints lead to a lot of further questions (which means prgress to
me).
>It
seems to me that the specifications for a "PCMCIA driver" in Geos do >not
define too many device-specific functions at all - most CardService
>functions only seem to deal with general things like notifications of
>inserting, removing and reserving access to the card, while additional
>interfaces have to be provided by the driver itself if it wants to
>support a non-standard device. Actually, this seems reasonable to me, as
>a new type of I/O device must bring its own command set unless it is only
>a PCMCIA version of an already supported device class... The PCMCIA
>driver structure appears to work only as a means of negotiating dynamic
>loading/unloading of drivers when cards are inserted/removed.
You
refer to
1. Card Services
2. The "driver itself"
3. The (PCMCIA) driver stucture
In section 1.1.2 of the Driver Development Guide (DDK)
the driver structure is described as consisting of
(a) an interface to the system (which is called the strategy routine),
and
(b) an interface to the device (which typically results in registering
interrupt handlers)
Card services for PCMCIA drivers are described in section 3.3. From the
kind of events signalled by the card services and the kind of functions
provided by card services, it looks as if the card services are closer to
the device than the "driver itself"; i.e. the card services are used by
the drivers to communicate with the device.
Is this also your understanding ?????
So
far, I thought that the Sample PCMCIA driver given in
\OMNIGO\DRIVER\DDK\PCMCIA\SAMPLE and \OMNIGO\DRIVER\DDK\PCMCIA describe
the "driver itself" but not the card services. Your comment seems to
indicate the opposite.
I also assumed that the part which is typically provided by the customer
or user or application developer is the driver (itself), and that the
card services are typically untouched. Your comment seem to agree with
this. If this is true, however, I would expect the samples to show how a
driver looks, but not how card services look.
In
conclusion, I'm still confused about
(a) where the part issuing the device specific commands has to be
(b) which part the sample is showing, and
(c) how I could get information about the functions not shown in the
sample
>I
had a quick look at the source code of the PSERIAL driver for PCMCIA
>serial cards on the Zoomer in ...\driver\sdk\pcmcia\pserial\zoomer of the
>pre-OmniGo version of the SDK (it seems that this driver is not in the
>OmniGo DDK, who knows why?): this driver doesn't contain any
>serial-device-specific functions, instead it just loads the standard
>serial.geo driver and registers itself as an additional "port" with the
>driver, specifying a base port and IRQ number. The serial driver then
>seems to handle actual access to the card. I think that a similar
>strategy will be necessary for other I/O-style cards...
What kind of cards are serial cards (on the Zoomer) ?
Could I get the source code of the PSERIAL driver, or is there another or
better way to learn about this method of combining two device drivers ?
>This is a list of the driver functions which are mapped by the PSERIAL
>driver's strategy routine:
What means these functions "are mapped by the PSERIAL driver's strategy
routine" ? Does it mean that these PCMCIA specific functions are first
received by the PSERIAL driver's strategy routine and from there routed to
the PCMCIA driver ( or the other way around ) ?
>DR_INIT
>DR_EXIT
>DR_SUSPEND
>DR_UNSUSPEND
>DRE_TEST_DEVICE
>DRE_SET_DEVICE
>DR_PCMCIA_CONFIRM_REMOVAL
>DR_PCMCIA_CARD_REINSERTED
>DR_PCMCIA_POWER_DOWN
>DR_PCMCIA_POWER_UP
>DR_PCMCIA_DEVICE_TURNED_ON
>DR_PCMCIA_DEVICE_TURNED_OFF
>The standard serial driver only becomes involved in DRE_SET_DEVICE and in
>the on/off/inserted/removed functions of the PCMCIA driver.
>Only very general stuff, but maybe this helps you in getting on the right
>track...
I'm sure you helped me getting on the right track.
Regards, Hans
>ciao marcus
- --
- -----------------------------------------------------------
diel@intbuso.boeblingen.netsurf.de
- -----------------------------------------------------------