Spin2 cog start/stop

VonSzarvas · 2019-01-10 10:39

Did anything change with regard running cogs?

This code runs directly, but not when called from a top-level wrapper.

I'm guessing its an addressing issue, as adjusting the code or stack size gets different results.
Maybe the cog memory address needs setting somehow... Seems like these cognew's are running over each other...

'
' Top level wrapper
'
CON

  oscmode = $010c3f04
  freq = 160_000_000

  basepin_ledmatrix = 40
  basepin_goertzel = 32
  
  
OBJ
  
  ledmatrix: "Test_LED_MATRIX.spin2"    
  goertzel: "Test_GOERTZEL.spin2"




PUB Main | i

  ledmatrix.Start(basepin_ledmatrix)
  goertzel.Start(basepin_goertzel)

  repeat
    i := 0

' Test_LED_MATRIX.spin2
'
' simple LED MATRIX test for P2 Eval board
'

OBJ
  
  pins: "Pins.spin2"	

VAR

  long cog, stack[128]

  


PUB Start(basepin) : okay

 Stop

 okay := cog := cognew(Main(@basepin), @stack) + 1



PUB Stop

  if cog > -1
    cogstop(cog)



PRI Main(basepin) | r, c
 
  repeat

	repeat r from 0 to 7

		pins.High(basepin + r)

		repeat c from 0 to 7

			if c == r
				next

			if r==7 and c==7
				next

			pins.Low(basepin + c)

			waitcnt(clkfreq / 100000 + cnt)

			pins.In(basepin + c)
			

		pins.In(basepin + r)

' Test_GOERTZEL.spin2
'
' simple GOERTZEL test
'

OBJ
  
  pins: "Pins.spin2"	

VAR

  long cog, stack[128]




PUB Start(basepin) : okay

  Stop

  okay := cog := cognew(Main(@basepin), @stack) + 1



PUB Stop

  if cog
    cogstop(cog~ - 1)



PRI Main(basepin)
 
  repeat

	pins.High(56)
	pins.High(basepin + 6)

	waitcnt(clkfreq / 200 + cnt)

	pins.Low(56)
	pins.Low(basepin + 6)

	waitcnt(clkfreq / 200 + cnt)

' Pins.spin2


PUB High(pin)

  if pin < 32
  
	outa[pin] := 1
	dira[pin] := 1
	
  else
  
	outb[pin] := 1
	dirb[pin] := 1

  

  
PUB Low(pin)

  if pin < 32
  
	outa[pin] := 0
	dira[pin] := 1 

  else
  
	outb[pin] := 0
	dirb[pin] := 1 		

  
  
PUB In(pin) : state

  if pin < 32
	
	dira[pin]:=0
	state := ina[pin]

  else
  
	dirb[pin]:=0
	state := inb[pin]

VonSzarvas · 2019-01-10 14:26

Argh.

OK, so I was mixing some sample code between SpinEdit, FastSpin and Spin2Gui.
The clock settings were from spin2gui, but not compiled by SpinEdit.

Lack of docs is as fun as it's frustrating. All part of the pioneer challenge I suppose.
At some point some simple samples of code for Spin2 that doesn't go into ASM at the first moment would probably help obviate such early hickups!

ersmith · 2019-01-10 21:25

Your code generally looks OK, but I think you need to add a "clkset(oscmode, freq)" to the top level Main to get the clock set up properly.

VonSzarvas · 2019-01-11 12:20

Thanks for the tip @ersmith, but still no joy.

I've slimmed the test code down. This compiles with both gui's, but only runs with "spin2gui".
Nothing happens after uploading from "SpinEdit"

Any other clues ?

'
' simple LED test for P2 Eval board
'
CON
  oscmode = $010c3f04
  freq = 160_000_000

  

PUB demo

  clkset(oscmode, freq)
  
  repeat
  
    High(56)
    pausems(250)
    Low(56)
    pausems(250)

  
  
PRI High(pin)

  if pin < 32
  
    outa[pin] := 1
    dira[pin] := 1
    
  else
  
    outb[pin] := 1
    dirb[pin] := 1

  

  
PRI Low(pin)

  if pin < 32
  
    outa[pin] := 0
    dira[pin] := 1 

  else
  
    outb[pin] := 0
    dirb[pin] := 1

