Hi,<div><br></div><div>congrats.</div><div><br></div><div>Does the chip manages T=0 or T=1 by itself or do you have to implement it in software?</div><div><br></div><div>Indeed APDU are always exchanged. If the card doesn't answer, it's an error condition. it should be reported by an error status return value. But the complete exchange can be long, a card may send "time extension requests".</div>

<div><br></div><div>The reset procedure requires a dedicated API.</div><div><br></div><div>What about PPS, ie line speed negociation? This feature is described in ISO7816-3, and also in TS 11.11 chapter 5.8.2.<br><br></div>

<div>Your driver need 4 functions:</div><div>-init driver</div><div>-stop driver</div><div>-reset card and return ATR</div><div>-exchange APDU</div><div>and, maybe</div><div>-suspend and resume, which can stop the clock.</div>

<div><br></div><div>I think official sim cards can be put in sleep state, that the clock can be stopped, and this sort of energy saving stuff. I don't know a lot about this, and we don't need this in a first version.</div>

<div><br></div><div>----- Update status for the on-card project: -----</div><div><br></div><div>Reminder : I'm using javacard 2.x.y</div><div><br></div><div>I'm still working on the file system implementation, I want it sufficiently versatile for others projects too, so it's a bit long, but already working. I have routines to create files and directories, support binary files, record files and directories. I still need to create write() and read() routines, but they are quite trivial.</div>

<div>I'm spending time on the file selection, even if the SIM spec supports only a few modes.</div><div><br></div><div>The first goal is to have a basic applet that's the most ISO7816-4 compatible, then a sim specific version. The functionalities are equivalent , but the apdu formats are a bit different.</div>

<div><br></div><div>The final goal is to have the ability to create any file structure (GSM or not) holding any possible data, without neglecting security (of files, not gsm algs ;) ). </div><div><br></div><div>Speaking of this, the COMP128 alg is already ported to javacard thanks to C code available on the web. If someone has test vectors (IE encryption results verified by someone else), I'll be happy to try them.</div>

<div><br></div><div>I still have a small doubt for high-update rate files. What is an high update rate? Can this really wear a card's eeprom? I may have to create a specific file type to implement wear levelling, using a log/cyclic structure. I don't know the urgency level of this feature.</div>

<div><br></div><div>Regards</div><div>Sebastien</div><div><br><div class="gmail_quote">On Tue, Mar 9, 2010 at 3:12 PM, dexter <span dir="ltr"><<a href="mailto:zero-kelvin@gmx.de">zero-kelvin@gmx.de</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi folks.<br>
<br>
I have now getting interrupts and i am sending the first little APDUs to the card. I think i will have something that basicly works soon. But up to now i think it will be impossible to save processing time during the transmission - wait phases without having semaphores (or something semilar that can be used to wait for an event without wasting processing time in a while loop.) However - this only makes sense with a multitasking os which we actually do not have ;-)<br>


<br>
The driver will get a function like sim_card_transceive(*message, *response) or so on because a transaction with the card will never be receive or send only. You always send something to the card and you always get something back.<br>


<br>
The response and answer apdu structures will be the same as in XCOS and i think i can reuse a lot of the good old XCOS header files that contain basic constants, returncodes ect...<br>
<br>
Thanks a lot to roh who showed me how i can register an interrupt.<br>
<br>
regards.<br>
Philipp<br>
<br>
<br>
</blockquote></div><br></div>