Memory Usage in Propellor
StephenMoore
Posts: 188
Back to the beginners circle...
Does the DAT variable section of a Spin program load main Prop RAM or Cog RAM?
Are DAT variables equally accessible by Spin routines and Assembly programs during run-time?
Does the DAT variable section of a Spin program load main Prop RAM or Cog RAM?
Are DAT variables equally accessible by Spin routines and Assembly programs during run-time?
Comments
variables in the VAR-section are "local" within the *.SPIN-file they are defined in.
DAT-variables are GLOBAL to all *.SPIN-files but can be accessed only over a pointer
You can pass this pointers to assembly-code.
If a cog runs assembly-code all PASM-commands effect only COG-RAM except the RDLONG/WRLONG-commands that read write to HUB-RAM
keep the questions coming
best regards
Stefan
Nothing gets loaded to COGs RAM unless your program does it with cognew/coginit. Except of course COG 0 is loaded with the Spin interpreter at start up which then runs you top level object.
A COG that you start with Spin can access the vars and dat in it's object. Be aware that all instances of the same object share the dat section but get their own var section.
A cog that you start with PASM can also access vars and dat with wrlong, rdlong etc. But then you have to arange for the PASM to get the addresses of the things you want to access.
Any Spin or PASM can actually access any locatin in HUB if it knows what address to use.
PUB Start {{ Initialize the two LED on/off periods and start the assembly cog. }} ping_period := clkfreq * 11 / 16 'Set periods for both LEDs. pong_period := clkfreq * 13 / 16 cognew(@pingpong, 0) ''=======[ Assembly Code ]======================================================== DAT {{ This code sets up and executes to coroutines, each controlling a different LED. The two LEDs toggle with different periods. }} pingpong or dira,ping_mask 'Enable PING_LED output. or dira,pong_mask 'Enable PING_LED output. mov ping_time,cnt 'Initialize timers. mov pong_time,ping_time '-------[ ping coroutine ]------------------------------------------------------- ping call #swap 'Give the pong coroutine a chance. 'Pong coroutine returns here. mov acc,cnt 'Is it time to change state? sub acc,ping_time cmp acc,ping_period wc if_c jmp #ping ' No: Keep checking. add ping_time,ping_period ' Yes: Add to get the next time. or outa,ping_mask ' Turn LED on. ping_on call #swap 'Give the pong coroutine a chance. 'Pong coroutine returns here. mov acc,cnt 'Is it time again to change state? sub acc,ping_time cmp acc,ping_period wc if_c jmp #ping_on add ping_time,ping_period ' Yes: Add to get the next time. andn outa,ping_mask ' Turn LED off. jmp #ping 'Loop back... '-------[ pong coroutine ]------------------------------------------------------- pong mov acc,cnt 'Is it time to change state? sub acc,pong_time cmp acc,pong_period wc if_nc add pong_time,pong_period ' Yes: Add to get next time. if_nc xor outa,pong_mask ' Invert output pin. call #swap 'Give the ping coroutine a chance. jmp #pong 'Loop back... '-------[ coroutine swapper ]----------------------------------------------------- swap swap_ret jmp #pong 'Initialize swap to point to pong. '-------[ variables ]------------------------------------------------------------- ping_mask long 1 << PING_LED pong_mask long 1 << PONG_LED ping_period long 0-0 pong_period long 0-0 ping_time res 1 pong_time res 1 acc res 1Apparently the Spin program rights to the DAT variuables and the PASM program is able to access them as well.
Can anyone shed some light on this?
After starting the COG there is no link! This means that any change in these variables won't affect the PASM code.
SPIN always works in HUB-RAM and PASM always works in COG-RAM (except when using wr/rd... instructions)
Of course you could now set different values and start a different COG. After loading the HUB-RAM into the COG-RAM there is also no link. And of course there is also no link between the first and the second COG started with this program.
This is some kind of an injection of parameters into the memory that's loaded into the COG. It's usefull if you have parameters that only have to be set once. This way you don't need to waste COG-RAM for code that fetches these values from somewhere.