Generating Clock and CS signals in background

Philldapill

I recently made a PASM driver for an ADC. The object works great, but I think it COULD work better. Many of the instructions that take alot of time are the clock and Chip Select signals. The clock should be a constant on/off signal, and the CS should be low for about 90% of the time, then high 10%, then back to low.

I'm only starting PASM, so forgive my ignorance. Could the counters be used to generate these signals in the background, allowing me to free up some instruction time for the actual code? If so, how would I go about sync'ing up the counters with my instructions? Examples?

Brian Fairchild

A quick pre-first-coffee-of-the-day thought...

Yes, use the counters and then since your CS and CLK signals go to external devices they appear on IO pins which you can read with the INA instruction. So you could use waitpne and waitpeq to sync up the other parts of your code. Or, you could implement something like the system in FullDuplexSerial where you look at the pin state and if it doesn't match your 'do the next bit' criteria you go away and do a bit more housekeeping, coming back at regular intervals to check the pin state.

mynet43

Chip wrote a cool routine for calculating the CTRA and FRQA values to generate any frequency on any pin.

I don't recall where the original code is, but here's a version that I've modified a few times.

I've found it provides very accurate frequencies. At least as accurate as I can measure with my scope.

Jim

rokicki

You should examine the sdspi*.spin routines that come with fsrw; they illustrate using the counters
to generate clocks (but not chip select).

kwinn

I am not sure that there is anything gained by using the counters for this type of I/O. I took a long look at doing something very similar to that a while back and could not see any way of using the counters to do anything beyond automatically clocking the data bits from a serial shift register or spi chip. It did save a few instructions, but the data could not be clocked in much if any faster than it would be in software.

If you had an external circuit that was appreciably faster than the prop it might be worthwhile. It might be possible to use the video circuitry to generate chip select and clock signals, but it would be tricky to synchronize reading or writing data to those signals.

mynet43

I've found these counters very useful when you're connected to an external chip that requires an input clock at a precise frequency. You simply set it and forget it.

A couple of examples are:

1. TI sound codec that needed a 2.8224 MHz signal to achieve a 44.1 KHz sample rate.

2. A camera chip that needs a high frequency input for VGA frame processing.

These would be almost impossible to do with raw code.

Jim

rokicki

For reading SPI, you can reduce per-bit times from four instructions to two using the counters.

For writing SPI, you can reduce per-bit times from (probably) four instructions to one using the counters.

Both of these are, in my view, substantial improvements.

kwinn

mynet43, I agree that a sound codec, camera chip, and even some types of ADC's will benefit from using the counters, but they are a small minority of the chips in use. They would also occupy a narrow region of the performance curve in that they would be too fast for the prop to generate the clock/select signals and read/write the data in software, but slow enough to read/write the data when the clock/select signals are generated by the counters. That is a fairly narrow performance window.

rokicki, I agree that using the counters can reduce the number of instructions per bit, and with tight coding can potentially double the read speed and increase write speed even more compared to doing it all in software. What I question is what is gained if the spi or other chips are not fast enough to take advantage of that speed.

I am in favor of using any and all hardware and software tricks and techniques available to speed things up when there is some benefit from doing so. I am currently looking at building a multichannel pulse height analyzer with a minimum of 10 bits of resolution and a 10MHz sample rate. For that project I will be looking to save every cycle possible and using the counters will definitely be considered.