...SPIN arrays did not seem to be addressable from the PASM code. I thought it was my bad since I have only just started but is this indeed a limitation?
Yes. What you have to do is pass the address of the array(s) from your SPIN to the start method of your PASM. The start method then has to embed those values into the .DAT section.
A good place to see how to do this is in any of the VGA objects.
Assuming PASM and the arrays are in separate objects.
I'm not sure if the trick with restarting Spin to move the stackpointer works. If you not do that the stack will be at the end of all objects and overwrite one of your arrays.
Could you not just put your stack array at the end of the other and allow it to get trashed? AFAIK there's no stack checking going on whichever way you do it.
I'll have a play with is later.
If it works I'll even write it up as a proper app note. I can't believe I'm the only person who wants to reclaim HUB RAM.
You aren't the only person. I haven't ever had this issue until very recently and am so new to PASM that I thought I just had to live with it. This is slightly beyond me, but I want to learn so I am too very interested.
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
VAR
long go
word A, B, C, D, E, F, G, H, I
PUB start | j, entry
'8kbytes of byte arrays
A := @entry1 'byte A[2048]
B := A + 2048 'byte B[2048]
C := B + 2048 'byte C[2048]
D := C + 2048 'byte D[2048]
'16kbytes of word arrays
E := D + 2048 'word E[2048]
F := E + 4096 'word F[2048]
G := F + 4096 'word G[2048]
H := G + 4096 'word H[2048]
'4kbytes of long array
I := H + 4096 'long I[1024]
repeat j from 0 to 6
entry := @entry1 + j * 496
long[entry][480] := A
long[entry][481] := B
long[entry][482] := H
cognew(entry, @go)
longfill(A, 0, (I + 4096) / 4)
go := true
repeat
'Do foreground stuff.
DAT
'480 longs of executable PASM
'16 longs for intermediate calculations and address pointers into HUB RAM
org 0
entry1 rdlong :ready,par wz
if_z jmp #entry1
:pasm_code long $5500AA00[477]
:ready long 0-0
:acc1 long 0-0 'pointer to byte array A
:acc2 long 0-0 'pointer to byte array B
:acc3 long 0-0 'pointer to word array H
:acc4 long 4
:acc5 long 5
:acc6 long 6
:acc7 long 7
:acc8 long 8
:acc9 long 9
:acc10 long 10
:acc11 long 11
:acc12 long 12
:acc13 long 13
:acc14 long 14
:acc15 long 15
:acc16 long 16
fit
'480 longs of executable PASM
'16 longs for intermediate calculations and address pointers into HUB RAM
org 0
entry2 rdlong :ready,par wz
if_z jmp #entry2
:pasm_code long $5500AA00[477]
:ready long 0-0
:acc1 long 0-0 'pointer to byte array A
:acc2 long 0-0 'pointer to byte array B
:acc3 long 0-0 'pointer to word array H
:acc4 long 4
:acc5 long 5
:acc6 long 6
:acc7 long 7
:acc8 long 8
:acc9 long 9
:acc10 long 10
:acc11 long 11
:acc12 long 12
:acc13 long 13
:acc14 long 14
:acc15 long 15
:acc16 long 16
fit
'480 longs of executable PASM
'16 longs for intermediate calculations and address pointers into HUB RAM
org 0
entry3 rdlong :ready,par wz
if_z jmp #entry3
:pasm_code long $5500AA00[477]
:ready long 0-0
:acc1 long 0-0 'pointer to byte array A
:acc2 long 0-0 'pointer to byte array B
:acc3 long 0-0 'pointer to word array H
:acc4 long 4
:acc5 long 5
:acc6 long 6
:acc7 long 7
:acc8 long 8
:acc9 long 9
:acc10 long 10
:acc11 long 11
:acc12 long 12
:acc13 long 13
:acc14 long 14
:acc15 long 15
:acc16 long 16
fit
'480 longs of executable PASM
'16 longs for intermediate calculations and address pointers into HUB RAM
org 0
entry4 rdlong :ready,par wz
if_z jmp #entry4
:pasm_code long $5500AA00[477]
:ready long 0-0
:acc1 long 0-0 'pointer to byte array A
:acc2 long 0-0 'pointer to byte array B
:acc3 long 0-0 'pointer to word array H
:acc4 long 4
:acc5 long 5
:acc6 long 6
:acc7 long 7
:acc8 long 8
:acc9 long 9
:acc10 long 10
:acc11 long 11
:acc12 long 12
:acc13 long 13
:acc14 long 14
:acc15 long 15
:acc16 long 16
fit
'480 longs of executable PASM
'16 longs for intermediate calculations and address pointers into HUB RAM
org 0
entry5 rdlong :ready,par wz
if_z jmp #entry5
:pasm_code long $5500AA00[477]
:ready long 0-0
:acc1 long 0-0 'pointer to byte array A
:acc2 long 0-0 'pointer to byte array B
:acc3 long 0-0 'pointer to word array H
:acc4 long 4
:acc5 long 5
:acc6 long 6
:acc7 long 7
:acc8 long 8
:acc9 long 9
:acc10 long 10
:acc11 long 11
:acc12 long 12
:acc13 long 13
:acc14 long 14
:acc15 long 15
:acc16 long 16
fit
'480 longs of executable PASM
'16 longs for intermediate calculations and address pointers into HUB RAM
org 0
entry6 rdlong :ready,par wz
if_z jmp #entry6
:pasm_code long $5500AA00[477]
:ready long 0-0
:acc1 long 0-0 'pointer to byte array A
:acc2 long 0-0 'pointer to byte array B
:acc3 long 0-0 'pointer to word array H
:acc4 long 4
:acc5 long 5
:acc6 long 6
:acc7 long 7
:acc8 long 8
:acc9 long 9
:acc10 long 10
:acc11 long 11
:acc12 long 12
:acc13 long 13
:acc14 long 14
:acc15 long 15
:acc16 long 16
fit
'480 longs of executable PASM
'16 longs for intermediate calculations and address pointers into HUB RAM
org 0
entry7 rdlong :ready,par wz
if_z jmp #entry7
:pasm_code long $5500AA00[477]
:ready long 0-0
:acc1 long 0-0 'pointer to byte array A
:acc2 long 0-0 'pointer to byte array B
:acc3 long 0-0 'pointer to word array H
:acc4 long 4
:acc5 long 5
:acc6 long 6
:acc7 long 7
:acc8 long 8
:acc9 long 9
:acc10 long 10
:acc11 long 11
:acc12 long 12
:acc13 long 13
:acc14 long 14
:acc15 long 15
:acc16 long 16
fit
extra_buf long $77777777[7168 - ((@extra_buf - @entry1) >> 2) #> 0]
This overlays the arrays beginning with the PASM code. extra_buf allocates whatever is left over. The go variable is used to make sure that all the cogs are started before the arrays are initialized and execution begins.
Also, if all the PASM cogs are doing pretty much the same thing, they can be cognew'd from the same block of code, with the differences handled by parameterization.
....
If it works I'll even write it up as a proper app note. I can't believe I'm the only person who wants to reclaim HUB RAM.
Some objects reclaim the HUB RAM of there own DAT-PASM section for buffers.
But what you want do do is reclaim the HUB RAM over several objects, which violates the whole idea of Spin. These will only work if you have the Spin objects first and know the amount of memory they use and reuse only the HUB RAM behind the Spin code.
Thank you to the last several posters who have given this thread a positive direction!
I was asked the question in a recent communication, "Is this an American thing (recent heated arguments in the forum)? Why don't they actually do something rather than /complaining/?" -- I won't reveal who said this, but know that people are lurking.. Our manners are showing..
Could you not just put your stack array at the end of the other and allow it to get trashed? AFAIK there's no stack checking going on whichever way you do it.
In this example Spin only starts the other cogs and does then terminate. In this case the stack is not a problem. But if you want also have a Spin cog running for debugging or so, then the stack must not be trashed. It shoud be at a safe place for example before the first array.
I was asked the question in a recent communication, "Is this an American thing (recent heated arguments in the forum)? Why don't they actually do something rather than /complaining/?"
I browse the forums when I'm taking a break from working. Since most of my work isn't Propeller projects it doesn't show up here, so it may appear that I don't do much. I suspect this applies to many others as well.
And anyway, I think these discussions are important to help define development directions, irregardless of whether it is seen as "complaining". How will those who do know what to work on if there isn't a problem to solve? That's what engineers do.
And anyway, I think these discussions are important to help define development directions, irregardless of whether it is seen as "complaining". How will those who do know what to work on if there isn't a problem to solve? That's what engineers do.
And anyway, I think these discussions are important to help define development directions, irregardless of whether it is seen as "complaining". How will those who do know what to work on if there isn't a problem to solve? That's what engineers do.
True, the real nuggets are most often what a chip does NOT do, (or struggles to do), and that is usually strangely omitted from the Vendor's Docs..
As someone who stumbled upon the Propeller (while looking for something else), I have found a very interesting architecture for my interest, which is the creation of music via emulated sound processing chips like the Commodore SID. What I find puzzling is that there are multiple ways to generate video, multiple ways to read from an SD card, multiple ways of processing MIDI data. Sometimes MIDI out is on pin X, other times it is on pin Y. Sometimes the VGA frequencies are set to values that my vanilla monitor can't lock onto. I understand that in certain situations designs and code must be tweaked for maximum performance, but all these differences can make for a confusing experience. I still don't know why my composite video out will only generate a usable display on an old black and white monitor.
--tom
I did wonder about putting everything in one huge file to improve name visibility and managing where things got put.
The thought of a source file running to over 4k lines is a bit scary though.
My solution (aka hack) is to use CAT to combine multiple files at compile time into a single file. I did this to have "global" variables and functions. I recently worked on a large project with different programs for different sets of hardware, but which shared common library functions and variables. As part of my process, I first ran the source code through a custom math preprocessor of mine (to convert FP equations to Propeller compatible code), then added the library functions and variable functions. Here's a snippet from my compile bash file:
This worked much better then copying and pasting the support functions/variables into the file, then trying to remember where things where and whether I had fixed that support function bug in that one file...
All told, for my main file this converts a source file of ~500 lines to a file of ~2500 lines.
If I were to stick with Spin, I think I'd continue with the same idea of CATing files together. But, I'm going to switch over to GCC because of the various Spin shortcomings...
I don't know what it is but I'm finding that seeing this thread at the top of the list constantly is bugging me no end. Well, it's probably more the thread title, it doesn't look encouraging to me and I'm sure not at all for anyone new to the forum, and perhaps others also. There seems to be whiskers from the thread that have more to do with software and compilers and programming style etc. The thing is, pick any CPU, any at all, and start a thread "Why I Find the *** So Frustrating" despite the excellencies of *** and sure as eggs you will have an endless thread that dominates the forum.
The proof of the pudding is in the eating and I can tell you that from my end it's all eaten up and I keep coming back for more (so do you guys). I cannot say this for micros (including dev tools) other than Propeller, some are tasty at first but after a while they start to leave a sour taste or maybe you start biting on some disconcerting bits, or else you find something else sweeter. The Propeller has some odd flavors, you either like it or hate it, but it's my favorite!
See, I've just popped this thread back to the top (can't win).
Oh my, and they call themselves "professionals"???? Standards have slipped. Any professional worth his salt can work with (and like) computer languages other than they were taught and brought up on. This is the problem with C as useful as it is in that it has become almost all pervasive yet it is not the only tool in the shed, there are other tools that suit certain tasks better. There's something to like about most languages and they all have been designed for a purpose. If you know what you want to do and you are versed in the use of more than one tool, then you choose your tool(s) and get the job done. So as for these so called "professionals", I can really blame them.
However the indentation thing could easily be made a compiler option surely and I don't know why Parallax haven't done so.
Besides, regarding the thread title I think that anything new and different can be frustrating, very frustating in fact. But the Propeller is worth it and really it's a lot easier to learn than a new SOC ARM
I am an application database programmer... I handle most coding for 5 different companies, that are owned by a parent entity. I didn't write the original application software that is here ( its been in use for longer then I have been alive, Then language is an older arcane one ( Informix )) I had to pick up when I started working here.
Generaly when I am making huge changes to a program I like to not indent any of my new code, incase something goes wrong I can easily see where my 'splice in' is and can quickly back changes out with out using an RCS which could take out other changes u want to keep etc.. etc... I also have a unique use of white space, to help separate diffrent portions of code. I cant do any of that with spin ;x
Not saying spin sucks, i think its just fine but it does hurt not to have free use of white space ( something i have had for years, and have learned to turn into a very strong tool for diagraming programs and bug hunting believe it or not.. ) its not a matter of good programmers can pick up this and that... its a matter of good programmers learn to use the tools provided to them over the years in unique ways to solve problems much quicker then they would be otherwise, spin took that away from me. Am I a bad programmer because of such ???
I'd hardly say you are a bad programmer from what you have told me and I can't see where I may have implied this in my post. However, the jibe was at the attitude of the masses when they hold themselves aloof and superior with such snobbish comments as "we are professionals" when in fact they really don't have the abilities to tackle something outside their comfort zone. A real die-hard programmer as you know will be ready to jump in (and often eager) to overcome obstacles rather than take the easy safe tried and proven traditional course. The one who jumps in gains much experience and knowledge and understanding while those who hold back and hide behind the "professional" label or get others to do the work are stagnating. I have a motto I often say to people "no effort, no joy" meaning that overcoming obstacles brings a lot of satisfaction and the alternative is so very boring and no fun at all.
Noob here. Zero previous experience programming and little electronics background, but I thought I'd add my two cents. Spin and the Propeller are my very first language/embedded platform, and the only things I've used are the Propeller Manual and the Kickstarts for learning how to use the Prop (http://firstspin.tv for evidence!).
So I guess I'm a little confused in terms of what kind of documentation people are looking for to learn Spin? (I know the OP's gripe was not on just learning Spin but figuring out how memory works, but for those who have since mentioned without "more proper documentation", people would be turned off by Spin) Again, just my 2cents/experience, but I like the indentation as a noobie, it seems to make my code more neat and therefore more understandable. I know also that people don't like the colors in PropTool, but I think they make it very easy for me to see where the different code chunks are.
And then in terms of the idea of is it worth it for people to take the time to learn a non-interrupt containing chip even though "all of the cool kids are doing it"...I think that the Propeller's architecture is so elegant that it'd be a waste of time NOT to learn how to use it to its fullest potential. Because once you've figured out the magic behind the cogs, you've probably saved a LOT of time in the future.
Also. If you've learned something new, then instead of waiting for Parallax to do it, you document it! For those who follow my blog, they know I sometimes OVER-document, but there's no harm done, it usually becomes a good reference for my own coding. (And you can write it in a way you understand instead of having to parse out someone else's explanation).
Addie
well try learning it all from scratch with out the help of two experts ;p ( no offence intended ). And on another note wait tell you have to make very very large changes to an app thats over 1000 lines of code. When you are changing say 200 of those lines up in various places, it becomes very easy to break your space delimited blocks..... and trying to pull those back into place i could only imagine how hard it could get. I make changes like this every day to programs but the language i use does have block delimiters etc.. etc... and I can still get them all screwed up and spend an hour or so tidying up behind my self ;x
So can we get a single resource from Parallax to help head up some best practice documents?
Best practice examples should come from the manufacturer and would eliminate a lot of the documentation gripes. Many will volunteer their time to help.
So can we get a single resource from Parallax to help head up some best practice documents?
Best practice examples should come from the manufacturer and would eliminate a lot of the documentation gripes. Many will volunteer their time to help.
I called Parallax in the fall of last year asking for help with this and they did not mention that app note or any app notes? Is that site something new? I really wish I had AN018 when I was trying to figure that out last year and asking for help from the forum. The forum got me sorted, but that simple example would have really made my life easier at the time.
Something like that for a large amount of topics would be a great start to documentation.
Indentation... Anyone working for me and writing programs in C, Spin, or VB would have to indent their programs. It is not optional IMHO, it is just good practice, the same as documenting your code.
Just because some slack programmers don't do it does not make it right. I was taught to document, etc, way back in 1970. It was as valid then as it is now, perhaps even more so because programs are so much larger.
While I agree the PropTool (or replacement) should permit swapping/converting from/to the use of braces, indentation is IMHO still mandatory.
At least Chip had the forsight to force new programmers to learn correct practice.
Sure indentation is a great aspiration, but making it FORCED structural has many downsides...
* It becomes context sensitive
* Tab size now matters
* Conditional compile is harder to manage, as too is file include
* Code blocks can come from multiple sources, scripts/translators are common.
Indentation is best left as an 'Editor Suggestion' and not carry a stealth change to how your code actually works.
Hah didn't have to But that being said, if anyone else wants to learn it from scratch with the help of two experts, now they have a resource to do that with, instead of having to start it all on their own. But even so, if I had found the documentation lacking, it would have come up in the podcast.
well try learning it all from scratch with out the help of two experts ;p ( no offence intended ). And on another note wait tell you have to make very very large changes to an app thats over 1000 lines of code. When you are changing say 200 of those lines up in various places, it becomes very easy to break your space delimited blocks..... and trying to pull those back into place i could only imagine how hard it could get. I make changes like this every day to programs but the language i use does have block delimiters etc.. etc... and I can still get them all screwed up and spend an hour or so tidying up behind my self ;x
So , if in C or Pascal indentation is optional and start/stop blok keywords are mandatory ( {, } in C, begin,end in Pascal).... let reverse this... Optinal start/stop keywords...
pub something | i
{begin}
repeat i from 0 to 100
{begin}
'some code here
{end}
{end}
This is vaild in current version of Spin and everyone can use it now
I "love" the indention aspect of the Spin language. If forces me to generate pefectly indented code.
PUB dec(value) | i, x
x := value == NEGX
if value < 0
value := {
} ||(value+x)
ser.tx("-")
i := 1_000_000_000
repeat 10
if value => i
ser.tx(value / i {
} + "0" + x*(i == 1))
value //= i
result~~
elseif result or i == 1
ser.tx("0")
i /= 10
Comments
Yes. What you have to do is pass the address of the array(s) from your SPIN to the start method of your PASM. The start method then has to embed those values into the .DAT section.
A good place to see how to do this is in any of the VGA objects.
Assuming PASM and the arrays are in separate objects.
In your SPIN module...
In the PASM module...
Wow.
Could you not just put your stack array at the end of the other and allow it to get trashed? AFAIK there's no stack checking going on whichever way you do it.
I'll have a play with is later.
If it works I'll even write it up as a proper app note. I can't believe I'm the only person who wants to reclaim HUB RAM.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 VAR long go word A, B, C, D, E, F, G, H, I PUB start | j, entry '8kbytes of byte arrays A := @entry1 'byte A[2048] B := A + 2048 'byte B[2048] C := B + 2048 'byte C[2048] D := C + 2048 'byte D[2048] '16kbytes of word arrays E := D + 2048 'word E[2048] F := E + 4096 'word F[2048] G := F + 4096 'word G[2048] H := G + 4096 'word H[2048] '4kbytes of long array I := H + 4096 'long I[1024] repeat j from 0 to 6 entry := @entry1 + j * 496 long[entry][480] := A long[entry][481] := B long[entry][482] := H cognew(entry, @go) longfill(A, 0, (I + 4096) / 4) go := true repeat 'Do foreground stuff. DAT '480 longs of executable PASM '16 longs for intermediate calculations and address pointers into HUB RAM org 0 entry1 rdlong :ready,par wz if_z jmp #entry1 :pasm_code long $5500AA00[477] :ready long 0-0 :acc1 long 0-0 'pointer to byte array A :acc2 long 0-0 'pointer to byte array B :acc3 long 0-0 'pointer to word array H :acc4 long 4 :acc5 long 5 :acc6 long 6 :acc7 long 7 :acc8 long 8 :acc9 long 9 :acc10 long 10 :acc11 long 11 :acc12 long 12 :acc13 long 13 :acc14 long 14 :acc15 long 15 :acc16 long 16 fit '480 longs of executable PASM '16 longs for intermediate calculations and address pointers into HUB RAM org 0 entry2 rdlong :ready,par wz if_z jmp #entry2 :pasm_code long $5500AA00[477] :ready long 0-0 :acc1 long 0-0 'pointer to byte array A :acc2 long 0-0 'pointer to byte array B :acc3 long 0-0 'pointer to word array H :acc4 long 4 :acc5 long 5 :acc6 long 6 :acc7 long 7 :acc8 long 8 :acc9 long 9 :acc10 long 10 :acc11 long 11 :acc12 long 12 :acc13 long 13 :acc14 long 14 :acc15 long 15 :acc16 long 16 fit '480 longs of executable PASM '16 longs for intermediate calculations and address pointers into HUB RAM org 0 entry3 rdlong :ready,par wz if_z jmp #entry3 :pasm_code long $5500AA00[477] :ready long 0-0 :acc1 long 0-0 'pointer to byte array A :acc2 long 0-0 'pointer to byte array B :acc3 long 0-0 'pointer to word array H :acc4 long 4 :acc5 long 5 :acc6 long 6 :acc7 long 7 :acc8 long 8 :acc9 long 9 :acc10 long 10 :acc11 long 11 :acc12 long 12 :acc13 long 13 :acc14 long 14 :acc15 long 15 :acc16 long 16 fit '480 longs of executable PASM '16 longs for intermediate calculations and address pointers into HUB RAM org 0 entry4 rdlong :ready,par wz if_z jmp #entry4 :pasm_code long $5500AA00[477] :ready long 0-0 :acc1 long 0-0 'pointer to byte array A :acc2 long 0-0 'pointer to byte array B :acc3 long 0-0 'pointer to word array H :acc4 long 4 :acc5 long 5 :acc6 long 6 :acc7 long 7 :acc8 long 8 :acc9 long 9 :acc10 long 10 :acc11 long 11 :acc12 long 12 :acc13 long 13 :acc14 long 14 :acc15 long 15 :acc16 long 16 fit '480 longs of executable PASM '16 longs for intermediate calculations and address pointers into HUB RAM org 0 entry5 rdlong :ready,par wz if_z jmp #entry5 :pasm_code long $5500AA00[477] :ready long 0-0 :acc1 long 0-0 'pointer to byte array A :acc2 long 0-0 'pointer to byte array B :acc3 long 0-0 'pointer to word array H :acc4 long 4 :acc5 long 5 :acc6 long 6 :acc7 long 7 :acc8 long 8 :acc9 long 9 :acc10 long 10 :acc11 long 11 :acc12 long 12 :acc13 long 13 :acc14 long 14 :acc15 long 15 :acc16 long 16 fit '480 longs of executable PASM '16 longs for intermediate calculations and address pointers into HUB RAM org 0 entry6 rdlong :ready,par wz if_z jmp #entry6 :pasm_code long $5500AA00[477] :ready long 0-0 :acc1 long 0-0 'pointer to byte array A :acc2 long 0-0 'pointer to byte array B :acc3 long 0-0 'pointer to word array H :acc4 long 4 :acc5 long 5 :acc6 long 6 :acc7 long 7 :acc8 long 8 :acc9 long 9 :acc10 long 10 :acc11 long 11 :acc12 long 12 :acc13 long 13 :acc14 long 14 :acc15 long 15 :acc16 long 16 fit '480 longs of executable PASM '16 longs for intermediate calculations and address pointers into HUB RAM org 0 entry7 rdlong :ready,par wz if_z jmp #entry7 :pasm_code long $5500AA00[477] :ready long 0-0 :acc1 long 0-0 'pointer to byte array A :acc2 long 0-0 'pointer to byte array B :acc3 long 0-0 'pointer to word array H :acc4 long 4 :acc5 long 5 :acc6 long 6 :acc7 long 7 :acc8 long 8 :acc9 long 9 :acc10 long 10 :acc11 long 11 :acc12 long 12 :acc13 long 13 :acc14 long 14 :acc15 long 15 :acc16 long 16 fit extra_buf long $77777777[7168 - ((@extra_buf - @entry1) >> 2) #> 0]This overlays the arrays beginning with the PASM code. extra_buf allocates whatever is left over. The go variable is used to make sure that all the cogs are started before the arrays are initialized and execution begins.
Also, if all the PASM cogs are doing pretty much the same thing, they can be cognew'd from the same block of code, with the differences handled by parameterization.
-Phil
Some objects reclaim the HUB RAM of there own DAT-PASM section for buffers.
But what you want do do is reclaim the HUB RAM over several objects, which violates the whole idea of Spin. These will only work if you have the Spin objects first and know the amount of memory they use and reuse only the HUB RAM behind the Spin code.
Andy
I was asked the question in a recent communication, "Is this an American thing (recent heated arguments in the forum)? Why don't they actually do something rather than /complaining/?" -- I won't reveal who said this, but know that people are lurking.. Our manners are showing..
OBC
In this example Spin only starts the other cogs and does then terminate. In this case the stack is not a problem. But if you want also have a Spin cog running for debugging or so, then the stack must not be trashed. It shoud be at a safe place for example before the first array.
Andy
I browse the forums when I'm taking a break from working. Since most of my work isn't Propeller projects it doesn't show up here, so it may appear that I don't do much. I suspect this applies to many others as well.
And anyway, I think these discussions are important to help define development directions, irregardless of whether it is seen as "complaining". How will those who do know what to work on if there isn't a problem to solve? That's what engineers do.
Indeed.
True, the real nuggets are most often what a chip does NOT do, (or struggles to do), and that is usually strangely omitted from the Vendor's Docs..
1) Sometimes its memory space is too small to do what I want do. For example emulate a full 64KB memory CP/M system.
2) Sometimes software peripherals are just not fast enough. For example USB or implementing a decent link to an XMOS device.
3) Sometimes it just not have enough I/O pins.
4) The 512 long limit on in COG PASM code is kind of cramping.
Well that's about it. So like any other device it either meets the requirements of the project or it does not.
It frustrates because I love the elegance of the thing. Every design decision in its making has a clear reason.
Oh yes. And elegance is exactly the correct word.
--tom
Thanks Phil,
I did wonder about putting everything in one huge file to improve name visibility and managing where things got put.
The thought of a source file running to over 4k lines is a bit scary though.
My solution (aka hack) is to use CAT to combine multiple files at compile time into a single file. I did this to have "global" variables and functions. I recently worked on a large project with different programs for different sets of hardware, but which shared common library functions and variables. As part of my process, I first ran the source code through a custom math preprocessor of mine (to convert FP equations to Propeller compatible code), then added the library functions and variable functions. Here's a snippet from my compile bash file:
This worked much better then copying and pasting the support functions/variables into the file, then trying to remember where things where and whether I had fixed that support function bug in that one file...
All told, for my main file this converts a source file of ~500 lines to a file of ~2500 lines.
If I were to stick with Spin, I think I'd continue with the same idea of CATing files together. But, I'm going to switch over to GCC because of the various Spin shortcomings...
The proof of the pudding is in the eating and I can tell you that from my end it's all eaten up and I keep coming back for more (so do you guys). I cannot say this for micros (including dev tools) other than Propeller, some are tasty at first but after a while they start to leave a sour taste or maybe you start biting on some disconcerting bits, or else you find something else sweeter. The Propeller has some odd flavors, you either like it or hate it, but it's my favorite!
See, I've just popped this thread back to the top (can't win).
Snap.
The SPIN suggestions here have been very very clever but are always going to be a way of working around the way the tools were conceived to work.
I am an application database programmer... I handle most coding for 5 different companies, that are owned by a parent entity. I didn't write the original application software that is here ( its been in use for longer then I have been alive, Then language is an older arcane one ( Informix )) I had to pick up when I started working here.
Generaly when I am making huge changes to a program I like to not indent any of my new code, incase something goes wrong I can easily see where my 'splice in' is and can quickly back changes out with out using an RCS which could take out other changes u want to keep etc.. etc... I also have a unique use of white space, to help separate diffrent portions of code. I cant do any of that with spin ;x
Not saying spin sucks, i think its just fine but it does hurt not to have free use of white space ( something i have had for years, and have learned to turn into a very strong tool for diagraming programs and bug hunting believe it or not.. ) its not a matter of good programmers can pick up this and that... its a matter of good programmers learn to use the tools provided to them over the years in unique ways to solve problems much quicker then they would be otherwise, spin took that away from me. Am I a bad programmer because of such ???
BTW, I use all the whitespace I want in Forth
well try learning it all from scratch with out the help of two experts ;p ( no offence intended ). And on another note wait tell you have to make very very large changes to an app thats over 1000 lines of code. When you are changing say 200 of those lines up in various places, it becomes very easy to break your space delimited blocks..... and trying to pull those back into place i could only imagine how hard it could get. I make changes like this every day to programs but the language i use does have block delimiters etc.. etc... and I can still get them all screwed up and spend an hour or so tidying up behind my self ;x
btw I love the pod cast
Best practice examples should come from the manufacturer and would eliminate a lot of the documentation gripes. Many will volunteer their time to help.
Like Application Notes?
I found the Application Notes extremely informative.
I called Parallax in the fall of last year asking for help with this and they did not mention that app note or any app notes? Is that site something new? I really wish I had AN018 when I was trying to figure that out last year and asking for help from the forum. The forum got me sorted, but that simple example would have really made my life easier at the time.
Something like that for a large amount of topics would be a great start to documentation.
Sure indentation is a great aspiration, but making it FORCED structural has many downsides...
* It becomes context sensitive
* Tab size now matters
* Conditional compile is harder to manage, as too is file include
* Code blocks can come from multiple sources, scripts/translators are common.
Indentation is best left as an 'Editor Suggestion' and not carry a stealth change to how your code actually works.
pub something | i {begin} repeat i from 0 to 100 {begin} 'some code here {end} {end}This is vaild in current version of Spin and everyone can use it now
PUB dec(value) | i, x x := value == NEGX if value < 0 value := { } ||(value+x) ser.tx("-") i := 1_000_000_000 repeat 10 if value => i ser.tx(value / i { } + "0" + x*(i == 1)) value //= i result~~ elseif result or i == 1 ser.tx("0") i /= 10@dave: that is really a great solution. I love 'write-only' languages!!