You're welcome. I'm happy if my comments helped you. Regards Sebastien
On Wed, Jul 7, 2010 at 6:18 PM, Drasko DRASKOVIC <[email protected] > wrote: > On Wed, Jul 7, 2010 at 6:05 PM, Sébastien Lorquet <[email protected]> > wrote: > > > > > > 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. > > Great, I will do it this way. > > Sebastien, > thank you very much for your help. > > 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
