Rubbish. If Chip added JTAG (very unlikely), then you or someone else would find something else to complain about.
I still think that it's going to be a major obstacle when Parallax tries to sell the Prop 2 to professionals. I just checked the Parallax Semiconductor web site and I can't see anything there about debugging techniques for use with the Prop 1, which is surprising. There should be a relevant app. note.
JTAG alone can't debug anything ---> to that needs adding info what PINs else other signals shall internaly be scanned. In JTAG chain.
And not entire ICs signals can be added to that chain.
Ps. Only on FPGA I can add any signal I wish for debuging.
Leon, how many people have to tell you that you are being disruptive to an otherwise positive and productive forum before it registers that you are out of line?
Leon, how many people have to tell you that you are being disruptive to an otherwise positive and productive forum before it registers that you are out of line?
What exactly makes my comments disruptive? Perhaps someone from Parallax or a moderator should adjudicate.
This particular case is difficult because there isn't a good rule, or rule condition test that can factor this kind of thing out of the discussion without impacting the quality and potency of the potential discussions.
It comes down to whether or not the participants are more important than the message advocacy is. Seriously.
We know you think no JTAG is an obstacle. That's not going to change either. The die is cast, meaning now it's all about making the best of what will come. Or... a few years of, "I told you so..." type discussions. Right now though, "I told you so" really makes no sense, because we've got no result data to gloat over.
I understand I told you so. Sometimes a good one is gratifying. I don't understand constant nags that have no productive end game, which is why I asked what I did.
It all is rather futile, reeking of "It's the end times" type vibes and nobody really wants that. Really. Nobody.
Leon, if nothing else, your posts are very entertaining and thought provoking. There are cetainly applications where the 50c processor is a better choice than the Propeller. There are also cases where the Prop is a better choice than the 50c processor. In fact, I can see where the Prop + 50c might be a really good combination. This would allow the Prop to use all 8 cogs for other things that it does best.
It is true that JTAG is used in many chips that are used by profesionals. Depending on the application, a debugger that uses the JTAG interface is very important. PropGCC will support the GDB debugger in the future. This will support LMM and XMM operation. There is a problem with using the debugger in the COG mode. I'm not sure how that will be resolved without JTAG. One approach would be to compile breakpoints into the COG code, and include a small debug kernel in the code. I've never used codeviewViewPort PASD, but maybe that's how it works. Personally, I prefer using printf's, but I know others prefer a debugger.
EDIT: As you can probably infer from the strikeouts in my post, I'm not very familiar with debuggers available for the Prop. After a quick search I found that PASD is a PASM debugger, and ViewPort is a Spin debugger. There are also the GEAR and SpinSim simulators. SpinSim has been used with the GDB debugger to a certain extent, but it's not fully integrated. In theory, SpinSim could be used with GDB to provide COG-level debugging.
XMOS uses gdb for debugging, via JTAG. It's likely to be rather slow on the Propeller, and using it without external memory is going to be difficult.
Many years ago, the first thing I did when I needed to work with a new processor was to implement a serial port and write a debugger that handled program loading, breakpoints, register/memory display, etc.
It is true that JTAG is used in many chips that are used by profesionals. Depending on the application, a debugger that uses the JTAG interface is very important. PropGCC will support the GDB debugger in the future. This will support LMM and XMM operation. There is a problem with using the debugger in the COG mode. I'm not sure how that will be resolved without JTAG. One approach would be to compile breakpoints into the COG code, and include a small debug kernel in the code.
JTAG is just a smart shift register, at the hardware level, and if the Chip to Chip opcodes documented in the Prop 2 are real, there will be (8?) shift registers available. (and faster than any JTAG link)
Of course, something smart has to connect to this high speed pipe, either a FPGA, or obviously, a Prop2 dedicated for Debug.
Software on top of this could include what I'd call a silicon based simulator : One that does not run a COG at full speed, but does use the cog flags and full HW and pin-access, to give a better simulator than a PC alone.
Some chips add some extra silicon to help the Debug (not just JTAG shifters), and that can be Multiple Hardware breakpoint registers, and some even break on Stack and Memory access.
Doing that per-cog would quickly choke the silicon under creeping featurism, and as soon as you stop a COG, you have lost the real time aspect, which is very important on a Prop.
For hard real time applications, I think Debug is best limited to mostly 'snooping' tasks.
What could be useful, and have low silicon cost, would be a Cog Status read - just a single 32 bit global would allow 4 bits per COG, which could flag what the COG was up to : 16 states covers everything short of an actual PgmCtr grab.
It would show Idle, Full Speed fetch, and numerous WAITxxx choices, and a sampled build up of this, would profile your code.
This would catch the 'oops' where programmers forgot to correctly configure a WAITxx.
There aren't any "end of times vibes" going on. Leon just says a few obvious things about costs and debugging and team fanbois act like Mr. Creosote just showed up. Really, it's over the top and then some. It's just a slab of silicon that may or may not be useful to people at a given point in time.
Let me be clear: I don't think so either. It reeks of that same kind of vibe, and in particular, adds very little value, mostly because it's framed in specific cost terms that do not account for more holistic product design approaches to compete, and in debugging terms that are not universally superior.
Anyway, I wanted to know why, and I got an answer that I understand. That helps me tune it out better than I would otherwise, which is why I asked this time.
Let me be clear: I don't think so either. It reeks of that same kind of vibe, and in particular, adds very little value, mostly because it's framed in specific cost terms that do not account for more holistic product design approaches to compete, and in debugging terms that are not universally superior.
Oh that makes it much clearer. Let me make sure I understand the major points. vibe, cost terms, holistic, universally superior. Got it!
There aren't any "end of times vibes" going on. Leon just says a few obvious things about costs and debugging and team fanbois act like Mr. Creosote just showed up. Really, it's over the top and then some. It's just a slab of silicon that may or may not be useful to people at a given point in time.
Leon makes the same argument year, after year, after year, after year. If I see his name in this forum, I know what his post will be... he's there to explain why you should have used another MC and by god you'll agree or he'll be there to repeat it again. Discuss what you can do with the software, he's there to remind us all for the 1500th time that part X has feature Y in hardware. It doesn't take a fanboy to grow weary of that.
I welcome the "holistic vibes" approach to engineering projects
Makes a change from all that "leveraging synergy" business. Never did get the hang of that.
Ok, since I asked for it on holistic, here is what I mean by that. There is the bare product, there are features, there is packaging, service, service life, related products and service, etc...
A product design company may choose to compete strictly on the scope of the product core merits, or they may choose to differentate in some way, potentially a unique way.
In the context of, "why use an expensive part when a cheap one will do?", this means expanding the scope or feature set of the product in some way that wouldn't otherwise be identified as being core to the value. It's not all about the lowest cost all of the time. If it were, Apple computer, by way of one very nice example, would not be in the fine position they currently are in. It is not always about the cheapest BOM.
I'll not say any more, other than Parallax themselves did this and continues to do this and are strongly differentiated as a result.
JTAG is vastly overrated, and so slow that it's good for only the most mundane debugging. Give me a spare cog any day!
But it could help Leon and Harprit...the ravages of age and all. I suppose we'll all be there someday.
On what devices have you found JTAG to be too slow? I've used it on lots of high-speed systems with various IDEs and JTAG interfaces and have found it to have no effect whatsoever on performance. Updating of registers and variables in the IDE when execution is halted or the device is single-stepped takes place instantaneously.
One advantage of getting old is the amount of experience that one accrues.
i think its good idea read the title of this thread. On my case i am agree about that its frustating learn propeller. its true that the forun help a lot, at least every time i have a question, i get help from you guys. most of the people here have experience in micros andbase on that, its easy to learn spin but the other side of the history its customer like me that want to learn. parallax have the basic stamp GREAT to learn.... after you finish with what its a micro you start building a robot with the next book. all books related to basic stamp have a LOT of examples and show you step by step how to use the basic stamp. went you finish with the basic stamp you want to go to the propeller and for meat leastits went the problem start. up today i was unable to find a book that show me the propeller on the same way and examples that parallax did with the basic stamp. (SORRY FOR MY ENGLISH)
i think its good idea read the title of this thread. On my case i am agree about that its frustating learn propeller. its true that the forun help a lot, at least every time i have a question, i get help from you guys. most of the people here have experience in micros andbase on that, its easy to learn spin but the other side of the history its customer like me that want to learn. parallax have the basic stamp GREAT to learn.... after you finish with what its a micro you start building a robot with the next book. all books related to basic stamp have a LOT of examples and show you step by step how to use the basic stamp. went you finish with the basic stamp you want to go to the propeller and for meat leastits went the problem start. up today i was unable to find a book that show me the propeller on the same way and examples that parallax did with the basic stamp. (SORRY FOR MY ENGLISH)
When I first looked into working with the propeller I went out and bought the Propeller Education Kit. It didn't cost a lot of money and I still use the manual that came with it!
@jvrproductions
@4x5n
There have been some formal announcements in the last couple of months that Parallax is committed to having versions of "What's a Microcontroller?" for the Propeller as well as upgrading their educational offerings in general for the Propeller. If you haven't seen it yet, take a look at their new educational website which features projects done for the Stamps, Propeller, and Arduino. It will take some time, but I'm sure the rich library of translated tutorials will get upgraded as well.
Others,
This thread has reached the point where personal attacks have surfaced. If all parties involved would show a little restraint, we can continue. If not, the thread will become locked. Enough said?
Comments
Rubbish. If Chip added JTAG (very unlikely), then you or someone else would find something else to complain about.
I still think that it's going to be a major obstacle when Parallax tries to sell the Prop 2 to professionals. I just checked the Parallax Semiconductor web site and I can't see anything there about debugging techniques for use with the Prop 1, which is surprising. There should be a relevant app. note.
I can ADD more rubbish.
JTAG alone can't debug anything ---> to that needs adding info what PINs else other signals shall internaly be scanned. In JTAG chain.
And not entire ICs signals can be added to that chain.
Ps. Only on FPGA I can add any signal I wish for debuging.
What exactly makes my comments disruptive? Perhaps someone from Parallax or a moderator should adjudicate.
It comes down to whether or not the participants are more important than the message advocacy is. Seriously.
We know you think no JTAG is an obstacle. That's not going to change either. The die is cast, meaning now it's all about making the best of what will come. Or... a few years of, "I told you so..." type discussions. Right now though, "I told you so" really makes no sense, because we've got no result data to gloat over.
I understand I told you so. Sometimes a good one is gratifying. I don't understand constant nags that have no productive end game, which is why I asked what I did.
It all is rather futile, reeking of "It's the end times" type vibes and nobody really wants that. Really. Nobody.
It is true that JTAG is used in many chips that are used by profesionals. Depending on the application, a debugger that uses the JTAG interface is very important. PropGCC will support the GDB debugger in the future. This will support LMM and XMM operation. There is a problem with using the debugger in the COG mode. I'm not sure how that will be resolved without JTAG. One approach would be to compile breakpoints into the COG code, and include a small debug kernel in the code. I've never used codeview ViewPort PASD, but maybe that's how it works. Personally, I prefer using printf's, but I know others prefer a debugger.
EDIT: As you can probably infer from the strikeouts in my post, I'm not very familiar with debuggers available for the Prop. After a quick search I found that PASD is a PASM debugger, and ViewPort is a Spin debugger. There are also the GEAR and SpinSim simulators. SpinSim has been used with the GDB debugger to a certain extent, but it's not fully integrated. In theory, SpinSim could be used with GDB to provide COG-level debugging.
XMOS uses gdb for debugging, via JTAG. It's likely to be rather slow on the Propeller, and using it without external memory is going to be difficult.
Many years ago, the first thing I did when I needed to work with a new processor was to implement a serial port and write a debugger that handled program loading, breakpoints, register/memory display, etc.
JTAG is just a smart shift register, at the hardware level, and if the Chip to Chip opcodes documented in the Prop 2 are real, there will be (8?) shift registers available. (and faster than any JTAG link)
Of course, something smart has to connect to this high speed pipe, either a FPGA, or obviously, a Prop2 dedicated for Debug.
Software on top of this could include what I'd call a silicon based simulator : One that does not run a COG at full speed, but does use the cog flags and full HW and pin-access, to give a better simulator than a PC alone.
Some chips add some extra silicon to help the Debug (not just JTAG shifters), and that can be Multiple Hardware breakpoint registers, and some even break on Stack and Memory access.
Doing that per-cog would quickly choke the silicon under creeping featurism, and as soon as you stop a COG, you have lost the real time aspect, which is very important on a Prop.
For hard real time applications, I think Debug is best limited to mostly 'snooping' tasks.
What could be useful, and have low silicon cost, would be a Cog Status read - just a single 32 bit global would allow 4 bits per COG, which could flag what the COG was up to : 16 states covers everything short of an actual PgmCtr grab.
It would show Idle, Full Speed fetch, and numerous WAITxxx choices, and a sampled build up of this, would profile your code.
This would catch the 'oops' where programmers forgot to correctly configure a WAITxx.
There aren't any "end of times vibes" going on. Leon just says a few obvious things about costs and debugging and team fanbois act like Mr. Creosote just showed up. Really, it's over the top and then some. It's just a slab of silicon that may or may not be useful to people at a given point in time.
Anyway, I wanted to know why, and I got an answer that I understand. That helps me tune it out better than I would otherwise, which is why I asked this time.
Leon makes the same argument year, after year, after year, after year. If I see his name in this forum, I know what his post will be... he's there to explain why you should have used another MC and by god you'll agree or he'll be there to repeat it again. Discuss what you can do with the software, he's there to remind us all for the 1500th time that part X has feature Y in hardware. It doesn't take a fanboy to grow weary of that.
Makes a change from all that "leveraging synergy" business. Never did get the hang of that.
A product design company may choose to compete strictly on the scope of the product core merits, or they may choose to differentate in some way, potentially a unique way.
In the context of, "why use an expensive part when a cheap one will do?", this means expanding the scope or feature set of the product in some way that wouldn't otherwise be identified as being core to the value. It's not all about the lowest cost all of the time. If it were, Apple computer, by way of one very nice example, would not be in the fine position they currently are in. It is not always about the cheapest BOM.
I'll not say any more, other than Parallax themselves did this and continues to do this and are strongly differentiated as a result.
But it could help Leon and Harprit...the ravages of age and all. I suppose we'll all be there someday.
Speaking as an "old duffer" I would prefer it if the next version was free of abuse.
On what devices have you found JTAG to be too slow? I've used it on lots of high-speed systems with various IDEs and JTAG interfaces and have found it to have no effect whatsoever on performance. Updating of registers and variables in the IDE when execution is halted or the device is single-stepped takes place instantaneously.
One advantage of getting old is the amount of experience that one accrues.
When I first looked into working with the propeller I went out and bought the Propeller Education Kit. It didn't cost a lot of money and I still use the manual that came with it!
@4x5n
There have been some formal announcements in the last couple of months that Parallax is committed to having versions of "What's a Microcontroller?" for the Propeller as well as upgrading their educational offerings in general for the Propeller. If you haven't seen it yet, take a look at their new educational website which features projects done for the Stamps, Propeller, and Arduino. It will take some time, but I'm sure the rich library of translated tutorials will get upgraded as well.
Others,
This thread has reached the point where personal attacks have surfaced. If all parties involved would show a little restraint, we can continue. If not, the thread will become locked. Enough said?