2 questions

Lee Marshall

i was wondering:
will the prop-2 have interrupt capability? will other cogs able to interrupt a cogs execution, and maybe force the cog to go to a certain vector?
i know the idea of 8 processors is supposed to eliminate the need, but it would be handy if one were designing a real multi-tasking OS for the prop.

what about undocumented instructions or secret pin functions, are there any?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I hear and I forget. I see and I remember. I do and I understand
-Confucius

Paul Sr.

We don' t need no stinkin' interrupts!!!!

Mike Green

The Prop-2 will not have interrupt capability. The whole idea of adding more cogs is, among other things, to avoid the need to assign more than one task to a cog. One of the major advantages to the Propeller's design philosophy is that other processors cannot affect the timing of one of the processors. You simply do not need a multitasking OS for the Propeller. The notion of an interruptless multitasking system is not new. Niklaus Wirth, who developed Pascal, Modula, and Oberon, wrote extensively on the subject years ago and implemented and published several multitasking systems in high-level languages that, although they used the underlying hardware interrupts, translated them into interruptless multitasking primitives at a very low level in the OS kernel.

I've written several operating systems over the years that did the same sort of thing since the hardware required the use of interrupts. One was for the IBM System 360/370 and the other was for the Z-80. In both cases, there was a small low-level kernel that provided the same functionality of the COGNEW, COGSTOP, WAITxxx, and LOCKxxx instructions of the Propeller. Other kernel functions had to do with I/O operations and would not be necessary on the Propeller.

There are no intentionally undocumented instructions or pin functions in any of Parallax's microcontroller products. The only thing that has not been documented is the Stamp's byte code instructions and interpreter and, until recently, the Propeller's Spin byte code instructions and interpreter which has now been publicly released along with the source code of the Spin interpreter.

Post Edited (Mike Green) : 6/10/2008 6:05:19 PM GMT

Phil Pilgrim (PhiPi)

Stop and think for a moment what interrupts and multitasking OSes accomplish on single-processor controllers: they make the controller behave as if it had multiple processors. In other words, they're a dodge designed to overcome the shortcomings of a single processor. With the Propeller, one doesn't need such a subterfuge. There's no need to imitate multiple processors when you have the real thing!

-Phil

Oldbitcollector (Jeff)

Yes, but wouldn't interrupts allow us to push more tasks out of the eight cogs
we have? Instead of using a single cog per input device, we could use a single
cog for all of them, using interrupts to switch from item to item.

I know.. heresy...

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange

Timmoore

Theres nothing to stop you running multiple tasks inside 1 cog its just more complex coding [noparse]:)[/noparse]. For example fullduplexserial is really 2 tasks, 1 looking after the tx pin and 1 looking after the rx pin. When 1 task is idle is runs the other. Theres nothing to stop you using the same approach, you 'just' have to account for the time it takes for each task and make sure you dont stay with 1 task too long. For example, there is enough time in fullduplexserial to look after multiple serial ports if you can run them slower, e.g. I look after a 115200 and a 38400 serial port in 1 cog

Phil Pilgrim (PhiPi)

The WAITPNE instruction allows you to monitor multiple inputs for a change in state. You can then vector, based on which monitored input changed, thus emulating multiple interrupts in a single cog. This works for level-triggered interrupts, where the interrupting device resets the pin upon being serviced. Edge-triggered interrupts are a little trickier, since the Propeller doesn't have edge capture on its input pins, and short pulses could be missed if the cog spends too much time service another "interrupt".

-Phil

Mike Green

Remember that the Prop II will have 16 cogs, not 8 and they'll be faster

Chuck Rice

Seems to me you (anyone) COULD (can) set up a cog as an interrupt processor right now. Just define some of your pins as interrupt pins, the assign a cog to WAITPEQ. When the pin changes, the interrupt object wakes up. It does not have to save its state as the other cogs are still running. If it wants to stop the other cogs, It could lock a spinlock. The other cogs would have to check that lock and go in to a spin wait till the interrupt cog said to go. This is just one example. I am not sure why you would want to, but that is the beauty of the Propeller design. Instead of actual hardware microcode to do UARTS, or ADCs, or Interrupts, you can code the microcode your self to emulate any of these functions. And do them pretty damn well and pretty damn fast, never waiting for your time slice, but only waiting on shared resources.

So, my take on it is "If you want an interrupt, be my guest. Write one". In my case, I have not seen a need for them. I do need more cogs and memory! [noparse]:)[/noparse]

Ken Peterson

The example Timmoore mentions is often called "cooperative multitasking" whereas that requiring interrupts is "preemptive multitasking". For most if not all multitasking that a single cog would do, the former approach should be adequate. Especially since I have never heard of a case where code from more than one object is running in a cog at the same time. In cooperative multitasking, each task must be written as to give up control of the processor when it is not needed, as opposed to having it taken away.

The only reason I ever wished I had an interrupt on the Prop is for processing inputs.· I know you can write one in software, but there is latency associated with that, especially if you are monitoring with one cog and messaging another cog.· The cog getting the message has to poll for it, which doesn't seem to have any advantages over polling the input directly.· The best way to work with the Prop is to forget about the concept of interrupts altogether and solve the problem another way.· The Prop performs the best when you focus on timing and determistic designs.

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


Post Edited (Ken Peterson) : 6/10/2008 8:38:46 PM GMT

Graham Stabler

In general if you interrupt a process then you have probably recked it in real time work, that is why there is so much hardware in most uControllers for things such as coms and PWM etc.

If you need something a bit like an interrupt then you can essentially add a command to any loop that says "am I interrupted?" this could be checking an io or the state of a hub variable/flag. This is not instant but may be fast enough for some things and at least it is somewhat deterministic, indeed the time required to service the "interupt" could already be factored in to the rest of the program's timing.

Graham

jazzed

Using a cog as a hardware pin monitor like Phil mentioned with waitpne is entirely doable with an LMM based machine. I have done this before with C running in LMM. The "check" for interrupt occurs at the end of the "unrolled" LMM instruction loop (causes some latency of course), context is saved, and the interrupt handler is called (some details omitted here). This takes a slice of time to handle the interrupt from the main routine. It is not really an interrupt, but there is no difference in behaviour.

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