You keep mentioning hub(0) (long[par][0]). But what your program actually does is reading from long[par][5] and write to long[par][6]. If reading ends up as 0 then the djnz will take a while to complete.
Yes, you do set a value for P_Val[5] later in your display loop but by that time the PASM cog is long up and running and - having read a 0 from said location - will block for several minutes in Be_d.
Help!
Wrapping this thing up is getting more complicated than I wanted or expected it to be!
Since I can not reasonably expect just one person to answer all these questions,
will you guys please respond till they all get answered.
I read under DAT and FIT in the manual and it less expansive and more cryptic than it need to be so...
I have some SPIN code
Under it I have DAT code for the PASM programs
There are 3 programs in the DAT area. Each uses constants and variables.
Each is called with Cognew(@Program, @Variable)
Should there be a Org 0 at the beginning of each PASM program area?
Does FIT test for the FIT in each Cog started?.
Should there be a FIT at the end of the SPIN part of the code?
Should there be a FIT statement at the end of each PASM program segment?
Where should the variables for each program be placed relative to the DAT and FIT statements for that program?
Is it accurate to say that since each Cognew starts a new Cog only 7 PASM Cogs can be started unless some shut down first?
Does starting Cogs include Objects that were called under OBJ? If not where is this code stored? What about the Cogs started by them
.
Harprit Singh Sandhu
You can call me at 217 369 8737 (CST) if you would rather
discuss this in real time or comment expansively, directly to me.
Should there be a Org 0 at the beginning of each PASM program area?
Yes. When code is loaded to COG it is loaded at location zero of the COG. So you should have an ORG 0 at the start of every such COG program no matter how many are in your DATA section.
There are reasons to use something other than zero in ORG, such as when loading overlays but that may be a bit much for a beginners book.
Think of ORG as a promise to the assembler that when the code ends up in COG it will be sitting at the specified address in COG. (Normally zero). This of course is very different than whatever address it may have as it sits in HUB. So the assembler needs to know. That is what ORG is for.
Does FIT test for the FIT in each Cog started?.
FIT makes sure the code between a given ORG address and the next FIT statement will fit in the length given to FIT. Basically it ensures the PASM code never runs off the end of COG memory space. Best to include a FIT after every ORG.
Should there be a FIT at the end of the SPIN part of the code?
No, it has nothing to do with SPIN.
Should there be a FIT statement at the end of each PASM program segment?
See above.
Where should the variables for each program be placed relative to the DAT and FIT statements for that program?
Be carefull. Eveything a section of COG code needs, both code and variables, should be between ORG and FIT statements. This is so that the whole caboodle is loaded into COG.
Consider that if you have two sections of PASM code each surrounded by ORG and FIT but you have variables in one section being referenced from another. That will go horribly wrong.
ORG 0
start_1
mov temp_1, someData ' This should works
jmp start_1
someData long 10
temp_1
FIT
ORG 0
start_2
mov temp_2, someData 'This should fail, gets the wrong data.
jmp start_2
temp_2
FIT
Do say if you don't see why this may be so.
Is it accurate to say that since each Cognew starts a new Cog only 7 PASM Cogs...
[/code]
No. There is no reson one of those 7 running PASM COGS can't COGINIT the COG that is running the original Spin interpreter with another PASM program. The you have 8 PASM COGS.
Does starting Cogs include Objects that were called under OBJ?
[/code]
For get about objects when writing PASM code. There are no objecst in PASM.
Do not confuse Spin objects with COGs. You can have many COGs running the same method of an object. You can have many Spin objects that are never never starting any COGs. Their methods all get run in the calling objects COG. COGs and objects are orthogonal concepts.
Should mention in book that org and fit are just compiler instructions, and having nothing to do with spin or pasm.
Org in an assembler tells what the base address is as to configure direct address and those relative addresses like PC +-511 etc.
The cogs uses only absolute addresses, so set org to 0.
Only time to use a different value, would be if you have for example have a code loader at org0 (6 longs big)
that will reload codes at will using rdlong. Each of these code snippets should have org 6 at start.
Let me clarify the cogs thing a bit so I can get it right for the beginners.
There are 8 cogs
Each can run one program that may have subroutines in it. Each one can call
and stop cogs etc but 8 is the limit at any one time and some are called when
we rerer to them under OBJ.
Have we now used three cogs or not? Meaning the main SPIN cog
that started everything and the two"what ever" that were referred to under OBJ.
These have to execute from code in a cog somewhere (and they eat up memory somewhere)
(Memory and cogs are the sort of the things we are short on So needs managing.)
Do they each use up a cog and if they themselves have OBJs called within them
do they then also use even more cogs.
Meaning that beginners need to understand that when they write code
they don't want to be careless about using up cogs and memory.
Since we cannot control space used by OBJs called, some care is warranted
You have only 8 cogs.
OBJ don't have to start a cog, they could be plain Spin subroutines that don't need Pasm to work.
It's normally a call to objname.start that will set up any Pasm cog(s) if needed.
So the OBJs eats space within the 512 longs long SPIN cog they are called in?
The more you call the less memory you have in your SPIN cog to write your own code?
And they cannot be called from PASM.
As I said, don't confuse COGs and obects.
You can easily write an object that has no cognew or cogstart in it. Then if it is included in the obj section of something else and it's methods called they all run in the same COG as the parent object.
On the other hand, as you have seen, and object can start more than one COG. Those cogs could be running methods of the tthat SPIN object or PASM.
All OBJs you add are complied in to one single bytecode file that can be up 32KB.
Calling them often does not add code size, as they are bytecode subroutines.
Pasm data is also included in this 32K, with some smart coding you could reclaim this hub space after the cogs have been started.
Spin have fixed location of it's varibles in hub ram (after compiling)
So if the Spin pass along the address of a variable in PAR, pasm can change it or read it at will.
In your example above you asked if we would now be running 3 COGs.
Well without reading the documentation or the code of the included objects we don't know just by looking at that OBJ declaration. Why assume only 3 COG? Perhaps that read4Pots object actually starts 4 COGS to do the job.
Indenting being so important in SPIN....
Is there a program similar to LINT in C that beginners can use to reformat their
code so that they can see indenting errors more clearly.
It would be a very useful tool but I would rather not write it right now.
Further, I would say that it is impossible to write one.
Because Spin has used the seriously brain damaged idea of using while space to delimit blocks it is impossible to tell if a level of indentation is missing because of a typographic / formatting error or if that is actually how the program logic should be. It would be impossible for such a program to know the intention of the author.
I think the best that could be done, and a good idea, is a program to check that only spaces are used or alternatively that only tabs are used. This is what jslint does for javascript.
If some program, for example used for typesetting your book, mangles the indentation. The is no way to automatically correct it. We see this on the forums everyday when people have not used the code tags.
What is a tab? In my editor it might be 4 spaces, in your editor it might be 8. That difference can change the meaning as we exchange code.
How would you know what was intended if I give you my code and the ndentation looks all wonky.
pub start (a, b) | x, y
if a == b
x := 1
else
y = doSomethingElse(a, b)
x := 2
return x
In the above code, purposely not using code tags, what should it return?
With such a simple example you might guess from reading it but you can never be sure.
With more complex code it becomes impossible.
Convert all spaces to non-breaking spaces. These are a different character code and are generally respected in most editing programs.
You can use an editor that will display spaces in a highlight color to sort out whether or not you've got it right. A simple method is to use the character map tool to get one into the clipboard, then use find / replace in PropTool to get them all converted over.
Did this a while back to post up some ASCII art on a forum that had very minimalistic display tagging. It did have a code operator, but in general, would not avoid mangling spaces. The non-breaking one turned out to be just the trick.
In Linux, Kedit will display spaces in highlight color, if that makes better sense. I'm sure many editors do. Personally, I'm kicking around starting to use Sublime, and now I wonder whether or not that's a feature or plug in option.
Yep, kedit and such are great for seeing what you have in your Spin files as you create them.
Still they are no help in "pretty printing" a Spin file that has had it's spacing mangled by a forum engine or other processing.
Also they can't help you when you inadvertently drop an indent when editing your code And afetr that the compiler cannot tell you about it either.
For these reasons, and others, I would prefer to have visible block delimiters in any language.
So there is not tool to convert Spin code to a Word formatted document?
What font are those grey indentions lines/forks?, they are not part of the parallax font.
Tony
"Control i" will turn those on and off. They do help in finding mistakes but automatic formatting would help other mistakes and pretty things up.
Code can be copied back and forth to Word
Heater
One interesting thing is that the user knows where his tabs are so these can be entered into the LINTlike program by him and then it will be possible to convert to spaces with no problems. Of course others could not reformat text they did not have the tab locations for.
Rich
I estimate that the book will be back from the printers some time in March. I am self publishing it.
Now that I have been enlightened AGAIN I have to go back and fix all the code in the book. (Its well over 100 pages of line by line FULLY documented code) and then test each program to make sure it works and then put it all back in the book and redo and index work...... Its endless but I have to get it done. I am next to burned out. I have quite a few orders already do I am committed.
For now I am going with Tony on how the OBJ files are handled and not worry about it. I need to get done.
RWgast
I do not understand what motivated all the unwarranted, negative talk about my SPIN book. All it does it keep guys like me from writing about the propeller. The propeller needs lots of independent outside support. Its an unbelievable chip. Unwarranted remarks by people who had not even seen much read the book did not help. Go by the amazon reviews. And Thanks for you support.
I just got this in the mail re the SPIN book. Out of the blue...not solicited.
This book was panned by some on this forum.
James Cullins ...........@gmail.com>
8:05 AM (2 hours ago)
to me
I really enjoyed your book. I used a regular servo motor and encoder to do the exercises. I did learn a lot from it.I wore one book out, the binder was shedding sheets so I bought a second one.
Thanks for a very detailed book on closed loop control.
Jim Cullins
>Code can be copied back and forth to Word
And the grey/gray forks are still visable in Word? (I could not get them visable)
In a book i would like to see these forks.
Yes they would be nice in the book but no dice!
However when you copy my programs from the internet and paste them into the PT they will come alive. So we get half way goodies.
This business of cogs getting ahead of one another is a problems that needs
a solution beginners can digest.
I have been thinking hard about this since potatohead's earlier comments.
Here is a possibility I would like comments on
This is about keeping the cog starting order under control using a pseudo
lock system
Suppose there are 2 SPIN cogs and 2 PASM cogs that need to run
I make the reasonable assumption that Hub memory as referenced by
PAR is all 0s.
If not I will need to find a solution that will take care of it
Would it work if every cog except the first one to start was inhibited
by a loop that watched PAR(1)..PAR(2).....with one memory location
for each program
As long a PAR(1) was 0 the second program would stay in a loop
at the head of its code.
As long a PAR(2) was 0 the third program would stay in a loop at
the head of the code
As long a PAR(3) was 0 the fourth program would stay in a loop at
the head of the code. And so on
After a while the first program would release the next program that
must start by setting its key to a 1
That program in turn would start the next program needed and so
on till all program were on
No programs would use the dedicated PAR locations ever
The programs would never loop back to their starting loops that
keep them locked.
I can see that there still might be problems but this might be OK
for beginning programmers.
Would this work?
Is there another way?
Is there a better way?
Rich
I estimate that the book will be back from the printers some time in March. I am self publishing it.
Now that I have been enlightened AGAIN I have to go back and fix all the code in the book. (Its well over 100 pages of line by line FULLY documented code) and then test each program to make sure it works and then put it all back in the book and redo and index work...... Its endless but I have to get it done. I am next to burned out. I have quite a few orders already do I am committed.
For now I am going with Tony on how the OBJ files are handled and not worry about it. I need to get done.
As someone who has expressed an interest in ordering your book, it seems to me that if you had a link where purchasers could download the tested Spin source code, that might sidestep the need for you to do a lot of rework on Word files.
Yes, it's a problem. Tough one for me, because I really like the lean input possible without those delimiters. I've been writing a few programs for work related things, and there they are... Kind of painful compared to assembly / SPIN.
An editor that used non breaking spaces would help a lot. Hell of a kludge, but an effective one. Those characters are respected nearly everywhere, and they render clear or can be colored too.
IMHO, a switch to the non-breaking space would do SPIN editors a lot of good. IMHO, ordinary "just put spaces in it" output could be a save as option, for those who want pure text.
Convert 'n strip tabs on the way in, leaving non-breaking spaces there for the longer haul will print, paste to forum and provide an reasonable delimiter all in one package. Use the non-breaking, until the line begins, then use spaces in the line.
What do you mean "this business of cogs getting ahead of one another"? Your problem statement is too vague and therefore we can have no idea if
the proposed solution is sensible or not.
No matter if your COGs are running Spin or PASM the issue generally is "how does one coordinate activity between parallel running processes?".
There are many solutions depending on what you are wanting to do. For example:
a) Simple case.
A COG is set running and all it has to do is read a sensor (ADC or whatever) and deliver provide resulting number values.
Another COG is set running and all it has to do is send those number values down a serial link or write them into a video display.
Solution: Set aside a LONG in HUB, have the first cog write values there whenever it gets them. Have the second cog read that LONG whenever it likes and do whatever with the numbers.
Note: This may mean certain updates of the values are skipped over and missed out but we may be just happy with that as we don't care about past values only the latest ones.
b) Harder case.
As above but the sensor reading COG must deliver 2 or more LONGs (perhaps from 2 or more sensors) AND those values have to come in pairs. i.e. reading of sensor A and sensor B at an instant T must be processed together.
Solution: Set aside two LONGs for the two readings. BUT now we have to be sure that the reader COG does not read A and then the writer cog updates B prior to the reader getting around to reading A.
We can ensure that does not happen by using Propeller locks. However we can also do it with a flag or "semaphore".
So, use a third LONG for that flag. Arrange that the flag is initially zero.
When the writer COG has data it always waits in a loop until that flag is zero. Then it writes the two data longs and sets the flag to one.
When the reader COG want's data it always waits for that flag to become one. Then it reads the two data longs and sets the flag back to zero.
At which point the writer cog sees it can write new data and the processes repeats.
Something similar to the flag technique can also be used to issue commands from a "master" cog to a "slave" cog. Say the slave provides some service like, floating point calculations or interfacing to an external RAM. Here the "flag" long might be a command value, say one=read RAM, two=write RAM, zero= do nothing. The slave cogs waits in a loop for a non-zero value of that command long and then does whatever action the long value implies. Having done it's job it sets the command value back to zero(may also write a result somewhere) . Seeing a zero the "master" cog can read the results and knows it can issue another command if it likes.
c) Still harder case.
A bunch of cogs are reading and writing a data structure in HUB and that data structure is required to be in some consistent state. Could just be an array of values that the cogs have to shuffle around to insert/delete other values.
Here you will need locks.
d) A very elegant case. The Full Duplex Serial object maintains receive and transmit buffers. They are both cyclic buffers with "head" and "tail"
pointers. You might think that locks would be required to stop the readers and writers mangling such a complex data structure. But no, it's all done with careful comparisons and manipulations of those pointers. As long as there is only one reader and one writer it works. Well worth studying.
e) Impossible cases.
There are those around here who synchronise cog activity to the nano second, perhaps for video generation, It's all done with flags and cycle counting and counters. Actually I have no idea how it is done. I would imagine this is not for a beginners book.
In general, think "mail boxes" containing both data and commands. Or think cyclic buffers like FDS. All accessed through PAR pointers. Don't forget locks when contention may be a problem.
An editor that used non breaking spaces would help a lot.
You know, I really had to think about what you are saying there for a minute. I have never edited code with anything that even knew the difference between a "hard space" and a "soft space". If I type a space into my code I mean a space. If the editor decided to compress multiple spaces into one or any other such nonsense without my express permission or command it would get deleted immediately.
I can just about stomach that spaces get vaporized in word processors or web browsers, but then putting text between HTML tags or into a word document is implicitly giving it my permission to do so.
Hell of a kludge, but an effective one.
Again, I don't follow you. Having all spaces as "hard spaces", that is to say "normal spaces", is what text editors have been doing since the dawn of time.
Seems somewhere in the past 100 years I missed a memo. What I think of as a "space" is ASCII code 32. They have always been "hard" to me. If I hit the space bar in Vim or Emacs or Kate or whatever that is what I get. But no, somewhere along the line someone decided to make 32 "soft" and have a new character for hard spaces, ASCII code 255.
I don't have the time to look at these problems in detail but glancing back at that post it seems to be a total confusion about how to use Spin syntax to access things and how to use PAR to access things.
Those issues have to be resolved before getting on to the business of "preventing cogs getting ahead of each other" in ways that I outlined above.
Comments
Yes, you do set a value for P_Val[5] later in your display loop but by that time the PASM cog is long up and running and - having read a 0 from said location - will block for several minutes in Be_d.
Wrapping this thing up is getting more complicated than I wanted or expected it to be!
Since I can not reasonably expect just one person to answer all these questions,
will you guys please respond till they all get answered.
I read under DAT and FIT in the manual and it less expansive and more cryptic than it need to be so...
I have some SPIN code
Under it I have DAT code for the PASM programs
There are 3 programs in the DAT area. Each uses constants and variables.
Each is called with Cognew(@Program, @Variable)
Should there be a Org 0 at the beginning of each PASM program area?
Does FIT test for the FIT in each Cog started?.
Should there be a FIT at the end of the SPIN part of the code?
Should there be a FIT statement at the end of each PASM program segment?
Where should the variables for each program be placed relative to the DAT and FIT statements for that program?
Is it accurate to say that since each Cognew starts a new Cog only 7 PASM Cogs can be started unless some shut down first?
Does starting Cogs include Objects that were called under OBJ? If not where is this code stored? What about the Cogs started by them
.
Harprit Singh Sandhu
You can call me at 217 369 8737 (CST) if you would rather
discuss this in real time or comment expansively, directly to me.
There are reasons to use something other than zero in ORG, such as when loading overlays but that may be a bit much for a beginners book.
Think of ORG as a promise to the assembler that when the code ends up in COG it will be sitting at the specified address in COG. (Normally zero). This of course is very different than whatever address it may have as it sits in HUB. So the assembler needs to know. That is what ORG is for. FIT makes sure the code between a given ORG address and the next FIT statement will fit in the length given to FIT. Basically it ensures the PASM code never runs off the end of COG memory space. Best to include a FIT after every ORG. No, it has nothing to do with SPIN. See above. Be carefull. Eveything a section of COG code needs, both code and variables, should be between ORG and FIT statements. This is so that the whole caboodle is loaded into COG.
Consider that if you have two sections of PASM code each surrounded by ORG and FIT but you have variables in one section being referenced from another. That will go horribly wrong.
ORG 0 start_1 mov temp_1, someData ' This should works jmp start_1 someData long 10 temp_1 FIT ORG 0 start_2 mov temp_2, someData 'This should fail, gets the wrong data. jmp start_2 temp_2 FITDo say if you don't see why this may be so.Org in an assembler tells what the base address is as to configure direct address and those relative addresses like PC +-511 etc.
The cogs uses only absolute addresses, so set org to 0.
Only time to use a different value, would be if you have for example have a code loader at org0 (6 longs big)
that will reload codes at will using rdlong. Each of these code snippets should have org 6 at start.
Let me clarify the cogs thing a bit so I can get it right for the beginners.
There are 8 cogs
Each can run one program that may have subroutines in it. Each one can call
and stop cogs etc but 8 is the limit at any one time and some are called when
we rerer to them under OBJ.
When we say
Have we now used three cogs or not? Meaning the main SPIN cog
that started everything and the two"what ever" that were referred to under OBJ.
These have to execute from code in a cog somewhere (and they eat up memory somewhere)
(Memory and cogs are the sort of the things we are short on So needs managing.)
Do they each use up a cog and if they themselves have OBJs called within them
do they then also use even more cogs.
Meaning that beginners need to understand that when they write code
they don't want to be careless about using up cogs and memory.
Since we cannot control space used by OBJs called, some care is warranted
You have only 8 cogs.
H
It's normally a call to objname.start that will set up any Pasm cog(s) if needed.
The more you call the less memory you have in your SPIN cog to write your own code?
And they cannot be called from PASM.
H
You can easily write an object that has no cognew or cogstart in it. Then if it is included in the obj section of something else and it's methods called they all run in the same COG as the parent object.
On the other hand, as you have seen, and object can start more than one COG. Those cogs could be running methods of the tthat SPIN object or PASM.
Thanks
Closed
H
Calling them often does not add code size, as they are bytecode subroutines.
Pasm data is also included in this 32K, with some smart coding you could reclaim this hub space after the cogs have been started.
Spin have fixed location of it's varibles in hub ram (after compiling)
So if the Spin pass along the address of a variable in PAR, pasm can change it or read it at will.
Well without reading the documentation or the code of the included objects we don't know just by looking at that OBJ declaration. Why assume only 3 COG? Perhaps that read4Pots object actually starts 4 COGS to do the job.
Is there a program similar to LINT in C that beginners can use to reformat their
code so that they can see indenting errors more clearly.
It would be a very useful tool but I would rather not write it right now.
H
Further, I would say that it is impossible to write one.
Because Spin has used the seriously brain damaged idea of using while space to delimit blocks it is impossible to tell if a level of indentation is missing because of a typographic / formatting error or if that is actually how the program logic should be. It would be impossible for such a program to know the intention of the author.
I think the best that could be done, and a good idea, is a program to check that only spaces are used or alternatively that only tabs are used. This is what jslint does for javascript.
If some program, for example used for typesetting your book, mangles the indentation. The is no way to automatically correct it. We see this on the forums everyday when people have not used the code tags.
and all the spaces were left as such?
H
What is a tab? In my editor it might be 4 spaces, in your editor it might be 8. That difference can change the meaning as we exchange code.
How would you know what was intended if I give you my code and the ndentation looks all wonky.
pub start (a, b) | x, y
if a == b
x := 1
else
y = doSomethingElse(a, b)
x := 2
return x
In the above code, purposely not using code tags, what should it return?
With such a simple example you might guess from reading it but you can never be sure.
With more complex code it becomes impossible.
Is there an estimate for when the book that this thread is talking about will be published?
cheers,
rich
You can use an editor that will display spaces in a highlight color to sort out whether or not you've got it right. A simple method is to use the character map tool to get one into the clipboard, then use find / replace in PropTool to get them all converted over.
Did this a while back to post up some ASCII art on a forum that had very minimalistic display tagging. It did have a code operator, but in general, would not avoid mangling spaces. The non-breaking one turned out to be just the trick.
In Linux, Kedit will display spaces in highlight color, if that makes better sense. I'm sure many editors do. Personally, I'm kicking around starting to use Sublime, and now I wonder whether or not that's a feature or plug in option.
Still they are no help in "pretty printing" a Spin file that has had it's spacing mangled by a forum engine or other processing.
Also they can't help you when you inadvertently drop an indent when editing your code And afetr that the compiler cannot tell you about it either.
For these reasons, and others, I would prefer to have visible block delimiters in any language.
What font are those grey indentions lines/forks?, they are not part of the parallax font.
"Control i" will turn those on and off. They do help in finding mistakes but automatic formatting would help other mistakes and pretty things up.
Code can be copied back and forth to Word
Heater
One interesting thing is that the user knows where his tabs are so these can be entered into the LINTlike program by him and then it will be possible to convert to spaces with no problems. Of course others could not reformat text they did not have the tab locations for.
Rich
I estimate that the book will be back from the printers some time in March. I am self publishing it.
Now that I have been enlightened AGAIN I have to go back and fix all the code in the book. (Its well over 100 pages of line by line FULLY documented code) and then test each program to make sure it works and then put it all back in the book and redo and index work...... Its endless but I have to get it done. I am next to burned out. I have quite a few orders already do I am committed.
For now I am going with Tony on how the OBJ files are handled and not worry about it. I need to get done.
RWgast
I do not understand what motivated all the unwarranted, negative talk about my SPIN book. All it does it keep guys like me from writing about the propeller. The propeller needs lots of independent outside support. Its an unbelievable chip. Unwarranted remarks by people who had not even seen much read the book did not help. Go by the amazon reviews. And Thanks for you support.
H
This book was panned by some on this forum.
James Cullins ...........@gmail.com>
8:05 AM (2 hours ago)
to me
I really enjoyed your book. I used a regular servo motor and encoder to do the exercises. I did learn a lot from it.I wore one book out, the binder was shedding sheets so I bought a second one.
Thanks for a very detailed book on closed loop control.
Jim Cullins
And the grey/gray forks are still visable in Word? (I could not get them visable)
In a book i would like to see these forks.
Yes they would be nice in the book but no dice!
However when you copy my programs from the internet and paste them into the PT they will come alive. So we get half way goodies.
H
a solution beginners can digest.
I have been thinking hard about this since potatohead's earlier comments.
Here is a possibility I would like comments on
This is about keeping the cog starting order under control using a pseudo
lock system
Suppose there are 2 SPIN cogs and 2 PASM cogs that need to run
I make the reasonable assumption that Hub memory as referenced by
PAR is all 0s.
If not I will need to find a solution that will take care of it
Would it work if every cog except the first one to start was inhibited
by a loop that watched PAR(1)..PAR(2).....with one memory location
for each program
As long a PAR(1) was 0 the second program would stay in a loop
at the head of its code.
As long a PAR(2) was 0 the third program would stay in a loop at
the head of the code
As long a PAR(3) was 0 the fourth program would stay in a loop at
the head of the code. And so on
After a while the first program would release the next program that
must start by setting its key to a 1
That program in turn would start the next program needed and so
on till all program were on
No programs would use the dedicated PAR locations ever
The programs would never loop back to their starting loops that
keep them locked.
I can see that there still might be problems but this might be OK
for beginning programmers.
Would this work?
Is there another way?
Is there a better way?
H
As someone who has expressed an interest in ordering your book, it seems to me that if you had a link where purchasers could download the tested Spin source code, that might sidestep the need for you to do a lot of rework on Word files.
phil
Yes, it's a problem. Tough one for me, because I really like the lean input possible without those delimiters. I've been writing a few programs for work related things, and there they are... Kind of painful compared to assembly / SPIN.
An editor that used non breaking spaces would help a lot. Hell of a kludge, but an effective one. Those characters are respected nearly everywhere, and they render clear or can be colored too.
IMHO, a switch to the non-breaking space would do SPIN editors a lot of good. IMHO, ordinary "just put spaces in it" output could be a save as option, for those who want pure text.
Convert 'n strip tabs on the way in, leaving non-breaking spaces there for the longer haul will print, paste to forum and provide an reasonable delimiter all in one package. Use the non-breaking, until the line begins, then use spaces in the line.
What do you mean "this business of cogs getting ahead of one another"? Your problem statement is too vague and therefore we can have no idea if
the proposed solution is sensible or not.
No matter if your COGs are running Spin or PASM the issue generally is "how does one coordinate activity between parallel running processes?".
There are many solutions depending on what you are wanting to do. For example:
a) Simple case.
A COG is set running and all it has to do is read a sensor (ADC or whatever) and deliver provide resulting number values.
Another COG is set running and all it has to do is send those number values down a serial link or write them into a video display.
Solution: Set aside a LONG in HUB, have the first cog write values there whenever it gets them. Have the second cog read that LONG whenever it likes and do whatever with the numbers.
Note: This may mean certain updates of the values are skipped over and missed out but we may be just happy with that as we don't care about past values only the latest ones.
b) Harder case.
As above but the sensor reading COG must deliver 2 or more LONGs (perhaps from 2 or more sensors) AND those values have to come in pairs. i.e. reading of sensor A and sensor B at an instant T must be processed together.
Solution: Set aside two LONGs for the two readings. BUT now we have to be sure that the reader COG does not read A and then the writer cog updates B prior to the reader getting around to reading A.
We can ensure that does not happen by using Propeller locks. However we can also do it with a flag or "semaphore".
So, use a third LONG for that flag. Arrange that the flag is initially zero.
When the writer COG has data it always waits in a loop until that flag is zero. Then it writes the two data longs and sets the flag to one.
When the reader COG want's data it always waits for that flag to become one. Then it reads the two data longs and sets the flag back to zero.
At which point the writer cog sees it can write new data and the processes repeats.
Something similar to the flag technique can also be used to issue commands from a "master" cog to a "slave" cog. Say the slave provides some service like, floating point calculations or interfacing to an external RAM. Here the "flag" long might be a command value, say one=read RAM, two=write RAM, zero= do nothing. The slave cogs waits in a loop for a non-zero value of that command long and then does whatever action the long value implies. Having done it's job it sets the command value back to zero(may also write a result somewhere) . Seeing a zero the "master" cog can read the results and knows it can issue another command if it likes.
c) Still harder case.
A bunch of cogs are reading and writing a data structure in HUB and that data structure is required to be in some consistent state. Could just be an array of values that the cogs have to shuffle around to insert/delete other values.
Here you will need locks.
d) A very elegant case. The Full Duplex Serial object maintains receive and transmit buffers. They are both cyclic buffers with "head" and "tail"
pointers. You might think that locks would be required to stop the readers and writers mangling such a complex data structure. But no, it's all done with careful comparisons and manipulations of those pointers. As long as there is only one reader and one writer it works. Well worth studying.
e) Impossible cases.
There are those around here who synchronise cog activity to the nano second, perhaps for video generation, It's all done with flags and cycle counting and counters. Actually I have no idea how it is done. I would imagine this is not for a beginners book.
In general, think "mail boxes" containing both data and commands. Or think cyclic buffers like FDS. All accessed through PAR pointers. Don't forget locks when contention may be a problem.
Anything missing here?
Take a look at #692 by K for the problem that occurred while I digest what you wrote
I'll be back with more detail.
H
You know, I really had to think about what you are saying there for a minute. I have never edited code with anything that even knew the difference between a "hard space" and a "soft space". If I type a space into my code I mean a space. If the editor decided to compress multiple spaces into one or any other such nonsense without my express permission or command it would get deleted immediately.
I can just about stomach that spaces get vaporized in word processors or web browsers, but then putting text between HTML tags or into a word document is implicitly giving it my permission to do so.
Again, I don't follow you. Having all spaces as "hard spaces", that is to say "normal spaces", is what text editors have been doing since the dawn of time.
Seems somewhere in the past 100 years I missed a memo. What I think of as a "space" is ASCII code 32. They have always been "hard" to me. If I hit the space bar in Vim or Emacs or Kate or whatever that is what I get. But no, somewhere along the line someone decided to make 32 "soft" and have a new character for hard spaces, ASCII code 255.
When did that happen?
I don't have the time to look at these problems in detail but glancing back at that post it seems to be a total confusion about how to use Spin syntax to access things and how to use PAR to access things.
Those issues have to be resolved before getting on to the business of "preventing cogs getting ahead of each other" in ways that I outlined above.