spin timing

stef

Hi

Did some projexts with the sx and javeline. Now I'm loking at some to do with the propeller. I have no experiance (jet) with the spin language.
So it could be a stupid question.

I'd like to use te propeller for counting pulses. (Schould be no problem i think). The pulses are +/- 50 µs and are at 2ms interval. Is the prop (1 cog) programed with spin fast enouf to see the pulses on pobably 2 lines to monitor with 2 pin's??
If not I try it with sx. Sx is fast enouf but then the rest· of my program has nothing left to run on. With propeller I have other cog's to run rest of program in.

second question. If 1 cog has calculated something and placed it in a variable. Can another cog retrieve the value and work with that further?

Thiese question are stupid for someone knowing spin and having experiance. Depending on the possabilatys I 'm going further with spin.

Stef from Belgium
·

deSilva

The short answer to all your questions will be "yes" but you will hardly get a short answer from deSilva

(a) Asking for "raw speed" is not a good question to be answered by SPIN... The Propeller is obviously made - as many have already remarked - to be used with SPIN and machine code. A request for "SPIN only" cripples you and the Prop.

(b) A basic SPIN instruction (whatever that may mean) will take 5 to 10 us, so polling two lines for such a glitch will most likely work.... just.

IF lines := INA & constant(|<line1 + |<line2) ....

(c) You can also use the hardware counters with SPIN, which gives you much more headroom for processing. The use of counters is well explained but they are rarely used..

(d) You can extremely easily use two COGs from the same SPIN program, making code very transparent and symmetric - and more than (!) twice as fast, as code for a single line only will be simpler

Post Edited (deSilva) : 10/15/2007 8:18:31 PM GMT

stef

Hi desilva

Thanks for the reaction.

So speed is no problem if using machine code. I'm not used to use that. If staying completly in spin, knowing it is mutch slower, can that also succeed?

stef

Mike Green

To give you some idea of the raw speed:

There is a serial_spin object that implements a half duplex serial channel completely in Spin at speeds over 19.2Kbps.

There is a FullDuplexSerial object that implements a full duplex buffered serial channel in assembly language with a single cog doing both transmit and receive at speeds over 230Kbps.

Some people have reported a half duplex serial assembly language routine that can handle over 1Mbps

It is possible, though complex, to synchronize several cogs together to do higher speed work. For example, there's a VGA driver for a 1600 x 1200 pixel display that uses 6 synchronized cogs to handle the data rates involved.

For simply counting pulses, the special purpose counters should be able to do what you want without the use of assembly language. They can realistically count pulses up to 20MHz and there are two identical counters in each cog.

It is usually easier to use one cog for each pulse stream to be counted since the same program can be used for each cog and the compiler can automatically provide a separate data area for each cog.

Post Edited (Mike Green) : 10/15/2007 8:51:08 PM GMT

Harley

Stef,

As an example, there is ViewPort; a DSO/logic analyzer. It can run at 20 MHz using one cog plus the ViewPort object and capture 50 nsec events on the I/O, or 80 MHz with 4 cogs and VP object.

Of course those cogs are assembly. I'd imagine your 'counting pulses' code would be quite simple.

Just FYI. The Prop is quite fast.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

deSilva

@Stef: Although I gave you the answer in my first posting, here it comes again: It depends on the processing you plan with those "spikes". Having 2ms time looks much (some hundred SPIN instructions), but not if you are processing one signal, and need to watch the other line. So it MIGHT simplify your task to have two or even three COGS:

COG 0: main logic
COG 1: watching line 1
COG 2. watching line 2

As the operation of COGs 1 and 2 is most likely very trivial, this is the reason it can be done by the special hardware counters, where you happen to have two in each COG. This "counter-concept" will break, if you need three lines; but it will be possible to use more COGs...

On the other hand, why do we need the "parallel" COGs in the first place? It is for not loosing any of the small 50 us spikes!

So it might even work out that one "on-line" COG can do it, e.g.

  REPEAT
      watch |= INA & watchedlines

This takes a little bit less than 50 us - so it is a borderline case and I should rather recommend one COG per line.

Most likely will the use of counters be more satisfying, but it needs some learning from your side - as I said they are not such popular...

stef

Hi desilva

Thanks for the explanation.

I'm going to set up a test and learn spin. Seem to me it can be verry educational to have some opinions by this forum.

stef