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? I wonder is it the implementation in most drivers. And did you see any implementation like this way? 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? It is so weird to let the dependency exist from bottom to top. 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. B.R. Wayne
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
