As I thought. If I use a hex editor on a text file and insert one of those new fangled "hard spaces" then I find that my normal editors Vim, Emacs, Kedit, etc have no idea what it is.
There are two Cogs, one in SPIN and one in PASM
The spin cog sets a value at say PAR(3)
The PASM cog reads the value into a countdown delay to pulse a signal
If the value has not been set by the SPIN cog by the time the PASM cog reads it
it is read it as a 0 and the loop now takes 53 minutes to run down. Once the
timer runs down, the next read is fine.
The PASM cog always beats the SPIN cog to it because it is
hundreds to time faster than the SPIN cog.
Your two routines need to have a protocol of some sort (very simple in this case) to use in the mailbox (the area used to exchange data).
For this example: If PASM COG finds 0, that's invalid and it needs to wait until it becomes non-zero indicating a valid delay.
In other cases, you may want to have a memory cell that the PASM routine sets to some value indicating it is ready to receive commands. Whenever you have two or more things working together, they need to communicate both data and intentions.....just like people! How it is done is up to the programmer to use what's best for the situation.
What you have told me there is that you have one LONG to communicate a 32 bit number between two parallel processes, which it does very well by all account.
BUT you also imply that the value zero is not perhaps a valid value in this system.
What to do?
1) Assume that zero is not a valid input for the delay COG. That is to say that when it starts up if it sees a zero it just loops until that value changes from zero. It then uses the value as normal. When done with it's delay business it waits in the loop again for that value to become non-zero again.
It's up to you if the delay cog sets the value to zero when it is done so that the master cog can set a new value when it is ready or simply reuses the old value again. Depends what you want to do. But basically a zero means "don't do anything".
2) What if all the possible values of that input are valid inputs? Perhaps not useful for you delay example but perhaps some other task. Then you are going to need a second LONG to hold a "flag" or "semaphore" which is either one or zero. In this case the reader cog waits for the flag LONG to become non-zero before reading the value LONG and getting on with the work. When done it goes back to looping on the flag.
Phil its is a great idea but right now I am trying so hard to get this done
that nothing else can take even a second if I am to maintain my sanity.
As you can tell from the forum, its getting close.
>There are two Cogs, one in SPIN and one in PASM The spin cog sets a value at say PAR(3)
When you say PAR3, I assume you mean the third long reserved Spin Var and the address of the first is the one passed to Pasm in PAR.
But if this cog is only reading one var,
you could just as well pass on the address of the 3rd var in the first place and the t1 and +8 in code below is not needed, just use rdlong delay,PAR instead.
Spin do: delay := 12000 ' delay is the third long var reserve in 'mailbox'
Pasm do
mov t1,PAR
add t1,#8 ' hubram is in bytes (first is at 0, second at +4, third at +8)
label1 mov cnt,#46 ' to shadow just for overhead
add cnt,cnt
label2 rdlong delay,t1
cmp delay,#46 wc
if_c jmp #label1 ' values between 0-45 are to small
waitcnt cnt,delay
xor outa,pinmask
jmp #label2
you could just as well pass on the address of the 3rd var in the first place and the t1 and +12 in code below ...
The 3rd variable is at offset +8, and - this being for beginners - you might want to explain how you arrived at 46 as a minimum delay. While you could have picked e.g. 100 to be safe, people (are supposed to) play around with the setup and then wonder why it stops working.
Rule1 for waitcnt:
You can not have your cntvalue to be lower than the hardware cnt by the the time you get to the waitcnt instruction.
clocks:
22.. rdlong delay,t1
04.. cmp delay,#46 wc
04.. if_c jmp #label1
04.. waitcnt cnt,delay (value is latched at clock 03..) delay is added to shadow-cnt at exit
04.. xor outa,pinmask
04.. jmp #label2
22 for hub access is in worse case scenario, if you count your clock cycles and always get 8,24,40.... cog cycles in between, you could use 8 clocks for hub access
If my calculations are right the lowest acceptable value would be 42
would this one now not be
10.. rdlong delay,t1
As the cycles below now are 22 total and next window is only 2 cycles away?
True for that specific case (loop taking 32 cycles total, ideal entry conditions). Then use a 33 cycle loop count and you're back at the point where you need 45 to keep it going reasonably. I think for this purpose we should stick with the worst case timing.
Here is my code for transferring a data array from listing code to the hub memory accessible via PAR
and displaying it on the PST.
It avoids indexing (which I was having trouble with) for now and its done in SPIN
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
Vars =20 'hub variables to be displayed
VAR
long p_Val[vars],subscr
OBJ
fds : "FullDuplexSerial"
PUB Go|x
fds.start(31,30,0,115200) 'start PST console at 115200 for output
transfer
repeat
fds.tx(1) 'home
fds.str(string("Displaying Hub variables")) 'heading
fds.str(string(" ")) 'spaces to erase old data overflow
fds.tx($d) 'new line
fds.tx($d) 'new line
repeat subscr from 0 to vars 'loop to display all vars
fds.dec(subscr) 'print value as decimal value
fds.str(string(" ")) 'spaces to erase old data overflow
fds.dec(P_Val[subscr]) 'print to the PST in binary
fds.tx($d)
waitcnt(clkfreq/60+cnt) 'wait 1/60.
x:=x+1 'increment counter. (This routine clears up the screen )
if x>100 'decision point (by erasing extraneous lines of )
fds.tx(16) 'clear screen (bottom of PST display every 100 loops)
x:=0 'reset counter (Needed only once in most cases. )
[COLOR=#ff0000][B]Pub Transfer
repeat subscr from 0 to 15
P_Val[subscr]:=mydata[subscr][/B][/COLOR]
[COLOR=#ff0000]DAT
mydata long 15, 313, 364, 46754, 85868, 969690, 3345, 345437, 995969
long 23, 44567, 234, 5, 887, 1988, 47475475[/COLOR]
Fit[COLOR=#000000] [/COLOR]
This completes all the code in the book
Only the Index still to go now.
I don't have an inclination to understand what that code does but:
As far as I can tell all you have done is move some data from a DAT section in HUB memory to a VAR section.
Which may be of interest to someone who wants to initialize their ojects data but is nothing to do with PASM programming. Which I thought this book was all about.
As for the "It avoids indexing" thing, I presume you mean using self modifying code in PASM to access arrays in COG or HUB. You might think this too much for a beginners book on PASM but I would suggest it is esential.
There is no reason to have a FIT statement when you are not loading code into COG. A DAT section sitting in HUB can be as long as it likes. A FIT makes no sense with out a previous ORG.
THE BOOK IS DONE. 276 pages plus all code listings in one text file by email to buyers.
Printers will take two weeks so it should ship by end of month. Will be book post US mail.
$35.00 each includes everything for US residents. No insurance on book posts.
Paypal only
Will send first copy to Parallax. Don't yet know if they will want to handle it.
Amazon etc will not be selling it.
I will send a personal note to all who had expressed and interest in getting a copy tomorrow.
Just got word from the printers. They are scheduled to ship books to me on the 22nd of this month.
My email address is harprit.sandhu@gmail.com for PayPal payments. $35.00 includes
everything in the USA. Mailed from Champaign Il. 61820 on about the 25th of March '13.
274 page book plus a file with ~100 pages of fully documented code you can cut and paste from.
Harprit.
When you select the documentation listing it tells you how long the program is.
Does this include the objects that were called under OBJ and if not how can you detect an overflow of code in hub memory (not cog FIT)?
When you call a method inside an OBJ does it call just the method or the whole OBJ into hub memory.
Where is such compiler specific information available to beginners?
H
Comments
As I thought. If I use a hex editor on a text file and insert one of those new fangled "hard spaces" then I find that my normal editors Vim, Emacs, Kedit, etc have no idea what it is.
Here is how I first found the problem.
There are two Cogs, one in SPIN and one in PASM
The spin cog sets a value at say PAR(3)
The PASM cog reads the value into a countdown delay to pulse a signal
If the value has not been set by the SPIN cog by the time the PASM cog reads it
it is read it as a 0 and the loop now takes 53 minutes to run down. Once the
timer runs down, the next read is fine.
The PASM cog always beats the SPIN cog to it because it is
hundreds to time faster than the SPIN cog.
H
For this example: If PASM COG finds 0, that's invalid and it needs to wait until it becomes non-zero indicating a valid delay.
In other cases, you may want to have a memory cell that the PASM routine sets to some value indicating it is ready to receive commands. Whenever you have two or more things working together, they need to communicate both data and intentions.....just like people! How it is done is up to the programmer to use what's best for the situation.
What you have told me there is that you have one LONG to communicate a 32 bit number between two parallel processes, which it does very well by all account.
BUT you also imply that the value zero is not perhaps a valid value in this system.
What to do?
1) Assume that zero is not a valid input for the delay COG. That is to say that when it starts up if it sees a zero it just loops until that value changes from zero. It then uses the value as normal. When done with it's delay business it waits in the loop again for that value to become non-zero again.
It's up to you if the delay cog sets the value to zero when it is done so that the master cog can set a new value when it is ready or simply reuses the old value again. Depends what you want to do. But basically a zero means "don't do anything".
2) What if all the possible values of that input are valid inputs? Perhaps not useful for you delay example but perhaps some other task. Then you are going to need a second LONG to hold a "flag" or "semaphore" which is either one or zero. In this case the reader cog waits for the flag LONG to become non-zero before reading the value LONG and getting on with the work. When done it goes back to looping on the flag.
Got it
Closed
H
@Phil
Phil its is a great idea but right now I am trying so hard to get this done
that nothing else can take even a second if I am to maintain my sanity.
As you can tell from the forum, its getting close.
Thanks
H
When you say PAR3, I assume you mean the third long reserved Spin Var and the address of the first is the one passed to Pasm in PAR.
But if this cog is only reading one var,
you could just as well pass on the address of the 3rd var in the first place and the t1 and +8 in code below is not needed, just use rdlong delay,PAR instead.
Spin do: delay := 12000 ' delay is the third long var reserve in 'mailbox'
Pasm do
mov t1,PAR add t1,#8 ' hubram is in bytes (first is at 0, second at +4, third at +8) label1 mov cnt,#46 ' to shadow just for overhead add cnt,cnt label2 rdlong delay,t1 cmp delay,#46 wc if_c jmp #label1 ' values between 0-45 are to small waitcnt cnt,delay xor outa,pinmask jmp #label2Right
Please tell me where the MAILBOX is located.
H
VAR 'Global variable declarations
long mydata1 ' these 3 longs MUST be contiguous
long mydata2
long delay
cognew(@entry, @mydata1) ' the mailbox starts at mydata1 location, the @ is to get the address and not the value that mydata1 have.
Rule1 for waitcnt:
You can not have your cntvalue to be lower than the hardware cnt by the the time you get to the waitcnt instruction.
clocks:
22.. rdlong delay,t1
04.. cmp delay,#46 wc
04.. if_c jmp #label1
04.. waitcnt cnt,delay (value is latched at clock 03..) delay is added to shadow-cnt at exit
04.. xor outa,pinmask
04.. jmp #label2
22 for hub access is in worse case scenario, if you count your clock cycles and always get 8,24,40.... cog cycles in between, you could use 8 clocks for hub access
If my calculations are right the lowest acceptable value would be 42
clocks:
23.. rdlong delay,t1
04.. cmp delay,#46 wc
04.. if_c jmp #label1
06.. waitcnt cnt,delay (first comparison in 4th cycle, 2 cycles exit path) delay is added to shadow-cnt at exit
04.. xor outa,pinmask
04.. jmp #label2
would this one now not be
10.. rdlong delay,t1
As the cycles below now are 22 total and next window is only 2 cycles away?
Though It may depend on what value delay had before.
Entry value should be left at 46
and displaying it on the PST.
It avoids indexing (which I was having trouble with) for now and its done in SPIN
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 Vars =20 'hub variables to be displayed VAR long p_Val[vars],subscr OBJ fds : "FullDuplexSerial" PUB Go|x fds.start(31,30,0,115200) 'start PST console at 115200 for output transfer repeat fds.tx(1) 'home fds.str(string("Displaying Hub variables")) 'heading fds.str(string(" ")) 'spaces to erase old data overflow fds.tx($d) 'new line fds.tx($d) 'new line repeat subscr from 0 to vars 'loop to display all vars fds.dec(subscr) 'print value as decimal value fds.str(string(" ")) 'spaces to erase old data overflow fds.dec(P_Val[subscr]) 'print to the PST in binary fds.tx($d) waitcnt(clkfreq/60+cnt) 'wait 1/60. x:=x+1 'increment counter. (This routine clears up the screen ) if x>100 'decision point (by erasing extraneous lines of ) fds.tx(16) 'clear screen (bottom of PST display every 100 loops) x:=0 'reset counter (Needed only once in most cases. ) [COLOR=#ff0000][B]Pub Transfer repeat subscr from 0 to 15 P_Val[subscr]:=mydata[subscr][/B][/COLOR] [COLOR=#ff0000]DAT mydata long 15, 313, 364, 46754, 85868, 969690, 3345, 345437, 995969 long 23, 44567, 234, 5, 887, 1988, 47475475[/COLOR] Fit[COLOR=#000000] [/COLOR]This completes all the code in the book
Only the Index still to go now.
H
As far as I can tell all you have done is move some data from a DAT section in HUB memory to a VAR section.
Which may be of interest to someone who wants to initialize their ojects data but is nothing to do with PASM programming. Which I thought this book was all about.
As for the "It avoids indexing" thing, I presume you mean using self modifying code in PASM to access arrays in COG or HUB. You might think this too much for a beginners book on PASM but I would suggest it is esential.
There is no reason to have a FIT statement when you are not loading code into COG. A DAT section sitting in HUB can be as long as it likes. A FIT makes no sense with out a previous ORG.
THE BOOK IS DONE. 276 pages plus all code listings in one text file by email to buyers.
Printers will take two weeks so it should ship by end of month. Will be book post US mail.
$35.00 each includes everything for US residents. No insurance on book posts.
Paypal only
Will send first copy to Parallax. Don't yet know if they will want to handle it.
Amazon etc will not be selling it.
I will send a personal note to all who had expressed and interest in getting a copy tomorrow.
Will announce it again when the books get here.
HSS
I know it's been a long road getting to this point!
Paul
My email address is harprit.sandhu@gmail.com for PayPal payments. $35.00 includes
everything in the USA. Mailed from Champaign Il. 61820 on about the 25th of March '13.
274 page book plus a file with ~100 pages of fully documented code you can cut and paste from.
Harprit.
I am looking forward to reading it cover to cover.
cheers,
rich
Right now I have my plate full with lot of catch up I need to do.
H
A direct link to paypal payment could prove helpful to others.
Paul
Same as my email address
harprit.sandhu@gmail.com
H
Done and done!
Does this include the objects that were called under OBJ and if not how can you detect an overflow of code in hub memory (not cog FIT)?
When you call a method inside an OBJ does it call just the method or the whole OBJ into hub memory.
Where is such compiler specific information available to beginners?
H