evanh · 2019-01-11 12:32

Not sure if this is important here but loadp2 needs -CHIP parameter to load the real silicon correctly.

Dave Hein · 2019-01-11 13:13

loadp2 will detect whether it is connected to an FPGA or P2 silicon. The -CHIP and -FPGA options are provide to override the automatic detection.

VonSzarvas · 2019-01-11 14:17

Considering I'm using a modified P2-EVAL board, I figured this would be worth a go. Although it didn't appear to change anything.

The command line that SpinEdit shows is this:

/C loadp2.exe -m 010c1f08 -CHIP -SINGLE -p COM3 "C:\Users\micha\Sync\Documents\Parallax\FastSPIN\Hello_LED56.binary" > loadp2.out

VonSzarvas · 2019-01-11 14:18

Oh wait....

The two applications report different versions of FastSpin......

VonSzarvas · 2019-01-11 14:24

OK, that was it.

I had downloaded the "latest" versions of both applications, but seemingly the SpinEdit zip has older versions of both FastSpin and loadp2.exe
Now I'm feeling silly!

@Rayman Is that FastSpin binary something you could update in the SpinEdit package ? ..... or with your permission, I would be happy to do that.
(And maybe include a note/link to the github latest versions, as they are likely moving fast at this time!)

Thanks for all the help on this everyone.

evanh · 2019-01-11 14:56

Dave Hein wrote: »

loadp2 will detect whether it is connected to an FPGA or P2 silicon. The -CHIP and -FPGA options are provide to override the automatic detection.

I always need the -CHIP option when loading the P2ES board. I've checked it many times.

Dave Hein · 2019-01-11 15:03

Specify the -v option, and see what prints out. You should get something like this:

$ loadp2 -t -v a.out
Setting user_baud to 115200
Set loader_baud to 2000000
Searching serial ports for a P2
P2 version A found on serial port com4
Setting load_mode to LOAD_CHIP
Setting clock_mode to 12427f8
Loading a.out - 2604 bytes
a.out loaded
[ Entering terminal mode.  Press ESC to exit. ]

evanh · 2019-01-11 15:05

$ ../bin/fastspin -2 lutson.spin2; ../bin/loadp2 -v -p /dev/serial/by-id/usb-Parallax_Inc._Propeller_P2-EVAL-ES_P2EEL5T-if00-port0 -t lutson.binary
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2018 Total Spectrum Software Inc.
Version 3.9.12 Compiled on: Dec 10 2018
lutson.spin2
lutson.p2asm
Done.
Program size is 2112 bytes
Setting user_baud to 115200
Set loader_baud to 2000000
Loading lutson.binary - 2112 bytes
lutson.binary loaded
[ Entering terminal mode.  Press ESC to exit. ]

$ ../bin/fastspin -2 lutson.spin2; ../bin/loadp2 -v -CHIP -p /dev/serial/by-id/usb-Parallax_Inc._Propeller_P2-EVAL-ES_P2EEL5T-if00-port0 -t lutson.binary
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2018 Total Spectrum Software Inc.
Version 3.9.12 Compiled on: Dec 10 2018
lutson.spin2
lutson.p2asm
Done.
Program size is 2112 bytes
Setting user_baud to 115200
Set loader_baud to 2000000
Setting clock_mode to 12427f8
Loading lutson.binary - 2112 bytes
lutson.binary loaded
[ Entering terminal mode.  Press ESC to exit. ]

Diag comport pins: 087a2007

Dave Hein · 2019-01-11 15:08

OK, because you specify the port number loadp2 skips the serial port search. This is where the version type is determined. Looks like I need to check for a P2 on the specified port.

VonSzarvas · 2019-01-11 15:10

Further diagnostics...

Whilst the correct version of FastSpin gets simple code loading from SpinEdit, the original issue of using OBJ and running stuff with COGNEW, as per the first sample batch of code posted, remains. (And I believe this is also an issue from spin2gui).

Likely culprits seem like clock settings for subsequent cogs (crazy-talk!), stack addressing, cog addressing. Something is trampling on something, or not starting at all.

