compile issue

Comments

• avsa242 Posts: 429

  2021-02-18 14:07

  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) Posts: 23,514

  2021-02-18 19:24 edited 2021-02-18 19:25

  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 Posts: 1,753

  2021-02-23 13:52

  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 Posts: 429

  2021-02-23 13:58 edited 2021-02-23 23:22

  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 Posts: 1,753

  2021-02-23 15:11 edited 2021-02-23 15:15

  @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 Posts: 429

  2021-02-23 23:24

  @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 Posts: 1,753

  2021-02-24 00:07 edited 2021-02-24 00:09

  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

  zip

  zip

  NRF_robot_1.0.zip

  28K

  NRF_robot_1.0.zip 28.4K
• avsa242 Posts: 429

  2021-02-25 00:29

  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?