Hi Sebastien, It seems I have to wait for a week or so till the crystal arrives. Though I'm also sure one can get advantage on the hardware usart to get things done and it's the way to go.
However, been testing this "by hand" now that I had some spare time at 1Mhz, with no success so far (I've got the impression I won't have it either when the crystal arrives and I setup the hardware accordingly, because of the problem here being some other that I can't see). What I'm doing now, with a 20Mhz clock on the chip, instead of the original 18Mhz one: * I setup the card's clock line to toggle each 10 cycles, hence giving me a full-swing 1Mhz signal on the output pin, though I don't yet let it toggle. * I activate the contacts appropiately, including the card's clock line. * Just after I activate the contacts, no interrupts or whatsoever, I just fall into a loop where I sample 80 bits on the i/o line each +/- 372 uS (have also tried with more and less, though this time the card actually sends bytes as expected, each +/- 372uS). I keep only getting the TS byte. In order to check that I'm not loosing successive bytes, after the first loop and a delay (that I set to different values across different tests, up to the maximum o 2688 etus in this case) I fall into another loop where I read another 80 bits. The voltages on the pins when the card is in operation are as follows (in respect to card's GND): * VCC: 4,96 * RST: 4,70 * CLK: 2,53 (this is actually my multimeter averaging over the 1Mhz signal I guess. The signal is comming directly from the chip, and so measured against chip's gnd) * IO: 4,93 Any clues? Regards, On 7/8/10, Sébastien Lorquet <[email protected]> wrote: >> >> Yes, that's exactly what I tried today. One can output a signal on >> certain pins by hardware, without it generatig a software interrupt, >> but I didn't have any success yet, same results. > > Only rare CPUs allows that mode, one of them is the PIC 18F2620. > >> >> I think the problem lies on the output signal and the interrupt (the >> one which samples the i/o line not being in synch). >> >> Hence why the need for a clock, one setups usart and recieves just >> what the card sends (the transciever does handle start and stop bits, >> etc). >> >> Not sure yet how to synch with the external clock with usart either, > > No sync is needed. Just a speed relationship. The USART will detect > the start bit and sync with that provided the baud rate is OK. > >> but I'm pretty sure that by going the usart way, the stop bits needed >> when one wants the card to repeat las byte are not going to be easily >> accessible, but we'll see. > > I'm definitely sure you can use the usart. It's half duplex, so you > just have to short Tx and Rx and disable receiver when transmitting > (and that may not be needed). > > The fundamental part is to set the correct baud rate. > > The USART bit rate must be 1/372 the frequency present on the card > "clock" pin. Forget about PPS until it works at basic speed. > > If you can use the same clock frequency for the usart and the clock > output, you're done. Just set the baud rate timer to 372 and exchange > bytes. If you know that the input to the baud rate generator is a > fraction of the xtal clock (because of a prescaler, for example), then > use the XTALOUT signal from your cpu to clock the card and compute the > proper baud rate generator parameters so that the usart bit rate is > 1/372 the XTAL clock :) > > Then remember cards can not use a very high clock: 3-5 MHz will be ok. > This will also be you CPU's clock. > > Also, I don't know your microcontroller, but some of them can use an > external clock to generate baud rates. > > Sebastien > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.drizzle.com/mailman/listinfo/muscle > _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
