Object Calls from Spin Cogs

[JonnyMac]

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)]

Jon,

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

-Phil

[JonnyMac]

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]

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]

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]

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 bollocks 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]

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.

86069

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]

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.