Spin2 cog start/stop
VonSzarvas
Posts: 3,450
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...
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]
Comments
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!
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 ?
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
The two applications report different versions of FastSpin......
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.
I always need the -CHIP option when loading the P2ES board. I've checked it many times.
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.
Cool, thanks. I have both boards connected so need to specify the port by ID.
@VonSzarvas, sorry for hijacking your thread.
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 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
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.
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.
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.
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:
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.
https://forums.parallax.com/discussion/168913/new-basic-compiler-for-prop1-and-prop2/p17
Can you use the "C" in the posting to retain the indentation.
My code is below. I have to pack up in about 15 min. Library closes at 7 pm.
Let's see how this looks.
Assembly code mentioned:
"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.