Yeah more tutorials and app-notes are always good. For me this forum and the obex is full of app-notes because I learn most from the code that others have written, also if the code contains not so much comments.
So here an example how to start 3 PASM cogs and reuse the hubram. The CON section defines the addresses of the shared variables. If you have the shared variables in the first 512 bytes in hubram, you can access them quite easy in PASM with immediate addressing, so no passing of pointers in the par is needed.
Perhaps this convinces also Sapieha that it IS possible....;-)
The code is for a Quickstart or Demoboard. One cog overwrites the hubram from which all the cogs are startet to show that this not affects the cogs. The second cog writes to a shared variable the flash speed, and the third reads this speed variable and flashes the LED.
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
#$14, startFlag, #18,speed 'enumerate shared variable adresses
#$30, shareEnd 'hubram $0030...$7FFF free
segment1 = $3000 'define some hub segments
segment2 = $4000
DAT
byte 0[28] 'reserve 28 byte in hubram ($14..$2F)
'for shared variables and init to zero
PUB Main
cognew(@cog1,0) 'start the 3 cogs
cognew(@cog2,0)
coginit(cogid,@cog3,0) 'last one reuses this spin cog
DAT
' cog 1 code: overwrite hubram until segment1
org 0
cog1 rdbyte tmp1, #startFlag wz 'wait for startflag
if_z jmp #cog1
mov tmp1, hubBeg
:loop wrlong zero, tmp1 'clear hubram long
add tmp1, #4
cmp tmp1, hubEnd wc 'all done?
if_b jmp #:loop
mov dira, led1 'LED1 on when done
mov outa, led1
:halt jmp #:halt
tmp1 long 0
zero long 0
bit15 long 1<<15
led1 long 1<<16
hubBeg long shareEnd
hubEnd long segment1 - 1
' cog 2 code: change shared speed variable every second
org 0
cog2 rdbyte tmp2, #startFlag wz 'wait for startflag
if_z jmp #cog2
rdlong clkfq, #0 'get clockfreq
mov tmp2, cnt
add tmp2, clkfq
mov dira, led2
:loop waitcnt tmp2, clkfq 'wait 1 second
or outa, led2 'led2 on
wrlong speed1, #speed 'change speed for cog3
waitcnt tmp2, clkfq 'wait 1 second
andn outa, led2 'led2 ooff
wrlong speed2, #speed 'change speed for cog3
jmp #:loop
tmp2 long 0
clkfq long 0
speed1 long 4500000
speed2 long 9000000
led2 long 1<<17
' cog 3 code: flash the LED according speed variable
org 0
cog3 wrbyte tmp3, #startFlag 'set startflag
mov dira, led3
:loop rdlong tmp3, #speed wz 'read speed variable
if_z jmp #:loop 'wait until speed > 0
add tmp3, cnt
waitcnt tmp3, #0 'wait speed periode
xor outa, led3 'toggle led3
jmp #:loop
tmp3 long 1
led3 long 1<<18
I wonder if more rigorous Application Notes might do the trick, but I still suspect that at some point books are a better means to handle the issue.
An excellent way to give all users a 'leg up', especially on less conventional silicon, is many small, working examples.
The question asked here is a good one, and not uncommon, so it should have an example.
#32 seems to show how it can be done.
It is the classic 'a picture is worth 1000 words', and in this case a functional code block (aka picture) , is worth FAR MORE than dry text in a manual.
Re memory mapping of 32k of hub ram, I've come across a similar problem memory mapping a megabyte of external ram. The external ram is being used for different things - for storing bitmaps, arrays and strings. Ok, bear with me, this is slightly complicated to explain. Start with the concept of "files" in ram. The very first routine takes a file off an SD card and puts it in ram. So we can call those file1, file2 etc.
Define an array memlocation[] and size[]. Define one variable "filecounter".
Load in file0 which might be 50k. memlocation[0] is 0, size[0] is 50k and filecounter is now 1.
Load in file1 which might be 20k. memlocation[1] is 50k, size[1] is 20k and filecounter is now 2.
Within a file you can do other things. eg file0 and file1 might have come off the SD card, but file2 could be a whole bunch of strings. So within file2 are all the names and locations of strings.
file3 might be another bitmap off the SD card.
To "wipe" the ram disk, set filecounter to zero.
There are more complex "fat" type systems of memory management and indeed I seriously looked at implementing the CP/M fat as a memory management tool, but for my particular application I wanted records and sectors within a file to always be contiguous (for dumping out the a display) so couldn't go for a fat that ended up with holes left in memory when a file was deleted. For hub ram that would not matter though.
I guess this is relevant to this post because this code originally started with memory locations hard coded but it got too complicated keeping track of everything when you wanted to change things later.
This idea would work in any language - Spin, Pasm, C, etc.
The propeller chip runs software. It allows you to have pseudo like hardware devices that are written in software. You need to know how to program device drivers in software to use the propeller chip.
It is a very nice processor, if you know how to use it, for handling many different things at once. But, given its age now. The industry has mostly moved on.
I agree that the lack of documentation makes it hard to use. You need to buy a Hydra book and read it if you want to understand how to use the processor. Otherwise you will be at a disadvantage, unless you are very skilled and have plenty of time on hand.
Without being able to program in ASM you really can't unlock the true potential of the chip. You also need to be very clever so that you can optimize your code to run ultra fast.
Programming in ASM is considered taboo by many people now.
The features of COGC and LMM should go far to helping out the speed and code density problem. Too bad prop GCC was not around 6 year ago.
There have been a lot of very wise and accurate comments in this thread, and it is not even 12 hours old. This should show Parallax there is still something very amiss with their documents and searches. Now let me discuss some points...
Indentation
Anyone who thinks structured programming and indentation are not a combination that they should strive for is not a real (commercial) programmer. But the real issue here is the tools (PropTool) because it would be a simple matter to permit braces as an alternative to indentation, all by a setting. In fact, the editor should be able to automatically switch between these two - it should be quite simple code. But alas, PropTool does not even have #define, #ifdef... nor even a proper #include. The private free homespun and bst have some of these. And yes, there is an open compiler coming, but it's not here now. BTW the indentation markers can be turned on to view your code in PropToool.
Spin Yes its slow, but often this does not matter for the main program. While its a bit different to C and basic, etc, it is not that different that an experienced programmer shouldn't be able to pick it up in hours - yes you will need to refer to the manual at times (loaded with PropTool and available from the help menu). Don't forget to print the 2 or 4 page summaries for both Spin and Pasm.
C, Forth, Basic, etc Yes there are other languages for the prop. Catalina C is stable, free, well supported and has been around for a couple of years. (wash my mouth out because the GCC guys want to deny it exists - criticism intended).
Documentation Sadly lacking for professionals who just want to find the document and scan it for what they want. You see, we are using the prop in ways it was never intended. Did you notice the SD card being used in Brian's project? All the documents (and they are hard to find) are more aimed at the hobbyist, not professionals. That is changing, but very slowly. App Notes are thin, but are being added consistently.
Re-use of Hub RAM There are a great deal of threads devoted to this subject. All advanced users struggle with this. They are looking for a defined way and there is none. There is not even agreement, nor enthusiasm, to define a semi standard way. Heck, others and I cannot even get discussion going about a standard way of defining a PASM "blob" interface (a standard way to call objects - cogs with drivers loaded)
@Brian: Take a look here http://forums.parallax.com/showthread.php?138251-A-Propeller-OS-that-can-run-on-multiple-hardware...&highlight=propeller+os for a basic propeller OS that defines a small amount of top hub memory. It shows how the cogs can be simply loaded and started, then reclaim almost all of hub for reuse (from $0010 to $7xxx) and you can load this program and let if run. I am sure this will simplify your goals. My work is based on others before me, but I am trying to extend it into a useful and standard product that can run with any software language that the prop has. I think you will find that while this is a wip, being able to load and run ZiCog/CPM and then back to the OS again shows just what the prop can in fact do (ZiCog is an 8080/Z80 software emulator in the prop that runs most/all the CPM2.2 programs - it requires external SRAM).
There is a 4port serial object that you may also find useful in your project(s). I have done a FulDuplexSerial_006 version that allows larger buffer sizes to be defined.
Please don't give up on the prop. While it's different, it is well worth the effort and is easier in the long run. Unfortunately Parallax doesn't have the resources to pour unlimited funds into the Prop. They are working through this, but it does take time even, if it is too long in our minds.
The documentation and support by the technical writers & engineers at Parallax is actually quite good. I have yet to have questions that could not be answered and also got design suggestions. Many companies have nice development kits but lack the backup documentation and people side. Try looking for comparable levels of info on a Launchpad for example. Personally, I liked the community based support approach of the propeller which is one of the reasons I chose it as a processor. The end-users (hobby and engineers) provide a depth of insight that is great way to move beyond more traditional manuals/guidebooks. I also find it interesting that it also creates an environment where others are writing books (e.g. on PASM) interactively with forum input. Yes, I started plinking on the old Textronix green screen alone in the computer lab with a giant manual they took years to write but the more I get used to it.. ... this new community based documentation and even user developed operating systems is an amazing evolution in advancing the technology.
It's counterproductive as heck for to make users pay $$ for a book just to use video and learn assembly. I mean reading that so called Parallax manual one wouldn't know you could run VGA on the Prop or that it uses software defined peripherals. It lacks big time. I learned far more from the gurus here than I ever did from the so-called manual.
Not a smart way of selling the Prop to the commercial world.
Compare it to the documentation and app notes of that other micro with software defined peripherals like the PSOC5. There isn't one and the PSOC5 hasn't been around for very long either and the Prop and it's been around for 6 years. I know Parallax doesn't have the resources of Cypress but it's no excuse to put out a incomplete manual on purpose and forces people to go buy a 3rd party's book in order to get a complete picture.
That's just shoddy.
About SPIN indentation. It's a booby trap for coders the way Chip and company implemented it. Not well thought out at all and needs to go.
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).
I love the indentation. It's clean, lean, easy to read, and when using the Parallax tool, assisted by the indent graphics. I don't often have problems with this, but isn't there a key combination to shift whole blocks of text one way or the other in the Prop tool?
There is a tendency to think that the digital age has arrived and that the Internet and visiting web sites is the only means needed to present information. And yet, we are often away from a keyboard and computer screen, but want to learn.
For every successful user that fully exploits the Forum and other Parallax online resources, there are likely to be even more that either don't have the time to stay engaged on the web, or at least in the beginning would like introductions that are not evolving and changing at a fast pace.
If you have a flair or genius for microcontrollers, the documentation is quite adequate. And I am not really concerned about indents and white spaces in programming becoming an editing issue for some. And the basic Propeller techical PDF has vastly improved from its early releases. Details such as realistic documentation of power distribution amongst all 32 I/O pins may be trivial to sophisticated engineers that realize that 2-5ma per pin (and even less) is adequate for nearly all designs. But some people do read these documents an learn via suggestions.
But I what I suspect is that the average person that walks in a store and is browsing would be more easily engage if there were several easy to get into texts available about different aspects of Propeller programming. And they might be more inclined to return, buy another text and re-engage repeatedly. These "small ticket" items are an entry point to loyal users.
'
It is about reaching more people that are studying in different moralities that those that visit here. Those people do exist.
It is about sustaining interests of people that have bought the Propeller, but at some point set it aside for a variety of reason. Some would like to restart their studies, but can't seem to find an entry point; others may dislike to participate in threaded online discussion.
Quarterly publication of useful Application Notes, focused topic entries, and more sophisticated concept issues - such as memory mapping; would all broaden AND sustain Parallax's customer base. "Nuts and Volts" and "Servo" magazine are useful media, but for many the presentation is not appealing to their level of experience or something they want to keep up with.
A lot of this was done and done well with the BasicStamp, but seems to have fallen off with later products.
Obviously, Parallax is doing something about all this as they created Parallax Semiconductor as a portal for more professional users that do not want to interact with a hobbyist community. But what I am trying to say is that a stream of on-going publications that are not big texts, but useful and interesting are as important to selling as occasional free shipping or discounted items. Maybe even more important to large volume sales. And there are a variety of audiences.
It does NOT have to be a huge stream of publications, just a steady one. Maybe someone needs to be installed as an in-house editor-in-chief. Is that really too expensive and dreadful?
Small E-Books on Amazon could be another interesting publication channel. Whet people's appetites and prime the pump. Though I generally do not buy E-Books, a series on Propellers would be an easy exception as I wouldn't have to pay shipping or make a huge commitment to reading 600-700 pages.
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.
Well, I am rather embarrassed.
The Parallax Semiconductor.com has a very good presentation for the professional and a series of very useful Application Notes. It seems that portion of what I have suggested is already in place.
My greatest frustrations are with age and not enough time to catch up will all that is going on here. This is not Parallax's fault, I was just born too soon. The Propeller is very stimulating and I see at Parallax Semiconductor very clear presentation of what the Propeller2 will be.
What am I trying to say?
For the Professional, so to Parallax Semiconductor and get the kind of interaction you expect.
For others, occasionally visit Parallax Semiconductor to get the short story and clarity.
For those that want to vent and complain, just continue this thread until exhaustion sets it.
I'm in the same boat, first chip and firmware language as well.
I don't care much about the indentation, I did not like it at first and prefer brackets like in c sharp, but it's a non issue as it takes a few minutes to adjust to. The problem is you have terrible documentation and a terrible IDE, I taught myself c sharp in 2 months because of the IDE, it took me 2 years to feel confident about spin, because of the lack of documentation and the IDE. An IDE with step and break points and some sort of pop up on a virtual software emulator would make an absolute world of difference and would *propel* this product to first class. At that point we could all experiment and figure things out in a reasonable amount of time. The IDE should also have a terminal built into it and have intellisense.
However, there are so many things that I would have never known without the forum that either are not documented in the manual or if they are they are not documented in a way that a noob would be able to read and understand or file away for the future when things start falling into place.
An example would be that there is actually 16kb on top of the 32kb that is used for only cog ram and that cog ram is non addressable by hub ram or other cog ram. A picture stating this would be spectacular.
Another would be bytes vs longs. Cog ram is longs and hub ram is bytes. I learned to do just about everything defined as a long in the var section, but if you want to have a string, a byte array is best and appropriate. And then we having strings, one of the biggest pains of the propeller, no string handling. IMO they should have went back and rewritten the interpreter to have some string functionality built into it. I asked Chip about this and he flat out told me they screwed up and forgot ... fine but go back and fix it.
Another, would the lack of examples for each code. It isn't hard to embed a basic working pop up version into acrobat, I say pop up so that the propeller manual didn't become 1000 pages after this. This way we can all reverse engineer, we are all probably pretty good at reverse engineering code, sans a few geniuses on here that's the only way you can learn on your own.
Another, risc vs cisc and basic processor functionality. This should be touched on a bit so that the user can grasp how the chip works and why it was designed that way, even wordage saying go to wikipedia would be good. I didn't know this difference existed until I tried do a mul or div in PASM. To me the top down explanation from the designer is always helpful, if you know their vision you can sometimes infer certain properties.
Some more
How to memory map
Cnt rollover and the proper way to deal with that
The proper way to check pin states in PASM
PASM divide by base 10
Blinking an LED in PASM
Sharing data between cogs in PASM
Local longs vs global longs vs return aliases
Basic bytemove reverse engineerable example
Floating point math example
A reverse engineerable way to and basic example to send commands to the propeller to update variables or change behavior through the PST (I can even provide this for you)
A detailed explanation on addresses vs variables with whys
The fact that the ftdi chip causes the prop to reset when hooked up for a long time
Basic prop scope oscilloscope usage for those of us that have not had classroom time with an oscope
So how did I come up with this list? I just went back and looked through the posts I've started. Some of the posts made me laugh and show how far I've came, even in the past year, but that is only because of the forum users and their generous help to me, not because of any assistance Parallax provided.
[size=+2]So Parallax, are you listening? I know it doesn't behoove you to jump into some possible smear the queer thread, but really I think a no reply and no acknowledgment says no care.[/size]
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).
Documentation or lack of documentation regardless, you may want to moderate your last post regarding the type of thread this is before it is moderated for you. Passion about a subject is one thing but your last comment has crossed the line.
Regarding documentation, despite what everyone thinks, it isn't easy to do well. When it's done well and accurately and meets everyone's needs, it's a thankless job that mostly goes unnoticed. When it's done poorly, or is incorrect and inaccurate, everyone knows how to fix it. I've been trying to write demos and tutorials for propgcc - it's not easy. You need to learn a lot to cover all the bases. You need to submit questions and drafts for peer review so what you write is correct. You need to address the needs of many different audiences. Yes, you learn a lot but it's not free, you end up earning what you learn....and if you do it well (not saying that I am), the parts that get mentioned and talked about are the parts you forgot or didn't get quite right.
Most everyone commenting appears to know exactly what is needed to make the Propeller a success and the programming task easier(at least to answer the questions they have or had).
Why don't I see anyone writing anything up?? Where's the threads for "Hey, I just finished this project and learned how to do this.....here's an example and a tutorial." Where are the submissions of application notes/educational tutorials/examples/blog entries for all these tricks folks are learning while they learn things aren't documented??
It's easy to complain, it's harder to try and fix things or to provide solutions to justify your complaint and then make things better for those following in your footsteps.
SO, what say you, community?? Let's put our words where our words are. Let's provide the community with community documentation. Takes too much time and effort? Not sure you got every step correct? Afraid your documentation will get cut to pieces in peer review? Afraid you can't write? Don't have a place to post your final draft where it won't get buried in the forum traffic?
You had enough time to complain. You had enough time to jump on the band wagon to bash Parallax. You had enough time to prowl the forums to get yoru questions answered and piece together the solution you needed. Spend some of that time documenting........yeah, it's not so much fun writing and re-writing and revising and testing examples, is it???
Need help?? I'm not a pro but I'll try and help.
Do we need a space for user documentation? Does it need a moderator/editor (yes, documentation needs to be fed and cared for like any living thing)? Maybe Parallax can help with this part.
I assume most of you spouting off about the quantity and quality of documentation provided by other companies realize that those other companies have documentation departments larger than ALL OF PARALLAX!
I throw down the challenge, bury me in examples and tutorials and things that aren't in the documentation (BUT you need to document them!!!). Make me regret having done this! Make me beg the community for help organizing all this material I'm sent! If we can present Parallax with a solution to the problem, I'm SURE they will help us out. If we just cry to them about what's missing, they will look at their resources (which are spread pretty thin delivering quality hardware and service to all of us), they may not be able to do much for the documentation!!!
turbosupra: Unfortunately it is not Parallax's job to teach you to program. I think you are expecting way too much. The forums have been a great help to you, but you must also learn to do some research and learning on your own. There are some great tutorials for the beginner. My apologies for being so harsh.
I am in agreement that there are some features that require more info and examples. These are for experienced programmers that may use the prop commercially. This is the area that Parallax needs to expand upon if the prop is to really gain a lot of commercial use. The tools are part of this, and while this is finally being addressed, it is years too late. Hindsight is great - it's a shame PropTool source wasn't available, warts and all. At least the users here could have provided the basic enhancements that have not even begun yet.
BTW there is a prop memory diagram and even a chip die picture which shows hub and cog memory. Obviously some complaints are from those who have not bothered to read what is available.
Yes, I'm sure everyone's listening here. We need to make better documentation. This is principally my fault, since I am the one who should have produced more bottom-level docs. I really wanted to make a short Spin manual, since there's actually not a whole lot anyone needs to know about it, but I never got to it because of other projects.
[SIZE=+2]So Parallax, are you listening? I know it doesn't behoove you to jump into some possible smear the queer thread, but really I think a no reply and no acknowledgment says no care.[/SIZE]
Of course we care and we are listening, but it's nearly by chance that I caught this thread since I'm on vacation. I concur with several of the statements in this thread, but I also think some of the expectations are truly beyond our capability right now. Consider that our R&D staff is immersed in Propeller 2, that our FAEs are gone to customer sites, that a number of our team are on vacation, our manufacturing staff is running two shifts and that our Education staff is traveling to run courses.
The expectations are that we perform like a silicon designer and manufacturer, competing against companies 1000x our size. We're a staff of 45 people with a sizable investment in our next product. It would be an easy business to run if we had short-term goals.
Propeller 2 will give us a great opportunity to do our best to document, simplify and demonstrate to everybody's satisfaction. We have plans to simplify the documentation base for it, too, rather than have it spread across a wide number of books as you see at present.
mindrobots: Just read your post after I posted mine. Just to say a little history... See my signature - there are 2 links to a collection of threads (index) of things that interested me. Others did the same too. We asked for these to be made stickies so others could easily find them. We are still waiting...
Um, Chip, not to tell Parallax how to allocate resources, but please keep on doing what you're doing....lots of people can take up the slack on documentation.....you're the only one that can design Propellers!!!
Yes, I'm sure everyone's listening here. We need to make better documentation. This is principally my fault, since I am the one who should have produced more bottom-level docs. I really wanted to make a short Spin manual, since there's actually not a whole lot anyone needs to know about it, but I never got to it because of other projects.
I take it Chip that we can expect to get our hands on Prop II real soon now seeing you have the luxury of taking the time to chat You must be just about done!
However..........if Prop II is some way off then GET BACK TO IT! and don't worry about the documentation for now
(Good to see you are still sane, those reports I heard about you just weren't true. But then again I see you got your Fozzie back...waka waka)
Ken: Please read my last post. I will ask again for a sticky that we can add indexes too. At least then, there would be a place where various info could be found. I think it should be on the forum, not on a wiki. There are a lot of us here who are willing to help, if only given a little support (and I don't mean anything tangible). I have not bothered to update my indexes since the forum software changed because it seemed to me Parallax was not interested.
I take it Chip that we can expect to get our hands on Prop II real soon now seeing you have the luxury of taking the time to chat You must be just about done!
However..........if Prop II is some way off then GET BACK TO IT! and don't worry about the documentation for now
(Good to see you are still sane, those reports I heard about you just weren't true. But then again I see you got your Fozzie back...waka waka)
Right now, the synthesis guy is finishing the physical design of the main logic block, with current focus on the power grid. I'm just wrapping up testing of every instruction and functional block on the FPGA. If I find a bug and fix it, or make an enhancement, it just goes into the synthesis guy's flow without any significant disruption to his work. Today I am working on finishing the register remapping tests, then I must verify that the SETXFR-related block moves data correctly between pins and the CLUT/quadlongs. After that, I want to retest all the video shifter modes to make sure nothing got broken towards the end. Everything else that has to do with the main logic block is known to be working soundly. I've found and fixed a few bugs over the last few weeks, and also made a few minor tweaks. The window will be closing soon, though, as the synthesis work finishes. I'm maybe two days away from having my stuff done, and he's probably two weeks away. Meanwhile, Beau is making sure the padframe (with all the pins and memories) properly accommodates the logic block. There are 5,692 connections between the two, including the power taps. 3,752 of those are signal connections.
An example would be that there is actually 16kb on top of the 32kb that is used for only cog ram and that cog ram is non addressable by hub ram or other cog ram. A picture stating this would be spectacular.
Another would be bytes vs longs. Cog ram is longs and hub ram is bytes.
An example would be that there is actually 16kb on top of the 32kb that is used for only cog ram and that cog ram is non addressable by hub ram or other cog ram. A picture stating this would be spectacular.
I may have a bad memory on this but aren't these things about the first things you find out when you open the Propeller manual? I'm sure there used to be an architecture diagram in there.
And then we having strings
You may have a point there. I guess the fix is not in the interpreter but if the Spin language features and compiler.
Another, would the lack of examples for each code.
Do you mean the PASM op codes? Might be useful but the manual explains PASM instructions ver clearly.
Another, risc vs cisc and basic processor functionality
Could you elaborate what you mean there? Who cares if you class the Prop as RISC or CISC? The instructions do what the documents say they do and that's what you need to know to use the thing. The definition of RISC or CISC is very woolly anyway.
I didn't know this difference existed until I tried do a mul or div in PASM.
Not sure what mul and div have got to do with RISC or CISC. Some processors don't have mul or div. mostly because there were not enough transistors available to get them in.
Some more ...[a big long list]
Yes I can see your point there. However many of the items on your list are not really about documenting the Propeller so much as teaching basic programming techniques.
I agree that a tutorial teaching these fundamentals from a Propeller perspective would be a great idea. Anyone up to writing it?
I can respect turbosupra's opinion about the IDE and documentation although I don't share it. There's probably a lot of personal taste in evaluating IDEs, and I like the spintool fine for the most part. I personally also like the style of spin programming and requiring indentation. I've programmed in c, c++ and java for a number of years but like spin much better.
But I completely agree with his wish for advanced coding examples. The propeller reference manual is great for specific instruction syntax, and the beginner code examples are fine for getting started on your first day, but we could use a ton of examples of intermediate to advanced spin and PASM techniques.
A wiki style OBEX might be a way to accomplish that. Maybe with a restricted group of editors selected by Parallax from forum members rather than free-for-all editing. The current unmanaged, unindexed OBEX is almost useless. It's like the attic of my garage; everything that anyone has ever tossed there is still there, collecting dust and making it harder to find useful code. I'm sure there are plenty of forum members with the interest, coding skills and sensitivity to the needs of the community to do this, so why not let them help?
Why am I just discovering this now? I doubt I can find it discussed the PASM presentation.
Some formal presentation of using hub RAM and memory mapping might be very helpful. It certainly is a big jump from what goes on in BasicStamps.
I can't answer why you're just discovering this, but it's in my Propeller Manual V1.0 on page 31. I've had this book for 2-3 years so the information has been out there.
Um, Chip, not to tell Parallax how to allocate resources, but please keep on doing what you're doing....lots of people can take up the slack on documentation.....you're the only one that can design Propellers!!!
Comments
So here an example how to start 3 PASM cogs and reuse the hubram. The CON section defines the addresses of the shared variables. If you have the shared variables in the first 512 bytes in hubram, you can access them quite easy in PASM with immediate addressing, so no passing of pointers in the par is needed.
Perhaps this convinces also Sapieha that it IS possible....;-)
The code is for a Quickstart or Demoboard. One cog overwrites the hubram from which all the cogs are startet to show that this not affects the cogs. The second cog writes to a shared variable the flash speed, and the third reads this speed variable and flashes the LED.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 #$14, startFlag, #18,speed 'enumerate shared variable adresses #$30, shareEnd 'hubram $0030...$7FFF free segment1 = $3000 'define some hub segments segment2 = $4000 DAT byte 0[28] 'reserve 28 byte in hubram ($14..$2F) 'for shared variables and init to zero PUB Main cognew(@cog1,0) 'start the 3 cogs cognew(@cog2,0) coginit(cogid,@cog3,0) 'last one reuses this spin cog DAT ' cog 1 code: overwrite hubram until segment1 org 0 cog1 rdbyte tmp1, #startFlag wz 'wait for startflag if_z jmp #cog1 mov tmp1, hubBeg :loop wrlong zero, tmp1 'clear hubram long add tmp1, #4 cmp tmp1, hubEnd wc 'all done? if_b jmp #:loop mov dira, led1 'LED1 on when done mov outa, led1 :halt jmp #:halt tmp1 long 0 zero long 0 bit15 long 1<<15 led1 long 1<<16 hubBeg long shareEnd hubEnd long segment1 - 1 ' cog 2 code: change shared speed variable every second org 0 cog2 rdbyte tmp2, #startFlag wz 'wait for startflag if_z jmp #cog2 rdlong clkfq, #0 'get clockfreq mov tmp2, cnt add tmp2, clkfq mov dira, led2 :loop waitcnt tmp2, clkfq 'wait 1 second or outa, led2 'led2 on wrlong speed1, #speed 'change speed for cog3 waitcnt tmp2, clkfq 'wait 1 second andn outa, led2 'led2 ooff wrlong speed2, #speed 'change speed for cog3 jmp #:loop tmp2 long 0 clkfq long 0 speed1 long 4500000 speed2 long 9000000 led2 long 1<<17 ' cog 3 code: flash the LED according speed variable org 0 cog3 wrbyte tmp3, #startFlag 'set startflag mov dira, led3 :loop rdlong tmp3, #speed wz 'read speed variable if_z jmp #:loop 'wait until speed > 0 add tmp3, cnt waitcnt tmp3, #0 'wait speed periode xor outa, led3 'toggle led3 jmp #:loop tmp3 long 1 led3 long 1<<18Andy
An excellent way to give all users a 'leg up', especially on less conventional silicon, is many small, working examples.
The question asked here is a good one, and not uncommon, so it should have an example.
#32 seems to show how it can be done.
It is the classic 'a picture is worth 1000 words', and in this case a functional code block (aka picture) , is worth FAR MORE than dry text in a manual.
Define an array memlocation[] and size[]. Define one variable "filecounter".
Load in file0 which might be 50k. memlocation[0] is 0, size[0] is 50k and filecounter is now 1.
Load in file1 which might be 20k. memlocation[1] is 50k, size[1] is 20k and filecounter is now 2.
Within a file you can do other things. eg file0 and file1 might have come off the SD card, but file2 could be a whole bunch of strings. So within file2 are all the names and locations of strings.
file3 might be another bitmap off the SD card.
To "wipe" the ram disk, set filecounter to zero.
There are more complex "fat" type systems of memory management and indeed I seriously looked at implementing the CP/M fat as a memory management tool, but for my particular application I wanted records and sectors within a file to always be contiguous (for dumping out the a display) so couldn't go for a fat that ended up with holes left in memory when a file was deleted. For hub ram that would not matter though.
I guess this is relevant to this post because this code originally started with memory locations hard coded but it got too complicated keeping track of everything when you wanted to change things later.
This idea would work in any language - Spin, Pasm, C, etc.
It is a very nice processor, if you know how to use it, for handling many different things at once. But, given its age now. The industry has mostly moved on.
I agree that the lack of documentation makes it hard to use. You need to buy a Hydra book and read it if you want to understand how to use the processor. Otherwise you will be at a disadvantage, unless you are very skilled and have plenty of time on hand.
Without being able to program in ASM you really can't unlock the true potential of the chip. You also need to be very clever so that you can optimize your code to run ultra fast.
Programming in ASM is considered taboo by many people now.
The features of COGC and LMM should go far to helping out the speed and code density problem. Too bad prop GCC was not around 6 year ago.
Indentation
Anyone who thinks structured programming and indentation are not a combination that they should strive for is not a real (commercial) programmer. But the real issue here is the tools (PropTool) because it would be a simple matter to permit braces as an alternative to indentation, all by a setting. In fact, the editor should be able to automatically switch between these two - it should be quite simple code. But alas, PropTool does not even have #define, #ifdef... nor even a proper #include. The private free homespun and bst have some of these. And yes, there is an open compiler coming, but it's not here now. BTW the indentation markers can be turned on to view your code in PropToool.
Spin
Yes its slow, but often this does not matter for the main program. While its a bit different to C and basic, etc, it is not that different that an experienced programmer shouldn't be able to pick it up in hours - yes you will need to refer to the manual at times (loaded with PropTool and available from the help menu). Don't forget to print the 2 or 4 page summaries for both Spin and Pasm.
C, Forth, Basic, etc
Yes there are other languages for the prop. Catalina C is stable, free, well supported and has been around for a couple of years. (wash my mouth out because the GCC guys want to deny it exists - criticism intended).
Documentation
Sadly lacking for professionals who just want to find the document and scan it for what they want. You see, we are using the prop in ways it was never intended. Did you notice the SD card being used in Brian's project? All the documents (and they are hard to find) are more aimed at the hobbyist, not professionals. That is changing, but very slowly. App Notes are thin, but are being added consistently.
Re-use of Hub RAM
There are a great deal of threads devoted to this subject. All advanced users struggle with this. They are looking for a defined way and there is none. There is not even agreement, nor enthusiasm, to define a semi standard way. Heck, others and I cannot even get discussion going about a standard way of defining a PASM "blob" interface (a standard way to call objects - cogs with drivers loaded)
@Brian: Take a look here http://forums.parallax.com/showthread.php?138251-A-Propeller-OS-that-can-run-on-multiple-hardware...&highlight=propeller+os for a basic propeller OS that defines a small amount of top hub memory. It shows how the cogs can be simply loaded and started, then reclaim almost all of hub for reuse (from $0010 to $7xxx) and you can load this program and let if run. I am sure this will simplify your goals. My work is based on others before me, but I am trying to extend it into a useful and standard product that can run with any software language that the prop has. I think you will find that while this is a wip, being able to load and run ZiCog/CPM and then back to the OS again shows just what the prop can in fact do (ZiCog is an 8080/Z80 software emulator in the prop that runs most/all the CPM2.2 programs - it requires external SRAM).
There is a 4port serial object that you may also find useful in your project(s). I have done a FulDuplexSerial_006 version that allows larger buffer sizes to be defined.
Please don't give up on the prop. While it's different, it is well worth the effort and is easier in the long run. Unfortunately Parallax doesn't have the resources to pour unlimited funds into the Prop. They are working through this, but it does take time even, if it is too long in our minds.
It's counterproductive as heck for to make users pay $$ for a book just to use video and learn assembly. I mean reading that so called Parallax manual one wouldn't know you could run VGA on the Prop or that it uses software defined peripherals. It lacks big time. I learned far more from the gurus here than I ever did from the so-called manual.
Not a smart way of selling the Prop to the commercial world.
Compare it to the documentation and app notes of that other micro with software defined peripherals like the PSOC5. There isn't one and the PSOC5 hasn't been around for very long either and the Prop and it's been around for 6 years. I know Parallax doesn't have the resources of Cypress but it's no excuse to put out a incomplete manual on purpose and forces people to go buy a 3rd party's book in order to get a complete picture.
That's just shoddy.
About SPIN indentation. It's a booby trap for coders the way Chip and company implemented it. Not well thought out at all and needs to go.
Python works the same way with indentation...
About the hydra manual, I didn't really learn a lot from it either to be honest. The forums is the best place to learn and it really helped me.
The hydra book got me started and had a lot of additional code examples to help me out with. I guess it was a catalyst.
I would say it's better to have had the hydra book then not.
BTW: The book is free now...
Anyway, I agree with you.
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
yes..... mark block and use TAB and Shift-TAB ...
not really like in VS but alike. Somehow its not really using tab-difference its different, as always with Parallax. try out and you will see.
Enjoy!
Mike
For every successful user that fully exploits the Forum and other Parallax online resources, there are likely to be even more that either don't have the time to stay engaged on the web, or at least in the beginning would like introductions that are not evolving and changing at a fast pace.
If you have a flair or genius for microcontrollers, the documentation is quite adequate. And I am not really concerned about indents and white spaces in programming becoming an editing issue for some. And the basic Propeller techical PDF has vastly improved from its early releases. Details such as realistic documentation of power distribution amongst all 32 I/O pins may be trivial to sophisticated engineers that realize that 2-5ma per pin (and even less) is adequate for nearly all designs. But some people do read these documents an learn via suggestions.
But I what I suspect is that the average person that walks in a store and is browsing would be more easily engage if there were several easy to get into texts available about different aspects of Propeller programming. And they might be more inclined to return, buy another text and re-engage repeatedly. These "small ticket" items are an entry point to loyal users.
'
It is about reaching more people that are studying in different moralities that those that visit here. Those people do exist.
It is about sustaining interests of people that have bought the Propeller, but at some point set it aside for a variety of reason. Some would like to restart their studies, but can't seem to find an entry point; others may dislike to participate in threaded online discussion.
Quarterly publication of useful Application Notes, focused topic entries, and more sophisticated concept issues - such as memory mapping; would all broaden AND sustain Parallax's customer base. "Nuts and Volts" and "Servo" magazine are useful media, but for many the presentation is not appealing to their level of experience or something they want to keep up with.
A lot of this was done and done well with the BasicStamp, but seems to have fallen off with later products.
Obviously, Parallax is doing something about all this as they created Parallax Semiconductor as a portal for more professional users that do not want to interact with a hobbyist community. But what I am trying to say is that a stream of on-going publications that are not big texts, but useful and interesting are as important to selling as occasional free shipping or discounted items. Maybe even more important to large volume sales. And there are a variety of audiences.
It does NOT have to be a huge stream of publications, just a steady one. Maybe someone needs to be installed as an in-house editor-in-chief. Is that really too expensive and dreadful?
Small E-Books on Amazon could be another interesting publication channel. Whet people's appetites and prime the pump. Though I generally do not buy E-Books, a series on Propellers would be an easy exception as I wouldn't have to pay shipping or make a huge commitment to reading 600-700 pages.
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.
The Parallax Semiconductor.com has a very good presentation for the professional and a series of very useful Application Notes. It seems that portion of what I have suggested is already in place.
My greatest frustrations are with age and not enough time to catch up will all that is going on here. This is not Parallax's fault, I was just born too soon. The Propeller is very stimulating and I see at Parallax Semiconductor very clear presentation of what the Propeller2 will be.
What am I trying to say?
For the Professional, so to Parallax Semiconductor and get the kind of interaction you expect.
For others, occasionally visit Parallax Semiconductor to get the short story and clarity.
For those that want to vent and complain, just continue this thread until exhaustion sets it.
I don't care much about the indentation, I did not like it at first and prefer brackets like in c sharp, but it's a non issue as it takes a few minutes to adjust to. The problem is you have terrible documentation and a terrible IDE, I taught myself c sharp in 2 months because of the IDE, it took me 2 years to feel confident about spin, because of the lack of documentation and the IDE. An IDE with step and break points and some sort of pop up on a virtual software emulator would make an absolute world of difference and would *propel* this product to first class. At that point we could all experiment and figure things out in a reasonable amount of time. The IDE should also have a terminal built into it and have intellisense.
However, there are so many things that I would have never known without the forum that either are not documented in the manual or if they are they are not documented in a way that a noob would be able to read and understand or file away for the future when things start falling into place.
An example would be that there is actually 16kb on top of the 32kb that is used for only cog ram and that cog ram is non addressable by hub ram or other cog ram. A picture stating this would be spectacular.
Another would be bytes vs longs. Cog ram is longs and hub ram is bytes. I learned to do just about everything defined as a long in the var section, but if you want to have a string, a byte array is best and appropriate. And then we having strings, one of the biggest pains of the propeller, no string handling. IMO they should have went back and rewritten the interpreter to have some string functionality built into it. I asked Chip about this and he flat out told me they screwed up and forgot ... fine but go back and fix it.
Another, would the lack of examples for each code. It isn't hard to embed a basic working pop up version into acrobat, I say pop up so that the propeller manual didn't become 1000 pages after this. This way we can all reverse engineer, we are all probably pretty good at reverse engineering code, sans a few geniuses on here that's the only way you can learn on your own.
Another, risc vs cisc and basic processor functionality. This should be touched on a bit so that the user can grasp how the chip works and why it was designed that way, even wordage saying go to wikipedia would be good. I didn't know this difference existed until I tried do a mul or div in PASM. To me the top down explanation from the designer is always helpful, if you know their vision you can sometimes infer certain properties.
Some more
How to memory map
Cnt rollover and the proper way to deal with that
The proper way to check pin states in PASM
PASM divide by base 10
Blinking an LED in PASM
Sharing data between cogs in PASM
Local longs vs global longs vs return aliases
Basic bytemove reverse engineerable example
Floating point math example
A reverse engineerable way to and basic example to send commands to the propeller to update variables or change behavior through the PST (I can even provide this for you)
A detailed explanation on addresses vs variables with whys
The fact that the ftdi chip causes the prop to reset when hooked up for a long time
Basic prop scope oscilloscope usage for those of us that have not had classroom time with an oscope
So how did I come up with this list? I just went back and looked through the posts I've started. Some of the posts made me laugh and show how far I've came, even in the past year, but that is only because of the forum users and their generous help to me, not because of any assistance Parallax provided.
[size=+2]So Parallax, are you listening? I know it doesn't behoove you to jump into some possible smear the queer thread, but really I think a no reply and no acknowledgment says no care.[/size]
Documentation or lack of documentation regardless, you may want to moderate your last post regarding the type of thread this is before it is moderated for you. Passion about a subject is one thing but your last comment has crossed the line.
Regarding documentation, despite what everyone thinks, it isn't easy to do well. When it's done well and accurately and meets everyone's needs, it's a thankless job that mostly goes unnoticed. When it's done poorly, or is incorrect and inaccurate, everyone knows how to fix it. I've been trying to write demos and tutorials for propgcc - it's not easy. You need to learn a lot to cover all the bases. You need to submit questions and drafts for peer review so what you write is correct. You need to address the needs of many different audiences. Yes, you learn a lot but it's not free, you end up earning what you learn....and if you do it well (not saying that I am), the parts that get mentioned and talked about are the parts you forgot or didn't get quite right.
Most everyone commenting appears to know exactly what is needed to make the Propeller a success and the programming task easier(at least to answer the questions they have or had).
Why don't I see anyone writing anything up?? Where's the threads for "Hey, I just finished this project and learned how to do this.....here's an example and a tutorial." Where are the submissions of application notes/educational tutorials/examples/blog entries for all these tricks folks are learning while they learn things aren't documented??
It's easy to complain, it's harder to try and fix things or to provide solutions to justify your complaint and then make things better for those following in your footsteps.
SO, what say you, community?? Let's put our words where our words are. Let's provide the community with community documentation. Takes too much time and effort? Not sure you got every step correct? Afraid your documentation will get cut to pieces in peer review? Afraid you can't write? Don't have a place to post your final draft where it won't get buried in the forum traffic?
You had enough time to complain. You had enough time to jump on the band wagon to bash Parallax. You had enough time to prowl the forums to get yoru questions answered and piece together the solution you needed. Spend some of that time documenting........yeah, it's not so much fun writing and re-writing and revising and testing examples, is it???
Need help?? I'm not a pro but I'll try and help.
Do we need a space for user documentation? Does it need a moderator/editor (yes, documentation needs to be fed and cared for like any living thing)? Maybe Parallax can help with this part.
I assume most of you spouting off about the quantity and quality of documentation provided by other companies realize that those other companies have documentation departments larger than ALL OF PARALLAX!
I throw down the challenge, bury me in examples and tutorials and things that aren't in the documentation (BUT you need to document them!!!). Make me regret having done this! Make me beg the community for help organizing all this material I'm sent! If we can present Parallax with a solution to the problem, I'm SURE they will help us out. If we just cry to them about what's missing, they will look at their resources (which are spread pretty thin delivering quality hardware and service to all of us), they may not be able to do much for the documentation!!!
Viva Les Documentation!!
I am in agreement that there are some features that require more info and examples. These are for experienced programmers that may use the prop commercially. This is the area that Parallax needs to expand upon if the prop is to really gain a lot of commercial use. The tools are part of this, and while this is finally being addressed, it is years too late. Hindsight is great - it's a shame PropTool source wasn't available, warts and all. At least the users here could have provided the basic enhancements that have not even begun yet.
BTW there is a prop memory diagram and even a chip die picture which shows hub and cog memory. Obviously some complaints are from those who have not bothered to read what is available.
"You can lead a horse to water but you STILL can't make him READ!!!!!"
Yes, I'm sure everyone's listening here. We need to make better documentation. This is principally my fault, since I am the one who should have produced more bottom-level docs. I really wanted to make a short Spin manual, since there's actually not a whole lot anyone needs to know about it, but I never got to it because of other projects.
Of course we care and we are listening, but it's nearly by chance that I caught this thread since I'm on vacation. I concur with several of the statements in this thread, but I also think some of the expectations are truly beyond our capability right now. Consider that our R&D staff is immersed in Propeller 2, that our FAEs are gone to customer sites, that a number of our team are on vacation, our manufacturing staff is running two shifts and that our Education staff is traveling to run courses.
The expectations are that we perform like a silicon designer and manufacturer, competing against companies 1000x our size. We're a staff of 45 people with a sizable investment in our next product. It would be an easy business to run if we had short-term goals.
Propeller 2 will give us a great opportunity to do our best to document, simplify and demonstrate to everybody's satisfaction. We have plans to simplify the documentation base for it, too, rather than have it spread across a wide number of books as you see at present.
Ken Gracey
I take it Chip that we can expect to get our hands on Prop II real soon now seeing you have the luxury of taking the time to chat
However..........if Prop II is some way off then GET BACK TO IT!
(Good to see you are still sane, those reports I heard about you just weren't true. But then again I see you got your Fozzie back...waka waka)
Right now, the synthesis guy is finishing the physical design of the main logic block, with current focus on the power grid. I'm just wrapping up testing of every instruction and functional block on the FPGA. If I find a bug and fix it, or make an enhancement, it just goes into the synthesis guy's flow without any significant disruption to his work. Today I am working on finishing the register remapping tests, then I must verify that the SETXFR-related block moves data correctly between pins and the CLUT/quadlongs. After that, I want to retest all the video shifter modes to make sure nothing got broken towards the end. Everything else that has to do with the main logic block is known to be working soundly. I've found and fixed a few bugs over the last few weeks, and also made a few minor tweaks. The window will be closing soon, though, as the synthesis work finishes. I'm maybe two days away from having my stuff done, and he's probably two weeks away. Meanwhile, Beau is making sure the padframe (with all the pins and memories) properly accommodates the logic block. There are 5,692 connections between the two, including the power taps. 3,752 of those are signal connections.
Yes I can see your point there. However many of the items on your list are not really about documenting the Propeller so much as teaching basic programming techniques.
I agree that a tutorial teaching these fundamentals from a Propeller perspective would be a great idea. Anyone up to writing it?
But I completely agree with his wish for advanced coding examples. The propeller reference manual is great for specific instruction syntax, and the beginner code examples are fine for getting started on your first day, but we could use a ton of examples of intermediate to advanced spin and PASM techniques.
A wiki style OBEX might be a way to accomplish that. Maybe with a restricted group of editors selected by Parallax from forum members rather than free-for-all editing. The current unmanaged, unindexed OBEX is almost useless. It's like the attic of my garage; everything that anyone has ever tossed there is still there, collecting dust and making it harder to find useful code. I'm sure there are plenty of forum members with the interest, coding skills and sensitivity to the needs of the community to do this, so why not let them help?
I can't answer why you're just discovering this, but it's in my Propeller Manual V1.0 on page 31. I've had this book for 2-3 years so the information has been out there.
Big Plus One on that!