On Tue, Jun 22, 2010 at 11:41 AM, Ludovic Rousseau <[email protected]> wrote: > 2010/6/22 Drasko DRASKOVIC <[email protected]>: >> Hi Ludovic, > > Hello, > >> I would like to kindly ask you for a few clarifications on this : >> 1) Which protocol is used then for communication with this card >> (looking at presented ATR) ? T=0 ? > > Used by who? By SC controller embedded as a peripheral in ARM based SoC. It has (physically) to talk with the SIM card and provide TX/RX services to higher layers.
> pcsc-lite uses T=0 by default unless the card declares (in the ATR) it > supports T=1. However, protocol fncs that turn on my device could choose T1 also. > >> 2) If I got it well, you suggest ignoring bit TD(2), and processing >> all other (i.e. taking configuration parameters from them, configuring >> controller, and acting like we use T=0 protocol) ? > > Who is processing the ATR? My device driver for my embedded controller. It has to parse ATR in order to re-configure controller (by writing correct values in the configuration registers) for further TX/RX. > >> 3) For my curiosity, do you have any idea why is this T=15 appearing ? > > No. > >> 4) Should we always quietly ignore any other TDi character apart from >> one that gives us T=0 or T=1 ? > > It depends on what you want to do. I want to re-configure my controller with parameters received from ATR (communication clock speed, baud settings, etc...) and also use them to keep internal status which I could pass to higher protocol layers (like - class or protocols that cart is supporting, which it reported in ATR). > >> 5) Having all this in mind, can I conclude at this moment that this >> ATR is correct ? > > It looks like it is correct. > Ok, thanks. It was this T=15 that was confusing me. I thought that card imposes communication in some proprietary protocol, but now I think that it should report all the protocols that it supports, and that we could choose which protocol among these we will use for further communication. > Why all these question? > Why do you want to interpret the ATR yourself? What are you doing with the > card? It is not PC platform I am working on, so I do not have elementary baremetal driver to talk to my SIM card. I have to configure my controller which will initiate 1Mhz clock on the SIM card, which will send back ATR, and my controller will collect it in RX FIFO. My driver has further to parse ATR and re-configure controller parameters (like baud speed, direction in which chars are arriving, etc...) in order so that it can talk to the SIM card, but also to be able to pass the info to the higher protocol layers (like - is card alive ? Whcih protocol does it support ? Which class we use ? Etc...) > > Are you using the PC/SC API or something else? No. I am not using PC not Linux at all. It is a baremetal driver. BR, Drasko _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
