Robert Adsett wrote:
> galapogos wrote:
> > 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.
> > The thing is, the MCU clock uses a crystal and not an oscillator, so it
> > provides a sine wave rather than a square wave.
>
> So?  The usual divide technique would use a CMOS logic circuit, that
> would result in a square wave not a sine wave.
>
> >I'm not sure if smart
> > cards will play nice with them. I've heard that they require
> > oscillators.
>
> 'All' an oscillator is, is a crystal oscillator with a buffer.  I'm
> just suggesting the buffer include a divide by eight.  You do need to
> make sure you don't overload the oscillator circuit.  If that's all
> your concerned about use an oscillator for the micro and run the divide
> by eight off of it instead.
>
> Robert

So I read up on frequency dividers and apparently I can use 3 DFFs in a
row to do a divide by 8. I tried to find some quad/octal/hex DFF chips
but they all share a common clock, whereas I'll need 3 separate
clocks(DFF1's output into DFF2's clock, and so on). Are there any chips
that allow this, or will I have to use 3 seperate single DFF chips?

galapogos wrote:
> 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.
> The thing is, the MCU clock uses a crystal and not an oscillator, so it
> provides a sine wave rather than a square wave.

So?  The usual divide technique would use a CMOS logic circuit, that
would result in a square wave not a sine wave.

>I'm not sure if smart
> cards will play nice with them. I've heard that they require
> oscillators.

'All' an oscillator is, is a crystal oscillator with a buffer.  I'm
just suggesting the buffer include a divide by eight.  You do need to
make sure you don't overload the oscillator circuit.  If that's all
your concerned about use an oscillator for the micro and run the divide
by eight off of it instead.

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.

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

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:
> 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

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:
>> 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

"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 ;-) 

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?