Likeyyorself , I din't think I wanted to learn it as I had no confidence it learning it depite Id never even tried. My bacgrounf is VB.Net.
If ytou read the manuals and theyt have tutorials; you will find spin not too hard. Having some previos object languages will make it even easier but even a begginer can easily pick up Spin but is not absolutly necessay. Just follow the tutorals( in the Manula and also download PE fundamentals pdf. Dont' stress [noparse]:)[/noparse]
@Cluso -- it's a fairly straightforward thing for structured BASIC to only permit GOTO within a procedure so that you can't create a stack leak. All versions of Visual Basic do this; as with Spin there is essentially no executable code that is not part of some SUB or FUNCTION, and GOTO doesn't work outside of that scope. GOTO can be extremely useful in certain narrowly focused situations, particularly for reacting to unusual edge cases, and it can be especially useful at certain times in embedded work for dealing with obscure real world input situations that don't happen very often, which makes the lack of GOTO in Spin especially noticeable. Spin expects you to use Abort for that, but figuring out how to use Abort properly is REALLY hard if your background is in something like PBasic. (In fact, it's sufficiently different from just about everything else that it takes quite a bit of thought to use right no matter where you're coming from, although it's elegant and does force you to think things through and not take shortcuts, which is probably why Spin does it that way).
Honestly though, my biggest problem with Spin is that the heirarchal nature makes it impossible to call high level object methods from low level sub-objects, which makes it a royal pain in the posterior to write out debug data from low level objects that are hanging low on a side branch to your main I/O output. There is no technical reason that is necessary and it creates a major headache in debugging. In C, BASIC, and just about every other language in existence, it is possible to write output to the standard output stream (or whatever passes for it) from anywhere, and the inability to do that in Spin is a major hassle.
I found spin to be nice once I get into it. I had not programmed processors in almost 20 years. And it was assembly on a Motorla HC11. I felt (and still feel) I lost all my memory of ASM. This spin was a big help when I decided to start playing with microprocessors. If you have any practice with general programming languages it should be easy enough to pick up for you.
When you flowchart, you either draw the flowchart to the left (counter clockwise) or to the right (clockwise) and I was always taught to write loops when I learned Pascal.· It is often possible to use "goto" in a way that you don't get a full loop and conceivably the flowchart can be going clockwise and the program due to unstructured code can be going counter clockwise and you might not get a full loop in the program. ·
I just swapped from pbasic to spin less than a month ago. I have not had that much trouble i still have a lot to learn but if u can learn pbasic from a book, spin is just as easy to learn in my opinion.
Honestly though, my biggest problem with Spin is that the heirarchal nature makes it impossible to call high level object methods from low level sub-objects, which makes it a royal pain in the posterior to write out debug data from low level objects that are hanging low on a side branch to your main I/O output. There is no technical reason that is necessary and it creates a major headache in debugging. In C, BASIC, and just about every other language in existence, it is possible to write output to the standard output stream (or whatever passes for it) from anywhere, and the inability to do that in Spin is a major hassle.
I completely agree. One of the biggest hassles for me is debugging and the fact a child can't call any interface method of a parent.
If you want to print from anywhere (parent or child) you might look at the video driver in Sphinx. It's like tv_text but it lives entirely in one cog. Outputting a character consists of writing to a fixed memory location, so any object—parent or child—can print text easily (as can other cogs—you can print from PASM).
localroger: I completely agree about Abort. TBH I haven't grasped that myself (lazy and guess I haven't yet found the need).
GOTO still has compiler issues even just inside a routine, as it can still be within nested repeat/case/if code.
BradC and mpark: Can a lower level routine call a higher level routine? e.g. I have declared an object dbg = "FullDuplexSerial" in the top level. Can a lower level do dbg.tx("A") or dbg.str(string("info1",13)). I don't believe PropTool can. Would be a nice feature, especially as mentioned, for debugging.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I find both Spin and PASM a bit quirky to work with... But, I have to admire PASM for the things it can do with very basic hardware...
I just wish Spin was written by a C programmer (and not a Pascal programmer)! As Pascal has evolved to become closer to C (like Basic and all the others too), it's not horrible. But, as I also program a bit in C++, I also find it sometimes unnecessarly irritating...
I think Spin could have been written to be very close to C syntax, and then maybe I'd be a lot happier.
Still, I have to admire all the novel operators in Spin that let you easily manipulate data. I don't think C has as many operators...
Cluso99 said...
localroger: I completely agree about Abort. TBH I haven't grasped that myself (lazy and guess I haven't yet found the need).
GOTO still has compiler issues even just inside a routine, as it can still be within nested repeat/case/if code.
This is not incredibly difficult to solve as the compiler has to be able to keep track of the stack there for next/quit anyway.
Cluso99 said...
BradC and mpark: Can a lower level routine call a higher level routine? e.g. I have declared an object dbg = "FullDuplexSerial" in the top level. Can a lower level do dbg.tx("A") or dbg.str(string("info1",13)). I don't believe PropTool can. Would be a nice feature, especially as mentioned, for debugging.
I'm pretty sure mpark has that working in homespun.
I find it much more logical standardising on a mailbox style approach with a shared long in a common location, then I can use the same debugging mechanism from SPIN or PASM clients.
You could also quite easily make a debug object that encapsulated fullduplex serial and put the buffers and pointers in DAT rather than VAR. That way you could include and call it from any object you like, provided you only start it from the top object. In fact, I think I recall someone having done this already. There are many ways to skin this cat without modifying the language.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Cluso99 said...
...e.g. I have declared an object dbg = "FullDuplexSerial" in the top level. Can a lower level do dbg.tx("A") or dbg.str(string("info1",13))...
People keep asking for this and I keep posting that link, but as far as I know, no one has ever actually used Homespun's (admittedly imperfect) object-passing capability. Heck, even I stick with the workarounds that Brad mentioned. I think object-passing is one of those things you think you can't live without and then it turns out, well, actually you can, whaddya know.
mpark: I now remember seeing that post. Looking again at it, I saw the same problem as originally - it just looks too complex to bother with. Probably it's not so I have marked it for later investigation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
mpark: I now remember seeing that post. Looking again at it, I saw the same problem as originally - it just looks too complex to bother with. Probably it's not so I have marked it for later investigation.
Yeah, that example is pretty complex. I have updated the thread with a simpler and more compelling example: parent and child share tv_text.
Maybe we can continue this conversation in that thread and leave this poor thread alone.
I used PBasic for many years, then learned SX and then SPIN.
SX was hardest for me because it is not designed for the kind of interaction like a BS2. You can't just throw in debugs to find a problem. ALso, the interupt system takes a lot of experience to understand and get right
SPIN was pretty easy once I got used to the spacing / indents. Spin with Prop has more interface options, so easier to see what is happening.
What takes some conceptual leaps is using the Propeller, not spin itself.
I got going with a PE kit (I think $100) and worked through it (I think the PropStick version is easier set-up for a beginner). Also read the sticky and early posts on the prop forum where they described general concepts of the Prop.
But don't forget - SPIN does not equal the Propeller. SPIN is a language you can learn pretty easily with your knowledge from PBASIC. Prop is a machine that operates differently from the BS2.
Comments
Likeyyorself , I din't think I wanted to learn it as I had no confidence it learning it depite Id never even tried. My bacgrounf is VB.Net.
If ytou read the manuals and theyt have tutorials; you will find spin not too hard. Having some previos object languages will make it even easier but even a begginer can easily pick up Spin but is not absolutly necessay. Just follow the tutorals( in the Manula and also download PE fundamentals pdf. Dont' stress [noparse]:)[/noparse]
Honestly though, my biggest problem with Spin is that the heirarchal nature makes it impossible to call high level object methods from low level sub-objects, which makes it a royal pain in the posterior to write out debug data from low level objects that are hanging low on a side branch to your main I/O output. There is no technical reason that is necessary and it creates a major headache in debugging. In C, BASIC, and just about every other language in existence, it is possible to write output to the standard output stream (or whatever passes for it) from anywhere, and the inability to do that in Spin is a major hassle.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Shane Merem
www.websiteforge.com
www.magnusoft.com
·
When you flowchart, you either draw the flowchart to the left (counter clockwise) or to the right (clockwise) and I was always taught to write loops when I learned Pascal.· It is often possible to use "goto" in a way that you don't get a full loop and conceivably the flowchart can be going clockwise and the program due to unstructured code can be going counter clockwise and you might not get a full loop in the program.
·
I completely agree. One of the biggest hassles for me is debugging and the fact a child can't call any interface method of a parent.
GOTO still has compiler issues even just inside a routine, as it can still be within nested repeat/case/if code.
BradC and mpark: Can a lower level routine call a higher level routine? e.g. I have declared an object dbg = "FullDuplexSerial" in the top level. Can a lower level do dbg.tx("A") or dbg.str(string("info1",13)). I don't believe PropTool can. Would be a nice feature, especially as mentioned, for debugging.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I just wish Spin was written by a C programmer (and not a Pascal programmer)! As Pascal has evolved to become closer to C (like Basic and all the others too), it's not horrible. But, as I also program a bit in C++, I also find it sometimes unnecessarly irritating...
I think Spin could have been written to be very close to C syntax, and then maybe I'd be a lot happier.
Still, I have to admire all the novel operators in Spin that let you easily manipulate data. I don't think C has as many operators...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
This is not incredibly difficult to solve as the compiler has to be able to keep track of the stack there for next/quit anyway.
I'm pretty sure mpark has that working in homespun.
I find it much more logical standardising on a mailbox style approach with a shared long in a common location, then I can use the same debugging mechanism from SPIN or PASM clients.
You could also quite easily make a debug object that encapsulated fullduplex serial and put the buffers and pointers in DAT rather than VAR. That way you could include and call it from any object you like, provided you only start it from the top object. In fact, I think I recall someone having done this already. There are many ways to skin this cat without modifying the language.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
With Homespun you can pass a "pointer" to dbg down to your lower level object: http://forums.parallax.com/showthread.php?p=777920
People keep asking for this and I keep posting that link, but as far as I know, no one has ever actually used Homespun's (admittedly imperfect) object-passing capability. Heck, even I stick with the workarounds that Brad mentioned. I think object-passing is one of those things you think you can't live without and then it turns out, well, actually you can, whaddya know.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
That's hysterical...!
Yeah, that example is pretty complex. I have updated the thread with a simpler and more compelling example: parent and child share tv_text.
Maybe we can continue this conversation in that thread and leave this poor thread alone.
SX was hardest for me because it is not designed for the kind of interaction like a BS2. You can't just throw in debugs to find a problem. ALso, the interupt system takes a lot of experience to understand and get right
SPIN was pretty easy once I got used to the spacing / indents. Spin with Prop has more interface options, so easier to see what is happening.
What takes some conceptual leaps is using the Propeller, not spin itself.
I got going with a PE kit (I think $100) and worked through it (I think the PropStick version is easier set-up for a beginner). Also read the sticky and early posts on the prop forum where they described general concepts of the Prop.
But don't forget - SPIN does not equal the Propeller. SPIN is a language you can learn pretty easily with your knowledge from PBASIC. Prop is a machine that operates differently from the BS2.