18 May
2012
18 May
'12
12:47 a.m.
Hi list,
A few questions regarding the 7816 driver, while I wait for my SIMtrace
board to arrive:
1) It is stated in the hardware section that the datasheet for the SAM7S
does not specify working as a slave, and this is indeed the case. How did
this slave implementation come about? Trial and error or is this an
officially supported mode?
2) The SAM3S also has no mention of 7816 slave mode, and I noticed v2.0 of
the hardware will be based on this uC. Has this been verified to work?
3) I'm trying to understand why compute_fidi_ratio() returns a
multiplication of fi, di instead of division if di > 8. Didn't see anything
that states this requirement in the SAM7S datasheet (table 31-5).
Thanks!
Eran
18 May
18 May
8:35 a.m.
Hi Eran,
On Fri, May 18, 2012 at 01:47:05AM +0300, Eran Duchan wrote:
1) It is stated in the hardware section that the
datasheet for the SAM7S
does not specify working as a slave, and this is indeed the case. How did
this slave implementation come about? Trial and error or is this an
officially supported mode?
It came about by thinking about 7816-3, carefully studying the sam7s
manual, some extrapolation how the logic in the IP core might work and a
small experiment with an sam7s development board in 2010.
Well, if you look at 7816-3, there is really not that much difference
between a master and a slave on the bit and byte level. The only real
difference is who transmits when, and who generates the clock.
As the Atmel USART can be clock master or slave in the non-7816 modes,
it seemed probable that this is the same for the 7816 mode.
Furthermore, a "passive slave" shall of course not signal any parity
error to the master, as it is up to the real slave to determine that.
The latter can be explicitly configured in the Atmel USART.
2) The SAM3S also has no mention of 7816 slave mode,
and I noticed v2.0 of
the hardware will be based on this uC. Has this been verified to work?
Atmel is known to use the same IP cores in a lot of their chips, and the
sam3s is more or less just the sam7s which replaces the arm7tdmi core
with a cortex-m3. There are some other improvements like more USB
endpoints, but I haven't seen any indication of changes in the USART.
3) I'm trying to understand why
compute_fidi_ratio() returns a
multiplication of fi, di instead of division if di > 8. Didn't see anything
that states this requirement in the SAM7S datasheet (table 31-5).
See Table 7 if ISO 7816-3. Di > 0x8 is "divide by 1/2, 1/4, 1/8, ..."
which is the same as multipliciation by the divisor.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10:38 a.m.
Harald,
Thanks for your detailed answer.
Furthermore, a "passive slave" shall of
course not signal any parity
error to the master, as it is up to the real slave to determine that.
The latter can be explicitly configured in the Atmel USART.
Are you hinting that parity generation will not work when configured
to be a slave (i.e. external clock)? As I gathered from looking at the
code and the schema SIMtrace was designed to also support MitM (though
the code is mostly stubs) which would require such a feature towards
the phone.
Atmel is known to use the same IP cores in a lot of
their chips, and the
sam3s is more or less just the sam7s which replaces the arm7tdmi core
with a cortex-m3. There are some other improvements like more USB
endpoints, but I haven't seen any indication of changes in the USART.
That makes sense. Has the SAM3S version been prototyped yet? Have you
seen this functionality work on the SAM3S USART?
See Table 7 if ISO 7816-3. Di > 0x8 is
"divide by 1/2, 1/4, 1/8, ..."
which is the same as multipliciation by the divisor.
This is rather interesting. I am looking at ISO 7816-3_2006 and there
are no such values (Table 8: Di[x] = RFU, 1, 2, 4, 8, 16, 32, 64, 12,
20, RFU, RFU, RFU, RFU, RFU, RFU). However, this source
(http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-3.aspx)
does show the values you speak of, but starting at Di > 0x9 (as Di[9]
= RFU). Am I looking at something wrong?
Thanks again!
Eran
10:50 a.m.
On Fri, May 18, 2012 at 11:38:07AM +0300, Eran Duchan wrote:
no. They are pin-compatible, so it should be easy to re-work one board
with hot air. The bigger differences are in the software (arm vs.
thumb2, exception vectors, ...). I think zecke had done some work here
in the past, but I'm not sure of the status.
I have a paper version of th original spec from 1989, and there it
clearly is stated.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Harald,
Thanks for your detailed answer.
No. Please read the data sheet. In ISO7816 mode you can explicitly
switch that on or off. I guess they put that in for T=1 support. Also,
it was my mistake, it is not parity that you're switching, but the
explicit nack in the waiting time after a character.
Furthermore, a "passive slave" shall of
course not signal any parity
error to the master, as it is up to the real slave to determine that.
The latter can be explicitly configured in the Atmel USART.
Are you hinting that parity generation will not work when configured
to be a slave (i.e. external clock)? Atmel is known
to use the same IP cores in a lot of their chips, and the
sam3s is more or less just the sam7s which replaces the arm7tdmi core
with a cortex-m3. There are some other improvements like more USB
endpoints, but I haven't seen any indication of changes in the USART.
That makes sense. Has the SAM3S version been prototyped yet? Have you
seen this functionality work on the SAM3S USART? See Table 7 if
ISO 7816-3. Di > 0x8 is "divide by 1/2, 1/4, 1/8, ..."
which is the same as multipliciation by the divisor.
This is rather interesting. I am looking at ISO 7816-3_2006 and there
are no such values (Table 8: Di[x] = RFU, 1, 2, 4, 8, 16, 32, 64, 12,
20, RFU, RFU, RFU, RFU, RFU, RFU).
10:57 a.m.
All is clear :)
Thanks!
Eran
On Fri, May 18, 2012 at 11:50 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
On Fri, May 18, 2012 at 11:38:07AM +0300, Eran Duchan
wrote:
no. They are pin-compatible, so it should be easy to re-work one board
with hot air. The bigger differences are in the software (arm vs.
thumb2, exception vectors, ...). I think zecke had done some work here
in the past, but I'm not sure of the status.
I have a paper version of th original spec from 1989, and there it
clearly is stated.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Harald,
Thanks for your detailed answer.
No. Please read the data sheet. In ISO7816 mode you can explicitly
switch that on or off. I guess they put that in for T=1 support. Also,
it was my mistake, it is not parity that you're switching, but the
explicit nack in the waiting time after a character.
Furthermore, a "passive slave" shall of
course not signal any parity
error to the master, as it is up to the real slave to determine that.
The latter can be explicitly configured in the Atmel USART.
Are you hinting that parity generation will not work when configured
to be a slave (i.e. external clock)? Atmel is
known to use the same IP cores in a lot of their chips, and the
sam3s is more or less just the sam7s which replaces the arm7tdmi core
with a cortex-m3. There are some other improvements like more USB
endpoints, but I haven't seen any indication of changes in the USART.
That makes sense. Has the SAM3S version been prototyped yet? Have you
seen this functionality work on the SAM3S USART? See Table
7 if ISO 7816-3. Di > 0x8 is "divide by 1/2, 1/4, 1/8, ..."
which is the same as multipliciation by the divisor.
This is rather interesting. I am looking at ISO 7816-3_2006 and there
are no such values (Table 8: Di[x] = RFU, 1, 2, 4, 8, 16, 32, 64, 12,
20, RFU, RFU, RFU, RFU, RFU, RFU).
4369
days inactive
4370
days old
4 comments
2 participants
participants (2)
-
Eran Duchan -
Harald Welte