Interrupts were designed to solve a problem that the Propeller handles much more elegantly with its multiple processors. I have never once missed having an interrupt capability when programming the Propeller. The requirement has simply not presented itself in hundreds of programs I've written for the Prop.
"Why do you need interrupts?"
This is only a general question. I do not have a specific need right now.
What are you trying to implement? Are you looking for a hardware or a software interrupt?
Are you looking for something that can handle an event such as a pin going from high to low and the event being handled on the rising edge, or are you looking for something that just polls for a condition and runs some code?
I suppose you could simulate an interrupt by dedicating a cog for the event that runs code when the event is seen and pauses the other cogs until the code is complete. So, if you have other tasks that you do not want to run when this particular event is seen you can pause then others and then restart them after the event. This is sort of like a Event Flag in an RTOS.
I believe JonnyMac's code a way to implement this. Note, this does require having a global variable that each cog/task has access to though.
The thing I do not know with the Propeller COG feature is whether or not you can save the state the other cogs processes were in ( a.k.a. Context Switch) when the sudo Interrupt event was seen.
That said, the Propeller is really flexible -- even in Spin, its simplest language -- and you can fake things quite easily. Let's say you're running a state machine and between states want to check to see if a pin was pulled low (that may have returned high before you can check it). No problem. Put a pull-up on the pin, assign a counter to increment its phsx register when the pin is low, and then check for a non-zero value to run your event handler code. Yes, I know it's not the same as a real interrupt, but it does let you get to an event in a reasonable time without having to dedicate a cog.
Here's a simple idea to deal with a quick, transient event that might be missed with regular polling.
pub main
ctra := (%01100 << 26) | LOW_INT_PIN ' setup pin for neg detection
frqa := 1
phsa := 0
repeat
if (phsa)
handle_event
case state
0 : state_0
1 : state_1
2 : state_2
pub state_0
'' state 0 code -- could conditionally change state
state := 1
pub state_1
state := 2
pub state_2
state := 0
pub handle_event
'' event code
phsa := 0
... Interestingly it includes a diagram of part of a control system developed in Lucol. Those diagrams were produced from the Lucol source code itself and could be used as documentation.
Ladder logic in PLC's would be another formal language along these lines. Because everything is executed as one big loop it has no loop statement in the language itself.
Hey, that is sneaky. The counter captures the event, by counting, and you can check an event has happened at your leisure in the software, Neat.
You don't even have to reset phsa. Just check it has changed. Which give you the possibility of knowing you have missed an even, it will have incremented by more than 1.
But UARTs aren't that simple.. take a look at what's around. Registers and status bits, modes, interrupt handling, fifos etc. You wouldn't need just the silicon space, but also the programming interface with dedicated addresses and usually pins as well.
I don't need a uart. Just a hardware shift register. They could do it as a counter mode, or allow us to shift data into the video generator and provide a way to retrieve it. A counter mode would probably look something like, counter a adds it's value to it self on rising edge of counter b, if data input line is high.
Comments
-Phil
What are you trying to implement? Are you looking for a hardware or a software interrupt?
Are you looking for something that can handle an event such as a pin going from high to low and the event being handled on the rising edge, or are you looking for something that just polls for a condition and runs some code?
I suppose you could simulate an interrupt by dedicating a cog for the event that runs code when the event is seen and pauses the other cogs until the code is complete. So, if you have other tasks that you do not want to run when this particular event is seen you can pause then others and then restart them after the event. This is sort of like a Event Flag in an RTOS.
I believe JonnyMac's code a way to implement this. Note, this does require having a global variable that each cog/task has access to though.
The thing I do not know with the Propeller COG feature is whether or not you can save the state the other cogs processes were in ( a.k.a. Context Switch) when the sudo Interrupt event was seen.
That said, the Propeller is really flexible -- even in Spin, its simplest language -- and you can fake things quite easily. Let's say you're running a state machine and between states want to check to see if a pin was pulled low (that may have returned high before you can check it). No problem. Put a pull-up on the pin, assign a counter to increment its phsx register when the pin is low, and then check for a non-zero value to run your event handler code. Yes, I know it's not the same as a real interrupt, but it does let you get to an event in a reasonable time without having to dedicate a cog.
Here's a simple idea to deal with a quick, transient event that might be missed with regular polling.
pub main ctra := (%01100 << 26) | LOW_INT_PIN ' setup pin for neg detection frqa := 1 phsa := 0 repeat if (phsa) handle_event case state 0 : state_0 1 : state_1 2 : state_2 pub state_0 '' state 0 code -- could conditionally change state state := 1 pub state_1 state := 2 pub state_2 state := 0 pub handle_event '' event code phsa := 0Ladder logic in PLC's would be another formal language along these lines. Because everything is executed as one big loop it has no loop statement in the language itself.
EDIT: Typo fix
You don't even have to reset phsa. Just check it has changed. Which give you the possibility of knowing you have missed an even, it will have incremented by more than 1.
I don't need a uart. Just a hardware shift register. They could do it as a counter mode, or allow us to shift data into the video generator and provide a way to retrieve it. A counter mode would probably look something like, counter a adds it's value to it self on rising edge of counter b, if data input line is high.