propeller and interruptions ?



  • 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.

    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • henrib75 wrote: »

    "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.
  • I'm with Phil.

    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
        if (phsa)
        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
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • evanhevanh Posts: 4,764
    edited January 7 Vote Up0Vote Down
    Heater. wrote: »
    ... 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.

    EDIT: Typo fix

    “What car did you learn to drive stick shift on?” == “What was the make and model of your first car?” -> Password reset! --
  • 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.
  • MIchael_MichalskiMIchael_Michalski Posts: 57
    edited January 7 Vote Up0Vote Down
    Tor wrote: »
    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.
    Particularly patient proactive practice positively predicates practically precise poly-processor Parallax Propeller programming paradigms.

Sign In or Register to comment.