Pic16f916 question; External clock on Timer0

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View


Hello all, I need to obtain a timer tick of 18.88 microseconds on a 20
MHZ clocked PIC16F

On the same board I also have a 13.56 clock, but for speed problems I
neet to keep the processor clocked at 20 MHZ

This 13.56 MHZ signal, divided by 256 is exactly the timer tick I want,
so I thought to feed this signal as an external clock for Timer'0
(T0ckl).

On the datasheet though, I've read some warning and limitations about
the use of Timer0 with external clock, I did not clearly understand if
in a case like mine I'm allowed to do it...

who can help please?


Re: Pic16f916 question; External clock on Timer0


Hi,
I see some limitations in relation to synchronization of that external
clock to the internal clock (page 6 of Microchip doc no 31011a.pdf)
But maybe as long as you have a duty cycle of approximately 50% you
might not have a problem.
On the other hand, please explain why your 13.56 (I guess it is MHz) is
so important for you. What is the needed resolution of that clock? Any
other relevant information could be handy in order to help you.
Regards
Klaus

la_panza skrev:
Quoted text here. Click to load it

Re: Pic16f916 question; External clock on Timer0


Klaus (DK) ha scritto:

Hi , thanks for answering

Quoted text here. Click to load it

I'm designing an ISO 15693 vicinity card reader, the unit is composed
by a PIC16F and an analog front-end IC that drives the antenna and
demodulates signals coming from the cards.

The analog front-end IC has its own 13.56 crystal, the electromagnetic
field generated by the antenna supplies power to the cards, but the
13.56 MHZ field is also used as master clock for the card's internal
logic.

All the card timings during data reception and transmission is based on
a 18.88 microsecond time unit, (13.56 MHZ divided by 256). the PIC16F
has the duty of composing data packets, send them with the right
timing, as well as decode response packets coming from the cards.

The PIC has a 20 MHZ quartz, it has other tasks and must be kept quite
fast,
Now, f I plan to use...say... Timer2 to generate the 18.88 Usec. timer
tick, the value to set on Timer2 period register is 94.4; Since it's
not possible to give such a value to a register, I fear that even a
minimum timing error may propagate along the data frame and make the
coding / decoding fail... Ideal solution would be to use the SAME clock
supplied to the cards as a timer clock!

Hope the explanation is clear enough...

Thankyou for interest  ....

Adolfo (Pordenone, IT)




The cards get power by inductively

Quoted text here. Click to load it


Re: Pic16f916 question; External clock on Timer0


Quoted text here. Click to load it
13.56 * 3 / 2 = 20.34

Overclocking the PIC this much should be possible, Substitute a PLL
based clock for the PIC's crystal, locked to 1.5 * the front end clock.
Your timer 2 period register could now be loaded with 96. (I haven't
checked the data sheet, I just scaled your values . . .)


--
Ian Malcolm.   London, ENGLAND.  (NEWSGROUP REPLY PREFERRED)
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk [at]=@, [dash]=- &
We've slightly trimmed the long signature. Click to see the full one.
Re: Pic16f916 question; External clock on Timer0



Ian Malcolm ha scritto:

Quoted text here. Click to load it

the idea si not bad, though I wish I would keep hardware modifications
to minimum (a schematic has been drawn already and a A-sample  PC-B is
being printed)..

As an alternativa I was considering a dirty trick like reloading the
period register with 94 and 95 alternatively at every timer2 service
routine.. This would add just a little "jitter" between an interrupt
and the next one, but would make a long.term period of 94.5, very close
to needed 94.4 theoretical time.

In normal condition, Timer 2 can work without any reload, this is its
nain advantage over the other timers, but in any case I think that
touching PR2 "on the fly" should be legal and bringing no adverse side
effect....  what do you think?

Adolfo Melilli - Pordenone - Italy


Re: Pic16f916 question; External clock on Timer0


