Closed 0xDRRB closed 7 months ago
Thanks for the contribution @Baldanos could you do a review of those improvements / modifications ?
Thanks for the contribution !
I really like the read with timeout idea and it could be applied to all modes by changing the read()
function prototype in all modes.
In that case, the timeout would be part of the main mode_config_proto_t
structure and other changes. This would require a dedicated PR IMO.
I would suggest to change this PR by only including 0d0862aeb373b447bf8ddba88dfbe89592433c0a and d9a7097fa3ceb320e6a59c1f5ba9280fc6406e96 so it can be merged quickly, and I'll open an issue regarding the read with timeout feature for all modes.
Edit: #164 has been opened
0d0862a is linked to 56989e0. So you mean d9a7097 alone, right ?
ok. i removed 0d0862a and 56989e0 for PR and added 9826b18554b91d28d5369964d75c9998846e6a39 (for SMARTCARD_DEFAULT_SPEED
).
I've moved the changes about timeout to a SCtimeout branch.
Hi,
Here's a patch adding a command to receive a smartcard message with a timeout. With the existing code, a successful read can only be achieved by specifying the exact number of characters (or less). This works:
But not this:
Of course, ATR is just an example, we don't always know the size of the data returned by the card.. So I added a new
tread
(timed read) command and atimeout
parameter. And now we can do this:Here, after the ATR, I selected the application on the smartcard (NXP J2A081, T=1 protocol) and used an APDU for a counter reading.
I have also configured a pull-up resistor on PA7 so that the normally closed contactor on the card reader opens and
query
displaysCD=1
when the card is present.Finally, the default communication speed should be 9408 bps because (1/((1/3500000)*372)). 9600 bps is a rounding-off that works but the ETU is normally 106µs with a 3.5 MHz clock.
Perhaps timeout read could be interesting for other buses too.