Object Calls from Spin Cogs

JonnyMac · 2011-10-17 10:38

I'm a little perplexed... I'm working on a project that sends CAN message from time to time and I want this to run as "background" process so that the main process can set flags for the required message. If I have this snippet of code in the main loop:

work := (hrs << 16) | (mns << 8) | scs
    work := (work << 8) | $40
    can.tx_msg(0, $91, $00, $04, @work)

... but if I move it to another Spin cog -- no go.

pri can_coms | work

  repeat
    if (canflags & %0000_0001)
      work := (hrs << 16) | (mns << 8) | scs
      work := (work << 8) | $40
      can.tx_msg(0, $91, $00, $04, @work)                       ' does not work from bg cog
      canflags := 0
      term.tx("*")                                              ' works
      term.tx(CR)                                               ' works

What's really odd is that I put a marker for FDS (called term in my test code) and that works just fine, even from the background cog. Any ideas?

And yes, I have pushed the stack size up but with no change. The CAN object is very simple, Spin-based SPI interface for MCP2515.

Phil Pilgrim (PhiPi) · 2011-10-17 10:58

Jon,

From which cog did you call the CAN object's start method?

-Phil

JonnyMac · 2011-10-17 14:08

Phil: The main cog, same as with FDS. I suppose I could make it an object of that "background" cog but as it's just sending simple messages I was wanting to keep the stack size down.

MagIO2 · 2011-10-17 14:45

Is can.tx_msg sending nothing at all or the wrong value?

Did you also remove the variable work from VAR or DAT section? Maybe the address-operator and usual assignment behave different in case the variable exists twice (once in VAR/DAT and once as local variable)?

Kevin McCullough · 2011-10-17 15:17

Hi Jon,

Could you post the rest of your code? Specifically the top level object and the 'CAN' driver object would be most helpful so we can determine what the issue might be. Alternately, you could email your code directly to me at: kmccullough@parallaxsemiconductor.com.

Thanks a lot!

JonnyMac · 2011-10-17 16:37

Okay... I think what Phil was hinting at and MagIO is suggesting that my Spin based SPI works fine when called from the main cog but, due to dira settings, is Smile when called from another cog. Will try that after I finish another Propeller programming job (which has me in big Hollywood FX shop with some AMAZING artists).

Kevin McCullough · 2011-10-18 10:15

Hi Jon,

Indeed this issue has to do with from which cog the start method is called (which initialized several pin directions). When the code loop is moved to a different cog, the other cog is essentially trying to drive the pin states but the pins were never set as outputs in that cog. The fix is to place your start method in the can_coms method before it falls into the repeat loop, so that it will be called when it is launched into a new cog. See example demo code attached.

Demo - Archive [Date 2011.10.18 Time 09.55].zip

The demo program runs on a quickstart board and blinks an LED (P16) whenever the pin (P15) is high. Suggest connecting a pull-down resistor from P15 to ground for this demo.

Cheers,

JonnyMac · 2011-10-19 16:35

Yes, that was the case. When I got home the other evening I moved the initialization to its own cog and everything works. The CAN object shares the SPI buss so I'm using a lock to ensure that there is not a clash between cogs that need to use SPI.

Object Calls from Spin Cogs

Comments