General I/O Q&A
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!
Comments
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.
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.
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.
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.
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.
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.