This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.
Eran Duchan pavius at gmail.comAll is clear :) Thanks! Eran On Fri, May 18, 2012 at 11:50 AM, Harald Welte <laforge at gnumonks.org> wrote: > On Fri, May 18, 2012 at 11:38:07AM +0300, Eran Duchan wrote: >> 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)? > > 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. > >> > 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? > > 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. > >> > 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). > > I have a paper version of th original spec from 1989, and there it > clearly is stated. > > Regards, > Harald > -- > - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6)