Why I Find the Propeller So Frustrating.
Brian Fairchild
Posts: 549
In a very short sentence - 'Lack of documentation'.
I'm already using the Prop in a commercial product where it does great service doing VGA + Mouse + Keyboard + SD Card. In effect, a very smart terminal. The heavy lifting, ie central processing, is left to another device.
I'm now starting a new project/product where the Prop would, on paper, by ideal.
Everything will run as PASM in COGs. A couple of COGs collecting data from the outside world over serial lines, a couple of COGs sending the data back out, a couple of COGs doing the data processing and a couple of COGs carrying out supervisory functions.
Once up and running there is nothing left in Hub RAM that is needed any more; the 8 blocks of 512 longs needed by the COG code having been loaded to the COGs so I should, on paper, have 32k bytes of memory to use for data storage.
Finding out how to use that memory though is a struggle. I've so far spent several hours searching the forum with a variety of search terms with not much luck. I've come to the conclusion that my best bet is to forget trying to get any help from the tools and just work out a memory map on paper and hard code the address of all my variable into the COG code.
I can't help feeling that for a processor so different to the 'norm' there ought to be a lot more documentation. I can quite understand why experienced engineers take one look at the Prop and go 'Huh?'
As someone who isn't a fan of Spin I've found the -mcog option for PropGCC, but no real documentation as to how you use it.
What really frustrating is that I know the Prop should do what I want. But can I justify the time required to find out things for myself?
I'm already using the Prop in a commercial product where it does great service doing VGA + Mouse + Keyboard + SD Card. In effect, a very smart terminal. The heavy lifting, ie central processing, is left to another device.
I'm now starting a new project/product where the Prop would, on paper, by ideal.
Everything will run as PASM in COGs. A couple of COGs collecting data from the outside world over serial lines, a couple of COGs sending the data back out, a couple of COGs doing the data processing and a couple of COGs carrying out supervisory functions.
Once up and running there is nothing left in Hub RAM that is needed any more; the 8 blocks of 512 longs needed by the COG code having been loaded to the COGs so I should, on paper, have 32k bytes of memory to use for data storage.
Finding out how to use that memory though is a struggle. I've so far spent several hours searching the forum with a variety of search terms with not much luck. I've come to the conclusion that my best bet is to forget trying to get any help from the tools and just work out a memory map on paper and hard code the address of all my variable into the COG code.
I can't help feeling that for a processor so different to the 'norm' there ought to be a lot more documentation. I can quite understand why experienced engineers take one look at the Prop and go 'Huh?'
As someone who isn't a fan of Spin I've found the -mcog option for PropGCC, but no real documentation as to how you use it.
What really frustrating is that I know the Prop should do what I want. But can I justify the time required to find out things for myself?
Comments
is that a call/return stack or a data stack? Or does PropGCC used a single stack model?
Theoretically possible ---> In practice not possible to directly implement in any of Tools that we have to it --- Now I have said IMPOSIBLE
You can't find that type of information -- In time I started with Propeller and some people said them write theirs own tools I asked if them can implement that type of programing to IT..
None was interested --
So You need on paper manage all Addresses For COGs then in start up routines for COGs You can Place start addresses for COGs "flags" work areas in PAR part of SPIN start routine.that every COG need test FLAGS for " OK start running " ---> This Flag need be managed by supervisory COG.
After You started COGs and Managed "supervisory COG answers ALL OK ... After that all 32KBytes of HUB Ram are free for YOU
Everybody else seems to be trying to address the memory part of the question.
Like Bryan said, for something so different the documentation (what there is of it) sucks.
The hardware is brilliant. No argument there. From concept to execution.
But the documentation is, at best, amateurish and thin.
Compare what is readily available with the competition.
Starting with the Propeller Manual.
It's a good start at a reference manual.
But precious little in terms of working examples.
The other big ***** is the software.
SPIN in particular.
Everyone (IT and Engineering) I've discussed this with has blown it off out of hand.
"Indentation for program structure? Are you kidding? We're professionals. We don't DO that".
And I can't really blame them.
Software is the most expensive part of any micro project.
Who can a company hire that already knows Spin? Or PASM?
The C compiler may be more interesting, but - again - documentation and examples?
I wandered in here for my first project (ship's bell).
The Prop offered a simple solution to a messy problem - how to get a microcontroller to play
wave files. It worked (after a lot of help from this forum getting up to speed with SPIN).
But I was doing that one for me - not for a commercial product.
(sorry guys - blow me off or do something about it)
Wouldn't this be a nice thing to find on the shelf ar Radio Shack?
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
Thank you, Peter. I may be alone in this opinion, but it seems to me that anyone who calls him/herself a professional programmer, especially those that program in C, should be able to pick up Spin in less than a day.
I'm available for consulting jobs!
The documentation may some day say something about that, but it's more likely that it would be the subject of a chapter in a book written by one of the forum dwellers.
The PropGCC project has pretty decent docs to start with, you just need to go to the Wiki that houses it. For the most part, PropGCC is WYSIWYG, you should learn about the memory models and the provided device drivers.
And yet Parallax claims to have an educational mission. The BasicStamp has had a lot of excellent documentation for beginners, intermediate, and advanced - though the whole topic of how tokens work is rather taboo. But some how the Propeller caught on with a lot of highly intelligent users and the gravy of the business - rank beginners - have to hunt and peck out of the OBEX and the forums unless someone likes their query and mentors them.
Something has slipped in the business model. But it is fixable. If there are writers that are well-informed users. What I fear the most is that everyone has gotten weary of writing for Internet publication for free. But a well-written intermediate course to advance would likely sell. At least I'd buy something if it was well written and NOT 700 pages of filler.
More needs to be done on the publication side with genuine focused utility and less on the next 'fun toy' item. And 200 pages of a good limited focus are far better than an all and everything tome.
The language simply gets the hardware to do what you want. Every language has application it excels at and other applications not so much.
I have yet to find something I could not do in SPIN (albeit VB is my favorite high level language and my very favorite IDE) or PASM. My choice would be to do as much in PASM as it is so clearly defined as to what each instruction does and very few mysteries and above all FAST. I detest C but realize it is a core language for micros and the nice thing is I DON'T HAVE TO USE IT.
Indenting? Sure why not? IMO it makes the code readable and years later when I look at what I created, it is easier to understand what the heck I was thinking.
However, memory mapping? Well I played with that for some time as I use most of the hub after boot for temp storage of running configurations of a pipe organ with 500+ inputs and 1100+ outputs and a bunch of circular Queues of various lengths. I found that using Excel or OpenOffice Calc, with a little pre-planning, allowed me to not only layout my memory but to self assign offset values to my Circular Queue array address locations. I just copy and paste the variables from Excel to my declarations section, delete some Excel artifacts and all my offsets are correct. Certainly not the only way to do this but it is cheap, fast, understandable, reduces errors and minimizes any issues with changing the length of Queues which effect other offsets.
Why did I bother to map this stuff out? If I have any complaints the Prop is not as easy to debug as a VB program and knowing exactly where some data was going to reside was a real time saver. I had Circular Queues with 1,2,3.. hundred bytes long and the memory map made debugging where the data should have been and where it actually ended up much easier.
Of course I could let the compiler figure most of this out, but when I was developing this application, it really helped to see how the memory mapped. I even went to the point of changing background colors in the Excel/Calc worksheets to identify the various Queues.
If I didn't have so much time invested in the prop, and not had some of the forum members invest so much time in me, I would have jumped ship a long time ago.
It doesn't matter if you have the greatest product in the world, if the documentation is poor it'll always be second fiddle at best.
I agree that documentation is a problem with using the Prop. On the other hand, this forum is a great place to ask questions and get answers.
As far as the issue raised about Spin, the biggest problem iwth acceptance in the professional world is that Spin is a proprietary language. This makes it almost impossible to pitch to a project manager. PropGCC helps to resolve this issue.
If you want an example of a cryptic product with terrible (paid) support, no documentation, and utter reliance on the forums for actual support, look no further than VMWare.
So even though the Prop may be frustrating at times, it has certainly provided me a useful learning experience.
With the SX chips, the Application Notes written by Senix and others were a great help. But Gunther's SX Tutorial was equally important. It is 'nice' that all these long experienced programmers find the Propeller easy and interesting. But for the rest of us, trying to pick it all out of Forum Threads and Code examples as daunting. So you see people turning to other platforms in hopes that they can learn more there.
The simple fact is that good writers are hard to come by as it is painstaking work. And Parallax has benefited from a lot of people doing it for free or on speculation. At this point, having some formal publishing goals would enhance interest (meaning sales) and retain a lot of us that cannot seem to break through on our own.
And the publications should be for more than high school students. There are university seniors and juniors that really would seek out the Propeller if the literature was there. And there are professionals that just don't have the time to follow Parallax Forums when they cannot find a good reference.
I suppose that Parallax may be thinking that they can hit a home run with the Propeller2, but I a definitely not on board as I understand too little about the Propeller. Successful enterprises have to do a lot of little things right, not just jump from one big thing to another and hope for the best. Customers might just drift away.
MY rant was mainly about the available documentation not being up to snuff.
(It's not and we all know that.)
But I'm just a customer, struggling to learn this stuff - so what do I know?
(Precious little even now!)
But since the reaction was mainly about SPIN...
I just relayed what my (professional ie: working in the business) friends have told me.
Bottom line is pretty universal too.
Before risking a large project on such a radical chip they would have to budget to study both
hardware and software. (Management still holds the purse strings - not the geeks).
Indentation in source code is important.
It makes the code so much more readable - understandable.
I think we are all in violent agreement there.
But I'm not convinced that indentation - to define the structure of the program - is such a great idea.
Here is why...
If I accidentally delete a parenthesis the compiler will let me know about it right quick.
But accidentally deleting a single space doesn't do that.
It simply morphs the structure of the program into something evil.
That's a much harder thing to find and fix.
For Pete sakes guys, we can't even post code on this forum without invoking the CODE: function.
Why? Because different software handles indentation, tabs, and white space differently.
But I like the Propeller.
So I can live with it if I have to.
But I'm not designing stuff for mass production...
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.
It's not so much SPIN and PASM but how to use the silicon.
I've been designing and coding embedded systems for over 30 years. Started with the 6502, spent a long while with 8051s, was doing multiple 800kbps SDLC serial links on a 5MHz 8085 back in 1980, etc etc. I'm very happy getting my head around the silicon but am struggling with the lack of information on how to do 'stuff'. It's not as if I have much choice on my toolset.
No argument from me either.
Hardly new though. What is it now? 6 years?
I guess it depends on where in the market the Prop is perceived to lie. I don't really think that it's the job of the documentation to place a chip in one segment or another except maybe in the 'hobby' section. And I don't mean that as an insult. Surely the point of documentation is to fully map out how the silicon works and how the supplied tools work.
I'm downloading it now.
I think it's great that people are so willing to help and engage in discussions. I'm genuinely in awe of some people's knowledge. That said, people's knowledge and time is no substitute for proper documentation.
I have noticed one type of post commonly seen on other chip support forums is missing around here though. You don't often see RTFM posts.
Indeed. When using PASM, without the ability to, or information on, reusing Hub RAM after the COGs have been loaded, you are effectively wasting up to 16kbytes, or 50%, of your 'global' RAM.
As for languages, much as Spin isn't my first choice, I'm not worried given that PropGCC is on the horizon. And let's face it, even C is a poor relation to PL/M!
Don't get me wrong, as I've said before, I think the Prop and its community is great. Just look at what people do with the chip and you see what huge potential it has. However, there's no getting away from the fact that if you have a chip which doesn't even have a basic UART, you need to tell people why it doesn't, why it doesn't matter and how to implement one which knocks the spots of all those hardwired UARTS in other people's chip.
From many years back, I think one can recognize that Forest Mim's Notebooks, Texas Instruments texts, and Tab Publications were a very important part of driving sales in some of Radio Shack's halcyon days. But the publications eventually were not forthcoming and the stores had stocks of parts without anything to inspire people to purchase.
Continued publications are an important part of driving demand in electronics. In earlier days, it was the ARRL Handbooks and related publications. But it has always been something. Books do not have to be big. In fact, a 100 page book gets carried and read far more in depth that a big heavy one. If Parallax were to publish 6-8 'focus' books for the Propeller to be sold retail in Radio Shack and other outlets, I suspect that the resulting sales would be better and more sustainable. Plus, the revenue would pay at least the writer's wages.
The other alternative is rather grim. Imagine an overstock of inventory of good quality at Radio Shack sitting on clearance tables nation-wide. Radio Shack has repeatedly ended up in such straits because they tried to retail without good support.
As far as the documentation of the silicon, all I read is that the Propeller will operate at 300ma max. No discussion of banks of pins having further limits due to bus distribution and the rather dubious statement of 40ma per pin. That certainly leaves an engineer out in the cold when he wants to design a reliable circuit for a major consumer product. And yet, the Propeller likely could be well accepted to be under the hood of a lot of consumer products as a better solution. The literature creates a commercial following as well.
I hate to see Parallax struggle against its own internal culture. But that may be what we are really discussing. The next step is to move up to some serious thoughts of documents and publications as a means to drive demand across the board. Hoping you can get this stuff gratis is rather passe.
It would be quite wonderful to walk into a store and see a series of Propeller titles sitting aside the hardward -- like "Getting started in GCC on the Propeller", "Getting started in Forth on the Propeller", "Getting started with VGA video on the Propeller", and so on.....
The Arduinos would be easier to ignore...
Yes they will - whitespace is too brittle in my and many other people's opinion to be controlling code semantics - reformatting can be accidental and completely change the meaning of a program (and still compile). Its one of those things that looks cute but can bite you very hard - although with care there is no deep problem with indentation controlling the parse, it just catches people out too often to be a great idea - its one more thing to worry about. Don't get me wrong though, its nowhere near as bad as the design of XML! (In fact replacing XML with an indentation-driven language would be a big improvement! - though the real problem is that its a markup language but gets used as a configuration language instead)
Don't get me wrong, I'm not really ranting, I just find indentation is causing a little too much worry to be worth the neat appearance - many people have stronger opinions both ways!
You might not have seen Algol68 but it had a good idea with bracketing IF with FI, DO with OD, BEGIN with END, etc. and generally made it very clear which block you were closing off (rather than the anonymous "}"). Human readable languages should have a balance between conciseness and redundancy. Shell scripts are an example of where the balance is wrong one way, Cobol is an example of the other!
If you switch between many different programming languages you see which ideas are strong and which are weak - generally the weaker ideas fade from use, but it takes time unless its a very bad idea. People still use Fortran, Spin is nicer than that!
Have you read the datasheet?
It has a description of the special function registers in the cogs with all the bitfields and what they do. For the counters exist even an appnote. The memory map and how the different memories work together is described in the introducion section of the PropellerManual and also in shorter form at begin of the datasheet.
When the cogs are startet you can access the whole hubram with the wrlong/word/byte and rdlong/word/byte instructions. So you can just overwrite all the cog-images in the hubram.
With the SpinTool you can define your own hub memory segementation with constants in CON section or even in a separate object-file, so all the cogs can know the segment (or shared variables) addresses.
I just looked at the PropellerManual, this is described in the first chapter under MainRAM (page 31).
I don't know what documentation you all expect, I think the datasheet and the PropellerManual do a good job for describing the chip and the Spin and PASM language. For sure you can't learn Assembly programming from it or a how to program a UART.
Andy