So Happy There are greater minds then mine out there. Thank you to everyone for your comments and help. This weekend turned out to be a bust in regards to me writing any (usable) code.
No fear I am not quitting quite yet, just a temporary speed bump.
Question: When writing SPIN code does everyone use the Propeller tool to do this or use pencil and paper and make a draft then finish within the Propeller tool window? Not sure if that is a silly question but I will soon find out.
I started off this weekend by drafting (on paper) a block diagram showing the different main functions and then sub functions and in some cases sub sub sub functions to achieve my goals.
This project started to look very daunting and I found myself quickly getting discouraged, but then I was reading post on this forum and came across (Heaters) post where he said to break the program down to very small parts and write the code for those small parts, then move on to the next small part and write that code.
I ended up reading over the weekend more about SPIN and its abilities and I think I'm ready to tackle this now.
So Happy There are greater minds then mine out there. Thank you to everyone for your comments and help. This weekend turned out to be a bust in regards to me writing any (usable) code.
No fear I am not quitting quite yet, just a temporary speed bump.
Question: When writing SPIN code does everyone use the Propeller tool to do this or use pencil and paper and make a draft then finish within the Propeller tool window? Not sure if that is a silly question but I will soon find out.
I started off this weekend by drafting (on paper) a block diagram showing the different main functions and then sub functions and in some cases sub sub sub functions to achieve my goals.
This project started to look very daunting and I found myself quickly getting discouraged, but then I was reading post on this forum and came across (Heaters) post where he said to break the program down to very small parts and write the code for those small parts, then move on to the next small part and write that code.
I ended up reading over the weekend more about SPIN and its abilities and I think I'm ready to tackle this now.
Generally I start with a very simple block diagram (in paint, on paper, on napkin, depending on when and where the need occurs).
Next comes the Propeller Tool to outline and describe the main program and methods as shown below. Then the fun starts.
main
'******************************************************
' Main program to do whatever.............
'******************************************************
do_this()
do_that()
do_the_other()
do_this()
'******************************************************
' do_this function.................
'******************************************************
do_that()
'******************************************************
' do_that() function.............
'******************************************************
do_the_other()
'******************************************************
' do_the_other() function.............
'******************************************************
As long as the descriptive comments are updated as things change (and they will change for all but the most trivial programs) I end up with a fairly well documented program.
Probably better when starting out to use a block diagram (flowchart). Keep it simple using blocks for routines. Then draw each code block separately.
As you get better at it, small programs can be entered directly into PropTool.
When you have questions, post you code between (code) ... (/code) tags to keep formatting. Note replace round braces with square brackets. You can also zip your file(s) in proptool and attach the zip file to your post.
Work from the bottom up. (Forget that top-down nonsense.) Write a small program that you can build upon and make into a subprogram of your larger project. Make sure it works before going any further. Then keep building upon that. Before you know it, you will have your app working!
Quite right Phil. Bottom up. Find a part that you think you can do easily and do it. When it works move on to the next part.
Make backups of everything that works before you start on the next part.
Might be an idea to just make all the parts as separate programs. Small things are easier to test and think about. Then compose them together for the final big program. The objects of Spin make this quite an easy thing to do.
Before you know it you may have a working app. It will also be a big tangled mess. With that experience you will start to think about organization when starting a project, "top down".
I find the best is to combine top-down and bottom-up. At some point you will need a general idea about how your program should function from a top-down point of view. That will influence how you design your functions when you do them bottom-up, e.g. what functions do you actually need? One to do a+b, one to do a+c, but do you need a+b+c for anything? That's something you can answer with from a top-down point of view. No need to implement functions you don't need.
Unless your entire application is really just a single bottom function to be called in various ways from higher up (sometimes Forth programming seems to work only that way..)
Before you know it you may have a working app. It will also be a big tangled mess. With that experience you will start to think about organization when starting a project, "top down".
As Heater said.. I don't think it collides with what I wrote above - it's good to see the mess in order to get better ideas about how to do things (now and in future projects)
As usual I'm getting a bunch of great advice from ALL of you and I can't thank you enough.
I find the terminology hard to follow and the Propeller Manual can seem overwhelming due to lack of experience on my part. I'm trying my best to keep it as simple as possible, but the project I thought was going to be easy turned out to be much more complicated then at first I thought. I'm now contemplating changing my project to something more manageable to a first timer, then I could work my way up to writing more complicated programs.
The one thing I am positive about is I want to write ALL of the code for my project myself, I do not want to piece together a bunch of code someone else has written. I had determined from the beginning that using a block diagram was going to be my best approach, but what I wasn't sure about was when writing the actual code would it be easier to use pen and paper to make a draft, or use the Propeller tool.
I also have a question which I'm not sure exactly how to word, I know by looking at other working programs that I will need to specify the amount of memory I will need to use, but I'm not sure how to determine this. At the beginning of a program:
(CON:, VAR:, OBJ:, FLOAT, BYTE, LONG)
these terms and amount of memory used is something I do not fully understand.
I find the best is to combine top-down and bottom-up. At some point you will need a general idea about how your program should function from a top-down point of view. That will influence how you design your functions when you do them bottom-up, e.g. what functions do you actually need? One to do a+b, one to do a+c, but do you need a+b+c for anything? That's something you can answer with from a top-down point of view. No need to implement functions you don't need.
Unless your entire application is really just a single bottom function to be called in various ways from higher up (sometimes Forth programming seems to work only that way..)
Before you know it you may have a working app. It will also be a big tangled mess. With that experience you will start to think about organization when starting a project, "top down".
As Heater said.. I don't think it collides with what I wrote above - it's good to see the mess in order to get better ideas about how to do things (now and in future projects)
+1. Although it may seem that way, what I do is certainly not a strictly "top down" method of programming, just a starting point. Lets me figure out and test the sub functions one at a time.
You do not need to specify the amount of working memory used.
Just start writing code. The tools, PropTool or whatever will tell you how much memory you have used.
Of course data takes up memory, LONGS are 4 bytes. You can guess the rest. Remember that data declared in VAR is duplicated for every instance of the object that is used in your program. Data declared in DAT is shared between all instances. Not usually a concern as there is generally only one instance of any object in a program.
Code of course takes up space. The compiler will tell you as you go along. You will soon get a feel for whether your finished program will fit or not.
Mind you, if you happen to know that your application requires 64K of data space then you know ahead of time that it ain't going to fit in a Propeller.
I find the terminology hard to follow and the Propeller Manual can seem overwhelming due to lack of experience on my part. ...
The one thing I am positive about is I want to write ALL of the code for my project myself, I do not want to piece together a bunch of code someone else has written. ...
I also have a question which I'm not sure exactly how to word, I know by looking at other working programs that I will need to specify the amount of memory I will need to use, but I'm not sure how to determine this. At the beginning of a program:
(CON:, VAR:, OBJ:, FLOAT, BYTE, LONG)
these terms and amount of memory used is something I do not fully understand.
Based on the basic questions you are asking, I recommend that you read & do the exercises in the "Propeller Education Kit". While the Propeller Manual is a great reference book and gives a good background on the Propeller, the Prop Education Kit book gives the details and explanations that someone starting to program needs. Follow each example. Make sure you understand what it is doing and how and why it does it. If you don't understand something - ask the author - you have a resource that many of us wish we had - easy access to Andy. Don't skip the Study Time or Exercises. Once you have done the exercises in a section, expand on them - use what you learned to do something similar.
In the first few chapters you will learn what those words mean. I'm not sure why you feel that you need to specify the amount of memory you will need.
Once you understand the basics, start a small project. Keep it finite and simple. One good thing about SPIN is that a project can be built up from small, simple, independent modules (objects).
Tom
Thank you Tom. You can tell my inexperience by the questions I'm asking, good job. You are right about my access to not only the authors but even more importantly I have access to the creator of the Propeller and all of the staff that worked on the SPIN code including but not limited Jeff Martin, Andy Lindsay, Ken Gracey, and many others.
Even though I have all of this great access I still prefer to attempt to do this for the most part by myself and the help of an even greater resource, this Forum.
The Propeller Education Kit (PEK) text gave me a basic understanding of how to use Spin but converting BS2 programs to it is what really made me good at it.
Wanted to update everybody that were nice enough to give advice and try to help direct me in the right direction programming in SPIN.
I want to give special thanks to (macrobeak) for calling me out and getting me to actually start coding instead of spending weeks (Talking) about how to start coding, he was right and now I have actual code that I was able to compile and is running exactly how I intended it to.
It's been a rough road with many pitfalls along the way and at times I was very close to quit learning SPIN, but I'm very happy I stuck with it and with the help of Jeff Martin gently leading in the right direction when I was having problems and wanted to quit, I ended up actually writing code. I'm very happy I didn't give up and stuck with it because I learned a lot and feel much more prepared to continue with this project and follow it through to it's very end.
In the months to come I think you'll be happy you stuck with it. Remember than nothing new to most of us comes easily. I struggled with Spin at first, too, I worked for Parallax at the time (and was very invested in PBASIC and SX/B). Now, it's second nature and I write programs that may be a few hundred lines, to apps as big as a recent project that is more than 6000 lines of Spin/PASM (the topmost file is about 3000 lines, the rest are libraries that I wrote).
If I may suggest: Even when there is a "big" goal in mind, break it down into small elements that are easier to deal with. As you can imagine, that recent 6000-line program has lots of blocks -- by isolating them I was able to build things a step at a time until it all came together. My client was occasional nervous (given the scope of the project and the frequently-changing spec), so I told him to watch "The Karate Kid" because programming, at times, can be a little like "Wax on, wax off."
If I may also suggest, creating a template for yourself will go a long way to reducing frustration, especially in the beginning. I've attached my most basic template, but I have several. For example, I do a lot of work with the PAB so I created a template for it. At EFX-TEK, we use the Propeller in our products and we release basic templates for them so that customers are free to "hack" our products with code that we use ourselves.
Propeller Tool supports just one template, so I tend to pre-pend my template names with a double underscore to sort those files to the top of the list. If you use Propeller IDE, you can get quite fancy with templates, you can even create a custom graphic for each (I discussed that in my Nuts & Volts column last year).
Thanks for the templates and for the advice. Breaking my program into small parts was the best advice I got. When trying to look at it as one BIG program can make it look overwhelming, but when broken down to smaller parts makes it more mangeable.
I will definately be taking advantage of these templates you sent me.
If you think about it, the smallest part of a program is a single line of code -- the goal is to break things down to where it's a single line.
My style tends to start with a template, add method names to the main loop, then create blank methods that match those names. This is basically an outline of the program logic. The program will compile but do nothing (that's okay at this point). Then I start building each method and testing it. Before long, a working program! I'm kind of nutty in that I test each method carefully before deployment. Don't be afraid to create separate little test programs to isolate new things before folding into the big program -- I do this all the time.
Once you get some experience, the real fun is creating your own objects. Most of the objects I use I have written. Of the two I didn't write, I modified one; the other is untouched. A lot of my work involves entertainment, and working with people that work in those areas. Like my friend, Rick, who uses a lot of my custom objects.
I kick myself for NOT getting into this much earlier in my career but unfortunately I focused more on the hardware, but having said that I couldn't be having any more fun with this. Having the ability to create something where the only limitations are your own imagination.
Thank you for the great advice. I was wondering about taking portions of my code and running them by themselves and now I know. So far I have written very limited code and I am using one object so now I'm ready to roll up my sleeves and get to work. I could do my whole project using only Objects but what would I learn by doing this, Nothing.
My title was Applications Engineer. I helped with product development and creating documentation for it. I also traveled a bit, conducting training (mostly for educators). In 2006, another Parallaxian (John Barrowman) and I started EFX-TEK (which was born out of an internal group called Parallax EFX that we created). We have these Propeller-based products in our mix:
-- AP-8+ Audio Player (nearing release)
-- AP-16+ Audio Player (just redesigned with some cool new features)
-- FC-4+ AC Lighting Controller
-- HC-8+ DC Lighting Controller / Expansion Module
-- RC-4+ Relay Controller
On top of those we've done lots of custom designs for clients, including that big laser-tag controller project I mentioned. Of our products, the HC-8+ is my favorite because it's really a general-purpose controller (even though we pre-program it with a slave application). The first HC-8+ designed based on input from a mouse-friendly amusement park here in SoCal; in fact, the first prototypes are still used in a scary house on those grounds. Based on additional feedback from them, other amusement parks, and my use with our customers here in Hollywood, we're at revision F which I am really happy about. You can see pictures of projects that I use the HC-8+ in on my Pinterest page (I note where the HC-8+ is used).
None of the the art-based programs are terribly difficult, though a couple took some time get working efficiently. My Hollywood artist friends don't speak in terms of features -- they usually describe what they want with hand gestures and sound-effects from their mouth. I'm also a professional actor (SAG-AFTRA), so I understand this and turn it into code.
BTW, every one of these projects and all of EFX-TEK Propeller-based products are programmed in Spin. Of course, some objects PASM where speed is critical.
It's okay to use objects by others, but don't do it blindly -- there's a lot of Smile out there, which I why I started writing my own objects (FTR, I've pulled all my own objects down from ObEx for a maintenance cycle -- they'll go back up later). It is fun writing objects, especially when they are useful to others. I've written about 200 objects over the past 10 years, mostly because a friend or colleague needed something special.
If I may be so bold as to offer another piece of advice: Keep your formatting neat and tidy. In my experience, a lot of bugs get hidden by the attitude, "Who cares if my code is messy -- nobody's going to see it!" Admittedly, I am nutty about formatting, but when you have 6000+ lines of code to manage (I've done that twice, the other time was an HVAC controller), it can make a big difference.
Keep at it. Down the road you'll be happy you did.
In my college day's (long long ago) I used both assembly and C. I remember some things through all the cobwebs, like being VERY generous with descriptions so when I look back I might better understand what I was attempting to do and keeping my code neat and tidy which will be not a problem for me, I'm a bit OCD, oh who am I kidding I'm completely OCD.
And yes, your comments about writing code are pure wisdom. I wish a lot more people followed these specs for their code. I have seen some rubbish in my many years of coding.
No doubt. I always wanted to work in Hollywood, and now I do. Frankly, though, the goal is to transition to more time in front of a camera than in front of my computer -- will make all those years of paying SAG dues worthwhile!
Comments
Jim's original post now looks normal and works for me using Firefox...
No fear I am not quitting quite yet, just a temporary speed bump.
Question: When writing SPIN code does everyone use the Propeller tool to do this or use pencil and paper and make a draft then finish within the Propeller tool window? Not sure if that is a silly question but I will soon find out.
I started off this weekend by drafting (on paper) a block diagram showing the different main functions and then sub functions and in some cases sub sub sub functions to achieve my goals.
This project started to look very daunting and I found myself quickly getting discouraged, but then I was reading post on this forum and came across (Heaters) post where he said to break the program down to very small parts and write the code for those small parts, then move on to the next small part and write that code.
I ended up reading over the weekend more about SPIN and its abilities and I think I'm ready to tackle this now.
Generally I start with a very simple block diagram (in paint, on paper, on napkin, depending on when and where the need occurs).
Next comes the Propeller Tool to outline and describe the main program and methods as shown below. Then the fun starts.
As long as the descriptive comments are updated as things change (and they will change for all but the most trivial programs) I end up with a fairly well documented program.
As you get better at it, small programs can be entered directly into PropTool.
When you have questions, post you code between (code) ... (/code) tags to keep formatting. Note replace round braces with square brackets. You can also zip your file(s) in proptool and attach the zip file to your post.
-Phil
Make backups of everything that works before you start on the next part.
Might be an idea to just make all the parts as separate programs. Small things are easier to test and think about. Then compose them together for the final big program. The objects of Spin make this quite an easy thing to do.
Before you know it you may have a working app. It will also be a big tangled mess. With that experience you will start to think about organization when starting a project, "top down".
Unless your entire application is really just a single bottom function to be called in various ways from higher up (sometimes Forth programming seems to work only that way..)
As Heater said.. I don't think it collides with what I wrote above - it's good to see the mess in order to get better ideas about how to do things (now and in future projects)
I find the terminology hard to follow and the Propeller Manual can seem overwhelming due to lack of experience on my part. I'm trying my best to keep it as simple as possible, but the project I thought was going to be easy turned out to be much more complicated then at first I thought. I'm now contemplating changing my project to something more manageable to a first timer, then I could work my way up to writing more complicated programs.
The one thing I am positive about is I want to write ALL of the code for my project myself, I do not want to piece together a bunch of code someone else has written. I had determined from the beginning that using a block diagram was going to be my best approach, but what I wasn't sure about was when writing the actual code would it be easier to use pen and paper to make a draft, or use the Propeller tool.
I also have a question which I'm not sure exactly how to word, I know by looking at other working programs that I will need to specify the amount of memory I will need to use, but I'm not sure how to determine this. At the beginning of a program:
(CON:, VAR:, OBJ:, FLOAT, BYTE, LONG)
these terms and amount of memory used is something I do not fully understand.
+1. Although it may seem that way, what I do is certainly not a strictly "top down" method of programming, just a starting point. Lets me figure out and test the sub functions one at a time.
Just start writing code. The tools, PropTool or whatever will tell you how much memory you have used.
Of course data takes up memory, LONGS are 4 bytes. You can guess the rest. Remember that data declared in VAR is duplicated for every instance of the object that is used in your program. Data declared in DAT is shared between all instances. Not usually a concern as there is generally only one instance of any object in a program.
Code of course takes up space. The compiler will tell you as you go along. You will soon get a feel for whether your finished program will fit or not.
Mind you, if you happen to know that your application requires 64K of data space then you know ahead of time that it ain't going to fit in a Propeller.
Based on the basic questions you are asking, I recommend that you read & do the exercises in the "Propeller Education Kit". While the Propeller Manual is a great reference book and gives a good background on the Propeller, the Prop Education Kit book gives the details and explanations that someone starting to program needs. Follow each example. Make sure you understand what it is doing and how and why it does it. If you don't understand something - ask the author - you have a resource that many of us wish we had - easy access to Andy. Don't skip the Study Time or Exercises. Once you have done the exercises in a section, expand on them - use what you learned to do something similar.
In the first few chapters you will learn what those words mean. I'm not sure why you feel that you need to specify the amount of memory you will need.
Once you understand the basics, start a small project. Keep it finite and simple. One good thing about SPIN is that a project can be built up from small, simple, independent modules (objects).
Tom
Even though I have all of this great access I still prefer to attempt to do this for the most part by myself and the help of an even greater resource, this Forum.
this learning process is excruciating. Just write some code already!
-Phil
Both of you are absolutely right. The next time I post something it will be some code I've written...
The Propeller Education Kit (PEK) text gave me a basic understanding of how to use Spin but converting BS2 programs to it is what really made me good at it.
Wanted to update everybody that were nice enough to give advice and try to help direct me in the right direction programming in SPIN.
I want to give special thanks to (macrobeak) for calling me out and getting me to actually start coding instead of spending weeks (Talking) about how to start coding, he was right and now I have actual code that I was able to compile and is running exactly how I intended it to.
It's been a rough road with many pitfalls along the way and at times I was very close to quit learning SPIN, but I'm very happy I stuck with it and with the help of Jeff Martin gently leading in the right direction when I was having problems and wanted to quit, I ended up actually writing code. I'm very happy I didn't give up and stuck with it because I learned a lot and feel much more prepared to continue with this project and follow it through to it's very end.
ModEdit: Language edit
If I may suggest: Even when there is a "big" goal in mind, break it down into small elements that are easier to deal with. As you can imagine, that recent 6000-line program has lots of blocks -- by isolating them I was able to build things a step at a time until it all came together. My client was occasional nervous (given the scope of the project and the frequently-changing spec), so I told him to watch "The Karate Kid" because programming, at times, can be a little like "Wax on, wax off."
Propeller Tool supports just one template, so I tend to pre-pend my template names with a double underscore to sort those files to the top of the list. If you use Propeller IDE, you can get quite fancy with templates, you can even create a custom graphic for each (I discussed that in my Nuts & Volts column last year).
Thanks for the templates and for the advice. Breaking my program into small parts was the best advice I got. When trying to look at it as one BIG program can make it look overwhelming, but when broken down to smaller parts makes it more mangeable.
I will definately be taking advantage of these templates you sent me.
My style tends to start with a template, add method names to the main loop, then create blank methods that match those names. This is basically an outline of the program logic. The program will compile but do nothing (that's okay at this point). Then I start building each method and testing it. Before long, a working program! I'm kind of nutty in that I test each method carefully before deployment. Don't be afraid to create separate little test programs to isolate new things before folding into the big program -- I do this all the time.
Once you get some experience, the real fun is creating your own objects. Most of the objects I use I have written. Of the two I didn't write, I modified one; the other is untouched. A lot of my work involves entertainment, and working with people that work in those areas. Like my friend, Rick, who uses a lot of my custom objects.
https://www.parallax.com/news/2017-09-26/destiny-2-live-action-trailer-cayde-6’s-animatronic-head-and-weapons-use-propeller
I kick myself for NOT getting into this much earlier in my career but unfortunately I focused more on the hardware, but having said that I couldn't be having any more fun with this. Having the ability to create something where the only limitations are your own imagination.
Thank you for the great advice. I was wondering about taking portions of my code and running them by themselves and now I know. So far I have written very limited code and I am using one object so now I'm ready to roll up my sleeves and get to work. I could do my whole project using only Objects but what would I learn by doing this, Nothing.
By the way, what did you do over at Parallax?
-- AP-8+ Audio Player (nearing release)
-- AP-16+ Audio Player (just redesigned with some cool new features)
-- FC-4+ AC Lighting Controller
-- HC-8+ DC Lighting Controller / Expansion Module
-- RC-4+ Relay Controller
On top of those we've done lots of custom designs for clients, including that big laser-tag controller project I mentioned. Of our products, the HC-8+ is my favorite because it's really a general-purpose controller (even though we pre-program it with a slave application). The first HC-8+ designed based on input from a mouse-friendly amusement park here in SoCal; in fact, the first prototypes are still used in a scary house on those grounds. Based on additional feedback from them, other amusement parks, and my use with our customers here in Hollywood, we're at revision F which I am really happy about. You can see pictures of projects that I use the HC-8+ in on my Pinterest page (I note where the HC-8+ is used).
-- https://www.pinterest.com/jonmcphalen/techno-art
None of the the art-based programs are terribly difficult, though a couple took some time get working efficiently. My Hollywood artist friends don't speak in terms of features -- they usually describe what they want with hand gestures and sound-effects from their mouth. I'm also a professional actor (SAG-AFTRA), so I understand this and turn it into code.
BTW, every one of these projects and all of EFX-TEK Propeller-based products are programmed in Spin. Of course, some objects PASM where speed is critical.
It's okay to use objects by others, but don't do it blindly -- there's a lot of Smile out there, which I why I started writing my own objects (FTR, I've pulled all my own objects down from ObEx for a maintenance cycle -- they'll go back up later). It is fun writing objects, especially when they are useful to others. I've written about 200 objects over the past 10 years, mostly because a friend or colleague needed something special.
If I may be so bold as to offer another piece of advice: Keep your formatting neat and tidy. In my experience, a lot of bugs get hidden by the attitude, "Who cares if my code is messy -- nobody's going to see it!" Admittedly, I am nutty about formatting, but when you have 6000+ lines of code to manage (I've done that twice, the other time was an HVAC controller), it can make a big difference.
Keep at it. Down the road you'll be happy you did.
take Jon's advices. I do not use much of his objects, but enjoyed reading them. He has a very good coding style.
@Jon, good to hear that your object are going into the OBEX again. They have been missed as far as I read.
Enjoy!
Mike
You have a truly interesting career!
And yes, your comments about writing code are pure wisdom. I wish a lot more people followed these specs for their code. I have seen some rubbish in my many years of coding.
I had an instructor who made us document every line of code and it seemed ridiculously unnecessary at the time but that code is still readable today.