architecural advice needed

Cncjerry

I am working on a ballistic chronograph and have most of it working but have a few problems to fix.

I have a spin cog that starts up, initializes the serial and lcd displays and is responsible for all user interaction. It runs the buttons (using quickstart board) as well as completes all the calculations. It also starts a timing cog. The timing cog is very net. It waits on a pulse from the first screen, stores the counter, waits for the next screen to pulse, stores the counter and then does the same for the third screen. It is written in assembler. Once the three counts are collected, it writes the values to hub ram and signals the main spin cog that the data is valid. Right now the data is considered valid after it falls thru the first, second and third screen pulses in order as bellow. It give no consideration for false pulses at this point. If I see a pulse light from the analog hardware then I just trip the second and third screens or reset the board.

waitpeq pin1_state,pin1_mask ' wait for sceen 1
mov timescr1,cnt
waitpeq pin2_state,pin2_mask ' wait for screen 2
mov timescr2,cnt
waitpeq pin3_state,pin3_mask ' wait for screen 3
mov timescr3,cnt

wrlong timescr1,addr
wrlong timescr2,addr2
wrlong timescr3,addr3

mov valid,#1
wrlong valid,addr3 'set data as valid


The problem is sometimes a screen won't pulse or will get a false pulse. It is especially bad when the wind is blowing and the sunlight is filtering thru the trees. The screens are very sensitive and though they are UV and daylight filtered the still fire. I don't want the error checking to be in the timing cog.

1) Can I start a third or fourth cog that waits on the same pin as the timing cog? I am using waitpeq as above.

2) If I can waitpeg on the same pin from another cog, can the third or fourth cog write to the same pin to force the timing cog to fall thru the loop? So the timing cog gets a pulse on pin1 and waits for pin2. If pin1 pulses and I don't get a pulse on 2, for instance, in 1/4 second, then I want to pulse pin2 and 3 and the timing cog will then go back to the start of the loop. So I would have to flip the dira bits from input to output on the third or fourth cogs. Same as if I get pin1 and 2 but not 3 in 1/4 second (actually much faster) I would want to pulse pin 3 to rest the loop and write the data invalid.

I'm sure there are other ways to accomplish this but I don't see how I can wait on more than one pin and I don't want to do a loop polling the pin as I need to be within 50ns or 4 clocks to be worthwhile.

So far, the prop chip has brought a new level of timing accuracy to a chronograph for about 1/4th the cost of others on the market. It has the capability to be +/- .02 fps at 700fps which is pretty good.

thanks,

Jerry

Mike Green

You could have a single error checking process running in Spin or PASM in another cog. This would watch to see when the screens fire and monitor the elapsed time. If the screens don't fire within some time limit, this cog can force the state of the I/O pin for the screen to change, thus triggering the WAITPEQ. It can set an extra variable that indicates that the trigger time is a forced one. The screen hardware will have to tolerate a signal coming from the Propeller (for the timeout).

kuroneko

Any cog can wait on any pin. What I wouldn't do is driving a pin from inside the prop (3rd/4th cog) when it's also driven by external h/w. If you have another pin available I'd pair each of these three main inputs with a timeout pin, the latter being controlled by your timeout cog. IOW you don't wait for a single pin becoming high but for a pair of pins leaving the %00 state. Which means that the waitpxx is either ended by a proper pulse input (%10) or a forced timeout (%-1). Would that help?

Cncjerry

Yes, I see the point in #3, i can use waitpne and tie the pins together. That would force the issue if there is a timeout and would only take two more pins since I start the train with pin1 firing and that could be an error but the timeout on pin2 would correct it.

The hardware can take the overdrive as it is only a high impedance op amp with coupling resistors. It wouldn't be the best solution and would use the two pins solution as long as I don't run out of pins again.

Thanks for the quick responses.

Jerry

Cncjerry

So I am trying the "pulse of the input pin" from #2, above first. Contrary to my thinking, it looks like if any cog sets the pin to output, then it is an output. So I need to make it an output to pulse it so the other pin can read it as an input, correct? So it can't be an output and input at the same time, or I am missing something.A. A pin is an input only of no active cog sets it to an output.
B. A pin is an output if any active cog sets it to an output.


Can I write to an input? It seems to trip the waitpeq if I flip the pin to an output and then write to it. So something is going on that I don't follow.

So if I have a cog waiting with waitpeq on say pin1 with a mask of high for that pin, then the second cog changes the dira to make it an output and I write to it, it seems to trip the waitpeq but it is hard to tell since the pulses come pretty fast.

Jerry

Mike Green

The INA registers of all the cogs always sense the actual output state of the I/O pins, whether the I/O pin state is determined by a cog's OUTA and DIRA registers or by some circuitry attached to the I/O pin. Even within the same cog this is true. You can set up one cog to monitor the state of all the I/O pins and transmit this to an attached PC for debugging purposes. You can set up one cog to provide a timeout for other cogs waiting for some I/O pin configuration.

Cncjerry

so do I have to change dira on the monitoring cog to an output or just write to outa?

Cncjerry

so I have it working. I had to pulse the pin, do some other stuff, then drop it. For some reason, and it could be anything, waitpeq on pin1 in cog1 wouldn't slip when cog2 set it unless I waited a few instructions. Could be something else but that is what it seems.

So now my chrono is working as wanted. I am waiting for the microsd card reader/writer so I can unload the pc interface.

Here's the output using an airsoft smg that is supposed to shoot around 315fps. I was able to let it rip:
317.93
318.10
315.14
318.92
318.57
317.50
315.79
315.21
317.90

pretty amazing though it is an expensive air soft gun. The arduino would have been +/- .40fps where the prop is +/- .005fps so the numbers above are accurate to 2 decimal places. The std dev on the above is 1.45. Not bad.

Jerry