I am trying to access a 16-bit PC-Card through a Cardbus controller. I
do this on an Windows XP platform with an RTX (Hard Realtime sub
system) extension. Using the RTX I have to do the driver-part myself! I
just have problems accessing the PC Cards CIS. I can (software) power
the PC Card up but then I'm lost. I don't know which EXCA-registers
should be set to properly get access to the memory I have allocated.

I have tried installing the device under Windows XP with the drivers
and looked at the registers set under XP management and tried to copy
these settings. This however doesn't work for me.

The funny thing is that I can access it if the PC Card and the Cardbus
controller are first installed in XP and then, without removing the PC
Card I reinstall the Cardbus under RTX. The running my software I can
find the CIS correctly! So I think the problem lies in the way I setup
the registers(or rather don't).

I am looking forward to hear from an experienced programmer on this
issue.

"Kim Stubberup" <stubberup (AT) gmail (DOT) com> wrote

Well, you mean you want to look at the tuples to ID the card? Or you want
to access the card?

If you are just copying the registers from a 'known' interface that works,
that
still won't do the work that is necessary (in most cases) to configure the
card, all you're doing is setting up the interface.

Further complicating this is 'where' the interface is. If your interface is
across
a 'bridge', then the bridge configuration comes into place. First you need
to
find out what resources get across the bridge and find out if they 'match'
what the configuration registers are set to for the PCCard interface. They
may not have a functional match.

As to drivers to talk to the card and how they play in this, I'm not gonna
even
go there!

Mike

Thanks Mike.

I have a PC Card (Mortara ECG). The card is placed in(sofar) a cardbus
controller on a laptop(dell latitude d510). As far as I can see the
cardbus controller on the laptop is a PCI1510 chipset. I Understand
this to be a bridge (PCI to Cardbus). The bridge is setup via the OS
and I have no trouble accessing the registers on that. Actually I can
read and write to the EXCA-registers (for 16-bit cards)(ergo I can read
the PCI configuration register) but I have my difficulties finding out
what should be written to them.
1) I can see that the card is inserted.
2) Then I can power up the card.
3) I can assign resources to the card.....and then I should be able to
just read in that memory area...but I don't see the correct data hence
I'm not in the right memory area(I think).

As I mentioned I can install the card under Win XP and then it is
possible for me to access it correctly when I reconfigure it to the RTX
environment. Mike (or anyone else) I hope you can give me some more
pointers or request more/specific info from my side.

Thanks in advance.

KimS

Realize that the 'configuration' of the card may be a 'sequence', not just
a static setting of registers.

Also realize that the resources used / assigned for successful operation
may be drastically different depending on the platform.

Isn't that an encryption card? That may take special handling right there.

Well, if you're doing it yourself... the first thing you would need to do
is
dump the configuration space. You can write a 'decoder' for the tuples,
but what I've found that's easy to do is just 'snapshot' the tuple space
and decode it manually. Then, on insert, if you find 'that' card, who
cares about the tuples. You KNOW it is the card you're looking for
if the space matches, so then just bang the configuration register(s) for
the card. Then bang the controller to set up the resources.

Thing is, how do you hook your driver to it on a hot insert? Or are you
also writing that?



"Kim Stubberup" <stubberup (AT) gmail (DOT) com> wrote

Thanks again Mike.

I have to write it all. The only thing I don't have to make myself is
the cardbus-controller resource-allocation.....which I believe is done
by the RTX driver. The Mortara ECG card is a heart rate
meassuring-thing. I need it in an embedded system for use in space(on
astronauts) just to let you a little bit in on it.

I have tried to get help in a book called: Cardbus System
Architechture, but this book only seems to tell me thing in a very
superficial way. Do you know of any ressources on the net (and not
pcmcia.org!!!) where I can find detailed info on the pcmcia/cardbus
subject?

I'll be glad to correspond with you through e-mail instead, if that
would be possible. My e-mail is stubberup (AT) gmail (DOT) com.

"Kim Stubberup" <stubberup (AT) gmail (DOT) com> wrote

SAMs had a book out, but I'm not sure if it's still available anymore.

Anyway, it's been years since I've written anything for this, but if
you're writing this so as to 'officially' interface...

First, you have to write your driver so that it 'registers' with
CardServices.
You want callbacks on events.

When you get an insertion event, then you have to decide how you want
to id the card. If this is a 'one shot', then just read the tuples through
CS (CardServices) and see if the card is a match. Remember, you'll get
callbacks for ANY and EVERY card inserted and/or removed.

Once you figure out the card is for you, either by decoding the tuples (the
'rom' code in 'attribute' memory space) or by just doing a 'match' to
space (but remember, tuples are only on every other address) then you
can request resources and request a configuration for the card.

Ok, at this point the card appears and should work. Usually at this point
you now have to call your driver for the card and tell it where the card is
in resource space (it could be different every insertion!).

And don't forget that you have to 'undo' all this stuff when the card is
removed and you get a removal event.

Also (and this can be the nasty part) you have to make sure you handle
suspend/resume and other power events. Some platforms can put a card
to sleep. Others treat power events as removal and insert events. The
removal and insert is easy, as long as your driver to use the card can
handle
'hot swap' type events. Putting the card to sleep can be tricky, as you
have
to know how to make sure the interface and the card are brought back up.
Writing drives for ATA cards was easy, I just treated everything as a
removal
and re-insert. With some 'sequence' type cards, it's not so easy.