On Thu, Jul 8, 2010 at 3:09 AM, Wayne <[email protected]> wrote: > > Hi Sebastein, > > As to the PB in T=0 protocol, I think I'm clear days before. But after the > discusstion between Drasko, I'm confused again. > > On Thu, Jul 8, 2010 at 12:05 AM, Sébastien Lorquet <[email protected]> wrote: >> >> The last one. a call to the driver is a single sequence of data sending / >> data return. >> Return only 61XX if necessary. >> Same as above :-) Return only the SW, and set return_len to 2. >> >> The only "intelligent" thing to do in your driver is a loop to wait for the >> card when it replies NULL procedure bytes (0x60) to request more time for >> its processing. If you get something else, the exchange step completes. > > > In your opinion, the driver should not issue any "GET REPONSE" command by it > self? Even for case4, where a "GET RESPONSE" is required to get all response, > the driver also wait for upper layer to issue the "GET RESPONSE" command? > And the re-issuing of original command is also done by upper layer?
Yes, the simplest example is javax.smartcardio. The library source is available. > > I wonder is it the implementation in most drivers. And did you see any > implementation like this way? pcsclite. and windows winscard. And CCID does not autosend get response either. See the function named CmdXfrBlockCHAR_T0 in the file: http://svn.debian.org/viewsvn/pcsclite/trunk/Drivers/ccid/src/commands.c?revision=5013&view=markup > > And the application( or support library) should be aware of the protocol used > in the driver, and to handle differently for T=0 and T=1? This can be very simple. If you get 61XX, send a get response, and return the get response reply to the user. If you get something else, and you have data, the card was contactless or T=1, so no get response is needed. > > It is so weird to let the dependency exist from bottom to top. totally agree with you. That's why T1 was invented, and ISO14443 is based on T=1 :-) > > > Hi Drasko, > Driver should always prepare to go back and forth for T=0 protocol. Assume > case3, you send a command, and the card alway feed you with a PB as "~INS", > then you must send a BYTE, get a PB, and again send BYTE, get a PB, over and > over till all command sent to card and then get SW1, SW2. In my mental model, this situation must be handled in the driver, because ~INS is a procedure byte, not a SW for the user. You quit the driver when the procedure byte turns out to be SW1 (return SW2) or INS (return data bytes) Also have a look at CmdXfrBlockCHAR_T0 in the previously mentionned file. Regars Sebastien _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
