Forums

Providing a clock with an MCU

Started by galapogos October 23, 2006
Hi,

I'm trying to communicate with a smart card via iso7816 by emulating
the T=0 protocol using a generic MCU's UART interface. One problem I'm
having is providing a clock to the smart card(~3.5712MHz) w/o the use
of a seperate crystal. Obviously using the GPIO pins would be too slow,
and the UART channel doesn't have a SCLK out. It's also impossible to
get a divisor for the MCU's clock since the UART prescalar(powers of 2)
isn't the same as the smart card's one(372), so they'll never agree on
the baudrate if I were to use the MCU's clock. Is there any other way
to supply the clock other than use a separate crystal?

"galapogos" <goister@gmail.com> wrote in message 
news:1161608353.824513.179180@m7g2000cwm.googlegroups.com...
> Hi, > > I'm trying to communicate with a smart card via iso7816 by emulating > the T=0 protocol using a generic MCU's UART interface. One problem I'm > having is providing a clock to the smart card(~3.5712MHz) w/o the use > of a seperate crystal. Obviously using the GPIO pins would be too > slow, > and the UART channel doesn't have a SCLK out. It's also impossible to > get a divisor for the MCU's clock since the UART prescalar(powers of > 2) > isn't the same as the smart card's one(372), so they'll never agree on > the baudrate if I were to use the MCU's clock. Is there any other way > to supply the clock other than use a separate crystal?
What happens if the smart card is clocked slower? Then GPIO becomes workable.
Tom Lucas wrote:
> "galapogos" <goister@gmail.com> wrote in message > news:1161608353.824513.179180@m7g2000cwm.googlegroups.com... > > Hi, > > > > I'm trying to communicate with a smart card via iso7816 by emulating > > the T=0 protocol using a generic MCU's UART interface. One problem I'm > > having is providing a clock to the smart card(~3.5712MHz) w/o the use > > of a seperate crystal. Obviously using the GPIO pins would be too > > slow, > > and the UART channel doesn't have a SCLK out. It's also impossible to > > get a divisor for the MCU's clock since the UART prescalar(powers of > > 2) > > isn't the same as the smart card's one(372), so they'll never agree on > > the baudrate if I were to use the MCU's clock. Is there any other way > > to supply the clock other than use a separate crystal? > > What happens if the smart card is clocked slower? Then GPIO becomes > workable.
Most smart cards work between 1-5MHz, and I think it would still be difficult to get anything done while trying to provide a 1MHz clock out of GPIO pins, no?
"galapogos" <goister@gmail.com> wrote in message 
news:1161635371.481403.42940@e3g2000cwe.googlegroups.com...
> > Tom Lucas wrote: >> "galapogos" <goister@gmail.com> wrote in message >> news:1161608353.824513.179180@m7g2000cwm.googlegroups.com... >> > Hi, >> > >> > I'm trying to communicate with a smart card via iso7816 by >> > emulating >> > the T=0 protocol using a generic MCU's UART interface. One problem >> > I'm >> > having is providing a clock to the smart card(~3.5712MHz) w/o the >> > use >> > of a seperate crystal. Obviously using the GPIO pins would be too >> > slow, >> > and the UART channel doesn't have a SCLK out. It's also impossible >> > to >> > get a divisor for the MCU's clock since the UART prescalar(powers >> > of >> > 2) >> > isn't the same as the smart card's one(372), so they'll never agree >> > on >> > the baudrate if I were to use the MCU's clock. Is there any other >> > way >> > to supply the clock other than use a separate crystal? >> >> What happens if the smart card is clocked slower? Then GPIO becomes >> workable. > Most smart cards work between 1-5MHz, and I think it would still be > difficult to get anything done while trying to provide a 1MHz clock > out > of GPIO pins, no?
You'd need to read the datasheet but some parts I've worked with (not smart cards admittedly) have no lower clock limit. If you don't mind waiting a bit longer for your data then you can run some parts as slowly as you like. I have an I2C eeprom which I read at very low speeds - mainly due to programming laziness but it gets the job done ;-)
<galapogos> wrote:
>> What happens if the smart card is clocked slower? Then GPIO becomes >> workable. > Most smart cards work between 1-5MHz, and I think it would still be > difficult to get anything done while trying to provide a 1MHz clock out > of GPIO pins, no?
Some MCUs (e.g. AVR) can toggle pins on Timer Overflow automagically without CPU overhead. nicholas
Tom Lucas wrote:
> "galapogos" <goister@gmail.com> wrote in message > news:1161635371.481403.42940@e3g2000cwe.googlegroups.com... > > > > Tom Lucas wrote: > >> "galapogos" <goister@gmail.com> wrote in message > >> news:1161608353.824513.179180@m7g2000cwm.googlegroups.com... > >> > Hi, > >> > > >> > I'm trying to communicate with a smart card via iso7816 by > >> > emulating > >> > the T=0 protocol using a generic MCU's UART interface. One problem > >> > I'm > >> > having is providing a clock to the smart card(~3.5712MHz) w/o the > >> > use > >> > of a seperate crystal. Obviously using the GPIO pins would be too > >> > slow, > >> > and the UART channel doesn't have a SCLK out. It's also impossible > >> > to > >> > get a divisor for the MCU's clock since the UART prescalar(powers > >> > of > >> > 2) > >> > isn't the same as the smart card's one(372), so they'll never agree > >> > on > >> > the baudrate if I were to use the MCU's clock. Is there any other > >> > way > >> > to supply the clock other than use a separate crystal? > >> > >> What happens if the smart card is clocked slower? Then GPIO becomes > >> workable. > > Most smart cards work between 1-5MHz, and I think it would still be > > difficult to get anything done while trying to provide a 1MHz clock > > out > > of GPIO pins, no? > > You'd need to read the datasheet but some parts I've worked with (not > smart cards admittedly) have no lower clock limit. If you don't mind > waiting a bit longer for your data then you can run some parts as slowly > as you like. I have an I2C eeprom which I read at very low speeds - > mainly due to programming laziness but it gets the job done ;-)
Well I guess I can just pay a lil extra for a 3.5712MHz oscillator, except I'm also having trouble finding this value. The closest I've seen are 3.579545MHz and 3.6864MHz. I know these will probably be within tolerance and will probably work just fine, but I'm just wondering if they even make 3.5712MHz oscillators? Also, does anyone know if I must use an oscillator for the CLK input or will a cheaper crystal do? Thanks!
galapogos wrote:
> Hi, > > I'm trying to communicate with a smart card via iso7816 by emulating > the T=0 protocol using a generic MCU's UART interface. One problem I'm > having is providing a clock to the smart card(~3.5712MHz) w/o the use > of a seperate crystal. Obviously using the GPIO pins would be too slow, > and the UART channel doesn't have a SCLK out. It's also impossible to > get a divisor for the MCU's clock since the UART prescalar(powers of 2) > isn't the same as the smart card's one(372), so they'll never agree on > the baudrate if I were to use the MCU's clock. Is there any other way > to supply the clock other than use a separate crystal? >
The usual approach is to have an inverter 74HC04 or so at the mcu crystal driver port, sometimes named XTAL2. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
Rene Tschaggelar wrote:
> galapogos wrote: > > Hi, > > > > I'm trying to communicate with a smart card via iso7816 by emulating > > the T=0 protocol using a generic MCU's UART interface. One problem I'm > > having is providing a clock to the smart card(~3.5712MHz) w/o the use > > of a seperate crystal. Obviously using the GPIO pins would be too slow, > > and the UART channel doesn't have a SCLK out. It's also impossible to > > get a divisor for the MCU's clock since the UART prescalar(powers of 2) > > isn't the same as the smart card's one(372), so they'll never agree on > > the baudrate if I were to use the MCU's clock. Is there any other way > > to supply the clock other than use a separate crystal? > > > > The usual approach is to have an inverter 74HC04 or > so at the mcu crystal driver port, sometimes named > XTAL2. > > Rene > -- > Ing.Buero R.Tschaggelar - http://www.ibrtses.com > & commercial newsgroups - http://www.talkto.net
Hmm, how exactly does that work? My MCU has a 27MHz crystal.
galapogos wrote:
> Rene Tschaggelar wrote: > > The usual approach is to have an inverter 74HC04 or > > so at the mcu crystal driver port, sometimes named > > XTAL2. > > Hmm, how exactly does that work? My MCU has a 27MHz crystal.
If you can change one of those a bit you could use a simple divide by eight. Robert
Robert Adsett wrote:
> galapogos wrote: > > Rene Tschaggelar wrote: > > > The usual approach is to have an inverter 74HC04 or > > > so at the mcu crystal driver port, sometimes named > > > XTAL2. > > > > Hmm, how exactly does that work? My MCU has a 27MHz crystal. > > If you can change one of those a bit you could use a simple divide by > eight. > > Robert
The thing is, the MCU clock uses a crystal and not an oscillator, so it provides a sine wave rather than a square wave. I'm not sure if smart cards will play nice with them. I've heard that they require oscillators.