General I/O Q&A

bambino

If a cog is running an SPI object on a set of pins, can another cog read those pin states, and if so is there any latency? I am pretty sure I read in the manual they can, but was just wanting to know if doing so was giving me bogis readings!

rokicki

Yes they can read the pins. There's only a very very tiny amount of latency. Most of the latency
is just the instruction pipeline itself and not the actual pin writing or reading. (That is, if one cog
modifies a pin, it does so at the end of the four-cycle instruction pipeline; another cog reading
that pin can respond to it only with an instruction after that.)

If you are writing SPI at "normal" rates (that is, 400Kbit or 1MHz or something) this latency is
not normally a problem.

Mike Green

Yes, another cog can read any pin state. The latency should be just the propagation time of the signals through the gates on the chip.

bambino

Thanks Mike, Rokicki

I am looking to use the prop in another project I recently finished useing a dsp engine. According to your respones I don't see a problem with the prop doing the job.

Basically it would read an adc using an·SPI object @ 2Mhz and store the readings to an FRAM using another SPI object. I didn't think there would be a chance of the second object keeping up if hub ram was used to pass the readings, but if the second object can get it's data directly from the pins, then it could do it no sweat.

bambino

Just to be sure,

Is it possible to load a hub ram array with data streaming from an spi @ 2Mhz clock rate. If working to that end was possible then the FRAM footprint could be avoided alltogether.

Mike Green

Assuming 8 bits per byte, that's 250K bytes per second. Worst case, the HUB takes 21 clocks for an access. That's still 4Mb per second. If you unroll the accesses and transfer a long word at a time, that's even better. It's possible to synchronize the cog to the hub if you're careful about instruction timing to avoid the worst case hub timing. Keep in mind that the VGA drivers output data at a much higher rate than what you need.

bambino

Thanks again Mike,

Maybe by the time I get it built I will fully understand Beau's SPI object.

I have already learned that it doesn't matter how much assembly experience I've had the prop Assembly is a new critter.

I am going to consider the cost for a bit, but I think it is doable.

Mike Green

Keep in mind that Beau's SPI object is intended for general purpose use. It has to accomodate different clock polarities, different bit order, and different clock edges for data validity. It will not be as efficient as a tightly coded, single purpose routine.

rokicki

How many samples are you trying to capture? For this I'd definitely recommend using hub memory as a buffer rather than
trying to get all the timing perfect so you can capture and write to the FRAM within a small set of samples. If you use
RDLONG/WRLONG to hub memory you can get pretty good performance. This will also simplify the design, which is a
win all its own.

Note that for high-speed SPI you can have a counter generate the clock transitions, so the instructions in your loop only
need to manage the data bitbanging itself. The inner loop of my high-speed SD reading routine ends up using two instructions
or eight cycles per bit, so I'm running the SD/SPI clock at 10MHz. (This is just the inner loop; I have to start and stop the clock
to set up for the next chunk of data, so I don't get 1.25Bytes/second.) I do 32 bits at a time; the inner loop itself works out
to about 70 instructions for those 32 bits, so the WRLONG to transfer it to hub memory does not introduce much overhead.

bambino

Indeed,Mike

But as a reference, his is the standard I would like to measure mine with. It will take me a bit of study to get all that down before I can write a dedicated routine for my app. However, knowing the potential is there means I can have a protobuilt before hand without fully wasting my time.

Rokicki,

I'll be taking in a 12 bit readings, looking for a trigger, then recording 2k samples into a hub ram buffer,· cook the raw data into G measurements then ship them out to a PC,PDa,etc.