P2ASM Sharing HUB RAM location between cogs?

nospin

Hello, I'm new to the propeller platform, but I've got a fairly extensive track record with assembly programming on other architectures (ARM, AVR, 6502, Z80). I'm having issues trying to share hub memory locations between cogs. And let me preface with I do not want to use spin2. I can't say that I'm a fan of there seeming to be no way around spin2 (please correct me if I'm wrong) - It appears that you have to still wrap and invoke your assembly code in spin2. Here is the example program I was using to try to get a better understanding of P2ASM:

CON
_clkfreq = 100_000_000
PUB main()
coginit(COGEXEC_NEW, @init_start, 0)
waitms(1_000)
coginit(COGEXEC_NEW, @cog_one, 0)
coginit(COGEXEC_NEW, @cog_two, 0)
waitms(2_000)
coginit(COGEXEC_NEW, @set_start, 0)
DAT
org
alignl
r0 byte 0
orgh $0600
alignl
start byte 1
init_start wrbyte #0, #@start
rdbyte r0, #@start
tjnz r0, #init_start
dirh #58
outl #58
loop jmp #loop
set_start wrbyte #1, #@start
rdbyte r0, #@start
tjz r0, #set_start
dirh #59
outl #59
loop2 jmp #loop2
cog_one rdbyte r0, #@start
tjz r0, #cog_one
dirh #56
outl #56
one jmp #one
cog_two rdbyte r0, #@start
tjz r0, #cog_two
dirh #57
outl #57
two jmp #two

