Leon:
Fair enough. the Prop was not designed for easy debugging, a minor trade off for all the positives of the architecture. Maybe we could suggest that the Prop 3 have an instruction to pause/resume another cog, and another to dump another cogs memory?
When I learned x86 Machine language I was not given the assembly mnemonics, and I could not afford an assembler, so I worked in machine language. Even once I did learn x86 assembly, I found that most assemblers would not generate the INT3 single byte op, and most did not understand the STT/CLT instructions.
I'd use a macro to generate it. If the assembler didn't have a macro capability I'd simply use an external macro-processor. There are usually ways round little problems like that.
We feel that the Prop 2 will solve allot of our problems. The Prop 1 does very well in our school and vending machine Personal Access Devices, but just dosent have the horse power for our Point of Sale terminals. Eight cogs is fine for us and 128K of hub ram will reduce our need to constantly load new programs from an SD card.
We are now using two 16 bit I/O expanders and the I2C interface is slow, the Prop 2 will also solve this problem and allow us to drive the display with a 16 bit pipe instead of 8. One of the features the schools really want is called classroom windows, the cashier can bring up the students home room then select the student by touching there photo. This is no easy matter because some of the schools have thousands of students. Our current Prop 1 terminal just brings up the students photo which is stored locally in the SD card.
It amazes me how much several of you seem to hate or misunderstand the use of debuggers for code. Being a professional programmer, I use debuggers daily. When you are dealing with very large projects (multi-million lines of code) it's impractical to not have/use a debugger. I think it's ludicrous to say they should be avoided or that they are not needed. It's like saying you should do electronics without a multimeter and/or scope. Also, unit testing and bottom up approaches only get you so far when dealing with large complex projects. I do use unit testing and bottom up approaches a fair amount, but it's silly to think that they could replace a good debugger.
The main reason we can get by without real debugging on the Prop 1 is that we're dealing with a tiny amount of code in a much simpler environment. The Prop 2 will have a significantly larger and more complex environment in most cases, and a LOT more code involved for those projects. I think it's essential that it have some form of debugging facility built in, I don't really care if it's JTAG or not. If there are no debugging facilities in the Prop 2 then it will suffer lack of acceptance by a lot of professionals. It's fundemental and not something that can be explained away as not needed.
Roy
p.s. I am seriously astonished at the attitude towards debuggers some of you display... Wow.
Roy:
I do not think that any one has an opposition to debuggers, just to HW interrupts. If you wish to debug larger apps on the Prop II, no problem use a cog, you will be able to read/write hub mem from any of them.
I am seriously astonished at the attitude towards debuggers some of you display... Wow.
I suppose if you can mange your addiction, a debugger is okay. In my case, my dependence became unmanageable, my programming skills languished, my dog left me, my friends quit calling, and I hit a personal breakpoint. But I'm happy to say that, as a recovering debugaholic, I've been debugger-free for ten years, four months, and seventeen days now. I still get urges, though, and break into a cold sweat whenever I see someone single-stepping; so it's one day at a time for this kid, as I expect it will be for the rest of my life. But thanks to my faith in Tektronix and the Propeller serial port, my programming skills have benefited greatly, and I'm able to live a normal life.
Roy:
I do not think that any one has an opposition to debuggers, just to HW interrupts. If you wish to debug larger apps on the Prop II, no problem use a cog, you will be able to read/write hub mem from any of them.
HW interrupts don't have anything to do with debuggers, per se.
The lack of on-chip debugging will be a turn-off for many professionals who look at the Propeller (I or II).
I don't understand the antipathy to interrupts, I've been using for over 30 years without any problems. They are essential on conventional processors. XMOS provides them for users who want to use legacy code, but they aren't needed for new applications.
I don't say that debuggers are bad things.
BUT at have JTAG as religion as some of people show in this thread are more that I can understand.
In my work I have used debuggers to - not so much but in some work them was needed as Interrupts on CPU I used give me problems and only debugging of Stack space show me problems.
Mostly in simple programs I not have need for debugging - BUT as You said -- My code mostly was some 10000 lines - not so big problem to see problems.
Most of debugging are in time any write program -- Think logically.
I see nothing wrong with Interrupts. As per the design interrupts do not go with the Propeller. If you are using a micro that uses interrupts, use them.
On the debugging issue, debuggers with out interrupts are purely the domain of software, thus the Propeller and the Propeller II provide already everything needed to do the debugging that can be with out interrupts.
The 'X' MCU provides 'HW threads' these slow down the processor in proportion to the numger of threads, this is because the threads are being interleaved on a single ALU, with a limited pipelined instruction decoder, this method of interleaving is a form of HW interrupt, regardless what it is officially called. The x86 series began partial support for the same thing with the 80286 and 'Protected Mode Multitasking', admittedly with a little more work required on the side of the programmer though not much.
How do you single-step through your Spin or assembler code?
On a chip that will run it and has interrupts. Single stepping a binary is the domain of simulators, or interrupts. On the spin side, write a spin bytecode interpreter that can handle single stepping.
Being a professional programmer, I use debuggers daily. When you are dealing with very large projects (multi-million lines of code) it's impractical to not have/use a debugger. ...
This nails it pretty good.
It is unlikely that a million LOC (pointy haired manager acronym) will ever be used at once with a BasicStamp or even Propeller I (but possible on the latter). Someone may hit 1M LOC with prop2.
JTAG is really nice if you don't have on board SRAM and the JTAG actually works. However, I remember once in 1999 having a board where the hardware engineer kept blaming the JTAG equipment for all his problems. One of the guys in my group became such good friends with the Motorola FAE, that he decided to take a job there. I had to write a monitor program for the hardware that booted from socketed flash so we could debug it all. Good thing I knew how to write debug monitors. Later I found out that the board's ground plane was insufficient and the JTAG was not even properly buffered! The hardware guy was "let go" pretty fast after that.
Moral of the story? Don't count on your 'buggers before they're properly patched.
On a chip that will run it and has interrupts. Single stepping a binary is the domain of simulators, or interrupts. On the spin side, write a spin bytecode interpreter that can handle single stepping.
I single-step PASM binaries at will with very little extra effort or special hardware. Others do too with one of several tools.
Howdy!
I wrote ViewPort several years ago to help me with my project- a vision guided balancing robot. Since it started as a personal hobby project- ViewPort includes all sorts of non-standard fun capabilities, like a fuzzy logic engine, integration with openCV, a customizable graphical interface- and of course being able to monitor/change variables on the fly with real time graphs. Only later did I add more standard debugging tools like single stepping through spin code, breakpoint, view memory and more. I'm a software guy, so I'm a huge fan of the Prop's vision that peripheral functionality is provided by code, not hardware. Dedicating 1 of the 8 cogs to a debugger (more if you want up to sample the IO port at up to 80MSPS) during development shouldn't be a big deal for most users- especially since the Prop makes it easy to swap functionality in and out. Catalina C and BlackCat offer a similar debugging experience- also fully integrated in ViewPort- edit, run, debug... I really like Ken's target audience for the Prop2- smaller, boutique designers who appreciate the unique features and personal touch that Parallax has been providing for decades.
Hanno
I've actually raised the matter of debug hardware on the Parallax Semiconductor forum, pointing out that professional users will be expecting it, and there is no mention of debugging techniques on the web site. It isn't covered in the Propeller Manual, apart from saying that strings and the 'Here' symbol are useful. It isn't mentioned in the Prop II preliminary features list.
I'm doubt if such users will be impressed by the need to devote one or more cogs to the Spin debug function, if only on a temporary basis. What about assembly code? A lot of re-education might be needed.
Most users of other devices get debug software thrown in with the free IDE, and the debug interface is usually quite cheap and on a par with the Prop Plug.
I can only speak for myself. Having thus said; The issues that you are raising are related to the non Propeller world, and part of the reason that the Propeller is so Ideal for the MuAmi (No interrupts rule for this).
I could have as easily used some other MCU to accomplish my task successfully. I had originally planned on using three 65C816 MCUs, two ATMEGAs, and a couple of high speed eZ80s. In the initial design I was always trying to figure out how to get around interrupts, or how to get the timing of the interrupts such that they did not interfere, the Prop solved these issues. Yes I sacrificed some speed in order to use the Propeller, though I also decreased the overall development time, because I did not have to worry about Interrupts anymore .
I've actually raised the matter of debug hardware on the Parallax Semiconductor forum, pointing out that professional users will be expecting it, and there is no mention of debugging techniques on the web site. It isn't covered in the Propeller Manual, apart from saying that strings and the 'Here' symbol are useful.
Yes, 50c low pin count Micros can do Debug, so there is no real excuse for 'zero support'.
Some seem to think 'debug', means finding bugs, but the systems I use are more for measurement and analysis, and on a device like the Prop II, that will be more important.
If I was adding 'debug' to a device like Prop II, I would do the 1 or 2 pin Vanilla Serial interface, and also include some simple Logic Analyser silicon.
Code-Flight-time counters and time stamps, would allow more of the measurement and analysis detail, tho perhaps a virtual pin could be pressed into service ?
Who says that the Prop2 can not have JTAG ?
Just add a big 2x10pin connector to a developement board, waste 5 I/O pins and write a JTAG emulator object in one cog. Then you can sell a special JTAG adapter board for 1000$ or so (the more expensive, the more professional). Together with a PC frontend you can do debugging like on other chips. If the compiler would support it, you don't need to manually insert special debug objects and define variables.
For the users that are not so professional that they only can work with JTAG, the same functionality can be provided by a PropPlug interface for free.
It's all about software and support in the IDE. (And that is the real problem of Parallax).
I suppose that would work, but would waste a cog. JTAG doesn't need much hardware, and can use a lot fewer connections than 20 (most of them are ground). It could have been included on the chip from the start. Two wire debug is offered on the newer ARM Cortex devices, which offers most of the facilities provided by JTAG.
I can only add as Propeller II shall have timed out Wait on pin instructions and Internal Parallel PORT to communicate COG to COG -- That will be simple to accomplish.
I suppose that would work, but would waste a cog. JTAG doesn't need much hardware, and can use a lot fewer connections than 20 (most of them are ground). It could have been included on the chip from the start. Two wire debug is offered on the newer ARM Cortex devices, which offers most of the facilities provided by JTAG.
Just add a big 2x10pin connector to a developement board, waste 5 I/O pins and write a JTAG emulator object in one cog.
I know you were not entirely serious, but besides the cost of a whole Cog, this software only solution, cannot 'see' too well into other Cogs.
That is why some minimal Hardware support is needed, and in a Prop II, it should also allow capture of simple tag/time info in Real Time, from any core.
You can do a lot with a J.K/T FlipFlop, and the right access.
We developed a system years ago, that replaced the external code memory in uC systems, and gave J.K/T FF control from read of any memory address.
This allows measurement of Response times, loop times, idle times, and maximum rates.
The hardware cost is low, but the information given is Gold.
If you all are so interested in tracing execution times and logging cog registers, write it into your code (it would only take a few longs on the Propeller II). On the other hand if you are really really into this single stepping PASM or other binaries, either write an on chip simulator or use a micro that has interrupts for doing this kind of thing. If your biggest concern is single stepping C use Cattalina. If you must single step SPIN write a spin bytcode interpreter for the Prop II that can do this. If you want Parallax to do all the above for you talk to Beau, Chip, and Ken.
Waste one COG else silicon that needs for it.
Give same result.
The silicon needed is minimal, far less than that in a cog. That is why debug hardware is available in tiny 8-pin MCUs.
Parallax must prepare themselves for questions like these, if they hope to sell to professional developers, and should have the answers. At present, they don't!
Ok I really like the architecture of the Propeller as well as that of the Propeller 2. There are some applications were in interrupts get in the way way to much, these applications lend themselves to the Propeller architecture.
So I ask are we really reduced to quibbling like infants about the merits/demerits of the not yet released Propeller 2 and the fact it does not have dedicated HW for debugging as far as we know. Remember the Propeller II does have 8 pins in use during boot up, for all we know these could be related to HW debug support of some kind.
It will be important to professional users. It will affect their attitude to the Prop I, as well, and Parallax will be asked about it. Their main multi-core competitor uses it.
If you all are so interested in tracing execution times and logging cog registers, write it into your code (it would only take a few longs on the Propeller II). On the other hand if you are really really into this single stepping PASM or other binaries, either write an on chip simulator or use a micro that has interrupts for doing this kind of thing. If your biggest concern is single stepping C use Cattalina. If you must single step SPIN write a spin bytcode interpreter for the Prop II that can do this. If you want Parallax to do all the above for you talk to Beau, Chip, and Ken.
The whole point is to use some tiny percentage of Silicon, to make access even less invasive, and more informative.
Kludges can only go so far.
eg The newest Dual Cores from NXP, mention this for hardware level support :
JTAG and Serial Wire Debug (SWD), serial trace, eight breakpoints, and four watch
points.
So I ask are we really reduced to quibbling like infants about the merits/demerits of the not yet released Propeller 2 and the fact it does not have dedicated HW for debugging as far as we know.
The idea is to explain why it matters, and how designers use such facilities, and what the 'state of the art' currently is.
To me, it is not just 'debug', but also the ability to characterize and optimize.
The Prop II design team are reading this, so they can decide if the Small Silicon cost, is worth the effort.
Since the Propeller II has not yet been released and the design is finalized, it is of little use to quibble about the HW debug support that we have no idea if exists or not. It would appear we will probably have to wait to resolve this until the chip is released. If it does not, we will find the best ways to do what we need, if it does then grand.
I can not help but notice that this issue has been repeatedly brought up about the Prop II, and yet Parallax has been conspicuously silent on the issue, beings that they have told us almost everything else about the Propeller II this raises the question of why the silence in this. It has been said that Chip has plans for better on chip development tools. Could this also extend to better off chip interfaces for debugging and code tracking?
My main point here is we should be focusing these same energies on what can be done to improve the new market target for the Propeller I, which we already know has not HW debugging.
Comments
Fair enough. the Prop was not designed for easy debugging, a minor trade off for all the positives of the architecture. Maybe we could suggest that the Prop 3 have an instruction to pause/resume another cog, and another to dump another cogs memory?
When I learned x86 Machine language I was not given the assembly mnemonics, and I could not afford an assembler, so I worked in machine language. Even once I did learn x86 assembly, I found that most assemblers would not generate the INT3 single byte op, and most did not understand the STT/CLT instructions.
We are now using two 16 bit I/O expanders and the I2C interface is slow, the Prop 2 will also solve this problem and allow us to drive the display with a 16 bit pipe instead of 8. One of the features the schools really want is called classroom windows, the cashier can bring up the students home room then select the student by touching there photo. This is no easy matter because some of the schools have thousands of students. Our current Prop 1 terminal just brings up the students photo which is stored locally in the SD card.
The main reason we can get by without real debugging on the Prop 1 is that we're dealing with a tiny amount of code in a much simpler environment. The Prop 2 will have a significantly larger and more complex environment in most cases, and a LOT more code involved for those projects. I think it's essential that it have some form of debugging facility built in, I don't really care if it's JTAG or not. If there are no debugging facilities in the Prop 2 then it will suffer lack of acceptance by a lot of professionals. It's fundemental and not something that can be explained away as not needed.
Roy
p.s. I am seriously astonished at the attitude towards debuggers some of you display... Wow.
I do not think that any one has an opposition to debuggers, just to HW interrupts. If you wish to debug larger apps on the Prop II, no problem use a cog, you will be able to read/write hub mem from any of them.
-Phil
HW interrupts don't have anything to do with debuggers, per se.
The lack of on-chip debugging will be a turn-off for many professionals who look at the Propeller (I or II).
I don't understand the antipathy to interrupts, I've been using for over 30 years without any problems. They are essential on conventional processors. XMOS provides them for users who want to use legacy code, but they aren't needed for new applications.
I don't say that debuggers are bad things.
BUT at have JTAG as religion as some of people show in this thread are more that I can understand.
In my work I have used debuggers to - not so much but in some work them was needed as Interrupts on CPU I used give me problems and only debugging of Stack space show me problems.
Mostly in simple programs I not have need for debugging - BUT as You said -- My code mostly was some 10000 lines - not so big problem to see problems.
Most of debugging are in time any write program -- Think logically.
On the debugging issue, debuggers with out interrupts are purely the domain of software, thus the Propeller and the Propeller II provide already everything needed to do the debugging that can be with out interrupts.
Since you dug up the dead:
The 'X' MCU provides 'HW threads' these slow down the processor in proportion to the numger of threads, this is because the threads are being interleaved on a single ALU, with a limited pipelined instruction decoder, this method of interleaving is a form of HW interrupt, regardless what it is officially called. The x86 series began partial support for the same thing with the 80286 and 'Protected Mode Multitasking', admittedly with a little more work required on the side of the programmer though not much.
It is unlikely that a million LOC (pointy haired manager acronym) will ever be used at once with a BasicStamp or even Propeller I (but possible on the latter). Someone may hit 1M LOC with prop2.
JTAG is really nice if you don't have on board SRAM and the JTAG actually works. However, I remember once in 1999 having a board where the hardware engineer kept blaming the JTAG equipment for all his problems. One of the guys in my group became such good friends with the Motorola FAE, that he decided to take a job there. I had to write a monitor program for the hardware that booted from socketed flash so we could debug it all. Good thing I knew how to write debug monitors. Later I found out that the board's ground plane was insufficient and the JTAG was not even properly buffered! The hardware guy was "let go" pretty fast after that.
Moral of the story? Don't count on your 'buggers before they're properly patched.
I single-step PASM binaries at will with very little extra effort or special hardware. Others do too with one of several tools.
I wrote ViewPort several years ago to help me with my project- a vision guided balancing robot. Since it started as a personal hobby project- ViewPort includes all sorts of non-standard fun capabilities, like a fuzzy logic engine, integration with openCV, a customizable graphical interface- and of course being able to monitor/change variables on the fly with real time graphs. Only later did I add more standard debugging tools like single stepping through spin code, breakpoint, view memory and more. I'm a software guy, so I'm a huge fan of the Prop's vision that peripheral functionality is provided by code, not hardware. Dedicating 1 of the 8 cogs to a debugger (more if you want up to sample the IO port at up to 80MSPS) during development shouldn't be a big deal for most users- especially since the Prop makes it easy to swap functionality in and out. Catalina C and BlackCat offer a similar debugging experience- also fully integrated in ViewPort- edit, run, debug... I really like Ken's target audience for the Prop2- smaller, boutique designers who appreciate the unique features and personal touch that Parallax has been providing for decades.
Hanno
I'm doubt if such users will be impressed by the need to devote one or more cogs to the Spin debug function, if only on a temporary basis. What about assembly code? A lot of re-education might be needed.
Most users of other devices get debug software thrown in with the free IDE, and the debug interface is usually quite cheap and on a par with the Prop Plug.
I can only speak for myself. Having thus said; The issues that you are raising are related to the non Propeller world, and part of the reason that the Propeller is so Ideal for the MuAmi (No interrupts rule for this).
I could have as easily used some other MCU to accomplish my task successfully. I had originally planned on using three 65C816 MCUs, two ATMEGAs, and a couple of high speed eZ80s. In the initial design I was always trying to figure out how to get around interrupts, or how to get the timing of the interrupts such that they did not interfere, the Prop solved these issues. Yes I sacrificed some speed in order to use the Propeller, though I also decreased the overall development time, because I did not have to worry about Interrupts anymore
Yes, 50c low pin count Micros can do Debug, so there is no real excuse for 'zero support'.
Some seem to think 'debug', means finding bugs, but the systems I use are more for measurement and analysis, and on a device like the Prop II, that will be more important.
If I was adding 'debug' to a device like Prop II, I would do the 1 or 2 pin Vanilla Serial interface, and also include some simple Logic Analyser silicon.
Code-Flight-time counters and time stamps, would allow more of the measurement and analysis detail, tho perhaps a virtual pin could be pressed into service ?
Just add a big 2x10pin connector to a developement board, waste 5 I/O pins and write a JTAG emulator object in one cog. Then you can sell a special JTAG adapter board for 1000$ or so (the more expensive, the more professional). Together with a PC frontend you can do debugging like on other chips. If the compiler would support it, you don't need to manually insert special debug objects and define variables.
For the users that are not so professional that they only can work with JTAG, the same functionality can be provided by a PropPlug interface for free.
It's all about software and support in the IDE. (And that is the real problem of Parallax).
Andy
Good reply.
I can only add as Propeller II shall have timed out Wait on pin instructions and Internal Parallel PORT to communicate COG to COG -- That will be simple to accomplish.
Give same result.
I know you were not entirely serious, but besides the cost of a whole Cog, this software only solution, cannot 'see' too well into other Cogs.
That is why some minimal Hardware support is needed, and in a Prop II, it should also allow capture of simple tag/time info in Real Time, from any core.
You can do a lot with a J.K/T FlipFlop, and the right access.
We developed a system years ago, that replaced the external code memory in uC systems, and gave J.K/T FF control from read of any memory address.
This allows measurement of Response times, loop times, idle times, and maximum rates.
The hardware cost is low, but the information given is Gold.
The silicon needed is minimal, far less than that in a cog. That is why debug hardware is available in tiny 8-pin MCUs.
Parallax must prepare themselves for questions like these, if they hope to sell to professional developers, and should have the answers. At present, they don't!
So I ask are we really reduced to quibbling like infants about the merits/demerits of the not yet released Propeller 2 and the fact it does not have dedicated HW for debugging as far as we know. Remember the Propeller II does have 8 pins in use during boot up, for all we know these could be related to HW debug support of some kind.
The whole point is to use some tiny percentage of Silicon, to make access even less invasive, and more informative.
Kludges can only go so far.
eg The newest Dual Cores from NXP, mention this for hardware level support :
JTAG and Serial Wire Debug (SWD), serial trace, eight breakpoints, and four watch
points.
This link
http://www.iqmagazineonline.com/current/pdf/IQ_V9_N4_Pg12-14-394006007.pdf
mentions 256K SRAM, and sub $10. This for a device designed in 2010.
The idea is to explain why it matters, and how designers use such facilities, and what the 'state of the art' currently is.
To me, it is not just 'debug', but also the ability to characterize and optimize.
The Prop II design team are reading this, so they can decide if the Small Silicon cost, is worth the effort.
I can not help but notice that this issue has been repeatedly brought up about the Prop II, and yet Parallax has been conspicuously silent on the issue, beings that they have told us almost everything else about the Propeller II this raises the question of why the silence in this. It has been said that Chip has plans for better on chip development tools. Could this also extend to better off chip interfaces for debugging and code tracking?
My main point here is we should be focusing these same energies on what can be done to improve the new market target for the Propeller I, which we already know has not HW debugging.