On Wed, Jul 7, 2010 at 4:27 PM, Drasko DRASKOVIC <[email protected] > wrote:
> > To make things as perfect as possible, my opinion is to change your > driver > > abstraction model to an upper level, and manage T=0 in a single "blob", > > which can be seen as a layer by itself, but does not follow the OSI > > concepts. > > What would that say in practice ? To do TX, and after RX processing > and possible TX-resend (upon reception of 61 XX) in the driver code ? > Or rather do give back 61 XX to transport layer function to process it > and re-send command ? > The last one. a call to the driver is a single sequence of data sending / data return. Return only 61XX if necessary. > > > typical drivers provide an API like this one: > > error_code_t exchange(unsigned char *command, int command_len /*known*/, > > unsigned char *response, int *response_len /*discovered*/ ); > > Same as the question above, would we find here after the function data > of length 2 (61 XX) or data of length Luicc ? I.e. does exchange() > function returns upon reception of 61 XX and put response_len to 2, or > continues conversation until reception of Luicc bytes of data and puts > response_len to Luicc ? > Same as above :-) Return only the SW, and set return_len to 2. All the terminals (PCSC or not) that I know work this way. 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. Regards Sebastien > BR, > Drasko > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.drizzle.com/mailman/listinfo/muscle >
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
