Pic16f916 question; External clock on Timer0

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?

Reply to
la_panza
Loading thread data ...

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:

Reply to
Klaus (DK)

Klaus (DK) ha scritto:

Hi , thanks for answering

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

Reply to
la_panza

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]=- & 
 Click to see the full signature
Reply to
Ian Malcolm

Ian Malcolm ha scritto:

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

Reply to
la_panza

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

Reply to
martin.shoebridge

martin.shoebridge ha scritto:

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

Reply to
la_panza

la_panza skrev:

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.

I agree on that. BR Klaus

Reply to
Klaus (DK)

Klaus (DK) ha scritto:

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

Adolfo

Reply to
la_panza

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:

Reply to
Klaus (DK)

Klaus (DK) ha scritto:

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

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

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

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

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

thanks for help! Bye

Adolfo

Reply to
la_panza

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.