Andreas Schwier wrote:
I say flush the protocol sections of ISO-7816 down the toilet and
come up with a protocol that works for the 21st Century.
like what: TCP/IP ?
No, that's way too much overhead.
Don't be unfair, these protocols need to be implemented in devices
> with quite limited computing capabilities.
Sure, but have you ever actually studied T=0 and, worse, T=1 specs
and tried to figure out just what kind of sense they make? There is
so much overhead in there, especially in T=1, for what is essentially
a very simple communication channel going over a few mm of wire or
PCB trace. It's like the T=1 architects (or consortium) wanted to
show the world how much crap they could pack into a protocol, and
had no thought about what actually needs to happen between the CPU
on the card and the CPU in the reader.
> They have to be robust and simple to implement.
I'll grant you that they have to be simple to implement, however
"robust" has been taken to mean all the layers in T=1 that just
make it seem like it would be a great protocol if your card was
in New York and your reader was in Munich. It's is way too much
overhead and complexity for how cards are really used.
If you think, that T=1 is to complex, I suggest to take a look
> at our T=1 implementation done for the ECO5000 card reader. In
> just 700 lines of source it implements a reliable protocol with
> error correction, buffer size negotiation, chaining, timeout
> handling and clean transmission abortion.
That's great, I'm glad that you could encapsulate all of T=1 in
700 lines of code. I'm assuming that your complete protocol stack
is in those 700 lines of code, and your interface to the card is
just a basically dumb UART-type device, not a microcontroller that
is running the actual T=0/T=1 stack?
> Please show me a simpler protocol that does all this.
Uh, well, you can start with a rational physical interface protocol
rather than the crazy thing that ISO-7816 mandates where you have
all these various bit timing/polarity/ordering/guard time contortions,
then you can put a very simple command/response packet protocol on
top of that, and perhaps even allow the card to send data to the
reader asynchronously (i.e.. unsolicited rather than requiring the
reader to poll the card all the time). What is the benefit of
things like error correction on what is basically a very slow speed
serial link when you could save all that error correction code by
just telling the card (or having the card tell the reader) to resend
the corrupted packet? What does anyone gain by buffer size negotiation?
What is there to negotiate? The card tells the reader what the max
packet size it can deal with is, and that's what the reader uses.
What does chaining give you? How is that different than just using
a larger packet, or defining the protocol to allow fragmented packets?
I have always thought that T=0 and especially T=1 took what should
have been a simple problem - moving a few bytes between the reader
and card and back - and made it into this overly complex octopus
that serves only to keep reader firmware writers employed, and keeps
cards from one vendor from reliably working with readers from another
vendor.
mike
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