I thought ISO cards work on a byte basis with CK + Data. Is this card like
that or something completely different? Even if it's on a byte basis (
rs232) then you can tolerate at least a few% error......

Quoted text here. Click to load it



Re: Pic16f916 question; External clock on Timer0



martin.shoebridge ha scritto:

Quoted text here. Click to load it

Sorry, I don't understand what you mean by "on a byte basis", In the
case I'm dealing with the data are treated in two different ways
depending on their direction...

data from reader to card is serially shifted a COUPLE bit a time, on a
1-of-4 pulse position scheme. this transmission scheme is not
self-clocking, it is asynchronous and relies on the timing accuracy
between transmitter and receiver... even a small error may get bigger
and bigger as the data frame is received, up to the point of mistaking
bit positions.

Data from card to reader is manchester-encoded, a logic 0 is a space
followed by a mark, a logic 1 is a mark followed by a space..that
strategy makes the protocol self-clocking and in this case a timing
accuracy is not so strictly necessary..


Re: Pic16f916 question; External clock on Timer0




la_panza skrev:
Quoted text here. Click to load it
I dont exactly understand what you mean by that.
If data were shifted in eternity you are right - the error will
eventually get too high. BUT there MUST be some sort of
re-synchronisation in an asynchronous world as this is. Usually you
start with some sort of a start bit, then you transmit a number of bits.
you may (usually) end a transmission by sending a stop bit. Then you
re-synchronise by sending another start bit, then data bits and so on.
Quoted text here. Click to load it
I agree on that.
BR
Klaus

Re: Pic16f916 question; External clock on Timer0



Klaus (DK) ha scritto:

Quoted text here. Click to load it

You are right, there is in fact a starting point, but it's at the
begining g of the frame, there is a "start of frame" sequence you can
rely on to trigger your timebase.

after the start of frame sequence, characters  are  sliced into 4
groups of two bits each, LSB first,...  each bit couple is expressed by
positioning a 9.44 usec pulse on one of four possible "phases", the bit
couple lasts 9.44 usec X 4, a pulse on the first quarter means 00, a
pulse on the second quarter means 01 and so on..
.
Apart from the start of frame sequence, all this has no more start
bits, stop bits nor any redundancy or synchronization pattern ,
characters are 8 bit each transmitted on 4 couples of 2 bits, the frame
may be made of many bytes. during which the error may propagate, though
I confess I never made a percentage evaluation of this error...

Quoted text here. Click to load it

Adolfo


Re: Pic16f916 question; External clock on Timer0


How many bytes will you need to handle between re-synch's ?
I still dont get how it works - sorry, but under all circumstances you
need to make an assesment on the error you could get based on a worst
case scenario. Then you should calculate wether the clock in your system
will be able to cope with that timing. If it can then go ahead.
Otherwise think of another apporach.
I guess this is of no help either.
Hope you will get better advice from others.
Good hunting.
Klaus

la_panza skrev:
Quoted text here. Click to load it

Re: Pic16f916 question; External clock on Timer0



Klaus (DK) ha scritto:

Quoted text here. Click to load it

up tp 64 bytes, a byte is 9.44 usec * 4 * 4  = 151.04 usec

Quoted text here. Click to load it

sorry, I wish I could post some text directly from ISO_15693-2 and -3
official documents, but I can't, they are licensed to my workplace
company and are under a non-disclosure agreement..

Quoted text here. Click to load it

I never did it, mainly because I'm lazy :-) if you remember my original
question, i wanted to use the front end IC clock as a timebase just
because it would work for sure, no error, no risk, even not necessary
to make worst-case sstimations..

Quoted text here. Click to load it

This morning I've tried the "dirty trick" of alternating 93 and 94 on
PR2, it works, the cards seem to understand the commands ...  now I can
relax a little and make things work both in theory and in practice..

Quoted text here. Click to load it

remember?  13.56 MHZ to directly clock TMR0 was the other approach I
was considering..

thanks for help!  Bye    

Adolfo


Site Timeline