Despite start being declared under 'orgh' (which based on documentation should ensure that is placed in hub memory), the variable is behaving as though it is being placed in cog memory. In init_start, I initialize start to 0 and then test that it actually is zero by immediately reading the value stored at the hub address (if it isn't, the cog will loop indefinitely, if it is, LED 58 on my eval board will illuminate - the LED is illuminated so this appears to be setting start to 0). In set_start, I overwrite start with 1 (again testing that this succeeds by following the wrbyte with a rdbyte of the same location - LED 59 is illuminated if a 1 is read, otherwise the cog will loop indefinitely - and again, the LED illuminates so it would appear that start is successfully set to 1) - However, LEDs 56 and 57 never illuminate, indicating that the rdbyte present in each cog_one and cog_two assembly routines is returning back 0, even after LED 59 illuminates (indicating that set_start has successfully written a 1 to the hub address for start. I've seen examples of sharing memory locations using spin2 functionalities (passing params when coginit gets called), but again, I'm not interested in using spin2 whatsoever. So please do not bombard me with "why don't you just use spin" responses. I'm a hobbyist and I enjoy working as close to the hardware as possible, I don't enjoy using abstractions.

As another aside, what is the purpose of values specified after org, orgh, and declarations in DAT?

orgh $FFFF

the $FFFF (or any other value it seems, I've tried several) doesn't appear to do anything.

name byte 26

the 26 (or any other value it seems, again, I've tried several) doesn't appear to initialize the value at the address that name gets assigned.

I'm using Propeller Tool, if that information is relevant.

Can a moderator please move this to the correct discussion? I could have sworn I clicked P2 Spin/P2ASM but apparently I did not.

VonSzarvas

Moved!

Welcome to the forums @nospin

Wuerfel_21

There's a number of problems here:

• You don't get control over hub memory layout when using the Spin language. This is why the address after ORGH is ignored. @something expressions in a DAT block also don't return an actual address (instead they have the offset into the current object's data block). You can create a pure ASM program by using only CON and DAT blocks. In that case the bootloader starts it like coginit(0|COGEXEC,0,0) (i.e. cogexec at address zero) and you can place things where you want them go and @something always gives the real cog address. Many of the example files that come with PNut (not sure if they're in proptool) are ASM only programs, so look at those for guidance and inspiration.
• Note the difference between COGEXEC and HUBEXEC init modes - the former copies code into cog RAM before running it, the latter runs it directly from hub RAM (leaving cog RAM uninitialized!). Code assembled for cogexec is not quite the same as code assembled for hubexec, so this is why you use ORG and ORGH to set the mode to assemble for. (the difference concerns relative addressing of other code). The number after ORG (0 if not given) sets the base cog address to assemble from. Note that the assembled code always is stored into hub RAM. Nothing is automatically loaded into cog RAM at any point, other than when starting a cog in COGEXEC mode, in which case 496 contiguous longs are copied from the given address. (Note that a cog doesn't have stay in the mode it started in, it can simply jump into the other address space)
• Cog RAM is exclusively addressed in units of 32bit longs - r0 should be defined as long - RDBYTE and similar instructions inherently zero-extend to a full 32 bit unit.
• As an aside: Code is addressed slightly differently than data. As data is concerned, cog, LUT and hub are 3 different address domains accessed with different instructions. As code is concerned $00000..$001FF is cog RAM, $000200..$3FF is LUT RAM, $00400..$FFFFF is hub RAM -> this has odd implications. When running from cog/LUT, the PC increments by 1 each instruction, when running from hub it increments by 4 due to difference in long/byte addressing. The first 1024 bytes of hub RAM can not be used to store code for HUBEXEC.
• ORG implies long alignment automatically, no need to do it yourself
• If you want an infinite loop, you can always do jmp #$, no need for a label
• Your source formatting is horrendous, use the tab key to indent things (again, check some of the example files for examplary formatting)

VonSzarvas

Btw… tip…. to post multiple lines of code, put 3 backticks on the line before and line after your code. No need to do the single backticks on every line, and the formatting will be preserved too.

nospin

Thank you @Wuerfel_21 for the many distinctions, very helpful! I will switch over to PNut as it looks to be geared toward more what I'm aiming to do. The examples packaged with PNut are also exactly what I've been looking for. Though I will say that the Assembly documentation, IMO, leaves much to be desired (some of the info you provided isn't listed, such as only specifying CON and DAT blocks for an asm only program - the doc is more so a quick overview and listing of instructions and is lacking in detail).

And thanks @VonSzarvas I was wondering that. I had tried that but with only 1 backtick and the preview was all code on one line (thats what the insert code button pasted in by default)

Wuerfel_21

@nospin said:
Though I will say that the Assembly documentation, IMO, leaves much to be desired (some of the info you provided isn't listed, such as only specifying CON and DAT blocks for an asm only program - the doc is more so a quick overview and listing of instructions and is lacking in detail).

Yea, Idk what they have Jeff working on, but it's not those docs.
Some useful resources:
- Chip's "silicon doc" - very raw: https://docs.google.com/document/d/1gn6oaT5Ib7CytvlZHacmrSbVBJsD9t_-kmvjd7nUR6o
- The Spin doc (even if not writing any actual Spin code - the sections on operators, predefined constants and the debugger apply to assembly just as well) https://docs.google.com/document/d/16qVkmA6Co5fUNKJHF6pBfGfDupuRwDtf-wyieh_fbqw/
- This website I made that has some stuff in greater detail: https://p2docs.github.io

nospin

Well, my previous comments were referring to Parallax ASM docs. The docs listed on the thread for PNut seem to be much more in depth. Will give them a read

bob_g4bby

deleted

TonyB_

@nospin said:
Hello, I'm new to the propeller platform, but I've got a fairly extensive track record with assembly programming on other architectures (ARM, AVR, 6502, Z80). I'm having issues trying to share hub memory locations between cogs. And let me preface with I do not want to use spin2. I can't say that I'm a fan of there seeming to be no way around spin2 (please correct me if I'm wrong) - It appears that you have to still wrap and invoke your assembly code in spin2.

Welcome to the forum. I've been here since before the P2 existed in physical form and some of my ideas are in the chip. I'm an assembly language programmer who has never used Spin2 so don't feel alone! Sharing hub RAM between two cogs is simple using PASM2.

I use Flexspin to assemble my programs. I always create 4KB binaries by filling to the end of LUT RAM using long 0 [$400-$] even if I don't need all the space. I concatenate two 4KB binary files into one 8KB file and load it into the P2 after a reset via the serial pins using LoadP2 starting at hub address $00000. Cog 0's register RAM is loaded and started automatically. If any cog uses LUT RAM then it must load this itself from hub RAM and I use the following code:

'ptrb = cog program start address
'in hub RAM after coginit

        add     ptrb,##$800
        setq2   $1ff
        rdlong  0,ptrb

Cog 0 can start cog 1 with

        coginit #1,##$1000

as cog 1 binary is directly after cog 0 binary in hub RAM.

HTH

evanh

The Prop2 IC, unlike Prop1 IC, was designed and produced before Spin2 was developed. The Prop2 boots in traditional fashion of loading a binary blob of machine code loaded at address 0 in main memory (hubRAM). The loading method is one of three ways: Serial comport on pins P62/P63, SPI memory chip on pins P58..61, or SD card (in SPI mode) can load from FAT16/32 formatted on same pins P58..61.

As for the Prop2 programming environments as presented by Pnut/Proptool:

• If Spin2 elements are used then Spin environment is loaded and the Pasm code will be controlled from Spin.
• If Pasm2 is alone in source form then Spin environment is not loaded and the Pasm code is on its own.

TonyB_

A few points:

1. Editing an existing post the next day or later seems to count as a new message. Must be annoying to others to click on a topic and find out there is no new message.
2. Often when I edit a post I have to scroll up through masses of whitespace before I see any text. Is this fixable?
3. Is there a real need for a separate PASM2/SPIN2 (P2) category? I don't think so and I've never thought so. Perhaps SPIN2 separate but PASM2 could go in the Propeller 2 category.