compile issue

RS_Jim

I have a program that runs standalone, but now I want that to be started in a new cog so that I can have it run in the background while other tasks are controled from the main cog(0)
here is the code that causes the compiler error:
`
{
--------------------------------------------
Filename: NRF_robot_1.0.spin
Author: Jim Meek using nRF24L01+ routines written by:
Author: Jesse Burt and modified for joystick use by Jim Meek
Description: nRF24L01+ Receive demo that uses the radio's
auto-acknowledge function (Enhanced ShockBurst - (TM) Nordic Semi)
Will display data from all 5 data pipes
Copyright (c) 2020
Started Nov 23, 2019
Updated Jan 25, 2020PUB FlashLED(led_pin, delay_ms)
Added ISR from RXDemo-PST-WithISR(1).spiin
updated Feb 16, 2021 to move all of receive function into a cog
io.Output(led_pin)
repeat
io.Toggle (led_pin)
time.MSleep (delay_ms)
See end of file for terms of use.
--------------------------------------------
}

CON

_clkmode        = cfg#_clkmode
_xinfreq        = cfg#_xinfreq

LED1        = 16  '' Blue LEDs
LED2        = 17
LED3        = 18
LED4        = 19
LED5        = 20
LED6        = 21
LED7        = 22
LED8        = 23

SER_RX          = 31
SER_TX          = 30
SER_BAUD        = 115_200

SCK_PIN         =0
MOSI_PIN        =1
MISO_PIN        =2
CS_PIN          =3
CE_PIN          =4
IRQ_PIN         =5


CLEAR           = 1
CHANNEL         = 113
CR = $0A
LF = $0D

OBJ
com : "nrf24rx-joy5.1"
ser : "com.serial.terminal.ansi3"
cfg : "core.con.boardcfg.quickstart.spin"
io : "io"
time : "time"
int : "string.integer"
nrf24 : "wireless.transceiver.nrf24l01.spi"
servo : "servo32V9"

VAR

long _ser_cog, _nrf24_cog,comscog,S_stack[100],myBuf[32]

' byte _fifo[34]
byte _pktlen
byte curbyte
byte col,bs3,didx

PUB Main

ifnot comscog := cognew(com,@S_Stack) + 1


coms.FlashLED2(LED6,100,6)

coms.FlashLED(LED8,100)

`
BST gives a compile time error that says it needs "#" on the cognew line following the "com"

Any suggestions?
JIm

avsa242

Jim,
I'm not sure, yet, but it seems like bst is expecting a constant from your com object. Are you able to try to build using openspin to see if there's any difference? Side note, I'm not sure you can start a method in a child object from the parent with cognew (e.g., cognew(com.start, @com_stack)).

Phil Pilgrim (PhiPi)

Side note, I'm not sure you can start a method in a child object from the parent with cognew (e.g., cognew(com.start, @com_stack)).

The cognew belongs in the daughter object, not in the parent object.

-Phil

RS_Jim

Ok,
Let's see if I understand correctly, The cognew instruction needs to be inside the "com" object?
Just as a side note I installed propelleride as an alternate for compiler. Does anyone know where there is some documentation on setting up the color scheme? Propelleride did not like single line CS (constant ref for Clear Screeen) in the ansi terminal method. but it compiled otherwise.
JIm

avsa242

Jim,

Yes, you can't call a method in another object using cognew/coginit. It has to be in the same object.

It's been awhile since I've used PropellerIDE, but the color scheme should be in Edit > Preferences, I think?

As for the terminal, it operates more like PST, so isn't ANSI-compatible. If you're using my library, use com.serial.terminal instead. If you're using Parallax libs, the equivalent is Parallax Serial Terminal.spin, I believe.

RS_Jim

@avisa
I am not really concerned about the terminal display. What I want to change is the appearence of the edit screen. For the actual terminal I use mincom.
I am still trying to figure out how to evoke cognew from within the object I want to run in the seperate cog.
Jim

avsa242

@RS_Jim
Okay I've got PropellerIDE running now... the color preferences are in the Edit > Preferences menu, in the Appearance tab. There should be some pre-defined themes, and then you can also customize the individual colors.

As far as the secondary cog, are you able to post or attach more of your code (the parent and the com child object, if possible), and what specifically you're trying to get it to accomplish? It may make it easier for us to help you.

Cheers

RS_Jim

Jessie,
Hopefully I can successfully attach the zipped file here. The browser says it is attached, I will send this and see what happens.
My goal is to get the nrf code running completely in the background sending input from the remote directly to the servos.

Jim

avsa242

Jim,

Okay, I see a few issues:
NRF_robot_1.0.spin:

• This looks like the top-level object, and declares the wireless driver as a child, but...
• The nrf24rx-joy6.1 object uses methods from its own separate copy of the wireless driver, but that copy of the driver is never started. It can't utilize the copy that's been started by NRF_robot_1.0 (child objects in spin don't have visibility of things their parent or siblings are doing, at least not in that way). The wireless start would have to occur somewhere in this object. e.g., if you wanted to add it to Start_coms(), you'd redefine it to something like

PUB Start_coms(fifo,chnl, CE_PIN, CS_PIN, SCK_PIN, MOSI_PIN, MISO_PIN): status

    if (status := nrf24.startx(CE_PIN, CS_PIN, SCK_PIN, MOSI_PIN, MISO_PIN))
        nrf24.channel(chnl)   ' your existing code
        receive(@fifo)
    else
        return FALSE ' got here because the nrf24 driver didn't start

• The ISR() method in nrf24rx-joy6.1 is no longer really an ISR, as it was originally written, since it's now just another method in the object. The example I'd given in the nrf24 interrupt demo put the ISR method in its own cog, so it would be sure to never miss a change on the interrupt pin. I think if you don't want to dedicate a cog to it, it may be better to just redefine irqpin as a VAR, set it to an input just once (maybe in the Start_coms() method), and call waitpne(|< irqpin, |< irqpin, 0) in Receive(). The way it's written now is just extra overhead (calling ISR(), calling input() from the io object, and then waiting for the state to change).

• in Start_coms(), you call Receive() with the address of the fifo parameter (Receive (@fifo)), but this is not likely what you want; when you called Start_coms(@_fifo, @chnl) from NRF_robot_1.0, you'd already passed the address of the _fifo variable. For the same reason, nrf24.RXPayload(_pktlen, @fifo) line would read nrf24.RXPayload(_pktlen, fifo), and from_node := fifo.byte[1] would read from_node := byte[fifo][1]

BTW the timing critical part of the nRF24 driver (the SPI engine) is written in PASM, so is already running in its own dedicated cog. It's only the spin methods that would be run in the calling cog. Were you running into issues with anything not being responsive enough?