Propeller C debug architecture
ImageCraft
Posts: 348
If you read the post on "RFC: Propeller C Runtime Architecture," you may notice that there is a primitive called @debug. Here's how it may work:
At the low level, in order to support debugging, there must exist a method for the debugger to stop the running program and read/write processor data. In modern microcontrollers, usually they provide some on-chip debug logic such as JTAG, BDM etc. to support this. Once we have this capability, then the high level portion of the debugger running on the host PC provides all the source level debugging features that you may be familiar with.
With the Propeller, there's no such on chip logic, but since we are going to use Large Memory Model for Propeller C anyway, we have something better, we have 8 CPUs at our disposal! If we dedicate one CPU to communicate to the host, then the job is fairly trivial. Since the workload is really rather modest, it can be made into a lightweight thread later on if we don't want to waste a full CPU for the job. Some HUB RAM will be used for data exchange and instruction storage, but the need is also modest.
The function of the debug thread is to communicate with the host program (RS-232) and coordinate all the data exchange between the host and all the Propeller CPUs. Here's a simple example:
- on the PC debugger, you want to stop when the execution goes to function X
- the debugger finds out the address (Y) for function X, and sends a command to the Propeller debug channel
- the Propeller debug thread sees the command and modify the instruction at Y to be the @debug command, after saving the original instruction somewhere.
- eventually the @debug command is executed on some CPU. It then sets a flag so that the debug thread may now tell the host debugger then the breakpoint has been reached.
- at this point, you may use the host CPU to examine or modify the program data.
There will be options to either let all the other CPUs run or stop them all while X is stopped.
We will support debugging of all processes in different CPUs. In fact, this is another reason why I don't want to commit to a threading model yet - we know we need to support at least 8 CPU processes, threading will introduce more complexity that may not be warranted in the end - I see the current generation of Propeller being memory limited and threading does not solve that problem. TurboProp may be the answer with more COGs and more memory.
If you have not used a high level debugger before, trust me on this: a good debugger can really save you from pulling hair off your head at times
. Of course we know debuggers are for wimps and that what's wrong with debugging with blinking LEDs (or the luxury of printf!), but you only have so much hair on your head And if you think debugging single process program is difficult without a debugger, wait til you have multiple processes going at once.
The bad news? We will NOT have a debugger at first release. We are looking at different options but they will take a while to close off. Just thought I would share this with you folks though.
// richard
At the low level, in order to support debugging, there must exist a method for the debugger to stop the running program and read/write processor data. In modern microcontrollers, usually they provide some on-chip debug logic such as JTAG, BDM etc. to support this. Once we have this capability, then the high level portion of the debugger running on the host PC provides all the source level debugging features that you may be familiar with.
With the Propeller, there's no such on chip logic, but since we are going to use Large Memory Model for Propeller C anyway, we have something better, we have 8 CPUs at our disposal! If we dedicate one CPU to communicate to the host, then the job is fairly trivial. Since the workload is really rather modest, it can be made into a lightweight thread later on if we don't want to waste a full CPU for the job. Some HUB RAM will be used for data exchange and instruction storage, but the need is also modest.
The function of the debug thread is to communicate with the host program (RS-232) and coordinate all the data exchange between the host and all the Propeller CPUs. Here's a simple example:
- on the PC debugger, you want to stop when the execution goes to function X
- the debugger finds out the address (Y) for function X, and sends a command to the Propeller debug channel
- the Propeller debug thread sees the command and modify the instruction at Y to be the @debug command, after saving the original instruction somewhere.
- eventually the @debug command is executed on some CPU. It then sets a flag so that the debug thread may now tell the host debugger then the breakpoint has been reached.
- at this point, you may use the host CPU to examine or modify the program data.
There will be options to either let all the other CPUs run or stop them all while X is stopped.
We will support debugging of all processes in different CPUs. In fact, this is another reason why I don't want to commit to a threading model yet - we know we need to support at least 8 CPU processes, threading will introduce more complexity that may not be warranted in the end - I see the current generation of Propeller being memory limited and threading does not solve that problem. TurboProp may be the answer with more COGs and more memory.
If you have not used a high level debugger before, trust me on this: a good debugger can really save you from pulling hair off your head at times
. Of course we know debuggers are for wimps and that what's wrong with debugging with blinking LEDs (or the luxury of printf!), but you only have so much hair on your head And if you think debugging single process program is difficult without a debugger, wait til you have multiple processes going at once.The bad news? We will NOT have a debugger at first release. We are looking at different options but they will take a while to close off. Just thought I would share this with you folks though.
// richard
Comments
Scott
Thank you for your kind words.
UGH, stupid Firefox killed my post...
Our current pricing scheme for our other products is as follows:
STD - $199 - good enough for commercial work
ADV - $349 - advanced capabilities depending on the target processors
PRO - $549 - global optimizer, and new 64 bits floating point etc.
We will release the STD version first. Since at least currently, most Propeller C users are hobbyists, I'd imagine that the STD version will be the most popular version even after we release advance versions. Hopefully this will change as more professional adopt the Propeller and Propeller C. I also understand that $199 is a lot of money for hobbyists. We do base the pricing scheme on the assumption that a good number of the users are professional. So will we release Propeller C with lower price point? May be. The basic criterion is always: does dropping the price by 50% increase the sales by at least 2X? If not, then it is not worth it. We will probably run some sort of "early bird" special regardless anyway. Foe the professional users, $199 is cheap since our competitors start their pricing at $1500+ or $2500+!
Also keep in mind that we will probably follow the current policy of making the demo fully functional for 45 days. Afterward, the demo will change to code size limited to X KBytes for non-commercial use. Not sure what X is yet, but it probably will be 4KB limited for Propeller C.
The debugger will be separate. If we can convince our long time partner www.noicedebugger.com to support Propeller, then the debugger will probably cost $99, which again is quite a bargain. If we end up developing our own solution or licensing another product, the cost will once again be different.
Thanks for your interest.
// richard