Without the fleshed out Spin2 command reference I feel like I'm poking a stick into a bag of time that I don't have right now.

At least I can run these tests individually (I'll just split all the code into separate files, and run them individually in cog 1). That'll do for today. Will come back to investigations later, as this feels like something important to fathom.

Edit: Refined description a bit.

evanh · 2019-01-11 15:11

Dave Hein wrote: »

OK, because you specify the port number loadp2 skips the serial port search. This is where the version type is determined. Looks like I need to check for a P2 on the specified port.

Cool, thanks. I have both boards connected so need to specify the port by ID.

Dave Hein · 2019-01-12 01:30

I checked a fix for loadp2 into GitHub. loadp2 now checks for a P2 when a port is specified, and it will automatically configure for either the FPGA or P2 silicon. You shouldn't have to specify -CHIP anymore.

@VonSzarvas, sorry for hijacking your thread.

ke4pjw · 2019-01-12 02:33

VonSzarvas wrote: »

Further diagnostics...

Whilst the correct version of FastSpin gets simple code loading from SpinEdit, the original issue of using OBJ and running stuff with COGNEW, as per the first sample batch of code posted, remains. (And I believe this is also an issue from spin2gui).

Likely culprits seem like clock settings for subsequent cogs (crazy-talk!), stack addressing, cog addressing. Something is trampling on something, or not starting at all.

Without the fleshed out Spin2 command reference I feel like I'm poking a stick into a bag of time that I don't have right now.

At least I can run these tests individually (I'll just split all the code into separate files, and run them individually in cog 1). That'll do for today. Will come back to investigations later, as this feels like something important to fathom.

Edit: Refined description a bit.

I am experiencing the same. I will fight on through this evening after the kiddos go to bed. If I get it working, I will let you know.

Looking at the P2asm file, it appears that it is compiling with all of the instantiated objects. I am starting to suspect that the COG is not starting or the parameters are not being passed off correctly.

VonSzarvas · 2019-01-12 06:13

ke4pjw wrote: »

I am experiencing the same. I will fight on through this evening after the kiddos go to bed. If I get it working, I will let you know.

Looking at the P2asm file, it appears that it is compiling with all of the instantiated objects. I am starting to suspect that the COG is not starting or the parameters are not being passed off correctly.

Thanks ke4pjw.

BTW.. I think cognew was working from a single spin2 file ( ie. running a local PUB ), but I dont recall if that was whilst passing a param.

Rayman · 2019-01-12 15:07

I haven't been able to get cognew to work with Fastspin in p2 yet...
I guess you could do it with inline assembly...
Maybe I'll try this again today, been a while...

VonSzarvas: I'll try to do a better job with the SpinEdit thread... Thanks for trying SpinEdit

ke4pjw · 2019-01-13 14:58

So, I have found that the new cog is indeed started. I do see pins toggling but something in the logic is not happy and so I started to place debug LEDs in the code to track down what was happening from a loop/subroutine perspective.

I placed the following in the part of code I want to see if it is executing:

mov dirb,testpin
or outb,testpin
andn outb,testpin

With this in the DAT section at the bottom of code.

testpin long %00000110000000000000000000000000

This will turn on LEDs P56 and P57. Since outb is not usually used in legacy code, this should be compatible for use.

Not a sophisticated troubleshooting method, but between finding where the code stops and the differences between PASM and PASM2 from this thread, I feel confident I can find the issue in my code that is incompatible with PASM2.

AwesomeCronk · 2019-01-13 16:16

Is there any way that a program could be made to convert spin to spin2, checking the code for non compatible commands?

ersmith · 2019-01-14 02:51

VonSzarvas wrote: »

show previous quotes

ke4pjw wrote: »

I am experiencing the same. I will fight on through this evening after the kiddos go to bed. If I get it working, I will let you know.

Looking at the P2asm file, it appears that it is compiling with all of the instantiated objects. I am starting to suspect that the COG is not starting or the parameters are not being passed off correctly.

Thanks ke4pjw.

BTW.. I think cognew was working from a single spin2 file ( ie. running a local PUB ), but I dont recall if that was whilst passing a param.

I'm able to do very simple programs using cognew, e.g. the attached "blink_all_cogs.spin" works on P2, as does the "exec13.spin" sanity check. Both are attached.

ersmith · 2019-01-14 04:06

AwesomeCronk wrote: »

Is there any way that a program could be made to convert spin to spin2, checking the code for non compatible commands?

I presume you mean converting the PASM parts of spin to spin2. fastspin already compiles plain spin for the P2 processor, but it doesn't try to convert the assembler parts.

I think @Cluso99 may have done some investigation of converting PASM to PASM2 automatically, but I don't think there's a tool for that yet. Many simple things are easily converted, but there are edge cases involving self modifying code that will be hard to convert correctly. There are also differences in the register sets of the two processors that would probably make automatic conversion extremely difficult.

Rayman · 2019-01-15 15:27

Cognew does work in spin mode, it seems.
I'm trying to remember what I was doing that didn't work...

I'm wondering if my issue was not waiting for cog to start up...
I noticed in FastSpin thread that a ~20ms delay was needed...
Here's a simple test that works:

jmg · 2019-01-15 19:50

Rayman wrote: »

...

I'm wondering if my issue was not waiting for cog to start up...
I noticed in FastSpin thread that a ~20ms delay was needed...
Here's a simple test that works:

I don't see a 20ms delay inside that ?
I did find that in present P2 silicon, you cannot Enable Xtal (even with no PLL) and have the hardware auto-wait for the Xtal to start, you need to Enable Xtal amplifier, wait, then switch.
Failing to do that simply hangs P2.

Rayman · 2019-01-15 21:46

Comment about needing 20 ms is here:
https://forums.parallax.com/discussion/168913/new-basic-compiler-for-prop1-and-prop2/p17

jonabel1971 · 2020-08-25 21:00

{Removed}

Publison · 2020-08-25 22:27

jonabel1971 wrote: »

I am unable to compile the cognew() statement below:

PUB Start()
cog := cognew(@PWM_Asm, @command)

The error I get is "Expected an expression term".

I tried changing the VAR statement.

long command --> long command[128] but same error.

cog & command are defined as such:

VAR
long cog, command, ARG0, ARG1, ARG2

@PWM_Asm looks like this:

DAT

org

{PWM_ASM mov temp, par}
{Replaced with P2 equivalent below}

PWM_ASM mov temp, ptra
mov cmd_address, temp 'Acquire command variable address
add temp, #4
mov ARG_0, temp 'Acquire ARG_0 variable address
add temp, #4
mov ARG_1, temp 'Acquire ARG_1 variable address
add temp, #4
mov ARG_2, temp 'Acquire ARG_2 variable address

"command" is set to 1 of 4 locations in assembly code (SyncPhase, IO_State, DutyOverRide, or UpdateTonToff). Locations in assembly start with underscores before each command.

Can you use the "C" in the posting to retain the indentation.

jonabel1971 · 2020-08-25 22:48

I'm sorry, but I don't know how formatting works in the discussions. How do I do that?

Publison · 2020-08-25 23:04

When you are posting, there is a format bar at the top. If you select the "C" in the bar that would allow you to paste code between the [ code ] [/ code ] tags.

jonabel1971 · 2020-08-25 23:16

Cool, I will use that from now on.

My code is below. I have to pack up in about 15 min. Library closes at 7 pm.
Let's see how this looks.

VAR
long    cog,command, ARG0, ARG1, ARG2


PUB Stop()
    cogstop(cog)


PUB Start()                                              '' Initialize PWM cog
    cog := cognew(@PWM_Asm, @command)

Assembly code mentioned:

DAT

  org

'PWM_ASM      mov      temp, par
              {Replaced with}
PWM_ASM       mov      temp, ptra
              mov      cmd_address, temp        'Acquire command variable address
              add      temp,    #4  
              mov      ARG_0, temp              'Acquire ARG_0 variable address
              add      temp,    #4  
              mov      ARG_1, temp              'Acquire ARG_1 variable address
              add      temp,    #4
              mov      ARG_2, temp              'Acquire ARG_2 variable address

"command" is set to 1 of 4 locations in assembly code (SyncPhase, IO_State, DutyOverRide, or UpdateTonToff). Locations in assembly start with underscores before each command.

Spin2 cog start/stop

Comments