How fast ???

Ibsen

Since the Propeller has no hardware interupt, how fast can it react to a state change on a pin in software ???
I guess all traditional hardware interupts will have to be written in software now...



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


*.*

Ibsen

" It's nice to be important, but
·· more important to be nice... "

Ryan Clarke

Ibsen,

I believe you are missing the point of the multiple cogs. Consider this- in a 'traditional hardware' setup (as you call it)- an interrupt is only as fast as a pin changing states as well as all of the necessary housekeeping to have the interrupt run/process- (this can vary depending on the hardware you are using)- So it naturally follows that a cog dedicated to a function will be able to react more quickly than an interrupt driven system...

Now all 'traditional hardware interrupts' should not have to be written in software now, if you don't stick to the paradigms imposed by a single processor system to this new, multiprocessor setup. The way to structure/approach your code should evolve to match and take advantage of the hardware you are working on.

Ryan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support

RClarke@Parallax.com

Gadgetman

In assembly language, just use WAITPEQ or WAITPNEQ to let the process wait for something to happen.
Then it'll continue execution within a few clock cycles.

The same commands exist in Spin also, but there it will take a few hundred clock cycles for the program to begin reacting a doing something. (It takes about 200 Assembly instructions to execute one Spin token by the interpreter)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

Ibsen

Remind me how fast is an instruction with COG running at 80MHz ???

So if the COG is dedicated to waiting for a pin to go hign and I'm running a assembler code,

how fast will it start my code ???

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


*.*

Ibsen

" It's nice to be important, but
·· more important to be nice... "

Gadgetman

If you check THIS document you'll find this bit of information:

PDF-file said...

The 'wait' instructions are used to stall the COG until some target condition is met. Once a wait instruction is engaged, the target condition is re-checked every clock cycle. Once the condition is met, the instruction finishes and the next instruction executes. During the wait, COG power consumption is reduced. These instructions are mainly used to align a COG's execution timing with some event.
The first two wait instructions deal with the I/O pins' input states. They wait for some set of pins to either equal, or not equal, some set of states. The S operand is used as a mask to isolate the pins of importance, while the D operand is the value to compare the isolated pins to. These instructions are as follows:

WAITPEQ D,S 'Wait for (INA & S) to equal D
WAITPNE D,S 'Wait for (INA & S) to not equal D

In other words, the program will continue executing on the next clock cycle, and THAT is just as quick as any Hardware interrupt I've seen...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

Ibsen

Cool !!! So you could have one COG act like a hardware interupt monitor ???

How long is a clock cycle at 80MHz ???

I'm getting exited about this...



I would like to build my own Electronic Fuel Injection controller for my motorcycle.

Timing is very critical for TDC (Piston Top dead center), Fuel injector firing duration and timimg, and ignition timing.

This is all coming together for me now...



Thank you.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


*.*

Ibsen

" It's nice to be important, but
·· more important to be nice... "

Gadgetman

That would be 1/80.000.000 Seconds, or 12.5nS.

And that again means that most assembly-language instructions execute in 50nS, and that you can execute up to 20instructions in ONE uS.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

pjv

Hi Ibsen;

My testing reveals that at 80MHz, the "wait instruction" completes in 3 clocks (3*12.5 nSec) after the "proceed event", and the next instruction is started right after the wait instruction is finished. So that is 37.5 nSec after the "wait" is satisfied. Each instruction takes 4*12.5 = 50 nSec.

Cheers,

Peter (pjv)

Post Edited (pjv) : 5/12/2006 8:57:15 PM GMT

Ibsen

WOW !!!!!!!!!!!!!!!!!!!!!!!

That·will provide plenty of acuracy ;-)

Way more that needed with today's Injector and Ignition technology.

The required precition·for a fuel injector is 1-1.5ms



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


*.*

Ibsen

" It's nice to be important, but
·· more important to be nice... "

johnsrobotics

Ibsen,

I am currently working on a similar project (ECM for a BMW), and the Propeller fullfils all of the requirements. This includes fuel injection timing among MANY other timing tasks. This project is going to take me a long time, as parts for BMWs aren't cheap, and I'd like to avoid (worst case) blowing the engine

Good luck with your project!
(Go for it!)

Ibsen

That is cool !!!

Have you seen this: http://www.megasquirt.info/

This is where I'm gettign my ideas and a lot of knowledge from.

It will take me a while as well· ;-)





▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


*.*

Ibsen

" It's nice to be important, but
·· more important to be nice... "

Chris Savage

Ibsen said...(trimmed)
Cool !!! So you could have one COG act like a hardware interupt monitor ???

Well, actually the COG would BE the interrupt routine...Not the interrupt monitor.· On an SX if you interrupt by event, the main code stops while the ISR is handled.· On the Propeller when the event happens it is concurrent with the main task, since that task is never interrupted...Hence no interrupts.· It's not even fair to call it a background task because it is concurrent.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

johnsrobotics

Thanks for that site! Very informative.