Resolved: Bug? Misundertanding? This blinky should work....(I think)
mindrobots
Posts: 6,506
My little peanut brain says this little blink_all_cogs program or something very close to it should work. I made a few org changes and some addressing prefix changes form the original. What I am asking and the code image I am building makes sense in my head.
edit: it starts the COGs but nothing blinks
I would think this would be a common program framework with COG0 doing overall init and setting up the other COGS and then doing something for itself.
{edited}
Start in HUBEXEC, Start in COG EXEC
jump to code in high HUB {switching to HUB EXEC} and set up variable space for what will be COG0 COGRAM (even though it doesn't get loaded),
run my HUBEXEC code as COG0 to kick off the other cogs to run blink in COGEXEC,
fall through to blink to run as COG0 in HUBEXEC
What am I misunderstanding? {I got it now, below, Chip was correcting my comments regarding starting in HUB exec.}
EDIT: Solution? Change 'coginit cognum,#blink' to 'coginit cognum,##@blink' so you get the proper address.
edit: it starts the COGs but nothing blinks
dat
orgh 0
jmp #highhub
org 0
cognum long 0
'
' launch cogs 15..0 with blink program
' cogs that don't exist won't blink
'
orgh $1000
highhub
mov cognum,#15 ' need to load it since COG0 COGRAM
' is not initialized
.loop coginit cognum,#blink ' should be ##@blink to work
djns cognum,#.loop
jmp #blink
'
' blink
'
org 0
blink cogid x 'which cog am I?
setb dirb,x 'make that pin an output
notb outb,x 'flip its output state
add x,#16 'add to my id
shl x,#18 'shift up to make it big
waitx x 'wait that many clocks
jmp #blink 'do it again
x res 1 'variable at cog register 8
I would think this would be a common program framework with COG0 doing overall init and setting up the other COGS and then doing something for itself.
{edited}
Start in HUBEXEC, Start in COG EXEC
jump to code in high HUB {switching to HUB EXEC} and set up variable space for what will be COG0 COGRAM (even though it doesn't get loaded),
run my HUBEXEC code as COG0 to kick off the other cogs to run blink in COGEXEC,
fall through to blink to run as COG0 in HUBEXEC
What am I misunderstanding? {I got it now, below, Chip was correcting my comments regarding starting in HUB exec.}
EDIT: Solution? Change 'coginit cognum,#blink' to 'coginit cognum,##@blink' so you get the proper address.
Comments
it appears to work just fine.
If I change the COGINIT to "coginit cognum,#@blink", PNUT complains that constant must be from 0 to 511and highlights @blink.
Is COGINIT an instruction that can't benefit from AUGS?
I can see if it has to be a valid S( or ADRA/ADRB/PTRA/PTRB) in the S field, then why PNUT can't just resolve it for you.
Maybe It's just a gotcha(quirk) to be aware of, document and move on.
Also, in case you're not using today's update and @ means relative address in your version of PNUT, I'm pretty sure coginit doesn't accept a relative address.
So I need the longer than 9 bit (##) constant of the address of something in hub (@)
Makes perfect sense now.
If so, cool. I like that better actually.
I must have missed that change.
We now always start in cog exec until we JMP someplace higher than $400?
(Haven't looked a the loader code lately.)
My assumption was that I started at $00000 in hub COG exec, immediately jumped over hubram to $400 to continue start execution in hub exec.
Then I switched to 'org 0' to build a COG RAM image that could be loaded into COG0 so I'd have labels with cog addressing and also could create my initialized variables.
Once I was running at $400, I just copied my COGRAM image from HUBRAM $00004 to COG0 COGRAM $0. After this, my COGRAM is loaded with any initialized variables I had created.
If I didn't do this, I was finding COGRAM for COG0 to be in an unknown state and I could not do something like 'wrlong vector,##DEBUGV_3' without first initializing vector first.
The above works great and solves my uninitialized COG variable problem. Is it just luck based on bad understanding?
The first cog always starts in cog exec. From there, you control whether you start in cog exec (with or without copying $1F0 longs) or hub exec based on D[5] in coginit.
...or a jump to an address beyond $1000 (bytes) or $3FF (longs) so after the first instruction executes, I am in hub exec. No?
I just need to update my description of the program above so it reflects the current reality.
The $00000..$001FF addresses are cog exec.
The $00200..$003FF addresses are lut exec.
The $00400..$FFFFF addresses are hub exec.
When you get inside those lower addresses for cog/lut exec, it is like Alice in Wonderland, where what would have been bytes in the hub are actually longs in the cog/lut.
Thanks!
Saw the comment when it first came out and added it to my notes, I just hadn't grabbed a new copy of the main loader since it changed from a HUB EXEC COGINIT to a COG EXEC COGINIT.
All is good now. The world makes more sense!!
I'm good now. Back to having fun!!