I can't understand why Spin is being dismissed so lightly sometimes and it complements the Prop so nicely too and is very easy to learn and very easy to get started even if you have little programming knowledge. It's a pity though that the compiler couldn't be resident on the chip itself and interactive as I find having my Tachyon Forth resident on the chip a very powerful development and debugging tool/environment with immediate access to all symbols and functions by name, and that is only a small part of it all.
Couldn't we do something similar with Spin2 in augmenting the bytecode interpreter with a compiler and an interactive console? For sure these extra functions would have to be loaded into serial Flash initially but just imagine if all the Parallax boards were "ready to Spin" from the moment you unpack it and plug it in (and powered from USB please). Even your phone or tablet could serve as a simple terminal then or over Bluetooth just as I do now with Tachyon.
Couldn't *we*? Aren't *you* the Propeller interpreter wizard. Will you build us one of these shiny things? You've done such a great job with Tachyon! :-)
I can't understand why Spin is being dismissed so lightly sometimes and it complements the Prop so nicely too and is very easy to learn and very easy to get started even if you have little programming knowledge. It's a pity though that the compiler couldn't be resident on the chip itself and interactive as I find having my Tachyon Forth resident on the chip a very powerful development and debugging tool/environment with immediate access to all symbols and functions by name, and that is only a small part of it all.
Couldn't we do something similar with Spin2 in augmenting the bytecode interpreter with a compiler and an interactive console? For sure these extra functions would have to be loaded into serial Flash initially but just imagine if all the Parallax boards were "ready to Spin" from the moment you unpack it and plug it in (and powered from USB please). Even your phone or tablet could serve as a simple terminal then or over Bluetooth just as I do now with Tachyon.
Couldn't *we*? Aren't *you* the Propeller interpreter wizard. Will you build us one of these shiny things? You've done such a great job with Tachyon! :-)
I don't think anyone would trust me as for sure I would build a Spin2 interpreter on top of Tachyon and sneak Forth onto every board just like Mitch Bradley did with Forth as the boot ROM in Sun workstations, which later became OpenFirmware etc.
I can't understand why Spin is being dismissed so lightly sometimes and it complements the Prop so nicely too and is very easy to learn and very easy to get started even if you have little programming knowledge. It's a pity though that the compiler couldn't be resident on the chip itself and interactive as I find having my Tachyon Forth resident on the chip a very powerful development and debugging tool/environment with immediate access to all symbols and functions by name, and that is only a small part of it all.
Couldn't we do something similar with Spin2 in augmenting the bytecode interpreter with a compiler and an interactive console? For sure these extra functions would have to be loaded into serial Flash initially but just imagine if all the Parallax boards were "ready to Spin" from the moment you unpack it and plug it in (and powered from USB please). Even your phone or tablet could serve as a simple terminal then or over Bluetooth just as I do now with Tachyon.
Couldn't *we*? Aren't *you* the Propeller interpreter wizard. Will you build us one of these shiny things? You've done such a great job with Tachyon! :-)
I don't think anyone would trust me as for sure I would build a Spin2 interpreter on top of Tachyon and sneak Forth onto every board just like Mitch Bradley did with Forth as the boot ROM in Sun workstations, which later became OpenFirmware etc.
Still others expect their IDE to include a Debugger & Simulator, and Debug is one area Parallax are very poor on right now.
I don't see that as a problem. A software debugger is nothing more than a crutch, and a poor one at that. My debugger is an oscilloscope, which gives me real-time data about how my program is running.
-Phil
Yup, I use scopes for real-time problems too....
However, not all problems are real-time problems, so more than just one tool in the toolbox, is often much smarter.
Long before I fire up the scope, I am tuning code in a software simulator, reducing size and increasing speed, as well as doing self-test generator cases that a scope alone cannot get close to.
These software test suites are all ready to run, instantly, in 6 months time, no need to set up another test bench...
Present target is 512k, so yes, "the P2 has significantly grown in memory", and it should easily support a full blown G-Code interpreter, as well as enough memory to run a CNC machine, with many bells and whistles.
The AVR is one reference for G-Code, (one that has already hit design saturation), but that is an 8-bit MCU, with 32k code, so is a fraction of P2's capability.
Porting saturated AVR code is not likely to be fun, but there may be C-code on thinks like RaspPi that manage the higher movement calcs that can more easily be ported.
P2's COGs + smart pins are far enough from AVRs Timers/interrupts, that a clean slate will be better for lowest level code.
Well then, it sounds to me that Parallax has a wonderful and powerful opportunity, to step in and take over where the others fail. Even if they have to start their motion control code from scratch, the motion control industry seems like a worthy target market to start with. Think of it as a starting point for P2 sales and then build other markets from there.
If the P2 can overcome the shortfalls of other motion control processors, such as a full blown G-Code interpreter, as well as amply handling various control and process signaling, then where else is a better market for the P2? Will somebody please enlighten me as to a better possible use for the P2?
I can't understand why Spin is being dismissed so lightly sometimes and it complements the Prop so nicely too and is very easy to learn and very easy to get started even if you have little programming knowledge. It's a pity though that the compiler couldn't be resident on the chip itself and interactive as I find having my Tachyon Forth resident on the chip a very powerful development and debugging tool/environment with immediate access to all symbols and functions by name, and that is only a small part of it all.
Couldn't we do something similar with Spin2 in augmenting the bytecode interpreter with a compiler and an interactive console? For sure these extra functions would have to be loaded into serial Flash initially but just imagine if all the Parallax boards were "ready to Spin" from the moment you unpack it and plug it in (and powered from USB please). Even your phone or tablet could serve as a simple terminal then or over Bluetooth just as I do now with Tachyon.
Couldn't *we*? Aren't *you* the Propeller interpreter wizard. Will you build us one of these shiny things? You've done such a great job with Tachyon! :-)
I don't think anyone would trust me as for sure I would build a Spin2 interpreter on top of Tachyon and sneak Forth onto every board just like Mitch Bradley did with Forth as the boot ROM in Sun workstations, which later became OpenFirmware etc.
Why not???
After all, it doesn't matter how it is done, just that it works nicely!
The Micromite MBasic has gained a lot of traction on the PIC micros, and now it's available on the Raspberry Pi. It's the simple interactive nature of Basic that has the interest. No reason why Spin2 couldn't provide an equivalent interactive environment.
I know it's not. I just don't want to see the P2 released with just Spin/Pasm. Or relegating C/C++ to the basement.
The point is to get larger commercial vendors interested in the P2. Now if they're told do it the Parallax/Chip approved way or no way. They'll walk away like they did on the P1.
Industry expects C/C++ to be defacto development language for embedded controllers along with a debuggers. Yes I know the P1 programmers here don't use debuggers - they use LED's, scopes, logic analyzers, etc.
But the point is, is to show industry that the P2 is mainstream just as any ARM or PIC and with a tool set they can transfer their knowledge to without too much effort.
Of course this is where several killer demos on a P2 Eval board come into play as well. Got to get their attention first above all else. Have to show them it's a valid alternative to ARM, PIC32 or DSC.
The other part of the rationale of having a nice C/C++ IDE for the P2 is to make the P2 acceptable to the pointy haired boss types that approve it's use.
Industry expects C/C++ to be defacto development language for embedded controllers along with a debuggers. Yes I know the P1 programmers here don't use debuggers - they use LED's, scopes, logic analyzers, etc.
This is contrary to Ken's observation, quoted here:
C follows Spin at Parallax in many ways. Almost all of our commercial customers are using Spin/ASM.
You'll get more from the Propeller with Spin and ASM, first. C proved necessary for Parallax business in Education, which pays the way for so many other efforts in our company. I don't know why you'd need to fear that C would kick Spin out of town. Do what you like and do it well. Chip's heart lies with Spin and ASM, so that'll ensure that our first demos, programming tools and examples will use Spin 2. However, please count on the C compiler team working concurrently to deliver the same.
If you work on large and/or complex software projects, then a debugger is not a crutch, it's required. PERIOD. Just as for any sufficiently large or complex hardware project, a scope or logic analyzer is required. Telling people that the tools of their trade are crutches is just insulting and ignorant (meaning you lack the clue required to understand).
Also, industry standard programming languages are required by many potential customers who might use the P2. It doesn't matter how great Spin/PASM is, their company likely won't even let them look at the P2. At many places, that means C. This is a reality, sorry if you don't like it.
I personally will use Spin/PASM for many things, and C/C++ for some things on P1 and P2, but that doesn't mean diddly squat. I'm not a large company that Parallax could sell 10s or 100s of thousands of units to for a product.
If you work on large and/or complex software projects, then a debugger is not a crutch, it's required. PERIOD. Just as for any sufficiently large or complex hardware project, a scope or logic analyzer is required.
Roy, you stated that very well.
Each programmer has his own preference on how they debug code. I've watched people that really know how to use a debugger, and they do can do some amazing things with it. I've never been able to figure out how to analyze a stack dump using GDB, but I've seen other people that could track down the source of a problem using that technique.
Dave, yep those stack dumps look pretty bewildering to me.
I have to admit that I also usually just insert printfs.
I too am old school and use printf for most debugging, but there are times if it is not a necessity, debuggers save a lot of time. All the competing microprocessors have this capability, and many potential large users won't even consider an alternative without it.
C follows Spin at Parallax in many ways. Almost all of our commercial customers are using Spin/ASM.
You'll get more from the Propeller with Spin and ASM, first. C proved necessary for Parallax business in Education, which pays the way for so many other efforts in our company. I don't know why you'd need to fear that C would kick Spin out of town. Do what you like and do it well. Chip's heart lies with Spin and ASM, so that'll ensure that our first demos, programming tools and examples will use Spin 2. However, please count on the C compiler team working concurrently to deliver the same.
Quick observation here. Does Parallax want to predict potential P2 use based on the current commercial customers, or what they "potentially" could have if they go a different route?
Yes, your current commercial customer's may now be using Spin/ASM. However, that may be based on the hard-core, "Parallax or bust" customers. What you really might want to consider is all of the customers they lost[, who didn't want to use Spin/ASM.
In my opinion, to grow the business, versus maintaining the business, you need to focus on customers and markets you don't have, versus ones you do have. In all honesty, your hardcore customers are going to be happy with anything you offer - be it hammered hieroglyphics on stone tablets, or programming the P2 using Morse code and a paddle key. You don't have to worry about those guys (I'm joking of course for the non-humorous folks). Look at the markets that have passed you by. Parallax was here LONG before the other folks out there, yet they have moved on, and whole industry's and market's have popped up, without Basic Stamps and Propellers.
I would submit that the need for a debugger is a consequence of one's programming style. Sure, if you write all or most of an app before testing any part of it, a debugger is probably necessary for finding deeply-embedded errors. But if you develop your app with a consistent program/test cycle on every little piece, the need for a debugger evaporates, since you're always able to isolate the errant code to the latest entry. I would also submit that the latter programming style is the preferable one to adopt -- always. Hence my assertion above, which I stand by.
But we've definitely veered off-topic with this little detour.
I don't know why anyone wouldn't want to have a nice debugger available. Trace can help with realtime profiling. You can use sophisticated watchpoints to track down errant behavior. Keep in mind that you're often dealing with code written by many people, and often with hardware that's being developed in parallel by someone else.
I guess the argument in this thread is more about priorities. Time spent developing a debugger is time spent not doing something else, and Parallax has very limited resources.
Phil,
Programming style isn't enough when you have a sufficiently large/complex software project. It can reduce the need, but not eliminate it.
Also, when you have many programmers working on the project (we have as many as 50 on projects where I work), things become much more difficult all around.
Debuggers save time, and time is money.
A Debugger can also help find hardware bugs. I have found a few of these in my 30+ years of coding.
I certainly don't advocate a Spin-only release; we've already made that mistake. I was only pointing out that all P1 commercial designs use Spin/ASM. P2 could only be released if we have Spin and C, both complete. The former is a necessity for the inventor and many existing customers; the latter is to grow a market much larger than we have at present.
There's so much more to consider than these tools, though. We will need to segment our customers properly for education and commercial, speaking to each of them directly.
The times when I have really needed a tool to help track down a bug are the times when debuggers do their best to hide the bug from me. They are really not much help with time critical, multi-processor, interrupt driven, shared memory foul ups.
A classic case was when trying to write the assembler boot code required to get an Intel 386 from 16 bit mode into 32 bit protected mode. Sure my code was wrong but single stepping through it with the Intel In Circuit Emulator did not help. Everything crashed out on the crucial "go protected" instruction. Eventually I got the code right and it still crashed under the ICE. In frustration I eventually just let it run at full speed from boot and bingo! All was well. That debugger wasted three days of my life.
On the other hand, by single stepping with a debugger we did find that the Intel 286 produced the wrong result for an integer multiply by a immediate value that happened to be negative, in protected mode only of course.
Mostly debuggers are just annoying.
Of course adding printfs to the code can be just as annoying. They change timing and move things around in memory just enough to hide the problems.
No, what you need is an LSA and/or scope. And more usually a good look at the code and some "perturbation debugging".
As Roy pointed out, debuggers are a tool for programmers, just like a scope or logic analyzer is a tool for electrical engineers. How can you argue about this point?
A tool is only as good as the man using it. In order to use any tool properly, you must be educated on it's proper usage. If you have not been educated on it's proper usage, then you cannot reasonably state that the tool is useless. And even though there are many seasoned programmers in the world, I am certain that a large portion of them have not been properly educated on the use of a debugger.
There is one area of programming that I have found debuggers especially useful and that is discovering the existence of memory leaks. Good luck discovering those with print statements.
There is one area of programming that I have found debuggers especially useful and that is discovering the existence of memory leaks. Good luck discovering those with print statements.
For those cases then you still don't need any debugger. You make the printf at every function call and return, writing the subrutine address, the memory/stack_pointer and time. And redirect the output to memory or file (if fast enough). And then you have invented something called 'Profiling' (kind of brute force printf).
Of course adding printfs to the code can be just as annoying. They change timing and move things around in memory just enough to hide the problems.
I agree with all of this.
I would add that the Propeller is uncommonly (and almost uniquely) useful in debugging itself. A spare cog is both powerful and unobtrusive when used to spy on other processes without affecting the timing or memory usage of those other processes.
I certainly don't advocate a Spin-only release; we've already made that mistake. I was only pointing out that all P1 commercial designs use Spin/ASM. P2 could only be released if we have Spin and C, both complete. The former is a necessity for the inventor and many existing customers; the latter is to grow a market much larger than we have at present.
There's so much more to consider than these tools, though. We will need to segment our customers properly for education and commercial, speaking to each of them directly.
I think that you will find that there will be many commercial customers for the P2 that will use C instead of Spin. With 512K of RAM, the P2 will be much less hindered by memory space than the P1 is. This will allow for much larger applications to run on the P2, and I believe C will lend itself better to these applications. Many new commercial customers will require a standard programming language, such as C or C++, and would not consider a non-standard proprietary language such as Spin.
I built some test equipment at my last job that used the P1. It measured time delays between video and audio. I could have done the job in Spin, but I decided to use C instead. It would not have been efficient to require my coworkers to learn Spin in case they needed to modify the code.
I certainly don't advocate a Spin-only release; we've already made that mistake. I was only pointing out that all P1 commercial designs use Spin/ASM. P2 could only be released if we have Spin and C, both complete. The former is a necessity for the inventor and many existing customers; the latter is to grow a market much larger than we have at present.
There's so much more to consider than these tools, though. We will need to segment our customers properly for education and commercial, speaking to each of them directly.
FYI My commercial design that uses 3 propeller chips runs Catalina C on one of the props using XMM (external 512KB of SRAM).
I agree there will be many more wanting to use C in some cog(s) in P2 designs.
Anyway, I know that you and Parallax understand this, even though some may not.
I certainly don't advocate a Spin-only release; we've already made that mistake. I was only pointing out that all P1 commercial designs use Spin/ASM. P2 could only be released if we have Spin and C, both complete. The former is a necessity for the inventor and many existing customers; the latter is to grow a market much larger than we have at present.
There's so much more to consider than these tools, though. We will need to segment our customers properly for education and commercial, speaking to each of them directly.
FYI My commercial design that uses 3 propeller chips runs Catalina C on one of the props using XMM (external 512KB of SRAM).
I agree there will be many more wanting to use C in some cog(s) in P2 designs.
Anyway, I know that you and Parallax understand this, even though some may not.
Catalina C? We haven't heard from Ross in ages. Any idea if he intends to add a P2 code generator to Catalina?
Comments
I don't think anyone would trust me as for sure I would build a Spin2 interpreter on top of Tachyon and sneak Forth onto every board just like Mitch Bradley did with Forth as the boot ROM in Sun workstations, which later became OpenFirmware etc.
OpenSpinware, oh my.
However, not all problems are real-time problems, so more than just one tool in the toolbox, is often much smarter.
Long before I fire up the scope, I am tuning code in a software simulator, reducing size and increasing speed, as well as doing self-test generator cases that a scope alone cannot get close to.
These software test suites are all ready to run, instantly, in 6 months time, no need to set up another test bench...
Well then, it sounds to me that Parallax has a wonderful and powerful opportunity, to step in and take over where the others fail. Even if they have to start their motion control code from scratch, the motion control industry seems like a worthy target market to start with. Think of it as a starting point for P2 sales and then build other markets from there.
If the P2 can overcome the shortfalls of other motion control processors, such as a full blown G-Code interpreter, as well as amply handling various control and process signaling, then where else is a better market for the P2? Will somebody please enlighten me as to a better possible use for the P2?
It's not mutually exclusive.
Why not???
After all, it doesn't matter how it is done, just that it works nicely!
The Micromite MBasic has gained a lot of traction on the PIC micros, and now it's available on the Raspberry Pi. It's the simple interactive nature of Basic that has the interest. No reason why Spin2 couldn't provide an equivalent interactive environment.
I know it's not. I just don't want to see the P2 released with just Spin/Pasm. Or relegating C/C++ to the basement.
The point is to get larger commercial vendors interested in the P2. Now if they're told do it the Parallax/Chip approved way or no way. They'll walk away like they did on the P1.
Industry expects C/C++ to be defacto development language for embedded controllers along with a debuggers. Yes I know the P1 programmers here don't use debuggers - they use LED's, scopes, logic analyzers, etc.
But the point is, is to show industry that the P2 is mainstream just as any ARM or PIC and with a tool set they can transfer their knowledge to without too much effort.
Of course this is where several killer demos on a P2 Eval board come into play as well. Got to get their attention first above all else. Have to show them it's a valid alternative to ARM, PIC32 or DSC.
The other part of the rationale of having a nice C/C++ IDE for the P2 is to make the P2 acceptable to the pointy haired boss types that approve it's use.
This is contrary to Ken's observation, quoted here:
-Phil
Also, industry standard programming languages are required by many potential customers who might use the P2. It doesn't matter how great Spin/PASM is, their company likely won't even let them look at the P2. At many places, that means C. This is a reality, sorry if you don't like it.
I personally will use Spin/PASM for many things, and C/C++ for some things on P1 and P2, but that doesn't mean diddly squat. I'm not a large company that Parallax could sell 10s or 100s of thousands of units to for a product.
Roy, you stated that very well.
Dave, yep those stack dumps look pretty bewildering to me.
David, I am right there with you on this
For max compiled code size of 4K (small PICs etc), does this slip under your personal debugger requirement?
Quick observation here. Does Parallax want to predict potential P2 use based on the current commercial customers, or what they "potentially" could have if they go a different route?
Yes, your current commercial customer's may now be using Spin/ASM. However, that may be based on the hard-core, "Parallax or bust" customers. What you really might want to consider is all of the customers they lost[, who didn't want to use Spin/ASM.
In my opinion, to grow the business, versus maintaining the business, you need to focus on customers and markets you don't have, versus ones you do have. In all honesty, your hardcore customers are going to be happy with anything you offer - be it hammered hieroglyphics on stone tablets, or programming the P2 using Morse code and a paddle key. You don't have to worry about those guys (I'm joking of course for the non-humorous folks). Look at the markets that have passed you by. Parallax was here LONG before the other folks out there, yet they have moved on, and whole industry's and market's have popped up, without Basic Stamps and Propellers.
But we've definitely veered off-topic with this little detour.
-Phil
I guess the argument in this thread is more about priorities. Time spent developing a debugger is time spent not doing something else, and Parallax has very limited resources.
Programming style isn't enough when you have a sufficiently large/complex software project. It can reduce the need, but not eliminate it.
Also, when you have many programmers working on the project (we have as many as 50 on projects where I work), things become much more difficult all around.
Debuggers save time, and time is money.
A Debugger can also help find hardware bugs. I have found a few of these in my 30+ years of coding.
There's so much more to consider than these tools, though. We will need to segment our customers properly for education and commercial, speaking to each of them directly.
The times when I have really needed a tool to help track down a bug are the times when debuggers do their best to hide the bug from me. They are really not much help with time critical, multi-processor, interrupt driven, shared memory foul ups.
A classic case was when trying to write the assembler boot code required to get an Intel 386 from 16 bit mode into 32 bit protected mode. Sure my code was wrong but single stepping through it with the Intel In Circuit Emulator did not help. Everything crashed out on the crucial "go protected" instruction. Eventually I got the code right and it still crashed under the ICE. In frustration I eventually just let it run at full speed from boot and bingo! All was well. That debugger wasted three days of my life.
On the other hand, by single stepping with a debugger we did find that the Intel 286 produced the wrong result for an integer multiply by a immediate value that happened to be negative, in protected mode only of course.
Mostly debuggers are just annoying.
Of course adding printfs to the code can be just as annoying. They change timing and move things around in memory just enough to hide the problems.
No, what you need is an LSA and/or scope. And more usually a good look at the code and some "perturbation debugging".
As Roy pointed out, debuggers are a tool for programmers, just like a scope or logic analyzer is a tool for electrical engineers. How can you argue about this point?
A tool is only as good as the man using it. In order to use any tool properly, you must be educated on it's proper usage. If you have not been educated on it's proper usage, then you cannot reasonably state that the tool is useless. And even though there are many seasoned programmers in the world, I am certain that a large portion of them have not been properly educated on the use of a debugger.
There is one area of programming that I have found debuggers especially useful and that is discovering the existence of memory leaks. Good luck discovering those with print statements.
For those cases then you still don't need any debugger. You make the printf at every function call and return, writing the subrutine address, the memory/stack_pointer and time. And redirect the output to memory or file (if fast enough). And then you have invented something called 'Profiling' (kind of brute force printf).
I agree with all of this.
I would add that the Propeller is uncommonly (and almost uniquely) useful in debugging itself. A spare cog is both powerful and unobtrusive when used to spy on other processes without affecting the timing or memory usage of those other processes.
I built some test equipment at my last job that used the P1. It measured time delays between video and audio. I could have done the job in Spin, but I decided to use C instead. It would not have been efficient to require my coworkers to learn Spin in case they needed to modify the code.
FYI My commercial design that uses 3 propeller chips runs Catalina C on one of the props using XMM (external 512KB of SRAM).
I agree there will be many more wanting to use C in some cog(s) in P2 designs.
Anyway, I know that you and Parallax understand this, even though some may not.
He moved south to operate a B&B, and I would presume that will likely take all his time