Counter Question

frank freedman

I am trying to create a way of syncronizing timing pulses across multiple cogs. The desired resolution would be to have a chip select enable the counter to count a certain number of positive edge of pulses and then return to the inactive state, simultaneously stopping the clock at the same time. Maybe I am missing something in the prop counter ckt, but the closest I find is setting the clock out APIN and using dira reset to input to stop the clock pulse to the chip. (desire to be disable in low state) This will be applied to three MC3201 ADCs used for acquisition of 256 samples into three cogs in parallel. Need to spend more time with AN0001 I guess.

Frank

I have downloaded the SPI from the OBEX, but I am hoping to find a way to do this using the counter to remove the load of timing generation from the cog

kuroneko

frank freedman wrote: »

I am trying to create a way of syncronizing timing pulses across multiple cogs. The desired resolution would be to have a chip select enable the counter to count a certain number of positive edge of pulses and then return to the inactive state, simultaneously stopping the clock at the same time.

So chip select is active low and the clock should be low while disabled (what would speak against high)?

frank freedman

kuroneko wrote: »

So chip select is active low and the clock should be low while disabled (what would speak against high)?

None against idle high now that I have a better idea of what I am working with. I found a good doc on spi. Seems the key may be in the statement that data changes or stays stable on opposite edges. Was not so clear on when the data out could be sampled.

Still want to off load the timing though to the cog 0 counters.

Thanks Kuroneko,
Frank

tdlivings

Frank
You can start and stop the counter by setting frqa or frqb to zero to stop and one to count .
In regards to each A/D with it's own cog, I would have each cog's code watch for a state change on
a pin. The pin would be driven by your sample clock . All cogs see all pins, so they can all watch the
same pin, using a PASM waitpeq and waitpne sequence of instructions.
What I do not know is the latency of three cog's watching the same pin do they see the pin state change
at the same time and if not by how much. If it is in the 100 ns range it may not matter
.
Kuroneko is the master expert on those kind of things


Ever since you posted your curve tracer project post I have been thinking about this and will share what
I have over on that post in the sprite of sharing idea's on implementation and not hijacking your project
progress post. Maybe you would rather try it your way first then see how others did it. Many ways to skin the
cat and none of the ways are all right or all wrong. I myself like to work thru something then look at OBEX code to see what others did.

Tom

tdlivings

Frank
Here is an experiment I tried syncing three cogs to a system counter value.
Basiclly you have all three cogs wait for a system counter (cnt) value that is far enough
out in time that all three cogs are thru initializing and can grab the same cnt value and do
there thing.
I am toggling a seperate pin in each instance of the cog.
Note the time horiz time scale is in nano sec on some pics and scope2 pic is a single
shot of it taking off on a download showing first output from each cog

By the way this is not what I was talking about in my other post about waiting for
a pin to change state . This is syncing cogs to a counter value


I was going to try Phil Pilgrum's way of using

kuroneko

@frank: I had a look at the data sheet and you're not going to get more than 1.6MHz anyway out of this ADC. This means that you could still clock the device manually without involving a counter (period covers 50 cycles @80MHz). If you insist on counter usage then that's OK as well. I'd go for a master cog which controls the clock (counter or not) and reads stuff. The other two just latch onto the relevant clock edge and read stuff.

frank freedman

Kuroneko,
Thanks for the mention of the clock idle high, looks like it will be easier to implement with the OR function of the prop chip. reviewing the data sheet, and the chip tops out about 100ksps. Not the fastest, but Nyquist and friends don't really apply here as my project currently will require about 62ksps. The initial testing of the acquisition circuit may be just feed in a sine wave and have the prop dump it back out on unused pins through an R2R network. Be interesting to see what sort of phase shift the processing chain will add. Opportunity for more fun with some topics from the Caxton Foster book on real time programming. Especially the sections on signal processing.

Currently it will still be one master cog and 3 slave cog state machines as (preference) it remains modular. Also it simplifies the memory allocation and handling. Need another state machine, add another cog. At the moment, the unit uses hub ram for storage, but this may change if I go to a faster ADC and higher acquisition resolution (512 points packed 2/long)or if hub sync causes timing issues.

Tom,

Pardon my the drooling on the screen. My current scope is an ebay Tektronix 2247A that was/is in mint condition. I have never been a fan of DSOs especially for video work, but those agilent pictures could almost get me to think twice.

Sorry I did not get to answer the first post ahead of your second. The day job needed my attention on an aging cath-lab. I had planned on using the waitpeq/ne, just need to experiment (read learn) them and figure out how to use them as a sort of software one-shot controlling the cog set up as a state machine which will return to armed post acquisition. The waitcnt has some interesting posibilities for future use. The Vce supply is a fullwave rectified sinewave from a transformer. Because, I can not get APS/PGE/ConEd/NYMO/TEPCO/APL/RWE/MOESK (or any others) to agree to sync to my prop kit, the acquisition must be triggered from a zero crossing detector to start the acquisition running. Perhaps when I drop the AC and go with a sawtooth amp (100V@10A future for big stuff), it might be the time to use waintcnt for pre-acquisition setup. Need to enhance my analog design capabilities first.


As to highjacking the project, can't do it. It is for me a learning project in preparation for a couple of medical device projects what will definitely benefit from the some specific prop features. Seeing more attempts at this project would actually be the highest possible complement for this idea. Perhaps among us we could come up with some really useful tools that the guys over on say, DIY audio would like to build for themselves. Its one thing to read the best in-house material down to the worst TAB quality book published, but nothing cements the knowledge like making a thing work and understanding how and why. Just do it! Then share it! Ideas and help seem to be the source of the atta boys/girls points(stars?). That may be why this community seems to hang together as well as it does without sinking into perpetual flame wars seen on other sites.

Getting a bit verbose on this reply, perhaps I should learn to blog /on this project?

Frank

tdlivings

Frank
Zero crossing detector is what I was thinking of to get things in sync. Actually two one on each side of
the center tapped low voltage transformer. To get a sync trigger at the beginning of each 120 Hz recitified
signal you need to detect both phases of the transformer output. At least that is what I am thinking now but
keep asking myself is there a way to use only one.
I will post what I am thinking tomorrow. I will make a drawing it is 12:30 am in Michigan getting late here.

Also I was looking at putting 320 samples in each cycle. At 120 Hz full wave that is 320 points in 8.333ms
or a sample rate of 38.4 KHZ. I think your 62 KHz value means your thinking of only doing points up to the peak of the wave and not taking points on the way up and again on the way down but I took a look at a transformer output and it was not nice and perfect sine looking at the peak so it would be hard to detect it consistantly.

A comment on nyquist we are digitizing a 120Hz signal at 38 or 62 KHZ so an anti alias filter is a good idea
for noise and stray rf pickup an to slow the edges down but we are way way below the nyquist frequency.