PASM2 data sharing between cogs
travgm
Posts: 6
I am reading through the assembler manual and trying to make some snippets of code to understand some things. So this may seem excessive for blinking an LED, but I am trying to create a new COG and flash the LED on pin 56. So far this way works where I use setq to pass the pin value where its stored in the PTRA register and I just move it to a general purpose register and use that. The way that doesn't work that I am confused about is if I define it where I have cog_id defined it does not blink. I am confused though because cog_id returns the proper cog_id for the print statement. Appreciate the help!
Working example:
con
_clkfreq = 100_000_000
dat org
asmclk
start
setq #56
coginit #COGEXEC_NEW, #@blink wc
if_c jmp #cog_err
' keep cog0 going
cogl jmp #cogl
' Blink code location
blink
cogid cog_id
debug(`message Started code in: `(cog_id)')
mov pr0, ptra
loop
drvnot pr0
waitx ##clkfreq_/5
jmp #loop
cog_err
debug(`message Error starting cog, exiting')
cogstop #0
cog_id res 4
Example that doesn't work (confused because cog_id returns right number):
con
_clkfreq = 100_000_000
dat org
asmclk
start
coginit #COGEXEC_NEW, #@blink wc
if_c jmp #cog_err
' keep cog0 going
cogl jmp #cogl
' Blink code location
blink
cogid cog_id
debug(`message Started code in: `(cog_id)')
loop
drvnot LED_PIN
waitx ##clkfreq_/5
jmp #loop
cog_err
debug(`message Error starting cog, exiting')
cogstop #0
LED_PIN long 56
cog_id res 4
Comments
You're missing an ORG directive to correct for relative offset. The first program doesn't reference any relative labels, so works without. The second program does have relative labels so doesn't work.
Register references are coded as absolute addressing, therefore relative labels in the source code have to be handled via ORG directives. COGINIT loads the target code to the start of target cog's cogRAM. For the assembler to calculate the correct absolute register addresses for each relative label, you need to tell the assembler where address zero is situated. It's generally always at the same address as COGINIT loads at.
To fix it, add an ORG at the
blinklabel. This then shifts the LED_PIN's register address from 15 to 6.con _clkfreq = 100_000_000 dat org asmclk start coginit #COGEXEC_NEW, #@blink wc if_c jmp #cog_err ' keep cog0 going cogl jmp #cogl ' Blink code location org blink cogid cog_id debug(`message Started code in: `(cog_id)') loop drvnot LED_PIN waitx ##clkfreq_/5 jmp #loop cog_err debug(`message Error starting cog, exiting') cogstop #0 LED_PIN long 56 cog_id res 4Another detail: Data addresses in cogRAM are always whole registers. Registers are 32-bit therefore each address covers four bytes of memory. This is something that ORG vs ORGH directives will affect.
Also, data space is not code space. There is three data spaces, each begin at address zero.
In code space, the three memories are in one map, with cogRAM first, beginning at 0, followed by lutRAM, beginning at $200, and finally hubRAM, beginning at $400. The first $400 bytes of hubRAM are not addressable in code space.
Wow, Thank you so much for the explanation and the information. Appreciate that. It makes a lot of sense now. I will need to study the datasheet and assembler manual more.
No problem, it's my first go at explaining it beyond just do it this way.
Everyone's first experience of ORG is usually one of perplexity, then just follow the rule. ORG's purpose is not anything special to the Propeller chips, just experiencing a pure assembler environment has become rare these days.
On that note, I presume you have a reason why you're diving straight in the deep end and not trying to work from a higher level first?
I really like assembler. I write alot of x86_64 daily in fasm. Assembly for Propeller is kind of an oddball and has some nuances I am finding out, but I just enjoy writing in assembly so I tend to always lean towards learning it. I have written some stuff in spin2 though so off and on for both.
Oh, a quick read of Fasm Wikipedia page tells me that it is probably the oddball case when it comes to assemblers. A multi-pass assembler is a new one on me. That implies it probably has some high-level language features.
Err, that's wrong. But self-hosted on the PC is certainly weird. Booting a PC is fraught with legacy.
Ha, yeah. It does. You can definitely use things the "old" way or choose to use higher level macros. The new fasmg is even more weird, but I tend to just stick to the original stuff tbh.