Hi Diego,
There are different approaches you use to solve the problem. Anyway if
you are talking about windows environment this is not the right forum as
it is the Movement for the Use of Smart Cards ina Linux Environment.
There are already some serial ifd handlers for linux, you could
consideradapting the serial protocol of your readers to behave as a
supported one or you could develop a serial reader driver with the help
of the IFDHandler API.
For windows, you can develop a core or a user mode driver (which is much
easier).
Bestregards,
Xavier
El 26/03/2013 9:41, Diego Delgado escribió:
Hi Xavi,
You are right. The reader is not able to act as an USB device, so it
seems the only solution is to develop the IFD handler (driver) for
Windows.
Then, do I have to begin with the WDK to develop such a driver? And
what about the the serial dependency, the PCSC driver will link to the
usbser.sys or another serial driver?
Thanks and regards.
El 22/03/2013 15:56, Xavier Monés escribió:
Hi Diego,
Although you have the source code of the readers, there is no PC/SC
specification for serial communication readers.
I also looks like your USB reader uses a USB to Serial bridge chipset
and you won't be able to change the USB behavior.
CCID applies to USB readers, so you will need to developyour own
driverfor the readers.
Best regards,
Xavier
El 22/03/2013 15:13, Sebastien Lorquet escribió:
Hello,
"PCSC" compliance is an API thing, you can achieve that with many methods:
-develop a pcsclite driver that handles your reader. In that case, you can
implement and support anything on the reader side.
This means developing a linux shared library that implements a specific API (IFD
API IIRC, not sure about the name)
You will have to distribute your driver in order for others to use your device.
-develop a CCID firmware for your device. CCID exists at a lower level than
PCSC.
You will have to follow the CCID specification (freely downloadable on the
usb-if website)
This means developing an embedded firmware acting as an USB device.
You will be able to use your device with pcsclite's "official" CCID driver,
which will imply PCSC compliance.
A CCID compliant device will likely also work with the stock MS Windows CCID
driver.
Regards
Sebastien
Le 22/03/2013 14:34, Diego Delgado a écrit :
El 22/03/2013 14:13, Bruno Jesus escribió:
On Fri, Mar 22, 2013 at 9:58 AM, Diego Delgado<[email protected]> wrote:
Well, I edit my last post.
I have the firmware source code of the readers and I can modify it. So I
think the best and fast solution would be to develop de CCID application
layer at firware level. I'm right?
Are there some resources, information, etc. to support the CCID developing?
You can refer to the documentation in
http://www.pcscworkgroup.com/specifications/specdownload.php
You can also see some sample code from Atmel. If you look for
cciddriver.c in google you will find several projects using their
files, for example:
http://makecontroller.googlecode.com/svn/firmware/trunk/core/usb/device/ccid/
It may be easier to write a CCID driver for pcsclite than try to write
the CCID for the device.
But the reader must to be CCID compliant, isn't? Is not theCCID driver a
generic driver for all CCID readers?
Moreover these readers are used in a Windows environment.
Thanks.
Diego.
Best wishes,
Bruno
El 22/03/2013 12:40, Diego Delgado escribió:
Hi there,
I have two smartcard contactless readers not PC/SC compliant.
The two readers communicate with the computer using a proprietary serial
protocol. One of the readers connects using a serial cable and the other
an USB cable although it's seen by Windows as a serial device (COMxx).
I would like to make these readers PC/SC compliant. I think the only way
is to make the PCSC driver for the reader, but I don't know how hard is
to develop a PC/SC driver from scratch and if it would be possible if
the reader (hardware and firmware) was not designed with PC/SC in mind.
If not, what about developing a "bridge layer" between the PCSC
framework and the propietary reader driver? In this case the bridge
layer redirects the PC/SC calls to to the propietary reader serial driver.
Maybe is this second approach more appropriate?
Thanks.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
_______________________________________________
Muscle mailing list
[email protected]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
_______________________________________________
Muscle mailing list
[email protected]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
_______________________________________________
Muscle mailing list
[email protected]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
_______________________________________________
Muscle mailing list
[email protected]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
_______________________________________________
Muscle mailing list
[email protected]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
_______________________________________________
Muscle mailing list
[email protected]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
_______________________________________________
Muscle mailing list
[email protected]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
